Journal Placing the RAG Landscape
ภูมิทัศน์เครื่องมือ RAG
ทุกสัปดาห์มีเครื่องมือ RAG ใหม่ ทำไมถึงมีเป็นร้อย เพราะแต่ละตัวแก้คนละปัญหา · บทนี้ไล่ดูทีละตัวว่าปัญหาคืออะไรแก้ด้วยอะไร — โมเดลไม่รู้จักเอกสารเรา จึงมี RAG · ค้นด้วยความหมายแต่พลาดรหัสและตัวเลข จึงมี hybrid search · ผลค้นลำดับมั่ว จึงมี reranker กับ ColBERT · เอกสารจริงเป็น PDF ตารางสแกน จึงมี chunkr docling · ตัดท่อนแล้วมองภาพรวมไม่ออก จึงมี RAPTOR · เชื่อมหลายจุดไม่ได้ จึงมี GraphRAG กับ Hyper-Extract · คำถามคนละชนิด จึงมี semantic router กับ Self-RAG · ปิดท้ายรวมทุกตัวบนแผนที่สองแกนพร้อมตารางสรุป · บทที่ 7 ของ LLM systems series
ทุกสัปดาห์มีเครื่องมือใหม่ — GraphRAG, chunkr, ColBERT, Hyper-Extract ทุกตัวทำให้ AI ตอบจากเอกสารของเราได้ ที่มีเยอะเพราะแต่ละตัวแก้คนละปัญหา บทนี้ไล่ดูทีละตัว ว่าปัญหาคืออะไร แล้วแก้ด้วยอะไร
(เทคนิคให้ AI ตอบจากเอกสารจริง ไม่ใช่จากความจำในตัวโมเดล เรียกว่า RAG — บทที่ 5 กับ บทที่ 6 เล่าวิธีการละเอียดแล้ว)
โมเดลไม่รู้จักเอกสารของเรา
LLM รู้แค่สิ่งที่เห็นตอนเทรน ถามเรื่องคู่มือเครื่องจักรในโรงงานเรา มันไม่เคยเห็น ก็ตอบมั่ว
RAG แก้ด้วยการค้นเอกสารที่เกี่ยวข้องมาก่อน แล้วให้โมเดลตอบจากเอกสารนั้น คำว่า RAG ย่อจาก Retrieval-Augmented Generation แปลว่า “สร้างคำตอบที่เสริมด้วยการค้น” มาจากเปเปอร์ปี 2020 ของ Patrick Lewis ทีม Meta AI (arxiv 2005.11401) และกลายเป็นชื่อเรียกของทั้งวงการ บทนี้เลยใช้คำนี้
LangChain ทำให้สูตรนี้ลงมือทำได้จริง วางขั้นตอนมาตรฐานที่ทุกคนใช้ร่วมกัน — โหลดเอกสาร ตัดเป็นท่อน แปลงเป็นเวกเตอร์ เก็บ ค้น ตอบ (LlamaIndex เป็นคู่หูสาย RAG) สูตรนี้คือจุดตั้งต้น ปัญหาที่เหลือคือจุดที่สูตรนี้ยังไม่พอ
ค้นด้วยความหมาย แต่พลาดรหัสและตัวเลข
สูตรพื้นฐานค้นด้วยความใกล้ของความหมาย ถาม “servo รุ่น MX-230 ตั้ง torque เท่าไร” รหัส MX-230 ถูกเกลี่ยจนจาง ระบบหยิบท่อนเรื่อง torque ทั่ว ๆ มา ไม่ใช่ของรุ่นนั้น
hybrid search ค้นสองแบบคู่กัน — ความหมาย (เวกเตอร์) กับคำตรงตัว (BM25 ที่จับ “MX-230” เป๊ะ) แล้วรวมผล คำเฉพาะกับตัวเลขไม่หลุด
ค้นเจอ แต่ท่อนที่ใช่ไม่ขึ้นบนสุด
ค้นมาสามสิบท่อนที่เกี่ยวข้อง แต่ท่อนที่ตอบตรงคำถามอยู่อันดับสิบ การวัดความใกล้แบบหยาบไม่ละเอียดพอจะจัดอันดับให้แม่น
reranker แบบ cross-encoder (bge-reranker) อ่านคำถามคู่กับแต่ละท่อนแล้วให้คะแนนใหม่ ส่วน ColBERT เก็บเวกเตอร์ถึงระดับคำ เทียบคำต่อคำ
เอกสารจริงไม่ใช่ข้อความสะอาด
เอกสารจริงเป็น PDF ที่มีตาราง มีสแกน มี drawing เป็นรูป ตารางถ้าดึงเป็นข้อความมั่ว ๆ ตัวเลขหลุดออกจากแถว รูป drawing ไม่มีตัวอักษรให้ค้น
chunkr แกะ PDF ตาราง สแกน เป็นชิ้นที่ระบุชนิดได้พร้อมพิกัด docling จาก IBM กับ unstructured ทำคล้ายกัน เปลี่ยนเอกสารเป็นข้อความสะอาดตอนนำเข้า
ตัดเป็นท่อน ทำให้มองภาพรวมไม่ออก
ตัดเอกสารเป็นท่อนเล็กดีกับคำถามเจาะจุด แต่ถาม “คู่มือเล่มนี้พูดเรื่องอะไรบ้าง” ไม่มีท่อนไหนตอบได้ เพราะคำตอบอยู่ที่ภาพรวมของทั้งเล่ม
RAPTOR สรุปเอกสารเป็นต้นไม้หลายชั้น จากท่อนย่อยไล่ขึ้นไปเป็นบทสรุป ถามเจาะจุดหรือถามภาพรวมก็ได้
คำถามที่ต้องเชื่อมหลายจุด
ถาม “ชิ้นส่วนที่ใช้น้ำมันเบอร์เดียวกับปั๊มตัวนี้ มีอะไรบ้าง” ต้องกระโดดจากปั๊ม ไปเบอร์น้ำมัน ไปชิ้นส่วนอื่นที่ใช้เบอร์เดียวกัน เวกเตอร์ทำไม่ได้ เพราะหาท่อนที่ใกล้คำถามทีละท่อน ไม่เห็นเส้นเชื่อมระหว่างจุด
GraphRAG จาก Microsoft กับ LightRAG สกัดเอกสารเป็นกราฟความสัมพันธ์ แล้วเดินตามเส้น ส่วน Hyper-Extract ไปถึงไฮเปอร์กราฟ ที่เส้นเดียวโยงได้หลายฝ่ายพร้อมกัน
คำถามคนละชนิด ต้องค้นคนละแบบ
“มีคู่มือกี่เล่ม” ตอบจากรายการเอกสาร “torque เท่าไร” ตอบจากเนื้อ “รุ่น A กับ B ต่างกันยังไง” ต้องเทียบ ระบบต้องรู้ก่อนว่าคำถามเป็นแบบไหน
semantic router วัดว่าคำถามใกล้ตัวอย่างแบบไหนที่สุด แล้วส่งไปทางนั้น ส่วน Self-RAG ให้โมเดลตัดสินใจเองระหว่างตอบ ว่าต้องค้นเพิ่มไหม
ทั้งหมดบนภาพเดียว
เครื่องมือแต่ละกลุ่มแก้คนละปัญหา วางบนสองแกน — แกนนอนคือรูปแบบที่เก็บความรู้ (ข้อความเวกเตอร์ ↔ กราฟโครงสร้าง) แกนตั้งคืองานหนักอยู่จังหวะไหน (ตอนนำเข้า ↔ ตอนถาม) — ได้ภูมิทัศน์ทั้งหมด
สีของจุดบอกว่าเอามาใช้แล้วต้องทำอะไร — เสียบโมเดลที่เทรนมา เขียนโค้ดโครงสร้างและวิธีค้น หรือร้อย workflow กรอบม่วงคือ LangChain กับ LlamaIndex ที่ประกอบทุกชิ้นเข้าด้วยกัน ทุกตัวที่เล่ามาคือชิ้นที่เสียบแทนชิ้นมาตรฐานในกรอบนี้
| เครื่องมือ | ปัญหาที่แก้ | ธรรมชาติของงาน | ทำอะไร |
|---|---|---|---|
| vector RAG | จุดตั้งต้น | เขียนโค้ด | RAG ตรงสูตร — โหลด ตัดท่อน เวกเตอร์ ค้นความใกล้ ตอบ |
| chunkr | เอกสารไม่ใช่ข้อความสะอาด | เขียนโค้ด | แกะ PDF ตาราง สแกน เป็นชิ้นระบุชนิด + พิกัด |
| docling | เอกสารไม่ใช่ข้อความสะอาด | เขียนโค้ด | แปลงเอกสารหลายฟอร์แมตเป็นข้อความสะอาด (IBM) |
| unstructured | เอกสารไม่ใช่ข้อความสะอาด | เขียนโค้ด | ดึงข้อความจากไฟล์ยุ่ง ๆ ให้พร้อมใช้ |
| RAPTOR | ตัดท่อนแล้วมองภาพรวมไม่ออก | ร้อย workflow | สรุปเอกสารเป็นต้นไม้หลายชั้น |
| GraphRAG | คำถามเชื่อมหลายจุด | ร้อย workflow | สกัดเอกสารเป็นกราฟความสัมพันธ์ (Microsoft) |
| LightRAG | คำถามเชื่อมหลายจุด | ร้อย workflow | กราฟ RAG ที่เบาและเร็วกว่า |
| Hyper-Extract | ความสัมพันธ์หลายฝ่าย | ร้อย workflow | สกัดเป็นไฮเปอร์กราฟ/สคีมา |
| hybrid search | ค้นพลาดรหัสและตัวเลข | เขียนโค้ด | ผสมค้นความหมายกับค้นคำตรงตัว |
| ColBERT | ผลค้นลำดับมั่ว | เสียบโมเดล | เทียบคำถามกับเอกสารถึงระดับคำ |
| bge-reranker | ผลค้นลำดับมั่ว | เสียบโมเดล | จัดอันดับผลค้นใหม่ด้วย cross-encoder |
| semantic router | คำถามคนละชนิด | ร้อย workflow | ตัดสินใจว่าคำถามควรไปทางไหน |
| Self-RAG | คำถามคนละชนิด | ร้อย workflow | ให้โมเดลวนคิดเองว่าจะค้นเพิ่มไหม |
| text-to-SQL · KG | ถามข้อมูลที่มีโครงสร้าง | ร้อย workflow | แปลคำถามเป็นคำสั่ง query ตอนถาม |
| LangChain · LlamaIndex | ต่อทุกชิ้นเข้าด้วยกัน | ร้อย workflow | เฟรมเวิร์กที่ประกอบทุกชิ้นเป็นระบบ |
วาง repo ตัวต่อไป
เจอเครื่องมือใหม่ ถามว่ามันแก้ปัญหาข้อไหน — ค้นพลาดคำเฉพาะ ลำดับมั่ว อ่านเอกสารไม่ออก มองภาพรวมไม่ได้ เชื่อมหลายจุดไม่ได้ หรือเลือกทางไม่เป็น พอรู้ว่ามันตอบปัญหาไหน ก็รู้ว่ามันยืนตรงไหนบนแผนที่ ทับกับของที่เรามีไหม และเติมส่วนที่ยังขาดได้หรือเปล่า
ขอบเขต — บทที่ 7 ของ LLM systems series · ต่อจาก บทที่ 5 เรื่องค้นกับเลือกทาง และ บทที่ 6 เรื่องอ่านกับจัดเก็บ · ตำแหน่งบนแผนที่เป็นการประเมินคร่าว ๆ เพื่อให้เห็นภูมิทัศน์ ไม่ใช่พิกัดตายตัว