Autoren: @hi_im_isaac_, @learnwdaniel, @gaozenghao
Hinweis: Die interaktive Version des vollständigen technischen Blogbeitrags ist verfügbar unter: https://www.cerebras.ai/blog/how-we-built-our-knowledge-base
Mitarbeiter stellen unserer internen Wissensdatenbank jeden Tag mehr als 15.000 Fragen. Seit dem Start vor drei Monaten ist sie zu einem der am weitesten verbreiteten internen Tools im Unternehmen geworden. Genutzt von Menschen, Automatisierungen und Agenten.
Bei Cerebras arbeiten unsere Teams in den Bereichen Rechenzentrumsbetrieb, Chipdesign, Hardware, Training, Inferenz, Cloud-Plattform und mehr. Da jedes Jahr Hunderte neuer Mitarbeiter dazukommen, waren unsere Kommunikationskanäle mit denselben Fragen überfüllt:
- „Wo finde ich X?“
- „Wer ist der Experte für Y?“
- „Was ist Z?“
Wir haben Cerebras Knowledge entwickelt, um Menschen und Systeme mit nützlichen Informationen zu verbinden.
Daten dort abholen, wo sie leben
Informationen innerhalb einer Organisation zu finden, ist schwierig. Die Daten sind über verschiedene Tools verstreut, und etwa jedes Quartal schlägt jemand dieselbe brillante Lösung vor: Lasst uns alles in einer Plattform aufzeichnen, damit alle Informationen an einem Ort sind. Der Traum von einer einzigen Quelle der Wahrheit funktioniert in der Praxis jedoch selten.
Informationen werden dort generiert, wo es praktisch und ergonomisch ist: Änderungsvorschläge in einem Dokument, Threads in Slack, Code-Referenzen in GitHub und Status-Metadaten in Jira. Diese Plattformen sind maßgeschneidert für ihre spezifischen Domänen, optimiert durch jahrelange Produktentwicklung und Analytik. Einen Pull-Request in Google Docs zu diskutieren, wäre eine schreckliche Erfahrung.
Also haben wir uns daran gemacht, ein System zu entwerfen, das nur minimale Änderungen am bestehenden Verhalten erfordert. Auf der Seite der Datenerfassung bedeutete dies, Daten direkt aus jeder Plattform zu extrahieren.
Anatomie einer Wissensdatenbank
Unsere Wissensdatenbank bietet drei Dinge:
- Eine Plattform zum Sammeln und Speichern interner Daten.
- Eine Plattform zum Abfragen dieser Daten.
- Eine Schicht, die Authentifizierung und Autorisierung mit Überwachung und Analyse erzwingt.
Im Kern befindet sich eine einzelne Postgres-Tabelle, die Embeddings, rohe Zusammenfassungen und Metadaten aus vielen Quellen enthält. Das System nimmt kontinuierlich Daten aus dem gesamten Unternehmen auf und unterhält einen abfragebereiten Datenspeicher.
Wir wollten eine Datenschnittstelle, die einfach ist, aber mit den meisten Datenformen arbeiten kann. Wir wollten auch, dass andere Entwickler bei Cerebras benutzerdefinierte Konnektoren erstellen können. Das Ergebnis ist bewusst einfach: Jede Quelle, von Slack-Threads bis zu Netlists, landet in derselben Embedding-Tabelle, und alles in dieser Tabelle ist sofort über dieselbe Schnittstelle abfragbar:
Jede Datenquelle definiert, was die Daten sind, wie man sich mit ihnen verbindet und wie oft sie abgerufen werden sollen. Jede resultierende Embedding-Zeile folgt derselben Schnittstelle, unabhängig davon, ob sie von Slack, einem Code-Repository, einem Dokumentensystem oder einer benutzerdefinierten Datenbank stammt.
Wie wir unstrukturierte Slack-Gespräche verarbeiten
Slack war die wichtigste Datenquelle, die wir entwerfen mussten. Hier finden unternehmensweit die aktuellsten technischen Diskussionen statt.
Zunächst haben wir getestet, ob einfache Embeddings über Rohtext ausreichen. Wir haben schnell erkannt, dass die reine Vektorsuche nicht ausreicht, um alle relevanten Daten zu finden.
Slack-Nachrichten stellen mehrere Herausforderungen dar:
- Die Informationsdichte variiert enorm: „hey yeah sure mike“ und eine detaillierte Kernel-Erklärung sind beides Nachrichten.
- Die Nachrichtenlängen variieren, und kürzere Nachrichten schneiden bei der Kosinus-Ähnlichkeit oft besser ab als längere, detailliertere Nachrichten.
- Die Bedeutung einer Nachricht hängt oft von der umgebenden Konversation ab.
Wir brauchten einen hybriden Ansatz. Wir haben die Slack-Erfassung so aufgebaut, dass jeder Thread über mehrere Suchtechniken gleichzeitig auffindbar ist, wobei jede Technik die Schwächen der anderen ausgleicht:
- Volltextsuche erfasst die genauen Tokens, die Embeddings verschmieren: Fehlerstrings, Flag-Namen, Hostnamen. Wenn ein Entwickler eine wörtliche Fehlermeldung einfügt, ist ein exakter lexikalischer Treffer fast immer der beste Beweis, und keine noch so große semantische Ähnlichkeit sollte ihn übertrumpfen.
- Embedding-Suche erfasst Paraphrasen. Die Person, die fragt: „Restore hängt nach Manifest-Load“ und die Person, die antwortet: „Checkpoint stockt auf dem NFS-Mount“, verwenden möglicherweise nie denselben Wortschatz. Vektorähnlichkeit verbindet eine Frage mit einer Antwort, die in anderen Worten formuliert ist.(1)
- Inverse Dokumenthäufigkeit trennt Signal von Füllmaterial. Eine kurze Nachricht, die um seltene Tokens herum aufgebaut ist, wie ein obskures Konfigurations-Flag, verdient eine hohe Platzierung. „klingt gut, danke!“ liegt in vielen Embedding-Räumen nahe an vielen Abfragen, erzielt aber nahezu null Punkte, sobald die Seltenheit der Begriffe berücksichtigt wird.
- Altersabklingung kodiert, dass Slack-Antworten veralten. Zwei Threads können dieselbe Frage beantworten, und der von vor sechs Monaten beschreibt möglicherweise eine Infrastruktur, die nicht mehr existiert. Wenn die Relevanz ansonsten gleich ist, gewinnt der neuere Thread.
Kein einzelner Bewerter wird allein verwendet. Jede Technik erzeugt ihre eigene Rangfolge desselben Korpus, und diese Ansichten werden zur Abfragezeit fusioniert (siehe Neubewertung).
Socket-Modus
Um Daten in Echtzeit zu sammeln, haben wir einen Slack-Bot in unserem Workspace installiert und im Socket-Modus ausgeführt. Slack pusht jedes Nachrichtenereignis über einen persistenten WebSocket an uns, sodass wir Echtzeit-Updates erhalten, ohne die Web-API abzufragen und deren Ratengrenzen zu überschreiten.
Wenn ein Ereignis eintrifft, bestätigen wir es sofort, deduplizieren es mit der stabilen Ereignis-ID und markieren die Nachricht für den Erfassungs-Consumer.
Der Erfassungs-Consumer speichert keine neue Nachricht isoliert. Er löst den Thread auf, zu dem die Nachricht gehört, und ruft die gesamte Konversation, einschließlich der übergeordneten und aller Antworten, erneut von der Slack-API ab. Dann schreibt er den gesamten Thread als eine Zeile zurück. Eine Antwort auf einen vorhandenen Thread zieht daher die übergeordnete und alle Geschwister nach, sodass der gespeicherte Inhalt, die Teilnehmerliste und der Zeitstempel der letzten Aktivität immer die vollständige Konversation widerspiegeln.
Jeder Slack-Channel in unserem System hat seine eigene Datenquelle. Dies ermöglicht eine fein abgestimmte Datenaktualität. Ein Team kann sich beispielsweise dafür entscheiden, einen viel frequentierten Vorfallskanal häufiger zu erfassen.
Threads und Nachrichten
Roher Slack-Text ist sofort nach dem Eintreffen durchsuchbar, da wir einen Postgres-Volltextindex (GIN) über den Rohinhalt führen. Um eine nützliche Vektorsuche zu ermöglichen, führen wir jedoch einige zusätzliche Verarbeitungsschritte durch.(8)
Während der Destillation extrahiert ein LLM strukturierte Daten aus dem vollständigen Thread:
- Eine einzeilige Frage, nach der ein Entwickler tatsächlich suchen würde.
- Eine kurze Zusammenfassung.
- Die Lösung.
- Die erwähnten Systeme und Code-Referenzen.
Wir embedden diese Datenpunkte und schreiben sie in die gemeinsame Embedding-Tabelle. Das ursprüngliche Transkript wird nicht direkt embedded. In unseren Experimenten stieg die Genauigkeit erheblich, wenn der Thread in ein konsistentes Format normalisiert wurde.(7,9) Die zusätzlichen Metadaten liefern dem semantischen Abgleich ebenfalls ein nützlicheres Signal.
Bursting
An diesem Punkt war die Slack-Suche gut, aber wir stießen immer wieder auf dasselbe Problem: Wichtige Nachrichten in langen Threads wurden nicht immer in der Thread-Zusammenfassung auf Thread-Ebene abgebildet.
Um das Signal einzelner Nachrichten zu verstärken, verwenden wir Bursting. Ein Burst ist eine Folge aufeinanderfolgender Nachrichten desselben Autors. Wir embedden einzelne Bursts mit dem vorangestellten Thread-Thema als Kontext(2), da die Antwort manchmal in einer einzigen tangentialen Nachricht lebt, deren Vokabular es nie in die Thread-Zusammenfassung schafft. Burst-Embeddings machen diese Nachricht eigenständig auffindbar.
Um zu verhindern, dass Daten mit geringem Signal die Datenbank erreichen, wird jeder Burst anhand einer gewichteten Kombination von Signalen bewertet und muss einen Schwellenwert überschreiten, bevor er embedded wird:
- Er enthält ein relativ seltenes Token im gesamten Korpus mit einer IDF von mindestens 4,0.
- Der kombinierte Burst ist mindestens 200 Zeichen lang.
- Eine oder mehrere Nachrichten im Burst enthalten Reaktionen, was einen sozialen Boost bietet.
Nach der Destillation werden qualifizierte Bursts embedded und zusammen mit dem Datensatz auf Thread-Ebene in der Embedding-Tabelle gespeichert.
Code-Repositories
Anfangs haben wir diskutiert, ob das Embedden von Code-Repositories notwendig ist. Mit dem Aufkommen von Claude Code und anderen Befehlszeilen-Tools schien es kontraintuitiv, Code-Embeddings zu erstellen, wenn es so aussah, als ob „grep ist alles, was du brauchst“. Nach Gesprächen mit anderen in der Branche und dem Lesen von Cursors Erkenntnissen zur semantischen Suche in großen Codebasen haben wir beschlossen, es zu versuchen.
Wir haben viele interne Repositories, einige davon größer als 40 GB. Unser Hauptanliegen war, wie wir sie effizient auf dem neuesten Stand halten können.
Verwendung von @cocoindex_io zur Pflege von Code-Embeddings
Nach mehreren Experimenten haben wir uns für CocoIndex entschieden, ein Open-Source-Dokument-Embedding-Framework, das sich auf das Vektorisieren von Codebasen spezialisiert hat.
Für jedes Repository teilen wir den Code mit sprachspezifischen Regex-Grenzen auf, die von grob zu fein geordnet sind. Der Splitter versucht zuerst, höherrangige Grenzen wie Klassen zu verwenden. Wenn ein resultierender Block immer noch zu groß ist, fällt er auf Methodengrenzen und dann auf kleinere Blöcke zurück. Wir embedden die resultierenden Blöcke und schreiben die Vektoren in Postgres. Eine einzelne Datei kann mehrere Embeddings auf verschiedenen Granularitätsebenen erzeugen, z. B. Datensätze auf Datei- und Funktionsebene.
CocoIndex verfolgt Synchronisationsmetadaten in Postgres. Bei jedem Commit werden nur die geänderten Code-Blöcke neu embedded und exportiert, anstatt das gesamte Repository neu zu berechnen. Dies hat für uns besonders gut funktioniert, da der Synchronisationsstatus und der Embedding-Speicher in derselben Datenbank leben.
Mit der wachsenden Anzahl von Codebasen haben wir die Aufnahme von Repositories in Konfigurationsdateien verlagert, die Teams selbst einreichen können, einschließlich Whitelists und Blacklists auf Dateipfad-Ebene.
Benutzerdefinierte Datenquellen
Einige Teams hatten bereits ihre eigenen Datenbanken und wollten Daten nicht in Slack oder ein Dokumentensystem verschieben, nur um an der Wissensdatenbank teilzunehmen. Sie wollten dieselbe Abfrageoberfläche für ihre vorhandenen Tabellen.
Um dies zu unterstützen, behandeln wir benutzerdefinierte Quellen als Plugin-Skripte. Ein Team eröffnet einen Pull-Request mit einem kleinen Python-Modul, das weiß, wie es aus seinem System liest und Zeilen ausgibt, die wie unsere Embedding-Tabelle geformt sind, plus einen passenden Datenquellen-Eintrag.
Solange das Skript unter Verwendung desselben Schemas wie jede andere Embedding-Zeile in die gemeinsame Datenbank schreibt, funktioniert der Rest des Stacks unverändert. Die Daten werden neben Slack, Code und Dokumenten abfragbar, ohne dass eine spezielle Behandlung an anderer Stelle im System erforderlich ist.
Planung und Tool-Aufteilung
Für jede Abfrage führen wir zunächst einen kurzen Planungsschritt durch, bei dem ein LLM entscheidet, welche Tools und Datenquellen wahrscheinlich relevant sind. Die wichtigsten Tools:
- subsystem_index: LLM-Zusammenfassungen pro Datei.
- search: die einheitliche Vektor-Pipeline über Slack, Wiki, Code und andere indizierte Quellen, intern zusammengeführt und neu bewertet.
- search_slack: direkter Slack-Abruf.
- search_code: ripgrep über Quell-Repositories.
- recent_prs: aktuelle Pull-Requests, die für die Frage relevant sind.
- who_knows: Personen mit nachgewiesener Expertise zu einem Thema.
Der Planer arbeitet mit einer kompakten Beschreibung dessen, was wir indiziert haben: welche Projekte existieren, welche Quellen in jedem Projekt verfügbar sind und wofür jede Quelle gut ist. Angesichts der Abfrage des Benutzers und des aktiven Bereichs gibt er Tool-Auswahlen aus, die der Executor parallel ausführt, in ein gemeinsames Beweisformat normalisiert und an ein endgültiges Synthese-LLM übergibt.(4)
Neubewertung (Reranking)
Ein Dokument kann allein deshalb weit oben erscheinen, weil es den Wortschatz der Abfrage teilt, während es eine andere Frage beantwortet. Vor der Neubewertung kombinieren wir die inkompatiblen Ergebnislisten der Retriever mit der reziproken Rangfusion (RRF). Für jedes Dokument addieren wir Gewicht / (60 + Rang) für jede Liste, in der es erscheint, mit einem Standardgewicht von 1,0 und einer Glättungskonstante von 60.
Die Glättungskonstante macht Konsens wichtiger als eine einzelne starke Stimme: Ein Dokument, das in mehreren Retrievern weit oben auftaucht, kann eines schlagen, das in nur einem von ihnen an erster Stelle steht. Wir führen dann doppelte Blöcke wieder zu einer Quelle zusammen, begrenzen, wie viele Ergebnisse jede Datei beitragen kann, und erhalten so eine vielfältigere Top-20-Liste.
Wir senden die ursprüngliche Abfrage und diese Kandidaten an ein kleines Reranker-Modell. Es bewertet jedes Dokument mit einer Punktzahl von null bis zehn, und wir behalten die Top Ten.(6)
Sobald das Ranking endgültig ist, fügen wir den Gewinnern Kontext hinzu. Wenn wir beispielsweise einen Wiki-Abschnitt abgleichen, ziehen wir die beiden benachbarten Abschnitte hinzu, damit die Überschrift, die Vorbedingungen und die Einschränkungen, die durch die Aufteilung getrennt wurden, nicht verloren gehen. Dies gibt den Lesern einen vollständigen Ausschnitt anstelle eines einsamen Absatzes, dem wichtiger Kontext fehlt.
Das Ergebnis der Suche ist also ein reichhaltiges Beweispaket: Ergebnisse, die von verschiedenen Retrievern fusioniert, auf Quellenebene dedupliziert, anhand der tatsächlichen Frage neu bewertet und erst dann mit umgebendem Kontext erweitert wurden.
MCP
In der MCP-Integration stellen wir Retrieval-Bausteine als direkte Tools zur Verfügung, anstatt sie hinter einem einzigen „Beantworte diese Frage“-Endpunkt zu verstecken. Diese Tools sind bewusst einfach und so LLM-frei wie möglich, damit Clients sie schnell und kostengünstig abfragen können.(5)
Jedes MCP-Tool entspricht einem zugrunde liegenden Retrieval-Primitiv, wie search_slack, search_code, search oder who_knows. Tool-Eingaben und -Ausgaben sind schmal, strukturiert und stabil, sodass sie von jedem Client oder Agenten einfach aufgerufen werden können, ohne zusätzliche Orchestrierungslogik in das Tool selbst einzubetten.
Die meisten Tools führen eine Abfrage-Pipeline aus, wie Vektorsuche, lexikalische Suche oder ripgrep, wenden leichte Bewertungsheuristiken an und geben rohe Beweiszeilen zurück.
Claude Code oder jeder MCP-kompatible Agent wird zur Orchestrierungs-Engine. Er entscheidet, welche Tools in welcher Reihenfolge aufgerufen werden und wie die Ergebnisse zu einer endgültigen Antwort oder Code-Bearbeitung zusammengesetzt werden. Die Retrieval-Schicht selbst ist für die Bedienung von Anfragen nicht von diesen LLM-Entscheidungen abhängig.
Web-UI
In der Web-UI existieren dieselben Tools, aber sie sind mit einer vollständigen Abfrage-Pipeline verbunden, die für jede Benutzerfrage durchgängig ausgeführt wird. Der UI-Agent besitzt die Schritte Planer und Executor.
- Planer: Ein leichter LLM-Durchlauf untersucht die Abfrage und das aktive Projekt und wählt dann aus, welche Retrieval-Tools aufgerufen werden sollen, z. B. search, search_slack und subsystem_index.
- Executor: Das System verteilt diese Tool-Aufrufe parallel, sammelt die Ergebnisse und normalisiert sie in ein gemeinsames Beweisschema mit Punktzahlen, Aktualität und Quellenhinweisen.
- Synthese: Ein letzter LLM-Durchlauf nimmt das typisierte Beweispaket und die ursprüngliche Frage und erzeugt die in der UI angezeigte Antwort, einschließlich Zitaten, Einschränkungen und quellenübergreifender Synthese.
Aus der Perspektive des Benutzers ist die Web-UI einfach „Stelle eine Frage und erhalte eine Antwort“. Unter der Haube führt sie dasselbe Planer → Executor → Synthesizer-Muster aus, das MCP-Clients explizit nachbilden können.
Organisation
Als der Korpus wuchs, war „Alles überall durchsuchen“ schnell nicht mehr nützlich. Entwickler in Compiler-Teams wollten keine Infrastruktur-Runbooks in ihren Ergebnissen und umgekehrt. Projekte sind die Art und Weise, wie wir die Suche standardmäßig relevant machen.
Projekte und bereichsbezogene Suche
Wir haben Projekte als primäre Möglichkeit eingeführt, den Arbeitsbereich zu organisieren, über den eine Abfrage läuft. Ein Projekt ist ein benanntes Bündel von Datenquellen: bestimmte Slack-Channels, Code-Repositories, interne Datenbanken und Dokumentenbereiche, die für ein Team oder eine Initiative relevant sind.
Projekte sind bewusst leichtgewichtig. Dieselbe Datenquelle, wie ein gemeinsamer Vorfallskanal oder ein zentrales Plattform-Repository, kann von mehreren Projekten referenziert werden, anstatt dupliziert zu werden.
Onboarding und Standardeinstellungen
Während des Onboardings werden Benutzer aufgefordert, ein Standardprojekt auszuwählen oder zu erstellen, das zu ihrer Arbeitsweise passt, z. B. ML-Trainingsinfrastruktur, Compiler oder Rechenzentrumsbetrieb.
Dieses Standardprojekt wird im Benutzerprofil gespeichert und schränkt Abfragen automatisch ein. Ein neuer Entwickler erhält aussagekräftige Antworten, ohne zuerst lernen zu müssen, welche Slack-Channels, Repositories oder Dokumentenbereiche relevant sind.
Abschließende Gedanken
Letztendlich funktioniert die Wissensdatenbank, weil sie die Menschen dort abholt, wo die Informationen bereits leben, anstatt alles in ein starres System zu zwingen. Durch die Kombination verschiedener Suchtechniken können wir Beweise schnell sichtbar machen. Das Ergebnis ist eine Sucherfahrung, die flexibel genug für reale Unternehmensdaten bleibt, aber strukturiert genug, um nützlich zu sein, während Cerebras weiter wächst.
Wenn du bis hierher gelesen hast und dies interessant findest, das AI/Growth-Team stellt ein. Melde dich, wenn du interessiert bist, bei @learnwdaniel
Referenzen
- Malkov und Yashunin, Effiziente und robuste approximative Nächste-Nachbarn-Suche mittels hierarchischer navigierbarer Small-World-Graphen, arXiv:1603.09320 / IEEE TPAMI 2018.
- Anthropic, Einführung in das kontextuelle Retrieval, 2024.
- Cormack, Clarke und Büttcher, Reziproke Rangfusion übertrifft Condorcet und individuelle Ranglernmethoden, SIGIR 2009.
- Li et al., Search-o1: Agente gestützte, suchverstärkte große Reasoning-Modelle, arXiv:2501.05366, 2025.
- Anthropic,
