RAG 总答偏，先查 chunk

如果你的 RAG 总把旧政策、半张表格、无权限文档混在一起先别急着换 embedding。很多检索事故不是发生在检索那一刻而是文档入库时已经埋好parser 后面直接接 fixed chunker版本、权限、来源都没贴在知识单元上。你拿半截事实去检索后面再加 reranker也是在给半截事实排座次。Akshay Pachaar 在一篇 X Article 里介绍了 Blockify 的做法先把文档蒸馏成 IdeaBlock再送进向量库。一个 IdeaBlock 不是随手切出来的一段文本而是一个问题、一个可信答案再加上版本、权限、来源、标签这些治理字段。我会把它理解成一句工程判断RAG 的输入单位不该只是“文本窗口”而应该是“可追踪、可更新、可控权限的一条事实”。先别急着调检索传统 RAG pipeline 很熟悉Raw Docs 进 parserparser 之后接 fixed chunker然后写进 Vector DB最后交给 LLM。这个流程的问题不在每一步都错而在中间少了一层“知识整理”。原始文档里有表格、脚注、版本、审批状态、权限级别、重复段落。固定长度切分器只关心窗口够不够长不关心一个想法有没有讲完。所以后面常见的排查会变成• 换 embedding 模型• 调 Top-K• 加 hybrid search• 再上一层 reranker• 最后靠 prompt 告诉模型“请注意上下文”。这些补丁可能有用但如果底层知识单元已经碎了检索调参只能缓解不能把半张表格变回完整事实。chunk 只是切片不是知识原文把 chunk 的问题拆成三类。第一chunk 没有想法边界。切分器跑到 token 限制就停可能把一个表格切成两半也可能只留下结论把支撑结论的前文扔到另一个 chunk。第二chunk 没有版本状态。企业资料里经常同时存在 v2、final_final、draft、approved_v3、deprecated。Top-K 一旦把几个近似段落一起捞上来LLM 很容易把旧政策和新政策混成一个看起来很自信的答案。第三chunk 本身不带权限。销售、法务、工程师查的是同一套知识库但能看的内容不同。如果权限只写在 orchestrator 的过滤逻辑里内容和治理规则就分家了。以后谁改了文档、谁改了权限、哪个版本可见都得靠外层系统继续兜。这类问题不是“语义相似度还不够聪明”。更像是知识库刚入库时就没有给知识一个清楚的地址。IdeaBlock一条事实一张身份证Blockify 提出的 IdeaBlock目标是把“窗口里的文字”改成“结构化的事实单元”。一个 IdeaBlock 至少包含•name这条知识叫什么•critical_question用户可能怎么问•trusted_answer经过验证的两三句话答案•tags / entity / keywords方便检索和归类•metadata来源、owner、版本、权限、状态。这样做的好处很直接用户问题本来就是问题索引里也存“问题 答案”匹配关系就不再只靠一段长文本里碰巧出现了相似词。它也给治理留了位置。版本、权限、来源不是外挂备注而是跟这条事实绑在一起。以后 spec 改了你更新一个 IdeaBlock下游应用下一次查到的就是新答案。用普通 chunk 时同一个事实可能散在几十个近重复段落里改一次像翻旧文件柜。数据少一点检索可能更稳原文引用了 Blockify 的内部 benchmark数字挺有意思但要按“项目方数据”理解。在 17 份文档、298 页材料上原文说 IdeaBlock 到最佳匹配 query 的平均 cosine distance 是 0.1585naive chunk 是 0.3624。按作者的说法这是 2.29x 的检索距离改善。另一个实验里2,042 个原始 IdeaBlock 经过 80% 到 85% 相似度阈值、3 到 5 轮去重后合并成 1,200 个 canonical IdeaBlock。词数从 88,877 降到 44,537蒸馏后的数据在 vector accuracy 上高出 13.55%。直觉上资料越多越安全。但向量库不是网盘。十五个近似段落挤在同一片 embedding 空间里反而会把概率质量摊薄检索结果在一堆重复项之间摇摆。把近重复事实合成一条 canonical block信号会干净很多。工程上怎么加这一层Blockify 的流程可以拆成七步先定义索引层级比如 Organization、Business Unit、Product、Persona。接入文档来源可以是 SharePoint、Confluence、Git、PDF、Markdown、图片等。按语义边界切分再让 LLM 抽出 draft IdeaBlock。用 embedding 和聚类找近重复原文提到 80% 到 85% 的相似度阈值。反复蒸馏把近重复内容合并成 canonical block。自动打标签把版本、权限、数据隐私、产品线这些字段补上。经过人工校验后导出到向量库或 JSON-L。GitHub README 里还提到开源仓库包含一个 FastAPI distillation service 和一个 Claude Code skill。支持的存储、部署和集成不少包括 Docker、Helm、SQLite、PostgreSQL、Redis、ChromaDB、Pinecone、Cloudflare Vectorize、Neo4j 等。我的看法是别先被这些集成列表带跑。更值得拿走的是中间那层在 parser 和 vector store 之间先做抽取、去重、归并、打标签。应用层少背三口锅把版本、权限、来源贴进 block 之后应用层少背三口锅。第一query construction 会简单一些。用户问问题索引里也有对应问题和答案不必一直靠阈值、重写 query、rerank 去弥补“问题”和“散文窗口”之间的形状差异。第二权限会靠近数据层。角色、版本、clearance level 直接贴在 block 上同一个索引给销售和法务返回不同数据不再完全依赖外层流程记得过滤。第三更新路径会变短。规格变了改一条 canonical IdeaBlock普通 chunk 则要先找到所有重复段落再判断哪个新、哪个旧、哪个还能被引用。这不是说 reranker、hybrid search、prompt engineering 都没价值。它们仍然是工具。只是当知识库里全是半截事实和重复版本时应用层越补越厚系统越难解释。收藏这张 RAG 排障清单如果你已经有一套 RAG不用马上换架构。先拿下面这张清单查一遍。自检问题命中后的处理Top-K 里经常出现同一段话的多个版本先做近重复聚类和 canonical 合并chunk 会切断表格、流程、结论和论据改成按语义边界抽取知识单元权限、版本、来源只在外层代码里把治理字段写回知识单元旧资料经常混进新答案给 block 加 version state 和审批状态更新一个事实要改很多文件建立一条事实一个记录的映射如果命中三条以上我会先看数据蒸馏层而不是继续微调 Top-K。反过来如果你的知识库很小、文档版本很少、权限也简单IdeaBlock 这套做法可能偏重。小团队先用更好的 parser、更严格的 chunk overlap、简单去重也能解决一批问题。RAG 的成熟方向大概率会像 Web stack 当年长出 CDN 一样在 source 和 consumer 之间长出一层优化层。Web 不会让每个请求都直打源站RAG 也不该让每个问题都面对一堆未经整理的原始 chunk。下次 RAG 又答偏把这张清单翻出来。先查向量库里存的是不是“知识”再决定要不要换模型、加 reranker、重写 prompt。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】