?核心內容

本文闡述了Instacart如何從傳統、分散的機器學習模型，轉向以LLM為核心，構建新一代、統一且高效的“意圖引擎”（Query Understanding, QU），旨在解決長尾搜索、數據稀疏及系統復雜性等關鍵挑戰。

一、戰略核心：LLM的領域化與系統整合

1. 立足LLM優勢，簡化系統：利用LLM的世界知識和推理能力，取代過去查詢分類、查詢重寫等多個獨立的定制模型，實現技術棧的集成與簡化，提高一致性。
2. 分層深度植入領域知識：采取“上下文工程（RAG）+ 后處理護欄 + 微調”的分層策略，將通用LLM轉化為Instacart的深度領域專家。其中，將專有知識編碼入模型權重的微調被視為處理復雜長尾查詢的關鍵長期目標。

二、關鍵應用與技術實現

1.查詢分類革新：

• 痛點：傳統模型基于帶噪的轉化數據，缺乏深層上下文理解。
• LLM方案：采用RAG模式，檢索Top-K轉化品類，利用LLM注入Instacart上下文（如層級產品分類法）重新排序，并通過語義相似性護欄進行校驗，顯著提升分類準確率和召回率。

2.結構化查詢重寫：

• 痛點：傳統系統覆蓋率低，生成的同義詞對商品發現價值有限。
• LLM方案：設計專用提示工程，為“替代品”“更寬泛查詢”“同義詞”三類重寫生成結構化結果，覆蓋率提升至95%以上，且準確率均超過90%。

3.混合式語義角色標注（SRL）：

• 架構：創新性地采用“教師-學生”混合系統，解決實時延遲和長尾查詢的開銷問題。
• “教師”離線：運行復雜的RAG流水線，利用歷史轉化、商品目錄等深厚上下文，大規模生成高質量、帶標簽的訓練數據，用于填充高頻查詢緩存。
• “學生”實時：針對緩存未命中的長尾查詢，部署經過“教師”數據微調（LoRA）的輕量級模型（如Llama3-8B），實現實時、高質量推理，性能媲美更大基礎模型。

三、生產化挑戰與工程優化

1. 馴服實時延遲：LLM在生產環境中的延遲是核心挑戰。通過適配器合并到基礎模型、硬件升級（H100 GPU）以及智能緩存策略，將延遲降至數百毫秒目標。
2. 效果驗證：實時LLM系統已顯著改善底部2%的長尾查詢搜索質量，將用戶找到商品的速度（平均滾動深度）降低6%，用戶投訴減少50%。

四、核心啟示與未來展望

1. 上下文是防御性護城河：通用LLM是商品，而領域知識（Context）才是核心價值，如何高效地將用戶互動、商品目錄等動態業務上下文編碼到LLM中，是構建可防御應用的要訣。
2. 從離線到實時策略：優先從處理高頻查詢的離線LLM流水線開始，驗證價值并生成訓練數據，再戰略性地轉向實時、輕量級的“學生”模型，是管理成本和驗證價值的有效路徑。
3. 整合而非復雜化：LLM應簡化現有技術棧，而非增加額外復雜性。
4. 工程決定成敗：優秀的模型必須通過嚴格的生產工程（適配器合并、緩存、GPU自動擴展）才能轉化為實際業務影響。

引言

用戶在Instacart上搜索商品時，輸入的內容并非總是措辭完美的句子。他們可能會輸入“不含麩質的面包”或“特大號自封袋”等非標準短語，這完全可以接受。我們的任務并非僅是字面理解用戶輸入內容，而是深入洞察其內在意圖。這個過程被稱為“查詢理解”（Query Understanding，QU），它是助力數百萬用戶在Instacart上找到所需商品的關鍵意圖引擎。準確實現查詢理解至關重要。

多年來，我們一直依賴傳統的機器學習模型。它們在處理大多數搜索時表現良好，但對于數量無限的、不常見、高度具體或表述富有創意的查詢，即我們稱之為“長尾搜索”（long-tail searches），我們希望提供真正智能的體驗。

這一目標指引我們走向了一種新的范式。我們沒有從零開始構建另一個定制模型，而是選擇立足于巨人的肩膀，利用LLM龐大的預訓練知識。我們看到了一個機會：不僅是使用這些模型，更是要引導它們成為我們垂直領域內的深度領域專家。本文將詳細介紹這一歷程。我們的戰略采取分層推進的方式，始于帶有護欄（Guardrails）的上下文工程（Context-Engineering），并以通過微調（Fine-Tuning）將專有知識直接注入LLM為最終目標。這種方法將一個通用模型轉變為真正的專業模型。這一轉變使我們的核心挑戰由特征工程（Feature Engineering）轉變為如何在管理延遲和成本的同時，將這些強大的骨干模型實現生產化部署。

傳統查詢理解面臨的挑戰

我們轉向LLM的旅程始于審視傳統查詢理解的不足之處。盡管查詢理解對于Instacart的搜索功能至關重要，但準確地解釋用戶意圖卻異常困難，原因如下：

• 寬泛查詢：諸如“健康食品”或“冷凍零食”等查詢很常見，但難以采取行動。它們缺乏特異性，使得縮小相關結果范圍變得困難，因為這些查詢可能涵蓋數十個品類。
• 缺乏標注數據：查詢理解工作位于整個數據流水線的上游，無法從點擊或轉化等直接反饋中受益。我們從用戶行為中推導出的偽標簽（pseudo-labels）本身就具有噪聲——用戶可能搜索“面包”，但最終購買了香蕉。生成干凈的標簽需要耗時且成本高昂的人工評估。
• 長尾查詢（Tail Queries）：高度具體或罕見的搜索，例如“紅辣椒香料”或“2%脫脂超高溫消毒巧克力奶”，存在數據稀疏性問題。在互動數據上訓練的模型由于歷史點擊或轉化有限而難以泛化，導致性能不佳。
• 系統復雜性：為了解決這些問題，我們歷來針對不同的查詢理解任務訓練和維護了多個獨立的模型。例如，查詢分類和查詢重寫由完全分離的系統處理，每個系統都有自己的邏輯（圖1）。每一個定制解決方案都需要自己的數據流水線、訓練和部署架構。這種異構性引入了不一致性，減緩了開發周期，并使整個查詢理解系統難以擴展和演進。

圖1：我們之前的查詢理解涉及多個獨立的模型來處理單個查詢理解任務。例如，查詢分類依賴于用于多標簽分類的FastText模型，而查詢重寫則由一個挖掘用戶會話行為的獨立系統生成。

LLM的優勢

為了解決這些問題，我們轉向LLM來整合和增強我們的查詢理解模型。它們提供了幾個關鍵優勢，可以提高Instacart搜索的準確性和效率：

• 世界知識和推理能力：LLM通過對多樣化文本數據的訓練，具備了世界知識，使它們能夠從用戶查詢中進行邏輯推理。例如，一個LLM已經理解“意大利歐芹”（Italian parsley）是“扁葉歐芹”（flat parsley）的同義詞，而“卷葉歐芹”（curly parsley）是一種常見的替代品。這種能力極大地減少了傳統模型所需的人工工程和專業數據，為我們提供了一個強大的起點。
• 簡化系統：由于LLM具備廣泛的語言處理能力，它們使能我們整合眾多定制模型。通過用單個LLM取代可以處理多個自然語言處理（NLP）任務的專業模型，我們消除了維護獨立模型及其不一致性所帶來的復雜性。

LLM作為查詢理解：我們的實戰策略

我們通過以下三種方式植入Instacart的領域上下文來整合LLM：

1. 上下文工程：我們的主要方法是檢索增強生成（RAG）。我們構建了數據流水線來檢索Instacart特有的上下文（如轉化歷史和商品目錄數據），并將其直接注入到提示（Prompt）中。這使得模型能夠基于我們的業務實際情況進行推理。
2. 后處理護欄：我們通過驗證層來精煉LLM的輸出。這些護欄會過濾掉模型幻覺（Hallucinations），并強制模型輸出與Instacart的產品分類法保持一致。
3. 微調以獲取深層專業知識：對于最復雜的用例，我們利用專有數據對模型進行微調。這能將深層領域專業知識直接編碼到模型的權重中，代表了我們長期戰略中處理復雜長尾查詢的關鍵部分。

以下示例說明了我們如何利用其中一些技術來革新關鍵的查詢理解組件。

1. 查詢品類分類

Instacart的商品目錄遵循一個龐大、分層的產品分類法進行組織，它構成了數十億商品的主體，從“肉類”（Meat）等廣泛部門一直到“牛肋骨 > 牛小排”（Beef Ribs > Short Ribs）等特定子品類。準確地將查詢分類到我們的產品分類法中至關重要。它直接支撐召回（Recall）和排序（Ranking），幫助我們從正確的品類中檢索商品，并在查詢寬泛或模糊時智能地擴展搜索范圍。

我們的傳統方法將此視為一個大規模的多品類分類問題。對于一個給定的查詢，模型會從一個扁平列表中預測出最有可能的Top-K個品類。例如，對于“黃油牛奶”（butter milk），它可能會預測出“乳制品”（Dairy，0.95）和“牛奶”（Milk，0.92）作為獨立、非層次化的輸出。

這種傳統方法存在兩個主要的局限。首先，因為它是在帶噪聲的轉化數據上訓練的（例如，用戶搜索“面包”卻購買了香蕉），它可能會產生不相關的建議。其次，它缺乏更深層次的上下文理解，使其無法利用世界知識來正確分類“素食烤肉”（vegan roast）等新的或細微差別的查詢，如表1所示。

我們基于LLM的新方法通過三步過程顯著提高了準確率（Precision）和召回率。首先，我們檢索每個查詢的Top-K個轉化品類作為初始候選；其次，我們使用LLM注入Instacart上下文來重新排序它們；最后，我們應用后處理護欄。這個過濾器計算原始查詢嵌入與LLM預測的品類路徑嵌入之間的語義相似性得分，濾除任何低于我們相關性閾值的組合。

表1：傳統模型與基于LLM的新方法在品類分類方面的比較。

圖2：用于查詢品類分類的LLM系統概述。

2. 查詢重寫

查詢重寫對于提高召回率至關重要，尤其是當原始查詢未能返回足夠結果時。我們的傳統系統從用戶會話數據中提取候選重寫，但這種方法覆蓋范圍有限，只覆蓋了50%的搜索流量，并且通常無法為商品發現生成有用的替代方案。

為了解決這個問題，我們轉向了LLM。我們最初的嘗試是使用一個簡單的提示，要求單個模型生成用于增強召回的重寫。但這被證明過于模糊。例如，對于“1%牛奶”（1% milk），模型可能會返回“百分之一牛奶”（one percent milk）——這是一個有效的同義詞，但對于商品發現而言并非有用的重寫。

這促使我們為三種不同的重寫類型設計了專用的提示：替代品（Substitutes）、更寬泛的查詢（Broader queries）和同義詞（Synonyms）。每種類型均由一個采用高級提示工程（Prompt Engineering）的專用提示驅動——包括具體的指令、思維鏈（Chain-of-Thought，COT）推理和少樣本示例（Few-Shot Examples）。為了確保結果是邏輯且有用的，我們應用了后處理護欄，包括語義相關性過濾器。這種結構化方法將我們的查詢重寫覆蓋率提高到95%以上，所有三種類型的準確率均達到90%以上。

基于這項成功，我們現在正采用上下文工程使重寫更具轉化效率、個性化并具備會話感知能力。我們通過注入用戶互動信號來實現這一目標，例如用戶在同一會話中后續搜索的Top轉化產品品類。

表2：由專業化LLM生成的結構化查詢重寫示例。

3. 語義角色標注（SRL）

語義角色標注（Semantic Role Labeling，SRL）是一項從用戶查詢中提取結構化概念（如商品、品牌和屬性）的任務。這些標簽對于從搜索召回、排序到廣告定位和過濾器等各項功能都至關重要。

我們的目標是利用LLM的力量來生成高質量標簽。然而，搜索流量的冪律分布特性帶來了挑戰：我們無法預先計算所有可能查詢的結果，因為新的和獨特的搜索組成的“長尾”實際上是無限的，且離線LLM的處理開銷巨大。

為了解決這個問題，我們設計了一個混合系統。一個強大的離線流程生成高質量數據，用于兩個目的：為我們最常見的“頭部”查詢填充緩存，并為處理“長尾”查詢的快速實時模型創建訓練數據。該系統的工作流程，如下圖所示，簡單地由緩存命中情況決定。

圖3：混合語義角色標注系統的架構。實時流量根據緩存命中情況進行路由。高頻的“頭部”查詢通過緩存即時響應，而“長尾”查詢則由一個實時的、經過微調的模型處理。整個系統由一個離線流水線驅動，該流水線生成數據用于填充緩存和訓練實時模型。

離線系統（“教師”）：大規模生成高質量數據

對于我們的高頻“頭部”查詢，我們運行一個離線的檢索增強生成（RAG）和緩存流水線。由于此處延遲并非關鍵考量，我們能夠運用復雜的技巧來確保最高的數據質量。其核心在于上下文工程：利用深厚的Instacart特有知識來豐富提示。

圖4：用于查詢標簽的檢索增強生成流水線概述。上下文工程注入Instacart領域知識，以支撐LLM的推理，并生成更準確的意圖信號。（注：用于說明的品牌示例是虛構的。）

考慮查詢“verdant machine”。如果沒有上下文，LLM可能會假設它指的是機械。然而，我們的離線流水線會自動利用來自內部數據系統的關鍵上下文來豐富提示，包括：

• 歷史轉化數據：Top轉化品牌（MuchPure）和品類（Smoothie Juices）。
• 商品目錄信息：具有高語義相似性的產品品牌名稱，按嵌入分數排序。

在這些上下文的支持下，模型正確推斷出用戶的意圖：他們正在尋找一個思慕雪品牌。生成后，后處理護欄會根據我們的商品目錄驗證標簽。這個嚴謹的過程有兩個關鍵產出：

1. 一個包含經過驗證、高質量標簽的低延遲緩存，用于我們最常見的查詢。
2. 一個高質量的訓練數據集，用于訓練輕量級的實時模型。

實時系統（“學生”）：用于長尾查詢的微調模型

當用戶的查詢導致緩存未命中時（表明這是一個長尾查詢），它會被路由至我們的實時模型。這是一個具有更小骨干（例如Llama3-8B）的語言模型，它對于實時推理來說既快速又具成本效益。

至關重要的是，該模型是基于由我們的離線“教師”流水線生成的高質量“課程”數據集進行微調的。通過這樣做，這個較小的模型學會了復制其更大模型對應物的準確性，以及我們注入的領域上下文。這使我們能夠為用戶輸入的幾乎任何查詢提供一致、高質量的體驗。這種混合方法為我們提供了兩全其美的優勢：大型LLM的原始能力，以及輕量級、可學習模型的速度和效率。

構建新基礎：針對實時推理的微調

實時“學生”模型在我們語義角色標注系統中的成功不僅僅是一個項目的勝利；它驗證了Instacart一項新的基礎能力的可行性：即微調更小的、開源的模型，以大規模地滿足我們的特定需求。

雖然語義角色標注系統是第一個生產應用，但構建和部署這個模型的過程為我們平臺上未來的創新奠定了藍圖。以下是我們如何實現它的更深入了解。

通過微調蒸餾知識

對于實時語義角色標注模型，我們使用低秩適應（Low-Rank Adaptation，LoRA）微調了一個開源的Llama-3-8B模型。該模型在來自離線“教師”流水線的數據集上進行訓練。這個過程有效地將來自更大模型的知識和細粒度的上下文蒸餾到這個更小、更高效的模型中。

結果非常顯著。我們微調后的8B模型，其性能與它所學習的更大前沿模型相當，以更高的準確率（Precision）實現了相近的F1分數。

圖5：我們微調后的8B模型實現了與更大基礎模型相當的性能。與基線（深藍色）相比，我們的生產模型（橙色）具有更高的準確率（96.4% 對 95.4%），稍低的召回率（95% 對 96.2%），以及相仿的F1分數（95.7% 對 95.8%）。

投入生產之路：馴服實時延遲

擁有一個出色的模型只是成功的一半；然而，在生產環境中以低至數百毫秒的延遲目標來部署它構成一項重大的工程挑戰。原生延遲在使用A100 GPU時接近700ms。我們通過一系列關鍵優化來降低了延遲：

• 適配器合并與硬件升級：將LoRA適配器權重直接合并到基礎模型中，并升級到H100 GPU，使我們達到了300ms的目標。
• 量化（Quantization）取舍：我們探索了FP8量化，這使延遲又降低了10%，但召回率略有下降。我們部署了未量化的模型以優先保證質量。
• 成本管理：我們啟用了GPU自動擴展，在非高峰時段使用更少的GPU運行，從而在不犧牲性能的情況下降低了成本。

A/B測試證實了我們的成功：實時LLM有意義地改善了底部2%查詢的搜索質量。通過針對長尾查詢的新語義角色標注標簽，我們將“平均滾動深度”（即用戶找到商品所需的速度）降低了6%，而延遲僅略有增加。該系統現已正式發布，每周為數百萬次冷啟動查詢提供服務，并將與長尾查詢結果不佳相關的用戶投訴降低了50%。

關鍵啟示

以下是我們從將LLM投入到生產搜索系統中所學到的經驗：

• 上下文是構建可防御護城河的關鍵：通用LLM是一種商品；您的業務上下文才是賦予您的應用防御性的原因，因為領域知識是最有價值的資產。它是龐大、嘈雜且動態的。它包括從用戶互動信號（搜索后實際購買了哪些商品？）到真實世界約束（特定商店貨架上現在有什么？）的一切。過去，將這些數據注入傳統機器學習模型既困難又脆弱。而今天，核心挑戰是如何有效地將這些知識編碼到LLM中。通過我們的工作，我們發現了一個清晰的有效性階梯，每種方法都有其工程取舍：微調 > 上下文工程（RAG） > 提示工程。每種方法都逐步將一個通用模型轉變為真正的領域專家。
• 從離線開始，戰略性地轉向實時：為了管理成本和驗證價值，我們首先從處理高頻“頭部”查詢的離線LLM流水線著手。這種具成本效益的方法處理了大部分流量，并生成了稍后訓練用于處理長尾查詢的“學生”模型所需的數據。
• 整合，而非復雜化：我們通過用單個LLM骨干取代眾多傳統模型，簡化了技術棧，減少了維護工作，并加速了開發。
• 模型只是成功的一半：如果一個優秀模型無法大規模服務流量，那么它就是失效的。我們通過關鍵的生產工程將潛力轉化為影響力：適配器合并將延遲降低了30%，智能緩存意味著只有2%的查詢需要實時推理，而GPU自動擴展有效地管理了成本。

最終，這段旅程不僅為我們提供了一個更智能的查詢理解系統；它也為未來的電子商務搜索奠定了新基礎。展望未來，我們正從單一查詢搜索擴展，構建一個更智能、上下文感知的系統。這意味著要建立一個能夠理解用戶整個旅程并區分復雜意圖的系統——例如，區分搜索“千層面配料”（商品搜索）與查詢“快速千層面食譜”（內容發現），或請求“我附近的千層面外送”（餐廳搜索）。通過理解這種上下文，我們可以引導用戶獲得完美的體驗，在Instacart的所有產品中創造無縫的旅程。

來源：???https://tech.instacart.com/building-the-intent-engine-how-instacart-is-revamping-query-understanding-with-llms-3ac8051ae7ac??

本文轉載自??????Andy730??????，作者：常華