How We Built Our Knowledge Base

Skip to main content

Go to homepage

Cerebras and AMD Partner on Disaggregated Inference. Learn more >>

Jul 15 2026

How We Built Our Knowledge Base

Isaac Tai Daniel Kim Mike Gao

Employees ask our internal knowledge base more than 15,000 questions every day. It's become one of the most widely adopted internal tools at the company since launching 3 months ago. Used by humans, automations and agents.

At Cerebras, our teams work across data center operations, chip design, hardware, training, inference, cloud platform, and more. With hundreds of new employees joining every year, our communication channels were filling up with the same questions:

> _“Where can I find X?”_ > > _“Who is the expert in Y?”_ > > _“What is Z?”_

We built Cerebras Knowledge to help people connect people and systems to useful information.

Exploded vertical stack of the internal knowledge baseSources feed distillation, embeddings, retrieval, fusion, and synthesis layers.12SYNTHESISANSWER + CITATIONSFUSION + RERANKRRF (K=60) -> LLM RERANKRETRIEVALSIX LISTS IN PARALLELEMBEDDINGSPGVECTOR - 3072-DIM - HNSWDISTILLATIONLLM EXTRACTORSSOURCESSLACK - WIKI - CODE - INCIDENTS

Meeting data where it lives

Finding information inside an organization is hard. The data is scattered across tools, and every quarter or so someone proposes the same brilliant fix: let’s record everything in one platform so that all information is in a single place. The dream of a single source of truth, of course, rarely works in practice.

Information is generated wherever it is convenient and ergonomic: suggested edits in a document, threads in Slack, code references in GitHub, and status metadata in Jira. These platforms are tailor-made for their specific domains, optimized through years of product engineering and analytics. Discussing a pull request in Google Docs would be a terrible experience.

So we set out to design a system that required minimal change to existing behavior. On the data collection side, this meant extracting data from each platform directly.

Anatomy of a knowledge base

Our knowledge base provides three things:

1. A platform for collecting and storing internal data. 2. A platform for querying that data. 3. A layer that enforces authentication and authorization, with auditing and analytics.

At the core is a single Postgres table that holds embeddings, raw summaries, and metadata from many sources. The system continually ingests data from across the company and maintains a query-ready datastore.

We wanted a data interface that was simple but could work with most forms of data. We also wanted other developers at Cerebras to be able to build custom connectors. The result is deliberately simple: every source, from Slack threads to netlists, lands in the same embeddings table, and anything in that table is immediately queryable through the same interface:

Many data sources feeding one queryable embeddings tableSLACKWIKI / CONFLUENCECODE REPOSNETLISTSPRM DOCSCUSTOM DATABASESEMBEDDINGSQUERYDOCUMENTEMBEDDINGMETADATASOURCE + TIMESTAMPSMCP - WEB UI - AGENTSONE EMBEDDINGS TABLEONE CONNECTOR PER SOURCE

Each data source defines what the data is, how to connect to it, and how often it should be fetched. Each resulting embedding row follows the same interface regardless of whether it came from Slack, a code repository, a document system, or a custom database.

Slack

Slack was the most important data source we needed to design for. It is where the most up-to-date engineering discussions happen across the company.

Slack event flow from Socket Mode through distillation and embeddingSOCKET EVENTROUTEBOT REPLYREINGEST\_THREADUPSERT THREADSYNC\_WORKERDISTILLTHREAD VECTORBURST VECTORS@MENTION / DMTRACKED CHANNELRESET WATERMARKS

How we process unstructured Slack conversations

We initially tested whether simple embeddings over raw text performed well enough. We quickly realized that vector search alone was insufficient for matching all relevant data.

Slack messages present several challenges:

• Information density varies enormously: “hey yeah sure mike” and a detailed kernel explanation are both messages.
• Message lengths vary, and shorter messages frequently beat longer, more detailed messages in cosine similarity.
• The meaning of a message often depends on the surrounding conversation.

We needed a hybrid approach. We built Slack ingestion so every thread is retrievable through several search techniques at once, where each technique makes up for the weaknesses of the others:

• Full-text search catches the exact tokens that embeddings blur together: error strings, flag names, host names. When an engineer pastes a literal error message, an exact lexical match is almost always the best evidence, and no amount of semantic similarity should outrank it.
• Embedding search catches paraphrase. The person asking “restore hangs after manifest load” and the person who answered “checkpoint stalls on the NFS mount” may never share vocabulary. Vector similarity is what connects a question to an answer written in different words.(1)
• Inverse document frequency separates signal from filler. A short message built around rare tokens, such as an obscure config flag, deserves to rank. “sounds good, thanks!” sits close to many queries in embedding space but scores near zero once term rarity is taken into account.
• Age decay encodes that Slack answers expire. Two threads can answer the same question, and the one from six months ago may describe infrastructure that no longer exists. When relevance is otherwise equal, the newer thread wins.

SEARCH / SLACK CANDIDATESFULL-TEXT

QUERY

“restore hangs after manifest load”

1. 2W AGO

NO SHARED TOKENS PARAPHRASE MATCH CKPT\_PREFETCH: RARE RECENT WINS TIE

Thread

Checkpoint stalls on the NFS mount — set CKPT_PREFETCH=4.

2. 1D AGO

EXACT TOKENS ERR\_MANIFEST\_TIMEOUT: RARE

Message

ERR_MANIFEST_TIMEOUT: restore hangs after manifest load.

3. 3H AGO

FALSE NEIGHBOR NO RARE TOKENS

Message

sounds good, thanks! will try that

4. 8MO AGO

ALSO MATCHES...