Questions clés pour évaluer les systèmes de retrieval des fournisseurs afin d’obtenir un contexte de qualité

Évaluer les systèmes de retrieval des fournisseurs commence par un test : est-ce que le système renvoie les bonnes preuves pour la question que vous avez posée, ou est-ce qu’il noie le prompt sous tout ce qui semble vaguement lié.

La plupart des démos fournisseurs mettent en avant des réponses IA générées et bien peaufinées. Mais une réponse fluide peut masquer un retrieval faible. Si le système a récupéré 40 extraits vaguement liés au lieu des 5 qui comptent vraiment, la réponse peut sembler bonne tout en passant complètement à côté du sujet.

La différence entre un système de retrieval augmented generation qui fonctionne et un autre qui frustre les utilisateurs se résume au signal par token : quelle part de la fenêtre de contexte contient de vraies preuves versus du bruit. Les sections ci-dessous présentent des critères précis, des grilles de score et des tests basés sur des personas, que vous pouvez utiliser pour distinguer un retrieval solide d’une supposition coûteuse.

Comment évaluer les systèmes de retrieval des fournisseurs pour un contexte de qualité

Commencez votre évaluation avec des requêtes en direct, pas des slide decks. Demandez à chaque fournisseur d’exécuter de vraies questions issues de votre environnement sur des politiques internes, de la documentation projet, des tickets support, des fils Slack et des spécifications d’ingénierie. Les démos préparées utilisent des données sélectionnées et des prompts pré-optimisés. Vos données, elles, sont désordonnées, multi-formats, et les droits d’accès varient selon les équipes.

C’est dans cet écart entre les conditions de démo et votre corpus réel que la plupart des systèmes de retrieval se cassent.

Notez le retrieval séparément de la génération. Une réponse bien rédigée peut cacher le fait que la bonne preuve n’est jamais apparue dans la fenêtre de contexte. Demandez aux fournisseurs de vous montrer les passages récupérés avant que le modèle de langage ne les traite.

Si ces passages ne contiennent pas la réponse, le modèle est soit en train de deviner, soit d’assembler des fragments. Dans les deux cas, ce sont des signes d’un retrieval faible. Selon Barnett et al. (2024), la plupart des échecs en retrieval-augmented generation (RAG) proviennent de la précision et du classement du retrieval, pas de l’intelligence du modèle.

Dites aux fournisseurs dès le départ ce que vous testez : si leur système peut répondre à la question derrière la requête en récupérant moins mais mieux, plutôt qu’en sur-récupérant un contexte bruité. Le principe « récupérer moins, mais mieux » signifie que le système renvoie le plus petit ensemble de sources à fort signal, respectant les permissions, nécessaire pour bien répondre à une question.

Chaque token supplémentaire envoyé au modèle de langage augmente la latence et le coût, même s’il est hors sujet. Des recherches sur l’élimination de tokens dans les modèles retrieval-augmented montrent que la suppression sélective des tokens non critiques dans les passages récupérés peut réduire le temps de décodage jusqu’à 62% avec seulement 2% de baisse de performance. Un fournisseur dont le système récupère systématiquement 30 extraits quand 4 suffiraient optimise le rappel au détriment de la précision. Vos utilisateurs ressentiront ce compromis via des réponses plus lentes et moins focalisées.

Utilisez une grille de score cohérente pour chaque fournisseur testé. Suivez ces dimensions pour chaque requête :

• Pertinence des éléments récupérés : Les passages renvoyés répondent-ils directement à la question, ou sont-ils seulement liés de manière tangentielle ?
• Qualité des preuves : Les passages proviennent-ils de sources faisant autorité et à jour, ou de brouillons archivés et de wikis obsolètes ?
• Sécurité des permissions : Le système applique-t-il les contrôles d’accès avant le retrieval, et non après ? Des permissions vérifiées en aval du modèle de langage créent un risque de fuite de données.
• Taux de doublons : Combien de passages récupérés répètent la même information avec des formulations légèrement différentes ? Les doublons gaspillent des tokens et diluent le signal.
• Nombre de tokens : Combien de tokens le système utilise-t-il par réponse ? Un nombre de tokens plus faible à qualité de réponse équivalente indique un retrieval plus serré.
• Latence : Quel est le temps jusqu’à la première réponse ? Les systèmes qui sur-récupèrent affichent souvent une latence plus élevée car ils traitent et reclassent des ensembles de candidats plus volumineux.
• Justification des réponses : Chaque affirmation de la réponse générée peut-elle être rattachée à un passage récupéré spécifique ?

Évaluez par persona et par tâche, pas seulement par sujet. Un commercial qui cherche un positionnement concurrentiel a besoin d’un comportement de retrieval différent d’un ingénieur qui débogue un incident en production ou d’un partenaire RH qui vérifie une politique d’avantages. Même si les bonnes pratiques sous-jacentes de recherche d’information sont communes, la pondération et la priorisation des sources devraient varier selon le rôle.

Lancez au moins 3 à 5 requêtes par persona pour tester si le système adapte le retrieval au contexte de l’utilisateur et à son niveau d’accès. Le Enterprise Graph de Glean gère cela en cartographiant les relations entre les personnes, le contenu et l’activité dans toute l’organisation, de sorte que les résultats de retrieval reflètent non seulement ce qui est pertinent pour la requête, mais aussi ce qui est pertinent pour la personne qui la pose.

Un exemple concret : un agent support demande : « Quelle est notre politique de remboursement pour les contrats enterprise ? » Un système de retrieval robuste renvoie le document de politique de remboursement en vigueur et la mise à jour interne la plus récente sur les exceptions. Cela fait deux ou trois passages, au périmètre bien défini.

Un système faible renvoie 15 passages, dont la politique de remboursement grand public, un brouillon archivé d’il y a deux ans, un fil Slack débattant des changements de politique, et un article de blog qui mentionne « remboursement » au passage. L’agent support doit alors trier le bruit pour trouver la réponse, ce qui va complètement à l’encontre de l’objectif du système.

1. Demandez ce que le système optimise et comment il définit un contexte pertinent

Un système de retrieval robuste optimise la capacité à répondre, pas seulement la similarité. La première question à poser à n’importe quel fournisseur est simple : que signifie un résultat de retrieval « bon » dans votre système ? Si la réponse est « les passages les plus proches de l’embedding de la requête », vous entendez une description de la recherche vectorielle, pas une stratégie de retrieval.

Les bonnes réponses décrivent les arbitrages. Le fournisseur doit expliquer comment son système équilibre précision et rappel, fraîcheur et autorité, et qualité des citations et couverture. Un résultat de retrieval n’est utile que si le modèle de langage peut s’y référer pour répondre à la question réelle de l’utilisateur.

Demandez des exemples où le système a volontairement récupéré moins d’éléments. Un fournisseur sûr de sa réduction du bruit saura vous montrer une requête où renvoyer 3 passages a mieux performé que d’en renvoyer 20. Si, à chaque fois qu’on demande « comment gérez-vous des preuves faibles ? », la réponse est « on augmente le top-k », le système traite la retrieval comme un problème de volume plutôt que de qualité.

Une bonne retrieval signifie aussi que le système comprend ce que l’utilisateur essaie de faire, pas seulement les mots qu’il a saisis. Une requête comme « checklist d’onboarding » d’un nouvel arrivant a besoin du document de politique RH à jour. La même requête d’un admin IT a besoin du runbook de provisioning. La pertinence dépend du rôle et de la tâche de l’utilisateur.

Signaux d’alerte à ce stade : le fournisseur n’arrive pas à expliquer comment ses métriques de retrieval se relient à ce que les utilisateurs vivent réellement, ou il se contente de « une fenêtre de contexte plus grande » comme correctif à chaque réponse manquée. Une fenêtre plus grande n’aide pas lorsque les passages qu’elle contient sont du bruit.

L’Enterprise Graph de Glean relie l’intention de la requête au rôle, à l’équipe et à l’activité récente de l’utilisateur, de sorte que les résultats de retrieval reflètent ce qui compte pour la personne qui demande, pas seulement ce qui correspond aux mots.

2. Demandez comment le système construit le contexte à partir des connaissances, des personnes et des autorisations de votre entreprise

Une retrieval qui ne fait que faire correspondre du texte à du texte passe à côté des signaux qui rendent les réponses en entreprise fiables. Le système doit pondérer le type de source, le propriétaire du document, les relations entre équipes, la récence et les autorisations avant qu’un seul passage n’atteigne le modèle de langage.

Les autorisations sont le point de départ non négociable. Les contrôles d’accès doivent être appliqués en amont de la génération. Un cadre récent sur les compromis du RAG en entreprise identifie le « contournement des autorisations » via une similarité sémantique aveugle comme la vulnérabilité principale lorsque l’on fait passer le RAG à l’échelle pour démocratiser l’accès aux connaissances, et propose une norme « Policy-Before-Retrieval » comme correctif. Si un système récupère un document restreint puis le supprime avant que le modèle ne réponde, le contenu est déjà entré dans le pipeline. Cela crée un chemin de fuite de données. Demandez au fournisseur : votre système vérifie-t-il les autorisations avant ou après la retrieval ?

Au-delà des autorisations, un système de retrieval doit comprendre comment les personnes, les projets et les documents sont liés entre eux via un knowledge graph. Quand un chef de produit demande le statut du lancement T3, le système doit savoir quels documents de projet sont actifs, quels canaux Slack sont pertinents et quels membres de l’équipe sont propriétaires des livrables. Une recherche à plat sur des morceaux isolés ne peut pas établir ces connexions.

Le classement doit varier selon l’utilisateur, ce qui nécessite une structure d’autorisations robuste. Un sales engineer et un responsable support qui posent la même question sur une intégration produit ont besoin de preuves différentes. Le sales engineer a besoin du document d’architecture technique et du brief de positionnement concurrentiel. Le responsable support a besoin du guide de dépannage et de la liste des problèmes connus. Même requête, résultats de retrieval différents.

Par exemple, prenez « Quoi de neuf sur Project Atlas ? ». Un responsable engineering devrait voir la rétrospective de sprint, l’architecture decision record et le résumé des pull requests ouvertes. Un VP of product devrait voir le suivi des jalons, la synthèse des retours clients et le document d’alignement de la roadmap. Si les deux utilisateurs obtiennent les mêmes 15 chunks, le système n’utilise pas le contexte organisationnel.

Signaux d’alerte ici : le fournisseur décrit la retrieval comme une « recherche sur des chunks » sans mentionner comment l’autorité de la source, la proximité d’équipe ou la récence du document influencent le classement. Un système qui traite chaque passage indexé comme ayant le même poids a peu de chances de faire remonter la bonne preuve à la bonne personne.

3. Demandez comment le contenu est découpé, enrichi et nettoyé avant la retrieval

La qualité de la retrieval dépend de décisions prises bien avant l’arrivée de la requête. La manière dont un système découpe les documents en chunks, les métadonnées qu’il y attache et la façon dont il gère le contenu obsolète ou dupliqué façonnent ce que le modèle de langage voit.

Différents types de contenu nécessitent un chunking différent. Une spécification technique avec des titres imbriqués et des tableaux requiert un parsing conscient de la structure qui préserve les limites des sections. Un thread Slack a besoin d’une segmentation au niveau des messages qui garde les réponses regroupées avec leur message parent. Un tableur a besoin d’une compréhension des lignes et des colonnes. Appliquer le même chunking à taille fixe à tous ces formats garantit que certains types de contenu perdent une structure critique.

Les métadonnées stockées avec chaque chunk déterminent si le retriever peut filtrer et classer efficacement. Au minimum, chaque chunk doit contenir son application source, le propriétaire du document, l’horodatage de dernière mise à jour, le type de document, le titre de section et le label d’accès. Sans ces métadonnées, le retriever n’a aucun moyen de distinguer une politique à jour d’un brouillon archivé, ni de prioriser un document rédigé par l’expert du domaine plutôt qu’un commentaire informel.

L’hygiène du contenu et la data governance comptent autant que le chunking. Les entreprises accumulent des documents dupliqués, des politiques obsolètes, des versions contradictoires et des modèles passe-partout. Un système qui indexe tout sans déduplication ni détection de contenu obsolète envoie au modèle de langage des preuves contradictoires. Demandez au fournisseur : comment votre système gère-t-il deux versions d’une même politique, l’une actuelle et l’autre datant d’il y a 18 mois ?

Glean Search traite plus de 100 types de contenu différents via des connecteurs qui comprennent la structure native de chaque application, en préservant les mises en page de tableaux, les hiérarchies de titres et les structures de threads au lieu d’aplatir tout en blocs de texte uniformes. Le système suit aussi la fraîcheur et la propriété des documents via l’Enterprise Graph, de sorte que le contenu obsolète ne concurrence pas à poids égal les sources à jour.

Un test utile : demandez au fournisseur de montrer comment son système gère un tableur de revue financière trimestrielle avec des cellules fusionnées et des formules intégrées. Si le retriever traite le tableur comme un sac de chaînes de texte, les chiffres et les relations entre colonnes sont perdus. Un chunking conscient de la structure devrait préserver le tableau comme une unité interrogeable.

Signaux d’alerte à ce stade : le fournisseur se concentre sur sa technologie de base de données vectorielle mais n’est pas capable de décrire une stratégie pour préserver le langage exact dans des tableaux, des listes ou des documents structurés. Les embeddings vectoriels capturent le sens, mais ils ne préservent pas la mise en forme, et la mise en forme porte souvent la réponse.

4. Demandez comment le système classe, reclasse et limite ce qui parvient au modèle

Après la récupération initiale, le vrai travail commence : décider quels passages valent la peine d’être envoyés au modèle de langage et lesquels sont du bruit. Un système qui récupère 50 candidats et en passe 50 dans le prompt gaspille des tokens et dilue le signal qui compte.

La récupération hybride combinant des signaux denses et clairsemés est un prérequis. La récupération dense (embeddings vectoriels) capture le sens sémantique. La récupération clairsemée (correspondance par mots-clés) capture les termes exacts, les acronymes, les identifiants de projet et les numéros de tickets. Les requêtes en entreprise en sont pleines. Un développeur qui recherche « PROJ-4782 timeout error » a besoin que le système corresponde exactement à cet identifiant, pas qu’il renvoie tous les documents sur les timeouts.

Une couche de reclassement après la récupération initiale lit chaque paire requête-candidat ensemble et évalue la pertinence plus précisément que la seule distance vectorielle. Des recherches récentes sur les systèmes de récupération agentiques montrent qu’une récupération itérative, augmentée par des outils, peut atteindre 49,6% de recall@1 — soit une amélioration de 21,8 points de pourcentage par rapport aux meilleures bases embedding — en laissant le modèle décider quoi rechercher et quand suffisamment de preuves ont été réunies. Demandez au fournisseur si son reranker exécute un cross-encoder ou un modèle équivalent qui compare la requête à chaque passage. Le reclassement est souvent le levier le plus important pour améliorer l’ancrage des réponses tout en réduisant ce qui arrive au prompt.

La réécriture et la décomposition des requêtes doivent être bornées, et les approches de récupération agentique gèrent cela en laissant le modèle décider de manière itérative quoi rechercher ensuite. Les bons systèmes réécrivent les requêtes pour correspondre à la terminologie indexée. Par exemple, un utilisateur demandant « comment déclarer un vol en note de frais ? » devrait aussi faire correspondre des documents intitulés « travel reimbursement policy ». Mais la décomposition des questions complexes en sous-requêtes doit avoir une limite. Une décomposition non bornée génère des appels de récupération qui multiplient la latence sans améliorer la précision.

Le top-k devrait varier selon le type de requête. Une recherche directe (« quelle est notre politique de congé parental ? ») peut nécessiter 2 à 3 passages. Une question de synthèse (« résumez les tendances du churn client du dernier trimestre ») peut en nécessiter 8 à 10 provenant de différentes sources. Une comparaison (« en quoi notre offre enterprise diffère-t-elle de notre offre growth ? ») nécessite des preuves appariées. Un top-k statique est le signe que le système n’a pas réfléchi à ces différences.

Glean applique une récupération basée sur l’intention via l’Agentic Engine, en classant les requêtes par type et en ajustant le nombre de passages récupérés, reclassés et transmis au modèle. Le système filtre également les quasi-doublons, le contenu passe-partout et les passages à faible autorité avant que le modèle de langage ne les voie.

Signal d’alerte : la réponse du fournisseur à « comment gérez-vous l’absence de preuves ? » est toujours « augmenter k » ou « utiliser une fenêtre de contexte plus grande ». Plus de tokens ne corrigent pas un problème de pertinence. Ils le masquent derrière des temps de traitement plus longs et des coûts plus élevés.

5. Demandez comment ils mesurent la qualité, l’efficacité des tokens et les modes de défaillance en production

La qualité de récupération n’est pas quelque chose que l’on teste une fois pendant une proof-of-concept, puis à laquelle on fait confiance pour toujours. Les charges de travail en production évoluent. Du nouveau contenu est indexé. Le comportement des utilisateurs change. Le fournisseur doit vous montrer une mesure continue, pas seulement des résultats d’évaluation d’avant le déploiement.

Commencez par des métriques spécifiques à la récupération. La precision@k mesure si les meilleurs résultats sont réellement pertinents. Le taux de citations (citation hit rate) suit la fréquence à laquelle les réponses générées citent un passage récupéré. Le taux de réponse étayée (answer-supported rate) mesure combien d’affirmations dans la réponse remontent à des preuves dans la fenêtre de contexte. Le taux de doublons (duplicate rate) révèle quelle part de la fenêtre de contexte répète la même information. Le taux d’abstention (abstention rate) montre à quelle fréquence le système refuse de répondre lorsque les preuves sont faibles. La latence de récupération (retrieval latency) suit le temps entre la requête et la livraison du contexte, indépendamment du temps de génération.

Le scoring de pertinence au niveau du passage est là où la plupart des fournisseurs échouent. Une revue systématique de 63 études RAG en entreprise a constaté que 80,5% s’appuyaient sur des métriques techniques comme la précision et le rappel, mais que seulement 19,5% incluaient une évaluation humaine et à peine 15,6% mesuraient l’impact métier. Les taux de victoire agrégés vous disent que « 70% des réponses ont été jugées bonnes », mais n’expliquent pas pourquoi les 30% restantes ont échoué. Demandez si le fournisseur mesure la pertinence contextuelle au niveau de chaque passage. Un système qui envoie 10 passages dont 4 sont pertinents et 6 sont du bruit paraît acceptable en agrégé, mais gaspille 60% de sa fenêtre de contexte.

Le reporting au niveau des tokens révèle les coûts et la qualité dans une même vue. Demandez au fournisseur : combien de tokens sont récupérés par requête ? Combien de tokens survivent au filtrage et au reclassement ? Que se passe-t-il pour la qualité des réponses lorsque le volume de tokens augmente ? Dans de nombreux systèmes, doubler les tokens récupérés ne double pas la qualité des réponses. Cela plafonne ou la dégrade.

Suivez le temps jusqu’à la première réponse en parallèle de la taille du prompt. Les recherches sur l’impact du nombre de tokens en entrée sur la latence confirment que le volume de récupération affecte directement les temps de réponse. Si le volume de récupération augmente et que la latence reste stable, le système filtre efficacement. Si la latence augmente linéairement avec le nombre de tokens, le système transmet au modèle un contexte non filtré.

Distinguez les échecs de récupération des échecs de génération. Quand une réponse est fausse, est-ce que la bonne preuve n’a jamais été récupérée, ou bien la preuve était-elle là mais le modèle a-t-il extrait la mauvaise information ? Ces cas nécessitent des correctifs différents. Un fournisseur qui ne peut pas distinguer les deux ne peut améliorer systématiquement ni l’un ni l’autre.

Glean mesure la qualité de récupération et de génération indépendamment à l’aide de son pipeline d’évaluation IA

, qui évalue si le système a récupéré les documents les plus pertinents et si le modèle en a extrait les bonnes informations. Des benchmarks internes montrent que les évaluateurs humains sont d’accord entre eux 79 % du temps, tandis que les évaluateurs IA sont d’accord avec les évaluations humaines 74 % du temps, ce qui fait de l’évaluation automatisée un signal fiable, prêt pour la production.

Signaux d’alerte : le fournisseur ne montre que des taux de victoire sans ventilation par cas d’usage, rôle ou type de source. Il est incapable de vous dire ce qu’il advient de la qualité des réponses lorsque le volume de tokens change. Il confond les échecs de retrieval avec les échecs de génération.

6. Demandez-leur de le prouver sur vos données, vos permissions et vos requêtes les plus difficiles

Une preuve en direct sur vos données vaut mieux que n’importe quelle diapositive de roadmap. Avant de signer un contrat, construisez un jeu de tests structuré à partir de votre propre environnement et demandez au fournisseur de l’exécuter de bout en bout.

Incluez des requêtes orientées échec. Ce sont celles qui exposent les faiblesses du retrieval, pas celles qui rendent les démos impeccables. Construisez votre jeu de tests avec des identifiants exacts (numéros de ticket, codes projet), des acronymes ambigus qui n’ont pas le même sens selon les départements, des politiques obsolètes avec des remplaçantes plus récentes, des comparaisons inter-documents qui exigent des preuves issues de plusieurs sources, des questions en plusieurs parties et du contenu soumis à des restrictions d’accès que certains utilisateurs doivent voir et d’autres non.

Pour chaque requête de test, demandez au fournisseur de montrer le chemin de retrieval complet. Vous voulez voir ce que le système a pris en compte, ce qu’il a filtré, ce qui est entré dans la fenêtre de contexte finale, et pourquoi. Si le fournisseur ne peut vous montrer que la réponse générée sans la trace de retrieval qui la sous-tend, vous ne pouvez pas évaluer si la réponse est fondée ou inventée.

Faites attention aux moments où le système choisit de ne pas répondre. Un système de retrieval qui produit toujours une réponse, même lorsque les preuves sont faibles, sur-génère. La capacité à s’abstenir indique que le système sait évaluer sa propre confiance. Demandez au fournisseur de démontrer un cas où son système a refusé de répondre faute de preuves suffisantes dans les contenus récupérés.

Exécutez des tests côte à côte où une fenêtre de contexte plus petite surpasse une plus grande. Demandez au système de répondre à la même question en utilisant 3 passages puis 15. Si la réponse avec 3 passages est tout aussi exacte et 4 fois plus rapide, vous avez la preuve que le filtrage du système fonctionne. Si la réponse avec 15 passages est meilleure, le système s’appuie peut-être sur le volume plutôt que sur la précision.

Évaluez chaque requête de test selon 5 résultats : pertinence (les passages répondent-ils à la question ?), fiabilité (les sources sont-elles actuelles et faisant autorité ?), sécurité des permissions (le système a-t-il respecté les contrôles d’accès ?), latence (combien de temps entre la requête et la réponse ?), et explicabilité (peut-on relier la réponse à des passages récupérés spécifiques ?).

Le permission-aware retrieval de Glean applique les contrôles d’accès avant que tout contenu n’entre dans le pipeline de retrieval. Pendant les évaluations, le système montre la trace complète de retrieval, y compris quelles sources ont été prises en compte, lesquelles ont été filtrées, et lesquelles ont contribué à la réponse finale. Cette transparence vous permet d’auditer le système selon vos propres critères.

Signaux d’alerte : le fournisseur évite d’exécuter sur les données client, esquive les cas de test sensibles aux permissions, ou ne peut pas expliquer comment une décision de retrieval spécifique a été prise.

Questions clés pour évaluer les systèmes de retrieval des fournisseurs afin d’obtenir un contexte de qualité : questions fréquentes

Quelles fonctionnalités spécifiques devons-nous rechercher dans un système de retrieval pour s’assurer qu’il récupère moins, mais mieux ?

Recherchez une recherche hybride (combinant retrieval dense et sparse), une couche de reranking dédiée qui score les passages par rapport à la requête, un ajustement top-k basé sur l’intention qui fait varier le volume de retrieval selon le type de requête, et une application des permissions en amont qui filtre le contenu restreint avant qu’il n’atteigne le modèle.

Comment évaluer la qualité du contexte fourni par le système de retrieval d’un fournisseur ?

Demandez au fournisseur de montrer les passages récupérés avant que le modèle de langage ne les traite. Notez chaque passage selon sa pertinence directe par rapport à la requête, l’autorité de la source, la fraîcheur, et la possibilité pour la réponse finale de le citer. Exécutez ce test sur vos propres données avec de vraies requêtes utilisateurs, pas des exemples sélectionnés par le fournisseur.

Quelles métriques pouvons-nous utiliser pour évaluer l’efficacité d’un système de retrieval ?

Suivez la précision à k, le taux de citations réussies, le taux de réponses étayées, le taux de doublons, le taux d’abstention, les tokens récupérés par requête, et le temps jusqu’à la première réponse. Mesurez ces éléments au niveau des passages, pas uniquement en agrégé, et dissociez la qualité du retrieval de la qualité de génération pour identifier quelle étape échoue.

Quels pièges courants devons-nous connaître lors de l’évaluation des systèmes de retrieval ?

Méfiez-vous des fournisseurs qui utilisent des données de démo toutes faites plutôt que votre corpus réel, traitent « augmenter top-k » comme une solution universelle, appliquent les permissions après le retrieval au lieu d’avant, confondent les métriques de retrieval avec les métriques de génération, ou ne montrent que des taux de victoire agrégés sans détail par requête selon le rôle, le type de source ou le cas d’usage.

Comment s’assurer que le système d’un fournisseur minimise le bruit dans le contexte récupéré ?

Testez avec des requêtes conçues pour faire ressortir le bruit : documents obsolètes remplacés par des versions plus récentes, contenu dupliqué entre plateformes, modèles standards (boilerplate) et termes ambigus ayant plusieurs sens. Un système qui renvoie un contexte propre doit montrer une déduplication, un filtrage de l’obsolescence et un chunking conscient de la structure, qui préserve la mise en page du document au lieu d’aplatir tout en texte brut.

Les fournisseurs qui gagneront votre confiance sont ceux qui montrent leurs résultats de retrieval avant leurs réponses générées, exécutent vos requêtes les plus difficiles sur vos propres données, et expliquent ce qu’ils ont filtré en chemin. La qualité du retrieval est le socle dont dépend chaque réponse IA, et vous méritez de le voir à l’œuvre avant de signer.

Demander une démo pour découvrir comment Glean et l’IA peuvent transformer votre environnement de travail.