我的 RAG 检索回来的片段总是缺头少尾、答非所问,我一直以为是检索算法不行,最后才发现是文档切块的策略从一开始就错了的深度复盘

这是一个让我对"RAG 里切块有多重要"刻骨铭心的故事。我做了一个 RAG(检索增强生成)的问答应用:把文档切成小块、转成向量存进库,用户提问时检索最相关的几块、喂给大模型作答。检索这一步,我用的 embedding 模型没问题、向量库也没问题(这些坑我之前踩过了)。可问答的效果,就是不好。

具体的毛病,很诡异:检索回来的那些片段,常常缺头少尾——一句话被从中间截断,前半句在这个片段、后半句不知道去哪了;或者,一个片段里,塞着好几个不相关的主题,东一句西一句。结果,大模型拿着这些支离破碎、又混杂的片段去回答,自然就答非所问、答得不完整。我一开始,把锅都甩给了"检索算法":是不是相似度算得不准?是不是该换个更高级的检索方法?我折腾了半天检索这一环,效果毫无改善。直到我回过头,去看那些被存进库的片段本身长什么样,才恍然大悟,补上了关于 RAG 最容易被忽略的一课:问题的根子,根本不在检索,而在更上游的"文档切块(chunking)"——我把文档切成块的方式,从一开始就错了!我当初图省事,用的是最粗暴的"按固定长度切":不管文档的语义、不管句子和段落的边界,就每隔 N 个字符,硬切一刀。这就造成了两个致命问题。第一,切断了语义:一刀下去,常常正好切在一句话、一个段落的中间,把一个完整的意思,生生劈成了两半——于是,每个片段,都可能缺头少尾、语义不完整。第二,主题混杂:如果切块的粒度没控制好,一个片段里,可能同时塞了好几个不相关的主题,导致这个片段的向量,语义被"稀释"得模糊不清,既检索不准、内容也杂乱。归根结底:RAG 的效果,极大地取决于"喂给它的知识块,质量好不好";而切块,正是决定知识块质量的、最上游的一环。我之前,只盯着"检索"和"生成"这两个看得见的环节,却完全忽略了,那个默默地、在最前面决定了一切原材料质量的"切块"——我用劣质的、切碎了的原材料,去喂一个再好的检索和模型,做出来的,自然也是劣质的答案。这,就是"garbage in, garbage out"在 RAG 里的体现。

故障现场:按固定长度硬切,把语义切得支离破碎

我把这个"切块切坏了"的现场,用例子摊开给你看:

# ✗ 灾难: 按固定长度"硬切", 不管语义和边界
def bad_chunk(text, size=200):
    # 每 200 个字符切一刀, 完全不管句子/段落
    return [text[i:i+size] for i in range(0, len(text), size)]

# 假设原文是:
#   "退款政策: 商品签收后 7 天内可申请退款, 需保证不影响二次销售。
#    生鲜类商品一经售出概不退换。退款将在 3-5 个工作日内原路返回。"
#
# bad_chunk 按 200 字硬切, 可能切成:
#   片段1: "退款政策: 商品签收后 7 天内可申请退款, 需保证不影响二次销售。生鲜类商品一经售"
#   片段2: "出概不退换。退款将在 3-5 个工作日内原路返回。"
#   ↑ "生鲜类商品一经售|出概不退换" 被从中间切断了! 语义残缺。

# 两个致命问题:
# 1. 切断语义: 一刀切在句子/段落中间 → 片段缺头少尾、意思不完整。
#    - 检索到"片段1", 用户问"生鲜能退吗", 答案的关键"概不退换"在片段2, 漏了!
# 2. 主题混杂: 块太大 → 一个块塞多个主题 → 向量语义被稀释, 检索不准。
#    块太小 → 上下文不足 → 一个完整的意思被拆碎, 召回了也不完整。

# 结果(我以为是检索的锅, 其实是切块的锅):
#   - 检索回来的片段, 缺头少尾 / 主题混杂。
#   - 模型拿着残缺、混杂的片段 → 答非所问、答不完整。

# 根因: 切块策略粗暴(按固定长度硬切, 无视语义/边界/重叠)
#   → 知识块质量差 → RAG 效果差(garbage in, garbage out)。
#   而我一直盯着"检索"环节调, 没意识到根子在更上游的"切块"。

看着这些被切坏的片段,我才算真正理解了这个"答非所问"的根源。问题的根子,根本不在我一直折腾的"检索"环节,而在更上游的"文档切块(chunking)"——我把文档切成块的方式,从一开始就是错的。我当初图省事,用的是最粗暴的"按固定长度切":不管文档的语义、不管句子和段落的边界,就每隔 N 个字符,硬切一刀。这就造成了两个致命问题:第一,切断了语义——一刀下去,常常正好切在一句话、一个段落的中间,把一个完整的意思,生生劈成两半;于是,每个片段,都可能缺头少尾、语义残缺(比如那个例子里,"生鲜类商品一经售|出概不退换"被切断了,用户问"生鲜能退吗",检索到前半个片段,关键的"概不退换"却在后一个片段里,答案就漏了)。第二,主题混杂——如果切块的粒度没控制好:块太大,一个片段里可能塞了好几个不相关的主题,导致它的向量语义被"稀释"得模糊不清,既检索不准、内容也杂;块太小,则上下文不足,一个完整的意思被拆得太碎,召回了也不完整。这就完美解释了我的困惑:我以为是"检索"的锅(相似度不准、算法不行),拼命去调检索;可检索算法,本身没问题——它忠实地,从一堆本身就支离破碎、又混杂的片段里,检索出了"最相关"的;问题是,这些片段的原材料质量,本身就太差了。归根结底:RAG 的效果,极大地取决于"喂给它的知识块,质量好不好";而切块,正是决定知识块质量的、最上游的一环。我之前,只盯着"检索"和"生成"这两个看得见的环节,却完全忽略了那个默默地、在最前面就决定了一切原材料质量的"切块"。我用劣质的、被切碎了的原材料,去喂一个再好的检索和模型,做出来的,自然也是劣质的答案——这,就是 "garbage in, garbage out(垃圾进,垃圾出)" 在 RAG 里的、活生生的体现。

第一件事:搞懂切块质量决定 RAG 效果

定位到根源,我必须把"切块为什么如此关键、好的切块该是什么样"彻底搞清楚:

RAG 里, 切块(chunking)的质量, 极大地决定最终效果

# RAG 的流程, 切块在最上游:
#   文档 →【切块 chunking】→ 块 → embedding → 存库 → 检索 → 喂给 LLM 作答
#   ↑ 切块, 决定了"知识块"的质量; 后面再好, 也救不回烂的块。

# 切块切不好, 会怎样?
# 1. 切断语义(按固定长度硬切): 句子/段落被劈两半 → 片段缺头少尾、意思残缺。
# 2. 块太大: 一块多主题 → 向量语义被"稀释", 检索不精准。
# 3. 块太小: 上下文不足 → 一个完整意思被拆碎, 召回了也不完整。
# 4. 丢了结构: 标题、列表、表格被切乱 → 失去原文的层次和关联。

# 好的切块, 应该:
# 1. 尊重语义/结构边界: 按句子、段落、章节切, 别从中间硬切。
# 2. 大小合适: 一个块, 表达"一个相对完整的意思", 不太大也不太小。
# 3. 适当重叠(overlap): 相邻块之间, 留一点重叠内容,
#    避免"刚好切在关键信息处"导致两边都不完整(给边界处一个缓冲)。
# 4. 保留必要上下文: 比如给每个块, 带上它所属的"标题/章节"信息。

# 一个核心认知: RAG = 检索 + 生成, 但它的"原材料", 是切好的知识块。
#   "原材料(块)的质量", 是 RAG 效果的地基。
#   检索和生成再强, 也补不回"切块"这一步丢掉的质量(garbage in, garbage out)。

# 核心: 切块质量决定 RAG 效果, 且它在最上游、最易被忽略。
#   要按语义/结构切、大小合适、适当重叠、保留上下文。

原理终于清晰了。在 RAG 的整个流程里,切块,处在最上游:文档 →【切块】→ 块 → embedding → 存库 → 检索 → 喂给 LLM 作答;切块,决定了"知识块"的质量,而后面的环节再好,也救不回烂的块。切块切不好,会有几种后果:切断语义(按固定长度硬切,句子/段落被劈两半,片段缺头少尾)、块太大(一块多主题,向量语义被稀释、检索不准)、块太小(上下文不足,意思被拆碎、召回了也不完整)、丢了结构(标题、列表、表格被切乱,失去原文的层次和关联)。而好的切块,应该:第一,尊重语义/结构的边界——按句子、段落、章节来切,别从中间硬切;第二,大小合适——一个块,表达"一个相对完整的意思",不太大也不太小;第三,适当重叠(overlap)——相邻的块之间,留一点重叠的内容,避免"刚好切在关键信息处"导致两边都不完整(给边界处一个缓冲);第四,保留必要的上下文——比如,给每个块,带上它所属的"标题/章节"信息。由此,我建立起一个核心认知:RAG,虽然叫"检索 + 生成",但它真正的"原材料",是那些被切好的知识块;而"原材料(块)的质量",才是 RAG 效果的地基;检索和生成再强,也补不回"切块"这一步丢掉的质量——这,正是 "garbage in, garbage out" 的道理。归根结底:切块的质量,极大地决定了 RAG 的效果;而它,恰恰处在最上游、最容易被忽略的位置。要把切块做好——按语义/结构切、大小合适、适当重叠、保留上下文——这,是我用一次"答非所问、还错怪了检索算法"的事故,补上的、关于 RAG 最关键、也最易被忽视的一课。

第二件事:正解——按语义/结构切,大小合适,适当重叠

搞懂了根因——"按固定长度硬切、切碎了语义"——正解就清晰了:别按固定字符数硬切,而要按"语义/结构边界"切(优先按段落、章节、句子);把块的大小控制在合适的范围(表达一个相对完整的意思);相邻块之间留一点重叠(overlap);并给每个块带上必要的上下文(如标题)。

# 正解1: 按"语义/结构边界"切(递归地按段落/句子切, 别从中间硬切)
# 思路: 优先按"大边界"(章节/段落)切; 太大再按"小边界"(句子)切。
# (实践中常用 LangChain 的 RecursiveCharacterTextSplitter 等, 原理如下)
def smart_chunk(text, target_size=500, overlap=50):
    paragraphs = text.split("\n\n")      # 先按段落分(尊重结构边界)
    chunks, cur = [], ""
    for para in paragraphs:
        if len(cur) + len(para) <= target_size:
            cur += para + "\n\n"          # 攒到一个块里, 直到接近目标大小
        else:
            if cur: chunks.append(cur.strip())
            cur = (cur[-overlap:] if cur else "") + para + "\n\n"  # 带一点重叠
    if cur: chunks.append(cur.strip())
    return chunks
# → 块尽量在"段落边界"结束, 不从句子中间切; 块之间有重叠缓冲。

# 正解2: 给每个块"带上上下文"(标题/章节), 别让它成为无源之水
chunk_with_context = f"【章节: {section_title}】\n{chunk_text}"
# → 检索/作答时, 块自带它的归属信息, 语义更完整、更准。

# 正解3: 块大小要"合适"(按内容类型和场景调)
#   - 太大(如 2000+ 字): 多主题混杂, 向量稀释, 检索不准。
#   - 太小(如 几十字): 上下文不足, 意思被拆碎。
#   - 经验值: 几百字一块(具体按文档类型/embedding 模型上限/问答粒度调)。

# 正解4: 按文档类型, 用专门的切法
#   - Markdown/HTML: 按标题层级(#, ##)切, 天然的语义结构。
#   - 代码: 按函数/类切, 别从函数中间切。
#   - 表格/PDF: 保留表格结构, 别切散。
#   - 对话/日志: 按轮次/条目切。

# 核心: 按语义/结构边界切 + 大小合适 + 适当重叠 + 带上下文。
#   让每个块, 都是一个"语义完整、主题聚焦、自带归属"的优质知识单元。

这套正解,核心是让每一个切出来的块,都成为一个"语义完整、主题聚焦"的优质知识单元。正解1(按语义/结构边界切):别按固定字符数硬切,而要优先按"大的结构边界"(章节、段落)切,块太大了,再按"小的边界"(句子)切(实践中常用 LangChain 的 RecursiveCharacterTextSplitter 这类工具,原理就是如此);这样,块尽量在段落/句子的边界结束,而不会从中间硬切。正解2(给每个块带上上下文):给每个块,带上它所属的标题/章节信息(如 【章节: 退款政策】...),别让一个块成为"无源之水"——这样,检索和作答时,块自带它的归属信息,语义更完整、也更准。正解3(块大小要合适):太大(如 2000+ 字),多主题混杂、向量稀释、检索不准;太小(如几十字),上下文不足、意思被拆碎;经验值是几百字一块(具体要按文档类型、embedding 模型的上限、问答的粒度来调)。正解4(按文档类型用专门的切法):Markdown/HTML 按标题层级切(天然的语义结构)、代码按函数/类切(别从函数中间切)、表格/PDF 保留表格结构、对话/日志按轮次/条目切。归根结底:按语义/结构边界切 + 大小合适 + 适当重叠 + 带上上下文——让每一个块,都成为一个"语义完整、主题聚焦、自带归属"的优质知识单元。我那次的错误,是用最粗暴的固定长度硬切、把语义切得稀碎;而正解,是用尊重语义和结构的方式,切出高质量的块。

下面这张图,对比了"固定长度硬切"和"按语义切"两条路径:

这张图的对比很清楚:左边红色那条,按固定长度硬切、切在句子/段落中间,片段缺头少尾、多主题混杂,检索到的是残缺片段、模型答非所问;右边绿色那条,按语义/结构边界切、大小合适且带重叠,每块语义完整、主题聚焦、带上下文,检索到完整片段、模型答得又准又全。两条路的根本分野,在于切块时,有没有尊重文档的语义和结构。

第三件事:提升 RAG 质量的其它环节

填平了切块这个上游坑,我系统梳理了一遍:除了切块,还有哪些环节,共同决定着 RAG 的质量:

RAG 质量的完整链条(切块只是其一, 但很关键):

# RAG 全链路, 每一环都影响质量:
# 1. 文档清洗: 去掉页眉页脚、乱码、无关内容(脏数据进去就是脏)。
# 2. 切块 chunking(本文): 按语义切、大小合适、重叠、带上下文。
# 3. embedding: 选对模型, 建库和查询用同一个(见"embedding 不一致"那篇)。
# 4. 检索: 向量检索 + 关键词检索(混合检索)往往更好; 调 top_k。
# 5. 重排序 rerank: 召回 top 20 → rerank 精排出最相关的 top 3-5 喂给模型。
# 6. 上下文组装: 把检索到的块, 有序、清晰地组织进 prompt(别堆成一团)。
# 7. 生成: 好的 prompt(让模型"基于给定片段作答, 没有就说不知道", 防幻觉)。
# 8. 引用/溯源: 让答案能追溯到来源块(便于核实、对治幻觉)。

# 排查 RAG 效果差, 从上游往下看:
#   - 先看"检索回来的块"对不对、完不完整 → 不对/不完整, 多半是切块/embedding。
#   - 块没问题但答得差 → 看 prompt、上下文组装、生成环节。
#   → 别一上来就怪"检索算法"或"模型笨"——先看上游的"原材料"。

# 核心: RAG 是一条链, 每一环都影响质量, 而"切块"是最上游、最易忽略的一环。
#   排查时从上游("块的质量")往下查; 优化时, 切块/检索/rerank/prompt 一起抓。

这一梳理,让我对 RAG 的全貌,有了系统的认识。RAG 是一条完整的链,每一环都影响着最终质量:文档清洗(去掉页眉页脚、乱码、无关内容——脏数据进去就是脏);切块(本文——按语义切、大小合适、重叠、带上下文);embedding(选对模型,建库和查询用同一个);检索(向量检索 + 关键词检索的混合检索往往更好,调 top_k);重排序 rerank(召回 top 20,再精排出最相关的 top 3-5 喂给模型);上下文组装(把检索到的块,有序、清晰地组织进 prompt,别堆成一团);生成(好的 prompt,让模型"基于给定片段作答、没有就说不知道",以对治幻觉);引用/溯源(让答案能追溯到来源块,便于核实)。而排查 RAG 效果差,要从上游往下看:先看"检索回来的块"对不对、完不完整——如果不对/不完整,那多半是切块或 embedding 的问题;如果块没问题、但答得差,再去看 prompt、上下文组装、生成 环节。别一上来就怪"检索算法"或"模型笨"(就像我那次)——要先看上游的"原材料"。归根结底:RAG 是一条链,每一环都影响质量,而"切块",是最上游、也最容易被忽略的一环;排查时,从上游("块的质量")往下查;优化时,把切块、检索、rerank、prompt,一起抓——这样,才能系统地,把 RAG 的质量提上去。

第四件事:切块策略怎么选——按内容、按场景

这次踩坑,逼我把"切块策略"系统地梳理了一遍——它不是只有一种,而要按内容类型和问答场景来选:

切块策略: 没有银弹, 按内容和场景选

# 几种常见的切块策略:
# 1. 固定长度切(按字符/token 数): 简单, 但易切断语义(本文的坑)。
#    → 仅适合"无结构的纯文本", 且一定要配"重叠 + 尽量在边界断"。
# 2. 按结构切(段落/章节/标题): 尊重文档天然结构, 语义完整。
#    → 适合 Markdown/HTML/有标题层级的文档(最常用、最推荐)。
# 3. 按句子切: 粒度细, 语义边界清晰。
#    → 适合需要精细匹配的问答; 但要注意别太碎(可几句合成一块)。
# 4. 递归切(Recursive): 先按大边界切, 太大再按小边界切, 兼顾结构和大小。
#    → 通用、效果好(LangChain 等的默认推荐)。
# 5. 语义切(Semantic): 用模型判断"语义在哪转折"来切, 最贴合语义。
#    → 效果好但成本高(要调模型), 高要求场景用。
# 6. 按内容类型专门切: 代码按函数、表格保结构、对话按轮次。

# 关键参数(都要根据实际调):
#   - chunk_size(块大小): 太大稀释、太小碎。几百字常见, 看场景。
#   - overlap(重叠): 通常块大小的 10%-20%, 缓冲边界。
#   - 是否带上下文(标题/章节): 多数场景建议带。

# 怎么定? 没有放之四海皆准的值, 要"实验 + 评估":
#   - 准备一批"问题 → 期望答案/期望命中块"的测试集。
#   - 试不同的切块策略/参数, 看哪种检索召回最准、答得最好。
#   - 用指标(召回率、答案质量)说话, 别凭感觉。

# 核心: 切块没有银弹, 按"内容类型 + 问答场景"选策略和参数;
#   并用测试集去实验、评估, 调出最适合你数据的那一套。

这一梳理,让我明白,切块不是只有一种做法,而要按内容和场景来选。几种常见的切块策略:固定长度切(简单,但易切断语义——本文的坑,仅适合无结构纯文本,且必须配重叠+尽量在边界断)、按结构切(段落/章节/标题,尊重文档天然结构、语义完整,适合 Markdown/HTML——最常用、最推荐)、按句子切(粒度细、边界清晰,适合精细匹配,但别太碎)、递归切(先按大边界、太大再按小边界,兼顾结构和大小——通用、效果好)、语义切(用模型判断语义转折点来切,最贴合语义但成本高)、按内容类型专门切(代码按函数、表格保结构、对话按轮次)。而几个关键参数都要根据实际调:chunk_size(块大小,太大稀释、太小碎,几百字常见)、overlap(重叠,通常块大小的 10%-20%)、是否带上下文(标题/章节,多数场景建议带)。那怎么定这些?没有放之四海皆准的值,要靠"实验 + 评估":准备一批"问题 → 期望答案/期望命中块"的测试集,试不同的策略和参数,看哪种检索召回最准、答得最好,用指标(召回率、答案质量)说话,别凭感觉。归根结底:切块没有银弹,要按"内容类型 + 问答场景"来选策略和参数;并用测试集去实验、评估,调出最适合你自己数据的那一套。我那次的错,就是用了一个"一刀切"的、最差的固定长度策略,还没做任何评估。把几种切块策略的适用场景,整理成一张表:

第五件事:别只盯着"看得见"的环节,上游的"原材料"更关键

这次踩坑,在认知层面给了我最大的纠偏——它让我学会,排查问题要往"上游"看。我把这层反思,沉淀了下来:

认知纠偏: 别只盯"看得见的环节", 上游的"原材料质量"常被忽略

# 我的误解(错误的):
#   RAG 效果差, 我第一时间盯着"检索"和"模型"(看得见、听起来高级的环节),
#   拼命调它们; 却忽略了最上游、最朴素的"切块"——原材料的质量。
#   → 我在"下游"反复折腾, 而病根在"上游"。

# 真相: 一个系统的输出质量, 往往由"最上游的输入质量"决定
#   - garbage in, garbage out: 上游进去的是垃圾, 下游再强也是垃圾。
#   - 而上游的环节(数据清洗、切块、预处理), 往往"不起眼、易被忽略",
#     大家的注意力, 都被下游"高级、酷炫"的环节(算法、模型)吸引了。
#   - 结果: 在下游使劲优化, 收效甚微; 因为瓶颈在上游没人管的地方。

# 这是一个普遍的现象:
#   - RAG: 盯检索/模型, 忽略切块/数据质量(本文)。
#   - 机器学习: 盯模型/调参, 忽略数据质量/特征工程(其实数据更重要)。
#   - 系统性能: 盯代码优化, 忽略架构/数据结构选型(上游决定上限)。
#   → "看得见、听起来高级"的环节抢走了注意力, 朴素但关键的上游被冷落。

# 正确的习惯:
#   1. 排查问题, 顺着数据流"从上游往下游"看, 别一上来就怀疑下游。
#   2. 重视那些"不起眼、但在上游"的环节(数据/输入/预处理)的质量。
#   3. 记住 garbage in garbage out: 先保证输入质量, 再谈下游优化。

# 核心: 别只盯"看得见、高级"的下游环节; 上游"原材料的质量", 常是真瓶颈。
#   从上游往下查、先保证输入质量——这是排查和优化系统的通用智慧。

这层反思,是这次踩坑给我最高维度的收获。复盘我的误解,根源是:RAG 效果差,我第一时间就盯着"检索"和"模型"(那些看得见、听起来高级的环节),拼命去调它们;却忽略了最上游、最朴素的"切块"——也就是原材料的质量。我在"下游"反复折腾,而病根,其实在"上游"。可真相是:一个系统的输出质量,往往由"最上游的输入质量"决定——garbage in, garbage out,上游进去的是垃圾,下游再强,出来的也是垃圾;而上游的那些环节(数据清洗、切块、预处理),又往往"不起眼、易被忽略",因为大家的注意力,都被下游那些"高级、酷炫"的环节(算法、模型)给吸引走了;结果就是,在下游使劲优化、收效甚微,因为真正的瓶颈,在上游那个没人管的地方。而这,是一个极其普遍的现象:RAG 里,盯检索/模型、忽略切块/数据质量(本文);机器学习里,盯模型/调参、忽略数据质量/特征工程(其实数据往往更重要);系统性能里,盯代码优化、忽略架构/数据结构选型(上游决定了上限)——"看得见、听起来高级"的环节,抢走了所有注意力,而朴素但关键的上游,被冷落了。由此,我立下了几条习惯:第一,排查问题,顺着数据流"从上游往下游"看,别一上来就怀疑下游;第二,重视那些"不起眼、但在上游"的环节(数据/输入/预处理)的质量;第三,记住 garbage in, garbage out——先保证输入的质量,再谈下游的优化。归根结底:别只盯着"看得见、高级"的下游环节;上游"原材料的质量",常常才是真正的瓶颈。从上游往下查、先保证输入质量——这,是排查和优化任何系统的、一条通用的智慧。我那次,正是被"检索""模型"这些酷炫环节迷了眼,冷落了"切块"这个朴素却关键的上游。把"只盯下游"和"重视上游"对比成一张表:

一套"RAG 效果差该怎么排查/切块怎么做"的决策流程

把这次踩坑的全部教训,我浓缩成了一张"RAG 效果差、该从哪查;以及切块该怎么做"的决策图,贴在了团队做 RAG 的文档里:

这张图,把我"血泪换来"的整套方法论,串成了一条可执行的路径:RAG 答得差,第一步永远是看"检索回来的块"对不对、完不完整——缺头少尾/混杂就是切块的锅(改按语义/结构切+重叠+带上下文)、不相关/乱就查 embedding 一致性和数据清洗、块没问题但答得差才去查 prompt/生成。而切块该怎么做:按文档类型选策略(结构切/递归切)、大小合适+overlap+带标题上下文、用测试集评估,不够好就继续调。这条"先看块的质量、再对症修上游"的决策链,现在是我们团队排查和优化 RAG 时的准则。

我立下的几条 RAG 切块规矩

这次"切块切坏了"的踩坑,让我把 RAG 切块的注意事项,认真地立成了几条规矩:

1. 别按固定长度硬切。会切断句子/段落、切碎语义;非用不可也要配重叠、尽量在边界断。
2. 按语义/结构边界切。优先段落/章节/句子,Markdown 按标题层级,递归切兼顾结构和大小。
3. 块大小要合适。太大稀释、太小碎,几百字常见,按内容和场景调。
4. 相邻块适当重叠。10%-20% 的 overlap,给边界处一个缓冲,避免关键信息被切断。
5. 给块带上上下文。带上所属标题/章节,别让块成为无源之水。
6. 用测试集评估切块。不同策略/参数用召回率、答案质量对比,别凭感觉。
7. 排查从上游往下看。先看块的质量,别一上来就怪检索算法或模型;重视上游原材料。

写在最后

这次"我的 RAG 答非所问、我却一直错怪检索算法、最后发现是切块切坏了"的经历,是我在 AI 应用开发路上,一次很典型、也很受用的成长。它教给我的,远不止"切块要按语义"这一条具体的技术经验,更是一个排查和优化系统的根本智慧——别只盯着那些"看得见、听起来高级"的下游环节,上游"原材料的质量",常常才是真正的瓶颈。我那个答非所问的 RAG,根源就在于,我被"检索""模型"这些酷炫的环节迷了眼,在下游反复折腾,却冷落了"切块"这个朴素、却在最上游决定了一切原材料质量的关键环节——garbage in, garbage out,我用切碎了的劣质知识块,喂出了劣质的答案。

所以,当你的系统效果不好、要排查时,请别一上来,就去怀疑那个最复杂、最"高级"的环节;而要沉下心,顺着数据流,从最上游开始看:进去的"原材料"——数据、输入、被预处理过的中间产物——它们的质量,本身过关吗?就像 RAG,你只要先去看一眼"检索回来的块"长什么样,就会立刻发现,问题根本不在检索,而在那些缺头少尾、支离破碎的块上,从而把功夫,花到真正关键的"切块"上去。从"只盯酷炫的下游"到"重视朴素的上游",从"garbage in 还怪下游"到"先保证输入质量",是从一个"会搭 RAG 流程"的开发,走向一个"懂数据、能系统优化"的工程师,必经的修炼。愿你的 RAG,都建立在高质量的知识块这块坚实的地基上;也愿你我,在排查任何系统时,都记得先回到上游,看看那份最朴素、却最关键的"原材料"。共勉。

—— 别看了 · 2026