AI 回答好不好怎么评估？别只凭感觉说“还行”

AI 回答最迷惑人的地方，是它经常写得很顺。顺口不代表正确，完整不代表可用，语气专业也不代表有依据。做 AI 应用时，如果只凭感觉说“这个回答还行”，很容易上线后才发现问题：答非所问、引用错资料、格式不稳定、遇到边界问题乱编、用户换个问法就失效。

评估 AI 输出，至少要看七个维度：是否回答了问题，事实是否准确，是否基于给定资料，是否遗漏关键步骤，表达是否清楚，格式是否符合要求，遇到资料不足时是否能说明不知道。不同场景权重不同。客服问答更重准确和边界，内容写作更重表达和可读性，结构化抽取更重格式稳定。

评估不是为了挑刺，而是为了知道系统哪里需要改。一个回答不好，可能是资料不清楚、检索没命中、提示词不明确、输出格式没约束，也可能是模型本身能力不足。只有拆开看，才知道应该改哪里。

没有测试集，就很难评估。测试集不需要一开始很大，但要真实。可以从用户搜索词、客服记录、站内反馈、自己常见工作任务里整理 30 到 100 个问题。每个问题最好标注期望答案、相关资料、不可接受的错误。这样后续每次改提示词、换模型、改资料，都能重新跑一遍对比。

测试问题要覆盖几类：高频问题、换说法的问题、边界问题、资料没有答案的问题、容易混淆的问题、格式要求严格的问题。比如企业知识库问答，不仅要问“怎么退款”，还要问“买错套餐能不能退”“超过7天怎么办”“资料里没有写的情况怎么办”。这些问题比标准问法更能暴露系统稳定性。

对 RAG 应用来说，测试集还要标注理想命中的资料。评估时先看检索结果，再看最终回答。如果检索没命中正确资料，模型后面答得再漂亮也不可靠。如果检索命中了，但回答仍然错，才重点看提示词和模型输出。

最简单的评分可以用 0、1、2 三档。0 分表示不可用，1 分表示部分可用但需要明显修改，2 分表示基本可用。每个维度单独打分，比如准确性、完整性、可执行性、格式、边界说明。不要只给一个总分，否则不知道问题在哪。

例如一个知识库问答可以这样评估：准确性 2 分，表示没有事实错误；引用 1 分，表示提到了来源但不够具体；完整性 1 分，表示漏了申请时限；边界 2 分，表示资料不足时没有编造。这样一看就知道下一步应该补资料或改引用格式，而不是盲目换模型。

如果输出是 JSON、表格或固定模板，还要检查格式稳定性。很多 AI 在普通对话里表现不错，一要求输出 JSON 就可能多一句解释、漏引号、字段名不一致。正式系统里，这些都算失败。可以把输出放到 JSON 工具里校验，或者在程序里做 schema 检查。

成功样本能让人有信心，失败样本才能推动改进。每次发现 AI 回答错，不要只改一下提示词就过去。应该记录问题、输入材料、检索结果、模型回答、错误类型、修复方式。积累一段时间后，你会发现错误往往集中在几个地方。

常见错误类型包括：问题理解错，资料检索错，资料本身过期，多个资料冲突，模型没有遵守格式，模型编造不存在的依据，回答太泛，遗漏关键限制。每种错误的修复方式不同。比如资料过期要改知识库，格式不稳要改输出约束，检索错要改切片或关键词，回答太泛要补示例。

失败样本还可以变成新的测试集。以后每次调整系统，都要确认老问题没有复发。AI 应用不是一次调好就结束，它需要像产品一样持续回归测试。尤其是企业知识库、客服、Agent 工具调用这类场景，回归测试非常重要。

离线测试通过，不代表真实用户一定满意。用户会用你想不到的说法提问，会省略上下文，会问超出范围的问题，也会把多个问题塞在一句话里。上线后要观察追问率、人工转接率、点赞点踩、复制率、工具调用成功率和失败日志。

评估指标不要太多，但要能指导行动。比如知识库问答可以看“有依据回答率”和“无依据拒答率”；内容助手可以看“用户是否继续编辑”和“是否复制使用”；Agent 可以看“工具调用成功率”“人工确认次数”“失败回退次数”。指标要和业务目标相关，不要为了好看而统计。

最后，评估结果要回到改进动作。发现用户总问某个资料没有的问题，就补文档；发现格式经常错，就加强结构化输出；发现回答太长，就调整长度；发现敏感问题处理不稳，就加规则和人工审核。AI 评估的价值，不是给模型打分，而是让产品越来越稳。