AI 开发的软件质量如何保证？一套可落地的 LLM 应用质量工程体系（QA 视角）

0. 先说结论

AI（尤其是 LLM）参与开发的软件，质量保障的本质变化只有一句话：从"验证确定性输出"变成"评估概率性表现"。

传统测试的核心是"断言"------给定输入，必有唯一正确的输出，写个 assertEquals 就完事。但 LLM 应用的输出是概率分布采样的结果，"正确"的定义本身在漂移：同一 prompt 两次输出不同、不同模型版本表现不同、知识库更新后答案跟着变、用户换个问法模型就 hallucinate。

所以保证 AI 软件质量，靠的不是多加几个测试用例，而是建立一套 Evaluation-driven（评测驱动） 的质量工程体系：

复制代码

下面逐层拆开讲。每一步都给可落地的做法，不谈虚的。

1. 为什么传统测试方法论在 LLM 应用上失效了

1.1 本质差异：确定性 vs 概率性

|-------|---------------|----------------------------|
| 维度 | 传统软件 | LLM 应用 |
| 输出确定性 | 确定（同输入必同输出） | 概率（同输入可不同输出） |
| 正确性定义 | 唯一/有限正确集 | 多解合理，需"评分"而非"判等" |
| 失败模式 | 崩溃 / 异常 / 逻辑错 | 幻觉 / 偏见 / 越权 / 退化 |
| 回归测试 | diff 比对即可 | 需语义层面评估，diff 无意义 |
| 质量维度 | 功能/性能/兼容/安全 | 叠加事实性/安全性/一致性/成本 |
| 缺陷根因 | 代码 bug | prompt / 数据 / 模型 / 链路任一环节 |

一句话：传统测试的"断言"在 LLM 上要么太严（把合理的不同表达判错），要么太松（对幻觉完全无感）。

1.2 质量维度爆炸

LLM 应用除了传统质量维度，还要额外管这几类原传统测试不擅长的事：

事实性（Faithfulness）：有没有编造不存在的信息、有没有引用错来源。

安全性（Safety）：提示注入、越权执行、敏感信息泄露。

一致性（Consistency）：同一问题换种说法，答案逻辑是否自洽。

合规性：内容是否触红线、是否按要求做 AI 生成标识。

成本/延迟：token 消耗、首字延迟、吞吐，直接关系商业可行性。

这些维度无法用传统断言覆盖，必须引入"评估"。

2. LLM 应用质量风险地图

保障质量的第一步是先盘风险，再谈保障。下面是一张可复用的风险矩阵，按"发生可能性 × 业务影响 × 可检测性"三维度标注。

|------------------------|----------------------|-----|----|--------------|
| 风险类别 | 典型表现 | 可能性 | 影响 | 主要检测手段 |
| 幻觉（Hallucination） | 编造政策、虚构接口、错引文档 | 高 | 高 | 事实性评测 / 引用校验 |
| 提示注入（Prompt Injection） | 越权执行指令、泄露系统 prompt | 高 | 高 | 对抗评测集 / 安全扫描 |
| 知识过时 / 退化（Drift） | 模型或知识库更新后表现下滑 | 中 | 高 | 在线评测 / 指标监控 |
| 隐私泄露 | 输出训练/上下文中的敏感数据 | 中 | 极高 | 敏感信息扫描 / 红队 |
| 偏见歧视 | 输出带性别/地域/职业刻板印象 | 中 | 高 | 偏见评测集 |
| 成本失控 | token 暴涨、循环调用、长上下文滥用 | 中 | 中 | 用量监控 / 预算熔断 |
| 合规触线 | 未标识 AI 内容、违规行业话术 | 低 | 极高 | 合规规则引擎 |

QA 团队要做的第一件事，就是基于这张图，给自己的产品画一张定制版风险矩阵，并标注每类风险的"兜底检测责任人"。

3. 范式转移：从"断言"到"评估"

3.1 Evaluation-driven 的核心思想

把"测试"升级为"评测"：不再问"输出等不等于标准答案"，而是问"输出在多个质量维度上打几分"。

评测的三要素：

复制代码

评分器分三类，组合使用：

规则型（Rule-based）：正则、关键词、JSON schema 校验、长度/格式约束。便宜、确定、可解释。

模型型（LLM-as-Judge）：用另一个强模型对照参考答案给分。覆盖语义、事实性、安全性，但有成本和偏见。

人工型（Human）：难例、线上抽检、争议样本复核。作为"真值锚点"校准自动评分器。

3.2 三层评测结构

复制代码

graph TD
    A[单元级评测<br/>单 Prompt / 单工具调用] --> B[链路级评测<br/>RAG 召回→生成 / 多智能体协作]
    B --> C[系统级评测<br/>端到端业务场景]
    C --> D[质量门禁 Gate]
    D --> E[上线灰度]
    E --> F[线上监控 / 用户反馈]
    F -->|回流| A

单元级：单个 prompt 模板、单个工具调用的输入输出质量。粒度最细，回归最快。

链路级：RAG 链路（召回→重排→拼上下文→生成）、多智能体编排的协作质量。

系统级：端到端模拟真实用户请求，看业务目标是否达成。

3.3 评测集建设（最值钱也最容易被忽视）

没有评测集，评测就是空转。评测集分三层：

|------------------|----------------|---------|
| 评测集类型 | 作用 | 维护方式 |
| Golden Set（黄金集） | 核心场景的"标准答案"基线 | 人工精标，慢增 |
| 难例集（Hard Cases） | 历史翻车样本、边界 case | 从线上问题回流 |
| 对抗集（Adversarial） | 提示注入、越权、诱导泄露 | 红队持续补充 |

经验法则：Golden Set 保"不退化"，难例集保"修过的坑不再犯"，对抗集保"不被攻破"。三者缺一不可。

3.4 一个最小可运行的评测骨架

复制代码

这只是规则型的最小骨架。真实项目里，把 rule_score 换成"规则 + LLM-Judge 混合"，把 CASES 换成 Golden/Hard/Adversarial 三套集，就是一条可进 CI 的评测流水线。

4. RAG 质量专项：知识密集型应用的生命线

RAG（检索增强生成）是当前企业落地最多的形态，它的质量短板几乎都在"检索"而非"生成"。

4.1 RAG 质量三道关

复制代码

graph LR
    Q[用户问题] --> R[召回 Recall]
    R --> Re[重排 ReRank]
    Re --> C[上下文拼装 Context]
    C --> G[生成 Generation]
    G --> A[答案 Answer]

    R -. 召回命中率 .-> M[质量指标]
    C -. 上下文相关度/污染 .-> M
    A -. 引用准确率/事实性 .-> M

4.2 关键指标

|---------------------------|----------------------|------------------|
| 指标 | 定义 | 检测方式 |
| 召回命中率（Hit Rate） | 相关文档是否进 Top-K | 基于标注的相关文档集 |
| 上下文相关度（Context Relevance） | 拼进 prompt 的内容是否和问题相关 | LLM-Judge |
| 引用准确率（Citation Accuracy） | 答案引用的片段是否真实支撑结论 | 规则 + 人工 |
| 事实性（Faithfulness） | 答案是否忠于上下文、未编造 | LLM-Judge + 事实校验 |

4.3 知识库治理是 QA 的隐藏战场

很多 RAG 翻车不是模型问题，是知识库脏：过期文档没下架、重复文档互相矛盾、权限文档越权召回。QA 要推动建立：

文档版本与有效期管理；

召回结果的权限隔离校验（用户 A 不能召回到用户 B 的私有文档）；

上下文污染防控（无关文档拼进 prompt 会带偏生成）。

5. Prompt 质量与版本管理：把 Prompt 当代码管

Prompt 是最容易被轻视、却最容易引入回归的"代码"。

5.1 Prompt-as-Code 三条铁律

版本化：每个 prompt 模板进 Git，改一次提一次 PR，带 diff 评审。

回归测试：prompt 改动必须跑全量评测集，性能回退禁止合入。

可观测：线上记录每次请求使用的 prompt 版本，出问题可精准回滚。

5.2 Prompt 回归流水线

复制代码

graph TD
    P[Prompt 改动 PR] --> T[自动跑评测集]
    T -->|通过| M[合入 main]
    T -->|回退| R[打回修改]
    M --> D[记录版本号]
    D --> O[线上标注 prompt_version]

一套最小实践：在 prompt 模板文件头部写 version: v1.3.2，评测脚本读取该版本跑分，CI 里设置"事实性 ≥ 0.9 且安全性 = 1.0 才允许合入"。

6. 模型退化监控：上线才是质量战争的开始

模型一上线，质量就进入"持续劣化"的常态：模型供应商悄悄升级、知识库变了、用户群体迁移导致问法变化。

6.1 在线评测闭环

复制代码

graph LR
    U[真实用户请求] --> S[系统响应]
    S --> L[日志埋点]
    L --> E[定时抽样评测]
    E --> D[指标看板]
    D -->|异常| A[告警]
    A --> F[回流难例集]
    F --> R[重新训练/调 prompt]

6.2 三个必须监控的信号

性能漂移（Performance Drift）：核心评测集分数周环比下滑超过阈值（如 3%）即告警。

成本漂移（Cost Drift）：单请求 token 均价异常上涨，往往是 prompt 膨胀或循环调用。

用户信号：点赞/点踩、会话中断率、转人工率------最真实的"质量温度计"。

6.3 灰度与影子评测

新模型 / 新 prompt 上线前，先走影子流量（Shadow）：用真实请求跑新版本但不对外返回，对比新旧版本评测分，确认无回归再放量。

7. 安全与合规：QA 必须卡住的最后一道门

这一层不是"加分项"，是红线。以下任一项翻车，可能直接封号或违法。

|-----------|------------------------|---------------|
| 红线 | 说明 | QA 动作 |
| 提示注入防护 | 用户输入诱导模型越权/泄露系统 prompt | 对抗评测集 + 输入过滤 |
| 越权执行 | 模型调用了无权限的工具/接口 | 工具权限矩阵 + 调用审计 |
| 敏感信息泄露 | 输出含 PII / 内部数据 | 输出扫描 + 脱敏 |
| AI 生成内容标识 | 按《AI 生成内容标识办法》显式标注 | 输出端强制打标 |
| 行业合规话术 | 金融/医疗/教育等领域禁用违规表述 | 规则引擎 + 人工审核 |

安全评测必须进质量门禁的强制卡点：安全项不通过，一律不得发布。

8. 质量门禁：把上面所有东西串成 Gate

把你已有的 SDD 质量门禁矩阵 直接平移到 LLM 应用，稍作语义改造即可复用：

复制代码

graph TD
    G0[Gate-0 需求门<br/>评测集与需求对齐<br/>明确质量维度与阈值] --> G1[Gate-1 契约门<br/>Prompt 版本契约<br/>接口/工具权限契约]
    G1 --> G2[Gate-2 专项门<br/>安全/对抗评测<br/>事实性/偏见评测]
    G2 --> G3[Gate-3 发布门<br/>线上监控预案<br/>灰度/影子评测报告]

Gate-0（Spec）：需求评审时就必须定义"怎么算质量达标"，并配套初始化评测集，而不是上线后再补。

Gate-1（Contract）：prompt 版本、工具调用契约、知识库版本，全部锁定可追溯。

Gate-2（Special）：安全、事实性、偏见等专项评测，强制卡点，不通过不发布。

Gate-3（Release）：上线前提交线上监控预案 + 灰度/影子评测报告。

这套门禁可以直接沉到你正在做的"AI 原生智能化测试平台"里，作为 LLM 应用的质量基线。

9. 工程化落地：评测流水线 + 质量左移

9.1 持续评测流水线（进 CI）

理想形态：每次 prompt / 知识库 / 模型改动，自动触发三层评测，分数写入看板，回退自动拦截。

复制代码

9.2 质量度量体系（KPI）

|----------|--------------|----------|
| 指标 | 说明 | 健康参考（行业） |
| 评测集覆盖率 | 核心场景被评测集覆盖比例 | ≥ 80% |
| 事实性得分 | 答案忠于知识库的比例 | ≥ 0.9 |
| 安全通过率 | 对抗集零越权 | = 1.0 |
| 回归阻断率 | 门禁拦住的坏变更占比 | 越高越好 |
| 线上退化告警时延 | 从退化发生到告警 | < 24h |

9.3 质量左移

质量不是测试阶段才介入。需求阶段定评测标准、开发阶段写评测用例、CI 阶段跑评测、线上阶段监控回流------评测集与代码同生命周期。

10. 组织与 ROI：质量工程不是成本中心

10.1 用 AI 工程栈六层地图分工

把你熟悉的 AI 工程栈六层地图（L0 模型 / L1 协议 / L2 单智能体执行 / L3 多智能体编排 / L4 工程方法 / L5 组织治理） 映射到质量责任：

L0~L2：重点管单元级评测 + 工具调用正确性。

L3：重点管多智能体协作的一致性与越权。

L4（工程方法）：评测体系、门禁、流水线落地点。

L5（组织治理）：质量度量、合规红线、跨团队标准。

质量工程不是某一层的事，是 L0→L5 全栈贯穿。测试团队真正的价值，是从"执行层（L2）"上探到"工程方法（L4）"和"组织治理（L5）"。

10.2 ROI 怎么算

质量工程的投入产出，用这个公式对齐老板：

复制代码

早期重建设（评测集 + 门禁），中期重自动化（流水线 + 监控），后期重治理（标准 + 度量）。

11. 结语：QA 在 AI 时代的位置

AI 不会让测试消失，只会淘汰只会写断言的测试。

LLM 应用质量工程的本质，是把测试从"找 bug"升级为"建度量、设门禁、盯退化"。谁能建立这套评测驱动的体系，谁就握住了 AI 软件质量的命脉。

落地优先级建议（按投入产出排序）：

🔴 必做：评测集建设（Golden + Hard + Adversarial）+ 质量门禁 Gate-2 安全卡点。

🟠 重点：RAG 召回质量评测 + Prompt 版本回归。

🟢 进阶：线上退化监控 + 影子评测 + 多智能体协作评测。