In-Memory RAG Architecture

はじめに

厳密には、このアーキテクチャは「In-Memory RAG」よりも「In-Context RAG」と呼んだ方が適切かもしれない。一般的にRAG（Retrieval-Augmented Generation）と言うと、Embeddingモデルを利用して文書をベクトル化し、Vector Databaseから関連情報を検索してLLMへ渡す構成を思い浮かべる人が多いだろう。

しかし、すべてのプロダクトにおいて、そのような本格的なRAG構成が必要になるわけではない。特にMVPやPoCの段階では、開発スピードを優先したり、インフラ運用コストを増やしたくないというケースが多い。

そこで私は、文書全体をメモリ上に保持し、そのままLLMのコンテキストへ渡すことで知識拡張を行うアーキテクチャを採用した。本記事では、この「In-Memory RAG Architecture」の考え方と実装方法について紹介する。

なぜ In-Memory RAG なのか

このアーキテクチャはMVPを素早く構築したいケースやインフラコストを極限まで削減したいケースにおいて有効である。一般的なRAGでは、Embedding生成→Chunking→Index作成→Vector DB管理→Retrieval品質の改善など、多くの実装と運用コストが発生する。一方で、小規模なドキュメントであれば、文書全体をそのままLLMへ渡した方がシンプルかつ高精度なケースも存在する。

一般的なRAGとの違い

通常のRAGは以下のような流れになる。

Document
 ↓
Chunking
 ↓
Embedding
 ↓
Vector DB
 ↓
Retrieve Top-K
 ↓
LLM

一方、In-Memory RAGでは、

Document
 ↓
OCR / Document Parsing
 ↓
In-Memory Storage
 ↓
LLM Context

という非常にシンプルな構成になる。Embeddingも不要であり、Vector Databaseも不要である。その代わり、文書全体がコンテキストウィンドウに収まることが前提となる。

設計

前提として、対象とするドキュメントサイズは数十ページ程度までの技術文書や設計資料を想定している。文書全体をLLMのコンテキストへ投入できるサイズであれば、検索フェーズそのものを省略できる。

このアプローチでは、Retrieval失敗やChunk境界問題、Embedding品質問題を回避できる。一方で、Token消費量増加したり、Context Window制約という別の課題を抱える。

1. 文書解析

まず文書からテキストを抽出する。候補としては、『Azure Document Intelligence』『Mistral OCR』『Google Document AI』などが利用できる。

VLMでも文字起こしは可能だが、長文書では省略や要約が発生する場合がある。そのため、まずはOCRベースでテキストを取得することを推奨する。この時点で取得できるのはテキスト情報のみである。図表や設計図に含まれる意味情報はまだ取得できない。

2. 図表キャプション生成

実際の業務文書では、設計図やフローチャート、アーキテクチャ図などの図表が重要な情報源になる。OCRだけでは図表の意味を理解できない。そこで各図表に対してVLMを利用し、自然言語による説明文（キャプション）を生成する。

図表のテキスト生成では以下のような文章を生成する。

Figure-12:
システム構成図。
API Gatewayの背後に認証サービス、注文管理サービス、在庫管理サービスが配置されている。

3. テキストへの統合

生成したキャプションを文書へ埋め込む。こうすることで、LLMは図表の内容も自然言語として理解できるようになる。この時、図ごとにIDを付与し、メモリ上で管理する。

本文

[Figure-12]

システム構成図。
API Gatewayの背後に認証サービス、
注文管理サービス、
在庫管理サービスが配置されている。

本文

4. 図表ID管理

図表を回答時に再表示したい場合は、システムプロンプトで「参照した図のIDも返却すること」と指示することで、参照された文書、並びに図表IDを取得することができ、返却されたIDとメモリ上のIDをマッチさせて図の実態を表示させる。

{
  "answer": "...",
  "related_figures": ["FIG_001", "FIG_004"]
}

アーキテクチャ図

In-Memory RAG Architecture

Pros

Vector DBが不要なため、インフラ構築・運用・チューニングのコストを大幅に削減できる。Chunkサイズやembeddingモデルの選択に左右されるRetrieval品質問題を回避でき、文書全体を直接渡すことで検索失敗による情報欠落が起きない。OCRとLLMだけで構築可能なため、MVPを短期間で実装できる。

Cons

文書全体を毎回投入するためトークンコストが高くなりやすく、数百ページ規模の文書ではコンテキストウィンドウに収まらない。質問に無関係な情報も送信するため推論コストとレイテンシが増加し、文書数が増えるほど従来型RAGの方が有利になる。

まとめ

In-Memory RAG Architectureは、RAGを完全に置き換えるものではない。しかし、MVPやPoC、小規模文書検索においては非常に有効な選択肢になる。まずはシンプルなIn-Memory構成で価値検証を行い、文書量や利用者数が増えてきた段階で本格的なRAGへ移行する。そのような段階的アーキテクチャ戦略の一つとして、十分に実用的なアプローチだと考えている。