Appearance
Skill 可以教 AI 怎么做，却不一定能让 AI 知道为什么这么做。如果你想真正蒸馏某个人的知识，今天的主角 RAG 才是关键。
很多人对 Skills 有误解，以为它能很好完成知识库的功能。Skill 解决的是流程复制，RAG 解决的是知识调用。
Skill 告诉模型第一步做什么、第二步做什么；RAG 告诉模型做这件事时，需要参考哪些资料、哪些历史经验。
这两者一组合，才真的有点蒸馏那个意思了。
为什么知识库效果总是不尽人意
很多团队知识库效果不好，第一反应是换模型、调 Top K、调 Score 阈值、换向量数据库。但真实情况大概率是：文档从一开始就没处理好。
知识库效果的上限，往往不是由模型决定的，而是由入库质量决定的。
今天我们拿最常见的 Dify 知识库来拆解，这套链路适用于任何 RAG 框架，写代码也行。
RAG 完整链路
这套链路大致分为两个阶段：
| 阶段 | 核心动作 |
|---|---|
| 离线阶段 | 文档解析 → 数据清洗 → 文档分块 → 向量化 → 建索引 |
| 在线阶段 | 用户提问 → 查询改写 → 召回 → 重排 → Top K过滤 → 拼接上下文 → 生成回答 |
离线阶段：数据入库
第一步：文档解析
PDF 不像 Markdown 那样天然结构化，一份 PDF 里可能混着正文、表格、页眉页脚、水印、扫描图片...
如果是扫描件生成的 PDF，系统需要先 OCR，这个过程天然容易出错：
- "0" 被识别成 "O"
- "SKU-20240315" 被识别错
- 表格里的列关系丢失
- 两栏排版被解析成错乱顺序
核心判断：这跟大模型无关，而是拿到的原始文本从一开始就不干净。
适合知识库的文档格式优先级：
| 文档类型 | 适合程度 | 原因 |
|---|---|---|
| Markdown | 很高 | 结构清晰，标题、段落、列表天然可解析 |
| 纯文本 | 很高 | 解析稳定，但结构信息较少 |
| Word | 较高 | 如果格式规范，解析效果不错 |
| 中等 | 取决于是否有文本层，扫描件风险很高 | |
| Excel | 较低 | 表格语义容易丢失 |
| 图片/扫描件 | 很低 | 依赖 OCR，错误率较高 |
第二步：数据清洗
很多人在上传 PDF 的时候，每一页都有页眉、页脚、正文中还有网址、邮箱、版权声明、水印文案...
如果不清理掉，后面分块时就会被切进知识片段里，污染检索结果。
系统自带的清洗能力是有限的，业务噪音需要在上跽前处理，比如：
- 过期条款
- 重复政策
- 错误版本
- 内部讨论备注
- 不适合对外暴露的信息
核心原则：数据处理越细致，后面效果越好。
第三步：文档分块
分块的本质是：定义知识检索的最小返回单位。
如果不分块，检索的最小单位就是整篇文档，用户问一个很小的问题，系统可能把整份几十页的文档都塞给模型，导致：
- 上下文太长
- 无关信息太多
- 成本太高
- 响应变慢
- 关键信息反而被淹没
但分块有个经典两难：太大，不精准；太小，不完整。
好的分块要满足：
- 语义完整：每个块能独立表达一个完整意思
- 长度合适：不能超过 Embedding 模型的输入限制
- 粒度适中：既不能太粗，也不能太碎
- 上下文连贯：边界处的信息不能被切断
- 检索友好：用户问一个问题时，相关块能被稳定召回
常见分块策略
1. 固定长度分块
每 N 个 token 切一块。优点是实现简单、速度快；缺点是不理解语义，可能把一句话切断、把表格切烂。
2. 语义边界分块
按自然语言边界切：按段落、按句号、按换行、按标题。这种方式比固定长度更合理，尽量在自然边界上切。
3. 递归分块
先尝试按大边界切，如果太长再按句子切，再按空格切，最后按字符切。尽量保留语义边界，不得已再降级。
4. 结构感知分块
如果文档结构明确（Markdown、HTML、技术文档），可以按结构分块：
- 一级标题/二级标题
- 代码块/表格
- FAQ 问答对
FAQ 文档最理想的分块方式是按一个完整 Q&A 切，而不是按 500 token 切。
5. 智能语义分块
用模型判断语义边界：通过 Embedding 计算相邻句子的语义相似度，当语义突然变化时说明话题发生切换，可以在这里切分。
这种方式效果可能更好，但成本更高、更复杂。一般适合高价值知识库、文档复杂、对准确率要求很高的场景。
Dify 三个核心参数
分段标识符
分段标识符决定在哪里切。默认是双换行符，也就是按段落边界切。
如果你的文档有自己的分隔标记，也可以自定义：
- FAQ 文档用 "Q：" 作为边界
- Markdown 按标题切
- 政策文档按"第 X 条"切
- 客服话术按"场景："切
分段最大长度
块太大，上下文越完整但检索越不精准；块太小，检索越精准但信息可能不完整。
经验参考：
| 文档类型 | 建议块大小 |
|---|---|
| FAQ | 200-500 tokens |
| 客服话术 | 300-700 tokens |
| 产品说明 | 500-1000 tokens |
| 技术文档 | 500-1200 tokens |
| 法务/制度文档 | 600-1200 tokens |
分段重叠长度
分段重叠是为了解决关键信息刚好被切断的问题。相邻两个片段之间共享一部分内容。
Dify 默认重叠 50 token，官方建议一般设为最大长度的 10%-25%。但也不能重叠太多，否则存储变多、检索结果重复、最终回答可能变啰嗦。
父子分块
这是 Dify 提供的一个特别能力，解决了 RAG 里一个核心矛盾：检索需要小块，生成需要大块。
父子分块的思路：
- 入库时同时切成大块和小块
- 检索时用小块匹配
- 命中后返回对应的大块给模型
用小块提高召回精度，用大块保证回答完整性。
这非常适合长文档、制度文档、产品手册。如果你的企业知识库文档比较长、规则之间有关联，很建议优先关注父子分块。
索引模式
高质量模式：向量化
系统调用 Embedding 模型，把每个知识片段转换成向量。语义相近的文本，向量距离也更近。
重要原则：文档和查询必须使用同一个 Embedding 模型。
如果文档用模型 A 向量化，查询用模型 B 向量化，那就像两套坐标系，检索结果会非常不稳定。
经济模式：关键词索引
不做向量化，用分词器提取关键词建立索引。优点是成本低、入库快；缺点是只能做字面匹配，不理解语义。
重要判断：索引模式是源头决策，后面调 Top K、调 Score 阈值是补不回来的。
在线阶段：检索生成
当用户问「SKU-20260315 这款商品超过 7 天还能退吗？」，RAG 系统会进入这条链路：
用户提问 → 查询改写 → 召回 → 重排 → TopK过滤 → 拼接上下文 → 大模型生成回答查询改写
用户的问题往往不是标准检索语句。比如用户问「这个东西过了 7 天还能不要了吗」，人理解他大概率是在问退货，但知识库里可能写的是「商品签收后 7 天内支持无理由退货」。
核心原则：所有改写都应该往知识库靠，而不是替用户脑补。
召回
向量检索
把用户问题转成向量，去向量数据库里找最相近的 chunk。擅长处理语义相似，但 SKU、订单号、合同编号这类精确信息不一定敏感。
全文检索
依赖关键词匹配，对精确词非常友好。只要文档里出现了这些词，就容易找到。
混合检索
同时走这两路，然后把结果合并。在大多数企业知识库场景里，无脑选择混合检索就好。
重排
召回阶段追求的是快和全，很难做细
