AI model routing και fallback: ανθεκτικότητα χωρίς αλλαγή συμπεριφοράς

Μια AI εφαρμογή που εξαρτάται από ένα μόνο model endpoint μπορεί να σταματήσει λόγω rate limit, έλλειψης χωρητικότητας ή προσωρινής βλάβης. Η προφανής λύση είναι να καλέσει άλλο μοντέλο. Αυτό όμως δεν εγγυάται ότι το δεύτερο θα ακολουθήσει το ίδιο schema, θα χρησιμοποιήσει τα ίδια εργαλεία ή θα πάρει ισοδύναμη απόφαση.

Το model fallback είναι πρόβλημα συμβατότητας και ποιότητας, όχι μόνο availability. Ένα response 200 από εναλλακτικό model μπορεί να είναι τεχνικά επιτυχές και επιχειρηματικά λάθος.

01Routing και fallback είναι διαφορετικά

Το routing επιλέγει model πριν από την κλήση με βάση task type, γλώσσα, latency, κόστος, privacy ή απαιτούμενες δυνατότητες. Το fallback ενεργοποιείται όταν η αρχική διαδρομή δεν μπορεί να εξυπηρετήσει το request ή αποτυγχάνει σύμφωνα με σαφείς συνθήκες.

Η AWS τεκμηριώνει ordered fallback chains για inference targets, triggers όπως 429, 503, connection error και first-byte timeout, καθώς και circuit breaker που παρακάμπτει destination που αποτυγχάνει. Η αρχή είναι χρήσιμη πέρα από συγκεκριμένη πλατφόρμα: οι συνθήκες μετάβασης πρέπει να είναι ρητές και παρατηρήσιμες.

02Πότε επιτρέπεται fallback

Κατάλληλοι triggers είναι:

• rate limit ή capacity error,
• service unavailable,
• connection failure,
• timeout πριν ξεκινήσει response,
• region ή endpoint unavailable,
• μοντέλο προσωρινά μη διαθέσιμο.

Δεν κάνουμε αυτόματα fallback επειδή το model έδωσε απάντηση που δεν μας άρεσε. Πρώτα εφαρμόζουμε schema validation ή quality checks και αποφασίζουμε αν επιτρέπεται retry, repair ή ανθρώπινη παρέμβαση.

Μετά την έναρξη streaming, η μετάβαση είναι δύσκολη: ο χρήστης έχει ήδη λάβει μέρος της απάντησης. Συνήθως χρειάζεται διακοπή και νέα προσπάθεια με σαφή ένδειξη, όχι αόρατη συγκόλληση δύο outputs.

03Capability matrix πριν από τη σειρά μοντέλων

Κάθε υποψήφιο model καταγράφεται σε matrix:

• υποστηριζόμενες γλώσσες και ποιότητα στα ελληνικά,
• context και output limits,
• structured output ή JSON schema,
• tool use και parallel calls,
• vision ή document input,
• streaming,
• latency profile,
• data residency και retention,
• κόστος και rate limits.

Ένα φθηνότερο text model δεν αποτελεί fallback για workflow που απαιτεί εικόνες ή συγκεκριμένο tool protocol. Η αλυσίδα φιλτράρεται πρώτα από hard capabilities και μετά από προτιμήσεις.

04Semantic compatibility

Δύο models που δέχονται το ίδιο prompt δεν παράγουν απαραίτητα ισοδύναμη συμπεριφορά. Μπορεί να ερμηνεύουν διαφορετικά priorities, να επιλέγουν άλλα tools ή να αλλάζουν το ύφος και τη λεπτομέρεια.

Αν η εφαρμογή ενημερώνει CRM, προτείνει refund ή ταξινομεί ticket, χρειαζόμαστε contract γύρω από το αποτέλεσμα: schema, allowed enum values, citations, confidence policy και approval requirements. Το model είναι implementation πίσω από αυτό το contract.

05Prompt adapters και κοινή πολιτική

Αποφεύγουμε ένα ενιαίο prompt string που αποστέλλεται αμετάβλητο παντού. Διατηρούμε provider-neutral task specification και adapter ανά model family για system instructions, tool definitions και formatting.

Οι safety και business policies παραμένουν κοινές και ελέγχονται και μετά το output. Δεν υποθέτουμε ότι κάθε provider εφαρμόζει τις ίδιες προεπιλογές. Κάθε adapter είναι versioned και συνδέεται με τα eval αποτελέσματά του.

06Structured outputs και tool calls

Το fallback output περνά το ίδιο schema validation. Αν δεν υποστηρίζεται native schema, μπορεί να χρησιμοποιηθεί parser και bounded repair, αλλά αυτή είναι διαφορετική reliability class.

Για tool use ελέγχουμε:

• ίδια ονόματα και περιγραφές εργαλείων,
• argument schema και required fields,
• handling unknown tool,
• μέγιστο πλήθος calls,
• permissions ανεξάρτητα από model,
• idempotency για ενέργειες.

Ο orchestrator, όχι το model, επιβάλλει authorization και spending limits.

07Fallback chain και circuit breaker

Μια πρακτική σειρά μπορεί να είναι ίδιο model σε δεύτερο region, ισοδύναμο model στον ίδιο provider και τέλος εγκεκριμένο model άλλου provider. Κάθε βήμα έχει trigger, timeout και μέγιστη προσπάθεια.

Ο circuit breaker σταματά να δοκιμάζει endpoint που αποτυγχάνει συνεχώς και επιτρέπει περιορισμένα probes κατά την ανάκαμψη. Έτσι μειώνεται latency και δεν χρεώνονται διαδοχικές αποτυχημένες προσπάθειες σε κάθε request.

08Αποφυγή retry storms και διπλών ενεργειών

Retries υπάρχουν σε SDK, gateway, application και job queue. Αν όλα επαναλαμβάνουν τρεις φορές, ένα request μπορεί να πολλαπλασιαστεί ανεξέλεγκτα. Ορίζουμε ένα συνολικό retry budget και γνωρίζουμε ποιο layer έχει την ευθύνη.

Αν το model είχε ήδη καλέσει εργαλείο πριν αποτύχει η ροή, το fallback δεν ξαναρχίζει τυφλά από την αρχή. Το state κρατά completed tool calls και idempotency keys. Για non-reversible action μπορεί να απαιτείται reconciliation ή ανθρώπινη απόφαση.

09Κόστος και latency budget

Κάθε επιπλέον attempt αυξάνει χρόνο και κόστος. Η αλυσίδα έχει συνολικό deadline, όχι ανεξάρτητο μεγάλο timeout σε κάθε model. Αν το request έχει budget έξι δευτερολέπτων, το primary δεν μπορεί να καταναλώσει πέντε και κάθε fallback άλλα πέντε.

Καταγράφουμε πραγματικό serving model, attempts, tokens, latency και κόστος. Αν το fallback είναι ακριβότερο, μπορεί να επιτρέπεται μόνο για premium workflow ή κρίσιμη ενέργεια.

10Graceful degradation

Όταν κανένα model δεν είναι διαθέσιμο, η εφαρμογή μπορεί να:

• επιστρέψει deterministic search results χωρίς generation,
• δημιουργήσει draft αργότερα μέσω queue,
• ζητήσει ανθρώπινη ανάληψη,
• περιορίσει προσωρινά λειτουργίες υψηλού κόστους,
• εμφανίσει σαφές μήνυμα αντί να εφεύρει απάντηση.

Το degradation σχεδιάζεται πριν το outage. Ένα customer support portal μπορεί να συνεχίσει να δέχεται ticket ακόμη κι αν δεν γίνεται AI classification.

11Evals για κάθε route και fallback

Δημιουργούμε dataset με αντιπροσωπευτικές ελληνικές ερωτήσεις, edge cases, tool scenarios και safety cases. Τρέχουμε κάθε model και adapter με τα ίδια acceptance criteria.

Μετράμε task success, schema validity, tool accuracy, groundedness, refusal correctness, latency και κόστος. Ελέγχουμε ειδικά αν η μετάβαση αλλάζει business outcome. Ένα fallback μπαίνει production μόνο όταν περνά το ελάχιστο επίπεδο για το συγκεκριμένο route.

Μετά από model update, prompt change ή provider migration, τα evals επαναλαμβάνονται. Το όνομα «ισοδύναμο model» δεν αποτελεί απόδειξη συμβατότητας.

12Observability

Κάθε request καταγράφει χωρίς ευαίσθητο prompt:

• route και λόγο επιλογής,
• primary και τελικό model,
• fallback trigger,
• attempts και circuit state,
• latency πρώτου byte και συνολική,
• token usage και εκτιμώμενο κόστος,
• schema ή tool validation failures,
• outcome του workflow.

Alerts ενεργοποιούνται όταν αυξάνεται fallback rate, γιατί μπορεί να κρύβει provider incident ή εξάντληση quota.

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

14Checklist

Το αξιόπιστο model routing δεν υπόσχεται ότι όλα τα μοντέλα είναι ίδια. Αναγνωρίζει τις διαφορές τους και επιτρέπει μετάβαση μόνο όταν το αποτέλεσμα παραμένει εντός του συμβολαίου της εφαρμογής.

15Πηγές

Γράφτηκε από την ομάδα της Ai Foundry (aifoundry.gr), εταιρείας ανάπτυξης λογισμικού και εφαρμογών τεχνητής νοημοσύνης στην Ελλάδα.