AI测试-07-RAG+测试知识库怎么做数据清洗召回和结果校验

发表于 分类于 本文字数： 4.7k 阅读时长 ≈ 17 分钟

一提到 RAG，最容易先聊的是向量库、Embedding 模型、Prompt 拼接和大模型回答效果。

这些当然重要，但放到测试知识库场景里，真正决定能不能长期可用的，通常不是模型回答得多像人，而是下面三件更基础的事情：

  • 知识数据干不干净
  • 召回链路稳不稳定
  • 结果校验能不能把误答拦住

如果这三件事没有先收稳，RAG + 测试知识库 很容易迅速变成另一种形式的“搜索看起来能用，回答真正落地却不敢信”的系统：

  • 文档很多，但召回出来的是旧版本
  • 关键词能命中，但命中的不是当前环境可执行方案
  • 回答看起来完整，实际把接口文档、故障复盘和口语经验混在一起
  • 返回了看似合理的步骤，但现场根本复现不了
  • 错答和半对半错的回答没有被识别，最后还是要靠人工兜底

所以这篇文章不写空泛的 RAG 原理，只聚焦测试知识库里最容易写坏的三段：

  • 数据清洗怎么做
  • 召回链路怎么设计
  • 结果校验怎么收口

一、先把目标说清：测试知识库里的 RAG 不是“会答”，而是“答得可执行、可追溯、可收敛”

测试知识库和通用问答知识库最大的差别，在于它最终要服务的不是泛知识消费，而是工程动作。

它回答的问题，往往都带着明确的执行目的：

  • 某个环境问题该怎么排查
  • 某类接口断言应该怎么组织
  • 某个中间件故障注入测试应该先看什么指标
  • 某个 UI 误判场景应该优先怎么留证
  • 某个测试平台模块出问题时，日志和状态该去哪里找

这意味着测试知识库里的 RAG 不能只追求“回答像模像样”，而要优先满足 4 个条件：

  • 回答来源可追溯
  • 回答内容与当前主题强相关
  • 回答里的动作具备可执行性
  • 回答错误时能被识别、拦截或降级

从这个角度看，测试知识库里的 RAG 更像一条工程决策支持链路，而不是一个只负责生成自然语言答案的能力点。

二、数据分层：先分清知识对象，再谈切片和向量化

RAG 第一层最容易做错的，不是切片大小，而是把完全不同性质的数据混在一起。

测试知识库至少应该分成下面 5 层。

1. 规范层

这类数据回答的是“应该怎么做”，通常包括：

  • 测试规范
  • 流程模板
  • 平台使用手册
  • 接口定义文档
  • 环境约束说明

这一层的特点是结构相对稳定、可引用性强，但容易过期。

2. 经验层

这类数据回答的是“现场通常怎么收”，通常包括：

  • 排障笔记
  • 复盘文档
  • 典型问题案例
  • 已收敛问题的处理路径

这一层最有价值，但也最容易脏，因为里面常常混着：

  • 口语描述
  • 临时判断
  • 只适用于某次环境的局部结论
  • 没有闭环的猜测

3. 证据层

这类数据回答的是“当时发生了什么”，通常包括：

  • 日志片段
  • 错误码记录
  • 截图
  • 报告摘要
  • 监控结论

这层适合辅助回答，但不适合直接当标准答案，因为它描述的是具体现场，不一定能直接外推。

4. 元数据层

这类数据不是知识正文，但对召回很重要，例如：

  • 文档类型
  • 所属系统
  • 所属环境
  • 生效时间
  • 版本号
  • 作者或维护模块
  • 适用阶段

没有这一层，召回很容易“看起来命中了，实际命中错版本”。

5. 禁入层

并不是所有文档都应该进知识库。
测试知识库里最常见的禁入内容包括：

  • 明显过期但未标注失效的方案
  • 纯聊天记录
  • 没有结论的排查草稿
  • 带敏感信息的原始配置
  • 无法确认来源的复制内容

如果禁入层不先挡住，后面的向量化和召回优化都只是在放大噪音。

三、数据清洗：真正难的不是“导进去”，而是“把脏知识挡在外面”

测试知识库做数据清洗时，最容易低估的是经验文档的脏度。

很多看起来像知识的内容，放到 RAG 场景里其实会直接拉低结果质量。

1. 先做文档准入，不要一上来全量入库

每类文档进库前，至少应该经过 4 个问题：

  • 这份文档是不是仍然生效
  • 这份文档是不是有明确主题
  • 这份文档是不是能定位来源
  • 这份文档是不是适合被引用给别人执行

一份“只有排查过程、没有收敛结论”的聊天摘录，就不适合作为主知识进入知识库。

2. 去掉无效内容块

测试文档里常见的无效内容包括：

  • 大段目录
  • 纯导航语句
  • 重复截图说明
  • 无上下文的代码块
  • 连续空表格
  • 纯情绪性总结

这些内容如果直接切片进库，会让召回出现大量“字面相似但没有执行价值”的伪命中。

3. 做结构化拆分，而不是只按字数切片

测试知识库里的切片不应该只按固定长度切。

更合适的拆法通常是：

  • 主题标题
  • 适用场景
  • 前置条件
  • 操作步骤
  • 观察点
  • 常见错误
  • 修复结论

这样拆出来的块更适合后续做：

  • 场景检索
  • 步骤检索
  • 排障检索
  • 结论校验

4. 补齐元数据，不要让向量自己承担所有匹配任务

仅靠向量语义去区分：

  • 测试环境和生产环境
  • 新版流程和旧版流程
  • Web 场景和移动端场景
  • 平台问题和业务问题

通常不够稳。

更合适的做法是给每个知识块补上最小元数据，例如：

字段 作用
doc_type 区分规范、经验、证据、复盘
system 标记业务域或平台模块
env_scope 标记环境范围
version 标记适用版本
status 标记生效、观察中、失效
updated_at 支持时间优先级
confidence 标记人工确认程度

5. 做重复和冲突治理

测试知识库里同一主题常常有多版文档并存。

如果不做治理，最常见的结果是：

  • 召回同时捞出新旧两套方案
  • 模型拿旧版文档拼成回答
  • 看起来信息很多，实际把执行者带偏

更稳的做法是：

  • 给旧文档打失效标记
  • 给同主题文档建立主从关系
  • 给冲突文档保留版本说明
  • 在召回前先按状态和时间做初筛

四、召回链路：测试知识库不能只有“向量检索”，必须有前置约束和后置重排

测试知识库的召回链路，如果只有一句“用户问题 -> 向量检索 -> 拼提示词 -> 模型回答”，通常会很快遇到三个问题：

  • 召回主题对了，但场景不对
  • 召回文档够多，但答案还是拼偏
  • 明明命中了好内容，却被噪音淹掉

更稳的召回链路，至少应该分 5 步。

1. 问题归一化

先把用户问题收成更稳定的检索输入。

例如把：

为什么发布后页面能打开，但任务都卡在执行中？

归一成：

  • 问题类型：测试平台执行异常
  • 观察现象：页面可访问，任务执行不推进
  • 优先模块：调度、执行引擎、状态写回
  • 证据需求：日志、状态表、任务实例

没有这一步，检索词很容易被原始口语表达带偏。

2. 规则过滤

先用元数据过滤掉明显不相关内容，例如：

  • 环境不匹配
  • 系统域不匹配
  • 版本过旧
  • 状态失效
  • 文档类型不适合当前问题

这一步不是为了替代语义召回，而是为了减少明显错误候选。

3. 多路召回

测试知识库不适合只用一种召回方式。

更常见的组合是：

  • 关键词召回：抓术语、错误码、组件名
  • 向量召回：抓语义相近问题
  • 规则召回：抓固定模板、固定流程、固定步骤

三路结果再合并，通常会比单纯向量检索稳很多。

4. 候选重排

候选出来以后，不要直接拿前几条拼上下文。

更合适的重排维度通常包括：

  • 主题相关性
  • 文档类型权重
  • 时间新鲜度
  • 适用环境匹配度
  • 是否有明确结论
  • 是否来自高置信来源

例如一条“故障复盘结论明确、更新时间新、适用模块精确”的经验文档，通常应该压过一条“泛泛介绍概念”的旧规范。

5. 上下文拼装

拼给模型的上下文也不应该只是把命中的文档原文全塞进去。

更合适的方式是按角色拼装：

  • 1 条主结论型知识
  • 1 到 2 条执行步骤型知识
  • 1 条边界或风险提示型知识
  • 必要时补 1 条证据型知识

这样拼出来的上下文更像“有主线的执行材料”，而不是一堆碎片化片段。

五、结果校验：RAG 真正进入测试平台，靠的不是回答生成，而是校验收口

测试知识库里的 RAG 如果要进入平台能力，而不是停留在助手能力，结果校验必须单独设计。

因为平台真正需要回答的不是“模型说得像不像”，而是：

  • 这次回答能不能信
  • 这次回答能不能执行
  • 这次回答能不能留痕
  • 这次回答错了有没有降级路径

更稳的校验骨架，通常可以拆成 4 层。

1. 来源校验

先检查回答引用的知识是不是靠谱。

至少要看：

  • 是否引用了有效文档
  • 是否引用了当前版本
  • 是否引用了当前环境允许的知识
  • 是否至少命中了 1 条高置信文档

如果来源本身就不稳，后面回答写得再完整也不该直接放行。

2. 主题校验

检查回答是否真的围绕用户问题，而不是只在关键词上沾边。

可以从这几个角度看：

  • 回答主题是否和问题对象一致
  • 回答里的模块、系统、组件是否匹配
  • 回答步骤是否回答了当前问题，而不是旁支问题
  • 是否把“排查建议”答成了“配置教程”

3. 动作校验

测试知识库最关键的一层，是校验回答里的动作是否具备执行性。

至少要看：

  • 步骤是否有明确顺序
  • 是否说明前置条件
  • 是否存在高风险动作
  • 是否混入当前环境不可执行的命令
  • 是否把猜测写成确定结论

如果一段答案写了很多动作，但没有前置条件、没有观察点、没有边界，就不适合直接给测试执行者使用。

4. 证据校验

回答应该尽量带出可核验依据，而不是只留一句结论。

更合适的校验要求通常是：

  • 至少给出引用来源
  • 尽量指出对应模块或文档标题
  • 关键步骤能对应到具体知识块
  • 高风险结论要附带人工复核提示

一个可执行的最小校验骨架

可以把一次 RAG 回答的校验收成下面这张表：

校验项 通过标准 不通过时处理
来源 至少 1 条高置信有效文档 直接降级为搜索结果列表
主题 问题对象和回答对象一致 重新召回并重排
动作 步骤清晰且可执行 标记为“仅供参考，不直接执行”
风险 无越权、高危或失效动作 拦截并要求人工确认
证据 能定位引用来源 回答保留但降低置信等级

六、把 RAG 接进测试平台时，更适合的输出不是“一个答案”，而是“答案 + 依据 + 风险”

测试知识库里的 RAG 输出，不太适合只返回一段自然语言。

更稳的输出结构通常是：

  • 结论摘要
  • 推荐步骤
  • 适用范围
  • 风险提示
  • 引用来源
  • 置信等级

例如：

  1. 结论摘要：更可能是执行引擎状态写回异常，而不是前端页面问题
  2. 推荐步骤：先查任务实例状态，再查 worker 日志，再核对状态表写回
  3. 适用范围：适用于 2026Q1 测试平台版本
  4. 风险提示：如果当前任务仍占用环境资源，不要直接重跑
  5. 引用来源：某篇平台排障文档 + 某次故障复盘
  6. 置信等级：中

这样输出的价值在于：

  • 执行者知道该先做什么
  • 执行者知道答案不是绝对真理
  • 平台知道回答可不可以直接进入自动化链路

七、常见坑：RAG 在测试知识库里最容易失真，不是因为模型笨，而是因为知识链路没收稳

1. 把所有资料一股脑导入知识库

这会让召回命中率看起来很高，但有效命中率很低。

2. 只做向量召回，不做规则过滤

结果是语义很像的旧文档、错环境文档、旁支主题文档都一起被捞出来。

3. 只校验答案是否流畅，不校验动作是否可执行

这种回答最危险，因为它看起来不像错，但执行时最容易带偏现场。

4. 只保留正文，不保留元数据

一旦缺少版本、环境、生效状态这些元数据，结果就会越来越不稳定。

5. 把故障现场日志直接当知识主料

日志适合辅助解释，不适合作为主结论来源。否则模型很容易复述现象，却给不出可执行收敛路径。

6. 没有回答降级策略

当召回不充分或校验没过时，系统不能硬答。

更稳的降级方式通常是：

  • 返回检索到的候选文档
  • 明确提示“不足以生成可执行答案”
  • 要求补充环境、系统、版本信息

八、真实案例：一条看起来很像正确答案的 RAG 回答，为什么最后把排查方向带偏了

场景

测试平台在一次发布后出现“任务创建成功，但大量实例卡在执行中”的现象。
平台页面可访问，调度中心也在运行，现场希望通过测试知识库助手快速得到排查路径。

执行

知识库收到的问题是：

发布后任务都卡在执行中，但页面正常，应该先查哪里？

系统按原有链路执行：

  • 直接做向量召回
  • 命中了一篇旧版“执行任务卡住排查手册”
  • 同时命中一篇泛化的“发布后页面正常但功能异常排查建议”
  • 把两篇文档拼进上下文后生成答案

给出的回答重点是：

  • 先检查前端轮询接口
  • 再检查网关转发
  • 再重启调度服务

现象

现场按回答执行后，页面接口一切正常，网关也没有异常。
调度服务重启后问题仍然存在，反而让原始现场被覆盖了一部分。

回答表面上看并不离谱，但排查方向明显偏了。

排查

后续把整条 RAG 链路拆开后，问题很快暴露出来：

  • 命中的旧版排查手册适用的是早期单 worker 架构
  • 当前平台已经拆成调度层和执行层，故障点更可能在状态写回和 worker 消费链路
  • 向量召回没有过滤版本字段
  • 召回结果重排时，把“字面更接近卡住”排到了前面
  • 结果校验只检查了回答是否引用来源，没有检查引用来源是否属于当前版本

进一步核对现场后，真正的问题是：

  • 新版 worker 已经消费到任务
  • 但状态写回表字段变更后，执行层仍按旧字段写入
  • 页面展示的是旧状态，看起来像任务一直卡住

修复

后续把知识库链路做了三类修复：

  1. 数据侧修复

    • 给排障文档补齐 version、system、status 字段
    • 将旧版手册标记为失效，不再参与默认召回

  2. 召回侧修复

    • 增加版本过滤和系统域过滤
    • 将“排障手册 + 故障复盘”设为优先文档类型
    • 把缺少明确结论的说明文档降权

  3. 校验侧修复

    • 新增“版本一致性校验”
    • 新增“动作风险校验”，禁止直接给出重启类建议作为第一步
    • 回答必须带出“适用版本”和“引用来源”

修复之后，再问同类问题时，系统给出的回答会先落到：

  • 查 worker 消费日志
  • 查状态写回字段
  • 查任务实例和状态表是否一致

这时回答不一定更长，但明显更能直接进入排查动作。

九、结论：测试知识库里的 RAG，最先要优化的不是模型回答，而是知识质量、召回链路和校验收口

RAG + 测试知识库 要真正进入测试平台，最重要的不是把回答写得更像专家，而是把下面三层先收稳：

  • 数据层：知识要干净、分层、可追溯
  • 召回层：链路要有过滤、多路召回和重排
  • 校验层：答案要过来源、主题、动作和证据校验

只有这三层都建立起来，RAG 才不会只是“帮忙找资料”的外围能力，而会逐步变成测试平台里真正可复用的工程能力：

  • 能辅助排障
  • 能辅助方案检索
  • 能辅助测试设计
  • 能辅助知识沉淀再利用

如果这三层还没有收稳，就先不要急着追求“更像人”的答案。
在测试知识库场景里，先让答案可控、可核验、可降级，通常比让答案看起来更聪明更重要。