L'hallucination n'est pas une ambiance : comment détecter réellement les allégations non fondées dans la sortie de l'agent

Toutes les équipes à qui je parle disent que leur agent « hallucine parfois », et presque aucun d'entre eux ne peut me dire à quelle fréquence. Cet écart – entre savoir que cela se produit et être capable de le compter – est tout le problème. Vous ne pouvez pas réparer, bloquer ou même suivre un mode de défaillance que vous détectez uniquement au toucher.

Voici l'opinion que je défendrai : la détection des hallucinations n'est pas un problème de qualité de modèle, c'est un problème d'instrumentation. La raison pour laquelle vous ne pouvez pas le mesurer est que vous avez jeté les preuves au moment où l'agent a fini de courir. Détecter une réclamation non fondée nécessite de savoir ce que l'agent a été autorisé à réclamer, et cela réside dans les sorties de l'outil et le contexte récupéré, et non dans la chaîne de réponse finale. Si vous ne les capturez pas, chaque contrôle d'hallucination que vous écrivez n'est qu'une supposition.

Permettez-moi de vous expliquer ce qu'est réellement une hallucination dans un système agent, pourquoi les méthodes de détection populaires ne répondent pas aux cas courants et comment câbler un numéro que vous pouvez mettre dans CI.

"Hallucination", c'est trois insectes différents portant un seul manteau

Le mot est surchargé, et c’est à cause de cette surcharge que les efforts de détection échouent. Dans un agent utilisant un outil, il y a au moins trois échecs distincts que les gens regroupent :

1. Fuite paramétrique. L'agent répond à partir de la mémoire de données d'entraînement au lieu du résultat de l'outil qui lui a été fourni. La réponse pourrait même être correcte, mais elle est correcte par chance, non pas parce qu'elle a utilisé les données sur lesquelles vous l'avez fondée. Demain, le même chemin de code produit une réponse fausse en tou...
   [Courte citation de 8% de l'article original]