คุยกับ AI แล้วรู้สึกว่า 'ง่ายนี่หว่า'? — แผนที่ภูเขาน้ำแข็งของสิ่งที่ต้องรู้จริง ก่อนเอา AI เข้า production

ช่วงนี้ผมได้ยินประโยคทำนองนี้บ่อยขึ้นเรื่อย ๆ — “เดี๋ยวเอา AI มาตอบลูกค้าแทนทั้งหมดเลย” “ให้ AI อ่านเอกสารทั้งบริษัทแล้วตอบได้ทุกเรื่อง” “ทีมเราไม่ต้องจ้าง dev เพิ่มแล้ว ให้ AI เขียนให้” และที่น่ากังวลที่สุดคือประโยคเหล่านี้มักตามมาด้วย “ผมลองคุยกับ ChatGPT ดูแล้ว มันทำได้จริง ๆ นะ”

นั่นแหละครับ คือจุดเริ่มต้นของอาการ “เพ้อ” ที่กำลังระบาดในวงการตอนนี้ — ความมั่นใจที่เกิดจากการคุยกับ AI ไม่ใช่จากการสร้างระบบด้วย AI ซึ่งเป็นคนละทักษะ คนละโลก และห่างกันหลายเดือนของการเรียนรู้

บทความนี้ไม่ได้เขียนมาเพื่อบอกว่า AI ใช้งานจริงไม่ได้ — ใช้ได้ และหลายที่ใช้ได้ผลมาก แต่เขียนมาเพื่อกางให้ดูว่าใต้ผิวน้ำของเดโมที่ดูง่าย มีภูเขาน้ำแข็งของเรื่องที่ต้องเข้าใจอยู่กี่ก้อน แล้วให้คุณถามตัวเองตรง ๆ ว่า แต่ละก้อนคุณเข้าใจถึงไหน

ทำไมการคุยกับ AI ถึงหลอกเราได้แนบเนียน

ก่อนไปถึงเรื่องเทคนิค ต้องเข้าใจก่อนว่าทำไมคนฉลาด ๆ จำนวนมากถึงประเมินความยากพลาดพร้อมกันทั้งวงการ

หนึ่ง — แชตคือเดโมที่สมบูรณ์แบบที่สุดในโลก เวลาคุณคุยกับ AI คุณกำลังทำหน้าที่เป็นทั้ง context provider (ป้อนข้อมูลแวดล้อมให้เอง), error handler (ถามใหม่เมื่อคำตอบเพี้ยน), และ evaluator (ตัดสินเองว่าคำตอบใช้ได้) — สามหน้าที่นี้คืองานที่ยากที่สุดในการสร้างระบบ AI จริง และในเดโม คุณทำมันให้ฟรีโดยไม่รู้ตัว พอเอาคุณออกจากลูป ระบบต้องทำสามอย่างนี้เองทั้งหมด นั่นคือจุดที่โปรเจกต์ล้ม

สอง — โมเดลตอบทุกอย่างด้วยความมั่นใจเท่ากัน ไม่ว่าจะถูกหรือผิด น้ำเสียงมันเหมือนกันหมด คนที่ไม่ได้ตรวจสอบเชิงลึกจะรู้สึกว่า “มันตอบได้หมดเลย” ทั้งที่ความจริงคือ “มันพูดได้หมด” ซึ่งไม่เหมือนกัน

สาม — ช่องว่างระหว่าง 80% กับ 99% มันมองไม่เห็นจากเดโม ระบบที่ถูก 80% ทำเดโมได้สวยมาก แต่ในงานจริง ผิด 1 ใน 5 ครั้งคือหายนะสำหรับหลาย use case และการไต่จาก 80% ไป 99% นั้นยากกว่าการไปถึง 80% แรกหลายเท่า — งานวิศวกรรมเกือบทั้งหมดอยู่ตรงช่วงนี้

ทีนี้มาดูกันว่า “ใต้ผิวน้ำ” มีอะไรบ้าง

ก้อนที่ 1: Model type — โมเดลไม่ได้มีแบบเดียว และมันไม่ใช่ฐานข้อมูล

คำถามแรกที่คนมักตอบไม่ได้: ระบบของคุณควรใช้โมเดลแบบไหน?

• Chat / instruct model — ตอบบทสนทนาทั่วไป เร็ว ถูก เหมาะกับงานส่วนใหญ่
• Reasoning model — คิดหลายขั้นก่อนตอบ แม่นกว่าในงาน logic/คณิต/โค้ดยาก แต่ช้ากว่าและแพงกว่าหลายเท่า ใช้กับงานง่ายคือเผาเงินเล่น
• Embedding model — ไม่ได้ “ตอบ” อะไรเลย มันแปลงข้อความเป็นเวกเตอร์เพื่อใช้ค้นหา — หัวใจของ RAG
• Reranker, classifier, โมเดลเล็กเฉพาะทาง — ตัวประกอบที่ระบบจริงใช้กันเต็มไปหมด แต่ไม่เคยปรากฏในเดโม

และเรื่องที่ต้องตอกย้ำเพราะเข้าใจผิดกันมากที่สุด: โมเดลภาษาไม่ใช่ฐานข้อมูล มันไม่ได้ “เก็บ” ข้อมูลบริษัทคุณ ไม่รู้จักข่าวหลังวัน cutoff และเมื่อไม่รู้ มันจะแต่งคำตอบที่ฟังดูดีขึ้นมา (hallucination) — นี่ไม่ใช่บั๊กที่รอแพตช์ แต่เป็นธรรมชาติของสถาปัตยกรรม ระบบจริงจึงต้องออกแบบโดยยอมรับข้อนี้ ไม่ใช่หวังว่ามันจะหายไป

ยังไม่นับเรื่อง context window (โมเดลรับข้อมูลได้จำกัด และยิ่งยาวยิ่งแม่นน้อยลง), ราคาต่อ token, latency ต่อคำตอบ — ตัวเลขพวกนี้กำหนดว่าสถาปัตยกรรมแบบไหน “เป็นไปได้” ทางธุรกิจบ้าง

ก้อนที่ 2: RAG — ไม่ใช่ “ต่อ vector database ก็จบ”

RAG (Retrieval-Augmented Generation) คือคำตอบมาตรฐานของโจทย์ “ให้ AI ตอบจากข้อมูลของเรา” และเป็นจุดที่ความเพ้อชนกำแพงความจริงบ่อยที่สุด เพราะหลักการฟังดูง่ายมาก: เอาเอกสารมาตัดเป็นชิ้น แปลงเป็นเวกเตอร์ พอมีคำถามก็ค้นชิ้นที่เกี่ยวแล้วแนบให้โมเดลตอบ

แต่ในทางปฏิบัติ ทุกขั้นคือจุดที่พังได้:

• Chunking — ตัดเอกสารยังไงไม่ให้ความหมายขาดกลาง? ตารางในไฟล์ PDF ตัดแล้วเหลืออะไร? หัวข้อกับเนื้อหาหลุดจากกันไหม?
• Retrieval — คำถามภาษาคน กับข้อความในเอกสาร มักใช้คนละคำกัน vector search อย่างเดียวจึงพลาดบ่อยจนระบบจริงต้องใช้ hybrid (ผสม keyword search) + reranker อีกชั้น
• เมื่อค้นไม่เจอ — นี่คือจุดตาย: โมเดลจะไม่บอกว่า “ไม่เจอ” แต่จะตอบมั่วอย่างมั่นใจจากชิ้นข้อมูลที่เกี่ยวแค่ผิวเผิน ผู้ใช้แยกไม่ออกเลยว่าคำตอบไหนมาจากเอกสารจริง
• ความสด — เอกสารแก้แล้ว index อัปเดตตามไหม? ใครลบชิ้นเก่าออก?
• สิทธิ์การเข้าถึง — เอกสาร HR ที่พนักงานทั่วไปไม่ควรเห็น ถูกดูดเข้า index รวมไปหรือเปล่า? (เรื่องนี้เกิดขึ้นจริงมาแล้วหลายองค์กร)

และคำถามที่ควรถามก่อนทำ RAG ด้วยซ้ำ: งานนี้ต้องใช้ RAG จริงไหม? บางงานเอกสารน้อยพอจะยัดใส่ context ตรง ๆ บางงานเหมาะกับให้ agent ไปเปิดหาเอกสารเองแบบ agentic search มากกว่า — การเลือกผิดตั้งแต่สถาปัตยกรรมคือค่าเทอมที่แพงที่สุด

ก้อนที่ 3: Agent loop — เมื่อ AI ไม่ได้แค่ตอบ แต่ “ลงมือทำ”

ปี 2026 คำว่า agent อยู่ในสไลด์ขายของทุกบริษัท แต่หัวใจของมันเรียบง่ายกว่าที่คิด: agent คือโมเดลที่รันอยู่ในลูป — โมเดลตัดสินใจเรียกเครื่องมือ (tool) → ระบบรันเครื่องมือจริง → ส่งผลกลับให้โมเดล → โมเดลตัดสินใจก้าวต่อไป → วนจนงานเสร็จ

ความยากไม่ได้อยู่ที่ตัวลูป แต่อยู่ที่คำถามรอบ ๆ มัน:

• Tool ล้มเหลวกลางทาง (API ล่ม, timeout) — โมเดลรู้ไหม? มัน retry เอง หรือเดินหน้าต่อบนข้อมูลผี?
• อะไรคือเงื่อนไข “หยุด”? agent ที่วนไม่จบคือ bill shock ที่มาพร้อมใบแจ้งหนี้ API
• ขั้นไหนต้องให้มนุษย์กดยืนยันก่อน? การให้ agent ลบข้อมูล / โอนเงิน / ส่งอีเมลโดยไม่มี approval gate คือการเซ็นเช็คเปล่า
• ข้อผิดพลาดสะสมยังไง? งาน 20 ขั้น แต่ละขั้นแม่น 95% — ความน่าจะเป็นที่รอดทั้งสายเหลือแค่ราว 36% เลขข้อนี้ข้อเดียวควรเปลี่ยนวิธีออกแบบระบบของคุณทั้งหมด

ก้อนที่ 4: Harness — เกราะรอบโมเดล ที่ตัดสินว่าผลิตภัณฑ์ดีหรือห่วย

นี่คือคำที่คนนอกวงการแทบไม่รู้จัก แต่คนทำระบบ AI จริงคุยกันทุกวัน: harness คือทุกอย่างที่ห่อรอบโมเดล — system prompt, ชุดเครื่องมือที่ให้ใช้, วิธีจัดการ context เมื่อบทสนทนายาวเกิน, กลไก memory, การแตกงานให้ subagent, sandbox กันโมเดลทำอะไรเกินขอบเขต, กติกาว่าเมื่อไหร่ต้องถามมนุษย์

ประเด็นที่อยากให้จำ: โมเดลเดียวกัน harness ต่างกัน ให้ผลต่างกันราวฟ้ากับเหว ผลิตภัณฑ์ AI ที่คุณรู้สึกว่า “ฉลาด” จำนวนมาก ไม่ได้ฉลาดเพราะโมเดลเก่งกว่าคู่แข่ง แต่เพราะทีมนั้นออกแบบ harness เก่งกว่า — และงานออกแบบ harness เป็นงานวิศวกรรม + product design ล้วน ๆ ที่ไม่มีทางเรียนรู้ได้จากการนั่งคุยกับแชตบอต

ก้อนที่ 5: Server-driven UI — จะเอาผลลัพธ์ AI ไปแสดงยังไงให้ไม่พัง

เรื่องที่เงียบที่สุดแต่เจ็บจริง: โมเดลตอบมาเป็นข้อความ แต่แอปของคุณต้องการข้อมูลที่มีโครงสร้าง — การ์ดสินค้า ตาราง ฟอร์ม ปุ่มกด

ทางแก้ที่วงการกำลังไปคือ structured output (บังคับโมเดลตอบตาม JSON schema) ผสมกับแนวคิด server-driven UI — ให้ฝั่ง server (ที่มี AI อยู่เบื้องหลัง) ส่ง “สเปกของ UI” ลงมา แล้ว client แค่ render ตามสเปก ทำให้ AI ประกอบหน้าจอที่ต่างกันตามบริบทของผู้ใช้แต่ละคนได้ โดยไม่ต้องออกแอปใหม่

ฟังดูเท่ — แต่ตามมาด้วยการบ้านชุดใหญ่: ต้อง validate ทุก payload เพราะโมเดลผิด schema ได้เสมอ, ต้องมี fallback UI เมื่อ payload เพี้ยน, ต้องออกแบบ streaming ให้ UI ทยอยขึ้นโดยไม่กระพริบ, และต้องจำกัด component ที่โมเดลสั่ง render ได้ ไม่ใช่ปล่อยให้มันประกอบอะไรก็ได้ตามใจ

ก้อนที่ 6: Evals — ถ้าวัดไม่ได้ ก็แค่ระบบที่ “รู้สึกว่าเวิร์ก”

ซอฟต์แวร์ปกติ: input เดิม → output เดิม เขียนเทสต์ได้ตรง ๆ ระบบ AI: input เดิม → output ไม่เดิม แล้วคุณจะรู้ได้ยังไงว่าการแก้ prompt เมื่อวาน ทำให้ระบบ “ดีขึ้น” ไม่ใช่แค่ดีขึ้นกับตัวอย่างที่คุณลอง แต่แอบพังกับเคสอื่นอีกร้อยเคส?

คำตอบคือ evals — ชุดข้อสอบของระบบ AI: รวบรวมเคสจริง (รวมเคสหิน ๆ) นิยามว่า “ตอบดี” แปลว่าอะไร แล้วรันวัดทุกครั้งที่แก้อะไรก็ตาม ทีมที่จริงจังถือว่า eval set มีค่ากว่า prompt เพราะ prompt เปลี่ยนได้ทุกสัปดาห์ แต่ข้อสอบที่ดีคือทรัพย์สินระยะยาว

ถ้าทีมของคุณกำลังปรับ prompt ด้วยวิธี “ลองสองสามคำถาม เออ ดูดีขึ้นนะ” — ต้องพูดตรง ๆ ว่านั่นไม่ใช่วิศวกรรม นั่นคือการเสี่ยงโชค

ก้อนที่ 7: Security — prompt injection ยังไม่มีทางแก้ขาด

ก้อนสุดท้ายที่คนเพ้อไม่เคยพูดถึงเลย: ระบบ AI ที่อ่านข้อมูลจากภายนอก (อีเมล เว็บ เอกสารที่ผู้ใช้อัปโหลด) เจอความเสี่ยงชนิดใหม่ที่ชื่อ prompt injection — คนร้ายฝังคำสั่งไว้ในเนื้อหาที่ระบบจะไปอ่าน แล้วโมเดลแยกไม่ออกว่าอะไรคือ “ข้อมูล” อะไรคือ “คำสั่ง”

สูตรอันตรายที่วงการ security เรียกว่า lethal trifecta: ระบบที่ (1) เข้าถึงข้อมูลลับ (2) อ่านเนื้อหาจากภายนอกที่ควบคุมไม่ได้ (3) ส่งข้อมูลออกไปข้างนอกได้ — ครบสามข้อเมื่อไหร่ คุณมีช่องข้อมูลรั่วเมื่อนั้น ข่าวช่องโหว่ทำนองนี้มีให้เห็นแทบทุกเดือน (เดือนนี้ก็เพิ่งมีเคส agent ถูกหลอกผ่าน API จองคลาสยิม) และคำตอบที่ถูกไม่ใช่ “เลือกโมเดลที่ฉลาดกว่า” แต่คือการออกแบบสถาปัตยกรรมโดยสมมติว่าโมเดลถูกหลอกได้เสมอ — จำกัดสิทธิ์, แยก sandbox, ให้มนุษย์ยืนยันการกระทำสำคัญ

แบบทดสอบ: คุณ “เข้าใจ” หรือ “มโน”?

ลองตอบคำถามชุดนี้กับตัวเองแบบไม่ต้องอายใคร — ตอบไม่ได้ไม่ใช่เรื่องผิด แต่การไม่รู้ว่าตัวเองตอบไม่ได้ แล้วไปเซ็นสัญญาโปรเจกต์ AI นั่นแหละเรื่องใหญ่:

1. คุณอธิบายได้ไหมว่าทำไมระบบ RAG ถึงตอบผิด ทั้งที่ข้อมูลที่ถูกต้องอยู่ในคลังเอกสาร?
2. ถ้า tool call ล้มเหลวกลาง agent loop ระบบของคุณเกิดอะไรขึ้น — รู้จริง หรือเดา?
3. การแก้ prompt ครั้งล่าสุดของทีม วัดผลด้วยอะไร? มี eval set กี่เคส หรือใช้ความรู้สึก?
4. ค่า API ต่อ request ตอนนี้เท่าไหร่ และถ้าผู้ใช้โต 100 เท่า ตัวเลขนั้นคูณแล้วธุรกิจยังรอดไหม?
5. ถ้ามีคนฝังคำสั่งแฝงในเอกสารที่ระบบคุณจะอ่าน — อะไรจะเกิดขึ้น? เคยลองโจมตีระบบตัวเองหรือยัง?
6. ขั้นตอนไหนของระบบที่มนุษย์ต้องกดยืนยัน และเลือกขั้นนั้นด้วยเหตุผลอะไร?
7. ระหว่าง reasoning model แพง ๆ กับ chat model ถูก ๆ — งานของคุณใช้อะไร เพราะอะไร?
8. เมื่อโมเดลตอบผิดใน production คุณรู้ได้ยังไง (ก่อนที่ลูกค้าจะบอก)?

ถ้าตอบได้เกินครึ่งอย่างมั่นใจ — คุณพร้อมกว่าคนส่วนใหญ่ในตลาดมากแล้ว ถ้าตอบไม่ได้เลย แต่กำลังจะ “เอา AI เข้ามาทั้งองค์กร” — บทความนี้ทำหน้าที่ของมันแล้ว

มุมมอง AI Curator

ผมไม่ได้เขียนบทความนี้เพื่อขู่ให้กลัวจนไม่ทำอะไร — ตรงกันข้าม ผมคิดว่า AI คือคลื่นที่องค์กรไทยไม่ควรพลาดที่สุดในรอบทศวรรษ แต่สิ่งที่เห็นตอนนี้ในไทยคือช่องว่างอันตราย: ฝั่งผู้บริหารถูกขายฝันด้วยเดโมและตัวเลข “ลดต้นทุน 70%” ส่วนฝั่งทีมเทคนิคจำนวนมากยังไม่เคยสร้างระบบ AI จริงสักตัว แล้วทั้งสองฝั่งประชุมกันด้วยความมั่นใจเต็มเปี่ยม — ความมั่นใจที่มาจากการคุยกับแชตบอตคนละสิบนาที

ข้อเสนอของผมเรียบง่าย: เปลี่ยนจากซื้อความฝัน มาเป็นซื้อความรู้ เริ่มจากโปรเจกต์เล็กที่วัดผลได้จริงหนึ่งตัว บังคับให้ทีมสร้าง eval ก่อนสร้างฟีเจอร์ ให้เวลาทีมเรียนรู้ก้อนความรู้ในบทความนี้อย่างจริงจัง — ทั้งหมดนี้เรียนรู้ได้ ไม่ใช่เวทมนตร์ และคนไทยเรียนได้ไม่แพ้ใคร ทีมเล็ก ๆ ในไทยที่เข้าใจ harness, evals และ security จริง จะสร้างของที่ชนะบริษัทใหญ่ที่มีแค่สไลด์กับความเพ้อได้สบาย ๆ

เพราะสุดท้าย คำถามที่แยกคนสองกลุ่มนี้ออกจากกันมีข้อเดียว: คุณรู้ไหมว่าคุณยังไม่รู้อะไร — คนที่ตอบข้อนี้ได้ คือคนที่พาองค์กรข้ามช่วงเพ้อไปสู่ของจริงได้ครับ