Détecter les lacunes de votre base avec les requêtes utilisateurs

Vos utilisateurs vous disent en permanence ce qui manque dans votre base de connaissances. Chaque question posée à votre assistant est un signal : soit la réponse existe et il la trouve, soit elle n'existe pas — et c'est précisément là que se cache la valeur. La plupart des organisations laissent ce signal se perdre. Pourtant, exploité correctement, il transforme un corpus statique en un organisme vivant piloté par l'usage réel.

Voici comment détecter les lacunes de votre base à partir des requêtes utilisateurs, et surtout comment fermer la boucle pour les combler.

Qu'est-ce qu'une lacune de connaissances ?

Une lacune est une question pour laquelle votre corpus ne contient aucune réponse satisfaisante. C'est différent d'un problème de récupération, où l'information existe mais n'est pas remontée correctement. Confondre les deux est l'erreur la plus fréquente — et elle envoie les équipes corriger le mauvais problème.

Prenons un exemple concret. Un assistant RAG interne reçoit la question : « Quel est le délai de rétractation pour un contrat signé électroniquement avec un client allemand ? » Trois scénarios sont possibles. (a) La procédure existe, bien découpée, et le système la remonte avec un score de similarité élevé : tout va bien. (b) La procédure existe dans un PDF de 80 pages, mais le passage pertinent a été noyé dans un chunk de 1000 tokens mélangeant cinq juridictions : c'est un problème de récupération. (c) La procédure n'a jamais été documentée pour l'Allemagne : c'est une vraie lacune. Les trois donnent une mauvaise réponse à l'utilisateur, mais appellent trois actions radicalement différentes.

Lacune ≠ mauvaise récupération. La première se règle en créant du contenu ; la seconde en corrigeant le pipeline. Diagnostiquer juste, c'est déjà la moitié du travail.

Comment les détecter

Les lacunes laissent des traces mesurables. Aucun signal pris isolément n'est fiable ; c'est leur combinaison qui fait le diagnostic.

• Faible score de similarité — la meilleure correspondance récupérée reste sous un seuil de pertinence. Le système « gratte les fonds de tiroir ».
• Réponses non sourcées ou « je ne sais pas » — un assistant bien conçu refuse d'inventer ; ces refus sont de l'or, car ils localisent les manques.
• Faible confiance du reranker — même après reranking cross-encoder (Cohere Rerank 3, bge-reranker-v2-m3), aucun passage ne se détache nettement du bruit.
• Feedback négatif explicite — pouce vers le bas, reformulations en cascade, escalades vers un humain.
• Questions répétées sans résolution — un même thème revient, jamais satisfait.

Des seuils indicatifs, pas des vérités absolues

Le score de similarité dépend du modèle d'embedding et de la métrique (cosinus, produit scalaire). Avec un modèle moderne comme text-embedding-3-large ou voyage-3 et une similarité cosinus normalisée entre 0 et 1, on observe souvent, à titre indicatif :

• au-dessus de 0,80 : correspondance forte, le contenu existe quasi certainement ;
• entre 0,60 et 0,80 : zone grise, à arbitrer avec le reranker et le feedback ;
• en dessous de 0,55-0,60 : signal de lacune probable, surtout si le meilleur des top-k passages reste bas.

Ces chiffres sont des ordres de grandeur à calibrer sur vos propres données, jamais des constantes universelles. La bonne méthode : prélever 100 à 200 requêtes annotées manuellement (réponse trouvée / non trouvée), tracer la distribution des scores, et placer le seuil là où le taux de faux négatifs devient acceptable. Un seuil trop haut classe en « lacune » des questions dont la réponse existait : vous créez des doublons. Un seuil trop bas laisse passer de vrais manques.

Ne pilotez jamais la détection sur un seul seuil de similarité figé. Croisez-le toujours avec la confiance du reranker et le feedback réel : un score moyen + un pouce vers le bas est un signal bien plus solide qu'un score isolé.

Trois causes, trois remèdes

Une fois une lacune repérée, identifiez sa cause avant d'agir :

1. L'information n'existe pas → il faut créer du contenu. C'est une vraie lacune.
2. L'information existe mais est mal indexée ou mal découpée → c'est un problème de pipeline (chunking, embedding, métadonnées). On corrige la récupération, pas le corpus. Les leviers concrets : revoir la stratégie de découpage (chunks plus petits, respect des frontières sémantiques), tester le contextual retrieval (préfixer chaque chunk d'un court contexte généré par LLM, technique formalisée par Anthropic), ajouter une recherche hybride BM25 + dense fusionnée en RRF pour rattraper les requêtes à vocabulaire exact (références produit, codes d'erreur).
3. L'information existe mais est contradictoire ou périmée → c'est un problème de gouvernance. Le système trouve plusieurs réponses incompatibles et ne sait pas laquelle privilégier. Ici, créer un nouvel article ne fait qu'aggraver le désordre : il faut désigner une source de vérité, archiver les versions obsolètes et dater les contenus.

Avant de rédiger un nouvel article, vérifiez toujours que l'information ne dort pas déjà quelque part, mal rangée. On crée trop de doublons faute d'avoir diagnostiqué la cause.

Un test simple pour trancher entre lacune et problème de pipeline : reformulez vous-même la question avec les mots-clés exacts du document que vous pensez exister, et relancez la recherche. Si le bon passage remonte alors, c'est un problème de récupération (vocabulaire, chunking). S'il ne remonte toujours pas et que vous ne trouvez l'information nulle part en cherchant à la main, c'est une vraie lacune.

Outiller le clustering des requêtes

Le maillon le plus négligé est le clustering. Vingt utilisateurs formulent la même lacune de vingt façons différentes (« congés payés à l'étranger », « RTT expatrié », « jours off en télétravail depuis l'Espagne »…). Sans regroupement, vous voyez vingt incidents anecdotiques au lieu d'un manque prioritaire.

La méthode est directe et réutilise l'infrastructure que vous avez déjà pour le RAG :

1. Embedder chaque requête avec le même modèle que votre corpus (cohérence de l'espace vectoriel).
2. Regrouper par similarité. Pour quelques centaines à quelques milliers de requêtes, un clustering par densité (type HDBSCAN) évite d'avoir à fixer le nombre de clusters à l'avance et isole proprement les requêtes uniques en « bruit ». Pour de plus gros volumes, un seuil de similarité cosinus (par ex. regrouper toute requête au-dessus de 0,75 d'un centroïde) suffit souvent.
3. Étiqueter chaque cluster automatiquement en demandant à un LLM de résumer en une phrase les 5-10 requêtes représentatives — cela donne un libellé lisible (« Politique de télétravail hors de France ») bien plus utile qu'un identifiant de cluster.
4. Conserver, par cluster : volume mensuel, score de similarité médian des réponses, taux de feedback négatif.

-- Esquisse : remonter les clusters de requêtes en lacune probable
SELECT
  q.cluster_label,
  COUNT(*)                       AS volume,
  AVG(q.top_similarity)          AS sim_mediane,
  AVG(CASE WHEN q.feedback = 'down' THEN 1 ELSE 0 END) AS taux_neg
FROM query_logs q
WHERE q.created_at >= now() - interval '30 days'
  AND q.top_similarity < 0.60          -- seuil de lacune calibré
GROUP BY q.cluster_label
HAVING COUNT(*) >= 5                    -- ignorer le bruit anecdotique
ORDER BY volume DESC;

Vous n'avez pas besoin d'un outil dédié coûteux : pgvector stocke déjà vos embeddings, et un job hebdomadaire de clustering + étiquetage suffit à alimenter un tableau de bord. L'essentiel est la régularité, pas la sophistication.

Mettre en place la boucle de détection

La détection ponctuelle ne sert à rien ; c'est un processus continu. Les étapes :

1. Journaliser toutes les requêtes, avec le score de récupération, la confiance, le statut de la réponse (sourcée / non sourcée / refus) et le feedback éventuel.
2. Scorer chaque requête sur son risque de lacune (combinaison des signaux ci-dessus).
3. Clustériser les questions sans réponse satisfaisante : beaucoup de formulations différentes pointent souvent vers un même manque.
4. Prioriser par fréquence × valeur métier. Une lacune posée 200 fois par mois sur un sujet stratégique passe avant une question unique et anecdotique.
5. Assigner la création ou la correction de contenu à un responsable, avec une échéance.
6. Vérifier que le comblement a bien résolu le problème (la question suivante sur le sujet doit désormais trouver réponse).

Requêtes ──► journalisation ──► scoring lacune ──► clustering
                                                       │
                                          priorisation (fréquence × valeur)
                                                       │
                                       création / correction de contenu
                                                       │
                                              vérification ──► (boucle)

Un exemple chiffré de priorisation

Priorité « au feeling », on comble ce qui est le plus visible. Avec un score fréquence × valeur, on comble ce qui rapporte le plus. Affectez à chaque cluster une fréquence mensuelle et une valeur métier (1 = anecdotique, 5 = critique : impact contractuel, support payant, conformité). Le produit donne un ordre de traitement défendable :

Cluster	Fréquence/mois	Valeur (1-5)	Score	Rang
Politique de télétravail hors de France	180	4	720	1
Procédure de remboursement client B2B	90	5	450	2
Configuration SSO pour un nouveau client	40	5	200	3
Horaires de la cafétéria du siège	220	1	220	4

La cafétéria, malgré 220 requêtes, passe après une procédure de remboursement deux fois moins fréquente mais critique. Sans pondération par la valeur, vous auriez documenté le menu du midi avant le sujet contractuel. C'est exactement le piège du tri par volume seul.

Les métriques à suivre

• Taux de lacunes — part des requêtes sans réponse satisfaisante. La tendance doit baisser ; un palier à 5-10 % est souvent le seuil où l'effort marginal cesse de payer.
• Délai de comblement — temps entre la détection d'une lacune prioritaire et sa résolution. Un délai qui s'allonge trahit un goulet d'étranglement côté production de contenu, pas côté détection.
• Évolution du taux de réponses sourcées — l'indicateur de santé global du corpus.
• Récurrence — une lacune comblée ne devrait plus revenir ; sa réapparition signale un problème de gouvernance (le contenu créé n'est pas trouvé, ou il est contredit par une autre source).

Mesurez ces indicateurs avant de lancer le chantier, sinon vous n'aurez aucune base pour prouver le progrès. Un tableau de bord mensuel suffit largement ; la temps réel est une fausse bonne idée à ce stade.

Les pièges classiques

• Confondre lacune et problème de récupération — on crée du contenu en double alors que l'info existait, mal indexée. C'est le piège n°1, et il coûte cher : double maintenance, contradictions futures.
• Ne pas fermer la boucle — détecter sans corriger ne sert à rien. La détection n'a de valeur que reliée à une action et à un responsable nommé.
• Prioriser au feeling — sans fréquence ni valeur métier, on comble des broutilles et on laisse les vrais manques.
• Ignorer le contexte temporel — certaines lacunes sont saisonnières (lancement produit, fin d'année fiscale, ouverture des congés). Le volume seul peut tromper : une lacune qui explose en novembre puis disparaît n'a pas la même urgence qu'un manque structurel.
• Vectoriser sans nettoyer les requêtes — questions de test internes, requêtes vides, copier-coller d'erreurs : ce bruit fausse le clustering. Filtrez avant d'analyser.

Un corpus vivant

Une base de connaissances n'est jamais « terminée ». Les produits évoluent, les procédures changent, les utilisateurs posent de nouvelles questions. En reliant les requêtes réelles à un processus d'enrichissement priorisé, vous arrêtez de deviner ce dont vos utilisateurs ont besoin : ils vous le disent, requête après requête. Il ne reste qu'à écouter — et à fermer la boucle.

Commencez petit : journalisez, calibrez un seuil sur 100 requêtes annotées, clusterez le dernier mois, et traitez les trois premiers clusters par score. Vous obtiendrez plus de valeur en deux semaines de boucle disciplinée qu'en six mois d'enrichissement au jugé.

Pour aller plus loin

• Auditer sa base de connaissances avant l'IA : la méthode complète
• Support client augmenté par RAG : diviser le temps de résolution sans perdre en qualité