เบื้องหลังคำตอบของ AI คือตัวเลข

เวลาเราถาม AI แล้วมันตอบกลับเป็นภาษาคนได้คล่อง ๆ มันดูเหมือนเข้าใจเรา แต่ความจริงคือ AI ไม่ได้เข้าใจภาษาแบบที่เราเข้าใจ สำหรับมันแล้ว ทุกอย่างเป็นแค่ตัวเลข

คำถามที่น่าสนใจคือ แล้ว AI ที่ทำงานด้วยตัวเลขล้วน ๆ ตอบคำถามเป็นภาษาคนได้ยังไง

บทนี้จะพาทำความเข้าใจชิ้นส่วนพื้นฐานที่อยู่ใต้ระบบพวกนี้ ทีละชิ้น หัวใจของมันคือคณิตศาสตร์ แต่เป็นคณิตศาสตร์ที่เห็นภาพได้ไม่ยาก — แค่เรื่องของจุดบนแผนที่ กับระยะห่างระหว่างจุด เราจะค่อย ๆ เข้าใจหลักคิดนั้นไปด้วยกัน พอเข้าใจสี่ชิ้นนี้ — LLM, embedding, index, และ reranker — บทอื่น ๆ ในซีรีส์ก็จะอ่านง่ายขึ้นมาก

ขอบเขต — ปฐมบทของ LLM systems series · เป็นพื้นฐานที่บทอื่นถือว่าผู้อ่านรู้แล้ว · ถ้าอยากเห็นชิ้นส่วนเหล่านี้ประกอบกันเป็นระบบจริง อ่านต่อที่ บทที่ 5 (ฝั่งอ่าน) และ บทที่ 6 (ฝั่งเขียน)

LLM คือตัวทำนายคำถัดไป

เริ่มจากชิ้นที่คนรู้จักมากที่สุดก่อน นั่นคือ LLM

หลายคนเข้าใจว่า LLM เป็นเหมือนฐานข้อมูลที่เก็บความรู้ไว้มหาศาล แต่จริง ๆ แล้วมันทำสิ่งเดียว คือ ทำนายคำถัดไป เราป้อนข้อความเข้าไป มันดูว่าคำไหนน่าจะตามมามากที่สุด แล้วเติมคำนั้น จากนั้นก็ทำซ้ำ ทีละคำ ต่อกันไปเรื่อย ๆ จนกลายเป็นประโยคและย่อหน้า

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

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

AI ทำงานด้วยตัวเลข ไม่ใช่ตัวอักษร

ทีนี้มาถึงปัญหาที่ว่า ถ้าเราอยากค้นเอกสาร “ด้วยความหมาย” จะทำได้ยังไง ในเมื่อ AI ไม่เข้าใจคำ

คำตอบคือเราต้องแปลงข้อความให้เป็นตัวเลขก่อน และเครื่องมือที่ทำหน้าที่นี้เรียกว่า embedding

วิธีคิดที่ง่ายที่สุดคือลองนึกถึงแผนที่ embedding จะเอาข้อความแต่ละชิ้นไปปักหมุดลงบนแผนที่ความหมายขนาดใหญ่ ข้อความที่ความหมายใกล้กัน หมุดจะอยู่ใกล้กัน ส่วนข้อความที่ความหมายต่างกัน หมุดจะอยู่ห่างกัน ยกตัวอย่างเช่น “ลูกสุนัข” กับ “หมาน้อย” จะถูกปักไว้ใกล้กัน ทั้งที่ไม่มีคำไหนซ้ำกันเลย

แผนที่จริงไม่ได้มีแค่สองแกนเหมือนแผนที่กระดาษ แต่มีเป็นร้อยเป็นพันแกน เพื่อเก็บแง่มุมของความหมายได้ละเอียด แต่หลักการยังเหมือนเดิม คือใกล้แปลว่าเหมือน

ลองดูของจริง เวลา embedding แปลงข้อความ มันได้ออกมาเป็นแถวตัวเลขยาว ๆ (ของจริงมีพันกว่าตัวเลข ในที่นี้ขอย่อเหลือ 3 ตัวเพื่อให้เห็นภาพ):

"ลูกสุนัข"       →  [ 0.91,  0.82,  0.10 ]
"หมาน้อย"        →  [ 0.88,  0.86,  0.12 ]   ← ตัวเลขเกาะกลุ่มกับ "ลูกสุนัข"
"ใบกำกับภาษี"    →  [ 0.09,  0.21,  0.94 ]   ← ตัวเลขไปคนละทางเลย

สองคำแรกความหมายใกล้กัน ตัวเลขเลยเกาะกลุ่มกัน ส่วนคำที่สามคนละเรื่อง ตัวเลขก็ไปอยู่คนละมุม จุดสำคัญคือ AI ไม่ต้องรู้ความหมายของคำเลย มันแค่วัดว่าแถวตัวเลขไหนอยู่ใกล้กัน ก็พอจะบอกได้แล้วว่าข้อความไหนเกี่ยวกัน

พอข้อความทุกชิ้นมีพิกัดแล้ว การ “ค้นด้วยความหมาย” ก็กลายเป็นเรื่องง่าย เราแค่แปลงคำถามให้เป็นพิกัดด้วยวิธีเดียวกัน แล้วมองหาหมุดที่อยู่ใกล้ที่สุด นี่คือหัวใจของสิ่งที่เรียกว่า vector search และมันต่างจากการค้นคำตรงตัว ที่ต้องสะกดให้ตรงเป๊ะถึงจะเจอ

แล้วตัวเลขพวกนี้ไปอยู่ในฐานข้อมูลยังไง คำตอบคือ แต่ละท่อนข้อความ (chunk) จะถูกเก็บเป็นหนึ่งแถว พร้อมกับเวกเตอร์ของมัน และที่มาของมัน (เอกสารไหน หน้าไหน) หน้าตาประมาณนี้:

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

index — แผนที่ที่หาของใกล้ได้เร็ว

แต่ก็มีปัญหาใหม่ตามมา ถ้าคลังมีหมุดเป็นล้านจุด การจะหาจุดที่ใกล้คำถามที่สุด เราต้องวัดระยะทีละจุดเป็นล้านครั้ง ซึ่งช้าเกินไป

ทางแก้คือสร้าง index ขึ้นมาทับ มันคือโครงสร้างที่ช่วยนำทาง ให้กระโดดไปยังบริเวณที่น่าจะมีจุดใกล้ ๆ ได้เลย โดยไม่ต้องไล่วัดทุกจุด (เทคนิคที่นิยมตัวหนึ่งชื่อ HNSW)

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

reranker — กรรมการที่อ่านเป็นคู่

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

reranker เกิดมาเพื่อแก้ตรงนี้ มันคือโมเดลอีกชนิด (เรียกว่า cross-encoder) ที่อ่านคำถามกับเอกสารที่เป็นไปได้ พร้อมกันเป็นคู่ แล้วให้คะแนนว่าทั้งคู่เข้ากันจริงแค่ไหน เพราะมันเห็นสองฝั่งพร้อมกัน มันจึงตัดสินได้แม่นกว่า embedding มาก

ข้อแลกเปลี่ยนคือมันช้าและแพงกว่า เราเลยไม่เอามันมาไล่ทั้งคลัง แต่ใช้มันเป็นด่านที่สองแทน คือให้ embedding คัดผู้เข้ารอบมาก่อนสัก ~30 ชิ้น แล้วค่อยให้ reranker จัดอันดับเฉพาะกลุ่มนั้น (บทที่ 6 เล่าการจับคู่สองด่านนี้แบบละเอียด)

ตัวเลข ~30 ไม่ใช่ลิมิตของโมเดลตัวไหน แต่เป็นปุ่มที่เราปรับเอง ถ้าส่งให้ reranker เยอะ โอกาสที่ของถูกติดมาก็สูงขึ้น แต่ก็ช้าและแพงขึ้น เพราะ reranker คิดทีละคู่ ส่ง 30 คู่คือรัน 30 ครั้ง ส่ง 300 คู่ก็ 300 ครั้ง ค่าที่พอดีจึงขึ้นกับว่า embedding คัดมาดีแค่ไหน reranker เร็วแค่ไหน และเรายอมรอได้นานแค่ไหน คนละโมเดลหรือคนละงานก็ตั้งไม่เท่ากัน

ทำไมสุดท้ายต้องมี RAG

ทีนี้ลองเอาทุกชิ้นมาต่อกัน แล้วจะเห็นว่าทำไมระบบ AI ที่ตอบจากเอกสารถึงต้องประกอบแบบนี้

ปัญหาตั้งต้นคือ LLM เก่งเรื่องภาษา แต่ไม่รู้ข้อเท็จจริงเฉพาะของเรา และที่อันตรายกว่านั้นคือ ถ้ามันไม่รู้ มันมักจะ แต่งเรื่องให้ฟังดูน่าเชื่อ แทนที่จะบอกว่าไม่รู้ อาการนี้เรียกว่าการหลอน (hallucinate)

กุญแจสำคัญคือ LLM รู้แค่สิ่งที่อยู่ตรงหน้ามันในตอนนั้น พื้นที่ตรงหน้านี้เรียกว่า context และมันมีขนาดจำกัด เราจะยัดทั้งคลังเป็นพันเล่มลงไปทีเดียวไม่ได้

ดังนั้นวิธีที่ใช้ได้จริงคือ ก่อนจะให้ LLM ตอบ เราต้องไปหาเฉพาะข้อเท็จจริงที่เกี่ยวกับคำถามมาวางใน context ให้มันก่อน การ “ไปหา” นั้นคืองานของ embedding, index และ reranker ส่วนการ “เรียบเรียงคำตอบ” คืองานของ LLM พอเอาสองส่วนนี้มารวมกัน นี่แหละคือสิ่งที่เรียกว่า RAG

ของจริงเขาใช้โมเดลอะไร

พอเห็นหน้าที่ของแต่ละชิ้นแล้ว ลองจับคู่กับชื่อจริงที่ได้ยินบ่อย (ชื่อพวกนี้เปลี่ยนเร็วตามยุค ดูเป็นตัวอย่างพอ):

• embedding — เช่น BGE-M3 หรือ Qwen3-Embedding ตัวที่เข้าใจภาษาไทยดีสำคัญมาก เพราะมันคือคนตั้งเพดาน recall ให้ทั้งระบบ
• reranker — เช่น bge-reranker-v2-m3 หรือ jina-reranker-v3 (ตัวหลังเด่นเรื่องเร็ว) ทำหน้าที่ด่านสองที่จัดอันดับให้แม่นขึ้น
• LLM — เช่น Typhoon ที่เก่งภาษาไทย หรือ Gemma และ Qwen เป็นคนเรียบเรียงคำตอบสุดท้าย

ส่วนจะเลือกตัวไหนจริง ๆ ขึ้นกับภาษา ต้นทุน ความเร็ว และความแม่นที่ต้องการ ซึ่งเป็นหัวข้อใหญ่พอจะแยกเล่าอีกบทหนึ่ง

ร้อยเข้าด้วยกัน

ถ้ามองทั้งระบบเป็นภาพเดียว มันคือสายพานสั้น ๆ คำถามเข้ามา แล้ว embedding แปลงเป็นพิกัด จากนั้น index หาเพื่อนบ้านที่ใกล้ได้เร็ว ต่อด้วย reranker คัดให้เหลือของที่แม่นจริง แล้วสุดท้าย LLM เอาของเหล่านั้นมาเรียบเรียงเป็นคำตอบ

จุดที่อยากให้จำคือ แต่ละชิ้นทำสิ่งที่ตัวเองเก่งอย่างเดียว ไม่มีชิ้นไหนทำได้ทุกอย่าง embedding เก่งเรื่องความหมายแต่หยาบ reranker แม่นแต่ช้า ส่วน LLM เรียบเรียงเก่งแต่ไม่รู้ข้อเท็จจริงของเรา พอเอามาวางต่อกันให้ถูกตำแหน่ง จุดอ่อนของชิ้นหนึ่งก็ถูกกลบด้วยจุดแข็งของอีกชิ้น

พอเห็นภาพนี้แล้ว บทที่เหลือในซีรีส์ — ตั้งแต่การเลือกโมเดล วางสถาปัตยกรรม ไปจนถึงฝั่งอ่านและฝั่งเขียนของ RAG — ก็จะอ่านได้ลื่นขึ้น เพราะทั้งหมดคือการเอาสี่ชิ้นนี้ไปประกอบกันในบริบทที่ใหญ่ขึ้นเรื่อย ๆ

ขอบเขต — ปฐมบทของ LLM systems series · อธิบายชิ้นส่วนพื้นฐานสี่ชิ้น: LLM ทำนายคำถัดไป · embedding แปลงข้อความเป็นพิกัดความหมาย · index หาเพื่อนบ้านได้เร็ว · reranker อ่านเป็นคู่เพื่อความแม่น · และเหตุผลว่าทำไม LLM ถึงต้องพึ่ง RAG · อ่านต่อ: บทที่ 5 ฝั่งอ่าน · บทที่ 6 ฝั่งเขียน