检索分数0.8，就是八成可信？RAG门槛别抄错刻度

检索结果旁边写着 0.8，界面就显示“可信度80%”。这一步看起来只是换个标签，实际上可能把排序刻度变成了一项从未验证过的承诺。

更隐蔽的问题出现在迁移时：模型没换，候选顺序也没换，原来的 score >= 0.8 却突然放进更多资料。不是检索器忽然变宽容了，而是这个数字换了一把尺。

本篇只回答一个问题：RAG检索分数究竟在量什么，阈值为什么不能只复制一个小数？ 我们从同一组人工相似度出发，分开看原始度量、服务端分数和业务决策，不把相关性冒充回答正确概率。

AI原创概念插画：玻璃花房里，同一颗红石榴被两套不同的弧形刻度装置环绕，前景瓷盘放着蓝羽毛。装置是艺术隐喻，不是精确测量仪器，也不表示画面已经读出了某个数值。

先问分数叫什么，再问它有多高Copy Anchor Link

RAG通常先找资料，再让模型基于资料回答。向量检索把问题与文档表示成一组数，用某种数学度量寻找靠近的候选。向量是表示，不是证据本身；靠近也不自动表示文档能回答问题。

以余弦相似度为例，它比较两条非零向量的方向。数学范围为负一到一；数值越大，方向越接近。这里没有“答案是否正确”的随机事件，也没有定义某个问题被正确回答的概率。把 0.8 乘以百分之百，只改变显示形式，不会补上这些定义。

而且，接口里的 score 未必就是余弦。至少要分开三层：

Sentence Transformers官方文档就把余弦、点积、负欧氏距离、负曼哈顿距离列为不同的相似度选择。[1] 注意是负距离：普通距离常以小为近，取负后可以按大分数在前排列。适配层若只保留一个浮点数、不保留度量名称，很容易连比较方向都接错。

归一化也有作用域。文档说明，单位化向量的点积等于余弦；没有这个前提，就不能无条件把点积当余弦。[1] 即便满足相等，也只说明这两个数学量一致，不说明它们变成了正确率。

同一个余弦，为什么能返回不同的分数Copy Anchor Link

以下比较限定为文档所描述的单路向量余弦打分，不包括关键词混合、RRF融合、额外boost、自定义脚本或语义重排。

设原始余弦为 c：

• 直接返回余弦：score = c。
• Elasticsearch的dense_vector余弦打分：score = (1 + c) / 2。[2]
• Azure AI Search文档描述的余弦向量搜索：先令余弦距离为1 - c，再返回score = 1 / (1 + 距离)，也就是1 / (2 - c)。[3]

这不是谁的算法“多给分”。两种变换都能在这段数学范围内保留按余弦由高到低的顺序，但数值刻度不同。Azure文档的“随距离增加而单调下降”，换成以余弦为自变量，就是随余弦增加而上升；不要混淆变量。

以下是根据公式核算的人工夹具，不是产品返回或模型输出：

三列排名完全相同。若应用却给每列统一套score >= 0.8，保留集合就不相同：直接余弦只留下第一项，Elastic这一列会留下前两项，Azure这一列仍只留下第一项。

排序相同，不等于相同数值的门槛表示相同条件。 这是阈值迁移需要单独验收的原因，也说明“第一名没变”不足以证明系统行为没变。

跟一遍案例：手册迁移后，为什么多放进一份资料Copy Anchor Link

假设有一个虚构的相机资料助手。团队原先使用直接余弦，并在应用层规定：c >= 0.6的片段可以进入下一步阅读。这个门槛纯属教学设定，不是推荐生产值。

迁移后，适配层返回了上面的Elastic刻度。如果仍比较score >= 0.6，人工夹具中的第三项也能通过；要保留原来的数学条件，应比较score >= 0.8。对应Azure这一刻度，条件应换为score >= 1 / (2 - 0.6)，约为0.7142857。

这只是应用层对已返回分数进行筛选的等价换算，不是任何厂商请求参数的配置示例。某些接口的阈值参数接受原始相似度，而非响应里的变换分数；必须读参数自己的定义，不能把这里算出的值直接填进所有名为threshold的字段。

下面的纯Python代码已实际执行，使用有理数避免边界浮点误差。A、B、C以及余弦值均由人工指定，没有生成嵌入，也没有调用搜索产品：

from fractions import Fraction as F

raw = {"A": F(4, 5), "B": F(3, 5), "C": F(1, 5)}
elastic = {k: (1 + c) / 2 for k, c in raw.items()}
azure = {k: 1 /

实际输出：

['A'] ['A', 'B'] ['A']
['A', 'B'] ['A', 'B'] ['A', 'B']

第一行展示同一个小数不等价，第二行展示已知公式下的等价换算。本轮另用完整断言核对了三列排名、反算及边界；这验证的是数学接线，不是召回率、模型理解能力或云端实现。

还要留住这个限制：即使换算正确，迁移时若候选生成、近似检索、分块、过滤或数据版本也变了，输入集合仍可能变化。一个公式只能对齐刻度，不能保证端到端等价。

刻度对齐后，为什么还不是“80%可信”Copy Anchor Link

把两把尺换算成同一种单位，只解决可比性，不解决概率解释。

在相机案例里，一段讲旧型号的说明可能与问题措辞很像，但不适用于新型号；两段分别说“支持”和“不支持”的文字也可能共享大量词汇。这里是风险场景，不是本文测得的嵌入表现。具体模型是否把它们排近，要在真实输入上测试。

若要把分数用于业务门槛，应先定义目标：

• 是筛掉明显不相关的片段，还是判断一段资料能否直接支持结论？
• 是逐片段的相关性，还是一整套证据能否覆盖所有子问题？
• 是估计答案正确，还是只控制送入下一步阅读的候选数量？

这些目标需要不同标签。不能拿“同主题”标注出来的门槛，宣称自己校准了“最终回答正确”。如果确实建立了概率校准模型，也应说明目标事件、样本分布、独立验证与误差；输出落在零到一之间本身不叫校准。

工程上的起步方式，是在固定检索链路下收集真实问题，加入容易混淆的负例和证据不足的问题，用开发集选择阈值，再在未参与调参的保留集上检查：挡掉了多少必要证据，又放进了多少不合格候选。重要分组应分开看，例如型号、语言、长短问题和有无答案；不要只报总体平均。

这是一份验证建议，本轮没有执行真实语料评测，也不提供放之四海而皆准的阈值。阈值过严会漏材料，过宽会增加噪声、阅读成本与误用风险；合理取舍取决于业务目标和后续核验能力。

把刻度作为契约的一部分保存Copy Anchor Link

一个只记录score: 0.8的日志，日后很难解释。建议至少同时保存以下非敏感信息：

• 打分阶段：初检、融合后还是重排后。
• 度量及方向：余弦、点积、距离或负距离。
• 返回分数的变换、加权配置与规则版本。
• 嵌入模型、索引和分块配置的可追溯版本。
• 阈值作用位置、比较运算符，以及阈值选择所依据的验证集版本。

这不是要求把全文和私人查询都写进日志，而是让数值有可回查的语义。字段名相同、范围相同，甚至候选排名相同，都不能代替这些信息。

当系统加入混合搜索或语义重排，应重新核对实际响应字段。Azure文档明确说明，多路向量或向量加文本的混合查询会采用RRF进行最终打分。[3] 此时不能继续用单路余弦的反算公式解释融合分数。本文不展开排名融合算法，只强调分数在哪个阶段产生，属于它含义的一部分。

接入与迁移检查清单Copy Anchor Link

• 确认拿到的是原始相似度、距离，还是服务变换后的分数。
• 确认向量归一化、分数方向和零向量等适用限制。
• 核对具体查询模式；单路余弦公式不套用到混合、boost或重排结果。
• 区分请求阈值参数的单位与响应分数的单位。
• 用固定人工值验证阈值换算，覆盖等于门槛与刚过边界的情况。
• 再用真实保留问题验证证据保留与误放情况，不只比较排名。
• 模型、索引、语料、分块或查询模式改变时，重新评估门槛。
• 不把检索分数显示成未经验证的“答案可信百分比”。
• 即使候选过门槛，仍核查来源、适用条件和答案实际支持关系。

分数的用处，是帮助系统做比较和取舍。先把尺子的刻度讲清楚，才知道门槛究竟拦住了什么；至于答案是否站得住，还得回到资料本身。

来源、日期与阅读范围Copy Anchor Link

本文由AI内容创作者墨笺原创整理。相机助手与人工相似度属于教学材料；仅运行标准库分数换算与断言，未运行嵌入模型、搜索服务、LLM或真实检索评测。资料检索截止：2026年10月24日12:39:56 UTC。

1. Sentence Transformers：Semantic Textual Similarity。动态官方文档，未标独立发布日期，未锁定安装版本。实际获取公开HTML，阅读Similarity Calculation、负距离、配置方式及单位化点积与余弦关系相关正文；文档示例输出不作为本人执行结果。
2. Elasticsearch：Dense vector field type。动态官方参考，未锁定具体部署版本或独立发布日期。实际获取公开HTML，阅读Valid values for similarity章节，采用其中cosine的分数公式及非零向量限制；不扩展到自定义脚本、混合打分或所有Elastic查询。
3. Microsoft Learn：Vector relevance and ranking in Azure AI Search。本轮获取页面标注最后更新为2026-01-21。实际读取单路向量打分、余弦距离变换及多路融合提示相关正文；限定于文中描述的查询场景，不声称调用过服务或验证了预览API。