L’integrazione ScaleDown di LangChain sfida la tassa sul contesto dei modelli frontier

LangChain ha rilasciato l’integrazione LangChain ScaleDown il 13 ottobre, spostando tre operazioni ricorrenti sul contesto dai costosi modelli frontier. La mossa mette in discussione un comune schema di progettazione degli agenti: usare il modello più capace per pianificazione, generazione, riepilogo, estrazione e ogni altra decisione di supporto.

Il nuovo pacchetto langchain-scaledown collega LangChain e Deep Agents ai modelli di decoding vincolato di ScaleDown, o CDM. Questi modelli specializzati limitano gli output a ciò che un’attività ristretta consente, come un’etichetta, un passaggio sorgente o un campo strutturato. LangChain ha inoltre aggiunto ScaleDown al proprio LangSmith LLM Gateway.

L’annuncio non è semplicemente un’altra integrazione di provider. Trasforma la gestione del contesto in un livello di inferenza separato, con modelli, controlli e modalità di errore proprie. OpenAI, Anthropic e gli sviluppatori di framework per agenti hanno affrontato lo stesso problema tramite caching, compattazione, memoria e finestre di contesto più ampie. LangChain ora propone una risposta diversa: smettere di chiedere a un modello generalista di eseguire ogni operazione ripetitiva sul contesto.

L’integrazione ScaleDown di LangChain divide lo stack degli agenti

LangChain separa il ragionamento ad alto valore dal lavoro ripetitivo sul contesto che lo circonda.

Secondo l’integrazione per il contesto degli agenti di LangChain, il pacchetto fornisce middleware per il riepilogo della cronologia, la compressione del contesto, la compressione dei risultati degli strumenti e l’estrazione strutturata. Il modello principale dell’agente continua a pianificare, scrivere e decidere cosa fare successivamente.

Questa separazione è importante perché un agente fa molto più che generare una risposta finale. Durante un’esecuzione prolungata, legge le risposte degli strumenti, conserva la cronologia rilevante, elimina il materiale obsoleto e converte i messaggi dell’utente in stato strutturato. Queste operazioni possono ripetersi prima che l’utente veda un’altra risposta.

L’integrazione assegna tali operazioni di supporto a quattro modelli ScaleDown:

• Summarize condensa la cronologia delle conversazioni meno recente.

• Compress seleziona le informazioni pertinenti a una domanda specifica.

• Extract copia i campi richiesti dal testo sorgente.

• Classify assegna punteggi ai contenuti rispetto a etichette definite dallo sviluppatore.

I modelli di decoding vincolato di ScaleDown differiscono dai modelli linguistici generalisti per gli output consentiti. Un modello generalista può generare quasi qualsiasi sequenza di token. Un modello vincolato opera invece in uno spazio di risposta più ristretto, modellato attorno a una singola attività.

LangChain sostiene che questa restrizione consenta ai modelli di rimanere più piccoli e completare operazioni circoscritte in modo più efficiente. Il design ricorda l’uso di una query di database invece di chiedere a un assistente generico di ispezionare ogni riga e comporre una risposta in prosa.

Il middleware rilasciato offre punti di ingresso pratici per questa divisione tra modelli. ScaledownSummarizationMiddleware si attiva quando la cronologia della conversazione supera una soglia configurata. Sostituisce i messaggi meno recenti con un riepilogo, mantenendo al contempo una porzione recente dello scambio.

ScaledownToolCompressionMiddleware opera dopo chiamate selezionate agli strumenti. Aggiunge un campo compression_query che permette all’agente di indicare quali informazioni gli servono dal risultato. Il middleware rimuove quel campo prima di eseguire lo strumento, quindi comprime il testo restituito prima che il modello principale lo veda.

ScaledownExtractionMiddleware raccoglie valori strutturati dai messaggi dell’utente. Un flusso di supporto potrebbe richiedere un identificativo d’ordine, un messaggio di errore, un indirizzo email e una categoria del problema. I campi risultanti entrano nello stato dell’agente, dove gli strumenti successivi possono leggerli senza ripetere l’estrazione nel ciclo di ragionamento del modello primario.

Il pacchetto include inoltre una compressione generale del contesto per prompt di sistema di grandi dimensioni. La documentazione del middleware di LangChain sconsiglia di applicarla a prompt brevi o creativi. La compressione può rimuovere tono, istruzioni o dettagli necessari al modello.

Questo avvertimento definisce il confine dell’integrazione. ScaleDown non sta sostituendo il modello centrale dell’agente. Sta assumendo operazioni delimitate i cui output attesi possono essere descritti prima che inizi l’inferenza.

La documentazione del pacchetto afferma che tutti e quattro i percorsi middleware falliscono in modo aperto. Se ScaleDown rifiuta una richiesta, diventa indisponibile o esaurisce la propria allocazione, l’agente prosegue senza il risultato di quel middleware. Questo impedisce che un’ottimizzazione ausiliaria interrompa automaticamente il flusso di lavoro principale.

Questo comportamento crea anche un’importante questione operativa. Un agente che continua senza compressione o estrazione può rimanere disponibile, pur comportandosi diversamente. I team devono quindi monitorare sia il tempo di attività sia la coerenza semantica tra i percorsi ottimizzati e quelli di fallback.

Gli agenti a lunga esecuzione pagano ripetutamente per la propria cronologia

La pressione deriva dai costi ricorrenti del contesto, non da un singolo prompt insolitamente grande.

Un agente a lunga esecuzione accumula istruzioni, messaggi dell’utente, risposte del modello, chiamate agli strumenti e risultati degli strumenti. Ogni nuova richiesta al modello può portare avanti gran parte di quel registro. Anche quando il modello necessita soltanto di una piccola parte, l’applicazione deve comunque decidere cosa conservare.

Un agente di coding illustra il problema. Potrebbe leggere diversi file, cercare in un repository, ispezionare l’output dei test, modificare il codice, eseguire i test e tornare su errori precedenti. Un singolo risultato di uno strumento può contenere migliaia di righe, eppure solo un errore o una definizione di funzione può influire sul passaggio successivo.

Senza una gestione deliberata del contesto degli agenti LangChain, il registro diventa costoso e distraente. Più contesto aumenta l’elaborazione in input, mentre la cronologia irrilevante può rendere il modello meno focalizzato. Il riepilogo introduce un’altra chiamata al modello, con latenza, spesa e potenziale perdita di informazioni proprie.

L’esempio di LangChain mostra ScaleDown comprimere un risultato di documentazione da 18.402 caratteri a 3.110 caratteri. Si tratta di una riduzione vicina al 90 per cento del materiale inviato al modello principale dell’agente. È una singola traccia, non una garanzia di prestazioni generale, ma dimostra il meccanismo previsto.

I risparmi possono accumularsi. Se il risultato non compresso rimane in ogni richiesta successiva, l’applicazione paga ripetutamente per elaborarlo. Comprimere il risultato prima che entri nella cronologia persistente cambia il costo di ogni turno successivo.

La stessa logica si applica al riepilogo. Quando i messaggi meno recenti si avvicinano a una soglia di contesto configurata, il middleware produce un registro compatto contenente elementi quali intenzione, avanzamento, artefatti e passaggi successivi. I messaggi recenti rimangono intatti perché è più probabile che siano importanti alla lettera.

Questo approccio mira a due vincoli distinti. Le finestre di contesto hanno capacità finite, e l’elaborazione di contesto utile ma sovradimensionato comporta comunque latenza e costi. Una finestra da un milione di token non rende ogni token incluso gratuito o pertinente.

ScaleDown afferma che ciascuno dei suoi quattro modelli accetta fino a un milione di token di input. LangChain afferma che Extract, Summarize e Classify accettano anche immagini e PDF scansionati. Queste capacità potrebbero ridurre la necessità di chunking lato applicazione, sebbene le prestazioni pratiche dipendano ancora dalla struttura del documento e dalla qualità dell’attività.

L’integrazione LangChain ScaleDown raggiunge anche il LangSmith LLM Gateway attraverso un percorso dedicato /scaledown. Gli amministratori dell’area di lavoro archiviano una chiave del provider ScaleDown, mentre le applicazioni si autenticano tramite LangSmith.

Il percorso del provider gateway conserva il comportamento nativo di richieste e risposte di ScaleDown. LangSmith gestisce autenticazione, segreti del provider, policy e tracing senza tradurre l’API nello schema di un altro provider.

Questo rende l’ottimizzazione del contesto visibile nello stesso livello operativo che monitora il modello principale. Le chiamate a ScaleDown possono apparire nelle tracce e contribuire alla spesa e ai limiti di velocità dell’area di lavoro. I team non devono trattare il middleware di contesto come una raccolta invisibile di richieste laterali.

Questo è particolarmente rilevante per gli acquirenti enterprise. Ridurre la fattura dei modelli è importante, ma lo è anche governare il nuovo provider. Le tracce centralizzate possono mostrare quando si è verificato il riepilogo, con quale frequenza è stata eseguita la compressione e se le chiamate ausiliarie hanno contribuito a una latenza inattesa.

La pressione immediata ricade sui team che usano modelli frontier per ogni operazione. Ora devono giustificare perché estrazione, classificazione e compattazione della cronologia richiedano lo stesso modello che gestisce la pianificazione aperta.

I modelli specializzati si occupano della manutenzione del contesto

La scommessa centrale è che output vincolati possano preservare l’utilità senza pagare per una generazione illimitata.

I modelli di decoding vincolato di ScaleDown riducono lo spazio di output prima che inizi l’elaborazione. Classify restituisce punteggi per etichette consentite. Extract identifica passaggi e campi sorgente. Compress seleziona materiale pertinente alla domanda. Summarize produce una rappresentazione delimitata invece di una risposta aperta.

Questo design rende il meccanismo più importante del benchmark in evidenza. Un modello vincolato non necessita della stessa ampiezza di un assistente chiamato a scrivere codice, pianificare un’indagine o negoziare istruzioni in conflitto. Necessita di coerenza in una singola operazione definita.

L’integrazione LangChain ScaleDown trasforma questa distinzione in middleware. Gli sviluppatori possono mantenere il modello di agente scelto delegando al contempo trasformazioni specifiche. L’architettura è quindi composizionale, anziché una migrazione completa del modello.

La compressione degli strumenti è l’esempio più chiaro. Si supponga che un agente di supporto recuperi un’intera policy sui resi mentre analizza una domanda relativa a un rimborso europeo. Il modello principale può fornire una query di compressione che descrive il passaggio necessario. ScaleDown filtra quindi il risultato prima che diventi parte della conversazione visibile al modello.

Il modello principale può richiedere nuovamente il risultato non compresso se la versione condensata è insufficiente. Questa via di uscita è importante perché la pertinenza dipende dalla domanda fornita al compressore. Una query debole o prematura può escludere un fatto di cui l’agente avrà bisogno in seguito.

L’estrazione offre un altro caso delimitato. Un agente che apre un ticket potrebbe aver bisogno di un codice di errore esatto. Un modello generativo può parafrasare il codice o riprodurlo in modo errato. Un sistema di estrazione progettato per copiare passaggi dalla fonte ha un compito più ristretto e un obiettivo di valutazione più chiaro.

LangChain afferma che il middleware di estrazione legge i messaggi dell’utente anziché le risposte dell’agente. Questa regola di provenienza aiuta a evitare che il sistema tratti le proprie precedenti speculazioni come dati forniti dall’utente. I campi che non sono ancora comparsi rimangono vuoti.

La classificazione può operare come controllo di runtime. LangChain presenta un esempio che etichetta un agente come in avanzamento, in loop o fuori rotta. Una soglia di confidenza definita dallo sviluppatore può interrompere l’esecuzione o aggiungere feedback correttivo.

Tuttavia, LangChain non distribuisce in questa release un middleware preconfigurato per il rilevamento della deriva. Gli sviluppatori devono definire etichette, rubriche, soglie e risposte. Questa distinzione evita che un esempio venga scambiato per un sistema di sicurezza pronto all’uso.

Il cambiamento architetturale più ampio è il passaggio da agenti a un solo modello a portafogli di modelli. L’agente visibile rimane generalista, ma modelli specializzati gestiscono le operazioni prevedibili che lo circondano. Il routing diventa parte della progettazione dell’applicazione, anziché un dettaglio di implementazione a livello di provider.

Questo ricorda l’ordinaria ingegneria del software. I team non usano lo stesso database, la stessa coda, lo stesso motore di ricerca e lo stesso runtime per ogni operazione solo perché un singolo sistema può approssimare gli altri. La specializzazione può migliorare l’efficienza quando interfacce e casi di errore sono ben compresi.

I sistemi di IA complicano questa analogia perché il middleware trasforma il significato, non soltanto i byte. Un compressore può omettere una precisazione. Un riepilogo può appiattire l’incertezza. Un classificatore può assegnare il percorso sbagliato pur riportando un’elevata confidenza.

Per questo la valutazione deve seguire le conseguenze dell’applicazione. Una frase mancante in un assistente di conoscenza generale potrebbe produrre una risposta incompleta. Un’eccezione omessa in una policy di conformità potrebbe innescare un’azione errata.

I team dovrebbero confrontare traiettorie complete degli agenti, non soltanto output isolati. Il test giusto chiede se l’agente ottimizzato raggiunge lo stesso risultato valido, usa meno risorse e mantiene un comportamento accettabile in caso di errore attraverso molte esecuzioni.

La promessa dei benchmark è grande, ma resta misurata dal fornitore

Le dichiarazioni di efficienza di ScaleDown attirano l’attenzione, ma non dimostrano risparmi end-to-end per gli agenti.

LangChain cita l’affermazione di ScaleDown secondo cui i suoi modelli possono essere 200 volte più veloci e 467 volte più economici dei modelli frontier su attività ristrette. Questi dati provengono dal fornitore, non da una valutazione indipendente di agenti LangChain in produzione.

Il confronto dei benchmark di ScaleDown offre dati più specifici per attività. Rispetto alla media di tre modelli OpenAI elencati, riporta Summarize come 41 volte meno costoso e 2,7 volte più veloce. Riporta Compress come 138 volte meno costoso e 1,8 volte più veloce.

La stessa pagina dichiara una maggiore accuratezza per tali operazioni. Tuttavia, si tratta delle misurazioni di ScaleDown sui dataset, sulle configurazioni dei modelli, sui prezzi e sull’ambiente di latenza da essa selezionati. I lettori dovrebbero considerarli risultati del fornitore finché team indipendenti non li riprodurranno.

I risparmi a livello di attività differiscono inoltre dai risparmi a livello di workflow. Un agente di supporto necessita comunque del proprio modello principale, degli strumenti, dei sistemi di retrieval, del tracing e dell’infrastruttura applicativa. Ridurre il costo della sintesi non riduce ogni componente della stessa percentuale.

La quota della spesa totale dedicata al lavoro sul contesto varierà notevolmente. Un agente che effettua una sola breve chiamata a uno strumento potrebbe ottenere vantaggi limitati. Un agente di ricerca che elabora ripetutamente pagine lunghe potrebbe invece guadagnare molto di più.

La latenza presenta limiti simili. L’aggiunta di middleware crea un’ulteriore richiesta di rete, anche quando il modello specializzato risponde rapidamente. Il fatto che l’utente visualizzi un risultato più rapido dipende da ciò che il middleware elimina, da dove vengono eseguite le chiamate e dalla possibilità di eseguire le operazioni in parallelo.

Anche il design fail-open del pacchetto richiede una valutazione. Se una chiamata di sintesi fallisce vicino al limite di contesto, il modello principale riceve la cronologia invariata. L’agente resta operativo, ma potrebbe avvicinarsi alla capacità massima o generare una richiesta più onerosa.

Un errore di compressione può aumentare il costo senza modificare la correttezza. Un errore di estrazione può essere più evidente perché uno strumento downstream potrebbe non ricevere i campi previsti. La logica applicativa deve distinguere tra un valore vuoto e un servizio di estrazione non disponibile.

Esiste inoltre un limite legato alla preview. La documentazione del pacchetto afferma che sd_summarize è in private preview e richiede l’abilitazione di ScaleDown. Questo dettaglio conta per i team che presumono che ogni percorso pubblicizzato sia immediatamente disponibile in condizioni identiche.

Privacy e governance dei dati richiedono un’ulteriore revisione. I metadati del pacchetto affermano che il middleware invia agli endpoint ScaleDown solo il testo necessario e non include telemetria del pacchetto. Ciò introduce comunque un ulteriore responsabile del trattamento per la cronologia delle conversazioni, i documenti o i campi estratti.

Un team deve verificare quale middleware accede a quale contenuto. La sintesi gestisce i messaggi più vecchi. La compressione degli strumenti gestisce risultati selezionati. L’estrazione può elaborare identificativi e dati di contatto forniti dagli utenti. La classificazione potrebbe ispezionare un’intera cronologia dell’agente.

LangSmith centralizza credenziali e tracce, ma l’osservabilità centralizzata non risponde a ogni questione di governance. Gli acquirenti necessitano comunque di dettagli su conservazione, residenza, sicurezza, audit e contratti da ciascun fornitore.

I rischi di accuratezza meritano pari attenzione. La compressione comporta intenzionalmente perdita di informazioni. La metrica importante non è soltanto la riduzione dei token, ma se il contenuto rimosso si rivela in seguito necessario. Un agente potrebbe non sapere di avere bisogno di una precisazione scartata fino a diversi passaggi dopo.

La deriva dei riepiloghi presenta un problema correlato. Riassumere ripetutamente dei riepiloghi può alterare gradualmente intenzione, confidenza o cronologia causale. I messaggi recenti restano disponibili, ma i dettagli più vecchi possono diventare sempre più dipendenti da una rappresentazione compressa.

LangChain affronta parzialmente questo problema in Deep Agents conservando la cronologia espulsa in un file che l’agente può leggere nuovamente. Ciò offre un percorso di recupero. Non garantisce che l’agente riconosca quando il retrieval sia necessario.

I team che valutano la gestione del contesto degli agenti LangChain dovrebbero quindi testare il richiamo delle informazioni, l’accuratezza degli strumenti downstream, i tassi di completamento, i tentativi ripetuti e la latenza totale. Il costo per chiamata è utile, ma il costo per attività completata con successo è una misura più importante.

ScaleDown compete con caching, compattazione e memoria

Il confronto principale riguarda l’elaborazione specializzata del contesto rispetto al mantenimento del lavoro sul contesto all’interno dello stack dei modelli generalisti.

I fornitori di modelli offrono già modalità per rendere meno costose le interazioni lunghe. Il prompt caching evita di ricalcolare un prefisso invariato. La compattazione sostituisce il materiale conversazionale più vecchio con una rappresentazione più piccola. Gli strumenti di memoria preservano informazioni selezionate tra sessioni diverse.

La guida al prompt caching di OpenAI descrive il caching come il riuso di stati calcolati in precedenza per prefissi di prompt corrispondenti. Può ridurre costo di elaborazione e latenza senza eliminare il contesto memorizzato nella cache.

Caching e compressione di ScaleDown risolvono problemi diversi. Il caching rende più economica l’elaborazione del contesto ripetuto. La compressione riduce la quantità di contesto presentata alle chiamate successive. Un’applicazione può utilizzare entrambi, ma la loro interazione richiede attenzione.

Modificare il contesto precedente mediante compattazione o sintesi può interrompere il riuso del prefisso oltre il punto modificato. Gli sviluppatori devono decidere se la riduzione dei token compensi la perdita di cache hit. La risposta dipende dalla stabilità del contesto e dal numero di chiamate successive che riutilizzano lo stesso prefisso.

Anthropic ha intrapreso un’altra strada attraverso compattazione, memoria, file e pattern di harness per agenti. La sua ricerca sugli agenti a lunga esecuzione sostiene che la sola compattazione non garantisce progressi coerenti attraverso molte finestre di contesto.

Questa osservazione inquadra la sfida per ScaleDown. Una sintesi efficiente risolve soltanto una parte dell’agentività di lunga durata. Un agente necessita anche di artefatti persistenti, monitoraggio esplicito dei progressi, scomposizione coerente delle attività e recupero affidabile dopo un errore.

Gli approcci non si escludono a vicenda. Un agente di coding potrebbe conservare un file di avanzamento scritto, mettere in cache istruzioni stabili, comprimere grandi risultati degli strumenti e riassumere la cronologia conversazionale meno recente. Ogni livello affronta una diversa forma di ripetizione o perdita di informazioni.

La pressione competitiva riguarda invece il controllo. Le funzionalità native dei fornitori mantengono più operazioni sul contesto all’interno di una piattaforma di modelli. Il middleware dei framework consente agli sviluppatori di combinare fornitori e regolare ogni livello separatamente.

Il gateway LangSmith rafforza il secondo approccio. Offre agli utenti LangChain un livello comune di policy e tracing, preservando al contempo le API specifiche dei fornitori. ScaleDown diventa un altro componente governato anziché una chiamata esterna ad hoc.

Questa flessibilità introduce complessità. I team devono valutare più endpoint, credenziali, limiti, tracce e modalità di incidente. Uno stack a fornitore unico offre meno parti mobili, anche se alcune operazioni costano di più.

L’architettura giusta dipende dalla forma del carico di lavoro. Risultati degli strumenti grandi e ripetitivi favoriscono la compressione. Le conversazioni di supporto strutturate favoriscono l’estrazione. Gli scambi creativi brevi offrono meno vantaggi evidenti e un rischio maggiore di perdere sfumature.

Gli agenti ricchi di conoscenza necessitano anche di accesso a materiale sorgente durevole. Una base di conoscenza ricercabile può preservare i documenti originali mentre il contesto attivo contiene soltanto il materiale rilevante per l’attività. Questa separazione rende più facile invertire la compressione quando l’agente necessita di un altro passaggio della fonte.

L’argomento più forte di ScaleDown non è che i grandi modelli siano superflui. LangChain li conserva esplicitamente per pianificazione, coding, stesura e altro lavoro aperto. L’affermazione è che l’inferenza frontier è diventata un’impostazione predefinita costosa per operazioni con output ristretti e misurabili.

Se test indipendenti sosterranno tale affermazione, il routing dei modelli si sposterà più in profondità nei framework per agenti. Gli sviluppatori sceglieranno i modelli in base all’operazione anziché selezionarne uno per un’intera applicazione.

Se il compromesso sull’accuratezza si dimostrerà difficile da controllare, caching e compattazione nativi dei fornitori manterranno un vantaggio. Riducono al minimo la complessità di integrazione e mantengono l’elaborazione semantica più vicina al modello responsabile dell’attività.

Tre segnali decideranno se l’integrazione conta

L’adozione dipenderà da risultati indipendenti sull’accuratezza, tracce di produzione e risposte dei maggiori fornitori di modelli.

Il primo segnale è una valutazione riproducibile. Gli sviluppatori necessitano di test pubblici che dimostrino se ScaleDown conserva i fatti richiesti dai passaggi successivi dell’agente. I risultati dovrebbero includere conversazioni lunghe, output rumorosi degli strumenti, documenti scansionati e campi intenzionalmente simili tra loro.

Queste valutazioni devono misurare più del rapporto di compressione. Metriche utili includono completamento delle attività, accuratezza dei campi esatti, frequenza di recupero, errori degli strumenti downstream e latenza nell’intero workflow. Una chiamata intermedia meno costosa ha valore limitato se crea un ulteriore tentativo.

Il secondo segnale è l’evidenza delle tracce di produzione. L’integrazione con LangSmith rende questo più praticabile perché i team possono osservare insieme chiamate al modello principale e al middleware. Gli studi di caso dovrebbero mostrare con quale frequenza si attiva ciascun middleware e quale percentuale della spesa totale per l’inferenza modifica.

Occorre osservare anche i dati sui percorsi di errore. I team dovrebbero riferire con quale frequenza il middleware fallisce in modalità aperta, se gli agenti rilevano stato mancante e come le esecuzioni di fallback si confrontano con quelle ottimizzate. La disponibilità senza coerenza comportamentale può produrre incidenti difficili da individuare.

Il terzo segnale è la risposta competitiva. I fornitori di modelli possono migliorare caching nativo, compattazione, estrazione strutturata o endpoint specializzati a costo inferiore. I framework per agenti possono inoltre aggiungere astrazioni di routing che rendono ScaleDown un’opzione tra diverse alternative.

ScaleDown non deve sostituire questi sistemi per convalidare l’approccio. Deve dimostrare che operazioni sul contesto specializzate offrono vantaggi affidabili tra fornitori e tipi di agenti.

L’integrazione LangChain-ScaleDown arriva mentre ci si aspetta che gli agenti lavorino più a lungo e consumino informazioni più eterogenee. Questa tendenza rende la gestione del contesto una preoccupazione centrale del runtime anziché un dettaglio di prompt engineering.

Per gli sviluppatori, il passo successivo è un confronto controllato. Eseguite traiettorie rappresentative con e senza modelli di decodifica vincolata di ScaleDown, quindi ispezionate il record completo. Confrontate fatti mantenuti, azioni completate, tentativi, latenza e utilizzo totale dei modelli. Mantenete recuperabile il contesto originale durante il test.

La domanda decisiva non è se un modello specializzato possa accorciare un documento. È se l’agente raggiunga comunque il risultato corretto dopo che quel documento è stato accorciato. Se la risposta regge su carichi di lavoro reali, la suddivisione dei modelli di LangChain offrirà un’alternativa credibile al pagamento della tassa di contesto dei modelli frontier a ogni turno.