RAG 检索结果为什么要保留来源：从召回片段到答案引用的接口设计

线上知识库接入 RAG 后，回答看起来更完整了，客服却开始追问“这句话来自哪份文档”。如果检索层只返回一串字符串，生成层无法稳定地把结论指回原文，空召回和文档过期也很难排查。更稳妥的做法是把来源定位信息和片段一起作为接口返回，让模型上下文、页面引用和日志使用同一份结构化数据。

RAG 的检索结果不应只是文本数组，而应至少带上稳定的 source_id、标题、片段位置和内容；这样答案引用、审计回溯与失败排查才有共同依据。

先把检索结果从字符串升级成可追溯对象

最小接口先解决调用方真正需要的三件事：模型要读到片段，前端要显示出处，日志要能定位原始文档。下面的结构没有绑定某个向量库，换数据库时也不会迫使生成层重写。

type SourceChunk struct {
    SourceID string
    ChunkID  string
    Title    string
    Locator  string
    Content  string
    Score    float64
}

type RetrievalResult struct {
    Query  string
    Chunks []SourceChunk
    TraceID string
}

SourceID 表示文档身份，ChunkID 表示文档内的片段，Locator 可以是页码、Markdown 标题或段落序号。图片里的 Content / Locator 代表给模型阅读的内容与回链定位，它们比把文件名拼进正文可靠：文件重命名不应该改变引用逻辑，正文也不应承担元数据解析工作。

接口参数要区分检索输入和引用输出

调用方通常会传入用户问题、召回数量和最低分数，但返回对象要把这些输入和结果分开。一个简单的 Go 接口如下：

type Retriever interface {
    Retrieve(ctx context.Context, query string, topK int) (RetrievalResult, error)
}

func buildContext(result RetrievalResult) (string, error) {
    if len(result.Chunks) == 0 {
        return "", errors.New("no retrieval chunks")
    }
    var b strings.Builder
    for _, chunk := range result.Chunks {
        fmt.Fprintf(&b, "[%s] %s\n%s\n", chunk.ChunkID, chunk.Title, chunk.Content)
    }
    return b.String(), nil
}

这里故意没有让 buildContext 重新查询来源。它只消费 RetrievalResult，把片段整理为模型上下文；引用卡片则继续读取同一个结果中的 SourceID、Title 和 Locator。接口职责清晰后，模型换成哪一家服务都不会影响引用数据。

空召回和低质量片段应该怎样表达

“没有找到内容”不是普通的空字符串。上层需要据此决定是直接回答“知识库暂无依据”，还是继续使用通用模型。建议保留 TraceID，并让空结果正常返回、由业务层做策略判断：

result, err := retriever.Retrieve(ctx, question, 5)
if err != nil {
    return Answer{}, fmt.Errorf("retrieve trace=%s: %w", traceID, err)
}
contextText, err := buildContext(result)
if err != nil {
    return Answer{TraceID: result.TraceID, Status: "no_evidence"}, nil
}
answer, err := generator.Generate(ctx, contextText)
if err != nil {
    return Answer{TraceID: result.TraceID, Status: "generation_failed"}, err
}
return attachCitations(answer, result.Chunks), nil

要注意，no_evidence 和 generation_failed 是两种不同状态：前者说明检索阶段没有可用证据，后者说明已有证据但生成调用失败。把两者都写成“回答失败”，后面的监控就失去了分层意义。

引用回链不要依赖模型自己编造

提示词可以要求模型输出片段编号，但最终引用列表仍应由服务端根据 result.Chunks 组装。模型输出的 [chunk-1] 只能作为候选，不能直接当成数据库主键。服务端至少要检查编号是否存在、是否属于本次 TraceID，再把标题和定位信息带给前端。

落地时最容易踩的四个坑

• 只保存模型上下文，不保存原始 RetrievalResult，导致回答无法复核。
• 用数组下标代替 ChunkID，排序变化后引用会指向错误片段。
• 把低分片段和高分片段混在一起，却不记录 Score，排查召回质量时没有证据。
• 生成失败后重新检索一次，日志里的结果与用户实际看到的上下文不一致。

相关问题

为什么不直接让模型输出完整来源 URL？

模型可能改写或臆造 URL。服务端应使用已核验的 SourceID 映射来源地址，模型只输出 ChunkID 候选。

SourceID 和 ChunkID 可以合并吗？

小型原型可以合并，但文档被重新切片后片段身份会变化，生产接口保留两级标识更容易迁移和审计。

topK 越大，引用就越可靠吗？

不一定。过大的 topK 会把相近但无关的片段塞进上下文，应结合分数阈值、去重和上下文长度做验证。

把接口契约当成 RAG 的边界

RAG 系统最值得先固定的不是某个模型参数，而是检索结果的边界。只要 SourceChunk 保留了来源、片段、定位和分数，生成层可以演进，前端引用和故障排查也有稳定抓手。下一次替换切片策略或向量库时，先跑一遍空召回、低分片段、生成超时三类验收，再看答案是否真的可回溯。