Knowledge Base: rag_search ผ่าน MCP-RagDoc

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

ภาพประกอบ: Knowledge Base: rag_search ผ่าน MCP-RagDoc

ใน Agent Lite รุ่นปัจจุบัน rag_search ไม่ได้เป็น top-level tool ที่ฝังอยู่ใน agent โดยตรง แต่เป็น tool ของ MCP-RagDoc ซึ่ง Agent Lite เรียกผ่าน generic MCP client:

mcp_call_tool(
  server="lite-rag",
  tool_name="rag_search",
  arguments_json='{"query":"..."}'
)

การแยกแบบนี้ทำให้ Knowledge Base backend อยู่คนละ boundary กับ agent loop และนำ MCP-RagDoc ไปใช้กับ host อื่นได้โดยไม่ต้องเปลี่ยน source code ของ RAG

ขอบเขตของ Knowledge Base

ค่าเริ่มต้นคือ:

rag_document/

รองรับ nested directories และ source documents หลายชนิด เช่น text/Markdown, PDF, Word, Excel, PowerPoint, ODF และภาพ

MCP-RagDoc ถูกผูกกับ source directory หนึ่งชุดต่อ process และไม่รับ tool argument ที่ใช้ขยายขอบเขตไปโฟลเดอร์อื่นตามใจโมเดล

Retrieval ทำงานอย่างไร

เส้นทางค้นหลัก:

filename-first
→ SQLite FTS5/BM25
→ Thai/mixed normalization + aliases
→ English split-word recovery
→ OCR fuzzy recovery
→ optional MiniLM semantic retrieval
→ deterministic RRF fusion

จึงไม่ใช่ lexical-only RAG แบบรุ่นเก่าอีกแล้ว ถ้ามี semantic index พร้อม ระบบสามารถดึงเอกสารที่ความหมายใกล้กันแม้คำไม่ตรงทั้งหมด แต่ถ้า semantic dependency/model ไม่พร้อม ระบบจะ degrade ไปใช้ lexical/OCR path แทน ไม่ทำให้ search ทั้งระบบหยุด

Semantic path ยังออกแบบให้ low-RAM

MCP-RagDoc ใช้ sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 ผ่าน ONNX INT8 worker แบบ subprocess อายุสั้น

หลัง build/query worker จบ process จึงไม่ค้าง ONNX/NumPy/SentencePiece resident อยู่ใน MCP server ตลอดเวลา ซึ่งเหมาะกับเป้าหมาย RAM ต่ำของ Agent Lite

Search ไม่ download model ตอนถาม

การค้นธรรมดาจะไม่แอบ download semantic model หากไม่มี cache Operator ต้องเตรียม model snapshot มาก่อน หรือปิด semantic แล้วใช้ lexical/OCR retrieval ต่อได้

นี่ช่วยให้พฤติกรรม search predictable และไม่เกิด network/download ชุดใหญ่กลางคำถามของผู้ใช้

Source provenance เป็นส่วนหนึ่งของผลลัพธ์

ผลค้นเก็บ source absolute path และตำแหน่ง เช่นหน้า/section เท่าที่ extractor รู้ และมี machine-readable marker รูปแบบเดียวกับ source evidence อื่นของ Agent Lite

agent layer จึงสามารถ:

rag_search
→ ได้ source path/page
→ read_file(path=...)
→ ตรวจต้นฉบับเพิ่มก่อนสรุป

เป้าหมายคือให้ผู้ใช้ย้อนกลับไปยังเอกสารจริงได้ ไม่ใช่มีเพียง snippet ที่ไม่รู้มาจากไหน

เมื่อเป็น scanned PDF

MCP-RagDoc ใช้ Apple Vision OCR สำหรับหน้าที่ไม่มี text layer และสามารถเลือกใช้ local OpenAI-compatible vision server ช่วย rewrite OCR แบบ conservative ก่อนเขียน SQLite

ค่าเริ่มต้นของ standalone public project ไม่ start/stop model เอง หาก server ไม่พร้อมหรือ validation ไม่ผ่าน ระบบเก็บ Apple Vision OCR เดิมแทน

ใน integration กับ Agent Lite สามารถ opt in ให้ local lifecycle endpoint เปิดโมเดลเมื่อจำเป็นได้ แต่ RAG backend ยังคงไม่ import host-agent modules

Sync ก่อนข้อมูลใหม่จะค้นเจอ

เมื่อเพิ่ม/แก้เอกสารใน rag_document/ ให้ใช้:

/sync_kb

หรือ agent เรียก:

mcp_call_tool(server="lite-rag", tool_name="sync_kb", arguments_json='{}')

sync_kb คืน persistent job_id; มี sync_status และ cancel_sync สำหรับติดตาม/ขอยกเลิกอย่างปลอดภัย

ถ้า MCP-RagDoc unavailable

Agent Lite ไม่ควรเรียก rag_search เดิมซ้ำไม่จบ

ถ้า server lite-rag ไม่มี, tool หาย หรือเชื่อมต่อไม่ได้ ระบบ fallback ไป bash แบบ read-only โดย ยังจำกัด scope ที่ Knowledge Base เดิม (rag_document/) ห้ามขยายไปทั้ง Home และห้ามเอา web search มาแทน local KB

  • rag_search → Knowledge Base (rag_document/)
  • local_search → ไฟล์ทั่วไปใน Desktop/Documents

สองเส้นทางตั้งใจแยกกันเพื่อให้คำว่า “ค้นไฟล์” ไม่ทำให้ระบบเดาสcopeผิด

อ่านต่อ

ความคิดเห็น

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