1. 项目概述当“得物”用户开始问“刁钻”问题在潮流电商和内容社区领域“得物”是一个绕不开的名字。用户在这里不仅交易商品更热衷于讨论潮流文化、单品鉴别、穿搭技巧。随之而来的是海量、复杂、且极具专业性的用户提问“这件外套的联名背景是什么”“如何鉴别这款鞋2023年和2024年版本的区别”“我身高180体重75kg穿这条裤子应该选什么码数”传统的单一路径检索比如只用关键词搜索商品详情页在这里频频失效。用户的一个问题往往需要拼接商品信息、社区帖子、鉴定报告、品牌历史乃至穿搭博主的经验分享才能完整回答。这不再是简单的“搜索-返回”而是一个需要理解意图、拆解问题、调度多种数据源、并组织成友好答案的复杂过程。这正是“复合检索 Agent”要解决的核心问题像一个精通潮流且耐心的专业顾问通过智能“体”Agent的协作完成对复杂问题的深度解答。最近像AgentScope、HarnessAgent这类框架的热度飙升正说明行业对构建此类可协作、可编排的智能体系统有着迫切需求。本次实践我们就以“得物知识问答”为场景深入拆解一个复合检索 Agent 系统的设计思路、核心模块与落地细节。你会发现它不仅仅是调用几个大模型接口那么简单而是一个涉及查询理解、路由决策、工具调用、结果合成与评估的完整系统工程。2. 系统核心设计思路与架构选型2.1 为什么是“复合检索”而非“单一搜索”首先要厘清概念。单一搜索例如基于 Elasticsearch 的关键词匹配其逻辑是“用户输入关键词 - 在倒排索引中匹配文档 - 按相关性排序返回”。这在问题明确、答案存在于单一文档时很有效。但在得物的场景下用户问题具有显著的复合性多意图复合一个问题可能包含多个子意图。例如“这款鞋的脚感如何以及适合什么季节穿”包含了“产品特性查询”和“使用场景建议”两个意图。多源数据复合答案的碎片可能散落在商品数据库SKU信息、社区UGC用户评测、鉴定库真伪细节、百科知识库品牌历史等多个异构数据源中。多模态复合用户可能上传一张图片问“这是正品吗”需要结合图像识别和文本知识进行回答。因此“复合检索”系统的设计目标是能够自动拆解复合问题并行或串行地查询多个最适合的数据源最后将碎片化信息整合成一个连贯、准确、有依据的答案。这本质上是一个规划与执行问题而 Agent智能体正是解决此类问题的范式。2.2 基于 Agent 范式的架构设计我们摒弃了传统的单体检索服务思路采用分层、模块化的智能体协作架构。核心思想是一个主控 AgentOrchestrator负责接收用户问题并制定解决计划然后调度一系列具备专项能力的子 Agent或工具去执行计划中的各个步骤最后汇总结果。下图展示了我们设计的核心系统架构用户提问 | [网关层] 请求接收、限流、鉴权 | [主控 Agent] (基于LLM) ├── 意图理解与问题拆解 ├── 检索策略规划路由 └── 子任务调度与监控 | [技能 Agent 池] (可动态注册) ├── 商品信息检索 Agent ├── 社区内容检索 Agent ├── 鉴定知识检索 Agent ├── 尺码推荐 Agent (含计算逻辑) └── 图像识别 Agent (如需) | [工具执行层] ├── 向量数据库 (用于语义检索社区、百科内容) ├── 关系型数据库 (用于精确查询商品、订单数据) ├── 搜索引擎 (用于关键词检索最新帖子) └── 外部API (如天气、物流) | [结果合成与校验 Agent] (基于LLM) ├── 多源信息去重、冲突检测 ├── 证据溯源与引用生成 └── 最终答案润色与格式化 | [输出] 结构化答案 (文本 可能的产品卡片、引用链接)架构选型背后的考量为什么用 Agent 框架而非硬编码用户问题的多样性和语言灵活性极高硬编码的 if-else 规则难以维护且扩展性差。Agent 框架如 AgentScope提供了智能体编排、消息传递、工具调用的基础能力让我们能更专注于业务逻辑而非通信机制。主控 Agent 为何必要它充当系统的“大脑”利用大语言模型LLM的推理能力将自然语言问题转化为结构化的执行计划Plan。例如面对“这双鞋偏码吗我平时穿42码”主控 Agent 会规划出a) 调用商品信息 Agent 获取该鞋款的标准尺码表b) 调用社区内容 Agent 搜索关于该鞋款“偏码”的用户评价c) 将两者信息传递给结果合成 Agent。技能 Agent 池化设计每个技能 Agent 职责单一如“只负责查商品”。这带来了高内聚、低耦合的好处便于独立开发、测试、更新和扩缩容。新的数据源或能力如接入价格历史趋势可以通过新增一个 Agent 快速集成。注意在框架选择上我们评估了多个方案。AgentScope因其对多智能体协作的原生支持、清晰的编程模型和良好的中文社区支持而被选用。HarnessAgent的理念也值得借鉴它更强调对智能体任务的“驾驭”和可靠性保障但其具体实现和生态在我们决策时尚未完全成熟。最终基于快速迭代和团队熟悉度我们选择了 AgentScope 作为基础框架进行二次开发。3. 核心模块深度解析与实现要点3.1 意图理解与查询重写模块这是整个系统的第一公里其准确性直接决定后续所有环节的成败。我们并未使用传统的分类模型而是充分利用了 LLM 的零样本/少样本能力。实现流程用户原始查询输入“求鉴定这双AJ1黑红脚趾鞋盒侧标钢印感觉有点模糊。”LLM 进行意图解析与标准化我们向 LLM 提供精心设计的 Prompt要求其输出结构化 JSON。{ core_intent: product_authentication, sub_intents: [check_box_label, check_steel_stamp], product_entity: {type: sneakers, brand: Air Jordan, model: 1 Retro High Black Toe}, query_rewrites: [ Air Jordan 1 黑红脚趾 鞋盒侧标 鉴定, AJ1 黑红脚趾 钢印 模糊 真伪, Nike Air Jordan 1 鞋盒标签 印刷质量 鉴别点 ] }关键参数解析同时我们会抽取关键参数如商品型号、品牌、用户提到的具体部位鞋盒侧标、钢印等这些参数将作为精准过滤条件传递给下游检索器。实操心得与避坑指南Prompt 工程是关键不要指望一个简单的“请分析意图”就能工作。我们的 Prompt 包含了角色设定“你是一名得物资深鉴定师”、输出格式约束、以及少样本示例few-shot examples。示例需要覆盖各类典型和边缘情况。处理模糊与歧义对于“椰子350灰橙怎么搭配”这类问题LLM 可能无法确定是问“Yeezy 350 V2 ‘Beluga 2.0’”还是“Yeezy 350 V2 ‘Hyperspace’”。此时策略是生成多个可能的实体并触发一个澄清对话 Agent与用户进行简短交互确认而不是盲目猜测。性能与成本平衡每次查询都调用高性能 LLM如 GPT-4成本过高。我们的策略是高频、常见的简单意图如“查价格”、“找链接”用微调的小模型或规则优先匹配复杂、长尾的查询才 fallback 到高性能 LLM。这需要对历史查询日志进行充分分析。3.2 智能路由与执行规划模块主控 Agent 拿到结构化的意图后需要决定“派谁去干活”以及“活的先后顺序”。这本质是一个动态的资源调度问题。路由策略设计我们实现了一个基于规则 模型评分的混合路由器。规则层处理明确场景。例如意图中包含“authenticate”或“鉴定”直接路由至鉴定知识检索 Agent包含“size”或“尺码”则路由至尺码推荐 Agent。模型评分层对于复合意图或规则无法覆盖的情况采用一个轻量级文本匹配模型如 Sentence-BERT计算用户查询与每个技能 Agent 能力描述之间的语义相似度。例如“这款羽绒服的保暖材料是什么科技”与商品信息检索 Agent描述为“查询商品材质、工艺、技术参数”的相似度会高于社区内容检索 Agent描述为“查询用户真实评价、穿搭分享”。执行规划的实现规划结果是一个有向无环图DAG定义了子任务间的依赖关系。并行任务彼此独立的任务可并行执行以降低延迟。例如查询商品官方信息和搜索社区评价可以同时进行。串行任务有依赖关系的任务需串行。例如尺码推荐 Agent需要先等待商品信息检索 Agent返回该款式的尺码表再结合用户的身体数据需询问或从历史中获取进行计算。# 伪代码示例基于 AgentScope 的任务规划 plan { tasks: [ { id: task_1, agent: product_info_agent, input: {product_name: Air Jordan 1 Black Toe, fields: [size_chart, material]}, dependencies: [] }, { id: task_2, agent: community_agent, input: {query_rewrites: [AJ1 黑红脚趾 尺码 偏大 偏小], max_results: 5}, dependencies: [] }, { id: task_3, agent: size_recommendation_agent, input: {user_stats: {height: 180, weight: 75}, product_size_chart: {{task_1.output.size_chart}}}, dependencies: [task_1] # 依赖 task_1 的结果 } ] }3.3 多源检索器的设计与优化不同的数据源需要不同的检索技术混合使用才能达到最佳效果。商品/订单结构化数据使用精确查询 条件过滤。直接通过商品ID、SKU或精确的品牌型号名查询数据库。这里的关键是实体链接的准确性确保从文本中抽取出的“AJ1黑红脚趾”能正确映射到数据库中的唯一商品ID。社区帖子、鉴定报告等文本内容采用向量语义检索。我们将所有社区精华帖、鉴定案例的文本内容通过 Embedding 模型如bge-large-zh向量化存入向量数据库如 Milvus、Chroma。检索时将用户查询或重写后的查询也转化为向量进行相似度搜索。这对于查找“主观评价”、“穿搭心得”等语义相关但关键词不匹配的内容至关重要。优化点单纯语义检索可能召回无关结果。我们采用“向量检索 关键词 BM25 二次过滤”的混合搜索Hybrid Search。先通过向量检索召回 Top-K 个相关文档再用 BM25 根据具体关键词如“钢印模糊”进行重排序兼顾语义相关性和关键词重要性。实时、热门内容对于“最近这款鞋行情如何”这类问题需要最新的帖子。我们维护了一个近期的时间索引对社区新内容进行近实时索引检索时优先按时间排序确保答案的时效性。检索结果的质量控制每个检索器返回的结果都附带一个置信度分数。这个分数由多种因素综合计算匹配分数如向量相似度、来源权威性官方商品页 vs 普通用户帖、内容新鲜度等。低置信度的结果会在合成阶段被降权或过滤。3.4 结果合成、溯源与答案生成这是“临门一脚”将碎片信息整合成用户可读的答案。我们部署了一个专用的“合成 Agent”它同样基于 LLM。合成 Agent 的工作流信息收集与去重接收来自各个技能 Agent 的原始结果文本片段、数据、链接。冲突检测与解决例如商品页说“标准尺码”但三个社区帖子两个说“偏大半码”一个说“正常”。合成 Agent 会识别这一冲突并在答案中客观呈现“官方标注为标准尺码但部分用户约占反馈的60%反映此鞋款可能偏大半码建议您参考下方具体用户评价。”证据溯源与引用这是建立信任的关键。合成 Agent 必须在生成的答案中为每一个关键事实陈述注明来源。例如“根据得物商品页面信息这款羽绒服采用 Gore-Tex 面料...根据用户‘潮流玩家小明’的社区分享他认为在零下5度穿着足够保暖...”。我们强制要求合成 Agent 以[来源x]的格式插入引用标记并在答案末尾列出详细的来源列表。答案结构化与润色根据问题类型采用不同的模板。对于鉴定类问题答案结构为“结论真/假/存疑 - 关键鉴别点分析图文对照 - 建议如补图”对于搭配类问题则可能是“风格建议 - 单品推荐 - 注意事项”。LLM 负责在模板框架内进行自然语言润色使回答亲切、专业。重要提示必须对合成 Agent 进行严格的“幻觉”抑制。在 Prompt 中明确指令“仅基于提供的信息生成答案对不知道的信息明确回答‘未找到相关信息’”。同时可以引入一个轻量级的事实核查步骤用关键事实在原始检索结果中进行二次匹配验证。4. 系统实现中的关键挑战与解决方案4.1 延迟与性能优化一个复合检索涉及多次 LLM 调用和外部检索延迟容易累积。我们的优化策略并行化与异步所有独立的子任务如调用不同数据源的 Agent全部异步并行执行。缓存策略LLM 结果缓存对频繁出现的、确定性高的用户查询如“AJ1黑红脚趾发售价格”将其意图解析和最终答案进行缓存。向量检索缓存对常见的查询 Embedding 和其 Top-K 结果进行缓存。数据库查询缓存对商品基础信息等变更不频繁的数据使用应用层缓存。LLM 调用优化使用流式响应Streaming让用户尽快看到部分答案对于非关键路径的 LLM 调用如答案润色可以考虑使用更小、更快的模型。4.2 稳定性与错误处理分布式 Agent 系统的一个挑战是局部失败可能导致整个流程阻塞。Agent 超时与重试为每个 Agent 调用设置合理的超时时间。对于因网络抖动导致的失败进行有限次数的指数退避重试。降级方案当某个关键 Agent如商品信息 Agent不可用时系统应能降级。例如转而从社区内容中寻找可能包含商品信息的帖子进行提取并在答案中说明“商品官方信息暂不可用以下信息整理自用户社区”。熔断机制监控每个技能 Agent 的失败率当超过阈值时暂时熔断对该 Agent 的调用直接返回降级结果或提示用户稍后再试。4.3 评估与持续迭代如何衡量这个系统的效果我们建立了多维度评估体系人工评估黄金标准定期抽样一批真实用户问题由专业运营或鉴定师标注标准答案与系统答案进行对比从“准确性”、“完整性”、“有用性”、“流畅性”四个维度打分。自动评估指标检索相关性评估召回片段的 MRR平均倒数排名、NDCG归一化折损累计增益。答案质量使用 ROUGE、BLEU 对比生成答案与人工答案的相似度仅供参考因答案可多样化。业务指标跟踪用户满意度调查如有、问题解决率用户未在首次回答后继续追问的比例、以及用户对答案中“引用来源”的点击率衡量溯源价值。数据飞轮将系统回答后用户的正/负反馈如点赞、点踩、继续追问作为强化学习信号用于持续优化路由策略和合成 Agent 的 Prompt。5. 典型问题排查与实战技巧实录在实际开发和运维中我们遇到了不少典型问题以下是部分实录问题1用户问题“这款鞋的鞋底软吗”系统错误地路由到了“商品信息Agent”只返回了官方材质橡胶而用户想了解的是“脚感”。排查检查意图理解模块的输出发现“软”这个词被归类到了“材质/特性”意图。查看路由规则该意图确实指向了商品信息。解决优化意图分类的 Prompt增加对“主观感受”、“体验”类词汇的识别。同时在路由层增加一个“用户反馈”意图当查询中包含“感觉”、“软硬”、“磨不磨脚”等词时优先路由到“社区内容检索Agent”。这是一个持续进行词库和规则维护的过程。问题2合成答案偶尔会出现“幻觉”编造了不存在的商品特性。排查发现当检索器返回的证据过于碎片化或模糊时LLM 在“填空”时容易过度发挥。解决采取了组合拳。第一强化合成 Agent 的 Prompt加入更严厉的约束“如果信息不明确就说‘根据现有信息无法确定’”。第二在合成前增加一个“证据充分性检查”步骤如果所有证据片段的置信度都低于某个阈值则直接触发“澄清对话”或回答“信息不足”。第三对生成答案中的关键实体如科技名称“Zoom Air”进行回标检查是否在证据中出现过。问题3在流量高峰时系统整体响应时间变长。排查通过链路追踪发现瓶颈在于向量数据库的检索耗时和 LLM 的排队耗时。解决对于向量数据库我们实施了预计算索引策略对热门商品相关的社区内容提前计算好其向量并建立专属的、更小的索引集加速检索。对于 LLM我们根据业务优先级设置了不同的队列问答系统的优先级高于内容生成等后台任务并设置了动态限流。问题4如何应对“超纲”问题比如用户问“这双鞋的投资价值如何”解决这是定义系统边界的问题。我们在主控 Agent 中设置了一个“意图过滤器”明确系统能处理的意图范围商品咨询、鉴定、搭配、尺码等。对于明确超出范围或涉及投资建议、医疗建议等敏感领域的问题系统会友好地拒绝并引导用户到相关社区板块或提示“此问题已超出当前助手的能力范围”。构建一个高效的复合检索 Agent 系统是一个不断在“智能”与“可控”、“灵活”与“稳定”之间寻找平衡的过程。它不是一个一劳永逸的项目而是一个需要持续喂养数据、观察效果、迭代优化的智能系统。从这次实践来看以 Agent 的视角来构建复杂问答系统不仅大幅提升了回答复杂问题的能力其模块化的设计也为未来接入更多数据源和能力如多模态理解、个性化推荐奠定了坚实的基础。
完全指南：从语法到实战配置)
