錯誤率從10%降至0.01%，領英全面分享LLM應用落地經驗-人工智慧-PHP中文網

隨著大型語言模型（LLM）技術日漸成熟，各行各業加快了 LLM 應用落地的步伐。為了改進 LLM 的實際應用效果，業界做出了許多努力。近期，領英（LinkedIn）團隊分享了他們在建立生成式 AI 產品的過程中總結的寶貴經驗。領英表示基於生成式人工智慧建構產品並非一帆風順，他們在許多地方都遇到了困難。以下是領英部落格原文。過去六個月，我們 LinkedIn 團隊一直在努力開發一種新的人工智慧體驗，試圖重新構想我們的會員如何進行求職和瀏覽專業內容。生成式人工智慧的爆發性成長讓我們停下來思考，一年前不可能實現的事情現在有了哪些可能。我們嘗試了很多想法，但都沒有成功，最終發現產品需要如下關鍵點：更快地獲取信息，例如從帖子中獲取要點或了解公司最新動態。將資訊點連接起來，例如評估您是否適合某個職位。取得建議，例如改善您的個人資料或準備面試。 ....

錯誤率從10%降至0.01%，領英全面分享LLM應用落地經驗

範例：新開發的系統工作方式

我們透過一個現實場景來展示新開發的系統是如何運作的。想像一下，您正在滾動瀏覽 LinkedIn 資訊流，偶然發現了一篇關於設計中的可訪問性的有趣帖子。除了這篇文章之外，您還會刷到一些入門問題，以便更深入地研究該主題，您很好奇，例如點擊“科技公司中可訪問性推動商業價值的例子有哪些？”

系統後台操作：

選擇合適的智能體：系統會接受您的問題並決定哪個AI 智能體最適合處理它。在這種情況下，它會識別您對科技公司內部可訪問性的興趣，並將您的查詢路由到專門執行通用知識搜尋的 AI 智慧體。
收集資訊：AI 智能體呼叫內部 API 和 Bing 的組合，搜尋具體範例和案例研究，突出設計的可訪問性如何為技術領域的商業價值做出貢獻。
制定回覆：有了必要的訊息，智慧體現在可以撰寫回應。它將數據過濾並合成為連貫、資訊豐富的答案，為您提供清晰的範例，說明可訪問性計劃如何為科技公司帶來商業價值。為了使體驗更具互動性，系統會呼叫內部 API 來使用文章連結或貼文中提到的人員簡介等附件。

你可能會提問「我如何將我的職業生涯轉向這個領域」，那麼系統會重複上述過程，但現在會將你轉給職業和工作（career and job）AI智能體。只需點擊幾下，您就可以深入研究任何主題，獲得可行的見解或找到下一個工作機會。

技術基礎：

大部分新功能是藉助 LLM 技術才成為可能。

整體設計：

系統 pipeline 遵循檢索增強生成（RAG），這是生成式人工智慧系統的常見設計模式。令人驚訝的是，建造 pipeline 並沒有我們預期的那麼令人頭痛。在短短幾天內，我們就建立並運行了基本框架：

路由：

決定查詢是否在範圍內，以及將其轉發給哪個 AI 智能體。

檢索：面向 recall 的步驟，AI 智能體決定調用哪些服務以及如何調用（例如 LinkedIn 人物搜尋、Bing API 等）。
產生：面向精度的步驟，篩選檢索到的雜訊數據，對其進行過濾並產生最終響應。
圖 1：處理使用者查詢時使用簡單的 pipeline。 KSA 代表「知識共享智能體」，是數十種可以處理使用者查詢的智能體之一。
關鍵設計包括：
固定三步pipeline；
用於路由/ 檢索的小型模型，用於生成的較大模型；
基於嵌入的檢索(EBR)，由內存數據庫提供支持，將響應示例直接注入到提示（prompt）中；
每步特定的評估pipeline，特別是對於路由/ 檢索。
開發速度
我們決定將開發任務拆分為由不同人員開發獨立智能體：常識、工作評估、職位要點等。
透過並行化開發任務，我們提高了開發速度，但這是以「碎片」為代價的。當與透過不同的模型、提示或工具進行管理的助手（assistant）進行後續互動時，保持統一的使用者體驗變得具有挑戰性。
為了解決這個問題，我們採用了一個簡單的組織結構：
一個小型「水平（horizontal）」工程pod，處理通用組件並專注於整體體驗，其中包括：
託管產品的服務
評估/ 測試工具
所有垂直領域使用的全域提示範本（例如智能體的全域身分（identity）、對話歷史、越獄防禦等）
為iOS/Android/Web 用戶端共用UX 元件
伺服器驅動的UI 框架，用於發布新的UI 更改，而無需更改或發布客戶端程式碼。
關鍵設計包括：
分而治之，但限制智能體數量；
具有多輪對話的集中式評估pipeline；
共享提示模板（例如“身份（identity）”定義）、UX 模板、工具和檢測
證明，評估響應的品質比預期的更加困難。這些挑戰可大致分為三個領域：制定指南（guideline）、擴展註釋和自動評估。
制定 guideline 是第一個障礙。以工作評估為例：點擊「評估我是否適合這份工作」並得到「你非常適合」並沒有多大用處。我們希望回應既真實又富有同理心。一些用戶可能正在考慮轉行到他們目前不太適合的領域，並需要幫助了解差距和後續步驟。確保這些細節一致對註釋者非常關鍵。
擴充註釋是第二步。我們需要一致和多樣化的註釋器。我們內部的語言學家團隊建立了工具和流程，以評估多達 500 個日常對話並獲得相關指標：整體品質分數、幻覺率、AI 違規、連貫性、風格等。
自動評估工作仍在進行中。如果沒有自動評估，工程師只能目測結果並在一組有限的範例上進行測試，並且要延遲 1 天以上才能了解指標。我們正在建立基於模型的評估器來評估上述指標，並努力在幻覺檢測方面取得一些成功，端到端自動評估 pipeline 將實現更快的迭代。

之後中使用 2：評估步驟。

調用內部 API

然而，LLM 尚未接受過這些資訊的訓練，因此無法使用它們進行推理和產生回應。
解決此問題的標準模式是設定檢索增強產生 (RAG) pipeline，透過此 pipeline 呼叫內部 API，並將其回應注入到後續的 LLM 提示中，以提供額外的上下文來支援回應。
許多此類資料透過各種微服務中的 RPC API 在內部公開。
我們透過圍繞這些 API 包裝「技能」來解決這個問題。每個技能都有以下組件：

調用RPC API 的配置（端點、輸入模式、輸出模式等）
LLM 友好的輸入和輸出模式
原始類型（字串/ 布林/ 數字）值
JSON 模式的輸入和輸出模式描述
LLM 友好模式和實際RPC 模式之間映射的業務邏輯

同樣的技術也用來呼叫非 LinkedIn API，例如 Bing 搜尋。
圖 3中：使用技能呼叫內部 API。

我們寫提示，要求 LLM 決定使用什麼技能來解決特定的工作（透過規劃選擇技能），然後輸出參數來呼叫技能（函數呼叫）。由於調用的參數必須與輸入模式匹配，因此我們要求 LLM 以結構化方式輸出它們。大多數 LLM 都接受過用於結構化輸出的 YAML 和 JSON 訓練。我們選擇 YAML 是因為它不太冗長，因此比 JSON 消耗更少的 token。

我們遇到的挑戰之一是，雖然大約90% 的情況下，LLM 回應包含正確格式的參數，但大約10% 的情況下，LLM 會出錯，並且經常輸出格式無效的數據，或者更糟的是甚至不是有效的YAML。

這些錯誤對人類來說是微不足道的，但卻會導致解析它們的程式碼崩潰。 10% 是一個足夠高的數字，我們不能輕易忽視，因此我們著手解決這個問題。

解決此問題的標準方法是檢測它，然後重新提示 LLM 要求其糾正錯誤並提供一些額外的指導。雖然這種方法有效，但它增加了相當大的延遲，並且由於額外的 LLM 呼叫而消耗了寶貴的 GPU 容量。為了規避這些限制，我們最終編寫了一個內部防禦性 YAML 解析器。

透過對各種有效負載的分析，我們確定了 LLM 所犯的常見錯誤，並編寫了程式碼以在解析之前適當地檢測和修補（patch）這些錯誤。我們也修改了提示，針對其中一些常見錯誤注入提示，以提高修補的準確率。我們最終能夠將這些錯誤的發生率減少到約 0.01%。

我們目前正在建立一個統一的技能註冊表，用於在我們的生成式人工智慧產品中，動態發現和調用打包為 LLM 友好技能的 API / 智能體。

容量和延遲

容量和延遲始終是首要考慮因素，這裡提及一些考慮維度：

質量與延遲：思想鏈(CoT) 等技術對於提高質量和減少幻覺非常有效，但需要從未見過的token，因此增加了延遲。
吞吐量與延遲：運行大型生成模型時，通常會出現 TimeToFirstToken (TTFT) 和 TimeBetweenTokens (TBT) 隨著利用率的增加而增加的情況。
成本：GPU 叢集不易取得且成本高昂。一開始我們甚至必須設定測試產品的時間表，因為會消耗太多 token。
端到端流式處理（streaming）：完整的答案可能需要幾分鐘才能完成，因此我們流式處理所有請求，以減少感知延遲。更重要的是，我們實際上在 pipeline 中端到端地進行串流處理。例如，決定調用哪些 API 的 LLM 回應是逐步解析的，一旦參數準備好，就會觸發 API 呼叫，而無需等待完整的 LLM 回應。最終的綜合回應也會使用即時訊息基礎設施一路傳輸到客戶端，並根據「負責任的 AI」等進行增量處理。
非同步非阻塞 pipeline：由於 LLM 呼叫可能需要很長時間才能處理，因此我們透過建置完全非同步非阻塞 pipeline 來優化服務吞吐量，該 pipeline 不會因 I/O 執行緒阻塞而浪費資源。
有興趣的讀者可以閱讀部落格原文，了解更多研究內容。原文連結：https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product