1. 从“搜不到”到“搜不准”Agentic Search 的挑战与 HotelQuEST 的诞生最近在折腾一个基于大语言模型LLM的智能客服项目核心需求是让 LLM 能根据用户模糊的、口语化的提问从一堆产品文档里找到最相关的信息来生成回答。一开始我们天真地以为把文档切块、向量化然后用一个向量数据库做语义检索再把检索到的前几条文本扔给 LLM 去总结这事儿就成了。结果呢用户问“你们家那个能自动调节亮度的台灯怎么设置定时关闭”系统检索出来的全是“台灯亮度调节指南”、“产品定时功能概述”这类宽泛的文档就是找不到“智能调光台灯定时关闭设置步骤”这个精准的答案。问题从传统的“搜不到”变成了更棘手的“搜不准”——检索系统返回的结果在语义上似乎相关但在解决具体任务上却效率低下甚至完全错误。这就是当前 LLM 应用特别是 Agent智能体系统面临的核心检索难题。传统的检索增强生成RAG流程是静态的、一次性的用户提问 - 检索 - 生成。但一个真正的智能体Agent在执行任务时其“思考”过程是动态的、多轮的。它可能需要先理解用户的深层意图然后规划搜索策略根据初步结果决定是深入挖掘、转换关键词还是询问澄清。这种带有自主性、规划性和迭代性的搜索过程被称为Agentic Search智能体搜索。它不再是简单的关键词匹配或语义相似度计算而是一个质量找到最精准、最权威的答案与效率用最少的搜索轮次、最低的计算成本完成任务之间的持续博弈。然而当我们想评估或优化一个 Agentic Search 系统时却发现市面上缺乏一个公认的“标尺”。现有的检索基准如 MS MARCO, BEIR大多关注单轮检索的静态相关性无法衡量智能体在多轮交互、动态规划下的综合表现。也没有一个统一框架能同时量化搜索结果的“好坏”质量和达成这个结果所耗费的“资源”效率。正是在这个背景下HotelQuEST 这个框架引起了我的注意。它的名字很有意思是Hotel Quality-Efficiency Search Trade-off的缩写。你可以把它想象成一个为“智能体搜索”量身定制的综合测试与平衡平台。它不关心你的智能体是用 LangChain 还是 LlamaIndex 搭的底层用的是 OpenAI 的 GPT 还是开源的 Llama它只关心一件事你的智能体在执行复杂信息搜寻任务时如何在“找到最佳答案”和“快速、省资源地找到答案”之间取得最佳平衡。这对于任何想要构建实用、可靠 LLM Agent 的开发者来说都是一个无法回避的核心议题。接下来我就结合自己的理解和实践拆解一下 HotelQuEST 究竟要解决什么问题以及我们该如何用它来指导和优化自己的系统。2. 拆解 HotelQuEST质量、效率与权衡的三角度量HotelQuEST 的核心思想是认为一个优秀的 Agentic Search 系统不能只看“最终答案对不对”还必须看“得到答案的过程优不优”。它将评估维度拆解为一个稳固的三角质量Quality、效率Efficiency和两者的权衡Trade-off。2.1 质量维度超越简单的“相关”在传统检索中质量通常指检索到的文档与查询的语义相关性。但在 Agentic Search 的语境下质量的定义复杂得多。HotelQuEST 可能会从以下几个层面进行度量任务完成度Task Completion这是最根本的。智能体是否成功完成了用户指定的搜索任务例如用户要求“找出过去三年人工智能在医疗影像诊断领域影响力最大的五篇论文”智能体最终给出的列表是否准确、完整地满足了这五个条件时间范围、领域、数量、影响力标准这通常需要一个最终的人工或自动化验证来判断输出是否直接回答了问题。答案忠实度Answer Faithfulness智能体生成的最终答案是否严格基于它检索到的证据Evidence是否存在“幻觉”Hallucination即编造了检索结果中不存在的信息例如检索到的文档只说“某模型在数据集A上达到95%准确率”智能体却总结成“该模型性能优于所有现有方案”这就属于不忠实。评估这一点需要将最终答案与检索到的源文档进行细粒度的事实核对。证据质量Evidence Quality智能体在决策过程中所依赖的检索结果本身的质量如何这包括相关性Relevance单条检索结果与当前搜索意图的匹配程度。覆盖度Coverage多轮检索获得的证据集合是否全面覆盖了回答问题所需的所有关键方面有没有重大遗漏权威性Authority检索到的信息来源是否可靠这在 HotelQuEST 的酒店搜索场景或事实查询中尤为重要。新颖性Novelty在多轮搜索中智能体是否能跳出初始结果的局限发现新的、有价值的信息搜索策略的合理性Search Strategy Rationality智能体选择搜索关键词、决定何时停止搜索、何时进行追问澄清等一系列决策是否显得合理、有逻辑一个总是用过于宽泛关键词或者陷入无限循环搜索的智能体其搜索策略的质量就是低下的。2.2 效率维度计算成本与交互成本的博弈效率关乎成本而成本在 Agentic Search 中是多方面的计算成本Computational CostLLM 调用次数LLM Calls这是最大的开销项。每一次规划搜索策略、改写查询、总结中间结果、生成最终答案都可能需要调用一次 LLM API。HotelQuEST 会统计完成一个任务的总调用次数。检索调用次数Retriever Calls向向量数据库或搜索引擎发起查询的次数。总处理令牌数Total Tokens包括输入给 LLM 的提示词Prompt长度和 LLM 生成的输出长度。这直接关联到 API 费用和推理时间。交互成本Interaction Cost / Latency搜索轮次Search Turns智能体完成整个任务需要经历多少轮“思考-搜索-观察”的循环轮次越少通常意味着智能体规划能力越强效率越高。总耗时Total Latency从任务开始到返回最终答案所经过的实时时间。这受到网络延迟、模型推理速度、检索速度等多重影响。用户等待成本在需要与用户交互澄清的场景中智能体发起澄清询问的次数。过多的澄清会降低用户体验效率。2.3 权衡的艺术寻找帕累托最优边界质量和效率往往是一对矛盾体。追求极致质量例如让智能体进行十轮深度搜索交叉验证每一条信息必然导致效率低下调用次数激增耗时漫长。反之一味追求效率只进行一轮简单检索质量又难以保证。HotelQuEST 的价值就在于它试图量化这个权衡。它可能通过引入一些复合指标来实现质量-效率分数Quality-Efficiency Score例如Score Task Success Rate / (LLM Calls * Avg Latency)。这个分数越高说明智能体能以更低的成本达成更高的任务成功率。帕累托前沿分析Pareto Frontier Analysis在同一个测试集上运行同一个智能体的不同配置版本例如调整搜索深度限制、改写查询的激进程度等将每个版本的质量分数和效率分数绘制在二维图上。那些“在同等质量下效率最高”或“在同等效率下质量最好”的点就构成了帕累托前沿。一个优秀的智能体框架应该能让开发者方便地调整参数使其表现点尽可能靠近这条前沿曲线。成本感知质量Cost-Aware Quality为不同质量维度赋予权重并减去效率成本项形成一个综合效用函数。例如Utility α*Completion β*Faithfulness - γ*LLMCalls - δ*Turns。开发者可以通过调整 α, β, γ, δ 来体现自己对质量和效率的偏好。实操心得在设计自己的 Agent 时我们常常盲目地增加检索轮次或扩大检索范围以为这样能提升质量。但 HotelQuEST 的视角提醒我们每增加一轮搜索都需要权衡其带来的潜在质量提升是否值得它付出的计算和延迟成本。一个实用的技巧是设置早期退出条件例如当连续两轮检索到的前3个结果重复率超过80%时可以认为信息已饱和应停止搜索避免无效消耗。3. 构建可评估的 Agentic Search 智能体核心组件与设计模式要让 HotelQuEST 这样的基准发挥作用我们的智能体需要被设计成可评估、可度量的。这意味着我们需要清晰地定义其内部工作流程并将关键决策点暴露出来以供记录。一个典型的、可用于 HotelQuEST 评估的 Agentic Search 智能体通常包含以下核心组件3.1 规划器Planner任务分解与策略生成规划器是智能体的大脑负责理解用户初始请求并将其分解为一系列可执行的搜索子任务或步骤。工作原理规划器通常是一个 LLM接收用户查询和上下文输出一个搜索计划Search Plan。这个计划可能包括首要搜索关键词、备选关键词、需要澄清的问题如果查询模糊、预期的信息类型、搜索的深度轮次等。示例提示词Prompt你是一个专业的研究助手。请分析以下用户请求并制定一个分步搜索计划来找到答案。 用户请求“帮我比较一下 TensorFlow 和 PyTorch 在分布式训练方面的最新特性。” 你的计划应包括 1. 首先搜索关于“TensorFlow 分布式训练 最新特性 [当前年份]”的文档。 2. 然后搜索关于“PyTorch DistributedDataParallel 最新更新”的文档。 3. 重点关注官方博客、技术论文和权威社区如 Stack Overflow, GitHub Issues的讨论。 4. 如果初步结果中关于“弹性训练”或“异步优化”的信息不足发起第二轮针对性搜索。 5. 最后综合所有信息进行对比。 请以 JSON 格式输出你的计划包含 steps 数组。HotelQuEST 评估点规划器的输出质量直接影响后续所有步骤。评估者可以检查其计划是否合理、步骤是否可操作、是否预见了可能的搜索难点。3.2 执行器Executor/ 检索器Retriever与知识源交互执行器负责执行规划器制定的搜索步骤其核心是与检索系统向量数据库、传统搜索引擎、API等交互。关键设计执行器需要记录每一次检索动作。包括使用的查询词、调用的检索接口、返回的结果数量、以及最重要的——它从返回结果中“观察”到了什么。这个“观察”通常是对检索结果的精简摘要或关键信息提取作为下一轮规划的输入。代码结构示意class SearchExecutor: def execute_step(self, search_step: Dict, context: List) - Dict: # 1. 构建查询可能结合上下文重写查询 query self._rewrite_query(search_step[query], context) # 2. 调用检索系统 search_results self.retriever.search(query, top_k5) # 3. 记录日志用于HotelQuEST评估 self.metrics_logger.log({ turn: self.current_turn, query: query, num_results: len(search_results), retrieval_latency: latency, results: search_results[:3] # 记录top结果摘要 }) # 4. 提取观察信息 observation self._summarize_results(search_results) return {observation: observation, raw_results: search_results}HotelQuEST 评估点直接记录LLM Calls如果重写查询用了LLM、Retriever Calls、Latency。同时检索结果的质量相关性、权威性构成了证据质量评估的基础。3.3 反思器Reflector评估进展与调整策略这是实现高效 Agentic Search 的关键。在每一轮或几轮搜索后智能体需要“反思”当前进展信息是否足够搜索方向是否正确是否需要调整策略工作原理反思器也是一个 LLM 调用它分析当前的用户目标、已制定的计划、历史搜索动作和观察到的结果然后判断继续搜索、调整搜索词、向用户请求澄清还是终止搜索并开始回答。示例提示词基于以下信息决定下一步行动 用户目标{user_goal} 已执行计划{executed_steps} 最新观察结果{latest_observation} 可选行动 A. 继续按原计划进行下一步。 B. 调整建议一个新的、更精确的搜索查询。 C. 澄清向用户提出一个明确的问题以获取更多背景。 D. 终止已有足够信息生成最终答案。 请给出你的选择A/B/C/D并简要说明理由。如果选B请提供新的搜索查询。HotelQuEST 评估点反思器的决策质量是效率的核心。一个优秀的反思器能避免无效搜索快速收敛到答案。评估者可以分析其决策理由是否合理以及决策对最终任务完成度和总成本的影响。3.4 回答生成器Answer Generator综合与输出当反思器决定终止搜索后回答生成器负责综合所有检索到的证据生成最终、连贯、忠实的答案。注意这一步虽然重要但对 HotelQuEST 的“搜索”过程评估来说它更多是终点。评估的重点在于生成答案的“忠实度”是否基于之前所有被评估过的“证据”。设计模式建议为了便于 HotelQuEST 评估建议采用ReAct (Reasoning Acting)或类似显式循环框架来构建智能体。这样智能体的内部状态计划、动作、观察、反思在每个循环都清晰可见易于记录和事后分析。避免使用“黑盒”式的端到端模型否则难以拆解质量与效率的贡献来源。4. 实战为你的 LLM Agent 设计 HotelQuEST 式评估方案理解了 HotelQuEST 的理念和智能体构成后我们完全可以为自己的项目设计一个简易版的评估流程而不必等待官方基准发布。以下是具体步骤4.1 第一步定义你的测试任务与质量标准首先你需要一套能代表你实际业务场景的测试查询Test Queries和对应的标准答案或评估标准。构建测试集来源从历史用户日志中提取真实、复杂的查询。如果没有就人工构造。关键是要有层次包括简单的事实查询、需要多步推理的查询、需要整合多个来源的查询、以及意图模糊需要澄清的查询。数量初期20-50个高质量查询远比几百个简单查询有用。格式每个测试用例应包含id: 唯一标识。query: 用户原始提问。context: 可选必要的上下文。golden_answer: 理想的标准答案如果难以编写可以是关键信息点列表。evidence_docs: 完成任务所需参考的理想文档集合用于评估证据覆盖度。allowed_clarifications: 可选允许智能体询问澄清问题的次数和类型。定义质量评估指标自动化指标Task Success Rate (TSR): 使用 LLM如 GPT-4作为裁判判断智能体最终答案是否满足了用户查询的核心要求。可以设计一个评分提示词让裁判模型输出“是/否”或“1-5分”。Answer Faithfulness Score: 将智能体答案与其引用的源文档检索结果一起交给裁判 LLM判断答案中的每一条关键主张是否有源文档支持计算忠实主张的比例。人工评估指标黄金标准随机抽取一部分结果由领域专家从“任务完成度”、“答案有用性”、“信息准确性”等维度进行评分。自动化指标应与人工评分有较高的相关性。4.2 第二步植入度量探针记录效率数据在你的智能体代码的关键节点插入日志记录确保能捕获 HotelQuEST 关心的所有效率数据。关键日志数据# 每个任务session开始时 session_log { session_id: ..., query: ..., start_time: timestamp, turns: [] # 记录每一轮的信息 } # 每一轮turn结束时 turn_log { turn_id: k, action_type: planning/retrieval/reflection/generation, llm_calls: 1, # 本次动作消耗的LLM调用次数 llm_prompt_tokens: 1500, llm_completion_tokens: 200, retriever_calls: 1, retrieval_latency_ms: 120, search_query_used: ..., num_results: 10, reflection_decision: continue/adjust/clarify/terminate, timestamp: timestamp } session_log[turns].append(turn_log) # 任务结束时 session_log[end_time] timestamp session_log[total_llm_calls] sum(t[llm_calls] for t in turns) session_log[total_tokens] sum(t[llm_prompt_tokens]t[llm_completion_tokens] for t in turns) session_log[total_latency_ms] end_time - start_time session_log[num_turns] len(turns)工具推荐可以使用像LangSmith、Weights Biases (WB)或MLflow这类实验跟踪平台来系统化地记录这些轨迹Traces和指标它们能提供很好的可视化。4.3 第三步运行实验与平衡分析使用同一套测试集运行你的智能体的不同配置版本我们称之为Agent Variants。可调整的配置参数搜索深度最大搜索轮次限制max_turns。反思激进度反思器被触发的频率每轮都反思 vs 每两轮反思一次以及其决策倾向例如让反思模型更倾向于“终止”以节省成本。检索广度每次检索返回的文档数量top_k。查询改写策略是否使用 LLM 对查询进行激进的重写扩展还是使用简单的模板。底层 LLM使用 GPT-4-turbo 还是成本更低的 GPT-3.5-turbo 或 Claude Haiku 来担任规划器和反思器。分析结果数据汇总计算每个Agent Variant在所有测试用例上的平均Task Success Rate、平均Total LLM Calls、平均Total Latency。绘制散点图以Total LLM Calls或Total Cost为 X 轴以Task Success Rate为 Y 轴将每个 Variant 的平均值作为一个点画在图上。寻找帕累托前沿观察哪些点位于图的“左上”区域即在相同或更低的成本下取得了更高的成功率。这些点对应的配置就是较好的权衡点。深度分析针对某个特定失败案例回放其完整的轨迹日志Trace分析是在哪一轮、哪个组件规划、检索、反思做出了错误决策导致了效率低下或质量不高。4.4 一个具体的调优案例控制“反思”的成本假设你的初始智能体Variant A配置是每轮搜索后都进行反思使用 GPT-4 作为反思器。你发现Task Success Rate很高92%但Total LLM Calls也极高平均每个任务12次成本昂贵。调整1Variant B将反思频率改为每两轮一次。预期LLM Calls 下降成功率可能轻微下降。调整2Variant C在 Variant B 基础上将反思器从 GPT-4 换成更便宜的 GPT-3.5-turbo。预期成本进一步大幅下降成功率可能进一步下降。调整3Variant D在 Variant A 基础上修改反思器的提示词加入更严格的终止条件例如“如果最近两轮的观察结果高度相似则倾向于终止”。预期可能在保持高成功率的同时减少不必要的搜索轮次和反思调用。运行测试后你可能会发现 Variant D 达到了和 Variant A 相近的 91% 成功率但 LLM Calls 降到了平均8次。而 Variant C 的成本最低平均5次调用但成功率只有85%。这时你就可以根据你的业务对质量和成本的容忍度做出明确的选择。这就是 HotelQuEST 思想指导下的量化权衡。踩坑提醒在评估“答案忠实度”时直接使用检索到的原始文本块chunk作为证据源可能有问题。因为 LLM 生成答案时可能综合了多个文本块的信息。更好的做法是在智能体运行过程中强制其以“引用”的形式输出答案标明每一句话来源于哪个文档的哪个片段。这样忠实度评估才能准确进行。这需要在回答生成环节设计特定的输出格式如 Markdown 引用格式并对提示词进行约束。 智能体搜索评估新框架：HotelQuEST如何量化质量与效率的权衡
1. 从“搜不到”到“搜不准”Agentic Search 的挑战与 HotelQuEST 的诞生最近在折腾一个基于大语言模型LLM的智能客服项目核心需求是让 LLM 能根据用户模糊的、口语化的提问从一堆产品文档里找到最相关的信息来生成回答。一开始我们天真地以为把文档切块、向量化然后用一个向量数据库做语义检索再把检索到的前几条文本扔给 LLM 去总结这事儿就成了。结果呢用户问“你们家那个能自动调节亮度的台灯怎么设置定时关闭”系统检索出来的全是“台灯亮度调节指南”、“产品定时功能概述”这类宽泛的文档就是找不到“智能调光台灯定时关闭设置步骤”这个精准的答案。问题从传统的“搜不到”变成了更棘手的“搜不准”——检索系统返回的结果在语义上似乎相关但在解决具体任务上却效率低下甚至完全错误。这就是当前 LLM 应用特别是 Agent智能体系统面临的核心检索难题。传统的检索增强生成RAG流程是静态的、一次性的用户提问 - 检索 - 生成。但一个真正的智能体Agent在执行任务时其“思考”过程是动态的、多轮的。它可能需要先理解用户的深层意图然后规划搜索策略根据初步结果决定是深入挖掘、转换关键词还是询问澄清。这种带有自主性、规划性和迭代性的搜索过程被称为Agentic Search智能体搜索。它不再是简单的关键词匹配或语义相似度计算而是一个质量找到最精准、最权威的答案与效率用最少的搜索轮次、最低的计算成本完成任务之间的持续博弈。然而当我们想评估或优化一个 Agentic Search 系统时却发现市面上缺乏一个公认的“标尺”。现有的检索基准如 MS MARCO, BEIR大多关注单轮检索的静态相关性无法衡量智能体在多轮交互、动态规划下的综合表现。也没有一个统一框架能同时量化搜索结果的“好坏”质量和达成这个结果所耗费的“资源”效率。正是在这个背景下HotelQuEST 这个框架引起了我的注意。它的名字很有意思是Hotel Quality-Efficiency Search Trade-off的缩写。你可以把它想象成一个为“智能体搜索”量身定制的综合测试与平衡平台。它不关心你的智能体是用 LangChain 还是 LlamaIndex 搭的底层用的是 OpenAI 的 GPT 还是开源的 Llama它只关心一件事你的智能体在执行复杂信息搜寻任务时如何在“找到最佳答案”和“快速、省资源地找到答案”之间取得最佳平衡。这对于任何想要构建实用、可靠 LLM Agent 的开发者来说都是一个无法回避的核心议题。接下来我就结合自己的理解和实践拆解一下 HotelQuEST 究竟要解决什么问题以及我们该如何用它来指导和优化自己的系统。2. 拆解 HotelQuEST质量、效率与权衡的三角度量HotelQuEST 的核心思想是认为一个优秀的 Agentic Search 系统不能只看“最终答案对不对”还必须看“得到答案的过程优不优”。它将评估维度拆解为一个稳固的三角质量Quality、效率Efficiency和两者的权衡Trade-off。2.1 质量维度超越简单的“相关”在传统检索中质量通常指检索到的文档与查询的语义相关性。但在 Agentic Search 的语境下质量的定义复杂得多。HotelQuEST 可能会从以下几个层面进行度量任务完成度Task Completion这是最根本的。智能体是否成功完成了用户指定的搜索任务例如用户要求“找出过去三年人工智能在医疗影像诊断领域影响力最大的五篇论文”智能体最终给出的列表是否准确、完整地满足了这五个条件时间范围、领域、数量、影响力标准这通常需要一个最终的人工或自动化验证来判断输出是否直接回答了问题。答案忠实度Answer Faithfulness智能体生成的最终答案是否严格基于它检索到的证据Evidence是否存在“幻觉”Hallucination即编造了检索结果中不存在的信息例如检索到的文档只说“某模型在数据集A上达到95%准确率”智能体却总结成“该模型性能优于所有现有方案”这就属于不忠实。评估这一点需要将最终答案与检索到的源文档进行细粒度的事实核对。证据质量Evidence Quality智能体在决策过程中所依赖的检索结果本身的质量如何这包括相关性Relevance单条检索结果与当前搜索意图的匹配程度。覆盖度Coverage多轮检索获得的证据集合是否全面覆盖了回答问题所需的所有关键方面有没有重大遗漏权威性Authority检索到的信息来源是否可靠这在 HotelQuEST 的酒店搜索场景或事实查询中尤为重要。新颖性Novelty在多轮搜索中智能体是否能跳出初始结果的局限发现新的、有价值的信息搜索策略的合理性Search Strategy Rationality智能体选择搜索关键词、决定何时停止搜索、何时进行追问澄清等一系列决策是否显得合理、有逻辑一个总是用过于宽泛关键词或者陷入无限循环搜索的智能体其搜索策略的质量就是低下的。2.2 效率维度计算成本与交互成本的博弈效率关乎成本而成本在 Agentic Search 中是多方面的计算成本Computational CostLLM 调用次数LLM Calls这是最大的开销项。每一次规划搜索策略、改写查询、总结中间结果、生成最终答案都可能需要调用一次 LLM API。HotelQuEST 会统计完成一个任务的总调用次数。检索调用次数Retriever Calls向向量数据库或搜索引擎发起查询的次数。总处理令牌数Total Tokens包括输入给 LLM 的提示词Prompt长度和 LLM 生成的输出长度。这直接关联到 API 费用和推理时间。交互成本Interaction Cost / Latency搜索轮次Search Turns智能体完成整个任务需要经历多少轮“思考-搜索-观察”的循环轮次越少通常意味着智能体规划能力越强效率越高。总耗时Total Latency从任务开始到返回最终答案所经过的实时时间。这受到网络延迟、模型推理速度、检索速度等多重影响。用户等待成本在需要与用户交互澄清的场景中智能体发起澄清询问的次数。过多的澄清会降低用户体验效率。2.3 权衡的艺术寻找帕累托最优边界质量和效率往往是一对矛盾体。追求极致质量例如让智能体进行十轮深度搜索交叉验证每一条信息必然导致效率低下调用次数激增耗时漫长。反之一味追求效率只进行一轮简单检索质量又难以保证。HotelQuEST 的价值就在于它试图量化这个权衡。它可能通过引入一些复合指标来实现质量-效率分数Quality-Efficiency Score例如Score Task Success Rate / (LLM Calls * Avg Latency)。这个分数越高说明智能体能以更低的成本达成更高的任务成功率。帕累托前沿分析Pareto Frontier Analysis在同一个测试集上运行同一个智能体的不同配置版本例如调整搜索深度限制、改写查询的激进程度等将每个版本的质量分数和效率分数绘制在二维图上。那些“在同等质量下效率最高”或“在同等效率下质量最好”的点就构成了帕累托前沿。一个优秀的智能体框架应该能让开发者方便地调整参数使其表现点尽可能靠近这条前沿曲线。成本感知质量Cost-Aware Quality为不同质量维度赋予权重并减去效率成本项形成一个综合效用函数。例如Utility α*Completion β*Faithfulness - γ*LLMCalls - δ*Turns。开发者可以通过调整 α, β, γ, δ 来体现自己对质量和效率的偏好。实操心得在设计自己的 Agent 时我们常常盲目地增加检索轮次或扩大检索范围以为这样能提升质量。但 HotelQuEST 的视角提醒我们每增加一轮搜索都需要权衡其带来的潜在质量提升是否值得它付出的计算和延迟成本。一个实用的技巧是设置早期退出条件例如当连续两轮检索到的前3个结果重复率超过80%时可以认为信息已饱和应停止搜索避免无效消耗。3. 构建可评估的 Agentic Search 智能体核心组件与设计模式要让 HotelQuEST 这样的基准发挥作用我们的智能体需要被设计成可评估、可度量的。这意味着我们需要清晰地定义其内部工作流程并将关键决策点暴露出来以供记录。一个典型的、可用于 HotelQuEST 评估的 Agentic Search 智能体通常包含以下核心组件3.1 规划器Planner任务分解与策略生成规划器是智能体的大脑负责理解用户初始请求并将其分解为一系列可执行的搜索子任务或步骤。工作原理规划器通常是一个 LLM接收用户查询和上下文输出一个搜索计划Search Plan。这个计划可能包括首要搜索关键词、备选关键词、需要澄清的问题如果查询模糊、预期的信息类型、搜索的深度轮次等。示例提示词Prompt你是一个专业的研究助手。请分析以下用户请求并制定一个分步搜索计划来找到答案。 用户请求“帮我比较一下 TensorFlow 和 PyTorch 在分布式训练方面的最新特性。” 你的计划应包括 1. 首先搜索关于“TensorFlow 分布式训练 最新特性 [当前年份]”的文档。 2. 然后搜索关于“PyTorch DistributedDataParallel 最新更新”的文档。 3. 重点关注官方博客、技术论文和权威社区如 Stack Overflow, GitHub Issues的讨论。 4. 如果初步结果中关于“弹性训练”或“异步优化”的信息不足发起第二轮针对性搜索。 5. 最后综合所有信息进行对比。 请以 JSON 格式输出你的计划包含 steps 数组。HotelQuEST 评估点规划器的输出质量直接影响后续所有步骤。评估者可以检查其计划是否合理、步骤是否可操作、是否预见了可能的搜索难点。3.2 执行器Executor/ 检索器Retriever与知识源交互执行器负责执行规划器制定的搜索步骤其核心是与检索系统向量数据库、传统搜索引擎、API等交互。关键设计执行器需要记录每一次检索动作。包括使用的查询词、调用的检索接口、返回的结果数量、以及最重要的——它从返回结果中“观察”到了什么。这个“观察”通常是对检索结果的精简摘要或关键信息提取作为下一轮规划的输入。代码结构示意class SearchExecutor: def execute_step(self, search_step: Dict, context: List) - Dict: # 1. 构建查询可能结合上下文重写查询 query self._rewrite_query(search_step[query], context) # 2. 调用检索系统 search_results self.retriever.search(query, top_k5) # 3. 记录日志用于HotelQuEST评估 self.metrics_logger.log({ turn: self.current_turn, query: query, num_results: len(search_results), retrieval_latency: latency, results: search_results[:3] # 记录top结果摘要 }) # 4. 提取观察信息 observation self._summarize_results(search_results) return {observation: observation, raw_results: search_results}HotelQuEST 评估点直接记录LLM Calls如果重写查询用了LLM、Retriever Calls、Latency。同时检索结果的质量相关性、权威性构成了证据质量评估的基础。3.3 反思器Reflector评估进展与调整策略这是实现高效 Agentic Search 的关键。在每一轮或几轮搜索后智能体需要“反思”当前进展信息是否足够搜索方向是否正确是否需要调整策略工作原理反思器也是一个 LLM 调用它分析当前的用户目标、已制定的计划、历史搜索动作和观察到的结果然后判断继续搜索、调整搜索词、向用户请求澄清还是终止搜索并开始回答。示例提示词基于以下信息决定下一步行动 用户目标{user_goal} 已执行计划{executed_steps} 最新观察结果{latest_observation} 可选行动 A. 继续按原计划进行下一步。 B. 调整建议一个新的、更精确的搜索查询。 C. 澄清向用户提出一个明确的问题以获取更多背景。 D. 终止已有足够信息生成最终答案。 请给出你的选择A/B/C/D并简要说明理由。如果选B请提供新的搜索查询。HotelQuEST 评估点反思器的决策质量是效率的核心。一个优秀的反思器能避免无效搜索快速收敛到答案。评估者可以分析其决策理由是否合理以及决策对最终任务完成度和总成本的影响。3.4 回答生成器Answer Generator综合与输出当反思器决定终止搜索后回答生成器负责综合所有检索到的证据生成最终、连贯、忠实的答案。注意这一步虽然重要但对 HotelQuEST 的“搜索”过程评估来说它更多是终点。评估的重点在于生成答案的“忠实度”是否基于之前所有被评估过的“证据”。设计模式建议为了便于 HotelQuEST 评估建议采用ReAct (Reasoning Acting)或类似显式循环框架来构建智能体。这样智能体的内部状态计划、动作、观察、反思在每个循环都清晰可见易于记录和事后分析。避免使用“黑盒”式的端到端模型否则难以拆解质量与效率的贡献来源。4. 实战为你的 LLM Agent 设计 HotelQuEST 式评估方案理解了 HotelQuEST 的理念和智能体构成后我们完全可以为自己的项目设计一个简易版的评估流程而不必等待官方基准发布。以下是具体步骤4.1 第一步定义你的测试任务与质量标准首先你需要一套能代表你实际业务场景的测试查询Test Queries和对应的标准答案或评估标准。构建测试集来源从历史用户日志中提取真实、复杂的查询。如果没有就人工构造。关键是要有层次包括简单的事实查询、需要多步推理的查询、需要整合多个来源的查询、以及意图模糊需要澄清的查询。数量初期20-50个高质量查询远比几百个简单查询有用。格式每个测试用例应包含id: 唯一标识。query: 用户原始提问。context: 可选必要的上下文。golden_answer: 理想的标准答案如果难以编写可以是关键信息点列表。evidence_docs: 完成任务所需参考的理想文档集合用于评估证据覆盖度。allowed_clarifications: 可选允许智能体询问澄清问题的次数和类型。定义质量评估指标自动化指标Task Success Rate (TSR): 使用 LLM如 GPT-4作为裁判判断智能体最终答案是否满足了用户查询的核心要求。可以设计一个评分提示词让裁判模型输出“是/否”或“1-5分”。Answer Faithfulness Score: 将智能体答案与其引用的源文档检索结果一起交给裁判 LLM判断答案中的每一条关键主张是否有源文档支持计算忠实主张的比例。人工评估指标黄金标准随机抽取一部分结果由领域专家从“任务完成度”、“答案有用性”、“信息准确性”等维度进行评分。自动化指标应与人工评分有较高的相关性。4.2 第二步植入度量探针记录效率数据在你的智能体代码的关键节点插入日志记录确保能捕获 HotelQuEST 关心的所有效率数据。关键日志数据# 每个任务session开始时 session_log { session_id: ..., query: ..., start_time: timestamp, turns: [] # 记录每一轮的信息 } # 每一轮turn结束时 turn_log { turn_id: k, action_type: planning/retrieval/reflection/generation, llm_calls: 1, # 本次动作消耗的LLM调用次数 llm_prompt_tokens: 1500, llm_completion_tokens: 200, retriever_calls: 1, retrieval_latency_ms: 120, search_query_used: ..., num_results: 10, reflection_decision: continue/adjust/clarify/terminate, timestamp: timestamp } session_log[turns].append(turn_log) # 任务结束时 session_log[end_time] timestamp session_log[total_llm_calls] sum(t[llm_calls] for t in turns) session_log[total_tokens] sum(t[llm_prompt_tokens]t[llm_completion_tokens] for t in turns) session_log[total_latency_ms] end_time - start_time session_log[num_turns] len(turns)工具推荐可以使用像LangSmith、Weights Biases (WB)或MLflow这类实验跟踪平台来系统化地记录这些轨迹Traces和指标它们能提供很好的可视化。4.3 第三步运行实验与平衡分析使用同一套测试集运行你的智能体的不同配置版本我们称之为Agent Variants。可调整的配置参数搜索深度最大搜索轮次限制max_turns。反思激进度反思器被触发的频率每轮都反思 vs 每两轮反思一次以及其决策倾向例如让反思模型更倾向于“终止”以节省成本。检索广度每次检索返回的文档数量top_k。查询改写策略是否使用 LLM 对查询进行激进的重写扩展还是使用简单的模板。底层 LLM使用 GPT-4-turbo 还是成本更低的 GPT-3.5-turbo 或 Claude Haiku 来担任规划器和反思器。分析结果数据汇总计算每个Agent Variant在所有测试用例上的平均Task Success Rate、平均Total LLM Calls、平均Total Latency。绘制散点图以Total LLM Calls或Total Cost为 X 轴以Task Success Rate为 Y 轴将每个 Variant 的平均值作为一个点画在图上。寻找帕累托前沿观察哪些点位于图的“左上”区域即在相同或更低的成本下取得了更高的成功率。这些点对应的配置就是较好的权衡点。深度分析针对某个特定失败案例回放其完整的轨迹日志Trace分析是在哪一轮、哪个组件规划、检索、反思做出了错误决策导致了效率低下或质量不高。4.4 一个具体的调优案例控制“反思”的成本假设你的初始智能体Variant A配置是每轮搜索后都进行反思使用 GPT-4 作为反思器。你发现Task Success Rate很高92%但Total LLM Calls也极高平均每个任务12次成本昂贵。调整1Variant B将反思频率改为每两轮一次。预期LLM Calls 下降成功率可能轻微下降。调整2Variant C在 Variant B 基础上将反思器从 GPT-4 换成更便宜的 GPT-3.5-turbo。预期成本进一步大幅下降成功率可能进一步下降。调整3Variant D在 Variant A 基础上修改反思器的提示词加入更严格的终止条件例如“如果最近两轮的观察结果高度相似则倾向于终止”。预期可能在保持高成功率的同时减少不必要的搜索轮次和反思调用。运行测试后你可能会发现 Variant D 达到了和 Variant A 相近的 91% 成功率但 LLM Calls 降到了平均8次。而 Variant C 的成本最低平均5次调用但成功率只有85%。这时你就可以根据你的业务对质量和成本的容忍度做出明确的选择。这就是 HotelQuEST 思想指导下的量化权衡。踩坑提醒在评估“答案忠实度”时直接使用检索到的原始文本块chunk作为证据源可能有问题。因为 LLM 生成答案时可能综合了多个文本块的信息。更好的做法是在智能体运行过程中强制其以“引用”的形式输出答案标明每一句话来源于哪个文档的哪个片段。这样忠实度评估才能准确进行。这需要在回答生成环节设计特定的输出格式如 Markdown 引用格式并对提示词进行约束。