LangSmith lance AI Search : les traces d'agents se recherchent désormais par description du comportement

LangChain a ajouté à LangSmith un mode AI Search : les traces peuvent désormais être recherchées en langage courant. Le développeur décrit le comportement qu'il cherche, et la plateforme renvoie les exécutions où il s'est produit. L'annonce est sortie le 13 octobre 2026. Elle est courte : elle présente l'idée, mais ne cite ni le modèle, ni les limites, ni le prix. Cette idée touche pourtant un point douloureux ancien pour tous ceux qui exploitent des agents en production.

Ce qui a été lancé exactement

LangSmith est la plateforme d'observabilité et d'évaluation des créateurs de LangChain. Chaque exécution d'un agent y est enregistrée sous forme de trace : une chaîne d'appels au modèle, aux outils, de raisonnements intermédiaires et de réponses. Quand un agent tourne depuis plus de quelques jours, ces traces se comptent par milliers.

Jusqu'à présent, on les recherchait via des champs structurés : statut, durée, tags, nom de l'outil, coût. Cela fonctionne si l'on sait d'avance quel critère chercher. AI Search change le point d'entrée. Au lieu d'un ensemble de conditions, on écrit une phrase comme « l'utilisateur est agacé par la réponse » ou « l'agent rappelle plusieurs fois le même outil ». Le système détermine lui-même quelles traces correspondent à cette description.

Les faits clés de l'annonce :

• Format de la requête : langage naturel, sans syntaxe spécifique.
• Critère de recherche : le comportement de l'agent, et non les valeurs des champs.
• Résultat : un ensemble de traces dans lesquelles ce comportement s'est produit.
• Date de l'annonce : 13 octobre 2026, blog de LangChain.
• Non communiqués : le modèle utilisé pour interpréter les requêtes, les limites, le prix, les langues de requête prises en charge.

Pourquoi la recherche par comportement concerne surtout les agents

Pour un service classique, une panne se traduit par une erreur 500 ou un pic de latence. Un agent tombe en panne de façon plus subtile. Il peut terminer formellement sa tâche tout en effectuant une dizaine d'appels superflus, en ignorant une consigne du prompt système ou en inventant des données avec aplomb. Le statut de cette trace sera « succès », et un filtre sur le statut ne la fera pas remonter.

Les équipes en sont donc réduites à lire à la main des échantillons de traces ou à écrire un évaluateur distinct pour chaque type de problème. La recherche par description modifie l'ordre de travail. On formule d'abord une hypothèse (« il semble que l'agent s'embrouille quand l'utilisateur change les conditions au milieu d'un dialogue »), puis on voit immédiatement des exemples. À partir des meilleurs exemples, on peut ensuite constituer un jeu de test ou un évaluateur.

Pour LangChain, c'est un mouvement logique. Les concurrents dans l'observabilité des LLM, de Langfuse à Arize en passant par Braintrust, s'orientent eux aussi vers l'analyse sémantique des traces. Un produit qui vit des données sur ce qu'ont fait les agents ajoute naturellement une couche permettant d'interroger ces données.

Ce qui reste en suspens

Le texte de l'annonce laisse plusieurs points dans le flou, et la valeur réelle de la fonction en dépend.

Premier point : la précision. Une recherche sémantique sur de longues traces comportant des appels imbriqués peut passer à côté de résultats pertinents ou produire du bruit. La part de résultats manqués n'a pas encore été publiée.

Deuxième point : l'échelle. On ne sait pas si le système cherche dans tout le projet ou dans une fenêtre de temps choisie, ni ce que cela coûte en tokens.

Troisième point : la confidentialité. Les traces contiennent souvent des données d'utilisateurs. Les équipes soumises à des exigences strictes voudront savoir quel modèle lit leurs traces et où il s'exécute.

Comment l'utiliser en pratique

Si vos agents écrivent déjà des traces dans LangSmith, il est raisonnable de tester la fonction sur des problèmes connus. Prenez trois à cinq cas que vous aviez trouvés à la main, décrivez-les par des phrases et comparez les résultats avec ce que vous savez déjà. Vous évaluerez ainsi rapidement l'exhaustivité et le bruit.

Formulez vos requêtes à partir d'une action observable plutôt que d'un jugement : « l'agent a appelé la recherche plus de trois fois de suite » est plus fiable que « l'agent a mal travaillé ». Il vaut mieux enregistrer les traces trouvées dans un dataset de tests de régression, afin qu'une trouvaille ponctuelle devienne une vérification permanente.

Enfin, tant que LangChain n'a pas publié de chiffres sur la qualité et le coût, considérez AI Search comme un moyen rapide de repérage, et non comme l'unique source de vérité sur le comportement d'un agent. Les scénarios critiques restent mieux couverts par des évaluateurs et des métriques explicites.