RAGアプリを構築し、好きな車について聞いてみた。しかし、答えられなかった。

私はKenningというドキュメントチャットツールを開発しています。これはRAG（Retrieval-Augmented Generation）を利用して、ユーザーがアップロードしたファイルについて質問できるようにするものです。

以下の技術を使用して、パイプライン全体をゼロから構築しました：

  • Java 21 と Spring Boot
  • Spring AI
  • PostgreSQL (pgvector 使用)
  • Ollama (llama3.2:3b と nomic-embed-text を実行)
  • Docker Compose

パイプラインの仕組みは以下の通りです： ファイルをアップロード → テキストを抽出 → テキストをチャンク化 → チャンクをベクトルに変換 → pgvector に保存 → 類似チャンクを検索 → チャンクと質問をモデルに送信 → ソース付きの回答を取得。

システムは動作しましたが、2つの異なる失敗に直面しました。見た目は似ていましたが、原因は異なっていました。

失敗1：モデルが混乱した。 質問：「このプロジェクトではどの埋め込みモデルを使用していますか？」 ドキュメントには答えが明記されていました。モデルは正しいテキストを検索できました。しかし、次の文章で正しいモデル名を繰り返しているにもかかわらず、「わかりません」と回答したのです。

私の推測：3Bモデルでは小さすぎました。正しいデータを取得できてはいたものの、自信を持って回答を断定することができませんでした。より大きなモデルを使えば解決する可能性が高いです。

失敗2：モデルが何も見つけられなかった。 質問：「私はどの車ブランドが好きですか？」 ドキュメントには、私がBMWを好むことが記載されていました。しかし、システムは結果をゼロと返しました。類似度スコアが、設定した閾値を下回るほど低すぎたのです。

私の推測：チャンクの希釈化（Chunk dilution）。テスト用のドキュメントが短かったことが原因です。Spring AI、OAuth2、そして私の車の好みといった多くのトピックが1つのチャンクに混在していました。その結果、チャンクのベクトルがそれらすべてのトピックに分散（希釈）されてしまったのです。車に関する特定の質問が、広範なチャンクに対して十分な強度を持てなくなりました。より優れたチャンキング戦略によって解決できるはずです。

学んだ教訓：

  • 小規模なモデルには推論能力の限界がある。
  • 単純なチャンキングは検索精度に影響を与える。
  • 単にエラーを修正するよりも、「なぜ」をデバッグすることの方が重要である。

アーキテクチャは成立しています。動作は遅く、時として誤りもありますが、ループは完成しています。

ソース: https://dev.to/mido-dev/i-built-a-rag-app-then-asked-it-what-car-i-like-it-didnt-know-583n

学習コミュニティ（任意）: https://t.me/GyaanSetuAi