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

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

先按文档结构确定 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,
    })

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

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

向量库中的文本可能会被清洗、重排或重新嵌入；如果引用只保存“第 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 查元数据生成可点击的原文链接或页码高亮。引用格式由应用层落地，可靠性会高于单靠提示词。

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

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

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

常见问题

chunk 越大，回答是不是越完整？

不一定。过大会稀释相似度并挤占上下文，过小又会切断定义和条件。先按结构切分，再用真实问题比较召回和引用覆盖率。

只保存 page 和 chunk_index 够不够？

对固定版 PDF 可能够用；网页、Markdown 或会频繁更新的文档还应保存版本和字符偏移，否则页面重排后无法精确复查。

引用错误一定是 embedding 模型的问题吗？

不是。先检查清洗文本、切块边界、过滤条件和 top-k 结果，再判断是否需要更换 embedding 或增加关键词检索。

官方资料：https://huggingface.co/docs/transformers/main/model_doc/rag