中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

在這篇文章中，作者分享了他們在領英上開發生成式AI產品的經驗。他們通過構建一個基于大語言模型的系統，實現了對用戶問題的智能回答。然而，這個過程并非一帆風順，他們遇到了許多挑戰，包括評估輸出質量、調用內部API、保持統一質量等。盡管如此，他們還是取得了顯著的成果，并計劃繼續優化和完善這個產品。

在過去的六個月里，在領英我們的團隊一直致力于開發一種新的 AI 驅動的產品體驗。我們想重新構想會員們進行求職和瀏覽專業內容的方式。

生成式人工智能的爆發讓我們停下腳步，思考現在能夠實現而一年前還無法實現的事情。我們嘗試了許多想法，但都不怎么靈。最終以信息流和招聘啟事切入找到了釋放AI強大力量的方法，它可以幫助用戶：

• 總結關鍵點，例如從帖子中總結要點或了解各個公司的最新動態。
• 關聯不同信息，例如評估自己與某個職位的匹配度。
• 獲取建議，例如改進個人資料或準備面試。
• 等等……

那么，這活容易么？哪些進展順利，哪些不好搞？在生成式人工智能的基礎上構建應用其實很麻煩的。我們遇到了一堆難題。

我們希望揭開這活的的神秘面紗，分享具體哪些部分好搞，哪些部分不好搞，以及接下來還需要搞定什么。

一、概覽

讓我們通過一個真實場景來展示這個系統是如何工作的。

想象一下，你正在瀏覽領英的動態，偶然發現了一篇關于產品設計中確保殘障人士可訪問性（注:就是那種系統里可以把字體放大好多倍的功能）的有趣帖子。在帖子旁邊，你看到了幾個入門問題，以便你更深入地了解這個主題。你感到好奇，點擊了“有哪些例子說明確保殘障人士可訪問性可以推動科技公司的商業價值？”

這時候，在幕后發生了以下事情：

1. 選擇合適的智能體：這是一切的原點。我們的系統接收你的問題，并決定哪個AI智能體最適合處理它。在上面這個例子中，它識別出你對科技公司中如何確保殘障人士可訪問性感興趣，就會將你的問題導引到負責一般知識性問題的AI智能體。
2. 收集信息：然后就得做些基礎工作。AI智能體會調用內部API和Bing，搜索具體的例子和研究案例，這些例子和研究案例突出了設計中的確保這種可訪問性與科技公司商業價值的關聯。這些就是產生最終回答的原始素材庫。
3. 編寫回答：有了回答所需要的原始信息，智能體就開始編寫回答了。它將數據過濾并綜合成一個連貫、信息豐富的答案，為你提供明確回答。為了避免生成太多的文字并使體驗更具互動性，會調用內部API來對回答進行修飾，比如加入文章鏈接或帖子中提到的人物的資料。

作為用戶你可能會接著問“我如何將自己的職業轉向這個領域？”，然后我們會重復上面這三個步驟，但這次會將你路由到職業和工作的AI智能體。只需點擊幾下，你就可以深入了解任何主題，獲得可操作的見解或找到你下一個大好機會。

這一切在很大程度上得益于大語言模型（LLMs）的出現，我們認為進一步分享我們在構建這些功能時面臨的挑戰和幕后故事會很有趣。

1. 整體設計

圖1：簡化的用戶查詢過程。

KSA代表“知識共享智能體”，是數十個能夠處理用戶查詢的智能體之一

大家可能已經注意到，我們的流程遵循了檢索增強生成（RAG），這是生成式AI系統中常見的設計模式。構建這個流程比我們預期的要容易得多。在短短幾天內，我們就搭建好了基本框架并使其運行起來：

• 路由(Routing)：判斷問題是否在處理范圍內，是的話將其轉發給哪個AI智能體。智能體的例子包括：崗位評估、理解公司、帖子要點提取等各種智能體。
• 檢索(Retrival)：這是一個逐步確定詳細信息的步驟（召回率導向的步驟），AI智能體決定調用哪些服務以及如何調用（例如，LinkedIn People Search、Bing API等）。
• 生成(Generation)：這是一個精準度導向的步驟，它篩選檢索到的各種數據，過濾它，并產生最終響應內容。

鑒于“路由”和“檢索”的分類性質，微調它們相對順暢：我們構建了開發測試集，并使用提示詞工程和內部模型進行優化。然而，“生成”則是一個完全不同的故事。它遵循80/20法則；很快可以達到80%的準確度，但剩下的20%卻耗費了我們大部分人的所有工作時間。當你的產品期望99%以上的答案都非常出色時，即使使用最先進的模型，每一個1%的進步也仍然需要大量的工作和創造力。

對我們而言好使的招數是：

• 固定的三步流程
• 用小模型干路由/檢索，用大模型干生成
• 基于內存數據庫的EBR（Embedding-Based Retrieval (EBR) ），直接將響應示例注入到我們的提示詞中（窮人版微調）。（注：EBR是個技術名詞，感興趣的自己再查吧。）
• 在路由和檢索過程中針對每個步驟做特定評估

2. 開發速度

我們希望多個團隊并行快速推進，因此決定將任務拆分為由不同人員開發的獨立智能體（即AI智能體）：崗位評估、理解公司、帖子要點提取等智能體分別由不同團隊負責。

這種方法帶來了顯著的不良影響（compromise）。通過并行處理任務，我們在速度上取得了優勢，但這卻以碎片化為代價。當與智能體的交互可能由不同的模型、提示詞或工具管理時，保持統一的用戶體驗變得極其具有挑戰性。

為了解決這個問題，我們采用了一個簡單的組織結構：

1）一個小型“橫向”工程小組，負責處理公共組件并專注于整體體驗。這包括：

• 各種支撐此產品的基礎服務
• 評估/測試工具
• 所有垂直領域使用的全局提示詞模板（例如，智能體的全局身份標識、對話歷史、越獄攻擊的防護等）
• iOS/Android/Web客戶端的共享UX組件（注：一般就是指按鈕、下拉列表這些）
• 一個服務器端驅動的UI框架，用于發布新的UI更改，而無需更改或發布客戶端代碼。（注：因為UI在服務端，那就需要有個在服務端生成UI的框架，很麻煩的一個東西）

2）多個“縱向”工程小組，各自對其智能體擁有自主權，例如：

• 個性化帖子摘要
• 崗位匹配度評估
• 面試技巧

3）那些東西對我們有用：

• 分而治之，但限制智能體的數量
• 建立一個中心化的，通過多輪對話支撐的評估過程
• 共享提示詞模板（如“身份”定義）、UX模板、工具及指令

3. 評價輸出好壞

評估我們回答的質量比預期的要困難得多。這些挑戰大致來自三個方面：制定指南、擴展標注和自動評估。

1. 制定指南：以崗位評估為例：點擊“評估我是否適合這份工作”卻得到“你非常不適合”的結果其實沒啥用。我們希望它既具有事實性又充滿同理心。有些用戶可能正在考慮轉行到他們目前并不十分適合的領域，并需要幫助了解差距和下一步行動。不能確保這些細節的一致性就沒法讓保持標注者保持評分的一致性。
2. 擴展標注：最初，團隊中的每個人都參與了討論（產品、工程、設計等），但我們知道我們需要一個更加有原則的方法，擁有一致且多樣化的標注者。我們內部的語言學家團隊建立了工具和流程，使我們能夠每天評估多達500次對話，并獲得以下方面的指標：整體質量分數、幻覺率、負責任的人工智能違規情況、連貫性、風格等。這成為我們了解趨勢、迭代提示詞并確保我們準備好上線的主要參考點。
3. 自動評估是終極目標，但仍在進行中：沒有它，工程師只能依靠主觀判斷和對有限示例的測試，并且需要1天以上的時間才能獲得反饋。我們正在構建基于模型的評估器來估算上述指標，并允許更快的實驗，我們在幻覺檢測方面取得了一些成功（但這并不容易！）。

圖2：我們執行的評估步驟。

工程師進行快速、粗略的評估以獲得方向性度量和判斷。標注者提供更詳細的反饋，但大約需要1天的時間。測試成員是最終的評判者，并為我們提供規模性的反饋，但單個更改的某些度量可能需要3天以上的時間。

還在死磕的事：端到端自動評估流程，以實現更快的迭代。

4. 調用內部API

領英擁有大量關于人、公司、技能、課程等的獨特數據，這些數據對于構建具有獨特和差異化價值的產品至關重要。然而，大語言模型（LLMs）并未經過這些信息的訓練，因此無法直接用于推理和生成響應。為了解決這個問題，一個標準的做法是設置檢索增強生成（RAG）流程，通過該流程調用內部API，并將它們的響應注入到后續的大語言模型提示詞中，以提供額外的上下文來支持生成響應。

這些獨特的數據中有很多是通過各種微服務中的遠程過程調用（RPC）API在內部公開的。這些API雖然這對于人類通過編程方式調用非常方便，但對于大語言模型來說并不友好。我們通過把這些API“包裝”成技能來解決這個問題。每個技能(Skill)都包含以下組件：

• 人類（和大語言模型）友好的描述：說明API的功能以及何時使用它。
• RPC API調用配置：包括端點、輸入、輸出schema等。

大語言模型友好的輸入和輸出schema：

• 基本類型（如字符串/布爾值/數字）
• JSON風格的輸入和輸出schema

業務邏輯：用于在大語言模型友好的schema與實際RPC schema之間進行映射。

（注：schema是個編程術語，也許可以翻譯成模式，拿excel表作類比，表頭是schema）

這樣的技能使大語言模型能夠執行與我們的產品相關的各種任務，如查看個人資料、搜索文章/人員/職位/公司，甚至查詢內部分析系統。同樣的技術也用于調用非LinkedIn API，如Bing搜索和新聞。

圖3：使用技能調用內部API

我們編寫了提示詞，要求大語言模型（LLM）決定使用哪種技能來解決特定任務（通過規劃來完成技能選擇），然后輸出調用該技能所需的參數（函數調用）。由于調用參數必須與輸入schema匹配，我們要求LLM以結構化的方式輸出它們。大多數LLM都經過YAML和JSON的結構化輸出訓練。我們選擇YAML是因為它更簡潔，因此消耗的tokens比JSON少。

我們遇到的一個挑戰是，雖然大約90%的時間里，LLM的響應包含了正確格式的參數，但有大約10%的時間，LLM會出錯（注：經常說的幻覺），并且經常輸出不符合要求的數據，或者更糟糕的是，甚至不是有效的YAML。雖然這些錯誤對人類來說微不足道，但會導致解析它們的代碼出錯。由于10%的比例足夠高，我們不能忽視這些微不足道的錯誤，因此我們著手解決這個問題。

解決這個問題的標準方法是檢測到錯誤，然后重新發提示詞給大語言模型，要求它在這些額外指示下糾正錯誤。雖然這種方法有效，但它增加了不小的延遲，并且由于額外的LLM調用而消耗了寶貴的GPU算力。為了繞過這些限制，我們最終編寫了一個內部防御性YAML解析器。

通過對各種調用參數（payload）的分析，我們確定了LLM常犯的錯誤，并編寫了代碼來在解析之前檢測和適當修補這些錯誤。我們還修改了提示詞，以便在這些常見錯誤周圍注入提示詞，以提高我們修補的準確性。最終，我們將這些錯誤的發生率降低到了約0.01%。（注：這其實是用規則補足模型的不足，降低成本）

還在死磕的事是：構建一個統一的技能注冊機制，以便在我們的生成式AI產品中動態發現和調用封裝為LLM友好技能的API/智能體。（注：可以想象是個技能商店，智能音箱那種能夠動態添加天氣、音樂技能的機制）

5. 保持統一的質量

團隊在首月內實現了我們目標體驗的80%，隨后又額外花費了四個月時間，致力于將我們的全面體驗完成度提升至95%以上——我們勤勉地工作，對各個方面進行精細化調整、優化和改進。然而，我們低估了檢測和減輕幻覺現象的挑戰，以及質量評分提升的難度（注：原文是速度應該是筆誤）——起初迅速攀升，隨后便迅速達到瓶頸期。

對于那些容忍一定錯誤率的產品而言，采用生成式AI進行構建無疑是一種令人耳目一新的直接方法。但這也帶來了不切實際的期望，初期的快速進展營造了一種“即將達成”的錯覺，而隨著后續每1%提升的改進速度顯著放緩，這種快速改進的錯覺變得令人沮喪。

構建該助手感覺像是偏離了“原則性”的機器學習，而更像是在專家系統中調整規則。因此，盡管我們的評估變得越來越復雜，但我們的“訓練”卻主要是提示詞工程，這更像是一門藝術而非科學。

還在死磕的事：對大語言模型（LLMs）進行微調，以使我們的流程更加數據驅動。（注：其實是肯定會出問題，所以修的要快）

6. 容量與延遲

容量和成員感知到的延遲始終是我們最關心的問題。以下是一些維度：

1. 質量 vs 延遲：像“思維鏈”（Chain of Thought, CoT）這樣的技術非常有效地提高了質量并減少了幻覺現象。但它們需要成員從未預想過的tokens，因此增加了成員感知到的延遲。
2. 吞吐量 vs 延遲：在運行大模型時，通常情況是“首個Token響應時間”（TimeToFirstToken, TTFT）和“Token間響應時間”（TimeBetweenTokens, TBT）會隨著使用率的增加而增加。在TBT的情況下，有時延遲甚至會呈現線性增長。如果你愿意犧牲這兩個方面的度量，獲得每秒Tokens數（TokensPerSecond, TPS）的兩倍或三倍增加是很容易的，但我們最初必須將它們限制得很緊。（注：否則用戶會覺得慢）
3. 成本：GPU集群并不容易獲得且成本高昂。在初期，我們甚至不得不為產品測試設定時間表，因為測試會消耗太多tokens并阻止開發人員工作。
4. 端到端流式傳輸：一個完整的答案可能需要幾分鐘才能完成，因此我們讓所有請求進行流式傳輸以減少感知到的延遲。更重要的是，我們實際上在流程內部實現了端到端的流式傳輸。例如，大語言模型（LLM）的響應會逐步解析出應調用的API，并在參數準備好后立即發起API調用，而無需等待完整的LLM響應。最終合成的響應也會通過我們的實時消息傳遞基礎設施進行流式傳輸，并對信任/負責任的AI分類等內容進行增量處理，直至到達客戶端。（注：就是通過流式提升可感知的響應速度，非流式會導致你等半天突然所有結果出來了）
5. 異步非阻塞管道：由于LLM調用可能需要很長時間來處理，我們通過構建一個完全異步非阻塞的管道來優化服務吞吐量，該管道不會因I/O阻塞的線程而浪費資源。

這些因素之間有時會產生有趣的相互作用。舉個例子，我們最初只限制了首個Token響應時間（TimeToFirstToken, TTFT），因為這對于我們初期產品延遲有直接影響。然而，隨著我們解決幻覺問題，并且思維鏈（Chain of Thought, CoT）在我們的提示詞中變得突出，如果我們忽略了Token間響應時間（TimeBetweenTokens, TBT）會對我們造成更大的傷害，因為任何“推理”token都會增加產品的延遲（例如，對于一個200個tokens的推理步驟，即使是10毫秒的TBT增加也意味著額外的2秒延遲）。這會導致我們公共平臺上的某些任務突然發出超時警告，我們不得不迅速增加算力以緩解這一問題。

還在死磕的事：

• 將更簡單的任務轉移到內部進行，并使用微調后的自己的模型進行處理。（注：潛在意思是專門化的模型要和通用大模型進行搭配）
• 為大語言模型（LLM）部署構建更可預測的基礎設施。（注：不理解，我猜是LLM吞吐量伸縮需要更可控）
• 減少每個步驟中浪費的tokens。

二、收獲

我們說的夠多了，為什么不讓產品自己說話呢？

這還不錯！特別是后續的建議中讓產品可以像維基百科那樣帶你進入一個充滿好奇心的“知識黑洞”的功能。

隨著我們不斷提高質量、開發新功能并優化流程以加快速度，我們很快就會向更多用戶推出上述功能。

能夠走到這一步，離不開一群優秀人士的巨大努力，我們將繼續學習并很快分享更多技術細節。敬請期待！

注：這里的產品、工程實踐其實和琢磨事之前分享的各種內容基本全部吻合，參見

原文鏈接：https://www.linkedin.com/blog/engineering/generative-ai/musings-on-building-a-generative-ai-product

原作者是：Juan Pablo BottaroandCo-authored byKarthik Ramgopal