AI应用的测试链路：从感觉验证到指标量化

AI应用说到底还是软件工程，但它的非确定性让传统的“跑通一次”根本站不住脚。做NL2SQL或RAG功能时，最棘手的点是模型对微小输入变化会大幅偏移。我把测试逻辑从“看感觉”换成了“看指标”。

构建低成本黄金评测集

搭建低成本评测集，别靠随机测试，得建黄金用例集。用JSON定义测试用例，字段是input和expected_contains，用断言检查输出是否覆盖预期关键字。

test_cases = [
  {
    "input": "Find the top 10 customers by revenue.",
    "expected_contains": ["GROUP BY", "ORDER BY", "LIMIT"]
  },
  {
    "input": "Find revenue for 2025 excluding cancelled orders.",
    "expected_contains": ["2025", "cancelled"]
  },
]

跑评测脚本时，输出缺关键字就记Failure并打印Diff。改Prompt或换模型（比如从GPT-4o切到Claude 3.5），跑一遍评测集就能看到通过率涨跌，不用靠猜。

把Prompt当代码管理

Prompt要当代码管，必须进版本系统。禁止在代码里硬编码Prompt，走的是Prompt v1 -> Evaluation -> Results -> Prompt v2闭环。优化Prompt必须附评测报告，新版本通过率不如旧版，就算个别Case更自然也不合并。

RAG幻觉的真正来源

RAG链路里很多报错不是Prompt的锅，是上下文污染。调试时发现，检索阶段喂给模型的5个片段里混进过期或无关文档，模型就会严重幻觉。所以测试焦点从“问了什么”转移到“喂了什么”。

实操上，测试日志里强制打印retrieved_context。模型胡说八道时先检查检索到的Context对不对。Context错了就优化Embedding模型或检索算法，别瞎改Prompt。

用CI流程防止功能退化

多步Agent或工具调用链，中间任何一环偏移都会被放大。把评测脚本集成到GitHub Actions的CI流程，PR合并前自动跑评测集，通过率直接卡Merge门槛。

# 模拟 CI 评测命令
pytest tests/eval_llm_performance.py --threshold 0.95

通过率低于95%，CI就返回Exit Code 1，构建失败。这强制开发者在提交代码前确保功能没退化，把AI开发从炼金术变成可预测的软件工程。