LangSmith AI Search individua i fallimenti degli agenti che i tradizionali filtri delle tracce non rilevano
LangSmith ha rilasciato AI Search in beta pubblica, offrendo ai team un nuovo modo per individuare fallimenti degli agenti che i normali filtri non riescono a cogliere. La funzionalità accetta descrizioni in linguaggio naturale dei comportamenti e cerca poi le tracce corrispondenti nelle interazioni registrate degli agenti.
Uno sviluppatore può chiedere di trovare i casi in cui un utente si è frustrato, un agente ha dichiarato di aver avuto successo senza completare il proprio compito, oppure sono apparse informazioni personali in una risposta. Queste domande dipendono dal significato e dalla sequenza, non da un tag noto o da una frase esatta.
Questa distinzione crea la vera tensione alla base di LangSmith AI Search. L'osservabilità degli agenti è dipesa soprattutto da filtri strutturati, query full-text e valutatori configurati prima che i team sappiano quali fallimenti contino davvero. LangSmith scommette sul fatto che un modello possa indagare comportamenti sconosciuti nel momento in cui emerge la domanda.
L'approccio introduce anche un interrogativo meno rassicurante. Se un altro modello decide quali conversazioni di produzione corrispondono a una descrizione soggettiva, i team devono comprendere cosa quel modello legge, esclude e classifica erroneamente.
LangSmith AI Search aggiunge query comportamentali all'esplorazione delle tracce
Il rilascio trasforma l'indagine sulle tracce da un problema di query di database a un problema di interpretazione.
LangChain ha annunciato la beta pubblica il 13 ottobre 2026. È disponibile tramite LangSmith Cloud nelle regioni statunitensi, europee e Asia-Pacifico di Google Cloud. Un amministratore dell'organizzazione deve abilitarla prima che gli altri membri possano utilizzarla.
LangSmith consente già ai team di filtrare le tracce in base a campi quali stato, latenza, tag, metadati, costi e feedback. La sua ricerca full-text può inoltre trovare parole presenti negli input delle tracce, negli output, nei metadati e negli errori.
Questi strumenti funzionano quando chi svolge l'indagine sa quale campo o frase identifica il bersaglio. Un filtro di stato può trovare gli errori, mentre una query testuale può localizzare conversazioni contenenti "refund". Nessuno dei due può però stabilire con affidabilità se un utente ha rinunciato silenziosamente dopo aver ricevuto una risposta poco utile.
LangSmith AI Search accetta invece una descrizione comportamentale. Gli esempi dell'azienda relativi alla ricerca comportamentale delle tracce includono utenti che mostrano frustrazione, agenti che espongono dettagli interni di implementazione e agenti che non completano il lavoro assegnato.
La funzionalità opera su thread, tracce e singole esecuzioni. Una traccia registra una richiesta e le sue operazioni annidate, mentre un thread collega più tracce della stessa conversazione.
I team possono combinare la query in linguaggio naturale con i filtri strutturati esistenti. Potrebbero prima limitare i risultati alle tracce di produzione con errori, quindi chiedere quali conversazioni mostrino utenti confusi durante l'onboarding.
Questa combinazione è importante. Consente ai filtri convenzionali di ridurre l'area di ricerca prima che un modello esamini le conversazioni rimanenti. Preserva inoltre controlli deterministici per attributi che non dovrebbero richiedere interpretazione.
I risultati includono punteggi di confidenza. Aprendo una corrispondenza, il revisore accede a una vista della traiettoria, in cui LangSmith evidenzia i messaggi disponibili che hanno influenzato la corrispondenza.
Una traiettoria è una sequenza normalizzata di messaggi umani, risposte dell'agente, chiamate a strumenti e risultati degli strumenti. Presenta la sessione una sola volta invece di ripetere la cronologia della conversazione inclusa nelle successive chiamate al modello.
Non si tratta semplicemente di un livello sintattico più intuitivo sopra i filtri esistenti. LangSmith afferma che il modello decisionale legge ogni traiettoria candidata e valuta se il comportamento richiesto si sia verificato.
La differenza risulta chiara con una richiesta come "l'agente ha detto di aver completato il compito, ma non l'ha fatto". Sia una traccia riuscita sia una non riuscita possono contenere argomenti, strumenti e vocabolario quasi identici.
Un embedding, che rappresenta il testo come vettore numerico, può collocare queste conversazioni vicine perché discutono dello stesso compito. La classificazione comportamentale deve invece confrontare l'affermazione con le azioni registrate nell'intera traccia.
L'azienda ha quindi portato un modello LLM-as-a-judge direttamente nella scoperta interattiva delle tracce. Gli ingegneri non devono più definire ogni valutatore prima di iniziare un'indagine.
Questo cambiamento rende più rapida l'analisi esplorativa. Non rende però autorevole ogni risultato.
Perché la ricerca nelle tracce degli agenti è diventata un problema di dati
Le lunghe sessioni degli agenti contengono prove preziose, ma la loro scala e ripetizione rendono la revisione manuale sempre più impraticabile.
Il monitoraggio tradizionale delle applicazioni si concentra su segnali prevedibili. Gli ingegneri cercano codici di errore, richieste lente, chiamate al database fallite o consumo anomalo di risorse. Questi segnali si adattano in genere a campi strutturati.
Gli agenti AI producono una superficie di fallimento diversa. Un agente può restituire una risposta tecnicamente riuscita pur avendo frainteso la richiesta, chiamato uno strumento inappropriato o sopravvalutato ciò che ha realizzato.
Anche la telemetria risultante è insolitamente densa. Un'attività di un agente può contenere messaggi dell'utente, output del modello, documenti recuperati, comandi shell, risposte degli strumenti, tentativi ripetuti e passaggi ad altri agenti.
LangChain ha esaminato 150 conversazioni selezionate casualmente da Open SWE, il suo agente di coding open-source. Secondo l'azienda, diverse superavano un milione di token.
La conversazione mediana conteneva circa 72.000 token. Solo circa 2.000 provenivano dai messaggi degli utenti e dalle risposte finali dell'agente, mentre approssimativamente l'85 percento era costituito dall'output degli strumenti.
Questi dati provengono dal campione di LangChain, non da un benchmark indipendente di settore. Illustrano comunque perché cercare in ogni evento grezzo comporti costi sia di contesto sia di inferenza.
Gli agenti inviano spesso l'intera cronologia della conversazione a ogni nuova chiamata al modello. Una rappresentazione ingenua delle tracce memorizza quindi ripetutamente gli stessi messaggi precedenti.
LangSmith affronta questa ripetizione attraverso le traiettorie. Il suo livello dati delle tracce converte i formati di traccia supportati in una rappresentazione comune man mano che i dati arrivano.
I formati includono tracce prodotte tramite LangChain, LangGraph, SDK di OpenAI e Anthropic, Vercel AI SDK e OpenTelemetry. La normalizzazione fornisce al sistema di ricerca una sequenza coerente da ispezionare.
Questo amplia anche la portata competitiva. I fornitori di osservabilità offrono sempre più spesso valutazioni a livello di traccia, non soltanto archiviazione e filtraggio.
Datadog, per esempio, documenta valutazioni a livello di traccia che inseriscono ogni span di una traccia in un prompt di valutazione LLM. Queste valutazioni possono classificare il completamento dell'obiettivo, l'ordine degli strumenti o la qualità della conversazione.
Arize Phoenix combina analogamente tracing, annotazioni, valutazioni, dataset ed esperimenti in un flusso di lavoro di tracing open-source. I suoi valutatori possono assegnare punteggi alle tracce di produzione e convertire le esecuzioni selezionate in dataset per test successivi.
La distinzione riguarda soprattutto tempistiche e flusso di lavoro. I valutatori rappresentano in genere criteri che un team definisce, testa e applica ripetutamente. LangSmith AI Search si rivolge alle domande che emergono nel corso di un'indagine.
Si consideri un agente di supporto che riceve un improvviso aumento delle richieste di cancellazione. Un dashboard strutturato potrebbe mostrare una latenza stabile e pochi errori espliciti. La ricerca full-text potrebbe identificare la parola "cancel", ma non la ragione sottostante.
Un product manager potrebbe invece cercare gli utenti che hanno tentato di cancellare dopo aver ricevuto risposte contraddittorie. Questa descrizione combina intento, sequenza e qualità percepita.
Se le corrispondenze sono utili, il team può esaminarle, aggiungere esempi a un dataset e creare un valutatore durevole. La ricerca diventa il front-end esplorativo per un processo di qualità più formale.
Questo flusso di lavoro spinge le piattaforme di osservabilità a collegare scoperta e valutazione. Memorizzare tracce dettagliate non è più sufficiente quando i clienti non riescono a recuperare il comportamento nascosto al loro interno.
Cambia anche quali team possono utilizzare i dati delle tracce. Product manager, revisori della sicurezza e responsabili del supporto possono descrivere un problema senza dover prima imparare un linguaggio di query specifico della piattaforma.
Il livello di query tecnico rimane necessario. Il linguaggio naturale avvicina semplicemente il primo passo investigativo alle persone che riconoscono il problema aziendale.
Come LangSmith AI Search legge una traccia senza leggere tutto
LangSmith riduce il costo della ricerca dando priorità alle prove conversazionali, ma questa compressione determina quali fallimenti restano visibili.
Quando un utente invia una descrizione a AI Search, i filtri esistenti restringono anzitutto l'insieme dei candidati. SmithDB prepara quindi le traiettorie mentre un modello decisionale le verifica in parallelo.
Le corrispondenze vengono visualizzate nell'interfaccia man mano che il sistema le identifica. Gli utenti non devono attendere che l'intero insieme di candidati sia stato elaborato.
Il meccanismo centrale è un budget di contesto di 8.000 token per ciascuna traiettoria. LangSmith riempie questo budget secondo un ordine di priorità fisso, anziché inviare ogni token registrato.
I messaggi dell'utente e le risposte dirette dell'agente ricevono la massima priorità. I messaggi intermedi del modello, le chiamate agli strumenti, i risultati degli strumenti e i messaggi di sistema occupano lo spazio rimanente.
Se il messaggio successivo non entra, LangSmith lo tronca. I contenuti successivi escono dalla visuale del modello una volta esaurito il budget.
Questa scelta rende pratiche molte ricerche conversazionali. Frustrazione, rifiuto, confusione, intenzione di cancellare e promesse non supportate compaiono spesso nel dialogo visibile.
Crea anche un punto cieco prevedibile. Alcuni fallimenti esistono soltanto nell'output degli strumenti o nei passaggi intermedi di esecuzione.
Un agente potrebbe incontrare un errore di autorizzazione, ignorarlo e dire comunque all'utente che un'attività è riuscita. La risposta visibile contiene l'affermazione falsa, ma la prova decisiva risiede nel risultato di uno strumento.
Il modello di ricerca può non rilevare quella prova quando contenuti precedenti e a priorità più alta consumano il budget di token. LangChain riconosce questa limitazione e afferma di stare esplorando una selezione del contesto dipendente dalla query.
Una simile selezione modificherebbe l'ordine delle prove in base alla domanda. Una query sugli errori degli strumenti ignorati dovrebbe dare priorità alle risposte degli strumenti, mentre una query sul sentimento degli utenti dovrebbe enfatizzare la conversazione.
L'attuale rilascio usa invece un unico ordinamento generale. È comprensibile per una beta, ma i team dovrebbero considerare la copertura risultante dipendente dalla query.
Il meccanismo spiega anche perché LangSmith non si è affidato soltanto alla ricerca vettoriale. Il recupero vettoriale funziona bene quando l'obiettivo è trovare materiale su un argomento.
Una conversazione sulla fatturazione sarà probabilmente vicina ad altre conversazioni sulla fatturazione in uno spazio di embedding. Tuttavia, interazioni sulla fatturazione riuscite e non riuscite possono restare semanticamente simili.
Le query comportamentali richiedono un giudizio su ciò che è avvenuto. Un modello decisionale valuta la traiettoria rispetto a una proposizione circoscritta, ad esempio se l'agente abbia completato l'attività richiesta.
Questo approccio basato sul modello migliora l'espressività, ma sostituisce un'incertezza di recupero con un'altra. Il sistema dipende ora dall'interpretazione di un modello rispetto a un linguaggio ambiguo.
La "frustrazione dell'utente" può includere reclami diretti, domande ripetute, sarcasmo, abbandoni improvvisi o rifiuti garbati. Revisori diversi potrebbero non concordare sui casi al limite.
I punteggi di confidenza aiutano a ordinare i risultati, ma non stabiliscono la verità oggettiva. Un punteggio elevato del modello riflette comunque la definizione del comportamento, il contesto disponibile e il modello giudice.
Il modello operativo più solido include quindi la revisione umana. I team possono esaminare le evidenze evidenziate, correggere le corrispondenze deboli e perfezionare la descrizione prima di considerare il set di risultati rappresentativo.
Per i rischi ricorrenti, possono trasformare i casi revisionati in un dataset di valutazione. Gli online evaluator esistenti di LangSmith possono quindi applicare un criterio definito alle tracce future.
Questo separa l’esplorazione dal monitoraggio. AI Search aiuta i team a individuare un pattern, mentre un evaluator misura quel pattern in modo coerente dopo che la sua definizione si è stabilizzata.
Questa separazione è particolarmente importante per sicurezza e conformità. Una ricerca in linguaggio naturale di informazioni personali può far emergere tracce sospette, ma non dovrebbe sostituire scanner deterministici o controlli formali.
Il giudizio del modello può ampliare un’indagine. Non dovrebbe diventare l’unico livello di applicazione per decisioni dalle conseguenze elevate.
La principale concorrenza è la valutazione predefinita
LangSmith mette in discussione l’ipotesi secondo cui i team debbano conoscere ogni failure importante prima che il traffico di produzione la riveli.
Prima della ricerca comportamentale, i team avevano generalmente tre modi per individuare tracce problematiche. Potevano cercare testo, filtrare attributi noti oppure eseguire un evaluator sul traffico selezionato.
La ricerca full-text offre velocità e riproducibilità. È utile quando le evidenze pertinenti includono una frase distintiva, un identificatore, un messaggio di errore o il nome di un prodotto.
Il filtraggio strutturato è ancora più preciso. I team possono isolare tracce con codici di stato non riusciti, latenza elevata, costose chiamate al modello, strumenti specifici o punteggi di feedback bassi.
Gli evaluator predefiniti gestiscono il significato. Un giudice LLM può stabilire se una risposta è stata utile, fondata, sicura o completa, quindi associare il risultato a ciascuna traccia.
L’approccio basato sugli evaluator è efficace quando un team comprende già la categoria di failure. Diventa meno pratico durante un incidente inatteso.
Qualcuno deve definire la rubrica, selezionare i campi della traccia richiesti, scegliere le regole di campionamento, testare l’evaluator e applicarlo al traffico passato o futuro. Questa preparazione crea una misurazione duratura, ma rallenta l’indagine a perimetro aperto.
LangSmith AI Search comprime questo lavoro in una descrizione inserita al momento della query. Offre un percorso più rapido dal sospetto alle evidenze candidate.
La funzionalità non elimina gli evaluator. Crea una fase di scoperta che li precede.
Un team potrebbe notare un aumento delle escalation al supporto senza sapere perché. Un analista potrebbe cercare gli utenti che hanno ripetuto una richiesta dopo che l’agente aveva dichiarato di averla risolta.
I revisori potrebbero scoprire che l’agente interpreta regolarmente la chiusura dell’account come annullamento dell’abbonamento. Quel pattern può quindi diventare un evaluator denominato con una rubrica testata.
Questa sequenza è la parte più significativa del lancio. Collega esplorazione qualitativa, costruzione del dataset, valutazione e monitoraggio della produzione.
Crea inoltre pressione oltre i concorrenti diretti di LangSmith. I team interni di analytics spesso esportano le tracce in data warehouse, notebook o sistemi di ricerca personalizzati perché le domande di prodotto superano ciò che le dashboard di osservabilità possono gestire.
La ricerca comportamentale nelle tracce potrebbe mantenere una quota maggiore di tale analisi all’interno della piattaforma di osservabilità. I team di prodotto e ingegneria lavorerebbero sullo stesso record di esecuzione sottostante.
L’approccio ricorda il più ampio passaggio dalla ricerca per parole chiave al recupero assistito dai modelli nei sistemi di conoscenza aziendali. Entrambi cercano di trovare un significato che gli utenti non hanno codificato come metadati.
La differenza è che le tracce degli agenti contengono azioni, non solo documenti. Un risultato utile dipende dalla ricostruzione di ciò che è accaduto attraverso messaggi e strumenti.
Per i team di ingegneria, questo rende l’organizzazione delle tracce parte dell’infrastruttura di qualità del prodotto. Lo stesso principio si applica quando i team costruiscono una base di conoscenza ricercabile a partire da documenti tecnici frammentati.
Il vantaggio andrà ai sistemi che preservano le evidenze riducendo al tempo stesso l’attrito investigativo. L’accesso in linguaggio naturale aiuta, ma la verificabilità conta altrettanto.
LangSmith evidenzia i messaggi corrispondenti nella vista della traiettoria. Questo design offre ai revisori un percorso dalla classificazione del modello fino alla conversazione registrata.
Tuttavia, la documentazione segnala che non tutte le corrispondenze possono essere evidenziate. Testo ripetuto o messaggi assenti dalla vista della traiettoria possono impedire la localizzazione delle evidenze.
Un risultato può quindi avere un punteggio di confidenza senza mostrare ogni ragione che lo sostiene. I team dovrebbero distinguere tra la confidenza del modello e le evidenze verificabili.
I concorrenti possono rispondere rendendo le proprie interfacce degli evaluator più conversazionali. Possono inoltre offrire giudici ad hoc, query comportamentali salvate o generazione automatica di dataset.
La competizione di prodotto non riguarda semplicemente chi offrirà per primo la ricerca in linguaggio naturale. Riguarda chi trasformerà scoperte incerte in test ripetibili con il minor numero di lacune.
Contesto, privacy e riproducibilità definiscono i limiti della beta
L’utilità della funzionalità dipende dalla comprensione, da parte dei team, dei dati che esclude e degli obblighi di governance che aggiunge.
La documentazione sui filtri di LangSmith identifica diverse limitazioni del prodotto. Al momento, le descrizioni di AI Search non possono essere salvate come viste né mantenute nei link delle pagine copiate.
Le ricerche inoltre non compaiono nella cronologia dei filtri recenti. Il pannello delle statistiche non è disponibile mentre una query AI Search è attiva.
Queste restrizioni incidono sulla riproducibilità. Un ingegnere che indaga un incidente non può semplicemente inviare a un altro revisore una query comportamentale salvata e aspettarsi un flusso di lavoro identico.
I team possono registrare altrove la formulazione, ma ciò aggiunge un processo manuale. È inoltre rilevante perché piccole variazioni nella formulazione possono influenzare le classificazioni del modello.
Il sistema applica limiti di frequenza a livello di workspace. LangChain non pubblica la soglia nella documentazione citata, quindi i team non possono ancora dedurne l’idoneità a indagini automatizzate frequenti.
Limiti più importanti derivano dalla traiettoria stessa. AI Search legge la conversazione dell’agente principale, ma non i contenuti di subagent, middleware o messaggi di compattazione.
Un flusso di lavoro multi-agent può quindi nascondere comportamenti decisivi al di fuori della rappresentazione ricercabile. L’agente padre potrebbe riportare un esito positivo mentre un subagent registra il failure effettivo.
Il sistema inoltre non può dedurre stato di esecuzione, tag, metadati o struttura della traccia dalla descrizione in linguaggio naturale. Gli utenti devono applicare filtri convenzionali per queste proprietà.
Questa divisione dovrebbe comparire nei playbook dei team. La ricerca comportamentale gestisce il significato all’interno della traiettoria, mentre i filtri strutturati gestiscono gli attributi operativi noti.
La privacy presenta un vincolo distinto. L’abilitazione di AI Search consente il trasferimento e l’elaborazione dei dati delle tracce negli Stati Uniti tramite inferenza e subprocessori gestiti da LangChain.
L’amministratore dell’organizzazione abilita la funzionalità per tutti i membri. Non è richiesta alcuna chiave separata del provider del modello.
LangChain afferma esplicitamente che i clienti non dovrebbero usare AI Search per informazioni sanitarie protette. La funzionalità non è coperta da alcun Business Associate Agreement sottoscritto da un’organizzazione con LangChain.
Questo avvertimento merita attenzione perché il lancio mette in evidenza le ricerche di informazioni di identificazione personale divulgate. Cercare dati sensibili richiede l’invio del contenuto rilevante della traccia attraverso il sistema di classificazione.
Le organizzazioni devono distinguere la revisione generale dei PII dal trattamento di dati sanitari regolamentati. Devono inoltre confermare requisiti di conservazione, accesso, residenza e subprocessori prima di abilitare la funzionalità.
Un rischio più ampio legato all’osservabilità rimane indipendentemente dal fornitore. Le tracce ricche possono acquisire prompt, risposte dei modelli, record dei clienti, documenti recuperati e risultati degli strumenti.
Una telemetria più completa migliora il debugging, aumentando al contempo le conseguenze di una raccolta eccessiva. I team dovrebbero minimizzare i campi sensibili prima che raggiungano qualsiasi piattaforma di osservabilità.
Dovrebbero inoltre testare falsi positivi e falsi negativi rispetto a campioni revisionati. Un utile benchmark della beta includerebbe incidenti comportamentali noti, negativi difficili ed esempi che spaziano tra diversi framework di agenti.
Il materiale pubblico non riporta precisione, richiamo, distribuzioni della latenza o confronti indipendenti con embedding ed evaluator predefiniti. Descrive l’architettura e un campione interno sulla lunghezza delle tracce.
Questo lascia agli acquirenti l’assenza di una misura comune della qualità della ricerca. Una funzionalità che restituisce corrispondenze plausibili può comunque trascurare i failure rari che contano di più.
L’interpretazione corretta è quindi circoscritta. LangSmith ha introdotto una promettente interfaccia di indagine, non un sostituto verificato della valutazione, della scansione di sicurezza o della revisione umana.
Il suo valore dipenderà dalla rapidità con cui gli utenti potranno convalidare un risultato, riprodurre la query e trasformare la scoperta in un controllo della qualità duraturo.
Cosa osservare dopo la beta di LangSmith AI Search
Tre segnali mostreranno se la ricerca comportamentale nelle tracce diventerà un’infrastruttura centrale o resterà una scorciatoia investigativa utile.
Il primo segnale è la selezione adattiva del contesto. LangChain afferma di stare esplorando metodi che scelgono le evidenze in base alla query e indicano quando il modello necessita di un secondo passaggio.
Questo lavoro affronta direttamente il limite di 8.000 token. Se le ricerche incentrate sugli strumenti inizieranno a dare priorità ai risultati degli strumenti, il sistema dovrebbe rilevare più failure di esecuzione nascoste dalle evidenze conversazionali.
Senza selezione adattiva, gli utenti dovranno adottare approcci distinti per diversi tipi di traccia. Le ricerche conversazionali potrebbero funzionare bene, mentre quelle operative potrebbero produrre una copertura incoerente.
Il secondo segnale è la riproducibilità. Ricerche salvate, query condivisibili, set di risultati stabili e limiti di frequenza documentati renderebbero AI Search più facile da integrare nella risposta agli incidenti.
Anche il raggruppamento di corrispondenze simili aiuterebbe i team ad andare oltre le singole tracce. LangChain afferma di voler riassumere i pattern comuni invece di restituire soltanto un elenco piatto.
Questa capacità potrebbe trasformare una ricerca ad hoc in un flusso di lavoro per insight di prodotto. I team potrebbero identificare cluster ricorrenti di failure, esaminare tracce rappresentative e creare evaluator mirati.
Il terzo segnale è la risposta della concorrenza. Datadog, Arize e altri provider di osservabilità combinano già il tracing con la valutazione basata su modelli.
Se aggiungeranno la scoperta comportamentale interattiva, la ricerca in linguaggio naturale nelle tracce diventerà un’interfaccia attesa. La concorrenza si sposterà quindi verso qualità delle evidenze, governance e integrazione con i dataset.
Se invece i concorrenti enfatizzeranno precisione valutata e monitoraggio ripetibile, LangSmith dovrà dimostrare che l’esplorazione produce miglioramenti misurabili dopo il deployment.
Gli utenti dovrebbero anche osservare la pubblicazione di benchmark sulla qualità della ricerca. Precisione e richiamo per frustrazione, attività incomplete, divulgazione non sicura ed errori degli strumenti ignorati fornirebbero una base di confronto più chiara.
Per ora, i team che valutano LangSmith AI Search dovrebbero iniziare con un set revisionato di tracce note. Possono testare diverse descrizioni, confrontare le corrispondenze restituite e documentare quali evidenze il modello non rileva.
Dovrebbero quindi usare la funzionalità per la scoperta, non per l’aggiudicazione finale. Confermare manualmente i risultati a elevato impatto e promuovere definizioni comportamentali stabili in evaluator o controlli deterministici.
Il lancio è importante perché cambia il momento in cui i team possono porre domande sul comportamento degli agenti. Non devono più prevedere ogni failure prima di raccogliere tracce di produzione.
Si tratta di un passo significativo per l’osservabilità degli agenti. La prova più difficile è se LangSmith AI Search riuscirà a rendere tali scoperte ripetibili, verificabili e sicure su carichi di lavoro reali in produzione.
