登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  人工智能

RAG 引用定位如何把 chunk ID 传回最终回答

来源:17golang原创

时间:2026-09-15 00:18:17 111浏览 收藏

我在做 RAG 问答时最容易踩的坑,不是“检索不到”,而是检索到了以后,回答里的引用无法回到原片段。解决办法是把 chunk_id 当成证据主键:检索层返回它,模型只负责选择它,应用层再把它映射成标题、页码和原文位置。这样即使答案改写了,引用仍然可追溯。

不要让模型直接生成来源 URL。让它返回检索上下文中已经存在的 chunk_id,并在服务端做一次白名单校验。
  • 片段身份:document_id + 稳定的 chunk_id
  • 回答格式:answercitations 分开。
  • 回填原则:无效 ID 不展示,缺失位置就标记待复核。

先把 chunk ID 设计成稳定的证据主键

我第一次实现时用检索结果数组下标当引用编号,重新排序或换 embedding 后,旧回答就指向了错误片段。更稳妥的记录至少包含下面几个字段:document_id 表示文档版本,chunk_id 表示片段,source_titlechunk_text 负责展示。

retrieved = [
    {
        "document_id": "handbook-v3",
        "chunk_id": "handbook-v3:c0012",
        "source_title": "部署手册",
        "chunk_text": "回滚前先保留上一版本的配置快照。",
    }
]
# 注释:chunk_id 不使用临时数组下标,重排结果后仍能定位原片段。
index = {item["chunk_id"]: item for item in retrieved}
RAG 证据记录中 chunk_id 与文档标题和片段文本的静态关系图
图1:证据记录把问题文本、chunk_id、来源标题和片段正文放在同一组可回填关系中。

如果文档会重新切片,建议把版本写进 document_id,不要复用旧片段 ID。引用要能回答“来自哪份文档、哪一块内容”,而不是只回答“排在结果数组第几位”。

把带 ID 的证据上下文交给模型

检索结果不要直接拼成一段没有边界的长文本。可以给每个片段加上稳定标记,并明确告诉模型:只能引用这些标记。OpenAI 的 Responses API 支持调用 file search,也可以通过 include 请求检索结果;如果业务需要自己的 chunk_id,仍应在自建检索层或工具返回值中保留这个字段。

evidence = "\n\n".join(
    f"[chunk_id={item['chunk_id']}]\n{item['chunk_text']}"
    for item in retrieved
)
# 注释:提示词只允许引用本轮证据中的 ID,避免模型凭空创造链接。
instruction = f"只根据证据回答;引用必须来自已有 chunk_id。\n{evidence}"

官方参考:https://developers.openai.com/api/reference/overview

RAG 检索结果、证据上下文、模型回答与 citations 的静态依赖关系图
图2:检索结果数组经证据上下文进入模型,回答正文与 citations 分离,应用层再回填来源标题。

让最终回答返回可校验的 citations

不要只要求模型在自然语言里写“参考资料:……”。更好的是让结果包含两个字段:answer 是读者看到的正文,citations 是数组,每项只放 chunk_id 和可选的证据说明。若使用结构化输出或函数调用,应用层先解析 JSON,再检查引用是否存在于本轮检索结果。

payload = {
    "answer": "回滚前应保留上一版本配置快照。",
    "citations": [{"chunk_id": "handbook-v3:c0012", "claim": "回滚前保留配置快照"}],
}
# 注释:服务端白名单校验后才把标题、页码等展示字段补回去。
valid_citations = [
    {**citation, "source_title": index[citation["chunk_id"]]["source_title"]}
    for citation in payload.get("citations", [])
    if citation.get("chunk_id") in index
]

这里的取舍很明确:模型适合判断“哪一片证据支持这句话”,不适合决定数据库里的公开 URL、页码或权限。那些字段应从 index 或文档元数据服务回填。

什么时候该选内置引用,什么时候保留自定义 ID

场景建议原因
只展示文件级来源优先使用平台返回的文件引用或 annotations接入成本低,来源由平台维护
需要页码、段落、权限过滤自建 chunk_id 白名单业务元数据必须由自己的服务回填
答案要进入审计或工单保存回答、检索快照和 citations后续可重放当时的证据集合

我的经验是:平台内置引用适合快速验证链路,自定义 chunk_id 适合正式产品。两者可以并存,但不要把“模型输出了一个看起来像 URL 的字符串”当成引用成功。

常见问题

chunk_id 要不要直接用数据库自增 ID? 可以,但最好再带上文档版本或租户边界,避免不同知识库之间发生碰撞。

模型返回了不存在的 chunk_id 怎么办? 丢弃这条引用并记录待复核,不要为了让页面有引用而自动拼接未知链接。

为什么有 ID 仍然定位不准? 重点检查切片版本、重排后的检索快照和权限过滤;引用校验只能保证“指向存在的片段”,不能替代召回和排序质量。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>