Tool Calling และ Structured Outputs: ข้อตกลงที่ยืนอยู่ได้

ก่อนเข้ากลไก ประโยคที่ช่วยลดความสับสนได้มากที่สุดคือ: tool call คือคำขอ ไม่ใช่การกระทำ

โมเดลปล่อยข้อความแบบมีโครงสร้างที่บอกว่า ฉันอยากให้เรียก search_flights ด้วย arguments เหล่านี้ แล้วก็หยุด โค้ดของคุณรับข้อความนั้น ตัดสินใจว่าจะยอมทำตามหรือไม่ เรียกสิ่งที่ต้องเรียก แล้วส่งผลลัพธ์กลับไปเป็นอีกข้อความหนึ่ง โมเดลไม่เคยแตะ database ของคุณ ไม่เคยส่ง HTTP request ไม่เคยมี credentials

ทุกอย่างเกี่ยวกับความปลอดภัยของ agent ใน บทที่ 30 เกิดจากการแบ่งหน้าที่นี้ และทุกอย่างเกี่ยวกับการออกแบบ agent ใน บทที่ 23 ก็เช่นกัน: โมเดลเสนอ ส่วนโค้ดของคุณตัดสินและจัดการ และโค้ดคือที่อยู่ของทุกการรับประกัน

ดังนั้น tool เมื่อถอดคำศัพท์ออกแล้ว มีอยู่สองอย่าง:

ไม่มีส่วนใดของเรื่องนี้เป็น emergent ตามที่ บทที่ 11 วางไว้ tool calling คือ พฤติกรรมที่ผ่านการ train มา:¹ ระหว่าง post-training โมเดลเห็นบทสนทนาหลายพันชุดที่มีรูปร่างแบบนี้พอดี นั่นคือเหตุผลที่ format เฉพาะกับโมเดล เหตุผลที่ความน่าเชื่อถือแตกต่างกันมากระหว่างโมเดลขนาดใกล้เคียงกัน และเหตุผลที่โมเดลสามารถ call tool ที่มันไม่เคยเห็นมาก่อน — รูปร่างถูก train มาแล้ว ส่วน tool เฉพาะมาจาก prompt ของคุณ

นี่คือ tool ในแบบที่คนส่วนใหญ่มักเขียนครั้งแรก สังเกตว่าไม่มีอะไรในนี้ ผิด; มันแค่บางเกินไป:

{
  name: "search_flights",
  description: "Search for flights.",
  parameters: {
    type: "object",
    properties: {
      from: { type: "string", description: "Airport." },   
      to:   { type: "string", description: "Airport." },   
      date: { type: "string", description: "The date." },  
    },
    required: ["from", "to", "date"],
  },
}

คำขอ 24 ครั้ง, city pairs 6 คู่ คูณกับ 4 วิธีในการบอกวันที่ (“วันที่ 3 ของเดือนหน้า”, “ศุกร์หน้า”, “15 ธันวาคม”, “พรุ่งนี้”), ใช้ greedy decoding เพื่อให้ผลลัพธ์ reproduce ได้:

อ่านสองคอลัมน์แรกก่อนสามคอลัมน์ท้าย โมเดลเรียก tool ที่ถูกต้องทุกครั้ง และสร้าง JSON ที่ well-formed ทุกครั้ง ความล้มเหลวอยู่ใน ค่า ทั้งหมด และค่าเหล่านั้นใช้ไม่ได้: "Madrid" แทน MAD, "3rd October 2026" แทน 2026-10-03

เรื่องนี้ควรย้ำ เพราะมันกำหนดว่าคุณควรมองหาตรงไหนเมื่อบางอย่างพัง สัญชาตญาณคือเพิ่ม JSON parser พร้อม retry หรือขอให้โมเดลสร้าง JSON ที่ถูกต้องอย่างหนักแน่นขึ้น ไม่มีอย่างไหนแก้สิ่งที่เกิดขึ้นตรงนี้

endpoint เดิม โค้ดเบื้องหลังเดิม โมเดลเดิม prompts เดิม decoding เดิม สิ่งเดียวที่เปลี่ยนคือข้อความใน schema:

{
  name: "search_flights",
  description: "Search scheduled flights between two airports on a given day.",
  parameters: {
    type: "object",
    properties: {
      from: {
        type: "string",
        description: "Departure airport as a three-letter IATA code, e.g. MAD for Madrid. Never a city name.",   
        pattern: "^[A-Z]{3}$",
      },
      to: { /* same */ },
      date: {
        type: "string",
        description: "Departure date as an ISO 8601 calendar date, YYYY-MM-DD. Resolve relative dates against today before calling.",   
        format: "date",
        pattern: "^\\d{4}-\\d{2}-\\d{2}$",
      },
    },
    required: ["from", "to", "date"],
  },
}

รูปแบบวันที่ขยับจาก 2 ใน 24 เป็น 24 ใน 24 สมบูรณ์แบบ จากการเปลี่ยนข้อความ โดยไม่แตะโค้ดและไม่มี retry logic ถ้าจะเอานิสัยเชิงปฏิบัติสักข้อจากบทนี้ ก็คือข้อนี้: เมื่อ tool ถูก call ผิด วิธีแก้มักอยู่ใน description แทบทุกครั้ง และเป็นวิธีแก้ที่ถูกที่สุดในระบบ

ตอนนี้อ่านคอลัมน์ที่สอง ซึ่งเป็นครึ่งที่สำคัญกว่า

วันที่อยู่ใน format ISO 24 ครั้งจาก 24 ครั้ง แต่มันเป็น วันที่ถูกต้อง 12 ครั้งจาก 24 ครั้ง

ดังนั้นครึ่งหนึ่งของ calls ตอนนี้พกวันที่ที่ format สมบูรณ์แบบ แต่เป็นวันที่ผิด description บอกโมเดลว่าต้องผลิต shape แบบไหน และโมเดลก็ผลิตออกมาได้อย่างไร้ที่ติ — แต่การแปลง “ศุกร์หน้า” เป็น 2026-09-11 ต้องรู้ว่าวันนี้คือวันอะไรและต้องคำนวณปฏิทิน ซึ่งไม่มี description ปริมาณเท่าใดเติมสิ่งนั้นให้ได้ เรื่องสนามบินก็เหมือนกัน: format ขยับจาก 4 เป็น 16 แต่ value ขยับแค่จาก 4 เป็น 8 เพราะการเขียน MAD ต้องรู้ว่าสนามบินของ Madrid คือ MAD

ความแตกต่างนี้คือแนวคิดรับน้ำหนักของบทนี้:

schema คือ ข้อตกลงเรื่อง form มันทำให้ output ของโมเดล parse ได้ มี type และสม่ำเสมอได้ แต่มันทำให้สิ่งนั้น จริง ไม่ได้ และ failure mode ทุกแบบที่ยังเหลือหลังมี schema ที่ดี คือความล้มเหลวด้านความรู้ ไม่ใช่ความล้มเหลวด้าน format

สองอย่างนี้ต้องแก้คนละแบบ และการสับสนระหว่างมันทำให้เสียเวลาเป็นสัปดาห์ ความล้มเหลวด้าน format แก้ใน description หรือด้วย constrained decoding ด้านล่าง ความล้มเหลวด้านความรู้แก้ด้วยการ ใส่ความรู้นั้นใน prompt — วันที่ปัจจุบันใน system message, airport lookup เป็น tool ตัวที่สอง ที่โมเดล call ก่อน, enum ใน schema เมื่อชุดข้อมูลเล็กพอจะแจกแจงได้ สังเกตว่าสามอย่างนี้มีอะไรเหมือนกัน: มันย้ายปัญหาออกจากหน่วยความจำของโมเดลและเข้าไปอยู่ใน input ของมัน ซึ่งคือใจความทั้งหมดของ บทที่ 24

ทุกอย่างข้างต้นยังพึ่งให้โมเดล เลือก สร้าง shape ที่ถูกต้อง ยังมีการรับประกันที่แข็งแรงกว่านั้น และมันคือผลตอบแทนที่ดีที่สุดของ บทที่ 17

ทวนวิธีที่ generation ทำงาน: ในทุก step โมเดลสร้าง logit สำหรับทุก token ใน vocabulary และ sampler เลือกหนึ่งตัว Constrained decoding แทรกขั้นตอนหนึ่งไว้ตรงกลาง เมื่อมี grammar — ที่ derive จาก JSON Schema ของคุณ — มันคำนวณว่า tokens ไหนตามมาได้อย่างถูกกฎหมาย ตั้ง logits ของตัวอื่นทั้งหมดเป็นลบอนันต์ แล้วปล่อยให้ sampler เลือกจากสิ่งที่เหลือ

ถ้า schema บอกว่าสิ่งถัดไปต้องเป็น { ดังนั้นทุก token ที่ไม่ใช่ { จะมีความน่าจะเป็นเป็นศูนย์ ไม่ใช่ “ไม่น่าเป็นไปได้”: แต่เป็นศูนย์ โมเดลไม่สามารถ emit JSON ที่ invalid ได้ เพราะ tokens ที่ invalid ถูกเอาออกจาก distribution ก่อน sampling แล้ว

นั่นคือสิ่งที่อยู่ใต้ “structured outputs”, “JSON mode” และ “guided generation” และมันอธิบายคุณสมบัติสองข้อของมัน การรับประกันเป็นแบบ ทั้งหมด สำหรับสิ่งที่ grammar แสดงออกได้ — types, required fields, enums, nesting — เพราะมันถูก enforce เชิงกลไก ไม่ใช่ร้องขออย่างสุภาพ และมันไม่ได้บอก อะไรเกี่ยวกับ content เลย: grammar บังคับให้ "date" เป็น string ที่ตรงกับ date pattern ได้ แต่บังคับให้เป็นวันที่ถูกต้องไม่ได้ ซึ่งก็คือกำแพงเดียวกับส่วนก่อนหน้า เพียงมาถึงจากอีกฝั่งหนึ่ง

หมายเหตุเชิงปฏิบัติสองข้อ มันไม่ฟรี: mask ต้องถูกคำนวณในทุก step และ grammars ที่ซับซ้อนมีต้นทุน latency ที่วัดได้ และมันเปลี่ยนสิ่งที่โมเดลกำลังทำ — โมเดลที่ถูกพาออกจาก token ที่มันชอบอาจสร้าง content แย่ลง แม้จะสร้าง structure สมบูรณ์แบบ นั่นคือเหตุผลที่ “ขออย่างสุภาพแล้ว validate” ยังเป็นค่าเริ่มต้นที่สมเหตุสมผลสำหรับ shape ง่าย ๆ และ constrained decoding คุ้มต้นทุนเมื่อ shape ซับซ้อนหรือ consumer เข้มงวด

บทที่ 14 วัดกรณี timeout ตามด้วย retry ที่คิดเงินสอง generations สำหรับคำตอบเดียว เมื่อมี tools ความล้มเหลวเดียวกันแย่ลง เพราะ tool สามารถ ทำ บางอย่างได้

ถ้าโค้ดของคุณ call charge_card, timeout, แล้ว retry คุณมี charges สองรายการ โมเดลไม่รู้เลยว่าสิ่งเหล่านี้เกิดขึ้น มันเห็น tool result หนึ่งรายการ วิธีแก้เหมือนใน distributed system ใด ๆ และไม่ใช่ปัญหาของโมเดล: ทำให้ operation idempotent โดยให้ call มี key เพื่อให้การ execute ครั้งที่สองจำครั้งแรกได้และคืนผลลัพธ์ของครั้งแรกแทนที่จะทำงานซ้ำ

กฎการออกแบบที่ตามมาควรพูดให้ชัด แยก reads ออกจาก writes ใน tool catalogue ของคุณ read สามารถ retry ได้อย่างอิสระ run แบบ parallel ได้ และ cache ได้ write ทำแบบนั้นไม่ได้ และควรมี key, permission check และ — สำหรับอะไรก็ตามที่ผู้ใช้ควรรู้ก่อนมันเกิดขึ้น — ขั้นตอน approval ที่วางมนุษย์ไว้ระหว่างคำขอกับการกระทำ ขั้นตอน approval นั้นไม่ใช่มารยาท: มันเป็นหนึ่งในไม่กี่สิ่งที่ยืนคั่นระหว่าง prompt injection กับผลลัพธ์จริง — และบทที่ 30 วัดแล้วว่ามันเป็นหนึ่งในจุดที่อ่อนที่สุด

คำเล่าต่อกันมาบอกว่าการโหลด tools จำนวนมากทำให้โมเดลเลือกพลาด ควรวัดแทนที่จะท่องซ้ำ ดังนั้น: คำขอ 24 ครั้งเดิม ด้วย flight tool บวกกับชุด tools อื่นที่เพิ่มขึ้นเรื่อย ๆ — รวมถึงสามตัวที่ตั้งใจให้สับสนได้ง่าย (ตารางรถไฟ, ferry crossings, เส้นทางรถบัส)

การเลือกไม่ได้แย่ลง เมื่อมี tools 20 ตัว โดย 3 ตัวในนั้นสับสนกันได้อย่างสมเหตุสมผล โมเดลขนาดครึ่งพันล้านพารามิเตอร์เลือกตัวถูก 24 ครั้งจาก 24 ครั้ง จุดตกที่ 10 คือ calls สามครั้งที่ตั้งชื่อ tool อื่น และมันไม่คงอยู่เมื่อเพิ่มเป็น 20

นี่คือผลลัพธ์เชิงลบ และควรรายงานแบบนั้น: ในงานนี้ ด้วย tools เหล่านี้ “tools มากเกินไป” ไม่ใช่ปัญหา สิ่งที่โตขึ้นอย่างสม่ำเสมอและเพิ่มขึ้น 6 เท่าคือ prompt: จาก 353 tokens เป็น 2,119 tokens ที่ต้องจ่ายในทุก request ของบทสนทนา ตลอดไป ไม่ว่าจะใช้ tool หรือไม่ก็ตาม

ดังนั้นเวอร์ชันที่ซื่อสัตย์ของคำเล่าต่อกันมาคือเรื่อง cost และ context ไม่ใช่ accuracy tools 20 ตัวคือภาษีถาวรบนทุกข้อความ และ บทที่ 16 ก็แสดงแล้วว่า prefix ถาวรทำอะไรกับบิลตลอด 40 turns เมื่อผู้คนรายงานว่า tools จำนวนมากทำให้คุณภาพลดลง กลไกมักเป็นเพราะ definitions เบียด context ที่สำคัญออกไป — ซึ่งเป็นปัญหาของบทที่ 24 ที่ใส่ชุดของบทที่ 18 อยู่ tools ที่เกือบซ้ำกันจริง ๆ ก็เป็นปัญหาจริงเช่นกัน และวิธีแก้ไม่ใช่ tools น้อยลง แต่เป็น descriptions และ namespaces ที่ดีกว่า: ใส่ prefix ตามระบบ (crm.search_customer, billing.search_customer) เพื่อให้ catalogues สองชุดที่ merge มาจากสองทีมไม่ชนกัน และเพื่อให้โมเดลมีบางอย่างไว้แยกแยะ

การจัด tools ตามสิ่งที่มันทำกับโลกช่วยได้ เพราะวิศวกรรมของแต่ละชนิดต่างกัน

Data tools อ่าน: search, fetch, query Retry ได้, parallelise ได้, cache ได้ มันล้มเหลวด้วยการไม่คืนสิ่งที่มีประโยชน์ และความเสี่ยงหลักคือมันพาข้อความที่ไม่น่าเชื่อถือเข้ามาใน context — ซึ่งคือพื้นที่โจมตีทั้งหมดของบทที่ 30

Action tools เขียน: send, create, charge, delete ไม่สามารถ retry ได้โดยไม่มี key, parallelise อย่างปลอดภัยไม่ได้ และเป็นเหตุผลที่ approval flows มีอยู่

Orchestration tools call โมเดลอื่น tool ที่ implementation เป็น agent อีกตัวหนึ่ง พร้อม prompt ของตัวเอง, tools ของตัวเอง และ loop ของตัวเอง — และสำหรับโมเดลที่เป็น caller มันดูเหมือนอีกสองชนิดทุกประการ เพราะ schema กับ endpoint คือทั้งหมดที่มันเคยเห็น

ชนิดที่สามไม่ใช่เรื่องแปลกเล่น ๆ มันคือกลไกเบื้องหลังครึ่ง agent-as-a-tool ของ บทที่ 25 — topology อีกแบบคือ handoff ที่ส่งบทสนทนาออกไปแล้วไม่ได้คืน — และมันทำงานได้พอดีเพราะ interface ในบทนี้แคบพอให้ agent ทั้งตัวซ่อนอยู่ข้างหลังได้

ตอนนี้คุณมีโมเดลที่ขอสิ่งต่าง ๆ ได้ และมีข้อตกลงที่ทำให้การขอนั้น parse ได้ สิ่งที่คุณยังไม่มีคืออะไรให้มันถาม เกี่ยวกับ นอกเหนือจากสิ่งที่ใส่ใน prompt ได้

tool ที่พบบ่อยที่สุดใน production แบบทิ้งห่าง คือการค้นหาบนชุดข้อความที่โมเดลไม่เคยเห็นระหว่าง training: เอกสารของคุณ, tickets ของคุณ, contracts ของคุณ ฟังดูเหมือนปัญหาที่แก้แล้ว — embed มัน หา nearest neighbours แล้ว paste เข้าไป — แต่ส่วนที่ยังไม่ถูกแก้คือส่วนที่ตัดสินว่าคำตอบน่าเชื่อถือหรือไม่: ข้อความถูกตัดอย่างไรก่อนถูก embedded, similarity threshold ต่ำแค่ไหนจึงแปลว่า ฉันไม่รู้, และ citation ถูก attach กับ claim อย่างไรเพื่อให้ผู้อ่านตรวจสอบได้

บทที่ 19 คือ retrieval และเป็นบทที่คำตอบผิดหยุดเป็นเรื่องน่าสนใจเฉย ๆ แล้วเริ่มเป็น liability

การวัดในบทนี้มาจาก Qwen/Qwen2.5-0.5B-Instruct ด้วย greedy decoding บน generated requests 24 รายการที่ข้าม city pairs 6 คู่กับ phrasing ของวันที่ 4 แบบ โดยใช้ chat template ของโมเดลเองสำหรับ tool definitions ผลลัพธ์ reproduce ได้เป๊ะ และเป็นโมเดลขนาดเล็ก: อ่านการแยก format/value เป็นการสาธิตกลไก มากกว่าเป็น benchmark ว่าโมเดลปัจจุบันทำอะไรได้ โมเดล frontier แก้ “ศุกร์หน้า” ได้ถูกต้องบ่อยกว่ามาก — และก็ยังไม่สามารถถูก บังคับ ให้ทำเช่นนั้นด้วย schema ได้ ซึ่งเป็นส่วนที่ generalise

JSON Schema vocabulary ที่ใช้ข้างต้น (type, properties, required, pattern, format, enum) ถูกระบุใน JSON Schema draft ที่ documentation ของ provider ของคุณอ้างถึง subset ที่มีประโยชน์มีขนาดเล็กและเหมือนกันข้าม providers และความแตกต่างที่มีอยู่ — keywords ไหนถูก enforce โดย constrained decoding แทนที่จะถูกส่งผ่านไปให้โมเดลเฉย ๆ — ควรอ่านจาก structured-output guide ของ provider มากกว่าจะ assume เอาเอง

สำหรับ constrained decoding ในฐานะเทคนิค libraries แนว guidance และโปรเจกต์ outlines document การสร้าง grammar-to-logit-mask ในแบบที่ map ตรงกับ sampler ของบทที่ 17 และสำหรับ round trip เอง specification ที่ชัดที่สุดไม่ใช่ tutorial แต่เป็น protocol: บทที่ 26 อ่านมันทีละบรรทัด