Comment Cerebras a construit sa base de connaissances interne

• Cerebras a construit Cerebras Knowledge, qui collecte directement Slack, les dépôts de code, les documents et les bases de données internes depuis leur emplacement existant ; trois mois après son lancement, il traite plus de 15 000 questions par jour de la part des employés, des automatisations et des agents.
• Au lieu de déplacer toutes les données dans un seul outil, le système les relie à une table d’embeddings Postgres avec un schéma commun, et sépare les couches de collecte, de requête, d’authentification/autorisation/audit/analyse afin de faciliter l’ajout de nouvelles sources de données.
• Pour la recherche Slack, les embeddings du texte brut ne suffisent pas : le système combine recherche plein texte, recherche par embeddings, fréquence inverse de document et décroissance temporelle, tout en intégrant séparément des résumés de threads et des regroupements de prises de parole individuelles importantes.
• Pour chaque requête, un LLM planifie d’abord les outils de recherche à utiliser, collecte les résultats en parallèle, puis les fusionne avec RRF et un modèle de reranking ; côté MCP, les mêmes fonctions de recherche sont exposées directement sous forme d’outils primitifs petits et stables.
• Plutôt que de rechercher systématiquement dans toute l’organisation, le périmètre de recherche par défaut est défini au niveau du projet, en regroupant canaux Slack, dépôts, espaces documentaires, etc., afin de fournir à chaque équipe des résultats plus pertinents.

---

Collecter directement là où l’information est créée

• Dans les équipes de Cerebras chargées de l’exploitation des data centers, de la conception de puces, du matériel, de l’entraînement, de l’inférence et de la plateforme cloud, des centaines de personnes rejoignent l’entreprise chaque année, ce qui fait revenir sans cesse des questions comme « où se trouve X », « qui est l’expert de Y » ou « qu’est-ce que Z ».
• L’entreprise a estimé qu’une approche consistant à consigner toutes les informations dans une plateforme unique ne fonctionnait pas bien dans le travail réel.
  • Les informations sont créées dans les outils adaptés à chaque tâche : propositions de modification de documents, threads Slack, références de code GitHub, métadonnées d’état Jira, etc.
  • Chaque plateforme a été optimisée pour son domaine grâce à de longues années de développement produit et d’analyse ; Cerebras a donc choisi de ne pas contraindre les utilisateurs à changer leurs habitudes.
• À l’étape de collecte, le système se connecte directement à chaque plateforme afin de minimiser les changements dans les pratiques de travail existantes.

Une architecture centrée sur une table commune d’embeddings

• La base de connaissances se compose de trois couches :
  • une plateforme qui collecte et stocke les données internes ;
  • une plateforme qui interroge les données stockées ;
  • une couche qui applique authentification, autorisation, audit et analyse.
• Au centre se trouve une table Postgres unique qui stocke les embeddings, résumés de texte source et métadonnées provenant de plusieurs sources.
• Les threads Slack, dépôts de code, systèmes documentaires, netlists et bases de données personnalisées utilisent la même interface de lignes d’embeddings.
• Chaque source de données définit les données, la méthode de connexion et la fréquence de collecte ; dès qu’elles sont écrites dans la table commune, elles deviennent consultables via la même interface de requête.
• L’interface de données est volontairement gardée simple afin que les développeurs de Cerebras puissent créer leurs propres connecteurs.

La recherche hybride nécessaire pour Slack

• Slack était la source de données la plus importante pour les discussions d’ingénierie récentes.
• Une simple recherche vectorielle appliquant des embeddings au texte brut ne permettait pas de retrouver toutes les informations pertinentes.
  • Des messages courts comme « oui, ça me va » et des explications détaillées sur un kernel étaient stockés avec la même granularité de message.
  • Les messages courts devançaient souvent des messages plus longs et détaillés en similarité cosinus.
  • Le sens d’un message individuel dépendait de la conversation autour de lui.
• Chaque thread Slack est recherché simultanément de quatre façons :
  • la recherche plein texte trouve les tokens exacts qui se diluent dans les embeddings, comme les chaînes d’erreur, noms de flags ou noms d’hôtes ;
  • la recherche par embeddings relie des questions et réponses formulées avec un vocabulaire différent, comme « la restauration s’arrête après le manifest » et « le checkpoint se fige sur le montage NFS » ;
  • la fréquence inverse de document (IDF) remonte les messages courts contenant des flags de configuration rares et abaisse le score des formules de réaction fréquentes ;
  • la décroissance temporelle privilégie, à pertinence égale, les threads récents plutôt que d’anciens threads susceptibles de décrire une infrastructure obsolète.
• Le système ne fait pas confiance à un score unique : il combine au moment de la requête les listes classées produites par chaque moteur de recherche.

Collecte en temps réel basée sur Socket Mode

• Un bot Slack est installé dans le workspace et reçoit tous les événements de messages via la connexion WebSocket persistante de Socket Mode.
• Les mises à jour se font en temps réel sans appels répétés à la Web API, ce qui réduit la consommation des limites de débit.
• Lorsqu’un événement arrive, le système répond immédiatement, déduplique à l’aide d’un ID d’événement stable, puis le marque pour traitement par un consommateur de collecte.
• Les nouveaux messages ne sont pas stockés isolément : le thread complet auquel ils appartiennent est récupéré à nouveau.
  • Le message parent et toutes les réponses sont stockés dans une seule ligne.
  • Lorsqu’une réponse est ajoutée à un thread existant, le parent, les réponses sœurs, la liste des participants et l’heure de dernière activité sont tous mis à jour.
• Chaque canal Slack dispose d’une source de données distincte, ce qui permet de configurer une fréquence de collecte plus courte pour les canaux qui changent souvent, comme ceux de gestion d’incidents.

Distillation et structuration des threads

• Le texte Slack brut peut être recherché par mots-clés dès son stockage grâce à un index plein texte GIN dans Postgres.
• Pour la recherche vectorielle, un LLM extrait les éléments suivants à partir du thread complet :
  • une question en une ligne qu’un ingénieur serait susceptible de chercher ;
  • un court résumé ;
  • la méthode de résolution ;
  • les systèmes concernés et références de code.
• Les éléments extraits sont intégrés sous forme d’embeddings et stockés dans la table commune ; la conversation originale elle-même n’est pas directement transformée en embeddings.
• Les expériences ont montré qu’une normalisation des threads dans un format cohérent améliorait fortement la précision, et que les métadonnées supplémentaires fournissaient aussi des signaux plus utiles pour la recherche sémantique.

Préserver les messages individuels des longs threads avec le bursting

• Les seuls résumés au niveau du thread laissaient subsister un problème : des messages importants pouvaient être omis dans les longues conversations.
• Les messages consécutifs d’un même auteur sont combinés en regroupements de prises de parole consécutives (bursts), puis précédés du sujet du thread comme contexte et intégrés séparément sous forme d’embeddings.
• Les réponses issues de conversations secondaires qui ne figurent pas dans le résumé du thread deviennent ainsi recherchables indépendamment.
• Pour éviter que des prises de parole à faible signal n’entrent dans la base, le système calcule un signal pondéré et ne stocke que les regroupements dépassant un seuil.
  • Ils contiennent des tokens rares dont l’IDF est supérieur ou égal à 4,0 dans l’ensemble du corpus.
  • La longueur combinée des prises de parole est d’au moins 200 caractères.
  • Au moins un message contient un emoji de réaction, ce qui lui donne un poids social.
• Les regroupements qui remplissent ces conditions sont stockés dans la table commune d’embeddings avec l’enregistrement au niveau du thread.

Embeddings incrémentaux pour de grands dépôts de code

• Avec la diffusion d’outils en ligne de commande comme Claude Code, Cerebras pensait que grep pourrait suffire pour le code, mais après avoir examiné les retours d’acteurs du secteur et les résultats de recherche sémantique de Cursor sur de grandes bases de code, l’entreprise a adopté les embeddings de code.
• Certains dépôts internes dépassent 40 Go, et le coût d’un ré-embedding complet et continu constituait un défi majeur.
• Après plusieurs expériences, Cerebras a choisi CocoIndex, un framework open source d’embeddings documentaires spécialisé dans la vectorisation de bases de code.
• Le code est découpé en appliquant des frontières par expressions régulières propres à chaque langage, des grandes unités vers les plus petites.
  • Les frontières de haut niveau, comme les classes, sont utilisées d’abord.
  • Si un chunk est trop grand, le découpage descend vers les méthodes et des blocs plus petits.
  • Un même fichier peut produire plusieurs embeddings à des granularités différentes, par exemple au niveau fichier et au niveau fonction.
• CocoIndex conserve dans Postgres des métadonnées de synchronisation, afin de ne réintégrer et exporter à chaque commit que les chunks de code modifiés.
• Une fois le nombre de dépôts accru, l’onboarding a basculé vers des fichiers de configuration que les équipes peuvent soumettre elles-mêmes, avec prise en charge de listes d’autorisation et de blocage par chemin de fichier.

Connexion de sources de données personnalisées

• Certaines équipes voulaient utiliser la même interface de recherche sans déplacer les informations de leurs bases de données existantes vers Slack ou le système documentaire.
• Les sources personnalisées sont traitées comme des scripts de plugin.
  • L’équipe soumet via pull request un petit module Python qui lit son système existant et exporte des lignes au format de la table commune d’embeddings.
  • La configuration de source de données correspondante est ajoutée en même temps.
• Tant que les données sont écrites dans la base partagée avec le schéma commun, elles sont recherchées avec Slack, le code et les documents ; le reste du système n’a pas besoin de traitement spécifique.

Planification des requêtes et exécution parallèle des outils

• Pour chaque question, un LLM exécute d’abord une courte étape de planification afin de décider quels outils et quelles sources de données utiliser.
• Les principaux outils sont les suivants :
  • subsystem_index : résumés LLM par fichier ;
  • search : recherche vectorielle qui unifie Slack, wiki, code et autres index, avec fusion et reranking internes ;
  • search_slack : recherche directe dans Slack ;
  • search_code : ripgrep sur les dépôts source ;
  • recent_prs : pull requests récentes liées à la question ;
  • who_knows : recherche de personnes ayant réellement démontré une expertise sur un sujet donné.
• Le planificateur utilise une liste de projets, les sources de données par projet et des descriptions compressées indiquant les types de questions auxquelles chaque source répond bien.
• L’exécuteur appelle les outils sélectionnés en parallèle, normalise les résultats dans un format commun de preuves, puis les transmet au LLM de synthèse final.

RRF et reranking

• Des documents qui partagent seulement le vocabulaire de la requête, mais répondent en réalité à une autre question, peuvent apparaître en tête ; une étape de reranking séparée est donc ajoutée.
• Les listes classées provenant de différents moteurs de recherche sont combinées par Reciprocal Rank Fusion (RRF).
  • Pour chaque liste où apparaît un document, on ajoute weight / (60 + rank).
  • Le poids par défaut est 1,0 et la constante de lissage est 60.
  • Un document qui apparaît régulièrement en bonne position dans plusieurs moteurs peut devancer un document classé premier dans un seul moteur.
• Les chunks dupliqués sont fusionnés au niveau de la source, et le nombre de résultats par fichier est limité afin de produire un top 20 de candidats diversifiés.
• Un petit modèle de reranking attribue une note de 0 à 10 à chaque document par rapport à la question initiale et conserve les 10 meilleurs.
• Le résultat final réajoute le contexte environnant.
  • Lorsqu’une section de wiki correspond, les deux sections adjacentes sont également récupérées afin que le titre, les prérequis et les avertissements ne disparaissent pas à cause du découpage en chunks.
• Les résultats de recherche sont renvoyés sous forme d’un ensemble de preuves ayant fait l’objet d’une fusion entre plusieurs moteurs, d’une déduplication au niveau de la source, d’un reranking fondé sur la question et d’un élargissement au contexte voisin.

Répartition des rôles entre MCP et l’interface web

• Dans MCP, au lieu d’un endpoint unique « répondre à une question », des fonctions de recherche de base comme search_slack, search_code, search et who_knows sont exposées comme outils distincts.
• Pour que les outils puissent être appelés rapidement et à faible coût, les dépendances au LLM sont supprimées autant que possible.
  • Les entrées et sorties restent étroites, structurées et stables.
  • Des pipelines unitaires comme la recherche vectorielle, la recherche lexicale ou ripgrep appliquent des règles de score légères et renvoient des lignes de preuves brutes.
• Les agents compatibles MCP, notamment Claude Code, deviennent le moteur d’orchestration qui décide quels outils appeler, dans quel ordre et comment combiner les résultats.
• Dans l’interface web, les mêmes outils sont reliés dans un pipeline complet de requête.
  • Le planificateur examine la question et le projet actif pour choisir les outils de recherche à appeler.
  • L’exécuteur traite les appels en parallèle et les convertit en un schéma commun de preuves incluant score, fraîcheur et indices de source.
  • Le synthétiseur génère une réponse à partir de la question et de l’ensemble de preuves, avec citations, avertissements et intégration entre sources.
• L’utilisateur se contente de poser une question et de recevoir une réponse, mais en interne le flux planificateur → exécuteur → synthétiseur est exécuté.

Périmètre de recherche au niveau du projet

• À mesure que le corpus grandissait, la pertinence d’une recherche systématique dans toute l’organisation chutait fortement.
  • L’équipe compilateur ne voulait pas voir apparaître des procédures d’exploitation d’infrastructure dans ses résultats, et l’inverse était tout aussi vrai.
• Les projets ont été introduits comme espace de travail par défaut dans lequel les requêtes sont exécutées.
  • Ils regroupent des canaux Slack, dépôts de code, bases de données internes et espaces documentaires par équipe ou par sujet.
  • Un canal d’incident partagé ou un dépôt de plateforme central peut être référencé par plusieurs projets, sans dupliquer les données.
• Lors de l’onboarding, les utilisateurs choisissent ou créent un projet par défaut adapté à leur travail, comme infrastructure d’entraînement ML, Compiler ou Data Center Operations.
• Le projet par défaut est enregistré dans le profil utilisateur, et le périmètre de toutes les requêtes est automatiquement limité, ce qui permet aux nouveaux ingénieurs de commencer à chercher sans devoir d’abord connaître les bons canaux et dépôts.

Une base de connaissances qui préserve les outils existants

• Le principe de fonctionnement de la base de connaissances est de ne pas déplacer l’information dans un système unique et rigide, mais de la collecter là où elle est déjà créée.
• En combinant plusieurs modes de recherche, elle retrouve rapidement les preuves tout en acceptant la diversité réelle des données d’entreprise, et construit une architecture capable de rester utile à mesure que l’organisation grandit.