AI Agent Glossary 03: Knowledge, Embedding และ RAG ทํางานอย่างไร

ai agent glossary knowledge rag

HR อัปโหลดนโยบายวันลาฉบับใหม่แล้ว แต่ Agent ยังอ้างเงื่อนไขจากฉบับเก่า ทีมหนึ่งบอกให้ “ทํา RAG ใหม่” อีกทีมบอกว่า “embedding ยังไม่เรียนรู้” ทั้งสองประโยคฟังดูเป็นเทคนิค แต่ยังไม่ชี้ว่าข้อมูลผิดตรงไหน

การตอบจากเอกสารมีเส้นทางหลายช่วง: เลือกแหล่งข้อมูล แบ่งเนื้อหา สร้างดัชนี ค้นข้อความ ส่งบริบทให้โมเดล และตรวจว่าคําตอบรองรับด้วยหลักฐานจริงหรือไม่ บทนี้แยกคําในเส้นทางนั้นเพื่อให้หาจุดเสียได้

แผนภาพประกอบ AI Agent Glossary 03: Knowledge, Embedding และ RAG ทํางานอย่างไร
แผนภาพสรุปจาก AI Agent Glossary ตอนที่ 3

Knowledge base ไม่ใช่ vector database

Knowledge base คือชุดข้อมูลที่องค์กรอนุมัติให้ระบบใช้ตอบคําถาม อาจเป็นไฟล์ PDF หน้าเว็บ ฐานข้อมูล หรือระบบจัดการเอกสาร ไม่จําเป็นต้องเก็บเป็น vector

Corpus คือเนื้อหาต้นทางทั้งหมดที่ retrieval ใช้ค้นหา ใน HR Agent corpus อาจประกอบด้วยนโยบายวันลา คู่มือสวัสดิการ และ FAQ ที่มีเจ้าของและเวอร์ชันชัดเจน

Vector store หรือ vector index คือโครงสร้างที่เก็บและค้น embedding มันเป็นชั้น index ไม่ใช่ตัวเอกสารต้นฉบับทั้งหมด และไม่ใช่ knowledge governance การมี vector database จึงไม่ได้ตอบว่าเอกสารใดได้รับอนุมัติหรือหมดอายุแล้ว

ถ้า Agent อ้างนโยบายเก่า ปัญหาอาจเป็นเอกสารเก่ายังอยู่ใน corpus, metadata ไม่มีสถานะ superseded, ingestion ไม่รัน หรือ retrieval เลือกผิด ไม่ควรรีบโทษ embedding ก่อนตรวจเส้นทางเหล่านี้

Chunking กําหนดว่าหลักฐานชิ้นหนึ่งมีขอบเขตแค่ไหน

Chunking คือการแบ่งเอกสารเป็นส่วนเล็กเพื่อทําดัชนีและค้นกลับมาใช้ ขนาด chunk และการ overlap มีผลต่อคุณภาพ retrieval

ถ้า chunk สั้นเกินไป ข้อความ “ใช้สิทธิ์ได้ไม่เกิน 10 วัน” อาจหลุดจากหัวข้อที่บอกว่านโยบายนี้ใช้เฉพาะพนักงานประจํา ถ้ายาวเกินไป ระบบอาจส่งเนื้อหาไม่เกี่ยวข้องเข้า context จนหลักฐานสําคัญถูกกลบ

การแบ่งตามจํานวนตัวอักษรอย่างเดียวมักทําลายโครงสร้างเอกสาร สําหรับนโยบาย HR ควรเก็บหัวข้อ ลําดับข้อ ประเทศ ประเภทพนักงาน วันที่มีผล และรหัสเวอร์ชันเป็น metadata ร่วมกับแต่ละ chunk

Embedding เป็นตัวแทนเพื่อค้น ไม่ใช่ความรู้ต้นฉบับ

Embedding คือเวกเตอร์ตัวเลขที่แทนคุณลักษณะของข้อมูล ทําให้ระบบวัดความใกล้เคียงเชิงความหมายได้ ข้อความ “ลาหยุดดูแลคนในครอบครัว” อาจอยู่ใกล้ “family care leave” แม้ไม่ได้ใช้คําตรงกัน

Embedding ไม่ได้เก็บข้อความต้นฉบับในรูปที่คนใช้อ้างอิงได้ และไม่ได้ “เรียนรู้เอกสาร” แบบเปลี่ยนพารามิเตอร์ LLM การเพิ่มไฟล์มักหมายถึงระบบสร้าง embedding ใหม่และใส่ index ไม่ใช่ฝึกโมเดลใหม่

Semantic search ใช้ความใกล้เคียงเชิงความหมาย ส่วน keyword search ใช้คําหรือรูปแบบที่ตรงกัน ทั้งสองแบบมีจุดแข็งต่างกัน ระบบจริงอาจใช้แบบผสม เพราะรหัสเอกสารหรือชื่อสิทธิ์เฉพาะมักเหมาะกับ keyword ขณะที่คําถามภาษาธรรมชาติเหมาะกับ semantic search

Retrieval เลือกหลักฐานก่อน generation

Retrieval คือขั้นตอนเลือกข้อมูลที่เกี่ยวข้องจากแหล่งภายนอก ก่อนส่งให้โมเดลสร้างคําตอบ

Reranking คือการจัดลําดับผลค้นใหม่ด้วยเกณฑ์หรือโมเดลที่ละเอียดขึ้น เช่น ให้เอกสารประเทศตรงกับผู้ใช้และเวอร์ชันปัจจุบันมาก่อนข้อความที่คล้ายแต่หมดอายุแล้ว

คุณภาพ retrieval มีสองมุมที่ต้องแยก:

  • Retrieval recall: ระบบค้นพบหลักฐานที่จําเป็นครบหรือไม่
  • Retrieval precision: สิ่งที่ค้นมานั้นเกี่ยวข้องจริงมากแค่ไหน

ถ้าหลักฐานสําคัญไม่ถูกค้นมาเลย โมเดลไม่มีทางอ้างมันได้ นี่คือ failure ของ recall ถ้าค้นมาสิบชิ้นแต่มีเพียงชิ้นเดียวเกี่ยวข้อง เรามีปัญหา precision และ context อาจเต็มไปด้วยสิ่งรบกวน

RAG ต่อ retrieval เข้ากับ generation

Retrieval-Augmented Generation หรือ RAG คือวิธีสร้าง output โดยผสานโมเดลกับข้อมูลที่ค้นจากหน่วยความจําภายนอก งานวิจัยต้นฉบับเสนอการใช้โมเดลร่วมกับ non-parametric memory เพื่อช่วยงานที่ต้องใช้ความรู้และที่มาของข้อมูล

ในระบบทั่วไป pipeline อาจเป็น:

คําถาม → สร้าง query → ค้น chunks → กรองสิทธิ์/เวอร์ชัน
→ rerank → ใส่ context → LLM สร้างคําตอบ → ตรวจ citation

RAG ไม่ใช่ Agent เพราะ pipeline อาจถูก code กําหนดทั้งหมดโดยโมเดลไม่เลือก action ใดเอง RAG ก็ไม่ใช่ fine-tuning เพราะมันเพิ่มข้อมูลใน request แทนการปรับพารามิเตอร์โมเดล

และ RAG ไม่ได้ทําให้คําตอบถูกเสมอ ระบบอาจค้นผิด โมเดลอาจตีความผิด หรือ citation อาจชี้เอกสารจริงแต่ไม่รองรับ claim นั้น

Grounding, citation และ provenance ตอบคนละคําถาม

Grounding คือการยึด output กับข้อมูลหรือสภาพแวดล้อมที่ตรวจสอบได้ เช่น บังคับให้คําตอบอิงเฉพาะข้อความที่ retrieval คืนมา

Citation คือตัวชี้ว่า claim อ้างแหล่งใด เช่น ชื่อเอกสาร หน้า หรือ URL การมี citation เพียงอย่างเดียวไม่พิสูจน์ว่าเนื้อหาในแหล่งนั้นรองรับ claim จริง

Provenance คือเส้นทางที่มาของข้อมูลและผลลัพธ์ เช่น เอกสารเวอร์ชันใด ถูก ingest เมื่อไร chunk ใดถูกค้นด้วย query ใด และ model run ใดสร้างคําตอบ

เมื่อผู้ตรวจถาม “คําตอบนี้เชื่อได้เพราะอะไร” citation ช่วยเปิดเอกสาร ส่วน provenance ช่วยย้อนดูว่าระบบไปถึงเอกสารนั้นอย่างไร ทั้งสองอย่างจําเป็นต่อการวิเคราะห์เหตุผิดพลาด แต่ทําหน้าที่ไม่เหมือนกัน

แกะเหตุการณ์นโยบายเก่าทีละชั้น

สมมติคําตอบอ้าง leave-policy-2025.pdf ทั้งที่ leave-policy-2026.pdf มีผลแล้ว วิธีตรวจที่มีหลักฐานคือ:

  1. ตรวจ corpus ว่ามีไฟล์ 2026 และสถานะเอกสารหรือไม่
  2. ตรวจ ingestion ว่าไฟล์ถูกแบ่ง chunk และสร้าง index สําเร็จหรือไม่
  3. ตรวจ query และ filters ว่าระบุประเทศ ประเภทพนักงาน และสถานะ current หรือไม่
  4. ตรวจ retrieval results ก่อน rerank และหลัง rerank
  5. ตรวจ context ที่ส่งให้ LLM จริง
  6. ตรวจว่า claim ในคําตอบตรงกับข้อความที่ citation ชี้หรือไม่

ถ้าไฟล์ใหม่ไม่เข้าระบบ นั่นคือ ingestion failure ถ้าเข้าระบบแต่ไม่ถูกค้น นั่นคือ retrieval failure ถ้าถูกส่งเข้า context แล้วแต่คําตอบยังใช้ฉบับเก่า นั่นคือ generation หรือ instruction failure คําว่า “RAG พัง” กว้างเกินกว่าจะบอกวิธีแก้

ขอบเขตที่ RAG ไม่ได้แก้ให้เอง

เอกสารที่ค้นคืนอาจมีข้อความโจมตี เช่น คําสั่งแฝงให้โมเดลเปิดเผยข้อมูลหรือเรียก tool การแนบเอกสารผ่าน RAG จึงเปิดช่อง indirect prompt injection ได้

RAG ไม่แทน authorization ระบบต้องกรองข้อมูลตามสิทธิ์ก่อนส่งเข้าโมเดล และ tool ต้องตรวจสิทธิ์ตอนใช้งานจริง ไม่พึ่ง prompt ว่า “อย่าเปิดเผยข้อมูลลับ”

RAG ยังไม่แทนวงจรดูแลเอกสาร ต้องมีเจ้าของ วันที่มีผล วิธีถอดเอกสารเก่า และการทดสอบเมื่อ corpus เปลี่ยน

แบบฝึกหัด: สร้าง retrieval evidence row

เลือกคําถามจริงหนึ่งข้อ แล้วบันทึก:

  • expected source และข้อความที่ควรถูกค้น
  • query และ filters ที่ระบบใช้
  • top retrieval results พร้อม score และ metadata
  • chunks ที่ถูกส่งเข้าโมเดลจริง
  • claims ในคําตอบและ citation ที่รองรับแต่ละ claim

งานผ่านเมื่อคนอีกคนบอกได้ว่าความผิดพลาดเกิดก่อน retrieval, ระหว่าง retrieval หรือหลัง retrieval โดยไม่ต้องเดาจากคําตอบสุดท้ายเพียงอย่างเดียว

ตอนถัดไปจะออกจากฐานความรู้ไปยังโลกของ actions: workflow, routing, tool calling, API และ MCP เชื่อมกันอย่างไร

แหล่งอ้างอิง

ตรวจสอบแหล่งอ้างอิงล่าสุด: 17 สิงหาคม 2026