Het ondersteunen van meerdere modelaanbieders klinkt als een adapterprobleem: normaliseer het verzoek, roep een API aan en normaliseer het antwoord. Dat is weliswaar noodzakelijk, maar het biedt geen antwoord op de lastige productbeslissingen.
Welke provider is toegestaan voor deze tenant? Ondersteunt deze het vereiste outputcontract? Kan het verzoek de geconfigureerde gegevensgrens overschrijden? Wat moet er gebeuren als de eerste respons begint te streamen en vervolgens mislukt?
Geef een beschrijving van de taak voordat u het model selecteert
Ik wil dat de routering bij de taak begint. Een herschrijving van een zoekresultaat, een antwoord gericht op de klant en een planningsstap waarbij een tool wordt gebruikt, stellen verschillende eisen aan kwaliteit, latentie, contextgrootte en outputstructuur.
In de aanvraag moeten deze vereisten expliciet worden vermeld, samen met het huurdersbeleid en een begroting. Bij de selectie van modellen kunnen vervolgens kandidaten die niet aan de vereisten voldoen worden uitgesloten, waarna de overgebleven opties met elkaar kunnen worden vergeleken.
Ik geef de voorkeur aan capaciteitscontroles boven voorwaardelijke controles op basis van de naam van de provider die verspreid zijn over de applicatie. Een capaciteitsrecord kan informatie bevatten over toolondersteuning, gestructureerde uitvoer, streaminggedrag, contextbeperkingen en de implementatieregio die voor die configuratie is geverifieerd.
Zorg ervoor dat het gezamenlijke contract eerlijk blijft
Een algemene adapter moet zich richten op wat de applicatie daadwerkelijk nodig heeft. Hij mag niet doen alsof elke provider elke functie op identieke wijze implementeert.
Zo kunnen bijvoorbeeld tool-aanroepen tijdens het streamen stapsgewijs binnenkomen. Gebruiksgegevens kunnen in een andere fase binnenkomen dan tekst. Een provider kan een schema afwijzen dat door een andere provider wel wordt geaccepteerd. De adapter moet over vastgelegd gedrag beschikken om met deze verschillen om te gaan, en over tests die het daadwerkelijke transmissieformaat doorlopen.
Als een functie niet beschikbaar is, geef ik de voorkeur aan een duidelijke foutmelding of een expliciet goedgekeurd alternatief. Het stilletjes negeren van een vereiste beperking leidt tot een reactie die er succesvol uitziet, terwijl in feite het taakcontract wordt geschonden.
De alternatieve regeling moet het recht op uitkering in stand houden
Een fallback-keten mag alleen providers bevatten die voor het huidige verzoek zijn toegestaan. Beschikbaarheid heeft geen voorrang boven een tenantbeperking, een regio-eis of een bestedingslimiet.
Ik maak onderscheid tussen verschillende soorten fouten. Een tijdelijke servicefout kan een reden zijn om een andere provider te kiezen. Ongeldige inloggegevens vereisen een aanpassing van de configuratie. Een ongeldig verzoek leidt waarschijnlijk overal tot dezelfde foutmelding. Een weigering moet ook worden geïnterpreteerd volgens de regels van de applicatie, in plaats van automatisch te worden beschouwd als een transportfout.
Elke extra poging kost tijd en kan geld kosten. De router heeft één totale deadline en één pogingenbudget nodig, en niet telkens een nieuw budget wanneer hij van provider verandert.
Bepaal wat ‘gedeeltelijke uitvoer’ inhoudt
Als er nog geen resultaat bij de gebruiker is aangekomen, kan het relatief eenvoudig zijn om het bij een andere aanbieder opnieuw te proberen. Zodra er al een deel van een antwoord is weergegeven, kan het toevoegen van het nieuwe antwoord van een tweede model leiden tot een verwarrende of tegenstrijdige boodschap.
Ik zou ofwel het genereren van gegevens in de buffer bewaren tot het gekozen vrijgavepunt, ofwel expliciet aangeven dat er een fout is opgetreden en een herstart aanbieden. De juiste keuze hangt af van het product, maar moet wel weloverwogen zijn.
De uitvoering van tools voegt nog een grens toe. Bij een herhalingspoging van een model mag een reeds voltooide externe actie niet worden herhaald, louter omdat de volgende planningsstap is mislukt. Het operatielogboek hoort buiten de provideradapter te vallen.
Evalueer routeringsbeslissingen, inclusief situaties waarin de dienstverlening is verslechterd
Mijn routetrace bevat het taaktype, geschikte kandidaten, de gekozen aanbieder, de reden voor terugval, de beleidsversie, de latentie en het geregistreerde verbruik. Gevoelige inhoud van prompts hoeft niet in elke statistiek te worden gekopieerd.
Ik maak ook onderscheid in de status van afhankelijkheden op basis van de omvang van de storing. Een verkeerd geconfigureerde interne assistent hoeft niet per se het circuit te onderbreken voor een klantchatpad dat verder in orde is. De juiste grens voor de circuitbreaker hangt af van welke inloggegevens, modellen en implementaties dezelfde storingsomstandigheden delen.
Een ontwerp met meerdere leveranciers is nuttig wanneer het ervoor zorgt dat de beloften van het product ook onder veranderende omstandigheden worden nagekomen. De technische werkzaamheden zijn erop gericht om die beloften zo expliciet te maken dat elke route, inclusief de noodroute, kan worden gecontroleerd.
Bijgewerkt op 25 september 2026.