传统RAG过时了？从RAG到RAG Flow的架构演进与技术实现 ｜LLM应用探讨

大模型发展到现在，随着下游应用尤其是B端场景不断深入验证，无论是知识密集型的RAG搜索问答，还是更复杂的AI Agents，在架构上都开始跳出简单的提示工程和传统“链”式套路，向着更灵活、更强大的方向演进。本文就借着当前最常见的RAG（检索增强生成）应用，聊聊它的最新架构变化和技术实现。

目录里先列几个重点：LLM应用架构的演进、RAG应用面临的挑战、从RAG到RAG Flow、实现一个RAG Flow，最后收个尾。好，我们直接开讲。

01 LLM应用架构的演进

这里说的应用，是指

。目前最主流的形态就是AI Agents智能体和RAG类应用，两者经常融合在一起。很多商业大模型开发平台和框架，已经把关注的焦点从简单的Re-Act范式或者Retrieve-Augment，转向了一些新特征和趋势：

• 从依赖单一模型到多模型协作。
  随着大模型在专业领域越来越细分，再加上大量“小”模型涌现，“让合适的模型干合适的事”成了实实在在的技术考量。有的模型擅长某领域知识推理，有的针对RAG场景做了微调，有的则在Text2SQL任务上表现更优——各司其职，效果拉满。

• 从“黑盒子”转向开放、可编排、可跟踪。
  大模型本身缺乏可解释性，如果完全依赖它自身的决策和思维链（COT），不确定性会非常大。这点在早期AutoGPT等Agent项目里体会很深——遇到复杂任务，结果基本是开盲盒。

• 从顺序式简单架构走向复杂WorkFlow。
  场景复杂了，优化方法也多了，简单的顺序执行步骤已经不够用。分支、并行、迭代、循环这些更复杂的工作流，能充分挖掘大模型潜力，让效果更优。

再说个老朋友——还记得LangGraph吗？前几篇文章里剖析过它，其推出的根本动机就是为了适应越来越复杂的Agent工作流。传统的Chain和黑盒Agent组件满足不了新需求。LangGraph用图（Graph）这种更灵活的算法结构来定义任务节点、关系和状态迁移，几乎能应对无限场景下的复杂Agent需求，开发效率提升巨大。

单一Prompt工程加个大模型已经不够用了。一个优化的Agent应用里，可能会融合更多类型的AI模型和技术：单模态、多模态、预测模型、视觉模型、向量搜索、关键字搜索、重排算法……多种AI技术组合在一起。比如一个Text2SQL分析助手，可以结合RAG思想来增强SQL生成。

下面，我们就从最常见的LLM RAG应用来认识这种架构转变和相关技术。

02 RAG应用面临的挑战

RAG的基本思想大家已经很熟了：

传统经典RAG架构看似简单，但实际用起来往往是“上手容易，做好极难”，尤其是要满足企业生产环境，更难。一部分原因来自企业运营——比如私有知识的管理和维护；另一部分则来自技术本身——自然语言的复杂性给检索和理解带来了不少挑战。主要挑战集中在以下几块：

• 知识召回的精准度

  检索回来的外部知识是否有足够的相关性和覆盖性，直接决定了生成阶段的质量。如果召回的信息里掺杂了大量无用、噪声甚至矛盾的干扰，或者最重要的信息没落在大模型的“关注区域”里，那最终输出肯定要打折扣。

  召回精准度通常涉及索引和检索两大环节：

  • 索引：
    原始知识数据（文档、数据库、网站等）的加载、识别、切分、索引处理。微观层面又会牵扯到多模态文档处理、切分块大小选择、索引机制选择、Embedding模型选择等一系列技术问题。

  • 检索：
    尽管当前基于Embedding的向量技术对语义检索能力有很大提升，但索引块的大小、Embedding算法、原始数据质量等问题，都可能导致检索结果不够理想。

• 大模型自身的生成能力

  检索到的相关知识形成上下文，最终要靠LLM来理解并生成。所以LLM的生成能力是另一个关键环节。

  不同场景怎么选模型、要多大参数规模，往往是实施RAG时最先遇到的困惑。简单知识问答可能6B、13B的模型也能表现不错；但SQL生成、Tools使用这类任务，即使千亿参数的大模型，也很难达到80%以上的准确率。

  此外，检索结果的排序、干扰信息、多余信息、矛盾信息，都需要LLM自己去识别和区分。模型本身的“抗干扰”能力和“注意力”范围，对最终生成有重要影响。所以有些实际应用，会针对RAG场景微调大模型，让它更适合这个场景。

• 可能的技术限制与难点

  还有几个常见的坑：携带过多关联知识可能撑爆大模型的上下文窗口；处理步骤太多会影响端到端响应性能；在多轮对话中，一个输入问题的完整语义可能分布在多轮交互里，如何合并这些语义形成完整检索输入，也是个技术活。

03 从RAG到RAG Flow

正是这些挑战，倒逼RAG架构不断优化演进。这里借用同济大学等团队最近的一篇调查报告《Retrieval-Augmented Generation for Large Language Models: A Survey》里的观点，来看RAG架构的发展：

：

核心思想是：把RAG应用中的各个步骤拆成多个

（代表一个核心流程，比如预检索）、（代表一个核心流程中的功能，比如预检索里的查询重写）和（代表一种实现方法，比如查询重写可以普通重写，也可以用HyDE重写）。

这里不逐个介绍每个模块和典型算法，感兴趣的话可以去原项目的GitHub（搜索RAG-Survey）看看。

从上面的图可以看到，

，下面简单分析一下（图片均来自原论文）。

经典RAG范式，不过相比简单的query-retrieve-generate，这里加上了Pre-Retrieval和Post-Retrieval模块。常用的算法比如Pre-Retrieval的Query Rewrite（查询重写）和Post-Retrieval的Rerank（重排序）：

顾名思义，条件范式的RAG Flow会根据不同条件选择不同的后续RAG路径。条件判断需要增加路由模块，可以根据关键词或语义路由到不同的后续路径，不同路径可以用不同的流程、模型、提示词、算法等。
这在构建RAG应用里很常见。

分支范式就是流程里出现多个并行分支，并行的部分可能是Retrieve检索环节，也可能是Generate生成环节。
这也是种常见优化范式。

循环范式里推理过程更复杂，可以根据场景出现多次等方法。下面是一个迭代模式的RAG Flow：

在每次迭代中，利用前一次迭代的模型输出作为特定上下文，帮助检索更多相关知识，再生成新知识，直到达到预定义迭代次数终止。显然，

循环范式的知名案例是Self-RAG，一种借助LLM进行自我反思与按需检索的框架，用来提高生成准确性（可以在GitHub搜索Self-RAG）。

04 实现一个RAG Flow

实现相对复杂的RAG Flow架构，建议基于目前主流的两个开发框架：

两者各有优势。LangChain更面向通用LLM应用设计，功能强大但相对复杂；推出了

之后，构建复杂Workflow的RAG或Agent能力大大增强。LlamaIndex则更针对RAG类应用，预置了大量模块化RAG架构中的算法实现，包括各种高级检索、模型微调等。

工作机制如下：

1. 借助LLM把原始查询扩展成多个相似但不同的问题。
   注意相似问题尽量能提供不同视角，以拓展输入问题的广度和深度。

为什么需要扩展查询？
通常我们使用问答或搜索系统时，只习惯用单个输入查询。但单个问题可能无法完整或深入地表达用户真正意图，导致检索到的关联知识也无法很好覆盖需要的内容。比如想了解“个人所得税专项附加扣除的相关规定”，可以生成“个税专项附加扣除的扣除标准”“个税专项附加扣除的在线操作流程”“个税专项附加扣除的主要类型”等相似问题，这些能帮助检索到更全面深入的知识。

2. 对原始输入和新问题执行基于向量的语义搜索，获得搜索结果。

3. 对多个搜索结果进行结果重排名，这里使用倒数排名融合算法（RRF）。

关于RRF：
倒数排名融合 (RRF) 是一种把多个搜索结果列表的排名组合起来，生成单个统一排名的技术。通过组合不同查询的排名，能增加最相关文档/知识出现在最终排名顶部的机会，帮助LLM提高生成质量。详细原理可以读这篇论文：https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf

4. 把重新排序后的相关知识和输入问题交给LLM进行生成。

下面是主要代码实现（仅展示核心过程）：

#加载知识文档
loader = TextLoader(file_path="test.txt")
document = loader.load()

#分割文档
text_splitter = CharacterTextSplitter(separator="n",chunk_size=500,chunk_overlap=0)
data = text_splitter.split_documents(document)

#嵌入并存储向量库
db=Chroma.from_documents(documents=data,embedding_function=OpenAIEmbeddings(),persist_directory="./chrom_db")

#检索器
retriever=db.as_retriever(k=5)

使用Langchain构建查询扩展chain

llm=ChatOpenAI(temperature=0.0,model_name='gpt-3.5-turbo-1106')
template = """
你是一个聪明的AI助手，能够根据输入的单个查询生成多个相关的查询问题.
请根据如下查询内容生成5个相关的搜索查询: {query}
"""
prompt = ChatPromptTemplate.from_template(template)

#LCEL语言构建一个Chain
generate_queries = (
    prompt | llm | StrOutputParser() | (lambda x: x.split("n"))
)

#RRF实现算法：对每个相关问题搜索出来的文档列表依次处理
#重新计算每个文档的Score，最后形成重新排序的文档结果
def reciprocal_rank_fusion(results: list[list], k=60):
    fused_scores = {}
    for docs in results:
        for rank, doc in enumerate(docs):
            doc_str = dumps(doc)
            if doc_str not in fused_scores:
                fused_scores[doc_str] = 0
            previous_score = fused_scores[doc_str]
            fused_scores[doc_str] += 1 / (rank + k)
    reranked_results = [
        (loads(doc), score)
        for doc, score in sorted(fused_scores.items(), key=lambda x: x[1], reverse=True)
    ]
    return reranked_results

#构造一个rag fusion的chain
#处理过程：生成相似问题 => 检索问题相关文档 => 文档重排序
ragfusion_chain = generate_queries | retriever.map() | reciprocal_rank_fusion

template = """
基于如下上下文回答问题:
{context}
===
问题: {question}
"""
prompt = ChatPromptTemplate.from_template(template)
#构建生成器的Chain
#输入：retriever返回的检索结果与输入问题
final_chain = ({"context": rag_fusion_chain, "question": RunnablePassthrough ()}
| prompt
| llm
| StrOutputParser ()
)

final_chain.invoke({question:"请介绍个人所得税专项附加扣除的政策"})

05 结束语

前面简单聊了聊当前LLM原生应用在架构演进上的一些新特征和范式，特别是更灵活的基于WorkFlow的架构，它大大扩充了LLM的应用场景，也提升了任务准确性和可靠性。说到底，技术总是在挑战中迭代，而RAG Flow这种模块化、可编排的思路，正是解决实际生产问题的关键方向之一。