当前位置：首页 > 文章列表 > 科技周边 > 人工智能 > RAG 切块与引用定位怎么配置或排查

RAG 切块与引用定位怎么配置或排查

来源：17golang原创 2026-09-13 01:57:07 0浏览收藏

RAG 出现“能回答但引用不准”，通常不是向量库单独出了问题，而是切块和定位从一开始就没有绑定起来。实用的配置顺序是：先按标题、段落或表格保留语义边界，再用模型的 token 预算控制长度，最后把文档版本、章节和字符区间一并写入每个 chunk。这样检索返回的不只是文本，还能回指到原文位置。

要点速览

切块大小没有通用常数，先保证一个片段围绕一个可回答的小问题。
stride 只负责跨边界保留上下文，不能替代结构化切分。
引用定位至少保存稳定的 doc_id、版本、章节和字符偏移。

先按文档结构确定 RAG 的切块单位

不要一上来按固定字符数截断整篇文档。对产品手册、接口文档和规章制度，更稳妥的顺序是“标题层级 → 段落 → 表格或列表”，再对超长段落做二次切分。每个 chunk 还应带上父级标题，例如“部署 / 环境变量 / 超时设置”，否则向量相似度相近的片段会互相混淆。

起步时可以把单片段预算设在约 300～700 tokens，重叠设为 40～100 tokens；这是待验证的初始值，不是所有模型都适用的标准。短问答可缩小片段，带定义、条件和例外的规范文本则要保留完整小节。切完后抽 20 个真实问题检查：答案所需的定义、条件、结论是否仍在同一片段或相邻片段内。

用 token 预算和 offset 处理长文本

字符数不等于模型 token 数，中文、代码和 URL 的切分比例也不同。以 Hugging Face Transformers 为例，Tokenizer 支持 max_length 控制上限，stride 保留溢出片段的尾部上下文，return_overflowing_tokens 返回溢出片段，快速 Tokenizer 还可用 return_offsets_mapping 得到字符起止位置。

from transformers import AutoTokenizer

# 这里的长度是入库前的片段预算，需给提示词和特殊 token 留余量。
tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese", use_fast=True)
encoded = tokenizer(
    text,
    max_length=512,
    truncation=True,
    stride=64,
    return_overflowing_tokens=True,
    return_offsets_mapping=True,
)

chunks = []
for index, (ids, offsets) in enumerate(zip(encoded["input_ids"], encoded["offset_mapping"])):
    # 去掉特殊 token 的无效偏移后，保存片段在原文中的字符范围。
    valid = [(start, end) for start, end in offsets if end > start]
    if not valid:
        continue
    start_char, end_char = valid[0][0], valid[-1][1]
    chunks.append({
        "chunk_index": index,
        "text": text[start_char:end_char],
        "start_char": start_char,
        "end_char": end_char,
    })

这段配置只展示切分契约，实际入库前还要补齐标题、文档版本和权限字段。常见排查顺序如下：

现象	优先检查	处理方向
引用总指向段落末尾	offset 是否来自同一份清洗文本	固定清洗版本，禁止重新折叠空白后再定位
答案缺少前置定义	chunk 是否从句子中间开始	先按标题和段落切，再在段落内按 token 切
相邻片段内容重复太多	stride 是否接近片段长度	减小重叠，并用真实问题比较召回结果

RAG 文档结构、token 预算和相邻片段重叠的静态关系示意图 — 图1：RAG 切块的操作示意图，展示文档标题、段落、token 预算、重叠窗口和片段索引之间的静态关系。

引用定位要绑定稳定坐标，而不是只存一段文本

向量库中的文本可能会被清洗、重排或重新嵌入；如果引用只保存“第 3 条结果”，下一次索引后就可能漂移。建议把下面这些字段作为最小定位元数据：doc_id、doc_version、source_url、section_path、page（有页码时）、start_char、end_char 和稳定的 chunk_id。其中 chunk_id 可由文档 ID、版本和片段序号组成，重建同一版本时不要随机生成。

引用展示时不要让模型凭记忆编造链接。把检索结果包装成带分隔符的证据块，例如 [chunk_id=manual-v3-014]，生成提示明确要求“每个事实后引用对应 chunk_id；上下文没有答案时说明证据不足；来源冲突时分别引用”。模型返回后，应用层再根据 chunk_id 查元数据生成可点击的原文链接或页码高亮。引用格式由应用层落地，可靠性会高于单靠提示词。

RAG chunk_id、章节路径、字符偏移和原文链接之间的引用定位关系示意图 — 图2：引用定位的结果示意图，展示检索片段如何通过文档版本、章节路径和字符偏移回指原文。

把检索结果和生成门禁连成一条链

排查时要分清三个层次：切块是否完整，检索是否召回，生成是否正确引用。先对固定问题记录 top-k 的 chunk_id、相似度和过滤条件，再看答案中的每个结论是否能在返回片段中找到原句。只改 prompt 而不检查召回片段，往往只能让措辞更像引用，不能修复漏召回。

如果正文有权限边界，还要在检索前执行租户或文档权限过滤，并把权限版本纳入重建策略。文档更新时生成新 doc_version，旧版本可以保留用于审计，但不要让新旧版本无条件混排。Hugging Face 的 RAG 文档展示了检索文档、文档得分和上下文输入等对象；微软的 RAG 指南也强调把标题、章节和来源 URL 随 chunk 传入上下文，这正是引用能稳定落地的基础。