Betrouwbare LLM API-routing: time-outs, nieuwe pogingen en modelfallbacks zonder semantische regressies

Een fallback-verzoek is niet succesvol louter omdat een ander model HTTP 200 heeft geretourneerd. De vervanging kan het oorspronkelijke latentiebudget overschrijden, vereiste JSON-velden weglaten, een andere tool aanroepen of een antwoord opleveren met een wezenlijk andere semantiek. Betrouwbare LLM API-routering vereist daarom meer dan een geordende lijst met modellen: er is een contract, een foutclassificator, een beleid voor begrensde pogingen en validatie vóór acceptatie nodig.

De centrale regel is simpel: probeer het alleen opnieuw als de fout aannemelijk tijdelijk is, en val alleen terug als de volgende route nog steeds aan het oorspronkelijke verzoekcontract kan voldoen.

Definieer het routeringscontract voordat u modellen kiest

Begin met te beschrijven wat een succesvol antwoord moet opleveren. Dit routeringscontract moet machinaal leesbaar zijn en aan elke werklast of verzoekklasse worden gekoppeld.

{
  "workload": "factuurextractie",
  "modaliteiten": ["tekst", "afbeelding"],
  "max_input_tokens": 50000,
  "requires_tools": false,
  "gestructureerde_uitvoer": {
    "vereist": waar,
    "schema_id": "factuur-v3",
    "streng": waar
  },
  "allowed_model_classes": ["documentextractie"],
  "max_kosten_usd": 0,08,
  "deadline_ms": 8000

Het contract moet de vereiste modaliteiten, contextcapaciteit, toolondersteuning, gestructureerd uitvoergedrag, acceptabele modelklassen, maximale kosten en de end-to-end deadline omvatten. Voeg waar nodig toepassingsspecifieke beperkingen toe, zoals toegestane regio's, minimale uitvoerlengte of een vereiste eindreden.

Aanbeveling: onderhoud afzonderlijke, geteste routegroepen voor platte tekst, schema-beperkte uitvoer, toolgebruik, visie en verzoeken met een lange context. Een model dat een acceptabele tekstfallback is, is niet automatisch een acceptabele fallback voor het aanroepen van tools of beeldinvoer.

Classificeer de fout voordat u actie onderneemt

Authenticatiefouten, verkeerd ingedeelde verzoeken, snelheidslimieten en serverstoringen vereisen verschillende reacties. Als u elke niet-succesvolle reactie behandelt als een hernieuwbare reactie, verspilt u capaciteit en kunt u defecten verbergen.

Feit: niet-succesvolle verzoeken met een tariefbeperking kunnen nog steeds meetellen voor de providerlimieten. Agressieve onmiddellijke nieuwe pogingen kunnen de beperking daarom verdiepen in plaats van oplossen. Nieuwe pogingen verbruiken ook extra capaciteit tijdens een storing, en beleid voor nieuwe pogingen op verschillende applicatielagen kan de resulterende belasting vermenigvuldigen.

Aanbeveling: laat één laag eigen pogingen ondernemen om modellen te genereren. In een typische architectuur is de AI API-gateway de juiste eigenaar, omdat deze de routestatus, de geschiedenis van pogingen, de latentie en de kosten ziet. Schakel waar mogelijk automatische nieuwe pogingen uit bij clients op een lager niveau, of tel ze expliciet mee in hetzelfde pogingsbudget.

Besteed één end-to-end latentiebudget

Time-outs per poging zijn onvoldoende. Drie pogingen met een time-out van vijf seconden kunnen een beoogde bewerking van vijf seconden omzetten in een reactie van vijftien seconden, voordat uitstel en validatie zijn inbegrepen.

Regel een absolute deadline wanneer het verzoek de gateway binnenkomt. Bereken vóór elke poging de resterende tijd:

resterend = deadline - huidige_tijd
vereist = connect_allowance + generatie_allowance + validatie_allowance
indien resterend < vereist:
    stop_zonder_launching_another_attempt

Voor een deadline van acht seconden zou een redelijke initiële toewijzing 300 ms kunnen reserveren voor gatewaywerk en uiteindelijke validatie, tot 4,5 seconden voor de primaire route en ongeveer 3,2 seconden voor één fallback. Deze waarden zijn een voorbeeld en geen benchmark. Ze moeten worden afgeleid van gemeten latentieverdelingen voor de daadwerkelijke providers, modellen, regio's en uitvoergroottes.

Gebruik een beperkte exponentiële uitstel met jitter voor tijdelijke nieuwe pogingen:

vertraging = willekeurig(0, min(cap, basis * 2^retry_index))

Hints voor opnieuw proberen van de provider, zoals een waarde voor opnieuw proberen na, moeten voorrang krijgen als ze binnen de resterende deadline vallen. Stop na een klein aantal pogingen. Een algemeen beleid is één primaire poging plus één fallback, met een optionele nieuwe poging via dezelfde route alleen bij een vroegtijdige verbindingsfout die geen factureerbare uitvoer had kunnen opleveren.

Trade-off: sequentiële terugval verbetert de beschikbaarheid, maar verhoogt de staartlatentie. Parallelle of afgedekte verzoeken kunnen de latentie tijdens vertragingen verminderen, maar ze verbruiken meer capaciteit en kunnen kosten met zich meebrengen voor meerdere succesvolle generaties. Het afdekken moet worden beperkt tot latentiekritieke werklasten zonder bijwerkingen, met annulerings- en kostenbeheersing.

Selecteer fallbacks op capaciteit, niet op rang

Een fallback-tabel moet compatibiliteit coderen in plaats van een globale voorkeursvolgorde. Filter kandidaatroutes op basis van het contract voordat u rekening houdt met de status, latentie of prijs.

kandidaten = routes
  .filter(ondersteunt_vereiste_modaliteiten)
  .filter(context_limit >= geschatte_invoergrootte)
  .filter(ondersteunt_vereiste_tools)
  .filter(ondersteunt_requested_schema_mode)
  .filter(model_class in toegestane_model_classes)
  .filter(geschatte_kosten <= resterende_kosten_budget)
  .filter(niet_tijdelijk_onderdrukt)
geselecteerd = rang (kandidaten, gezondheid, latentie, kosten)

Ondersteuning voor gestructureerde uitvoer verdient expliciete tests. Zelfs als twee routes schema-beperkte generatie adverteren, kunnen ze verschillende JSON-schema-subsets ondersteunen of edge-cases anders interpreteren. Modellen die geschikt zijn voor tools kunnen eveneens verschillen in toolselectie, argumentconstructie en parallelle aanroepgedrag.

Feit: het wisselen van modelfamilies kan de beschikbaarheid van transport behouden, terwijl de stijl, redeneerkwaliteit, veiligheidsgedrag, tokenisatie en gereedschapsselectie veranderen. HTTP-succes is geen bewijs van semantische gelijkwaardigheid.

Voorspelling: naarmate modelcatalogi zich uitbreiden, zal het productieroutingbeleid steeds vaker gebruik maken van versiebeheerprofielen en werklastspecifieke acceptatietests in plaats van statische modellijsten. Beschouw dit als een ontwerprichting, en niet als een garantie voor het gedrag van de provider.

Valideer het antwoord voordat u het accepteert

Voer elk antwoord, inclusief het primaire antwoord, via dezelfde acceptatiepijplijn uit. Validatie moet plaatsvinden voordat het resultaat in de cache wordt opgeslagen, intern als succesvol wordt gefactureerd of wordt doorgegeven aan een tool-uitvoerder.

1. Bevestig dat het transport is voltooid en dat de antwoordenvelop kan worden geparseerd.
2. Controleer de reden van voltooiing en weiger afkapping wanneer volledige uitvoer vereist is.
3. Gestructureerde uitvoer valideren aan de hand van het oorspronkelijke schema.
4. Verifieer de vereiste velden, opsommingswaarden en toepassingsinvarianten.
5. Sta alleen geregistreerde toolnamen toe en valideer argumenten tegen elk toolschema.
6. Pas werklastspecifieke semantische controles toe waar valse acceptatie kostbaar zou zijn.

Voor het extraheren van facturen kunnen semantische controles een niet-negatief totaal, een ondersteunde valutacode en regelitemtotalen vereisen binnen een expliciet gedefinieerde tolerantie. Voor classificatie is een label uit de toegestane set vereist. Voor het genereren van code kan parseren of compileren geschikt zijn. Deze controles bewijzen geen kwaliteit, maar voorkomen wel dat voorspelbare contractovertredingen als succes worden beschouwd.

Repareer niet stilletjes elk verkeerd geformuleerd antwoord. Deterministische normalisatie, zoals het verwijderen van onschadelijke omringende witruimte, kan acceptabel zijn. Het raden van ontbrekende financiële velden of het herschrijven van toolargumenten verandert de betekenis van het model en zou tot afwijzing of menselijke beoordeling moeten leiden.

Scheid nieuwe generatiepogingen van bijwerkingen

LLM-verzoeken maken gewoonlijk gebruik van HTTP POST, wat niet inherent idempotent is. Belangrijker nog is dat een modelreactie een externe actie kan initiëren, zoals het in rekening brengen van een betaalmethode, het verzenden van een bericht, het aanmaken van een ticket of het aanpassen van de infrastructuur. Het opnieuw proberen te genereren en het opnieuw afspelen van die actie zijn afzonderlijke beslissingen.

Wijs een bewerkings-ID toe aan de applicatiegrens en een poging-ID aan elke modelaanroep. Houd de uitvoeringsstatus van het gereedschap aan tegen een deterministische sleutel, zoals:

execution_key = operatie_id + tool_name + canonical_arguments_hash

Controleer voordat u een tool uitvoert of die sleutel in behandeling is, voltooid of mislukt is. Retourneer het opgeslagen resultaat voor een voltooide uitvoering in plaats van het opnieuw uit te voeren. Voor bewerkingen waarvan de argumenten legitiem kunnen veranderen, is goedkeuring op applicatieniveau of een nieuwe bewerkings-ID vereist.

Een dubbelzinnige time-out vereist een speciale behandeling. Als de verbinding mislukt nadat een verzoek is verzonden, weet de gateway mogelijk niet of er sprake is van generatie. Een door de provider ondersteunde idempotentiesleutel kan helpen, indien beschikbaar. Anders registreert u de uitkomst als onbekend en past u een werklastspecifiek herhalingsbeleid toe in plaats van aan te nemen dat er niets is gebeurd.

Onderdruk ongezonde routes en maak elke poging zichtbaar

Een stroomonderbreker of tijdelijke onderdrukking van de status voorkomt dat elk nieuw verzoek dezelfde falende route opnieuw ontdekt. Open het circuit na een gedefinieerde foutfrequentie of drempel voor opeenvolgende storingen en laat vervolgens beperkte sondes toe in een halfopen toestand. Stem de drempelwaarden af op route en foutklasse, zodat een onjuist opgemaakt clientverzoek er niet voor kan zorgen dat een gezond model niet beschikbaar lijkt.

Neem één gebeurtenis op verzoekniveau en één gebeurtenis per poging op. Nuttige velden zijn onder meer bewerkings-ID, poging-ID, geselecteerde provider en model, foutklasse, statuscode, latentie, tokenaantallen, geschatte kosten, terugvalreden, validatieresultaat, circuitstatus en uiteindelijke uitkomst. Bewerk of hash prompts, uitvoer en toolargumenten op basis van hun gevoeligheid en bewaarvereisten.

Handige operationele statistieken zijn onder meer het terugvalpercentage, het aantal pogingen per voltooid verzoek, het uitputtingspercentage van de deadline, het percentage afgewezen validaties, dubbelzinnige resultaten, de kosten per geaccepteerd antwoord en de latentie per uiteindelijke route. Een stijgend HTTP-succespercentage naast een stijgend validatie-afwijzingspercentage is een waarschuwing dat de beschikbaarheid van transport contractmislukkingen maskeert.

Checklist voor productie-uitrol

• Definieer een routeringscontract met versiebeheer voor elke werkbelastingklasse.
• Breng providerfouten in permanente, tijdelijke, incompatibele, ongeldige respons- en dubbelzinnige categorieën.
• Kies één eigenaar voor een nieuwe poging en beperk het totale aantal pogingen.
• Propageer een absolute deadline via gateway, providerclient, validatie en uitvoering van tools.
• Bouw op mogelijkheden geteste reservegroepen in plaats van één mondiale modelketen.
• Valideer schema's, toolaanroepen, eindredenen en domeininvarianten.
• Ontdubbel bijwerkingen met bedienings- en uitvoeringstoetsen.
• Voeg routeonderdrukking toe met begrensde halfopen sondes.
• Log latentie op pogingsniveau, tokens, kosten, mislukkingen en acceptatieresultaten.
• Injecttime-outs, 429s, geselecteerde 5xx-fouten, verkeerd opgemaakte JSON, contextoverloop en langzame successen in de fasering.

Begin met een primaire route en één compatibele fallback voor één werklast met laag risico. Vergelijk de kwaliteit, latentie en kosten van geaccepteerde reacties voordat u het beleid uitbreidt. Het doel is niet het hoogst mogelijke terugvalpercentage. Het is een begrensd systeem dat ofwel een antwoord retourneert dat voldoet aan het oorspronkelijke contract, ofwel duidelijk faalt voordat het dubbel werk of semantische schade veroorzaakt.

Gerelateerd lezen

• eerdere API-testopmerking
• vorige Engelstalige artikel