手把手教你构建高性能意图识别引擎
摘要：本文分析了构建意图引擎：如何构建的核心概念与应用实践。作者详细分析了相关技术细节，并结合实际案例展示了最佳操作流程，帮助读者提升工程效率与解决复杂问题的能力。
1、构建意图引擎：如何构建
构建意图引擎：Instacart 如何与LLM一起改进查询理解 作者：Yuanzheng Zhu、Guanghua Shu、Raochuan Fan、Vinesh Gudla、Tejaswi Tenneti 简介 当人们搜索时……
2、介绍
当人们在 Instacart 上搜索商品时，他们并不总是输入措辞完美的短语。他们可能会写_“面包不含麸质”或“x大拉链锁”_——没关系。我们的工作是理解它们的含义，而不仅仅是它们键入的内容。这个过程称为查询理解 (QU)，是帮助数百万客户在 Instacart 上找到他们需要的内容的意图引擎。正确对待 QU 至关重要。
多年来，我们一直依赖传统的机器学习模型。它们对于许多搜索效果很好，但我们希望为无数种不常见、高度具体或创造性措辞的查询（我们称之为_长尾搜索_）提供真正智能的体验。
这种追求使我们找到了一个新的范式。我们没有从头开始构建另一个定制模型，而是选择“站在巨人的肩膀上”。我们求助于大型语言模型 (LLM)，因为它们拥有大量的预训练知识。我们不仅看到了使用这些模型的机会，而且引导它们成为我们垂直领域的深度领域专家。这篇文章详细介绍了这段旅程。我们的策略是分层的，从带有护栏的背景工程转向我们的最终目标：微调将专有知识直接提炼为LLM。这种方法将通才模型转变为真正的专家。它将我们的核心挑战从功能工程转移到生产这些强大的骨干网，同时管理延迟和成本。
3、传统查询理解的挑战
我们的LLM之旅始于研究传统 QU 的不足之处。虽然对于 Instacart 的搜索至关重要，但准确解释用户意图却非常困难，原因如下：
- 广泛查询： 像_“健康食品”或“冷冻零食”_这样的查询很常见，但很难采取行动。它们缺乏特异性，因此很难缩小相关结果的范围，因为它们可能跨越数十个类别。
- 缺乏标记数据： QU 在上游运营，无法从点击或转化等直接反馈中受益。我们从用户行为中得出的伪标签本质上是有噪音的——用户可能会搜索“面包”，但最终会购买香蕉。生成清洁标签需要昂贵且耗时的人工评估。
- 尾部查询： 高度具体或罕见的搜索，例如_“红辣椒香料”或“2％低脂超巴氏杀菌巧克力牛奶”_遭受数据稀疏的困扰。由于历史点击或转化有限，基于参与度数据训练的模型会遇到困难，导致泛化能力较差。
- 系统复杂性： 为了解决这些问题，我们历来为各个 QU 任务训练和维护多个独立模型。例如，查询分类和查询重写由完全独立的系统处理，每个系统都有自己的逻辑（图 1）。每个定制解决方案都需要自己的数据管道、培训和服务架构。这种异构性引入了不一致性，减慢了开发周期，并使整个 QU 系统难以扩展和发展。
图 1。我们之前的 QU 涉及各个 QU 任务的多个独立模型。例如，查询分类依赖于 FastText 模型进行多标签分类，而查询重写是由挖掘用户会话行为的单独系统生成的。
4、LLM 的优势
为了解决这些问题，我们求助于LLM来巩固和增强我们的 QU 模型。它们提供了几个关键优势，可以提高 Instacart 搜索的准确性和效率：
- 世界知识和推理能力： 经过不同文本数据的培训，LLM拥有世界知识，使他们能够根据用户查询进行逻辑推理。例如，LLM已经知道“意大利欧芹”是“扁平欧芹”的同义词，而“卷曲欧芹”是常见的替代品。此功能极大地减少了传统模型所需的手动工程和专业数据，为我们提供了强大的领先优势。
- 简化系统： 由于LLM拥有广泛的语言能力，它们使我们能够整合众多定制模型。通过用可以处理多个 NLP 任务的单个 LLM 替换专用模型，我们消除了维护单独模型及其不一致的复杂性。
5、LLM作为 QU：我们的行动策略
我们通过三种方式添加 Instacart 的领域上下文来集成LLM：
以下示例说明了我们如何利用其中一些技术来转换关键 QU 组件。
5.1 查询类别分类
Instacart 的目录被组织成一个庞大的、分层的产品分类法，该分类法构建了数十亿个项目，从“肉类”等广泛的部门到“牛肋骨>小排骨”等特定的子类别。将查询准确地分类到我们的产品分类中至关重要。它直接增强召回和排名，帮助我们从正确的类别中检索项目，并在查询广泛或模糊时智能地扩展搜索。
我们的传统方法将其视为一个巨大的多类分类问题。对于给定的查询，模型将从平面列表中预测前 K 个最有可能的类别。例如，对于_“酪乳”_，它可能会将 (“乳制品”，0.95) 和 (“牛奶”，0.92) 预测为不同的、非分层的输出。
这种传统方法有两个主要缺陷。首先，接受嘈杂的转换数据训练（例如，用户搜索_“面包”_但购买香蕉）意味着它可能会产生不相关的建议。其次，它缺乏更深入的上下文理解，导致它无法使用世界知识来正确分类新的或细致入微的查询，例如“纯素烤肉”，如表 1 所示。
我们新的基于 LLM 的方法通过三步过程极大地提高了精确度和召回率：首先，我们检索每个查询的前 K 个转换类别作为初始候选；其次，我们使用 LLM 通过注入的 Instacart 上下文重新对它们进行排名；最后，我们应用后处理护栏。该过滤器计算原始查询的嵌入和 LLM 的预测类别路径之间的语义相似度得分，丢弃任何低于我们的相关性阈值的对。
表 1：遗留模型和基于 LLM 的新方法之间的类别分类比较。
图2：查询类别分类系统的LLM概述
5.2 查询重写
查询重写对于提高召回率至关重要，尤其是当原始查询没有返回足够的结果时。我们的旧系统从用户会话数据中挖掘候选重写，但这种方法是有限的，仅覆盖 50% 的搜索流量，并且通常无法为产品发现生成有用的替代方案。
为了解决这个问题，我们转向了LLM。我们最初的尝试涉及一个简单的提示，要求单个模型生成重写以增强召回率。事实证明这太模棱两可了。例如，对于“1% 牛奶”，模型可能会返回“百分之一牛奶”——这是一个有效的同义词，但对于发现替代产品来说不是一个有用的重写。
这导致我们为三种不同的重写类型设计了专门的提示：替代、更广泛的查询_和_同义词。每种类型均由具有高级提示工程的专用提示处理 – 包含特定指令、思维链 (COT) 推理和少量示例。为了确保结果合乎逻辑且有用，我们应用了后处理护栏，包括语义相关性过滤器。这种结构化方法将我们的查询重写覆盖率提高到 95% 以上，所有三种类型的精度都达到 90% 以上。
在此成功的基础上，我们现在采用上下文工程来使重写更加可转换、个性化和会话感知。我们通过注入用户参与信号来实现这一目标，例如来自同一会话中后续搜索的转化率最高的产品类别。
表 2：由专门的 LLM 生成的结构化查询重写示例
5.3 语义角色标签 (SRL)
语义角色标签 (SRL) 是从用户查询中提取结构化概念的任务，例如产品、品牌和属性。这些标签对于从搜索检索和排名到广告定位和过滤器的一切都至关重要。
我们的目标是利用LLM的力量来生成高质量的标签。然而，搜索流量的幂律性质提出了一个挑战：我们无法预先计算每个可能查询的结果，因为新的和独特的搜索的“长尾”实际上是无限的，并且离线 LLM 处理成本高昂。
为了解决这个问题，我们设计了一个混合系统。强大的离线流程会生成高质量的数据，这些数据有两个目的：为我们最常见的“头”查询填充缓存，并为处理“长尾”的快速实时模型创建训练数据。如下图所示，系统的流程仅由缓存命中决定。
图 3. 混合 SRL 系统的架构。 实时流量基于缓存命中进行路由。高频“头”查询通过缓存立即提供服务，而“尾”查询则由实时、微调的模型处理。整个系统由离线管道提供支持，该管道生成数据以填充缓存并训练实时模型
6、离线系统（“老师”）：大规模生成高质量数据
对于我们的高频“头”查询，我们运行离线检索增强生成（RAG）和缓存管道。由于延迟不是这里的问题，因此我们可以使用复杂的技术来确保尽可能高的质量。其核心是上下文工程：用深入的 Instacart 特定知识来丰富提示。
图 4. 用于查询标记的 RAG 管道概述。情境工程注入 Instacart 领域知识，为LLM的推理奠定基础，并生成更准确的意图信号。 （注：用于说明的品牌示例均属虚构。）
考虑查询_“verdant machine”_。如果没有上下文，LLM可能会认为它是针对机械的。然而，我们的离线管道会自动利用内部数据系统的关键上下文来丰富提示，包括：
- 历史转化数据： 转化次数最多的品牌 (MuchPure) 和类别 (Smoothie Juices)。
- 产品目录信息： 语义相似度高的产品品牌名称，按嵌入分数排名。
有了这种背景，该模型就可以正确推断用户的意图：他们正在寻找冰沙品牌。生成后，后处理护栏会根据我们的目录验证标签。这个严格的过程有两个关键输出：
7、实时系统（“学生”）：长尾的微调模型
当用户的查询导致缓存未命中（表示长尾查询）时，它将被路由到我们的实时模型。这是一种主干网要小得多的语言模型（如 Llama3-8B），对于实时推理来说速度快且经济高效。
至关该模型在我们的离线“教师”管道生成的高质量“课程”数据集上进行了微调。通过这样做，较小的模型学会复制其较大模型的准确性以及我们注入的域上下文。这使我们能够为用户输入的几乎任何查询提供一致、高质量的体验。这种混合方法为我们提供了两全其美的优势：大规模LLM的原始力量，以及轻量级、可学习模型的速度和效率。
8、建立新的基础：实时推理的微调
我们的 SRL 系统中实时“学生”模型的成功不仅仅是一个项目的胜利；它证明了 Instacart 一项新的基础功能的可行性：微调更小的开源模型以大规模满足我们的特定需求。
虽然 SRL 系统是第一个生产应用程序，但构建和部署该模型的过程为我们平台的未来创新制定了蓝图。下面详细介绍了我们是如何做到的。
通过微调提炼知识
对于实时 SRL 模型，我们使用 LoRA（低阶适应）对开源 Llama-3–8B 模型进行了微调。该模型是根据离线“教师”管道的数据集进行训练的。这一过程有效地将知识和微妙的背景从较大的模型中提炼成更小、更高效的模型。
结果是显着的。我们经过微调的 8B 模型的性能与其学习的更大的前沿模型相当，以更高的精度实现了类似的 F1 分数。
图 5。我们经过微调的 8B 模型实现了与更大的基础模型相当的性能。与基线（深蓝色）相比，我们的生产模型（橙色）具有更高的精度（96.4% vs 95.4%）、较低的召回率（95% vs 96.2%）、F1 分数相当（95.7% vs 95.8%）。
9、生产之路：控制实时延迟
拥有一个优秀的模型只是成功的一半；在生产环境中提供服务并将延迟目标控制在数百毫秒内是一项重大的工程挑战。 A100 GPU 的开箱即用延迟接近 700 毫秒。我们通过一系列关键优化减少了延迟：
- 适配器合并和硬件升级： 将 LoRA 适配器权重直接合并到基本模型中并升级到 H100 GPU，使我们达到了 300 毫秒的目标。
- 量化权衡： 我们探索了量化 (FP8)，它将延迟又减少了 10%，但召回率略有下降。我们部署了非量化模型来优先考虑质量。
- 成本管理： 我们启用了 GPU 自动缩放，以便在非高峰时段在更少的 GPU 上运行，从而在不影响性能的情况下降低成本。
A/B 测试证实了成功：实时 LLM 显着提高了排名靠后 2% 的查询的搜索质量。通过尾部查询的新 SRL 标记，我们将“平均滚动深度”减少了 6%（用户更快地找到项目），而延迟仅略有增加。该系统现已上线，每周服务数百万个冷启动查询，并将与尾部查询搜索结果不佳相关的用户投诉减少了 50%。
10、要点
以下是将LLM纳入我们的生产搜索系统中学到的东西：
- 背景是防御护城河：通用LLM是一种商品；您的业务环境使您的应用程序具有防御性，因为领域知识是最有价值的资产。它广阔、喧闹、充满活力。它包括从用户参与信号（搜索后实际购买了哪些产品？）到现实世界的约束（特定商店现在货架上有什么？）的一切。过去，将这些数据注入传统的机器学习模型既困难又脆弱。今天的核心挑战是如何有效地将这些知识编码到LLM中。通过我们的工作，我们发现了一个清晰的有效性层次结构，每个层次结构都有自己的工程权衡：微调 > 上下文工程 (RAG) > 提示。每种方法都逐渐将通才模型转变为真正的领域专家。
- 从离线开始，战略性地进行实时：为了管理成本并证明价值，我们从高频“头”查询的离线 LLM 管道开始。这种经济高效的方法处理了大量流量，并生成了稍后训练长尾“学生”模型所需的数据。
- 整合，不要复杂化：我们通过用单个 LLM 主干替换大量遗留模型来简化我们的堆栈，减少维护并加速开发。
- 模型只是成功的一半：如果不能大规模服务流量，再好的模型也是毫无用处的。我们通过关键的生产工程将潜力转化为影响：适配器合并将延迟减少了 30%，智能缓存意味着只有 2% 的查询需要实时推理，GPU 自动扩展有效地管理了成本。
最终，这一旅程为我们带来的不仅仅是一个更智能的 QU 系统；它为电子商务搜索的未来奠定了新的基础。展望未来，我们将超越单一查询搜索，构建更智能的上下文感知系统。这意味着构建一个能够理解用户整个旅程并区分复杂意图的系统 – 将搜索_“烤宽面条配料”（物品搜索）与查询“快速烤宽面条食谱”（内容发现）或请求“我附近的烤宽面条送货”_（餐厅搜索）区分开来。通过了解这一背景，我们可以引导用户获得完美的体验，在 Instacart 的所有产品中打造无缝旅程。
11、参考文献
- 构建意图引擎：如何构建
