เข้าใจ Plain RAG, GraphRAG และ Hybrid ก่อนตัดสินใจ
RAG หรือ Retrieval-Augmented Generation คือการแยกขั้นตอนค้นหาข้อมูลจากฐานข้อมูลส่วนตัวออกจากขั้นตอนให้ LLM สร้างคำตอบ เพื่อให้ผลลัพธ์อิงกับข้อความจริงแทนการเดาจากความจำของโมเดล โดยระบบจะค้นย่อหน้าที่เกี่ยวข้องจากแหล่งข้อมูลที่ปลอดภัยแล้วส่งต่อให้โมเดลพร้อมคำสั่งให้ตอบโดยใช้ข้อมูลที่ตรวจสอบแล้วเท่านั้น แนวคิดนี้ทำให้ RAG กลายเป็นโครงสร้างพื้นฐานสำคัญในสภาพแวดล้อมที่มีกฎระเบียบสูง เช่น งานธนาคารและคอมพลายแอนซ์ ซึ่งคำตอบผิดอาจนำไปสู่ปัญหาการตรวจสอบย้อนหลังได้ แต่สถาปัตยกรรม RAG ไม่ได้มีแบบเดียว คุณต้องเลือกให้เหมาะกับรูปแบบคำถามและงบประมาณการดูแลระบบของทีม
| มุมเปรียบเทียบ | Plain RAG | GraphRAG |
|---|---|---|
| จุดเด่นหลัก | ค้นหาย่อหน้าคำตอบตรง ๆ จาก chunk หรือ vector ใกล้เคียง | ดึงความสัมพันธ์ซ่อนเร้นและโครงสร้างทั่วทั้ง corpurs |
| จังหวะที่ใช้แล้วคุ้ม | คำถามส่วนใหญ่เป็นการ lookup จุดเดียวหรือใช้ metadata/keyword ได้ดี | คำถามเน้น entity relationship, multi-hop และการสังเคราะห์ระดับ corpus-wide |
ทำความรู้จัก semantic search และต้นทุนที่ซ่อนอยู่
การลด RAG optimization cost ที่ดีเริ่มจากการออกแบบ retrieval ให้ฉลาดกว่าเดิม ซึ่งหัวใจคือ semantic search embeddings บน vector database แทนที่จะค้นด้วยคำตรงตัวเหมือนระบบเดิมที่พลาดเอกสารที่ใช้คำว่า “car” เมื่อค้นด้วย “automobile” semantic search จะเปลี่ยนข้อความเป็นเวกเตอร์ตัวเลขมิติสูงที่แทนความหมาย จากนั้นคำนวณระยะห่างอย่าง Cosine Similarity เพื่อหาข้อความที่ใกล้กับคำถามมากที่สุด วิธีนี้แก้ปัญหา keyword mismatch ในงานธนาคารและคอมพลายแอนซ์ได้ดี เช่น เวลาผู้ตรวจสอบค้น “Liquidity Coverage Ratio issues” เอกสารที่พูดถึง “term high-quality liquid asset shortfalls” ก็ยังถูกดึงขึ้นมา อย่างไรก็ตาม การฝังเวกเตอร์และจัดเก็บในฐานข้อมูลก็มีต้นทุนทั้งด้านคอมพิวต์และสตอเรจที่ต้องคิดรวมก่อนขยายระบบ
ข้อดีของ semantic search
- ค้นหาแบบอิงแนวคิด แก้ปัญหาคำไม่ตรงและคำศัพท์เฉพาะในโดเมนธนาคาร/คอมพลายแอนซ์
- ดึงบริบทที่สัมพันธ์กับคำถามมากกว่า keyword search ทำให้คำตอบ LLM grounded และตรวจสอบได้ง่าย
ข้อควรระวัง
- ต้องลงทุนสร้าง embeddings ให้เอกสารทั้งหมด ซึ่งมีค่าใช้จ่ายด้าน compute และ storage
- คุณภาพคำตอบขึ้นกับคุณภาพ retrieval ถ้าดึงบริบทผิด LLM จะตอบผิดอย่างมั่นใจ
กรอบ break-even: เลือก GraphRAG หรือ Plain/Hybrid ให้ไม่เปลือง
หัวใจของการไม่ overspend คือทำ break-even analysis ระหว่าง GraphRAG vs plain RAG และ hybrid retrieval โดยดูจากรูปคำถามจริง ไม่ใช่เดโมสวย ๆ GraphRAG เหมาะมากเมื่อคำถามคือความสัมพันธ์ซับซ้อนทั่วทั้ง corpus เช่นถาม “มีซัพพลายเชนไหนที่เกี่ยวกับการล้มเหลวสองภูมิภาคนี้บ้าง” เพราะโครงสร้างกราฟตอบคำถามแบบ multi-hop และ corpus-wide synthesis ได้ดีกว่า plain vector RAG ที่มักดึงแค่ chunk ใกล้ที่สุดแล้วพลาด connection ระยะไกล แต่ถ้าผู้ใช้ถามแค่ “หน้าต่างยกเลิกใน policy version 12 คือกี่วัน” การสร้างกราฟเต็มรูปแบบอาจช้ากว่า ไม่สดเท่า และโฟกัสไม่ตรงเท่าการค้นด้วย keyword หรือ metadata filter ตรง ๆ โควทที่ควรจำคือ “GraphRAG is not better RAG. It is a different retrieval investment whose return depends on the shape of your questions.”
- Plain หรือ hybrid RAG มักคุ้มกว่าเมื่อคำถามส่วนใหญ่เป็น point lookup, ใช้ filter และ lexical search ได้ดี, เอกสารเปลี่ยนเร็ว และต้องการความสดของข้อมูลสูง
- GraphRAG เริ่มคุ้มเมื่อคำถามหนักไปทาง relationship และมีมูลค่ามาก, corpus ใหญ่จน chunk เดี่ยว ๆ มองไม่เห็นโครงสร้าง, ความสัมพันธ์มีเสถียรภาพพอจะเฉลี่ยต้นทุน indexing และทีมดูแลกราฟได้ดี
ขั้นตอนสร้าง cascade RAG ให้ลดค่า LLM inference ได้ 6 เท่า
ถ้าคุณอยากลดค่า LLM inference efficiency ให้เหลือประมาณ 1 ใน 6 โดยไม่เสียคุณภาพ งานสำคัญคือไล่คัดเคสที่ไม่ต้องถึงมือ LLM ตั้งแต่ต้นทาง ในระบบหนึ่ง การส่งเฉพาะเคสที่กำกวมจริง ๆ แค่ 10–15% ไปหาโมเดล ทำให้ค่า inference ลดลงประมาณ 6 เท่าจาก baseline ที่ส่งทุกเคสเข้าโมเดล และยังทำให้เคสเชิงกฎเกณฑ์ที่ชัดเจนมีความสม่ำเสมอใกล้สมบูรณ์แบบ จุดพลาดยอดฮิตคือทีมมัก route เคสกำกวมทุกแบบตรงไปยัง LLM แล้วหวังว่าบริบทที่ retrieval เจอจะเคลียร์ปัญหาเอง ซึ่งพอระบบต้องผ่านการ audit หรือการตรวจสอบย้อนหลัง แนวทางนี้จะอธิบายเส้นทางการตัดสินใจได้ยากมาก
- ออกแบบ Stage 1 ให้เป็น deterministic: ใช้ exact match, เทียบฟิลด์โครงสร้าง และกฎที่ชัดเจนเพื่อเคลียร์เคสส่วนใหญ่โดยไม่เรียก LLM เลย
- สร้าง retrieval layer สำหรับ Stage 2: ดึงหลักฐานเฉพาะที่เกี่ยวกับความกำกวม เช่นการตัดสินใจก่อนหน้า เอกสารอธิบายความขัดแย้ง หรือข้อบังคับที่เกี่ยวข้อง โดยเน้นว่าถ้า retrieval ดึงบริบทผิด LLM จะให้คำตอบผิดอย่างมั่นใจ
- ส่งเคสที่ยังไม่เคลียร์จาก Stage 2 ไปยัง Stage 3: ทำ LLM call เฉพาะ “สารตกค้าง” ที่สองสเตจแรกตัดสินไม่ได้ แล้วบันทึกเส้นทางการตัดสินใจเพื่อใช้ตรวจสอบย้อนหลัง
ออกแบบ Hybrid Router และหลุมพรางที่ควรหลบ
Hybrid retrieval ที่ดีไม่ได้หมายถึงการโยนทุกอย่าง ทั้ง keyword, vector, graph เข้าไปในคำถามเดียวกัน แต่คือการ routing ให้แต่ละคำถามใช้เครื่องมือที่เหมาะที่สุด คุณควรเริ่มจาก prerequisites ที่ชัดเจน เช่นรวบรวมคำถามตัวแทนขององค์กร, ติดป้ายว่ามีรูปแบบคำถามอย่างไร, สร้าง baseline ด้วย plain RAG ให้แข็งแรง, ทำกราฟบน corpus ที่มีขอบเขตและมูลค่าสูง, เทียบโหมดคำตอบบนคำถามคู่กัน, รวมต้นทุน indexing และ operations เข้าไปในการเปรียบเทียบ, ตรวจสอบเคสที่ล้มเหลว แล้วค่อยตัดสินว่าคลาสคำถามไหนควรส่งเข้ากราฟ จากนั้นสร้าง router ที่เริ่มด้วยฟีเจอร์ deterministic และ classifier เล็ก ๆ เพื่อส่งคำถามไปยัง lexical/metadata search, vector RAG, local/global graph search หรือแม้แต่การเรียก tool ตรงตามประเภทคำถาม แล้วบันทึกเส้นทางเพื่อวัดข้อผิดพลาดในการ routing
- ข้อผิดพลาดที่เจอบ่อยใน GraphRAG คือการ extract entity แล้วแยกตัวเดียวเป็นหลายชื่อ หรือรวม entity คนละตัวเข้าด้วยกัน รวมถึงสร้างหรือทำหาย edges ความสัมพันธ์ในกราฟ
- อีกหลุมพรางใหญ่คือการคิดว่าทุกเคสกำกวมต้องส่งตรงไป LLM ทำให้ต้นทุน inference และ latency โตตาม volume แทนที่จะใช้กฎ deterministic เคลียร์เคสง่ายให้มากที่สุด
