一个编码器，两套错误成本

原创分析 · 2026年10月16日。

DMIS于10月14日发布的UltraBERT按掩码方案分离预训练头，面向分类与检索。

对企业真正有用的问题，是哪些错误可以承受。搜索系统纳入一份无关文档，会增加工作量；路由系统排除正确目的地，却可能直接拿走正确回答的机会。即使两套系统起步于同一模型家族，这两种成本也不会变得相同。

我们的核心观点是，整合不应延伸到统一的损失函数，也就是企业衡量一次错误价值的规则。共同的技术基础可以很有吸引力，但不意味着一个平均质量分数就适合作为部署目标。最能说明问题的场景，是分类先决定检索可以看到什么。

搜索之前的错误

设想一个客服产品。分类器先判断请求是否需要技术知识库，检索器再为获准进入的请求选择候选文档。在这种设计中，分类器是一道闸门，检索器则负责制作候选清单。闸门可以丢掉一个机会，让后者根本没有机会评估。

假设有1,000个请求确实需要该知识库。闸门放行900个；对这900个，检索器有90%的概率在候选清单中找到相关文档。整个系统成功处理810个，也就是原始1,000个请求的81%。这些是假设，并非UltraBERT测量结果。计算采用的是已经获准进入条件下的检索成功率，不假设两阶段错误相互独立。

现在，保持闸门不变，把这一条件检索成功率提高到95%，总成功数变成855。作为对比，若放行980个请求，同时保持原先90%的条件检索成功率，就会得到882次成功。后一种比较假设新增放行请求同样容易检索，这可能并不成立。它的目的，是指出必须测量什么：过去被闸门挡住的请求，到底有多难。

如果团队只庆祝已放行请求的搜索质量，就可能忽略这个区别。更严格的闸门可能让系统看起来更干净，只因为它不再尝试困难工作。因此，我们会以所有需要证据的请求为分母，报告成功找到证据的比例，包括上游已拒绝的请求。

为多余工作和遗漏工作分别定价

Scikit-learn文档说明了不同决策阈值下的精确率与召回率。

我们的经济分析是，根据放行和排除任务的后果来选择闸门。一次错误放行，可能消耗一次搜索、一次重排序和一些审核时间。一次错误排除，则可能导致问题未解决、客户再次联系或不必要的升级处理。结论并不是一律放行更多，而是比较边际成本，不把两种错误都视为同等程度的不良结果。

例如，假设调整阈值会增加200次不必要的搜索，同时挽回20个原本漏掉的案例。只要挽回一个案例、扣除该案例自身处理成本后的平均净价值超过一次多余搜索增量成本的十倍，便能覆盖这些搜索的增量成本。这里是我们的简化计算，不是价格预测。新增延迟、误导性搜索结果和下游回答错误，也都应计入成本比较。

这会影响激励机制。基础设施负责人可能因搜索次数减少而受奖励，客服团队则按解决案例数考核。两个团队都可能改善自己的仪表盘，整体产品却变差。共享编码器应当让这些相互竞争的目标更容易讨论，而不是将它们隐藏在一个模型分数后面。

检索的边际价值不同

BEIR研究基准跨不同任务和领域评估检索。

对我们的客服例子，商业问题更具体：下一阶段应该收到多少有用候选？多一个候选，可能补回缺失证据，也可能占用注意力或引入看似合理的干扰。它的价值取决于下游如何使用它。浏览清单的分析人员和自动生成答案的系统，未必都适合同样长度的候选列表。

我们会在这个交接点衡量检索变化的成本收益。测量新增候选是否真正帮助完成案例，增加了多少审核工作，以及是否挤掉更有用的项目。让相关文档出现在长清单中的某处，不等于把可用证据放到下一阶段实际会检查的位置。高相似度分数，也不等于企业已经决定采取行动。

这形成了两个不同的优化问题。分类器要判断的是，开启一条路径是否值得付出预期成本；检索器要判断的是，哪些新增证据值得传给下一阶段。两者可以使用相关的表示方式，但运行时的取舍应反映不同后果。没有普遍理由认为，同样严格的筛选程度会同时适合二者。

测试相互作用，不只测试零件

我们建议用同一批留出的请求测试四种配置：旧闸门配旧搜索、新闸门配旧搜索、旧闸门配新搜索，以及两者都换新。固定底层知识库。这能分离每项变化带来的收益，也能发现两份独立测试报告可能遗漏的相互影响。

被拒绝的请求也要标注。否则，闸门可能通过删除恰恰最能判断其成本的案例，来改善表面效率。把数量少但代价高的类别与常见简单案例分开追踪，并保留足够样本，避免把一次特殊结果扩大成普遍结论。

共同的基础还带来一个问题：弱点会不会重叠？如果闸门和检索器都漏掉同类语言表达，第二阶段就可能很难补救。这是需要测试的假设，并非对这次发布的断言。应检查实际失败的重合情况，而不是认定两次模型调用就提供了两次独立机会。

机会在于更好地复用工程工作。约束在于，省下一次操作与丢掉一个答案，价值并不相同。企业可以整合模型栈，同时为打开搜索路径，以及选择沿这条路径传递的证据，保留各自的错误成本预算。