8月25日、Towards Data Scienceが「10 Positions for Enterprise RAG That Mainstream Tutorials Get Wrong」と題した記事を公開した。エンタープライズ向けRAG実装において主流チュートリアルが誤りがちな10の設計方針を論じたもので、「ベクトルストアをパイプラインの入口に置く」という広く普及したアプローチを根本から問い直す内容だ。契約書・規制書類・技術レポートといった実務文書を扱う現場では、チュートリアル的レシピがいかに早く破綻するか——その理由が10の論点として整理されている。
なお本稿が紹介する元記事は、エンタープライズ文書インテリジェンスをテーマとした連載シリーズの一篇として公開されたものだ。連載の文脈を前提とした記述が随所にあるため、以下では初読者向けに適宜補足を加えながら紹介する。
「チャンクして、ベクトルストアに突っ込んで、コサイン類似度で取り出す」——このパターンがRAGチュートリアルの標準になって久しい。だが実際のエンタープライズ文書にこのレシピを当てはめると、すぐに破綻する。元記事はその理由を10の論点として整理したものだ。
最も核心的な論点：ベクトルストアは「最後の手段」
論点1：ベクトルストアは基盤ではなく、フォールバックだ。
標準的なRAGはベクトルストアをパイプラインの入口に置く。元記事が主張する設計はこれを逆転させる。エンタープライズ文書に対するクエリの大半は、構造優先の検索（文書が宣言した目次、コーパスインデックス、専門家キーワード）で処理できる。埋め込みは、言い換えや他言語表現、内部略語といった残余ケースに対するセーフティネットとして機能させるべきであり、デフォルトの第一段階にすべきではない。
その理由は再現率（Recall@k）ではなく、解釈可能性にある。line_df（パーサーが生成する行単位のDataFrame）に対するキーワードマッチングと文書の目次フィルタリングを使えば、「なぜこのパッセージが取得されたか」を人間が読める形で説明できる——マッチしたキーワード、セクションパス、行番号という形で。コサイン類似度では「768次元空間でこの2つが近かった」という説明しか得られない。
監査人やドメイン専門家に対して取得根拠を説明しなければならないエンタープライズ環境では、この解釈可能性のギャップこそが設計を規定する。
「専門家辞書 > 良い埋め込みモデル」という主張
論点2：専門家辞書は、より良い埋め込みモデルに勝る。
埋め込みが解くとされてきた同義語問題（Premium→cost、Termination→cancellation、Franchise→deductible）を、元記事はドメイン専門家が管理するconcept_keywords_dfテーブル（「専門家辞書」）で処理する。
ファインチューニング済みの埋め込みモデルは、辞書がカバーしていない未知の表現や言語には強い。しかし「この会社の内部製品コードが何を意味するか」「この業界特有の表現の曖昧さ解消」は、専門家が無償で知っている。埋め込みはそれを推測するしかない。
実用上の帰結として、埋め込みモデルは「辞書に載せるべきエイリアスを発見するためのツール」として数回走らせ、その後は検証済みの辞書で永続的に検索するという使い方が推奨される。ファインチューニングは贅沢品になる。
その他8つの論点：要点まとめ
論点3：リランカーは主要ステージではなく補助ツール。
クロスエンコーダ（クエリと各候補文書をペアで入力し、関連度スコアを直接出力するモデル。埋め込みの内積で近似するバイエンコーダより精度が高い反面、計算コストが大きい）のリランカーは、MS MARCOのような学術ベンチマーク（top-100〜top-1000の候補プールが前提）では有効だ。しかし、専門家語彙検索と構造フィルタリングで候補セットがすでに小さく絞られているエンタープライズ環境では、レイテンシとコストが増えるだけで精度改善は限界的になる。リランカーを「必須コンポーネント」として設計に組み込む前に、上流の絞り込み精度を問うべきだという主張だ。
論点4：「全てをベクトルストアに接続する」を拒否する。
ハイパースケーラー（AWS・Google Cloud・Azureなど超大規模クラウド事業者）が推奨するこのパターンは、チャンクごと・クエリごとの課金という自社ビジネスモデルに最適化されており、顧客の検索精度に最適化されていない。代替として、文書分類→コーパスインデックス→フィルタリング→ルーティング（集計クエリはSQLエージェントへ）という構成が提案されている。
論点5：企業はGoogleではない。
Googleのベンチマーク手法——1000万文書インデックス、カスタム埋め込みモデル、学習済みリランカー——は、数百種類の文書タイプと数十人のドメイン専門家を持つ一般企業には転用できない。スケールの前提が根本的に異なるという指摘だ。論点1・2で示した「構造優先＋専門家辞書」のアプローチは、この現実的なスケール差を踏まえた設計でもある。
論点6：専門家を置き換えるのではなく、増幅する。
エンタープライズRAGが扱う文書はドメイン専門家が熟知しているものだ。自律エージェントや汎用ベクトル検索は専門家の判断を迂回しようとするが、正しいアーキテクチャはその判断をスケールさせるものであるべきだ。専門家知識を辞書・ルーター・評価基準として明示的にシステムへ組み込む設計が、この思想を体現する。
論点7：決定論的ディスパッチャーは自律エージェントに勝る。
「どのツールを呼ぶか」をLLMに決めさせる「エージェントRAG」はデモでは柔軟に見えるが、再現不能なインシデントのコストは膨大になる。decide.pyのような決定論的ルーターは人間が読めるコードで動き、監査人が決定を再現でき、蓄積された判断ロジックがバージョン管理に残る。エンタープライズ環境で「なぜその回答を返したか」を説明できることの重みは、柔軟性のメリットを上回るという主張だ。
論点8：集計スコアではなく、失敗モード別の評価。
システム全体で95%の正確率でも、クロスリファレンス・列挙型質問・条件節・スキャンPDFページといったハードサブセットで50%の精度を隠せる。単一の集計指標はこの問題を覆い隠す。指標はサブセット（スライス）別に保持し、どの文書タイプ・質問タイプで失敗しているかを可視化すべきだ。
論点9：各ブリック（処理単位）はリレーショナル構造データを生成し、生文字列は返さない。
ここでいう「ブリック」とは、元記事の連載で定義されているパイプラインの処理単位を指す。ブリック間のインターフェースを文字列ではなくDataFrameのテーブルにすることで、各ブリックの独立テスト、再パース不要な検索再実行、型付きの監査証跡が実現する。中間出力を構造化しておくことで、デバッグ・評価・再利用のコストが大幅に下がる。
論点10：引用は装飾ではなく証拠だ。
生成された回答には(start_page, start_line, end_page, end_line)と逐語引用を付与し、PDFの該当箇所をハイライトする。これはLLMの不透明性をなくすのではなく、エンタープライズ業務で重要な問いに対してその不透明性を無関係にする発想だ。回答の根拠を原文で辿れる設計は、法務・コンプライアンス・監査の場面で実質的な差を生む。
元記事によれば、連載のコンパニオンノートブックはGitHubのdoc-intel/notebooks-vol1で公開されており、実際のPDFを使って各ブリックをエンドツーエンドで動かせるとのことだ。
詳細は10 Positions for Enterprise RAG That Mainstream Tutorials Get Wrongを参照していただきたい。
