基本RAG vs 高级RAG

了解大型语言模型的朋友可能都有这样的体会：这些模型确实厉害，能写出流畅的文本、生成有创意的新内容、还能给出聪明的回答。但事情的另一面是，不管它们训练了多少数据，知识边界就是训练数据本身——这就注定了它们没法实时提供最新的信息。

于是问题来了：你问一个模型“今天发生了什么新闻”，它大概率会给你一个过时甚至完全错误的答案。这种现象，业界有个专门的叫法——信息幻觉。而为了应对这个问题，一种叫“检索增强生成”（RAG）的技术方案逐渐浮出水面。它的核心思路很简单：把传统语言模型的“聪明劲儿”和检索系统的“信息获取能力”结合起来，让模型不再凭空硬编答案。

什么是RAG？

RAG是一种检索增强方法，目标很明确——提升大型语言模型的实战表现。通过在文本生成过程中引入一个信息检索的步骤，它能确保模型的回答更加靠谱、更有时效性。当然，RAG这些年也在迭代，目前主要发展出了两种模式：

• Naive RAG（基础RAG）
  ：最原始的版本。系统直接从知识库里检索相关信息，然后一股脑儿丢给LLM去生成回答。简单直接，但没什么花招。

• Advanced RAG（高级RAG）
  ：进化版。在检索前和检索后都增加了额外的处理步骤，对拿到的信息再做一轮精加工，确保生成的回答不仅准确，还能跟上下文无缝衔接。

Naive RAG

Naive RAG算是RAG家族的“开山之作”，思路非常直接：把检索到的数据和LLM模型绑在一起，快速生成回答。它的基本工作流程包含以下几个环节：

1. 文档分块
   ：启动之前先把文档拆成小段。道理很简单——小块更容易管理和处理。比如你有一份超长文档，先把它切碎，系统后续检索的时候才方便定位。

2. 嵌入模型
   ：这是系统的核心部件之一。它把文档块和用户的查询都转换成数值形式的“嵌入”——计算机天生擅长处理数字。用机器学习的办法，给文本的含义做一个“数学素描”。比方说，用户提一个问题，模型就把这个问题转化成一组数字，这组数字能捕捉到查询背后的语义。

3. 向量数据库（MyScaleDB）
   ：文档块转成嵌入之后，全部存入向量数据库（比如MyScaleDB）。这种数据库天生就是干这个的——高效存储和检索嵌入。用户提交查询，系统就拿查询的嵌入跟库里存的嵌入做比对，找到最相关的那些文档块。比对结果越匹配，说明离用户的问题越近。

4. 检索
   ：一旦向量数据库找到了相关的文档块，就把它捞出来。这一步很关键——它决定了哪些信息会进入最终的生成环节。只有最相关的数据才能进入下一步。

5. LLM（大型语言模型）
   ：相关块到手后，LLM上位。它的任务很明确：理解检索到的信息，生成一个连贯的回答。回答既要覆盖用户的问题，又要跟检索到的块在语境上合得上。

6. 回答生成
   ：最终，系统基于LLM处理完的信息给出答案，交到用户手上。整个过程力求清晰、简洁、刚好命中需求。

顺着这个流程，从用户发起查询到收到最终答案，整条数据链路就清楚了。每个组件都各司其职，保障最后传回用户手里的信息是准确且相关的。

优点很明显，但短板也同样突出

• 实现简单：嵌入式把检索和生成焊在一起，省去了复杂的定制修改和额外组件。
• 无需微调：不用动LLM本身，节省了大量时间和运营成本，能快速部署。
• 增强准确性：用外部的实时信息“喂”给模型，输出结果自然更靠谱。
• 减少幻觉：拿真实数据说话，从根本上抑制了模型胡编乱造的可能性。
• 可扩展性和灵活性：简单架构让它在不同应用场景间切换成本很低，几乎可以即插即用。

• 处理能力有限：检索到的信息直接裸用，不做二次加工，生成的回答可能在连贯性上打折扣。
• 依赖检索质量：如果检索模块拉回的东西不对或不全，那后续的生成“巧妇难为无米之炊”。
• 扩展性问题：数据集一大，检索速度可能拖后腿，影响整体性能。
• 上下文限制：它不太擅长把握用户的深层意图，有时给出表面正确的答案，但跟用户想要的并不完全匹配。

Advanced RAG

在Naive RAG的基础上，Advanced RAG多做了几步功夫。它不像基础版那样拿过来直接用，而是在生成最终答案前，对检索到的数据再做一轮精加工——排序、压缩、去噪，确保输出的质量和相关性都更上一层楼。

检索前的优化功夫

在进入实际检索环节之前，Advanced RAG就已经开始“做功课”了：

• 索引改进
  ：MyScale的MSTG（多策略树图）索引算法在速度和性能上超过了不少同类方法。它融合了层次图和树结构的长处，在未筛选和已筛选搜索场景下都表现不俗。

• 查询重写
  ：检索启动前，先对用户的原始查询做一轮“修缮”——重写、扩展、转换。比如用户的问题太宽泛，就补充一些上下文或具体术语；或者加进同义词和关联术语，让搜索的触角伸得更广。

• 动态嵌入
  ：Naive RAG常常只用一套嵌入模型打天下，针对不同场景效率可能不够。Advanced RAG会根据具体任务或领域对嵌入模型做调校，让它更懂得某个领域里的微妙语境。

• 混合搜索
  ：不再死磕单一搜索策略。关键字搜索、语义搜索、神经搜索混着来。比如MyScaleDB就支持过滤后的向量搜索加上全文搜索，还能用复杂的SQL查询来精细筛选。

检索后的二次加工

检索完毕不代表万事大吉，Advanced RAG还在收尾阶段下功夫：

• 重排序
  ：捞出的结果按相关性再排一遍队。优先把最有用、最精准的信息推上前台，确保最终生成的回答既准确又流畅。

• 上下文压缩
  ：送给LLM之前，先剔除冗余和噪音。只保留最核心的信息，让LLM的工作更聚焦、效率更高。

Advanced RAG的优势

• 更高的相关性：通过重排序，最相关的信息被优先使用，答案的准确度和流畅度都明显提升。
• 动态嵌入：嵌入模型适配具体任务，能让系统更懂不同的查询需求。
• 更精确的检索：混合搜索策略让捞回来的信息高度相关，误差更小。
• 更高效的生成：上下文压缩去掉不必要的内容，处理更快、输出更集中。
• 更强的查询理解：检索前的查询重写和扩展，确保系统充分吃透用户想问什么。

对比

把Naive RAG和Advanced RAG放在一块看就能发现，后者在前者的基础上引入了不少关键改进——准确性更高、效率更优、检索质量整体提升了一截。

结论

Naive RAG和Advanced RAG都是很强大的RAG框架，各有擅长的赛道。

Naive RAG胜在简单直接、响应快，尤其适合那些需要快速上手、运维成本低的应用场景。它把检索和生成直接拧在一起，大大提升了回答生成的能力，特别适用于时间紧、资源紧的环境。

而Advanced RAG更适合对质量和准确性有高要求的场景。它不满足于“捞到什么就用什么”，而是在检索前后都动刀，给生成的答案多添了一道“精炼”的工序，让回答不仅准确，还更流畅、更贴合上下文。对于处理复杂需求、追求高质量输出的项目来说，它是更有底气的选择。