Cerebras 社内ナレッジベース — 統一 embeddings テーブル × ハイブリッド検索 × エージェント問い合わせ¶

作成日: 2026-08-08 出典 / きっかけ: Cerebras 公式ブログ "How We Built Our Knowledge Base"（2026-07-18 公開）関連: rag_hybrid_search_bm25_embedding_rrf_整理 / rag_dense_bm25_splade_rrf_jmteb検証_整理 / vectordb_recommendation_整理 / エアークローゼット_agentic_graph_rag_と社内mcp基盤_整理 / メルカリ_socrates_データ基盤とマルチエージェント_整理

0. 要点（3行）¶

中身は「1枚の Postgres テーブルに全社の知識を embeddings で寄せる」だけ — Slack・コード・Wiki・DB・障害報告を元の場所に置いたまま、document / embedding / metadata という共通スキーマの1テーブルに流し込む。ソースが増えてもクエリ側はほぼ不変、という一点突破の設計。
効くのは「ベクトル1本足」をやめたこと — 全文検索・embedding・IDF（希少語重み）・時間減衰の4信号を RRF（定数60）で順位合議。エラー文字列やフラグ名の完全一致も、言い換え質問の意味一致も、両方拾える。
問い合わせは Planner→Executor→Synthesizer のエージェントで、検索プリミティブを MCP ツールとして素で公開。結果、公開3ヶ月で 1日15,000+ 質問を人・自動化・エージェントがさばく規模に。

1. なぜ作ったか — 「データを1箇所に集める」を諦めた¶

社内の知識は Slack スレッド、GitHub のコード、Wiki、独自 DB、障害レポートにバラバラに存在する。よくある失敗は「全部を1つのシステムに移して統一しよう」とすること。Cerebras の判断は逆で、

データは元の場所に置いたまま、その上に統一された検索・取得レイヤだけを載せる。

「情報が既に住んでいる場所に会いに行く（meets people where the information already lives）」という思想。移行プロジェクトを起こさず、各ソースにコネクタを書いて共通テーブルに吐かせる方式にした。

2. 中核 — 統一 embeddings テーブル（1枚の Postgres テーブル）¶

全ソースを同一スキーマの単一 Postgres テーブルに正規化するのが設計の心臓部。

カラム	中身
`document`	埋め込み対象になる正規化済みテキスト（生データそのままではない）
`embedding`	ベクトル
`metadata`	ソース名・タイムスタンプ等（`source name`, `timestamp` ほか）

この1テーブルに入ったものは、即座に同じインターフェースでクエリ可能になる。
新ソース追加＝「コネクタを書いて共通スキーマの行を吐く」だけ。クエリ側のコードは基本さわらない（拡張の摩擦を極小化）。
各データソースは「何のデータか / どう接続するか / どの頻度で取得するか」を定義する。他部門の開発者がカスタムコネクタを自作できることも要件だった。

※ ベクトル格納は Postgres 単一テーブル、と本文にある。実装拡張（pgvector 等）の明記は取得できた抜粋では未確認。

[Slack] [GitHub] [Wiki] [独自DB] [障害報告]
   │       │       │       │        │      ← 元の場所に置いたまま
   ▼       ▼       ▼       ▼        ▼
 コネクタ / プラグイン（fetch頻度・接続・正規化を各自定義）
   └───────────────┬───────────────┘
                   ▼
   ┌─────────────────────────────────────┐
   │  単一 Postgres テーブル               │
   │  document | embedding | metadata      │  ← ここに入れば即クエリ可能
   └─────────────────────────────────────┘
                   ▲
                   │ 同一インターフェースで検索

3. ソース別の作り込み — 「そのまま埋めない」¶

生データを素で embedding しないのがポイント。ソースごとに前処理で質を作ってから入れる。

3-1. Slack — 「薄い雑談」と「濃い技術」を分離する¶

生メッセージはそのまま埋めない（浅い雑談と技術情報が混ざり品質が悪化するため）。
スレッド単位で LLM 要約し、question / summary / resolution / related systems / code references を持つ正規化ドキュメントにしてから埋め込む。
"Burst"（バースト） = スレッドに埋もれた重要な連続メッセージ列を個別に抽出する概念。抽出条件は:
希少トークンを含む（高 IDF、最低 IDF 4.0）
200文字以上
リアクションが付いている
スレッド要約と burst の両方を統一テーブルに格納。

3-2. コード — 全文検索＋意味検索の二段¶

まず ripgrep による高速テキスト検索。
それを CocoIndex（OSS） による意味検索で補完。
CocoIndex = Apache-2.0 の増分インデックス基盤（Rust コア＋Python SDK）。変更 delta だけ再処理し、full re-embed を避ける（cocoindex.io）。
言語別の正規表現で class → function → より小さいブロック の階層にチャンク分割。
40GB+ のリポジトリを、コミット単位で変更分だけ差分同期（差分インデックス）。

3-3. 独自データソース — プラグイン方式¶

社内 DB を読み、共通 embeddings スキーマに合う行を emit する Python モジュールとして実装。チームが自分の proprietary システムを自力で繋げられる。

4. 検索 — ベクトル1本足をやめ、4信号を RRF 合議¶

ハイブリッド検索が肝。単一のベクトル類似度に頼らず、4つの信号を混ぜる。

信号	何を拾うか
全文検索（full-text）	エラー文字列・フラグ名・ホスト名などの完全一致
embedding 検索	言い換え・パラフレーズ質問の意味一致
IDF（逆文書頻度）	一般的な埋め草より希少トークンを優先
時間減衰（age decay）	古くなったインフラ解決策を下げる

これらを RRF（Reciprocal Rank Fusion） で統合。平滑化定数 = 60。

「a single strong vote」より「consensus（多数の合議）」を効かせるための順位ベース融合。点数（スコア絶対値）を信じず、順位で多数決するのが RRF の本質。cf. rag_hybrid_search_bm25_embedding_rrf_整理。

query
  ├─ full-text  → ランキングA
  ├─ embedding  → ランキングB
  ├─ IDF 重み   → ランキングC
  └─ age decay  → ランキングD
        └──→ RRF (k=60) で順位合議 →  上位エビデンス行

5. 問い合わせパイプライン — Planner → Executor → Synthesizer¶

エージェント型の3段構成。

Planner（小型 LLM）: 質問に対し、どのツールを使うかを決める。
Executor: ツールを並列実行し、結果を「evidence row（エビデンス行）」に正規化する。
Synthesizer（最終 LLM）: 回答・引用（citations）・ソース横断の要約を生成する。

MCP ツールとして検索プリミティブを公開¶

「回答を返す1つの巨大エンドポイント」ではなく、低レベルの検索プリミティブを個別ツールとして MCP で公開。オーケストレーションはクライアント側に委ねる（人・自動化・他エージェントが自由に組める）。公開ツール:

ツール	役割
`subsystem_index`	サブシステムの索引
`search`	汎用検索
`search_slack`	Slack 検索
`search_code`	コード検索
`recent_prs`	直近の PR
`who_knows`	あるトピックに実績で詳しい人を特定（有識者探索）

6. スコープ制御 — 「Project」でノイズを絞る¶

検索ノイズ対策として "Project" 単位を導入。Project = 関連する Slack チャンネル・リポ・DB・ドキュメントを束ねた「名前付きの束」（例: ML Training / Compiler / Data Center Operations）。
「Projects are how we make search relevant by default」。新入社員はオンボーディングで自分の業務領域の default project を選ぶと、クエリが自動的にその範囲へスコープされる。

7. 規模・成果¶

公開（2026-07-18）時点で、ローンチから3ヶ月。
1日あたり 15,000 件超の質問を処理。人間・自動化・エージェントが横断的に利用。

8. まとめ — いつこの設計を真似るか¶

状況	この設計から借りる手
社内知識が Slack/コード/Wiki/DB に散在	移行せず、共通スキーマの単一テーブル＋各ソースにコネクタ
生データの品質がバラつく（特にチャット）	LLM で正規化ドキュメント化してから埋める（Slack のスレッド要約＋burst 抽出）
完全一致も意味一致も両方欲しい	全文＋embedding＋IDF＋時間減衰を RRF（k=60）で合議
コード検索を意味レベルに上げたい	ripgrep ＋ CocoIndex で言語別階層チャンク＋差分同期
検索結果がノイジー	Project（データソースの束）でデフォルト・スコープ
検索を人にもエージェントにも開放したい	検索プリミティブを MCP ツールで公開し、統合はクライアント側 Planner→Executor→Synthesizer

一言で: 「凝った統合基盤」ではなく「全部を1テーブルに寄せ、検索だけ賢くする」。統合の複雑さをデータ移行ではなく前処理と検索合議に振ったのが勘所。

参考リンク¶

原典: Cerebras "How We Built Our Knowledge Base"（2026-07-18） — https://www.cerebras.ai/blog/how-we-built-our-knowledge-base ※直アクセスは 500/402 になりやすい
X 記事版 — https://x.com/cerebras/article/2077822555159945507
Thread Navigator ミラー — https://threadnavigator.com/thread/2077822555159945507/
kun432 氏の日本語メモ（Zenn scrap） — https://zenn.dev/kun432/scraps/a207c3f2cc7f5c
CocoIndex（OSS・Apache-2.0 の増分インデックス基盤） — https://cocoindex.io/ / https://github.com/cocoindex-io

作成: 2026-08-08 ／最終更新: 2026-08-08