当前位置：首页 > 文章列表 > 科技周边 > 人工智能 > RAG 文档切片为什么要保留标题路径：用 Go 生成可追溯检索片段

RAG 文档切片为什么要保留标题路径：用 Go 生成可追溯检索片段

来源：17golang原创 2026-08-27 14:17:36 0浏览收藏

RAG 问答最容易被忽略的不是向量相似度，而是命中之后能不能说清“这句话来自文档的哪一节”。如果切片只保留正文，模型拿到的上下文会像几张没有书签的纸：能回答，却很难回链、纠错和定位版本。给每个片段保存标题路径、片段编号和来源位置，成本很小，却能把检索结果变成可追溯证据。

标题路径不是展示字段，而是检索数据的一部分；它要在切片时进入 Chunk，随后沿着 buildContext 传到回答层，才能稳定生成引用。

实践要点

切片正文时同时保存 heading_path、chunk_id 和 source_anchor。
标题变化应触发新的片段边界，避免把两个章节拼成一个语义块。
检索上下文只拼接命中的片段，但保留来源锚点供回答和日志回查。
引用验收至少检查标题路径、片段编号和原文窗口三项是否一致。

线上症状：答案对了，却找不到出处

一个内部知识库问答返回了正确的配置建议，评审却无法确认它来自哪份运维手册。日志里只有一段相似度最高的文本，没有章节名、页码或稳定 ID。文档更新后，同一段文字甚至可能来自旧版本，问题就从“答得准不准”变成了“这条结论能不能复核”。

RAG 的检索记录至少要能回答三个问题：命中了哪一个文档版本？命中片段在文档结构中的位置是什么？最终上下文把哪些片段交给了模型？这三个答案分别需要 source_id、heading_path 和 chunk_id。

先把文档结构变成 Chunk 元数据

下面的示例不依赖具体向量数据库，先把 Markdown 中的标题路径和正文行组织成稳定的切片对象。示例中的 Chunk、splitByHeading 和 source_anchor 都会在后续检索链路中继续使用。

type Chunk struct {
    ID           string
    SourceID     string
    HeadingPath  []string
    Text         string
    SourceAnchor string
}

func splitByHeading(sourceID string, lines []string) []Chunk {
    var path []string
    var body []string
    var chunks []Chunk
    flush := func() {
        text := strings.TrimSpace(strings.Join(body, "\n"))
        if text == "" { return }
        chunks = append(chunks, Chunk{
            ID: fmt.Sprintf("%s-%03d", sourceID, len(chunks)+1),
            SourceID: sourceID,
            HeadingPath: append([]string(nil), path...),
            Text: text,
            SourceAnchor: fmt.Sprintf("%s#chunk-%03d", sourceID, len(chunks)+1),
        })
        body = nil
    }
    for _, line := range lines {
        if strings.HasPrefix(line, "## ") || strings.HasPrefix(line, "### ") {
            flush()
            path = append(path[:0], strings.TrimSpace(line[2:]))
            continue
        }
        body = append(body, line)
    }
    flush()
    return chunks
}

这里有一个容易漏掉的细节：HeadingPath 必须复制当前路径，而不是把同一个可变切片直接塞进每个 Chunk。否则下一次遇到标题时，旧片段的路径也可能被悄悄改掉。SourceAnchor 则把来源 ID 和稳定序号连起来，后面可以映射到数据库记录或原文窗口。

RAG 文档通过 splitByHeading 生成带 HeadingPath、Chunk 和 source_anchor 的切片数据路径

故障根因：孤立正文切断了回答回链

如果只把 Text 写入向量索引，召回结果通常仍能完成语义匹配，但回答层看到的是脱离上下文的句子。例如“保留七天”可能属于日志保留策略，也可能属于备份保留策略；相邻标题才是消除歧义的线索。

标题路径不应该在检索之后临时拼接。临时拼接往往依赖原始文档再次查找，遇到同名标题、文档重排或异步更新就会错配。更稳妥的做法是让 Chunk 在入库前就带齐结构信息，向量库的 metadata 与正文索引使用同一个 chunk_id。

让 buildContext 保留证据链

召回后不要只做字符串拼接。上下文中的每个片段都应带一个短而稳定的来源头，既让模型知道语义边界，也让日志能够记录实际送入模型的片段集合。

func buildContext(chunks []Chunk) string {
    var blocks []string
    for _, chunk := range chunks {
        heading := strings.Join(chunk.HeadingPath, " / ")
        blocks = append(blocks, fmt.Sprintf(
            "[%s | %s | %s]\n%s",
            chunk.ID, heading, chunk.SourceAnchor, chunk.Text,
        ))
    }
    return strings.Join(blocks, "\n\n")
}

调用方拿到的字符串包含 chunk_id、标题路径和 source_anchor，而不是一堆没有身份的段落；这就是送给回答层的回答上下文。实际接入模型 API 时，还应把这份片段列表作为自己的审计记录保存下来；不要依赖模型是否会原样复述来源头。