こんにちは、ネットワールドの海野です。
今回から 2回 + 補足コラムの構成で、社内文書を対象にした RAG (Retrieval-Augmented Generation) の検証について書いていきます。前編では「なぜこの構成にしたのか」という設計思想の部分を中心にお伝えします。
実装の詳細は後編で、今後の VAST DATA や NetApp との連携については補足コラムでそれぞれ扱う予定です。(元気があれば。)
なお、リポジトリは GitHub で公開しています。
企業が RAG を導入するときの「データの壁」
生成AIを業務に取り入れたい。社内文書を検索して、根拠付きで回答してほしい。そういったニーズは増えています。
ただ、実際にやろうとすると壁にぶつかるのではないでしょうか。
- 機密文書をクラウドに上げられない (社内規程、データ主権の要件)
- GPU や DRAM の調達が難しい (オンプレで推論を動かしたくてもリソースがない)
- マネージドの RAG サービスは便利だが、データの所在と統制が不透明になりがち
近い将来、「全部クラウドでやる」も「全部オンプレでやる」もどちらかに振り切りにくい局面がいよいよ出てくるかもしれません。
「データ正本はオンプレ、計算はクラウド」という割り切り
そこで今回の検証では、このような構成を採用しました。
- データの正本 (PDF原本、チャンク、ベクトルインデックス)はオンプレに置く
- AI推論 (回答生成) は AWS Bedrock に任せる
将来、GPU やメモリの調達が進めばオンプレ回帰も可能です。逆にクラウド側のサービスが要件に合えばそちらに寄せることもできます。計算リソースの配置を後から変えられるよう、ポータビリティを意識した設計にしています。
この「データは出さない、AIは借りる」という割り切りが、今回の構成の出発点です。
特に「AIは借りる」というフレーズについて、今回の Bedrock のように LLM 自体をサービスとして利用する形式ももちろんそうですが、 CoreWeave や Nebius などで GPU を調達し、Gemma のようなオープンウェイトモデルを自前で動かすシナリオも可能かもしれません。(私自身はネオクラウドを使ったことないですが。)
VPNless — PoC 段階の現実的な割り切り
リポジトリ名に vpnless と入っています。これは「VPNなしで安全」という主張ではありません。
ポイントは、クラウドに送る情報を最小限に絞ることで、PoC段階では VPN や AWS PrivateLink を導入しなくても許容できるリスクレベルに抑えられる、という判断です。
具体的には、Bedrock に送信するのは「ユーザーの質問文 + Top-K根拠 (数件の短い抜粋テキスト)」だけです。PDF原本もベクトルインデックスも、メタデータの本体もクラウドには渡しません。
本番環境では AWS PrivateLink や Site-to-Site VPN 等の経路保護が必要です。 リポジトリの検証プランでも「セキュア化 (VPN導入)」は今後の課題として明記しました。あくまで、最小開示によって PoC フェーズの検証速度を優先できた、という位置づけです。
最小開示の設計 — 何を送り、何を送らないか
もう少し具体的にオンプレとクラウドの責務境界を確認します。
オンプレ (Linux、例えば WSL) に留まるもの:
- PDF原本
- チャンク化されたテキスト (chunks.jsonl)
- Embedding (ベクトル表現)
- ベクトルインデックス (FAISS)
- メタデータ (文書ID、部署、機密ラベル等)
- ACL (アクセス権限情報)
クラウド (AWS Bedrock) に渡すもの:
- ユーザーの質問文
- Top-K根拠 (上位数件の抜粋テキスト、通常5件程度)
送信対象は「質問 + 許可された抜粋」に限定し、必要に応じてチャンク長の上限やマスキングで統制する方針です。
なぜ Embedding はローカルで動かすのか
「推論は Bedrock に任せるのに、Embedding はなぜローカルなのか」と思われるかもしれません。
理由は明確です。Embedding 生成には全チャンクのテキストをモデルに入力する必要があります。これをクラウド側で実行すると、PDF から抽出した全文テキストをクラウドに送ることになり、最小開示の原則に反します。
一方、推論時にクラウドに送るのは「質問 + Top-K根拠」だけなので、送信データ量は限定的です。
さらに、Embedding はインデックス構築時のバッチ処理です。リアルタイム性は不要なのでローカル Linux の CPU で十分間に合います。今回は intfloat/multilingual-e5-small (384次元)を使っていますが、日本語対応かつ軽量で、ローカル実行に適したモデルです。
アーキテクチャ全体像
データフロー図で示すとこのようになります。
原本から回答生成まで、どの段階でどのデータがどこにあるかが明確です。監査や承認フローに載せやすい構成を意識しています。
用語解説
記事中で使う用語を簡単に補足します。
- Top-K根拠 — 質問に対して関連度が高い抜粋を上位K件だけ選んだもの。例えば「社内文書の該当箇所を5つだけ持ってくる」というイメージです。
- Embedding — 文章を「意味の特徴量」に変換する処理。変換結果 (ベクトル)を使って、意味が近い文章同士を高速に検索できます。
- チャンク — PDF の本文を検索・引用しやすい単位 (段落サイズ)に分割したもの。原本をそのまま扱うと重いため、小さめの抜粋に分けます。
- ACL (アクセス権限) — 「誰がその文書を参照してよいか」のルールです。この情報がクラウドに出ると組織構造が推測される可能性があるため、オンプレに閉じます。
- メタデータ — タイトル、更新日、機密ラベル、文書種別など、本文以外の付帯情報です。本文がなくても「存在」や「重要度」が推測される場合があるため、LLM への送信量は絞る方針です。
次回予告
後編では、この設計思想を具体的にどうコードに落としたかを掘り下げようかと思います。PDF の抽出パイプライン、FAISS によるベクトル検索、Bedrock の呼び出し方、Terraform によるコスト統制まで、実装の全体像をお伝えする予定です。
