Cerebras 每日 1.5 萬次查詢的內部知識庫：不是單一真相來源，而是到資料產地搜尋
Cerebras 公開內部 Knowledge Base 架構：保留 Slack、Wiki、Code、Incident、客製資料庫等資料產地，以同一張 Postgres/pgvector embeddings 表與共通介面接入；查詢端採 full-text、embedding、IDF、age decay、RRF、LLM rerank、project scope 與 MCP/Web UI 工具化，讓企業知識庫從文件倉庫變成可被人、automation、agent 共同使用的證據檢索層。
Enterprise Knowledge Base / RAG Architecture
Cerebras 在官方工程文章 How We Built Our Knowledge Base 裡公開了一個很值得企業 AI 團隊研究的內部知識庫架構：上線 3 個月後，員工、automation 與 agents 每天會向這套系統提出超過 15,000 個問題。
這篇 Threads 轉述的重點抓得很準：Cerebras 沒有把所有資料硬搬進同一個平台，而是承認資訊本來就長在 Slack、Wiki、GitHub、Jira、incident、團隊資料庫等不同地方；知識庫的核心任務不是創造「唯一資料入口」，而是把各資料產地整理成同一種可查詢證據介面。
核心觀念：meet data where it lives
多數企業知識庫失敗，不是因為少了一個更漂亮的文件工具，而是因為「single source of truth」常常違反實際工作流。PR 討論適合在 GitHub，incident 協作適合在 Slack，文件評審適合在 Docs/Wiki，專案狀態可能在 Jira 或內部資料庫。硬要求所有人改用同一個平台，通常只會讓資料更新率下降。
Cerebras 的資料層：一張共用 embeddings table，多個 connector
Cerebras 的核心資料介面很簡單：不同來源各自負責接資料，但最後都寫入同一張 Postgres 表，裡面包含 embedding、原始摘要與 metadata。官方文章列出的來源包含 Slack、Wiki/Confluence、code repos、netlists、PRM docs、custom databases 等。
| 資料來源 | 接入方式 | 設計重點 |
|---|---|---|
| Slack | Socket Mode + thread re-fetch | 即時事件、去重、整串 thread 重新整理，避免只存單則訊息造成上下文破碎。 |
| Wiki / 文件 | 文件 connector | 保留段落、鄰近 context 與 metadata，查詢時可補回前後文。 |
| Code repo | CocoIndex + language-aware chunking | 依 class、method、區塊等語意邊界切分；只重算變更 chunk。 |
| 團隊自有 DB | plugin script / custom source | 團隊只要寫小型 Python module，把資料輸出成同一 schema，就能被同一查詢介面使用。 |
Slack 為什麼不能只靠 vector search
官方文章特別花篇幅談 Slack，因為工程團隊最新、最真實的解法常在 Slack 裡，但 Slack 對話非常不適合直接拿 raw text 做純 embedding：
- 訊息資訊密度差異很大：「收到，謝謝」和完整 debug 解法都是 message。
- 短訊息可能在 cosine similarity 上打敗更完整的長訊息。
- 單則訊息常常依賴整串 thread 才能理解。
所以 Cerebras 對 Slack 採混合搜尋：
- Full-text search：抓 error string、flag name、host name 這種 embedding 容易模糊掉的精確 token。
- Embedding search：處理不同講法之間的語意相似，例如使用者問 restore hangs，但答案可能寫 checkpoint stalls。
- IDF：讓罕見的專有名詞、config flag 壓過「sounds good, thanks」這類低訊號句子。
- 當相關性相近時偏向新答案，避免撈到早已過時的 infra 解法。