RAG 引用为什么会指错段落：chunk_id、来源快照与回答验收

做RAG知识库问答最闹心的坑，不是模型全凭空编答案，而是输出结果末尾带着个看着完全没问题的引用标记，点进去跳转的要么是旧版本文档，要么是完全不相关的相邻段落。用在客服、法务、内部规则查询这类场景里，这种错配反而更难排查，普通用户根本分不清该信回答内容还是跳转出来的原文。

RAG 引用不是给回答末尾加一个跳转链接就完事，整套链路要做到「原文快照—chunk_id—检索结果—回答引用」四个环节指向完全一致的同一份版本内容。

先复现一次“引用看似正确”的错配

假设你们公司把《退款政策》导入内部知识库，六月的版本写着「超过七天需人工审核」，七月更新后的版本改成「超过十四天需人工审核」。如果存元数据的时候只拿文件名当唯一标识，重建索引之后很可能留下两份同名的不同版本文档。结果模型输出了「超过十四天需要审核」这个新内容，附带的引用却指向六月旧文档的对应位置，这就是大家常碰到的引用漂移。

排查这类问题的时候，先把三份证据单独存好：用户的原始提问、最终送入大模型的完整上下文、前端界面实际展示出去的引用对象。只盯着模型返回的最终文字看，根本分不清问题出在召回环节、上下文拼接环节，还是前端用旧链接渲染的环节。

chunk_id 不能只用数组下标生成

每个切块的标识至少要绑定对应的文档快照ID、自身的段落序号、在原文里的字符起止范围。普通的数组下标在重新切分内容、插入新标题、多进程并行写入索引的时候很容易发生错位，只能临时用来调试定位，完全不适合当长期有效的引用唯一键。

type Chunk struct {
    ID          string // 例如 refund-policy:v202607:07:003
    DocumentID  string
    Snapshot    string
    Section     string
    StartOffset int
    EndOffset   int
    Text        string
}

type Hit struct {
    ChunkID  string
    Snapshot string
    Score    float64
    Text     string
}

ChunkID 的核心要求不是字符串长度多短多规整，而是拿到这个ID一定能反查到唯一对应的文档快照。对外给用户展示引用的时候可以生成可读性好的标题、页码这类信息，但后台链路里必须保留这个机器能直接校验的身份标识。

检索结果和模型上下文要携带完整元数据

很多简易实现图省事，直接把所有召回回来的 text 字段内容拼起来塞给提示词，等模型生成完回答之后，再根据之前的相似度排序的位置猜应该对应哪条引用。这种做法直接把 chunk_id 给丢了，就算模型输出了正确的引用序号，上层应用也没办法可靠地映射回真实的原文段落。

type Evidence struct {
    Ref       string
    ChunkID   string
    Snapshot  string
    Title     string
    Text      string
}

func buildEvidence(hits []Hit) []Evidence {
    out := make([]Evidence, 0, len(hits))
    for _, hit := range hits {
        out = append(out, Evidence{
            Ref: hit.ChunkID,
            ChunkID: hit.ChunkID,
            Snapshot: hit.Snapshot,
            Title: "退款政策",
            Text: hit.Text,
        })
    }
    return out
}

送入大模型的上下文可以用 [REF:refund-policy:v202607:07:003] 这类标记把每一段证据包住，同时要求模型生成回答的时候只能引用上下文里实际出现过的REF标记。这类标记本身不是绝对的安全边界，但能给后续的事后校验提供明确的输入依据。

回答生成后做两次引用验收

第一重校验先检查回答里出现的所有引用ID，是不是属于本轮请求的召回集合里的内容，有没有重复、空值、指向已经标记失效的旧快照的情况。第二重校验要检查引用关联的原文内容，是不是真的能支撑回答里对应的那部分陈述。只做第一重校验的话，很容易出现模型引用了完全合法的ID，却输出了证据原文根本没提的结论的情况。

func validateRefs(answer string, evidence map[string]Evidence) error {
    refs := extractRefs(answer)
    if len(refs) == 0 {
        return fmt.Errorf("missing evidence reference")
    }
    for _, ref := range refs {
        item, ok := evidence[ref]
        if !ok || item.Snapshot == "" || item.Text == "" {
            return fmt.Errorf("unknown or empty reference: %s", ref)
        }
    }
    return nil
}

第二重校验可以先跑简单的规则检查：引用标记后面的回答句子，必须包含对应证据里的核心实体或者数值信息，剩下的难判定样本再交给独立的判定模型处理。这个判定模型也必须同时拿到原始的证据快照和用户声明的内容，不能只喂模型已经生成好的最终回答。

文档更新时，先切换快照再淘汰旧索引

源文档更新的时候，不要直接覆盖已经生成好的旧切块内容。更稳妥的流程是先生成全新的文档快照、做完新的切分和索引写入、跑一遍抽样检索验证没问题，再把知识库的 active_snapshot 指针切到新版本上。旧版本的索引可以保留一段时间，方便回溯历史回答的依据，也支持出问题的时候快速回滚。

newSnapshot := "refund-policy:v202607"
indexChunks(newSnapshot)
if err := smokeTest(newSnapshot); err != nil {
    return err
}
activateSnapshot("refund-policy", newSnapshot)
retireSnapshotLater("refund-policy:v202606")

检索服务必须在同一个用户请求的生命周期里固定使用同一份快照，不能第一批召回结果来自新版本，后续补召回的段落又来自旧版本。把 snapshot 作为查询上下文的固定字段存在日志里，线上出问题的时候才有完整的信息复盘全链路。

相关问题：三个容易误判的边界

引用链接能正常打开，就说明引用是正确的吗？

不对。链接可能跳转到同名文档的最新版本，但模型生成回答的时候实际用到的是更早的旧快照内容。链接能不能正常访问，和引用对应的证据内容是否一致，是两项完全独立的检查项。

把 topK 调大就能解决错段落引用的问题吗？

大部分情况下没用。召回的候选数量越多，反而越容易混入相邻段落、旧版本的无关内容。先做好文档版本过滤、同一份父文档去重，再考虑调整召回数量。

为什么线下测试集跑全过，线上还是会出现引用漂移？

大多数测试集只验证最终回答的文字正确性，根本没有校验引用对应的对象和版本。线上要把引用存在性、快照一致性、证据支撑度，还有源文档更新后的回归样本，全部纳入常规指标校验里。

收尾检查：让每条引用都能完整复盘

一套可用的引用验收记录，至少要包含 question_id、active_snapshot、召回的全量 chunk_id、模型原始回答、最终展示给用户的引用、校验结果这几个字段。出现争议的时候，用这些字段就能完整复现当时的运行上下文，比重新发一次请求问模型要靠谱得多。

碰到引用错误的问题，先逐层排查问题出在快照层、切分层、召回层、上下文拼接层还是前端展示层，再修复对应的环节。把所有异常都直接归咎于大模型本身，往往会漏掉那些完全可以靠数据链路规则修正的确定性问题。