Tool: search_files — หาไฟล์จากชื่อ ไม่ใช่จากเนื้อหา ตัดสับสนกับ rag_search
search_files ค้นหาไฟล์จากชื่อหรือพาธในคลังความรู้ เหมาะเมื่อผู้ใช้รู้ชื่อเอกสารคร่าว ๆ และต้องการหาไฟล์ต้นทางก่อนอ่านหรือค้นหาเนื้อหาในไฟล์นั้น
Tool นี้คืออะไร
ค้นหาไฟล์ในคลังความรู้ที่ชื่อไฟล์มีคำที่ระบุอยู่ในตัว — ไม่แตะเนื้อหาไฟล์เลย เป็นการเทียบ substring แบบง่ายๆ (query.lower() in filename.lower()) คืนรายชื่อไฟล์ที่ตรงกัน สูงสุด 30 รายการ พร้อมบอกจำนวนที่เหลือถ้ามีมากกว่านั้น
จุดสำคัญ: แยกจาก rag_search ชัดเจนเพื่อกันความสับสน
Docstring ระบุเงื่อนไขการใช้ตรงๆ: “Use when the user asks to find files by name or topic keyword” — เช่นคำถามแบบ “หาไฟล์ที่มีคำว่า ‘สัญญา’ ในชื่อ” ต่างจาก rag_search ที่ค้นจากเนื้อหาภายในไฟล์ ทั้งสอง tool มีจุดประสงค์ต่างกันชัดเจนแม้ผิวเผินจะดูคล้ายกัน (“ค้นหาในคลัง” เหมือนกัน) — การแยก tool ออกจากกันชัดเจนแบบนี้ช่วยให้โมเดลเลือกถูกตัวตั้งแต่ต้น: ถามหาชื่อไฟล์ → search_files, ถามหาเนื้อหา/คำตอบ → rag_search
ถ้ารวมสอง capability นี้ไว้ใน tool เดียว โมเดลอาจสับสนว่าเมื่อไรควรเทียบ substring ชื่อไฟล์ตรงๆ เมื่อไรควรทำ semantic search เต็มรูปแบบ — การแยกเป็นคนละ tool ทำให้แต่ละ tool มี “งานเดียว” ที่ชัดเจน
ผลลัพธ์ที่จำกัดจำนวนแบบโปร่งใส
คืนสูงสุด 30 ชื่อไฟล์ พร้อมข้อความบอกจำนวนที่เหลือชัดเจน (... ยังมีอีก N ไฟล์) ถ้าคำค้นกว้างเกินไปจนแมตช์เยอะ — ผู้ใช้เห็นทันทีว่าควรเจาะจงคำค้นให้แคบลงถ้าต้องการดูให้ครบ แทนที่จะได้ผลลัพธ์ที่ดูเหมือนครบถ้วนแต่จริงๆ ถูกตัดไปเงียบๆ
ทำไมเรื่องนี้ถึงสำคัญ
search_files เป็นตัวอย่างของ tool ที่เรียบง่ายที่สุดในชุดของ RAG แต่มีบทบาทสำคัญในการแบ่งความรับผิดชอบให้ชัดเจน — ไม่พยายามทำทุกอย่างในที่เดียว (รวมค้นชื่อ+เนื้อหาไว้ใน tool เดียว) แต่แยกเป็นเครื่องมือคนละชิ้นที่มีขอบเขตแคบและชัดเจน ทำให้ทั้งโมเดลเลือกใช้ถูกและนักพัฒนาแก้ไข/ทดสอบแต่ละ tool แยกจากกันได้ง่ายกว่า
ความคิดเห็น
กำลังโหลดความคิดเห็น...