你做RAG，错在第一步

如果你以为 RAG 做不好，是因为检索算法不够强、reranker 不够聪明、embedding 模型不够先进，那你可能一开始就盯错了地方。

现在有一种新的做法，可以把语料库规模缩小 40 倍，把每次查询消耗的 token 降低 3 倍，还能让向量搜索相关性提升 2.3 倍。

更关键的是，它不改你的检索算法，不换你的 reranker，也不碰你的 embedding 模型。

它只修了一个几乎没人认真检查的上游问题。

几乎所有 RAG 流水线，都默认了一件事：一段文本 chunk，就是最适合被 embedding 的知识单元。

但这个假设，很少被真正质疑。

而大量检索失败，恰恰就从这里开始。

为什么 chunk 本身就不靠谱？

所谓 chunk，本质上只是一个结构中立的文本容器。它并不知道：

一条观点从哪里开始，又在哪里结束； 它来自文档的哪个版本； 谁有权限看到它。

因为 chunk 没有“观点边界”，所以切分器只能按 token 数往下切。字数到了，就一刀下去。

于是，你可能检索到半张表格，或者只有结论、没有论证的段落，又或者是一句脱离上下文后完全变味的判断。问题在于，模型根本不知道自己缺了什么。

版本问题同样麻烦。

在大多数企业语料库里，同一份文档经常以十几个高度相似的版本，散落在 SharePoint、Confluence 和 Git 里。

Top-K 检索一跑，返回的可能是五段几乎一样的内容：有当前版本，也有废弃版本。LLM 再把它们混在一起，最后生成一个看似笃定、实际错误的答案。

更麻烦的是，chunk 本身也不携带足够清晰的治理信息。

角色过滤、版本状态、保密级别，这些本该和内容绑定的东西，最后往往变成了挂在 orchestrator 上的一堆额外逻辑。内容在一边，权限在另一边，两者并没有真正长在一起。

LangChain、LlamaIndex、Haystack 这些工具，其实都位于这一层之上。它们负责调度检索流程，但你放进向量库的是什么，它们并不会替你从根上解决。

多数技术栈在文档解析器和向量数据库之间，几乎是空的。

而这个空白，正是三类问题不断叠加、不断放大的地方。

更好的知识单元：问答包

chunk 失败，是因为它对结构没有感知。

真正的解决办法，是把知识单元变成结构明确的对象。

也就是说，不再 embedding 一段随意截取的正文窗口，而是 embedding 一个明确的 claim：一个问题、一个经过验证的答案，以及一组类型化的治理字段。

一个单元，只承载一个事实。

你的用户查询，本来就是问题。既然如此，当索引里存放的也是“问题对应的答案”，匹配就不再只是语义上的碰运气，而变成了结构上的对齐。

你不再祈祷“正确段落刚好浮到最前面”，而是在把一个问题直接匹配到它对应的答案。

Iternal Technologies 的预处理层 Blockify，就是按照这个思路实现的。它把这种结构称为 IdeaBlock：一个问题、一个经过验证的答案，再加上保密级别、版本状态、来源等类型化治理字段，并且这些信息都挂在同一个对象上。

这正好贴合了用户使用 RAG 系统的真实方式：他们不是输入一段文档，他们是在提问。

关键洞察在于：当你 embedding 的是一个问答包，而不是一段文本窗口时，向量所代表的就是一个原子级事实，而不是“刚好包含这个事实的一段叙述”。

这会直接影响向量空间里的几何分布。

在 Blockify 针对 17 份文档、298 页内容做的内部 benchmark 中，query 到最佳匹配 block 的平均 cosine distance，IdeaBlock 是 0.1585，而朴素 chunk 是 0.3624。

这意味着，检索距离降低了 2.29 倍。

最反直觉的是：数据更少，效果更好

很多人会本能地以为，语料库缩小以后，检索效果一定会变差。

但语义蒸馏带来的结果，恰好相反。

在 Blockify 的内部 benchmark 中，原始文档一开始生成了 2,042 个 raw IdeaBlocks。

经过 3 到 5 轮、相似度阈值为 80% 到 85% 的迭代去重之后：

2,042 个 block 被压缩成 1,200 个 canonical IdeaBlocks； 总词数从 88,877 降到 44,537； 蒸馏后的数据集，在向量准确率上反而比未蒸馏版本高出 13.55%。

原因并不复杂。重复内容不是增强信号，很多时候反而是在制造噪音。

同一段话如果有十五个近似副本，就会在 embedding 空间的同一片区域里制造十五个互相竞争的向量。检索时，概率质量被这些副本分散，真正应该命中的 canonical version，分数反而被拉低。

把它们合并成一个规范 block，信号才会变锋利。

你的向量索引不是硬盘，不是越塞越好。它是一张检索表面，而冗余会磨钝这张表面。

整条流水线：从文档到 IdeaBlocks

真正的修复，发生在内容进入向量数据库之前。

也就是说，需要在 parser 和 vector store 之间，增加一条预处理流水线。

Blockify 的处理过程分为七个阶段。每个阶段都有明确的输入和输出，因此一旦出错，问题可以被定位，也可以被复现。

Stage 1：范围定义

在任何文档被解析之前，先定义索引层级：Organization > Business Unit > Product > Persona。

这一步决定了后续 block 会被打到哪个访问层级上，也会影响之后的去重方式。

Stage 2：内容摄取

文档可以是 DOCX、PDF、PPT、PNG/JPG、Markdown 或 HTML。

解析器会把内容交给 LLM 层处理。这里可以运行 fine-tuned LLaMA 3、QWEN 3.5、Gemma4，以及其他定制 foundation model 变体，将原始 chunk 转成 draft IdeaBlocks：一个关键问题、一个两到三句话的验证答案，以及类型化治理字段。

输入大小通常限制在 1,000 到 4,000 个字符之间，实际使用中，2,000 字符左右是比较合适的中间值。

Stage 3：切分与抽取

这里的切分不是简单按 token 数硬切，而是 context-aware splitting。

LLM 会把 chunk 转成 draft IdeaBlocks。也就是说，每个输出单元是一个问答对，而不是一块没有边界的文本窗口。

Stage 4：语义去重

这一阶段，是清理检索表面的关键。

系统会按照 80% 到 85% 的 cosine similarity 阈值，把 block 聚类，并进行 3 到 5 轮迭代处理。

近重复内容会通过第二个专门调优过的 LLM 合并为单个 canonical block。整条流水线针对 GPU 做了优化，不过也可以通过 Intel Xeon 优化版本，使用额外 CPU 资源运行。

最终得到的数据集里，每一个向量都代表一个不同的 claim，而不是十五个近似副本里的一份拷贝。

Stage 5：自动打标签

每个 block 都会获得类型化 metadata，包括 clearance level（PUBLIC、INTERNAL、CONFIDENTIAL、SECRET）、version state（Current、Deprecated、Draft、Approved）、product line、export control flags，以及 data privacy labels。

这些标签由流水线自动应用，而不是依赖文档作者手动维护。

Stage 6：人工验证

一个产品语料库如果有 2,000 到 3,000 个 IdeaBlocks，可以分配给 5 到 10 位 SME。每个人每个季度只需要花 1 到 2 小时处理自己负责的部分。

他们验证的不是一整份原始文档，而是带有 source citation 的结构化 claim。

这件事的工作量，会小很多，也更容易保证质量。

Stage 7：导出

经过验证的 block 可以通过 API 推送到向量数据库，也可以导出为 JSON-L。

支持的向量存储包括 Azure AI Search、Pinecone、Milvus、Vertex Matching Engine。支持的 embedding 模型包括 OpenAI、Bedrock、Mistral、Jina，以及开源模型。

重点在于，无论你使用哪种 parser、哪种 vector store、哪种 embedding 模型，这条流水线都坐在文档解析和向量化之间。

它不抢检索层的工作。

它只是让进入检索层的数据，先变得更值得信任。

应用层会发生什么变化？

你 embedding 的知识单元，决定了应用层能做什么。

首先，query construction 会变简单。

用户的问题本来就是 question。当索引里存的是问题的答案时，匹配关系就从“概率相似”变成了“结构对齐”。你不再需要不停调 similarity threshold，去弥补 query shape 和 document shape 之间天然不一致的问题。

其次，治理会下沉到数据层。

基于角色的访问控制、版本状态、保密级别，不再是外挂在 orchestrator 上的一堆判断，而是每个 block 自带的类型字段。

一个 sales engineer 和一个 legal reviewer 查询同一个索引时，拿到的数据集不同，不是因为检索层临时过滤了一下，而是因为 block 本身就带着访问边界。

再次，更新会从单条记录开始传播。

当某个 spec 发生变化时，你只需要更新一个 IdeaBlock。所有查询这个 block 的应用，在下一次请求时都会拿到修正后的答案。

而在朴素 chunking 里，同一个事实可能藏在几十段近重复 passage 中，散落在多份文档里。要更新它，就意味着你必须先找到所有副本。

在企业规模下，这件事几乎不可操作。

所以，这种架构并不会改变你如何发起查询。

它真正改变的是：你能对返回答案信任到什么程度。

底层原则：错的不是检索，是知识单元

chunk 原本只是一个解析便利，后来却被默认成了检索假设。

可它没有观点边界，没有版本上下文，也没有访问状态。

于是过去几年里，RAG 技术栈一直在为这个错位打补丁：reranker、hybrid search、threshold tuning、prompt engineering。

这些方法当然有价值。

但它们全都在下游。

真正的问题，早就发生在数据进入向量库之前。

所以，解决方案不是一个更强的检索算法，而是一个更好的知识单元。

地址：

https://github.com/iternal-technologies-partners/blockify-agentic-data-optimization

最后：

精通 React 面试：从零到中高级(针对面试回答)

CSS终极指南

Vue 设计模式实战指南

20个前端开发者必备的响应式布局

深入React:从基础到最佳实践完整攻略

python 技巧精讲

React Hook 深入浅出

CSS技巧与案例详解

vue2与vue3技巧合集