Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Toepassingen kunnen modellen van verschillende deductieservices gebruiken voor verschillende beurten van een gesprek. Een toepassing kan bijvoorbeeld modellen wijzigen op basis van gebruikerskeuze, modelmogelijkheden, beschikbaarheid of kosten.
Het wijzigen van de bestemming voor de volgende aanvraag is slechts één deel van de routering. Het nieuwe model heeft ook het voorafgaande gesprek nodig om door te gaan met dezelfde context. Of deze context kan worden ontvangen, is afhankelijk van waar de chatgeschiedenis is opgeslagen en wie deze beheert.
Opslag van chatgeschiedenis bepaalt de draagbaarheid
Inferentieservices ondersteunen verschillende benaderingen voor de gesprekstoestand. Bij sommige API's wordt verwacht dat de beller de relevante berichtgeschiedenis bij elke aanvraag levert. Andere API's slaan het gesprek op in de deductieservice en laten de aanroeper dit voortzetten door een id door te geven.
| Geschiedenismodel | Waar de berichten worden opgeslagen | Wat de beller verzendt |
|---|---|---|
| Door beller beheerd | In door toepassingen beheerd geheugen of duurzame opslag | De relevante berichtgeschiedenis plus eventuele nieuwe berichten bij elke aanvraag |
| Inferentieservice-beheerd | In opslag die door de inferentieservice wordt beheerd | Een servicespecifieke gespreks- of antwoord-id, plus eventuele nieuwe berichten. |
Sommige deductieservices ondersteunen beide benaderingen via verschillende API's of opties. OpenAI Responses heeft bijvoorbeeld de parameter store, die u kunt instellen op true voor door de inferentieservice beheerde chatgeschiedenis en op false voor door de aanroeper beheerde chatgeschiedenis.
Door aanroeper beheerde geschiedenis ondersteunt routering
Wanneer de beller de geschiedenis beheert, heeft deze vanaf eerdere beurten toegang tot de berichten. Een router kan een ander model of een andere inferentieservice selecteren, en de aanroeper kan die berichten met het volgende verzoek verzenden.
De geschiedenis hoeft niet in procesgeheugen te blijven. Het kan afkomstig zijn van duurzame opslag in toepassingseigendom, zolang de toepassing deze kan laden en naar de geselecteerde service kan verzenden. De bestemming moet ook ondersteuning bieden voor de berichtinhoud en -functies die eerder in het gesprek zijn gebruikt.
Routering van door de inferentieservice beheerde geschiedenislimieten
Wanneer een deductieservice de geschiedenis beheert, is het de bron van waarheid voor het gesprek. De aanroeper behoudt doorgaans een ondoorzichtige id in plaats van de berichten zelf.
Die identifier verwijst naar de toestand die door de oorspronkelijke service wordt bijgehouden. Toegang kan ook afhangen van het gebruikte account of project, eindpunt en de gebruikte inloggegevens waarmee het gesprek wordt aangemaakt. Een client voor een andere service kan de id niet gebruiken om de berichten op te halen. Een andere client voor dezelfde service heeft mogelijk ook geen toegang tot het gesprek als het een ander bereik gebruikt.
Een service kan ondersteuning bieden voor het wijzigen van modellen in een van de eigen opgeslagen gesprekken. Dat gedrag is specifiek voor de service en is geen draagbare routering. Een algemene router kan het gesprek aan de servicezijde niet overbrengen naar een andere provider zonder eerst de berichten op te halen of te reconstrueren.
| Scenario voor routering | Historisch model | Result |
|---|---|---|
| Schakelen tussen modellen van één provider | Door beller beheerd | De aanroeper kan de geschiedenis opnieuw afspelen naar het nieuwe model. Het nieuwe model moet ondersteuning bieden voor het bericht en de inhoudstypen die in eerdere versies worden gebruikt. |
| Schakelen tussen verschillende inferentieproviders | Door de beller beheerd | De beller kan de geschiedenis opnieuw afspelen naar de nieuwe provider. De nieuwe provider moet de rollen, inhoudstypen, tool-aanroepberichten en tool-resultaatberichten accepteren die in eerdere beurten zijn gebruikt. |
| Modellen wijzigen binnen één gesprek aan de serverzijde | Inferentieservice-beheerd | De switch werkt alleen als de deductieservice het bestaande gesprek laat doorgaan met het nieuwe model. De routeringsclient kan dit gedrag niet inschakelen. |
| Overschakelen naar een andere deductieservice | Inferentieservice-beheerd | De nieuwe service heeft geen toegang tot de gespreks-id van de oorspronkelijke service. Haal de berichten op of reconstrueer deze en start de nieuwe route met de door de beller beheerde geschiedenis. |
Zie Storage voor meer informatie over deze opslagmodellen.
Hoe Agent Framework runtimeroutering implementeert
Agent Framework kan de door de beller beheerde geschiedenis bieden die nodig is voor draagbare routering. In dit routeringspatroon is een chatgeschiedenisprovider de bron van waarheid voor het gesprek. Het kan berichten opslaan in de sessie van de agent of in door de toepassing beheerde opslag.
In Agent Framework omvat de door de aanroeper beheerde geschiedenis de lokale sessiestatus en aangepaste opslag voor chatgeschiedenis. Door de inferentieservice beheerde geschiedenis komt overeen met door de service beheerde opslag.
Voor een ChatClientAgent bevindt een routeringschatclient zich in de chatclientlaag van de agent-pijplijn. De agent en de sessie blijven hetzelfde, terwijl de routeringsclient voor elk verzoek een van meerdere benoemde IChatClient-exemplaren selecteert.
Een gerouteerde aanvraag volgt deze reeks:
- De chatgeschiedenisprovider laadt de gespreksgeschiedenis.
- De agent combineert de historie met de invoer voor de huidige beurt.
- De routeringsclient selecteert de actieve chatclient voor de sessie.
- De geselecteerde client ontvangt de volledige aanvraag.
- De chatgeschiedenisprovider slaat de nieuwe berichten op na de uitvoering.
Omdat de geselecteerde client de geschiedenis ontvangt die door de provider is geladen, kan de toepassing routes wijzigen zonder het gesprek handmatig opnieuw te bouwen.
De .NET SDK bevat de experimentele RoutePersistingRoutingChatClient. Stel de eerste route in met RoutePersistingRoutingChatClientOptions.DefaultRoute, inspecteer de route van een sessie met GetActiveRouteen wijzig deze met SetActiveRoute. Als u geen standaardroute instelt, gebruikt de client de eerste route die tijdens de bouw is opgegeven.
In Microsoft.Extensions.AI bestaan er meer routeringsclients waarmee verdere routeringsstrategieën mogelijk zijn.
Zie het voorbeeld van routering met meerdere modellen voor een volledige C#-implementatie.
Important
Elke chatclient die is geregistreerd als route, moet de door de beller beheerde geschiedenis gebruiken die wordt geleverd door een chatgeschiedenisprovider. De aanbieder kan die geschiedenis opslaan in de sessie of in door de toepassing beheerde opslag. Registreer geen route die gebruikmaakt van door de inference-service beheerde gespreksgeschiedenis.
Python ondersteuning is momenteel niet beschikbaar.
Go-ondersteuning is momenteel niet beschikbaar.