11 ssot-search v2 — RAG検索の仕組みと精度改善
4,000文書の知識ベースから「あの話、どこに書いてたっけ？」を1発で見つける仕組み
RAGとは — 「覚えている」のではなく「探してくる」
RAG（ラグ・Retrieval-Augmented Generation）は、LLMに質問する前に「関連する資料を検索して文脈として渡す」構成の総称です。
本プロジェクト（ssot-search v2）では答えの「生成」は行わず、検索に特化しています。つまり SSOT 全体から「目的の知識が書かれた断片」を1発で見つけ出す検索エンジンです。LLMの記憶に頼らず、自分の記録から根拠を引いてくるのが目的です。
💡 一言でいうと: 4,000冊のノートの中から「あの話、どのページ？」と聞くと、10回中7〜8回は関連ページ5枚以内で見つけてくれる助手、です。
検索パイプラインの4工程
| 工程 | やったこと | 例え |
|---|---|---|
| ① チャンキング | 4,021個のMarkdown文書を、意味のまとまりごとに24,010断片へ分割 | 厚い辞書を見出しのカード1枚ずつに切り分ける |
| ② 埋め込みモデル選定 | 日本語特化の ruri-v3-130m を公開ベンチマーク（JMTEB）比較のうえ選定 | 翻訳者を雇うとき「日本語が得意な人」を試験成績で選ぶ |
| ③ ベクトルDB構築 | 各断片を「意味の座標（ベクトル）」に変換し ChromaDB に格納。意味が近い文ほど近い座標になる | 図書館の本を「内容が似ている順に棚に並べ直す」 |
| ④ 差分更新（30分毎） | auto-sync（30分毎の自動バックアップ）と連動し、変更のあった断片だけを再索引。全量再構築は不要 | 辞書を作り直さず、改訂ページだけ差し替える |
「検索したい文」も同じ座標系に変換して、近い座標の断片を取り出すのが意味検索です。「ファイル名やキーワードが一致」しなくても、書いている内容が近ければ見つかります。
精度を測る — 39問のテストセット
「検索が賢くなった気がする」で終わらせず、試験を先に用意して数字で測定しました。
- 採点基準の事前固定: 測定指標（Recall@5 / Recall@10 / MRR@10 / 根拠文表示率@5）を、評価実行の前にファイルとして確定（commit）。結果を見てから基準を変える余地を構造的に排除
- 合成Q&A 26問: 記録から抽出した文書をもとに、別のLLM（MiniMax M3）に質問文を生成させた（問題を作った本人が解く自己バイアスの回避）
- 「答えを知らない問い」13問: 細部事実（日付・件数・設定値）を問う問題。正解（番号と文書の対応）はスクリプト内部に閉じ、測定する側は実行まで正解一覧を見ない（ブラインド担保）
- ハルシネーション検査: 生成された回答キーワードが、出題元の文書本文に実在するかを機械検証（棄却0件）
結果 — Recall@5 0.026 → 0.744
| 検索方式 | Recall@5 | Recall@10 | MRR@10 |
|---|---|---|---|
| v1（キーワード一致） | 0.026 | 0.077 | 0.014 |
| v2（意味検索） | 0.744 | 0.744 | 0.547 |
| RRF統合（v1+v2の併合） | 0.718 | 0.744 | 0.391 |
Recall@5 は「正しい答えが書かれた断片が、検索上位5件に入る割合」です。旧検索（キーワード一致）は **2.6%**＝100問中2〜3問しか当たらない状態で、v2（意味検索）で **74.4%**＝10問中7〜8問で上位5件に正解が来るまで改善しました。
正直な負けも記録しています。v1とv2を併合するRRF統合は、Recall@10ではv2と同率（上位10件に入る正解を1つも落とさない）だった一方、順位精度（MRR@10）は0.391に低下。レビューで期待された「統合が両者を超える」は未達です。評価後のパラメータ調整は**ベンチ過学習（テストにだけ強くなること）**を招くため実施せず、未達のまま記録に残しています。改善は採点基準を変えずに次回再測定で行います。
⚠ 評価の誠実性の話です。数字を良く見せるためにテストを削ったり基準を変えたりすると、測定の意味がなくなります。「未達」という結果をそのまま残すこと自体が、この評価の信頼性の証明です。
どう使うか
Claude Code セッション内で /ssot-search スキルを呼ぶと、SSOT 全文書を意味検索できます。日常の「過去の決定を探す」「あの設定どこだっけ」が、ファイル名を思い出さずに引けます。
- 検索コマンドの使い方・スキル連携: 03 Claude Code統合
- 全体マップ（mindmap）: トップ
設計の教訓
- 測る前に試験を固定する — 結果を見てからの基準変更は、測定ではなく作文になる
- 問題を作った本人に解かせない — 問題生成と評価対象を別系統（別LLM・ブラインド）に分ける
- 負けも記録する — 「統合すれば良くなるはず」が外れた事実は、次の改善の最も確実な手がかりになる