每周一道 Agent 面试题 - 现在市面上的 Embedding Model 怎么选择(6)

小综t

231人浏览 · 2026-11-11 17:16:19

小综t · 2026-11-11 17:16:19 发布

怎样把选型变成可复用的工程方法

开场

前五篇分别讨论了：约束怎么定、评测怎么做、模型和 chunk 怎么配合、出了问题往哪查、换完模型怎么证明它值得上线。

如果只是面试前背过这些结论，遇到线上问题时，还是可能凭直觉改参数。

系统漏检了，第一反应把 Top K 调大；新模型一发，立刻开始重建索引；某次实验效果变好了，回头一看，模型、chunk、Reranker 是同时改的，说不清哪个起了作用，也没法复现。

比背结论更有用的，是把工作顺序固定下来。这样哪怕问题突然冒出来、信息不全、上线时间又紧，你也知道先查什么、先记什么，以及什么情况下才需要更换模型。

这就是这篇说的「肌肉记忆」：遇到问题，有一套固定动作。面试时，也可以沿着实际工作流程展开，解释每一步的依据。

1、第一条肌肉记忆：先定位问题，再改参数

出了检索问题，先别急着动手，顺着链路从头走一遍：

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

同样是「答错了」，原因可能出在链路中的不同环节，对应的处理方式也不同。沿链路检查，才能确定问题在哪里、由谁处理。

排查时，存一条完整的证据链：用户的原话是什么，你预期该命中哪篇文档哪段证据；解析出来的文本里到底有没有这段话；它被切进了哪个 chunk，前后文丢没丢；这个 chunk 在初召回里排第几，过滤重排之后又排第几；有没有进最终上下文；生成模型最后是怎么答的。

例如，用户问「实习生出差能坐一等座吗」，制度里明确写了实习生按二等座执行。第一步翻原文，规则确实在；第二步看解析文本，表格还在，没丢；第三步找证据被切进的那个 chunk，「实习生」这个条件和「二等座」这个结论还在同一块里；第四步查初召回，排在第十八，重排后第九，Top 5 之外，没进上下文。在这个例子中，证据已经被召回，但排名靠后，没有进入最终上下文。应先检查排序环节，而不是直接更换模型。

信号归纳起来就几类：解析文本里都没有，是解析的问题；解析有、初召回没有，是切块或向量的问题；召回了但没进上下文，是排序或 Top K 的问题；进了上下文还答错，才轮到怀疑生成。

有了这条链，讨论就从「模型好像不太行」变成「正确证据在初召回排第十八，重排后第九，仍未进入最终 Top 5 上下文」。定位越具体，相关人员越容易复核和处理。确认后的失败案例还可以进入回归集，用于检查下一次升级是否修复了问题。

还有两种误判要防着：答案错了，不代表检索就错了，可能检索没问题，是生成模型把证据忽略了；答案对了，也不代表检索就正常，它可能没有利用检索证据，只是依靠已有知识碰巧答对。

2、第二条肌肉记忆：模型选型前先写业务约束

评估新模型前，先明确这些业务条件：文档主要是什么语言，要不要跨语言检索；文档里都有什么结构、什么专业术语，用户平时怎么问；chunk 实际多长；数据能不能出网；延迟、并发、成本的红线在哪；团队有没有能力本地部署、长期维护；真要迁移，重新编码、重建索引的账单扛不扛得住。

这些条件直接决定哪些模型可以进入候选池。文档中英混着、用户还会拿中文查英文资料，单语模型直接出局；制度文档不许出网，即使 API 效果好，也需要考虑本地模型；要求 P95 一秒内出结果，参数过大的模型可能难以满足要求；团队就一个兼职维护的人，需要精细调参的方案可能难以持续维护。不满足硬约束的方案，榜单排名再高也不能采用。

然后把硬约束和软目标分开。数据不能出网、许可不合规、延迟超上限，这些是硬的，一票否决；质量更高、成本更低、维护更省，这些是软的，拿来权衡。硬的先筛、软的再比，先确认候选满足硬约束，再比较质量和成本，可以避免评测完成后才发现部署条件不允许。

公共榜单可以帮助缩小候选范围。池子里谁行谁不行，得用你自己的数据说话，具体可以沿用前几篇的评测方法。

3、第三条肌肉记忆：第一轮实验只改一个核心变量

初筛模型的时候，把文档、解析、chunk、Top K、过滤、重排全固定住，只换 Embedding Model 这一个。等候选缩到两三个，再去试不同的 chunk、输入模板、向量维度。Reranker、上下文组装等配置留到后续实验中调整。

如果模型和 chunk 同时变化，就很难区分分数提升来自哪项改动，退化时也难以确定回滚对象。先单独比较模型，可以让每轮结果有明确的解释，后续调整也有依据。

模型通过初筛后，再比较它与不同 chunk 大小的组合。切块方式会影响模型表现，因此初筛结果还需要在组合实验中验证。模型和 chunk 确定后，再评估 Reranker、查询改写等调整。

每一轮实验都写下来：这轮想验证什么，固定了哪些、动了哪些，用的哪个版本的测试集，指标和失败案例是什么，花了多少资源，最终结论是什么。保留这些记录，后续才能复核当初的选择，也能在退化时找到需要恢复的配置。

控制变量不是说要永远一次只改一个参数，关键是每一轮都能说清楚：效果为什么变好，退化了该回滚哪个。

4、第四条肌肉记忆：失败案例与总分同样重要

平均分反映整体表现，失败案例帮助解释具体的错误。

给每个案例打个标签：术语对不上、跨语言、条件太细、否定与例外、时间范围、多条件组合、长文本把语义稀释了，还是解析切块的时候就没弄好，或者被过滤重排弄丢了。

标签怎么打？看出错的方式，不是看题目内容。查询和文档说的是同一件事、用词完全对不上，标「术语不一致」；问「哪些费用不能报销」，召回的全是「如何报销」，标「否定与例外」；条件对但时间范围错了，标「时间」。一个案例可以对应多个标签，先据此整理常见失败类型。

分类后，可以根据失败集中的环节决定调整方向。例如，三十个失败案例里有二十个来自表格解析错误，应先修复解析器；如果跨语言问题集中失败、其他场景表现正常，再重点比较候选模型的多语言能力。

普通问题和关键问题也要分开看。合规、资金、安全和核心业务规则一旦答错，后果可能更严重。因此，问题的重要性不能只按出现频率判断，低频的合规问题也需要单独检查。总分涨了，但关键风险问题退化了，这方案一般就不能直接上，应先查清退化原因，判断能否修复。

每个确认过的新失败案例，都进回归集。下次升级时重新运行回归集，检查这些问题是否再次出现。

5、第五条肌肉记忆：先设质量底线，再比较成本

工程选型需要同时满足质量和运行要求。

先把底线定了：核心问题、关键失败类型，必须达到什么水平。比如核心业务集通过率不能低于九成五，跨语言案例不得比现在差。过线的模型，才有资格谈成本。

如果先比较成本，容易因为价格低而放宽质量要求，忽略关键问题上的差距。先用质量把门槛立住，再谈钱，判断才不会被带偏。

成本需要分项计算：建库编码要多久，看吞吐量——比如全量五万个块、每小时能编两万个，重建就是两个多小时，具体数按你自己的吞吐算；文档天天有增量的，每天那一小时才是常态成本。在线查询多快，要看平均延迟，更要看 P95，以检查较慢请求的表现。向量维度多大、索引占多少，直接影响内存和账单；走 API 按 token 花钱；本地部署要什么硬件、怎么扩容；监控、升级、故障处理谁来干；数据安全和许可过不过关；迁移和回滚好不好做；团队能否持续承担。

其中最容易漏的是「长期」那部分。上线那天贵的不一定一直贵：API 按量计费会随业务量涨，本地部署的硬件是一次性的、人力却是持续的。把三年的账粗算一遍，结论经常和只看第一周的完全不同。

分数最高但部署不稳，没法用；最便宜但老漏关键规则，也不能要。说得过去的结论应该是：这个模型过了质量线，在现在的规模和并发下，延迟、成本、维护风险也都能接受。

6、第六条肌肉记忆：换模型就是一次数据迁移

更换 Embedding Model，还涉及文档重新编码和索引迁移。

根子在向量空间不兼容：同样一句「差旅住宿标准」，A 模型给它的坐标和 B 模型给的完全是两套体系。直接拿 B 的查询向量检索 A 建立的索引，无法按原有的语义空间比较相关性。所以全部文档向量要重新生成、索引要重建，查询侧也得换成配套的模型，两边必须严格配套。

上线前挨个确认：文档是不是全部重新编码完了，数量对没对上；新旧索引的文档数量、版本对不对得上，别有页面漏编或者版本错位；查询和文档用的是不是同一个模型同一个版本；维度和距离算法匹不匹配，1536 维的查询别去查 768 维的库；完整回归跑没跑，实际产物要和评审结论对得上；灰度指标和日志备好了没；旧模型、旧索引、回滚开关都还在不在。

重建期间新来的文档也别干等：先进增量队列，新索引切换完再补录进去，别留下「这几天的文档查不到」的空洞。

新旧索引并行留着，先切一小部分流量，稳了再放量。提前明确回滚条件——核心问题通过率掉了、P95 超了预算、错误率持续走高，触发哪条就切回去，避免故障发生后才讨论处理标准。旧索引留着就是为了这一刻：切回去是分钟级的事，不用重新等全量编码。

7、第七条肌肉记忆：定期检查是否需要重新选型

业务和运行条件变化后，原有选型需要重新检查。

这些变化出现了，就该重新评估：文档从纯中文变成多语言了；进来一大堆表格、代码、扫描件；用户从说行话变成说大白话了；核心业务开始稳定漏检；数据涨到存储或延迟扛不住了；API 涨价、不稳、许可或合规变了；或者新模型正好能解决你已经确认的某个瓶颈。

重新评估应有具体的问题依据。例如，已经确认的三十个失败案例中，二十个属于跨语言问题，就可以针对候选模型的跨语言能力做比较。新模型发布本身不足以说明当前系统需要迁移。

重新评估可以先从回归集对比开始：新模型在老题目上是不是真的更好，好在哪里，代价多大。评完可能发现现在的模型还是最合适的，那就继续用，这同样是有依据的结论。迁移会引入风险，业务没有变化、收益也不明确时，无需为了追新反复更换方案。

8、一份可以直接使用的固定检查清单

8.1、问题定位

先看原文里到底有没有答案、文档是不是最新的——答案根本不在库里，后面全白搭；再看解析得全不全、chunk 有没有把条件和结论切散、输入有没有被截断，这三样坏了，向量再好也救不回；然后确认正确证据进没进初召回、过滤重排有没有把它删掉——一个查召回，一个查排序；最后判断锅是检索的还是生成的，这一锤定音，决定你去修检索还是调 prompt。

8.2、模型评估

先摸清语言、查询类型、领域术语，哪些是硬约束——这是筛掉候选的筛子；看测试集里有没有真实问题和历史失败案例，全是拍脑袋编的题测不出真水平；第一轮是不是只换了模型，不是的话这轮结果基本作废；出结果的时候，总分、分组、关键问题都要看，改善和退化的案例挨个过——光看一个总分，等于没看。

8.3、工程决策

质量过线之后，再看延迟、吞吐、并发扛不扛得住，尤其 P95 和高峰时段；维度上来存储多花多少，API 或本地的长期账单是多少，算三年的不只算第一周的；安全、许可、版本风险清不清楚，团队接不接得住——最后一项最容易漏，也最容易在半年后爆雷。

8.4、上线验证

独立新索引建了没，数据一致性查了没，完整离线回归过了没——这三样保证你上线的和评审的是同一个东西；灰度和对照的指标准备齐没，旧模型旧索引留了没——没留就等于放弃了回滚；扩量和回滚的条件写明白了没，线上失败案例有没有回流进测试集——不回流，这个坑下次还会再摔。

9、用一次小型实验准备这道面试题

准备这道题时，可以通过一次小型对比实验熟悉选型流程。

先挑一批真实文档，普通文本、标题列表、表格、专业术语、中英混合，尽量都覆盖到——类型越杂，模型之间的差距越容易暴露，规模几十篇就够。再整理一批真实问题，最好的来源是用户真问过的、系统真错过的问题，每个问题标好关键证据：正确答案在哪个文档哪一段。这一步需要花时间完成，后续质量指标的计算依赖这些标注。

然后选两到四个候选模型，在实验规模可控的情况下进行比较。固定 chunk、Top K 和检索流程，只换模型。每个模型跑完记录：找回了什么、漏了什么；正确证据排在第几名；哪些失败扎堆出现在术语、跨语言或者例外条件上；查询延迟和编码吞吐什么水平；维度和存储占了多少；最后为什么保留或排除这个候选。

实验结束后，你会有具体结果可以讨论：哪些模型在表格相关查询中漏检，哪些模型容易混淆肯定与否定条件。面试时可以据此说明自己怎样使用业务数据比较模型，以及最终选择的依据。

10、把实验整理成完整的面试故事

回答可以从业务背景讲起：知识库里是什么内容，语言、查询方式、约束都是什么。这段别超过三句话，交代清楚你在什么条件下做选择——背景一立，后面所有决策才有依据。

接着用一两个能验证的失败案例，说明原方案差在哪。案例要具体到「正确证据在初召回排第十八」这种程度，模糊的「效果不好」没有说服力。

然后讲你怎么搭候选池和测试集，哪些变量没动，比了哪些指标。讲结果别只报总分，哪些问题好了、哪些还是不行、核心指标有没有掉，都要说，让对方看到完整结果和取舍依据。

讲到最后的选择，把取舍说透：为什么没选分数最高的、也没选最便宜的，延迟、存储、部署、安全、维护各自怎样影响选择。收尾补上索引重建、灰度验证和回滚，说明方案如何从实验进入实际运行。

面试追问往往围绕这些依据展开：为什么没有采用另一个模型，某项指标为什么退化，退化后怎样处理。保留完整的实验和上线记录，回答时才有具体材料可用。

11、约 90 秒的面试回答

面试里可以这么组织：

Embedding Model 没有脱离场景的最佳选择。我会先明确知识库语言、文档类型、用户查询、chunk 长度、数据安全、延迟和成本约束，用硬条件筛掉不合适的模型。然后保留少量候选，用真实查询和文档建立测试集，标注应命中的关键证据。第一轮固定解析、chunk、Top K、过滤和重排，只替换 Embedding Model，比较 Recall@K、MRR、NDCG、核心问题通过率和具体失败案例。模型初筛后，再测试模型与 chunk 的组合。质量达到门槛后，继续比较编码吞吐量、查询延迟、向量维度、存储、API 或本地部署成本。最终重新生成文档向量、建立新索引，通过灰度验证，并保留旧索引用于回滚。公共榜单只用于建立候选池，最后的选择必须由自己的业务数据和工程约束决定。

时间有限时，可以先概述这段流程；对方继续追问时，再结合前五篇的方法和自己的实验展开。回答的顺序是：约束、评测、组合实验、工程决策、上线验证。

12、检查自己是否真正理解

前一章给出了一段面试回答，但能复述这段话，还不代表能解释其中的判断。可以先合上资料，用自己的话回答下面十个问题，检查哪些地方还没有想清楚。

为什么榜单第一的模型，未必适合你的系统？ 回答时要结合业务语言、数据安全、延迟、成本和维护条件，说明你会根据哪些约束筛选候选。

怎样判断问题出在 Embedding Model，还是解析、chunk 等其他环节？ 试着沿检索链路说明检查顺序，以及需要查看哪些中间结果，才能找到证据丢失或排名下降的位置。

为什么中文、英文和跨语言查询要分开评测？ 说明只看整体分数可能漏掉什么，以及分组结果会怎样影响选择。

模型支持更长的输入，为什么不一定要把 chunk 加长？ 区分模型能接收的输入长度与业务中合适的切块长度，再说明怎样通过实验比较不同的 chunk 配置。

Recall@K 提高了，为什么还要检查失败案例？ 说明平均指标没有交代哪些信息，尤其要考虑核心问题是否退化、正确证据的排名是否改善。

什么时候更换通用模型，什么时候考虑微调？ 先说明已经确认的失败类型，以及系统调整和通用模型对比的结果，再解释考虑微调的依据。

高维向量会增加哪些工程成本？ 除了存储，还要考虑内存、索引构建和网络传输，并说明这些代价怎样参与选型决策。

为什么更换模型后要重新生成文档向量、重建索引？ 解释新旧模型向量空间不兼容的问题，以及查询侧和文档侧为什么必须配套。

离线评测改善了，为什么上线时还要灰度？ 说明离线测试与真实查询之间可能存在的差异，以及灰度期间要观察什么、何时回滚。

哪些变化会让你重新启动选型？ 结合语言、文档类型、查询方式、质量、成本或服务条件的变化，说明重新评估的理由。

自查时，不必逐字复述文章，但要能说清判断依据和验证方法。例如，回答“先定位问题，再换模型”之后，还应能说明：你会检查哪个环节、查看什么结果，以及什么证据会让你决定更换模型。如果只能记住结论，遇到具体场景却不知道怎么检查，就需要回到对应章节再梳理一遍。

查漏时可以按主题回看：候选筛选和业务约束看第 1 篇，测试集和分组评测看第 2 篇，chunk 配合看第 3 篇，故障定位与调整方向看第 4 篇，效果验证、迁移和灰度看第 5 篇。涉及多个环节的问题，需要把几篇的内容连起来回答。

13、怎样把个人方法变成团队机制

如果检查清单只由一个人掌握，人员变动后就容易遗漏关键步骤。可以把这些检查纳入团队流程，让其他成员也能按同样的要求执行。

这些要求分别用于防止不同的遗漏。新文档类型接入前先验解析和切分——常见的事故是一批扫描件直接入库，表格全碎，线上答错了一周才发现；模型或检索配置一变，标准回归集必须跑——需要防止「就改了小小的 chunk 参数」，核心问题通过率悄悄掉了五个点；评测报告必须带配置、版本和失败案例——不然半年后没人说得清当时的分数怎么来的；核心问题单设门槛，不许被平均分糊过去——一万道普通题的满分，盖不住一道合规题的零分。

后面几条同理。新索引上线必须过一致性检查和灰度，避免未经验证就直接切换流量；线上确认的失败案例定期回流测试集，让测试集覆盖业务中的新问题；每个模型和索引版本都有负责人、上线记录和回滚方式，出了事十分钟能找到能拍板的人。

线上查询也要留够排查信息：命中了哪些文档、各阶段排第几、为什么被过滤、最终上下文里是什么。保留这些中间结果，才能在出现问题时沿日志复核，减少排查中的猜测。

复盘的时候也别只问「这个月准确率多少」，还要问失败类型变没变、测试集跟没跟上新业务、成本还合不合理。

把检查、记录和回滚要求纳入日常流程后，不同成员都能依据同一套标准完成升级，之前积累的评测结果也能继续使用。