Aggiunta di provider di contesto

La pagina precedente ha illustrato in che modo il middleware esegue il wrapping della pipeline di esecuzione dell'agente con problemi trasversali, ovvero registrazione, guardrail, gestione degli errori, senza toccare la logica di base dell'agente. Ma il middleware gestisce il modo in cui viene eseguito l'agente, non quello che l'agente conosce. Finora, le conoscenze dell'agente provengono da due fonti: i dati di addestramento e tutto ciò che l'utente dice nel turno corrente.

È un problema. Un agente utile ha bisogno di più di questo. È necessario ricordare ciò che l'utente ha detto tre turni fa, conoscere le preferenze dell'utente o estrarre fatti rilevanti da una knowledge base, tutto prima di iniziare a generare una risposta. Gli strumenti possono recuperare informazioni, ma sono reattive: il modello deve decidere di chiamarle. Se il modello non capisce di aver bisogno di contesto, non lo chiederà.

I provider di contesto risolveranno questo problema. Si tratta di componenti eseguiti prima e dopo ogni chiamata dell'agente, inserendo in modo proattivo le informazioni pertinenti nella finestra di contesto ed estraendo facoltativamente lo stato dalla risposta da archiviare per un uso futuro. Forniscono all'agente memoria, personalizzazione e accesso a conoscenze esterne, senza modificare le istruzioni o il codice dell'agente.

Quando usare questa opzione

Aggiungere provider di contesto all'agente quando:

  • L'agente necessita della cronologia delle conversazioni : deve ricordare ciò che è stato detto nei turni precedenti, non solo il messaggio corrente.
  • Si vogliono inserire dati specifici dell'utente , ovvero profili, preferenze, dettagli dell'account o stato della sessione, in modo che l'agente possa personalizzare le risposte.
  • È necessaria la generazione aumentata dal recupero (RAG) — attingendo automaticamente a documenti o fatti pertinenti da una base di conoscenza prima di ogni risposta.
  • L'agente richiede istruzioni dinamiche : contesto che cambia tra le chiamate in base all'ora del giorno, alla posizione dell'utente o ad altre condizioni di runtime.
  • Si vuole separare l'origine dati dalla logica dell'agente . L'agente non deve sapere da dove proviene il contesto, ma solo che è disponibile.

Perché non usare solo gli strumenti?

Gli strumenti e i provider di contesto consentono entrambi agli agenti di accedere a informazioni esterne, ma funzionano in modi fondamentalmente diversi:

Aspetto Tools Provider di contesto
Attivazione Reattivo: il modello decide quando chiamare uno strumento Proattivo: viene eseguito automaticamente prima di ogni chiamata
Controllo Basata su modello: il modello sceglie quale strumento, quando e con quali argomenti Guidata dallo sviluppatore: si decide quale contesto è sempre disponibile
Visibilità Il modello deve conoscere l'esistenza di uno strumento e valutare che sia pertinente Il contesto viene inserito in modo trasparente: il modello lo considera come parte della richiesta
caso d'uso Azioni e ricerche su richiesta: "eseguire ricerche nel Web", "eseguire query sul database" Contesto sempre presente: cronologia delle conversazioni, profili degli utenti, conoscenze pre-caricate.
Costo del token Token spesi solo quando viene chiamato lo strumento Token spesi per ogni chiamata (il contesto è sempre nel prompt)

Nessuno dei due è strettamente migliore. Molti agenti usano entrambi i provider di contesto per informazioni che devono essere sempre presenti (cronologia, profilo utente, conoscenza principale) e strumenti per informazioni che l'agente deve recuperare su richiesta (risultati della ricerca in tempo reale, query di database, chiamate API).

Suggerimento

Una buona regola generale: se l'agente deve avere queste informazioni ogni volta che viene eseguita, usare un provider di contesto. Se l'agente deve recuperarlo solo quando pertinente, usare uno strumento.

Come funzionano i provider di contesto

I provider di contesto partecipano a un ciclo di vita in due fasi intorno a ogni chiamata dell'agente:

┌──────────────────────────────────────────────────────────────┐
│  Caller: agent.run("What's the return policy?")              │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  BEFORE RUN — each context provider injects context          │
│                                                              │
│  • History provider loads past conversation messages         │
│  • Memory provider retrieves relevant facts/preferences      │
│  • RAG provider searches knowledge base and adds results     │
│  • Custom provider injects user profile, time, location      │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  Agent core — model sees original input + all injected       │
│  context and generates a response                            │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  AFTER RUN — each context provider processes the response    │
│                                                              │
│  • History provider saves the new messages                   │
│  • Memory provider extracts facts to remember for later      │
│  • Custom provider updates session state                     │
└──────────────────────────────────────────────────────────────┘

Punti principali:

  1. I provider di contesto vengono eseguiti automaticamente. È possibile registrarli una sola volta durante la creazione dell'agente. Successivamente, partecipano a ogni invocazione senza alcun codice aggiuntivo da parte tua.
  2. Più provider compongono insieme. È possibile registrare diversi provider di contesto, ovvero un provider di cronologia, un provider rag e un provider personalizzato, e contribuiscono tutti alla stessa finestra di contesto. I loro contributi vengono uniti nell'ordine di registrazione.
  3. I provider hanno due ganci. L'hook prima inserisce il contesto (messaggi, istruzioni, strumenti) nel prompt. L'hook after elabora la risposta, archiviando messaggi, estraendo memorie o aggiornando lo stato.
  4. I provider sono in grado di tenere conto delle sessioni. I provider di contesto ricevono la sessione corrente, in modo che possano caricare e archiviare i dati con ambito specifico a una conversazione. Per informazioni sul funzionamento della gestione delle sessioni, vedere Sessioni .

Suggerimento

Per una visualizzazione dettagliata del percorso in cui i provider di contesto si trovano nella pipeline di esecuzione completa dell'agente, insieme al middleware e al client di chat, vedere Architettura della pipeline dell'agente.

Gestione della finestra di contesto

Ogni parte di contesto inserita utilizza i token dalla finestra di contesto del modello. La storia cresce con ogni giro. Risultati RAG aggiungono blocchi di documenti. I profili utente aggiungono metadati. Se il totale supera il limite del modello, le informazioni meno recenti o meno rilevanti vengono troncate, potenzialmente perdendo contesto importante.

La gestione delle finestre di contesto è una considerazione fondamentale quando si usano provider di contesto: le strategie di compattazione riepilogano o tagliano la cronologia precedente per rimanere entro i limiti dei token mantenendo al tempo stesso le informazioni chiave. Vedere Compattazione.

Suggerimento

Per un'esperienza pratica con provider di memoria e contesto, vedere Passaggio 4: Memoria nell'esercitazione Introduttiva.

Importante

Non è consigliabile mantenere una finestra di contesto molto lunga, perché le prestazioni del modello possono peggiorare man mano che aumenta la finestra di contesto. Se l'agente inizia a riscontrare prestazioni ridotte, è consigliabile usare strategie di compattazione per ridurre le dimensioni del contesto.

Considerazioni

Considerazione dettagli
Budget dei token Ogni contesto inserito utilizza i token. Monitorare attentamente le dimensioni totali del contesto, soprattutto quando si combinano più provider. Se il contesto cresce illimitato, le informazioni importanti vengono troncate silenziosamente.
Latenza di recupero I provider di contesto che eseguono query su servizi esterni (database, indici di ricerca, API) aggiungono latenza a ogni chiamata. Usare la memorizzazione nella cache, il pool di connessioni e le operazioni asincrone per mantenere l'accesso rapido.
Relevance L'inserimento di un contesto irrilevante non comporta solo lo spreco di token, ma può ridurre attivamente le risposte del modello diluendo il segnale. Assicuratevi che i provider inseriscano informazioni mirate e pertinenti.
Rancidità Il contesto memorizzato nella cache o precaricato può diventare obsoleto. Progettare fornitori per aggiornare i dati a intervalli appropriati e valutare se un contesto leggermente datato è accettabile per il caso d'uso.
Componibilità Quando più provider contribuiscono alla stessa finestra di contesto, i contributi possono interagire in modi imprevisti. Metti insieme i fornitori di test, non solo singolarmente, per garantire che il contesto combinato abbia senso.

Passaggi successivi

Ora che l'agente dispone di strumenti, competenze, middleware e provider di contesto, il passaggio successivo è rappresentato dagli agenti come strumenti, ossia comporre agenti utilizzando un agente come strumento per un altro, consentendo specializzazione e delega.

Agenti come strumenti

Approfondimento:

  • Last updated on