目录前言进阶环境依赖补充模块一多模态文档解析与结构化分块落地模块二用户反馈闭环与 RAG 效果自迭代模块三Agent 编排升级从 ReAct 到 Plan-and-Execute进阶开发踩坑复盘进阶面试考点自检清单写在最后前言上篇把基础版 RAGAgent 知识库的架子搭完之后这段时间接着做了三轮进阶优化把之前留的三个扩展点全部落地了多模态文档解析、用户反馈闭环、更复杂的 Agent 编排。基础版能跑通纯文本问答但真要落到实际业务里还会碰到很多问题PDF 里的表格图片解析不出来、上线后效果没法持续优化、复杂多步任务 Agent 容易跑偏。这篇就是把这些进阶能力的实现过程拆解开顺着代码看思路不脱节。这篇是基础篇的进阶延伸默认你已经跑通了基础的向量检索、ReAct Agent 链路。 —— 讲清楚项目的演进思路、踩过的进阶坑、落地的优化手段。2. 进阶环境依赖补充在上篇依赖的基础上补装几个进阶功能需要的包尽量保持轻量化不引入太重的组件。多模态解析我用了unstructured处理 PDF 结构化图片 OCR 直接调用通义多模态 API不用本地装大模型反馈数据用 Python 自带的 SQLite 存不用额外搭服务。pip install unstructured[pdf] pillow python-multipart需要额外准备通义千问 VL 多模态模型 API 权限处理图片 OCR带表格、图片的测试 PDF 文档用来验证多模态解析效果3. 模块一多模态文档解析与结构化分块落地基础版只能处理纯文本真拿企业里的 PDF 文档测试就会发现坑很多表格解析出来全是乱行、图片里的文字直接丢失、章节层级完全没保留很多关键信息明明在文档里就是检索不到。我最终的方案是先做结构化文档解析区分文本、表格、图片三类内容 —— 表格转成带结构的 Markdown 文本图片做 OCR 提取文字再基于章节层级做父子块分块每个内容块都带上所属章节的标题信息既保留语义上下文又保证检索粒度。核心代码实现from unstructured.partition.pdf import partition_pdf from langchain.schema import Document from langchain.text_splitter import RecursiveCharacterTextSplitter def parse_pdf_multimodal(pdf_path: str): 多模态PDF解析区分文本、表格、图片结构化提取内容 表格转Markdown格式图片调用OCR提取文字 elements partition_pdf( filenamepdf_path, strategyhi_res, # 高清解析模式能识别表格、图片 extract_images_in_pdfTrue, infer_table_structureTrue, chunking_strategyby_title # 按标题层级初步拆分 ) docs [] current_section 前言 # 记录当前章节标题作为父块上下文 for elem in elements: # 记录章节标题作为所有子块的上下文 if elem.category Title: current_section elem.text.strip() continue # 处理表格转成Markdown格式保留行列结构 if elem.category Table: table_md f**表格{current_section}**\n{elem.metadata.text_as_html} docs.append(Document(page_contenttable_md, metadata{type: table, section: current_section, source: pdf_path})) # 处理图片调用多模态模型做OCR提取文字 elif elem.category Image: # 这里简化调用通义VL模型做OCR实际可替换成本地OCR image_text ocr_image_by_vl(elem.metadata.image_path) image_content f**图片说明{current_section}**\n图片文字内容{image_text} docs.append(Document(page_contentimage_content, metadata{type: image, section: current_section, source: pdf_path})) # 处理普通文本 else: text_content f**章节{current_section}**\n{elem.text.strip()} docs.append(Document(page_contenttext_content, metadata{type: text, section: current_section, source: pdf_path})) return docs def advanced_split_documents(docs: list[Document]): 进阶分块基于章节的父子块结构保证每个块都有章节标题上下文 避免纯文本分块丢失层级信息 text_splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap80, separators[\n\n, \n, 。, , , , ], length_functionlen ) chunks [] for doc in docs: # 章节标题部分不拆分保证每个块都带上下文 section_header f**{doc.metadata[section]}**\n content_body doc.page_content.split(\n, 1)[1] if \n in doc.page_content else doc.page_content body_chunks text_splitter.split_text(content_body) for body in body_chunks: full_chunk section_header body chunks.append(Document(page_contentfull_chunk, metadatadoc.metadata)) print(f进阶分块完成共{len(chunks)}个文档块均携带章节上下文) return chunks补充一个极简的图片 OCR 调用封装实际项目里可以替换成本地 PaddleOCRimport dashscope from dashscope import MultiModalConversation def ocr_image_by_vl(image_path: str) - str: 调用通义多模态模型提取图片文字 messages [{ role: user, content: [ {image: image_path}, {text: 请提取这张图片里的所有文字内容直接输出文字不要多余描述。} ] }] response MultiModalConversation.call( modelqwen-vl-plus, messagesmessages, api_keyDASHSCOPE_API_KEY ) return response.output.choices[0].message.content[0][text]实测下来带章节上下文的分块比纯文本分块的召回率高了 15% 左右尤其是跨章节的相似内容不会再混在一起表格和图片的内容也能正常被检索到不会出现 “文档里有答案但搜不到” 的情况。对应面试考点附答题思路多模态 RAG 怎么处理表格、图片这类非文本内容答核心思路是把非文本内容转成可检索的文本向量同时尽量保留结构信息。 表格优先做结构化提取转成 Markdown 或者 HTML 格式保留行列关系再参与分块和向量化不能直接把表格拆成零散文字不然结构全丢了检索到也没用。 图片用 OCR 提取文字内容同时补充图片所在的章节上下文一起做成文档块如果是流程图、架构图这类纯视觉内容还可以用多模态模型生成文字描述再参与检索。 关键是不能丢上下文不管是表格还是图片都要带上所属章节的标题信息不然检索出来不知道是哪部分的内容。什么是父子块 / 分层分块它比普通分块好在哪里答父子块就是分层分块父块是大的语义单元比如章节、大段落子块是细粒度的检索单元检索的时候先匹配子块再把对应的父块完整上下文传给大模型。 好处很明显既保证了检索的细粒度又不会丢失完整的语义上下文解决了普通分块 “切太碎没上下文、切太粗噪声多” 的矛盾而且每个子块都带上层章节信息能减少跨章节的误匹配提升召回准确率。 我们用的带章节标题的分块就是轻量化的分层分块每个内容块都带上所属章节实现简单提升效果很明显。PDF 文档解析有哪些常见的坑怎么优化解析准确率答常见的坑特别多比如扫描版 PDF 全是图片直接解析不出文字带复杂排版的 PDF列错乱、表格错位加密 PDF 解析失败还有页眉页脚、页码这类噪声内容混进去。 优化方式首先区分原生 PDF 和扫描版扫描版必须走 OCR复杂排版优先用高清解析模式识别表格和文档结构然后做后处理过滤页眉页脚、页码、水印这些噪声表格尽量保留结构化格式不要纯文本平铺。 落地里不用追求 100% 解析准确核心是保证关键内容能被检索到噪声内容尽量过滤掉。除了按字符分块你还了解哪些进阶分块策略答除了基础的递归字符分块还有几种常用的进阶策略 一是语义分块根据 Embedding 相似度来切语义相近的放在一个块里变化大的地方切开语义完整性最好但速度慢、成本高。 二是结构化分块根据文档本身的标题层级、段落结构来切比如 Markdown、HTML 文档按 #标题层级拆分保留文档原生结构。 三是父子块分层分块粗粒度存上下文细粒度做检索兼顾准确率和上下文完整度。 落地里一般用结构化分块 递归字符分块的组合性价比最高纯语义分块成本太高适合小体量高要求的场景。易错点提醒很多人回答多模态 RAG只会说 “图片转文字”说不出表格怎么处理、怎么保留结构、怎么解决上下文丢失的问题还有人不知道分层分块的思路只会说固定大小分块这都是深度不够的表现。4. 模块二用户反馈闭环与 RAG 效果自迭代基础版搭完只是开始RAG 系统不是上线就完事了实际用起来总会有答非所问、检索不准的情况。如果全靠人工排查优化效率特别低。所以我加了一套轻量的用户反馈闭环让系统能基于用户的点赞点踩数据自动迭代优化效果。核心逻辑很简单用户对答案点赞 / 点踩系统把问题、检索结果、用户反馈存下来积累一定数据后自动做两件事一是把负反馈的问题和错误答案加入黑名单下次检索时过滤二是用正负样本优化 query 改写的 Prompt提升检索匹配度。不用动模型微调成本很低见效很快。核心代码实现import sqlite3 from datetime import datetime # 初始化反馈数据库 def init_feedback_db(): conn sqlite3.connect(./feedback.db) cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS rag_feedback ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id TEXT, user_query TEXT, answer TEXT, retrieved_docs TEXT, feedback_type INTEGER, # 1点赞 0点踩 create_time TEXT ) ) conn.commit() conn.close() # 上报用户反馈 def save_feedback(session_id: str, user_query: str, answer: str, retrieved_docs: list, feedback_type: int): 保存用户反馈点赞/点踩 conn sqlite3.connect(./feedback.db) cursor conn.cursor() docs_str \n---\n.join([doc.page_content for doc in retrieved_docs]) cursor.execute( INSERT INTO rag_feedback VALUES (NULL, ?, ?, ?, ?, ?, ?), (session_id, user_query, answer, docs_str, feedback_type, datetime.now().strftime(%Y-%m-%d %H:%M:%S)) ) conn.commit() conn.close() # 基于负反馈优化检索过滤低质量文档块 def get_negative_block_list() - set: 提取多次被点踩的文档片段加入检索黑名单 同一片段被3次以上点踩就过滤避免单点噪声 conn sqlite3.connect(./feedback.db) cursor conn.cursor() cursor.execute( SELECT retrieved_docs FROM rag_feedback WHERE feedback_type 0 GROUP BY retrieved_docs HAVING COUNT(*) 3 ) bad_docs set([row[0] for row in cursor.fetchall()]) conn.close() return bad_docs # 带黑名单过滤的检索器 def get_optimized_retriever(vector_store): base_retriever vector_store.as_retriever(search_typesimilarity, search_kwargs{k: 12}) compression_retriever ContextualCompressionRetriever( base_compressorreranker, base_retrieverbase_retriever ) # 包装一层过滤黑名单内容 class FilteredRetriever(BaseRetriever): def _get_relevant_documents(self, query, *, run_managerNone): docs compression_retriever.get_relevant_documents(query) bad_docs get_negative_block_list() # 过滤掉多次负反馈的片段 filtered [doc for doc in docs if doc.page_content not in bad_docs] return filtered[:3] # 最终保留Top3 return FilteredRetriever()除了黑名单过滤我还做了 query 改写 Prompt 的自动优化定期把用户点踩的问题整理出来让大模型分析检索失败的原因自动优化 query 改写的提示词不用人工一点点调。这套机制跑起来之后不用天天盯着日志查问题用户用得越多系统就越准属于典型的低成本高收益优化。对应面试考点附答题思路RAG 系统上线后怎么持续优化效果有哪些迭代手段答我一般从四个方向持续迭代成本从低到高 第一是用户反馈闭环也是成本最低的。做点赞点踩功能收集正负样本先做低质内容过滤再优化分块、Prompt见效最快。 第二是检索侧优化基于 bad case 调分块参数、优化分隔符、加 query 改写、调整 TopK 和 Rerank 参数还可以加关键词混合检索补充 BM25 召回。 第三是 Prompt 侧优化针对高频错误场景优化系统提示词加示例、加强约束减少幻觉和答非所问。 第四是模型侧优化数据积累多了之后可以微调 Embedding 模型或者 Rerank 模型适配垂直领域成本最高但提升上限也最高。 落地里肯定是先做低成本的反馈闭环和参数调优优先最后再考虑微调模型。怎么设计 RAG 的用户反馈闭环核心流程是什么答核心是 “数据收集→问题分析→优化落地→效果验证” 的闭环。 首先是数据收集前端做点踩点赞按钮用户点踩的时候可以补充原因后台记录问题、检索结果、答案、反馈类型、时间。 然后是问题归因区分是检索不准没搜到正确内容、还是生成幻觉搜到了但答错了、还是文档本身没有答案。 接着是优化落地检索问题就调分块、加 query 改写、优化 Rerank生成问题就改 Prompt、调 temperature文档缺失就补充知识库。 最后是效果验证优化后回归测试 bad case看是否解决同时监控整体好评率变化。 自动化程度可以逐步提升先人工抽样分析数据多了再做自动过滤、自动优化 Prompt。怎么衡量 RAG 系统的效果好坏有哪些评估指标答分离线指标和线上指标两类。 离线指标构建测试集评估召回率、准确率比如 TopK 召回率、Rerank 后的命中率还有生成答案的指标比如忠实度有没有幻觉、相关性、完整度可以用大模型打分也可以人工评估。 线上指标最核心的是用户好评率 / 点踩率最真实反映用户体验还有检索耗时、首 token 延迟、答案平均长度这些性能指标另外还有 “无答案率”就是多少问题知识库答不上来反映知识库的覆盖度。 不能只看向量相似度分数那个不代表真实效果最终还是要结合人工评估和线上用户反馈。用户反馈数据有噪声怎么办比如用户乱点踩、误操作答不能单条反馈就改系统一定要做噪声过滤不然反而会越优化越差。 首先做频次过滤同一个问题、同一个文档片段多次出现负反馈才纳入优化比如 3 次以上避免单点误操作影响。 然后做置信度判断比如用户点踩的时候补充原因有明确原因的优先级高还可以用大模型自动判断负反馈是否合理排除明显误判的。 最后优化的时候灰度生效先在小流量上验证效果没问题再全量避免一次坏数据带偏整个系统。易错点提醒很多人只会说 “做用户反馈”说不出闭环的完整流程、怎么衡量效果、怎么处理噪声一听就是没真正落地过。5. 模块三Agent 编排升级从 ReAct 到 Plan-and-Execute基础版用的 ReAct Agent处理单工具、简单任务没问题但碰到复杂的多步任务就容易跑偏。比如用户问 “帮我查一下销售部的年假规则再算一下入职满 2 年能休多少天最后整理成一句话总结”ReAct 经常走一步看一步算完天数就忘了前面的规则或者重复调用工具。所以我做了 Agent 编排的升级引入 Plan-and-Execute 模式先让大模型做整体规划把任务拆成几个子步骤明确每个步骤用什么工具然后按步骤依次执行收集结果最后把所有结果整合起来输出最终答案。复杂任务的完成度提升特别明显。核心代码实现from langchain.chains import LLMChain from langchain.prompts import PromptTemplate from langchain.agents import AgentExecutor, create_plan_and_execute_agent # 1. 规划Prompt让大模型拆解任务步骤 plan_prompt PromptTemplate( input_variables[input, tools], template 你是一个任务规划师请根据用户的问题拆解成清晰的执行步骤。 可用工具{tools} 要求 1. 拆解成2-5个清晰的子步骤每个步骤对应一个工具 2. 明确每个步骤的输入和目标 3. 步骤之间要逻辑连贯最终能解决用户问题 用户问题{input} 请输出执行计划 ) # 2. 构建Plan-and-Execute Agent plan_agent create_plan_and_execute_agent( llmllm, toolstools, planner_llmllm, planner_promptplan_prompt ) plan_agent_executor AgentExecutor( agentplan_agent, toolstools, verboseTrue, handle_parsing_errorsTrue, max_iterations10 ) # 3. 动态调度简单任务用ReAct复杂任务自动升级 def smart_agent_invoke(user_input: str, chat_history): 智能调度先判断任务复杂度 单工具简单问题用ReAct省token速度快 多工具复杂问题用Plan-and-Execute完成度更高 # 简单复杂度判断包含多个动作关键词、多步需求的走规划模式 complex_keywords [分别, 同时, 先, 再, 然后, 计算, 整理, 汇总] is_complex any(k in user_input for k in complex_keywords) if is_complex: executor plan_agent_executor else: executor agent_executor # 基础版ReAct执行器 result executor.invoke({ input: user_input, chat_history: chat_history }) return result[output]我做了动态调度不是所有任务都走规划模式。简单问题还用 ReAct速度快、省 token复杂多步任务才自动切规划模式兼顾了效率和完成度。实测下来多步任务的完成准确率从原来的 50% 左右提升到了 85% 以上代价就是 token 消耗大概多了 30%延迟也高一点但复杂场景下体验提升很明显。对应面试考点附答题思路ReAct 和 Plan-and-Execute 分别适合什么场景怎么选型答ReAct 是边想边做走一步看一步适合工具少、任务简单、单步就能解决的场景优点是轻量、省 token、灵活、能动态调整缺点是复杂多步任务容易跑偏没有全局观。 Plan-and-Execute 是先规划再执行先把任务拆成子步骤再一步步做适合多工具协同、多步骤、逻辑复杂的任务优点是任务完成度高、逻辑连贯缺点是 token 消耗大、延迟高、不够灵活规划错了容易一路错到底。 落地里不用二选一可以做动态调度简单问题用 ReAct复杂问题自动切规划模式兼顾效率和效果。我们就是这么做的大部分简单问答走轻量模式复杂任务自动升级。复杂 Agent 任务的拆解原则是什么怎么保证规划的合理性答拆解核心原则是单步单一目标、步骤粒度适中、依赖关系清晰、可落地执行。 首先每个子步骤只做一件事对应一个工具不要一步里塞多个动作然后粒度要合适不能太粗也不能太细太粗执行不了太细效率低还要理清楚步骤的依赖关系前面步骤的输出可以作为后面步骤的输入。 保证规划合理性的手段一是在 Prompt 里给示例展示正确的拆解方式二是加步骤数量限制防止拆得太碎三是执行中做校验如果某一步执行失败可以触发重规划调整步骤。多工具协同的场景下怎么处理工具之间的数据传递答核心是做好上下文管理把上一个工具的输出作为下一个工具的输入上下文。 一般有两种方式一种是全量传递把每一步的执行结果都追加到全局上下文里后面的步骤和最终整合都能看到所有历史结果另一种是显式映射规划的时候就定义好每个步骤的输入来自哪一步的输出数据传递更精准。 轻量化实现一般用全量传递就行靠大模型自己从上下文里提取需要的信息复杂编排可以用显式的变量传递比如 LangGraph 里的状态机每个节点的输入输出都定义清楚。你了解哪些 Agent 编排框架 / 模式除了 ReAct 和 Plan-and-Execute答还有几种主流的模式 一是 Function Calling 模式大模型原生支持工具调用直接输出工具名和参数不用 ReAct 的思考格式速度更快、格式更稳现在大部分大模型都支持是生产里很常用的。 二是状态机模式比如 LangGraph把 Agent 的每个步骤定义成节点按状态流转执行支持分支、循环、回退适合做复杂的工作流编排可控性最强。 三是多 Agent 模式多个不同角色的 Agent 协同比如规划 Agent、执行 Agent、评审 Agent各司其职适合特别复杂的大型任务。 落地选型看任务复杂度简单工具调用用原生 Function Calling中等复杂度用 ReAct复杂多步任务用 Plan-and-Execute工作流类的复杂场景用 LangGraph 状态机。易错点提醒很多人只会背 ReAct 的概念说不出其他编排模式也讲不清选型依据还有人不知道动态调度的思路觉得两种模式只能二选一这都是经验不足的表现。6. 进阶开发踩坑复盘进阶优化的坑比基础版多很多挑几个最典型的说说面试被问到 “做进阶优化遇到过什么难点”直接拿这些说特别真实。坑 1PDF 表格解析行列错位结构全乱现象复杂合并单元格的表格解析出来文字顺序全乱行列对应不上检索出来也没法看。排查思路对比了多种解析策略发现默认的文本提取模式会把表格按行平铺合并单元格就会错位高清结构化模式能识别表格结构但对特别复杂的表格还是会出错。解决方案优先输出 HTML/Markdown 格式的表格尽量保留行列结构对于解析失败的复杂表格 fallback 成 “表格标题 关键内容摘要” 的形式保证核心信息能被检索到不追求 100% 还原格式。坑 2负反馈噪声导致检索误伤现象有用户因为 “答案太长”“排版不好看” 点踩导致正确的文档片段被加入黑名单反而把正确答案过滤掉了。排查思路追溯黑名单里的内容发现很多片段本身是正确的只是用户体验问题被点踩不是内容错误。解决方案提高负反馈的生效阈值从 1 次改成 3 次同一片段多次被点踩才过滤同时区分反馈类型把 “内容错误” 和 “体验不好” 分开只有内容错误的反馈才影响检索逻辑加人工审核环节定期校验黑名单内容避免误伤。坑 3规划模式 token 爆炸延迟翻倍现象复杂任务走 Plan-and-Execute规划 执行 总结大模型调用次数多token 消耗是 ReAct 的两倍多延迟也很高。排查思路打印了完整链路的 token 消耗发现规划 Prompt 写得太啰嗦执行过程中又把所有历史结果全量传递很多冗余内容。解决方案精简规划 Prompt去掉无用套话执行结果做摘要压缩再传给下一步不用全量传递加上动态调度只有真正复杂的任务才走规划模式简单问题继续用 ReAct整体平均 token 消耗只涨了 10% 左右。对应进阶故障排查类面试题附答题思路多模态 RAG 解析效果差表格图片内容搜不到怎么排查优化答我会先定位问题环节从解析→分块→检索逐层排查先确认内容有没有被正确提取再确认有没有被正确索引和召回。 第一步先定位根因拿目标文档本地复现打印解析后的原始内容看表格、图片的文字有没有被提取出来。如果提取结果里根本没有对应内容就是解析环节的问题如果内容有但搜不到就是分块或检索环节的问题。 如果是解析环节问题表格先看解析模式是不是用了纯文本平铺换成高清结构化解析模式输出 HTML/Markdown 格式保留行列结构复杂合并单元格的表格做降级处理提取表格标题 核心内容摘要不追求 100% 格式还原保证关键信息可检索。图片先判断是原生 PDF 里的图片还是扫描版 PDF扫描版必须全页 OCR普通图片调用 OCR 或多模态模型提取文字同时补充图片所在的章节标题作为上下文避免孤立内容匹配不上。如果是分块检索问题检查是不是分块把表格、图片的内容切碎了结构被破坏给表格、图片单独成块并且强制带上所属章节的上下文信息做成父子块结构保证语义完整。检查向量相似度图文转文字后语义和纯文本有差异可以适当调大召回 TopK再靠 Rerank 精排提升召回率。上线了反馈闭环后检索效果反而下降了可能是什么原因答大概率是反馈数据的噪声和误伤导致的常见原因集中在四点 第一是负反馈阈值太低单点误操作就生效。比如用户因为 “答案太长”“排版不好看” 点踩不是内容错误但系统直接把对应文档片段拉黑了反而把正确答案过滤掉了解决方式是提高生效阈值比如同一片段累计 3 次以上负反馈才纳入黑名单避免单点误判。 第二是反馈类型没区分所有点踩都作用于检索。用户点踩的原因很多有内容错误、答案不完整、体验不好甚至误操作如果全都当成检索错误去优化就会误伤正确内容解决方式是拆分反馈维度区分 “内容错误”“答案不全”“体验问题”只有内容错误类的反馈才调整检索逻辑。 第三是反馈数据有偏差样本分布不均。比如某一类问题用户问得多反馈也多优化过度导致其他场景效果下降解决方式是定期全量评估效果不能只盯着反馈数据优化还要兼顾整体召回率和准确率。 第四是黑名单粒度太粗直接过滤整段内容。可能只是片段里部分信息有误但整个片段都被拉黑了连带正确内容也搜不到解决方式是细化粒度只过滤错误内容或者做内容修正不要整片拉黑。 排查的时候先看黑名单里的内容校验是不是有误伤的正确片段再回溯负反馈的原因基本就能定位到问题。Agent 升级规划模式后响应耗时大幅增加怎么优化答我会先把链路耗时拆开定位瓶颈在哪个环节再针对性优化。规划模式耗时增加主要来自三个地方多了一次规划调用、执行轮次变多、上下文冗余传递。 首先做动态调度不要所有任务都走规划模式。简单单步问题继续用轻量的 ReAct 或原生 Function Calling只有多步复杂任务才触发 Plan-and-Execute从整体上拉低平均耗时。我们就是这么做的简单问答走轻量模式复杂任务才升级平均耗时只涨了 10% 左右。 然后优化规划阶段精简规划 Prompt去掉冗余的套话和示例只保留核心约束限制规划的步骤数量比如最多拆 5 步避免过度拆分也可以用更小更快的模型做规划不用和生成答案用同一个大模型。 接着优化执行阶段控制每一步的上下文长度执行结果做摘要压缩后再传给下一步不要全量传递所有历史结果避免上下文越来越长导致生成变慢同时可以做并行执行没有依赖关系的步骤同时调用工具不用串行等待。 最后做工程优化加结果缓存常见的规划和工具调用结果直接复用优化工具执行耗时比如检索接口加缓存、下游服务提速再加超时兜底避免极端复杂任务长时间阻塞。 一般做完动态调度和上下文压缩耗时就能降下来一大半。把进阶篇的考点整理成清单配合基础篇的内容。多模态与分块进阶多模态 RAG 处理表格、图片的方案父子块 / 分层分块的原理与优势进阶分块策略的对比与选型PDF 文档解析的常见问题与优化手段反馈闭环与效果迭代RAG 上线后的持续优化手段用户反馈闭环的设计与核心流程RAG 系统的效果评估指标反馈数据噪声的处理方案Agent 编排进阶ReAct 与 Plan-and-Execute 的选型与适用场景复杂任务的拆解原则与规划合理性保障多工具协同的数据传递方案主流 Agent 编排模式与框架对比8. 写在最后从基础版到进阶版整套知识库的演进思路其实很务实先搭架子跑通核心链路再针对真实业务里的痛点逐个优化不追求一步到位也不堆没用的技术概念。
目录前言进阶环境依赖补充模块一多模态文档解析与结构化分块落地模块二用户反馈闭环与 RAG 效果自迭代模块三Agent 编排升级从 ReAct 到 Plan-and-Execute进阶开发踩坑复盘进阶面试考点自检清单写在最后前言上篇把基础版 RAGAgent 知识库的架子搭完之后这段时间接着做了三轮进阶优化把之前留的三个扩展点全部落地了多模态文档解析、用户反馈闭环、更复杂的 Agent 编排。基础版能跑通纯文本问答但真要落到实际业务里还会碰到很多问题PDF 里的表格图片解析不出来、上线后效果没法持续优化、复杂多步任务 Agent 容易跑偏。这篇就是把这些进阶能力的实现过程拆解开顺着代码看思路不脱节。这篇是基础篇的进阶延伸默认你已经跑通了基础的向量检索、ReAct Agent 链路。 —— 讲清楚项目的演进思路、踩过的进阶坑、落地的优化手段。2. 进阶环境依赖补充在上篇依赖的基础上补装几个进阶功能需要的包尽量保持轻量化不引入太重的组件。多模态解析我用了unstructured处理 PDF 结构化图片 OCR 直接调用通义多模态 API不用本地装大模型反馈数据用 Python 自带的 SQLite 存不用额外搭服务。pip install unstructured[pdf] pillow python-multipart需要额外准备通义千问 VL 多模态模型 API 权限处理图片 OCR带表格、图片的测试 PDF 文档用来验证多模态解析效果3. 模块一多模态文档解析与结构化分块落地基础版只能处理纯文本真拿企业里的 PDF 文档测试就会发现坑很多表格解析出来全是乱行、图片里的文字直接丢失、章节层级完全没保留很多关键信息明明在文档里就是检索不到。我最终的方案是先做结构化文档解析区分文本、表格、图片三类内容 —— 表格转成带结构的 Markdown 文本图片做 OCR 提取文字再基于章节层级做父子块分块每个内容块都带上所属章节的标题信息既保留语义上下文又保证检索粒度。核心代码实现from unstructured.partition.pdf import partition_pdf from langchain.schema import Document from langchain.text_splitter import RecursiveCharacterTextSplitter def parse_pdf_multimodal(pdf_path: str): 多模态PDF解析区分文本、表格、图片结构化提取内容 表格转Markdown格式图片调用OCR提取文字 elements partition_pdf( filenamepdf_path, strategyhi_res, # 高清解析模式能识别表格、图片 extract_images_in_pdfTrue, infer_table_structureTrue, chunking_strategyby_title # 按标题层级初步拆分 ) docs [] current_section 前言 # 记录当前章节标题作为父块上下文 for elem in elements: # 记录章节标题作为所有子块的上下文 if elem.category Title: current_section elem.text.strip() continue # 处理表格转成Markdown格式保留行列结构 if elem.category Table: table_md f**表格{current_section}**\n{elem.metadata.text_as_html} docs.append(Document(page_contenttable_md, metadata{type: table, section: current_section, source: pdf_path})) # 处理图片调用多模态模型做OCR提取文字 elif elem.category Image: # 这里简化调用通义VL模型做OCR实际可替换成本地OCR image_text ocr_image_by_vl(elem.metadata.image_path) image_content f**图片说明{current_section}**\n图片文字内容{image_text} docs.append(Document(page_contentimage_content, metadata{type: image, section: current_section, source: pdf_path})) # 处理普通文本 else: text_content f**章节{current_section}**\n{elem.text.strip()} docs.append(Document(page_contenttext_content, metadata{type: text, section: current_section, source: pdf_path})) return docs def advanced_split_documents(docs: list[Document]): 进阶分块基于章节的父子块结构保证每个块都有章节标题上下文 避免纯文本分块丢失层级信息 text_splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap80, separators[\n\n, \n, 。, , , , ], length_functionlen ) chunks [] for doc in docs: # 章节标题部分不拆分保证每个块都带上下文 section_header f**{doc.metadata[section]}**\n content_body doc.page_content.split(\n, 1)[1] if \n in doc.page_content else doc.page_content body_chunks text_splitter.split_text(content_body) for body in body_chunks: full_chunk section_header body chunks.append(Document(page_contentfull_chunk, metadatadoc.metadata)) print(f进阶分块完成共{len(chunks)}个文档块均携带章节上下文) return chunks补充一个极简的图片 OCR 调用封装实际项目里可以替换成本地 PaddleOCRimport dashscope from dashscope import MultiModalConversation def ocr_image_by_vl(image_path: str) - str: 调用通义多模态模型提取图片文字 messages [{ role: user, content: [ {image: image_path}, {text: 请提取这张图片里的所有文字内容直接输出文字不要多余描述。} ] }] response MultiModalConversation.call( modelqwen-vl-plus, messagesmessages, api_keyDASHSCOPE_API_KEY ) return response.output.choices[0].message.content[0][text]实测下来带章节上下文的分块比纯文本分块的召回率高了 15% 左右尤其是跨章节的相似内容不会再混在一起表格和图片的内容也能正常被检索到不会出现 “文档里有答案但搜不到” 的情况。对应面试考点附答题思路多模态 RAG 怎么处理表格、图片这类非文本内容答核心思路是把非文本内容转成可检索的文本向量同时尽量保留结构信息。 表格优先做结构化提取转成 Markdown 或者 HTML 格式保留行列关系再参与分块和向量化不能直接把表格拆成零散文字不然结构全丢了检索到也没用。 图片用 OCR 提取文字内容同时补充图片所在的章节上下文一起做成文档块如果是流程图、架构图这类纯视觉内容还可以用多模态模型生成文字描述再参与检索。 关键是不能丢上下文不管是表格还是图片都要带上所属章节的标题信息不然检索出来不知道是哪部分的内容。什么是父子块 / 分层分块它比普通分块好在哪里答父子块就是分层分块父块是大的语义单元比如章节、大段落子块是细粒度的检索单元检索的时候先匹配子块再把对应的父块完整上下文传给大模型。 好处很明显既保证了检索的细粒度又不会丢失完整的语义上下文解决了普通分块 “切太碎没上下文、切太粗噪声多” 的矛盾而且每个子块都带上层章节信息能减少跨章节的误匹配提升召回准确率。 我们用的带章节标题的分块就是轻量化的分层分块每个内容块都带上所属章节实现简单提升效果很明显。PDF 文档解析有哪些常见的坑怎么优化解析准确率答常见的坑特别多比如扫描版 PDF 全是图片直接解析不出文字带复杂排版的 PDF列错乱、表格错位加密 PDF 解析失败还有页眉页脚、页码这类噪声内容混进去。 优化方式首先区分原生 PDF 和扫描版扫描版必须走 OCR复杂排版优先用高清解析模式识别表格和文档结构然后做后处理过滤页眉页脚、页码、水印这些噪声表格尽量保留结构化格式不要纯文本平铺。 落地里不用追求 100% 解析准确核心是保证关键内容能被检索到噪声内容尽量过滤掉。除了按字符分块你还了解哪些进阶分块策略答除了基础的递归字符分块还有几种常用的进阶策略 一是语义分块根据 Embedding 相似度来切语义相近的放在一个块里变化大的地方切开语义完整性最好但速度慢、成本高。 二是结构化分块根据文档本身的标题层级、段落结构来切比如 Markdown、HTML 文档按 #标题层级拆分保留文档原生结构。 三是父子块分层分块粗粒度存上下文细粒度做检索兼顾准确率和上下文完整度。 落地里一般用结构化分块 递归字符分块的组合性价比最高纯语义分块成本太高适合小体量高要求的场景。易错点提醒很多人回答多模态 RAG只会说 “图片转文字”说不出表格怎么处理、怎么保留结构、怎么解决上下文丢失的问题还有人不知道分层分块的思路只会说固定大小分块这都是深度不够的表现。4. 模块二用户反馈闭环与 RAG 效果自迭代基础版搭完只是开始RAG 系统不是上线就完事了实际用起来总会有答非所问、检索不准的情况。如果全靠人工排查优化效率特别低。所以我加了一套轻量的用户反馈闭环让系统能基于用户的点赞点踩数据自动迭代优化效果。核心逻辑很简单用户对答案点赞 / 点踩系统把问题、检索结果、用户反馈存下来积累一定数据后自动做两件事一是把负反馈的问题和错误答案加入黑名单下次检索时过滤二是用正负样本优化 query 改写的 Prompt提升检索匹配度。不用动模型微调成本很低见效很快。核心代码实现import sqlite3 from datetime import datetime # 初始化反馈数据库 def init_feedback_db(): conn sqlite3.connect(./feedback.db) cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS rag_feedback ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id TEXT, user_query TEXT, answer TEXT, retrieved_docs TEXT, feedback_type INTEGER, # 1点赞 0点踩 create_time TEXT ) ) conn.commit() conn.close() # 上报用户反馈 def save_feedback(session_id: str, user_query: str, answer: str, retrieved_docs: list, feedback_type: int): 保存用户反馈点赞/点踩 conn sqlite3.connect(./feedback.db) cursor conn.cursor() docs_str \n---\n.join([doc.page_content for doc in retrieved_docs]) cursor.execute( INSERT INTO rag_feedback VALUES (NULL, ?, ?, ?, ?, ?, ?), (session_id, user_query, answer, docs_str, feedback_type, datetime.now().strftime(%Y-%m-%d %H:%M:%S)) ) conn.commit() conn.close() # 基于负反馈优化检索过滤低质量文档块 def get_negative_block_list() - set: 提取多次被点踩的文档片段加入检索黑名单 同一片段被3次以上点踩就过滤避免单点噪声 conn sqlite3.connect(./feedback.db) cursor conn.cursor() cursor.execute( SELECT retrieved_docs FROM rag_feedback WHERE feedback_type 0 GROUP BY retrieved_docs HAVING COUNT(*) 3 ) bad_docs set([row[0] for row in cursor.fetchall()]) conn.close() return bad_docs # 带黑名单过滤的检索器 def get_optimized_retriever(vector_store): base_retriever vector_store.as_retriever(search_typesimilarity, search_kwargs{k: 12}) compression_retriever ContextualCompressionRetriever( base_compressorreranker, base_retrieverbase_retriever ) # 包装一层过滤黑名单内容 class FilteredRetriever(BaseRetriever): def _get_relevant_documents(self, query, *, run_managerNone): docs compression_retriever.get_relevant_documents(query) bad_docs get_negative_block_list() # 过滤掉多次负反馈的片段 filtered [doc for doc in docs if doc.page_content not in bad_docs] return filtered[:3] # 最终保留Top3 return FilteredRetriever()除了黑名单过滤我还做了 query 改写 Prompt 的自动优化定期把用户点踩的问题整理出来让大模型分析检索失败的原因自动优化 query 改写的提示词不用人工一点点调。这套机制跑起来之后不用天天盯着日志查问题用户用得越多系统就越准属于典型的低成本高收益优化。对应面试考点附答题思路RAG 系统上线后怎么持续优化效果有哪些迭代手段答我一般从四个方向持续迭代成本从低到高 第一是用户反馈闭环也是成本最低的。做点赞点踩功能收集正负样本先做低质内容过滤再优化分块、Prompt见效最快。 第二是检索侧优化基于 bad case 调分块参数、优化分隔符、加 query 改写、调整 TopK 和 Rerank 参数还可以加关键词混合检索补充 BM25 召回。 第三是 Prompt 侧优化针对高频错误场景优化系统提示词加示例、加强约束减少幻觉和答非所问。 第四是模型侧优化数据积累多了之后可以微调 Embedding 模型或者 Rerank 模型适配垂直领域成本最高但提升上限也最高。 落地里肯定是先做低成本的反馈闭环和参数调优优先最后再考虑微调模型。怎么设计 RAG 的用户反馈闭环核心流程是什么答核心是 “数据收集→问题分析→优化落地→效果验证” 的闭环。 首先是数据收集前端做点踩点赞按钮用户点踩的时候可以补充原因后台记录问题、检索结果、答案、反馈类型、时间。 然后是问题归因区分是检索不准没搜到正确内容、还是生成幻觉搜到了但答错了、还是文档本身没有答案。 接着是优化落地检索问题就调分块、加 query 改写、优化 Rerank生成问题就改 Prompt、调 temperature文档缺失就补充知识库。 最后是效果验证优化后回归测试 bad case看是否解决同时监控整体好评率变化。 自动化程度可以逐步提升先人工抽样分析数据多了再做自动过滤、自动优化 Prompt。怎么衡量 RAG 系统的效果好坏有哪些评估指标答分离线指标和线上指标两类。 离线指标构建测试集评估召回率、准确率比如 TopK 召回率、Rerank 后的命中率还有生成答案的指标比如忠实度有没有幻觉、相关性、完整度可以用大模型打分也可以人工评估。 线上指标最核心的是用户好评率 / 点踩率最真实反映用户体验还有检索耗时、首 token 延迟、答案平均长度这些性能指标另外还有 “无答案率”就是多少问题知识库答不上来反映知识库的覆盖度。 不能只看向量相似度分数那个不代表真实效果最终还是要结合人工评估和线上用户反馈。用户反馈数据有噪声怎么办比如用户乱点踩、误操作答不能单条反馈就改系统一定要做噪声过滤不然反而会越优化越差。 首先做频次过滤同一个问题、同一个文档片段多次出现负反馈才纳入优化比如 3 次以上避免单点误操作影响。 然后做置信度判断比如用户点踩的时候补充原因有明确原因的优先级高还可以用大模型自动判断负反馈是否合理排除明显误判的。 最后优化的时候灰度生效先在小流量上验证效果没问题再全量避免一次坏数据带偏整个系统。易错点提醒很多人只会说 “做用户反馈”说不出闭环的完整流程、怎么衡量效果、怎么处理噪声一听就是没真正落地过。5. 模块三Agent 编排升级从 ReAct 到 Plan-and-Execute基础版用的 ReAct Agent处理单工具、简单任务没问题但碰到复杂的多步任务就容易跑偏。比如用户问 “帮我查一下销售部的年假规则再算一下入职满 2 年能休多少天最后整理成一句话总结”ReAct 经常走一步看一步算完天数就忘了前面的规则或者重复调用工具。所以我做了 Agent 编排的升级引入 Plan-and-Execute 模式先让大模型做整体规划把任务拆成几个子步骤明确每个步骤用什么工具然后按步骤依次执行收集结果最后把所有结果整合起来输出最终答案。复杂任务的完成度提升特别明显。核心代码实现from langchain.chains import LLMChain from langchain.prompts import PromptTemplate from langchain.agents import AgentExecutor, create_plan_and_execute_agent # 1. 规划Prompt让大模型拆解任务步骤 plan_prompt PromptTemplate( input_variables[input, tools], template 你是一个任务规划师请根据用户的问题拆解成清晰的执行步骤。 可用工具{tools} 要求 1. 拆解成2-5个清晰的子步骤每个步骤对应一个工具 2. 明确每个步骤的输入和目标 3. 步骤之间要逻辑连贯最终能解决用户问题 用户问题{input} 请输出执行计划 ) # 2. 构建Plan-and-Execute Agent plan_agent create_plan_and_execute_agent( llmllm, toolstools, planner_llmllm, planner_promptplan_prompt ) plan_agent_executor AgentExecutor( agentplan_agent, toolstools, verboseTrue, handle_parsing_errorsTrue, max_iterations10 ) # 3. 动态调度简单任务用ReAct复杂任务自动升级 def smart_agent_invoke(user_input: str, chat_history): 智能调度先判断任务复杂度 单工具简单问题用ReAct省token速度快 多工具复杂问题用Plan-and-Execute完成度更高 # 简单复杂度判断包含多个动作关键词、多步需求的走规划模式 complex_keywords [分别, 同时, 先, 再, 然后, 计算, 整理, 汇总] is_complex any(k in user_input for k in complex_keywords) if is_complex: executor plan_agent_executor else: executor agent_executor # 基础版ReAct执行器 result executor.invoke({ input: user_input, chat_history: chat_history }) return result[output]我做了动态调度不是所有任务都走规划模式。简单问题还用 ReAct速度快、省 token复杂多步任务才自动切规划模式兼顾了效率和完成度。实测下来多步任务的完成准确率从原来的 50% 左右提升到了 85% 以上代价就是 token 消耗大概多了 30%延迟也高一点但复杂场景下体验提升很明显。对应面试考点附答题思路ReAct 和 Plan-and-Execute 分别适合什么场景怎么选型答ReAct 是边想边做走一步看一步适合工具少、任务简单、单步就能解决的场景优点是轻量、省 token、灵活、能动态调整缺点是复杂多步任务容易跑偏没有全局观。 Plan-and-Execute 是先规划再执行先把任务拆成子步骤再一步步做适合多工具协同、多步骤、逻辑复杂的任务优点是任务完成度高、逻辑连贯缺点是 token 消耗大、延迟高、不够灵活规划错了容易一路错到底。 落地里不用二选一可以做动态调度简单问题用 ReAct复杂问题自动切规划模式兼顾效率和效果。我们就是这么做的大部分简单问答走轻量模式复杂任务自动升级。复杂 Agent 任务的拆解原则是什么怎么保证规划的合理性答拆解核心原则是单步单一目标、步骤粒度适中、依赖关系清晰、可落地执行。 首先每个子步骤只做一件事对应一个工具不要一步里塞多个动作然后粒度要合适不能太粗也不能太细太粗执行不了太细效率低还要理清楚步骤的依赖关系前面步骤的输出可以作为后面步骤的输入。 保证规划合理性的手段一是在 Prompt 里给示例展示正确的拆解方式二是加步骤数量限制防止拆得太碎三是执行中做校验如果某一步执行失败可以触发重规划调整步骤。多工具协同的场景下怎么处理工具之间的数据传递答核心是做好上下文管理把上一个工具的输出作为下一个工具的输入上下文。 一般有两种方式一种是全量传递把每一步的执行结果都追加到全局上下文里后面的步骤和最终整合都能看到所有历史结果另一种是显式映射规划的时候就定义好每个步骤的输入来自哪一步的输出数据传递更精准。 轻量化实现一般用全量传递就行靠大模型自己从上下文里提取需要的信息复杂编排可以用显式的变量传递比如 LangGraph 里的状态机每个节点的输入输出都定义清楚。你了解哪些 Agent 编排框架 / 模式除了 ReAct 和 Plan-and-Execute答还有几种主流的模式 一是 Function Calling 模式大模型原生支持工具调用直接输出工具名和参数不用 ReAct 的思考格式速度更快、格式更稳现在大部分大模型都支持是生产里很常用的。 二是状态机模式比如 LangGraph把 Agent 的每个步骤定义成节点按状态流转执行支持分支、循环、回退适合做复杂的工作流编排可控性最强。 三是多 Agent 模式多个不同角色的 Agent 协同比如规划 Agent、执行 Agent、评审 Agent各司其职适合特别复杂的大型任务。 落地选型看任务复杂度简单工具调用用原生 Function Calling中等复杂度用 ReAct复杂多步任务用 Plan-and-Execute工作流类的复杂场景用 LangGraph 状态机。易错点提醒很多人只会背 ReAct 的概念说不出其他编排模式也讲不清选型依据还有人不知道动态调度的思路觉得两种模式只能二选一这都是经验不足的表现。6. 进阶开发踩坑复盘进阶优化的坑比基础版多很多挑几个最典型的说说面试被问到 “做进阶优化遇到过什么难点”直接拿这些说特别真实。坑 1PDF 表格解析行列错位结构全乱现象复杂合并单元格的表格解析出来文字顺序全乱行列对应不上检索出来也没法看。排查思路对比了多种解析策略发现默认的文本提取模式会把表格按行平铺合并单元格就会错位高清结构化模式能识别表格结构但对特别复杂的表格还是会出错。解决方案优先输出 HTML/Markdown 格式的表格尽量保留行列结构对于解析失败的复杂表格 fallback 成 “表格标题 关键内容摘要” 的形式保证核心信息能被检索到不追求 100% 还原格式。坑 2负反馈噪声导致检索误伤现象有用户因为 “答案太长”“排版不好看” 点踩导致正确的文档片段被加入黑名单反而把正确答案过滤掉了。排查思路追溯黑名单里的内容发现很多片段本身是正确的只是用户体验问题被点踩不是内容错误。解决方案提高负反馈的生效阈值从 1 次改成 3 次同一片段多次被点踩才过滤同时区分反馈类型把 “内容错误” 和 “体验不好” 分开只有内容错误的反馈才影响检索逻辑加人工审核环节定期校验黑名单内容避免误伤。坑 3规划模式 token 爆炸延迟翻倍现象复杂任务走 Plan-and-Execute规划 执行 总结大模型调用次数多token 消耗是 ReAct 的两倍多延迟也很高。排查思路打印了完整链路的 token 消耗发现规划 Prompt 写得太啰嗦执行过程中又把所有历史结果全量传递很多冗余内容。解决方案精简规划 Prompt去掉无用套话执行结果做摘要压缩再传给下一步不用全量传递加上动态调度只有真正复杂的任务才走规划模式简单问题继续用 ReAct整体平均 token 消耗只涨了 10% 左右。对应进阶故障排查类面试题附答题思路多模态 RAG 解析效果差表格图片内容搜不到怎么排查优化答我会先定位问题环节从解析→分块→检索逐层排查先确认内容有没有被正确提取再确认有没有被正确索引和召回。 第一步先定位根因拿目标文档本地复现打印解析后的原始内容看表格、图片的文字有没有被提取出来。如果提取结果里根本没有对应内容就是解析环节的问题如果内容有但搜不到就是分块或检索环节的问题。 如果是解析环节问题表格先看解析模式是不是用了纯文本平铺换成高清结构化解析模式输出 HTML/Markdown 格式保留行列结构复杂合并单元格的表格做降级处理提取表格标题 核心内容摘要不追求 100% 格式还原保证关键信息可检索。图片先判断是原生 PDF 里的图片还是扫描版 PDF扫描版必须全页 OCR普通图片调用 OCR 或多模态模型提取文字同时补充图片所在的章节标题作为上下文避免孤立内容匹配不上。如果是分块检索问题检查是不是分块把表格、图片的内容切碎了结构被破坏给表格、图片单独成块并且强制带上所属章节的上下文信息做成父子块结构保证语义完整。检查向量相似度图文转文字后语义和纯文本有差异可以适当调大召回 TopK再靠 Rerank 精排提升召回率。上线了反馈闭环后检索效果反而下降了可能是什么原因答大概率是反馈数据的噪声和误伤导致的常见原因集中在四点 第一是负反馈阈值太低单点误操作就生效。比如用户因为 “答案太长”“排版不好看” 点踩不是内容错误但系统直接把对应文档片段拉黑了反而把正确答案过滤掉了解决方式是提高生效阈值比如同一片段累计 3 次以上负反馈才纳入黑名单避免单点误判。 第二是反馈类型没区分所有点踩都作用于检索。用户点踩的原因很多有内容错误、答案不完整、体验不好甚至误操作如果全都当成检索错误去优化就会误伤正确内容解决方式是拆分反馈维度区分 “内容错误”“答案不全”“体验问题”只有内容错误类的反馈才调整检索逻辑。 第三是反馈数据有偏差样本分布不均。比如某一类问题用户问得多反馈也多优化过度导致其他场景效果下降解决方式是定期全量评估效果不能只盯着反馈数据优化还要兼顾整体召回率和准确率。 第四是黑名单粒度太粗直接过滤整段内容。可能只是片段里部分信息有误但整个片段都被拉黑了连带正确内容也搜不到解决方式是细化粒度只过滤错误内容或者做内容修正不要整片拉黑。 排查的时候先看黑名单里的内容校验是不是有误伤的正确片段再回溯负反馈的原因基本就能定位到问题。Agent 升级规划模式后响应耗时大幅增加怎么优化答我会先把链路耗时拆开定位瓶颈在哪个环节再针对性优化。规划模式耗时增加主要来自三个地方多了一次规划调用、执行轮次变多、上下文冗余传递。 首先做动态调度不要所有任务都走规划模式。简单单步问题继续用轻量的 ReAct 或原生 Function Calling只有多步复杂任务才触发 Plan-and-Execute从整体上拉低平均耗时。我们就是这么做的简单问答走轻量模式复杂任务才升级平均耗时只涨了 10% 左右。 然后优化规划阶段精简规划 Prompt去掉冗余的套话和示例只保留核心约束限制规划的步骤数量比如最多拆 5 步避免过度拆分也可以用更小更快的模型做规划不用和生成答案用同一个大模型。 接着优化执行阶段控制每一步的上下文长度执行结果做摘要压缩后再传给下一步不要全量传递所有历史结果避免上下文越来越长导致生成变慢同时可以做并行执行没有依赖关系的步骤同时调用工具不用串行等待。 最后做工程优化加结果缓存常见的规划和工具调用结果直接复用优化工具执行耗时比如检索接口加缓存、下游服务提速再加超时兜底避免极端复杂任务长时间阻塞。 一般做完动态调度和上下文压缩耗时就能降下来一大半。把进阶篇的考点整理成清单配合基础篇的内容。多模态与分块进阶多模态 RAG 处理表格、图片的方案父子块 / 分层分块的原理与优势进阶分块策略的对比与选型PDF 文档解析的常见问题与优化手段反馈闭环与效果迭代RAG 上线后的持续优化手段用户反馈闭环的设计与核心流程RAG 系统的效果评估指标反馈数据噪声的处理方案Agent 编排进阶ReAct 与 Plan-and-Execute 的选型与适用场景复杂任务的拆解原则与规划合理性保障多工具协同的数据传递方案主流 Agent 编排模式与框架对比8. 写在最后从基础版到进阶版整套知识库的演进思路其实很务实先搭架子跑通核心链路再针对真实业务里的痛点逐个优化不追求一步到位也不堆没用的技术概念。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
