Marktmannen wiki Personal Knowledge Management (PKM)

Enterprise RAG-kennisbank (Cerebras)

Laatst bijgewerkt: 21-07-2026

TL;DR: Cerebras bouwde een interne kennisbank die 15.000+ vragen/dag beantwoordt door Slack, code, wiki's en custom databases in één Postgres embeddings-tabel te bundelen, met hybride retrieval (full-text + embeddings + IDF + age decay) en een planner→executor→synthesis-pipeline.

Interne AI-kennisbank van chipbedrijf Cerebras, gebouwd rond het principe "meet data waar het al leeft" in plaats van alles naar één platform te verhuizen. Sinds lancering (3 maanden voor publicatie) een van de meest gebruikte interne tools, gebruikt door mensen, automations en agents. Relevant als tegenhanger van de LLM-wiki-aanpak in Zelfverbeterende Kennisbank: dit is een RAG/embeddings-architectuur op schaal, niet een door een LLM gecureerde Markdown-wiki.

Architectuur: één tabel, veel bronnen

Drie lagen: (1) platform voor het verzamelen/opslaan van data, (2) platform voor het bevragen ervan, (3) laag voor authenticatie/autorisatie met auditing. Kern is één Postgres-tabel met embeddings, ruwe samenvattingen en metadata uit alle bronnen (Slack, wiki/Confluence, code repos, netlists, PRM-docs, custom databases). Elke bron heeft een eigen connector die definieert wat de data is, hoe te verbinden, en hoe vaak te verversen — maar elke resulterende rij volgt hetzelfde interface, ongeacht bron.

Slack-verwerking: hybride retrieval

Slack was de belangrijkste en lastigste bron (meest actuele discussies, maar sterk wisselende informatiedichtheid). Pure embeddings bleken onvoldoende. Vier technieken werken samen, elk compenserend voor de zwakte van de andere:

  • Full-text search — vangt exacte tokens die embeddings vervagen: foutmeldingen, flag-namen, hostnamen. Letterlijke matches verslaan semantische gelijkenis.
  • Embedding search — vangt parafrases; verbindt een vraag met een antwoord in andere bewoordingen.
  • Inverse document frequency (IDF) — scheidt signaal van ruis. Een kort bericht met een zeldzaam token (obscure configvlag) scoort hoog; "sounds good, thanks!" scoort laag ondanks embedding-nabijheid.
  • Age decay — nieuwere antwoorden winnen bij gelijke relevantie, omdat infrastructuur-context verloopt.

Ingestie via Socket Mode: een Slack-bot ontvangt elk bericht real-time via persistent WebSocket (geen polling). Bij een nieuw bericht wordt niet het bericht alleen opgeslagen — de hele thread (parent + alle replies) wordt herladen en als één rij weggeschreven, zodat inhoud en laatste-activiteit-timestamp altijd de complete conversatie weerspiegelen.

Distillatie: een LLM extraheert uit elke thread een one-line vraag, korte samenvatting, resolutie, en genoemde systemen/code-referenties. Het ruwe transcript wordt niet direct ge-embed — normalisatie naar een consistent formaat verhoogde de nauwkeurigheid aanzienlijk.

Bursting: opeenvolgende berichten van dezelfde auteur ("bursts") worden apart ge-embed met de thread-topic als context, omdat belangrijke informatie soms in een tangent-bericht zit dat niet in de thread-samenvatting terechtkomt. Een burst moet een signaaldrempel halen (zeldzaam token met IDF ≥ 4.0, minimaal 200 tekens, of reacties als sociale boost) voor die wordt opgeslagen.

Code repositories

Twijfel vooraf of code-embeddings nodig waren naast grep/ripgrep-achtige tools; na onderzoek (o.a. Cursor's bevindingen over semantisch zoeken) toch gekozen voor embeddings. Gebruikt CocoIndex (open-source embedding-framework) om repo's te chunken via taalspecifieke regex-grenzen, van grof (klassen) naar fijn (methodes, kleinere blokken). Bij elke commit worden alleen gewijzigde chunks opnieuw ge-embed — synchronisatiestatus en embeddings staan in dezelfde database.

Custom databases als plugins

Teams met eigen databases hoeven hun data niet te migreren: ze schrijven een klein Python-script dat rijen emit in hetzelfde schema als de gedeelde embeddings-tabel. Zodra het schema klopt werkt de rest van de stack ongewijzigd — geen speciale behandeling elders in het systeem.

Planner → executor → synthesis

Voor elke vraag bepaalt een planner welke tools/bronnen relevant zijn (search, search_slack, search_code, recent_prs, who_knows, subsystem_index). De executor voert deze parallel uit, normaliseert de resultaten naar een gedeeld evidence-formaat, en een synthesis-LLM stelt het uiteindelijke antwoord met citaten samen.

Reranking: resultaatlijsten van verschillende retrievers worden eerst gecombineerd via Reciprocal Rank Fusion (RRF) — elk document krijgt gewicht/(60 + rank) per lijst waarin het voorkomt, met smoothing-constante 60. Consensus over meerdere retrievers weegt zo zwaarder dan één sterke ranking in slechts één lijst. Na deduplicatie en een cap per bestand gaat de top-20 naar een reranker-model dat elk document 0-10 scoort; top-10 blijft over. Bij de uiteindelijke winnaars worden aangrenzende secties toegevoegd zodat context (kopjes, randvoorwaarden) niet verloren gaat door chunking.

MCP vs. web-UI

MCP: retrieval-primitieven (search_slack, search_code, search, who_knows) worden als losse, LLM-vrije tools blootgesteld — smal, gestructureerd, stabiel. Claude Code of een ander MCP-compatibel agent-systeem wordt zelf de orchestratielaag en beslist welke tools wanneer aan te roepen.

Web-UI: dezelfde tools, maar ingebed in een complete pipeline die de planner→executor→synthesis-stappen zelf uitvoert — voor de gebruiker is het simpelweg "stel een vraag, krijg een antwoord."

Naarmate de corpus groeide werd "zoek overal" onbruikbaar (compiler-engineers wilden geen infra-runbooks in hun resultaten). Projects bundelen specifieke Slack-kanalen, repo's, databases en documentruimtes per team/initiatief. Eenzelfde bron (bijv. een gedeeld incidenten-kanaal) kan door meerdere projecten gerefereerd worden zonder duplicatie. Nieuwe gebruikers kiezen bij onboarding een default project, wat direct relevante antwoorden geeft zonder eerst te hoeven leren welke kanalen/repo's tellen.

Praktisch: dit zelf nabouwen

De YouTube-bespreking van dit blogbericht (Nick Saraev) demonstreert dat je deze architectuur met een coding agent (Claude Code) kunt laten nabouwen door simpelweg het blogbericht te plakken en te vragen om ingestion-pipelines voor je eigen bronnen (Slack, e-mail, GitHub, YouTube) te bouwen — de agent regelt authenticatie/OAuth-setup grotendeels zelf. In zijn eigen (kleinere) implementatie met ~640 documenten steeg de score op 20 testvragen van 0/20 (zonder kennisbank) naar 17/20 (met kennisbank). Kanttekening: dit is een enthousiast praktijkverslag van een individuele gebruiker, geen onafhankelijke validatie van de Cerebras-cijfers (15.000 vragen/dag) zelf.

Open vragen

  • Hoe verhoudt de investering (Postgres + CocoIndex + eigen reranker + planner/executor-laag) zich tot een eenvoudiger LLM-wiki-aanpak voor een MKB-schaal team — vanaf welke teamgrootte/documentvolume loont een volwaardige RAG-pipeline?
  • Welke onderdelen (bijv. RRF-reranking, age decay) zijn ook met beperkte middelen te implementeren zonder de volledige Postgres/CocoIndex-stack?

Verwante concepten

Bronnen

#rag #embeddings #kennisbank #slack-ingestie #reranking #mcp #enterprise

Backlinks