AI 购物代理：为何上下文优先于查询

AI 购物代理：为何上下文优先于查询

Agent Builder 现已正式发布 (GA)。立即开始 Elastic Cloud 试用，并在此处查看 Agent Builder 的文档。

零售商正竞相满足客户不断变化的期望，以提供更丰富、更优质的在线购物体验。客户不仅仅满足于搜索商品；他们渴望由 AI 驱动的互动式、个性化和前瞻性指导。挑战在于，尽管大型语言模型 (LLMs) 功能强大，但如何构建一个系统，使其能够像您店铺里知识渊博的员工一样，以快速、准确且经济高效的方式运作？本文将探讨构建这些 AI 购物助手所面临的挑战，以及新兴的上下文工程方法，以优化其工作方式。

AI 购物代理的失败并非因为模型本身有误，而是因为代理在每次对话开始时，对您的商品目录、词汇表或业务规则一无所知。它必须通过工具调用来探索所有这些上下文，而这种探索正是成本所在。通过您已有的信号（词汇表、策略、用户画像、会话行为）预先计算一个结构化的上下文层，可以减少代理在回答问题之前所需的探索性工作，并使其行为更受控且可预测。

在一个类比的文档检索案例中，预计算上下文在一个受控基准测试中将输入 token 减少了高达 75%；我们预计在 电商领域也能实现类似的节省，因为探索模式是相同的，尽管具体数字会因商品目录和查询组合而异。电商领域的信号比几乎任何其他领域都更丰富，而且大多数零售商已经拥有这些信号。问题在于，这些信号是否以代理在开始推理之前即可使用的形式进行了整合。Elastic 广泛的搜索功能组合，包括语义搜索、混合搜索、关键词搜索、过滤和聚合，使其不仅是构建核心检索工具的理想选择，也是重要的上下文引擎。

为何 AI 购物代理在生产环境中会失败

投资 AI 购物助手的零售商们发现，演示效果和实际生产环境前几个月的表现之间存在令人不安的差距。

助手需要四秒钟才能响应。它自信地推荐了一款产品，但其尺码范围在该商品中根本不存在。它向一位老顾客推荐了一件他们在 18 个月前购买并退回的大衣款式。它根据一个与内部分类法不符的类别名称进行筛选，结果返回零。顾客最终放弃并完全中断了聊天。

这些并非模型故障。驱动这些代理的先进模型在拥有正确信息时，能够进行出色的推理。问题在于，代理在对话开始时，对零售商的商品目录、客户或管理推荐的业务规则一无所知。它必须通过对话本身来学习所有这些信息，进行探索性的工具调用，以发现存在哪些部门、哪些筛选值有效以及品牌的特定产品政策是什么。每一次这样的探索性调用都会在代理向客户提供任何有用信息之前，产生延迟和 token 成本。

延迟在电商领域的重要性远超许多其他场景。购物者期望以秒为单位的响应时间，而不是企业知识库代理通常所需的几分钟。众所周知，较慢的响应会降低在线零售的参与度和转化率。一个在回答礼品创意问题前明显思考五秒钟的 AI 购物助手，不是一个“功能”；它是一个“障碍”。

解决方案并非更快的模型或更大的上下文窗口。代理的延迟和成本问题是一个上下文问题。 这可以通过在代理调用之前，而非调用期间，精心计算上下文来解决。

AI 购物代理在搜索前了解什么

想象一下，您是那个代理。您有一个连接到商品目录的搜索工具，然后收到了这样的查询：

"an outfit for an autumn wedding"

您实际会怎么处理这个查询？

首先从您不知道的开始。这是男装还是女装？“autumn”是颜色、季节、面料款式，还是仅仅指婚礼发生的时间？这位购物者是谁，是多年来的老客户，还是一个陌生人？他们是购买昂贵的设计师品牌，还是总是在促销时寻找便宜货？您对这些问题一无所知。所以您会像一个盲目工作的代理一样：提出大量后续问题、猜测，或者发起一系列探索性搜索，以找出存在哪些部门和筛选值，眼看着时间一秒一秒过去，而您却还没向客户提供任何东西。

请记住这种盲目工作的感觉。本文的其余部分将探讨当代理首先获得答案时会发生什么变化。

为何电商不同于通用 RAG

大多数关于降低代理成本的已发表工作都集中在文档检索上：对文章、报告或知识库条目语料库进行问答。Elastic 团队最近的一项实验（通过预计算上下文降低代理成本）表明，在代理调用前从文档中预先提取结构化事实，可将输入 token 消耗减少高达 75%，并将硬性事实基准测试的回答准确率从 60% 提高到 92%。这种改进是分阶段实现的，其中最大的飞跃是由将代理自己的错误答案反馈到提取步骤中驱动的，而不是仅仅通过预计算上下文，这一点我们将在讨论治理时再次提及。

电商将相同的原则应用于一个根本不同的结构。商品目录不是文档语料库。它是一个高度结构化的商品索引，具有严格的字段语义、特定领域的品牌名称、颜色代码和类别层次结构词汇表，以及在特定情况下覆盖纯粹相关性的业务规则层。

由此导致的故障模式与文档检索增强生成 (RAG) 的故障不同：

• • 词汇不匹配： 客户询问“navy jumper”。代理根据一个字段构建过滤器，其中规范值是 NAVY，类别存储为 Knitwear & Jumpers。如果没有词汇映射，代理要么猜测颜色和类别并出错，要么进行多次探索性调用以发现存在哪些值，然后才能正确过滤。
• • 幻觉筛选值： 在不知道给定查询哪些筛选维度有效的情况下，代理可能会针对不存在的字段或返回零结果的值构建查询。像 category: knitwear 这样的过滤器看起来合理；而 masterCategoryNames: "Knitwear & Jumpers" 才是索引实际包含的内容。如果代理不知道，它要么产生幻觉，要么必须进行单独的工具调用来查找，这会导致另一个 LLM 循环，从而耗费时间和 token。
• • 无上下文的个性化： 来自两位不同客户的相同查询，一位通常购买高端商品并适合正式场合，另一位主要购买 40 英镑以下的休闲装，应该返回不同的结果。如果没有用户画像上下文，代理会平等对待每个查询，这比经过良好调优的关键词搜索更糟糕，因为它给人一种私人助手的印象，但却提供了通用答案。

上下文层：它需要哪些信号

电商特别适合预计算上下文的原因是，零售商已经拥有异常丰富的信号集。挑战不在于数据的可用性；而在于整合。

信号分为两组。其中两个，商品目录词汇表和业务策略，是真正独创的工作，也是这种方法的核心。其余的，实时分面状态、用户画像和会话历史，虽然有价值，但更接近于基本要求，是大多数团队已经知道如何获取的信号。以下是大多数中大型零售商所拥有的以及每个信号所能预防的问题。

我们之所以说“语义元数据”而不仅仅是“元数据”，是因为我们试图匹配意图的语义（含义），而不是确切的词语。如果用户搜索“teal”，我们应该能够理解这是一种颜色，并且在我们的产品中找到与 teal 语义相似的颜色，即使其中没有一种实际是 teal 色。因此，如果搜索“teal”，我们可能希望返回：

1

ProductColours = “aquamarine, turquoise”

希望您能看到这种语义元数据是如何弥合用户意图与代理对产品知识之间的鸿沟的。

商品目录词汇表：上下文工程的基础

商品目录词汇表是承担最多工作且最值得优先构建的层。

词汇索引将自然语言映射到产品索引中使用的确切字段值和类别路径。它回答诸如：“navy”映射到什么？“knitwear”下有哪些类别？“Autograph”是品牌还是系列？代理在查询中可能遇到的竞争品牌正确拼写是什么？

使其不仅仅是一个同义词列表的关键在于其查询方式。购物者所说的有趣内容很少是精确的字段值。他们说“something cozy for fall”，而不是 colour: NAVY 和 masterCategoryNames: "Knitwear & Jumpers"。因此，词汇索引需要将模糊的自然语言意图解析为精确的、完全匹配的过滤器，这需要两种匹配方式同时进行：语义搜索 以理解“cozy”倾向于针织品和抓绒，以及精确的关键词匹配以将结果锁定到产品索引实际存储的规范值。一个在相同文档上同时支持这两种匹配的元数据索引，实际上是客户说话方式与商品目录结构方式之间的翻译层。

这也是索引获得“语义元数据层”而非“查找表”描述的原因。每个条目都是对分面值或模式概念的简短自然语言描述，因此代理可以根据含义进行匹配，然后读回要使用的精确过滤器。对于典型的时尚零售商，这涵盖了数百个颜色值、品牌别名、类别同义词和尺码范围约定。从全目录聚合构建语义元数据层是一次性的工程工作；维护它是增量式的，随着新类别和品牌的添加而更新。没有它，代理在遇到不熟悉的术语时必须猜测或进行探索性工具调用来发现存在什么。

上下文层中的业务策略

第二个原始层是策略。有些查询带有隐式业务要求，而纯粹的相关性无法处理。对“wine gift for a friend”的查询，在法律要求年龄验证的市场中，应触发年龄验证提醒。对“gluten-free food gift”的查询，应从普通糖果转向特定的无麸质系列。在春季提及“wedding guest outfit”的查询，应与 11 月的相同查询应用不同的权重。

这些都是策略，大多数零售搜索团队已经编写了它们。他们只是称之为提升规则、商品叠加或同义词配置。在代理上下文中的区别在于，它们不是作为查询修改静默应用，而是作为可读提示浮现出来，代理在决定如何组织答案和展示哪些产品时可以使用。代理不必从商品目录中推断您的交易规则；它会直接获得这些规则。

关键点是：这些策略编码的是业务意图，而不仅仅是相关性。一个将酒精查询通过年龄验证流程的策略不是检索优化；它是一个交易要求。这就是为什么这一层必须由人工编写和管理，而不是根据流量模式自动生成，这一点我们将在治理部分再次提及。

词汇表和策略共同使代理表现得像它了解您的业务而不仅仅是您的数据。其余三个信号能提升体验，但它们是更熟悉的工程工作。

上下文层中的分面、画像和会话信号

• • 实时分面状态： 在代理推荐筛选器之前，它应该知道哪些筛选器可用，以及每个筛选器针对此特定查询会返回多少结果。一个在不知道特定尺码（例如，尺码 8）在该查询中已缺货的情况下，仍建议“按尺码 8 筛选”的代理，会立即损害客户的信任。对产品索引进行分面状态查询，与词汇表和策略查找并行运行，可以返回针对当前查询的计数、范围和可用值。
• • 用户画像： 持久的用户画像（尺码、颜色偏好、预算范围、品牌偏好）让老客户无需重复说明他们已经提供过的信息。这通常是获取最快的信号，通过用户 ID 进行单文档查找。
• • 会话和购买历史： 在一个会话中，代理应该知道客户已经看过、拒绝或添加到购物篮中的商品，这样它就不会重复推荐已拒绝的商品或重复自己。更长期的购买历史可以扩展这一点，而像退货历史这样的信号则更加丰富，但要很好地利用它们，取决于大多数零售商在尚未连接到其搜索路径的系统中保存的数据。这是最具抱负的一层，最好在早期层已交付价值后最后处理。在构建初始上下文时，也必须注意平衡，不要过度膨胀大小，这会减慢首次回复并增加 token 成本。因此，在初始上下文提供购买历史等信息，或将其作为代理在对话期间使用的工具之间，需要仔细权衡，但用户会期望，如果他们已登录，代理应该知道他们购买了什么。精确的最佳上下文可能因每个实现和客户体验而异，需要仔细测试。

上下文工程如何在 LLM 调用前工作

实现这种模式的方法描述起来很简单，但实际操作起来却相当复杂：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

graph TD
    A[用户查询] --> B{并行上下文构建}
    B --> C1[商品目录词汇表]
    B --> C2[业务策略]
    B --> C3[实时分面状态]
    B --> C4[用户画像]
    B --> C5[会话/购买历史]
    C1 --> D(结构化上下文)
    C2 --> D
    C3 --> D
    C4 --> D
    C5 --> D
    D --> E[LLM 推理]
    E --> F[AI 购物代理响应]

如果没有这种上下文构建，代理会自行进行相同的发现，但通过 LLM 驱动的工具调用，每次调用都会产生完整的推理往返成本。根据经验法则，一次探索性工具（例如，GetFilterValues）调用在实践中往往会产生大约 600 毫秒到 1 秒的延迟；因此，一个在开始回答之前通过三次独立的工具调用发现词汇表、检查策略提示并检索分面状态的代理，可能会在响应时间上增加两到三秒，这还不包括它执行实际产品搜索的时间。这些是数量级估算，而非基准测试数据，实际数字在很大程度上取决于模型、网络路径以及工具的实现方式。

用一个在 LLM 调用之前并行执行的获取操作（可以并行进行多个上下文构建查询）来替换这些探索性调用，可以消除大部分成本。上下文构建所需的时间大致与单个 LLM 工具调用相同，但它替代了三到四个这样的调用。LLM 要么需要重复失败的搜索，要么需要按顺序进行自己的上下文构建工具调用，才能获得足够的上下文以成功。预计算上下文也是确定性的，而不受模型工具选择的影响，这为业务提供了更多控制权来微调体验。

token 减少遵循相同的逻辑：每次探索性工具调用都会返回模型必须处理的原始数据。预先组装的上下文摘要用结构化事实取代了原始数据，模型可以一次性消费这些事实。在面向公众的零售网站可能达到的使用规模下，这种 token 成本节省可能非常显著。这项关于文档搜索的工作（通过预计算上下文降低代理成本）在一个受控基准测试中显示，输入 token 减少了高达 75%。该基准测试是文档检索而非电商，其作者明确表示，这个乘数并非一个可以在任何地方都预期的固定数字。我们预计在电商领域方向会保持一致，因为探索模式是相同的；它只是针对结构化商品目录而不是文档语料库运行。具体幅度是每个团队应根据自己的流量来衡量。

具备完整上下文的 AI 购物代理

还记得那个让您猜测的查询吗：“an outfit for an autumn wedding”。再次运行它，但这次，在您开始思考之前，您会收到一份预计算的上下文，作为一份简短的简报：

• • 这位购物者名叫 Sarah，女性，32 岁，购买女装，尺码 12。
• • 她通常购买您店铺的中档系列。
• • 这里的“Autumn”与这些特定的颜色标签匹配：“rust”、“burgundy”、“forest green”、“camel”。
• • 匹配的部门：“Womenswear”、“Menswear”。
• • 匹配的标签：“occasion dresses”、“trouser suits”、“wedding”。
• • 她的购物篮中已经有一个勃艮第色的包。
• • 婚礼宾客着装的内部规定：完善整套服装。展示帽子和配饰，而不仅仅是连衣裙。

突然之间，您不再是猜测；您正在为这位客户进行造型。有趣的部分在于这些事实如何结合，而不仅仅是堆叠。季节提供了一个完整的秋季调色板；购物篮中已有的勃艮第色包将调色板缩小到与其协调的几种色调；内部规定告诉您要用匹配的头饰完成造型，而不是止步于连衣裙。所有这些事实加在一起，让您能够像一个既了解这位客户又了解这家商店的人一样，一次性地回答问题，没有任何凭空捏造。

这份简短的简报正是信号栈所产生的：购物者的用户画像、已解析的词汇表、实时购物篮和业务策略。这些信息并行组装，并在代理采取第一个行动之前呈现在它面前，因此“我该怎么处理这个？”的问题永远不需要通过一次次昂贵的工具调用来解决。

在没有自动化漂移的情况下管理上下文层

这里描述的方法与自动化知识提取系统之间的一个区别值得直接探讨：在电商领域，上下文索引不能在没有人为审查的情况下自动更新。

管理代理如何响应礼品查询、酒精查询或特定年龄段客户查询的策略，不仅仅是相关性配置；它们是具有潜在法律和品牌影响的交易决策。一个未经审查、根据流量模式自动生成新策略的自动化系统，在成为技术资产之前，就已构成合规风险。

这实际上是大多数零售组织的正确约束，并且与搜索团队的现有工作方式相符。商品策划师编写提升规则。搜索团队维护同义词配置。内容团队批准自动化推荐中出现的语言。上下文策略层是相同类型的受控配置；它只是服务于不同的消费者，即代理的推理步骤而非查询管道。

值得注意的是，这与前面提到的文档检索工作有所不同。在该实验中，最大的准确性提升来自于一个自动化反馈循环，该循环将代理的错误答案直接反馈给提取器。这对于事实问答非常有效，因为“正确”和“错误”是明确无误的。在电商领域，等效的信号仍然会自动浮现，但由人工决定如何处理它们，因为这些更改带有交易和合规权重。循环的形状相同；只是发布步骤中有人参与。

在实践中奏效的治理循环分为两个层次：

• • 自动信号浮现： 零结果查询、同一主题的重复重构，以及代理交互后未完成购买的会话，都表明上下文层中存在缺失或错误。这些信号会自动浮现，作为改进体验的候选点，例如：一个未能解析的词汇术语，或一个本应覆盖但未触发的策略。为此，您需要一个详细的对话日志，包括在 Elastic 等平台中的推理和工具调用跟踪。这允许您使用结构化工具（例如，“差评”对话的百分比增长）和语义方式来分析代理的性能。您还可以运行对 12 月左右“礼物”相关对话的自动化审查，以表征两个代理在 AB 测试中的“点赞/点踩”比率。
• • 人工编写和审查： 搜索或商品策划团队审查候选条目并编写相应的词汇条目或策略。策略在发布前需经过批准。这通常反映了现有同义词更改或提升规则修改的工作流程；唯一的不同是工具。

如何分阶段实施上下文工程

• • 阶段 1：词汇层（最高杠杆，有界工程任务）。
• • 阶段 2：分面状态和初始策略（依赖相同的商品目录和检索原语）。
• • 阶段 3：用户画像和会话信号（需要 CRM 和分析集成；最好在代理活跃后添加）。
• • 阶段 4：受控反馈循环（转向组织协调；发现商品策划团队的差距）。

上述完整的信号堆栈无需一次性构建，而且顺序并非随意。最高杠杆的起点也是实现复杂度最低的：词汇层。一个通过全目录聚合（规范颜色值、品牌别名、类别路径、字段名称）构建的语义元数据索引是一个有界的工程任务，而且一个能够在第一次工具调用之前将“navy jumper”解析为 color: NAVY, masterCategoryNames: "Knitwear & Jumpers" 的代理，比通过试错发现这些信息的代理要好得多。如果您不构建其他任何东西，请务必构建这个。

分面状态和第一批策略可以紧随其后，通常并行进行，因为它们依赖相同的商品目录和相同的检索原语。后面的层，例如用户画像、会话信号和受控反馈循环，是工作从搜索工程转向组织协调的地方。实施 CRM 系统集成、商品策划工作流更改以及浮现差距所需的分析可能需要大量工作。一旦代理投入日常使用并生成使受控循环值得运行的流量信号，这些层才更有价值。重要的特点是每一层都独立存在，因此零售商可以从第一阶段获得实际价值，而无需承诺完成第六阶段。

上下文层需要什么基础设施？

以这里描述的深度预计算上下文，对底层平台提出了特定要求。有必要明确说明这些要求，因为在早期的代理构建中，人们倾向于为每项功能选择最简单的可用工具。

• • 语义搜索用于将自然语言查询与词汇索引匹配，并显示正确的规范值。模糊关键词匹配本身无法解决相似品牌名称或颜色术语之间的歧义。
• • 一个 percolator 来实现策略层。percolator 反转了通常的搜索方向：它不是将查询与存储的文档匹配，而是存储查询并将传入的文本（此处为客户消息）与它们匹配。这正是策略匹配所需要的，因为每个策略本质上是一个保存的模式，它表示“当查询看起来像这样时，显示此提示。”
• • 对整个产品目录进行实时聚合，以便在查询时生成准确的分面状态。预计算的分面快照在活跃的目录中会迅速过时；查询时聚合是更可靠的来源。
• • 通过键检索文档以获取用户画像：通过用户 ID 进行快速的单文档查找，必须在上下文构建窗口内完成。
• • 对查询跟踪和代理交互进行结构化和语义日志记录和分析，这些是受控循环自动信号浮现的原始材料。

这些是一个成熟的搜索和分析平台的标准功能，而不是六个独立的系统，而 Elasticsearch 将所有这些功能集于一身。这与其说是一个采购点，不如说是一个架构点：当语义匹配、percolator、聚合、用户画像查找和分析都在同一集群中针对同一目录运行时，上下文层与搜索层在构建上保持一致。将这些功能分散到单独的向量存储和单独的分析平台是一个合理的选择，但它增加了操作界面，并在两个对相同产品进行推理的系统之间引入了数据一致性问题。当上下文基础设施与产品数据所在的位置一起运行，并且无需单独的提取、转换、加载 (ETL) 步骤即可更新时，它的运行最简单。

结论：上下文工程是搜索团队的职责

那些能够大规模运行高效 AI 购物体验的零售商，并非拥有最大模型或最慷慨 token 预算的零售商。他们是那些在代理开始推理之前，已完成工作使其商品目录、词汇表和策略对代理清晰可读的零售商。

好消息是，大部分工作已经完成。词汇表隐含在商品目录中。策略以商品策划规则和合规指南的形式存在。用户画像存储在 CRM 中。会话信号存在于分析流中。差距不在于数据；而在于将这些信号转化为代理在开始推理之前即可使用的结构化上下文的整合层。

搜索团队已经拥有词汇表、策略和商品策划工作流程。上下文层正是搜索团队正在进行的工作的理想归宿，其形式既能服务于代理，也能服务于查询管道。而且，由于每次发现并填补空白时它都会增长，因此它更像是一种不断增值的资产，而非一次性设置成本。

要在 Elastic 中开始构建上下文层，您可以启动 Elastic Cloud 试用 或在本地运行。您应该熟悉如何配置语义搜索，如果您对如何在查询时构建、存储和匹配搜索策略感兴趣，您会喜欢这篇博客。

📡 更多 Elastic & AI 可观测性干货