Cerebras published the blueprint for its internal knowledge base — data stays put, no habits change, and the AI does the fetching
- Three Cerebras engineers published how the company built its internal knowledge base, Cerebras Knowledge. Three months after launch, it's fielding more than 15,000 questions a day — from employees, automated scripts, and agents alike.
- It doesn't ask anyone to change how they work: material stays in Slack, code repos, and the docs system, and the system goes to each platform to pull the data, all landing in the same Postgres table.
- Slack is the hardest source to crack. The same batch of candidates gets scored four different ways at once — full-text match, embedding match, rare-term weighting, and time decay — each covering a different blind spot.
- Chat logs don't go straight into embeddings. A model first distills them into a fixed structure — a one-line question, a summary, the resolution, and the systems and code symbols involved — and only that gets embedded.
- Six retrievers each produce their own ranking, merged into one via reciprocal rank fusion with the constant set to 60 — so a document that ranks well across several lists beats one that's first on only one.
15,000 questions a day — and some of them come from agents
Three Cerebras engineers recently pulled back the curtain on the company blog, laying out exactly how their internal knowledge base, Cerebras Knowledge, works — from how data gets ingested to how answers get ranked, with every threshold and parameter along the way spelled out.
The system has been live for three months and now fields more than 15,000 questions a day. The people asking aren't just employees — automated scripts and agents ask too.
The problem it solves is one a lot of companies know well. Cerebras's teams span data center operations, chip design, hardware, training, inference, and cloud, and hundreds of new hires join every year. The company's chat channels fill up with the same three questions on repeat: where's this thing, who actually knows this, and what does this term mean.
① SOURCES — Slack, wiki, code, incident records ② DISTILLATION — a model extracts raw content into a fixed structure ③ EMBEDDINGS — stored in Postgres via pgvector, 3,072 dimensions, indexed with HNSW to find the nearest vectors fast ④ RETRIEVAL — six rankings run in parallel ⑤ FUSION + RERANK — reciprocal rank fusion first, then a small model reranks ⑥ SYNTHESIS — produces a cited answer. Source: Cerebras
Why "move everything to one place" never works
The hard part of finding things inside a company was never the search itself — it's that the material is inherently scattered. Every quarter, someone proposes the same "brilliant plan": record everything on one platform from now on, and make it the single source of truth. In practice, that almost never works.
The reason is that information gets created wherever it's most convenient: a suggested edit in a doc, a thread in Slack, a code reference on GitHub, a status field in Jira. Each of these platforms has spent years being refined for its own use case. Discussing a pull request in Google Docs would be a miserable experience.
So Cerebras's first decision was to design a system that asks almost no one to change their existing habits. On the ingestion side, that means going directly to each platform and pulling the data out.
- Ask everyone to write to one unified platform from now on
- Everyone gets an extra step, and it lapses after a few weeks
- Historical material stays where it was — neither copy is complete
- People keep writing wherever is most natural
- Write one connector per source to pull the data
- Everything pulled back gets normalized into the same table
The core of the whole thing is a single table
The knowledge base offers three things externally: a place to store internal data, a place to query it, and a layer handling authentication, access control, auditing, and usage stats.
At the core is one Postgres table holding vectors, raw summaries, and metadata side by side, regardless of source. The system keeps pouring in data from across the company to stay continuously queryable. The data interface is deliberately simple: whether it comes from a Slack thread or a netlist file used in chip design, it lands in the same vector table — and once it's in that table, it's queryable through the same interface.
Every data source only needs to define three things: what the data is, how to connect to it, and how often to pull it. Every row it produces has exactly the same field structure.
This design also leaves a door open for other teams. Some teams already run their own databases and don't want to move that data into Slack or a docs system just to get it into the knowledge base. The workaround is to treat that kind of source as a plugin script: the team submits a pull request with a small Python module that reads from its own system, emits rows matching the table's schema, and registers a data-source record. As long as it writes into the same store using the same fields, nothing else in the pipeline needs to change.
The hardest part of Slack is telling which line actually matters
Slack is the data source they care about most and find hardest to handle — it's where the company's freshest engineering discussions happen. They initially tried the cheapest approach: embed the raw text directly and search it. It quickly became clear that vectors alone couldn't catch everything.
The problem comes down to three traits of chat logs. First, information density varies wildly — "okay thanks" and a full paragraph explaining a kernel implementation both look like a single message to the system. Second, messages vary a lot in length, and short messages often beat out longer, more detailed ones on vector similarity. Third, a message's meaning often depends on the conversation around it.
Say you search the channel for "restore hangs after manifest load." The reply that actually solved this might not share a single word with the query — it says "checkpoint got stuck on the NFS mount." The literal closest match might be an eight-month-old workaround that's since been retired. And "okay thanks" resembles almost every question ever asked, at least a little.