RAG 深度解析：分块向量化召回重排才是蒸馏同事 Skill 的关键¶

Ch01.327 RAG 深度解析：分块向量化召回重排才是蒸馏同事 Skill 的关键¶

📊 Level ⭐⭐ | 11.3KB | entities/rag-chunking-vectorization-rerank-distillation.md

-> 原文存档

核心洞察¶

RAG 完整流程：分块->向量化->召回->重排；知识蒸馏同事 Skill 的关键在召回质量而非生成质量。Skill 可以教 AI 怎么做，却不一定能让 AI 知道为什么这么做。

摘要¶

文章深入解析 RAG 全链路各环节，批判"蒸馏同事 Skill"现象。很多所谓蒸馏，蒸馏出来的是 Workflow 而非判断力/经验。Skill 的本质是教 AI 做事流程，而非赋予 AI 做判断的能力。RAG 各环节调优顺序：分块 -> 向量化 -> 召回 -> 重排。

要点¶

Skill vs 判断力：Skill 教 AI 怎么做，但不赋予防为什么这么做的判断力
分块策略：5 种分块策略，选择影响召回质量
向量化：embedding 模型选择影响语义检索效果
召回阶段：混合检索、多路召回提升召回率
重排（Rerank）：精排阶段提升最终相关性
调优顺序：分块 > 向量化 > 召回 > 重排

深度分析¶

1. Skill 与 RAG 的分工本质¶

当前 AI 圈盛行的"同事.skill"现象，本质上混淆了两个截然不同的能力层级：流程复制与知识调用。 Skill 解决的是"怎么做"的 Workflow 问题——第一步做什么、第二步做什么。但这些写在 Skill 里的流程，本质上是人类将隐性经验显性化后的规则文档，并非真正的判断力。一个销冠的 Skill 能复制他的跟进话术，却无法复制他在不同情境下选择不同话术的判断依据。而 RAG 解决的是"基于什么做"的认知问题——做这件事需要参考哪些资料、哪些历史经验、信息从哪里来。这两者的根本差异在于：

Skill = 动作序列（How） RAG = 参考知识（What/Why Based On） 真正有价值的"AI 同事"需要三层能力叠加：Workflow 层（怎么做）+ Knowledge 层（参考什么）+ Judgement 层（复杂情况如何权衡）。Skill 覆盖第一层，RAG 覆盖第二层，第三层取决于模型本身能力。

2. 数据质量先于模型调优¶

这是 RAG 工程中最容易被忽视却最关键的认知：知识库效果的上限不是由模型决定的，而是由入库质量决定的。很多团队在知识库效果不好时，第一反应是换 Embedding 模型、调 Top K、调 Score 阈值。但真实情况大概率是文档从一开始就处理得不够细致。这个判断的深层含义是：RAG 系统存在一个"木桶效应"——最短的木板决定了整体水位。如果文档解析质量差、分块策略不合理，那么后续无论用多先进的 Embedding 模型、多精细的 Rerank 策略，都只是在用更高的算力去弥补更低的数据质量。80% 的 RAG 项目时间实际上应该花在数据处理上，而非模型调参上。

3. 分块策略的两难困境¶

分块是 RAG 链路中最"经验驱动"的环节，没有标准答案，只有不停的测试。核心矛盾在于：太大则语义模糊，太小则上下文断裂。当一个 chunk 包含退货规则、换货规则、发票规则、运费规则等多个主题时，向量化后的语义表达会变得模糊——它试图同时表示很多件事，结果哪件事都表示不精准。反之，如果切得太小，比如只保留了"超过 7 天后"，单独看没有任何意义，模型无法判断不能退还是可以换还是要人工审核。这个两难没有完美解法，只有业务场景下的最优解。FAQ 类文档适合小 chunk（200-500 tokens），技术文档适合中等 chunk（500-1200 tokens），长文档总结可以用大 chunk（800-1500 tokens）。但这些都只是经验值，真正好不好只能通过实际召回效果来验证。

4. 父子分块的工程智慧¶

Dify 提供的父子分块机制，本质上解决了一个核心矛盾：检索需要小块，生成需要大块。这个设计思想值得深入理解。小块语义更聚焦，更容易精准匹配用户问题（比如直接命中"SKU-20240315 属于定制类商品，不支持无理由退货"）；但如果只给模型这个小块，模型可能缺上下文，不知道这个规则属于哪个政策、是否有适用范围、是否有时间限制。父子分块的思路是：入库时同时切成大块和小块，检索时用小块匹配，命中后返回对应的大块给模型。这个设计非常接近知识图谱和树形结构的思路，在处理复杂场景（长文档、制度文档、产品手册）时效果显著。它本质上是将"检索精度"和"回答完整性"这两个目标解耦，分别优化，而不是在一个 chunk 里试图同时满足两者。

5. 召回与重排的职责分离¶

RAG 链路中"召回是海选，重排是复试"这个比喻非常精准。召回阶段追求的是快且不漏，重排阶段追求的是准且相关。召回阶段的算法复杂度决定了它必须简单快速——向量检索找语义相似，全文检索找精确匹配，混合检索两者兼顾。但无论哪种方式，都很难做到真正精细的相关性判断。比如用户问"Python 异步编程最佳实践"，召回可能同时命中"Python 异步编程指南"、"Python 编程最佳实践"、"JavaScript 异步编程最佳实践"三个都沾边的结果。重排阶段的 Rerank 模型则会把用户问题和每个候选 chunk 一起做深度相关性判断，这比单纯比较向量距离要细得多。但代价也很清楚：成本和效率。所以实践中，高风险场景（客服、售后、法务、医疗、金融）尽量开 Rerank，而内部知识助手可以先不开，把链路跑通再说。

6. 配置参数的链路映射¶

Dify 知识库的每一个配置项，本质上都是 RAG 链路某个环节的控制开关。理解这个映射关系，才能真正调好知识库： | 配置项 | 对应环节 | 本质作用 | |---|---|---| | 索引模式 | 向量化/建索引 | 决定用语义检索还是关键词检索 | | 分块方式 | 文档分块 | 决定知识片段颗粒度 | | 分段最大长度 | 文档分块 | 控制 chunk 大小 | | 分段重叠长度 | 文档分块 | 防止边界信息丢失 | | 检索方式 | 召回 | 决定按语义找、关键词找，还是两者都用 | | Rerank | 重排 | 决定候选片段怎么重新排序 | | Top K | 上下文过滤 | 决定最多给模型多少片段 | | Score 阈值 | 上下文过滤 | 决定低相关内容是否丢弃 | 调优的合理顺序应该是：文档质量 → 分块策略 → 索引模式 → 检索方式 → 重排 → Top K/Score 阈值 → Prompt 约束。前面环节没做好，后面再怎么调都只是修修补补。

7. 知识蒸馏的真正瓶颈¶

文章批判的"蒸馏同事 Skill"现象，揭示了一个深层问题：知识蒸馏社区长期以来过度关注生成质量（模型输出多流畅多像人），却忽视了召回质量（模型有没有基于正确的信息来生成）。真正有效的知识蒸馏，应该同时蒸馏两部分能力：一是 Workflow 能力（可通过 Skill 传递），二是判断力来源（必须通过高质量 RAG 实现）。没有 RAG 支撑的 Skill，本质上只是一个写得比较详细的 SOP 文档，能告诉 AI 流程，却无法告诉 AI 在具体情境下应该参考什么材料做出判断。

实践启示¶

数据处理是核心：不要把未经整理的资料一股脑上传到知识库。在上传前就做好文档格式处理（优先 Markdown 和结构化文本，扫描件和图片风险很高）、噪音清理（页眉页脚、水印、版权声明、过期条款、内部备注）、版本校验（制度之间是否有冲突）。
分块需要迭代验证：没有最优分块策略，只有最适合业务场景的分块策略。从递归分块或结构化分块开始，通过实际召回效果（用户问题能不能稳定召回完整答案）来迭代调整。必要时引入智能语义分块或父子分块机制。
混合检索是默认选择：在大多数企业知识库场景里，混合检索（向量+全文）是最稳妥的起步方案。用户问题通常不是纯语义也不是纯关键词，两者混在一起是常态。
Rerank 按场景开启：客服、售后、法务、医疗、金融等高风险场景尽量开 Rerank；内部知识助手等低风险场景可以先关闭，把链路跑通后再逐步开启。
Top K 不是越大越好：大模型不是看到越多资料越聪明。如果塞进去 10 个片段其中 3 个相关 7 个不相关，模型反而可能被噪音带偏。根据 chunk 大小和业务场景调整：FAQ 3-5，技术文档 5-8，多规则综合判断 5-10。
Score 阈值防止硬凑：知识库里没有依据时，不要强行回答。宁可保守——"当前知识库中没有找到足够依据，建议转人工处理"——也不要让模型硬编。
可观测性是持续改进的基础：建立数据飞轮，持续收集用户问题日志、召回命中率、回答准确率等指标。RAG 项目不是一次性工程，而是需要根据真实使用数据持续优化的数据工程。
Skill + RAG 才是完整方案：单独的 Skill 只是 Workflow 复制，单独的 RAG 只是知识检索。真正要"蒸馏同事能力"，必须让 Skill 告诉 AI 流程，RAG 告诉 AI 在这个流程中应该参考什么材料，两者配合才能形成完整的 AI 同事能力。

来源¶

→ 原文存档