1. 课程导入与全景认知

当团队把大模型应用从演示环境推进到生产环境时，最先暴露的问题往往不是“模型不够聪明”，而是“我们不知道它现在到底怎么样”。一次 RAG 问答返回了错误答案，是检索没召回正确文档，还是提示词被截断，抑或模型本身产生了幻觉？一次批量推理任务延迟飙升，是 GPU 排队、数据倾斜，还是外部向量库响应变慢？这些问题在传统软件监控体系里很难直接回答，因为 AI 系统的行为由数据、提示词、模型权重、检索索引和运行时资源共同决定，任何一个环节漂移都会改变最终输出。Databricks AI 平台的可观测性与质量治理，正是为这类系统建立“看得见、量得准、管得住”的能力。

一、定义与边界：可观测性不等于质量治理

可观测性（Observability）关注的是“系统内部状态能否由外部信号推断”。在 Databricks AI 平台上，这些信号包括推理请求的输入输出、Token 用量、端到端延迟、检索命中片段、模型版本、GPU 利用率、错误码与重试次数等。它回答的是“发生了什么、在哪里发生、影响多大”。质量治理（Quality Governance）关注的是“输出是否满足业务与合规要求”，包括答案正确性、引用可追溯性、有害内容拦截率、PII 泄露风险、提示词注入防护以及评测集回归结果。它回答的是“这样算不算合格、谁批准上线、出问题如何回滚”。

两者的边界可以这样理解：可观测性提供证据，质量治理依据证据做判断和决策。没有可观测性，质量治理只能靠抽样人工评审，成本高且滞后；没有质量治理，可观测性会退化成“指标很多但没人知道阈值该定多少”。在 Databricks 上，二者共享同一套数据底座——Delta Lake 中的推理日志表、MLflow 的 Run 与 Model Registry、Unity Catalog 的权限与血缘，以及 Lakehouse Monitoring 的统计画像。

二、核心挑战：AI 系统为什么比传统服务更难观测

第一，非确定性。相同输入在不同温度参数或不同模型版本下可能产生不同输出，传统“固定断言”的监控方式失效，必须引入语义相似度、LLM-as-Judge 或人工标注作为评测手段。第二，链路长且跨系统。一次 RAG 请求可能经过网关、检索服务、重排序、提示词组装、模型推理、后处理六个阶段，延迟和错误会在阶段间传递，需要端到端 Trace 才能定位。第三，质量维度难以量化。正确性、忠实性、相关性、安全性没有统一单位，需要为每个业务场景定义可计算的指标和阈值。第四，数据与模型持续漂移。上游文档更新、用户提问分布变化、模型供应商升级，都会让昨天的合格线今天不再适用。第五，成本与延迟的权衡。更大的模型、更长的上下文、更多的检索片段通常提升质量，但也推高 Token 成本和响应时间，治理必须把三者放在同一张决策表里。

三、整体学习地图：从信号采集到闭环治理

本课程后续章节将沿着一条完整的能力链展开：先建立数据与信号采集层（推理日志、Trace、指标），再构建评测与质量度量层（离线评测集、在线 Judge、漂移检测），然后进入治理与运营层（阈值、告警、审批、回滚、成本归因），最后落到典型场景的端到端实践。下图给出这一全景结构，帮助你在学习每一节时知道它位于整条链路的哪个位置。

四、一个可操作的起点：先定义“一次请求的观测契约”

面对庞杂的指标，最有效的切入方式不是一次性建全平台，而是先为一条真实链路定义观测契约。以 Databricks 上的 RAG 问答为例，可以约定每次请求必须落库以下字段：request_id、app_name、model_version、prompt_tokens、completion_tokens、retrieval_doc_ids、retrieval_scores、latency_ms、judge_faithfulness、judge_relevance、safety_flag、error_code。这些字段一旦稳定写入 Delta 表，后续的漂移检测、成本归因、质量看板才有共同的数据基础。

-- 示例：推理日志表结构（字段为教学示例，非实测结果）
CREATE TABLE ai_obs.inference_log (
  request_id        STRING,
  app_name          STRING,
  model_version     STRING,
  prompt_tokens     INT,
  completion_tokens INT,
  retrieval_doc_ids ARRAY<STRING>,
  retrieval_scores  ARRAY<DOUBLE>,
  latency_ms        INT,
  judge_faithfulness DOUBLE,
  judge_relevance    DOUBLE,
  safety_flag       BOOLEAN,
  error_code        STRING,
  event_time        TIMESTAMP
) USING DELTA;

有了这张表，就可以用一条 SQL 得到最基础的治理视图：按应用统计近一小时的请求量、P95 延迟、平均忠实性得分与安全拦截率。当某个应用的忠实性得分从 0.85 掉到 0.62，同时检索得分中位数同步下降，基本可以判断问题出在检索侧而非模型侧；如果检索得分稳定而忠实性下降，则应检查提示词模板或模型版本是否变更。这种“指标组合 + 归因方向”的判断方式，是本课程贯穿始终的分析方法。

五、本课程的能力目标

完成本课程后，你应当能够：为 Databricks AI 应用设计可落地的观测字段与日志表；使用 MLflow 与 Lakehouse Monitoring 建立评测与漂移检测流程；定义质量阈值、告警规则与发布门禁；在 RAG、批量推理与 Agent 三类场景中完成从信号采集到问题归因的闭环；并在成本、延迟与质量之间做出有依据的权衡决策。可观测性与质量治理不是一次性项目，而是伴随 AI 应用持续演进的运营能力——先让系统“说得清自己发生了什么”，再让它“证明自己足够好”。