2026年，大模型应用正处在一个关键的转折点上：从“人工体验效果”向“自动化质量评测”过渡。
回想一下，过去团队评估一个大模型应用好不好用，流程其实很原始。开发者准备几个问题，人工试一遍，看看模型回答是否准确、流畅，是否符合业务要求。如果感觉还行，那就推上线继续观察。坦白说，这种“投石问路”的方式在早期Demo阶段确实够用。
但一旦应用进入真实业务系统，人工试问的短板就暴露无遗。随便列举几个场景，你就会明白为什么自动化评测势在必行：
- Prompt修改后，回答质量有没有下降？
- RAG知识库更新后，答案是否还靠谱？
- 模型版本切换后，输出格式还能不能稳住？
- Agent工具调用结果被正确利用了吗？
- 安全规则更新后，敏感输出是否依然被牢牢卡住？
这些问题的答案，都指向同一个方向：自动化评测。所以，大模型评测系统正在成为AI工程化不可或缺的新基础设施。它的定位不是要完全取代人工，而是在每一次模型、Prompt、知识库或工具链发生变化后，自动运行测试集，快速发现回答质量是否出现了退化。
一、为什么大模型应用需要回归测试？
传统软件开发中，代码修改后必须跑一遍测试，这是常识。大模型应用其实也一样，只不过它测试的不是函数返回值，而是一系列更复杂的维度：回答质量、格式稳定性、事实一致性、安全合规性，以及业务可用性。
一个成熟的大模型应用，至少需要覆盖以下几个测试点：
- 回答是否包含了关键信息；
- 回答是否符合指定的输出格式；
- 回答是否引用了正确资料；
- 回答中是否出现了敏感内容；
- 回答是否拒绝了本不该回答的问题；
- 回答长度是否稳定；
- 关键业务问题是否持续命中。
为了让你更直观地理解这套机制，下面用Python搭建一个简化版的大模型回答质量评测系统。
二、基础配置：定义评测用例
第一步，定义测试用例。每个用例都需要明确：用户问题、参考资料、期望关键词、禁止词，以及输出格式要求。
import json
import re
from datetime import datetime
TEST_CASES = [
{
"case_id": "case_001",
"question": "RAG 系统为什么需要内容清洗？",
"context": "网页中常常包含导航栏、广告、重复段落和登录提示，RAG 系统需要清洗正文后再入库。",
"expected_keywords": ["RAG", "内容清洗", "正文"],
"forbidden_keywords": ["无法回答", "不知道"],
"required_format": "paragraph"
},
{
"case_id": "case_002",
"question": "Serverless Agent 适合什么任务？",
"context": "Serverless Agent 适合短任务、事件驱动任务和按需执行的轻量智能任务。",
"expected_keywords": ["Serverless", "短任务", "事件驱动"],
"forbidden_keywords": ["数据库删除", "敏感信息"],
"required_format": "paragraph"
},
{
"case_id": "case_003",
"question": "AI 可观测性需要关注哪些指标？",
"context": "AI 可观测性需要关注响应时间、Token 消耗、RAG 召回数量、工具调用成功率和错误类型。",
"expected_keywords": ["响应时间", "Token", "工具调用"],
"forbidden_keywords": ["身份证", "密码", "密钥"],
"required_format": "list"
}
]
测试用例是整个评测系统的核心。没有一套稳定的测试集，你很难判断模型效果到底是变好了还是变差了——感觉是最大的敌人。
三、模拟模型回答
第二步，模拟大模型回答。真实场景中，这里会替换成模型API调用。为了清晰演示流程，我们先用规则生成模拟回答。
def fake_model_answer(question, context):
if "可观测性" in question:
return """1. 需要关注响应时间；
2. 需要关注 Token 消耗；
3. 需要关注工具调用成功率；
4. 需要关注错误类型。"""
if "Serverless" in question:
return (
"Serverless Agent 适合短任务、事件驱动任务和按需执行场景。"
"它可以在任务触发时启动，任务完成后释放资源。"
)
if "RAG" in question:
return (
"RAG 系统需要内容清洗，因为网页中常常包含导航栏、广告、"
"重复段落和登录提示。只有提取干净正文后，知识库检索效果才会更稳定。"
)
return "无法回答。"
可以看出，这个评测系统并不关心回答具体是由哪个模型生成的，它只关心最终结果是否符合预设的质量标准。
四、关键词命中评测
第三步，判断回答是否包含期望关键词。这种评测方法虽然简单，但对于业务关键问题却非常有效。
def evaluate_expected_keywords(answer, expected_keywords):
hits = []
for keyword in expected_keywords:
if keyword in answer:
hits.append(keyword)
score = 0
if expected_keywords:
score = round(
len(hits) / len(expected_keywords) * 100,
2
)
return {
"score": score,
"hits": hits,
"missing": [
keyword for keyword in expected_keywords
if keyword not in hits
]
}
关键词命中不代表回答完全正确，但它能保证关键业务信息没有丢失。对于企业知识库问答来说，这一步的意义不言而喻。
五、禁止词检测
第四步是禁止词检测。如果回答中间出现了敏感词、错误表述，或者不允许输出的内容，就需要扣分，甚至直接判定失败。
def evaluate_forbidden_keywords(answer, forbidden_keywords):
hits = []
for keyword in forbidden_keywords:
if keyword in answer:
hits.append(keyword)
passed = len(hits) == 0
return {
"passed": passed,
"hits": hits,
"score": 100 if passed else 0
}
禁止词检测可以作为安全评测的第一道防线。在真实环境中，还可以继续接入敏感信息识别、越权内容检测以及政策规则检查，层层加固。
六、格式评测
第五步，检查输出格式。很多业务系统要求模型输出指定格式——列表、JSON、表格或固定段落。格式一旦不稳定，后续系统解析就会出问题。
def evaluate_format(answer, required_format):
if required_format == "list":
has_list = bool(
re.search(r"^\s*\d\..*", answer, re.MULTILINE)
)
return {
"passed": has_list,
"score": 100 if has_list else 30,
"format": required_format
}
if required_format == "paragraph":
lines = [
line for line in answer.split("\n")
if line.strip()
]
passed = len(lines) <= 3
return {
"passed": passed,
"score": 100 if passed else 60,
"format": required_format
}
return {
"passed": True,
"score": 100,
"format": required_format
}
格式稳定性是大模型应用上线后最常见的问题之一。特别是当模型输出要进入自动化处理流程时，格式的规范性比文采更重要。
七、单条用例评测
第六步，对单条测试用例进行综合评测。系统会同时计算关键词分、禁止词分和格式分，并加权得出最终得分。
def evaluate_case(case):
answer = fake_model_answer(
question=case["question"],
context=case["context"]
)
keyword_result = evaluate_expected_keywords(
answer,
case["expected_keywords"]
)
forbidden_result = evaluate_forbidden_keywords(
answer,
case["forbidden_keywords"]
)
format_result = evaluate_format(
answer,
case["required_format"]
)
final_score = round(
keyword_result["score"] * 0.5
+ forbidden_result["score"] * 0.3
+ format_result["score"] * 0.2,
2
)
passed = final_score >= 80 and forbidden_result["passed"]
return {
"case_id": case["case_id"],
"question": case["question"],
"answer": answer,
"keyword_result": keyword_result,
"forbidden_result": forbidden_result,
"format_result": format_result,
"final_score": final_score,
"passed": passed
}
综合评分能让评测结果更贴近真实的质量判断。只看关键词，可能忽略安全问题；只看安全，又可能漏掉业务效果——两者缺一不可。
八、批量评测与报告生成
最后一步，批量运行测试集，并生成一份清晰的评测报告。
def run_evaluation(test_cases):
details = []
for case in test_cases:
result = evaluate_case(case)
details.append(result)
total = len(details)
passed_count = sum(
1 for item in details
if item["passed"]
)
a vg_score = 0
if total > 0:
a vg_score = round(
sum(item["final_score"] for item in details) / total,
2
)
pass_rate = 0
if total > 0:
pass_rate = round(
passed_count / total * 100,
2
)
report = {
"report_name": "大模型回答质量自动评测报告",
"total_cases": total,
"passed_cases": passed_count,
"pass_rate": pass_rate,
"a vg_score": a vg_score,
"details": details,
"generate_time": datetime.now().isoformat()
}
return report
if __name__ == "__main__":
report = run_evaluation(TEST_CASES)
print(json.dumps(
report,
ensure_ascii=False,
indent=2
))
九、趋势判断
从这套流程可以看出，大模型评测正在成为AI应用工程化中不可回避的关键环节。过去，团队更多依赖人工试问来“感觉”效果；未来，团队需要像测试传统代码一样，系统地测试模型回答。
Prompt修改、模型切换、知识库更新、工具链调整——每一次变更，都应该触发自动化评测。这会让大模型应用从一个“感觉效果不错”的状态，走向“有数据证明稳定”的成熟阶段。
可以预见的是，AI应用的竞争不会只停留在模型能力的比拼上，评测体系是否完善同样是一个重要的分水岭。谁能更早建立起稳定的自动化评测系统，谁就更容易把大模型应用稳妥地推向生产环境，在真实业务中赢得先机。
