Contatore di token LangChain: stima di audit e copertura dell'utilizzo

La risposta utile non è scegliere un contatore di token LangChain. Utilizzare due contatori diversi per due decisioni diverse. Eseguire count tokens approximately() prima di una chiamata di modello quando hai bisogno di una rapida stima della pressione di contesto. Leggi il AIMessage.usage metadata riportato dal fornitore dopo la chiamata quando hai bisogno dell'utilizzo osservato di input, output, cache o ragionamento. Poi confrontare i registri di utilizzo con un modello di chiamata atteso manifesto. Senza quell'ultimo controllo di copertura, un totale ordinato può essere basso solo perché una chiamata non è mai stata contata. Questa distinzione conta per un agente. Una stima della storia del messaggio può aiutare a decidere se tagliare il contesto. Non può dimostrare che il fornitore ha elaborato, che ha fatturato, se un nuovo tentativo ha emesso un utilizzo o se una chiamata di modello annidato è sfuggita al richiamo. La questione operativa è quindi: Qual è il sistema di conteggio che sostiene questa decisione, e come sappiamo che ogni chiamata attesa l'ha raggiunta? Trattare l'approssimazione e l'utilizzo del fornitore come prove separate L'attuale riferimento Python di LangChain descrive count tokens approximately() come una semplice approssimazione. Al suo impostazione predefinita, divide i caratteri per quattro, aggiunge tre gettoni per messaggio e ruota in modo conservatore. La funzione conta il contenuto del messaggio e i ruoli. Esso contiene anche le chiamate degli strumenti AI, gli ID delle chiamate dei messaggi degli strumenti, i nomi opzionali, un'allocazione di immagine fissa e gli schemi degli strumenti forniti tramite l'argomento tools . La documentazione afferma esplicitamente che per i conti precisi sono necessari tokenizzatori specifici del modello. Ciò rende utile la funzione prima dell'invocazione: Il dettaglio tools=bound tools non è cosmetico. L'implementazione serializza ogni schema fornito e aggiunge i suoi caratteri all'approssimazione. Se un modello è legato agli strumenti ma il contatore riceve solo messages , la stima può omettere una grande superficie di input ripetuto. Al contrario, il passaggio degli strumenti non rende l'effetto esatto. Essa rimane una stima basata su un rapporto generico e quote fisse. Dopo l'invocazione, utilizzare i metadati contenuti nella AIMessage restituita: LangChain standardizza UsageMetadata attorno a input tokens , output tokens e total tokens , con mappe dettagliate di input e output opzionali. Il suo esempio include la creazione di cache, le letture di cache, l'audio e il ragionamento. Optional è la parola importante. Un campo cache read mancante è una prova non disponibile, non la prova che il valore è stato zero. Conservare tale distinzione in magazzino invece di riempire i dettagli assenti con 0 . Per più chiamate, UsageMetadataCallbackHandler aggrega AIMessage.usage metadata tra i modelli: L'aggregazione è conveniente, ma l'aggregazione risponde a ciò che il gestore ha visto, non a ciò che il flusso di lavoro avrebbe dovuto chiamare. Indicare ad ogni tentativo di modello una call id stabile, una attempt id , il nome del fornitore/modello risolto e un timestamp. Un nuovo tentativo è un secondo tentativo, non una correzione del primo contatore. Costruire un test di copertura attorno al manifesto di chiamata modello Iniziare dal lavoro previsto, non da qualsiasi fila di utilizzo che si verifichi. Per una corsa in quattro fasi, il manifesto potrebbe richiedere plan:1 , retrieve:1 , draft:2 e verify:1 . Il suffisso è il numero di tentativo. Il verificatore unisce quindi i tentativi attesi a tre forme di prova: una approssimazione previo volo, compresi i messaggi e gli schemi degli strumenti richiesti; l'utilizzo riportato dal fornitore del messaggio restituito o del richiamo di ritorno; la ricevuta a livello di attività che dice che la fase ha prodotto il suo effetto atteso. La combinazione produce stati più utili di un totale: Stato Che cosa esiste Interpretazione sicura provider reported utilizzo del fornitore, con l'identità della chiamata l'uso osservato per tale tentativo approximate only Previazione del volo, nessun utilizzo del fornitore stima del contesto; utilizzo della fatturazione non disponibile missing call riga manifesto, nessuna osservazione non è mai stato eseguito detail unavailable totale del fornitore, mancano i dettagli della cache/ragione attese totale può essere utilizzata; l'analisi dei componenti è bloccata duplicate attempt due righe di utilizzo per un ID di tentativo rischio di aggregazione; fissa l'identità prima di sommare L'apparecchio che accompagna sembra deliberatamente plausibile, pur restando incompleto. Contiene quattro chiamate attese. Due hanno l'uso del fornitore, uno ha solo un'approssimazione, e uno non ha osservazione. Le due file di fornitori si sommano a 1.451 token. Questo numero è aritmeticamente corretto e operativamente incompleto. Eseguire l' audit: Il risultato è: Le due richieste che presentano entrambe le forme di prova dimostrano anche il motivo per cui una stima dovrebbe mantenere la propria etichetta. L'approssimazione è stata inferiore del 5,0% al totale dei fornitori per una chiamata e del 16,5% per un'altra. Questa cornice non afferma che tali percentuali siano generalizzate; i valori sono dati di prova fissi. Essa dimostra che l'audit mantiene le stime al di fuori del totale dei fornitori osservati e può rivelare i disaccordi senza trattare alcun esempio come fattore di calibrazione universale. Un sottile dettaglio attuale della realizzazione merita di essere messo in guardia. La use usage metadata scaling=True opzionale di LangChain prende il messaggio AI più recente con l'uso, richiede un fornitore coerente e scala l'approssimazione verso l'alto. La fonte si blocca con quel fattore tra 1.0 e 1.25 ; non fa scalare una stima verso il basso. Questa può essere una stima di storia conservatrice utile. Non è un algoritmo di riconciliazione per fatture, fornitori misti o chiamate mancanti. Decidete cosa deve guidare ogni contatore Attaccare un limite decisionale a ogni numero memorizzato. Utilizzare una approssimazione per: avvertire prima che una storia si avvicini a un limite di contesto morbido; confrontare due varianti di schema di richieste o di schemi di strumenti prima di inviarle; decidere se riassumere, recuperare o eliminare il contesto sostitutibile; stimare l'effetto relativo dell'inclusione di un altro messaggio o schema di strumento. Utilizzare l' utilizzo segnalato dal fornitore per: attribuire l'input e l'output osservati a un tentativo di modello completato; quando il fornitore li restituisce, separare i componenti di cache, audio o di ragionamento; conciliare i totali di fornitori/modelli in tutti i tentativi; calcolare i costi solo con una fonte di prezzo data e una gestione esplicita per dettagli non disponibili. Utilizzare nessuno dei contatori da soli per dimostrare: che tutte le richieste di modello attese siano state effettuate con strumenti; che una chiamata agli strumenti abbia raggiunto la destinazione; l'esistenza del consegnabile atteso; che un nuovo tentativo sia stato sicuro o utile; che una corsa a basso token abbia ottenuto il risultato richiesto. Queste affermazioni richiedono la copertura delle chiamate e la prova del risultato. Un'attuazione compatta può far rispettare quattro regole di promozione: 1. Ogni attempt id previsto ha esattamente una osservazione. 2. Ogni chiamata osservata è etichettata come approximate o provider reported ; le etichette non vengono mai fusi in silenzio. 3. Le stime di previo volo con attrezzatura dimostrano che il schema è stato trasmesso al bancone. 4. Il provider mancante o i dettagli della cache rimangono null /disponibile e bloccano solo le decisioni che lo richiedono. La soglia non deve essere universale al 100%. Una preview non prodotta potrebbe consentire una copertura approssimativa. Un avviso di bilancio o il rimborso dei clienti non dovrebbero. In codice la politica accanto al consumatore: context warning può accettare le stime, mentre cost reconciliation richiede l'utilizzo completo del fornitore e ID unici di tentativo. Controllare il limite prima di ottimizzare Il risarcimento ragionevole è semplice: stima prima, osservazione dopo, copertura dell'audit al limite di esecuzione. Ottimizzare solo dopo tutti e tre i lavori. Se una stima di contesto è elevata, controllare i suoi input prima di tagliare. L'insieme completo degli strumenti era incluso? Sono ancora necessari i risultati degli strumenti per la prossima decisione? Un messaggio lungo è un ricevimento decisionale duraturo o una narrazione sostitutibile? Rimuovere il contesto sbagliato può rendere la corsa più economica e meno affidabile. Se l'utilizzo del fornitore è inaspettatamente basso, controlla le chiamate mancanti prima di festeggiare. I blocchi di streaming di conferma sono stati combinati nel messaggio finale, le richieste di richiamo sono state propagate in child runnables, i retries hanno ricevuto ID di tentativo distinti e la fase di verifica prevista è effettivamente stata eseguita. Un grafico dei costi con spazi mancanti non è un risultato di ottimizzazione. Se il caching è importante, richiedere la mappa dettagliata specifica per il fornitore e registrarne la disponibilità. LangChain fornisce una busta comune, ma i fornitori non necessariamente popola ogni componente. Non dedurre una mancanza di cache da una chiave mancante. Confronta come con come: lo stesso provider, modello, superficie prompt/strumento, stato cache e esigenza di risultato. Infine, unire le prove simboliche a una ricevuta del compito. Per un agente di revisione dei documenti, la ricevuta potrebbe contenere la revisione della fonte, le sezioni richieste controllate, affermazioni fallite e hash di uscita. I token per chiamata riuscita sono ancora un denominatore debole se l'artefatto finale è assente. Questo design a due binari è intenzionalmente più stretto di un generico stack di osservabilità. Risponde a una decisione concreta: se un numero di token LangChain è una stima di contesto, una misurazione osservata del fornitore o una visione incompleta che non deve guidare i costi o le richieste di ottimizzazione. Sidewisp è attualmente in anteprima privata. L'utilizzo dei token e l'analisi dei costi stimati sono pianificati, non spediti. La direzione del prodotto consiste nel collegare i segnali di costo ai progressi utili e ai risultati verificati mantenendo visibili le prove e l'incertezza. Se quel confine operativo corrisponde al modo in cui gestisci gli agenti, puoi Partecipa alla visualizzazione privata. Fonti Referenza Python di LangChain: count tokens approximately Presentazione della sorgente LangChain per il contatore approssimativo Guida dei messaggi LangChain: utilizzo dei token su AIMessage Referenza LangChain: UsageMetadata Referenza LangChain: UsageMetadataCallbackHandler