資料を1か所に全部集める、なぜこれまで一度も成功しなかったのか

社内で資料を探すのが難しいのは、検索そのものが難しいからではなく、資料が生まれつき散らばっているからだ。四半期ごとに誰かが同じ「絶妙な案」を出す——今後すべての情報を1つのプラットフォームに記録し、唯一の真実の情報源にしよう、と。この構想は実践でほとんど成功したためしがない。

理由は、情報はどこで作るのが便利かによって生まれる場所が決まるからだ。ドキュメントの中の修正提案、Slack のスレッド、GitHub のコード参照、Jira のステータス欄。これらのプラットフォームはそれぞれの用途に何年もかけて磨き上げられてきた。Google Docs で pull request を議論するのは、体験としてかなりひどいものになる。

そのため Cerebras の最初の決断は、既存の習慣をほぼ変えさせないシステムを設計することだった。収集側のやり方は、各プラットフォームから直接データを抜き出すというものだ。

システム全体の核は、1枚のテーブル

このナレッジベースが外部に提供するのは3つ:社内データを置く場所、そのデータを検索する場所、そして認証・権限制御・監査・統計を担う層だ。

核となるのは Postgres の1テーブルで、そこにベクトル、元の要約、メタデータが出どころを問わず同居している。システムは社内各所のデータを継続的に流し込み、常に検索可能な状態を保つ。データインターフェースは意図的にシンプルに作られている。Slack のスレッドから来ようが、チップ設計で使うネットリストファイルから来ようが、同じベクトルテーブルに落ちる。このテーブルに入りさえすれば、同じインターフェースで検索できる。

各データソースが定義する必要があるのは3つだけ:これは何のデータか、どう接続するか、どのくらいの頻度で取得するか。取ってきて生成される各行は、フィールド構造がまったく同じだ。

この設計は他チーム向けの抜け道も用意している。すでに自前のデータベースを持っていて、ナレッジベースに入れるためだけに Slack やドキュメントシステムにデータを移したくないチームもある。その場合は、このソースをプラグインスクリプトとして扱う。チームが pull request を1本提出し、自分のシステムからデータを読んでそのテーブル構造に合う行を吐き出す小さな Python モジュールを用意し、データソースのレコードを1件設定する。同じライブラリに書き込み、同じフィールドセットを使う限り、残りの全パイプラインは1行も変更する必要がない。

Slack で一番難しいのは、どの発言が有用か見分けること

Slack は彼らが最も重視し、かつ最も扱いにくいデータソースだ。社内の最新のエンジニアリング議論はそこで行われる。最初は最も手軽な方法を試した——元のテキストをそのままベクトル化して検索する。だがすぐに、ベクトルだけでは網羅できないことがわかった。

問題はチャット履歴自体が持つ3つの特徴から来ていた。第一に、情報密度の差が極端に大きい。「了解、ありがとう」と、カーネル実装を丸ごと説明する長文が、システムの目にはどちらも「1件のメッセージ」にしか見えない。第二に、メッセージの長さがまちまちで、短いメッセージがベクトル類似度でしばしば長く詳細なメッセージを上回ってしまう。第三に、あるメッセージの意味は前後の会話に依存することが多い。

彼らの解決策は、同じコンテンツを複数の検索方式で同時にカバーし、それぞれが他の弱点を補うというものだ。同じクエリ、同じ4件の候補で、スコアリング方式を切り替えると、誰が上がり誰が下がるかが毎回変わる(データは原文の例による)。

チャット履歴はそのままベクトル化しない

元の Slack テキストは、そのまま置くだけでキーワード検索できる。Postgres 上で元テキストに全文インデックスを維持しているからだ。しかしベクトル検索を本当に使えるものにするには、もう一段の加工が必要だった。

この工程を蒸留と呼ぶ。モデルにスレッド全体を読ませ、4つのものを抽出させる——エンジニアが実際に検索しそうな一言の質問文、簡潔な要約、最終的な結論、そして過程で言及されたシステムとコードシンボルだ。ベクトル化されるのはこの4つであり、逐語のチャット記録そのものはベクトルデータベースに入らない。実測では、スレッドを統一フォーマットに正規化することで精度がはっきり向上し、追加されたメタデータが意味的マッチングにより多くの手がかりを与えている。

長いスレッドの中で、要約に漏れてしまうメッセージ

ここまでで Slack の検索はすでに使えるものになっていたが、彼らは繰り返し同じ問題にぶつかった。長いスレッドの中の重要なメッセージが、スレッド全体の要約に必ずしも痕跡を残すとは限らないのだ。

この対策が bursting と呼ばれる手法だ。バーストとは、同じ人が連続して投稿した複数のメッセージのことを指す。彼らは各バーストを個別にベクトル化し、その前にスレッド全体の話題をコンテキストとして付加する。こうすることで、答えが脱線した枝分かれの中に埋もれていて、使われている単語がスレッド全体の要約に一度も出てこないようなケースでも、単独で検索できるようになる。

低価値なコンテンツがデータベースに大量に流れ込まないよう、各バーストは加重スコアリングを通過して初めてベクトル化される。判定基準は3つ:全社的なコーパスの中で十分珍しい単語を含んでいること(希少度のしきい値は IDF 4.0以上)、統合後に最低200文字あること、そのバースト内のメッセージに同僚からの絵文字リアクションが付いていること(これは同僚からの承認とみなされる)。

40GBのコードリポジトリを、どうやって最新に保つか

コードリポジトリをベクトル化すべきかどうか、彼らは最初ためらっていた。Claude Code のようなコマンドラインツールが登場した今、コード用のベクトルインデックスを作るのは少し直感に反するように見える——grep があれば十分ではないかと感じてしまう。同業者と話し、大規模コードベースの意味検索についての Cursor の知見を読んだうえで、彼らは試してみることにした。

本当の懸念は別のところにあった。社内のリポジトリは数が多く、1つで40GBを超えるものもある。それを許容できるコストで常に最新のインデックスに保つにはどうすればよいか、という点だ。

最終的に落ち着いたのは CocoIndex という、コードリポジトリのベクトル化専用に作られたオープンソースフレームワークだ。チャンク分割のルールは言語の構文境界に従い、粗いものから細かいものへと順に試す。まずクラスのような上位の境界を試し、切り出したチャンクがまだ大きすぎればメソッド境界まで下がり、それでもだめならさらに小さなコードブロックまで下がる。同じファイルからこうして複数の粒度のベクトルが生まれる。たとえばファイル単位で1本、関数単位でそれぞれ1本ずつといった具合だ。

原文のチャンク分割例、表記は英語。左側のコードで薄い色の背景が付いている箇所が識別された意味的チャンクで、行末の注釈には各チャンクが何段階目で切り出されたかが書かれている——まず class を試し、LoadManifest()、WarmShardCache()、Restore() の3つのメソッドまで進み、メソッド内がまだ大きい場合は if や for のレベルまで下げる。末尾のプライベートフィールド領域は単独のチャンクになる。右側の2つのボックスは上の対照表にある2つの分割方式(01 NAIVE WINDOWS:Nトークンごとに機械的に切る、02 LANGUAGE-AWARE:構文境界による分割。図で選択されているのは後者)。下部の凡例では SEMANTIC NODE は意味的チャンク、FIXED SPLIT は固定長の切れ目を指す。出典:Cerebras

更新面はこの方式が本当に手間を省いてくれるところだ。CocoIndex は同期用のメタデータも Postgres に保存しており、コミットのたびに変更のあったコードチャンクだけを作り直せばよく、リポジトリ全体を再計算する必要がない。同期状態とベクトルが同じデータベースに保存されている点は、彼らにとって特に都合が良かった。

接続するコードリポジトリが増えるにつれ、リポジトリ接続そのものが設定ファイルとして扱われるようになり、各チームが自分で提出できるようになった。ファイルパス単位でホワイトリストとブラックリストを設定することもできる。

質問が来たあと、システムは何をしているのか

質問を受け取るたびに、システムはまず短いプランニングを1回走らせる。モデルがこの質問にどのツール、どのデータソースが必要そうかを判断し、選ばれたツールを並行して発行する。

MCP 側では、ツールを直接 Agent に渡して自分で組み立てさせる

Web インターフェースでは、上記のパイプラインはエンドツーエンドで実行される。プランニングがツールを選び、実行層が並行して証拠を取得してスコア・時刻・出典のヒント付きの統一された証拠に正規化し、最後のモデルのパスがそれに基づいて引用と注意事項付きの回答を生成する。利用者から見れば、質問して回答を受け取るだけだ。

MCP 統合はこれと逆のアプローチを取っている。検索機能を「この質問に答えて」という1つの大きなインターフェースの裏に隠すのではなく、1つずつ直接呼び出せるツールとしてバラして公開する。これらのツールは意図的にシンプルに作られており、できるだけモデルを介在させない。そのためクライアント側は速く、安価に検索できる。各 MCP ツールは最も基本的な検索動作1つに対応しており、入出力は狭く、構造化されていて、安定している。どんなクライアントや Agent でも直接呼び出せる。ほとんどのツールは1本のクエリ経路だけを実行する——意味で検索する、文字面で検索する、あるいは直接 ripgrep を実行する——その上に軽量なスコアリングを1層かけて、元の証拠行を返す。

こうすることで、組み立てる作業は Claude Code のような MCP 対応の Agent に任せられる。どのツールをどの順序で呼ぶか、結果をどう最終的な回答や1回のコード修正にまとめるかは、Agent 自身が判断する。検索層はこれらのモデル判断に依存しなくても、通常どおりサービスを提供できる。

6本のランキングを、どう1本に合成するか

ある文書が最上位に来るのは、単に検索語と文字面がたまたま一致しただけで、実際には別のことに答えているだけかもしれない。さらに厄介なのは、6つの検索器が出すスコアが互いに直接比較できないことだ。ベクトルのコサイン類似度と全文検索の関連度は、まったく違う物差しだ。

彼らのやり方は、まずスコアを見ず、順位だけを見ることだ。このアルゴリズムは Reciprocal Rank Fusion(RRF、逆順位融合)と呼ばれる。ある文書が1本のランキングに載るたびにスコアを加算する。加算量は「1 割る(60 足す そのランキングでの順位)」で、重みはデフォルトで1.0、60というのは平滑化定数だ。

総合ランキング1位を計算してみると、この仕組みがはっきり見えてくる。CLASS: CheckpointLoader は6本のランキングのうち5本に入り、順位はそれぞれ1位、2位、3位、5位、5位だ。

合成後にもう3つの工程がある

融合して出てきたランキングは、そのまま回答の生成には送られない。次にまず同じ出典から分割されて重複しているチャンクを1つに統合し、続いて1ファイルが貢献できる結果数に上限を設けて、より分散した上位20件を得る。この20件は元の質問文とともに小型のリランクモデルに渡され、各件に0〜10点のスコアを付けて上位10件を残す。

順位が決まったあと、コンテキストを補い戻す。たとえばヒットしたのが Wiki のあるセクションだった場合、その前後2セクションも一緒に引っ張ってくる。チャンク分割で見出しや前提条件、注意事項が分断されて失われるのを防ぐためだ。こうすることで、読者の手元に届くのは前提を欠いた孤立した断片ではなく、完全な形の引用になる。

この一連の工程を経て、検索ステップが引き渡すのは1パックの証拠だ——異なる検索器から集まり、融合を経て、出典レベルで重複排除され、実際の質問に対してリランクされ、最後に周辺の文脈が付け加えられたものになっている。

全社検索すると、逆に役立つものが見つからなくなる

コーパスが大きくなっていくにつれ、「なんでも検索する」というやり方はすぐに使いづらくなった。コンパイラを作っているエンジニアは、結果の中にデータセンター運用マニュアルが出てきてほしくないし、その逆も同じだ。

彼らはこれを解決するために project という層を導入した。project とは、データソースを名前付きでまとめたグループのことだ——指定した複数の Slack チャンネル、複数のコードリポジトリ、複数の社内データベース、複数のドキュメントスペースを、あるチームやあるプロジェクトグループを中心に構成する。project は意図的に軽量に作られている。同じデータソース、たとえば全社共通の障害対応チャンネルや中央プラットフォームのリポジトリは、複製することなく複数の project から同時に参照できる。

新人が入社すると、自分の仕事に最も近いデフォルトの project を1つ選ぶか作るよう案内される。たとえばトレーニング基盤、コンパイラ、データセンター運用といった具合だ。このデフォルト値はユーザープロファイルに保存され、以降のすべてのクエリが自動的にこの範囲に限定される。効果として、新しく入ったエンジニアはどの Slack チャンネル、どのリポジトリ、どのドキュメントスペースが自分に関係あるのかを先に調べる時間をかける必要がなくなり、最初から関連性のある結果が手に入る。

このナレッジベースが機能しているのは、情報が本来あった場所でそのまま人を受け止めているからであり、すべてを1つの硬直したシステムに詰め込んでいるからではない。 Cerebras、『How we built our knowledge base』

原文に登場した具体的な数字

Cerebras の最初の決断は方向転換だった。誰にも物を書く習慣を変えさせず、代わりに各プラットフォーム向けにデータ取得プログラムを1本ずつ用意し、取ってきたものを統一フォーマットにして、すべて同じデータテーブルに落とす。公開から3か月、1日15000件超の質問をさばいており、質問者には社員だけでなく自動化スクリプトや Agent も含まれる。

同じテーブルに落とすことの利点は、新しいデータソースを1つ追加してもクエリ側は一切変更不要な点だ。だが新たな悩みがすぐにやってくる。Slack は最も手強いソースで、「了解、ありがとう」とカーネル実装を丸ごと説明する長文が、システムの目にはどちらも「1件のメッセージ」にしか見えない。どうやってどの発言が有用かを見分けるのか?

彼らの答えは、どの物差しにも頼らないことだった。同じ候補集合に対して4種のスコアリングを同時にかけ、それぞれの盲点を補い合う。下の図は、小互(筆者)の実際の質問1件をたどっている。彼はグループチャットで「マニフェスト読み込み後に復元が止まる」と質問し、データベースには4件の候補がある。4つの物差しがそれぞれ誰を押し上げ、誰を押し下げるかを見てみよう。

「検索精度が向上した」という言い方には実感が湧かない。同じ具体的な出来事に置き換えてみよう——新人がトレーニングクラスタを引き継ぎ、復元が止まる問題に遭遇して「CKPT_PREFETCH=4 に設定する」という答えにたどり着くまで、3つのやり方でそれぞれどれくらいかかるか。