Akshay 发了一条关于 RAG 的长 thread，核心判断很直接：所有人都在优化检索算法，但 RAG 的真正问题在更上游——文本分块这个假设本身就是 bug。
文本分块的三个致命缺陷
没有 idea 边界
分块器按 token 数切割，切到哪儿算哪儿。结果你检索到半张表、一个没论据的结论、一个被剥离上下文的断言。模型根本不知道缺了什么。
版本灾难
企业知识库里有同一个文档的十几个近似版本，散落在 SharePoint、Confluence、Git 里。Top-K 返回五个相同段落的副本，当前版和废弃版混在一起。LLM 把它们融成一个自信的错误答案。
权限与内容脱节
分块本身不带元数据，角色过滤、版本状态、 clearance level 全部变成 orchestrator 上的外挂逻辑，和要治理的内容完全脱节。
解决方案：IdeaBlock
不是嵌入一段文字窗口，而是嵌入一个声明：一个问题、一个验证过的答案、以及治理字段作为类型化 schema。
一个事实一个单元，不多不少。
你的查询已经是问题。当索引里存的是答案时，匹配就变成了结构性的，而不只是语义性的——你不是在赌正确的段落浮到顶部，你是在直接把问题匹配到答案。
数据：效果很显著
Blockify 的内部基准测试（17 个文档，298 页）：
- 检索距离：IdeaBlock 平均 cosine distance 0.1585，naive chunks 0.3624——2.29 倍提升
- corpus 压缩：2,042 个 raw IdeaBlocks 经 3-5 轮 80-85% 相似度去重后，collapse 到 1,200 个 canonical blocks
- 字数：88,877 → 44,537（约 50% 缩减）
- 准确率：蒸馏后的数据集比未蒸馏的高 13.55%
为什么冗余副本不是帮助而是伤害：十五个近似副本在嵌入空间的同一区域创造了十五个竞争向量。检索把概率质量分散到所有副本上，拉低了 canonical 版本的匹配分数。 collapse 成一个 canonical block，信号就锐化了。
七阶段处理管道
Blockify 的处理在向量存储之前运行七个阶段：
- 定义索引层级：Organization > Business Unit > Product > Persona——决定哪些 block 标记到哪个访问层级
- 文档解析：DOCX、PDF、PPT、图片、Markdown、HTML
- LLM 转换：fine-tuned LLaMA 3/QWEN 3.5/Gemma4 把 raw chunks 转成 draft IdeaBlocks——一个关键问题、一个 2-3 句的验证答案、类型化治理字段
- 上下文感知分块：LLM 把 chunks 转成 draft IdeaBlocks，而不是只按 token 数切割
- 去重聚类：cosine similarity 80-85% 阈值，3-5 轮迭代，近 duplicates 合并成 single canonical block
- 元数据标注：clearance level（PUBLIC/INTERNAL/CONFIDENTIAL/SECRET）、version state（Current/Deprecated/Draft/Approved）、产品线、出口控制标志、数据隐私标签——由管道应用，不是文档作者
- 推送向量库：Azure AI Search、Pinecone、Milvus、Vertex Matching Engine 等
三个架构级影响
查询构造变简单
你的查询已经是问题。索引里存的是答案。匹配是结构性的而不是概率性的。你不再为了补偿查询形状和文档形状之间的语义错配而调 similarity 阈值。
治理进入数据层
角色访问、版本状态、clearance level 是每个 block 上的类型化字段，不是 orchestrator 上的外挂逻辑。销售工程师和法务 reviewer 查询同一个索引得到不同数据集，不是因为检索层过滤了，而是因为 block 本身携带了访问边界。
更新从单条记录传播
当 spec 变了，你更新一个 IdeaBlock。每个查询这个 block 的应用下次请求就得到修正后的答案。用 naive chunking，同一个事实活在几十个近似 passage 里，分散在多个文档中。更新它意味着找到所有副本，这在企业规模上不可行。
关键判断
"The chunk is a parsing convenience that became a retrieval assumption."
分块是一个解析便利，后来变成了检索假设。它本身没有 idea 边界、版本上下文或访问状态。检索栈花了多年修补这个错配：rerankers、hybrid search、阈值调优、prompt engineering。
所有这些都在真正问题的下游。
修复不是更好的检索算法，而是更好的单元。
RAG 栈正在像 web 栈在 origin 和浏览器之间长出 CDN 层那样，在解析和向量化之间长出一个蒸馏层。
你可以自己用聚类、LLM-based summarization 和 schema enforcement 构建它。也可以用 Blockify 这种 purpose-built 的工具。无论如何，chunk-as-unit 假设是 bug，在数据层修复它比调检索算法回报更大。