――SOMの歴史が示す「最初の教科書」の罠
生成AIを社内文書に接続する方法として、RAG（Retrieval-Augmented Generation）が広く知られるようになった。
一般に説明されているRAGの仕組みは、驚くほど単純である。
- 文書を短いチャンクに分割する
- 各チャンクを埋め込みベクトルに変換する
- ユーザーの質問もベクトル化する
- 質問に近いチャンクを上位から取得する
- 取得したチャンクをLLMに渡して回答させる
LangChainの公式入門も、文書、テキスト分割、埋め込み、ベクトルストア、Retrieverをセマンティック検索の基本構成として説明している。RAG研究の代表的なサーベイでも、この「文書をチャンク化し、ベクトルDBに保存し、質問との類似度で上位のチャンクを取得する」方式は、明確にNaive RAGと分類されている。
問題は、この方式が入門用の基本モデルとして紹介されていることではない。
入門用のモデルが、あたかもRAGの完成形であるかのように受け止められていることである。
質問と回答文を直接比較する不自然さ
そもそも、ユーザーが入力する質問文と、文書に記載されている回答文は、言語的に異なる形式を持っている。
例えば、契約書に次のように書かれているとする。
契約期間満了日の30日前までに書面による通知がない場合、契約は自動的に更新される。
利用者はこれを、次のように質問するかもしれない。
自動更新を止めるには、いつまでに連絡すればよいですか。
二つの文章は同じ内容に関係しているが、表現も構文も語彙も違う。片方は規則を記述した文章であり、もう片方は利用者の意図を表した質問である。
Naive RAGは、この異なる形式の文章を直接ベクトル空間で比較し、「意味が近いはずだ」と期待する。
もちろん、高性能な埋め込みモデルであれば一定程度は対応できる。しかし、文書が増え、似た表現を含むチャンクが増えれば、正しいチャンクが上位数件から外れることがある。RAGの代表的なサーベイでも、Naive RAGには、関連しないチャンクの取得、必要情報の取りこぼし、取得情報に根拠を持たない回答などの問題があると整理されている。
そこで現場では、
- チャンクサイズを変える
- オーバーラップを増やす
- 取得件数を増やす
- キーワード検索を併用する
- 再ランキングを加える
- プロンプトを調整する
といった改良が繰り返される。
しかし、これは根本構造を変えずに、検索精度を調整しているだけである。
文書ではなく「回答可能な質問」を索引にする
より自然なのは、元文書からあらかじめ、
この文章は、どのような質問に答えることができるか
を生成しておくことである。
先ほどの契約条項からなら、次のような質問パターンを作れる。
- 契約を終了するには、いつまでに通知する必要がありますか
- 自動更新を停止する方法を教えてください
- 更新を希望しない場合の通知期限は何日前ですか
- 連絡しなければ契約は自動的に更新されますか
ユーザーの入力は、元の契約条文よりも、これらの質問パターンに近い。
したがって、検索構造は次のように変えられる。
一般的なRAG
ユーザーの質問
↓
文書チャンクとの直接比較
↓
元テキスト質問パターン方式
ユーザーの質問
↓
生成済みの質問パターンと比較
↓
対応するWikiページを特定
↓
元テキスト
↓
根拠に基づく回答重要なのは、生成された質問パターンを最終回答の根拠にしないことである。
質問パターンは、あくまで適切な元テキストへ到達するためのルーターである。最終的な回答は元文書を参照して生成する。
この方法なら、Wikiページを作成する際に文章の細部が要約から漏れたとしても、最終回答では原文へ戻ることができる。
質問ベースの検索は突飛な発想ではない
文書から合成質問を生成し、検索に利用する方法は、研究上すでに提案されている。
2024年に発表された企業RAG向け研究では、文書チャンクを原子的な記述に分解し、そこから合成質問を生成して、ユーザー質問と合成質問を照合する方法が検証された。実験では、元のチャンクを直接検索するよりも、生成された質問を使った検索の方が高い再現率を示した。
2025年にも、文書チャンクから「その文書が回答可能な質問」を生成し、質問と質問の埋め込み類似度によって文書を取得する方式が提案され、複数の質問応答データセットでベースラインを上回ったと報告されている。
つまり、ベクトル検索そのものが間違っているのではない。
何をベクトル化し、何と何を比較するのかという設計が粗いのである。
元テキストのチャンクを無条件に検索対象とするのではなく、元テキストから回答可能な質問空間を構築し、ユーザーの質問をそこへルーティングする方が合理的な場合がある。
SOMでも同じことが起きていた
この状況は、自己組織化マップ、すなわちSOMの歴史とよく似ている。
多くの教科書でSOMは、データを1件ずつ提示し、勝者ノードとその近傍を少しずつ更新する逐次学習アルゴリズムとして説明されてきた。
この説明は、SOMの原理を理解するには分かりやすい。しかし、逐次学習では、
- データの提示順序
- 初期値
- 学習率
- 学習回数
などによって結果が変化する。
一方、データ全体をまとめて用いるバッチSOMでは、学習率を必要とせず、条件を固定すれば安定したモデルを構築しやすい。
SOMの考案者であるTeuvo Kohonen自身も、2013年の論文で、実用上はバッチ学習版だけを推奨すると述べ、逐次学習より収束が速く安全であると説明していた。
Viscovery SOMineも長年にわたりバッチSOMを中核に採用し、現在の製品資料でも、高性能なバッチSOM、六角形格子上の二次元表示、変数の重み付け、欠損値処理などを基本機能としている。
それにもかかわらず、一般に「SOM」と聞いて思い浮かべられるのは、今でも教科書に載っている逐次学習型であることが多い。
ここには、技術普及の典型的な問題がある。
最初に分かりやすく説明された方式が、その技術の標準形として固定される。
その後に優れた方法が登場しても、それが教科書、講座、サンプルコード、一般向け記事に反映されるまでには長い時間がかかる。
初歩的な方式ほど普及しやすい
Naive RAGが普及した理由は、その方法が最も優れていたからではない。
説明しやすく、デモを作りやすかったからである。
「PDFを分割し、ベクトルDBに入れ、質問に近い部分をLLMに渡す」と言えば、多くの人が理解できる。
さらに、この構造は、
- 埋め込みAPI
- ベクトルデータベース
- RAGフレームワーク
- クラウド検索サービス
といった具体的な商品にも結びつけやすい。
初歩的な説明は、技術者にとって実装しやすく、販売会社にとって売りやすく、発注者にとって社内説明しやすい。
その結果、「まず動かす」ための方式が、「本番でも使うべき標準方式」へと昇格してしまった。
SOMでも、逐次学習アルゴリズムはニューラルネットワークらしく説明しやすかった。入力を与え、勝者を決め、近傍を更新するという物語は直感的である。
しかし、説明しやすいことと、実務上優れていることは同じではない。
調整作業が高度な技術に見えてしまう
Naive RAGを採用すると、回答できない質問が現れるたびに、
- チャンクをどう切るか
- 上位何件を取得するか
- 類似度の閾値をどうするか
- 再ランキングをどうするか
- プロンプトをどう書くか
という調整が必要になる。
この調整が複雑であるため、RAGは高度な技術に見える。
しかし、別の見方をすれば、初歩的な設計を採用した結果として、大量の調整が必要になっているとも言える。
質問文と回答文を直接マッチングするという無理を、後段のパラメータ調整で補っているからである。
これは、逐次SOMの学習率や学習順序を何度も調整しながら、「SOMは結果が安定しない」と結論づけることに似ている。
バッチSOMを使えば問題設定そのものが簡単になるように、RAGでも検索対象を再設計すれば、多くの調整を不要にできる可能性がある。
LLM Wikiは知識の保存庫ではなくルーティング層である
文書からWikiページを自動生成するというと、元文書を要約して別の知識ベースを作るものだと誤解されやすい。
しかし、ここでいうLLM Wikiの中心的な役割は、要約を保存することではない。
各Wikiページに、
- ページの対象
- 元テキストへの参照
- その元テキストが答えられる質問パターン
を持たせる。
Wikiページは、ユーザーの質問を適切な元テキストへ導く意味的なルーターとして機能する。
文書ごとに独立したLLM Wikiを作れば、さらに問題は単純になる。
- 文書単位で更新できる
- 文書単位でテストできる
- 文書単位で無効化できる
- 文書単位で権限を設定できる
- 閲覧可能なWikiだけを仮想的に統合できる
全社文書を一つの巨大なベクトルDBへ投入し、検索後にLLMへ権限判断までさせる必要はない。
認証された利用者が閲覧できるWiki集合を先に確定し、その範囲内だけで質問パターンを検索すればよい。
ベクトル検索を否定しているのではない
ここで主張したいのは、ベクトル検索を廃止すべきだということではない。
質問パターンとユーザー入力の照合にも、埋め込みベクトルは利用できる。
違いは、次の一点にある。
生文書をそのままベクトル化して検索するのか。
それとも、文書が回答可能な質問を生成し、その質問空間を検索するのか。
ベクトル検索は道具であり、知識設計ではない。
ところが、ベクトルDBを導入したことが、知識基盤を構築したことと同一視されている。
ここに現在のRAGブームの大きな混乱がある。
技術の進歩を妨げるのは、無知だけではない
この問題を、単純に「世間の技術者のレベルが低い」と片づけるべきではないだろう。
より根深いのは、次のような構造である。
- 最初のチュートリアルが認識の枠組みを作る
- フレームワークがその枠組みをコードとして固定する
- ベンダーがその構成に沿って製品を販売する
- 発注者が一般的な方式を選ぶ
- 教育機関が市場で広く使われている方式を教える
この循環が形成されると、より合理的な方法が存在していても、標準方式は簡単には変わらない。
バッチSOMが長年一般化しなかったことも、質問パターン型の検索がRAGの標準になっていないことも、同じ構造の中で理解できる。
必要なのは、検索技術ではなく知識設計である
企業が本当に必要としているのは、文書に似たチャンクを探すシステムではない。
必要なのは、
- この文書は何について答えられるのか
- どの質問をどの知識領域へ送るのか
- どの元テキストを根拠とするのか
- どの利用者がどの文書を閲覧できるのか
- 文書が更新されたとき、何を再生成するのか
- 回答できなかった質問をどう知識へ追加するのか
を管理する仕組みである。
つまり、RAGの本質的な課題は、ベクトルDBの性能ではない。
人間向けに書かれた文書を、AIが質問に答えられる構造へどう変換するかという知識設計の問題である。
「教科書に載っている基本形」を疑う
新しい技術が登場すると、最初に広まった単純な説明が長く残る。
SOMでは、逐次学習型がSOMそのものだと思われた。
RAGでは、文書チャンクと質問をベクトル検索する方式がRAGそのものだと思われている。
しかし、基本原理は出発点であって、完成形ではない。
SOMが実務の中でバッチ学習、変数重み、欠損値処理、クラスタリング、安定した二次元表示へ発展したように、RAGもまた、生文書検索から、
- 質問パターン生成
- 知識領域ルーティング
- 文書単位のWiki
- 権限付き仮想統合
- 元テキストへの再参照
- 継続的な質問追加と回帰テスト
へ進む必要がある。
皆が信じている方式が広く使われているからといって、それが最も合理的な方式であるとは限らない。
技術の本当の進歩は、既存のパラメータを細かく調整することではなく、誰も疑わなくなった前提を、もう一度疑うことから始まる。
