Runity a montré comment elle développe un assistant RAG d’entreprise pour Confluence et GitLab

Runiti a expliqué comment elle transforme un prototype interne en un assistant RAG d'entreprise pour travailler avec la documentation et le code. Le système recherche simultanément dans Confluence et GitLab, respecte les droits d'accès et fonctionne en circuit fermé sans envoyer de données d'entreprise à des services externes.

De l'idée à la mise en œuvre

Le projet est né d'une douleur très pratique. Au début de 2025, l'équipe devait comprendre simultanément l'ancien site de Rucentra et la refonte de Reg.ru : découvrir ce qui était déjà implémenté, où se trouvait la documentation actuelle et quels fragments de code étaient responsables de fonctions spécifiques.

La recherche manuelle prenait des heures : Confluence contenait plusieurs versions du même document, et dans GitLab, il fallait naviguer à travers les branches et le code hérité écrit en JavaScript obsolète. Les premiers réseaux de neurones locaux approuvés par la sécurité de l'information ont déjà aidé à accélérer le travail. Selon l'équipe, les spécifications techniques pour les développeurs ont été préparées en quelques jours au lieu d'un long balisage manuel et d'une analyse.

Après cela, l'entreprise a décidé de ne pas se limiter à des expériences isolées et a construit un produit séparé qui pourrait être intégré au flux de travail quotidien des développeurs et des architectes. Le prototype, qui a commencé comme une initiative personnelle, est devenu par la suite une partie du Centre d'Intelligence Hybride de Runiti — une division interne axée sur les pilotes d'IA et les scénarios appliqués avec des résultats mesurables.

Accès et sécurité

La question principale de l'équipe de sécurité était prévisible : qui exactement verrait les documents d'entreprise via un tel assistant ? L'équipe a résolu cela non pas avec une politique séparée au-dessus du modèle, mais au niveau de l'architecture. Le bot ne stocke pas une matrice de permissions en interne.

Les utilisateurs eux-mêmes ajoutent leurs jetons personnels Confluence et GitLab, après quoi le système vérifie l'accès à chaque document trouvé via l'API. S'il n'y a pas d'accès, ce fragment n'entre simplement pas dans le contexte du modèle. Essentiellement, la décision concernant l'accès est prise non par l'LLM, mais par le code.

Cela réduit le risque de fuite de données et maintient les données d'entreprise au sein de leur propre circuit fermé. Le compromis ici en est un : les vérifications d'accès synchrones ralentissent la réponse. Mais l'équipe affirme que même sous cette forme, une tâche qui prenait auparavant plusieurs heures tient maintenant en cinq à sept minutes.

Après des raffinements supplémentaires, la journalisation et les corrections d'interface, le projet a reçu l'approbation de la sécurité et a été déployé.

"Si un processus peut être décrit comme une séquence d'actions — il

peut être automatisé."

Stack et scénarios

En interne, le système fonctionne selon un schéma RAG classique : la requête est convertie en un embedding, puis Qdrant sélectionne les documents sémantiquement similaires de Confluence et GitLab, après quoi la couche de sécurité filtre tout ce qui n'est pas nécessaire, et le modèle génère une réponse avec des liens vers des sources spécifiques. Cette approche a été choisie à la place du fine-tuning : l'équipe valorise le contexte actuel au moment de la requête plus que la réentraînement du modèle sur les données d'entreprise. La pile utilise Python, Temporal, Qdrant, PostgreSQL, Next.

js, LangGraph et des modèles Qwen déployés localement, tandis que les données dans la base de données vectorielle sont actuellement mises à jour via des reconstructions nocturnes. Au lieu d'un assistant universel, Runiti a créé quatre modes spécialisés. Cette approche ne provenait pas d'une architecture abstraite, mais des demandes de différents rôles au sein de l'entreprise : les développeurs ont besoin d'un assistant de code, les architectes ont besoin d'une entrée rapide dans le paysage actuel, et les gestionnaires ont besoin d'un moyen de collecter automatiquement un radar technique de la pile et des dépendances dans les référentiels.

Cela simplifie également le développement du produit : les scénarios individuels sont plus faciles à tester, mesurer et affiner sans essayer de résoudre toutes les tâches avec un seul prompt.

• un chatbot général pour les questions sur les documents internes et l'intégration rapide du projet;
• un agent de radar technique qui parcourt les référentiels et collecte une vue des langages et des bibliothèques;
• un agent pour la planification architecturale qui aide à comprendre le paysage actuel avant de lancer un nouveau projet;
• un partenaire de programmation qui connaît la base de code interne et les exigences de l'équipe.

Le coût d'une telle solution est loin d'être un "jouet pour expériences." Pour un mode d'entreprise avec plusieurs utilisateurs, l'équipe estime le besoin d'environ quatre GPU de niveau A100 avec 24 Go de mémoire, ce qui coûte 160–200 mille roubles par mois uniquement en calcul. Si vous n'avez pas vos propres GPU, le seuil d'entrée pour une petite configuration locale commence à environ 500 mille roubles, et le développement nécessite toujours un backend, un frontend, un ingénieur ML et un ingénieur de données.

Ce que cela signifie

Le cas de Runiti montre que les assistants d'IA d'entreprise se déplacent rapidement de l'idée de "simplement brancher un chatbot" à des produits internes complets avec RAG, vérification d'accès et leur propre infrastructure. En pratique, ce qui gagne, ce n'est pas la rhétorique d'IA la plus bruyante, mais une combinaison de recherche solide, d'accès sécurisé, de données actuelles et de scénarios qui économisent vraiment des heures de travail à l'équipe. Pour le marché, c'est un signal de plus : l'IA d'entreprise se transforme de plus en plus d'un pilote en un produit d'ingénierie avec des coûts clairs et des zones de responsabilité.