3. 可观测性入门

在金融RAG系统中,模型回答“看起来对”并不等于系统“真的健康”。可观测性(Observability)不是简单的监控升级,而是一种通过系统外部输出推断内部状态的能力。对金融场景而言,它直接关系到合规审计、风险控制与客户信任。

一、核心原理:可观测性到底解决什么问题

传统监控回答“系统是否宕机”,可观测性回答“系统为什么给出这个答案”。金融RAG链路长:用户提问 → 查询改写 → 向量检索 → 重排 → 上下文拼接 → 大模型生成 → 合规过滤 → 返回。任一环节的偏差都可能导致幻觉、遗漏关键风险披露或引用错误数据。

可观测性的三大支柱各有分工:

  • 日志(Logs):记录离散事件,如“检索命中3篇文档”“合规规则R-102触发”。适合事后取证与审计。
  • 指标(Metrics):聚合数值,如检索延迟P99、幻觉率、拒答率。适合趋势告警与容量规划。
  • 追踪(Traces):串联一次请求的完整调用链,标注每个Span的输入输出与耗时。适合定位“哪一步拖慢或污染了结果”。

关键区别:日志告诉你“发生了什么”,指标告诉你“发生得有多频繁”,追踪告诉你“在哪个环节发生、影响了谁”。三者缺一不可。

二、方法流程:从埋点到诊断的闭环

在金融RAG中落地可观测性,建议按以下流程推进:

  1. 定义关键信号:检索召回率、重排NDCG、生成忠实度、引用准确率、P99延迟、合规拦截率。
  2. 统一Trace ID:从网关到向量库、LLM、规则引擎全链路透传,确保一次问答可完整回放。
  3. 结构化日志:采用JSON格式,固定字段如trace_id、stage、doc_id、score、rule_id。
  4. 指标聚合与告警:按业务线、客户等级、问题类型分维度统计。
  5. 诊断与复盘:结合Trace与日志定位根因,形成失败案例库。
{
  "trace_id": "f8a2-9c31-4d7e",
  "stage": "retrieval",
  "query": "某理财产品风险等级",
  "top_k": 5,
  "doc_ids": ["DOC-1021", "DOC-3387"],
  "scores": [0.91, 0.87],
  "latency_ms": 142,
  "timestamp": "2025-03-18T10:22:31Z"
}

下面这张图展示了金融RAG可观测性三大支柱如何围绕一次问答请求协同工作:

金融RAG一次问答请求的可观测性协同 用户提问 → 查询改写 → 向量检索 → 重排 → 上下文拼接 → LLM生成 → 合规过滤 → 返回 Trace ID: f8a2-9c31-4d7e 贯穿全链路 日志 Logs 离散事件记录 doc_id / score / rule_id 合规审计取证 失败案例回放 用途:事后取证与审计 指标 Metrics 聚合数值统计 P99延迟 / 幻觉率 召回率 / 拒答率 分业务线告警 用途:趋势告警与容量规划 追踪 Traces 调用链Span串联 每步输入输出耗时 定位污染环节 端到端回放 用途:根因定位与链路诊断 关联 关联 三大支柱通过统一Trace ID关联,形成“发现→定位→取证→改进”闭环

三、金融RAG中的重要性:为什么比通用场景更苛刻

金融行业对RAG的要求远高于一般问答系统。一次错误的利率引用、遗漏的风险提示或不合规的投资建议,都可能引发监管处罚与客户纠纷。可观测性在此承担三重职责:

维度 通用RAG 金融RAG 可观测性支撑
准确性 容忍一定幻觉 要求引用可溯源 日志记录doc_id与score
合规性 一般无强制要求 需审计留痕 结构化日志+规则触发记录
时效性 秒级可接受 行情类需毫秒级 指标P99延迟告警
可解释性 可选 必须可解释 Trace全链路回放

实践提示:在金融RAG中,建议将“引用准确率”和“合规拦截率”作为一级指标,与延迟、可用性并列监控,而非仅关注系统层指标。

四、与MLOps的关系:可观测性是MLOps在RAG时代的延伸

MLOps关注模型训练、部署、版本管理与监控。传统MLOps监控数据漂移、模型衰减与特征分布。但RAG系统引入了检索库、提示词、重排模型、合规规则等新变量,传统MLOps的监控维度已不够用。

可观测性可视为MLOps在RAG场景下的扩展层:

  • 数据层:MLOps监控特征漂移;可观测性额外监控检索库更新与文档覆盖率。
  • 模型层:MLOps监控模型版本与精度;可观测性额外监控提示词版本与生成忠实度。
  • 服务层:MLOps监控API延迟与错误率;可观测性额外监控检索-生成链路各Span耗时。
  • 合规层:MLOps通常不覆盖;可观测性通过日志与规则触发记录实现审计闭环。

常见误区:不少团队把可观测性等同于“加日志”。实际上,没有统一Trace ID的日志是孤岛,没有分维度聚合的指标无法告警,没有输入输出快照的追踪无法复盘。三者必须协同设计,而非事后补丁。

复盘一个典型失败案例:某金融RAG系统在回答“某基金历史最大回撤”时给出错误数值。日志显示检索命中了旧版文档,指标显示该文档库已30天未更新,追踪显示重排阶段未对文档时效性打分。三个支柱共同定位根因:文档更新流程缺失时效性权重。若只有日志,只能看到“命中了旧文档”;只有指标,只能看到“文档库陈旧”;只有追踪,才能看到“重排未考虑时效”。这正是可观测性在金融RAG中不可替代的价值。

总结而言,可观测性不是运维的附属品,而是金融RAG系统可信交付的基础设施。它让每一次回答都可追溯、可解释、可改进,从而在合规与体验之间建立可持续的平衡。