AI 知识库检索召回工作流：从文档切分到重排和证据引用

很多 AI 知识库刚接入时看起来很顺：上传文档、生成向量、提问返回答案。但上线后常见问题很快出现：用户问的是 A，召回片段却是 B；答案像是对的，却找不到原文依据；文档更新后，旧答案还在被引用。

这篇文章按完整工作流梳理一套 RAG 知识库检索方案。重点不在某个单点工具，而是从文档进入系统开始，把切分、索引、召回、重排、生成和复查串成可维护流程。

目标和边界：知识库检索要解决什么

知识库检索的目标不是“把所有文档塞进模型”，而是在用户提问时找到少量高相关证据，让模型基于证据回答。一个可上线的流程至少要满足三点：

• 能召回正确片段，而不是只召回相似词。
• 答案能指出依据，便于用户和运营复查。
• 文档更新、删除、过期时，索引能跟着变化。

本文默认场景是企业内部文档、产品帮助中心、接口说明、运维手册一类文本知识库；不展开音视频理解、多模态检索和复杂权限体系。

全流程总览：从文档入口到证据回答

先说结论：RAG 知识库应该按“文档治理 -> 切片 -> 向量入库 -> 查询处理 -> 召回重排 -> 证据回答 -> 复查改进”的顺序建设。不要只把精力放在模型回答上，前面的检索质量决定了后面的答案上限。

阶段 1：清洗文档并设计切片规则

目标：让进入知识库的内容结构稳定。切片不是简单按固定字数截断，好的切片应该保留标题、章节、来源和版本。

关键动作：

• 清理页眉页脚、重复目录、空白行和无意义编号。
• 把文档标题、章节标题、来源路径、更新时间写成字段。
• 按语义段落切片，再用最大长度兜底。
• 为每个片段保存原文定位信息，方便答案引用。

def chunk_text(title, paragraphs, max_chars=900, overlap=120):
    chunks = []
    current = []
    current_len = 0

    for paragraph in paragraphs:
        if current_len + len(paragraph) > max_chars and current:
            text = "\\n".join(current)
            chunks.append({"title": title, "text": text})
            current = [text[-overlap:], paragraph]
            current_len = sum(len(item) for item in current)
        else:
            current.append(paragraph)
            current_len += len(paragraph)

    if current:
        chunks.append({"title": title, "text": "\\n".join(current)})

    return chunks

检查点：随机抽 20 个片段，确认每个片段能独立表达一个知识点，同时还能看到它属于哪份文档、哪个章节。

阶段 2：向量入库并保留可过滤字段

目标：让相似度检索和业务过滤同时生效。只存文本向量不够，还要把业务字段带进去，例如产品线、文档类型、版本、语言、权限范围和更新时间。

关键动作：

• 为每个切片生成向量，并保存切片正文。
• 保存文档来源、章节路径、版本号和更新时间。
• 建立同步记录，文档变更后能更新或删除旧片段。
• 准备一组标准问题，用来检查入库质量。

{
  "chunk_id": "manual_2026_001_03",
  "doc_title": "订单同步接口说明",
  "section": "错误码处理",
  "product": "order-center",
  "version": "2026-06",
  "text": "当接口返回 429 时，应进入限流重试流程..."
}

检查点：同一个问题在指定产品线内能召回正确片段；切换产品线后，不会混入其他业务的旧文档。

阶段 3：查询改写、过滤和召回候选

目标：把用户问题转成适合检索的查询，并用业务字段先缩小范围。比如“这个错误怎么处理”本身太短，最好补出产品、模块、错误码或页面名。

关键动作：

• 从会话和页面上下文里补充产品、模块、版本。
• 对明确字段先做过滤，再做向量召回。
• 召回数量不要太小，先保证候选覆盖，再交给重排收窄。
• 记录每次召回的片段 ID、分数和过滤条件。

def build_search_plan(question, context):
    filters = {
        "product": context.get("product"),
        "version": context.get("version"),
        "doc_type": context.get("doc_type"),
    }
    query = f"{context.get('module', '')} {question}".strip()
    return {"query": query, "filters": filters, "top_k": 20}

检查点：对标准问题查看候选列表，确认正确答案片段至少出现在前 20 个候选里。如果根本没有进入候选，优先修切片、字段过滤或查询改写。

阶段 4：重排片段并生成带证据的回答

目标：把候选片段压缩成少量高质量证据，减少无关内容干扰。重排后再生成回答，并要求答案引用片段标题、章节或编号。

关键动作：

• 对候选片段按“问题和片段是否直接相关”重新排序。
• 只把前几条高质量片段交给回答模型。
• 生成答案时保留引用，例如“依据《订单同步接口说明 / 错误码处理》”。
• 如果没有足够证据，返回“知识库未找到明确依据”，不要硬编。

检查点：答案中的每个关键结论都能在引用片段里找到原文支持；没有证据时，系统能明确拒答或提示补充文档。

推荐工作流：一个可落地的上线顺序

1. 先选一个小范围知识库，例如 30 到 100 篇高质量文档。
2. 清理文档并补齐标题、章节、版本和产品线字段。
3. 设计切片规则，人工抽样检查可读性。
4. 向量入库后，用标准问题检查召回候选。
5. 增加过滤条件和重排流程，减少无关片段。
6. 生成回答时强制携带证据标题和片段编号。
7. 上线后记录用户问题、命中片段、反馈结果，定期修切片和文档。

容易踩坑：为什么知识库越用越不准

坑 1：切片只按长度，不看章节

固定长度切片容易把一个操作步骤切断，也容易把两个主题混在一起。后果是召回看似相似，实际答不到点上。

坑 2：没有版本字段

产品文档一更新，旧片段仍然参与回答。用户问 2026 版功能，系统却引用了旧版本说明，这类问题必须靠版本字段和同步记录解决。

坑 3：只看最终答案，不看召回片段

答案错了不一定是模型问题。很多时候正确片段根本没有被召回，或者被低质量片段挤掉。排查时要先看候选，再看重排，最后看生成。

速查表：阶段、检查点和异常信号

AI 知识库的稳定性不是单靠模型变强得到的，而是靠一条可复查的检索链路：文档清楚、切片合理、召回覆盖、重排准确、回答有证据。把这条链路做好，后续换模型、换向量库或扩展文档范围都会更稳。