检索证据打分专题

版本：v1.1
最后更新：2026-07-07
适用对象：正在建设 RAG、企业知识库、文档问答、智能客服、合规问答和 Agent 检索链路的产品、算法、后端与运营同学

1. 为什么检索证据打分很重要

很多 RAG 系统看起来已经有检索能力，但线上回答仍然不稳定。

常见现象包括：

检索到了片段，但片段只能解释背景，不能回答问题。
排名前几的片段关键词很像，但业务结论无关。
新旧制度同时命中，模型引用了旧版本。
同一个问题命中多个部门文档，来源权威性不同。
片段相关但缺上文、缺表格、缺条件，模型被迫猜。
多租户或权限过滤不严，检索到了用户不该看到的证据。
生成答案引用了证据，但证据并没有支撑这句话。

这些问题不能只靠“换一个 embedding 模型”解决。

检索证据打分要解决的是：

检索结果里哪些片段真的能作为证据？
哪些证据应该进入模型上下文？
哪些证据只能作为参考背景？
哪些证据必须触发拒答、补检索或人工确认？

一句话理解：

证据打分是 RAG 从“找得到资料”走向“资料能支撑答案”的关键控制层

2. 证据打分在 RAG 链路中的位置

一个常见 RAG 链路可以拆成：

text

用户问题
 -> query rewrite / expansion
 -> 多路召回
 -> fusion / 初排
 -> rerank / 精排
 -> evidence scoring / 证据打分
 -> context assembly / 上下文装配
 -> answer generation / 生成回答
 -> citation verification / 引用校验
 -> feedback / eval / 回放

这里容易混淆三个概念：

概念	解决的问题	输出
召回	有没有把可能相关的片段找出来	候选片段列表
排序	哪些候选片段应该排在前面	排序分数和顺序
证据打分	这些片段是否足以支撑答案	可用性、可信度、拒答或补检索决策

所以证据打分不是替代检索，也不是替代 rerank。

它更像检索之后、生成之前的质量门禁。

3. 什么是证据

在企业 RAG 里，一个证据片段不应该只是文本。

更推荐把证据建模成结构化对象。

json

{
  "chunk_id": "policy-refund-2026-001#p3",
  "document_id": "policy-refund-2026-001",
  "title": "企业版退款政策",
  "section_path": ["售后政策", "退款条件"],
  "text": "企业版订单开票后不支持自动退款，需要提交人工审批。",
  "source_type": "policy",
  "owner": "finance",
  "updated_at": "2026-06-20",
  "effective_at": "2026-07-01",
  "version": "v3.2",
  "permission_scope": ["tenant:dispatch", "role:finance_viewer"],
  "retrieval_scores": {
    "bm25": 12.4,
    "vector": 0.83,
    "rrf": 0.027
  },
  "evidence_scores": {
    "relevance": 0.91,
    "answerability": 0.88,
    "authority": 0.94,
    "freshness": 0.96,
    "citation_quality": 0.89,
    "final": 0.91
  }
}

这个对象里有两类信息：

检索层信息：BM25、向量相似度、RRF、rerank 分。
证据层信息：是否能回答问题、来源是否权威、是否过期、是否可引用。

不要把两类分数混成一个“相似度分数”。

4. 为什么相似度分数不等于证据质量

向量相似度和关键词相关性很有用，但它们回答的是：

这个片段和问题像不像？

证据质量要回答的是：

这个片段能不能支撑最终答案？

两者差别很大。

情况	相似度可能很高	证据质量可能很低
术语相同但场景不同	是	是
只命中定义，不命中限制条件	是	是
旧版本制度命中新版本问题	是	是
FAQ 命中但没有审批例外	是	是
片段来自低权威评论区	是	是
片段缺失表格上下文	是	是

OpenAI Retrieval 文档强调语义检索可以找出语义相近内容，即使关键词并不重合。这是语义检索的优势，但对生产系统来说，还需要在召回之后判断这些结果能否进入可信回答链路。

5. 证据打分的核心维度

5.1 相关性 relevance

相关性判断片段是否围绕用户问题。

检查问题：

是否回答同一个主题？
是否命中用户问题里的关键实体？
是否命中用户问题里的约束条件？
是否只是词面相似？
是否和 query rewrite 后的意图一致？

示例：

text

问题：企业版开票后还能退款吗？

高相关片段：
企业版订单开票后不支持自动退款，需要提交人工审批。

低相关片段：
企业版支持发票抬头修改。

第二个片段包含“企业版”和“发票”，但并不回答退款问题。

5.2 可回答性 answerability

可回答性判断片段是否足以支撑答案。

5.3 完整性 completeness

完整性判断证据是否缺关键条件。

典型缺失：

缺时间范围
缺适用对象
缺角色或权限
缺版本
缺审批条件
缺例外条款
缺表格行列标题
缺多步骤流程里的某一步

完整性差的证据容易让模型补脑。

5.4 权威性 authority

权威性判断来源是否可信。

常见权威顺序可以是：

text

正式制度 / 合同 / 产品手册
 > 经过审核的知识库文章
 > 运营 FAQ
 > 工单历史回复
 > 聊天记录
 > 用户评论 / 未审核笔记

不同业务可以调整顺序。

高风险场景下，权威性通常比语义相似度更重要。

5.5 时效性 freshness

时效性判断证据是否仍然有效。

检查字段：

updated_at
effective_at
expired_at
version
status
superseded_by

如果两条制度冲突，通常应优先：

生效时间更新的
状态为 active 的
由权威部门发布的
明确覆盖旧版的

5.6 权限与租户 permission

企业知识库里，证据必须先过权限。

一个片段再相关，如果用户无权访问，就不能进入上下文。

检查：

当前用户是否属于该租户？
用户角色是否有读取权限？
是否包含敏感字段？
是否需要脱敏？
是否允许被模型用于生成答案？

权限不应该只在前端做，也要在检索和上下文装配层做。

5.7 可引用性 citation_quality

可引用性判断最终用户能不能验证证据。

好证据通常能提供：

文档标题
章节路径
片段原文
版本
更新时间
链接或锚点
支持了答案里的哪一句

如果只能返回“根据知识库”，那不是合格引用。

5.8 一致性 consistency

一致性判断多个证据之间是否冲突。

冲突类型：

新旧版本冲突
不同部门口径冲突
FAQ 和制度冲突
文档正文和表格冲突
检索片段与用户提供信息冲突

如果冲突无法自动消解，不应该强行回答。

5.9 风险 risk

有些证据本身涉及高风险业务：

法律
财务
医疗
权限
生产环境操作
安全策略
审批结论

高风险证据打分不应该只看相关性，还要看：

是否来自正式来源
是否最新
是否有完整条款
是否需要人工确认
是否允许模型直接给操作建议

6. 推荐的多阶段打分架构

生产系统不要只设计一个总分。

更稳定的做法是分阶段：

text

候选召回分
 -> 融合排序分
 -> 语义重排分
 -> 证据可用分
 -> 信任分
 -> 引用校验分
 -> 最终决策

6.1 第一阶段：候选召回

目标：

尽量把可能有用的证据找出来。

常见方法：

BM25
向量检索
混合检索
metadata filter
query rewrite
多 query expansion

这个阶段更关注 Recall。

宁可多召回一些候选，也不要过早过滤。

6.2 第二阶段：融合排序

如果同时使用关键词检索和向量检索，就要融合不同排序结果。

Azure AI Search 和 Elasticsearch 官方文档都介绍了 Reciprocal Rank Fusion，简称 RRF。

RRF 的核心思想是：

不直接比较不同检索器的原始分数。
而是根据各自排序名次计算融合分。
多个结果列表里都排得靠前的文档，会获得更高最终排名。

一个简化公式：

text

rrf_score(d) = sum(1 / (k + rank_i(d)))

这里：

d 是文档。
rank_i(d) 是文档在第 i 个检索器里的排名。
k 是平滑常数，常见默认值是 60。

RRF 的好处是不用把 BM25 分数和向量相似度硬归一化。

6.3 第三阶段：语义重排

语义重排通常使用 cross-encoder、LLM reranker 或搜索引擎的 semantic ranker。

Microsoft Azure AI Search 文档说明，semantic ranker 会在初始 BM25 或 RRF 排名结果上做二级排序，并且它不能重新扫描整个语料库，只能重排已经进入候选集的结果。

这点非常重要：

rerank 不是召回补救药。
如果正确证据没有进入候选集，rerank 也救不回来。

6.4 第四阶段：证据可用性打分

这一步从“相关”进入“能否支撑答案”。

推荐评分维度：

维度	含义
relevance	是否与问题相关
answerability	是否足以回答问题
completeness	是否缺关键条件
authority	来源是否权威
freshness	是否过期
permission	用户是否可访问
citation_quality	是否可引用
consistency	是否与其他证据冲突
risk	是否需要人工确认

6.5 第五阶段：决策

最终要把分数转成系统行为。

情况	建议动作
高相关、高可回答、高信任	进入上下文并允许回答
高相关、低完整性	补检索或提示缺信息
高相关、低权威	降权，不直接作为结论依据
多证据冲突	触发冲突消解或人工确认
权限不通过	过滤，不进入上下文
高风险且证据不足	拒答或转人工
总分过低	不回答，要求补充信息或重新检索

7. 一个可落地的打分 schema

可以把证据打分结果统一成 JSON。

json

{
  "query_id": "q-20260707-001",
  "chunk_id": "policy-refund-2026-001#p3",
  "document_id": "policy-refund-2026-001",
  "scores": {
    "retrieval": {
      "bm25": 12.4,
      "vector": 0.83,
      "rrf": 0.027,
      "rerank": 0.91
    },
    "evidence": {
      "relevance": 0.92,
      "answerability": 0.88,
      "completeness": 0.84,
      "authority": 0.95,
      "freshness": 0.96,
      "permission": 1.0,
      "citation_quality": 0.9,
      "consistency": 0.86,
      "risk_penalty": 0.05,
      "final": 0.89
    }
  },
  "decision": "use",
  "decision_reason": "证据来自正式政策，版本有效，能够直接回答退款条件。",
  "supported_claims": [
    "企业版订单开票后不支持自动退款",
    "需要提交人工审批"
  ],
  "missing_information": [],
  "conflicts": []
}

7.1 decision 推荐枚举

decision	含义
use	可进入上下文并用于支撑答案
background_only	只能作为背景，不能支撑结论
downrank	降权，但不完全过滤
filter	过滤，不进入上下文
need_more_evidence	需要补检索
conflict	与其他证据冲突，需要消解
human_review	需要人工确认

7.2 为什么要保留 decision_reason

分数本身很难解释。

decision_reason 可以帮助：

人工复盘
评测样例标注
错误归因
优化权重
给运营同学理解为什么某条证据被过滤

8. 总分怎么计算

可以先用可解释的加权方式起步。

text

final_score =
  0.25 * relevance +
  0.20 * answerability +
  0.15 * completeness +
  0.15 * authority +
  0.10 * freshness +
  0.10 * citation_quality +
  0.05 * consistency -
  risk_penalty

这不是固定公式，而是起点。

不同业务应该调整权重：

场景	更高权重
FAQ 问答	relevance、answerability
制度流程	completeness、freshness、authority
法务合规	authority、freshness、risk
技术排障	relevance、completeness、recency
客服工单	answerability、citation_quality
多租户知识库	permission、authority

8.1 不要过早追求复杂模型

证据打分可以从规则加权开始。

成熟后再考虑：

训练 pairwise reranker
使用 LLM judge 做证据可用性评分
用用户采纳率做学习信号
用人工标注做监督微调
按知识域训练不同权重

早期最重要的是可解释和可回放。

9. 阈值策略：分数如何影响回答

打分必须进入系统决策，否则只是报表。

可以先设计三档阈值：

最终分	策略
`>= 0.80`	允许进入上下文并支撑回答
`0.60 - 0.80`	进入上下文，但要求答案标注不确定点
`< 0.60`	不用于结论，触发补检索或拒答

高风险任务需要更严格：

场景	建议阈值
普通 FAQ	0.70 可回答
内部制度	0.80 可回答
财务/法务/权限	0.90 或人工确认
生产操作建议	0.90 + 人工审批

9.1 拒答不是失败

如果证据不足，拒答是正确行为。

推荐回答：

text

当前检索到的资料不足以确认退款期限。已找到的资料只说明需要人工审批，但没有说明审批时限。建议补充“退款审批流程”或“售后时限政策”相关文档。

这比模型猜一个期限更安全。

10. 证据打分和上下文装配

证据打分会直接影响上下文装配。

推荐顺序：

text

高分直接证据
 -> 高权威补充证据
 -> 冲突说明
 -> 背景解释
 -> 不确定点

不推荐：

text

按检索返回顺序全部塞给模型

10.1 上下文装配规则示例

text

上下文装配规则：
1. 只放 decision=use 或 background_only 的片段。
2. decision=use 的片段必须排在 background_only 前面。
3. 同一结论最多放 3 条证据，避免重复。
4. 如果存在 conflict，必须把冲突证据和冲突原因一起放入上下文。
5. 权限不通过的证据绝不进入上下文。
6. 高风险问题如果没有 authority >= 0.9 的证据，禁止直接回答。

10.2 控制证据冗余

多个片段讲同一件事时，不要全部塞进上下文。

可以做：

按 document_id 去重
按 supported_claims 去重
同一章节只保留最高分片段
多个来源冲突时保留代表性证据

冗余证据会浪费上下文，也会让模型误以为某个结论更可靠。

11. 证据打分和引用校验

最终答案里的每个关键结论都应该能回到证据。

推荐做“claim -> evidence”映射。

json

{
  "claim": "企业版订单开票后不支持自动退款。",
  "evidence_ids": ["policy-refund-2026-001#p3"],
  "support_level": "direct",
  "quote": "企业版订单开票后不支持自动退款，需要提交人工审批。"
}

11.1 support_level 推荐枚举

support_level	含义
direct	证据直接支持该结论
partial	证据只支持一部分
inferred	需要推理才能得到
unsupported	没有证据支持
contradicted	证据与结论冲突

如果关键结论是 unsupported 或 contradicted，答案应该被拦截或要求重写。

11.2 引用质量检查

引用不是装饰。

检查项：

引用是否来自进入上下文的证据？
引用是否支持答案里的具体句子？
引用是否保留原文，不被模型改写？
引用是否包含标题、章节、版本和更新时间？
引用是否可点击或可追踪？

12. 人工标注怎么做

证据打分最终要靠样例校准。

建议先做一个小型标注集。

每条样例包含：

json

{
  "question": "企业版开票后还能退款吗？",
  "candidate_evidence": [
    {
      "chunk_id": "policy-refund-2026-001#p3",
      "label": {
        "relevance": 5,
        "answerability": 5,
        "authority": 5,
        "freshness": 5,
        "citation_quality": 4,
        "decision": "use"
      }
    }
  ],
  "expected_answer_policy": "可回答，但必须说明需要人工审批。"
}

12.1 标注等级建议

可以用 1-5 分：

分数	含义
5	完全支持，能直接作为答案依据
4	基本支持，但缺少少量背景
3	相关但不完整，只能作为补充
2	主题相近，但不能支撑答案
1	不相关或误导

12.2 标注冲突处理

如果标注员意见不同，不要简单平均。

应该复盘：

是规则写得不清？
是文档本身模糊？
是业务口径不一致？
是证据切片缺上下文？
是问题表达有歧义？

这些复盘结果应该回流到：

切片策略
metadata
query rewrite
rerank
打分规则
知识库治理

13. 评测指标

证据打分要同时看检索指标、证据指标和最终答案指标。

13.1 检索排序指标

指标	说明
Recall@K	正确证据是否进入前 K
Precision@K	前 K 结果里有多少是真证据
MRR	第一个正确证据排名是否靠前
nDCG	排序是否把更高价值证据放前面

这些指标适合评估召回和排序。

13.2 证据可用性指标

指标	说明
Evidence Use Rate	最终进入上下文的证据比例
Evidence Support Rate	答案关键结论有直接证据支持的比例
Unsupported Claim Rate	无证据结论比例
Conflict Detection Rate	证据冲突被识别的比例
Permission Leak Rate	无权限证据进入上下文的比例

13.3 最终答案指标

LangSmith RAG 评测文档把 RAG 评测拆成答案相关性、答案准确性、检索质量、groundedness 等方向。这个拆法很适合用于证据打分体系。

建议评估：

答案是否正确
答案是否基于检索证据
答案是否覆盖用户问题
答案是否引用正确
答案是否在证据不足时拒答

13.4 离线与在线评测

OpenAI Evals 和 LangSmith Evaluation Concepts 都强调，评测需要数据集、样例和持续迭代。

落地时可以分两类：

类型	用途
离线评测	上线前比较不同检索、rerank、打分策略
在线评测	上线后监控真实问题、异常、漂移和用户反馈

不要只看线上点赞率。

点赞率可能受 UI、用户耐心、问题难度影响，不一定能反映证据质量。

14. 常见策略组合

14.1 FAQ 场景

特点：

问题短
答案固定
证据片段通常短
用户希望直接回答

策略：

强化 query rewrite
提高 relevance 和 answerability 权重
同义词和关键词召回很重要
最好用 FAQ 对作为评测集
低分时建议给相近问题而不是强答

14.2 制度流程场景

特点：

条件多
版本多
例外多
用户可能问具体适用情况

策略：

metadata 必须包含版本、生效时间、发布部门
completeness、authority、freshness 权重更高
冲突证据必须显式处理
答案要引用章节和更新时间
高风险条款不完整时拒答

14.3 技术文档场景

特点：

代码、配置、版本差异明显
片段可能依赖上下文
用户常问报错原因和修复步骤

策略：

保留标题路径、代码块语言、版本号
片段不要切碎代码块
answerability 要检查是否包含完整步骤
新旧版本冲突时按版本过滤
引用最好能定位到具体小节

14.4 客服工单场景

特点：

用户表达口语化
需要结合订单、账号、知识库
常有情绪和风险升级

策略：

先识别意图和风险
知识库证据和业务系统查询结果分开打分
高风险投诉优先转人工
证据不足时追问关键字段
工单历史回复不能自动当正式政策

15. 线上监控与告警

证据打分上线后，要监控这些指标。

指标	异常含义
平均 final_score 下降	检索质量或知识库质量变差
low_score_answer_rate 上升	系统在证据不足时仍然回答
no_evidence_rate 上升	召回失败或权限过滤过严
conflict_rate 上升	知识版本或部门口径冲突
unsupported_claim_rate 上升	生成层开始脱离证据
permission_filter_count 异常下降	可能存在权限过滤失效
rerank_latency 上升	精排链路成本或性能异常

15.1 建议保留的日志字段

json

{
  "query_id": "q-20260707-001",
  "user_id_hash": "u_xxx",
  "tenant_id": "dispatch",
  "query": "企业版开票后还能退款吗？",
  "retrieval_version": "hybrid-v3",
  "rerank_version": "rerank-v2",
  "scoring_version": "evidence-score-v1",
  "top_evidence": ["chunk-1", "chunk-2"],
  "filtered_evidence": ["chunk-9"],
  "decision": "answer",
  "answer_supported": true,
  "latency_ms": 820
}

注意：

日志要脱敏。
不要把密钥、隐私字段、无权限原文直接写进日志。
高风险行业要遵守合规要求。

16. 一个完整案例：退款政策问答

16.1 用户问题

text

企业版开票后还能退款吗？

16.2 候选证据

证据	内容摘要	问题
A	企业版订单开票后不支持自动退款，需要提交人工审批	直接可用
B	发票抬头可以在 30 天内修改	相关词命中，但不回答退款
C	旧版政策：企业版付款后 7 天内可退款	旧版本冲突
D	客服历史回复：一般可以申请看看	低权威

16.3 打分结果

证据	relevance	answerability	authority	freshness	decision
A	0.95	0.92	0.96	0.98	use
B	0.48	0.10	0.90	0.95	filter
C	0.90	0.85	0.80	0.20	conflict
D	0.72	0.40	0.30	0.70	background_only

16.4 最终回答策略

如果 A 是最新有效制度：

text

企业版订单开票后不能自动退款，需要提交人工审批。当前可引用的正式政策是“企业版退款政策 v3.2”，更新时间为 2026-06-20。

如果 A 和 C 都显示 active 且无法判断谁覆盖谁：

text

当前资料存在冲突：新版政策显示开票后不支持自动退款，需要人工审批；旧版政策显示付款后 7 天内可退款。由于两条资料都可能影响结论，建议先确认当前生效版本后再答复。

这就是证据打分真正发挥作用的地方。

17. 实施路线

17.1 第一阶段：让证据可观测

先记录：

query
topK
chunk_id
document_id
source_type
updated_at
retrieval_score
rerank_score
最终是否被使用

这一阶段先不追求复杂模型。

17.2 第二阶段：建立人工样例

准备 50-100 条真实问题。

每条标注：

哪些证据应该进入上下文
哪些证据应该过滤
哪些证据冲突
最终是否应该回答

17.3 第三阶段：加规则打分

先按固定权重：

relevance
answerability
authority
freshness
citation_quality

输出 decision。

17.4 第四阶段：接入评测和回放

每次调整：

embedding
chunking
query rewrite
hybrid search
rerank
scoring weights

都要跑同一批样例。

17.5 第五阶段：按知识域优化

不同知识域拆不同策略：

FAQ
制度
技术文档
合同
工单
多媒体转写

不要所有知识都用同一个阈值。

18. 常见反模式

18.1 只看向量相似度

向量相似度高只能说明语义接近，不能说明能回答。

18.2 分数很多但不影响决策

如果分数没有进入上下文装配、拒答、补检索和人工确认，就只是观测字段。

18.3 低权威证据和正式制度同权

工单历史、聊天记录、用户评论不能和正式政策同权。

18.4 不记录版本

没有版本和生效时间，就无法处理新旧冲突。

18.5 不做权限过滤

无权限证据不能进入模型上下文，否则即使最终没显示，也可能影响答案。

18.6 把 rerank 当万能解法

rerank 只能重排候选集，不能召回不存在的正确证据。

18.7 不做引用校验

答案有引用不代表被引用内容真的支持答案。

19. 推荐搭配阅读

20. 落地检查清单

是否把检索分、rerank 分、证据分分开记录？
是否定义 relevance、answerability、authority、freshness、citation_quality？
是否把权限过滤放在上下文装配之前？
是否能识别旧版本、低权威和冲突证据？
是否有 decision 字段影响回答、拒答、补检索或人工确认？
是否能做 claim 到 evidence 的引用校验？
是否有人工标注样例校准打分？
是否有 Recall@K、MRR、nDCG 等检索指标？
是否有 unsupported claim rate、conflict rate、permission leak rate 等证据指标？
是否对不同知识域设置不同阈值？
是否保留 query、chunk_id、scoring_version 供回放？
是否在高风险场景提高阈值或接人工审批？

21. 推荐资源

以下资源在 2026-07-07 检查时可访问。

官方文档

OpenAI Retrieval：https://developers.openai.com/api/docs/guides/retrieval
OpenAI Evals：https://developers.openai.com/api/docs/guides/evals
Azure AI Search Semantic Ranking：https://learn.microsoft.com/en-us/azure/search/semantic-search-overview
Azure AI Search RRF：https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking
Elasticsearch RRF：https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion
LangSmith RAG Evaluation：https://docs.langchain.com/langsmith/evaluate-rag-tutorial
LangSmith Evaluation Concepts：https://docs.langchain.com/langsmith/evaluation-concepts

22. 最后总结

检索证据打分的目标不是让系统多一个漂亮分数，而是让 RAG 链路具备判断力：

找到的资料是否相关？
资料是否足以回答？
来源是否权威？
版本是否有效？
用户是否有权限？
答案里的结论是否被证据支持？

只要这些问题没有回答清楚，RAG 系统就仍然停留在“把资料塞给模型”的阶段。

真正成熟的知识库问答，需要把证据打分接入上下文装配、拒答、补检索、引用校验、评测和线上监控。

检索证据打分专题 ​

1. 为什么检索证据打分很重要 ​

2. 证据打分在 RAG 链路中的位置 ​

3. 什么是证据 ​

4. 为什么相似度分数不等于证据质量 ​

5. 证据打分的核心维度 ​

5.1 相关性 relevance ​

5.2 可回答性 answerability ​

5.3 完整性 completeness ​

5.4 权威性 authority ​

5.5 时效性 freshness ​

5.6 权限与租户 permission ​

5.7 可引用性 citation_quality ​

5.8 一致性 consistency ​

5.9 风险 risk ​

6. 推荐的多阶段打分架构 ​

6.1 第一阶段：候选召回 ​

6.2 第二阶段：融合排序 ​

6.3 第三阶段：语义重排 ​

6.4 第四阶段：证据可用性打分 ​

6.5 第五阶段：决策 ​

7. 一个可落地的打分 schema ​

7.1 decision 推荐枚举 ​

7.2 为什么要保留 decision_reason ​

8. 总分怎么计算 ​

8.1 不要过早追求复杂模型 ​

9. 阈值策略：分数如何影响回答 ​

9.1 拒答不是失败 ​

10. 证据打分和上下文装配 ​

10.1 上下文装配规则示例 ​

10.2 控制证据冗余 ​

11. 证据打分和引用校验 ​

11.1 support_level 推荐枚举 ​

11.2 引用质量检查 ​

12. 人工标注怎么做 ​

12.1 标注等级建议 ​

12.2 标注冲突处理 ​

13. 评测指标 ​

13.1 检索排序指标 ​

13.2 证据可用性指标 ​

13.3 最终答案指标 ​

13.4 离线与在线评测 ​

14. 常见策略组合 ​

14.1 FAQ 场景 ​

14.2 制度流程场景 ​

14.3 技术文档场景 ​

14.4 客服工单场景 ​

15. 线上监控与告警 ​

15.1 建议保留的日志字段 ​

16. 一个完整案例：退款政策问答 ​

16.1 用户问题 ​

16.2 候选证据 ​

16.3 打分结果 ​

16.4 最终回答策略 ​

17. 实施路线 ​

17.1 第一阶段：让证据可观测 ​

17.2 第二阶段：建立人工样例 ​

17.3 第三阶段：加规则打分 ​

17.4 第四阶段：接入评测和回放 ​

17.5 第五阶段：按知识域优化 ​

18. 常见反模式 ​

18.1 只看向量相似度 ​

18.2 分数很多但不影响决策 ​

18.3 低权威证据和正式制度同权 ​

18.4 不记录版本 ​

18.5 不做权限过滤 ​

18.6 把 rerank 当万能解法 ​

18.7 不做引用校验 ​

19. 推荐搭配阅读 ​

20. 落地检查清单 ​

21. 推荐资源 ​

官方文档 ​

22. 最后总结 ​

检索证据打分专题

1. 为什么检索证据打分很重要

2. 证据打分在 RAG 链路中的位置

3. 什么是证据

4. 为什么相似度分数不等于证据质量

5. 证据打分的核心维度

5.1 相关性 relevance

5.2 可回答性 answerability

5.3 完整性 completeness

5.4 权威性 authority

5.5 时效性 freshness

5.6 权限与租户 permission

5.7 可引用性 citation_quality

5.8 一致性 consistency

5.9 风险 risk

6. 推荐的多阶段打分架构

6.1 第一阶段：候选召回

6.2 第二阶段：融合排序

6.3 第三阶段：语义重排

6.4 第四阶段：证据可用性打分

6.5 第五阶段：决策

7. 一个可落地的打分 schema

7.1 decision 推荐枚举

7.2 为什么要保留 decision_reason

8. 总分怎么计算

8.1 不要过早追求复杂模型

9. 阈值策略：分数如何影响回答

9.1 拒答不是失败

10. 证据打分和上下文装配

10.1 上下文装配规则示例

10.2 控制证据冗余

11. 证据打分和引用校验

11.1 support_level 推荐枚举

11.2 引用质量检查

12. 人工标注怎么做

12.1 标注等级建议

12.2 标注冲突处理

13. 评测指标

13.1 检索排序指标

13.2 证据可用性指标

13.3 最终答案指标

13.4 离线与在线评测

14. 常见策略组合

14.1 FAQ 场景

14.2 制度流程场景

14.3 技术文档场景

14.4 客服工单场景

15. 线上监控与告警

15.1 建议保留的日志字段

16. 一个完整案例：退款政策问答

16.1 用户问题

16.2 候选证据

16.3 打分结果

16.4 最终回答策略

17. 实施路线

17.1 第一阶段：让证据可观测

17.2 第二阶段：建立人工样例

17.3 第三阶段：加规则打分

17.4 第四阶段：接入评测和回放

17.5 第五阶段：按知识域优化

18. 常见反模式

18.1 只看向量相似度

18.2 分数很多但不影响决策

18.3 低权威证据和正式制度同权

18.4 不记录版本

18.5 不做权限过滤

18.6 把 rerank 当万能解法

18.7 不做引用校验

19. 推荐搭配阅读

20. 落地检查清单

21. 推荐资源

官方文档

22. 最后总结