6月26日、Towards Data Scienceが「Amplify the Expert: A Philosophy for Building Enterprise RAG」と題した記事を公開した。この記事では、エンタープライズRAGを「専門家を増幅する」という設計思想のもとで構築するための哲学と実装方針について詳しく紹介されている。
3つの設計原則と4つのブロック
記事はこの哲学を実装に落とし込む際の3つの規律を定義する。
- プラグマティック・専門家駆動：「これはすでにドキュメントを知っている人の蓄積した専門性を活かすか？」が唯一の判断基準
- ピラミッド型エンジニアリング：パーシング・質問パーシング・検索・生成の4ブロックを明確に分離し、新任の上級エンジニアがコードだけを読んで入力から出力まで追跡できる設計。LLMが次のステップを自律的に決める「オーケストレーションループ」は採用しない
- すべてのブロック接合部をリレーショナルテーブルで繋ぐ：PDFのパース結果も（
line_df、page_df、toc_df等）、質問のパース結果も、検索もすべてDataFrameに落とす。ブロック間のやり取りを文字列で行うと「デバッグ地獄の半分を生む」と明言している
4つのブロック（パーシング、質問パーシング、検索、生成）はそれぞれ専門家の手作業を鏡に映したものだ。パーシングは「初読時のスキャン」を模倣し、質問パーシングはCtrl+Fの反射を2軸（共起・専門家辞書展開）で拡張する。パーシングで取りこぼしたものはダウンストリームで復元できないため、パーシングがパイプライン中で最も重要な選択だと記事は強調する。
「専門家を代替する」のではなく「増幅する」
記事の核心は一文に凝縮されている。エンタープライズRAGは専門家を増幅するものであり、代替するものではない。
対象となるのは、数千の契約書を読んできた弁護士、条件反射的に免責事項の条項に手が伸びる保険引受人、監査員が何を聞いてくるかを事前に知っているコンプライアンス担当者といった人材だ。システムの役割は、彼らの判断を「スケール」させることにある。大量のドキュメントを捌き、該当箇所を数秒で見つけ、複数文書を体系的に比較する。専門家のふりはしない。
この前提を置くと、多くのアーキテクチャ上の選択が変わってくると著者は主張する。
- ベクトルストアはフォールバック：専門家はキーワードを知っている
- 決定論的なディスパッチャーがエージェントに勝る：専門家は何が起きたかを監査できる必要がある
- 専門家辞書がファインチューニング済み埋め込みに勝る：専門家の語彙はIDF式やベクトル空間より豊かだ
なお、RAGとは「Retrieval-Augmented Generation（検索拡張生成）」の略であり、LLMが外部ドキュメントを検索・参照しながら回答を生成する手法を指す。LangChainのRAG解説やMicrosoftの概要記事も参考になる。また埋め込み（embedding）とは、テキストを数値ベクトルに変換し意味的な類似度計算を可能にする技術で、RAGパイプラインの検索フェーズで広く用いられる。
IT側と専門家側の断絶
記事が指摘する現場の実態は鋭い。多くの企業では、同じドキュメントに対して2つの平行世界が走っている。
片方は、ベンダーとカンファレンスの影響を受けてITチームが作った「チャンクをベクトルストアに入れてコサイン類似度で検索する」パイプライン。なぜその検索結果が返ってきたのかを正確に説明できる人間は、構築した本人でさえほとんどいない。
もう片方は、数十年のドキュメント読解経験を持つ専門家が今日もCtrl+Fを叩いている現実だ。自分が知っているキーワードを入力し、目的の箇所を探す。キーワードが外れれば目次へ移動し、該当セクションを1行ずつ読む。これが「数十年の専門経験が収束した検索メソッド」だと記事は表現する。
ギャップの構造はシンプルだ。ITキャンプのシステムは不透明すぎる。専門家キャンプの手法は正確だがスケールしない。この記事のシリーズが目指すのは、専門家がすでに信頼している手法（実際の語彙に基づくキーワード検索、外れたら目次ナビゲーション）をLLMでスケールさせることだ。
また記事は「答えを出す方法は2種類あり、それらは同じ操作ではない」と明確に線引きする。
- モデルのパラメトリック記憶から回答する：質問を書けばモデルが答える。チャットボット的用途には十分
- ドキュメントから回答する：2フェーズに分かれる。まず専門家がCtrl+Fを叩くようにキーワードで箇所を探し、次にそのドキュメントに対して質問に答える
エンタープライズ業務は後者であり、この2フェーズを常に分離して保つことがこのシリーズの軸になる。
歴史的な繰り返し：2015〜2020年のML導入と同じ轍
著者はRAGの現状を、2015〜2020年の企業MLブームと重ねて論じる。当時の企業はGoogle・DeepMind・Metaを模倣し、「学習するモデルを作れ」というスローガンのもと汎用的なアプローチを試みた。本番稼働に至らないプロジェクトが多数を占めた、と著者は指摘する（元記事は具体的な調査数値を引用していないが、この傾向は業界で広く認識されている）。理由はほぼ共通していた。データスケールが違う、研究チームがない、汎用アプローチを正当化するユースケースがない。
最終的に価値を生んだのは、保険向けに調整された損害予測、社内語彙でキャリブレーションした文書分類、ドメイン専門家がすでに予測因子として特定していた変数を活用したリスクスコアリングなど、ドメイン特化の取り組みだった。
RAGは今、まったく同じパターンを繰り返している。企業はOpenAIを模倣し、汎用マネージドRAG製品にデータを流し込み、デフォルトですべてをベクトル化する。10年前と同じ失敗モードだ。
このアーキテクチャが適用できる4条件
記事はこの設計思想が万能ではないと明示しており、以下の4条件がすべて揃う場合にのみ有効だと述べる。
- ドキュメントのコンテキストが既知である：保険契約書、医療記録、法的契約書、規制ファイリング、財務諸表など、構造・語彙・慣例が既知の文書クラスを対象としている
- ドメイン専門家がいてアクセスできる：日常的にその文書を扱う人材と話ができ、その知識をシステムにコード化できる
- 目的が増幅であり代替ではない：システム導入後も専門家は存在し続ける。現在のAIは非自明なケースで専門家の判断を信頼性高く代替できないという技術的立場、および専門家は代替されることを望まないという運用上の立場の両方が根拠
- 専門家がシステムを監査できる：検索結果がトレースでき、回答がソースを引用し、動作が再現可能であること
これらが成立するのは、保険ブローカー、法律事務所、病院、銀行、行政機関など、専門家が規制下で構造化ドキュメントを扱う組織だ。逆に、Webを横断するオープンドメインQAや、専門家が存在しないコーパス探索には、このアーキテクチャは適さない。
詳細はAmplify the Expert: A Philosophy for Building Enterprise RAGを参照していただきたい。
