Why DoorDash, Instacart, and Uber Eats Integrated LLMs Into Search Three Different Ways

为什么DoorDash、Instacart和Uber Eats以三种不同方式将大型语言模型整合到搜索中

ByteByteGo

2026年7月28日

WorkOS Pipes：更多上下文带来更智能的产品（赞助内容）

用户期望应用和代理能够直接接入他们日常使用的工具。每一种实现方式都需要不同的OAuth流程、不同的令牌生命周期，以及在编写第一行产品代码之前数周的基础设施建设。

WorkOS Pipes通过一次API调用即可完成。预构建的GitHub、Slack、Salesforce、Google Drive等连接器。Pipes处理OAuth、令牌刷新和凭证存储。每次调用真实提供商API时，都会使用全新的令牌。

连接到100多个提供商 →

在过去的几年中，三家最大的食品配送公司围绕大型语言模型重建了他们的搜索系统。DoorDash、Instacart和Uber Eats都在解决同一个问题：当用户在搜索框中输入内容时，如何理解用户的意图。他们也都在访问大致相同的科研成果。然而，他们最终构建的架构却呈现出显著差异。

这种差异是现代开发中使用大型语言模型最引人注目的特征之一。一旦我们理解每家公司为何选择不同的路径，就能建立一个思考如何将AI集成到任何生产系统中的思维模型。

将大型语言模型添加到现有技术栈归结为一个问题：大型语言模型应该多深入运行时环境？

最终，DoorDash、Instacart和Uber Eats对这个问题给出了不同的答案，而他们选择的具体大型语言模型只是次要因素。每家公司选择的具体模型也是次要因素。他们已有的基础设施才是决定答案的关键。

在本文中，我们将逐一分析他们不同的解决方案，尝试理解他们的选择，并揭示背后的规律。

免责声明：本文基于来自多个来源的公开信息。文末有参考文献。如果您发现任何不准确之处，请在评论区指出。

问题

在食品配送应用中输入“雨夜的健康餐”，观察返回的结果。目前我们得到的结果在实用性和令人印象深刻之间。五年前的相同查询可能只会返回一堆随机物品，因为关键词搜索将词语视为标记的集合而非意图，且查询本身对关键词匹配帮助有限。

这种模式在食品搜索的多个常见失败场景中反复出现。例如：

• 同义词："Soda"和"soft drink"描述的是同一产品，但关键词引擎会将它们视为不同标记。

• 拼写错误："Mozzarela"应检索到mozzarella结果，但拼写差异会破坏查询。

• 缩写："Gf pizza"表示无麸质披萨，系统需要识别缩写为完整短语的同义词。

• 混合语言：西班牙语的"pan"意为面包，而英语的"pan"意为烹饪器具，双语搜索栏需要进行歧义消除。

• 词义歧义：水果"Apple"和公司"Apple"拼写相同但含义不同，正确答案取决于上下文。

每个场景都可能是用户意图与商品目录描述错位的潜在时刻。

这两个更复杂的问题隐藏在表象之下：

• 长尾效应：杂货和餐厅平台会遇到大量独特的查询。任何基于转化数据训练的专用模型在处理仅出现几次的查询时都会遇到困难，因为稀有查询本质上就是稀有的。

• 约束问题：像“素食鸡肉三明治”这样的查询内部包含硬性约束，基于相似性检索可能会返回违反约束的鸡肉三明治，因为相似性评分仍然接近。饮食限制、过敏原和数量筛选都属于此类问题。

食品搜索是观察这些现象的最佳领域，因为所有这些失败模式会同时出现。在后续章节中，我们将探讨不同公司如何以不同方式处理这些情况。

您的基础设施平台不应成为您最大的项目 [虚拟活动]（赞助）

在一家价值20亿美元的AI公司中，平台工程师如何跟上日益增长的开发团队步伐？8月11日，加入Rogo的平台工程负责人Lawrence Aiello，了解他的团队如何评估并实施现代IaC平台。他将涵盖：

• Rogo在选择现代IaC平台时的评估标准，评估了Pulumi、OpenTofu、Crossplane等解决方案

• 基础设施运营中“开箱即用”的实际表现

• 为什么可靠的平台是AI驱动的基础设施工作流程的基础

如果您的基础设施平台已成为另一个需要维护的系统，这场会议就是为您准备的。

立即注册 →

DoorDash

当大型语言模型（LLM）在生产环境中变得可行时，DoorDash已经拥有用于商品和餐厅的知识图谱。该图谱为每个商品保存了结构化属性，包括菜品类型、饮食偏好、菜系、品牌和口味。

他们的方法是使用LLM离线丰富这个图谱，从SKU数据中提取属性，并仅在运行时使用LLM将查询解析为可以链接回图谱的片段。检索本身仍然保持基于关键词和图谱驱动。

以查询“小份无乳香草冰淇淋”为例，LLM将其分割为三个片段：

• “小份”是数量属性。

• “无乳”是饮食偏好属性，对应规范标签“无乳制品”。

• “香草冰淇淋”进一步拆分为菜品类型（“冰淇淋”）和口味（“香草”）。

每个片段随后链接到知识图谱中的特定字段。饮食偏好成为硬性筛选条件，因此只检索无乳制品商品。口味成为排名的软性偏好。菜品类型缩小了候选池。

请参见下图：

DoorDash方法的独特之处在于他们如何约束LLM的输出。

他们使用检索增强生成（RAG）作为防护网而非生成器。对于每个查询片段，近似最近邻查找从现有图谱中检索出最接近的前100个分类概念。然后提示LLM从该列表中选择，而不是发明新标签。这是一种对常规RAG模式的巧妙反转，通常RAG会将上下文注入生成器。在这里，RAG定义了整个输出空间，因此系统只会生成其余设计已经知道如何处理的概念。

实际效果是，热门菜品轮播的触发率提升了约30%，所有改进都通过一个运行时保持大部分传统架构实现。

关键在于，DoorDash的大型语言模型（LLM）主要在离线环境中运行，以批量处理为主，主要在运行时的边缘部分发挥作用。

Instacart

当Instacart的工程师首次使用现成的LLM对搜索查询“protein”进行分类时，模型返回了鸡肉、豆腐、牛肉等高蛋白食物。

从英语语言的角度来看，这个答案是合理的。问题在于，Instacart的实际用户在输入“protein”时，实际上是在寻找蛋白棒和蛋白粉。模型的通用世界知识与公司的特定用户行为存在方向偏差，这种小规模的失败揭示了Instacart必须解决的核心问题。

他们正在替换的系统非常复杂。

查询分类依赖FastText模型，查询重写来自单独挖掘会话行为的引擎，拼写修正、查询标记和货架分类各自运行独立模型，每个模型都有自己的数据管道和部署基础设施。维护负担相当沉重，长尾查询仍然存在问题，因为每个模型都需要自己的标注数据，而罕见查询的标注数据本质上就稀缺。

Instacart的策略分为三个层面：

• 上下文工程：检索增强生成（RAG）技术在LLM看到查询前，将Instacart特有的上下文（高转化率分类、历史转化数据、商品目录详情）注入提示词中。
• 后处理防护机制：语义相似度过滤器会剔除偏离原始查询的LLM输出。
• 微调：对于最复杂的任务，团队会在Instacart专有数据上对Llama-3-8B进行微调，使领域知识直接融入模型权重。

部署架构根据头部查询与长尾查询的分布进行拆分。

头部查询通过一个延迟容忍且深度上下文工程优化的离线RAG缓存流水线，而长尾查询则通过实时微调的Llama-3-8B模型处理，该模型通过适配器合并、H100 GPU和自动扩展技术将延迟控制在300ms以内。

缓存处理公司已见过的查询，而实时微调模型处理其余所有查询，这正是长尾冷启动查询的所在位置。这种拆分正好符合头部/长尾流量分布所鼓励的决策模式，因为预计算只有在查询重复时才有价值。

在实施该解决方案后，查询重写覆盖率从50%跃升至95%以上，替代词、扩展重写和同义词的精确度均达到90%以上。实时微调模型显著提升了底部2%查询（冷启动长尾）的搜索质量，使滚动深度降低6%，对长尾查询结果的投诉量减少一半。

关键在于，Instacart的LLM位于查询理解层，部分采用离线缓存，部分在线微调，而后续的检索和排序仍由传统机器学习和信息检索系统完成。LLM负责上游的语义解析，传统方法负责下游的执行落地。

Uber Eats

Uber Eats面临与其他公司相同的挑战，同时还存在额外的复杂性。他们需要在包括餐饮、杂货和零售在内的多个业务领域，跨越多个市场和大量语言环境中运行。

他们的原有架构是碎片化的，每个垂直领域都有独立的基于BERT的嵌入模型，部分场景使用词汇搜索，同时需要维护多个系统并行运行的运营开销。目标是构建一个统一的检索系统，通过一致的嵌入空间处理所有垂直领域、所有市场和所有语言。

他们最终选择的架构是经典的双塔结构，其中查询编码器和文档编码器分别在共享空间中生成向量，通过该空间内的相似性进行匹配。

关键创新在于每个塔内部的实现方式，因为两个塔都使用了微调后的Qwen大语言模型作为核心嵌入层。查询塔在线运行，实时对每个查询进行嵌入；文档塔离线运行，将数十亿文档预嵌入到HNSW向量索引中（一种基于图结构的快速相似性搜索系统）。这种分工使系统在经济上可行，因为如果在查询时对每个文档运行重型LLM将成本过高，而预计算一次并在检索时查询则是可实现的。

微调与架构选择同样关键。

Qwen原生支持世界知识和跨语言能力，这正是解决前述西班牙语“pan”问题的关键。通过在Uber自有查询-文档交互数据上微调，嵌入空间学习到Uber Eats用户真正关注的内容，这赋予了系统领域对齐能力。基础模型提供通用语义，微调则添加Uber Eats特有的规则。

系统在规模上的可行性依赖于一系列优化：

• Matryoshka表示学习训练出一个模型，其嵌入可截断为不同长度。Uber在生产环境中使用256维表示，相比完整1,536维的召回率损失低于0.3%。

• 标量量化（int7代替float32）再次将延迟降低一半。

• 在六边形、城市和履约类型上的预过滤器在ANN搜索前就缩小候选集规模。

数据揭示了成本效益。调整ANN参数k使延迟降低34%、CPU使用降低17%且召回率影响可忽略；量化在召回率高于0.95时将延迟减半；MRL使存储需求减少近50%。这些工程选择使微调后的LLM能够作为Uber Eats规模搜索系统的检索基础。

核心结论是：Uber Eats的LLM本身就是嵌入模型，因为每个查询和文档都通过LLM生成向量，所有层级的检索都依赖LLM生成的表示。

集成深度

如果将三家公司按"LLM在运行时的深度"排列在一条轴线上，可以发现以下模式：

• DoorDash位于左侧，LLM仅用于离线丰富商品目录，在线运行时仍主要依赖传统方法处理查询。

• Instacart位于中间，LLM通过离线RAG处理头部查询，尾部查询使用微调后的Llama-3-8B模型，下游检索仍采用传统方式。

• Uber Eats位于右侧，微调后的Qwen作为嵌入主干，对每个查询实时运行，并预计算到每个文档向量中。

每家公司在这条光谱上的位置主要由其现有基础设施决定。

• DoorDash 已经拥有一个知识图谱，传统检索可以利用这一图谱，因此最直接的收益来自于丰富图谱内容并教会查询如何与之交互。

• Instacart 拥有专门的查询理解模型，但维护成本较高，因此最大的突破来自于采用统一的 LLM 策略进行整合。

• Uber Eats 已经按业务领域运行着双塔嵌入基础设施，因此下一步自然选择是用微调后的 LLM 替换为共享的主干网络，使单一模型能够处理所有业务领域和所有语言。

这个教训表明，在询问某个任务应该使用哪种 LLM 之前，更重要的是思考在现有技术栈中 LLM 真正能发挥作用的位置。

结论

三家最大的食品配送公司在同一时间段内都围绕 LLM 重建了搜索系统，尽管研究文献存在重叠且生产环境约束相似，但最终形成了三种完全不同的架构。

食品搜索是一个适合研究的领域，因为它以多种方式同时打破了传统关键词检索的局限性。主观查询（例如“雨天的健康晚餐”）、长尾流量、多语言目录和复合约束等要素都存在于同一个搜索框中。

三种方法分别代表了不同的应用场景：

• DoorDash 使用 LLM 离线丰富知识图谱，而传统检索仍主导实时运行。

• Instacart 在查询理解层使用 LLM，通过微调的轻量模型处理热点路径中的长尾查询。

• Uber Eats 将 Qwen LLM 微调为双塔检索的嵌入主干网络，使每个查询和文档都能获得 LLM 生成的向量表示。

每家公司在这条光谱上的定位都与其现有基础设施密切相关，这正是为什么集成深度问题比模型选择更重要。

所有架构都体现了三个普遍的权衡：

• 混合系统是默认方案。传统检索、知识图谱和 ANN 索引仍然承担着大部分工作。

• 预训练模型的世界知识只是一个起点。领域上下文仍需通过 RAG、微调或两者结合注入到系统中。

• 安全防护是每个生产 LLM 系统的重要组成部分。受限词库、相似性过滤和分类学约束等机制在后台默默决定着输出是否与目录保持一致。

References:

• Uber 配送搜索平台的演进与规模扩展

• Uber Eats 配送中多语言语义搜索的扩展

• DoorDash 如何利用 LLM 实现更优的搜索检索

• 使用大语言模型构建 DoorDash 产品知识图谱

• 构建意图引擎：Instacart 如何利用 LLM 重构查询理解

• 利用 LLM 提升搜索发现能力