Tool: rag_retrieve — Hybrid retrieval contract หลักของ MCP-RagMax

เผยแพร่ 12 สิงหาคม 2569 · อัปเดต 11 กันยายน 2569

ภาพประกอบ: Tool: rag_retrieve — Hybrid retrieval contract หลักของ MCP-RagMax

rag_retrieve คือ tool หลักของ MCP-RagMax สำหรับดึงหลักฐานจาก knowledge base โดยไม่เปิด chat model และไม่ใช้ LLM rerank ภายใน backend

Input

รับ query เป็น string เดียวหรือ list ของ query variants แบบ bounded พร้อมตัวเลือก:

  • mode: chunks, files, source_first
  • tags
  • filename_contains
  • created_after / created_before (YYYY-MM-DD)
  • source_type

ถ้าใช้หลาย query ทุกตัวต้องเป็น same intent เช่นประโยคไทยเดิม, คำแปลอังกฤษ และ keyword ของคำถามเดียวกัน ไม่ควรใช้ list เพื่อยัดหลาย subquestion ที่ต่างกันเข้ามาใน call เดียว

Retrieval pipeline

query variant
  ├─ multilingual MiniLM dense search
  └─ Thai-aware BM25
           │
           ▼
       RRF fusion
           │
           ▼
  deterministic unique-parent selection

การใช้ RRF ทำให้ระบบรวม ranking จาก dense กับ lexical search ได้โดยไม่ต้องเทียบ raw score คนละสเกล และไม่ต้องโหลด LLM เพิ่มเพื่อ rerank

เลือก mode ให้ตรงงาน

  • chunks — เหมาะเมื่อ caller ต้องการ context ไปตอบคำถาม
  • files — เหมาะเมื่ออยากได้ candidate files ก่อนอ่านต่อ
  • source_first — เหมาะเมื่อ provenance/source selection สำคัญก่อนเนื้อหา

Caller agent เป็นคนตัดสินใจว่าจะอ่าน source เพิ่มหรือสรุปอย่างไรต่อ ไม่ใช่ backend

Read-only และ source-confined

rag_retrieve ไม่เปิด arbitrary filesystem read, shell, Python หรือ memory-write tool และทำงานกับ index/source root ที่ backend กำหนดไว้เท่านั้น

ทำไมไม่ใช้ LLM rerank

รุ่นก่อนของ RAG บางแบบใช้ LLM ช่วยขยาย query หรือ rerank candidate แต่ MCP-RagMax ตั้งใจให้ retrieval backend deterministic เพื่อให้ behavior reproducible, test ได้ และไม่ผูกกับโมเดลของ caller

ถ้า caller อยากใช้ LLM ช่วยแตก query ให้ดีขึ้น ก็ทำได้ที่ชั้น agent แล้วส่ง same-intent variants เข้ามา แต่ ranking ฝั่ง backend ยังคงเป็น Dense + BM25 + RRF เหมือนเดิม

อ่านต่อ

ความคิดเห็น

กำลังโหลดความคิดเห็น...