如何设计一个RAG

构建一个检索增强生成系统（RAG）听起来确实很简单。借助像是 LlamaIndex 或 LangChain 这样的框架，几分钟就能搭出一个原型。让大模型基于外部数据回答问题，这个核心功能跑通起来并不费劲。但真正决定系统成败的，从来不是跑通流程，而是把它设计好。最近我自己也完整走了一遍这个流程，才深刻体会到，从索引到生成，每一步都塞满了大大小小的选择，而这些选择又会以各种隐蔽的方式影响性能、行为和成本。

言归正传，下面就来逐一梳理这些设计选择。

RAG的五个组成部分

RAG 系统的本质，是让聊天机器人能访问外部数据，从而做出有据可依的回答，而不是凭空编造。因此，它需要处理从数据获取到最终生成答案的全流程。我习惯从五个核心组件来思考这个系统：

• 索引
  ：把外部数据转换成向量表示。

• 存储
  ：把向量嵌入存到数据库里。

• 检索
  ：从存储的数据中找出相关的片段。

• 合成
  ：基于检索到的信息生成回答。

• 评估
  ：量化整个系统表现的好坏。

索引：从数据到向量的第一步

索引是所有工作的起点，它的任务是把各种格式的源数据——可能是 PDF、Excel、SQL 数据库，甚至是图像和视频——统统转换成数字向量。这一步的核心理念是：相似的输入会产生相似的向量，不同的输入则会在向量空间中相距甚远。这是后续检索得以成立的前提。

关于索引，需要关注以下几个设计要点：

数据处理方式：批处理还是流式？

简单来说，就是选择定期批量处理新数据，还是一有数据更新就立刻处理。批处理模式成本低、维护简单，适合数据更新频率固定的场景。比如一个法律咨询助手，如果新法规只在每周公报上发布，那么每周执行一次批量索引就足够了。但如果要做体育赛事实时问答，比分、球员动态瞬息万变，那就必须采用流式处理，确保系统能拿到最新的信息。

索引模型：选择哪种嵌入模型？

嵌入模型的质量直接决定了存储信息的颗粒度和检索时上下文的相关性。通常来说，专有的大模型更准，但调用成本高、速度也慢。一个值得注意的要点是：最好的嵌入模型，往往和后面用来生成答案的 LLM 不是同一个。速度问题尤其关键，因为索引不仅在预处理阶段发生，在用户提问时，也需要先用同一个模型把查询转换成向量，才能去数据库里比对。想换个模型？可以随时换生成模型，但索引模型一换，就意味着所有已经存好的数据都得重新索引一遍——数据量大的话，代价可不小。所以，选择嵌入模型时，最好把眼光放长远些。

文本分割方法：怎么切分文本？

在索引之前，文本需要先被切分成一个个块。怎么切，学问不小。是按句子、按 token、按段落，还是按语义来切？这直接决定了检索时模型会看到什么样的上下文片断。需要精确答案的场景，比如问答系统，按句子或语义块来切可能最合适，模型能精准定位到相关信息。而需要概括或整体理解的场景，比如总结或主题探索，按段落或层次结构来切则更有利，模型能获取更完整的上下文。

分块超参数：块多大？重叠多少？

除了切分方法，还有两个重要的超参数：块大小（以 token 数计）和块重叠。小块能产生非常精确的嵌入，但也可能导致最有用的信息恰好被切散，检索时落在 top-k 之外。大块则信息全面，但可能丢失细枝末节，而且给 LLM 的处理时间也更长。这是个需要权衡的选择。

存储：把向量安顿好

向量生成之后，需要一个落脚点。这就涉及两个关键决策：数据库选型和元数据策略。

数据库选型：向量数据库是关键

虽然原则上可以用常规 SQL 数据库来存放向量，但效率极低。RAG 系统通常会选择专门的向量数据库，它天生就是为存储和快速比对高维向量而设计的。市面上选择不少，从免费的开源方案到托管式 SaaS 产品都有。选型时，除了价格，还得看它是否支持你需要的功能，比如：与 LlamaIndex 或 LangChain 等开发框架的集成是否顺畅、是否支持混合搜索、有没有压缩或自动缩放的能力。别被花哨的高级功能吸引，关键是确认你的核心需求。

元数据策略：别什么都往里存

在向量数据库里，除了向量本身，还可以存储元数据。这在检索时能发挥奇效，比如通过元数据做预过滤，直接把不相关的内容排除掉，使搜索更快更准。一个实用的策略是：先设想你的 RAG 系统最理想的工作场景，想想用户会问什么问题，然后反推出哪些元数据能帮助定位答案。只存这些就够了。什么都存，换来的只是不必要的成本。

检索：找到最相关的信息

检索是连接索引和合成的桥梁，目标是从存储的海量数据中精准捞出与用户问题相关的信息。这部分需要关注：检索策略、超参数调优和查询转换。

检索策略：语义搜索还是混合搜索？

最基础的方法就是语义搜索，用余弦相似度等指标，找出与用户查询语义最接近的向量。但它的缺陷是可能漏掉关键词。混合搜索则结合了语义搜索和字面关键词搜索，效果往往更好。至于如何给找出来的结果排序，BM25（最佳匹配 25）算法是 RAG 领域的常客，另外还有更复杂的倒数秩融合（RRF）算法。值得一提的是，你选择的向量数据库可能会限制检索策略的选项，所以这部分最好在索引阶段就一并考虑。

一个有趣的变体是“块窗口检索”。它不只把检索到的相关块传给模型，还会把每个块前后的块也一并带上。这能给 LLM 提供更广的上下文，但代价是 token 用量增加，成本上升。不过，窗口宽度的好处通常不会线性增长，不建议设得过大。

检索超参数：Top-k 与相似度截止

所有检索策略都离不开两个超参数：Top-k（返回前 k 个最相似的块）和相似度截止。Top-k 越大，传入的上下文越丰富，但成本也越高，而且还可能把不那么相关的块也带进来。相似度截止则像一个门槛，只让相似度高于该值的块通过。设得太高可能什么也检索不到，设得太低又会让一堆无关内容混进来。这里的关键是：这两个参数必须联合调优，不能孤立地设置。把它们当作机器学习中的任何超参数一样对待，用评估结果来指导选择。

查询转换：用户的提问不那么完美，怎么办？

用户提问的措辞有时并不理想，这会影响检索效果。解决办法是在检索前对查询进行转换。常用的技术包括：

• 查询重写
  ：让 LLM 自己用更清晰的语言改写一遍。

• 子查询生成
  ：把模糊的原始提问拆解成几个更具体的问题，一并检索。

• 假设文档嵌入（HyDE）
  ：先让 LLM 基于提问生成一个“可能的答案”，哪怕有幻觉也不要紧，然后用“原始提问 + 这个假设答案”一起去检索。这背后的思路是，假设的答案虽然不准，但在语义上应该与真正优秀的答案相似，能帮助定位到更相关的信息。

查询转换能显著提升性能，尤其适合那些预期会收到短小模糊提问的场合。当然，代价是检索速度会因此变慢。

合成：生成最终的答案

合成是 RAG 系统的回答环节，由 LLM 基于检索到的上下文生成最终回复。这部分的核心在于：模型选择、系统提示以及合成超参数。

综合模型：选哪个 LLM？

生成模型的选择关乎回答的连贯性、准确性、安全性和成本。如果预算和响应时间允许，通常都会选择最好的模型。怎么找最好的？可以看看 Chatbot Arena 这样的社区排行榜，上面让用户盲评不同模型的回答，最终通过 ELO 分数排出名次。如果你的应用领域极其特殊（比如法律文本分析），那就要去查阅专门的评估基准，挑出在你最看重的维度上（如逻辑推理）表现最优的模型。

系统提示：给 LLM 的“操作手册”

系统提示是附在上下文和用户查询前面的一条指令，用来设定 LLM 的行为模式。设计系统提示与其说是一门科学，不如说更像一门艺术。但有一条是必须包含的：明确要求 LLM 只能基于提供的上下文来回答，不要依赖自身的一般知识。此外，你还可以通过系统提示来指定回答风格、控制长短。LlamaIndex 的文档里有很多关于提示工程的实践方法，可以借鉴。

合成超参数：窗口与长度

负责合成的 LLM 也有两个关键超参数：上下文窗口和最大响应长度。较长的窗口能让模型看到更多信息，但也可能掺杂不相关的内容。最大响应长度则由用例决定。一个实用的调优思路是：先设置一个你觉得能保证回答完整性的值，然后在评估阶段观察，如果发现回复经常因为触顶而被打断、无法充分说明问题，就再把这个值调大。别忘了，如果你是调用 API 按量付费，这两个值越大，成本越高。

评估：量化系统好坏

评估是整个 RAG 系统的闭环，也是让系统持续进化的核心。建立一套严谨的评估流程非常关键，主要包括：评估方案、评估员提示和模型指南。

评估方案：测什么、怎么测？

一份好的评估方案应该明确回答三个问题：用什么数据测试？关注哪些指标？哪个指标是优化的首要目标，哪些是必须满足的“满意度指标”？理想情况下，测试数据应该来自真实的目标用户。如果条件不允许，也可以使用 LLamaIndex 提供的数据集，但这时的评估结果只能反映实验室环境下的表现。

可选的评估指标很多，比如：回答的准确性和真实性、生成文本的连贯性、是否包含偏见或有害内容，以及用户满意度调查。特别推荐关注“RAG 三元组”指标——基础性、答案相关性和上下文相关性。这些指标抓住了 RAG 系统最核心的价值。实践中，通常会选择三元组的（加权）平均值作为优化指标，只要其他指标（如连贯性、安全性）能维持在一个可接受的水平即可。

评估员提示：量化指标的指令

很多自动化评估指标（比如忠诚度）是由 LLM 生成的。你需要给这个“评估教练”写一份提示。以忠诚度为例，LlamaIndex 默认的提示是让模型判断“上下文是否支持给定的信息”，并给出“是”或“否”的答案。虽然这些默认提示效果已经不错，但针对特定用例进行微调，有时能带来更好的评估效果。

模型指南：定好行为准则

模型指南是一组你希望系统遵守的规则。除了像“回应应完全回答问题”这类通用规则，你还可以根据应用特点添加更具体的指导。例如，一个侧重快速传递信息的应用，可以加上“回应应简洁，避免不必要的冗词”；一个面向社区的问答系统，则可以加入“回应应尊重所有用户，避免冒犯性语言”。

总结与资源

设计一个好的 RAG 系统远不止是搭好一个流水线那么简单，它关乎在每一个环节做出明智的权衡。希望上面的梳理能帮你理清头绪。

最后，附上两个实用资源，可以进一步探索：

• 使用 LlamaIndex 评估 RAG 系统的理想块大小：https://mp.weixin.qq.com/s/DfYCvMHXPWRR7UpQU2AGuA
• HyDE Query Transform 的官方 Demo：https://docs.llamaindex.ai/en/stable/examples/query_transformations/HyDEQueryTransformDemo.html