แยก tool ที่หน้าที่ทับซ้อนกันด้วยชื่อและคำอธิบาย
แนวคิด
ปัญหาที่พบบ่อยกว่า description สั้น คือ tool สองตัวที่คำอธิบายคลุมเครือหรือทับซ้อนกันจนโมเดลแยกไม่ออกว่าจะเรียกตัวไหน ตัวอย่างคลาสสิกคือ analyze_content กับ analyze_document ที่เขียนคำอธิบายเกือบเหมือนกัน เมื่อคำถามเข้ามา โมเดลมีสองประตูที่ดูเหมือนกัน จึงเกิดการ misrouting คือเรียกผิดตัว
ทางแก้มีสองมือที่ใช้คู่กัน มือแรกคือเปลี่ยนชื่อให้สื่อความต่างชัด เช่น เปลี่ยน analyze_content เป็น extract_web_results เพื่อบอกว่ามันเจาะจงกับเนื้อหาจากเว็บ มือที่สองคือเสริมคำอธิบายของแต่ละตัวให้ระบุ "เมื่อไรควรใช้ตัวนี้แทนตัวที่คล้ายกัน" อย่างชัดเจน การมี boundary ที่เขียนออกมาเป็นตัวหนังสือช่วยให้โมเดลตัดสินได้โดยไม่ต้องเดา
ทำไมสำคัญ
พิจารณา Sample Question ข้อ 2 จาก exam guide ระบบซัพพอร์ตลูกค้ามี tool สองตัว คือ get_customer และ lookup_order ทั้งคู่มีคำอธิบายน้อยมาก คือ "Retrieves customer information" กับ "Retrieves order details" และรับ identifier รูปแบบใกล้เคียงกัน production log แสดงว่าเมื่อผู้ใช้ถามเรื่องออเดอร์ เช่น "check my order #12345" โมเดลกลับเรียก get_customer บ่อยครั้งแทนที่จะเป็น lookup_order
คำถามคือขั้นแรกที่ได้ผลที่สุดในการปรับปรุงความน่าเชื่อถือของการเลือก tool คืออะไร คำตอบที่ถูกคือขยายคำอธิบายของแต่ละ tool ให้ระบุรูปแบบ input ที่รับ ตัวอย่างคำถาม edge case และขอบเขตว่าเมื่อไรใช้ตัวนี้แทนตัวที่คล้ายกัน เพราะ tool description คือกลไกหลักที่โมเดลใช้เลือก และตอนนี้มันน้อยเกินไปจนโมเดลขาดบริบทที่จะแยกสอง tool ออกจากกัน
ตัวเลือกอื่นแก้ไม่ตรงจุด การเติม few-shot example ห้าถึงแปดตัวเพิ่มโทเคนแต่ไม่แก้รากของปัญหา การสร้าง routing layer ที่ parse keyword ก่อนทุกเทิร์นเป็นการ over-engineer และข้ามความสามารถด้านภาษาธรรมชาติของโมเดลไป ส่วนการยุบสอง tool เป็น lookup_entity ตัวเดียวเป็นทางเลือกเชิงสถาปัตยกรรมที่ถูกต้องได้ แต่ลงแรงมากเกินกว่าจะเป็น "ขั้นแรก" เมื่อปัญหาเฉพาะหน้าคือคำอธิบายไม่พอ
ตัวอย่าง
// ก่อน — คลุมเครือ ทับซ้อน
{ "name": "get_customer", "description": "Retrieves customer information" }
{ "name": "lookup_order", "description": "Retrieves order details" }
// หลัง — ชื่อและ boundary ชัด
{ "name": "get_customer_by_id",
"description": "Look up a customer profile by verified customer ID (format: CUST-xxxxx). Use for account, contact, or billing questions. Do NOT use for order lookups — use lookup_order_by_number for anything with an order number." }
{ "name": "lookup_order_by_number",
"description": "Retrieve one order by its order number (format: #12345). Use whenever the user references an order, shipment, or refund by number, even if they also mention their name." }
เช็คความเข้าใจ
ใน Sample Q2 เพราะอะไรโมเดลจึงเรียก get_customer ทั้งที่ผู้ใช้ถามเรื่องออเดอร์ และแก้อย่างไรเป็นขั้นแรก
สองมือที่ใช้คู่กันเพื่อลบความทับซ้อนของ tool คืออะไร