Tools: build_kb, build_status, cancel_build และ rag_health
สี่ tool นี้ดูแล lifecycle ของ knowledge base: เริ่ม build, ติดตาม, ขอหยุดอย่างปลอดภัย และตรวจว่า derived state พร้อมใช้งานจริงหรือไม่
build_kb()
เริ่ม incremental build แบบ background แล้วคืน persistent job_id ทันที Caller ไม่ต้องค้าง stdio process รอจนจบ
Source root ถูกกำหนดจาก configuration ของ MCP-RagMax อยู่แล้ว Tool นี้ไม่รับ arbitrary path จาก model
build_status(job_id)
ใช้ poll งานเดิมเพื่อดู phase, progress และ ETA
เพราะ job state ถูก persist ใต้ derived state การ poll ไม่จำเป็นต้องมาจาก MCP process เดิมที่เริ่มงาน เหมาะกับ host ที่สร้าง stdio process ใหม่ต่อ tool call
cancel_build(job_id)
เป็น cooperative cancellation ไม่ใช่ kill process ทันทีทุกจุด
เหตุผลคือ changed file บางช่วงกำลัง replace rows เก่าใน index ถ้าหยุดกลางจุดนั้นอาจทำให้ไฟล์หายจาก derived state ทั้งที่ build ยังไม่เสร็จ
นโยบายหลัก:
- new file สามารถ rollback partial ingest แล้วหยุดได้
- changed file ที่เข้าสู่ destructive replace section แล้วจะ finish ไฟล์ปัจจุบันก่อน แล้วค่อยหยุดก่อนเริ่มไฟล์ถัดไป
จึงยอมแลกความเร็วในการ cancel บางช่วงเพื่อรักษา consistency ของ KB
rag_health()
health ของ RAG ไม่ควรหมายถึงแค่ “MCP process ตอบได้” เพราะ process อาจยังรันแต่ Chroma, BM25, registry หรือ orientation state มีปัญหา
rag_health จึงตรวจภาพรวมของ:
- dense/Chroma readiness
- BM25 state
- file registry
- pipeline fingerprint/state
- orientation index
- background build jobs
Caller ควรใช้ health เป็น contract ก่อนงานสำคัญหรือเมื่อ retrieval/build มีอาการผิดปกติ
Workflow ตัวอย่าง
rag_health
↓
ต้อง build/update?
↓ yes
build_kb → job_id
↓
build_status(job_id)
↓
ถ้าผู้ใช้ยกเลิก → cancel_build(job_id)
↓
terminal state
↓
rag_health → rag_retrieve
ความคิดเห็น
กำลังโหลดความคิดเห็น...