【2026 最新】企業 AI 知識庫怎麼做？拆解 Cerebras 7 層架構、Hybrid Search 與 MCP

同事在 Slack 問過、工程師在 GitHub 修過、文件也明明寫過，但新問題一來，大家還是從頭找一次。這不是公司沒有知識，而是知識散落在不同工具，沒有一條能被可靠查詢、核對權限並附上引用的路。

2026 年 7 月 15 日，AI 晶片公司 Cerebras 公開了自己的企業 AI 知識庫架構：資料留在 Slack、文件、程式碼與內部系統，再經過同步、整理、混合檢索、重排與回答。Cerebras 表示，系統推出約三個月後，每天處理超過 15,000 個問題；這個數字包含員工、automation 與 agent，是官方自陳的使用量，不等於 15,000 位使用者，也不能單獨證明答案準確率。

這篇不會叫你照抄一張架構圖，而是把企業 AI 知識庫拆成新手也能實作的七層：先讓資料可同步、可搜尋、可授權、可引用，再讓 AI 回答。讀完你會知道每一層在解什麼問題、第一版 PostgreSQL 怎麼設計，以及兩週 MVP 應該先驗收什麼。

企業 AI 知識庫是什麼？先別把它當成聊天機器人

沒有連接企業資料的通用模型，主要依參數內知識回答；企業 AI 知識庫則先確認「這位使用者能看哪些公司資料」，再找出最相關的原文，最後才生成答案與引用。它的核心其實不是 LLM，而是一條能追溯的證據管線。

• 來源層：Slack、Wiki、雲端文件、程式碼 repo、工單與內部資料庫。
• 索引層：把原文、摘要、metadata、全文索引與向量放進共同資料模型。
• 檢索層：精確字串、語意、稀有詞與時效各自找候選，再合併排序。
• 安全層：沿用來源權限、同步撤權與刪除、保留稽核紀錄。
• 回答層：只用已授權證據回答，附上可點回原始資料的引用；找不到就明說找不到。

如果你還不熟 RAG，可以先讀什麼是 RAG。本文往前走一步：不只解釋「檢索後生成」，而是教你把它變成可營運的內部系統。

拆解 Cerebras：企業 AI 知識庫的七層架構

第 1 層：資料留在原工具，connector 只負責同步

Cerebras 的第一個選擇很務實：不逼所有團隊搬到「唯一真相來源」。Slack 繼續是 Slack，程式碼留在 repo，文件與自訂資料庫也保留原本工作流；每個 connector 只需輸出共同的資料格式。這能減少導入阻力，也讓下游檢索不必替每個來源重寫一套邏輯。

「資料留在原工具」指工作流與權威來源不搬家，不是零複製。索引裡的 raw text、摘要、metadata 與 embedding 都是新副本，必須繼承原資料的 ACL（存取控制清單）、retention、刪除與加密要求。

第一版只接一個團隊的一個來源。接十種來源看似完整，實際上會同時遇到十套權限、刪除與版本問題，反而無法判斷檢索到底有沒有變好。

程式碼來源則不能只按固定字數亂切。Cerebras 表示部分內部 repo 超過 40 GB，採用 CocoIndex 依 class、method、較小 block 由粗到細切分，並在 commit 後只更新變動 chunk。CocoIndex 現行文件支持增量資料流的概念；但 Cerebras 沒有公開使用版本與完整設定，不能把今天的範例當成它的 production config。

第 2 層：事件接收、ACK、去重與完整重抓

以 Slack 為例，Cerebras 用 Socket Mode 接事件，立即 ACK，依穩定的 event ID 去重，接著重新抓取 parent 與所有 replies，把完整 thread upsert 回資料庫。實作時要分清兩個 ID：Socket Mode 回送的是外層 envelope_id ACK，去重則用內層 Events API payload 的 event_id。這比「每來一則回覆就嵌入一次」可靠，因為真正的問題與解法通常分散在整串對話。

Slack Socket Mode 文件說明它透過 WebSocket 收事件並回 ACK；Events API 文件則說明 event payload、HTTP Request URL 的快速 2xx 回覆與重送。兩種模式都不能假設 exactly-once：正式系統仍需 durable queue、retry、dead-letter queue 與週期性 reconciliation。

第 3 層：原文保留，另外蒸餾成可搜尋知識

Slack 對話充滿「收到」「我試試」「好了」等低資訊內容。Cerebras 先保存完整 transcript，讓錯誤碼與函式名仍能做全文搜尋；再讓 LLM 蒸餾出一行問題、短摘要、resolution、系統與程式碼參照，將這些結構化重點做 embedding。

同一作者連續訊息還可以合成 burst，並在前面補上 thread topic，避免「改成 4 就好了」離開上下文後失去意義。Cerebras 公開文提到 IDF（稀有詞權重）、字數與 reaction 等加權信號，但沒有公開完整權重與總門檻；它們是該公司的 heuristic，不是所有團隊都該照抄的標準答案。

第 4 層：共同 schema，讓所有來源進同一條管線

每筆知識至少要有穩定的來源 ID、chunk ID、原文、可搜尋文字、metadata、來源修改時間、權限版本與 embedding。Cerebras 描述以一張核心 PostgreSQL table 承載 embeddings、摘要與 metadata；這是共同介面的設計，不表示任何規模都只需要一張實體表，也不等於權限會自動正確。

第 5 層：混合檢索，不押寶單一分數

錯誤碼、flag、hostname、函式名適合全文搜尋；「checkpoint 在 NFS 上卡住」與「restore 讀 manifest 後不動」字面不同，卻可能指向同一個問題，適合向量搜尋。稀有詞 IDF 與時效信號再補上「這個 token 是否關鍵」「同樣相關時是否優先新資料」。真正穩健的起點是讓不同偵探各自找線索，而不是只相信 embedding。

第 6 層：RRF（倒數排名融合）、rerank，再補回鄰近上下文

不同檢索器的分數尺度不一樣，不能把 0.82 的向量相似度直接和全文分數相加。Cerebras 公開的流程使用 weighted Reciprocal Rank Fusion（RRF），依各清單的名次合併候選，再去重、限制單一檔案占比、取多樣化 top 20，交給小型 reranker 打 0–10 分，保留 top 10，最後才展開鄰近段落。

公開公式採 Σ weight / (60 + rank)，default weight 為 1；RRF 原始論文也使用 k=60。但 60 不是跨公司的最佳常數，0–10 也只是排序訊號，不是答案正確率。正確文件如果根本沒進 top 20，reranker 救不回來。

第 7 層：Planner 選工具，平行取證，最後才合成答案

Cerebras 把查詢拆成 planner → executor → evidence → synthesis。Planner 看問題與 project scope，決定要查 Slack、code、近期 PR 或專家；executor 平行執行工具，正規化結果；最後的 LLM 只負責用已取回證據生成答案、引用與 caveat。

同一批 retrieval primitives 也能透過 MCP（Model Context Protocol，模型與工具的共通介面）給其他 agent 使用。重點是工具要窄、輸出穩定、先回 raw evidence，而不是做一個神祕的「幫我回答一切」端點。這和AI Agent Harness的思路一致：模型負責判斷，系統負責權限、工具與可觀測性。

完整走一遍：一句故障問題如何變成可引用答案

假設工程師問：「為什麼 restore 在 manifest 載入後卡住？」一條合格的企業 AI 知識庫管線會這樣處理：

1. 先辨識查詢者：取得登入者、群組與目前 ACL version，建立可讀來源範圍。
2. Planner 選工具：這是技術故障，平行查 Slack thread、repo 的 ripgrep 與近期 PR；不必先掃所有 Wiki。
3. 全文搜尋抓精確線索：找到 manifest、restore、錯誤碼或設定 flag。
4. 向量搜尋抓換句話說：找到「checkpoint 在 NFS prefetch 時 stall」等字面不同但語意相近的紀錄。
5. RRF 合併候選：看名次共識，不硬比不同搜尋器的原始分數。
6. 權限重查與 rerank：未授權候選先移除，再讓 reranker 依原問題排序；低於相關門檻就拒答。
7. 補回上下文：帶回 thread 的 parent/replies、Wiki 鄰段或函式所屬 class，避免孤立 chunk 被誤解。
8. 生成可核對答案：例如「兩個證據都指向 NFS prefetch；PR #123 將預設值改為 4」，並逐句連回 Slack thread 與 PR。若證據互相衝突，就呈現版本與日期，而不是替讀者偷偷選一個。

這個例子顯示，答案品質取決於「證據是否找得到、是否有權看、是否仍有效」，模型口才只是最後一段。想更深入理解全文與向量為什麼互補，可接著看BM25、Embedding 與 Hybrid Search。

Hybrid Search 怎麼做？四位偵探先分頭找

你不必第一天就複製 Cerebras 的六路檢索。MVP 先做兩路就夠：PostgreSQL 全文搜尋加 pgvector 向量搜尋。把每路 top 20 交給 RRF，去除相同 source/chunk，再限制單一檔案最多占幾筆。等 golden set（固定驗收題庫）顯示真正缺口，再加時效、稀有詞或 source authority。

一個可起步的 PostgreSQL schema

下面的範例同時建立全文 GIN 與 HNSW。HNSW 是以可能犧牲部分召回率換取速度的近似向量索引；小資料集應先用 exact search 建立品質基準，再決定是否需要它。

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE knowledge_chunks (
  id                 bigserial PRIMARY KEY,
  tenant_id          uuid NOT NULL,
  source_type        text NOT NULL,
  source_id          text NOT NULL,
  chunk_id           text NOT NULL,
  source_uri         text NOT NULL,
  title              text NOT NULL DEFAULT '',
  locator            jsonb NOT NULL DEFAULT '{}',
  raw_text           text NOT NULL,
  search_text        text NOT NULL,
  metadata           jsonb NOT NULL DEFAULT '{}',
  allow_principals   text[] NOT NULL,
  deny_principals    text[] NOT NULL DEFAULT '{}',
  acl_version        bigint NOT NULL,
  source_modified_at timestamptz NOT NULL,
  embedding          vector(1536),
  search_tsv         tsvector GENERATED ALWAYS AS
    (to_tsvector('simple', title || ' ' || search_text)) STORED,
  UNIQUE (tenant_id, source_type, source_id, chunk_id)
);

CREATE INDEX knowledge_chunks_fts
  ON knowledge_chunks USING GIN (search_tsv);

CREATE INDEX knowledge_chunks_embedding_hnsw
  ON knowledge_chunks USING hnsw (embedding vector_cosine_ops);

vector(1536) 只是可建立標準 HNSW index 的示例，維度必須和你的 embedding 模型一致。這裡特別不能直接照 Cerebras 圖上的「3072-DIM + HNSW」，建立 vector(3072) 後就套用一般 HNSW index：截至本文查核日，pgvector 官方文件列出的 HNSW 索引上限是一般 vector 2,000 維、halfvec 4,000 維。vector(3072) 本身可以儲存並做 exact search；若要近似索引，可評估較低維模型、降維、half-precision／subvector 等索引策略。Cerebras 沒有公開欄位型別與索引細節，所以只能確認圖示，不能猜它用了 halfvec。

HNSW 是近似搜尋，授權條件必須放在 SQL／RLS，不能先取回未授權內容再由應用層過濾。pgvector 的近似掃描可能先形成候選、再套用 WHERE filter，效果是授權範圍內的 top-k 可能不足；這不構成放寬 ACL 的理由。上線前要用同一批查詢比較 exact scan 與 HNSW 的 Recall@k，需要時再調 ef_search、iterative scan、partial index 或 partition。權限計算採 deny 優先；ACL 映射缺失或未知時一律 fail closed。

全文欄位則用PostgreSQL GIN index。上例的 simple 只示範 tsvector 與 GIN 接線，不是中文斷詞方案；中文文件與查詢必須採相同斷詞流程，並用實際語料與專有詞驗證。

查詢流程的最小虛擬碼

def answer(query, request):
    principal = authenticated_principal(request)  # server-side identity
    scope = authorization_scope(principal)        # tenant + groups + ACL version

    lexical, dense = parallel(
        fts_search(query, scope=scope, top_k=20),
        vector_search(query, scope=scope, top_k=20),
    )

    candidates = reciprocal_rank_fusion(lexical, dense, k=60)
    candidates = dedupe_and_cap_per_source(candidates)
    candidates = recheck_acl(candidates, principal)  # before any LLM sees text

    ranked = rerank(query, candidates[:20])
    ranked = [x for x in ranked if x.relevance >= MIN_RELEVANCE]

    evidence = expand_neighbors(ranked[:10], scope=scope)
    evidence = recheck_acl(evidence, principal)    # defense in depth

    if not enough_supported_evidence(evidence):
        return abstain_with_missing_information()

    draft = synthesize_with_evidence_ids(query, evidence)  # no tools or credentials
    return render_verified_citations(draft, allowed_evidence=evidence)

這段刻意把權限檢查放兩次：候選進 reranker 前一次，補鄰段後再一次。引用 URL 也由 server 依允許的 evidence ID 組裝，不能信任模型或文件自行提供的連結。正式版還要加 timeout、retry、最小化並遮罩敏感內容的 query tracing，以及包含 tenant、authorization-scope hash、ACL version 的 cache key；撤權或刪除時必須失效。這段虛擬碼只界定責任邊界，不是可直接部署的完整程式。

兩週 MVP：先證明「找得到」，再追求「答得像人」

以下是單一團隊、單一來源的 retrieval prototype 示範排程，不代表兩週就能達到 production readiness；真正上線仍取決於來源權限、資料量、法遵與維運要求。

Day 1–2：鎖定範圍與 golden set

• 選一個高頻團隊，例如平台工程；只接一組 Slack channels 或一個 Wiki space。
• 整理 30–50 個真實問題，包含錯誤碼、換句話說、跨文件、無答案、過期版本與權限問題。
• 每題標出可接受文件、必要引用、可讀身分，以及應該拒答的條件。

Day 3–5：完成 ingestion 的生命週期

• 事件先持久化再處理，event ID 做 idempotency key。
• Thread 更新時重抓完整對話，晚到事件不得覆蓋較新版本。
• 修改、刪除與撤權都要能從 source ID 追到摘要、全文索引、向量、鄰段與快取。
• 每天做一次 reconciliation，找出 connector 與來源系統的落差。

Day 6–8：先做 lexical + dense + RRF

先比較 lexical only、dense exact、dense HNSW、hybrid RRF 四組結果。不要急著加 reranker；如果正確文件沒有進候選集，應先修 chunk、query、語言處理或權限 filter。RRF 權重也要用 golden set 調，不要把 Cerebras 的 default 當答案。

Day 9–10：加引用、拒答與 context expansion

讓每個 answer claim 指向原始 thread、文件段落或 commit。候選不足、來源衝突或時間失效時，回答應說明缺什麼，而不是硬湊。長 context 也不是免檢索通行證；Lost in the Middle 研究顯示，相關資訊落在長上下文中段時，模型表現可能下降。

Day 11–14：安全、評測，最後才開 MCP

MVP 先把 MCP 工具限制在 read-only retrieval，不開寄信、寫檔或執行程式等高影響動作。本文查核日（2026 年 8 月 9 日）的最新發布規格是 MCP 2026-07-28；規格中的 authorization 整體為 optional。若企業知識庫採 HTTP authorization，每個 request 都要帶 token，server 驗證 token 與 audience，再由應用層映射到最終使用者及來源 ACL。read-only 只降低寫入與執行的破壞面，不會阻止過寬檢索或資料外洩。

如果要把 planner、工具與驗收做成可重複的工程流程，可參考AI Agent Harness 實作指南；先有穩定 retrieval primitive，再讓 agent 組合它們。

真正容易出事的地方：ACL、刪除與 Prompt Injection

不能直接假設 Project 是權限邊界

Cerebras 用 Project把 Slack channels、repos、文件空間與資料庫組成命名集合，方便新使用者取得預設範圍；公開文章只概括提到 authentication、authorization、auditing 與 analytics，沒有交代不同來源的 ACL 如何逐筆映射。因此不能把 Project 直接假設成 ACL。自己的版本必須在檢索前依登入者做文件級授權；若 Project membership 也參與授權，仍要和每個來源 ACL 取交集，不能假設「bot 看得到，所有員工就看得到」。

若用 PostgreSQL Row-Level Security，要特別注意 table owner、superuser 與帶 BYPASSRLS 的角色可能繞過一般 policy；這是PostgreSQL RLS 文件明列的行為。正式查詢使用的 application role 不應是上述角色；若 owner 也要查詢，應評估 FORCE ROW LEVEL SECURITY，並用真實 runtime role 做負向測試。權限 filter 應在 reranker 與生成模型看到內容之前完成，title、snippet、命中數與 citation 也不能洩漏。

撤權與刪除是兩條流程

撤權的目標是「這個人現在查不到」；刪除則還要沿 source ID 清掉 raw text、summary、thread/burst/code embeddings、FTS、鄰段與各層 cache。穩健做法是先 tombstone、立即 fail closed，再由背景工作清除衍生物，並用唯一 canary 驗證 UI、MCP、全文、向量與快取在 SLA 後都沒有命中。

Embedding 不是加密，檢索內容也不是可信指令

向量與蒸餾摘要仍可能承載機密，應採用與原文件相同等級的權限、加密、網路隔離與 retention；OWASP Vector and Embedding Weaknesses也將未授權存取、資料外洩與跨情境風險列為重點。更重要的是，Slack、文件與程式碼都可能包含惡意指令；RAG 並不會消除間接 prompt injection。OWASP Prompt Injection 指南建議把外部內容視為不可信，落實 least privilege、輸入輸出過濾與人類批准。

對企業 AI 知識庫而言，這代表 distiller、reranker、planner 與最終回答都可能受污染。防線不能只是一句 system prompt，而要從架構上阻止不可信文字碰到敏感 token、跨越 ACL 或觸發高影響工具。可搭配AI 文件蠕蟲與 Prompt Injection 防禦建立紅隊案例。

企業 AI 知識庫怎麼評測？順序比單一分數重要

先問「正確證據有沒有進來」，再問「排序是否正確」，最後才問「答案寫得好不好」。建議固定保留以下儀表板，並依 exact、語意、跨來源、時效、無答案、ACL 與攻擊案例分開看：

• Retrieval Recall@20：正確文件是否進入 reranker 前的候選池。
• nDCG@10／MRR@10：重要證據是否排在前面，以及第一個正確結果有多快出現。
• HNSW 對 exact recall：近似索引換來多少速度，又遺失多少候選。
• Citation correctness：引用是否真的支持對應 claim，而不只是主題相似。
• Unsupported-claim rate：答案中沒有證據支持的敘述比例。
• No-answer false assertion：資料庫沒有答案時，模型是否仍硬答。
• Freshness：source modified 到 searchable 的 p50/p95，以及 stale-answer rate。
• ACL／delete gate：固定測試集中，未授權 artifact exposure、撤權與刪除 SLA 後殘留、敏感 canary 洩漏都必須是 0；這是該測試集的 release gate，不是宣稱全球零風險。
• 營運與價值：human／automation／agent 查詢分開計算，再看 human WAU（每週活躍人類使用者）、成功回答率、任務完成、升級人工搜尋率、p95 latency 與 cost/query。

Cerebras 公開文章沒有提供正式 benchmark、測試集、latency、cost 或安全紅隊結果，所以不能用每日 15,000 次查詢替代自己的 eval。你的 golden set 才是產品決策依據；模型評審可以協助擴大監控，但不能取代人工標註與 ACL canary。

最常見的 8 個問題

1. 已經有企業搜尋，還需要企業 AI 知識庫嗎？

看使用情境。如果大家只要找文件，優先改善既有搜尋；如果問題常需跨 Slack、code、PR 與文件組合證據，才值得增加 planner、reranker 與生成答案。不要為了聊天介面重建已經好用的搜尋。

2. 只用向量資料庫不行嗎？

通常不夠。向量擅長同義與換句話說，錯誤碼、函式名、flag 和 hostname 則常由 lexical search 找得更準。最小可用組合是全文 + 向量，再用 RRF 合併。

3. 一定要先用 LLM 蒸餾 Slack 嗎？

不一定。MVP 可先索引完整 thread 與全文，建立 baseline；只有當短回覆、雜訊或上下文缺失確實拉低 recall，再加入 summary、resolution 與 burst。蒸餾模型也會接觸完整對話，資料保留與供應商政策要一起評估。

4. Cerebras 的 IDF 4.0、200 字與 reaction 門檻能直接抄嗎？

不能當成通用門檻。公開文把它們描述為加權信號，沒有提供全部權重與最終 threshold。你的團隊語言、reaction 習慣與錯誤碼分布不同，應由 golden set 決定。

5. Project 能不能直接當 ACL？

不能直接拿來用。Project 適合限定 relevance scope；若要參與授權，必須明確強制 membership，並和來源的 user、group、inheritance、deny 與版本取交集。每次 UI、API、MCP 和 raw search 都要以最終使用者身分檢查。

6. Reranker 能消除幻覺嗎？

不能。它只能重排已取回候選，還可能判錯或受 prompt injection 影響。你仍需要 relevance threshold、no-answer、claim-level citations 與 unsupported-claim 評測。

7. 一開始就要接 MCP 嗎？

先不用。先把 retrieval API 的輸入、權限與 evidence schema 穩定下來；之後再把窄工具用 MCP 暴露給 agent。第一版只讀，避免把搜尋品質問題放大成寫入或執行風險。

8. 成功指標是不是每日查詢量？

查詢量只是其中一項。它混合人、automation 與 agent，也不代表答案有用。至少要搭配 unique human WAU、成功回答率、任務完成、人工升級率、citation correctness、延遲與成本。

最後帶走 7 個重點

1. 企業 AI 知識庫的核心不是模型，而是可追溯的證據管線。
2. 資料不必搬家，但 connector 必須處理事件去重、版本、刪除與對帳。
3. 保留原文做 lexical search，再把結構化重點做 embedding。
4. 全文與向量先分頭找，用 RRF 合併；reranker 只處理已取回候選。
5. Project 管 relevance，ACL 管安全，兩者不能混為一談。
6. 先驗 Retrieval Recall，再驗 citation 與回答；固定測試集的權限洩漏 gate 必須是 0。
7. MCP 放最後：先做窄、穩定、read-only 的 retrieval tools，再交給 agent 組合。

如果你今天就要開始，最有價值的動作不是選 embedding 模型，而是找一個團隊，寫下 30 個「我們每天真的在找」的問題，逐題標註答案、來源與誰有權看。當 lexical、dense、RRF 與 ACL 能穩定通過這組題目，你才真正擁有企業 AI 知識庫的第一塊地基。