被动太阳能遮阳系统建模与优化实践
2026/10/13 15:45:27
承接第 4 篇。前面做的"测试用例生成助手"只能靠模型"肚子里"的知识回答。这篇给它加上一个知识库：把《用户登录模块需求说明》喂进去，让它能基于这份文档生成测试用例。这一步会接触到 AI 应用里非常重要的概念——RAG（检索增强生成），我尽量用大白话讲清楚。
一、为什么需要知识库（RAG）？
大模型只知道训练时的数据，不知道你的私有文档。RAG的思路很简单：
你的文档 → 切成小块 → 向量化存入向量库 用户提问 → 先从库里检索最相关的几块 → 拼进提示词 → 模型基于这些内容回答
好处：回答"有据可依"，能引用你的资料，还能减少凭空编造。
二、Step 1：创建知识库、上传文档
左侧「知识库」→「创建知识库」→「导入已有文本」，上传你要用的文档（支持 TXT / MD / PDF / DOCX 等，每批最多 5 个文件、单个不超过 15MB）。我上传了《用户登录模块需求说明.md》：
三、Step 2：文本分段与清洗
上传后进入"文本分段与清洗"，这是 RAG 的第一步——把长文档切成小块：
几个核心概念（新手先懂意思，用默认即可）：
| 概念 | 含义 | 我的设置 |
|---|---|---|
| 分段标识符 | 按什么规则切块（这里按空行\n） | 默认 |
| 分段最大长度 | 每块最多多少字符（这里 1024） | 默认 |
| 分段重叠长度 | 相邻两块重叠多少字符（50），让上下文更连贯 | 默认 |
| 文本预处理 | 清洗文本（替换连续空格、删 URL 等） | 勾选"替换连续空格/换行/制表符" |
| 父子分段 | 子块检索、父块作上下文，更精细（进阶再开） | 关闭 |
右侧预览能看到文档被切成了一个个 Chunk（我的文档约 27 块），每块都保留了完整语义：
为什么分段？模型一次能"读"的内容有限，分段就是让检索能找到"和问题最相关的那一小块"。
四、Step 3：索引与检索设置
点「下一步」进入索引与检索设置：
① 索引方式：高质量 / 经济
高质量（推荐）：调用Embedding 模型把每块转成向量，检索更准；
经济：每块用 10 个关键词检索，省 token 但准确性降低。
⚠️ 选了高质量之后不能切回经济。Embedding 模型选默认的
multimodal-embedding-v1即可。
② 检索方式
向量检索：把问题转成向量，找"语义最接近"的分块（默认开）；
Rerank 模型：对检索结果二次重排，把最相关的排前面（开了
qwen3-rerank更准）；全文检索：按关键词字面匹配；
混合检索（推荐）：向量 + 全文同时查，再重排序，效果更稳。
③ 两个关键参数（以后调优/评测的重点）
Top K = 3：每次检索召回最相关的几块（这里 3 块）；
Score 阈值 = 0.5：相关性得分低于 0.5 的分块直接丢弃。
记住一句话：Top K 管"召回多少"，Score 阈值管"太差的不要"。这俩是 AI 测试里调检索和评效果的核心参数。
五、Step 4：知识库创建完成
点「保存并处理」，处理完会显示配置总结（分段 1024、高质量、向量检索），知识库就建好了：
六、Step 5：让应用关联知识库
回到「测试用例生成助手」的「编排」页 → 左侧「知识库」→「+ 添加」：
我第一次点「添加」时弹窗显示"未找到知识库"——因为我还没建好库。点了弹窗里的「去创建」把库建好后再来，就能看到了。
关联后，「知识库」区域会出现你的文档，标注「高质量 · 向量检索」：
七、Step 6：调试测试——一个真实的观察
我在调试区问：
请根据《用户登录模块需求说明》，为"密码规则"设计边界值用例
结果 AI 的回答是：
它说"当前需求中未明确密码规则的具体约束"，然后假设了规则（密码 8~20 位、至少 3 类）来出用例，还列出了需要补充的规则问题：
但我的文档里明明写了"密码8~32 位、必须包含大写/小写/数字"。为什么 AI 没用上？我决定做个召回测试查个明白。
召回测试一：短问题能召回到正确内容
进入知识库的「召回测试」，先用更直接的问题密码的规则是什么？测试：
结果成功召回了 3 个相关段落，第一条就是密码规则本身：
Chunk-10 · SCORE 0.80：密码：长度 8~32 位，必须同时包含大写、小写、数字三类字符 ✅
Chunk-16 · SCORE 0.79：密码错误时的提示
Chunk-15 · SCORE 0.77：用户名不存在时的提示
召回测试二：换一种问法，结果天差地别
再用调试时那个长问题请根据《需求说明》为密码规则设计用例测试：
这次召回的是：
Chunk-01 · SCORE 0.84：用户登录模块需求说明（只是文档标题，没实际规则）
Chunk-15 · SCORE 0.78：用户名不存在时的提示
Chunk-16 · SCORE 0.78：密码错误时的提示
注意：真正包含密码规则的Chunk-10，没有出现在 Top 3 里，被挤掉了。
对比一下，原因就清楚了
| 查询 | 召回 Top 3 | 是否命中"密码规则"块 |
|---|---|---|
短问题：密码的规则是什么？ | Chunk-10（密码规则，0.80）等 | ✅ 命中 |
长问题：请根据《需求说明》为密码规则设计用例 | Chunk-01（标题）+ 报错提示块 | ❌ Chunk-10 被挤出 |
所以调试时 AI 为什么假设"8~20 位"？不是模型不听话，而是：长问题召回的段落里根本没有"密码 8~32 位"这条——模型没拿到这条规则，只能拿自己的常识兜底。根源是检索质量问题：同一个知识库，问题怎么问（表述）、Top K 取多大（这里 3），会直接决定模型能不能看到正确答案。
延伸到 AI 测试
这里其实埋了两个 AI 测试要解决的核心问题：
检索质量（Retrieval）：问题表述不同、Top K 设置不同，召回结果就差很多——怎么保证该召回的一定被召回？
忠实度（Faithfulness）：就算召回了正确内容，模型生成时也可能不用、自己编——怎么检测回答有没有忠实引用资料、有没有幻觉？
这两件事合起来就是RAG 评估，正是 AI 应用质量保障（AI 测试）的核心研究点。这也是我接下来最想深入的方向。
八、小结
给应用加知识库，流程是：
创建知识库(上传文档) → 分段清洗 → 索引检索设置 → 应用关联 → 调试验证
关键收获：
RAG = 分段 + 向量化 + 检索 + 拼进提示词，让模型"有据可依"；
Top K、Score 阈值、Rerank是影响检索效果的核心，以后调优和评测就调它们；
问题怎么问，决定了模型能不能看到正确答案——同一个知识库，短问题能召回到密码规则（Chunk-10），长问题却把它挤出 Top 3，导致模型没拿到规则、拿常识兜底。如何评测检索质量（该召回的有没有召回）和回答忠实度（有没有编造），正是 AI 测试要解决的问题，也是我接下来最想深入的方向。