AI agent fallback: τι κάνει η εφαρμογή όταν το model ή ο provider δεν απαντά

Ένα AI demo μπορεί να θεωρεί ότι κάθε model call επιστρέφει γρήγορα και κάθε tool είναι διαθέσιμο. Στο production υπάρχουν timeouts, rate limits, προσωρινά provider errors, αργά APIs και απαντήσεις που δεν περνούν validation. Η αξιοπιστία του προϊόντος κρίνεται από το τι συμβαίνει τότε.

Fallback δεν σημαίνει απλώς «δοκίμασε άλλο μοντέλο». Είναι προκαθορισμένη στρατηγική που προστατεύει τη ροή, τα δεδομένα και τον χρήστη όταν ένα AI βήμα δεν μπορεί να ολοκληρωθεί με ασφάλεια.

Ταξινομήστε πρώτα τις αποτυχίες

Διαφορετικό χειρισμό χρειάζεται ένα προσωρινό network timeout, ένα invalid response schema, ένα safety refusal και ένα tool error. Καταγράψτε κατηγορίες όπως:

• provider unavailable ή rate limited
• timeout
• invalid ή ελλιπής έξοδος
• moderation ή policy block
• retrieval χωρίς επαρκές αποτέλεσμα
• tool authorization failure
• downstream API error
• exceeded budget ή token limit

Αν όλα μετατρέπονται σε γενικό retry, η εφαρμογή μπορεί να αυξήσει κόστος και καθυστέρηση χωρίς να λύσει το πρόβλημα.

Timeouts και περιορισμένα retries

Κάθε εξωτερική κλήση χρειάζεται timeout ανάλογο με τη χρήση. Ένα interactive chatbot δεν μπορεί να περιμένει όσο ένα background document job. Χρησιμοποιήστε περιορισμένα retries μόνο για προσωρινά σφάλματα, με backoff και jitter.

Μην επαναλαμβάνετε write tools χωρίς idempotency. Αν ο agent δεν έλαβε απάντηση από το CRM, δεν γνωρίζει απαραίτητα αν η εγγραφή δημιουργήθηκε. Πρώτα ελέγξτε το αποτέλεσμα ή χρησιμοποιήστε idempotency key πριν ξαναδοκιμάσετε.

Fallback model με δοκιμασμένο contract

Ένα δεύτερο μοντέλο μπορεί να βοηθήσει όταν ο βασικός provider δεν είναι διαθέσιμος, αλλά δεν είναι drop-in αντικατάσταση από μόνο του. Μπορεί να διαφέρει σε tool calling, context limits, structured output και safety behavior.

Κρατήστε κοινό application-level contract και adapters ανά provider. Δοκιμάστε τα ίδια evaluations και failure cases και στα fallback paths. Αν το δεύτερο μοντέλο δεν υποστηρίζει ασφαλώς τη συγκεκριμένη ενέργεια, προτιμήστε degraded mode αντί να χαλαρώσετε validation.

Degraded mode που παραμένει χρήσιμο

Ο agent μπορεί να συνεχίσει με περιορισμένη λειτουργία:

• αναζήτηση σε verified knowledge base χωρίς δημιουργική σύνθεση
• εμφάνιση σχετικών εγγράφων αντί για τελική απάντηση
• δημιουργία draft χωρίς αυτόματη αποστολή
• αποθήκευση αιτήματος σε queue για αργότερα
• μεταφορά σε άνθρωπο με συγκεντρωμένο context
• παραδοσιακή φόρμα ή deterministic workflow

Το degraded mode πρέπει να λέει καθαρά τι ολοκληρώθηκε και τι όχι. Μην εμφανίζετε επιτυχία αν μια κρίσιμη ενέργεια έμεινε pending.

Circuit breaker και προστασία από αλυσιδωτές αποτυχίες

Αν ένας provider αποτυγχάνει επανειλημμένα, ο circuit breaker σταματά προσωρινά νέες κλήσεις αντί να συσσωρεύει timeouts. Η εφαρμογή μπορεί να ενεργοποιήσει fallback ή να βάλει jobs σε ουρά μέχρι να αποκατασταθεί η υπηρεσία.

Ορίστε thresholds, χρονικό παράθυρο και τρόπο επαναφοράς. Προσέξτε να μη μεταφέρετε όλο το φορτίο σε δεύτερο provider και προκαλέσετε νέα αποτυχία. Rate limits και capacity planning ισχύουν και για το fallback.

Human handoff χωρίς χαμένο context

Όταν η αυτοματοποίηση σταματά, ο άνθρωπος χρειάζεται το αρχικό αίτημα, τα ασφαλή intermediate results, τα tools που κλήθηκαν και τον λόγο αποτυχίας. Δεν χρειάζεται raw chain-of-thought ούτε secrets.

Η ανάθεση πρέπει να δημιουργεί σαφές task στο CRM ή support queue και να ενημερώνει τον χρήστη για το επόμενο βήμα. Ένα «δοκιμάστε αργότερα» δεν είναι αρκετό για κρίσιμη επιχειρηματική ροή.

Αποφύγετε διπλές και αντικρουόμενες ενέργειες

Αν ο primary path ολοκληρωθεί αργά ενώ το fallback έχει ήδη δράσει, μπορεί να σταλούν δύο emails ή να δημιουργηθούν δύο cases. Χρησιμοποιήστε workflow state machine, idempotency keys και compare-and-set transitions ώστε μόνο μία διαδρομή να δεσμεύει το τελικό αποτέλεσμα.

Καταγράψτε ποιο path κέρδισε και ακυρώστε ή αγνοήστε τα υπόλοιπα με ασφαλή τρόπο. Αυτό είναι ιδιαίτερα σημαντικό σε πληρωμές, ενημερώσεις CRM και ειδοποιήσεις πελατών.

Monitoring και δοκιμές αστοχίας

Μετρήστε timeout rate, retry count, fallback activation, queue age, human handoff και τελικό business outcome. Alert χρειάζεται όταν αυξάνεται η αποτυχία ή το degraded mode μένει ενεργό περισσότερο από το αναμενόμενο.

Δοκιμάστε ελεγχόμενα provider outage, invalid JSON, αργό tool, exhausted budget και duplicate callback. Το fallback που δεν έχει εκτελεστεί ποτέ πριν από πραγματικό incident είναι απλώς υπόθεση.

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

Στην Ai Foundry σχεδιάζουμε τους AI agents ως production workflows με σαφείς καταστάσεις. Ορίζουμε timeouts, retries, idempotency και degraded behavior για κάθε κρίσιμο βήμα πριν συνδέσουμε models και tools.

Όπου υπάρχει επιχειρηματική ανάγκη, υλοποιούμε provider adapters, fallback models, circuit breakers και human handoff προς CRM ή support queue. Έτσι μια εξωτερική αστοχία δεν μετατρέπεται σε διπλή ενέργεια, σιωπηλή απώλεια αιτήματος ή ψευδή επιβεβαίωση προς τον πελάτη.

Checklist

• Έχουν ταξινομηθεί οι πιθανές αποτυχίες;
• Υπάρχουν timeouts ανά interactive και background εργασία;
• Γίνονται retries μόνο σε προσωρινά errors;
• Είναι idempotent τα write tools;
• Έχει δοκιμαστεί το fallback model με το ίδιο contract;
• Υπάρχει χρήσιμο degraded mode;
• Δημιουργείται human task με επαρκές context;
• Αποτρέπονται διπλές ενέργειες από racing paths;
• Μετριούνται fallback rate και τελικό outcome;

Συμπέρασμα

Ένας αξιόπιστος AI agent δεν είναι αυτός που δεν αποτυγχάνει ποτέ. Είναι αυτός που αποτυγχάνει με ελεγχόμενο τρόπο, κρατά τη ροή συνεπή και δίνει στον χρήστη ή στην ομάδα καθαρό επόμενο βήμα.

Πηγές: NIST AI RMF: Generative AI Profile, OWASP Agentic AI Threats and Mitigations.