Krok montre comment il a construit un assistant RAG interne pour les données d'entreprise

Croc a expliqué comment il a construit un assistant RAG interne pour travailler avec les connaissances d'entreprise en boucle fermée. Au lieu d'un 'chat pour le chat', l'entreprise a créé un outil qui réduit le temps consacré à la recherche de fragments pertinents dans les documents, wikis et portails internes.

Pourquoi ils ont choisi RAG

L'équipe a commencé par un problème simple : bien que la recherche intégrée existe dans pratiquement tous les grands systèmes d'entreprise, cela ne facilite pas la vie des employés. Les informations sont dispersées dans plusieurs référentiels, chacun avec ses propres règles, structure et logique de retour de résultats. En conséquence, les gens se souviennent du sens d'un document mais oublient la formulation exacte, le nom du fichier ou l'emplacement. La recherche standard repose sur la correspondance des mots plutôt que sur le contexte, et c'est là qu'elle commence à échouer.

Ils ont également testé une approche directe avec GPT et le téléchargement de documents, mais elle ne fonctionnait pas pour les grands ensembles de données. Plusieurs limitations sont entrées en jeu : la taille de la fenêtre de contexte, l'instabilité des réponses et le risque d'exposer des documents sensibles en dehors de l'infrastructure de l'entreprise. C'est pourquoi Croc a choisi l'approche RAG : d'abord trouver les fragments pertinents de sources internes, puis les transmettre à un modèle de langage pour assembler la réponse.

« Nous avions besoin d'un outil d'IA utile, pas d'une IA à la mode—un assistant d'entreprise géré. »

RAG a été choisi dans ce projet pour quatre raisons pratiques :

• Les documents restent dans l'infrastructure de l'entreprise ;
• Seul le contexte nécessaire est transmis au modèle, pas l'ensemble des données ;
• L'indexation et la récupération peuvent être contrôlées séparément ;
• Le risque d'hallucinations est plus faible car la réponse est basée sur des sources réelles.

Comment le système a été organisé

La solution est basée sur deux circuits séparés. Le premier gère la création d'assistants : les utilisateurs peuvent ajouter des fichiers, des liens vers des portails ou des espaces de base de connaissances via le messager d'entreprise ou une interface web pilote. Le système de gestion des assistants vérifie ensuite les droits d'accès, exécute les analyseurs nécessaires, prépare les données et les envoie uniquement alors au noyau RAG pour l'indexation. Une fois l'index prêt, l'employé reçoit une notification et peut commencer un dialogue.

Le deuxième circuit est le circuit de dialogue. Les demandes des utilisateurs passent par le bus LLM d'entreprise et le moteur RAG présélectionne le contexte pertinent. Les droits d'accès sont vérifiés non seulement une fois lors du chargement, mais à chaque requête d'assistant. En raison de la complexité des ACL dans les différents systèmes, l'équipe a décidé de s'éloigner des assistants partagés dans certains scénarios et a basculé vers les assistants personnels. C'est moins pratique, mais cela réduit le risque qu'un employé ne voie des données auxquelles il ne devrait pas avoir accès.

Ils ont dû construire des connecteurs et un prétraitement pour pratiquement chaque type de source de données. Le portail d'entreprise, la base de connaissances, les fichiers personnels et les pages wiki étaient trop différents pour passer directement à un noyau RAG unique prêt à l'emploi. Ils ont donc extrait le nettoyage, la normalisation et la préparation des données dans des services séparés. Pour le point d'entrée principal, ils ont choisi un messager interne basé sur Express : Telegram semblait initialement pratique, mais utiliser un service externe pour les informations sensibles a été immédiatement écarté.

Où les problèmes sont apparus

Les défis les plus difficiles ne venaient pas de l'interface, mais des données et des processus. Les wikis avec un balisage complexe nécessitaient un nettoyage manuel extensif. Les tables et les données numériques produisaient des réponses instables. Les PDF avec des scans et des graphiques cassaient l'analyse de base. Les structures visuelles comme les organigrammes étaient moins bien comprises par le modèle que le texte et pouvaient confondre les relations entre les départements et les gestionnaires.

De plus, les utilisateurs s'attendaient à ce que RAG fournisse une recherche complète sur toutes les correspondances, bien que l'approche elle-même tende à classer le contexte le plus probable plutôt que de garantir une liste complète des occurrences. La collaboration avec les fournisseurs s'est avérée tout aussi difficile. Croc a testé plusieurs plateformes sur ses propres ensembles de documents et des requêtes typiques, puis a passé près d'un an à affiner la solution avec son fournisseur. Les mises à jour sont devenues un problème : elles pouvaient changer drastiquement la qualité de la réponse : une version a réduit la métrique de 85 % à 70 %.

En raison de la relation opaque entre RAG et le LLM intégré, l'équipe a demandé une interface séparée entre eux pour qu'ils puissent indépendamment choisir le modèle et gérer le traitement ultérieur du contexte. Pour le contrôle de qualité, ils ont introduit des benchmarks, des questions de référence, des vérifications régulières et même un juge LLM séparé qui compare les réponses réelles aux réponses attendues.

Ce que cela signifie

Le cas de Croc illustre bien que l'IA d'entreprise aujourd'hui n'est pas tant une question de choix de modèle que d'ingénierie autour des données, de l'accès et des tests. RAG seul ne résout pas le problème s'il n'y a pas de connecteurs, d'isolation des collections, de contrôle ACL et de métriques de qualité claires. Mais quand tout cela est rassemblé dans un système, un assistant interne peut réellement éliminer des heures de recherche routinière et rendre le travail avec les connaissances d'entreprise considérablement plus rapide.