Tools — มือของโมเดล

ในบทที่แล้วเราพบว่าผู้ช่วย เดา ว่าห้องว่าง บทนี้คือการให้ “มือ” กับมัน — เครื่องมือที่ไป ดึงการจองจริง แทนการเดา และจุดที่วิศวกรหลายคนพลาด: ชื่อและคำอธิบายของเครื่องมือ ไม่ใช่เอกสารสำหรับมนุษย์ แต่เป็น “คำสั่ง” ที่โมเดลอ่านเพื่อตัดสินใจ ส่วนข้อความ error คือ โอกาสเดียวที่มันจะแก้ตัวในรอบถัดไป

พูดแบบเข้าใจง่าย

Tool คือความสามารถหนึ่งอย่างที่เรายื่นให้โมเดล — เหมือนปุ่มที่มีป้ายกำกับหนึ่งปุ่ม โมเดลไม่เคยเห็นโค้ดข้างในเลย มันเห็นแค่ สามสตริง: ชื่อ (name), คำอธิบาย (description), และ ผลลัพธ์/ข้อผิดพลาด (error) หลังเรียก — และสามสตริงนี้ คือ prompt

• คำอธิบาย คือสิ่งที่โมเดลใช้ “เลือก” ว่าจะเรียกเครื่องมือไหน จึงต้องบอกทั้ง ทำอะไร และ เมื่อไรควร/ไม่ควรใช้
• ข้อความ error คือโอกาสเดียวให้มันแก้เองรอบหน้า — “ใส่ confirmed=true แล้วเรียกใหม่” ดีกว่าโยน exception ดิบ ๆ
• ทุกเครื่องมือที่เพิ่มยัง กินพื้นที่ context ด้วย คำถามจึงไม่ใช่ “เพิ่ม tool นี้ได้ไหม” แต่คือ “มันคมพอจะคุ้มพื้นที่ไหม”

ในระบบของเรา — คำอธิบายคือสิ่งที่ขับการเลือกเครื่องมือ

เมื่อมีคนถามว่า “ห้องว่างไหม” ผู้ช่วยไม่ได้สุ่มเครื่องมือ — มัน อ่านคำอธิบายของแต่ละตัวแล้วเลือก:

ในระบบจริงของเรามีเครื่องมือหลายตัวที่โค้ดข้างในแทบเหมือนกัน — สิ่งที่แยกแยะมันคือ ภาษาในคำอธิบาย เช่นใส่ประโยคสั่งว่า “เป็นค่าเริ่มต้นเมื่อผู้ใช้พูดแค่คำว่า ‘อาคาร’ โดยไม่ระบุชื่อ” หรือ “ใช้เฉพาะเมื่อถาม EN6 ตรง ๆ” และเรายังทำ เครื่องมือแบบรวบยอด (สรุปข้อมูลนักศึกษาใน “หนึ่งครั้ง” แทนที่จะเรียกย่อย 3 รอบ) — ความคุ้มถูกโฆษณาไว้ในคำอธิบายเอง โมเดลจึงเลือกมันก่อน

ทำพลาด vs ทำถูก

ลองเอง — แก้คำอธิบาย แล้วดูโมเดลเปลี่ยนใจ

สรุปบทที่ 04

• โมเดลเห็นเครื่องมือเป็น สามสตริง: name · description · error — ทั้งหมดคือ prompt
• คำอธิบายขับการเลือก — ประโยคสั่งคมกว่าและเร็วกว่าการเปลี่ยนชื่อหรือแก้โค้ด
• error ที่ดีต้องบอกวิธีแก้ ไม่งั้นโมเดลวนซ้ำที่เดิม
• เครื่องมือ น้อยแต่คม ชนะเครื่องมือเยอะแต่กำกวม — ตัวซ้ำให้ “ปิด ไม่ใช่ลบ”