Cerebras はいかにして
社内ナレッジベースを構築したか

Cerebras の社員は、社内ナレッジベースに毎日 15,000 件以上の質問を投げている。ローンチからわずか 3 ヶ月で、同社で最も広く使われる社内ツールのひとつになった。利用者は人間に限らない——自動化パイプラインや AI エージェントも、このナレッジベースを日常的に叩いている。

Cerebras のチームはデータセンター運用、チップ設計、ハードウェア、学習、推論、クラウドプラットフォームと極めて広い領域にまたがる。毎年数百人の新しい社員が加わる中で、コミュニケーションチャンネルは同じ質問で埋まりつつあった。

「X はどこにある？」
「Y の専門家は誰？」
「Z って何？」

Cerebras Knowledge は、人とシステムを有用な情報へつなぐために作られた。その全体像が図 1 である。データソース群から単一の埋め込みストア（pgvector・3072 次元・HNSW インデックス）へ、そして 6 系統の並列検索、RRF と LLM リランクによる融合、引用付きの回答合成へと積み上がる垂直スタックだ。

組織内の情報探索が難しいのは、データがツールに散らばっているからだ。そして四半期に一度くらいの頻度で、誰かが同じ「名案」を提案する——「全部を 1 つのプラットフォームに記録しよう。そうすれば情報は一箇所に集まる」。この Single Source of Truth の夢は、現実にはまず機能しない。

情報はそれを生むのに最も都合が良く、道具として手に馴染む場所で生成される。ドキュメントへの修正提案、Slack のスレッド、GitHub のコード参照、Jira のステータスメタデータ。各プラットフォームは長年のプロダクトエンジニアリングと分析によってそれぞれのドメインに最適化されている。プルリクエストの議論を Google Docs でやるのは悪夢でしかない。

そこで Cerebras は、既存の行動をほぼ変えなくてよいシステムを設計方針に据えた。データ収集側で言えば、各プラットフォームから直接データを抽出するということだ。

Cerebras Knowledge が提供するものは 3 つに整理できる。

① 収集と保存

社内データを集めて保存するプラットフォーム。

② クエリ

そのデータへ問い合わせるプラットフォーム。

③ 認証・認可

監査とアナリティクスを備えた、認証・認可を強制するレイヤー。

中核にあるのは単一の Postgres テーブルだ。多様なソース由来の埋め込み・生の要約・メタデータをすべてこの 1 テーブルが保持する。システムは全社からデータを継続的に取り込み、常にクエリ可能なデータストアを維持する。

データインターフェースは意図的にシンプルに保たれている。狙いは 2 つ——ほとんどの形式のデータを受け入れられること、そしてCerebras の他の開発者が自分でカスタムコネクタを書けること。Slack スレッドからネットリスト（チップ設計データ）まで、あらゆるソースが同じ埋め込みテーブルに着地し、テーブルに入ったものは即座に同じインターフェースで検索可能になる。

各データソースは「データが何であるか」「どう接続するか」「どの頻度で取得するか」を定義する。生成される埋め込み行は、出自が Slack でもコードリポジトリでもドキュメントシステムでもカスタム DB でも、まったく同じインターフェースに従う。

Slack は設計上最も重要なデータソースだった。全社を横断して、最も鮮度の高いエンジニアリング議論が交わされる場所だからだ。

非構造化された会話をどう処理するかHOW WE PROCESS UNSTRUCTURED SLACK CONVERSATIONS

チームはまず「生テキストへの素朴な埋め込み」で十分かをテストし、ベクトル検索単体では関連データを拾いきれないことをすぐに突き止めた。Slack メッセージには固有の難しさがある。

• 情報密度の振れ幅が極端に大きい。「はいよろしく」も、カーネルの詳細解説も、同じ 1 メッセージである。
• メッセージ長はまちまちで、コサイン類似度では短いメッセージが長く詳細なメッセージにしばしば勝ってしまう。
• メッセージの意味が前後の会話に依存することが多い。

必要なのはハイブリッドアプローチだった。Slack 取り込みは、すべてのスレッドが複数の検索技術から同時に到達可能になるよう設計されている。各技術は互いの弱点を補い合う。

全文検索

埋め込みがぼかしてしまう「正確なトークン」を捕まえる。エラー文字列、フラグ名、ホスト名。エンジニアがエラーメッセージをそのまま貼り付けたとき、字句の完全一致はほぼ常に最良の証拠であり、意味的類似度がそれを上回るべきではない。

埋め込み検索

言い換え（パラフレーズ）を捕まえる。「restore が manifest ロード後にハングする」と質問する人と、「checkpoint が NFS マウントで停止する」と答えた人は、語彙をまったく共有しないかもしれない。異なる言葉で書かれた質問と回答をつなぐのはベクトル類似度だ。

逆文書頻度（IDF）

シグナルとノイズを分離する。珍しい設定フラグのような希少トークンを軸にした短いメッセージは上位に来るべきだ。「いいね、ありがとう！」は埋め込み空間では多くのクエリの近くに位置するが、語の希少性を考慮すればスコアはほぼゼロになる。

時間減衰

「Slack の回答には賞味期限がある」ことをエンコードする。同じ質問に答える 2 つのスレッドがあるとき、6 ヶ月前のものはもう存在しないインフラを説明しているかもしれない。関連度が拮抗するなら、新しいスレッドが勝つ。

重要なのは、単一のスコアラーを信用しないという原則だ。各技術が同じコーパスに対してそれぞれのランキングを生成し、それらの「見え方」はクエリ時に融合される（SECTION 07 のリランキング参照）。

Socket Mode — リアルタイム取り込みSOCKET MODE

データをリアルタイムに収集するため、ワークスペースに Slack ボットをインストールし Socket Mode で稼働させている。Slack が永続 WebSocket 越しにすべてのメッセージイベントをプッシュしてくるため、Web API のポーリングでレート制限を浪費せずに済む。

イベント到着時は即座に ACK を返し、安定したイベント ID で重複排除し、取り込みコンシューマ向けにマークする。ここで面白いのは、取り込みコンシューマが新着メッセージを単体では保存しないことだ。メッセージが属するスレッドを解決し、親とすべての返信を含む会話全体を Slack API から再取得し、スレッド丸ごとを 1 行として書き戻す。既存スレッドへの返信は親と兄弟メッセージすべての再取得を引き起こすので、保存されたコンテンツ・参加者リスト・最終活動時刻は常に会話の完全な状態を反映する。

また、Slack チャンネルごとに独立したデータソースを持たせている。これによりデータ鮮度を細かくチューニングできる。たとえば多忙なインシデントチャンネルだけ取り込み頻度を上げる、といった運用が可能だ。

スレッドの蒸留THREADS AND MESSAGES — DISTILLATION

生の Slack テキストは、Postgres の全文検索（GIN）インデックスによって着地した瞬間からキーワード検索可能になる。しかし有用なベクトル検索のためには追加処理を行う。「蒸留（distillation）」と呼ばれる工程で、LLM がスレッド全体から構造化データを抽出する。

• エンジニアが実際に検索しそうな一行の質問文
• 短い要約
• 解決策（resolution）
• 言及されたシステムとコード参照

埋め込まれるのはこれらの抽出データであり、元のトランスクリプトは直接埋め込まれない。実験では、スレッドを一貫したフォーマットに正規化したとき精度が大きく向上した。付加されたメタデータはセマンティックマッチにもより有用なシグナルを与える。

バースト — 埋もれた重要メッセージの救出BURSTING

ここまでで Slack 検索は十分良くなったが、同じ問題に繰り返し遭遇した。長いスレッドの中の重要なメッセージが、スレッドレベルの要約に必ずしも反映されないのだ。

個々のメッセージのシグナルを増幅するために使うのがバースト（bursting）だ。バーストとは同一著者による連続したメッセージのまとまりのこと。バースト単位で、スレッドのトピックを文脈として先頭に付与した上で埋め込む（Anthropic の Contextual Retrieval の考え方 [02]）。答えが「スレッド要約に語彙が残らない 1 本の脱線メッセージ」に眠っていることがあるからで、バースト埋め込みはそのメッセージを単独で発見可能にする。

低シグナルなデータが DB に到達するのを防ぐため、各バーストは重み付きシグナルの組み合わせでスコアリングされ、閾値を超えたものだけが埋め込まれる。

• コーパス全体で相対的に希少なトークン（IDF 4.0 以上）を含む。
• 結合後のバーストが200 文字以上ある。
• バースト内の 1 つ以上のメッセージにリアクションが付いている（ソーシャルブースト）。

蒸留の後、基準を満たしたバーストは埋め込まれ、スレッドレベルのレコードと並んで同じ埋め込みテーブルに格納される。

当初、コードリポジトリの埋め込みが本当に必要かは社内でも議論があった。Claude Code のような CLI ツールの台頭で「grep があれば十分では？」という感覚があったからだ。しかし業界内の対話と、大規模コードベースでのセマンティック検索に関する Cursor の知見 [10] を読み、試すことを決めた。

Cerebras には多数の内部リポジトリがあり、中には 40 GB を超えるものもある。最大の懸念は「どう効率的に最新状態を保つか」だった。

CocoIndex による差分埋め込みUSING COCOINDEX TO MAINTAIN CODE EMBEDDINGS

数度の実験を経て採用したのが CocoIndex——コードベースのベクトル化に特化したオープンソースのドキュメント埋め込みフレームワークだ。

各リポジトリのコードは、粗→細の順に並べた言語別の正規表現境界で分割する。スプリッタはまずクラスのような高水準の境界を試し、チャンクがまだ大きすぎればメソッド境界、さらに小さいブロックへとフォールバックする。得られたチャンクを埋め込み、ベクトルを Postgres に書き込む。1 つのファイルからファイルレベル・関数レベルなど複数の粒度の埋め込みが生成されることもある。

CocoIndex は同期メタデータを Postgres で管理し、コミットごとに変更されたコードチャンクだけを再埋め込み・再エクスポートする。リポジトリ全体の再計算は不要だ。同期状態と埋め込みストアが同じデータベースに同居する構成は、Cerebras のスタックと特に相性が良かった。

コードベースの数が増えてからは、リポジトリのオンボーディングをチームが自分で提出できる設定ファイルに移行した。ファイルパスレベルの許可リスト・拒否リストもここに含まれる。

既に自前のデータベースを持つチームは、ナレッジベースに参加するためだけにデータを Slack やドキュメントシステムへ移したくはなかった。彼らが求めたのは、既存のテーブルの上に同じクエリ面が乗ることだ。

これを支えるのがプラグインスクリプト方式だ。チームは「自分たちのシステムからデータを読み、埋め込みテーブルと同じ形の行を出力する小さな Python モジュール」と、対応するデータソース定義をプルリクエストで提出する。

スクリプトが他のすべての埋め込み行と同じスキーマで共有データベースに書き込む限り、スタックの残りは一切変更なしで動く。そのデータは Slack・コード・ドキュメントと並んで検索可能になり、システムの他の場所に特別扱いのコードは存在しない。

プランニングとツールのファンアウトPLANNING AND TOOL FAN-OUT

すべてのクエリは、まず短いプランニングパスを通る。LLM が「どのツールとデータソースが効きそうか」を判断する工程だ。主要ツールは次の 6 つ。

subsystem_index

ファイル単位の LLM 要約。

search

Slack・Wiki・コードなど全インデックスを横断する統合ベクトルパイプライン。内部でマージとリランクまで行う。

search_slack

Slack への直接検索。

search_code

ソースリポジトリへの ripgrep。

recent_prs

質問に関連する最近のプルリクエスト。

who_knows

そのトピックについて実績のある専門家（人）を探す。

プランナーは「何がインデックスされているか」のコンパクトな記述——どんなプロジェクトがあり、各プロジェクトでどのソースが使え、各ソースが何に答えるのが得意か——の上で動く。ユーザーのクエリとアクティブなスコープを入力に、ツール選択を出力し、エグゼキュータがそれらを並列にファンアウトして共通のエビデンス形式に正規化し、最終合成 LLM へ渡す [04]。

リランキング — RRF と小型リランカーRERANKING

語彙がクエリと重なっているだけで、別の質問に答えている文書が上位に浮上してしまうことがある。リランキングの前段として、互換性のない各リトリーバーの結果リストを Reciprocal Rank Fusion（RRF）[03] で結合する。各文書について、出現したリストごとに weight / (60 + rank) を加算する（デフォルト weight は 1.0、平滑化定数は 60）。

平滑化定数の働きで、単独の強い一票よりも合意（コンセンサス）が重視される。複数のリトリーバーで上位に顔を出す文書は、どれか 1 つで 1 位を取っただけの文書に勝てる。その後、重複チャンクを 1 ソースにマージし、1 ファイルが提供できる結果数に上限を設け、多様性のある上位 20 件を得る。

元のクエリとこれらの候補を小型のリランカーモデルに送り、各文書に 0〜10 のスコアを付けさせ、上位 10 件を残す [06]。

ランキング確定後、勝者には文脈を復元する。たとえば Wiki のセクションがマッチしたら前後の隣接セクション（計 2 つ）を引き込み、チャンキングで切り離された見出し・前提条件・注意書きを失わないようにする。読者は「文脈を失った孤独な段落」ではなく、完結したスニペットを受け取れる。

つまり検索の出力は、異なるリトリーバーから融合され、ソースレベルで重複排除され、実際の質問に対してリランクされ、最後に周辺文脈まで展開された「証拠のパケット」である。

MCP 統合 — エージェントに委ねるMCP

MCP 統合では、検索の構成要素を「この質問に答えよ」という単一エンドポイントの裏に隠すのではなく、直接ツールとして公開する。これらのツールは意図的にシンプルで、可能な限り LLM を使わない。クライアントが速く・安く叩けるようにするためだ [05]。

各 MCP ツールは search_slack、search_code、search、who_knows といった検索プリミティブに 1 対 1 で対応する。入出力は狭く、構造化され、安定しているので、どんなクライアントやエージェントからでも、ツール内部にオーケストレーションロジックを埋め込むことなく呼び出せる。

ほとんどのツールはベクトル検索・字句検索・ripgrep のような 1 本のクエリパイプラインを実行し、軽量なスコアリングヒューリスティクスを適用して、生のエビデンス行を返す。

Claude Code をはじめとする MCP 対応エージェントが、オーケストレーションエンジンになる。どのツールをどの順に呼び、結果をどう最終回答やコード編集に組み立てるかはエージェントが決める。検索レイヤー自体はそうした LLM の判断に依存せずリクエストを捌ける。

Web UI — 同じツールをパイプラインで包むWEB UI

Web UI にも同じツール群が存在するが、こちらは全ユーザー質問に対して端から端まで走る完全なクエリパイプラインに接続されている。UI エージェントがプランナーとエグゼキュータを所有する。

PLANNER

軽量な LLM パスがクエリとアクティブなプロジェクトを検査し、呼び出す検索ツール（search、search_slack、subsystem_index など）を選ぶ。

EXECUTOR

ツール呼び出しを並列にファンアウトし、結果を収集して、スコア・鮮度・ソースヒント付きの共有エビデンススキーマに正規化する。

SYNTHESIS

最終 LLM パスが型付きエビデンスの束と元の質問を受け取り、引用・注意書き・ソース横断の統合を含む回答を生成する。

ユーザーから見れば Web UI は「質問すると答えが返る」だけの存在だ。しかし水面下では、MCP クライアントが明示的に再現できるのと同じ Planner → Executor → Synthesizer パターンが走っている。

コーパスが育つにつれ、「あらゆる場所のあらゆるものを検索する」は急速に役立たなくなった。コンパイラチームのエンジニアはインフラの運用手順書を検索結果に混ぜてほしくないし、逆もまた然り。デフォルトで検索を関連性の高いものにする仕組みがプロジェクトだ。

プロジェクトは、クエリが走るワークスペースを組織する第一の単位で、データソースの名前付きバンドルである。特定の Slack チャンネル、コードリポジトリ、内部データベース、ドキュメントスペースを、チームやイニシアチブ単位で束ねる。

プロジェクトは意図的に軽量だ。共有インシデントチャンネルや中央プラットフォームリポジトリのような同一のデータソースは、複製されるのではなく複数のプロジェクトから参照される。

オンボーディングとデフォルトONBOARDING AND DEFAULTS

オンボーディング時、ユーザーは自分の働き方に合ったデフォルトプロジェクト（ML 学習インフラ、コンパイラ、データセンター運用など）の選択または作成を促される。

デフォルトプロジェクトはユーザープロファイルに保存され、クエリを自動的にスコープする。新入りのエンジニアは、どの Slack チャンネル・リポジトリ・ドキュメントスペースが重要かを学ぶ前から、シグナルの高い回答を得られる。

結局のところ、このナレッジベースが機能しているのは、すべてを 1 つの硬直したシステムへ押し込む代わりに、情報が既に生きている場所へ出向いているからだ。複数の検索技術の組み合わせによって証拠を素早く提示できる。その結果は、現実の社内データに対して柔軟でありながら、Cerebras が成長し続けても有用であり続ける程度に構造化された検索体験である。

1. Malkov & Yashunin, Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs, arXiv:1603.09320 / IEEE TPAMI 2018.
2. Anthropic, Introducing Contextual Retrieval, 2024.
3. Cormack, Clarke & Büttcher, Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods, SIGIR 2009.
4. Li et al., Search-o1: Agentic Search-Enhanced Large Reasoning Models, arXiv:2501.05366, 2025.
5. Anthropic, Code Execution with MCP, 2025.
6. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, arXiv:2307.03172, 2023.
7. Anthropic, Use XML Tags.
8. Salesforce/Slack Engineering, How Slack AI Processes Billions of Messages.
9. Improving Agents, Best Nested Data Format.
10. Cursor, Improving Agent with Semantic Search, 2025.