Enrutament de l'API LLM fiable: temps d'espera, reintents i fallbacks de models sense regressió semàntica
Una arquitectura pràctica per classificar els errors de l'API de LLM, fer complir un pressupost de latència, seleccionar models de reserva compatibles, protegir els efectes secundaris i validar totes les respostes acceptades.
Una sol·licitud alternativa no té èxit només perquè un altre model ha retornat HTTP 200. La substitució pot superar el pressupost de latència original, ometre camps JSON obligatoris, trucar a una eina diferent o produir una resposta amb una semàntica materialment diferent. Per tant, l'encaminament fiable de l'API LLM requereix més que una llista ordenada de models: requereix un contracte, un classificador d'errors, una política d'intent limitat i una validació abans de l'acceptació.
La regla central és senzilla: torneu-ho a provar només quan la fallada sigui plausiblement temporal i reduïu-vos només quan la següent ruta encara pugui satisfer el contracte de sol·licitud original.
Definiu el contracte d'encaminament abans de triar els models
Comenceu descrivint què ha de proporcionar una resposta satisfactòria. Aquest contracte d'encaminament s'ha de poder llegir per màquina i s'ha d'adjuntar a cada càrrega de treball o classe de sol·licitud.
{ "workload": "extracció_factura", "modals": ["text", "imatge"], "max_input_tokens": 50000, "requires_tools": fals, "sortida_estructurada": { "obligatori": cert, "schema_id": "factura-v3", "estricte": cert }, "allowed_model_classes": ["extracció de documents"], "max_cost_usd": 0,08, "deadline_ms": 8000 }
El contracte ha de cobrir les modalitats requerides, la capacitat del context, el suport de l'eina, el comportament de la sortida estructurada, les classes de models acceptables, el cost màxim i el termini d'extrem a extrem. Afegiu restriccions específiques de l'aplicació quan sigui necessari, com ara regions permeses, longitud mínima de sortida o un motiu d'acabat requerit.
Recomanació: mantenir grups de rutes separats i provats per a sol·licituds de text sense format, resultats restringits per esquemes, ús d'eines, visió i sol·licituds de context llarg. Un model que és una alternativa de text acceptable no és automàticament una alternativa acceptable per a la crida d'eines o l'entrada d'imatges.
Classifica l'error abans de prendre mesures
Els errors d'autenticació, les sol·licituds amb format incorrecte, els límits de velocitat i els errors del servidor requereixen respostes diferents. Tractar totes les respostes que no tenen èxit com a capacitat de reintentar malbaratament i poden amagar defectes.
Fet: les sol·licituds de tarifa limitada sense èxit encara poden comptar amb els límits del proveïdor. Per tant, els intents immediats agressius poden augmentar l'acceleració en lloc de resoldre'l. Els reintents també consumeixen capacitat addicional durant una interrupció i les polítiques de reintents a diverses capes d'aplicació poden multiplicar la càrrega resultant.
Recomanació: permet que una capa tingui els seus propis intents de generació de models. En una arquitectura típica, la passarel·la de l'API AI és el propietari correcte perquè veu la salut de la ruta, l'historial d'intents, la latència i el cost. Desactiveu els reintents automàtics als clients de nivell inferior quan sigui possible, o compta-los explícitament en el mateix pressupost d'intents.
Gasa un pressupost de latència d'extrem a extrem
Els temps d'espera per intent són insuficients. Tres intents amb un temps d'espera de cinc segons poden convertir una operació prevista de cinc segons en una resposta de quinze segons, abans que s'incloguin la desactivació i la validació.
Anoteu una data límit absoluta quan la sol·licitud entri a la passarel·la. Abans de cada intent, calcula el temps restant:
remaining = data límit - hora_actual
requerit = connect_allowance + generation_allowance + validation_allowance
si queda < necessari:
aturar_sense_llançar_un altre_intent
Per a un termini de vuit segons, una assignació inicial raonable pot reservar 300 ms per al treball de passarel·la i la validació final, permetre fins a 4,5 segons per a la ruta principal i conservar aproximadament 3,2 segons per a una alternativa. Aquests valors són un exemple, no un punt de referència. S'han de derivar de distribucions de latència mesurades per als proveïdors, models, regions i mides de sortida reals.
Utilitzeu un backoff exponencial limitat amb fluctuació per als reintents transitoris:
retard = aleatori (0, min (cap, base * 2^retry_index))
Les pistes de reintent del proveïdor, com ara un valor de reintent després, haurien de tenir prioritat quan s'ajustin dins del termini restant. Atureu-vos després d'un petit nombre d'intents. Una política comuna és un intent principal més una alternativa, amb un reintent opcional de la mateixa ruta només per a un error de connexió primerenc que no podria haver generat una sortida facturable.
Compartiment: la alternativa seqüencial millora la disponibilitat però augmenta la latència de la cua. Les sol·licituds paral·leles o cobertes poden reduir la latència durant les alentiments, però consumeixen més capacitat i poden comportar càrrecs per a diverses generacions d'èxit. La cobertura s'ha de limitar a càrregues de treball crítiques per a la latència i sense efectes secundaris amb cancel·lació i controls de costos.
Seleccioneu alternatives per capacitat, no per classificació
Una taula alternativa hauria de codificar la compatibilitat en lloc d'un ordre global de preferències. Filtra les rutes dels candidats amb el contracte abans de considerar la salut, la latència o el preu.
candidats = rutes
.filter(supports_required_modalities)
.filter(limit_context >= mida_entrada_estimada)
.filter(supports_required_tools)
.filter(supports_requested_schema_mode)
.filter(classe_model a classes_models_permeses)
.filter(cost_estimat <= pressupost_de_cost_remanent)
.filter(no_suprimit_temporalment)
seleccionat = rang (candidats, salut, latència, cost)
El suport de la sortida estructurada mereix una prova explícita. Fins i tot quan dues rutes anuncien la generació restringida per l'esquema, poden ser compatibles amb diferents subconjunts d'esquemes JSON o interpretar casos extrems de manera diferent. Els models compatibles amb eines també poden diferir en la selecció d'eines, la construcció d'arguments i el comportament de trucades paral·leles.
Fet: canviar les famílies de models pot preservar la disponibilitat del transport alhora que es canvia l'estil, la qualitat del raonament, el comportament de seguretat, la tokenització i la selecció d'eines. L'èxit HTTP no és una prova d'equivalència semàntica.
Predicció: a mesura que els catàlegs de models s'amplien, les polítiques d'encaminament de producció utilitzaran cada cop més perfils de capacitat versionats i proves d'acceptació específiques de càrrega de treball en lloc de llistes de models estàtiques. Tracteu-ho com una direcció de disseny, no com una garantia sobre el comportament del proveïdor.
Valida la resposta abans d'acceptar-la
Executeu totes les respostes, inclosa la resposta principal, a través del mateix canal d'acceptació. La validació s'ha de fer abans que el resultat s'emmagatzemi a la memòria cau, es factura internament com a correcte o es passa a un executor d'eines.
- Confirmeu que s'hagi completat el transport i es pot analitzar el sobre de resposta.
- Comproveu el motiu de finalització i rebutgeu el truncament quan es requereixi una sortida completa.
- Valida la sortida estructurada amb l'esquema original.
- Verifiqueu els camps obligatoris, els valors d'enumeració i els invariants de l'aplicació.
- Permet només els noms d'eines registrats i valideu els arguments de cada esquema d'eina.
- Aplica comprovacions semàntiques específiques de la càrrega de treball quan una acceptació falsa seria costosa.
Per a l'extracció de factures, les comprovacions semàntiques poden requerir un total no negatiu, un codi de moneda compatible i totals de partida dins d'una tolerància definida explícitament. Per a la classificació, cal una etiqueta del conjunt permès. Per a la generació de codi, pot ser adequat l'anàlisi o la compilació. Aquestes comprovacions no demostren la qualitat, però eviten que les infraccions de contracte previsibles siguin tractades com a èxits.
No repareu en silenci totes les respostes incorrectes. La normalització determinista, com ara l'eliminació d'espais en blanc inofensius circumdants, pot ser acceptable. Endevinar els camps financers que falten o reescriure els arguments de l'eina canvia el significat del model i hauria de provocar un rebuig o una revisió humana.
Reintents de generació separats dels efectes secundaris
Les sol·licituds LLM solen utilitzar HTTP POST, que no és inherentment idempotent. Més important encara, una resposta model pot iniciar una acció externa com ara cobrar un mètode de pagament, enviar un missatge, crear un bitllet o modificar la infraestructura. Tornar a provar la generació i reproduir aquesta acció són decisions separades.
Assigneu un ID d'operació al límit de l'aplicació i un ID d'intent a cada trucada de model. Persistir l'estat d'execució de l'eina amb una clau determinista, com ara:
execution_key = operation_id + tool_name + canonical_arguments_hash
Abans d'executar una eina, comproveu si aquesta clau està pendent, completada o fallada. Retorna el resultat emmagatzemat per a una execució completa en lloc d'executar-lo de nou. Per a les operacions els arguments de les quals poden canviar legítimament, cal l'aprovació a nivell d'aplicació o un nou identificador d'operació.
Un temps d'espera ambigu requereix un tractament especial. Si la connexió falla després de transmetre una sol·licitud, és possible que la passarel·la no sàpiga si s'ha produït la generació. Una clau d'idempotència compatible amb el proveïdor pot ajudar quan estigui disponible. En cas contrari, registreu el resultat com a desconegut i apliqueu una política de reproducció específica de la càrrega de treball en lloc de suposar que no ha passat res.
Suprimeix les rutes no saludables i exposa tots els intents
Un interruptor de circuit o una supressió temporal de l'estat impedeixen que cada sol·licitud nova torni a descobrir la mateixa ruta que falla. Obriu el circuit després d'una taxa d'error definit o un llindar de fallada consecutiva, després admet sondes limitades en un estat mig obert. Ajusteu els llindars per ruta i classe d'error, de manera que una sol·licitud de client amb un format incorrecte no pot fer que un model saludable sembli no disponible.
Enregistreu un esdeveniment a nivell de sol·licitud i un esdeveniment per intent. Els camps útils inclouen l'identificador d'operació, l'identificador d'intent, el proveïdor i el model seleccionats, la classe d'error, el codi d'estat, la latència, el recompte de testimonis, el cost estimat, el motiu de reserva, el resultat de la validació, l'estat del circuit i el resultat final. Redacta o hash les indicacions, les sortides i els arguments de l'eina segons els seus requisits de sensibilitat i retenció.
Les mètriques operatives útils inclouen el percentatge de retorn, els intents per sol·licitud completada, el percentatge d'esgotament del termini, el percentatge de rebuig de validació, els resultats ambigus, el cost per resposta acceptada i la latència per la ruta final. Una taxa d'èxit d'HTTP creixent juntament amb una taxa de rebuig de validació creixent és un advertiment que la disponibilitat del transport està emmascarant les falles dels contractes.
Llista de comprovació del llançament de la producció
- Definiu un contracte d'encaminament versionat per a cada classe de càrrega de treball.
- Mapegeu els errors del proveïdor en categories permanents, transitories, incompatibles, de resposta no vàlida i ambigües.
- Trieu un propietari de reintents i limiteu el total dels intents.
- Propaga una data límit absoluta mitjançant la passarel·la, el client proveïdor, la validació i l'execució d'eines.
- Creeu grups alternatius amb prova de capacitat en lloc d'una cadena de models global.
- Validar esquemes, trucades a eines, motius d'acabament i invariants de domini.
- Deduplica els efectes secundaris amb tecles d'operació i execució.
- Afegiu la supressió de ruta amb sondes mig obertes limitades.
- Registreu la latència del nivell d'intent, els testimonis, el cost, els errors i els resultats d'acceptació.
- Temps d'espera d'injectar, 429 s, errors 5xx seleccionats, JSON amb format incorrecte, desbordament de context i èxits lents en la posada en escena.
Comenceu amb una ruta principal i una alternativa compatible per a una única càrrega de treball de baix risc. Compareu la qualitat de la resposta acceptada, la latència i el cost abans d'ampliar la política. L'objectiu no és la taxa de retorn més alta possible. És un sistema acotat que o bé retorna una resposta que satisfà el contracte original o falla clarament abans de provocar un treball duplicat o un dany semàntic.