作者来自 Elastic Matthew Adams猜测你使用词汇的 AI 购物 agent 会犯下代价高昂的错误。预先计算的商品目录上下文会在第一次工具调用之前就阻止这种猜测。Agent Builder 现已 正式发布。立即开始使用 Elastic Cloud Trial并查看 Agent Builder 的文档点击 这里。零售商正在竞相满足客户不断变化的期望为他们提供更加丰富的在线购物体验。客户不再满足于搜索商品他们希望获得由 AI 驱动的交互式、个性化和主动式引导。挑战在于虽然大型语言模型LLMs功能非常强大但你如何构建一个能够像店内知识丰富的员工一样工作的系统同时做到快速、准确且具有成本效益本文将讨论构建这些 AI 购物助手所面临的挑战以及新兴的上下文工程方法以优化它们的工作方式。AI 购物 agent 失败的原因并不是模型出错而是因为 agent 在每次对话开始时都不了解你的商品目录、词汇体系或业务规则。它必须通过工具调用来发现所有这些上下文而这种发现过程就是成本所在。通过利用你已经拥有的信号词汇体系、策略、用户档案、会话行为预先计算出一个结构化的上下文层可以减少 agent 在能够回答问题之前所需进行的探索性工作并使其行为受到治理且更加可预测。在类似的文档检索场景中预先计算上下文在受控基准测试中最多将输入 token 减少了 75%我们预计在 电子商务 场景中也会获得类似的节省因为探索模式是相同的不过具体数值会因商品目录和查询组合而有所不同。电子商务中的信号比几乎任何其他领域都更加丰富而且大多数零售商已经拥有这些信号。问题在于这些信号是否已经被组织成 agent 在开始推理之前就能够使用的形式。Elastic 广泛的搜索能力组合包括语义搜索、混合搜索、关键字搜索、过滤和聚合使其不仅成为构建核心检索工具的理想选择也成为至关重要的上下文引擎。为什么 AI 购物 agent 在生产环境中失败投资于 AI 购物助手的零售商们正在发现演示所承诺的与投产头几个月实际交付的之间存在一个令人不安的差距。助手需要四秒才能响应。它自信地推荐了一个尺码范围但该商品根本不存在这个尺码。它告诉一位回头客关于一件 18 个月前购买并退回的外套款式。它按一个与内部分类法不匹配的分类名称进行筛选结果返回零个结果。顾客放弃并完全离开了聊天。这些不是模型失败。驱动这些 agent 的前沿模型在拥有正确信息时具备非凡的推理能力。问题在于agent 进入对话时对零售商的商品目录、顾客或管理推荐规则的业务规则一无所知。它必须通过对话本身学习所有这些进行探索性的工具调用来发现存在哪些部门、哪些筛选值是有效的以及品牌对某些产品类型的政策是什么。每一个这样的发现调用都会消耗延迟和 token 在 agent 对顾客说出任何有用的话之前。延迟在电子商务中的重要性是许多其他场景所无法比拟的。购物者期望响应时间以秒来衡量而不是企业知识库 agent 通常需要的几分钟。众所周知响应速度变慢会降低在线零售中的用户参与度和转化率。一个 AI 购物助手如果在回答礼物推荐问题之前需要明显思考五秒钟那不是一种功能而是一种阻碍。解决方案不是更快的模型或更大的上下文窗口。agent 的延迟和成本问题是一个上下文问题。这可以通过在 agent 调用之前仔细计算上下文来解决而不是在调用期间。AI 购物 agent 在搜索前知道什么想象你是 agent 。你有一个连接到商品目录的搜索工具这个查询到来an outfit for an autumn wedding/一套秋季婚礼的服装你实际上会怎么处理这个从你不知道的开始。一套给男人还是女人的服装autumn 是一种颜色、一个季节、一种面料风格还是只是婚礼发生的时间这位购物者是谁是多年来一直从你这里购买的人还是陌生人他们购买昂贵的设计师品牌还是总是在打折时寻找便宜货你没有任何这些答案。所以你会像 agent 在盲目工作时所做的那样问大量跟进问题猜测或发起一系列探索性搜索来发现存在哪些部门和筛选值看着秒数流逝在你向顾客提供任何东西之前。请记住这种在毫无信息的情况下工作的感觉。本文其余内容将讨论当 agent 在开始之前就已经获得答案时会发生哪些变化。为什么电子商务不同于通用 RAG大多数关于降低 agent 成本的已发表研究都聚焦于文档检索针对文章、报告或知识库条目组成的语料库进行问答。Elastic 团队最近的一项实验使用预先计算的上下文降低 agent 成本表明在调用 agent 之前先从文档中提取结构化事实可将输入token消耗最多减少 75%并将困难事实性基准测试中的回答准确率从 60% 提高到 92%。这种提升是分阶段实现的其中最大的提升来自于将 agent 自己的错误答案反馈到提取步骤中而不仅仅是预先计算上下文这一区别将在我们讨论治理时再次提及。电子商务将同样的原则应用到了一个本质上不同的结构中。商品目录并不是一个文档语料库。它是一个高度结构化的商品索引具有严格的字段语义、包含品牌名称、颜色代码和类别层级的领域专用词汇体系以及一层在特定场景下会覆盖纯相关性的业务规则。由此产生的失败模式与文档 检索增强生成RAG的失败模式有所不同词汇体系不匹配客户搜索 “navy jumper”。agent 构建了一个过滤条件而索引中的规范颜色值是NAVY类别存储为Knitwear Jumpers。如果没有词汇映射agent 要么猜测颜色和类别并得出错误结果要么进行多次探索性调用以发现有哪些可用值之后才能正确过滤。幻觉式过滤值在不了解某个查询有哪些有效过滤维度的情况下agent 可能会针对不存在的字段构建查询或者使用返回零结果的字段值。例如category: knitwear看起来很合理但索引中实际包含的是masterCategoryNames: Knitwear Jumpers。如果 agent 不知道这一点它要么产生幻觉要么必须额外进行一次工具调用来查明事实从而导致又一次 LLM 循环增加时间和token成本。缺乏上下文的个性化对于两个不同客户相同的查询应该返回不同的结果一个客户通常购买高端商品并穿着正式服装另一个客户主要购买价格低于 £40 的休闲服。如果没有用户档案上下文agent 会以完全相同的方式处理所有查询这甚至比经过精心调优的关键字搜索还要糟糕因为它给人一种私人助手的印象却提供了千篇一律的回答。上下文层它需要哪些信号电子商务特别适合使用预先计算的上下文原因在于零售商已经拥有一组异常丰富的信号。挑战并不在于数据是否可用而在于如何将这些数据组织起来。这些信号可分为两类。其中两个 —— 商品目录词汇体系和业务策略 —— 才是真正具有原创性的工作也是这种方法的核心。其余的包括实时分面状态、用户档案和会话历史同样很有价值但更接近于基础能力大多数团队已经知道如何获取这些信号。下面列出了大多数中大型零售商已经拥有的信号以及每种信号能够防止的问题。信号可防止的问题构建工作量商品目录词汇体系防止词汇体系不匹配和幻觉式过滤值避免 agent 猜测颜色、类别或品牌名称而是将它们解析为规范字段值一次性的工程投入整个商品目录聚合随着新增类别和品牌需要进行增量维护业务策略防止推荐结果忽略法律或业务要求例如在酒类查询中遗漏年龄验证或路由时遗漏无麸质商品范围由人工编写和治理而不是自动生成随着新增策略类型持续进行审查实时分面状态防止推荐会返回零结果或当前查询下缺货的过滤条件与词汇体系和策略查询并行运行依赖现有的商品目录和检索基础设施用户档案防止让回访客户重复提供他们已经给出的尺码、预算或品牌偏好获取速度最快的信号只需根据用户 ID 查询一条文档会话和购买历史防止再次推荐客户已经拒绝或已经购买后又退货的商品最具发展潜力的一层依赖客户关系管理CRM和分析系统集成最好在 agent 已经上线后再加入我们之所以称其为语义元数据而不仅仅是元数据是因为我们的目标是匹配用户意图的语义含义而不是精确匹配用户输入的词汇。例如如果用户搜索 “teal”我们应该能够理解这是一个颜色并知道哪些商品颜色在语义上与 “teal” 相近即使实际上没有任何商品的颜色就是 “teal”。因此当搜索 “teal” 时我们可能希望返回ProductColours aquamarine, turquoise希望你能够理解这种语义元数据正在弥合用户意图与 agent 对商品知识之间的鸿沟。商品目录词汇体系上下文工程的基础商品目录词汇体系是承担最多工作的那一层也是最值得优先完善的一层。词汇体系索引将自然语言映射到商品索引中使用的精确字段值和类别路径。它能够回答诸如“navy” 映射到什么、哪些类别属于 “knitwear”、“Autograph” 是一个品牌还是一个产品系列、对于 agent 在查询中可能遇到的竞争品牌正确的拼写是什么等问题。它之所以不仅仅是一个同义词列表是因为它的查询方式与众不同。购物者所表达的内容很少是精确的字段值。他们会说 “something cozy for fall”而不是colour: NAVY和masterCategoryNames: Knitwear Jumpers。因此词汇体系索引需要将模糊的自然语言意图解析为精确的完全匹配过滤条件而这要求同时使用两种匹配方式使用 语义搜索 理解 “cozy” 更倾向于针织服饰和抓绒服而使用精确关键字匹配将结果定位到商品索引实际存储的规范值。一个能够在同一份文档上同时支持这两种匹配方式的元数据索引本质上就是连接客户表达方式与商品目录结构之间的翻译层。这也是为什么我们将该索引称为 “语义元数据层”而不是 “查找表”。每个条目都是对某个分面值或模式概念的一小段自然语言描述因此 agent 可以根据语义进行匹配然后读取应该使用的精确过滤条件。对于一个典型的时尚零售商来说这一层涵盖了数百种颜色值、品牌别名、类别同义词以及尺码范围约定。通过对整个商品目录进行聚合来构建语义元数据层是一次性的工程投入随着新增类别和品牌只需进行增量维护。如果没有这一层agent 在遇到陌生术语时要么只能猜测要么必须通过探索性工具调用来发现有哪些可用值。上下文层中的业务策略第二个原创层是策略。有些查询包含纯相关性无法处理的隐含业务要求。在法律要求的市场中查询 “wine gift for a friend” 应该触发年龄验证提醒。查询 “gluten-free food gift” 应该从普通糖果产品转向特定的无麸质商品范围。在春季提到 “wedding guest outfit” 的查询应该应用与 11 月相同查询不同的权重。这些都是策略而且大多数零售搜索团队已经在编写这些策略。他们只是将其称为提升规则、商品运营覆盖规则或同义词配置。在 agent 场景中不同之处在于这些策略不再只是作为查询修改被静默应用而是以 agent 可以读取的提示形式呈现让 agent 在决定如何组织回答以及展示哪些商品时使用这些信息。agent 不需要从商品目录中推断你的业务规则它直接获得这些规则。关键点在于这些策略编码的是业务意图而不仅仅是相关性。一个将酒类查询引导到符合年龄要求流程的策略并不是检索优化它是一项业务要求。这就是为什么这一层必须由人工编写并进行治理而不是根据流量模式自动生成这一点我们将在治理部分再次讨论。词汇体系和策略共同使 agent 表现得像是理解你的业务而不仅仅是理解你的数据。其余三个信号可以进一步提升体验但它们属于更加常见的工程能力。上下文层中的分面、档案和会话信号实时分面状态在 agent 推荐过滤条件之前它应该知道哪些过滤条件可用以及对于当前特定查询每个过滤条件会返回多少结果。如果 agent 推荐 “按尺码 8 过滤”但不知道对于这个查询尺码 8 已经缺货这会立即破坏客户的信任。针对商品索引执行的分面状态查询与词汇体系和策略查询并行运行可以返回与当前查询相关的数量、范围和可用值。用户档案持久化的用户档案尺码、颜色偏好、预算范围、品牌偏好可以让回访客户跳过重复提供已经告诉过你的信息。通常这是最快获取的信号只需要根据用户 ID 查询一条文档。会话和购买历史在一次会话中agent 应该知道客户已经查看过、拒绝过或加入购物篮的商品这样它就不会再次推荐客户已经拒绝的商品也不会重复自己的回答。更长期的购买历史可以扩展这一能力而退货历史等信号则更加丰富但有效利用这些信息依赖于大多数零售商已经拥有、但尚未连接到搜索路径中的系统。这是最具发展潜力的一层也是最适合最后处理的一层应该在前面的层已经产生价值之后再引入。在构建初始上下文时也必须注意不要过度扩大上下文规模否则会降低首次响应速度并增加 token 成本。因此需要在初始上下文中提供例如购买历史这样的信息还是将其作为 agent 在对话过程中调用的工具之间取得谨慎平衡。但用户会期望如果他们已经登录agent 应该知道他们购买过什么。精确的最佳上下文很可能取决于每个实现方式和客户体验并且需要通过仔细测试来确定。上下文工程如何在 LLM 调用之前发挥作用实现这种方式的模式很容易描述但实现起来需要适度的工作如果没有这个上下文构建过程agent 会自行完成相同的发现过程但它会通过由 LLM 驱动的工具调用来完成而每次工具调用都会产生一次完整的 推理 往返。一个粗略的经验法则是探索性工具例如 GetFilterValues调用在实际中通常会带来大约 600 毫秒到 1 秒的延迟一个 agent 如果在开始回答之前需要通过三个独立的工具调用来发现词汇体系、检查策略提示并获取分面状态那么响应时间可能因此增加两到三秒而且这还没有执行实际的商品搜索。这些只是数量级估算并非基准测试数据实际数字会高度依赖于模型、网络路径以及工具的实现方式。用一个在 LLM 被调用之前运行的并行获取过程多个上下文构建查询可以并行执行替代这些发现调用可以消除大部分成本。上下文构建所需的实际耗时大致与一次 LLM 工具调用相同但它可以替代三到四次工具调用。为了获得足够的上下文LLM 要么需要重复执行失败的搜索要么需要自行按顺序进行上下文构建工具调用。预先计算上下文的另一个优势是它具有确定性而不是受模型工具选择决策的影响这使业务方能够更好地控制和微调体验。token 减少遵循相同的逻辑每次探索性工具调用都会返回模型必须处理的原始数据。预先组装的上下文摘要用模型可以一次性处理的结构化事实替代了这些原始数据。在面向公众的零售网站可能达到的使用规模下这种 token 成本节省可能非常显著。这项关于文档搜索的工作使用预先计算的上下文降低 agent 成本在受控基准测试中实现了最多 75% 的输入 token 减少。该基准测试针对的是文档检索而不是电子商务并且其作者明确说明这个倍数并不是一个可以在任何地方都期待的固定数字。我们预计这一趋势在电子商务中仍然成立因为探索模式是相同的只是它面对的是结构化商品目录而不是文档语料库。具体提升幅度需要每个团队根据自己的流量进行衡量。拥有完整上下文的 AI 购物 agent还记得那个让你陷入猜测的查询吗一套适合秋季婚礼的穿搭。现在重新运行它但这一次在你开始思考之前你会收到一份预先计算好的简短上下文摘要这位购物者名叫 Sarah女性32 岁购买女装尺码为 12。她通常购买你的中档产品系列。这里的 “Autumn” 对应这些具体颜色标签“rust”、“burgundy”、“forest green”、“camel”。匹配的部门“Womenswear”、“Menswear”。匹配的标签“occasion dresses”、“trouser suits”、“wedding”。她的购物篮中已经有一个酒红色手提包。婚礼宾客造型的店铺规则完成整套穿搭。展示帽子和配饰而不仅仅是连衣裙。突然之间你不再是在猜测你是在为这位客户进行造型搭配。而有趣的地方在于这些事实如何组合在一起而不仅仅是简单堆叠。季节因素提出了一个完整的秋季色彩方案她购物篮中已有的酒红色手提包将这个方案缩小到与其搭配的几种色调店铺规则告诉你应该使用匹配的羽毛头饰来完成整体造型而不是停留在连衣裙推荐上。这些信息结合起来让你能够像一个同时了解这位客户和这家商店的人一样在一次处理过程中完成回答而且没有任何臆造。这份简短摘要正是信号堆栈产生的结果购物者档案、解析后的词汇体系、实时购物篮以及业务策略。这些信息会并行组装并在 agent 第一次行动之前提供给它因此 “我到底应该如何处理这个” 这个问题不需要通过一次又一次昂贵的工具调用来解决。在不产生自动漂移的情况下治理上下文层这里描述的方法与自动化知识提取系统之间有一个值得直接讨论的区别在电子商务中上下文索引不能在没有人工审查的情况下自行更新。控制 agent 如何响应礼物查询、酒类查询或来自特定年龄段客户的查询的策略不仅仅是相关性配置它们是具有潜在法律和品牌影响的业务决策。一个未经审查、根据流量模式自动生成新策略的系统在成为技术资产之前就已经成为合规风险。实际上对于大多数零售组织来说这是正确的约束条件而且它符合搜索团队已有的工作方式。商品运营人员编写提升规则。搜索团队维护同义词配置。内容团队批准自动推荐中出现的语言。上下文策略层属于同类型的受治理配置只是它服务的是不同的消费者即 agent 的推理步骤而不是查询流程。值得注意的是这一点与前面提到的文档检索工作有所不同。在那个实验中最大的准确率提升来自一个自动反馈循环该循环将 agent 的错误答案直接反馈给提取器。这对于事实问答效果很好因为“正确”和“错误”是明确的。而在电子商务中对应的信号仍然会自动出现但人类需要决定如何处理这些信号因为这些变化具有业务运营和合规影响。循环的形态相同但发布步骤中包含人工参与。实际有效的治理循环有两个层级自动信号发现零结果查询、针对同一主题的重复改写以及在 agent 交互后未产生购买的会话都是上下文层中缺失或错误内容的信号。这些信号会自动呈现为改善体验的候选项例如某个词汇术语没有被解析或者某个策略没有在应该覆盖的查询类型中触发。要做到这一点你需要在类似 Elastic 的平台中完整记录对话包括推理过程和工具调用轨迹。这使你能够同时通过结构化工具和语义方式分析 agent 的性能例如分析负面评价对话比例的增加情况。你还可以对 12 月期间关于“礼物”的对话进行自动化审查以评估两个 agent 的 A/B 测试中点赞/点踩比例。人工编写和审查搜索或商品运营团队审查候选项并编写适当的词汇条目或策略。策略在发布之前需要经过审批。这通常与现有的同义词变更或提升规则修改流程类似唯一新增的是工具支持。如何分阶段实施上下文工程阶段 1词汇体系层最高价值边界明确的工程任务。阶段 2分面状态和初始策略依赖相同的商品目录和检索基础能力。阶段 3用户档案和会话信号需要 CRM 和分析系统集成最好在 agent 已经运行后添加。阶段 4受治理的反馈循环转向组织协作为商品运营团队发现缺口。上述完整信号堆栈不需要一次性构建完成而且实施顺序并不是随意的。最高价值的起点同时也是实现复杂度最低的部分词汇体系层。通过完整商品目录聚合构建的语义元数据索引规范颜色值、品牌别名、类别路径、字段名称是一项边界明确的工程任务而一个能够在第一次工具调用之前将 “navy jumper” 解析为color: NAVY、masterCategoryNames: Knitwear Jumpers的 agent会明显优于通过反复试错来发现这些信息的 agent。如果你什么都不构建至少应该构建这一层。分面状态和第一批策略可以紧随其后通常可以并行进行因为它们依赖相同的商品目录和相同的检索基础能力。后续层例如用户档案、会话信号和受治理的反馈循环会让工作从搜索工程转向组织协作。实现 CRM 系统集成、改变商品运营工作流程以及构建用于发现缺口的分析能力都可能需要大量工作。这些层在 agent 已经被日常使用并产生足够流量信号之后会更有价值因为这些信号能够让受治理的循环真正发挥作用。重要的是每一层都是独立存在的因此零售商可以从第一阶段获得实际价值而无需承诺完成第六阶段。上下文层需要什么基础设施按照本文所描述的深度进行预先计算上下文会对底层平台提出特定要求。明确这些要求很重要因为在早期 agent 构建过程中人们很容易倾向于为每种能力选择最简单可用的工具。语义搜索用于将自然语言查询与词汇体系索引进行匹配并发现正确的规范值。仅依靠模糊关键字匹配无法解决相似品牌名称或颜色术语之间的歧义。Percolator用于实现策略层。Percolator 反转了通常的搜索方向它不是将查询与存储的文档进行匹配而是存储查询并将传入的文本这里指客户的消息与这些查询进行匹配。这正是策略匹配所需要的方式因为每个策略本质上都是一个保存的模式用于表示“当查询看起来像这样时提供这个提示”。实时聚合在完整商品目录上执行实时聚合以便在查询时生成准确的分面状态。在活跃商品目录中预先计算的分面快照很快会过期查询时聚合是更加可靠的数据来源。通过键进行文档检索用于用户档案通过用户 ID 进行快速的单文档查询并且必须在上下文构建窗口内完成。针对查询轨迹和 agent 交互的结构化和语义日志记录与分析这些是受治理循环中自动信号发现的原始材料。这些并不是六个独立系统而是成熟搜索和分析平台中的标准能力而 Elasticsearch 在一个地方提供了所有这些能力。这一点的重要性并不主要体现在采购层面而更多体现在架构层面当语义匹配、percolation、聚合、档案查询和分析都针对同一个集群中的同一个商品目录运行时上下文层会天然保持与搜索层的一致性。将这些能力拆分到独立的vector存储和独立的分析平台中也是一种合理选择但这会增加运维复杂度并引入两个系统之间的一致性问题因为它们都在处理相同的商品数据。当上下文基础设施存在于商品数据已经存储的位置并且无需额外的提取、转换、加载ETL步骤即可更新时运行上下文基础设施会更加简单。结论上下文工程应该由搜索团队负责能够大规模运行有效 AI 购物体验的零售商并不是拥有最大模型或最宽松 token 预算的企业。而是那些在 agent 开始推理之前就已经完成了让商品目录、词汇体系和策略对 agent 可理解工作的企业。好消息是大部分工作其实已经完成。词汇体系隐含在商品目录中。策略存在于商品运营规则和合规指南中。用户档案位于 CRM 中。会话信号存在于分析流中。缺少的不是数据而是一个组装层将这些信号转换成 agent 在开始推理之前就可以使用的结构化上下文。搜索团队已经拥有词汇体系、策略和商品运营流程。上下文层正是承载搜索团队已经在做的工作的合适位置它不仅服务于查询流程也服务于 agent。而且由于每当发现并填补一个缺口时它都会不断增长因此它不像一次性的配置成本更像一个能够持续积累价值的资产。要开始在 Elastic 中构建上下文层你可以启动一个 Elastic Cloud 试用或者 本地运行。你应该熟悉如何配置 语义搜索如果你对如何在查询时构建、存储和匹配搜索策略感兴趣你会喜欢 这篇博客。原文Context engineering for AI shopping agents - Elasticsearch Labs