How Cerebras built its AI knowledge base, and what every ecommerce brand should steal from it

Cerebras builds some of the fastest AI inference hardware on the planet. Last month its engineering team did something rare and published a detailed write-up of how it built *Cerebras Knowledge*, the internal system that now answers more than 15,000 questions a day from employees, automations, and AI agents. It is genuinely worth reading in full. But you do not run a chip company, you run a store, so here is the translation: almost every decision they made is the same decision we make when we build the knowledge base behind an AI support agent for an ecommerce brand. The scale is wildly different. The principles are identical.

Lesson 1: meet your data where it lives

Their first and biggest decision was a refusal. They did not build a pristine central knowledge base that every team has to maintain by hand. They extract knowledge from where it is already being created, Slack, docs, code, tickets, and leave those tools untouched. Their guiding principle is to meet data where it lives.

Your store’s knowledge is exactly this scattered, which is the same thing we argued in the piece on Karpathy’s wiki idea. It lives in your Gorgias and Zendesk macros, in every resolved ticket, in a Google Doc of policies, in the Slack thread where someone finally explained the EU returns rule for the third time, and in your product catalogue. The losing move is to demand everyone stop and hand-write a perfect manual. The winning move is to read the sources they already use, automatically, and keep them fresh.

“Do not make your team maintain a second copy of everything they already know. Read the sources they already live in.”

Lesson 2: one index, many sources

Under the hood, everything lands in a *single* embeddings table with one shared schema: every distilled Slack thread, every doc section, every code chunk, in the same place. Adding a new source means declaring just three things, what the data is, how to connect to it, and how often to refresh it. Then it flows into the same searchable layer as everything else, with no bespoke plumbing per source.

# Each source only has to declare three things:
source:  resolved_tickets
connect: gorgias(api_key)   # where it lives
refresh: hourly            # how fresh to keep it
# ...then it flows into the same index as your policies,
# product catalogue, and FAQs, queryable through one interface.

The same shape works for a store. Your FAQs, policy docs, product descriptions, and a cleaned-up version of every past ticket become rows in one index the agent searches. Live order data is the deliberate exception: that is never embedded, it is fetched in real time through a secure tool call, exactly the split we drew in the RAG explainer. One index for the reference knowledge, tools for the live facts.

Lesson 3: distill before you embed

This is the detail most teams miss, and it is the one I would copy first. Cerebras does not embed raw Slack threads. Before indexing, an LLM reads each messy thread and rewrites it into a clean, structured record: the underlying question, a summary, the resolution, and the systems involved. That distilled version is what gets embedded. The reported payoff was "significant accuracy gains" over embedding the raw transcript.

This is the same failure mode we warned about with naive retrieval: bad chunking and raw text bury the answer where search cannot find it. Distillation is the fix, and it is cheap.

Lesson 4: one embedding model is not enough

Cerebras found that pure semantic search was not enough on its own, so it fuses several signals at once: full-text search for exact strings like error codes and flag names, embedding search for paraphrases, a rarity weight that boosts unusual terms and filters boilerplate like "thanks, works now," and an age decay so a fresh thread beats a stale one.

Your customers generate the exact same mix, and a single embedding model will fail on half of it:

• Exact match for an order number, a SKU, or a discount code, where semantics are useless and you need the literal string.
• Meaning-based match for "can I send this back," which has to find a doc titled "Returns & Exchanges" that shares none of those words.
• Rarity weighting so "free-shipping threshold" outranks the generic filler that appears in every policy.
• Recency so that when your shipping rule changed last month, the current version wins and last month’s does not.

Lesson 5: retrieval is a pipeline, not a lookup

Here is the line between a demo and a product. In Cerebras Knowledge a query does not just hit a vector search and return. It runs a pipeline: a lightweight planner picks which tools to use, retrieval runs in parallel across sources, the results are fused and reranked down to a best handful, the context is expanded to include neighbouring sections, and only then does a final model synthesize an answer *with citations*.

You do not need their exact stages, but you need that shape. Plan, retrieve from the right sources, rerank hard, and synthesize an answer that cites the policy it came from, so when a customer asks about a refund the agent quotes your actual rule and can show its work. The citation is what makes the answer safe to put in front of a customer, and it is what lets a human spot-check the agent instead of trusting it blind.

“A support answer with no source is just a guess in a nicer font.”

Lesson 6: scope it before it drowns

One of their most honest admissions: as the corpus grew, "global search stopped being useful." Their fix was a Projects feature, bundles of the specific channels, repos, and docs relevant to one team, so a question is answered from the right slice rather than the entire company.

The same rot sets in for a store as the catalogue and the ticket history grow. A question about one product line should not be answered from an unrelated one, and a wholesale query should not pull retail policy. Scope the agent by domain, returns, shipping, a specific product family, so it reasons over the relevant slice. More knowledge only helps if it is organized; dumped in a pile, it just adds noise.

Lesson 7: build it for agents, not just a chat box

The quiet punchline is who is asking the questions. Those 15,000 daily queries do not all come from people. They come from humans, automations, and *other AI agents*. Cerebras exposes its retrieval as an MCP server so agents can call it directly. The knowledge base is not a chatbot, it is a retrieval layer the whole company and its automations run on.

This is exactly how we think about it for a brand. The knowledge base you build for your support agent is the same grounded layer your other systems draw on: the content agent that needs your brand voice and claims, the automation that needs your policies. Build the brain once, and every agent you add afterwards gets smarter for free.

You do not need Cerebras’s scale

The instinct on reading a write-up like this is "that is a frontier AI lab, it does not apply to me." It applies more than you think. Strip away the 40 GB repositories and the big numbers and the blueprint is small: pull from where knowledge already lives, distill it before you store it, retrieve with more than one signal, cite your sources, scope by domain, and expose it to your agents. Do that and you have a support agent that answers like your best rep on their best day.

If your team keeps answering the same questions and your knowledge is scattered across five tools, that scatter is the raw material for exactly this kind of system. Book a call and we will map your sources into one brain.