RAGシステムのオブザーバビリティと評価の設計

はじめに

RAGシステムがHTTP 200を返すからといって、正しい答えを出したとは限らない。 一つの回答が妥当に思えるからといって、検索や引用、権限管理の問題がないとは限りません。

一般的な用途の監視は通常、レイテンシ、エラー率、リソース使用に重点を置きます。 RAGシステムは別の質問にも答える必要があります。

  • この回答ではどの文書やチャンクが使われましたか?
  • Dense Retrieval、Sparse Retrieval、Fusion、リランキングはそれぞれ何を返しますか?
  • 正しい証拠はリコールされなかったのか、それともリコール後に下部に置かれたのか?
  • モデルは証拠に忠実であり、引用は本当に結論を支持しているのか?
  • プロンプトやモデル、検索パラメータが変わった後、システムは全体的に改善されるのか、それとも劣化するのか?

これらの問題はログだけでも、単一のオフラインスコアセットだけでも解決できません。 より完全な設計には、オブザーバビリティと 評価 をつなげる必要があります。前者はシステムが実際に何をしているかを記録し、後者はその機能が良くできているかどうかを判断します。

トレース、メトリック、ログ、コレクタ、コンテキスト伝播をまず理解したい場合は、まず以下の内容を読むことができます:OpenTelemetryの始め方:AIアプリケーションとAIエージェント開発者のための人気ガイド。 この記事ではOpenTelemetryの全コンポーネントを繰り返し述べるわけではなく、RAGの高品質なクローズドループをどのように支えるかに焦点を当てます。

1. オブザーバビリティと評価が答える問いは異なる

オブザーバビリティと評価は密接に関連していますが、混同してはいけません。

寸法オブザーバビリティ評価
核心的な問題システムに実際に何が起こったのかシステムはよくできていますか?
主なターゲットTrace、Span、Metric、LogDataset、Expected Output、Score、Experiment
典型的な内容コールパス、遅延、トークン、エラー、候補文書リコール、nDCG、正しさ、忠実度、引用の質
期間オンラインリクエストと運用状況オフライン回帰とオンライン品質評価
主な用途故障やパフォーマンスのボトルネックを特定するプランを比較し、品質の回帰を防ごう

例えば、トレースは次のように示すことができます:

retrieve.dense 返回了 20 个候选
retrieve.sparse 返回了 20 个候选
reranker.rank 耗时 180ms
llm.generate 使用了 3,200 个输入 Token

しかし、それだけでは説明できません。

应该出现的文档是否真的被召回
排在前面的 Chunk 是否与问题相关
生成结果是否忠实于证据
引用是否支持对应结论

したがって、Traceは評価にとって重要なデータ基盤ですが、品質の結論そのものではありません。

2. RAGリクエストを診断可能な段階に分解する

RAG Traceを設計する際は、すべての小さな関数ごとにSpanを作成しないでください。 SPANは独立した診断価値を持ち、遅延や品質の段階を同等に許容すべきです。

典型的なリンクは次のように設計できます:

Trace: rag.answer
├── request.validate
├── query.prepare
├── query.embed
├── retrieve
│   ├── retrieve.dense
│   ├── retrieve.sparse
│   └── retrieve.fuse
├── reranker.rank
├── context.build
├── llm.generate
├── citation.validate
└── response.finalize

権限フィルタリング、クエリの書き換え、複数ラウンドのエージェントを含む場合、以下も追加できます:

query.rewrite
acl.filter
agent.plan
tool.call
guardrail.check

ユーザーリクエストはルートトレースに対応し、API、キュー、ワーカーをコンテキスト伝播を通じてリンクさせることが推奨されます。 非同期タスクがコンテキストを渡さない場合、エントリリクエストとバックグラウンド処理は無関係なレコードとなります。

各段階で記録する内容

記録に適した構造化された属性には以下が含まれます:

service.name
service.version
deployment.environment.name
app.release.git_sha
app.prompt.version
app.knowledge_base.version
app.retrieval.config_hash

gen_ai.provider.name
gen_ai.request.model
gen_ai.usage.input_tokens
gen_ai.usage.output_tokens

app.rag.top_k
app.rag.candidate_count
app.rag.document_ids
app.rag.chunk_ids
app.rag.reranker_model

ここでのapp.*はビジネスカスタムの名前空間であり、公式のOpenTelemetryフィールドではありません。 カスタム属性は安定し明確に保ち、公式の意味慣習として偽装しないべきです。

バージョン情報は特に重要です。 プロンプト、知識ベース、埋め込みモデル、検索設定、Git SHAがなければ、失敗したトレースは「問題が起きた」だけを教えてくれ、「どのバージョンが問題が起きたのか」は知らないかもしれません。

3. 4層の指標でRAG品質を理解する

RAGの指標は、ラン、検索、生成、ビジネス成果ごとにレイヤー化するのが最も効果的です。 最終回答のスコアを見るだけでは、どの層の問題が実際に起きたのか分からなくなってしまうことがあります。

3.1 実行時指標

運用指標は、システムの安定性、高速さ、耐久性を反映します:

P50 / P95 / P99 Latency
Error Rate
Timeout Rate
Token Usage
Cost per Query
Empty Retrieval Rate
Index Freshness
Ingestion Failure Rate

これらの指標は、トレンド、アラート、容量評価に利用される指標やダッシュボードの入力に適しています。 trace_id. ユーザーIDや質問文などの高基準または機密性の高い内容は、メトリックラベルとして使用すべきではありません。

3.2 検索指標

検索評価「証拠は正しいのか?」と答えました。

Recall@K
Precision@K
MRR
nDCG@K
Document Hit Rate
ACL Leakage Rate

正しい文書が候補セットに全く入らない場合は、チャンク化、埋め込み、クエリの書き換え、リコールチャネルをチェックします。 候補者リストには入っても上位にランクインしない場合は、融合と再ランキングを調べるべきです。 候補結果を段階的に保存することは、これら2つのタイプの問題を区別するために必要です。

3.3 生成指標

「モデルは証拠を正しく使ったか?」評価回答を生成する:

Answer Correctness
Groundedness / Faithfulness
Answer Relevance
Citation Correctness
Citation Completeness
Refusal Accuracy

これらの指標は決定論的ルール、手動注釈、または校正されたLLMによる判定によるものがあります。 主観的な判断が関わる場合、モデルスコアは絶対的な真理として扱うべきではありません。 まずは手動サンプルを使って、スコアリング基準、一貫性、バイアスを検証する必要があります。

3.4 ビジネス成果

システムが最終的に価値を持つかどうかは、実際のタスク結果に依存します:

用户是否解决问题
是否继续追问或改写问题
点赞、点踩和人工纠错
任务完成率
转人工率
高风险错误数量

ビジネス成果は通常、単一のオフライン指標よりも真の目標に近いですが、フィードバックが遅れることもあります。 その後のフィードバックは、安定したトレースID、セッションID、またはビジネスタスクIDを通じて現在のランタイムバージョンにリンクし、エビデンスチェーンで提供されるべきです。

4. 評価データセットには独立してバージョン管理された信頼できる唯一の情報源が必要

プラットフォームオブザーバビリティデータセット、実験、スコアのインターフェースを提供できますが、評価データは単一のウェブページだけに存在すべきではありません。

慎重な方法は、リポジトリ内でJSONL、JSON、または他の検閲可能なファイルとしてバージョン信頼できる唯一の情報源を使うことです。

{
  "id": "refund-policy-001",
  "question": "退款申请需要哪些材料？",
  "expected_behavior": "列出必要材料并给出政策出处",
  "expected_sources": ["refund-policy"],
  "tags": ["policy", "citation"]
}

各評価ランは少なくとも以下の記録を残さなければなりません。

dataset_hash
git_sha
prompt_version
knowledge_base_version
embedding_provider_and_model
retrieval_parameters
reranker_model
generation_model
evaluation_code_version

dataset_hash テスト内容の変更確認に使われます。 git_shaし、テスト対象のシステムバージョンを確認するために指紋を設定してください。 入力データ、システム構成、実行結果、スコアリングルールを一体化して初めて、2つの実験を真に比較可能にすることができます。

プラットフォーム内のデータセットは、コラボレーション、注釈付け、実験の入り口としてより適しています。 同期が失敗しても、ローカルデータセットや実行時の製品は保持され、一時的な評価 コントロールプレーン履歴の利用不可によって失われることはありません。

5. オンラインとオフラインをつなぐフィードバックループを構築する

オフライン評価とオンライン観察は別々のシステムであるべきではありません。 成熟したプロセスは通常以下の通りです:

生产 Trace
  ↓
规则、用户反馈、人工审核或 LLM Judge 评分
  ↓
发现失败样本与边界案例
  ↓
加入版本化 Evaluation Dataset
  ↓
修改 Prompt、模型、Chunking、Retriever 或 Reranker
  ↓
运行离线 Experiment
  ↓
比较基线并执行 CI Regression Gate
  ↓
灰度发布并继续观察

この閉ループは、2つの一般的な問題を回避できます:

  • オフラインのデータセットは長期間更新されておらず、実際のユーザー問題とは切り離されています。
  • オンラインでは大量のトレースしか蓄積されませんが、失敗は再現可能なテストに変換されません。

RAGでは、まず強い決定論的閉ループ決定性を持つ検索メトリックを使用し、その後生成品質とLLMをジャッジとして拡張することが推奨されます。 検索段階は通常、明確なグラウンドトゥルースを確立しやすく、変化と指標の変化の因果関係をより容易に特定できます。

より完全なRAGレイヤーアーキテクチャと評価指標については、以下を参照してください:エンタープライズレベルのRAGシステム設定ガイド。

6. オブザーバビリティと評価のコントロールプレーンを配置する

一般的なアーキテクチャの一つは、ビジネスアプリケーションが構造化されたテレメトリや評価製品を生成し、それらを異なるバックエンドで保存、表示、分析することです。

RAG Application
├── HTTP / Worker / Evaluation Runner
├── OpenTelemetry Instrumentation
└── Versioned Evaluation Dataset
            │
            ├── Trace / Metric / Log
            │        ↓
            │   Collector（可选）
            │        ↓
            │   Observability Backend
            │
            └── Dataset / Experiment / Score
                     ↓
                Evaluation Control Plane

ここでは、観測可能性バックエンドと評価制御プレーンを単一のプラットフォームで処理することも、分割して管理することも可能です。 選択時には、まず製品を結合するよりも能力の境界に注目してください。

  • 各RAG段階での親子トレースが示せるかどうか;
  • トークン、コスト、モデル情報を記録できるかどうか、
  • データセット、実験、スコア、手動注釈のサポートかどうか;
  • OpenTelemetryとの相互運用性;
  • データのレジデンシー、権限、バックアップ、アップグレードの要件が満たされているかどうか;
  • バックエンドの利用不可はビジネスリクエストに影響しますか?

Langfuse、Phoenixなどはこの実装オプションの層に属します。 例としてLangfuseを見てみましょう。Trace、Dataset、Experiment、Scoreを同じコントロールプレーンに配置できます。 現在のPython SDKはOpenTelemetryをベースにしており、他のOTel計測機器とコンテキスト共有可能です。

自己管理が採用されると、製品選択は運用と保守の選択となります。 Langfuse v3の低規模Docker Composeデプロイを例にすると、Web、Worker、PostgreSQL、ClickHouse、Redis/Valkey、オブジェクトストレージの保守が必要です。 Docker Composeはテストや低スケール環境に適していますが、完全な高可用性、水平スケーリング、自動バックアップ機能は提供していません。

これは、「自分の環境にデータを保持する」ことが「コストがかからない」という意味ではなく、ホスティングコストを容量、バックアップ、復旧、アップグレード、セキュリティ責任に変換することを示しています。

7. 重複送信と不完全なTraceを避ける

アプリケーションは同時にフレームコールバック、モデリングゲートウェイコールバック、OpenTelemetryの自動ステーキングステーク、プラットフォームSDKにアクセスできます。 もしすべてが同じモデルコールのために生成を作れば、重複トレースや重複トークン、繰り返しのコストを簡単に生成できます。

接続する前に、明確にしておきます:

谁创建根 Trace
谁创建 Retrieval Span
谁创建 Generation Observation
谁负责自动插桩 HTTP、数据库和队列
哪些 Span 发送到 AI 可观测后端
哪些信号发送到基础设施可观测后端

AI コントロールプレーンとインフラのバックエンドがTracerProviderを共有している場合、データは異なるSpan ProcessorやExporterを通じて配信できますが、低価値のインフラSpanをすべてAIプラットフォームに送らないように明確なフィルタリングルールを設けるべきです。

プロバイダー同士が分離されている場合は、親子関係やコンテキストが依然として維持されているか確認してください。 誤ったプロバイダー境界は孤立したスパンを引き起こし、モデル呼び出しが散在し、RAGリクエスト全体が欠落することがあります。

8. 本文はデフォルトで収集せず、アプリケーション側でプライバシー境界を設ける

RAG Traceはユーザー質問、プライベートドキュメント、プロンプト、証拠テキスト、モデル回答を簡単に含みます。 デバッグを容易にするため、すべてのコンテンツがデフォルトで記録され、新しい機密データのコピーが迅速に生成されます。

より安全なデフォルトポリシーは以下の通りです:

capture_content = false

デフォルトでは、許可リストから構造化された情報のみが送信されます。例えば:

模型和提供商
Token 与时延
候选数量
Document ID / Chunk ID
检索和重排参数
状态、错误类型和业务结果

以下の内容はデフォルトで無効化し、明確な承認および保持ポリシーの見直し後にのみ有効化されるべきです。

用户问题正文
私有文档与证据正文
完整 Prompt
模型输入与输出
认证信息和个人信息

最初の脱感作層はアプリケーション側やSDK側で行われ、機密性の高いコンテンツが送信前に削除されるようにします。 コレクター側やプラットフォーム側の二次フィルタリングは安全網として機能しますが、クライアントの境界に代わることはできません。 データがアプリケーションから離れると、その後の削除やアクセス制御の複雑さは大幅に増加します。

9. オブザーバビリティは縮退可能なサイドパスとして設計する

テレメトリや評価コントロールプレーンはビジネスを理解するために使われており、ビジネスに依存するハードなものになってはいけません。

以下の原則が推奨されます:

  • バッチ処理と非同期エクスポートは、マスターリクエストでテレメトリバックエンドを待たずに済むように使われます。
  • エクスポーターはネットワークエラーを記録しますが、通常のビジネスリターンは変更しません。
  • ショートライフサイクルプロセスは、終了前に明示的にフラッシュまたはシャットダウンします。
  • ローカル評価結果はまずディスク上に配置され、その後非同期的にリモートコントロールプレーンに同期されます。
  • キュー容量、ドロップボリューム、再試行回数、ディスク使用状況の監視、
  • テレメトリが有効になった時点で、認証情報の設定エラーはできるだけ早く暴露すべきであり、データが長時間静かに失われてはいけません。

「バックエンドが利用できない場合でも業務は継続される」と「設定エラーによる急速な障害」は相反するものではありません。前者は外部のランタイム障害を処理し、後者はシステムが有効に見えるが実際にはデータがない場合に長時間の稼働を妨げます。

10. 推奨する段階的な導入順序

初日から完全なプラットフォームを作る必要はありません。 建設は以下のように段階的に進められます。

第1段階：ログとリクエストIDを統一する

  • リクエストに安定したリクエストIDを割り当てること;
  • 構造化JSONログを活用し、
  • レコードモデル、トークン、レイテンシ、エラー、行動結果;
  • 機密性の高い本文は収集しないでください。

第2段階：中核となるTraceを構築する

  • RAGリクエストは1つのルートトレースに対応します。
  • 検索、再ランク付け、生成のための手動スパン作成;
  • HTTP、キュー、ワーカーコンテキストを統合する;
  • Git SHAのバージョン、プロンプト、ナレッジベース、検索構成を書きます。

第3段階：指標とコントロールプレーンを追加する

  • 集約遅延、エラー率、トークン、コスト、検索レート;
  • コレクターやオブザーバビリティバックエンドへの接続;
  • 検証サンプリング、フィルタリング、再試行、故障分解;
  • バックアップ、容量、そして責任のアップグレードを確立しましょう。

第4段階：再現可能な評価を構築する

  • バージョン版Golden Datasetの作成;
  • まず、リコール、MRR、nDCGなどの完全な検索インジケーター;
  • サンプルレベルの結果と集計された指標を保持し、
  • データセットのハッシュ、Git SHA、ランタイムの設定を記録します。

第5段階：継続的改善のループを閉じる

  • オンライン故障サンプルをデータセットに追加します。
  • 手動フィードバックと校正されたLLM審査員の導入;
  • プロンプト、モデル、検索スキームに関する実験を行う;
  • CIで検証済み回帰閾値を設定してください。

11. 設計チェックリスト

公開前に、商品ごとに確認できます:

Trace

  • リクエストはクエリ処理から最終応答までの完全なリンクを見ることができますか?
  • API、キュー、ワーカーは同じコンテキストを共有しているのでしょうか?
  • 不合格の回答を特定の候補者や候補者検索、現役バージョンに分類できますか?

Evaluation

  • 評価検索、生成、ビジネス成果は同時に存在するのでしょうか?
  • データセットはバージョン可能で、レビュー可能で、再利用可能ですか?
  • 実験はデータセットのハッシュ、Git SHA、モデル、検索設定を記録していますか?

Privacy

  • 質問、証拠、プロンプト、回答の収集はデフォルトでオフになっているのでしょうか?
  • アプリを離れる前に敏感なコンテンツはフィルタリングされていますか?
  • データの保持、削除、アクセス制御のポリシーはありますか?

Reliability

  • テレメトリのバックエンドが利用できない場合でも、ビジネスは通常通り対応できますか?
  • ローカル評価の結果は独立して保存されますか?
  • キュー、放棄、ディスク、バックアップ、復旧に責任がある人はいますか?

結論

RAG オブザーバビリティ単にすべてのモデルコールにトレースを追加するだけでなく、評価もLLMをジャッジとして一度だけ実行するわけではありません。

より完全なシステムは、次のような関係性を形成すべきです:

Trace 记录一次请求经历了什么
Metric 展示系统整体表现如何
Log 保存具体事件和错误细节
Dataset 固化需要重复验证的问题
Score 表达质量判断
Experiment 比较不同版本的结果
线上失败继续反哺离线回归

本当に価値のある目標は「さらなるデータを収集すること」ではなく、失敗を特定し、説明し、テストセットに追加し、次のリリース前に確実に再現できるようにすることです。

参考文献