1. 项目概述当搜索代理需要提问时最近在折腾大语言模型LLM驱动的搜索代理时我反复遇到一个核心痛点“它太自信了自信到经常答非所问。”比如你问“帮我找一下苹果的最新财报”它可能直接给你一份“Apple Inc.”的文档完全没意识到你可能指的是“苹果公司”还是“苹果水果市场报告”。这种缺乏交互、一锤子买卖的搜索方式在复杂、模糊或专业化的查询面前显得力不从心。这正是“When Search Agents Should Ask: DiscoBench for Clarification-Aware Deep Search”这个项目标题直指的核心问题——我们需要让搜索代理学会在关键时刻“提问”进行澄清式交互从而实现更深层、更精准的搜索。简单来说这不是在做一个更快的搜索引擎而是在打造一个更“聪明”的搜索伙伴。它不再满足于被动地解析你的初始查询而是具备主动澄清意图的能力。当你的问题存在歧义、信息不足或隐含复杂上下文时一个具备“Clarification-Aware”澄清感知能力的搜索代理会停下来通过生成一个或多个澄清问题与你互动比如“您指的是科技公司苹果还是水果品种苹果”或者“您需要的是年度财报还是季度财报摘要”。在获得你的明确反馈后它再进行深度搜索Deep Search整合多源信息最终给出精准答案。这个过程我们称之为“Clarification-Aware Deep Search”。而“DiscoBench”则是为了系统评估这种能力而构建的一个基准测试框架。你可以把它想象成一个“考场”专门用来考校各种搜索代理模型在面临模糊查询时其提问澄清的质量、必要性判断以及最终答案的准确性。没有好的评估就无法推动技术进步。DiscoBench的出现正是为了填补这一空白为社区提供一个标准化的“尺子”来衡量和比较不同搜索代理的澄清感知与深度搜索性能。这对于研究者优化模型、对于开发者选择技术路线都至关重要。2. 核心思路与架构设计拆解要让搜索代理学会“该问时才问”并且“问得好”这背后是一套复杂的决策与执行链条。我们不能让代理对每个简单问题都提问那会严重损害用户体验也不能在关键歧义点沉默导致搜索失败。整个系统的设计需要平衡智能、效率与用户体验。2.1 澄清感知决策模块判断“何时该问”这是整个系统的“大脑”和“守门员”。它的核心任务是分析用户初始查询判断当前信息是否足以进行有效搜索或者是否存在必须通过交互来消除的歧义。决策依据通常基于多维度分析命名实体歧义如“苹果”、“Java”、“Python”等一词多义的情况。系统需要调用实体链接或知识库判断查询中的实体是否存在多个高概率的指代项。查询完整性用户查询是否包含了完成任务的所有必要参数例如“预订机票”缺少时间、目的地“比较两款手机”缺少具体型号。这需要模型理解任务的领域框架Schema。上下文缺失与隐含需求查询可能表面清晰但隐含了未声明的偏好或约束。例如“推荐一部电影”隐含了用户的历史喜好、当前心情等未说明的上下文。查询的模糊性与特异性通过分析查询词的分布、句法结构和语义密度判断查询是宽泛如“人工智能”还是具体如“Transformer模型在BERT中的具体实现”。过于宽泛的查询可能也需要引导。技术实现上这个模块通常由一个经过微调的LLM担任其输入是用户查询和可能的会话历史输出是一个结构化决策需要澄清或直接搜索。如果是需要澄清还需附带一个“歧义类型”标签和生成澄清问题所需的关键信息点如歧义实体列表、缺失参数槽位。实操心得训练这个决策模型时最大的挑战是数据。你需要大量带有“是否需要澄清”标注的查询数据。一个实用的技巧是利用公开的论坛数据如Stack Exchange将问题标题视为初始查询将问题正文中补充的细节视为“用户本应提供但未提供”的信息从而反向构建训练样本。这能有效模拟真实世界中用户提问不完整的场景。2.2 澄清问题生成模块解决“如何问得好”一旦决策模块判定需要澄清接力棒就交给了澄清问题生成模块。生成一个好的澄清问题绝非易事它需要满足几个条件清晰无歧义、选项完备且互斥、引导性强、符合自然对话习惯。生成策略主要有两种基于模板的生成预先为常见的歧义类型如实体歧义、参数缺失设计问题模板。例如对于实体歧义“您指的是[选项A]还是[选项B]”对于缺失参数“请问您的[参数名如出发日期]是什么”。这种方法可控性强、生成稳定但灵活性和覆盖面有限。基于LLM的开放式生成直接提示LLM根据查询和决策模块提取的歧义信息生成自然语言的澄清问题。例如输入“用户查询‘我想了解苹果的供应链’。经检测‘苹果’存在歧义可能指1. 苹果公司Apple Inc. 2. 水果苹果。请生成一个澄清问题。” LLM可能输出“请问您想了解的是科技公司苹果的供应链还是作为水果的苹果的产业链情况” 这种方法更灵活、更自然但对模型能力要求高且需要精心设计提示词Prompt来控制生成质量。在DiscoBench的评估框架下会对生成的问题进行多维度打分相关性是否针对核心歧义、有效性提供的选项是否覆盖了主要可能性、流畅性是否自然易懂以及信息量是否提供了足够背景帮助用户选择。2.3 深度搜索执行与答案合成模块完成“问后如何搜”用户回答澄清问题后系统获得了消歧后的、信息更完备的查询。此时便进入深度搜索阶段。这里的“深度”体现在两个方面搜索过程的深度不再是简单的关键词匹配。代理可能会将复杂查询分解成多个子问题进行多轮、多步骤的搜索例如先搜索概念定义再搜索最新进展最后搜索相关案例。这涉及到规划Planning和工具调用Tool Use能力。信息处理的深度代理需要从多个来源网页、文档、数据库、API检索信息并进行批判性评估、信息去重、证据关联和逻辑合成最终生成一个连贯、准确、有据可查的答案而不仅仅是罗列链接。技术栈上这个模块通常是一个强大的LLM作为“控制器”配合一系列工具如网络搜索API、知识图谱查询、专业数据库接口和长期记忆。控制器根据消歧后的查询制定计划调用工具获取信息并不断评估信息的充分性和可靠性循环此过程直至满足答案生成条件。注意事项深度搜索非常消耗计算资源和时间。必须设计超时机制和“优雅降级”策略。当搜索过程过于复杂或耗时过长时系统应能部分回答或告知用户进度而不是让用户无限等待。同时所有引用的信息源必须可追溯这对建立信任至关重要。2.4 DiscoBench评估框架设计解析DiscoBench作为基准测试其设计哲学是全面、公平、可复现。它不仅仅看最终答案对不对更要看澄清过程好不好。其评估体系通常包含三个层次澄清必要性识别准确率给定一个查询模型是否能正确判断“需要/不需要”澄清这是二分类任务可以用准确率、F1值来衡量。测试集会包含大量精心设计的模糊查询和清晰查询。澄清问题质量评估对于需要澄清的查询模型生成的问题质量如何这通常采用人工评估与自动指标结合的方式。自动指标可能包括与标准问题的相似度如BLEU, ROUGE但更重要的是基于LLM的评估器从相关性、有用性等维度进行打分。端到端任务完成度从模糊查询开始经过可能的澄清交互到最终给出答案整个流程的成功率如何评估标准包括最终答案的准确性与标准答案对比、信息完整性以及效率交互轮次、总耗时。测试集的构建是DiscoBench的核心价值。它需要覆盖多种歧义类型词汇、实体、范围、意图等、多个领域科技、医疗、金融、日常等以及不同的查询复杂度。一个高质量的测试集往往通过众包平台收集真实模糊查询或通过规则与LLM结合的方式自动生成并筛选。3. 关键技术实现与核心环节理解了整体架构我们深入到几个关键的技术实现环节。这些环节决定了系统是“花架子”还是“真有用”。3.1 基于LLM的歧义检测与分类实现决策模块的核心是一个分类器。虽然可以用传统的机器学习模型但利用LLM的零样本/少样本能力进行推理在当前阶段更为灵活和强大。一个典型的实现流程如下提示词工程设计一个结构化的提示词Prompt引导LLM扮演一个“查询分析员”。你是一个专业的搜索查询分析员。请分析以下用户查询判断其是否包含可能影响搜索结果的重大歧义或信息缺失。你的任务输出严格的JSON格式 { need_clarification: true/false, ambiguity_type: none/entity/scope/parameter_missing/..., ambiguous_entities: [实体1, 实体2, ...], // 如果存在实体歧义 missing_parameters: [参数名1, 参数名2, ...], // 如果存在参数缺失 reason: 简要说明判断理由 } 查询[用户查询]调用与解析将用户查询填入提示词调用LLM API如GPT-4, Claude-3。由于需要稳定的结构化输出必须使用支持JSON模式JSON mode的模型或通过后处理确保输出能被解析。置信度校准LLM的输出可能存在不确定性。可以并行调用多次如3次采用“自洽性”Self-Consistency投票或者让LLM同时输出一个置信度分数只有当置信度高于阈值且判定为需要澄清时才触发后续流程。这能有效减少误判。参数与技巧温度Temperature在决策任务中应设置为较低值如0.1或0以确保输出的确定性和一致性。系统提示System Prompt在对话API中系统提示可以更稳固地定义角色和任务规则比在用户提示中反复说明更有效。后处理对LLM输出的ambiguity_type等进行标准化映射防止其创造过多新类别便于后续处理。3.2 高效且自然的澄清问题生成策略生成模块的目标是产生用户友好、高效的问题。结合模板与LLM的混合策略往往效果最佳。混合策略工作流歧义路由根据决策模块输出的ambiguity_type将查询路由到不同的处理通道。模板优先对于高度结构化的歧义如“参数缺失”直接调用预定义的模板库生成问题。例如对于缺失“出发日期”模板可能是“请问您的出发日期是哪一天”LLM兜底与优化对于复杂的、非结构化的歧义如“范围模糊”、“隐含假设冲突”或者当模板生成的问题不够自然时调用LLM生成。此时提示词需要包含更丰富的上下文背景用户查询“[用户查询]”存在[歧义类型]歧义。具体来说[根据决策模块输出填充的详细歧义描述如“实体‘苹果’可能指代A或B”]。 任务请你以搜索引擎助手的身份生成一个简洁、清晰、友好的澄清问题帮助用户明确意图。问题应提供明确的选项如果适用并易于用户快速回答。 请直接输出澄清问题不要额外解释。选项生成与排序对于实体歧义需要生成候选实体列表。这可以通过查询知识图谱如Wikidata、利用词向量相似度从大规模实体库中检索或再次调用LLM来生成。生成的候选列表需要按相关性排序通常只展示前2-3个最可能的选项并提供一个“其他”的开放式入口以平衡效率与覆盖率。实操心得澄清问题切忌冗长和包含专业术语。例如与其问“您指的是‘Malus domestica’栽培苹果的供应链还是‘Apple Inc.’纳斯达克AAPL的供应链”不如问“您想了解水果苹果还是苹果公司”同时避免提出让用户难以回答的开放性问题如“您具体想了解苹果的什么”这会让用户感到困惑。好的澄清问题是选择题或填空题。3.3 深度搜索的规划与执行引擎这是搜索代理的“四肢”。一个典型的规划-执行循环如下查询理解与计划制定消歧后的查询被送入“规划器”通常是一个LLM。规划器将复杂任务分解为一系列可执行的子任务或称“工具调用”。输入任务基于用户澄清后的意图‘比较iPhone 15 Pro和三星Galaxy S24 Ultra的摄像头性能’请制定一个分步搜索计划。输出结构化{ plan: [ {step: 1, action: search, query: iPhone 15 Pro 摄像头规格 传感器尺寸 像素}, {step: 2, action: search, query: 三星Galaxy S24 Ultra 摄像头规格 传感器尺寸 像素}, {step: 3, action: search, query: iPhone 15 Pro vs Galaxy S24 Ultra 摄像头 对比评测 2024}, {step: 4, action: synthesize, goal: 从规格、样张、评测观点三个方面对比总结} ] }工具调用与信息获取执行器根据计划按顺序调用相应的工具。最核心的工具是网络搜索API如Serper, Tavily, Google Search API。调用时需要精心构造搜索Query并设置合理的返回结果数量如5-10条。除了搜索还可能调用计算器、代码解释器、专业数据库API等。信息评估与迭代获取搜索结果通常是网页摘要或片段后需要一个“评估器”来判断信息是否足够、是否相关、是否可靠。这个评估器也可以是LLM其任务是对每条信息进行评分或分类。如果当前步骤的信息质量未达到阈值规划器可能需要调整搜索词或增加一个补充搜索步骤。答案合成与溯源当所有计划步骤完成或达到迭代上限时将所有收集到的、经过筛选的信息片段和原始来源连同原始任务一起提交给“合成器”一个LLM要求其生成最终答案。关键点必须强制合成器在答案中引用来源例如使用上标[1]并在末尾列出参考文献。这不仅是学术规范更是产品可信度的基石。性能考量深度搜索的延迟主要来自LLM的多次调用和网络搜索的耗时。可以采用异步并行调用如并行执行多个不依赖的搜索步骤、缓存频繁出现的查询结果、以及对非关键路径使用较小、较快的模型等策略来优化。4. 基于DiscoBench的评估实践与问题排查当我们自己构建或选择一个澄清感知搜索代理时如何用DiscoBench的思路来评估它这里分享一套可落地的评估方法和常见问题。4.1 构建内部评估测试集即使不使用官方的DiscoBench你也可以构建一个针对自己业务场景的小型测试集。步骤收集种子查询从你的产品日志、客服对话、用户反馈中收集那些经常被误解或需要后续追问的查询。这是最宝贵的资源。分类与标注人工或借助LLM将这些查询分类如实体歧义、意图模糊、参数缺失等并为每个需要澄清的查询编写1-3个“标准澄清问题”和“消歧后的理想答案”。补充对抗性样本故意构造一些边界清晰的查询用于测试代理是否“过度提问”。同时构造一些极其模糊的查询测试其澄清能力的上限。设计评估指标澄清准确率代理在需要/不需要澄清的查询上判断正确的比例。问题相关性人工评分随机抽取一批生成的澄清问题让评估者可以是团队成员在1-5分制下打分。任务成功率从模糊查询开始到获得满意答案对比标准答案的端到端成功率。可以细分为“经过澄清后成功”和“无需澄清直接成功”两种情况。4.2 典型问题与调试技巧在实际运行中你肯定会遇到各种问题。下面是一个常见问题排查表问题现象可能原因排查与解决思路代理从不提问总是直接搜索1. 决策模块的LLM提示词过于保守或偏向行动。2. 决策置信度阈值设置过高。3. 训练/微调数据中“需要澄清”的样本不足或质量不高。1. 调整提示词强调“当存在任何不确定性时优先澄清”。在系统提示中明确角色“你是一个谨慎的助手在行动前会确保理解正确。”2. 降低触发澄清的置信度阈值。3. 补充更多模糊查询的样本并在微调时给予更高权重。代理提问过于频繁甚至对清晰问题也提问1. 决策模块过于敏感将简单查询中的正常词汇变化误判为歧义。2. 澄清生成模块产生的选项质量差误导了决策。3. 缺乏对清晰查询的识别能力。1. 在决策提示词中加入反面示例“以下查询是清晰的不应提问[示例]”。2. 加强候选实体生成的准确性使用更可靠的知识源进行消歧。3. 在测试集中增加大量清晰查询并确保决策模型能正确识别它们。生成的澄清问题模糊、冗长或难以回答1. 生成模型的提示词指令不明确。2. 模型本身能力不足如使用了较小的模型。3. 提供给生成模型的歧义信息本身就不清晰。1. 优化生成提示词使用“角色-任务-约束”格式明确要求“问题简短”、“选项明确”、“易于回答”。2. 升级生成模型或在关键环节使用更大规模的模型。3. 检查决策模块的输出确保ambiguous_entities或missing_parameters字段是具体、准确的。澄清交互后最终答案仍不准确1. 深度搜索模块的规划能力不足未能制定有效的搜索策略。2. 搜索API返回的结果质量差或无关。3. 信息合成模块未能有效整合和推理多源信息。1. 为规划器提供更详细的工具描述和成功案例Few-shot Learning提升其分解任务的能力。2. 优化搜索Query构造策略尝试不同的搜索API并对结果进行更严格的相关性过滤。3. 在合成答案时要求模型“基于以下证据逐条推理”并提供所有检索到的文本片段作为上下文强制其进行证据引用。系统响应速度慢用户体验差1. 串行执行规划-搜索-评估-合成循环延迟累积。2. 使用的LLM模型过大推理耗时。3. 网络搜索API延迟高。1. 分析任务依赖图将可以并行的搜索步骤改为异步并行执行。2. 实施模型级联用快模型做决策和简单生成用大模型做复杂规划和最终合成。3. 为搜索API设置合理的超时时间并考虑使用多个备用API源。引入缓存层对相同或相似的搜索Query结果进行短期缓存。4.3 关于“Chimera”多智能体服务框架的联想在搜索热词中出现的“chimera: latency- and performance-aware multi-agent serving for heterogeneous llms”虽然与DiscoBench的评估焦点不同但它指向了实现高性能搜索代理的另一个关键基础设施层面。你可以这样理解它们的关系DiscoBench定义了“考什么”评估澄清感知搜索的能力而Chimera这类框架解决了“怎么考得又快又好”高效、低延迟地调度异构LLM来执行这些智能体任务。在一个复杂的澄清感知搜索代理中我们可能同时用到一个小型、快速的模型如Phi-3, Qwen2.5-7B来处理初始查询分类和简单的澄清生成。一个大型、能力强的模型如GPT-4, Claude-3 Opus来处理复杂的任务规划、多步推理和最终答案合成。甚至多个 specialized 模型分别处理不同领域的消歧。“Chimera”所关注的延迟与性能感知的异构LLM多智能体服务正是为了优化这种混合部署。它需要智能地路由请求将决策任务发给快模型将合成任务发给强模型管理多个模型的加载与卸载进行批处理以提升吞吐量并监控每个环节的延迟确保整个系统的端到端响应时间在可接受范围内例如一次完整的澄清交互在数秒内完成。因此当你基于DiscoBench的指导设计好智能体的逻辑后若想将其投入实际应用就必须考虑类似Chimera的工程架构问题。否则一个再聪明的代理如果每次响应都要几十秒也毫无用户体验可言。构建一个真正实用的澄清感知深度搜索代理是一条融合了自然语言理解、对话管理、信息检索和系统工程的漫漫长路。DiscoBench为我们提供了清晰的评估坐标而实现过程则充满了对细节的打磨和对权衡的考量。从我个人的实践来看启动时不必追求大而全可以从一个垂直领域如科技产品查询入手构建一个最小可行产品重点打磨“何时问”和“如何问”的体验再逐步扩展搜索深度和领域范围。记住每一次成功的澄清不仅是获取了更准确的信息更是与用户建立了一次有效的沟通这或许是智能搜索体验超越传统搜索的最重要一步。 LLM搜索代理如何学会提问？DiscoBench基准与澄清感知深度搜索实践
1. 项目概述当搜索代理需要提问时最近在折腾大语言模型LLM驱动的搜索代理时我反复遇到一个核心痛点“它太自信了自信到经常答非所问。”比如你问“帮我找一下苹果的最新财报”它可能直接给你一份“Apple Inc.”的文档完全没意识到你可能指的是“苹果公司”还是“苹果水果市场报告”。这种缺乏交互、一锤子买卖的搜索方式在复杂、模糊或专业化的查询面前显得力不从心。这正是“When Search Agents Should Ask: DiscoBench for Clarification-Aware Deep Search”这个项目标题直指的核心问题——我们需要让搜索代理学会在关键时刻“提问”进行澄清式交互从而实现更深层、更精准的搜索。简单来说这不是在做一个更快的搜索引擎而是在打造一个更“聪明”的搜索伙伴。它不再满足于被动地解析你的初始查询而是具备主动澄清意图的能力。当你的问题存在歧义、信息不足或隐含复杂上下文时一个具备“Clarification-Aware”澄清感知能力的搜索代理会停下来通过生成一个或多个澄清问题与你互动比如“您指的是科技公司苹果还是水果品种苹果”或者“您需要的是年度财报还是季度财报摘要”。在获得你的明确反馈后它再进行深度搜索Deep Search整合多源信息最终给出精准答案。这个过程我们称之为“Clarification-Aware Deep Search”。而“DiscoBench”则是为了系统评估这种能力而构建的一个基准测试框架。你可以把它想象成一个“考场”专门用来考校各种搜索代理模型在面临模糊查询时其提问澄清的质量、必要性判断以及最终答案的准确性。没有好的评估就无法推动技术进步。DiscoBench的出现正是为了填补这一空白为社区提供一个标准化的“尺子”来衡量和比较不同搜索代理的澄清感知与深度搜索性能。这对于研究者优化模型、对于开发者选择技术路线都至关重要。2. 核心思路与架构设计拆解要让搜索代理学会“该问时才问”并且“问得好”这背后是一套复杂的决策与执行链条。我们不能让代理对每个简单问题都提问那会严重损害用户体验也不能在关键歧义点沉默导致搜索失败。整个系统的设计需要平衡智能、效率与用户体验。2.1 澄清感知决策模块判断“何时该问”这是整个系统的“大脑”和“守门员”。它的核心任务是分析用户初始查询判断当前信息是否足以进行有效搜索或者是否存在必须通过交互来消除的歧义。决策依据通常基于多维度分析命名实体歧义如“苹果”、“Java”、“Python”等一词多义的情况。系统需要调用实体链接或知识库判断查询中的实体是否存在多个高概率的指代项。查询完整性用户查询是否包含了完成任务的所有必要参数例如“预订机票”缺少时间、目的地“比较两款手机”缺少具体型号。这需要模型理解任务的领域框架Schema。上下文缺失与隐含需求查询可能表面清晰但隐含了未声明的偏好或约束。例如“推荐一部电影”隐含了用户的历史喜好、当前心情等未说明的上下文。查询的模糊性与特异性通过分析查询词的分布、句法结构和语义密度判断查询是宽泛如“人工智能”还是具体如“Transformer模型在BERT中的具体实现”。过于宽泛的查询可能也需要引导。技术实现上这个模块通常由一个经过微调的LLM担任其输入是用户查询和可能的会话历史输出是一个结构化决策需要澄清或直接搜索。如果是需要澄清还需附带一个“歧义类型”标签和生成澄清问题所需的关键信息点如歧义实体列表、缺失参数槽位。实操心得训练这个决策模型时最大的挑战是数据。你需要大量带有“是否需要澄清”标注的查询数据。一个实用的技巧是利用公开的论坛数据如Stack Exchange将问题标题视为初始查询将问题正文中补充的细节视为“用户本应提供但未提供”的信息从而反向构建训练样本。这能有效模拟真实世界中用户提问不完整的场景。2.2 澄清问题生成模块解决“如何问得好”一旦决策模块判定需要澄清接力棒就交给了澄清问题生成模块。生成一个好的澄清问题绝非易事它需要满足几个条件清晰无歧义、选项完备且互斥、引导性强、符合自然对话习惯。生成策略主要有两种基于模板的生成预先为常见的歧义类型如实体歧义、参数缺失设计问题模板。例如对于实体歧义“您指的是[选项A]还是[选项B]”对于缺失参数“请问您的[参数名如出发日期]是什么”。这种方法可控性强、生成稳定但灵活性和覆盖面有限。基于LLM的开放式生成直接提示LLM根据查询和决策模块提取的歧义信息生成自然语言的澄清问题。例如输入“用户查询‘我想了解苹果的供应链’。经检测‘苹果’存在歧义可能指1. 苹果公司Apple Inc. 2. 水果苹果。请生成一个澄清问题。” LLM可能输出“请问您想了解的是科技公司苹果的供应链还是作为水果的苹果的产业链情况” 这种方法更灵活、更自然但对模型能力要求高且需要精心设计提示词Prompt来控制生成质量。在DiscoBench的评估框架下会对生成的问题进行多维度打分相关性是否针对核心歧义、有效性提供的选项是否覆盖了主要可能性、流畅性是否自然易懂以及信息量是否提供了足够背景帮助用户选择。2.3 深度搜索执行与答案合成模块完成“问后如何搜”用户回答澄清问题后系统获得了消歧后的、信息更完备的查询。此时便进入深度搜索阶段。这里的“深度”体现在两个方面搜索过程的深度不再是简单的关键词匹配。代理可能会将复杂查询分解成多个子问题进行多轮、多步骤的搜索例如先搜索概念定义再搜索最新进展最后搜索相关案例。这涉及到规划Planning和工具调用Tool Use能力。信息处理的深度代理需要从多个来源网页、文档、数据库、API检索信息并进行批判性评估、信息去重、证据关联和逻辑合成最终生成一个连贯、准确、有据可查的答案而不仅仅是罗列链接。技术栈上这个模块通常是一个强大的LLM作为“控制器”配合一系列工具如网络搜索API、知识图谱查询、专业数据库接口和长期记忆。控制器根据消歧后的查询制定计划调用工具获取信息并不断评估信息的充分性和可靠性循环此过程直至满足答案生成条件。注意事项深度搜索非常消耗计算资源和时间。必须设计超时机制和“优雅降级”策略。当搜索过程过于复杂或耗时过长时系统应能部分回答或告知用户进度而不是让用户无限等待。同时所有引用的信息源必须可追溯这对建立信任至关重要。2.4 DiscoBench评估框架设计解析DiscoBench作为基准测试其设计哲学是全面、公平、可复现。它不仅仅看最终答案对不对更要看澄清过程好不好。其评估体系通常包含三个层次澄清必要性识别准确率给定一个查询模型是否能正确判断“需要/不需要”澄清这是二分类任务可以用准确率、F1值来衡量。测试集会包含大量精心设计的模糊查询和清晰查询。澄清问题质量评估对于需要澄清的查询模型生成的问题质量如何这通常采用人工评估与自动指标结合的方式。自动指标可能包括与标准问题的相似度如BLEU, ROUGE但更重要的是基于LLM的评估器从相关性、有用性等维度进行打分。端到端任务完成度从模糊查询开始经过可能的澄清交互到最终给出答案整个流程的成功率如何评估标准包括最终答案的准确性与标准答案对比、信息完整性以及效率交互轮次、总耗时。测试集的构建是DiscoBench的核心价值。它需要覆盖多种歧义类型词汇、实体、范围、意图等、多个领域科技、医疗、金融、日常等以及不同的查询复杂度。一个高质量的测试集往往通过众包平台收集真实模糊查询或通过规则与LLM结合的方式自动生成并筛选。3. 关键技术实现与核心环节理解了整体架构我们深入到几个关键的技术实现环节。这些环节决定了系统是“花架子”还是“真有用”。3.1 基于LLM的歧义检测与分类实现决策模块的核心是一个分类器。虽然可以用传统的机器学习模型但利用LLM的零样本/少样本能力进行推理在当前阶段更为灵活和强大。一个典型的实现流程如下提示词工程设计一个结构化的提示词Prompt引导LLM扮演一个“查询分析员”。你是一个专业的搜索查询分析员。请分析以下用户查询判断其是否包含可能影响搜索结果的重大歧义或信息缺失。你的任务输出严格的JSON格式 { need_clarification: true/false, ambiguity_type: none/entity/scope/parameter_missing/..., ambiguous_entities: [实体1, 实体2, ...], // 如果存在实体歧义 missing_parameters: [参数名1, 参数名2, ...], // 如果存在参数缺失 reason: 简要说明判断理由 } 查询[用户查询]调用与解析将用户查询填入提示词调用LLM API如GPT-4, Claude-3。由于需要稳定的结构化输出必须使用支持JSON模式JSON mode的模型或通过后处理确保输出能被解析。置信度校准LLM的输出可能存在不确定性。可以并行调用多次如3次采用“自洽性”Self-Consistency投票或者让LLM同时输出一个置信度分数只有当置信度高于阈值且判定为需要澄清时才触发后续流程。这能有效减少误判。参数与技巧温度Temperature在决策任务中应设置为较低值如0.1或0以确保输出的确定性和一致性。系统提示System Prompt在对话API中系统提示可以更稳固地定义角色和任务规则比在用户提示中反复说明更有效。后处理对LLM输出的ambiguity_type等进行标准化映射防止其创造过多新类别便于后续处理。3.2 高效且自然的澄清问题生成策略生成模块的目标是产生用户友好、高效的问题。结合模板与LLM的混合策略往往效果最佳。混合策略工作流歧义路由根据决策模块输出的ambiguity_type将查询路由到不同的处理通道。模板优先对于高度结构化的歧义如“参数缺失”直接调用预定义的模板库生成问题。例如对于缺失“出发日期”模板可能是“请问您的出发日期是哪一天”LLM兜底与优化对于复杂的、非结构化的歧义如“范围模糊”、“隐含假设冲突”或者当模板生成的问题不够自然时调用LLM生成。此时提示词需要包含更丰富的上下文背景用户查询“[用户查询]”存在[歧义类型]歧义。具体来说[根据决策模块输出填充的详细歧义描述如“实体‘苹果’可能指代A或B”]。 任务请你以搜索引擎助手的身份生成一个简洁、清晰、友好的澄清问题帮助用户明确意图。问题应提供明确的选项如果适用并易于用户快速回答。 请直接输出澄清问题不要额外解释。选项生成与排序对于实体歧义需要生成候选实体列表。这可以通过查询知识图谱如Wikidata、利用词向量相似度从大规模实体库中检索或再次调用LLM来生成。生成的候选列表需要按相关性排序通常只展示前2-3个最可能的选项并提供一个“其他”的开放式入口以平衡效率与覆盖率。实操心得澄清问题切忌冗长和包含专业术语。例如与其问“您指的是‘Malus domestica’栽培苹果的供应链还是‘Apple Inc.’纳斯达克AAPL的供应链”不如问“您想了解水果苹果还是苹果公司”同时避免提出让用户难以回答的开放性问题如“您具体想了解苹果的什么”这会让用户感到困惑。好的澄清问题是选择题或填空题。3.3 深度搜索的规划与执行引擎这是搜索代理的“四肢”。一个典型的规划-执行循环如下查询理解与计划制定消歧后的查询被送入“规划器”通常是一个LLM。规划器将复杂任务分解为一系列可执行的子任务或称“工具调用”。输入任务基于用户澄清后的意图‘比较iPhone 15 Pro和三星Galaxy S24 Ultra的摄像头性能’请制定一个分步搜索计划。输出结构化{ plan: [ {step: 1, action: search, query: iPhone 15 Pro 摄像头规格 传感器尺寸 像素}, {step: 2, action: search, query: 三星Galaxy S24 Ultra 摄像头规格 传感器尺寸 像素}, {step: 3, action: search, query: iPhone 15 Pro vs Galaxy S24 Ultra 摄像头 对比评测 2024}, {step: 4, action: synthesize, goal: 从规格、样张、评测观点三个方面对比总结} ] }工具调用与信息获取执行器根据计划按顺序调用相应的工具。最核心的工具是网络搜索API如Serper, Tavily, Google Search API。调用时需要精心构造搜索Query并设置合理的返回结果数量如5-10条。除了搜索还可能调用计算器、代码解释器、专业数据库API等。信息评估与迭代获取搜索结果通常是网页摘要或片段后需要一个“评估器”来判断信息是否足够、是否相关、是否可靠。这个评估器也可以是LLM其任务是对每条信息进行评分或分类。如果当前步骤的信息质量未达到阈值规划器可能需要调整搜索词或增加一个补充搜索步骤。答案合成与溯源当所有计划步骤完成或达到迭代上限时将所有收集到的、经过筛选的信息片段和原始来源连同原始任务一起提交给“合成器”一个LLM要求其生成最终答案。关键点必须强制合成器在答案中引用来源例如使用上标[1]并在末尾列出参考文献。这不仅是学术规范更是产品可信度的基石。性能考量深度搜索的延迟主要来自LLM的多次调用和网络搜索的耗时。可以采用异步并行调用如并行执行多个不依赖的搜索步骤、缓存频繁出现的查询结果、以及对非关键路径使用较小、较快的模型等策略来优化。4. 基于DiscoBench的评估实践与问题排查当我们自己构建或选择一个澄清感知搜索代理时如何用DiscoBench的思路来评估它这里分享一套可落地的评估方法和常见问题。4.1 构建内部评估测试集即使不使用官方的DiscoBench你也可以构建一个针对自己业务场景的小型测试集。步骤收集种子查询从你的产品日志、客服对话、用户反馈中收集那些经常被误解或需要后续追问的查询。这是最宝贵的资源。分类与标注人工或借助LLM将这些查询分类如实体歧义、意图模糊、参数缺失等并为每个需要澄清的查询编写1-3个“标准澄清问题”和“消歧后的理想答案”。补充对抗性样本故意构造一些边界清晰的查询用于测试代理是否“过度提问”。同时构造一些极其模糊的查询测试其澄清能力的上限。设计评估指标澄清准确率代理在需要/不需要澄清的查询上判断正确的比例。问题相关性人工评分随机抽取一批生成的澄清问题让评估者可以是团队成员在1-5分制下打分。任务成功率从模糊查询开始到获得满意答案对比标准答案的端到端成功率。可以细分为“经过澄清后成功”和“无需澄清直接成功”两种情况。4.2 典型问题与调试技巧在实际运行中你肯定会遇到各种问题。下面是一个常见问题排查表问题现象可能原因排查与解决思路代理从不提问总是直接搜索1. 决策模块的LLM提示词过于保守或偏向行动。2. 决策置信度阈值设置过高。3. 训练/微调数据中“需要澄清”的样本不足或质量不高。1. 调整提示词强调“当存在任何不确定性时优先澄清”。在系统提示中明确角色“你是一个谨慎的助手在行动前会确保理解正确。”2. 降低触发澄清的置信度阈值。3. 补充更多模糊查询的样本并在微调时给予更高权重。代理提问过于频繁甚至对清晰问题也提问1. 决策模块过于敏感将简单查询中的正常词汇变化误判为歧义。2. 澄清生成模块产生的选项质量差误导了决策。3. 缺乏对清晰查询的识别能力。1. 在决策提示词中加入反面示例“以下查询是清晰的不应提问[示例]”。2. 加强候选实体生成的准确性使用更可靠的知识源进行消歧。3. 在测试集中增加大量清晰查询并确保决策模型能正确识别它们。生成的澄清问题模糊、冗长或难以回答1. 生成模型的提示词指令不明确。2. 模型本身能力不足如使用了较小的模型。3. 提供给生成模型的歧义信息本身就不清晰。1. 优化生成提示词使用“角色-任务-约束”格式明确要求“问题简短”、“选项明确”、“易于回答”。2. 升级生成模型或在关键环节使用更大规模的模型。3. 检查决策模块的输出确保ambiguous_entities或missing_parameters字段是具体、准确的。澄清交互后最终答案仍不准确1. 深度搜索模块的规划能力不足未能制定有效的搜索策略。2. 搜索API返回的结果质量差或无关。3. 信息合成模块未能有效整合和推理多源信息。1. 为规划器提供更详细的工具描述和成功案例Few-shot Learning提升其分解任务的能力。2. 优化搜索Query构造策略尝试不同的搜索API并对结果进行更严格的相关性过滤。3. 在合成答案时要求模型“基于以下证据逐条推理”并提供所有检索到的文本片段作为上下文强制其进行证据引用。系统响应速度慢用户体验差1. 串行执行规划-搜索-评估-合成循环延迟累积。2. 使用的LLM模型过大推理耗时。3. 网络搜索API延迟高。1. 分析任务依赖图将可以并行的搜索步骤改为异步并行执行。2. 实施模型级联用快模型做决策和简单生成用大模型做复杂规划和最终合成。3. 为搜索API设置合理的超时时间并考虑使用多个备用API源。引入缓存层对相同或相似的搜索Query结果进行短期缓存。4.3 关于“Chimera”多智能体服务框架的联想在搜索热词中出现的“chimera: latency- and performance-aware multi-agent serving for heterogeneous llms”虽然与DiscoBench的评估焦点不同但它指向了实现高性能搜索代理的另一个关键基础设施层面。你可以这样理解它们的关系DiscoBench定义了“考什么”评估澄清感知搜索的能力而Chimera这类框架解决了“怎么考得又快又好”高效、低延迟地调度异构LLM来执行这些智能体任务。在一个复杂的澄清感知搜索代理中我们可能同时用到一个小型、快速的模型如Phi-3, Qwen2.5-7B来处理初始查询分类和简单的澄清生成。一个大型、能力强的模型如GPT-4, Claude-3 Opus来处理复杂的任务规划、多步推理和最终答案合成。甚至多个 specialized 模型分别处理不同领域的消歧。“Chimera”所关注的延迟与性能感知的异构LLM多智能体服务正是为了优化这种混合部署。它需要智能地路由请求将决策任务发给快模型将合成任务发给强模型管理多个模型的加载与卸载进行批处理以提升吞吐量并监控每个环节的延迟确保整个系统的端到端响应时间在可接受范围内例如一次完整的澄清交互在数秒内完成。因此当你基于DiscoBench的指导设计好智能体的逻辑后若想将其投入实际应用就必须考虑类似Chimera的工程架构问题。否则一个再聪明的代理如果每次响应都要几十秒也毫无用户体验可言。构建一个真正实用的澄清感知深度搜索代理是一条融合了自然语言理解、对话管理、信息检索和系统工程的漫漫长路。DiscoBench为我们提供了清晰的评估坐标而实现过程则充满了对细节的打磨和对权衡的考量。从我个人的实践来看启动时不必追求大而全可以从一个垂直领域如科技产品查询入手构建一个最小可行产品重点打磨“何时问”和“如何问”的体验再逐步扩展搜索深度和领域范围。记住每一次成功的澄清不仅是获取了更准确的信息更是与用户建立了一次有效的沟通这或许是智能搜索体验超越传统搜索的最重要一步。