เทคนิค RAG ขั้นสูงไม่ได้ดีกว่าเสมอไป แต่มันดีกว่าในบางกรณีเท่านั้น
เทคนิค RAG ขั้นสูงไม่ใช่การอัปเกรดที่ได้มาฟรีๆ แต่มันคือเครื่องมือที่มีข้อแลกเปลี่ยน (trade-offs)
ผมได้เพิ่มเทคนิคการดึงข้อมูล (retrieval) 5 รูปแบบเข้าไปใน RAG pipeline เพื่อทดสอบ และผลลัพธ์ที่สำคัญที่สุดคือเทคนิคที่ล้มเหลว
ผมคาดหวังว่า HyDE จะช่วยปรับปรุงการดึงข้อมูลให้ดีขึ้น แต่กลายเป็นว่ามันกลับส่งผลเสียกับบางคำถาม (queries) ค่า Recall ลดลงจาก 0.80 เหลือเพียง 0.17 เทคนิคนี้ไม่เพียงแต่ช่วยไม่ได้ แต่มันยังดึงข้อมูลที่ผิดพลาดเข้ามาในผลลัพธ์อย่างจงใจอีกด้วย
ทุกเทคนิคขั้นสูงที่ผมทดสอบมีลักษณะการทำงานดังนี้:
- Hybrid search (BM25 + dense): ดีมากสำหรับคำที่ต้องการความแม่นยำสูง (exact terms) ควรใช้เมื่อคำถามของคุณต้องพึ่งพาพารามิเตอร์ที่เฉพาะเจาะจง
- HyDE: ดีมากสำหรับคำถามทั่วไปที่ไม่ได้ใช้คำศัพท์เดียวกับในเอกสาร แต่มันจะล้มเหลวเมื่อคำถามนั้นตรงกับเนื้อหาในคลังข้อมูล (corpus) อยู่แล้ว
- Reranking: ดีมากเมื่อข้อมูลส่วนที่ถูกต้อง (chunk) อยู่ในผลลัพธ์แล้ว แต่ลำดับความสำคัญกลับอยู่ต่ำเกินไปในรายการ
- Contextual retrieval: ดีมากสำหรับข้อมูลส่วนสั้นๆ ที่ขาดบริบท แต่มันจะเพิ่มต้นทุนเพราะคุณต้องใช้ LLM กับทุกๆ chunk
ผมสร้าง pipeline นี้โดยอ้างอิงจากเอกสารของ Anthropic ผมใช้ Postgres ร่วมกับ pgvector และ HNSW index ผมมองเรื่องนี้ในมุมของวิศวกร backend ผมไม่ได้ถามว่าเทคนิคนั้นเป็นเทคโนโลยีล้ำสมัย (state of the art) หรือไม่ แต่ผมถามว่ามันคุ้มค่ากับความซับซ้อนที่เพิ่มขึ้นมาหรือไม่
ทุกส่วนประกอบที่คุณเพิ่มเข้าไป คือสิ่งที่คุณต้องดูแล (operate) แก้ไข (debug) และต้องจ่ายเงินค่าใช้จ่ายที่ตามมา
ก่อนที่จะเพิ่มเครื่องมือที่ซับซ้อน ผมได้วัดค่าพื้นฐาน (baseline) โดยใช้การดึงข้อมูลแบบ dense retrieval แบบธรรมดา
ผลลัพธ์แสดงตัวชี้วัด (metrics) สองค่าที่แตกต่างกัน:
- Faithfulness: 0.96
- Context precision: 0.60
ข้อมูลนี้เปลี่ยนแนวทางทั้งหมดของผม เทคนิคส่วนใหญ่มุ่งเน้นไปที่การดึงข้อมูล (retrieval) แต่การดึงข้อมูลของผมคือส่วนที่ล้มเหลว หากค่า faithfulness ต่ำ ผมคงต้องไปปรับจูน prompt แต่ในเมื่อค่า retrieval ต่ำ ผมจึงต้องไปปรับจูนการค้นหา (search) แทน
ผมยังได้เรียนรู้บทเรียนเกี่ยวกับเครื่องมือประเมินผล (evaluation tools) ด้วย ผมลองใช้ Ragas แต่พบว่ามันช้าเกินไป มันจะพยายามเรียกซ้ำเมื่อการเรียกใช้งานล้มเหลวและใช้เวลานานหลายชั่วโมง ผมจึงสร้าง async harness ของตัวเองขึ้นมาแทน และสามารถรันตัวชี้วัดเดิมได้ในเวลาเพียง 221 วินาที แทนที่จะเป็น 11 ชั่วโมง
บทสรุปนั้นเรียบง่าย:
อย่าใช้เทคนิคแบบสุ่มสี่สุ่มห้า จงใช้ query router เพื่อเลือกโหมดที่เหมาะสมกับคำถามที่ถูกต้อง วัดผลข้อมูลของคุณก่อน จากนั้นจึงเลือกเครื่องมือที่แก้ปัญหาในรูปแบบความล้มเหลว (failure mode) เฉพาะจุดของคุณ
โมเดลอาจจะเป็นเรื่องใหม่ แต่ระเบียบวินัยทางวิศวกรรมนั้นไม่ใช่เรื่องใหม่
ที่มา: https://dev.to/yogesh23012001/advanced-rag-techniques-arent-better-theyre-better-sometimes-4m2o