Embedding 检索效果差：先定位问题，再决定换模型还是微调

开场

检索效果不好时，很多人的第一反应是换模型。

模型 A 没有命中，就换模型 B；模型 B 解决了一个问题，却在其他问题上退化，于是再试模型 C。几轮下来，积累了不少测试结果，问题发生在哪一层仍然说不清。

有些问题甚至与 Embedding 模型无关。

假设用户问：“特殊情况下可以先订票再补审批吗？”系统没有找到例外规定。团队先后换了三个模型，结果都不稳定。最后才发现，PDF 解析后只保留了表格第一列，特殊条件所在的第二列已经丢失。

模型无法召回从未见过的内容。

面对“向量化效果一直不好，应该优先微调还是更换模型”，先不要急着二选一。要先确认问题是不是主要出在向量表示和语义召回阶段。

1、先把“效果不好”描述具体

“召回不好”太笼统，无法直接排查。先把它改写成具体、可验证的现象。

例如，用户输入内部简称时，系统找不到使用正式名称的文档；用中文提问，召回不到对应的英文资料；普通规则能够命中，例外规则却经常被忽略。这些现象更像查询与文档之间的语义没有对齐。

有时证据已经被召回，只是排名不够靠前。比如正确证据能进入 Top 20，却进不了 Top 5；文档规模增加后，相似片段开始挤占前几名。

也有些问题根本不在向量召回。表格内容无法检索而正文正常，应该检查解析；证据已经进入上下文，回答仍然遗漏条件，则要检查生成环节。只有关键词检索稳定命中、向量检索持续失败时，问题才更接近语义表示。

还要确认影响范围。只有个别问题失败，可能只是文档缺失或标注错误；某一类查询反复失败，才可能说明存在稳定模式；所有查询突然退化，则需要检查模型版本、索引配置和服务状态。

2、沿着完整链路逐层排查

可以使用下面这条链路：

原文 → 文档解析 → chunk → 向量化 → 初步召回 → 过滤与重排 → 上下文组装 → 回答生成

每一步都要确认正确证据有没有在这里丢失。

2.1、原文中是否真的有答案

先确认知识库里确实有答案，而且文档没有过期。

有些问题来自知识库更新不及时。制度已经变化，系统仍然使用旧文档；用户问了一个原文从未说明的问题；或者业务人员认为某条规则存在，实际文档并没有明确写出。

这种情况下，调整模型没有作用。

2.2、解析后的文本是否完整

不要只打开原始 PDF 或网页查看。应该检查系统实际送入切分环节的文本。

解析问题不只表现为文字缺失。扫描 PDF 没有完成 OCR，扫描文字就无法完整进入解析结果；表格只保留部分列，关键条件和对应结论也可能随之缺失；网页中的折叠内容没有抓取，同样会造成内容不完整。

内容虽然保留下来，结构也可能已经损坏。标题和正文的顺序错乱、列表层级丢失，都会影响后续切分。页眉页脚混入正文、文本编码异常，也需要在这一阶段处理。

原文中看得到，不代表模型也看得到。

2.3、chunk 是否包含完整证据

检查适用对象、条件、结论和例外是否位于同一个片段。标题是否保留？表头是否与数据行一起出现？输入是否超过模型长度上限？

如果“特殊地区”在上一个 chunk，“住宿标准上浮”在下一个 chunk，两个片段都无法独立表达完整规则。此时应先调整切分。

2.4、正确证据是否进入初始召回

找到正确证据对应的 chunk，直接查看它在向量检索结果中的位置。

正确证据完全没有进入较大的候选集合，问题可能出在模型、查询表达或过滤，不能直接归因于模型能力。证据能进入 Top 50，却进不了 Top 10，说明模型能识别相关性，但区分相似内容的能力可能不足。此时要关注排名，而不是笼统地判断“召回成功”或“召回失败”。

如果证据原本排名正常，增加元数据过滤后却消失，应检查过滤条件。关键词检索能够稳定命中，而向量检索始终不能命中时，再继续比较其他通用模型，确认问题是否出在当前模型。

排查时不要只看最终 Top 5。候选范围太小，会把“完全没有召回”和“已经召回但排名靠后”混在一起。

2.5、重排和上下文是否删除了证据

如果正确证据已经进入初始召回，经过 Reranker 后排名却下降，甚至直接消失，主要问题就不在 Embedding 模型。

去重、过滤、文档合并和 token 预算裁剪，也可能删掉关键内容。需要保存各阶段结果，确认正确证据是在哪一步被删掉的。

2.6、生成模型是否正确使用证据

如果正确证据已经完整进入上下文，回答仍然错误，就要检查提示词、上下文顺序、冲突信息和生成模型。

最终答案错误不等于检索错误。反过来，模型凭已有知识偶然答对，也不能证明检索正常。

3、什么时候先调整系统

文档缺失、版本过期，或者解析时丢失表格、标题和扫描文字，应更新知识库或修复解析流程。模型没有拿到完整内容，换模型也无法解决。

chunk 拆散了条件与结论，或者输入发生截断，需要调整切分和输入处理。查询过于含糊时，可以根据已有上下文改写，不必立即更换模型。

数据和输入都正常，再检查召回配置。元数据过滤可能误删结果，初始 Top K 太小也可能让正确证据进不了后续流程。证据已经召回后，还要看 Reranker 是否排错、上下文组装是否删除了关键片段，以及生成模型是否遵循证据。

更强的模型有时能让这些问题暂时缓解，但根因仍在，换一批文档后很可能再次出现。

4、什么时候应该更换通用模型

确认解析、chunk、过滤和后续流程都正常后，如果失败反复集中在初始语义召回，就可以开始比较新的通用模型。

当前模型如果始终无法理解核心领域术语，或无法对齐内部简称与正式名称，或者频繁混淆相似主题下的条件、对象和范围，就值得比较其他通用模型。跨语言表现明显落后，或者面对长度差异较大的查询和文档时不稳定，也说明模型可能不适合当前数据。

有时换模型并非因为语义质量，而是工程条件发生了变化，例如输入长度、向量维度或部署方式不再满足要求，服务成本、稳定性或许可也需要重新评估。

更换模型时仍然要控制变量：固定文档、chunk、Top K、过滤和重排，只替换 Embedding 模型，再用同一套测试集比较。

不要根据一个失败案例直接迁移。新模型解决了内部简称，也可能让英文文档或其他类型查询退化。

5、什么时候才值得微调

微调通常放在更靠后的位置。

在考虑微调前，先确认：

1. 已经测试过多个合适的通用模型；
2. 问题确实发生在向量表示和初始召回阶段；
3. 失败类型稳定且具有业务价值；
4. 有足够真实、准确的训练数据；
5. 能构造高质量正样本和困难负样本；
6. 有独立评测集，避免只看训练数据；
7. 团队能够承担训练、版本管理和后续维护。

如果只缺少少量内部简称，维护术语词典或做查询改写往往更简单。新的通用模型已经达到要求时，也没有必要为了“更定制”而微调。

领域术语密集、多个通用模型普遍表现不足，或者查询与文档之间长期存在行业表达差异时，微调才有明确目标。团队还需要积累足够的真实点击数据、人工标注或已确认的问答对，并持续构造高质量的困难负样本。负样本过于简单，模型仍然难以学会细粒度区分。

微调还要算投入产出。检索质量提升应当有明确的业务收益，模型也要长期使用，训练、版本管理和维护成本才有机会被摊薄。

6、微调数据应该包含什么

训练数据通常包括查询、正样本和负样本。

正样本是能够回答查询的证据。负样本不能只选完全无关的内容，还要加入困难负样本：主题相近、关键词重合，但条件、对象或时间范围不同。

例如，查询“试用期员工能否乘坐一等座”：

试用期员工交通标准能够直接回答问题，可以作为正样本。采购流程与查询主题无关，属于容易区分的简单负样本。正式员工或管理人员交通标准与查询主题接近，却不适用于试用期员工，因此更适合作为困难负样本。

如果训练数据中只有简单负样本，模型可能学会区分不同主题，却仍然无法处理真实系统中最常见的细粒度混淆。

训练数据还要覆盖线上查询分布，不能只由文档标题自动生成。自动生成数据可以辅助扩充，但需要抽样检查，避免问题过于书面、答案过于明显。

7、怎样判断微调是否真的有效

微调模型必须和原模型、其他通用模型放在同一套独立测试集上比较。

评测要覆盖整体检索质量，包括 Recall@K、MRR、NDCG 和核心问题通过率。还要确认目标失败类型是否改善、非目标问题有没有退化，并分别比较中文、英文和跨语言查询，避免整体指标掩盖局部问题。

工程表现也不能忽略。查询延迟、编码速度和部署资源会影响模型能否实际使用；新数据加入后是否仍然稳定，则关系到评测结论能否长期成立。

还要防止过拟合。模型在训练样本里的术语和模板上表现很好，不代表遇到新的真实问题也会改善。测试集必须与训练集分开，并保留后续新增的问题做时间外验证。

8、一个完整决策案例

假设系统在查询内部产品简称时经常失败。排查时先确认原文确实写明了正式名称与简称的关系，再检查解析结果和 chunk，排除两者被拆开的可能。

扩大候选范围后，正确证据仍然没有进入 Top 50。换用关键词检索，简称可以稳定命中；再比较几个通用模型，其中一个能够较好地对齐简称和正式名称。

此时优先更换通用模型，而不是微调。

如果所有候选模型都失败，而公司又有大量简称、历史查询和人工确认数据，可以用查询、正式文档和相似产品文档构造训练样本，再评估是否微调。

如果简称数量很少、变化频繁，维护别名词典并在查询时扩展，可能比训练模型更合适。

同样是“简称检索失败”，有时应该换模型，有时值得微调，有时维护别名词典就够了。选择取决于问题规模、数据条件和维护成本。

9、面试时怎样回答

面试中可以这样回答：

我不会直接在换模型和微调之间二选一，而是先把“检索效果差”说清楚。比如，是内部简称找不到正式名称、中文问题召回不了英文文档，还是证据能进入 Top 20 却进不了 Top 5。还要看问题只影响少量查询、集中在某一类查询，还是所有查询都在退化。

然后沿着检索链路排查：原文里是否有答案，解析时有没有丢失表格、标题或 OCR 内容，chunk 是否拆开了条件和结论，证据有没有进入初始候选集，过滤、重排和上下文组装是否把它删掉，生成模型是否正确使用了证据。答案已经进入上下文但回答仍然错误，问题就不在 Embedding 模型；关键词检索能命中、向量检索不能命中，而且证据始终进不了较大的候选集合，才更像语义表示问题。

确认问题集中在初始语义召回后，我会比较几种合适的通用模型。测试时固定文档、chunk、Top K、过滤和重排配置，只替换 Embedding 模型，并使用同一套独立测试集。除了 Recall@K、MRR 和 NDCG，还要看目标问题是否改善、其他问题有没有退化，以及中文、英文和跨语言查询的表现。如果某个通用模型已经能稳定解决问题，就直接换模型，不必为了定制而微调。

如果多个通用模型都在同一类领域问题上失败，而团队又有足够、可靠的训练数据，能构造正样本和困难负样本，也有独立评测集和长期维护能力，我才会考虑微调。微调后既要验证目标问题，也要检查普通查询是否退化，并比较延迟、编码速度、部署资源和新数据加入后的稳定性。如果只是少量简称或别名失败，维护词典、扩展查询或增加规则通常更合适；没有高质量训练数据，就先优化解析、chunk、查询改写和混合检索，同时积累经过确认的线上案例。

面试官继续追问时，可以结合具体失败案例，说明困难负样本怎么构造、如何控制变量，以及微调后怎样做回归验证。

10、可以怎样快速决定下一步动作

完成链路定位后，可以使用一个简单决策表：

这张表不是固定答案，它的作用是把不同层的问题交给相应工具。Embedding 模型替换起来不难，不代表所有问题都该由它解决。

还要考虑每个动作是否容易回滚。调整查询改写或 Top K 通常比较灵活；全量微调并重建索引的成本更高。证据不足时，应优先选择成本低、容易验证和回滚的动作。

11、换模型和微调时最容易忽略什么

更换通用模型时，最容易忽略输入方式。新模型可能要求查询前缀、文档前缀或归一化处理。如果直接沿用旧模型配置，测试结果会低估新模型的能力。

微调时则容易忽略数据偏差。如果训练数据里的问题主要由文档标题自动生成，模型可能只擅长书面表达；真实用户使用口语、简称和错别字时，效果仍然不好。

另一个风险是把线上反馈直接当成负样本。用户没有点击某个结果，不一定表示结果错误，可能只是没有看到或无需继续操作。训练数据需要经过清洗和确认。

还要做好模型版本管理。微调模型需要记录基础模型、训练数据版本、训练参数和评测结果。无法复现的微调，即使当前分数不错，也很难长期维护。

不要只验证目标问题。为跨语言问题做微调后，普通中文问题可能退化；针对内部术语做增强后，模型也可能过度偏向企业词汇。完整的回归验证始终不能省略。

12、这一题常见的面试追问

直接进入微调，需要同时满足几个条件：多个通用模型都无法解决稳定的领域差异，手里有足够的真实正负样本，也有独立测试集和长期维护能力。

没有训练数据时，先调整解析、chunk、查询改写和混合检索，并继续积累经过确认的线上案例。为了赶进度而使用大量低质量自动数据，往往会把噪声带进训练集。

困难负样本可以从同主题、不同对象、条件、时间或版本的文档中选择。例如，正式员工标准是试用期员工问题的困难负样本，完全无关的采购制度只能算简单负样本。

混合检索能否代替换模型，要看失败类型。关键词检索擅长精确术语和编号，向量检索擅长语义表达，两者结合可以处理一部分问题；跨语言和复杂语义对齐仍可能需要更合适的模型。

下篇预告

找到新模型或完成微调后，还要回答一个问题：怎样证明它真的比原方案好？

下一篇《每周一道 Agent 面试题：现在市面上的 Embedding Model 怎么选择（5）——换模型以后，怎样证明整体效果真的提高》，会把离线基线、控制变量、失败案例回归、工程成本、索引迁移、灰度上线和回滚串成一套验证流程。

结束语

检索系统出问题时，模型最显眼，却未必最该先改。

保留各阶段的中间结果，确认正确证据在哪一步丢失。系统问题先修系统；合适的通用模型能解决，就不必急着微调。只有确认问题出在向量表示，并且存在稳定的领域差异和高质量数据时，微调才值得投入。否则，后面的模型比较没有依据。