RAGを使ったアプリ開発のススメ

Last updated at 2025-07-11Posted at 2025-06-27

従来のアプリ開発との違い

LLM を使ったアプリは、その性質上 ベストエフォート型 である。ゆえに、従来のシステム開発でベースとなってきた詳細設計レベルのシステム定義だけでは、十分な仕様の定義が行えない。

ここでいう「ベストエフォート型」とは、LLM の出力が決定論的ではなく、同じ入力でも異なる出力を返す可能性があるという性質を指す

ベストエフォート型のシステムである以上、アプリの返却値は一意的にならず、多少のゆらぎを含む。そこで 期待値に対して何 % 応えられているか をもって、システムの担保条件とする

したがって RAG アプリを作る際は、まず どんなデータをインプットし、どんなデータをアウトプットするシステムか を宣言的に定義する必要がある

ここでいう「どんなデータ」とは、試験にそのまま使える粒度であり、教師データ（＝テストや学習に用いる正解例）と同等とみなす

ユースケース	インプット例	期待アウトプット例
FAQ 型	「パスワードを忘れたときは？」	「ログイン画面の『パスワードを忘れた場合』リンクから再設定できます」
マニュアル検索型	「エラーコード E104」	マニュアル 3.2.4「E104 対処フロー」セクション
他システム連携型	`{ "機種": "ABC-1000", "症状": "電源が入らない" }`	「ABC-1000 は電源ユニットが劣化している可能性があります」
トラブルシューティング型	U: ログインできません A: エラーメッセージは？ U: 認証失敗と出ます	「パスワード誤入力の可能性があります。〜」

現実には分類不能な曖昧系の入力もありうるが、まずは明示的に扱えるケースから設計する

実際に評価に使えるデータを集めるとしても、内容がイマイチでは評価自体が機能しない。
ユースケースに見合ったデータを集めるべきであり、集めなければならないデータの範囲はユースケースで想定される範囲と同等である。

アプリを作ったら、先に定義したインプットデータを流し込み、得られたアウトプットと期待アウトプットの類似度を測定する。これがシステムの性能かつ品質を示す指標となり、低ければ改善が必要となる

類似度が測定できない状況では、改善要否の判定すらできず、独りよがりのアプリに終わるリスクが高まる。

人間レビューは最終的な品質保証として最適だが、工数は大きい。
加えて 何がどう満たされていれば良いのか を言語化しないと再現性が担保できない。

評価を始める前に、「何が満たされていれば高評価なのか」という評価軸を明示的にする。

チャット型アプリは汎用性が高く、明確な評価軸を事前に定めにくい。
そのため Good / Bad という主観評価が、ユースケースに適合した唯一の軸になることが多い。

ただし 主観的満足 ≠ 品質担保 である。正確性や説明責任が求められる業務ユースでは、別途明示的な評価基準が欠かせない。

RAG アプリの開発は、どんなインプットを入れたらどんなアウトプットが出てほしいのかでシステムを定義する

ユースケースを特定し、入力と出力を具体的にイメージする
最小単位のデータセット（インプット／アウトプット）を作成
そのデータセットを使いアプリを開発
ユースケース範囲内でデータセットを拡張
データセットで精度を測定し、精度が足りなければ改修
- 基本的に E2E 評価を採用（中間教師データは作りづらい）
- 機械的測定と人間レビューを併用。ただし人間レビュー時は評価基準を明確に
デリバリ → データ回収 → 継続改善のループを回す

上記の通り、RAG アプリの開発には教師データの存在が必要不可欠である

ゆえに 教師データが集めにくいユースケースや、デリバリ後の継続的なデータ回収が難しいケースでは、プロダクトの開発はかなり難しい ものになる

外部サービスにデータセット作成を委託したり、本番環境とは別軸で継続的なデータ回収ができるプラットフォームを作るなど、やり方を工夫しなければならない