
1. 从“搜不到”到“答得准”为什么需要复合检索 Agent在信息爆炸的时代无论是电商平台的商品咨询、企业内部的知识库查询还是像“得物”这样专注于潮流商品鉴别的社区用户对问答系统的要求早已超越了简单的关键词匹配。传统的搜索引擎或FAQ系统面对“这双鞋的鞋底材质在雨天防滑吗”或者“我身高175体重70公斤穿这款外套的M码会显胖吗”这类复杂、多维度、甚至隐含上下文的问题时往往显得力不从心。用户得到的要么是一堆不相关的商品列表要么是几篇割裂的、需要自己拼凑答案的文档体验非常糟糕。这就是“复合检索 Agent”要解决的核心痛点。它不是一个单一的搜索框而是一个智能的“信息侦探”。想象一下当你向一位资深导购提问时他不会只翻看一本产品手册。他会结合你的体型、风格偏好、使用场景甚至当前的天气从海量的商品库、用户评价、穿搭攻略、材质说明书中提取、推理并整合出一个精准的、个性化的答案。复合检索 Agent 要做的就是把这个“资深导购”的能力系统化、自动化。“复合”二字是它的灵魂。它意味着检索策略的多样性。单一向量检索擅长语义相似性但可能漏掉关键的专业术语关键词BM25检索能精准命中特定词汇却无法理解“不显胖”和“修身效果”其实是同一诉求。更复杂的问题可能还需要调用专门的工具比如查询实时库存、调用尺寸计算器、甚至分析图片中的款式元素。一个设计良好的复合检索 Agent会根据问题动态地组合这些检索能力先广撒网再精筛选最后进行逻辑推理与信息融合最终生成一个直接、可靠、有依据的答复。我最近在参与一个类似得物知识问答场景的系统设计时深刻体会到构建这样一个系统技术选型只是第一步更关键的是对业务场景的深度理解和对“智能体”Agent行为模式的精细设计。接下来我将结合实践拆解从架构设计到核心模块实现的全过程特别是如何利用 AgentScope 这类框架来落地 ReAct 推理范式让系统不仅“能回答”更能“会思考”。2. 系统蓝图分层架构与核心组件拆解一个健壮的复合检索 Agent 系统不能是“一锅粥”需要有清晰的分层和职责划分。经过多次迭代我们最终确立了一个四层架构自下而上分别是数据层、检索层、智能体层和应用层。这个架构确保了系统的可扩展性、可维护性以及核心逻辑的清晰度。2.1 数据层知识原料的标准化预处理一切智能问答的基础是高质量的知识源。在得物这类场景中知识源是高度异构的结构化数据商品SPU/SKU信息、品牌、价格、库存等存在于数据库。半结构化/非结构化数据商品详情描述、用户评测、穿搭笔记、鉴别帖子、社区问答等这类数据富含语义但格式不一。多媒体数据商品图片、视频其中包含的视觉信息如颜色、纹理、版型也是关键知识。数据层的核心任务是将这些“原料”加工成便于后续检索和理解的“标准食材”。我们的处理流水线包括数据接入与清洗从各业务数据库、日志系统、内容平台通过ETL工具同步数据。清洗掉无意义的符号、广告文本、重复内容并对文本进行标准化如统一“AJ1”和“Air Jordan 1”的表述。知识切片Chunking这是至关重要的一步。直接将一篇长达数千字的穿搭攻略全文向量化检索精度会急剧下降。我们根据文本类型采用混合策略按语义分割对于连贯性强的文章使用基于自然段或句子重叠的滑动窗口进行分割确保上下文完整性。按结构分割对于商品详情页按照“标题”、“材质说明”、“洗涤建议”、“尺码表”等预定义字段进行提取和独立存储。切片元数据为每个切片附加丰富的元数据如来源类型商品、帖子、评测、商品ID、品牌、创建时间、点赞数作为可信度权重参考等。这些元数据将在后续的检索排序中发挥巨大作用。向量化嵌入Embedding使用如text-embedding-3-small或BGE-M3等适合中文且支持长文本的模型将文本切片转换为高维向量。这里的一个关键决策是分字段嵌入。例如将“商品标题”和“用户评价”分别用不同的模型或同一模型的不同提示词进行嵌入因为它们的语言风格和重要性不同。标题更注重精确匹配评价更注重情感和体验描述。索引构建将向量存入专业的向量数据库如 Milvus, Qdrant, Weaviate同时将原始文本、元数据和关键词索引用于BM25存入关联的文档存储如 Elasticsearch。两者通过一个唯一的chunk_id进行关联形成“向量索引”“原文存储”的经典组合。实操心得知识切片的大小是平衡召回率与精度的艺术。我们通过AB测试确定对于商品描述300-500字符的切片效果最佳对于社区帖子500-800字符更合适。太小会丢失上下文太大会引入噪声。元数据的设计要前瞻多考虑未来可能的筛选和排序需求。2.2 检索层多路召回与融合排序当用户问题到来时检索层扮演了“侦察兵”的角色它的目标是从海量知识中快速找到所有可能的候选片段。单一检索方式如同只用一种工具侦察复合检索则是多兵种协同作战。查询理解与改写首先对原始用户查询进行预处理。包括纠错“AJ”纠为“Air Jordan”、扩展同义词“跑步鞋”扩展为“跑鞋”、“运动鞋”、意图识别判断是问“材质”、“搭配”还是“真伪鉴别”。这一步能显著提升后续检索的召回率。多路召回向量检索路将改写后的查询语句进行向量化在向量数据库中进行近似最近邻搜索召回语义最相似的Top K个片段。关键词检索路利用Elasticsearch的BM25算法对查询中的关键实体词品牌、型号、颜色进行精确匹配和全文检索召回另一批Top K片段。元数据过滤路如果查询中包含了明确的过滤条件如“耐克的鞋子”、“2024年的新款”则直接在数据库层面进行筛选缩小检索范围。工具调用路可选对于“有货吗”、“上海明天能送到吗”这类问题检索层会识别出需要调用实时接口库存查询、物流计算的意图并将“调用工具”本身作为一个特殊的“检索结果”传递给上层。融合排序Rerank多路召回会产生大量重复和相关性不一的片段直接返回给用户是灾难。我们需要一个“精排”阶段。这里我们采用了两阶段排序策略粗排根据基础规则快速筛选如去重、过滤掉元数据完全不匹配的片段比如用户问“羽绒服”召回了“短袖”的片段。精排使用一个轻量级但强大的交叉编码器模型如BGE-Reranker。它将用户查询和每一个候选片段进行交互计算得出一个精细的相关性分数。这个分数比单纯的向量余弦相似度准得多。最后我们设计了一个加权公式最终分数 0.6 * 精排分数 0.3 * 向量相似度分数 0.1 * 来源权威性权重如官方详情页权重高于普通帖子。根据最终分数对片段进行重排序选出Top N通常5-10个最相关的片段作为“证据”提交给智能体层。踩坑记录初期我们直接使用向量相似度排序发现经常出现“答非所问但语义沾边”的情况。例如用户问“这款鞋偏码吗”向量检索可能召回大量描述“这款鞋外观好看”的评测因为“好看”和“偏码”在训练语料中可能都与“鞋”共现。引入专用的重排模型后准确率提升了40%以上。重排模型虽增加了少量延迟但对于提升答案质量是绝对值得的。2.3 智能体层基于ReAct范式的推理与作答这是系统的“大脑”。它接收检索层提供的“证据”和原始用户问题负责理解、推理并生成最终答案。我们采用ReActReasoning Acting范式来构建这个智能体并使用AgentScope框架进行高效编排。ReAct的核心思想是让智能体模仿人类的思考过程先思考Reason再行动Act观察结果再继续思考循环往复直至解决问题。在我们的设计中智能体被设计成一个具有明确工作流的“虚拟专家”观察与规划智能体首先分析用户问题判断其复杂程度。是一个简单的事实查询“这双鞋的价格”还是一个需要对比、推理的复杂问题“这款鞋和另一款A相比哪个更适合通勤”。对于复杂问题它会在内部生成一个思考链例如“要比较通勤适用性我需要先分别找出两款鞋的‘重量’、‘鞋底材质’、‘用户通勤评价’等信息然后进行综合对比。”指令执行与工具调用根据规划智能体可以执行多种“动作”信息提取与总结从检索层提供的证据片段中提取关键信息。如果证据不足或矛盾它可以“要求”检索层换一种方式重新检索例如“请用更具体的关键词‘Air Jordan 1 脚感’再搜一次”。调用计算工具对于“我穿多大码”的问题智能体在提取用户的身高体重和商品的尺码表后可以调用一个预置的“尺码推荐工具函数”进行计算。多轮追问如果信息缺失如用户没说明身高体重智能体会主动发起追问引导用户补充必要信息而不是给出一个模糊的答案。推理与合成收集到所有必要信息后智能体进行最终推理。它需要判断信息间的可信度官方信息优先于个人评测处理可能存在的矛盾并将分散的信息点整合成一个连贯、完整、口语化的答案。答案生成与溯源使用大语言模型生成最终回复。一个关键要求是答案中的每一个关键事实陈述都必须引用其来源证据的ID。例如“根据商品详情页来源ID: doc_123鞋面采用头层牛皮另据用户‘潮流玩家小明’的评测来源ID: review_456这双鞋前三次穿着可能略硬。” 这样既增加了答案的可信度也方便后续审计和模型优化。AgentScope框架在这里的价值在于它为我们提供了便捷的方式来定义这个智能体的工作流Workflow管理其内部状态State并优雅地处理工具调用、多智能体协作例如可以设计一个“质检员”智能体来复核主智能体的答案等复杂逻辑而无需我们从零开始处理繁琐的异步和状态管理代码。2.4 应用层接口、管控与持续学习这是系统与外界交互的界面和运营后台。API网关提供统一的问答接口处理用户请求的路由、认证、限流和日志记录。会话管理维护用户的多轮对话上下文确保智能体在后续对话中能引用之前的讨论内容。管控与评估平台这是运营核心。我们需要一个界面来监控问答质量记录每一次问答的输入、检索证据、智能体思考过程、输出和溯源。收集反馈提供“点赞/点踩”功能将不满意的回答标记出来放入改进池。主动测试与评估利用积累的bad case和标准测试集定期对系统进行自动化评估跟踪准确率、有用性、安全性等关键指标。知识库热更新对于高频或重要的新知识如突发的新品发布信息提供快速通道更新到知识库无需等待全量重建。持续学习闭环将标注的bad case和用户反馈用于微调重排模型、优化查询改写策略、甚至作为few-shot示例注入智能体的提示词中让系统在实践中不断进化。3. 核心挑战精准性与“幻觉”的攻防战在复合检索 Agent 系统中最大的敌人是“幻觉”——即模型生成看似合理但事实上错误或毫无依据的信息。在电商、鉴别这种对准确性要求极高的场景幻觉是致命的。我们的防线是多层次的。3.1 检索阶段宁可错过不可错杀检索是源头如果检索到的“证据”本身就是错的或不相关的后续智能体再聪明也无法生成正确答案。策略在融合排序阶段我们设置了一个较高的相关性分数阈值。如果Top N个证据片段的精排分数都低于这个阈值系统不会强行将低质量证据送入智能体而是触发“拒答”机制回复“您的问题暂时没有找到足够可靠的信息您可以尝试换一种问法或咨询人工客服。”技术手段除了交叉编码器重排我们还引入了一致性校验。例如如果多个证据片段对同一个事实如“鞋底材质”的描述不一致系统会标记冲突并在提供给智能体的上下文中明确指出“以下信息存在矛盾请谨慎参考”。智能体在生成答案时必须处理这种冲突或明确告知用户存在不同说法。3.2 智能体阶段用框架约束思维用溯源锁定责任这是对抗幻觉的主战场。我们通过精心设计提示词和流程来约束大语言模型的行为。严格的指令设计在给智能体的系统提示词中我们会反复强调“你必须且仅能基于提供的检索证据来回答问题。如果证据中没有明确信息你必须承认不知道禁止编造任何细节。” 并将此作为最高优先级指令。分步推理与强制暂停利用AgentScope的流程控制我们强制智能体必须显式地输出“思考”步骤。例如思考用户想知道鞋子的材质。我需要在提供的证据中查找与“材质”、“面料”、“用料”相关的描述。行动扫描证据片段1, 3, 5。观察在证据片段1商品详情页中找到“鞋面头层牛皮内里猪皮革”。思考证据充分可以据此回答。行动生成最终答案并附上溯源。这个过程让模型的推理“白盒化”便于调试和监控。溯源Citation的非妥协性我们不在事后让模型补充引用而是在生成答案的指令中要求模型以特定格式如【来源ID: xxx】在陈述事实的句子末尾即时插入引用。在输出解析阶段我们会严格检查答案中是否每一个事实点都有对应的引用如果没有则触发重生成或降级为安全回复。3.3 后处理与人工巡检最后的安全网敏感词与合规过滤在答案最终返回给用户前必须经过一层严格的内容安全过滤屏蔽不当言论、虚假宣传、歧视性语言等。不确定性表达对于证据模糊或存在冲突的问题训练模型使用“可能”、“据部分用户反馈”、“官方信息显示…但也有用户认为…”等谨慎性措辞。人工巡检与强化学习运营人员定期审查被用户点踩或系统置信度低的问答记录。这些记录经过校正后形成高质量的“问题 证据 理想答案”三元组可以用于对智能体进行检索增强生成RAG的微调或强化学习RLHF直接教会模型在类似场景下如何更好地利用证据和避免幻觉。4. 性能与成本在体验与资源间寻找平衡一个不能快速响应或成本高昂的系统是没有实用价值的。我们面临几个关键权衡4.1 延迟优化异步、缓存与分级处理用户对问答的延迟容忍度很低理想应在1-3秒内返回。检索并行化向量检索、关键词检索、元数据过滤这三路召回是相互独立的必须并行执行这是降低延迟最有效的手段。结果缓存对于高频、热点问题如“得物APP怎么鉴别”将其问答对进行缓存。下次遇到相同或高度相似的问题时可直接返回缓存结果绕过复杂的检索和推理流程。缓存键的设计需要巧妙既要匹配语义又不能过于宽松导致错误命中。分级响应对于极其复杂、需要多轮工具调用和深度推理的问题系统可以采用“快速初步回答后台深度分析推送”的策略。先立即返回一个基于已有信息的简要回答同时后台继续运行完整流程完成后通过消息推送等方式将更详尽的分析补充给用户。模型选型在智能体层推理速度极快的小模型如 7B 参数量的模型与能力强但慢的大模型如 70B 模型之间需要权衡。我们的策略是使用模型路由简单问题由小模型处理当问题复杂度超过阈值或小模型多次尝试后置信度仍低时自动路由到大模型处理。4.2 成本控制让每一次调用都物有所值大模型API调用和向量数据库查询是按量计费的成本必须可控。精准的检索前置高质量的检索是降低成本的第一道关。如果检索到的证据足够精准和浓缩就能极大减少需要输入大模型的上下文长度Token数从而直接降低调用成本。这也是为什么我们在检索层投入大量精力做重排和去重。上下文压缩与摘要如果检索到的证据原文很长可以在送入大模型前先用一个更便宜的模型或摘要算法对证据进行压缩只保留与问题最相关的核心句段。智能体“节俭”意识在提示词中鼓励智能体进行简洁的思考和输出避免冗长的内部独白。同时设定工具调用的次数限制防止智能体陷入无意义的循环检索。监控与预算建立详细的成本监控仪表盘按业务线、问题类型统计模型调用次数、Token消耗量。设置每日/每月预算告警及时发现异常消耗模式例如某个被恶意利用的提问模式导致循环调用。5. 评估与迭代如何衡量一个智能问答系统的优劣上线不是终点而是持续优化的开始。我们建立了一套多维度的评估体系自动化评估指标检索相关度Retrieval Relevance使用标注数据计算召回片段的平均精排分数或人工评分。答案忠实度Faithfulness通过NLP模型自动判断生成的答案是否严格源自提供的证据量化幻觉比例。答案相关性Answer Relevance判断答案是否直接回答了问题是否答非所问。ROUGE/BLEU与人工标准答案的文本相似度作为参考在开放域问答中此指标局限性较大。人工评估核心定期抽样一批问答记录由专业标注人员从以下维度评分1-5分有用性答案是否解决了用户问题准确性答案中的事实是否正确完整性是否涵盖了问题的所有方面清晰性与友好度表达是否清晰易懂、语气是否友好业务指标联动最终系统的价值要体现在业务上。我们会分析接入智能问答后对应场景的人工客服咨询量是否下降用户对问答结果的满意度点赞率如何问答后用户的后续行为如浏览商品详情、加购、下单转化率是否有提升基于这些评估数据我们形成了明确的迭代闭环发现bad case - 根因分析是检索失败、智能体误解还是知识缺失 - 针对性优化调整检索策略、修改提示词、补充知识 - A/B测试验证 - 全量发布。设计并实现一个像得物知识问答这样的复合检索 Agent 系统是一个典型的系统工程它没有银弹而是检索技术、大模型能力、软件架构和业务理解的深度结合。最大的体会是不能盲目追求技术的“炫酷”每一个设计决策——从知识切片的大小到重排模型的权重再到智能体提示词里的一个措辞——都必须紧紧围绕“精准、可靠、有用”这个核心目标。AgentScope这类框架的出现确实降低了构建复杂智能体工作流的门槛但如何定义智能体的“思维”模式如何让它更好地理解业务、利用工具、对抗幻觉这些更深层的问题依然需要我们深入场景持续地打磨和探索。