เข้าใจโจทย์ก่อน: RAG ไม่ใช่ให้ LLM ทำทุกอย่าง
การลดต้นทุน RAG ให้เหลือ 1 ใน 6 คือการออกแบบสถาปัตยกรรมที่ใช้ตัวกรองข้อมูล AI แบบเป็นขั้นบันไดเพื่อกันเคสที่ตอบได้แบบเด็ดขาดออกจากโมเดลภาษา และส่งต่อเฉพาะคำถามที่กำกวมไปยัง LLM เพื่อวิเคราะห์เชิงบริบท ทำให้ทั้งค่าใช้จ่าย ความหน่วง และความเสี่ยงจากคำตอบเชิงความน่าจะเป็นลดลงอย่างมีนัยยะ โดยยังรักษาความสามารถในการดึงและสรุปข้อมูลจากคลังเอกสารขนาดใหญ่ได้ครบถ้วนสำหรับเคสที่ซับซ้อนแท้จริง
ถ้าคุณกำลังสร้างระบบ RAG ในโดเมนที่มีความเสี่ยงสูง เช่น การตัดสินอนุมัติ ปฏิบัติตามข้อกำกับ หรืองานที่ต้องมีการตรวจสอบย้อนหลัง สิ่งแรกที่ควรถามไม่ใช่ “จะทำให้โมเดลเก่งขึ้นอย่างไร” แต่คือ “ส่วนไหนของการตัดสินใจที่ไม่ควรให้โมเดลแตะต้องเลย” เพราะทุกครั้งที่คุณส่งเคสที่จริง ๆ มีคำตอบแบบกำหนดไว้แล้วเข้าไปให้ LLM ตัดสิน คุณกำลังเพิ่มทั้งต้นทุนและความเสี่ยงโดยไม่จำเป็น
หัวใจของการทำ AI inference optimization สำหรับ RAG คือการตัดสินใจให้ชัดว่าเคสไหนควรแก้ด้วยกฎ เคสไหนต้องดึงหลักฐาน เคสไหนถึงจะปล่อยให้ LLM ใช้การสรุปเชิงภาษาช่วยตัดสิน การออกแบบตัวกรองข้อมูล AI ที่ดีจึงเป็นงานวิศวกรรมที่มีคุณค่ามากกว่าแค่การปรับ prompt ให้โมเดลดูฉลาดขึ้น เพราะ “การคิดให้ละเอียดว่าข้อใดไม่ควรให้โมเดลจับต้องเลย คือวิศวกรรมที่มีค่ามากกว่า”
ขั้นบันได 3 ชั้น: โครงสร้างตัวกรองข้อมูล AI ลดต้นทุน RAG
สาเหตุใหญ่ที่ต้นทุน RAG พุ่งคือสถาปัตยกรรมแบบส่งทุกเคสเข้า LLM แล้วหวังว่าคอนเท็กซ์จะช่วยแก้ไข ทำให้คำถามง่าย ๆ อย่างดูค่าฟิลด์หรือค้นหาข้อกำหนดไปกินโควตาโมเดลโดยไม่จำเป็น วิธีแก้คือใช้ cascade architecture หรือสถาปัตยกรรมแบบขั้นบันได เปลี่ยน LLM จากแนวหน้าให้กลายเป็นช่องทางส่งต่อเคสที่แก้ด้วยกฎและ retrieval ธรรมดาไม่ได้
- ชั้นที่ 1: ใช้กฎแบบกำหนดชัด – จับเคสที่เป็น exact match, การเปรียบเทียบฟิลด์แบบโครงสร้าง และเงื่อนไขที่เขียนเป็น rule ได้ ให้ตัดสินใจจบที่นี่โดยไม่เรียก LLM เลย เคสกลุ่มนี้มักจะกินสัดส่วนมากกว่าครึ่งของปริมาณงาน และให้คำตอบที่ตรวจสอบย้อนหลังได้ง่ายเพราะเป็นการ lookup ไม่ใช่ inference
- ชั้นที่ 2: Retrieval เฉพาะจุด – เคสที่หลุดมาจากชั้นแรกเพราะไม่เข้าเกณฑ์เด็ดขาด ให้สร้าง retrieval layer ที่ดึงหลักฐานเฉพาะกรณี เช่น บันทึกการตัดสินก่อนหน้า เอกสารที่อธิบายข้อขัดแย้ง หรือ miss-match ในข้อมูล ขั้นนี้เน้นคุณภาพการดึง ความผิดพลาดของ retrieval ทำให้ LLM ให้คำตอบผิดได้แม้โมเดลจะเก่งแค่ไหน
- ชั้นที่ 3: เรียก LLM เฉพาะเคสกำกวม – ส่งต่อเฉพาะเคสที่สองชั้นแรกยังสรุปไม่ได้ให้ LLM ช่วยตัดสินโดยมีหลักฐานประกอบ ในระบบหนึ่ง การส่งต่อเพียงประมาณ 10–15% ของเคสที่กำกวมจริง ๆ ไปยัง LLM ทำให้ต้นทุน inference ลดลงประมาณ 6 เท่าเมื่อเทียบกับการส่งทุกเคสเข้าโมเดล พร้อมทั้งทำให้ความสม่ำเสมอของคำตอบในเคสแบบกำหนดชัดใกล้เคียงกับความสมบูรณ์แบบ
จุดสำคัญคืออย่าปล่อยให้ LLMแตะต้องทุกเคสเพียงเพราะ “เผื่อเจอเคสแปลก” คุณควรออกแบบตัวกรองข้อมูล AI ให้เคลียร์เคสแบบ deterministic ให้มากที่สุด แล้วใช้ retrieval เป็นตัวคัดคำถามที่สมควรให้โมเดลวิเคราะห์ การทำแบบนี้ไม่ใช่แค่ลดต้นทุน RAG แต่ยังลดการ drift ของโมเดลในเคสที่ควรมีคำตอบตายตัว เพราะไม่เปิดช่องให้โมเดลตอบตาม “อารมณ์” บนโจทย์ง่าย ๆ
GraphRAG vs plain RAG: ใช้แบบไหนคุ้มกว่าด้วยการทดสอบจุดคุ้มทุน
เมื่อพูดถึงการลดต้นทุน RAG หลายทีมเริ่มมอง GraphRAG ว่าเป็นทางลัด เพราะมันตอบคำถามที่ค้นความสัมพันธ์ซ่อนเร้นในคลังข้อมูลทั้งชุดได้ดีมาก เช่น “ความสัมพันธ์ระหว่างคน เอกสาร และเหตุการณ์ทั้งหมดคืออะไร” ที่ plain vector RAG มักดึงแค่ชิ้นข้อมูลใกล้ ๆ แล้วหลุด theme ใหญ่ แต่ในคำถามง่ายแบบ point lookup เช่น “หน้าต่างยกเลิกใน policy เวอร์ชัน 12 คืออะไร” GraphRAG อาจช้ากว่า แพงกว่า และล้าข้อมูลกว่า plain RAG แบบใช้ keyword หรือ metadata filter ตรง ๆ
สิ่งที่ต้องจำคือ “GraphRAG ไม่ใช่ RAG ที่ดีกว่า แต่เป็นการลงทุนด้าน retrieval รูปแบบหนึ่งที่ผลตอบแทนขึ้นอยู่กับรูปทรงของคำถาม” คุณควรเริ่มด้วยการเก็บตัวอย่างคำถามจริงแล้วจัดหมวดรูปแบบคำถามออกเป็นสี่ประเภท เช่น point lookup, entity neighborhood, multi-hop relationship และ corpus-wide synthesis จากนั้นสร้าง baseline plain RAG ที่แข็งแรงบนคลังเอกสาร และเลือกคลังย่อยที่มีคุณค่าสูงมาทำเป็นกราฟเพื่อทดลองเปรียบเทียบ
ระหว่างการทดสอบ ให้คิดแบบ break-even test: นับต้นทุนทั้งหมดของการทำ GraphRAG ตั้งแต่การเรียกโมเดลเพื่อดึง entity และ relationship การสรุปเป็นรายงานชุมชน การทำ embeddings ค่า compute และ storage การ retry และ cache การทำ entity resolution การรีวิวโดยมนุษย์ การ reindex เมื่อเปลี่ยน schema หรือ prompt การย้ายเวอร์ชัน การจัดการสิทธิ์ ไปจนถึงการมอนิเตอร์และดูแลระบบ แล้วแบ่งต้นทุนนี้ด้วยจำนวนคำตอบที่กราฟให้ประโยชน์จริง ไม่ใช่จำนวนคำถามทั้งหมด คุณจะเห็นว่าหลาย ๆ กรณี plain RAG หรือ hybrid RAG แบบมีตัวกรองและ router ที่ดี ให้ความคุ้มค่ามากกว่า
ออกแบบตัวกรองและตัวกระจายคำถาม: hybrid routing ที่ไม่เปลืองโทเคน
อีกความเข้าใจผิดที่พบบ่อยคือคิดว่า hybrid RAG ต้องรวมผลจากทุก retriever แล้วส่งเข้า LLM ทุกครั้ง ซึ่งทำให้โทเคนเยอะขึ้น ต้นทุนสูงขึ้น และทำให้หลักฐานขัดแย้งกันจนยากต่อการตีความ วิธีที่ฉลาดกว่าคือมอง hybrid เป็นเรื่องของการ routing ไม่ใช่การผสมทุกอย่างเข้าด้วยกัน คุณออกแบบตัวกรองข้อมูล AI และ router ให้เลือกเส้นทางที่ถูกต้องให้กับแต่ละคำถามแทน
ระบบที่ใช้งานจริงสามารถกำหนดเส้นทางแบบชัดเจน เช่น คำถามที่เป็น exact identifier หรือ policy lookup ให้ไปการค้นแบบ lexical หรือ metadata search, คำถามเชิงข้อเท็จจริงเชิงความหมายให้ไป vector RAG, คำถามความสัมพันธ์ของ entity ให้ไป local graph search, คำถาม theme ทั้งคลังให้ไป global graph search, คำถามซับซ้อนที่ไม่แน่ใจให้ไป agentic retrieval ที่ควบคุมได้ และคำถามสถานะบัญชีแบบ real-time ให้เรียก direct tool โดยตรง router เริ่มต้นจากการใช้ฟีเจอร์เชิง deterministic และ classifier ขนาดเล็กเพื่อเลือกเส้นทาง แล้วบันทึก path ที่เลือกเพื่อวิเคราะห์ความผิดพลาดของการ routing ในภายหลัง
จุดที่ต้องระวังคืออย่าดักทุกคำถามให้วิ่งผ่านกราฟหรือ LLM โดยไม่มีเหตุผล ถ้า distribution ของคำถามส่วนใหญ่เป็น point lookup และ metadata search แรง Plain หรือ hybrid RAG มักชนะ ทั้งในด้านต้นทุนและ latency โดยเฉพาะในคลังเอกสารที่เปลี่ยนแปลงบ่อย มีข้อจำกัดเรื่องความสดของข้อมูล และสิทธิ์ในการเข้าถึงเอกสารเปลี่ยนตลอดเวลา การ routing แบบฉลาดจึงทำหน้าที่เป็นตัวกรองชั้นแรกที่กันโอกาสสิ้นเปลืองโทเคนใน workload ปริมาณสูง และช่วยให้การ AI inference optimization ที่คุณลงทุนไปเห็นผลชัดเจน
สรุป: เมื่อไหร่ GraphRAG ถึงคุ้ม และอะไรที่ไม่ควรให้โมเดลแตะต้องเลย
เมื่อคุณออกแบบตัวกรองข้อมูล AI และ cascade architecture ดีแล้ว ผลลัพธ์ที่ควรเห็นคือเคสแบบ deterministic ถูกเคลียร์ด้วยกฎและ lookup อย่างมีความสม่ำเสมอใกล้เคียงสมบูรณ์แบบ ขณะที่ต้นทุน inference ลดลงอย่างมาก เพราะมีเพียงเคสที่กำกวมจริง ๆ เพียงประมาณ 10–15% เท่านั้นที่เข้าสู่ LLM ทำให้ต้นทุน RAG ลดลงได้ประมาณ 6 เท่าเมื่อเทียบกับ baseline ที่ทุกเคสเข้าโมเดล นี่คือผลลัพธ์ที่จับต้องได้จากการวางกลยุทธ์ “อะไรที่ไม่ควรไปถึงโมเดลตั้งแต่แรก”
สำหรับ GraphRAG ให้ใช้หลักคิดว่า “โครงสร้างคือคำตอบ” หรือไม่ ถ้าคำถามของคุณต้องการเห็นเส้นทางความสัมพันธ์หลายชั้น ธีมข้ามคลังใหญ่ และคำถามเชิง community หรือ tension ที่ plain RAG มองไม่เห็น โครงสร้างกราฟย่อมมีค่าคุ้มต้นทุน แต่ถ้าส่วนใหญ่เป็น point lookup ใช้ metadata filter สบาย เอกสารเปลี่ยนเร็ว และต้องการคำตอบสดใหม่พร้อม citation จาก passage เล็ก ๆ การลงทุนในกราฟอาจเป็นการใช้ทรัพยากรมากเกินไป โดย plain หรือ hybrid RAG จะตอบโจทย์กว่ามาก
ท้ายที่สุด การลดต้นทุน RAG ไม่ใช่ความสามารถของโมเดล แต่เป็นการออกแบบสถาปัตยกรรมที่ลด “ความน่าจะเป็นที่เปลืองโดยไม่จำเป็น” ในระบบปริมาณงานสูง ชั้นกฎที่ดี retrieval ที่แม่น และ router ที่เลือกเส้นทางอย่างมีเหตุผล จะช่วยให้คุณได้ทั้งความคุ้มค่า ความโปร่งใสในการตรวจสอบ และคำตอบที่สอดคล้องกับความเสี่ยงของโดเมนที่คุณทำงานอยู่
