Tool: local_search — ค้นเนื้อหาใน Desktop/Documents โดยไม่ปะปนกับ Knowledge Base

ภาพรวมระบบสำหรับ: Tool: local_search — ค้นเนื้อหาใน Desktop/Documents โดยไม่ปะปนกับ Knowledge Baselocal_search ของ Agent Lite ค้นไฟล์ทั่วไปแบบ read-only เฉพาะ Desktop และ Documents รองรับ text/PDF/Office พร้อม location/snippet และตั้งใจแยกจาก MCP-RagDocคำขอขั้นที่ 1ตรวจเงื่อนไขขั้นที่ 2ทำงานจริงขั้นที่ 3ผลลัพธ์ขั้นที่ 4agent lite
ภาพประกอบระบบคำขอทุกครั้งผ่านการตรวจสอบก่อนระบบจะทำงานจริง

local_search เกิดขึ้นเพื่อแก้ปัญหา scope ที่พบบ่อยใน Agent Lite: ไฟล์ทั่วไปของผู้ใช้ไม่ได้แปลว่าอยู่ใน Knowledge Base

Knowledge Base รุ่นปัจจุบัน index เฉพาะ rag_document/ ผ่าน MCP-RagDoc ส่วนคำขอทั่วไปอย่าง “หาไฟล์ใน Documents ที่พูดถึงหัวข้อนี้” ควรมีเส้นทางค้นเฉพาะ Desktop/Documents โดยไม่ต้อง sync KB ก่อน

ขอบเขตชัดเจน

local_search ค้นเฉพาะ roots ที่ config กำหนดไว้ ซึ่ง production default คือ:

Desktop
Documents

เป็น read-only, deterministic, ไม่ใช้ Knowledge Base index และไม่ใช้เว็บ

ค้นจาก “เนื้อหา” ไม่ใช่แค่ชื่อไฟล์

Tool รับ query สั้นๆ แล้ว scan candidate files ที่รองรับ ทั้ง text/code และ document formats

สำหรับ text file ใช้ sliding window แบบ bounded เพื่อหา query/terms โดยไม่อ่านทุกอย่างขึ้น memory พร้อมกัน

สำหรับเอกสารใช้ extractor ของ Lite และรักษา location ที่อธิบายได้ เช่น:

  • PDF page
  • slide
  • sheet
  • table
  • DOCX location

ผลลัพธ์คืน absolute path + location + snippet เพื่อให้ caller ใช้ read_file ต่อ

Thai/mixed query normalization

query ถูก normalize และตัด filler words จากไทย/อังกฤษ จากนั้นแยก meaningful terms แบบ bounded

ถ้าประโยคตรงๆ ไม่ match ระบบยังตรวจว่าคำสำคัญหลายคำอยู่ใน unit เดียวกันหรือไม่ เพื่อรับมือ spacing/line-break ในเอกสาร โดยไม่กลายเป็น OR-search กว้างเกินไปจากคำทั่วไปคำเดียว

ต่างจาก MCP-RagDoc อย่างไร

rag_document/        → MCP-RagDoc rag_search
Desktop/Documents   → local_search

MCP-RagDoc มี persistent SQLite/semantic index และต้อง sync เมื่อ source เปลี่ยน ส่วน local_search เป็น bounded live scan สำหรับไฟล์ทั่วไปที่ไม่ควรถูกบังคับให้ย้ายเข้า KB ก่อน

ทำไมไม่ให้ RAG ค้นทั้ง Mac

ถ้า RAG มี scope ทั้ง Desktop/Documents/Home พร้อมกัน จะทำให้:

  • ผู้ใช้ไม่รู้ว่าข้อมูลไหนถูกนำเข้า KB
  • sync/index cost โตโดยไม่จำเป็น
  • source boundary अस्पष्ट
  • ความเสี่ยงอ่านไฟล์ผิดขอบเขตเพิ่มขึ้น

การแยก tool ตาม intent ทำให้ scope ตรวจสอบง่ายกว่า

Safety

  • ข้าม hidden/system-ish directories ที่กำหนด
  • ไม่ follow symlink
  • sensitive paths ถูกบล็อก
  • candidate file type และ plain-file size ถูกจำกัด
  • search มี deadline/limits เพื่อไม่ scan แบบไม่สิ้นสุด
  • ผลที่พบควรตามด้วย read_file จาก absolute path แทนการค้นซ้ำ

อ่านต่อ

ความคิดเห็น

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