企业官网建设流程全解析

作者：来自 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 会以完全相同的方式处理所有查询，这甚至比经过精心调优的关键字搜索还要糟糕，因为它给人一种私人助手的印象，却提供了千篇一律的回答。

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

电子商务特别适合使用预先计算的上下文，原因在于零售商已经拥有一组异常丰富的信号。挑战并不在于数据是否可用，而在于如何将这些数据组织起来。

这些信号可分为两类。其中两个 —— 商品目录词汇体系和业务策略 —— 才是真正具有原创性的工作，也是这种方法的核心。其余的，包括实时分面状态、用户档案和会话历史，同样很有价值，但更接近于基础能力，大多数团队已经知道如何获取这些信号。下面列出了大多数中大型零售商已经拥有的信号，以及每种信号能够防止的问题。

我们之所以称其为语义元数据，而不仅仅是元数据，是因为我们的目标是匹配用户意图的语义（含义），而不是精确匹配用户输入的词汇。

例如，如果用户搜索 “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