4.2 检索配置：向量、全文与混合

4.2 检索配置：向量、全文与混合

检索方式三选一：向量检索按语义相似度找（"想退掉这个东西"能命中"退货流程"）、全文检索按关键词匹配找（术语、编号、型号的精确命中）、混合检索两者都做再融合排序。客服场景的答案通常是"混合 + 重排"——语义泛化与术语精确两个都要。

库已建好（4.1），本节是 RAG 三车间的第二个：问题进来，候选分段怎么挑。产出是一份定稿的检索配置；4.3 节用数据验收它。

三种检索的机理

向量检索：问题先被嵌入模型转成向量，然后在所有分段向量里找"方向最接近"的 top_k 个。它强在同义与口语泛化——"东西不想要了"能对上"退货申请"。弱在精确术语：用户问"YY-33 型号支持退货吗"，语义上它和所有"退货政策"段落都像，向量检索分不出谁真提到这个型号。

全文检索：传统关键词倒排。用户词与分段词精确命中才有效，强在型号、条款编号、人名这类硬词。弱在泛化——"不想要了"命中不了"退货"。

混合检索：两路都跑，结果融合（加权或按名次合并），兼得两种能力。代价是计算量翻倍，以及一个新问题：两路结果怎么排到一张榜单上？这就引出重排（rerank）：用一个专门的模型对融合后的候选做精细打分排序，把真正相关的段提到最前。

三个数值旋钮

检索配置页除了方式，还有三个数值，每个都有明确的物理意义：

top_k（召回条数）：取前几条候选分段塞给模型。默认 3。调大，召回全但噪声多、token 费用涨——塞给模型十个分段，其中七个无关，模型容易被带偏（这在 RAG 里有个专门的名字：上下文污染）。客服经验值 3 到 5，从 3 起步，验收数据说话。

相似度阈值（score threshold）：候选分段的相关性得分低于这条线就直接丢弃，宁缺毋滥。它的价值在防误命中：库里根本没有相关内容时，向量检索也会硬凑出"最不相关里最相关的三条"，模型拿着无关材料一本正经地发挥——这正是编造的另一种来源。设了阈值，不达线的候选被拦下，配合 3.2 节的兜底段（"这个问题我需要转人工"），编造从两端被夹住。

权重（混合模式）：语义与关键词两路的权重比。政策问答语义权重略高（0.6 对 0.4），型号查询多的场景反过来。没有万能值，4.3 节用测试集校准。

小艺检索配置 v1（记录进迭代日志）
方式：混合检索，开启重排
top_k：3
相似度阈值：0.5（首轮先保守，验收后调）
语义与关键词权重：0.6 : 0.4
依据：客服问法口语化占多数，偶有型号与条款号
​

在应用里接上知识库

配置好检索，还要把库挂到小艺身上。回工作室打开小艺的编排面板：功能配置区"上下文"里添加"售后政策库"，检索设置就继承库级配置（也可在应用侧覆盖）。挂上之后，3.2 节预留的 {{#context#}} 占位符正式上岗——检索命中的分段会被拼进这个位置，随系统提示词一起发给模型。

最后打开"引用与归属"开关：小艺的回答下方会出现引用来源，用户可以点开看到命中的原文分段。这个开关对客服场景不是装饰——它是用户信任的来源，也是 4.3 节验收的观测点。

⚠️ 常见坑一：top_k 一路调大到 10 去"提高召回"，结果答案质量反而下降——无关分段进入上下文，模型开始答非所问。召回不够先查分段质量与检索方式，不是先加 top_k。常见坑二：忘了设相似度阈值，库外问题被硬凑的三条不相干分段带偏。两个坑的共同解法是记住：检索的职责是"找对"，不是"找满"。

一个快速对照实验

配置定稿前，花五分钟做一个小实验，直观感受三种方式的差异。在知识库的"命中测试"里输入同一个问句，切换检索方式对比命中结果（下一节把它升级成完整的验收方法）。

测试问句："买的 YY-33 电磁炉能不能七天无理由"

向量检索命中：退货政策总则·第七条（会员天数条款）  ← 语义像但没提型号
全文检索命中：FAQ·型号专区第 12 条（含 YY-33）      ← 精确命中
混合检索命中：FAQ·型号专区第 12 条 + 政策第七条      ← 两路各取所长
​

这个实验同时演示了 4.3 节的核心方法论：看命中的分段对不对，而不是看最终答案像不像。答案层混着模型的发挥，命中层干净地暴露检索的真实水平。

旋钮拧过头的症状速查

每个旋钮都有"拧过头"的形态，提前认识它们，调参时能少走一轮弯路：

症状                         最可能拧过头的旋钮
答案张冠李戴，引用了无关政策   top_k 太大（噪声入上下文）
明明库里有，却说"需转人工"     相似度阈值太高（正确候选被拦）
型号类问题总答错               没开混合或全文，或关键词权重太低
口语问题命中不了               语义权重太低或分段里只有书面表述
每次回答都很慢                 开了重排但候选池过大（top_k 前值过大）
费用异常高                     检索正常但 top_k 大且上下文轮数也大
​

最后一行值得展开一句：检索侧的 token 膨胀与 3.3 节对话侧的轮数膨胀是相乘关系——top_k 从 3 到 5、上下文从 5 轮到 8 轮，单轮成本接近翻倍。调优时两侧分开动、分别记录，否则账单涨了都不知道该怪谁。

问题：重排模型必须单独接入吗？不开会怎样？

重排是独立的模型类型，需要在系统模型设置里单独指定（2.2 的三件套之外多配一项）。不开的后果不是"不能用"，而是混合检索的融合排序靠默认规则，排名差的分段时有发生——4.3 首轮验收里四题排名差就是它的代价。起步阶段可以先不开，等验收数据里"排名差"类失手超过两成再开，把它当按需升级项而不是必选项。

💡 关键直觉：检索配置的三个旋钮（方式、top_k、阈值）分别回答三个问题——用什么方式找、找到的取几条、多不像的不要。把它们跟"找对、找满、宁缺毋滥"对上号，配置就不是抄来的，是你自己的。

本节要点回顾

• 三方式机理：向量管语义泛化、全文管硬词精确、混合两路兼得，重排负责把融合榜排准；
• top_k 平衡：3–5 起步，调大换来的不是更多正确，而是更多噪声；
• 阈值防硬凑：不达线的候选拦下，配合兜底话术从机制上压编造；
• context 占位符：知识库挂到应用后，命中内容注入 3.2 节预留的位置；
• 引用归属必开：答案可溯源既是信任也是验收观测点；
• 看命中不看答案：诊断检索问题的唯一干净视角。

配置有了，但它到底好不好？下一节用命中测试和一批测试问题给出量化答案。