Ch 47 评估、可观测与持续演进¶

面包屑

项目第 4 年 · Data+AI转型期——评估可观测

本章你将学到¶

Agent 评估方法论：端到端/轨迹/结果
治理 CI 校验 + LLM-as-a-Judge 多维评估（含评估 prompt 模板）
Agentic BI 效果基准（准确率/延迟/护栏/自愈/缓存）与成本分析（LLM API vs 传统 BI 人力 TCO）
可观测四通道：链路追踪/事件流/结构化日志/指标
Roadmap：多租户 RLS、多 Provider 抽象、基准评测

47.1 Agent 评估方法论¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TB
 subgraph 三种评估["Agent 三种评估方法"]
 E2E@{ icon: "codicon:check", form: "rounded", label: "端到端评估<br/>问题→最终答案<br/>整体正确性", pos: "b", h: 40 }
 TRAJ@{ icon: "codicon:history", form: "rounded", label: "轨迹评估<br/>每一步推理是否正确<br/>过程质量", pos: "b", h: 40 }
 OUT@{ icon: "codicon:database", form: "rounded", label: "结果评估<br/>SQL 是否正确执行<br/>结果是否准确", pos: "b", h: 40 }
 end
classDef bpProcess  fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpData     fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616

class E2E,TRAJ bpProcess
class OUT bpData
linkStyle default stroke:#697077,stroke-width:2px

图 47-1 Agent 评估方法论

评估方法	评什么	优势	局限	代表
端到端	最终答案是否正确	最贴近用户体验	无法定位错误环节	Spider/BIRD execution accuracy
轨迹	每步推理是否正确	可定位错误环节	评估成本高	AgentBench、Trajectory Evaluation
结果	SQL/数据是否正确	客观可量化	不评估过程质量	LLM-as-a-Judge、DeepEval、Ragas

表 47-1 Agent 评估方法论

三级评估体系¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TD
 L1@{ icon: "codicon:pulse", form: "rounded", label: "一级：运行时评估<br/>自动校验<br/>语法/护栏/执行成功", pos: "b", h: 40 }
 L2@{ icon: "codicon:shield", form: "rounded", label: "二级：治理 CI 评估<br/>语义资产一致性<br/>发布前校验", pos: "b", h: 40 }
 L3@{ icon: "codicon:hubot", form: "rounded", label: "三级：LLM-as-a-Judge<br/>多维度质量评分<br/>定期评估", pos: "b", h: 40 }
classDef bpSuccess  fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616
classDef bpProcess  fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpInfo     fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616

class L1 bpSuccess
class L2 bpProcess
class L3 bpInfo
linkStyle default stroke:#697077,stroke-width:2px

图 47-2 三级评估体系

三级评估器设计¶

我把三级评估器做成了纯规则引擎（def 而非 async def），不依赖 LLM 也不做 IO，这样延迟很低。三个评估器分别管检索、SQL、答案三个环节，各自治一段。它们只在 deep_analysis_workflow 路由下启用——主路径 nl2sql_query 对延迟很敏感，不适合跑完整评估；deep_analysis 本身就是"质量优先于速度"的路由，多花几百毫秒做评估是划算的。评估分低了就触发重试（Ch 42 的 Reflexion 自愈回路）。

评估器	评估对象	评估内容	触发条件
Retrieval Evaluator	检索结果	召回的覆盖度、相关性	`deep_analysis_workflow` 路由
SQL Evaluator	生成 SQL	正确性、性能、安全性	同上
Answer Evaluator	最终回答	完整性、准确性	同上

表 47-2 三级评估器设计

47.2 治理 CI 校验 + LLM-as-a-Judge 多维评估¶

治理 CI 校验¶

%%{init: {'theme':'base','themeVariables':{'mindmapRootColor':'#0f62fe','mindmapTextColor':'#ffffff','mindmapMainColor':'#1d3649','mindmapSecondaryColor':'#393939','mindmapLineColor':'#697077'}}}%%
mindmap
  root((治理 CI 校验))
    语义资产一致性
      引用完整性
    术语-指标映射
      是否自洽
    规则可计算性
      计算规则是否合法
    few-shot 质量
      示例 SQL 是否正确

图 47-3 治理 CI 校验

治理 CI 在语义资产发布前跑四个校验项，缺一不可：

校验维度	校验对象	校验方式	失败处理	对应语义资产
语义资产一致性	模型/表/字段/关系之间的引用	引用完整性检查：被引用对象必须存在、字段类型匹配	阻断发布，标记缺失引用并回退到上次绿色版本	semantic model、table schema
术语-指标映射	业务术语与底层指标的绑定关系	自洽性检查：每个术语必须有对应指标，指标公式引用的维度必须存在	阻断发布，列出悬空术语/指标供作者修正	glossary、metric definitions
规则可计算性	指标计算规则、转换规则	合法性检查：规则语法可解析、依赖字段已声明、无循环依赖	阻断发布，标注非法规则与冲突路径	metric rules、transformation rules
few-shot 质量	few-shot 示例（自然语言 + SQL 对）	示例 SQL 正确性检查：语法可执行、引用对象存在、与当前 schema 一致	剔除失败示例并告警，不阻断发布但记录质量分	few-shot examples

表 47-3 治理 CI 校验矩阵

LLM-as-a-Judge 四维评估¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TB
 subgraph LLM-as-Judge["LLM-as-a-Judge 四维评估"]
 D1[正确性<br/>SQL 结果是否正确]
 D2[可解释性<br/>答案解释是否清晰]
 D3[安全性<br/>SQL 是否安全合规]
 D4[效率<br/>SQL 是否高效<br/>是否不必要全表扫描]
 end

 SAMPLE@{ icon: "codicon:database", form: "rounded", label: "采样查询", pos: "b", h: 36 } --> JUDGE@{ icon: "codicon:hubot", form: "rounded", label: "LLM 评分", pos: "b", h: 36 }
 JUDGE --> D1 & D2 & D3 & D4
 D1 & D2 & D3 & D4 --> REPORT@{ icon: "codicon:dashboard", form: "rounded", label: "质量报告", pos: "b", h: 36 }
classDef bpProcess  fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpData     fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616
classDef bpDecision fill:#fcf4d6,stroke:#f1c21b,stroke-width:2px,color:#161616
classDef bpSuccess  fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616

class D1,D2,D3,D4 bpProcess
class SAMPLE bpData
class JUDGE bpDecision
class REPORT bpSuccess
linkStyle default stroke:#697077,stroke-width:2px

图 47-4 LLM-as-a-Judge 四维评估

维度	评估内容	工具
正确性	SQL 结果与标准答案对比	DeepEval / Ragas
可解释性	答案解释是否清晰准确	LLM 评分
安全性	SQL 是否遵守护栏规则	规则检查 + LLM
效率	SQL 执行计划是否高效	EXPLAIN 分析

表 47-4 LLM-as-a-Judge 四维评估

引申

LLM-as-a-Judge 是用 LLM 评估 LLM 的方法——因为人工评估不可规模化。但 LLM Judge 也有偏差（可能偏好某种风格），所以最佳实践是"LLM 评估为主 + 人工抽检为辅"。DeepEval 和 Ragas 是两个开源的 LLM 评估框架，提供了标准化的评估指标和流程。

LLM-as-a-Judge 落到代码是一个评估 prompt 模板，对采样查询按四维打分：

# 示意：LLM-as-a-Judge 四维评估 prompt 模板
JUDGE_PROMPT = """你是 Agentic BI 的质量评审。对以下问答按四维打分（1-5 分）：
【问题】{question}
【生成 SQL】{sql}
【执行结果】{result}
【标准答案】{gold_answer}

请按四维评分并说明扣分原因：
1. 正确性：SQL 结果与标准答案是否一致
2. 可解释性：答案解释是否清晰准确
3. 安全性：SQL 是否遵守护栏规则（无 DDL/PII/全表扫描）
4. 效率：SQL 执行计划是否高效（是否避免不必要 join/扫描）
输出 JSON：{{"correctness": n, "explainability": n, "safety": n, "efficiency": n, "reason": "..."}}"""

def judge_sample(sample: dict) -> dict:
    return llm.evaluate(JUDGE_PROMPT.format(**sample))   # 核心意图：LLM 评估为主 + 人工抽检为辅

DeepEval + Ragas 集成¶

除了自建的 LLM-as-a-Judge，我们还接了两个开源评估框架来做 RAG 专项评估——有现成的标准化指标，没必要自己重造一遍：

工具	用途	关键指标
DeepEval	LLM 评估框架，支持自定义指标与 pytest 集成	answer_relevancy、faithfulness
Ragas	RAG 专项评估	context_precision、context_recall、faithfulness、answer_relevancy

表 47-10 DeepEval + Ragas 集成

Ragas 四个核心指标的含义：

faithfulness：生成的答案是否忠于检索到的上下文（不幻觉）——SQL 是否只用了检索到的表/列
answer_relevancy：答案是否切题——SQL 是否回答了用户问题
context_precision：检索的上下文是否相关——召回的表/列是否与问题相关
context_recall：是否检索到了回答问题所需的全部上下文——有没有漏召回关键表

资产认证生命周期¶

资产不只有"存在"和"不存在"两种状态——它需要质量状态。quality_score + lifecycle_status 两个字段串起了认证流程，质量过关的资产进入 certified 状态，检索时会被优先选中（Ch 40 SemVer 与认证生命周期）：

draft → reviewed → certified → deprecated

这个设计的出发点是"用质量信号影响检索优先级"——Reranker（Ch 41）给 certified 资产加分，让高质量资产更容易被 LLM 看到。

反馈闭环¶

用户反馈是系统改进的燃料——负反馈经过 Admin 审核后，会触发一系列闭环动作：

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
 USER@{ icon: "codicon:person", form: "rounded", label: "用户反馈<br/>like/dislike/纠正", pos: "b", h: 36 } --> ADMIN[Admin 审核]
 ADMIN --> ACTION[闭环动作]
 ACTION --> M1[Correction Memory<br/>纠正记忆]
 ACTION --> M2[资产修订<br/>语义资产更新]
 ACTION --> M3[Few-shot 审批<br/>动态 few-shot]
 ACTION --> SYSTEM[系统改进]
 SYSTEM --> METRICS[评估指标变化]
 METRICS --> USER

 classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
 classDef bpData fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616
 classDef bpSuccess fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616
 classDef bpError fill:#fff1f1,stroke:#da1e28,stroke-width:2px,color:#161616
 classDef bpInfo fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616
 class USER bpInfo
 class ADMIN,ACTION bpProcess
 class M1,M2,M3 bpData
 class SYSTEM,METRICS bpSuccess
 linkStyle default stroke:#697077,stroke-width:2px

图 47-10 反馈闭环：用户反馈→系统改进

三种反馈动作各有用处：负反馈→Correction Memory（Ch 45 纠正记忆，避免再犯同样的错误）；术语或指标出错→资产修订（Ch 40 语义资产更新）；成功案例→Few-shot 审批（Ch 45 动态 few-shot 三步审批）。

基准评测结果¶

以下评测数据为基于行业合理推演的量级，旨在让读者建立 Agentic BI 效果的直觉，非 NewtonData 真实生产数据。

Roadmap 里 Spider/BIRD 基准评测还挂在 P2，但实际跑下来，内部评测和线上观测已经积累了一批量化基线。以下是 Agentic BI 上线后实测的效果基准：

指标	基准值	说明
简单查询 NL2SQL 准确率	95%+	单表聚合/过滤，术语绑定强路由覆盖（"华东区上月销售额"→ `region='East China'`）
复杂查询 NL2SQL 准确率	85-90%	多表 join + 子查询 + 窗口函数；Steiner 树优化 join 路径后准确率提升约 12%
端到端响应延迟 P50	~8 秒	LLM 推理 2-3s + 检索 1-2s + Redshift 查询 2-4s
端到端响应延迟 P95	~25 秒	含 Redshift 大查询排队 + 自愈重试
护栏拦截率	~7%	危险 DDL 3% + PII 字段探测 2% + 超量查询限制 2%
自愈成功率	~70%	表名/列名纠错最成功（90%+），复杂逻辑改写需人工介入
缓存命中率	~35%	语义查询缓存 + 结果缓存双层
用户满意度评分	4.2/5.0	20+ 高频用户季度调研

表 47-5 基准评测结果

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
 Q@{ icon: "codicon:comment", form: "rounded", label: "用户问题", pos: "b", h: 36 } --> S1@{ icon: "codicon:check", form: "rounded", label: "简单查询 95%+ 准确", pos: "b", h: 36 }
 Q --> S2@{ icon: "codicon:check", form: "rounded", label: "复杂查询 85-90% 准确<br/>Steiner 树提升 12%", pos: "b", h: 36 }
 S1 --> P50@{ icon: "carbon:time", form: "rounded", label: "P50 ~8s", pos: "b", h: 36 }
 S2 --> P95@{ icon: "carbon:time", form: "rounded", label: "P95 ~25s 含自愈", pos: "b", h: 36 }
 S1 --> CACHE@{ icon: "codicon:sync", form: "rounded", label: "缓存命中 35% 跳过全流程", pos: "b", h: 36 }
 S2 --> HEAL@{ icon: "codicon:refresh", form: "rounded", label: "自愈成功 70%", pos: "b", h: 36 }
classDef bpData     fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616
classDef bpSuccess  fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616
classDef bpProcess  fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpInfo     fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616

class Q bpData
class S1,S2 bpSuccess
class P50,P95 bpProcess
class CACHE,HEAL bpInfo
linkStyle default stroke:#697077,stroke-width:2px

图 47-5 基准评测结果

成本分析：LLM API vs 传统 BI 人力 TCO¶

Agentic BI 的成本不能只看 LLM API 账单——要跟它替代的传统 BI 人力取数做 TCO 比较才有意义：

维度	传统 BI（人工取数）	Agentic BI（NewtonData）
取数时效	业务提需求→IT 排期→3-5 天	秒级/分钟级
人力成本	3-4 名分析师全职取数	1 名 AI 工程师维护
LLM API 成本	—	日均 ~500 次查询 ≈ ¥15,000/月（见 Ch 1 平台经济学）
月度即席查询量	<50 次（人工瓶颈）	~10,000 次（200×）
总拥有成本（含人力）	高（人力是主要成本）	LLM API 成本远低于替代的人力

表 47-6 成本分析：LLM API vs 传统 BI 人力 TCO

Trade-off

LLM API 成本会随查询量线性增长——日均 500 次查询时月成本 ¥1.5 万可控，但如果涨到 5000 次/天，月成本会到 ¥15 万。控制成本的关键是缓存命中率（35% 的命中已省下三分之一的 LLM 调用）和简单查询强路由（术语绑定直接命中 metric 定义，跳过规划器）。把"所有查询都走完整 LLM 流程"改为"简单查询走缓存/强路由、复杂查询才走完整流程"，是成本可控的核心策略。

47.3 可观测四通道¶

评估关心的是"质量好坏"，可观测关心的是"出了问题怎么定位"。传统系统做可观测主要盯日志和指标就够，Agentic BI 的可观测复杂了一个数量级。

原因很直接。传统 BI 的查询是确定性的——用户写 SQL，系统执行，成就是成，败就是败。Agentic BI 的查询是一条非确定性的多步流水线——一个问题要经过意图理解、检索、规划、SQL 生成、护栏校验、执行、可视化这七八个节点，哪个节点都可能掉链子。而且 LLM 的行为天然不可预测：同一个问题可能走不同的路由，生成不同的 SQL，拿到不同的结果。最终答案如果错了，你没法一眼看出是哪儿出的问题——是检索漏了关键表？是 SQL 幻觉了个不存在的列名？是护栏误拦了？还是执行超时？

没有全链路可观测，这些问题全答不上来。所以四通道可观测不是一个"锦上添花"的东西，是基础设施级的前提。

四通道各司其职¶

四个通道不是随便凑的，各自对着一种不同的观测需求——粒度、时间维度、用途都不一样，互补的，不是互相替代：

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart TB
    subgraph 流水线["Agent 查询流水线"]
        QU[查询理解] --> RAG[RAG 检索]
        RAG --> GEN[SQL 生成]
        GEN --> GUARD[护栏校验]
        GUARD --> EXEC[执行]
        EXEC --> VIZ[可视化]
    end

    QU --> OBS
    RAG --> OBS
    GEN --> OBS
    GUARD --> OBS
    EXEC --> OBS
    VIZ --> OBS

    OBS[ObservabilityFacade<br/>统一观测网关]

    OBS --> T1[链路追踪<br/>Langfuse<br/>每次查询的完整节点轨迹]
    OBS --> T2[事件流<br/>AutoMQ/Kafka<br/>结构化事件异步流]
    OBS --> T3[结构化日志<br/>structlog<br/>可搜索的详细运行日志]
    OBS --> T4[指标<br/>Prometheus<br/>聚合统计与告警]

    T1 --> G1[排障：定位哪一步出错]
    T2 --> G2[审计：谁查了什么数据]
    T3 --> G1
    T4 --> G3[质量监控：成功率/延迟趋势]
    T1 --> G4[持续改进：识别低质场景]

    classDef bpProcess fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
    classDef bpData fill:#d9fbfb,stroke:#007d79,stroke-width:2px,color:#161616
    classDef bpInfo fill:#f6f2ff,stroke:#8a3ffc,stroke-width:2px,color:#161616
    classDef bpSuccess fill:#defbe6,stroke:#198038,stroke-width:2px,color:#161616
    classDef bpGroup fill:#ffffff,stroke:#0f62fe,stroke-width:2px,color:#161616
    class QU,RAG,GEN,GUARD,EXEC,VIZ bpProcess
    class OBS bpInfo
    class T1,T2,T3,T4 bpData
    class G1,G2,G3,G4 bpSuccess
    linkStyle default stroke:#697077,stroke-width:2px

图 47-6 可观测四通道：从流水线到观测目标

链路追踪（Langfuse）是四个通道里最核心的——它记录每次查询从入口到出口的完整节点轨迹，形成一棵 trace 树。一个用户问题对应一条 trace，trace 下面每个节点（查询理解、检索、生成、护栏、执行、可视化）是一个 span，span 内部的 LLM 调用是 generation。trace → span → generation 这种层级让你排查问题时可以逐层下钻：先找到出错的 span，再钻进 span 看具体的 LLM 调用，最后落到 prompt 和 response。Langfuse 底层用的是 OpenTelemetry 的 trace/span 模型（langfuse.com），算是 LLM 应用可观测的事实标准了。

事件流（AutoMQ/Kafka）走的是异步流——每次查询的关键节点（查询开始、检索完成、SQL 生成、护栏通过/拒绝、执行成功/失败、可视化完成）都会发出一个结构化事件。事件流的场景是审计和回放——安全审计要知道"谁在什么时候查了什么数据、拿到了什么结果"，事件流给了完整的操作记录。它和链路追踪的差异在于视角：链路追踪是排障视角（盯某次查询内部出了什么问题），事件流是审计视角（盯跨查询的操作记录）。

结构化日志（structlog）是粒度最细的一层——每个节点内部的运行细节（调试信息、中间状态、错误堆栈）都记下来。"结构化"是这里的关键——日志字段是机器可解析的 JSON，含 trace_id、session_id、节点名、级别，而不是一段自由文本。这样日志可以搜索、过滤、聚合，而不是只能靠人眼去翻。日志通过 trace_id 和链路追踪打通——在 Langfuse 看到某条 trace 后，拿 trace_id 就能在日志系统里把这条查询的所有日志搜出来。

指标（Prometheus）是粒度最粗的一层——它不做单次查询的细节，只看聚合。指标回答的是"系统整体怎么样"：成功率多少？P50/P95/P99 延迟各是多少？缓存命中率？重试次数？指标是告警的基础——成功率突然掉下去了、延迟飙升了，Prometheus 触发告警通知运维。仪表盘上画出趋势图，是做"健康度监控"的骨架。

通道	工具	粒度	时间维度	核心用途
链路追踪	Langfuse	单次查询的节点级	实时+历史查询	排障：定位哪一步出错
事件流	AutoMQ/ Kafka	单次查询的关键事件	实时流+审计存储	审计：谁查了什么数据
结构化日志	structlog	节点内部的调试级	实时+滚动存储	排障：详细的运行细节
指标	Prometheus	聚合统计	时间序列趋势	监控：成功率/延迟/告警

表 47-7 可观测四通道的分工

这四个通道从不同角度观测同一个系统，靠 trace_id 串在一起——链路追踪的 trace、事件流的事件、结构化日志的记录、指标的 label 都带同一个 trace_id，做到了"一次查询、四处留痕"。开发侧只需要调 ObservabilityFacade 这一个统一接口，Facade 内部自动把数据分发到四个通道，底层的工具差异被屏蔽掉了。

运行时稳定性：可观测的"反馈→自愈"闭环¶

可观测不光是"看"——它也驱动"自愈"。系统跑起来之后，一堆稳定性机制在持续工作，它们的效果又通过可观测通道反哺回来，形成"观测→发现→自愈→验证"的闭环：

SQL 语义缓存：相似度 ≥ 0.92 的查询直接命中缓存，跳过完整流水线——35% 的命中率已省下三分之一的 LLM 调用，这是成本可控的关键（Ch 45）。
修复回路：护栏失败后触发 corrective_retrieval，拉取正确资产重新生成——约 70% 的失败查询能自愈成功（Ch 42）。
熔断器：LLM 连续失败时自动暂停该模型调用，避免故障扩散到所有查询（Ch 42 模型分配）。
会话清理与元数据缓存：后台清理过期会话、缓存元数据减少重复查询，保持系统轻量。

这些机制不是可观测的替代品——恰恰相反，它们的效果必须通过可观测来验证。缓存命中率到底多少？修复成功率够不够？熔断器有没有误触发？这些问题只能靠指标和链路追踪来回答。可观测和稳定性机制，一个负责"感知"，一个负责"反应"——前者找到问题，后者解决问题。

Trade-off

四个可观测通道的运维成本不低——Langfuse、AutoMQ、Prometheus 各需独立维护。但 Agentic BI 的"黑盒性"比传统系统更严重——LLM 的行为不可预测，没有全链路可观测就无法排障和改进。对于企业级 Agentic BI，可观测是必需投入，而非可选附件。关键是用 ObservabilityFacade 统一网关降低开发侧成本——开发者只对接一个接口，而非四个。

引申：基石回扣——从 batch_id 到 trace_id

可观测四通道的"安全审计"（谁查了什么数据）是 Ch 11 batch_id 可追溯性的 AI 场景延伸。CDP 平台用 batch_id 贯穿数据管道实现血缘追溯——每个数据批次都有唯一标识，可追溯到来源、处理过程、下游消费。Agentic BI 用 trace_id 贯穿查询全链路实现审计追溯——每次 AI 查询都有完整轨迹（问题→路由→检索→SQL→执行→结果），可追溯到具体的 session_id 和 user_id。

这个延续不是偶然的——医药行业 GxP 合规要求"可归属"（ALCOA+Attributable，Ch 1）：任何数据变更都必须可追溯到操作人。CDP 的 batch_id 满足了"数据管道"的可追溯要求；Agentic BI 的 trace_id 把这个要求延伸到了"AI 查询"——即使 SQL 是 AI 生成的，也必须知道是哪个用户的哪个会话触发的，生成过程经历了哪些节点。可观测不是技术附加，而是合规刚需的延续。

47.4 Roadmap：多租户 RLS、多 Provider 抽象、基准评测¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8'}}}%%
timeline
    title NewtonData 持续演进 Roadmap
    section P0 优先
        多租户 RLS : 不同租户数据隔离
    section P1 重要
        多 Provider 抽象 : 不绑定单一 LLM，可切换/回退
    section P2 增强
        基准评测 : Spider/BIRD 标准评测，量化质量
    section P3 探索
        动态子图 + 多 Agent : 复杂问题拆分给多 Agent 协作

图 47-8 Roadmap：多租户 RLS、多 Provider 抽象、基准评测

优先级	方向	价值
P0	多租户 RLS	支持多业务线/多部门数据隔离
P1	多 Provider 抽象	不绑定单一 LLM，可切换/回退
P2	基准评测	Spider/BIRD 标准评测，量化质量
P3	动态子图 + 多 Agent	复杂问题拆分给多 Agent 协作

表 47-8 Roadmap：多租户 RLS、多 Provider 抽象、基准评测

多 Provider 抽象¶

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#edf5ff','primaryTextColor':'#161616','primaryBorderColor':'#0f62fe','lineColor':'#697077','secondaryColor':'#d9fbfb','tertiaryColor':'#f2f4f8','fontSize':'14px'}}}%%
flowchart LR
 subgraph 多Provider["多 LLM Provider 抽象"]
 REG[Provider 注册表]
 REG --> P1[Provider A<br/>主用]
 REG --> P2[Provider B<br/>备选]
 REG --> P3[Provider C<br/>特定任务]

 AGENT@{ icon: "codicon:hubot", form: "rounded", label: "Agent", pos: "b", h: 36 } -->|调用|REG
 REG -->|故障切换|P2
 end
classDef bpProcess  fill:#edf5ff,stroke:#0f62fe,stroke-width:2px,color:#161616
classDef bpDecision fill:#fcf4d6,stroke:#f1c21b,stroke-width:2px,color:#161616
classDef bpExternal fill:#f2f4f8,stroke:#697077,stroke-width:2px,color:#161616

class AGENT bpProcess
class REG bpDecision
class P1,P2,P3 bpExternal
linkStyle default stroke:#697077,stroke-width:2px
linkStyle 4 stroke:#da1e28,stroke-width:2px,stroke-dasharray:5

图 47-9 多 Provider 抽象

引申

多 Provider 抽象的核心价值是"不把鸡蛋放一个篮子"——LLM 服务可能故障、限流、涨价。抽象层让 Agent 可在不同 Provider 间切换/回退，保证可用性。这也是企业级 AI 系统与"绑定单一 LLM 的 demo"的区别。

引申：基石回扣——P0 多租户 RLS 是 CDP 多租户的延伸

P0 多租户 RLS 不是从零开始的新需求——Ch 37 的 DaaS 已建立了 db_user_{tenant} 多租户隔离，Ch 46 已把这套机制延伸为 ai_agent_as_user_{tenant} 角色。P0 的工作是把它从"单租户验证"推广到"多业务线/多部门正式隔离"——让不同业务线的 AI Agent 只能查自己业务线的数据。这是 CDP 安全骨架在 AI 场景的持续深化，而非全新建设。

47.5 已知局限与失败模式：NewtonData 回答不了什么¶

坦率讲，NewtonData 不是万能的——有一些问题它到现在也回答不好，有些场景它表现就是不行。把这些局限明摆出来，比假装完美更有意义：

局限类型	表现	根因	演进方向
跨库关联	无法 join Redshift 与外部数据源（如临时 Excel）	执行域限于 Redshift 单库	多模态输入→临时表入 Redshift（Ch 39 引申框）
复杂窗口函数	ROW_NUMBER/RANK 跨多维度时准确率下降	窗口语义复杂，LLM 难以正确表达	few-shot 补充 + 窗口函数模板化
非结构化推理	"分析一下处方趋势的原因"类开放问题	超出 NL2SQL 能力，需因果推理	接入分析 Agent + ML 能力（Ch 45 ML 注册表）
实时流查询	无法查询"最近 5 分钟"的实时数据	Redshift 是批处理数仓，非实时	接入 streaming source（Kinesis → 物化视图）
超长复杂查询	10+ 表 join + 多层子查询时准确率降至 ~60%	LLM 上下文限制 + 规划器复杂度	子查询分解 + 分步执行

表 47-9 已知局限与失败模式：NewtonData 回答不了什么

Trade-off

承认局限不是失败，而是"工程诚实"的体现（Ch 52）。把 NewtonData 定位为"覆盖 90% 高频分析查询的助手"而非"万能分析师"，是务实的——剩下 10% 的复杂/开放问题仍需人工分析师。强行让 AI 回答它答不好的问题，只会产生错误结果和用户不信任。明确的边界声明，反而提升了用户对"它能答好的部分"的信任。

本章小结¶

Agent 评估三方法：端到端（整体正确性）/ 轨迹（过程质量）/ 结果（SQL 准确性）——互补使用（AgentBench/Trajectory Evaluation/LLM-as-a-Judge）
三级评估：运行时（三级评估器——纯规则引擎、低延迟、仅 deep_analysis 路由）/ 治理 CI（发布前四维校验）/ LLM-as-a-Judge（定期四维评分：正确性/可解释性/安全性/效率，含 prompt 模板）
DeepEval + Ragas 集成（faithfulness/answer_relevancy/context_precision/context_recall）；资产认证生命周期（draft→reviewed→certified→deprecated + quality_score 驱动检索优先级）；反馈闭环（用户反馈→Admin 审核→Correction Memory/资产修订/Few-shot 审批）
Agentic BI 效果基准：简单查询准确率 95%+、复杂查询 85-90%（Steiner 树提升 12%）、P50 ~8s/P95 ~25s、护栏拦截 ~7%、自愈成功 ~70%、缓存命中 ~35%、满意度 4.2/5
成本分析：LLM API 月成本 ~¥1.5 万，远低于替代的传统 BI 人力（Ch 1 平台经济学）；成本可控靠缓存命中 + 简单查询强路由
可观测四通道：Langfuse（链路追踪）/ AutoMQ（事件流）/ structlog（日志）/ Prometheus（指标）——ObservabilityFacade 统一网关；Prometheus 指标（ttd_pipeline_duration_seconds 等）；运行时稳定性机制（SQL Cache/修复循环/Circuit Breaker/Session 清理/Metadata Cache）
审计可追溯：trace_id 贯穿查询全链路——CDP 的 batch_id 可追溯性（Ch 11）在 AI 场景的延伸
Roadmap：P0 多租户 RLS（Ch 37 DaaS 多租户的延伸）/ P1 多 Provider 抽象 / P2 基准评测 / P3 动态子图+多 Agent
已知局限与工程诚实：跨库关联/复杂窗口函数/非结构化推理/实时流/超长查询——承认局限是 Ch 34/Ch 52 工程诚实传统的延续

下一部分

Part VIII 治理、运维与价值复盘 —— AI 转型讲完了，接下来进入最后一部分：安全合规、监控排障、价值度量与架构师复盘。

Ch 47 评估、可观测与持续演进¶

本章你将学到¶

47.1 Agent 评估方法论¶

三级评估体系¶

三级评估器设计¶

47.2 治理 CI 校验 + LLM-as-a-Judge 多维评估¶

治理 CI 校验¶

LLM-as-a-Judge 四维评估¶

DeepEval + Ragas 集成¶

资产认证生命周期¶

反馈闭环¶

基准评测结果¶

成本分析：LLM API vs 传统 BI 人力 TCO¶

47.3 可观测四通道¶

四通道各司其职¶

运行时稳定性：可观测的"反馈→自愈"闭环¶

47.4 Roadmap：多租户 RLS、多 Provider 抽象、基准评测¶

多 Provider 抽象¶

47.5 已知局限与失败模式：NewtonData 回答不了什么¶

本章小结¶

评论