构建“生产就绪”的企业级RAG应用的6大优化考量【上】｜深度探讨

关于RAG应用，圈内有一个共识：搭个原型，十分钟甚至更短就能搞定；但真要把它打造成一个足够健壮、性能卓越、能扛住企业级知识应用需求与多元数据环境的“生产就绪”系统，那难度一下子就上来了。你可能会遇到这些常见挑战：海量知识文档下的精确检索、任务形态不再只是简单的事实问答、知识形态复杂多样（不光是文件文本），还有企业工程层面的严苛要求——响应时间、准确率，一个都不能少。

本文参考了国内外一些实践和分享，把构建企业级RAG应用中的几个关键优化考量做个总结和解析，希望能对实际项目有所启发。注意，这里只讨论方案，具体实践后续再展开。

1. 选择合适的知识块大小

2. 分离用于检索的块与用于生成的块

3. 对大文档集知识库做分层检索

4. 多模态知识的输入输出处理

5. 考虑高级检索与查询重写

6. 在投入生产之前对应用作全面评估

考量一：选择合适的知识块大小

先聊一个基础参数问题——看似简单，却很容易被忽略。不管用LlamaIndex还是LangChain搭RAG，把外部知识（尤其是文件）向量化存储时，都会碰到

这个参数，它决定把原始知识拆成多大的块（chunk），而chunk又是后续检索上下文的基本单位。所以chunk_size很大程度上决定了检索和生成的质量：

• 较小的chunk_size
  会产生更小粒度、更多的知识块。好处是语义更精准，但风险是上下文信息太少，重要信息可能压根儿不在检索出来的顶部块里（尤其top_K设得比较小的时候）。

• 较大的chunk_size
  有利于承载更完整的上下文，但语义检索的精度会下降，还可能带来性能问题、窗口溢出、tokens成本飙升。

• 合适的块大小
  还得看任务类型：事实性问答只需要少量特定知识块；而摘要、总结、对比这类任务，可能需要更大的块甚至全部知识块。

所以，确定最佳chunk_size本质上是找平衡——在不牺牲性能的前提下，尽可能捕获最重要的信息。企业级场景下，最靠谱的做法是

，评估指标包括响应与检索上下文的相关性、响应的有用性、正确率等。具体实现可以用独立的评估框架，或者LlamaIndex里的模块，批量跑出不同chunk_size的结果，然后选出最优解。

一个批量评估的过程输出

考量二：分离用于检索的块与用于生成的块

你可能想着，选一个最佳chunk_size就能一劳永逸，既保证检索精准又保证语义丰富。但企业数据环境的复杂性往往让这种“一刀切”策略失效。比如：

• 一个原始知识块里包含了生成需要的详细信息，但也混着一些让向量产生偏差的关键词，导致它没法被精确检索到。
• 在问答型应用里，用户提问方式可能很简单，适合少量块精准检索；但生成答案时却需要更多上下文才能形成完整回答。

因此，常见的优化思路是：

——输入给LLM的知识块，不一定非得是直接检索出来的top-k块。

经典RAG应用中，检索和生成过程对知识块的传递大致是这样的（此处省略示意图描述）。那么，有哪些策略可以实现这种分离呢？

1. 从问题扩充到完整的问答对

如果原始知识是大量结构化的问答对，那么很适合只对问题做向量嵌入。精确检索到问题后，再把关联的答案内容一起喂给LLM做生成。另外，这里还有常见的检索前处理：

• 利用LLM生成更多

  相似问法
  做嵌入，提高召回能力。
• 利用LLM生成

  假设性问题
  做嵌入，模拟问答对。

2. 动态扩充知识块的上下文窗口

对于常见的连续文档型知识，在检索到相关知识块后，

。比如设置窗口大小为3，检索到这个块后，通过块的关系信息或元数据，获得上下各3个关联块，一起输入LLM。这样既能把每个知识块的粒度做小，提高召回精准度，又能给LLM提供足够的生成上下文。

3. 从知识摘要扩充到原始内容

构建两种类型的知识块：一种存知识摘要，另一种存原始内容。

。这种方案提供了更高层面的检索手段，更适合原知识内容过于细节、而问题输入相对概括单一的场景。

4. 从“小”知识扩充到“大”知识

这是一种多粒度分割与嵌入方案。

。检索到关联的小块后，根据关系找到包含更丰富内容的大块，再输入给LLM。

上面几种拆分“检索块”与“生成块”的策略，实现方法虽然不同，但核心理念一致：

。

考量三：对大文档集知识库做分层检索

如果你只是用笔记本上一个简单的PDF搭经典RAG，可能永远遇不到这个坑。但在企业复杂的知识密集型场景里，几百个不同来源、不同类型的知识文档堆在那里，光靠传统文本分割+top-k检索，精度不足、知识互相干扰的问题立马冒出来。最关键的还是检索阶段。一个重要的方法是实现

。下面介绍三种分层检索策略。

【元数据过滤 + 向量检索】

在向量库构建时，根据文档信息对每个知识块做元数据标识（比如地区、类型），然后生成向量并存储。检索流程变成：

• 利用LLM推理输入问题的元数据信息；
• 借助向量数据库的元数据过滤定位到部分文档；
• 再结合向量语义检索，进一步定位到top-k知识块。

好处是简单，能快速自动过滤；缺点也不少：需要设计元数据标签、LLM推理元数据有不确定性、元数据只能精确匹配不能语义搜索、可能需要依赖特定向量数据库。

【摘要检索 + 内容检索】

这个方案用了前面提到的“小块到大块”多层向量思想。对每个文档做摘要提取，在摘要和原始文档两个级别分别做嵌入与向量存储，并关联两者。检索流程：

• 在摘要级别检索，获得相关摘要块；
• 根据摘要块的关联信息，关联到原始文档；
• 递归查找原始文档的知识块，找到top-k上下文。

好处是两个层次都能做语义检索。缺点是：需要借助LLM生成摘要块，成本增加；摘要匹配一旦出错，后续就得不到有效上下文。

【多文档AI Agent】

和前两种不同，这是基于AI Agent思想的方案。同样是两级结构，但不是简单的两级向量递归，而是

。核心思路：

• 为每个文档或知识库实现一个知识Agent，能够使用一个或多个RAG工具回答问题；
• 在多个知识Agent之上实现一个语义路由Agent，借助推理来调用后端知识Agent完成任务。

这不是简单的知识检索优化，而是基于RAG的多级Agent方案（Agentic RAG）。

。知识既可以是向量化的，也可以是外部系统的结构化/非结构化知识。优势主要来自两点：

• 通过对二级Agent的扩展，可以赋予更多工具能力，不再局限于回答事实性问题，还能做整理、摘要生成、数据分析，甚至通过API访问外部实时知识。
• 多个Tool Agent可以协作完成联合型任务，比如对比和汇总两个不同文档的知识——这是经典问答型RAG做不到的。

当然，这种方案的缺点是实现复杂度高。后面我们会专门用文章和实例探讨Agentic RAG的应用。

我们将在【下】篇中继续探讨RAG应用的另外三个常见优化考量。