Wie Cerebras seine interne Wissensdatenbank aufgebaut hat

• Cerebras entwickelte und veröffentlichte Cerebras Knowledge, das Slack/Code-Repositories/Dokumente/interne Datenbanken direkt an ihrem bestehenden Speicherort erfasst, und verarbeitete bereits drei Monate nach dem Launch täglich über 15.000 Fragen von Mitarbeitenden/Automatisierungen/Agenten
• Statt alle Daten in ein einziges Tool zu verschieben, werden sie mit einer Postgres-Embedding-Tabelle mit gemeinsamem Schema verbunden; Erfassungs-/Abfrage-/Authentifizierungs-, Berechtigungs-, Audit- und Analyseschichten sind getrennt, damit sich neue Datenquellen leicht hinzufügen lassen
• Für die Slack-Suche reichen Embeddings des Originaltexts allein nicht aus; daher werden Volltextsuche/Embedding-Suche/inverse Dokumentfrequenz/Zeitabklingung gemeinsam genutzt, und Thread-Zusammenfassungen sowie Bündel wichtiger Einzeläußerungen separat eingebettet
• Für jede Anfrage plant das LLM zunächst die zu nutzenden Suchwerkzeuge, sammelt die Ergebnisse dann parallel und integriert sie mit RRF und einem Reranking-Modell; in MCP wird dieselbe Suchfunktionalität direkt als kleine und stabile primitive Werkzeuge bereitgestellt
• Statt standardmäßig die gesamte Organisation zu durchsuchen, wird ein suchbarer Bereich pro Projekt als Standard festgelegt, der Slack-Kanäle/Repositories/Dokumentationsräume bündelt, um Teams relevantere Ergebnisse zu liefern

---

Direkt dort erfassen, wo Informationen entstehen

• Bei den Teams für Rechenzentrumsbetrieb/Chipdesign/Hardware/Training/Inferenz/Cloud-Plattform von Cerebras stoßen jedes Jahr Hunderte neue Mitarbeitende dazu, wodurch Fragen wie „Wo ist X?“, „Wer ist Experte für Y?“ oder „Was ist Z?“ immer wieder auftauchen
• Man kam zu dem Schluss, dass es in der Praxis nicht gut funktioniert, alle Informationen in einer einzigen Plattform zu dokumentieren
  • Informationen entstehen in den jeweils passenden Werkzeugen für die jeweilige Aufgabe, etwa bei vorgeschlagenen Änderungen in Dokumenten, Slack-Threads, Code-Referenzen auf GitHub oder Status-Metadaten in Jira
  • Jede Plattform ist durch langjährige Produktentwicklung und Analyse für ein bestimmtes Einsatzfeld optimiert, daher wollte man die Nutzung nicht künstlich umstellen
• In der Erfassungsphase wird direkt an jede Plattform angebunden, um Änderungen am bestehenden Arbeitsverhalten zu minimieren

Architektur rund um eine gemeinsame Embedding-Tabelle

• Die Wissensdatenbank besteht aus drei Schichten
  • einer Plattform zum Erfassen und Speichern interner Daten
  • einer Plattform zum Abfragen der gespeicherten Daten
  • einer Schicht für Authentifizierung/Autorisierung/Auditing/Analysen
• Im Zentrum steht eine einzelne Postgres-Tabelle, die Embeddings/Originalzusammenfassungen/Metadaten aus verschiedenen Quellen speichert
• Slack-Threads, Code-Repositories, Dokumentationssysteme, Netlists und benutzerdefinierte Datenbanken verwenden dieselbe Schnittstelle für Embedding-Zeilen
• Jede Datenquelle definiert, was die Daten sind, wie sie verbunden wird und in welchem Rhythmus sie erfasst wird; sobald sie in die gemeinsame Tabelle geschrieben wurden, lassen sie sich über dieselbe Abfrageschnittstelle durchsuchen
• Die Datenschnittstelle wurde bewusst einfach gehalten, damit Cerebras-Entwickler eigene Connectoren bauen können

Die notwendige hybride Suche für Slack

• Slack war die wichtigste Datenquelle, weil dort die neuesten Engineering-Diskussionen stattfinden
• Vektorsuche nur mit einfachen Embeddings des Originaltexts reichte nicht aus, um alle relevanten Informationen zu finden
  • Kurze Nachrichten wie „Ja, gut“ und detaillierte Kernel-Erklärungen werden auf derselben Nachrichtenebene gespeichert
  • Kurze Nachrichten landen bei der Kosinus-Ähnlichkeit oft vor längeren und detaillierteren Nachrichten
  • Die Bedeutung einzelner Nachrichten hängt vom umgebenden Gespräch ab
• Jeder Slack-Thread wird gleichzeitig auf vier Arten durchsucht
  • Volltextsuche findet exakte Tokens wie Fehlerstrings/Flag-Namen/Hostnamen, die in Embeddings verwischt werden
  • Embedding-Suche verbindet Fragen und Antworten, die mit unterschiedlichem Vokabular formuliert sind, etwa „Wiederherstellung stoppt nach dem Manifest“ und „Checkpoint hängt beim NFS-Mount“
  • Inverse Dokumentfrequenz (IDF) hebt kurze Nachrichten mit seltenen Konfigurations-Flags im Ranking an und senkt die Punktzahl häufiger reaktiver Phrasen
  • Zeitabklingung priorisiert bei gleicher Relevanz neuere Threads gegenüber älteren Threads, die veraltete Infrastruktur beschreiben könnten
• Statt nur einem Score zu vertrauen, werden die von jedem Retriever erzeugten Ranglisten zur Anfragezeit zusammengeführt

Echtzeiterfassung auf Basis von Socket Mode

• Ein Slack-Bot wird im Workspace installiert und empfängt über eine dauerhafte WebSocket-Verbindung mit Socket Mode alle Message-Events
• So wird in Echtzeit aktualisiert, ohne die Web API wiederholt aufzurufen, und der Verbrauch von Rate Limits sinkt
• Wenn ein Event ankommt, wird sofort geantwortet, es wird über eine stabile Event-ID dedupliziert und dann zur Verarbeitung durch den Erfassungs-Consumer markiert
• Neue Nachrichten werden nicht isoliert gespeichert; stattdessen wird der vollständige Thread, zu dem die Nachricht gehört, erneut abgerufen
  • Elterneintrag und alle Antworten werden als eine Zeile gespeichert
  • Wird einem bestehenden Thread eine Antwort hinzugefügt, werden Elterneintrag/Geschwisterantworten/Teilnehmerliste/Zeitpunkt der letzten Aktivität vollständig aktualisiert
• Für jeden Slack-Kanal gibt es eine eigene Datenquelle, sodass sich für häufig veränderte Kanäle wie Incident-Response-Kanäle kürzere Erfassungsintervalle festlegen lassen

Destillation und Strukturierung von Threads

• Der originale Slack-Text ist direkt nach dem Speichern per Keyword-Suche über einen Postgres-GIN-Volltextindex auffindbar
• Für Daten der Vektorsuche extrahiert das LLM aus dem gesamten Thread folgende Elemente
  • eine einzeilige Frage, nach der ein Engineer tatsächlich suchen würde
  • eine kurze Zusammenfassung
  • die Lösung
  • relevante Systeme und Code-Referenzen
• Diese extrahierten Elemente werden eingebettet und in der gemeinsamen Tabelle gespeichert; die ursprünglichen Gesprächstexte selbst werden nicht direkt eingebettet
• In Experimenten stieg die Genauigkeit deutlich, wenn Threads in ein konsistentes Format normalisiert wurden; zusätzliche Metadaten lieferten zudem nützlichere Signale für die semantische Suche

Bursting: Einzelne Nachrichten in langen Threads erhalten

• Selbst mit Zusammenfassungen auf Thread-Ebene blieb das Problem bestehen, dass wichtige Nachrichten in langen Gesprächen verloren gehen
• Mehrere aufeinanderfolgende Nachrichten desselben Autors werden zu einem zusammenhängenden Äußerungsbündel (burst) kombiniert, dem das Thread-Thema als Kontext vorangestellt und das separat eingebettet wird
• Dadurch werden auch Antworten aus Nebensträngen auffindbar, die nicht in der Thread-Zusammenfassung enthalten sind
• Damit Äußerungen mit schwachem Signal nicht in die Datenbank gelangen, wird ein gewichtetes Signal berechnet und nur Bündel, die einen Schwellenwert überschreiten, werden gespeichert
  • Sie enthalten seltene Tokens mit einer IDF von mindestens 4,0 über den Gesamtkorpus
  • Die kombinierte Äußerung ist mindestens 200 Zeichen lang
  • Mindestens eine Nachricht enthält Reaktions-Emojis und erhält dadurch soziales Gewicht
• Bündel, die diese Bedingungen erfüllen, werden zusammen mit Datensätzen auf Thread-Ebene in der gemeinsamen Embedding-Tabelle gespeichert

Inkrementelle Embeddings für große Code-Repositories

• Mit der Verbreitung von Kommandozeilenwerkzeugen wie Claude Code hielt man grep zunächst für ausreichend für Code, führte aber nach Gesprächen mit Branchenleuten und nach Prüfung der Ergebnisse semantischer Suche in großen Codebasen bei Cursor doch Code-Embeddings ein
• Einige interne Repositories überschritten 40 GB, sodass die Kosten für ständiges vollständiges Re-Embedding eine zentrale Herausforderung waren
• Nach mehreren Experimenten fiel die Wahl auf CocoIndex, ein Open-Source-Framework für Dokument-Embeddings, das auf die Vektorisierung von Codebasen spezialisiert ist
• Der Code wird mithilfe sprachspezifischer Regex-Grenzen vom Großen zum Kleinen aufgeteilt
  • Zuerst werden obere Grenzen wie Klassen verwendet
  • Ist ein Chunk zu groß, wird auf Methoden und kleinere Blockgrenzen heruntergegangen
  • So können innerhalb einer Datei mehrere Embeddings mit unterschiedlicher Granularität entstehen, etwa auf Datei- oder Funktionsebene
• CocoIndex hält Synchronisierungsmetadaten in Postgres vor und bettet pro Commit nur geänderte Code-Chunks neu ein und exportiert sie
• Mit wachsender Zahl von Repositories wurde das Onboarding auf Konfigurationsdateien umgestellt, die Teams selbst einreichen können, einschließlich Allowlist/Blocklist nach Dateipfad

Anbindung benutzerdefinierter Datenquellen

• Einige Teams wollten Informationen aus bestehenden Datenbanken über dieselbe Suchschnittstelle nutzen, ohne sie nach Slack oder in Dokumentationssysteme zu verschieben
• Benutzerdefinierte Quellen werden als Plugin-Skripte behandelt
  • Teams reichen per Pull Request ein kleines Python-Modul ein, das ihr bestehendes System liest und Zeilen im Format der gemeinsamen Embedding-Tabelle exportiert
  • Dazu wird die passende Konfiguration der Datenquelle ergänzt
• Sobald nur in die gemeinsame Datenbank mit dem gemeinsamen Schema geschrieben wird, wird die Quelle zusammen mit Slack/Code/Dokumenten durchsucht; für den Rest des Systems ist keine Sonderbehandlung nötig

Anfrageplanung und parallele Werkzeugausführung

• Für jede Frage führt das LLM zunächst einen kurzen Planungsschritt aus, um die zu verwendenden Werkzeuge und Datenquellen zu bestimmen
• Die wichtigsten Werkzeuge sind
  • subsystem_index: LLM-Zusammenfassungen pro Datei
  • search: Vektorsuche, die Slack/Wiki/Code/andere Indizes integriert und intern zusammenführt sowie rerankt
  • search_slack: direkte Slack-Suche
  • search_code: ripgrep über Quell-Repositories
  • recent_prs: aktuelle Pull Requests mit Bezug zur Frage
  • who_knows: Suche nach Personen, die tatsächliche Expertise zu einem bestimmten Thema gezeigt haben
• Der Planer nutzt komprimierte Beschreibungen von Projektlisten/Datenquellen je Projekt/Fragetypen, die jede Quelle gut beantworten kann
• Der Executor ruft die ausgewählten Werkzeuge parallel auf, normalisiert die Ergebnisse in ein gemeinsames Evidenzformat und übergibt sie an das abschließende Synthese-LLM

RRF und Reranking

• Dokumente, die nur die Anfrage und das Vokabular teilen, aber tatsächlich andere Fragen beantworten, können oben erscheinen; deshalb gibt es einen separaten Reranking-Schritt
• Die Ranglisten verschiedener Retriever werden mit Reciprocal Rank Fusion (RRF) zusammengeführt
  • Für jede Liste, in der ein Dokument erscheint, wird weight / (60 + rank) addiert
  • Das Standardgewicht ist 1,0, die Glättungskonstante 60
  • Dokumente, die bei mehreren Retrievern konstant weit oben erscheinen, können vor Dokumenten landen, die nur bei einem einzelnen Retriever auf Rang 1 stehen
• Doppelte Chunks werden auf Ursprungseinheiten zusammengeführt, und die Anzahl der Ergebnisse pro Datei wird begrenzt, um vielfältige Top-20-Kandidaten zu erzeugen
• Ein kleines Reranking-Modell vergibt für jedes Dokument anhand der ursprünglichen Frage 0 bis 10 Punkte und behält die Top 10
• Im Endergebnis wird der umgebende Kontext wieder ergänzt
  • Wenn ein Wiki-Abschnitt passt, werden die zwei benachbarten Abschnitte mitgeladen, damit Titel/Voraussetzungen/Hinweise nicht durch Chunking verloren gehen
• Die Suchergebnisse werden als Evidenzbündel zurückgegeben, das eine Zusammenführung mehrerer Retriever, Deduplizierung auf Ursprungsebene, fragebasiertes Reranking und Erweiterung um umgebenden Kontext durchlaufen hat

Rollenverteilung zwischen MCP und Web-UI

• In MCP wird statt eines einzigen „Frage beantworten“-Endpunkts jeweils eine primitive Suchfunktion wie search_slack, search_code, search oder who_knows als eigenes Werkzeug bereitgestellt
• Um Werkzeuge schnell und günstig aufrufen zu können, wird die Abhängigkeit von LLMs so weit wie möglich entfernt
  • Ein- und Ausgabebereich bleiben eng, strukturiert und stabil
  • Auf einzelne Pipelines wie Vektorsuche, lexikalische Suche oder ripgrep werden leichte Scoring-Regeln angewendet, um rohe Evidenzzeilen zurückzugeben
• MCP-kompatible Agenten wie Claude Code werden damit zur Orchestrierungs-Engine, die entscheidet, welche Werkzeuge in welcher Reihenfolge aufgerufen und wie die Ergebnisse kombiniert werden
• In der Web-UI werden dieselben Werkzeuge zu einer vollständigen Anfrage-Pipeline verbunden
  • Der Planer betrachtet die Frage und das aktive Projekt und wählt die aufzurufenden Suchwerkzeuge aus
  • Der Executor verarbeitet die Aufrufe parallel und wandelt sie in ein gemeinsames Evidenzschema mit Hinweisen zu Score/Aktualität/Quelle um
  • Der Synthesizer erzeugt aus Frage und Evidenzbündel eine Antwort mit Zitaten/Hinweisen/Integration über mehrere Quellen hinweg
• Für Nutzende sieht es so aus, als würden sie einfach nur fragen und eine Antwort erhalten, intern läuft jedoch der Ablauf Planer → Executor → Synthesizer

Suchbereich pro Projekt

• Als der Korpus größer wurde, sank die Relevanz stark, wenn immer die gesamte Organisation durchsucht wurde
  • Das Compiler-Team wollte keine Betriebsverfahren der Infrastruktur in den Suchergebnissen sehen, und umgekehrt galt dasselbe
• Projekte wurden als Standard-Arbeitsbereich eingeführt, in dem Anfragen ausgeführt werden
  • Bestimmte Slack-Kanäle/Code-Repositories/interne Datenbanken/Dokumentationsräume werden nach Team oder Aufgabe gebündelt
  • Gemeinsame Incident-Kanäle oder zentrale Plattform-Repositories können von mehreren Projekten referenziert werden, ohne Daten zu duplizieren
• Im Onboarding wählen oder erstellen Mitarbeitende Standardprojekte passend zu ihrer Arbeit, etwa ML-Trainingsinfrastruktur/Compiler/Data Center Operations
• Das Standardprojekt wird im Nutzerprofil gespeichert und begrenzt automatisch alle Anfragen, sodass auch neue Engineers mit der Suche beginnen können, ohne zuerst die relevanten Kanäle und Repositories kennenlernen zu müssen

Eine Wissensdatenbank, die bestehende Werkzeuge beibehält

• Das Grundprinzip der Wissensdatenbank besteht darin, Informationen nicht in ein einziges starres System zu verlagern, sondern sie dort zu erfassen, wo sie ohnehin entstehen
• Durch die Kombination mehrerer Suchverfahren findet sie Evidenz schnell, akzeptiert zugleich die Vielfalt realer Unternehmensdaten und bleibt auch bei weiterem Organisationswachstum nützlich