RAG 检索结果如何做来源分层：上下文拼接、引用保留与空结果处理

知识库问答最容易出问题的地方，不是模型不会回答，而是检索结果混在一起：一条过期产品说明、一段内部备注和一篇正式规范同时进入上下文，模型很难知道谁更可信。更稳的做法是先给结果分层，再决定拼接顺序；如果没有达到最低证据门槛，就明确返回“未检索到足够依据”，而不是让模型凭常识补全。

RAG 的关键控制点是“检索结果 → 来源分层 → 上下文拼接 → 引用保留 → 空结果分支”。来源等级和最低分数都要在进入模型前确定。

为什么检索命中后还要再做一次来源判断

向量相似度只回答“这段文字像不像问题”，没有回答“这段文字能不能作为依据”。例如用户问“退款窗口是多少天”，旧 FAQ 可能和新政策具有很高相似度，但业务上应该优先采用带版本号和生效日期的正式文档。

因此可以把每个检索片段看成一个带证据属性的对象，而不是一串纯文本：

retrieved = [
    {
        "chunk_id": "policy-2026-04-17",
        "source_level": "official",
        "title": "退款规则",
        "source_url": "https://kb.example.test/policy/refund",
        "text": "自签收次日起七日内……",
        "score": 0.86
    }
]

这里的 source_level 不是模型猜出来的标签，而是入库时由采集流程写入的字段。来源标签缺失时宁可降低优先级，也不要在拼接阶段临时臆测。

用 source_level 和 score 形成可解释的入选规则

来源分层不必做成复杂的机器学习模型，先用一个稳定的业务规则即可复查。下面的示例把正式资料、审核后的业务资料和临时备注分成三档；排序时先看来源等级，再看相似度。

LEVEL_WEIGHT = {"official": 3, "reviewed": 2, "note": 1}

def rank_chunk(chunk):
    level = LEVEL_WEIGHT.get(chunk.get("source_level"), 0)
    return (level, chunk.get("score", 0.0))

selected = sorted(retrieved, key=rank_chunk, reverse=True)[:4]

这个排序只解决“谁先进入上下文”，不代表低等级资料永远不能使用。若正式资料没有覆盖用户问题，可以保留一条审核资料，但要把来源等级原样交给后续提示词和引用渲染层。

拼接上下文时把引用元数据一起带进去

常见的错误是只拼 chunk["text"]，回答生成后再根据记忆补链接。这样做会让引用和事实脱钩。更稳的方式是在每个片段前放一个短标识，并把相同对象保存到 evidence 列表。

def build_context(selected):
    blocks = []
    evidence = []
    for chunk in selected:
        ref = f"[{chunk['chunk_id']}]"
        blocks.append(f"{ref} {chunk['title']}\n{chunk['text']}")
        evidence.append({
            "chunk_id": chunk["chunk_id"],
            "source_url": chunk["source_url"],
            "source_level": chunk["source_level"]
        })
    return "\n\n".join(blocks), evidence

模型看到的是带标识的上下文，应用层保存的是同一批 evidence。最终输出只能引用 evidence 中存在的 chunk_id，这条约束比“请务必引用来源”更容易自动检查。

空结果和低质量结果要走 no_evidence 分支

过滤后没有合格片段，是一个业务状态，不是异常字符串。可以把阈值判断放在上下文拼接之前：如果 selected 为空，返回固定的 no_evidence 状态；如果只有低等级资料，则降低回答范围并要求带引用。

def prepare_query(retrieved):
    selected = [
        chunk for chunk in retrieved
        if chunk.get("source_level") in LEVEL_WEIGHT
        and chunk.get("score", 0.0) >= 0.72
    ]
    if not selected:
        return {"state": "no_evidence", "context": "", "evidence": []}

    context, evidence = build_context(sorted(
        selected, key=rank_chunk, reverse=True
    )[:4])
    return {"state": "ready", "context": context, "evidence": evidence}

调用方只在 state == "ready" 时请求模型；no_evidence 可以提示用户补充关键词、转人工检索，或返回明确的证据不足说明。这里别急着把阈值调得很低，先抽样检查被过滤的片段是否真的能回答问题。

用三组检查验收一条 RAG 回答链路

线上日志至少记录查询文本的脱敏摘要、入选 chunk_id、来源等级、阈值和最终状态。不要只记录模型回答；出了争议时，真正需要复盘的是“哪些证据被送进去了”。

常见问题：来源分层和上下文拼接怎么取舍

来源等级越高，是否就一定应该排在最前面？

不一定。来源等级是可信度优先级，score 是语义相关度；正式资料完全不覆盖问题时，硬排第一只会稀释有效证据。可以先设最低相关度，再在合格集合内按等级排序。

为什么不能让模型自己判断 source_level？

模型可以辅助分类，但最终等级应来自采集、审核或发布系统。把权限和生效状态交给生成模型，会让同一来源在不同问题下出现不稳定判断。

空结果时返回“我不知道”就够了吗？

还不够。应用需要返回机器可读的 no_evidence 状态，并保留过滤原因，前端才能提示用户改写问题或转人工，而不是把一次检索失败伪装成普通回答。

把证据边界固定在进入模型之前

RAG 的可靠性来自一条可回放的证据链：检索片段先带着 source_level 和 score 接受筛选，再把 chunk_id、source_url 和正文一起进入上下文；过滤为空则明确结束在 no_evidence。这几个状态都能在日志和测试里复现，后续更换向量库或模型时，验收标准也不会跟着漂移。