智能体化规划驱动多模态RAG:从检索生成到思考检索生成的范式跃迁

📅 2026/8/23 1:58:40
智能体化规划驱动多模态RAG:从检索生成到思考检索生成的范式跃迁
1. 从“检索-生成”到“思考-检索-生成”多模态RAG的范式跃迁最近在跟几个做企业知识库和内容生成的朋友聊天发现一个挺有意思的现象。大家一提到RAG脑子里蹦出来的第一反应还是那个经典的三段式流程文档切片、向量化、塞进向量数据库然后用户提问系统检索最后把检索到的片段扔给大模型去生成答案。这个模式我们姑且称之为“检索即答”Retrieve-then-Generate。它在处理纯文本、结构清晰的知识问答时确实立下了汗马功劳让很多项目快速跑通了从0到1。但当我们把场景切换到更复杂的现实世界比如需要分析一份包含图表、流程图和文字说明的PDF市场报告或者理解一张产品设计图上的标注和旁边的技术参数表格时问题就来了。传统的RAG系统就像一个视力很好但不太会动脑子的助手。你问它“这张图表里第三季度的增长率是多少”它可能会一股脑地把文档里所有提到“增长率”的文本片段甚至是一些不相关的图片描述向量都检索出来然后硬塞给大模型。大模型面对这些杂乱无章、可能还包含它“看不懂”的图片向量信息只能硬着头皮生成结果往往是答非所问或者干脆胡编乱造。这就是典型的“垃圾进垃圾出”Garbage In, Garbage Out检索的质量直接决定了最终答案的上限。这背后的核心矛盾在于多模态信息文本、图像、表格、代码等的复杂性和关联性远远超出了简单向量相似度匹配的能力范围。一张技术架构图的价值不仅在于图本身更在于图例说明、图中的文字标注、以及前后文对其的阐述。传统的“检索即答”范式缺乏一个前置的“理解”和“规划”环节它不知道用户到底想问图的哪个部分也不知道应该优先检索文本描述还是图像特征更不知道如何将不同模态的信息片段有机地组合起来进行推理。于是“智能体化规划”Agentic Planning的思路开始被引入到多模态RAG中形成了“Reason Before You Retrieve”的新范式。这个范式不再是机械的“提问-检索-回答”而是引入了一个“智能体”角色。这个智能体的核心任务是在执行检索之前先对用户的复杂问题、对话历史、可用工具进行一番“思考”和“规划”。它要自己拆解问题判断需要哪些模态的信息规划调用哪些工具如图像理解模型、表格解析器、代码分析器以及调用的顺序然后再根据规划结果发起精准的、多步骤的检索。这相当于给RAG系统装上了一个“大脑”让它从被动的信息搬运工变成了主动的问题解决者。2. 智能体化规划的核心组件与工作流拆解一个典型的、基于智能体化规划的多模态RAG系统其内部不再是线性的管道而是一个由多个协同工作的智能体模块构成的“小团队”。我们可以把这个团队拆解为几个核心角色来看看它们是如何工作的。2.1 规划智能体任务拆解与蓝图绘制这是整个系统的“总指挥”。它的输入是用户的原始查询Query可能还包括对话历史Context。它的核心职责是进行任务分解Task Decomposition和工具规划Tool Planning。任务分解面对一个复杂问题如“对比一下我们去年和今年的产品宣传册在设计风格和核心卖点表述上的差异”。规划智能体不会直接把这个长句扔去检索。它会分析出这个任务至少包含几个子任务识别并定位“去年产品宣传册”文档。识别并定位“今年产品宣传册”文档。从两份宣传册中提取“设计风格”相关信息这主要涉及图像分析。从两份宣传册中提取“核心卖点表述”相关信息这主要涉及文本分析。对提取出的信息进行对比分析。工具规划针对每个子任务规划智能体需要决定调用哪个“工具”即哪个专有能力模块来完成。例如对于任务1和2可能需要调用“文档检索工具”先根据元数据如年份、文档类型缩小范围。对于任务3明确需要调用“视觉理解工具”如CLIP、BLIP等模型来分析宣传册的封面、版式、配色等。对于任务4则需要调用“文本理解工具”来解析宣传册中的标题、要点列表、段落文字。对于任务5则可能由规划智能体自身或一个专门的“推理智能体”来汇总处理。规划智能体的输出是一个结构化的执行计划Plan。这个计划可能是一个JSON结构清晰地列出了步骤序列、每个步骤的目标、所需的工具、以及该步骤的输入应该是什么可能依赖于上一步的输出。{ plan: [ { step: 1, goal: 定位去年和今年的产品宣传册PDF文件, tool: metadata_filter_retriever, parameters: {doc_type: brochure, year: [2023, 2024]} }, { step: 2, goal: 从定位到的PDF中提取所有页面图像用于风格分析, tool: pdf_image_extractor, depends_on: 1 }, { step: 3, goal: 使用视觉模型分析提取图像的风格特征如颜色分布、布局复杂度, tool: visual_style_analyzer, depends_on: 2 }, { step: 4, goal: 从定位到的PDF中提取所有文本内容用于卖点分析, tool: pdf_text_extractor, depends_on: 1 }, { step: 5, goal: 使用文本模型识别并总结核心卖点表述, tool: key_point_extractor, depends_on: 4 }, { step: 6, goal: 综合视觉风格特征和文本卖点生成对比报告, tool: report_generator, depends_on: [3, 5] } ] }2.2 工具执行智能体专业化能力的调度中心规划智能体制定了蓝图接下来就需要“工人”去执行。工具执行智能体就是这个调度中心。它本身可能不直接具备视觉、文本分析能力但它知道如何调用这些专业工具。工具注册与管理系统需要预先将各种能力封装成“工具”。例如multi_modal_retriever: 一个能同时处理文本查询和图像查询的检索器背后可能连接着Milvus、Qdrant等向量数据库其中存储了文本块向量、图像特征向量甚至多模态联合向量。table_extractor: 专门从PDF或图片中提取表格结构化和数据的工具。diagram_parser: 解析流程图、架构图识别图形元素和连接关系的工具。code_analyzer: 对检索到的代码片段进行语法解析、摘要生成的工具。按计划调度工具执行智能体接收规划智能体产生的执行计划然后按顺序或根据依赖关系图调用相应的工具。它负责将上一步的输出转化为下一步工具所需的输入格式。例如它从pdf_image_extractor拿到图片列表然后循环调用visual_style_analyzer对每张图片进行分析并将结果收集起来。注意这里的工具调用可以是同步的也可以是异步的。对于没有依赖关系的任务如同时分析多张图片完全可以并行执行以提升效率。这是智能体化架构相比线性管道的一大优势。2.3 检索智能体从“模糊匹配”到“精准制导”在传统RAG中检索器Retriever是核心但也是“傻白甜”——它只做相似度匹配。在智能体化规划范式中检索智能体被赋予了更明确的指令和上下文。查询改写与丰富检索智能体在收到检索指令时这个指令已经不再是用户的原始问题而是规划中某个步骤的明确目标。例如目标可能是“检索与‘产品宣传册封面设计风格’相关的文本描述和图像片段”。检索智能体可以基于这个明确的目标生成更精准的查询向量。它甚至可以利用大语言模型的能力将指令改写成多个不同角度、不同表述的查询进行查询扩展Query Expansion以提高召回率。混合检索策略根据指令检索智能体可以动态决定采用哪种检索策略。是纯文本检索纯图像检索还是需要将文本查询和图像特征进行某种融合后的多模态检索它也可以决定是否需要结合关键词搜索稀疏检索和向量搜索稠密检索进行混合检索Hybrid Search以兼顾精确度和召回率。结果初步过滤与排序检索回来的原始片段可能很多。检索智能体可以基于当前步骤的目标对结果进行初步的相关性过滤和排序只将最相关的Top-K个结果传递给下一步。这减轻了后续推理环节的负担。2.4 推理与合成智能体从碎片到答案的“拼图师”所有工具执行和检索的结果最终会汇聚到推理与合成智能体这里。它的任务是把这些来自不同工具、不同模态的“信息碎片”拼成一幅完整的“答案图景”。多模态信息融合这是最具挑战性的部分。它需要理解文本描述、图像特征、表格数据之间的内在联系。例如它需要将视觉分析得出的“封面主色调为蓝色布局简洁”与文本分析得出的“强调科技感与可靠性”关联起来形成“采用蓝色简洁设计以视觉化传达科技与可靠的品牌形象”的洞察。冲突消解不同来源的信息可能存在矛盾。比如图像识别可能将某个图表中的趋势判断为“上升”但旁边文本的描述却是“平稳”。推理智能体需要根据置信度、来源优先级或进行二次验证如下一步规划去检索更权威的源来解决冲突。最终答案生成在融合了所有必要信息后推理智能体驱动大语言模型生成最终的回答。这个回答不再是基于一堆杂乱片段的“编造”而是基于经过规划、检索、验证的结构化信息的“推导”因此其准确性、可靠性和可解释性都大大增强。整个工作流形成了一个动态的、可循环的闭环规划 - 执行/检索 - 推理 - 根据推理结果可能触发新一轮的规划。例如在推理时发现信息不足或存在矛盾推理智能体可以反馈给规划智能体请求制定一个新的子计划去获取补充信息。3. 实现路径从框架选型到核心代码实践理解了架构我们来看看如何动手搭建一个这样的系统。目前业界并没有一个开箱即用的“多模态Agentic RAG”全家桶但我们可以利用现有的优秀框架进行组合和扩展。3.1 框架与工具链选型1. 智能体框架Agent Framework这是实现“规划”和“工具调用”逻辑的核心。推荐使用LangChain或LlamaIndex的高级抽象。LangChain其AgentExecutor、Tool抽象以及ReAct、Plan-and-Execute等代理类型非常适合构建此类系统。LangChain的生态丰富支持多模态模型如GPT-4V作为智能体的“大脑”。LlamaIndex从RAG起家对数据连接、索引构建有天然优势。它的AgentRunner和QueryEngineTool等概念能很自然地将RAG检索器封装成智能体可用的工具。LlamaIndex对多模态数据的索引和查询支持也在快速演进中。新兴框架CrewAI强调多智能体协作其“角色-任务-工具”的模型与我们的“规划-执行”范式非常契合可以清晰地定义规划者、检索专家、视觉分析师等角色。2. 多模态模型与嵌入模型规划与推理大脑需要强大的多模态大语言模型MLLM来理解复杂指令、拆解任务、进行深层推理。GPT-4V(ision)、Claude 3Opus/Sonnet是闭源领域的佼佼者。开源方面LLaVA-Next、Qwen-VL、CogVLM等模型能力越来越强可以部署在本地或私有云上。视觉理解工具除了直接用MLLM分析图像专精的模型可能效率更高。例如用CLIP做图像-文本的跨模态检索和零样本分类用BLIP-2进行图像描述生成和视觉问答用PaddleOCR或EasyOCR提取图像中的文字。多模态嵌入模型这是实现高质量多模态检索的基石。你需要一个能将文本和图像映射到同一向量空间的模型。OpenAI的CLIP文本/图像编码器是经典选择。Salesforce的BLIP系列也提供了强大的嵌入能力。开源社区如BAAI的FlagEmbedding项目也在推进多模态嵌入模型的发展。3. 向量数据库与检索器向量数据库需要支持多种向量类型文本向量、图像向量以及可能的混合查询。Milvus、Qdrant、Weaviate、Pinecone都是成熟的选择。它们通常支持过滤、分块、多向量检索等高级功能。检索器抽象利用LangChain或LlamaIndex的Retriever抽象你可以封装一个“多模态检索器”。这个检索器内部可能并行查询文本向量索引和图像向量索引然后对结果进行融合排序。3.2 核心代码实践构建一个简易的智能体化多模态RAG系统下面我们以LangChain GPT-4V CLIP Qdrant为例勾勒一个核心的实现片段。请注意这是一个高度简化的示例用于展示核心逻辑。步骤1环境准备与数据索引假设我们有一批产品文档包含PDF内嵌图片和文字。我们需要先进行多模态索引。# 伪代码/概念性代码 import langchain from langchain.vectorstores import Qdrant from langchain.embeddings import HuggingFaceEmbeddings from PIL import Image import fitz # PyMuPDF # 1. 初始化嵌入模型 # 文本嵌入模型 text_embedder HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh) # 图像嵌入模型 (使用CLIP) from transformers import CLIPProcessor, CLIPModel clip_model CLIPModel.from_pretrained(openai/clip-vit-base-patch32) clip_processor CLIPProcessor.from_pretrained(openai/clip-vit-base-patch32) def embed_image(image_path): image Image.open(image_path) inputs clip_processor(imagesimage, return_tensorspt) with torch.no_grad(): image_features clip_model.get_image_features(**inputs) return image_features.squeeze().numpy() # 2. 处理PDF提取文本块和图像 documents [] for pdf_path in pdf_files: doc fitz.open(pdf_path) for page_num in range(len(doc)): page doc[page_num] # 提取文本 text page.get_text() if text.strip(): # 创建文本Document对象包含元数据如来源、页码 text_doc Document(page_contenttext, metadata{source: pdf_path, page: page_num, type: text}) documents.append(text_doc) # 提取图像 image_list page.get_images() for img_index, img in enumerate(image_list): xref img[0] pix fitz.Pixmap(doc, xref) image_path ftemp_{pdf_path}_p{page_num}_i{img_index}.png pix.save(image_path) # 创建图像Document对象存储图像路径和嵌入向量 image_vector embed_image(image_path) image_doc Document(page_contentimage_path, metadata{source: pdf_path, page: page_num, type: image, embedding: image_vector}) documents.append(image_doc) # 3. 构建向量存储此处简化实际需分别存储文本和图像向量或使用支持多向量的数据库 # 假设我们使用一个支持多向量或自定义元数据的方案 vectorstore Qdrant.from_documents( documentsdocuments, embeddingtext_embedder, # 主要文本嵌入 collection_namemulti_modal_docs, # 需要自定义方式存储图像向量例如存入metadata或使用另一个collection )步骤2定义工具我们将检索器、图像分析器等封装成LangChain的Tool对象。from langchain.tools import Tool from langchain.chains import RetrievalQA from langchain.llms import OpenAI # 1. 定义多模态检索工具 def multi_modal_retrieve(query: str, filter_type: str None): 根据查询和过滤类型进行检索。 filter_type: text, image, or None (混合) # 构建过滤条件 filter_condition None if filter_type: filter_condition {type: filter_type} # 执行检索 (这里需要根据vectorstore的具体实现调整) # 如果是混合检索可能需要分别查询文本和图像索引然后融合结果 if filter_type text or filter_type is None: text_docs vectorstore.similarity_search(query, k3, filterfilter_condition) if filter_type image or filter_type is None: # 对于图像检索需要将文本查询转换为图像查询向量例如用CLIP的文本编码器 text_inputs clip_processor(textquery, return_tensorspt, paddingTrue) with torch.no_grad(): text_features clip_model.get_text_features(**text_inputs) query_image_vector text_features.squeeze().numpy() # 假设我们有一个专门存储图像向量的索引 image_vectorstore image_docs image_vectorstore.similarity_search_by_vector(query_image_vector, k3) # 合并和排序结果简化处理实际可能需要更复杂的重排序模型 combined_docs [...] return combined_docs retrieval_tool Tool( nameMultiModalRetriever, funcmulti_modal_retrieve, descriptionUseful for searching through multi-modal documents (text and images). Specify filter_type: text, image, or leave empty for hybrid search. ) # 2. 定义图像分析工具调用MLLM如GPT-4V import base64 from langchain.chat_models import ChatOpenAI from langchain.schema import HumanMessage def analyze_image(image_path: str, question: str): 使用GPT-4V分析图像并回答问题。 with open(image_path, rb) as image_file: encoded_image base64.b64encode(image_file.read()).decode(utf-8) chat ChatOpenAI(modelgpt-4-vision-preview, max_tokens500) message HumanMessage( content[ {type: text, text: question}, {type: image_url, image_url: {url: fdata:image/png;base64,{encoded_image}}}, ] ) response chat([message]) return response.content vision_analysis_tool Tool( nameImageAnalyzer, funcanalyze_image, descriptionUseful for answering questions about the content, style, or details of an image. Input should be the image file path and a specific question. ) tools [retrieval_tool, vision_analysis_tool]步骤3构建智能体并执行使用LangChain的create_react_agent或Plan-and-Execute模式来组装智能体。from langchain.agents import AgentExecutor, create_react_agent from langchain.prompts import PromptTemplate from langchain.llms import OpenAI # 或使用ChatOpenAI with gpt-4 # 使用一个强大的LLM作为智能体的“大脑” llm ChatOpenAI(modelgpt-4-turbo, temperature0) # ReAct代理提示词模板 prompt PromptTemplate.from_template( Answer the following question as best you can. You have access to the following tools: {tools} Use the following format: Question: the input question you must answer Thought: you should always think about what to do Action: the action to take, should be one of [{tool_names}] Action Input: the input to the action Observation: the result of the action ... (this Thought/Action/Action Input/Observation can repeat N times) Thought: I now know the final answer Final Answer: the final answer to the original question Begin! Question: {input} Thought:{agent_scratchpad} ) # 创建智能体 agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 执行一个复杂查询 result agent_executor.invoke({ input: 对比一下我们去年和今年的产品宣传册在设计风格和核心卖点表述上的差异。 }) print(result[output])在这个简化的流程中智能体由GPT-4驱动会自己“思考”Thought我需要先找到去年和今年的宣传册。我应该使用检索工具。Action:MultiModalRetrieverAction Input:query产品宣传册, filter_typetext先通过文本元数据定位文档Observation: 检索到两个PDF文档brochure_2023.pdf,brochure_2024.pdf。Thought现在我需要分析它们的设计风格。这需要看图片。我可以从PDF中提取图片或者直接用检索工具找这些文档里的图片。Action:MultiModalRetrieverAction Input:query封面 设计 风格, filter_typeimage, metadata_filter{source: [brochure_2023.pdf, brochure_2024.pdf]}Observation: 检索到若干封面图片路径。Thought我需要用图像分析工具来分析这些封面的风格。Action:ImageAnalyzerAction Input:image_path...brochure_2023_cover.png, question描述这张图片的设计风格包括主要颜色、布局、字体感觉等。...循环执行分析另一张封面并检索分析文本卖点...Thought我已经收集了关于设计风格和文本卖点的信息现在可以总结差异了。Final Answer: 生成最终对比报告。4. 实战中的挑战、优化策略与未来展望将智能体化规划应用于多模态RAG虽然前景广阔但在实际落地中会遇到不少挑战。这里分享一些我实践中遇到的“坑”和思考的优化方向。4.1 核心挑战与应对策略1. 规划的不确定性与错误累积智能体的规划能力完全依赖于底层大语言模型LLM/MLLM的推理能力。模型可能会制定出有缺陷、不完整或根本无法执行的计划。一个步骤的错误会导致后续步骤全部偏离。应对策略规划验证与回滚设计一个简单的验证机制。例如在执行工具调用前先检查工具是否存在、输入参数格式是否正确。对于关键步骤可以设置“检查点”让另一个智能体或规则引擎验证中间结果是否合理不合理则触发重新规划。子目标细化与逐步确认不要让智能体一次性制定一个庞大的计划。可以采用“逐步细化”的方式。先制定一个高层计划然后每执行完一步根据结果再规划下一步的细节。这类似于人类的“走一步看一步”容错性更高。多智能体投票对于关键决策如“该用哪个工具”可以并行运行多个规划智能体让它们各自生成计划然后通过投票或一致性评估来选择最佳方案。2. 多模态信息对齐与融合的难题如何将一段文本描述、一张图片的特征向量、一个表格的数据进行语义层面的对齐和融合简单的拼接Concatenation往往效果不佳。应对策略使用多模态大模型作为融合器最直接有效的方法就是将检索到的所有多模态片段文本片段、图片的base64编码、表格的Markdown表示连同用户问题一起喂给GPT-4V、Claude 3等顶级MLLM。它们内在的多模态理解能力可以很好地完成融合与推理。缺点是成本高、延迟大。设计中间表示层为不同模态的信息设计一种统一的中间表示。例如将图像通过视觉模型转化为结构化的描述文本“一张柱状图展示了Q1到Q4的销售额分别为...将表格转化为Markdown或JSON格式。这样所有信息都“降维”到了文本模态可以用更成熟、更经济的纯文本LLM进行处理。关键在于描述的质量要足够高不能丢失关键信息。图神经网络融合将不同模态的信息片段视为图中的节点它们之间的共现关系、语义相似度等视为边构建一个异构图。然后利用图神经网络进行信息传播和聚合最终得到每个节点的融合表示。这种方法更复杂但理论上能更好地捕捉复杂关系。3. 系统复杂性与调试成本智能体系统由多个模块、多次LLM调用、多次工具调用组成整个链路很长任何一个环节出错都难以定位。调试这样的系统就像在调试一个黑盒集群。应对策略全面的日志与追踪必须为每个智能体的每次思考Thought、每次行动Action及其输入输出、每次工具调用、每次检索请求和结果都打上详细的日志并关联到一个唯一的会话ID。使用像LangSmith、Weights Biases这样的LLM应用观测平台是几乎必须的。设计可解释的规划与执行让智能体在规划时不仅输出动作也输出“理由”Why。在执行时记录每个步骤的“信心分数”或依据。这能帮助开发者理解系统的决策过程。模块化与单元测试将每个工具检索器、分析器都设计成独立的、可单元测试的服务。对智能体的规划能力可以构造大量的测试用例包括各种边界和异常情况进行批量测试评估其规划的成功率。4.2 性能优化与成本控制1. 检索阶段的优化分层检索与过滤不要一开始就用昂贵的多模态嵌入模型进行全量检索。可以先使用快速的元数据过滤如文档类型、时间范围和关键词匹配缩小候选集范围再对缩小后的集合进行精准的向量检索。缓存机制对于常见的查询模式、中间结果如图片特征向量、解析后的表格数据进行缓存可以极大减少重复计算和模型调用。自适应检索深度根据查询的复杂性动态调整检索数量K值。简单问题少检索复杂问题多检索。这可以通过一个轻量级分类器或规则来实现。2. 模型调用与推理优化小模型协同并非所有步骤都需要GPT-4。规划智能体可能需要强模型但一些简单的工具调用如格式转换、规则过滤完全可以用小模型或规则引擎。图像描述生成可以用专门的、更高效的VLM不一定非要GPT-4V。异步与并行执行仔细分析执行计划中的依赖关系图。对于没有依赖关系的任务如分析多张独立的图片一定要并行执行缩短整体响应时间。流式输出与渐进式生成对于需要长时间处理的复杂查询可以考虑采用流式Streaming响应先输出部分确定的结果或思考过程让用户感知到进度最后再给出完整答案。4.3 未来研究方向与应用展望“Reason Before You Retrieve”的范式正在快速演进我认为以下几个方向值得密切关注规划模型的专门化目前规划严重依赖通用大语言模型。未来可能会出现专门为任务规划和工具调用而微调Fine-tune或训练的“规划模型”它们在制定可靠、可执行计划方面会更强且成本更低。端到端的学习将整个智能体系统规划、检索、工具调用、合成视为一个可训练的整体通过强化学习或模仿学习进行端到端优化让系统自动学习如何制定最优计划而不是完全依赖LLM的零样本Zero-shot能力。更复杂的工具生态与组合未来的多模态智能体将能调用更多、更复杂的工具例如直接调用数据分析库处理检索到的表格调用代码解释器执行检索到的代码片段并返回结果甚至调用其他API或软件来完成跨平台任务。在垂直领域的深度应用在医疗领域智能体可以规划先检索医学影像再检索相关病历文本最后调用诊断模型进行辅助分析。在教育领域可以规划根据学生问题检索教科书文本、示意图、实验视频等多种材料组合成个性化讲解。在工业领域可以分析设备设计图、故障日志和维修手册辅助排查问题。从我个人的实践来看引入智能体化规划确实让多模态RAG系统从“能用”变得“好用”。它不再是一个脆弱的、只能回答简单事实性问题的玩具而开始像一个真正的、能够处理复杂、开放域问题的智能助手。虽然这条路还在早期基础设施和最佳实践仍在摸索中但它的潜力无疑是巨大的。对于开发者而言现在正是深入理解其原理并在具体场景中开始尝试和积累经验的好时机。