Ένας χρήστης γράφει «ακύρωσέ το», αλλά στο account υπάρχουν δύο ενεργές παραγγελίες. Ο AI agent μπορεί να μαντέψει ποια εννοεί, να αρνηθεί εντελώς ή να ζητήσει τη μία πληροφορία που λείπει. Η τρίτη επιλογή είναι συνήθως η χρήσιμη.
Η ασφαλής συμπεριφορά στην αβεβαιότητα δεν σημαίνει ότι ο agent απαντά συνεχώς «δεν γνωρίζω». Σημαίνει ότι ξεχωρίζει πότε μπορεί να προχωρήσει με αναστρέψιμη έρευνα, πότε πρέπει να ρωτήσει και πότε πρέπει να σταματήσει πριν από μη αναστρέψιμη ενέργεια.
Η αβεβαιότητα έχει διαφορετικές αιτίες
Δεν αντιμετωπίζονται όλα τα κενά με τον ίδιο τρόπο. Ο agent μπορεί να έχει:
- Ασαφή πρόθεση: δεν είναι σαφές τι θέλει ο χρήστης.
- Ελλιπή οντότητα: λείπει order ID, ημερομηνία ή λογαριασμός.
- Αντιφατικά δεδομένα: δύο πηγές δίνουν διαφορετική κατάσταση.
- Ανεπαρκή δικαιώματα: ο agent δεν μπορεί να δει ή να αλλάξει τον πόρο.
- Αποτυχία εργαλείου: timeout, malformed response ή προσωρινή διακοπή.
- Περιορισμένη γνώση: δεν υπάρχει επαρκής τεκμηρίωση για αξιόπιστη απάντηση.
- Αβέβαιο αποτέλεσμα: η ενέργεια μπορεί να έχει μη προβλέψιμες συνέπειες.
Η εφαρμογή πρέπει να καταγράφει reason category. Αν όλες οι περιπτώσεις γίνουν ένα γενικό low_confidence, δεν θα ξέρετε αν χρειάζεται καλύτερο retrieval, καθαρότερο UI ή διόρθωση integration.
Confidence score δεν είναι άδεια εκτέλεσης
Ένας αριθμός confidence μπορεί να βοηθήσει στο routing, αλλά δεν πρέπει να αποφασίζει μόνος του αν επιτρέπεται μια ενέργεια. Τα model probabilities δεν είναι πάντα καλά βαθμονομημένα και η σοβαρότητα του λάθους αλλάζει ανά use case.
Χρησιμοποιήστε policy matrix με δύο άξονες: αβεβαιότητα και impact. Για read-only αναζήτηση χαμηλού κινδύνου ο agent μπορεί να προχωρήσει και να επαληθεύσει. Για ακύρωση, πληρωμή, αποστολή ή αλλαγή permissions, ακόμη και μικρή ασάφεια απαιτεί διευκρίνιση ή approval.
Το threshold πρέπει να προκύπτει από evals και πραγματικά incidents, όχι από αυθαίρετο 0.8. Παρακολουθήστε false confidence: περιπτώσεις όπου ο agent ήταν βέβαιος αλλά λάθος.
Κάντε πρώτα την ασφαλή έρευνα
Πριν ρωτήσει τον χρήστη, ο agent μπορεί να συλλέξει όσα είναι ήδη διαθέσιμα και επιτρέπονται. Αν το αίτημα λέει «βρες το τελευταίο invoice», μπορεί να αναζητήσει read-only τα invoices και να διαπιστώσει ότι υπάρχει ένα μόνο πρόσφατο αποτέλεσμα.
Η αρχή είναι: ολοκλήρωσε τα ασφαλή, αναστρέψιμα βήματα που μειώνουν την ασάφεια και σταμάτα ακριβώς πριν από το ρίσκο. Μην ζητάς πληροφορία που υπάρχει ήδη στο context ή σε επιτρεπόμενο σύστημα. Μην εκτελείς side effect για να «δεις αν ήταν αυτό».
Η έρευνα χρειάζεται όρια. Μετά από συγκεκριμένο αριθμό queries ή αποτυχημένων retries, η εφαρμογή μεταβαίνει σε clarification ή handoff αντί να ψάχνει επ' αόριστον.
Η καλή διευκρινιστική ερώτηση
Μια χρήσιμη ερώτηση είναι συγκεκριμένη και παρουσιάζει τις πραγματικές επιλογές:
Κακό: «Μπορείτε να δώσετε περισσότερες πληροφορίες;»
Καλό: «Βρήκα δύο ενεργές παραγγελίες: #1842 της 12/10 και #1871 της 17/10. Ποια θέλετε να ακυρώσω;»
Η ερώτηση πρέπει να ζητά το ελάχιστο στοιχείο που ξεκλειδώνει την επόμενη απόφαση. Αποφύγετε να εμφανίζετε δεδομένα που ο χρήστης δεν δικαιούται να δει. Αν υπάρχουν πολλές επιλογές, χρησιμοποιήστε structured selection αντί για νέο ελεύθερο κείμενο.
Μετά την απάντηση, ο agent επιβεβαιώνει ότι η διευκρίνιση αντιστοιχεί στο ίδιο account και στην ίδια ενεργή εργασία. Δεν πρέπει ένα μεταγενέστερο «τη δεύτερη» να εφαρμοστεί σε διαφορετικό context μετά από timeout.
Abstention με χρήσιμο επόμενο βήμα
Το abstention είναι η συνειδητή απόφαση να μην παραχθεί βέβαιη απάντηση ή να μην εκτελεστεί action όταν τα στοιχεία δεν επαρκούν. Πρέπει να περιλαμβάνει:
- τι δεν μπορεί να επιβεβαιωθεί,
- γιατί αυτό εμποδίζει ασφαλή συνέχεια,
- τι στοιχεία χρησιμοποιήθηκαν ήδη,
- ποια πληροφορία ή ανθρώπινη απόφαση χρειάζεται,
- τι ασφαλές μέρος της εργασίας ολοκληρώθηκε.
Αν δεν υπάρχει πηγή για μια εταιρική πολιτική, ο agent μπορεί να πει ότι δεν βρέθηκε εγκεκριμένη απάντηση και να ανοίξει draft ticket. Δεν πρέπει να συμπληρώσει το κενό με γενική γνώση και να την παρουσιάσει ως πολιτική της εταιρείας.
Pause πριν από tool call
Η ασφαλής παύση πρέπει να εφαρμόζεται στο runtime. Για εργαλεία υψηλού αντίκτυπου, ο agent προτείνει action με συγκεκριμένα arguments και το σύστημα δημιουργεί pending approval αντί να το εκτελεί.
Η επίσημη τεκμηρίωση των OpenAI Agents περιγράφει interruptions που διατηρούν resumable state: το run παγώνει, ο άνθρωπος εγκρίνει ή απορρίπτει και η ίδια εργασία συνεχίζει. Αυτή η δομή αποφεύγει να ξεκινήσει νέο conversation που μπορεί να χάσει ποια ακριβώς ενέργεια εγκρίθηκε.
Οι validations πρέπει να τοποθετούνται δίπλα στο tool που δημιουργεί το side effect. Ένα γενικό instruction στο system prompt δεν αντικαθιστά server-side έλεγχο target, permissions, arguments και policy.
Handoff σε άνθρωπο με πλήρες context
Όταν η διευκρίνιση δεν αρκεί ή η περίπτωση απαιτεί κρίση, ο agent παραδίδει σε άνθρωπο. Το handoff package πρέπει να περιλαμβάνει:
- αρχικό αίτημα και επαληθευμένη ταυτότητα,
- συνοπτικό ιστορικό ενεργειών,
- δεδομένα και πηγές που ελέγχθηκαν,
- ακριβές σημείο αβεβαιότητας,
- pending action που δεν εκτελέστηκε,
- deadlines ή urgency.
Ο άνθρωπος δεν πρέπει να ξανακάνει όλη την έρευνα. Παράλληλα, το summary δεν πρέπει να κρύβει αντιφατικά στοιχεία για να φαίνεται πιο καθαρή η υπόθεση.
Αποφυγή loops διευκρινίσεων
Ένας agent μπορεί να παγιδευτεί σε κύκλο ερωτήσεων αν κάθε απάντηση δημιουργεί νέα ασάφεια. Ορίστε μέγιστο clarification count και state machine με σαφείς μεταβάσεις: investigating, waiting_for_user, waiting_for_approval, handed_off, completed ή cancelled.
Αν ο χρήστης δεν απαντήσει, η εργασία λήγει χωρίς side effect και μπορεί να επανεκκινήσει αργότερα με νέο confirmation. Αν αλλάξει ουσιωδώς το target ή το ποσό, η προηγούμενη έγκριση δεν μεταφέρεται αυτόματα.
Αξιολόγηση της συμπεριφοράς
Τα evals πρέπει να περιλαμβάνουν ασαφή αιτήματα, πολλαπλά matching records, αντιφατικές πηγές και tool failures. Μετρήστε:
- σωστό action χωρίς περιττή ερώτηση,
- σωστή διευκρίνιση όταν λείπει κρίσιμο στοιχείο,
- unsafe action rate,
- unnecessary refusal rate,
- χρόνο και βήματα μέχρι resolution,
- ποιότητα handoff context,
- calibration ανά κατηγορία κινδύνου.
Η επιτυχία δεν είναι ο agent να ενεργεί πάντα ούτε να ρωτά πάντα. Είναι να επιλέγει την κατάλληλη συμπεριφορά για το impact και τις διαθέσιμες αποδείξεις.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε uncertainty policies ανά workflow και tool. Χαρτογραφούμε ποιες πληροφορίες είναι υποχρεωτικές, ποια read-only βήματα μπορεί να κάνει ο agent αυτόνομα και ποια actions απαιτούν clarification ή ανθρώπινη έγκριση.
Υλοποιούμε stateful pauses, structured questions, server-side validation και handoff summaries με provenance. Προσθέτουμε eval cases για ασάφεια, conflicting data και failures και παρακολουθούμε τόσο τις επικίνδυνες ενέργειες όσο και τις περιττές αρνήσεις. Έτσι η Ai Foundry δημιουργεί agents που παραμένουν χρήσιμοι χωρίς να μετατρέπουν την αυτοπεποίθηση του μοντέλου σε ανεξέλεγκτη εξουσιοδότηση.
Checklist σχεδιασμού
- Κατηγοριοποιείται η αιτία αβεβαιότητας;
- Γίνονται πρώτα ασφαλή read-only βήματα;
- Οι ερωτήσεις ζητούν το ελάχιστο κρίσιμο στοιχείο;
- Το confidence δεν παρακάμπτει impact και permissions;
- Τα side effects παγώνουν σε resumable state;
- Οι validations εφαρμόζονται στο tool boundary;
- Το handoff περιλαμβάνει πηγές και pending action;
- Υπάρχουν όρια σε retries και clarification loops;
Ο ώριμος AI agent δεν αποδεικνύει την αξία του μαντεύοντας γρήγορα. Την αποδεικνύει γνωρίζοντας πότε έχει αρκετά στοιχεία για να προχωρήσει και πότε χρειάζεται μία καθαρή ερώτηση πριν αγγίξει το πραγματικό σύστημα.