Erreurs confiantes provoquées par un rappel RAG élevé

Lorsque de nombreuses équipes lancent RAG pour la première fois, le premier indicateur sur lequel elles se concentrent est généralement le volume de rappels.

Si 3 coups ne suffisent pas, ajustez-le à 8 coups ; si 8 résultats ne sont toujours pas stables, continuez à assouplir le seuil de similarité vectorielle, puis empilez BM25, le filtrage des balises et l’expansion des synonymes. Le taux de réussite sur le panneau semble intéressant, et de nombreux problèmes semblent être « couverts ». Mais après avoir fonctionné en ligne pendant un certain temps, un autre type de questions plus difficiles est apparu : les réponses ont commencé à ressembler de plus en plus à la vérité et le ton est devenu de plus en plus complet. Cependant, une fois la source soigneusement vérifiée, elle a été mélangée à des règles d’anciennes versions, à d’autres documents de locataire, à des SOP obsolètes et même à des instructions contradictoires.

Mon jugement sur ce type de problème est le suivant : **La fiabilité de RAG souffre souvent du “rappel de trop de choses qui ne devraient pas apparaître en même temps”. Une fois que le contexte est rempli d’informations contradictoires, de documents expirés et de contenus avec des autorisations incohérentes, le modèle ne vous dira pas honnêtement « les preuves sont contradictoires et il est impossible de répondre à la réponse ». Il est plus courant de suivre l’inertie du langage et de coudre ces fragments dans une réponse qui semble complète, mais en réalité la chaîne des preuves a été relâchée. **

Ce type de problème ressemble au début à un rappel insuffisant, mais s’avère ensuite être une pollution du contexte.

C’est la première fois que j’exprime clairement ce jugement. En apparence, il semble que la réponse du modèle soit trop courte, mais en réalité elle est plus proche du fait qu’elle est trop lisse.

Le scénario est une session de questions et réponses sur les connaissances internes au sein d’une entreprise. L’utilisateur a posé une question très spécifique dans le lien d’approbation du remboursement : après un voyage d’affaires à l’étranger dépassant la limite, s’il faut d’abord s’adresser au superviseur direct pour approbation, ou se rendre d’abord au centre de coûts pour examen. Le système ne parvient souvent pas à répondre aux questions au début, et la raison est simple. Les systèmes associés sont dispersés dans différentes bases de connaissances, et les recherches vectorielles ne peuvent souvent en obtenir que la moitié.

L’équipe a donc procédé à une série d’améliorations très typique :

• TopK augmenté de 4 à 10 ;
• Ajout de mots-clés pour rappeler l’essentiel ;
• Correspondance d’expressions synonymes détendue ;
• Rassemblez les annonces historiques, les FAQ et les textes du système dans l’ensemble des candidats.

Cela fonctionne bien à court terme. La réponse n’est plus « Aucune information pertinente trouvée », mais peut désormais organiser des étapes complètes. Le problème commence ici : les utilisateurs signalent que la réponse “semble être la bonne réponse”, mais s’ils la suivent réellement, ils feront le mauvais ordre.

Plus tard, lorsque j’ai démonté une mauvaise réponse et l’ai regardée, trois types de matériaux sont apparus simultanément dans le contexte du modèle :

1. La chaîne d’approbation dans l’ancien système il y a six mois ;
2. Clauses d’exception dans le texte du nouveau système ;
3. Description d’une autre entité régionale dans la FAQ.

Chacun de ces trois documents n’est pas un déchet et semble même « très pertinent » lorsqu’on le considère individuellement. Le problème est qu’ils n’appartiennent pas au même espace de décision. Le modèle obtient un ensemble de fragments liés en termes de mots mais dont les limites commerciales sont incohérentes. En fin de compte, la réponse obtenue a été de mélanger les trois matériaux dans un nouveau processus.

C’est là que de nombreux projets RAG risquent le plus d’être mal évalués : en apparence, il semble que « le rappel soit devenu plus fort », mais en substance, cela fait passer l’erreur de récupération du « manque de preuves » à « des preuves sales entrant dans la phase de génération ».

Après d’autres rappels, le modèle ne deviendra pas plus prudent, mais deviendra seulement meilleur dans la réparation des coutures.

Une situation courante est que, par défaut, donner plus d’informations au modèle le laissera, au mieux, simplement choisir.

Mais la situation réelle est plus proche d’un autre mécanisme : plus le contexte est long, plus il y a de fragments et plus la relation sémantique est lâche, plus il est facile pour le modèle d’épeler « partiellement raisonnable » en « globalement vrai ». **

En effet, la phase de génération est confrontée à une chaîne de texte linéarisée. Tant que ces textes peuvent littéralement se rapprocher, le modèle aura naturellement tendance à combler le fossé. Cette tendance sera particulièrement forte dans les situations suivantes :

• Les deux documents aboutissent à des conclusions différentes, mais partagent de nombreux termes commerciaux ;
• Lorsque le nouveau système a renversé l’ancien système, il n’a pas dit clairement « les anciennes règles sont abolies » ;
• La FAQ résume le texte en termes familiers, mais omet les conditions applicables ;
• Les contenus multi-locataires, multi-régions et multi-versions sont rappelés ensemble, mais ne sont distingués que dans les métadonnées.

À ce stade, le modèle n’exposera pas directement « Je vois un conflit », mais fera souvent trois choses :

1. Donnez la priorité aux phrases qui forment le mieux un récit complet ;
2. Remplissez automatiquement les liens de cause à effet qui ne sont pas explicitement indiqués dans le contexte ;
3. Avalez les conditions aux limites et remplacez-les par des expressions qui ressemblent davantage à des règles générales.

En fin de compte, ce que l’utilisateur voit est une réponse fluide, complète et qui semble avoir été évaluée de manière globale. Le vrai danger est que cela taquine le conflit.

Les documents obsolètes ne sont pas du bruit, ils dilueront activement le poids des nouvelles preuves

Lorsque de nombreuses équipes corrigent les réponses incorrectes de RAG, elles ont l’habitude de traiter les documents expirés comme une sorte de « bruit de mauvaise qualité » et estiment que tant que le nombre est petit, ce n’est pas un gros problème.

Mais pendant la phase de génération, les documents expirés constituent souvent des preuves concurrentes qui modifient activement l’orientation de la réponse.

Un exemple plus typique que j’ai vu est la base de connaissances du service client. Une certaine règle de remboursement a été modifiée dans la nouvelle version de la politique, mais l’ancienne version de la FAQ est plus susceptible d’être classée plus haut lors de la phase de rappel en raison de son nombre élevé de visites et de ses expressions plus familières. Le texte de la nouvelle politique est rédigé avec précision mais avec rigueur ; l’ancienne FAQ est rédigée de manière fluide et dispose d’un modèle rhétorique complet. En conséquence, lorsque le modèle répond, il est très facile de considérer la nouvelle version des règles comme des restrictions locales et l’ancienne FAQ comme le récit principal.

La réponse finale ressemble souvent à ceci :

通常情况下用户可先申请原路退款，如遇活动商品则需进一步审核。

La chose la plus puissante à propos de cette phrase est que presque tous les mots peuvent être trouvés dans le contexte, mais la phrase entière elle-même n’existe dans aucune source. La véritable nouvelle règle a peut-être été modifiée en « Les produits actifs ne prennent pas en charge les remboursements initiaux », et le « généralement » dans l’ancienne FAQ a été utilisé par le modèle comme une phrase générale, supprimant directement la nouvelle règle en une exception.

Par conséquent, le problème des documents expirés n’est jamais simplement que « d’anciennes informations ont été mélangées », mais que d’anciennes informations ressemblent souvent davantage à un discours humain et sont plus faciles à utiliser comme squelette par les modèles**.

Rappeler des autorisations incohérentes est plus gênant que de mauvaises réponses, car cela créera des réponses « apparemment bien fondées » qui dépassent l’autorité.

Un autre problème souvent sous-estimé concerne les limites des autorisations.

De nombreux systèmes internes de RAG placent la vérification des autorisations au niveau de « si le document peut être ouvert », pensant que tant que le texte original n’est pas affiché à l’utilisateur à la fin, tout ira bien. Le véritable danger du système génératif est le suivant : **Tant que le document restreint entre dans le contexte, même si le texte original n’est pas publié à la fin, la réponse elle-même peut avoir révélé des jugements qui ne devraient pas être connus. **

Par exemple, lorsque le service commercial pose une question sur l’approbation d’un contrat, il n’existe que des procédures générales dans la base de connaissances publique, et il existe une clause d’exception pour les clients particuliers dans la base de connaissances juridiques. Si l’étape de récupération ne fait que “rappeler d’abord, puis recadrer”, alors le modèle a peut-être profité de cette règle d’exception lors de l’étape de brouillon et a finalement émis une suggestion apparemment neutre :

Ces clients nécessitent généralement une approbation supplémentaire du responsable régional.

L’utilisateur ne peut pas voir le document restreint, mais il a reçu une règle d’organisation dont il n’aurait pas dû connaître l’existence. Ce qui est encore plus troublant, c’est que cette phrase est difficile à identifier comme une fuite dans sa forme, car elle ressemble moins à un copier-coller qu’au modèle « l’a résumé par lui-même ».

Par conséquent, la question des autorisations ne peut pas être comprise uniquement comme un contrôle d’accès, mais doit être comprise comme un contrôle des sources de preuves. Dès que des matériaux qui n’appartiennent pas à la même plage visible sont introduits ensemble dans le modèle, le système franchit une ligne. Les désensibilisations et les restrictions de référence ultérieures ne concernent que les contaminations déjà survenues.

Ce qui doit vraiment être optimisé, c’est d’abord laisser les preuves converger en fonction de la limite de décision

De nombreux systèmes RAG deviennent ensuite de plus en plus chaotiques. En apparence, il semble que le modèle soit trop faible. En fait, elle est plus proche de l’étape de récupération et la direction de l’optimisation elle-même est biaisée.

Ce à quoi les équipes sont le plus susceptibles de se livrer, c’est de traiter les rappels comme des problèmes de moteur de recherche :

• Si la corrélation n’est pas suffisante, ajouter un canal de rappel ;
• Si la couvrance n’est pas suffisante, ajoutez un peu plus de topK ;
• La méthode de requête de l’utilisateur est instable, alors réécrivez davantage la requête.

Ces actions ne sont pas nécessairement fausses, mais s’il y a un manque de contraintes de « limites de décision », davantage de matériaux qui ne devraient pas apparaître en même temps seront envoyés à l’étape de génération.

Ce à quoi je prête plus attention plus tard, c’est un autre ensemble de séquences de convergence :

1. Effectuez d’abord la convergence des plages, puis effectuez le tri par corrélation.

De nombreuses questions et réponses peuvent en fait limiter la portée avant la récupération sémantique, telles que :

• entité organisationnelle ;
• région ou pays ;
• Temps effectif ; -Type de document ;
• Champ des autorisations utilisateur.

Si ces conditions ne sont pas prises en compte en premier et que le classement est basé uniquement sur la similitude intégrée, le résultat inclura certainement des éléments « similaires ». C’est parce que l’ensemble des candidats est mal défini.

2. Traitez la version et l’heure effective comme des citoyens de premier ordre plutôt que comme des métadonnées subsidiaires

De nombreuses bases de connaissances comportent évidemment des champs updated_at, version et status, mais ils ne sont utilisés que dans la couche de présentation et participent peu à la prise de décision lors de la récupération et de l’énonciation du contexte. De cette façon, l’ancien document et le nouveau document sont traités de la même manière et le modèle n’a aucune idée de qui doit écraser qui.

Une approche plus stable consiste à gérer explicitement la relation de couverture :

• Les documents obsolètes n’entrent pas dans le contexte de génération par défaut ;
• Lorsque les règles anciennes et nouvelles entrent en conflit, elles sont directement marquées comme conflits et le modèle ne peut pas être synthétisé librement ;
• La FAQ ne peut pas couvrir le texte principal du système et ne peut être utilisée que comme couche d’explication pour le compléter.

3. Laissez le conflit être exposé au lieu de laisser le modèle être l’arbitre au lieu du système.

De nombreux systèmes assemblent par défaut plusieurs matériaux candidats directement et les transmettent au modèle, en espérant que le modèle les « comprendra de manière globale » par lui-même. Cette étape est précisément la plus dangereuse, car elle sous-traite la gestion des conflits de preuves à la couche la plus apte à combler les lacunes.

Si deux documents de poids élevé contiennent des conclusions contradictoires, un comportement plus raisonnable du système consiste généralement à indiquer explicitement à l’utilisateur :

• Des règles contradictoires ont été trouvées ;
• Où sont les points de conflit ?
• Quelle version est actuellement utilisée par défaut, ou une confirmation manuelle est requise.

Cela n’a pas l’air aussi soyeux, mais c’est vraiment contrôlable. Reconnaître un conflit ressemble plus à un système fiable qu’à donner une réponse complète mais falsifiée.

Un cas d’échec particulièrement courant : considérer le réarrangement comme la solution finale

Après que de nombreuses équipes aient constaté que « plus il y a de rappels, plus il y a de chaos », elles utiliseront immédiatement le reranker. En conséquence, la qualité du tri s’est effectivement améliorée et ils considèrent donc le problème comme résolu.

Mais ce que le reranker peut résoudre est principalement « qui ressemble le plus à la réponse à la question » ; il ne peut pas déterminer « si ces candidats appartiennent au même espace de faits de fusion ».

Si l’ensemble candidat contient les deux :

• Règlement Région A 2024 ;
• Règles de la région B 2025 ;
• Instructions d’exception internes pour les administrateurs ;
• FAQ pour les employés ordinaires ;

Le reranker ne classe que deux ou trois des articles plus haut. Il ne peut pas fondamentalement décider pour le système si ces matériaux peuvent être introduits ensemble dans le modèle.

Cela montre également que de nombreuses critiques de RAG semblent bonnes hors ligne, mais commencent à dériver dès qu’elles entrent dans des scènes complexes en ligne. Les questions et réponses dans les collections hors ligne sont souvent uniques, standards et ont des limites claires ; la véritable complexité des questions en ligne réside dans le fait qu’elles sont liées aux versions, aux autorisations, aux structures organisationnelles et aux exceptions. Le tri ne donne la priorité qu’aux matériaux les plus similaires et ne gère pas automatiquement l’équipe.

Limite applicable : tous les scénarios ne devraient pas réduire le montant du rappel

Dire « trop de rappels facilitent les erreurs » ne signifie pas que tous les systèmes devraient réduire topK très petit.

Si vous effectuez des questions et réponses exploratoires, une collecte de données et une aide à la recherche, il est raisonnable de fournir plus de matériel, et les utilisateurs sont prêts à accepter « il y a plusieurs opinions ici ». Dans ce scénario, l’objectif du système est d’aider les utilisateurs à naviguer dans l’espace d’informations.

Ce qui doit vraiment contrôler strictement la limite de rappel, ce sont les scénarios dans lesquels la réponse sera directement exécutée, tels que :

• Questions et réponses institutionnelles ;
• Processus d’approbation ;
• Calibre du service à la clientèle;
• Runbook d’exploitation et de maintenance ;
• Aide à la décision médicale, financière et de conformité.

Dans ces scénarios, la capacité la plus importante du système est de « ne pas combiner des preuves mutuellement incompatibles dans une instruction exécutable ». Une fois que le coût d’une mauvaise réponse est supérieur à celui de l’impossibilité de répondre, la stratégie de recherche ne peut plus s’articuler uniquement autour de la couverture.

Résumé

La chose la plus addictive de RAG est qu’il peut toujours améliorer l’apparence des données du panel à court terme en “rappelant un peu plus”.

Mais une fois qu’un système de connaissances est effectivement lancé, le plus difficile à collecter est de savoir si les matériaux qui entrent dans le contexte appartiennent au même ensemble de frontières factuelles, à la même sémantique de version et à la même portée d’autorité.

Tant que la question n’est pas réglée au préalable, plus il y aura de rappels, plus le modèle ressemblera à une personne particulièrement douée pour rédiger des résumés : il ne dira pas nécessairement délibérément des bêtises, mais il rassemblera des preuves qui ne devraient pas être rassemblées dans une réponse qui ressemble beaucoup à une conclusion.

Par conséquent, lors de la prochaine étape de l’optimisation de RAG, nous ne devrions souvent pas demander « combien de choses supplémentaires peuvent être rappelées », mais d’abord demander : ** Quel contenu ne doit pas du tout apparaître ensemble dans la même invite. **