DoorDash、Instacart和Uber Eats为何以三种不同方式将LLM整合进搜索
内容提要
DoorDash、Instacart和Uber Eats以不同方式将LLM整合进搜索系统。DoorDash离线用LLM丰富知识图谱，运行时保持传统检索；Instacart用LLM处理查询理解，结合RAG和微调模型；Uber Eats将微调Qwen作为嵌入骨干，统一多垂直领域检索。三者差异源于现有基础设施，核心问题是LLM应深入运行时多深。
延伸解读
架构选择取决于现有基础设施
三家公司采用不同方案，并非单纯模型差异，而是由各自已有的技术栈决定。DoorDash已有知识图谱，因此LLM用于离线丰富图谱，运行时保持传统检索；Instacart原有多个独立的查询理解模型，维护成本高，因此用LLM统一查询理解；Uber Eats已有双塔嵌入架构，因此将LLM作为嵌入骨干。这提示我们在引入LLM时，应优先考虑现有系统瓶颈，而非盲目追求最新模型。
LLM集成深度的权衡
三家公司对LLM在运行时介入深度的选择不同：DoorDash最浅，LLM仅离线处理；Instacart居中，LLM处理查询理解，但检索仍用传统方法；Uber Eats最深，LLM直接作为嵌入模型，参与每个查询和文档的向量生成。深度越深，性能提升可能越大，但工程复杂度和成本也越高。Uber Eats通过量化、降维等优化来控制成本，说明深度集成需要配套的工程优化。
混合系统与领域适配是常态
即使深度集成LLM，三家公司仍保留传统检索、知识图谱或ANN索引等组件，形成混合系统。同时，预训练模型的世界知识只是起点，必须通过RAG或微调注入领域数据。例如，Instacart发现通用模型对“protein”的理解与用户实际意图不符，因此需要微调。这提醒我们，LLM落地必须结合业务数据，并设置约束或过滤等防护措施，确保输出符合实际需求。
Q&A
DoorDash、Instacart和Uber Eats在搜索中集成LLM的方式有何不同？
DoorDash主要离线使用LLM丰富知识图谱，运行时保持传统检索；Instacart用LLM处理查询理解，结合RAG和微调模型；Uber Eats将微调Qwen作为嵌入骨干，统一多垂直领域检索。
DoorDash如何利用LLM改进搜索？
DoorDash使用LLM离线从SKU数据中提取属性来丰富知识图谱，运行时仅用LLM将查询解析为可链接到图谱的片段，检索仍由关键词和图谱驱动。例如，查询“small no-milk vanilla ice cream”被分割为数量、饮食偏好和口味等属性，并映射到图谱字段，其中饮食偏好作为硬过滤器。
Instacart在搜索中如何结合RAG和微调模型？
Instacart采用分层策略：对于高频查询，使用离线RAG和缓存管道，通过检索增强生成注入上下文；对于低频尾部查询，使用实时微调的Llama-3-8B模型，通过适配器合并和H100 GPU保持低延迟。此外，还使用语义相似性过滤作为后处理护栏。
Uber Eats如何将LLM作为嵌入骨干？
Uber Eats采用双塔架构，查询塔和文档塔都使用微调的Qwen LLM作为嵌入层。查询塔在线运行，文档塔离线预嵌入数十亿文档到HNSW索引。通过Matryoshka表示学习、标量量化和预过滤等优化，使系统在规模上可行。
为什么三家公司选择了不同的LLM集成深度？
主要取决于它们已有的基础设施。DoorDash已有知识图谱，因此离线丰富图谱最有效；Instacart有难以维护的多个查询理解模型，因此统一到LLM策略收益最大；Uber Eats已有双塔嵌入基础设施，因此将LLM作为共享骨干是自然下一步。
在搜索中集成LLM时，有哪些常见的挑战？
常见挑战包括同义词、拼写错误、缩写、语言混合、词义歧义，以及长尾查询和约束问题（如“素食鸡肉三明治”）。这些挑战导致关键词检索失败，需要LLM来理解意图。
三家公司集成LLM后取得了哪些效果？
DoorDash的触发率提升约30%；Instacart的查询重写覆盖率从50%提升到95%以上，尾部查询的滚动深度减少6%，投诉减半；Uber Eats通过优化将延迟降低34%，CPU降低17%，存储减少近50%。
在搜索系统中集成LLM时，有哪些通用权衡？
通用权衡包括：混合系统是常态，经典检索仍承担大部分工作；预训练模型的世界知识只是起点，仍需通过RAG或微调注入领域上下文；护栏（如约束词汇、相似性过滤）对保持输出与目录一致至关重要。
