Structured output από AI: γιατί το έγκυρο JSON δεν αρκεί πριν ενημερωθεί το CRM

Ένας AI agent διαβάζει email και επιστρέφει JSON με όνομα πελάτη, προτεραιότητα και προτεινόμενη ενέργεια. Το output κάνει parse χωρίς error, οπότε η εφαρμογή το περνά στο CRM. Λίγο αργότερα ανακαλύπτει ότι η προτεραιότητα έχει μη επιτρεπόμενη τιμή, το ποσό είναι string και το customer ID ανήκει σε άλλο tenant.

Το structured output μειώνει την ασάφεια, αλλά δεν κάνει τα δεδομένα αυτόματα αξιόπιστα. Χρειάζονται διαδοχικά επίπεδα validation πριν το αποτέλεσμα επηρεάσει επιχειρησιακά συστήματα.

JSON syntax, schema και business rule

Τρία διαφορετικά πράγματα συχνά συγχέονται:

• syntactically valid JSON: το κείμενο μπορεί να γίνει parse
• schema-valid JSON: τα types, required fields και επιτρεπόμενες τιμές ταιριάζουν στο contract
• business-valid action: τα IDs υπάρχουν, ο χρήστης έχει δικαίωμα και η ενέργεια επιτρέπεται στην τρέχουσα κατάσταση

Ένα payload μπορεί να περάσει τα πρώτα δύο και να αποτύχει στο τρίτο. Για παράδειγμα, ένα order_id είναι σωστό string αλλά ανήκει σε άλλον πελάτη.

Ορίστε ρητό schema

Χρησιμοποιήστε JSON Schema ή αντίστοιχο typed contract για properties, required fields, enums, ranges και nested objects. Δηλώστε τη version του schema και αποφασίστε αν επιτρέπονται πρόσθετα properties.

Το JSON Schema είναι δηλωτική γλώσσα για δομή και constraints. Η επίσημη προδιαγραφή 2020-12 επιτρέπει, μεταξύ άλλων, types, required fields, enum, numeric limits και conditional validation. Χρησιμοποιήστε validator στο backend ακόμη κι αν το model API υπόσχεται structured output.

Μικρότερο contract, λιγότερη αβεβαιότητα

Μη ζητάτε από το μοντέλο να επιστρέψει ολόκληρο CRM record αν χρειάζεστε μόνο classification και summary. Κάθε πρόσθετο πεδίο είναι νέα πιθανότητα λάθους και πιθανή έκθεση δεδομένων.

Προτιμήστε enums αντί για ελεύθερο κείμενο όταν υπάρχουν γνωστές επιλογές. Για ποσά, ξεχωρίστε value και currency. Για ημερομηνίες, επιλέξτε συγκεκριμένο format και timezone. Για IDs, ζητήστε opaque references που μετά επαληθεύει ο server.

Αποφύγετε αθόρυβα defaults

Αν λείπει κρίσιμο πεδίο, μην το συμπληρώνετε σιωπηρά με τιμή που αλλάζει την απόφαση. Το priority: normal ως default μπορεί να κρύψει επείγον αίτημα. Διαχωρίστε optional από required και επιστρέψτε validation error με ασφαλές context.

Τα null, κενό string και απουσία πεδίου δεν είναι πάντα ισοδύναμα. Ορίστε τη σημασία τους στο contract και δοκιμάστε τα ξεχωριστά.

Retry με feedback, αλλά με όριο

Αν το output αποτύχει schema validation, μπορείτε να ζητήσετε από το μοντέλο διόρθωση δίνοντας μόνο τα validation errors και το απαιτούμενο schema. Περιορίστε όμως τα retries. Επαναλαμβανόμενη αποτυχία πρέπει να οδηγεί σε fallback ή human review, όχι σε loop κόστους.

Μην περνάτε stack traces, secrets ή ολόκληρα ευαίσθητα records στο repair prompt. Καταγράψτε schema version, error category και attempt count για observability.

Business validation στο authoritative system

Μετά το schema, ελέγξτε ότι customer, product και status υπάρχουν και είναι επιτρεπτά. Αν η ενέργεια αλλάζει δεδομένα, εφαρμόστε τα ίδια authorization και state-transition rules που θα ίσχυαν για ανθρώπινο χρήστη.

Το AI δεν πρέπει να μπορεί να παρακάμπτει validation επειδή καλεί εσωτερικό tool. Ο server αποφασίζει αν η μετάβαση από approved σε cancelled επιτρέπεται και αν ο συγκεκριμένος actor έχει δικαίωμα.

Confidence δεν είναι άδεια εκτέλεσης

Ένα confidence score που παράγει το ίδιο μοντέλο δεν αποτελεί από μόνο του αξιόπιστη πιθανότητα. Χρησιμοποιήστε το μόνο ως signal μέσα σε ευρύτερο rule και βαθμονομήστε το με πραγματικά evaluation data.

Για κρίσιμες ενέργειες, ορίστε human approval ή deterministic verification. Ένα draft μπορεί να δημιουργηθεί αυτόματα, αλλά η αποστολή προσφοράς ή η αλλαγή οικονομικών στοιχείων χρειάζεται ισχυρότερο έλεγχο.

Versioning και backward compatibility

Όταν αλλάζει το schema, κρατήστε version στο request, output και stored result. Background jobs μπορεί να ολοκληρωθούν με παλιότερη έκδοση μετά από deployment. Ο consumer πρέπει να γνωρίζει αν μπορεί να μετατρέψει το payload ή αν χρειάζεται επανεκτέλεση.

Δοκιμάστε real examples, edge cases και malicious inputs για κάθε version. Μην αλλάζετε την έννοια ενός υπάρχοντος enum value χωρίς migration.

Πώς το υλοποιεί η Ai Foundry

Στην Ai Foundry ορίζουμε typed contract ανά AI workflow και κρατάμε το output όσο μικρό χρειάζεται. Κάθε αποτέλεσμα περνά backend schema validation, business rules και authorization πριν φτάσει σε CRM, ERP ή άλλο tool.

Υλοποιούμε περιορισμένα repair retries, fallback και human approval ανάλογα με το ρίσκο. Έτσι το AI μπορεί να μετατρέπει μη δομημένο περιεχόμενο σε χρήσιμα δεδομένα χωρίς το production σύστημα να εμπιστεύεται τυφλά ένα JSON που απλώς έκανε parse.

Checklist

• Υπάρχει versioned schema για κάθε output;
• Είναι required μόνο τα πραγματικά αναγκαία πεδία;
• Χρησιμοποιούνται enums και ranges όπου γίνεται;
• Τρέχει validator στο backend;
• Ελέγχονται IDs, permissions και state transitions;
• Είναι περιορισμένα τα repair retries;
• Υπάρχει fallback ή human review;
• Καταγράφονται schema version και validation errors;

Συμπέρασμα

Το structured output είναι interface, όχι εγγύηση αλήθειας. Με JSON Schema, business validation και authorization, το AI γίνεται ασφαλής παραγωγός προτάσεων και δεδομένων αντί για ανεξέλεγκτη πηγή αλλαγών.

Πηγές: JSON Schema overview, JSON Schema reference, JSON Schema specification.