跳转至

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

Ch01.453 RAG深度解析：分块、向量化、召回、重排，才是"蒸馏同事skill"的关键

📊 Level ⭐⭐ | 7.8KB | entities/rag深度解析分块向量化召回重排才是蒸馏同事skill的关键.md

核心要点

微信文章：RAG深度解析：分块、向量化、召回、重排，才是"蒸馏同事skill"的关键 → 原文存档

深度分析

这篇文章的核心贡献是把"同事.skill"热潮拉回工程现实：skill 复制动作，RAG 补足认知，二者合一才接近真正的"蒸馏同事"。一个 top sales 的能力由三层构成——Workflow 层（他知道第一步做什么第二步做什么）、Knowledge 层（他知道做这件事要参考哪些资料）、Judgement 层（在复杂情况下如何权衡）。Skill 负责第一层，RAG 负责第二层，第三层取决于模型能力和人类兜底机制。绝大多数"同事.skill"项目只做了第一层，然后误以为完成了全部蒸馏。 RAG 的工程链路分为离线阶段（文档解析→清洗→分块→向量化→建索引）和在线阶段（用户提问→查询改写→召回→重排→TopK 过滤→拼接上下文→大模型生成）。作者的核心判断——"知识库效果的上限往往不是由模型决定的，而是由入库质量决定的"——是整篇文章最有工程价值的观点。团队 RAG 效果不好时，第一反应是换模型调参数，但真实情况大概率是文档从一开始就处理得不够干净。 分块是 RAG 工程中最经验性的环节，也是最容易被低估的环节。作者揭示了一个经典两难：太大则语义模糊（一个 chunk 同时表示退货规则、换货规则、运费规则，向量到底代表什么），太小则语义断裂（"超过 7 天后"单独成块没有意义）。这个两难没有通用解，只能通过持续测试来逼近最优。具体场景的最优 chunk 大小取决于用户问题的分布——FAQ 类问题通常需要 200-500 tokens，客服话术 300-700 tokens，技术文档 500-1200 tokens，但这些都是经验值，不是真理。 清洗环节揭示了一个常被忽视的工程现实：系统自带的清洗能力只能处理通用噪音（如连续空格、多余换行符、URL、邮箱），无法处理业务噪音（如过期条款、重复政策、错误版本、内部备注）。这些业务噪音必须在上传前由人工处理，否则"垃圾进，垃圾出"——向量数据库会把垃圾更快更准地找出来。作者估算 RAG 项目"80% 的时间在搞数据"，这个比例在严肃企业场景下并不过分。 在线阶段的检索参数（TopK 取 3/5/10、Score 阈值设 0.5/0.7、Rerank 模型开不开）都依赖于离线阶段的数据质量。在离线阶段数据没搞好之前，调在线参数是本末倒置。

实践启示

  1. 先清洗再上传，不要依赖系统的自动清洗能力。数据处理的细致程度直接决定知识库的上限。上传前应该人工审查一遍：去掉过期内容、合并重复政策、删除内部讨论备注、处理表格转文本后的结构错乱。这个工作量在初期看似繁琐，但会成倍减少后续调参的试错成本。
  2. Chunk 大小没有银弹，但有起始参考值。从 FAQ 的 200-500 tokens 开始，用真实用户问题集做召回测试，逐步调优。不要在离线阶段一次性把 chunk 大小定死——要与在线召回效果形成反馈循环。如果发现某个问题总是召回不完整答案，往往是 chunk 太小导致上下文被切断；反之，如果召回的内容经常包含无关信息，chunk 可能太大。
  3. 文档格式的选择优先级是：Markdown > 纯文本 > Word > PDF > Excel > PPT > 扫描件。扫描件和图片依赖 OCR，错误率高，是知识库效果的最短板。在企业内部推动知识管理时，应该优先推动团队以 Markdown 格式沉淀文档，而不是把 PDF 当作最终交付物。
  4. 检索质量评估要先于参数调优。建立一套"问题-期望召回块"的 ground truth 测试集，覆盖主要业务场景。定期跑召回率（recall）和精确率（precision），用量化指标而非主观感受来评估知识库健康度。
  5. Skill + RAG 是真正的"AI 同事"最小完整集。只部署 Skill 而不接 RAG，AI 同事知道怎么做但不知道参考资料在哪里；只部署 RAG 而不接 Skill，AI 同事知道资料在哪但不知道按什么顺序使用。两者合一，配合 Judgement 层（模型能力+业务边界+人类兜底），才构成一个可以独立工作的 AI 同事的数字分身。

相关实体