最近、RedditでRAGシステムの構築に関する興味深い投稿を見つけました。
投稿者は数ヶ月かけて本格的なRAGシステムを開発しています。
そして、その過程で得た知見を共有してくれました。
この記事では、その投稿内容とコメントでの議論を参考にします。
そして、実践的なRAGシステム構築のポイントを解説していきます。
なぜ既存のRAGシステムでは不十分なのか
多くのRAGシステムは、文書解析が甘い。
投稿者も同じ不満を持っていました。
単純にテキストを抽出するだけでは、ユーザーの期待に応えられません。
特に問題となるのは以下の点です。
まず、文書内の図表や画像が無視されてしまう。
テキストだけで「グラフがあります」と説明されても、実際のグラフを見たいですよね。
次に、チャンキングが機械的すぎる問題があります。
文脈を無視して固定長で分割すると、意味のまとまりが壊れてしまうのです。
さらに、精度と速度のトレードオフも悩ましい。
精度を重視すると速度が犠牲になります。
逆に速度を優先すると、回答の質が下がってしまう。
ベクトルデータベースの選択：PostgreSQLが最適だった理由
投稿者は複数のベクトルデータベースを検証しました。
Qdrant、Milvus、ChromaDB、Pinecone。
しかし最終的にPostgreSQL用のVectorChordを選択しています。
その理由は明確でした。
まず速度が圧倒的に速い。
バイナリ量子化と組み合わせると、数百万の文書を500ミリ秒以下で検索できるそうです。
次にBM25によるハイブリッド検索のサポート。
これによりキーワード検索とベクトル検索を組み合わせられます。
結果として、より正確な検索が可能になりました。
そして、既存のPostgreSQLインフラを活用できる点も大きい。
新しいデータベースを追加する必要がありません。
だから運用の複雑さを抑えられるのです。
文書解析の要：LlamaParse
文書解析にはLlamaParseを採用しています。
投稿者はAzureやGoogle、AWSの文書解析サービスと比較しました。
その結果、LlamaParseが最も優れていたとのこと。
LlamaParseの利点は次のとおりです：
- 使いやすさ
- カスタマイズ性の高さ
- 価格の予測可能性
- 高品質なOCR機能
重要なのは、テキストだけでなく画像や表も抽出できること。
抽出した画像はオブジェクトストレージに保存します。
そして、必要に応じてストリーミングで返すのです。
これによって、文書内のグラフや図表を実際に表示できるようになりました。
エージェント型チャンキングの威力
チャンキング手法として、エージェント型チャンキングを採用しています。
LLMを使って各チャンクを処理するため、コストは高くなります。
でも精度を最優先に考えた結果、この選択になったそうです。
各チャンクの処理プロセスは次のとおりです。
まず、前後のチャンクも含めてLLMに渡します。
これにより一貫性のあるチャンクを生成できる。
さらに、チャンクの要約と関連する質問も生成させます。
処理速度は確かに遅くなります。
しかし、強力なキューイングシステムで並列処理することで対応しています。
安価で高速な手法では得られない精度が実現できるとのことです。
リランキングと検索精度
PostgreSQLから取得したデータは、Cohereのリランキング機能で再評価します。
上位6件を取得し、最も関連性の高いものを選択する仕組みです。
埋め込みモデルはCohere embed-v4を使用。
複数の言語でテストした結果、最も良好な結果が得られたそうです。
アラビア語、デンマーク語、英語で検証済みとのこと。
エバリュエーションの重要性
コメント欄で言及されていた書籍「Enterprise RAG」。
この本では、RAGシステムにはエバリュエーション（評価テスト）が不可欠だと説明されています。
エバリュエーションは、ユニットテストのRAG版と考えると分かりやすい。
事前に質問と期待される回答を用意します。
そしてシステムの出力と比較するのです。
投稿者も多数のエバリュエーションを作成しています。
これによりシステムの精度を継続的に検証しているそうです。
技術スタックの詳細
フロントエンドの構成：
- Vue.js 3
- TypeScript
- Tailwind CSS 4
バックエンドの構成：
- PHP 8.4とLaravel 12（メイン）
- Rust（tiktoken用）
- Python（FastAPI、インジェストとチャンキング用）
興味深いのは、WebSocketsではなくSSEを採用した点です。
チャットボットには全二重通信は不要。
だからSSEの方がシンプルに実装できます。
実際、多くの最新チャットボットがSSEを使用しているそうです。
サーバーはAMD EPYC 7502Pを搭載。
2TB NVMe、256GB RAMという強力な構成です。
これを2台用意し、災害復旧にも備えています。
実装上の課題と解決策
コメントでは様々な質問や議論がありました。
構造化データ（CSVやExcel）の扱いについて質問がありました。
また、2000ページにも及ぶマニュアルを扱う場合の工夫も議論されています。
大規模文書の場合、次のようなアプローチが紹介されていました。
初回検索で30ページ程度を取得します。
その後、Qwenの軽量リランカーで1-5ページまで絞り込むのです。
チャットメモリについては、Redisを使用。
直近5件の会話を保持しています。
速度を重視した選択とのことです。
今後の展望
投稿者はGraphRAGの実装を検討中です。
「Essential GraphRAG」という書籍を参考に実験を進めているそうです。
また、ローカルモデル（Qwen）の導入も計画中。
ユーザーがローカルモデルと外部モデルを選択できるようにする予定だそうです。
まとめ
この投稿から学べることは多い。
RAGシステムの構築は、単なる技術の組み合わせではありません。
精度と速度のバランスを取る必要があります。
そして何より、ユーザーの期待に応えることが重要です。
特に印象的だったのは、精度を最優先にした設計思想。
コストや処理時間が増えても構わない。
正確な回答を提供することを重視しています。
画像のストリーミング対応も革新的です。
文書内の図表を実際に表示する。
これによって、より豊かな情報提供が可能になりました。
RAGシステムの構築を検討している方は、この投稿者のアプローチを参考にしてみてください。
完璧なシステムではないかもしれません。
でも、実践的な知見が詰まっています。
