自建 AI 对话应用测试框架：从题库设计到自动校验的实践
导读：这篇文章讲的是一套自建的大模型对话应用测试框架，解决"用什么数据测、怎么接入被测对象、如何判定结果对错"的问题，核心由持续维护的题库（单轮/多轮/业务金标/安全四类）、即选即用的机器人接入和双通道结果校验三块拼图组成。关键结论是校验优先用"余弦相似度初筛 + 结构化比对的 LLM 评判"：相比初版自由式评审，token 消耗降为约四分之一（每段对话从约 1250 token 降到约 300 token），且结构化判定思路具备跨模型通用性；同时自动校验之外必须保留人工修正兜底。适合负责 LLM 对话应用质量保障、想做自动化评测的工程师与面试官。
分类：AI应用 ｜ 标签：AI应用、对话测试、测试框架、自动化校验
一、为什么需要一套对话应用测试框架
随着大语言模型（LLM）在企业间的广泛应用，越来越多的业务开始接入对话机器人。随之而来的问题是：如何对模型的能力进行标准化判定？如何在提示词调优前后，快速对比模型能力的变化？
参考对话模型产品的测试方法，核心要回答的其实是四个问题：
- 是否满足业务功能
- 是否能应对未知问题
- 是否会泄露敏感信息
- 是否能应对舆情问题
落到具体接入场景，又衍生出三类典型诉求：
- 高频问题库：录入的问题如何快速校验正确性？大模型针对相似问题如何作答？未知问题是否能够走兜底逻辑？
- 智能初筛机器人：多轮对话如何快速测试？提示词优化后如何快速验证效果？
- 其他机器人实例：包括基于开源框架搭建的对话服务（如 FastGPT）与本地部署模型，如何统一纳入测试？
这些问题靠人工一条条点验是撑不住的，于是我们自建了一套测试框架，把"用什么数据测试、怎么接入被测对象、如何判定结果对错"串成一条流水线。
二、框架的核心：三块拼图
1. 不断维护的测试题库
题库是测试的地基，按类型可分为：
- 单轮用例：一问一答，覆盖广、见效快；
- 多轮用例：模拟真实多轮对话，验证上下文记忆与追问能力；
- 业务类题目（金标答案）：如用户端高频问题、智能初筛等场景，每条题目配有期望答案作为"标准答案"；
- 安全类题目：敏感词、敏感信息泄露、越权应答等专项验证。
题库不是一次性建完就结束的，它需要持续维护：随着业务迭代、模型调优不断补充和更新，复用性会越来越强。
2. 机器人选择即用：接入零成本
测试时不需要写任何代码，只需要三步：
- 选择题库
- 选择被测机器人
- 选择测试方法（若被测机器人支持自定义提示词，还可以选择一个自己的提示词来测试）
这种"即选即用"方式的好处是：任何接入的机器人，都能用同一套题库快速跑一遍，从而横向比较不同模型在同一批题目上的表现差异，也方便调优前后的 A/B 对比。
3. 结果自动校验：双通道判定
判定"AI 的回答是否接近期望答案"，框架提供两条通道：
通道一：余弦相似度
将预设答案与模型回答分别向量化，计算余弦相似度，用分数衡量两者的语义接近程度。速度快、成本低，适合大批量初筛。
通道二：大模型评判（LLM-as-Judge）
初版的思路是"一股脑把大模型和用户之间的对话丢给大模型，并给它设定提示词进行校验"。这种自由式评审的优点是复用性强，缺点也很明显：提示词需要足够精准，覆盖全面需要大量设定、比较冗余，而且 token 消耗大——按一个汉字平均 1.2 个 token 估算，一段对话预计消耗约 1250 token，按 50 段对话、每段跑 3 次估算，一轮约 18.75 万 token。
后来改为结构化比对：设定固定字段结构，让大模型按固定工作流逐字段判定，从"自由评论"变成"结构化判定"：
- 优点：把大模型的回答与预设答案做语境、语义的对比，结果更清晰；便于 case 的设计与维护；token 消耗大幅下降，每段对话约 300 token，同样规模一轮约 4.5 万 token，成本约为自由式评审的四分之一；
- 缺点：测试方向受个人设计影响较大——字段怎么拆、怎么比，决定了整个判定口径。
结构化判定的提示词示例如下（字段可按业务场景替换）：
角色定义：你是一个文本对比与解析专家，能够对两段内容作出相似度判断；
目标设定：根据我提供的 contextA、contextB两段文案，按照下方工作流程得出两段内容的相似度结论；
说明：contextA、contextB均为Json格式内容；
工作流程：
1、依次对比contextA、contextB中的字段名称是否完全一致，如果不相同，回复N，如果相同，继续下一步；
2、除detailField、summaryField两个字段以外，依次对比contextA、contextB中其他字段的值所表达的意思是否一致，若至少有一处意思不相同，回复N且流程结束；若全部相同，继续下一步；
3、对于detailField（地址类信息），判断contextB中的地址内容是否与contextA中的地址内容一致，若是继续下一步，若地址不符回复N且流程结束；
4、对于summaryField（总结类信息），判断contextB表达的内容是否包含contextA中的关键词，若全部包含回复Y，若未全部包含回复N；
限制条件：
1、需要具体分析；
2、严格按照工作流程执行；
3、内容相同但顺序不同，可以认为它们是相同。
该提示词在 Kimi、通义千问等不同模型上均能得到符合预期的判定结果，说明"结构化判定"的思路具备跨模型通用性。
4. 人工修正兜底
自动校验不是终点。当模型判定结果不理想、或自动校验难以覆盖特殊场景时，支持人工修正：进入执行结果详情页，逐条核对分数与判定结论，必要时手动调整结果。自动打分 + 人工兜底，兼顾效率与准确。
三、功能盘点
1. 题库
支持 Excel 导入，覆盖：
- 单轮问答导入
- 多轮问答导入
2. 任务
- 创建测试任务：需要测试一个机器人时创建；
- 执行测试任务：创建后即可执行（若被测机器人支持自定义提示词，可选择自己的提示词来测试）；
- 执行结果详情页：任务执行完成后查看详情，逐条核对相似度分数与大模型判定结果，必要时进行人工修正。
四、落地建议与踩坑提醒
- 题库要持续维护，别一锤子买卖：单轮、多轮、业务、安全四类题目都要覆盖，业务场景变化后及时补充金标答案，否则自动化跑得再快，测的也是过期题目。
- 两条校验通道互补使用：先用余弦相似度做大批量初筛，再用大模型评判处理语义复杂、难以靠向量相似度判定的题目；自由式评审看似省事，实则提示词冗余、token 消耗大（估算约为结构化比对的 4 倍），建议优先结构化比对。
- 提示词里的字段定义即判定标准：字段怎么拆分、怎么比对决定了整个判定口径，设计阶段要多花时间，否则就会出现"测试方向受个人影响较大"的问题。
- 别指望全自动：自动校验之外一定要保留人工修正入口，特殊场景由人兜底，模型评审结果也应支持人工复核与覆盖。
五、前景展望
- 短期目标：根据业务需求持续迭代测试功能；
- 长期目标：为自建的所有模型提供统一的测试支持——不止文本对话，还包括图像、视频等多模态内容。