1. 项目概述当RAG学会“三思而后行”最近在搞多模态RAG检索增强生成项目的朋友估计都遇到过类似的头疼事你给系统一张产品图问“这个零件怎么安装”它可能从知识库里给你拽出一堆八竿子打不着的用户手册文本或者另一张完全不相关的结构图。问题出在哪传统RAG的“检索-生成”流水线在面对图像、音频、表格等非文本数据时常常表现得像个莽撞的新手——还没想清楚要什么就一头扎进向量数据库里乱翻。这正是“Reason Before You Retrieve: Agentic Planning for Multi-modal RAG”这个方向要解决的核心痛点。它不再是简单地把用户问题扔给检索器然后指望大模型去“圆”搜回来的结果。相反它引入了一个具备“规划”能力的智能体Agent让系统在动手检索之前先好好地“动脑筋”Reason一番。这个“动脑筋”的过程就是根据复杂的多模态查询动态规划出一条最优的检索路径先查什么查哪种类型的数据以什么粒度去查这些决策不再是预设的规则而是由智能体根据对任务和上下文的理解实时生成的。简单说它让RAG从“条件反射”进化到了“深思熟虑”。对于企业级知识库、复杂客服机器人、跨模态数据分析这些场景这种“先规划后检索”的智能体范式能显著提升答案的准确性、相关性和可解释性。如果你正在为多模态检索的精准度发愁或者想让你的RAG系统更“聪明”一点那么深入理解并实践Agentic Planning会是接下来必须啃下的硬骨头。2. 核心理念拆解为什么“先推理”如此关键要理解Agentic Planning的价值我们得先看看传统多模态RAG的短板在哪里。2.1 传统多模态RAG的“检索盲动症”在一个典型的多模态RAG系统中知识库可能包含文本文档、图片、PDF表格、音频片段等多种形式的数据。这些数据通常被分别处理文本切成片段并向量化图片通过CLIP等模型编码成向量表格可能被提取成结构化数据。当用户提出一个混合查询时比如“对比一下去年Q3的销售数据图表图A和上季度市场调研报告PDF中提到的客户满意度趋势”传统做法通常有两种暴力混合检索将用户查询同时丢给文本检索器和图像检索器各自返回Top-K个结果然后简单拼接在一起送给大模型去生成答案。这会导致信息过载和噪声干扰大模型可能被无关的图片或文本片段带偏。固定流程检索预设一个死板的流程例如“永远先检索文本再根据文本结果中的关键词检索相关图片”。这种一刀切的方法无法适应灵活多变的查询意图。如果用户的核心需求是解读图表先检索文本可能就是南辕北辙。这两种方法的共性问题在于检索动作与对查询的深度理解是脱节的。系统没有评估查询的复杂性没有分析不同模态数据在此次查询中的潜在作用和优先级就仓促执行检索相当于蒙着眼睛抓药效果自然难以保证。2.2 Agentic Planning为检索装上“决策大脑”Agentic Planning的核心思想是在检索器Retriever之前插入一个“规划智能体”Planning Agent。这个智能体的任务不是直接生成答案而是生成一个“检索计划”Retrieval Plan。你可以把它想象成一个经验丰富的侦探在开始搜查证据检索前先仔细分析案情用户查询制定一套周密的搜查方案。这个规划过程通常包含以下几个关键决策点查询分解与意图识别智能体首先会解析用户查询识别其中隐含的多个子问题或意图。例如“解释这张架构图并找出与文档描述不符的地方”可以分解为1) 理解架构图内容2) 检索相关技术文档3) 进行对比分析。模态选择与优先级排序针对每个子问题智能体决定需要检索哪种或哪几种模态的数据并确定优先级。对于“理解架构图”核心是检索类似的架构图或图示说明图像模态优先对于“检索相关文档”则是文本模态。检索粒度规划决定检索的细致程度。是检索整篇文档还是章节或是具体的段落和图片区域对于对比分析可能需要较粗的粒度来获取概览对于查找具体不符点则需要更精细的片段。依赖关系与执行顺序规划有些检索步骤可能存在依赖关系。例如可能需要先从图像中提取出关键术语如“微服务网关”再用这些术语作为关键词去检索文本这比直接用原始查询去检索文本更精准。智能体会规划这些步骤的执行顺序和依赖逻辑。这个由智能体动态生成的、结构化的“检索计划”才是后续多模态检索器执行的蓝图。它让每一次检索都变得目标明确、有的放矢。2.3 智能体与工具规划的执行基石要实现上述规划智能体需要具备两个核心能力思考Reasoning和使用工具Tool Use。思考能力通常由一个大语言模型LLM充当智能体的“大脑”。LLM根据系统指令如“你是一个检索规划专家”和用户查询通过链式思考Chain-of-Thought或更高级的推理框架逐步推导出检索计划。提示工程在这里至关重要我们需要设计精妙的提示词来引导LLM进行结构化输出例如要求它输出一个JSON格式的计划包含steps,modality,query_rewrite,dependencies等字段。工具使用能力智能体在规划时可能需要调用一些工具来辅助决策。例如调用一个“图像描述生成”工具来理解用户上传的图片内容从而生成更准确的文本检索关键词或者调用一个“查询分类器”工具来判断查询的主要意图。规划智能体本身并不执行检索但它可以通过调用工具来获取制定计划所需的信息。实操心得在初期搭建时不必追求一步到位的复杂规划。可以从最简单的“二分法”开始让智能体先判断当前查询是“以图为主”还是“以文为主”然后决定优先调用图像检索工具还是文本检索工具。这种单步决策能快速验证流程之后再逐步增加查询分解、多步规划等高级能力。3. 系统架构设计与核心组件一个完整的Agentic Planning for Multi-modal RAG系统其架构可以看作一个分层协作的流水线。下面我们自顶向下拆解。3.1 总体工作流与数据流系统的核心工作流可以概括为以下五个阶段用户查询接收与预处理系统接收用户输入的多模态查询如文本图片。预处理可能包括图像编码、语音转文本、文本清洗等为后续分析提供统一格式的输入。智能体规划阶段规划智能体LLM驱动对预处理后的查询进行分析。通过思考和使用工具生成一个结构化的检索计划。这个计划是一份“任务清单”。计划分发与执行阶段一个“计划执行器”组件接收这份清单。它根据计划中的每一步调用对应的工具即各种检索器。例如调用“向量数据库文本检索工具”传入改写后的查询词调用“图像相似性检索工具”传入图片编码向量。多模态检索与结果整合各个检索工具并行或按序执行从向量数据库或传统数据库中获取原始数据片段文本块、图片、表格行等。执行器将这些来自不同模态的、原始的检索结果收集起来。生成与呈现将所有检索到的上下文片段附上来源引用连同原始用户查询一起提交给答案生成器通常也是一个LLM。生成器综合所有信息生成最终的自然语言答案并可能以图文混合的形式呈现。整个过程中规划阶段是大脑执行器是四肢工具是手脚而多模态知识库是外部世界。3.2 规划智能体的内部构造规划智能体是系统的灵魂其设计有多种范式ReAct范式这是最经典的Agent框架之一Reason Act。智能体在“思考”和“行动”间循环。在规划场景下“思考”是分析查询、制定/调整计划“行动”是调用一个工具来获取信息如图片描述以辅助下一步思考。它适合需要与环境工具反馈动态交互的复杂规划。Plan-and-Execute范式智能体先利用其内部知识一次性生成整个多步计划Plan然后按部就班地执行Execute。这种模式结构清晰但缺乏在执行过程中根据中间结果调整计划的灵活性。Reflexion或Tree-of-Thoughts范式更高级的范式。智能体在规划时会生成多个可能的计划分支像一棵树然后通过自我评估或模拟执行选择最优路径。这能显著提升复杂规划的可靠性但计算开销也更大。对于大多数多模态RAG场景采用ReAct范式是一个稳健的起点。它平衡了灵活性和复杂度。一个典型的ReAct循环提示词模板可能如下你是一个多模态检索规划师。你的任务是为用户查询制定一个高效的检索计划。 你可以使用的工具包括[图像描述工具]、[文本检索工具]、[图像检索工具]。 当前查询是{用户查询} 历史步骤和观察如果是首次则为空{历史} 请按以下格式回应 思考你分析查询、决定下一步该如何做的推理过程 行动要调用的工具名称输入应为JSON格式如{tool: 图像描述工具, input: 图片ID} 或 {tool: 文本检索工具, input: 检索关键词} 3.3 多模态工具集的构建工具是智能体与知识库交互的桥梁。每个工具都应被封装成具有明确定义输入输出的函数并通过工具描述如函数名、参数说明暴露给智能体。核心工具通常包括文本检索工具封装对向量数据库如Milvus, Pinecone或全文搜索引擎如Elasticsearch的调用。输入是文本查询输出是相关的文本片段列表。图像检索工具封装对图像向量数据库的调用。输入可以是图片的编码向量也可以是由LLM生成的、描述图片内容的文本再通过文本编码模型转为向量。输出是相似的图片及其元数据。跨模态理解工具图像描述工具调用视觉-语言模型如GPT-4V, LLaVA将用户上传的图片或检索到的图片转化为详细的文本描述供文本检索使用。表格解析工具从PDF或图片中提取表格数据并将其结构化为JSON或Markdown格式便于LLM理解。查询改写/扩展工具基于对话历史和当前查询生成更优的检索关键词。这是一个纯文本工具但对提升召回率至关重要。注意事项工具的描述信息必须清晰准确。智能体完全依赖这些描述来选择工具。模糊的描述会导致智能体调用错误。例如“图像检索工具”的描述应明确说明它接受的是“图片文件的base64编码”还是“图片的CLIP向量”。3.4 知识库的底层支持无论规划多么巧妙最终都离不开高质量的多模态知识库。这要求底层数据管道必须扎实分模态处理管道文本需要高质量的切片Chunking策略。对于技术文档按章节或子标题切分比固定长度滑动窗口更有效。切片时需保留层级信息。图像关键是为每张图片生成高质量的文本描述Alt-Text和向量表示。可以使用BLIP、CLIP等模型。描述应尽可能包含图中关键物体、文字、关系和上下文。表格/PDF使用OCR如PaddleOCR提取文字并用专用解析库如Camelot, Tabula提取表格结构。将提取出的结构化数据以清晰格式如Markdown表格存储并生成摘要性描述。向量化与索引不同模态的数据应使用各自领域最优的嵌入模型如text-embedding-3-small用于文本CLIP-ViT用于图像并存入支持多向量检索的数据库。更先进的方案是为同一数据实体建立多模态的联合索引。4. 实战构建从零搭建一个简易系统理论说了这么多我们动手搭建一个具备基础规划能力的多模态RAG原型。我们将使用LangChain作为Agent框架Milvus作为向量数据库OpenAI的GPT-4系列作为LLM和嵌入模型。4.1 环境准备与依赖安装首先确保你的Python环境建议3.9并安装核心库。pip install langchain langchain-openai langchain-community pymilvus pillow requests此外你需要一个可用的OpenAI API密钥。一个运行中的Milvus实例可通过Docker快速搭建。4.2 构建多模态知识库假设我们有一个产品知识库包含产品手册文本和产品示意图图片。步骤1文本处理与入库from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Milvus # 1. 加载文本 loader TextLoader(product_manual.txt) documents loader.load() # 2. 智能切分按章节分割是更优策略此处简化 text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) texts text_splitter.split_documents(documents) # 3. 向量化并存入Milvus embeddings OpenAIEmbeddings(modeltext-embedding-3-small, openai_api_keyyour_key) vector_store_text Milvus.from_documents( texts, embeddings, connection_args{host: localhost, port: 19530}, collection_nameproduct_manual_text )步骤2图像处理与入库这里我们需要为每张图片生成描述和向量。由于LangChain对多模态的原生支持在演进中我们可能需要更底层的操作。import base64 from PIL import Image import requests from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType # 连接Milvus connections.connect(hostlocalhost, port19530) # 定义图片集合Schema fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nameimage_vector, dtypeDataType.FLOAT_VECTOR, dim512), # CLIP向量维度 FieldSchema(nameimage_path, dtypeDataType.VARCHAR, max_length255), FieldSchema(namedescription, dtypeDataType.VARCHAR, max_length1000), # 图片文本描述 ] schema CollectionSchema(fields, descriptionProduct images collection) collection_img Collection(product_images, schema) # 创建索引 index_params { index_type: IVF_FLAT, metric_type: L2, params: {nlist: 128} } collection_img.create_index(image_vector, index_params) # 处理单张图片的函数 def process_and_insert_image(image_path): # 1. 编码图片为base64用于GPT-4V生成描述 with open(image_path, rb) as img_file: base64_image base64.b64encode(img_file.read()).decode(utf-8) # 2. 调用GPT-4V生成详细描述 headers { Content-Type: application/json, Authorization: fBearer {openai_api_key} } payload { model: gpt-4-vision-preview, messages: [ { role: user, content: [ {type: text, text: 请详细描述这张图片中的所有关键信息包括物体、文字、布局和可能的功能。}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{base64_image}}} ] } ], max_tokens: 300 } response requests.post(https://api.openai.com/v1/chat/completions, headersheaders, jsonpayload) description response.json()[choices][0][message][content] # 3. 使用CLIP模型生成图片向量 (此处需假设有CLIP模型API或本地服务) # 伪代码image_vector clip_model.encode_image(image_path) # 为简化我们假设有一个服务端点 clip_response requests.post(http://localhost:5000/clip_encode, json{image_path: image_path}) image_vector clip_response.json()[vector] # 4. 插入Milvus data [ [image_vector], # 注意维度匹配 [image_path], [description] ] collection_img.insert(data) print(fInserted {image_path} with description: {description[:100]}...) # 批量处理图片 for img_path in [product_diagram_1.jpg, product_photo_2.png]: process_and_insert_image(img_path) collection_img.load()4.3 定义智能体可用的工具我们将文本检索和图像检索封装成LangChain工具。from langchain.tools import tool from langchain_community.vectorstores import Milvus from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings(modeltext-embedding-3-small, openai_api_keyyour_key) # 连接到已有的文本集合 text_retriever Milvus( embedding_functionembeddings, connection_args{host: localhost, port: 19530}, collection_nameproduct_manual_text ).as_retriever(search_kwargs{k: 3}) # 工具1文本检索工具 tool def retrieve_text(query: str) - str: 根据输入的问题检索相关的产品手册文本片段。输入应为清晰的问题或关键词。 docs text_retriever.invoke(query) return \n\n.join([doc.page_content for doc in docs]) # 工具2图像检索工具通过描述检索 tool def retrieve_image_by_description(description_query: str) - str: 根据对图片的文字描述检索最相似的产品图片及其描述。输入应是对想找的图片的文字描述。 # 这里简化将描述文本向量化然后在图片向量库中搜索 query_vector embeddings.embed_query(description_query) # 伪代码通过Milvus SDK搜索相似图片向量 search_params {metric_type: L2, params: {nprobe: 10}} results collection_img.search( data[query_vector], anns_fieldimage_vector, paramsearch_params, limit2, output_fields[image_path, description] ) formatted_results [] for hits in results: for hit in hits: formatted_results.append(f图片路径: {hit.entity.get(image_path)}, 描述: {hit.entity.get(description)}) return \n.join(formatted_results) # 工具3图像描述生成工具 tool def describe_image(image_url_or_path: str) - str: 详细描述一张图片的内容。输入可以是图片的本地路径或可公开访问的URL。 # 此处调用本地或云端的VLM模型为简化我们返回一个模拟描述 # 实际应调用类似上面的GPT-4V代码 return f[模拟] 图片 {image_url_or_path} 的描述图中显示了一个产品的三维爆炸图包含部件A、B、C标注了安装顺序。4.4 组装规划智能体并运行使用LangChain的ReAct框架创建智能体。from langchain import hub from langchain.agents import create_react_agent, AgentExecutor from langchain_openai import ChatOpenAI # 拉取一个标准的ReAct提示模板 prompt hub.pull(hwchase17/react) # 初始化LLM llm ChatOpenAI(modelgpt-4-turbo, temperature0, openai_api_keyyour_key) # 定义工具列表 tools [retrieve_text, retrieve_image_by_description, describe_image] # 创建智能体 agent create_react_agent(llm, tools, prompt) # 创建执行器 agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 测试一个多模态查询 query 用户上传了一张产品局部图片路径user_upload_part.jpg他想知道这个部件在手册的哪个章节有说明并且有没有更清晰的安装示意图 result agent_executor.invoke({input: query}) print(result[output])在这个例子中一个规划良好的智能体可能会执行以下步骤思考用户需要两样东西1) 文本手册中对应部件的说明2) 更清晰的示意图。我需要先理解用户图片的内容。行动调用describe_image工具输入user_upload_part.jpg获取描述。思考根据描述“一个圆柱形连接器带有红色卡扣”我需要从文本手册中查找关于“圆柱形连接器”和“红色卡扣”的说明。行动调用retrieve_text工具输入“圆柱形连接器 红色卡扣 安装”。思考从检索到的文本中我看到了部件编号“XC-205”。现在我需要找这个部件的清晰示意图。行动调用retrieve_image_by_description工具输入“XC-205 部件 清晰示意图 爆炸图”。思考我获得了文本片段和相关的图片信息。现在可以综合这些信息来回答用户了。最终输出组织语言引用检索到的文本和图片信息生成最终答案。5. 高级策略与优化方向当基础系统跑通后可以从以下几个方向进行深度优化以应对更复杂的工业级场景。5.1 动态查询改写与路由规划智能体生成的“检索计划”中最关键的一环是决定“用什么query去检索”。简单的查询传递往往不够。基于上下文的查询改写智能体在规划时可以利用对话历史、已检索到的信息来动态改写查询。例如当用户问“这个怎么用”而对话历史显示之前正在讨论“部件A”那么智能体应自动将查询改写为“部件A的使用方法”。查询路由智能体可以作为一个路由器判断查询更适合用关键词检索稀疏检索还是语义检索稠密检索或者需要进行混合检索。这可以通过调用不同的检索工具来实现。5.2 迭代式检索与重规划首次检索的结果可能不理想。高级的Agentic Planning应支持迭代优化。自我评估与反馈在获得初步检索结果后智能体可以调用一个“相关性评估”工具可以是另一个LLM判断结果是否充分回答了子问题。如果不够则基于当前结果生成新的、更精确的查询进行第二轮检索。重规划当执行某一步骤失败如工具返回空结果或发现新的信息时智能体应能动态调整后续计划。这需要ReAct范式或更复杂的Reflexion范式的支持。5.3 多模态结果的融合与重排序检索回来的文本、图片等是原始的、离散的片段。直接扔给生成模型可能效果不佳。跨模态关联对齐智能体在规划时可以记录不同检索步骤结果之间的潜在关联。例如“步骤2检索到的图片对应步骤1检索到的文本中的Figure 3”。在最终整合上下文时将这些关联信息一并提供给生成模型。重排序将所有检索结果无论模态合并成一个列表使用一个“重排序模型”根据与原始查询的整体相关性进行重新排序。这能确保最相关的信息排在前面减轻生成模型的负担。5.4 评估与持续改进如何衡量Agentic Planning的有效性需要建立多维度的评估体系。规划质量评估评估生成的检索计划本身是否合理。可以人工标注或使用LLM作为裁判根据计划与查询的匹配度打分。端到端效果评估检索指标考察最终提供给生成模型的上下文集合的召回率Recall和准确率Precision。生成指标使用RAGAS、TruLens等框架评估最终答案的忠实度是否基于提供的上下文、答案相关性和上下文利用率。持续学习收集失败的查询案例如低分回答分析是规划阶段、检索阶段还是生成阶段的问题。针对规划问题可以将其作为few-shot示例加入智能体的提示词中让它学习更优的规划策略。6. 避坑指南与常见问题在实际开发和部署过程中我踩过不少坑这里总结几个最关键的问题和解决方案。6.1 智能体“幻觉”与规划失控这是最常见的问题。智能体可能制定出逻辑混乱、无限循环或调用不存在工具的计划。根因提示词指令不清晰LLM的推理能力不足或温度参数过高工具描述模糊。解决方案强化系统提示词在提示词中明确约束例如“你必须且只能使用提供的工具”、“如果工具返回空结果请尝试换一种问法重新检索不要轻易放弃”、“规划步骤不超过5步”。使用更强的基础模型在规划任务上GPT-4通常比GPT-3.5稳定得多。如果成本允许规划智能体应使用能力最强的模型。设计工具熔断机制在执行器中监控工具调用频率。如果智能体在短时间内反复调用同一工具且无进展强制中断并返回特定错误信息引导智能体改变策略。6.2 多模态数据对齐与表征不一致文本检索用OpenAI的嵌入图片检索用CLIP的嵌入这两种向量不在同一个语义空间导致跨模态关联困难。根因不同模态使用独立的编码模型。解决方案使用统一的多模态模型如ImageBind、ONE-PEACE等模型能将图像、文本、音频等映射到同一个向量空间从根本上解决对齐问题。但目前这类模型的成熟度和易用性还在发展中。桥接层训练一个轻量的“对齐网络”学习将一种模态的向量转换到另一种模态的向量空间附近。这需要额外的标注数据。依赖文本描述这是当前最实用的方法。将所有非文本数据图片、音频通过VLM/AudioLM模型转化为高质量的文本描述。这样所有检索在“文本描述”这个层面实现统一。虽然会损失一些非文本的细粒度信息但大大简化了系统复杂度。6.3 系统延迟与成本激增Agentic Planning引入了额外的LLM调用用于规划和可能的多轮工具调用延迟和API成本显著增加。根因规划步骤复杂每次工具调用都可能涉及LLM或昂贵的外部API。解决方案规划缓存对于常见或相似的查询缓存其生成的检索计划。下次遇到类似查询时可以直接复用计划跳过规划步骤。异步与并行执行分析检索计划中的步骤依赖关系。对于没有依赖关系的步骤如同时检索文本和图片让执行器并行调用工具缩短整体耗时。模型分级对于简单的、模式固定的查询可以设置一个“快速通道”绕过复杂的智能体规划直接使用规则或更简单的模型进行检索。只有复杂查询才走完整的Agentic Planning流程。本地小模型对于描述生成、查询改写等任务可以尝试使用开源的、参数较小的VLM或LLM如LLaVA, Qwen-VL部署在本地以控制成本。6.4 检索结果冲突与信息过载当从不同来源检索到相互矛盾的信息时生成模型可能产生混淆。根因知识库中存在过期或冲突的信息不同模态的信息表述角度不同。解决方案来源元数据与置信度为知识库中的每一条数据添加来源、版本和置信度可信度标签。智能体在规划时可以优先检索高置信度的来源。生成模型在回答时也可以引用来源让用户自行判断。冲突检测与消解在结果整合阶段可以加入一个“冲突检测”步骤。使用LLM分析不同片段之间是否存在事实矛盾。如果存在则在上下文中明确指出“关于XX检索到两种说法A... B...”让生成模型以更谨慎的方式回答或者直接提示用户信息存在冲突。信息摘要与过滤在将大量检索结果送给生成模型前先让一个LLM对其进行摘要和去重只保留最核心、最不重复的信息点。这能有效减轻上下文长度压力并减少噪声。构建一个真正智能的、先推理后检索的多模态RAG系统是一个将Agent思想与信息检索技术深度融合的过程。它没有银弹需要根据具体的业务场景、数据形态和性能要求进行精细化的设计和调优。从最简单的单步决策智能体开始逐步迭代增加其规划能力并持续关注规划质量、系统延迟和答案的忠实度是通往成功最实际的路径。这个领域仍在快速演进新的模型、框架和思想不断涌现保持学习与实验的心态至关重要。 多模态RAG的Agentic Planning：让检索增强生成系统先推理后行动
1. 项目概述当RAG学会“三思而后行”最近在搞多模态RAG检索增强生成项目的朋友估计都遇到过类似的头疼事你给系统一张产品图问“这个零件怎么安装”它可能从知识库里给你拽出一堆八竿子打不着的用户手册文本或者另一张完全不相关的结构图。问题出在哪传统RAG的“检索-生成”流水线在面对图像、音频、表格等非文本数据时常常表现得像个莽撞的新手——还没想清楚要什么就一头扎进向量数据库里乱翻。这正是“Reason Before You Retrieve: Agentic Planning for Multi-modal RAG”这个方向要解决的核心痛点。它不再是简单地把用户问题扔给检索器然后指望大模型去“圆”搜回来的结果。相反它引入了一个具备“规划”能力的智能体Agent让系统在动手检索之前先好好地“动脑筋”Reason一番。这个“动脑筋”的过程就是根据复杂的多模态查询动态规划出一条最优的检索路径先查什么查哪种类型的数据以什么粒度去查这些决策不再是预设的规则而是由智能体根据对任务和上下文的理解实时生成的。简单说它让RAG从“条件反射”进化到了“深思熟虑”。对于企业级知识库、复杂客服机器人、跨模态数据分析这些场景这种“先规划后检索”的智能体范式能显著提升答案的准确性、相关性和可解释性。如果你正在为多模态检索的精准度发愁或者想让你的RAG系统更“聪明”一点那么深入理解并实践Agentic Planning会是接下来必须啃下的硬骨头。2. 核心理念拆解为什么“先推理”如此关键要理解Agentic Planning的价值我们得先看看传统多模态RAG的短板在哪里。2.1 传统多模态RAG的“检索盲动症”在一个典型的多模态RAG系统中知识库可能包含文本文档、图片、PDF表格、音频片段等多种形式的数据。这些数据通常被分别处理文本切成片段并向量化图片通过CLIP等模型编码成向量表格可能被提取成结构化数据。当用户提出一个混合查询时比如“对比一下去年Q3的销售数据图表图A和上季度市场调研报告PDF中提到的客户满意度趋势”传统做法通常有两种暴力混合检索将用户查询同时丢给文本检索器和图像检索器各自返回Top-K个结果然后简单拼接在一起送给大模型去生成答案。这会导致信息过载和噪声干扰大模型可能被无关的图片或文本片段带偏。固定流程检索预设一个死板的流程例如“永远先检索文本再根据文本结果中的关键词检索相关图片”。这种一刀切的方法无法适应灵活多变的查询意图。如果用户的核心需求是解读图表先检索文本可能就是南辕北辙。这两种方法的共性问题在于检索动作与对查询的深度理解是脱节的。系统没有评估查询的复杂性没有分析不同模态数据在此次查询中的潜在作用和优先级就仓促执行检索相当于蒙着眼睛抓药效果自然难以保证。2.2 Agentic Planning为检索装上“决策大脑”Agentic Planning的核心思想是在检索器Retriever之前插入一个“规划智能体”Planning Agent。这个智能体的任务不是直接生成答案而是生成一个“检索计划”Retrieval Plan。你可以把它想象成一个经验丰富的侦探在开始搜查证据检索前先仔细分析案情用户查询制定一套周密的搜查方案。这个规划过程通常包含以下几个关键决策点查询分解与意图识别智能体首先会解析用户查询识别其中隐含的多个子问题或意图。例如“解释这张架构图并找出与文档描述不符的地方”可以分解为1) 理解架构图内容2) 检索相关技术文档3) 进行对比分析。模态选择与优先级排序针对每个子问题智能体决定需要检索哪种或哪几种模态的数据并确定优先级。对于“理解架构图”核心是检索类似的架构图或图示说明图像模态优先对于“检索相关文档”则是文本模态。检索粒度规划决定检索的细致程度。是检索整篇文档还是章节或是具体的段落和图片区域对于对比分析可能需要较粗的粒度来获取概览对于查找具体不符点则需要更精细的片段。依赖关系与执行顺序规划有些检索步骤可能存在依赖关系。例如可能需要先从图像中提取出关键术语如“微服务网关”再用这些术语作为关键词去检索文本这比直接用原始查询去检索文本更精准。智能体会规划这些步骤的执行顺序和依赖逻辑。这个由智能体动态生成的、结构化的“检索计划”才是后续多模态检索器执行的蓝图。它让每一次检索都变得目标明确、有的放矢。2.3 智能体与工具规划的执行基石要实现上述规划智能体需要具备两个核心能力思考Reasoning和使用工具Tool Use。思考能力通常由一个大语言模型LLM充当智能体的“大脑”。LLM根据系统指令如“你是一个检索规划专家”和用户查询通过链式思考Chain-of-Thought或更高级的推理框架逐步推导出检索计划。提示工程在这里至关重要我们需要设计精妙的提示词来引导LLM进行结构化输出例如要求它输出一个JSON格式的计划包含steps,modality,query_rewrite,dependencies等字段。工具使用能力智能体在规划时可能需要调用一些工具来辅助决策。例如调用一个“图像描述生成”工具来理解用户上传的图片内容从而生成更准确的文本检索关键词或者调用一个“查询分类器”工具来判断查询的主要意图。规划智能体本身并不执行检索但它可以通过调用工具来获取制定计划所需的信息。实操心得在初期搭建时不必追求一步到位的复杂规划。可以从最简单的“二分法”开始让智能体先判断当前查询是“以图为主”还是“以文为主”然后决定优先调用图像检索工具还是文本检索工具。这种单步决策能快速验证流程之后再逐步增加查询分解、多步规划等高级能力。3. 系统架构设计与核心组件一个完整的Agentic Planning for Multi-modal RAG系统其架构可以看作一个分层协作的流水线。下面我们自顶向下拆解。3.1 总体工作流与数据流系统的核心工作流可以概括为以下五个阶段用户查询接收与预处理系统接收用户输入的多模态查询如文本图片。预处理可能包括图像编码、语音转文本、文本清洗等为后续分析提供统一格式的输入。智能体规划阶段规划智能体LLM驱动对预处理后的查询进行分析。通过思考和使用工具生成一个结构化的检索计划。这个计划是一份“任务清单”。计划分发与执行阶段一个“计划执行器”组件接收这份清单。它根据计划中的每一步调用对应的工具即各种检索器。例如调用“向量数据库文本检索工具”传入改写后的查询词调用“图像相似性检索工具”传入图片编码向量。多模态检索与结果整合各个检索工具并行或按序执行从向量数据库或传统数据库中获取原始数据片段文本块、图片、表格行等。执行器将这些来自不同模态的、原始的检索结果收集起来。生成与呈现将所有检索到的上下文片段附上来源引用连同原始用户查询一起提交给答案生成器通常也是一个LLM。生成器综合所有信息生成最终的自然语言答案并可能以图文混合的形式呈现。整个过程中规划阶段是大脑执行器是四肢工具是手脚而多模态知识库是外部世界。3.2 规划智能体的内部构造规划智能体是系统的灵魂其设计有多种范式ReAct范式这是最经典的Agent框架之一Reason Act。智能体在“思考”和“行动”间循环。在规划场景下“思考”是分析查询、制定/调整计划“行动”是调用一个工具来获取信息如图片描述以辅助下一步思考。它适合需要与环境工具反馈动态交互的复杂规划。Plan-and-Execute范式智能体先利用其内部知识一次性生成整个多步计划Plan然后按部就班地执行Execute。这种模式结构清晰但缺乏在执行过程中根据中间结果调整计划的灵活性。Reflexion或Tree-of-Thoughts范式更高级的范式。智能体在规划时会生成多个可能的计划分支像一棵树然后通过自我评估或模拟执行选择最优路径。这能显著提升复杂规划的可靠性但计算开销也更大。对于大多数多模态RAG场景采用ReAct范式是一个稳健的起点。它平衡了灵活性和复杂度。一个典型的ReAct循环提示词模板可能如下你是一个多模态检索规划师。你的任务是为用户查询制定一个高效的检索计划。 你可以使用的工具包括[图像描述工具]、[文本检索工具]、[图像检索工具]。 当前查询是{用户查询} 历史步骤和观察如果是首次则为空{历史} 请按以下格式回应 思考你分析查询、决定下一步该如何做的推理过程 行动要调用的工具名称输入应为JSON格式如{tool: 图像描述工具, input: 图片ID} 或 {tool: 文本检索工具, input: 检索关键词} 3.3 多模态工具集的构建工具是智能体与知识库交互的桥梁。每个工具都应被封装成具有明确定义输入输出的函数并通过工具描述如函数名、参数说明暴露给智能体。核心工具通常包括文本检索工具封装对向量数据库如Milvus, Pinecone或全文搜索引擎如Elasticsearch的调用。输入是文本查询输出是相关的文本片段列表。图像检索工具封装对图像向量数据库的调用。输入可以是图片的编码向量也可以是由LLM生成的、描述图片内容的文本再通过文本编码模型转为向量。输出是相似的图片及其元数据。跨模态理解工具图像描述工具调用视觉-语言模型如GPT-4V, LLaVA将用户上传的图片或检索到的图片转化为详细的文本描述供文本检索使用。表格解析工具从PDF或图片中提取表格数据并将其结构化为JSON或Markdown格式便于LLM理解。查询改写/扩展工具基于对话历史和当前查询生成更优的检索关键词。这是一个纯文本工具但对提升召回率至关重要。注意事项工具的描述信息必须清晰准确。智能体完全依赖这些描述来选择工具。模糊的描述会导致智能体调用错误。例如“图像检索工具”的描述应明确说明它接受的是“图片文件的base64编码”还是“图片的CLIP向量”。3.4 知识库的底层支持无论规划多么巧妙最终都离不开高质量的多模态知识库。这要求底层数据管道必须扎实分模态处理管道文本需要高质量的切片Chunking策略。对于技术文档按章节或子标题切分比固定长度滑动窗口更有效。切片时需保留层级信息。图像关键是为每张图片生成高质量的文本描述Alt-Text和向量表示。可以使用BLIP、CLIP等模型。描述应尽可能包含图中关键物体、文字、关系和上下文。表格/PDF使用OCR如PaddleOCR提取文字并用专用解析库如Camelot, Tabula提取表格结构。将提取出的结构化数据以清晰格式如Markdown表格存储并生成摘要性描述。向量化与索引不同模态的数据应使用各自领域最优的嵌入模型如text-embedding-3-small用于文本CLIP-ViT用于图像并存入支持多向量检索的数据库。更先进的方案是为同一数据实体建立多模态的联合索引。4. 实战构建从零搭建一个简易系统理论说了这么多我们动手搭建一个具备基础规划能力的多模态RAG原型。我们将使用LangChain作为Agent框架Milvus作为向量数据库OpenAI的GPT-4系列作为LLM和嵌入模型。4.1 环境准备与依赖安装首先确保你的Python环境建议3.9并安装核心库。pip install langchain langchain-openai langchain-community pymilvus pillow requests此外你需要一个可用的OpenAI API密钥。一个运行中的Milvus实例可通过Docker快速搭建。4.2 构建多模态知识库假设我们有一个产品知识库包含产品手册文本和产品示意图图片。步骤1文本处理与入库from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Milvus # 1. 加载文本 loader TextLoader(product_manual.txt) documents loader.load() # 2. 智能切分按章节分割是更优策略此处简化 text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) texts text_splitter.split_documents(documents) # 3. 向量化并存入Milvus embeddings OpenAIEmbeddings(modeltext-embedding-3-small, openai_api_keyyour_key) vector_store_text Milvus.from_documents( texts, embeddings, connection_args{host: localhost, port: 19530}, collection_nameproduct_manual_text )步骤2图像处理与入库这里我们需要为每张图片生成描述和向量。由于LangChain对多模态的原生支持在演进中我们可能需要更底层的操作。import base64 from PIL import Image import requests from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType # 连接Milvus connections.connect(hostlocalhost, port19530) # 定义图片集合Schema fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nameimage_vector, dtypeDataType.FLOAT_VECTOR, dim512), # CLIP向量维度 FieldSchema(nameimage_path, dtypeDataType.VARCHAR, max_length255), FieldSchema(namedescription, dtypeDataType.VARCHAR, max_length1000), # 图片文本描述 ] schema CollectionSchema(fields, descriptionProduct images collection) collection_img Collection(product_images, schema) # 创建索引 index_params { index_type: IVF_FLAT, metric_type: L2, params: {nlist: 128} } collection_img.create_index(image_vector, index_params) # 处理单张图片的函数 def process_and_insert_image(image_path): # 1. 编码图片为base64用于GPT-4V生成描述 with open(image_path, rb) as img_file: base64_image base64.b64encode(img_file.read()).decode(utf-8) # 2. 调用GPT-4V生成详细描述 headers { Content-Type: application/json, Authorization: fBearer {openai_api_key} } payload { model: gpt-4-vision-preview, messages: [ { role: user, content: [ {type: text, text: 请详细描述这张图片中的所有关键信息包括物体、文字、布局和可能的功能。}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{base64_image}}} ] } ], max_tokens: 300 } response requests.post(https://api.openai.com/v1/chat/completions, headersheaders, jsonpayload) description response.json()[choices][0][message][content] # 3. 使用CLIP模型生成图片向量 (此处需假设有CLIP模型API或本地服务) # 伪代码image_vector clip_model.encode_image(image_path) # 为简化我们假设有一个服务端点 clip_response requests.post(http://localhost:5000/clip_encode, json{image_path: image_path}) image_vector clip_response.json()[vector] # 4. 插入Milvus data [ [image_vector], # 注意维度匹配 [image_path], [description] ] collection_img.insert(data) print(fInserted {image_path} with description: {description[:100]}...) # 批量处理图片 for img_path in [product_diagram_1.jpg, product_photo_2.png]: process_and_insert_image(img_path) collection_img.load()4.3 定义智能体可用的工具我们将文本检索和图像检索封装成LangChain工具。from langchain.tools import tool from langchain_community.vectorstores import Milvus from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings(modeltext-embedding-3-small, openai_api_keyyour_key) # 连接到已有的文本集合 text_retriever Milvus( embedding_functionembeddings, connection_args{host: localhost, port: 19530}, collection_nameproduct_manual_text ).as_retriever(search_kwargs{k: 3}) # 工具1文本检索工具 tool def retrieve_text(query: str) - str: 根据输入的问题检索相关的产品手册文本片段。输入应为清晰的问题或关键词。 docs text_retriever.invoke(query) return \n\n.join([doc.page_content for doc in docs]) # 工具2图像检索工具通过描述检索 tool def retrieve_image_by_description(description_query: str) - str: 根据对图片的文字描述检索最相似的产品图片及其描述。输入应是对想找的图片的文字描述。 # 这里简化将描述文本向量化然后在图片向量库中搜索 query_vector embeddings.embed_query(description_query) # 伪代码通过Milvus SDK搜索相似图片向量 search_params {metric_type: L2, params: {nprobe: 10}} results collection_img.search( data[query_vector], anns_fieldimage_vector, paramsearch_params, limit2, output_fields[image_path, description] ) formatted_results [] for hits in results: for hit in hits: formatted_results.append(f图片路径: {hit.entity.get(image_path)}, 描述: {hit.entity.get(description)}) return \n.join(formatted_results) # 工具3图像描述生成工具 tool def describe_image(image_url_or_path: str) - str: 详细描述一张图片的内容。输入可以是图片的本地路径或可公开访问的URL。 # 此处调用本地或云端的VLM模型为简化我们返回一个模拟描述 # 实际应调用类似上面的GPT-4V代码 return f[模拟] 图片 {image_url_or_path} 的描述图中显示了一个产品的三维爆炸图包含部件A、B、C标注了安装顺序。4.4 组装规划智能体并运行使用LangChain的ReAct框架创建智能体。from langchain import hub from langchain.agents import create_react_agent, AgentExecutor from langchain_openai import ChatOpenAI # 拉取一个标准的ReAct提示模板 prompt hub.pull(hwchase17/react) # 初始化LLM llm ChatOpenAI(modelgpt-4-turbo, temperature0, openai_api_keyyour_key) # 定义工具列表 tools [retrieve_text, retrieve_image_by_description, describe_image] # 创建智能体 agent create_react_agent(llm, tools, prompt) # 创建执行器 agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 测试一个多模态查询 query 用户上传了一张产品局部图片路径user_upload_part.jpg他想知道这个部件在手册的哪个章节有说明并且有没有更清晰的安装示意图 result agent_executor.invoke({input: query}) print(result[output])在这个例子中一个规划良好的智能体可能会执行以下步骤思考用户需要两样东西1) 文本手册中对应部件的说明2) 更清晰的示意图。我需要先理解用户图片的内容。行动调用describe_image工具输入user_upload_part.jpg获取描述。思考根据描述“一个圆柱形连接器带有红色卡扣”我需要从文本手册中查找关于“圆柱形连接器”和“红色卡扣”的说明。行动调用retrieve_text工具输入“圆柱形连接器 红色卡扣 安装”。思考从检索到的文本中我看到了部件编号“XC-205”。现在我需要找这个部件的清晰示意图。行动调用retrieve_image_by_description工具输入“XC-205 部件 清晰示意图 爆炸图”。思考我获得了文本片段和相关的图片信息。现在可以综合这些信息来回答用户了。最终输出组织语言引用检索到的文本和图片信息生成最终答案。5. 高级策略与优化方向当基础系统跑通后可以从以下几个方向进行深度优化以应对更复杂的工业级场景。5.1 动态查询改写与路由规划智能体生成的“检索计划”中最关键的一环是决定“用什么query去检索”。简单的查询传递往往不够。基于上下文的查询改写智能体在规划时可以利用对话历史、已检索到的信息来动态改写查询。例如当用户问“这个怎么用”而对话历史显示之前正在讨论“部件A”那么智能体应自动将查询改写为“部件A的使用方法”。查询路由智能体可以作为一个路由器判断查询更适合用关键词检索稀疏检索还是语义检索稠密检索或者需要进行混合检索。这可以通过调用不同的检索工具来实现。5.2 迭代式检索与重规划首次检索的结果可能不理想。高级的Agentic Planning应支持迭代优化。自我评估与反馈在获得初步检索结果后智能体可以调用一个“相关性评估”工具可以是另一个LLM判断结果是否充分回答了子问题。如果不够则基于当前结果生成新的、更精确的查询进行第二轮检索。重规划当执行某一步骤失败如工具返回空结果或发现新的信息时智能体应能动态调整后续计划。这需要ReAct范式或更复杂的Reflexion范式的支持。5.3 多模态结果的融合与重排序检索回来的文本、图片等是原始的、离散的片段。直接扔给生成模型可能效果不佳。跨模态关联对齐智能体在规划时可以记录不同检索步骤结果之间的潜在关联。例如“步骤2检索到的图片对应步骤1检索到的文本中的Figure 3”。在最终整合上下文时将这些关联信息一并提供给生成模型。重排序将所有检索结果无论模态合并成一个列表使用一个“重排序模型”根据与原始查询的整体相关性进行重新排序。这能确保最相关的信息排在前面减轻生成模型的负担。5.4 评估与持续改进如何衡量Agentic Planning的有效性需要建立多维度的评估体系。规划质量评估评估生成的检索计划本身是否合理。可以人工标注或使用LLM作为裁判根据计划与查询的匹配度打分。端到端效果评估检索指标考察最终提供给生成模型的上下文集合的召回率Recall和准确率Precision。生成指标使用RAGAS、TruLens等框架评估最终答案的忠实度是否基于提供的上下文、答案相关性和上下文利用率。持续学习收集失败的查询案例如低分回答分析是规划阶段、检索阶段还是生成阶段的问题。针对规划问题可以将其作为few-shot示例加入智能体的提示词中让它学习更优的规划策略。6. 避坑指南与常见问题在实际开发和部署过程中我踩过不少坑这里总结几个最关键的问题和解决方案。6.1 智能体“幻觉”与规划失控这是最常见的问题。智能体可能制定出逻辑混乱、无限循环或调用不存在工具的计划。根因提示词指令不清晰LLM的推理能力不足或温度参数过高工具描述模糊。解决方案强化系统提示词在提示词中明确约束例如“你必须且只能使用提供的工具”、“如果工具返回空结果请尝试换一种问法重新检索不要轻易放弃”、“规划步骤不超过5步”。使用更强的基础模型在规划任务上GPT-4通常比GPT-3.5稳定得多。如果成本允许规划智能体应使用能力最强的模型。设计工具熔断机制在执行器中监控工具调用频率。如果智能体在短时间内反复调用同一工具且无进展强制中断并返回特定错误信息引导智能体改变策略。6.2 多模态数据对齐与表征不一致文本检索用OpenAI的嵌入图片检索用CLIP的嵌入这两种向量不在同一个语义空间导致跨模态关联困难。根因不同模态使用独立的编码模型。解决方案使用统一的多模态模型如ImageBind、ONE-PEACE等模型能将图像、文本、音频等映射到同一个向量空间从根本上解决对齐问题。但目前这类模型的成熟度和易用性还在发展中。桥接层训练一个轻量的“对齐网络”学习将一种模态的向量转换到另一种模态的向量空间附近。这需要额外的标注数据。依赖文本描述这是当前最实用的方法。将所有非文本数据图片、音频通过VLM/AudioLM模型转化为高质量的文本描述。这样所有检索在“文本描述”这个层面实现统一。虽然会损失一些非文本的细粒度信息但大大简化了系统复杂度。6.3 系统延迟与成本激增Agentic Planning引入了额外的LLM调用用于规划和可能的多轮工具调用延迟和API成本显著增加。根因规划步骤复杂每次工具调用都可能涉及LLM或昂贵的外部API。解决方案规划缓存对于常见或相似的查询缓存其生成的检索计划。下次遇到类似查询时可以直接复用计划跳过规划步骤。异步与并行执行分析检索计划中的步骤依赖关系。对于没有依赖关系的步骤如同时检索文本和图片让执行器并行调用工具缩短整体耗时。模型分级对于简单的、模式固定的查询可以设置一个“快速通道”绕过复杂的智能体规划直接使用规则或更简单的模型进行检索。只有复杂查询才走完整的Agentic Planning流程。本地小模型对于描述生成、查询改写等任务可以尝试使用开源的、参数较小的VLM或LLM如LLaVA, Qwen-VL部署在本地以控制成本。6.4 检索结果冲突与信息过载当从不同来源检索到相互矛盾的信息时生成模型可能产生混淆。根因知识库中存在过期或冲突的信息不同模态的信息表述角度不同。解决方案来源元数据与置信度为知识库中的每一条数据添加来源、版本和置信度可信度标签。智能体在规划时可以优先检索高置信度的来源。生成模型在回答时也可以引用来源让用户自行判断。冲突检测与消解在结果整合阶段可以加入一个“冲突检测”步骤。使用LLM分析不同片段之间是否存在事实矛盾。如果存在则在上下文中明确指出“关于XX检索到两种说法A... B...”让生成模型以更谨慎的方式回答或者直接提示用户信息存在冲突。信息摘要与过滤在将大量检索结果送给生成模型前先让一个LLM对其进行摘要和去重只保留最核心、最不重复的信息点。这能有效减轻上下文长度压力并减少噪声。构建一个真正智能的、先推理后检索的多模态RAG系统是一个将Agent思想与信息检索技术深度融合的过程。它没有银弹需要根据具体的业务场景、数据形态和性能要求进行精细化的设计和调优。从最简单的单步决策智能体开始逐步迭代增加其规划能力并持续关注规划质量、系统延迟和答案的忠实度是通往成功最实际的路径。这个领域仍在快速演进新的模型、框架和思想不断涌现保持学习与实验的心态至关重要。