第二步：设计好提示词（别让模型自由发挥）很多测试同学把RAG用废了，问题出在提示词上——太随意。一个合格的测试用例生成提示词，至少应该包含这几层：你是一名资深测试开发工程师。请根据以下【测试需求】和【参考知识】生成测试用例。【测试需求】{用户输入的需求描述}【参考知识】{从知识库检索到的相关文档片段}要求：1. 覆盖正常流程、异常流程、边界值2. 每个用例包含：用例编号、前置条件、测试步骤、预期结果3. 优先覆盖高风险场景（参考历史缺陷库）核心逻辑就一句话：告诉模型你是谁、要干嘛、拿什么资料干、按什么格式交作业。缺了任何一环，出来的东西都可能跑偏。第三步：调检索参数（别让模型“找不到”或“找太多”）检索是RAG的咽喉。检索出来的东西不对，后面生成什么都不对。几个可以调的参数：Top-K：每次检索返回多少条结果。K太小可能漏掉关键信息，K太大上下文太长模型会“失焦”。一般5-10是个不错的起步区间。相似度阈值：低于这个相似度的结果直接丢弃，避免把不相关的东西喂给模型。分块大小（Chunk Size） ：块太大检索精度差，块太小上下文割裂。根据文档类型调，接口文档可以切小一点，需求文档可以稍大。另外可以考虑混合检索——向量检索+关键词检索结合。向量检索擅长语义匹配，关键词检索擅长精确匹配（比如接口名、字段名），两者互补效果更好。第四步：建反馈闭环（让系统越用越聪明）RAG不是一次性工程。用得越多，应该越准。怎么做？把测试执行的结果反向喂回去：哪些用例执行通过了→说明生成质量OK，标记为正样本哪些用例执行失败了→分析原因：是文档错了还是模型理解错了？把问题反馈到知识库或提示词里哪些场景模型漏掉了→补充到知识库中天猫技术团队的实践数据可以参考：C端业务用例采纳率达到85%以上，中小型需求的用例编写时效从2小时降到0.5小时，提升75%。他们能做到这个水平，靠的就是“需求规范化+Prompt工程+知识库RAG+平台化集成”这套闭环策略。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
