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

在這篇文章中，作者分享了他們在領(lǐng)英上開發(fā)生成式AI產(chǎn)品的經(jīng)驗。他們通過構(gòu)建一個基于大語言模型的系統(tǒng)，實現(xiàn)了對用戶問題的智能回答。然而，這個過程并非一帆風(fēng)順，他們遇到了許多挑戰(zhàn)，包括評估輸出質(zhì)量、調(diào)用內(nèi)部API、保持統(tǒng)一質(zhì)量等。盡管如此，他們還是取得了顯著的成果，并計劃繼續(xù)優(yōu)化和完善這個產(chǎn)品。

在過去的六個月里，在領(lǐng)英我們的團隊一直致力于開發(fā)一種新的 AI 驅(qū)動的產(chǎn)品體驗。我們想重新構(gòu)想會員們進行求職和瀏覽專業(yè)內(nèi)容的方式。

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

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

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

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

一、概覽

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

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

這時候，在幕后發(fā)生了以下事情：

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

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

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

1. 整體設(shè)計

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

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

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

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

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

對我們而言好使的招數(shù)是：

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

2. 開發(fā)速度

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

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

為了解決這個問題，我們采用了一個簡單的組織結(jié)構(gòu)：

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

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

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

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

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

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

3. 評價輸出好壞

評估我們回答的質(zhì)量比預(yù)期的要困難得多。這些挑戰(zhàn)大致來自三個方面：制定指南、擴展標(biāo)注和自動評估。

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

圖2：我們執(zhí)行的評估步驟。

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

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

4. 調(diào)用內(nèi)部API

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

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

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

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

• 基本類型（如字符串/布爾值/數(shù)字）
• JSON風(fēng)格的輸入和輸出schema

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

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

這樣的技能使大語言模型能夠執(zhí)行與我們的產(chǎn)品相關(guān)的各種任務(wù)，如查看個人資料、搜索文章/人員/職位/公司，甚至查詢內(nèi)部分析系統(tǒng)。同樣的技術(shù)也用于調(diào)用非LinkedIn API，如Bing搜索和新聞。

圖3：使用技能調(diào)用內(nèi)部API

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

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

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

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

還在死磕的事是：構(gòu)建一個統(tǒng)一的技能注冊機制，以便在我們的生成式AI產(chǎn)品中動態(tài)發(fā)現(xiàn)和調(diào)用封裝為LLM友好技能的API/智能體。（注：可以想象是個技能商店，智能音箱那種能夠動態(tài)添加天氣、音樂技能的機制）

5. 保持統(tǒng)一的質(zhì)量

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

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

構(gòu)建該助手感覺像是偏離了“原則性”的機器學(xué)習(xí)，而更像是在專家系統(tǒng)中調(diào)整規(guī)則。因此，盡管我們的評估變得越來越復(fù)雜，但我們的“訓(xùn)練”卻主要是提示詞工程，這更像是一門藝術(shù)而非科學(xué)。

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

6. 容量與延遲

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

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

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

還在死磕的事：

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

二、收獲

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

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

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

能夠走到這一步，離不開一群優(yōu)秀人士的巨大努力，我們將繼續(xù)學(xué)習(xí)并很快分享更多技術(shù)細節(jié)。敬請期待！

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

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

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