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

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

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

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

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

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

一、概覽

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

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

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

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

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

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

1. 整體設(shè)計(jì)

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

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

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

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

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

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

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

2. 開發(fā)速度

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

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

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

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

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

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

• 個(gè)性化帖子摘要
• 崗位匹配度評(píng)估
• 面試技巧

3）那些東西對(duì)我們有用：

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

3. 評(píng)價(jià)輸出好壞

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

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

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

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

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

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

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

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

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

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

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

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

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

這樣的技能使大語言模型能夠執(zhí)行與我們的產(chǎn)品相關(guān)的各種任務(wù)，如查看個(gè)人資料、搜索文章/人員/職位/公司，甚至查詢內(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是因?yàn)樗啙?，因此消耗的tokens比JSON少。

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

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

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

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

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

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

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

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

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

6. 容量與延遲

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

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

這些因素之間有時(shí)會(huì)產(chǎn)生有趣的相互作用。舉個(gè)例子，我們最初只限制了首個(gè)Token響應(yīng)時(shí)間（TimeToFirstToken, TTFT），因?yàn)檫@對(duì)于我們初期產(chǎn)品延遲有直接影響。然而，隨著我們解決幻覺問題，并且思維鏈（Chain of Thought, CoT）在我們的提示詞中變得突出，如果我們忽略了Token間響應(yīng)時(shí)間（TimeBetweenTokens, TBT）會(huì)對(duì)我們?cè)斐筛蟮膫?，因?yàn)槿魏巍巴评怼眛oken都會(huì)增加產(chǎn)品的延遲（例如，對(duì)于一個(gè)200個(gè)tokens的推理步驟，即使是10毫秒的TBT增加也意味著額外的2秒延遲）。這會(huì)導(dǎo)致我們公共平臺(tái)上的某些任務(wù)突然發(fā)出超時(shí)警告，我們不得不迅速增加算力以緩解這一問題。

還在死磕的事：

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

二、收獲

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

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

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

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

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

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

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