Tool: read_file — อ่านไฟล์ดิบเต็มๆ เมื่อผู้ใช้ขอเปิดไฟล์ตรงๆ ไม่ผ่านการค้น
read_file เปิดอ่านไฟล์ที่เลือกแล้วตามช่วงเนื้อหาที่ต้องการ ใช้เมื่อผลการค้นหาบอกตำแหน่งที่น่าสนใจ แต่ยังต้องตรวจรายละเอียดจากต้นฉบับ
Tool นี้คืออะไร
อ่านและคืนเนื้อหาดิบเต็มๆของไฟล์หนึ่งจากคลังความรู้ — ต่างจาก rag_search ที่คืนแค่ chunk ที่เกี่ยวข้อง read_file คืนทั้งไฟล์ตรงๆ ไม่ผ่านการตัดหรือสรุปใดๆ
Agent เรียก tool นี้เมื่อไร
Docstring ระบุ trigger ชัดเจน: ใช้เมื่อผู้ใช้พูด “เปิดไฟล์ X”, “อ่านไฟล์ X” หรือขอดูเนื้อหาไฟล์ตรงๆ — เป็นคนละสถานการณ์กับการถามคำถามที่คำตอบอาจอยู่ในเอกสาร (ซึ่งเหมาะกับ rag_search มากกว่าเพราะไม่ต้องยัดทั้งไฟล์เข้า context) read_file เหมาะกับกรณีที่ผู้ใช้ต้องการเห็นไฟล์ทั้งไฟล์จริงๆ ไม่ใช่แค่คำตอบที่สกัดมาจากไฟล์นั้น
จับคู่ชื่อไฟล์แบบยืดหยุ่นเป็นลำดับขั้น
รับ input ได้ 3 แบบ: absolute path เป๊ะ, ชื่อไฟล์เป๊ะ, หรือชื่อไฟล์บางส่วน — ระบบลองจับคู่ตามลำดับความแม่นยำ: path/ชื่อไฟล์ตรงเป๊ะก่อน ถ้าไม่เจอค่อยลองจับคู่แบบ substring บนชื่อไฟล์ ลำดับนี้สำคัญเพราะป้องกันกรณีที่ substring ของชื่อไฟล์หนึ่งไปตรงกับชื่อไฟล์อื่นที่ไม่เกี่ยวข้องโดยบังเอิญ — ให้ความแม่นยำสูงสุดก่อนเสมอ
ปฏิเสธเมื่อกำกวม แทนที่จะเดา
ถ้าค้นแบบ partial match แล้วเจอมากกว่า 1 ไฟล์ tool ไม่เดาว่าไฟล์ไหนที่ผู้ใช้หมายถึง แต่คืน error พร้อมรายชื่อไฟล์ที่เข้าเงื่อนไขทั้งหมด (สูงสุด 10 รายการแรก) พร้อมข้อความ “กรุณาระบุชื่อให้ชัดเจนขึ้น” — หลักการ fail-safe เดียวกับที่เห็นใน edit ของ LOCAL AGENT TH ที่ปฏิเสธเมื่อ old_string กำกวม: เมื่อไม่แน่ใจ ให้ถามกลับแทนการเดา เพราะการอ่านไฟล์ผิดตัวส่งผลเสียกว่าการขอความชัดเจนเพิ่ม
ทำไมเรื่องนี้ถึงสำคัญ
read_file ของ RAG แสดงหลักการที่พบซ้ำหลายครั้งในทั้ง 4 ผลิตภัณฑ์: การจับคู่แบบยืดหยุ่นมีประโยชน์ แต่ต้องรู้ขีดจำกัดของตัวเองและปฏิเสธเมื่อผลลัพธ์กำกวมเกินกว่าจะตัดสินใจแทนผู้ใช้ได้อย่างปลอดภัย — ความยืดหยุ่น (รับได้ทั้ง path เต็ม/ชื่อเป๊ะ/ชื่อบางส่วน) กับความปลอดภัย (ปฏิเสธเมื่อกำกวม) ไม่ใช่สิ่งที่ขัดแย้งกัน แต่เป็นการออกแบบที่ให้ทั้งสองอย่างพร้อมกันได้
ความคิดเห็น
กำลังโหลดความคิดเห็น...