ลดต้นทุนการใช้ RAG ถึง 6‑เท่าด้วยสถาปัตยกรรมแบบ cascade.

การออกแบบระบบ Retrieval‑Augmented Generation (RAG) เพื่อใช้ในงานจำแนกประเภทระดับสูงได้มีการเปลี่ยนแปลงสำคัญเมื่อผู้พัฒนาตระหนักว่าการส่งข้อมูลทุกกรณีไปยังโมเดลภาษาใหญ่ (LLM) ไม่สามารถรับมือกับข้อกำหนดด้านการตรวจสอบและต้นทุนที่เพิ่มขึ้นได้ ระบบแบบใหม่ที่ใช้ cascade architecture สามารถลดค่าใช้จ่ายของการ inference ได้ประมาณ 6‑เท่า** พร้อมเพิ่มความชัดเจนในการอธิบายผลลัพธ์

Overview

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

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

สุดท้ายโมเดลภาษาใหญ่มีคุณสมบัติ drift หรือการเปลี่ยนแปลงพฤติกรรมในกรณีที่ควรให้ผลลัพธ์เชิง deterministic การพึ่งพา LLM เพียงอย่างเดียวอาจทำให้เกิดความไม่สอดคล้องกันในเคสที่ควรจะตอบได้ชัดเจน

Cost Challenges

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

• Auditability – ผู้ตรวจสอบต้องการเส้นทางตัดสินใจที่สามารถเรียกคืนได้โดยไม่ต้องรัน inference ซ้ำ
• Scalability – ระบบที่ต้องจัดการกับหลายหมื่นเคสต่อวันจะเผชิญกับค่าใช้จ่ายและ latency ที่เพิ่มขึ้นอย่างรวดเร็ว
• Model Drift – ความไม่เสถียรของ LLM ในกรณี deterministic ทำให้ผลลัพธ์อาจเปลี่ยนแปลงโดยไม่มีเหตุผลที่ชัดเจน

การพิจารณาปัจจัยเหล่านี้ทำให้หลายองค์กรเริ่มมองหาวิธีจัดสรรงานระหว่างกฎฐาน (rule‑based) กับ LLM อย่างมีประสิทธิภาพ

Cascade Architecture

แนวคิดหลักของ cascade architecture คือเปลี่ยนตำแหน่งของ LLM ให้เป็น “เส้นทางการยกระดับ” แทนที่จะเป็นจุดเริ่มต้นของการตัดสินใจ ระบบแบ่งออกเป็นสามขั้นตอน:

• Deterministic stage – ตรวจสอบความตรงกันแบบ exact match, การเปรียบเทียบฟิลด์ที่มีโครงสร้างชัดเจน และกฎที่กำหนดไว้ล่วงหน้า ขั้นตอนนี้ไม่มีการเรียก LLM เลยและมักจัดการได้มากกว่า **50 % ของปริมาณข้อมูล ขึ้นอยู่กับคุณภาพของข้อมูลต้นทาง
• Retrieval stage – สำหรับเคสที่ไม่สามารถตัดสินใจได้ในขั้นแรก ระบบจะดึงเอกสารหรือกรณีก่อนหน้าที่เกี่ยวข้อง เช่น การตัดสินใจของผู้ตรวจสอบคนอื่น หรือข้อกำหนดประวัติศาสตร์ การเลือกบริบทที่เหมาะสมเป็นสิ่งสำคัญ เพราะแม้ LLM จะดีที่สุด หากได้รับข้อมูลผิดก็จะให้ผลลัพธ์ที่เชื่อถือไม่ได้
• LLM stage – ขั้นสุดท้ายนี้รับเคสที่ยังเหลืออยู่หลังจากสองขั้นตอนแรกเท่านั้น ซึ่งโดยทั่วไปคือประมาณ 10‑15 % ของเคสทั้งหมด การส่งเฉพาะเคสที่มีความคลุมเครือจริง ๆ ไปยัง LLM ทำให้ค่า inference ลดลงถึง 6‑เท่า** เมื่อเปรียบเทียบกับโมเดลที่ใช้ตลอดกระบวนการ

โครงสร้างแบบ cascade จึงทำให้ระบบทั้งในแง่ของต้นทุนและความสอดคล้องกันดีขึ้นอย่างมีนัยสำคัญ

Prompt Design for Asymmetric Risk

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

การออกแบบ prompt ที่คำนึงถึง asymmetric risk จะบ่งบอกให้โมเดลเข้าใจว่า “ความไม่แน่นอน” ควรส่งต่อให้ผู้ตรวจสอบมนุษย์แทนที่จะทำการตัดสินใจอัตโนมัติ ตัวอย่างของแนวทางนี้รวมถึง:

• ให้โมเดลระบุระดับ confidence score พร้อมกับผลลัพธ์
• กำหนดเกณฑ์ว่าหากคะแนนความเชื่อมั่นต่ำกว่าเกณฑ์ที่ตั้งไว้ ระบบจะส่งต่อให้ผู้ตรวจสอบมนุษย์โดยอัตโนมัติ
• จัดทำตัวอย่าง (examples) ที่ชัดเจนเกี่ยวกับผลกระทบของการพลาดประเภทหนึ่งเทียบกับอีกประเภทหนึ่ง

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

Evaluation & Impact

มาตรฐานการวัดผลของ RAG มักมุ่งเน้นที่ retrieval quality และ final classification accuracy เพียงอย่างเดียว ซึ่งอาจให้ภาพลวงตาว่าระบบทำงานได้ดี เนื่องจากส่วนใหญ่ของเคสอยู่ในขั้น deterministic ที่ถูกจัดการได้ง่าย

เพื่อประเมินระบบแบบ cascade อย่างแม่นยำ ผู้พัฒนาต้องแยกการวัดผลออกเป็นสองส่วน:

• Retrieval metrics – ตรวจสอบคุณภาพของเอกสารที่ดึงมาโดยไม่ผสานกับขั้นตอน generation
• Stage‑three performance – เน้นการสุ่มเลือกเคสที่ต้องผ่าน LLM อย่างเต็มที่ เพื่อให้เห็นข้อบกพร่องในส่วนที่สำคัญที่สุด

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

สุดท้าย ระบบต้องสร้าง feedback loop เพื่อนำผลลัพธ์ที่ยืนยันแล้วกลับเข้าสู่คอร์ปัสของ retrieval ทำให้ฐานข้อมูลมีความทันสมัยและช่วยลดโอกาสของการดึงบริบทผิดพลาดในอนาคต

Summary

การเปลี่ยนจากโมเดล LLM เป็นศูนย์กลางไปเป็นส่วนสุดท้ายของกระบวนการแบบ cascade สามารถลดค่า inference ได้ประมาณ 6‑เท่า พร้อมเพิ่มความโปร่งใสและความแม่นยำสำหรับเคสที่ต้องการตรวจสอบอย่างละเอียด การออกแบบ prompt ให้คำนึงถึงความเสี่ยงแบบไม่สมดุล และการประเมินผลโดยแยกขั้นตอนเป็นจุดสำคัญที่จะทำให้ระบบ RAG ที่ใช้ในองค์กรมีประสิทธิภาพและปลอดภัยต่อการปฏิบัติงานจริง.