Tool Calling και Structured Outputs: η σύμβαση που κρατάει

Πριν από τους μηχανισμούς, η πρόταση που αποτρέπει τη μεγαλύτερη σύγχυση: ένα tool call είναι request, όχι ενέργεια.

Το μοντέλο εκπέμπει ένα δομημένο μήνυμα που λέει θα ήθελα να κληθεί το search_flights με αυτά τα arguments. Μετά σταματά. Ο κώδικάς σας λαμβάνει αυτό το μήνυμα, αποφασίζει αν θα το τιμήσει, καλεί ό,τι είναι να καλέσει και στέλνει το αποτέλεσμα πίσω ως άλλο μήνυμα. Το μοντέλο δεν άγγιξε ποτέ τη βάση δεδομένων σας, δεν έκανε ποτέ HTTP request, δεν είχε ποτέ credentials.

Όλα σχετικά με την ασφάλεια των agent στο Κεφάλαιο 30 προκύπτουν από αυτόν τον διαχωρισμό, όπως και όλα σχετικά με τον σχεδιασμό agent στο Κεφάλαιο 23: το μοντέλο προτείνει και ο κώδικάς σας αποφασίζει, και ο κώδικας είναι το σημείο όπου ζει κάθε εγγύηση.

Άρα ένα εργαλείο, χωρίς ορολογία, είναι δύο πράγματα:

Τίποτα από αυτά δεν είναι emergent. Όπως έδειξε το Κεφάλαιο 11, το tool calling είναι εκπαιδευμένη συμπεριφορά:¹ κατά το post-training το μοντέλο είδε χιλιάδες συζητήσεις με ακριβώς αυτό το σχήμα. Γι’ αυτό το format είναι συγκεκριμένο ανά μοντέλο, γι’ αυτό η αξιοπιστία διαφέρει τόσο πολύ ανάμεσα σε μοντέλα παρόμοιου μεγέθους, και γι’ αυτό ένα μοντέλο μπορεί να καλέσει ένα εργαλείο που δεν έχει ξαναδεί — το σχήμα εκπαιδεύτηκε, το συγκεκριμένο εργαλείο έρχεται από το prompt σας.

Να το εργαλείο όπως το γράφουν οι περισσότεροι στην αρχή. Προσέξτε ότι τίποτα σε αυτό δεν είναι λάθος· είναι απλώς λεπτό:

{
  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"],
  },
}

Είκοσι τέσσερα requests, έξι ζεύγη πόλεων διασταυρωμένα με τέσσερις τρόπους έκφρασης ημερομηνίας («στις 3 του επόμενου μήνα», «την επόμενη Παρασκευή», «15 Δεκεμβρίου», «αύριο»), greedy decoding ώστε τα αποτελέσματα να αναπαράγονται:

Διαβάστε τις δύο πρώτες στήλες πριν από τις τελευταίες τρεις. Το μοντέλο καλεί το σωστό εργαλείο κάθε φορά και παράγει καλοσχηματισμένο JSON κάθε φορά. Η αποτυχία βρίσκεται εξ ολοκλήρου στις τιμές, και οι τιμές είναι άχρηστες: "Madrid" αντί για MAD, "3rd October 2026" αντί για 2026-10-03.

Αξίζει να επιμείνουμε σε αυτό, γιατί καθορίζει πού κοιτάτε όταν κάτι σπάει. Το ένστικτο είναι να προσθέσετε έναν JSON parser με retry, ή να ζητήσετε από το μοντέλο πιο αυστηρά έγκυρο JSON. Κανένα από τα δύο δεν αντιμετωπίζει κάτι που συνέβη εδώ.

Ίδιο endpoint. Ίδιος κώδικας πίσω του. Ίδιο μοντέλο, ίδια prompts, ίδιο decoding. Το μόνο που αλλάζει είναι το κείμενο στο σχήμα:

{
  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"],
  },
}

Το format της ημερομηνίας πηγαίνει από 2 στα 24 σε 24 στα 24. Τέλειο, από μια αλλαγή κειμένου, χωρίς να αγγιχτεί κώδικας και χωρίς retry logic. Αν κρατήσετε μία επιχειρησιακή συνήθεια από αυτό το κεφάλαιο, είναι αυτή: όταν ένα εργαλείο καλείται λάθος, η διόρθωση βρίσκεται σχεδόν πάντα στην περιγραφή, και είναι η φθηνότερη διόρθωση στο σύστημα.

Τώρα διαβάστε τη δεύτερη στήλη, που είναι το πιο σημαντικό μισό.

Η ημερομηνία είναι σε ISO format 24 στις 24 φορές. Είναι η σωστή ημέρα 12 στις 24 φορές.

Άρα οι μισές calls μεταφέρουν τώρα μια τέλεια μορφοποιημένη ημερομηνία που είναι λάθος ημερομηνία. Η περιγραφή είπε στο μοντέλο ποιο σχήμα να παράγει, και το μοντέλο το παρήγαγε άψογα — αλλά το να μετατρέψει το «επόμενη Παρασκευή» σε 2026-09-11 απαιτεί να ξέρει τη σημερινή ημερομηνία και να κάνει αριθμητική ημερολογίου, και καμία ποσότητα περιγραφής δεν το παρέχει αυτό. Το ίδιο ισχύει για τα αεροδρόμια: το format πήγε από 4 σε 16, αλλά η τιμή μόνο από 4 σε 8, επειδή το να γράψει MAD απαιτεί να ξέρει ότι το αεροδρόμιο της Μαδρίτης είναι MAD.

Αυτή η διάκριση είναι η βασική ιδέα του κεφαλαίου:

Ένα σχήμα είναι μια σύμβαση για τη μορφή. Μπορεί να κάνει την έξοδο του μοντέλου parseable, typed και συνεπή. Δεν μπορεί να την κάνει αληθινή, και κάθε failure mode που επιβιώνει από ένα καλό σχήμα είναι αποτυχία γνώσης, όχι αποτυχία format.

Τα δύο χρειάζονται διαφορετικές διορθώσεις, και το να τα μπερδεύετε σπαταλά εβδομάδες. Οι αποτυχίες format διορθώνονται στην περιγραφή ή με constrained decoding, παρακάτω. Οι αποτυχίες γνώσης διορθώνονται βάζοντας τη γνώση στο prompt — τη σημερινή ημερομηνία στο system message, μια αναζήτηση αεροδρομίου ως δεύτερο εργαλείο που το μοντέλο καλεί πρώτο, ένα enum στο σχήμα όταν το σύνολο είναι αρκετά μικρό για να απαριθμηθεί. Προσέξτε τι κοινό έχουν και τα τρία: μετακινούν το πρόβλημα έξω από τη μνήμη του μοντέλου και μέσα στο input του, που είναι ολόκληρο το Κεφάλαιο 24.

Όλα τα παραπάνω εξακολουθούν να βασίζονται στο ότι το μοντέλο επιλέγει να παράγει το σωστό σχήμα. Υπάρχει διαθέσιμη μια ισχυρότερη εγγύηση, και είναι η καλύτερη απόδοση του Κεφαλαίου 17.

Θυμηθείτε πώς λειτουργεί η παραγωγή: σε κάθε βήμα το μοντέλο παράγει ένα logit για κάθε token στο λεξιλόγιο, και ο sampler επιλέγει ένα. Το constrained decoding εισάγει ένα βήμα ανάμεσα. Με δεδομένη μια γραμματική — που προκύπτει από το JSON Schema σας — υπολογίζει ποια tokens θα μπορούσαν νόμιμα να έρθουν στη συνέχεια, θέτει τα logits όλων των άλλων στο αρνητικό άπειρο, και αφήνει τον sampler να επιλέξει από ό,τι απομένει.

Αν το σχήμα λέει ότι το επόμενο πράγμα πρέπει να είναι {, τότε κάθε token που δεν είναι { έχει πιθανότητα μηδέν. Όχι «απίθανο»: μηδέν. Το μοντέλο δεν μπορεί να εκπέμψει invalid JSON επειδή τα invalid tokens αφαιρέθηκαν από την κατανομή πριν από τη δειγματοληψία.

Αυτό είναι που βρίσκονται από κάτω τα «structured outputs», «JSON mode» και «guided generation», και εξηγεί τις δύο ιδιότητές τους. Η εγγύηση είναι ολική για οτιδήποτε μπορεί να εκφράσει η γραμματική — τύπους, απαιτούμενα πεδία, enums, nesting — επειδή επιβάλλεται μηχανικά αντί να ζητείται ευγενικά. Και δεν λέει τίποτα για το περιεχόμενο: μια γραμματική μπορεί να αναγκάσει το "date" να είναι string που ταιριάζει με μοτίβο ημερομηνίας, και δεν μπορεί να το αναγκάσει να είναι η σωστή ημέρα. Που είναι ο ίδιος τοίχος με την προηγούμενη ενότητα, από την άλλη πλευρά.

Δύο πρακτικές σημειώσεις. Δεν είναι δωρεάν: η μάσκα πρέπει να υπολογίζεται σε κάθε βήμα, και οι σύνθετες γραμματικές κοστίζουν μετρήσιμο latency. Και αλλάζει αυτό που κάνει το μοντέλο — ένα μοντέλο που απομακρύνεται από το preferred token του μπορεί να παράγει χειρότερο περιεχόμενο ενώ παράγει τέλεια δομή, γι’ αυτό το «ζήτησέ το ευγενικά και κάνε validate» παραμένει μια λογική προεπιλογή για απλά σχήματα, ενώ το constrained decoding αξίζει το κόστος του όταν το σχήμα είναι σύνθετο ή ο καταναλωτής είναι αυστηρός.

Το Κεφάλαιο 14 μέτρησε ένα timeout ακολουθούμενο από retry που χρέωσε δύο generations για μία απάντηση. Με εργαλεία η ίδια αποτυχία χειροτερεύει, επειδή ένα εργαλείο μπορεί να κάνει κάτι.

Αν ο κώδικάς σας καλέσει το charge_card, κάνει timeout και δοκιμάσει ξανά, έχετε δύο χρεώσεις. Το μοντέλο δεν έχει ιδέα ότι συνέβη κάτι από αυτά· βλέπει ένα αποτέλεσμα εργαλείου. Η διόρθωση είναι η ίδια όπως σε κάθε distributed system και δεν είναι πρόβλημα του μοντέλου: κάντε την πράξη idempotent δίνοντας στο call ένα κλειδί, ώστε η δεύτερη εκτέλεση να αναγνωρίζει την πρώτη και να επιστρέφει το αποτέλεσμά της αντί να κάνει ξανά τη δουλειά.

Ο κανόνας σχεδιασμού που ακολουθεί αξίζει να ειπωθεί καθαρά. Διαχωρίστε τα reads από τα writes στον κατάλογο εργαλείων σας. Ένα read μπορεί να γίνει retry ελεύθερα, να τρέξει παράλληλα και να γίνει cached. Ένα write δεν μπορεί, και πρέπει να φέρει κλειδί, έλεγχο permission και — για οτιδήποτε θα ήθελε να γνωρίζει ο χρήστης πριν συμβεί — ένα βήμα approval που βάζει άνθρωπο ανάμεσα στο request και την ενέργεια. Αυτό το βήμα approval δεν είναι ευγένεια: είναι ένα από τα λίγα πράγματα που στέκονται ανάμεσα σε ένα prompt injection και μια πραγματική συνέπεια — και, όπως μετρά το Κεφάλαιο 30, το πιο αδύναμο από αυτά.

Η λαϊκή σοφία λέει ότι η φόρτωση πολλών εργαλείων κάνει το μοντέλο να επιλέγει λάθος. Αξίζει να το μετρήσουμε αντί να το επαναλαμβάνουμε, οπότε: τα ίδια είκοσι τέσσερα requests, με το εργαλείο πτήσεων συν ένα αυξανόμενο σύνολο άλλων — συμπεριλαμβανομένων τριών σκόπιμα μπερδεμένων μεταξύ τους (δρομολόγια τρένων, ακτοπλοϊκές συνδέσεις, διαδρομές λεωφορείων).

Η επιλογή δεν υποβαθμίστηκε. Με είκοσι εργαλεία, τρία από αυτά εύλογα μπερδεύσιμα, ένα μοντέλο μισού δισεκατομμυρίου parameters διάλεξε το σωστό είκοσι τέσσερις φορές στις είκοσι τέσσερις. Η πτώση στα δέκα είναι τρία calls που ονόμασαν διαφορετικό εργαλείο, και δεν επιβιώνει όταν πάμε στα είκοσι.

Αυτό είναι αρνητικό αποτέλεσμα και πρέπει να αναφερθεί ως τέτοιο: σε αυτή την εργασία, με αυτά τα εργαλεία, το «πάρα πολλά εργαλεία» δεν ήταν το πρόβλημα. Αυτό που όντως αυξήθηκε, μονότονα και κατά παράγοντα έξι, είναι το prompt: από 353 tokens σε 2.119, πληρωμένα σε κάθε request της συζήτησης, για πάντα, είτε χρησιμοποιηθεί κάποιο εργαλείο είτε όχι.

Άρα η ειλικρινής εκδοχή της λαϊκής σοφίας αφορά κόστος και context, όχι ακρίβεια. Είκοσι εργαλεία είναι μόνιμος φόρος σε κάθε μήνυμα, και το Κεφάλαιο 16 έχει ήδη δείξει τι κάνει ένας μόνιμος prefix σε έναν λογαριασμό μέσα σε σαράντα turns. Όταν οι άνθρωποι αναφέρουν ότι πολλά εργαλεία βλάπτουν την ποιότητα, ο μηχανισμός είναι συνήθως ότι οι ορισμοί εκτόπισαν το context που είχε σημασία — ένα πρόβλημα του Κεφαλαίου 24 που φορά κοστούμι Κεφαλαίου 18. Εργαλεία που είναι πραγματικά σχεδόν διπλότυπα μεταξύ τους είναι επίσης πραγματικό πρόβλημα, και η διόρθωση γι’ αυτά δεν είναι λιγότερα εργαλεία αλλά καλύτερες περιγραφές και namespaces: προσθέστε prefix ανά σύστημα (crm.search_customer, billing.search_customer), ώστε δύο κατάλογοι που συγχωνεύονται από δύο ομάδες να μη συγκρούονται, και ώστε το μοντέλο να έχει κάτι για να διακρίνει.

Βοηθά να ταξινομείτε τα εργαλεία με βάση το τι κάνουν στον κόσμο, επειδή το engineering διαφέρει για το καθένα.

Data tools διαβάζουν: search, fetch, query. Retryable, parallelisable, cacheable. Αποτυγχάνουν επιστρέφοντας τίποτα χρήσιμο, και ο κύριος κίνδυνός τους είναι ότι φέρνουν μη αξιόπιστο κείμενο μέσα στο context — που είναι ολόκληρη η επιφάνεια επίθεσης του Κεφαλαίου 30.

Action tools γράφουν: send, create, charge, delete. Δεν είναι retryable χωρίς κλειδί, δεν είναι με ασφάλεια parallelisable, και είναι ο λόγος που υπάρχουν approval flows.

Orchestration tools καλούν άλλα μοντέλα. Ένα εργαλείο του οποίου η υλοποίηση είναι άλλος agent, με το δικό του prompt, τα δικά του εργαλεία και τον δικό του βρόχο — και για το μοντέλο που το καλεί μοιάζει ακριβώς όπως τα άλλα δύο, επειδή ένα σχήμα και ένα endpoint είναι όλα όσα βλέπει ποτέ.

Αυτό το τρίτο είδος δεν είναι περιέργεια. Είναι ο μηχανισμός πίσω από το μισό agent-as-a-tool του Κεφαλαίου 25 — η άλλη τοπολογία, το handoff, παραδίδει τη συζήτηση και δεν την παίρνει ποτέ πίσω — και λειτουργεί ακριβώς επειδή το interface αυτού του κεφαλαίου είναι αρκετά στενό ώστε να χωρά ένας ολόκληρος agent πίσω του.

Τώρα έχετε ένα μοντέλο που μπορεί να ζητά πράγματα, και μια σύμβαση που κάνει το αίτημα parseable. Αυτό που δεν έχετε είναι κάτι για να ρωτήσει σχετικά με πέρα από ό,τι χωρά στο prompt του.

Το πιο συνηθισμένο εργαλείο σε production, με μεγάλη διαφορά, είναι μια αναζήτηση πάνω σε ένα σώμα κειμένου που το μοντέλο δεν είδε ποτέ κατά την εκπαίδευση: την τεκμηρίωσή σας, τα tickets σας, τα συμβόλαιά σας. Αυτό ακούγεται σαν λυμένο πρόβλημα — κάντε το embed, βρείτε τους κοντινότερους γείτονες, επικολλήστε τους — και τα μέρη που δεν είναι λυμένα είναι εκείνα που αποφασίζουν αν η απάντηση είναι αξιόπιστη: πώς κόβεται το κείμενο πριν γίνει embedded, ποιο similarity threshold είναι αρκετά χαμηλό ώστε να σημαίνει δεν ξέρω, και πώς μια παραπομπή συνδέεται με έναν ισχυρισμό ώστε ένας αναγνώστης να μπορεί να τον ελέγξει.

Το Κεφάλαιο 19 είναι retrieval, και είναι το κεφάλαιο όπου μια λάθος απάντηση παύει να είναι περιέργεια και αρχίζει να είναι ευθύνη.

Οι μετρήσεις σε αυτό το κεφάλαιο προέρχονται από Qwen/Qwen2.5-0.5B-Instruct με greedy decoding, σε 24 generated requests που διασταυρώνουν έξι ζεύγη πόλεων με τέσσερις διατυπώσεις ημερομηνίας, χρησιμοποιώντας το ίδιο το chat template του μοντέλου για τους ορισμούς εργαλείων. Αναπαράγονται ακριβώς, και είναι μικρό μοντέλο: διαβάστε τη διάκριση format/value ως επίδειξη του μηχανισμού και όχι ως benchmark του τι κάνουν τα σημερινά μοντέλα. Ένα frontier model επιλύει το «επόμενη Παρασκευή» σωστά πολύ πιο συχνά — και πάλι δεν μπορεί να αναγκαστεί να το κάνει από ένα σχήμα, που είναι το μέρος που γενικεύεται.

Το λεξιλόγιο JSON Schema που χρησιμοποιήθηκε παραπάνω (type, properties, required, pattern, format, enum) καθορίζεται στο JSON Schema draft που ονομάζει η τεκμηρίωση του provider σας· το χρήσιμο υποσύνολο είναι μικρό και ίδιο μεταξύ providers, και οι διαφορές που υπάρχουν — ποια keywords επιβάλλονται από constrained decoding αντί απλώς να περνούν στο μοντέλο — αξίζει να διαβαστούν στον οδηγό structured-output του provider αντί να θεωρηθούν δεδομένες.

Για το constrained decoding ως τεχνική, οι guidance-style libraries και το project outlines τεκμηριώνουν την κατασκευή grammar-to-logit-mask με τρόπο που αντιστοιχεί απευθείας στον sampler του Κεφαλαίου 17. Και για το ίδιο το round trip, η καθαρότερη προδιαγραφή δεν είναι tutorial αλλά protocol: το Κεφάλαιο 26 το διαβάζει γραμμή προς γραμμή.