Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Le applicazioni possono usare modelli di servizi di inferenza diversi per turni diversi di una conversazione. Ad esempio, un'applicazione potrebbe modificare i modelli in base alla scelta dell'utente, alle funzionalità del modello, alla disponibilità o ai costi.
La modifica della destinazione per la richiesta successiva è solo una parte del routing. Il nuovo modello richiede anche la conversazione precedente per continuare con lo stesso contesto. Se può ricevere tale contesto dipende dalla posizione in cui viene archiviata la cronologia delle chat e da chi la controlla.
L'archiviazione della cronologia delle chat determina la portabilità
I servizi di inferenza supportano approcci diversi allo stato della conversazione. Alcune API prevedono che il chiamante fornisca la cronologia dei messaggi pertinente a ogni richiesta. Altre API archiviano la conversazione nel servizio di inferenza e consentono al chiamante di continuare passando un identificatore.
| Modello di cronologia | Posizione in cui vengono archiviati i messaggi | Cosa invia il chiamante |
|---|---|---|
| Gestito dal chiamante | Nella memoria controllata dall'applicazione o nell'archiviazione durevole | Cronologia dei messaggi pertinenti e tutti i nuovi messaggi con ogni richiesta |
| Gestita-da-servizio-inferenza | Nell'archiviazione gestita dal servizio di inferenza | Identificatore di conversazione o risposta specifico del servizio, oltre a eventuali nuovi messaggi. |
Alcuni servizi di inferenza supportano entrambi gli approcci tramite API o opzioni diverse. Ad esempio, le risposte OpenAI hanno il store parametro che è possibile impostare su true per la cronologia delle chat gestite dal servizio di inferenza e su per false il chiamante gestito.
La cronologia gestita dal chiamante supporta il routing
Quando il chiamante gestisce la cronologia, ha accesso ai messaggi dei turni precedenti. Un router può selezionare un altro modello o un altro servizio di inferenza e il chiamante può inviare tali messaggi con la richiesta successiva.
La cronologia non deve rimanere in memoria di processo. Può provenire da un archivio durevole di proprietà dell'applicazione, purché l'applicazione possa caricarla e inviarla al servizio selezionato. La destinazione deve supportare anche il contenuto e le funzionalità del messaggio usati in precedenza nella conversazione.
Routing basato sui limiti della cronologia gestiti dal servizio di inferenza
Quando un servizio di inferenza gestisce la cronologia, è la fonte attendibile per la conversazione. Il chiamante mantiene in genere un identificatore opaco anziché i messaggi stessi.
Tale identificatore fa riferimento allo stato mantenuto dal servizio di origine. L'accesso può anche dipendere dall'account o dal progetto, dall'endpoint e dalle credenziali usate per creare la conversazione. Un client per un altro servizio non può usare l'identificatore per recuperare i messaggi. Un altro client per lo stesso servizio potrebbe anche non essere in grado di accedere alla conversazione se usa un ambito diverso.
Un servizio potrebbe supportare la modifica dei modelli all'interno di una delle proprie conversazioni archiviate. Questo comportamento è specifico di questo servizio e non costituisce routing portabile. Un router generale non può trasferire la conversazione sul lato servizio a un altro provider senza prima recuperare o ricostruire i messaggi.
| Scenario di instradamento | Modello di cronologia | Result |
|---|---|---|
| Passare da un modello all'altro di uno stesso provider | Gestito dal chiamante | Il chiamante può inviare nuovamente la cronologia al nuovo modello. Il nuovo modello deve supportare i tipi di messaggio e di contenuto usati nei turni precedenti. |
| Passare da provider di inferenza diversi | Gestito dal chiamante | Il chiamante può riprodurre la cronologia al nuovo provider. Il nuovo provider deve accettare i ruoli, i tipi di contenuto, i messaggi di chiamata agli strumenti e i messaggi dei risultati degli strumenti usati nei turni precedenti. |
| Modificare i modelli all'interno di una conversazione sul lato servizio | Gestita-da-servizio-inferenza | L'opzione funziona solo se il servizio di inferenza consente alla conversazione esistente di continuare con il nuovo modello. Il client di routing non può abilitare questo comportamento. |
| Passare a un servizio di inferenza diverso | Gestita-da-servizio-inferenza | Il nuovo servizio non può accedere all'identificatore di conversazione del servizio originale. Recupera o ricostruisci i messaggi e avvia il nuovo percorso con cronologia gestita dal chiamante. |
Per altre informazioni su questi modelli di archiviazione, vedere Archiviazione.
Come Agent Framework implementa il routing di runtime
Agent Framework può fornire la cronologia gestita dal chiamante necessaria per il routing portabile. In questo modello di routing, un provider della cronologia della chat è la fonte autorevole della conversazione. Può archiviare i messaggi nella sessione dell'agente o nella risorsa di archiviazione di proprietà dell'applicazione.
In Agent Framework la cronologia gestita dal chiamante include lo stato della sessione locale e l'archiviazione della cronologia chat personalizzata. La cronologia gestita dal servizio di inferenza corrisponde all'archiviazione gestita dal servizio.
Per un ChatClientAgent, un client di instradamento della chat si trova nel livello del client di chat della pipeline dell'agente. L'agente e la relativa sessione rimangono invariati mentre il client di routing seleziona una delle diverse istanze denominate IChatClient per ogni richiesta.
Una richiesta indirizzata segue questa sequenza:
- Il provider della cronologia delle chat carica la cronologia delle conversazioni.
- L'agente combina la cronologia con l'input per il turno corrente.
- Il client di routing seleziona il client di chat attivo per la sessione.
- Il client selezionato riceve la richiesta completa.
- Il provider della cronologia della chat archivia i nuovi messaggi al termine dell'esecuzione.
Poiché il client selezionato riceve la cronologia caricata dal provider, l'applicazione può modificare le route senza ricompilare manualmente la conversazione.
.NET SDK fornisce l'oggetto sperimentale RoutePersistingRoutingChatClient. Impostare la route iniziale con RoutePersistingRoutingChatClientOptions.DefaultRoute, esaminare la route di una sessione con GetActiveRoutee modificarla con SetActiveRoute. Se non si imposta una route predefinita, il client usa la prima route fornita durante la costruzione.
In Microsoft.Extensions.AI esistono altri client di routing che consentono ulteriori strategie di instradamento.
Per un'implementazione C# completa, vedere l'esempio di routing a più modelli .
Importante
Ogni client di chat registrato come route deve usare la cronologia gestita dal chiamante fornita da un provider di cronologia chat. Il provider può archiviare la cronologia nella sessione o nell'archiviazione di proprietà dell'applicazione. Non registrare un percorso che utilizza la cronologia delle conversazioni gestita dal servizio di inferenza.
Python supporto non è attualmente disponibile.
Il supporto di Go non è attualmente disponibile.