過(guò)去一年，大模型應(yīng)用以前所未有之勢(shì)從出現(xiàn)到繁榮。LLM應(yīng)用從原型展示向生產(chǎn)落地演進(jìn)。近日，Oreilly刊發(fā)了由 Eugene Yan, Bryan Bischof等人撰寫的大模型總結(jié)性文章《What We Learned from a Year of Building with LLMs？》，由于作者們背景各不相同，有獨(dú)立咨詢顧問(wèn)（Hamel Husain，Jason Liu），有研究人員（Shreya Shankar），還有科技公司AI團(tuán)隊(duì)領(lǐng)袖（Eugene Yan，Bryan Bischof），以及AI領(lǐng)域布道師（Charles Frye），這使得文章內(nèi)容更為全面深入。他們從戰(zhàn)術(shù)、運(yùn)營(yíng)和戰(zhàn)略三個(gè)部分展開(kāi)解讀了自己過(guò)去一年有關(guān)LLM應(yīng)用開(kāi)發(fā)與運(yùn)營(yíng)的全方位經(jīng)驗(yàn)。

一、戰(zhàn)術(shù)篇

??過(guò)去一年有關(guān)大模型應(yīng)用構(gòu)建的干貨經(jīng)驗(yàn)之戰(zhàn)術(shù)篇??

二、運(yùn)營(yíng)篇

在運(yùn)營(yíng) LLM 應(yīng)用時(shí)，會(huì)遇到一些傳統(tǒng)軟件系統(tǒng)中常見(jiàn)的問(wèn)題，但這些問(wèn)題通常都會(huì)以新穎的方式出現(xiàn)，以保持新穎性。LLM 應(yīng)用也提出了全新的問(wèn)題。文章將這些問(wèn)題和答案分為四個(gè)部分：數(shù)據(jù)、模型、產(chǎn)品和人員。

• 對(duì)于數(shù)據(jù)，如何以及多久審查一次 LLM 輸入和輸出？如何衡量和減少測(cè)試-產(chǎn)品偏差？
• 對(duì)于模型，如何將語(yǔ)言模型集成到堆棧的其他部分？如何考慮模型的版本化以及模型和版本之間的遷移？
• 對(duì)于產(chǎn)品，設(shè)計(jì)應(yīng)該何時(shí)參與應(yīng)用程序開(kāi)發(fā)過(guò)程，為什么是 "盡早"？如何設(shè)計(jì)具有豐富人際反饋的用戶體驗(yàn)？如何對(duì)眾多相互沖突的需求進(jìn)行優(yōu)先排序？如何校準(zhǔn)產(chǎn)品風(fēng)險(xiǎn)？
• 對(duì)于人員，要成功構(gòu)建LLM應(yīng)用，應(yīng)該招聘什么樣的人？如何培養(yǎng)正確的實(shí)驗(yàn)文化？如何利用新興的LLM應(yīng)用軟件來(lái)構(gòu)建自己的LLM應(yīng)用軟件？流程和工具哪個(gè)更重要？

數(shù)據(jù)

正如食材的質(zhì)量決定了菜肴的味道一樣，輸入數(shù)據(jù)的質(zhì)量也制約著機(jī)器學(xué)習(xí)系統(tǒng)的性能。此外，輸出數(shù)據(jù)是了解產(chǎn)品是否有效的唯一途徑。所有作者都密切關(guān)注數(shù)據(jù)，每周都要花幾個(gè)小時(shí)查看輸入和輸出，以便更好地了解數(shù)據(jù)分布：其模式、邊角情況以及模型的局限性。

檢查開(kāi)發(fā)-生產(chǎn)數(shù)據(jù)偏差

傳統(tǒng)機(jī)器學(xué)習(xí)Pipeline中常見(jiàn)的錯(cuò)誤源是開(kāi)發(fā)-生產(chǎn)數(shù)據(jù)偏差（train-serve skew）。當(dāng)訓(xùn)練中使用的數(shù)據(jù)與模型在生產(chǎn)中遇到的數(shù)據(jù)不同時(shí)，就會(huì)出現(xiàn)這種情況。雖然可以在不進(jìn)行訓(xùn)練或微調(diào)的情況下使用 LLM，因此沒(méi)有訓(xùn)練集，但開(kāi)發(fā)-生產(chǎn)數(shù)據(jù)偏差也會(huì)產(chǎn)生類似的問(wèn)題。從根本上說(shuō)，在開(kāi)發(fā)過(guò)程中測(cè)試系統(tǒng)的數(shù)據(jù)應(yīng)該反映系統(tǒng)在生產(chǎn)中將面臨的情況。否則，可能會(huì)發(fā)現(xiàn)生產(chǎn)準(zhǔn)確性會(huì)受到影響。

LLM 開(kāi)發(fā)-生產(chǎn)數(shù)據(jù)偏差可分為兩類：結(jié)構(gòu)性偏差和內(nèi)容偏差。結(jié)構(gòu)性偏差包括格式差異等問(wèn)題，例如具有列表類型值的 JSON 字典與 JSON 列表之間的差異、不一致的大小寫以及錯(cuò)別字或句子片段等錯(cuò)誤。這些錯(cuò)誤可能會(huì)導(dǎo)致無(wú)法預(yù)測(cè)的模型性能，因?yàn)椴煌?LLM 是根據(jù)特定的數(shù)據(jù)格式進(jìn)行訓(xùn)練的，而提示可能會(huì)對(duì)細(xì)微變化高度敏感。基于內(nèi)容或 "語(yǔ)義 "的偏差指的是數(shù)據(jù)含義或上下文的差異。

與傳統(tǒng)的 ML 一樣，定期測(cè)量 LLM 輸入/輸出對(duì)之間的偏差也很有用。輸入和輸出的長(zhǎng)度或特定格式要求（如 JSON 或 XML）等簡(jiǎn)單指標(biāo)是跟蹤變化的直接方法。對(duì)于更 "高級(jí) "的漂移（drift）檢測(cè)，可以考慮對(duì)輸入/輸出對(duì)的嵌入進(jìn)行聚類，以檢測(cè)語(yǔ)義漂移，例如用戶討論的話題發(fā)生了變化，這可能表明他們正在探索模型以前未曾接觸過(guò)的領(lǐng)域。

在測(cè)試變化（如提示工程）時(shí)，確保保留數(shù)據(jù)集是最新的，并能反映最新的用戶交互類型。例如，如果錯(cuò)別字在生產(chǎn)輸入中很常見(jiàn)，那么它們也應(yīng)該出現(xiàn)在保留數(shù)據(jù)中。除了數(shù)值偏差測(cè)量，對(duì)輸出進(jìn)行定性評(píng)估也很有益處。定期檢查模型的輸出結(jié)果--俗稱 "振動(dòng)檢查(vibe checks)"--可確保結(jié)果符合預(yù)期，并始終與用戶需求相關(guān)。最后，將非確定性納入偏差檢查也很有用，通過(guò)對(duì)測(cè)試數(shù)據(jù)集中的每個(gè)輸入多次運(yùn)行Pipeline并分析所有輸出，就更有可能捕捉到偶爾出現(xiàn)的異常情況。

每天審查L(zhǎng)LM的輸入和輸出樣本

LLM 是動(dòng)態(tài)的，不斷進(jìn)化的。盡管 LLM 具備令人印象深刻的零誤差能力，而且通常能提供令人滿意的輸出結(jié)果，但其失敗類型卻可能非常難以預(yù)測(cè)。對(duì)于定制任務(wù)而言，定期查看數(shù)據(jù)樣本對(duì)于直觀了解 LLM 的性能至關(guān)重要。

來(lái)自生產(chǎn)的輸入輸出對(duì)是 LLM 應(yīng)用的 "真實(shí)事物、真實(shí)地點(diǎn)"，它們是不可替代的。最近的研究強(qiáng)調(diào)，開(kāi)發(fā)人員對(duì)什么是 "好"、什么是 "壞 "輸出的看法會(huì)隨著他們與更多數(shù)據(jù)的交互而改變（即標(biāo)準(zhǔn)漂移）。雖然開(kāi)發(fā)人員可以預(yù)先制定一些標(biāo)準(zhǔn)來(lái)評(píng)估 LLM 輸出，但這些預(yù)定義的標(biāo)準(zhǔn)往往是不完整的。例如，在開(kāi)發(fā)過(guò)程中，我們可能會(huì)更新提示，以增加好回答的概率，降低壞回答的概率。這種評(píng)估、重新評(píng)估和標(biāo)準(zhǔn)更新的迭代過(guò)程是必要的，因?yàn)槿绻恢苯佑^察輸出結(jié)果，就很難預(yù)測(cè) LLM 的行為或人類的偏好。

為了有效管理，應(yīng)該記錄 LLM 的輸入和輸出。通過(guò)每天檢查這些日志樣本，可以快速識(shí)別并適應(yīng)新的模式或失敗類型。當(dāng)發(fā)現(xiàn)一個(gè)新問(wèn)題時(shí)，可以立即編寫一個(gè)斷言或評(píng)估。同樣，失敗類型定義的任何更新都應(yīng)反映在評(píng)估標(biāo)準(zhǔn)中。這些 "振動(dòng)檢查 "是不良輸出的信號(hào)，利用代碼和斷言日常執(zhí)行這些檢查。最后，必須將這種形式制度化，例如在值班輪換中增加對(duì)輸入和輸出的審查或注釋。

使用模型

有了 LLM API，我們可以依靠少數(shù)幾個(gè)供應(yīng)商提供的智能。雖然這是件好事，但這些依賴性也涉及性能、延遲、吞吐量和成本方面的權(quán)衡。此外，隨著更新、更好的模型的出現(xiàn)（去年幾乎每月都有），應(yīng)該做好準(zhǔn)備，在淘汰舊模型并遷移到更新模型時(shí)更新的產(chǎn)品。在本節(jié)中，將分享在使用我們無(wú)法完全控制的技術(shù)時(shí)的經(jīng)驗(yàn)教訓(xùn)，在這些技術(shù)中，模型無(wú)法自托管和管理。

生成結(jié)構(gòu)化輸出，便于下游集成

對(duì)于大多數(shù)實(shí)際用例而言，LLM 的輸出將由下游應(yīng)用通過(guò)某種機(jī)器可讀格式來(lái)使用。例如，房地產(chǎn) CRM Rechat 需要結(jié)構(gòu)化的響應(yīng)，以便前端渲染小部件。同樣，用于生成產(chǎn)品戰(zhàn)略創(chuàng)意的工具 Boba 也需要結(jié)構(gòu)化的輸出，其中包括標(biāo)題、摘要、可信度評(píng)分和時(shí)間范圍等字段。最后，LinkedIn 分享了如何限制 LLM 生成 YAML，然后用 YAML 決定使用哪種技能，并提供調(diào)用技能的參數(shù)。

這種應(yīng)用模式是波斯特爾定律（Postel’s law）的極端版本：接受的內(nèi)容（任意自然語(yǔ)言）要自由，發(fā)送的內(nèi)容（鍵入的機(jī)器可讀對(duì)象）要保守。因此，我們希望它非常耐用。

目前，"指導(dǎo)者 "和 "大綱 "是從 LLM 獲取結(jié)構(gòu)化輸出的事實(shí)標(biāo)準(zhǔn)。如果你正在使用 LLM API（例如 Anthropic、OpenAI），請(qǐng)使用 Instructor；如果你正在使用自托管模型（例如 Hugging Face），請(qǐng)使用 Outlines。

在不同模型間遷移提示是件麻煩事

有時(shí)，我們精心制作的提示信息在一種模型中效果極佳，但在另一種模型中就會(huì)大打折扣。當(dāng)我們?cè)诓煌哪Ｐ吞峁┥讨g切換時(shí)，以及在同一模型的不同版本之間升級(jí)時(shí)，就會(huì)出現(xiàn)這種情況。

例如，Voiceflow 發(fā)現(xiàn)，從 gpt-3.5-turbo-0301 遷移到 gpt-3.5-turbo-1106 后，他們的意圖分類任務(wù)性能下降了 10%。(幸好他們有評(píng)估！）同樣，GoDaddy 也觀察到了積極的趨勢(shì)，升級(jí)到 1106 版縮小了 gpt-3.5-turbo 和 gpt-4 之間的性能差距。

因此，如果我們必須在不同型號(hào)之間遷移提示信息，預(yù)計(jì)這將比簡(jiǎn)單地交換 API 端點(diǎn)花費(fèi)更多時(shí)間。不要以為插入相同的提示符就能得到相似或更好的結(jié)果。此外，擁有可靠的自動(dòng)驗(yàn)證有助于衡量遷移前后的任務(wù)性能，并減少手動(dòng)驗(yàn)證所需的工作量。

版本化和固定模型

在任何機(jī)器學(xué)習(xí)Pipeline中，"改變?nèi)魏螙|西都會(huì)改變一切"。這一點(diǎn)在我們依賴大型語(yǔ)言模型（LLM）等組件時(shí)尤為重要，因?yàn)檫@些組件不是我們自己訓(xùn)練的，而且可能在我們不知情的情況下發(fā)生變化。

幸運(yùn)的是，許多模型提供商提供了 "固定 "特定模型版本的選項(xiàng)（例如，gpt-4-turbo-1106）。這樣我們就能使用特定版本的模型權(quán)重，確保它們保持不變。在生產(chǎn)中固定模型版本有助于避免模型行為發(fā)生意想不到的變化，這可能會(huì)導(dǎo)致客戶抱怨在交換模型時(shí)可能出現(xiàn)的問(wèn)題，例如過(guò)于冗長(zhǎng)的輸出或其他不可預(yù)見(jiàn)的失敗情況。

此外，還可以考慮維護(hù)一個(gè)影子Pipeline，以反映生產(chǎn)設(shè)置，但使用最新的模型版本。這樣就能安全地使用新版本進(jìn)行實(shí)驗(yàn)和測(cè)試。一旦您驗(yàn)證了這些較新模型輸出的穩(wěn)定性和質(zhì)量，您就可以放心地更新生產(chǎn)環(huán)境中的模型版本。

選擇能完成工作的最小版本的模型

在開(kāi)發(fā)新的應(yīng)用時(shí)，使用最大、最強(qiáng)大的模型很有誘惑力。但是，一旦我們確定任務(wù)在技術(shù)上是可行的，就值得嘗試一下較小的模型是否也能達(dá)到類似的效果。

較小模型的好處是延遲更短，成本更低。雖然它的性能可能較弱，但COT、N-shot和上下文學(xué)習(xí)等技術(shù)可以幫助較小的模型發(fā)揮更大的作用。除了 LLM API 之外，微調(diào)我們的特定任務(wù)也有助于提高性能。

綜合來(lái)看，使用較小模型精心設(shè)計(jì)的工作流程往往可以達(dá)到甚至超過(guò)單一大型模型的輸出質(zhì)量，同時(shí)速度更快、成本更低。例如，這篇文章分享了 Haiku + 10-shot prompt 如何優(yōu)于 0-shot Opus 和 GPT-4 故事（??https://twitter.com/mattshumer_/status/1770823530394833242??）。從長(zhǎng)遠(yuǎn)來(lái)看，我們希望看到更多使用較小模型進(jìn)行流程設(shè)計(jì)的例子，以實(shí)現(xiàn)輸出質(zhì)量、延遲和成本之間的最佳平衡。

再以簡(jiǎn)單的分類任務(wù)為例。像 DistilBERT（6700 萬(wàn)參數(shù)）這樣的輕量級(jí)模型是一個(gè)令人驚訝的強(qiáng)大基線。400M 參數(shù)的 DistilBART 是另一個(gè)不錯(cuò)的選擇--在開(kāi)源數(shù)據(jù)上進(jìn)行微調(diào)后，它可以識(shí)別幻覺(jué)，ROC-AUC 為 0.84，超過(guò)了大多數(shù) LLM，而延遲和成本卻不到 5%。

重點(diǎn)是，不要忽視較小的模型。雖然我們很容易在每一個(gè)問(wèn)題上都拋出一個(gè)龐大的模型，但通過(guò)一些創(chuàng)造性的嘗試，我們往往可以找到更有效的解決方案。

產(chǎn)品

雖然新技術(shù)提供了新的可能性，但打造優(yōu)秀產(chǎn)品的原則是永恒的。因此，即使我們是第一次解決新問(wèn)題，我們也不必重新設(shè)計(jì)產(chǎn)品。將我們的 LLM 應(yīng)用開(kāi)發(fā)建立在堅(jiān)實(shí)的產(chǎn)品基礎(chǔ)之上，可以讓我們?yōu)槲覀兯?wù)的人群提供真正的價(jià)值。

盡早并經(jīng)常參與設(shè)計(jì)

有了設(shè)計(jì)師的參與，就能促使你深入理解和思考如何構(gòu)建產(chǎn)品并將其呈現(xiàn)給用戶。我們有時(shí)會(huì)將設(shè)計(jì)師刻板地認(rèn)為他們只會(huì)把東西做得漂亮。但除了用戶界面之外，他們還會(huì)重新思考如何改善用戶體驗(yàn)，即使這意味著要打破現(xiàn)有的規(guī)則和模式。

設(shè)計(jì)師尤其擅長(zhǎng)將用戶需求重構(gòu)為各種形式。其中一些形式比其他形式更容易解決，因此，它們可能為人工智能解決方案提供更多或更少的機(jī)會(huì)。與許多其他產(chǎn)品一樣，打造人工智能產(chǎn)品的核心應(yīng)該是要完成的工作，而不是為其提供動(dòng)力的技術(shù)。

重點(diǎn)是問(wèn)自己"用戶要求這款產(chǎn)品為他們做什么工作？這項(xiàng)工作是聊天機(jī)器人擅長(zhǎng)的嗎？自動(dòng)完成怎么樣？也許會(huì)有所不同！"考慮現(xiàn)有的設(shè)計(jì)模式以及它們與待完成任務(wù)的關(guān)系。這些都是設(shè)計(jì)師為團(tuán)隊(duì)能力增添的寶貴財(cái)富。

為 "Human-in-the-Loop"設(shè)計(jì)用戶體驗(yàn)

獲得高質(zhì)量注釋的方法之一是將 "Human-in-the-Loop"（HITL）集成到用戶體驗(yàn)（UX）中。通過(guò)允許用戶輕松提供反饋和更正，我們可以改進(jìn)即時(shí)輸出，并收集寶貴的數(shù)據(jù)來(lái)改進(jìn)我們的模型。

想象一下，在一個(gè)電子商務(wù)平臺(tái)上，用戶上傳并分類他們的產(chǎn)品。我們可以通過(guò)以下幾種方式來(lái)設(shè)計(jì)用戶體驗(yàn)：

• 用戶手動(dòng)選擇正確的產(chǎn)品類別；LLM 定期檢查新產(chǎn)品并在后臺(tái)糾正分類錯(cuò)誤。
• 用戶根本不選擇任何類別；LLM 定期在后臺(tái)對(duì)產(chǎn)品進(jìn)行分類（可能會(huì)出錯(cuò)）。
• LLM 實(shí)時(shí)建議產(chǎn)品類別，用戶可根據(jù)需要進(jìn)行驗(yàn)證和更新。

雖然這三種方法都涉及到 LLM，但它們提供的用戶體驗(yàn)卻截然不同。第一種方法讓用戶承擔(dān)前期成本，而 LLM 則充當(dāng)后處理檢查。第二種方法不需要用戶做出任何努力，但不提供任何透明度或控制。第三種方法取得了適當(dāng)?shù)钠胶狻Ｍㄟ^(guò)讓 LLM 提前提出分類建議，我們減輕了用戶的認(rèn)知負(fù)擔(dān)，他們無(wú)需學(xué)習(xí)我們的分類法來(lái)對(duì)產(chǎn)品進(jìn)行分類！同時(shí)，通過(guò)允許用戶審查和編輯建議，他們對(duì)產(chǎn)品如何分類擁有最終決定權(quán)，從而將控制權(quán)牢牢掌握在自己手中。另外，第三種方法還為模型改進(jìn)創(chuàng)造了一個(gè)自然的反饋回路。好的建議會(huì)被接受（正面標(biāo)簽），不好的建議會(huì)被更新（負(fù)面標(biāo)簽后是正面標(biāo)簽）。

這種建議、用戶驗(yàn)證和數(shù)據(jù)收集的模式在多個(gè)應(yīng)用中都很常見(jiàn)：

• 編碼助手：用戶可以接受建議（強(qiáng)正反饋）、接受并調(diào)整建議（正反饋）或忽略建議（負(fù)反饋）。
• Midjourney：用戶可以選擇放大并下載圖片（強(qiáng)正反饋）、更改圖片（正反饋）或生成一組新圖片（否定）
• 聊天機(jī)器人：用戶可以對(duì)回復(fù)豎起大拇指（強(qiáng)正反饋）或摁下大拇指（負(fù)反饋），或者在回復(fù)非常糟糕的情況下選擇重新生成回復(fù)（強(qiáng)負(fù)反饋）

反饋可以是顯性的，也可以是隱性的。顯性反饋是用戶應(yīng)我們產(chǎn)品的要求而提供的信息；隱性反饋是我們從用戶交互中了解到的信息，無(wú)需用戶刻意提供反饋。編碼助手和 Midjourney 就是隱式反饋的例子，而豎起大拇指和放下大拇指則是顯式反饋。如果我們能像編碼助手和 Midjourney 一樣設(shè)計(jì)好用戶體驗(yàn)，我們就能收集到大量的隱式反饋，從而改進(jìn)我們的產(chǎn)品和模型。

客觀地確定需求層次的優(yōu)先級(jí)

當(dāng)我們考慮將我們的演示投入生產(chǎn)時(shí)，我們必須考慮以下需求：

• 可靠性：99.9% 的正常運(yùn)行時(shí)間，堅(jiān)持結(jié)構(gòu)化輸出
• 無(wú)害性：不生成攻擊性、NSFW 或其他有害內(nèi)容
• 事實(shí)一致性：忠實(shí)于所提供的上下文，不胡編亂造
• 有用性：與用戶的需求和要求相關(guān)
• 可擴(kuò)展性：延遲 SLA、支持的吞吐量
• 成本：因?yàn)槲覀儧](méi)有無(wú)限的預(yù)算
• 更多安全、隱私、公平、GDPR、DMA 等。

如果試圖一次解決所有這些需求，將永遠(yuǎn)無(wú)法交付任何東西。因此，需要分清輕重緩急。這意味著要明確哪些要求是必須滿足的（如可靠性、無(wú)害性），否則產(chǎn)品將無(wú)法運(yùn)行或無(wú)法生存。這就是要確定最小產(chǎn)品。我們必須接受第一個(gè)版本并不完美的事實(shí)，并不斷推出和迭代。

根據(jù)使用案例校準(zhǔn)風(fēng)險(xiǎn)容忍度

在決定應(yīng)用程序的語(yǔ)言模型和審查級(jí)別時(shí)，要考慮使用案例和受眾。對(duì)于面向客戶提供醫(yī)療或金融建議的聊天機(jī)器人，我們需要對(duì)安全性和準(zhǔn)確性有很高的要求。錯(cuò)誤或糟糕的輸出可能會(huì)造成真正的傷害并削弱信任。但對(duì)于不那么重要的應(yīng)用，如推薦系統(tǒng)，或面向內(nèi)部的應(yīng)用，如內(nèi)容分類或摘要，過(guò)于嚴(yán)格的要求只會(huì)減慢進(jìn)度，而不會(huì)增加多少價(jià)值。

這與 a16z 最近的一份報(bào)告（???A16Z:2024年企業(yè)落地生成式AI技術(shù)的16個(gè)變化??）不謀而合，該報(bào)告顯示，與外部應(yīng)用相比，許多公司的內(nèi)部應(yīng)用進(jìn)展更快。通過(guò)嘗試使用人工智能提高內(nèi)部生產(chǎn)力，企業(yè)可以開(kāi)始獲取價(jià)值，同時(shí)學(xué)習(xí)如何在更可控的環(huán)境中管理風(fēng)險(xiǎn)。然后，隨著信心的增強(qiáng)，他們可以擴(kuò)展到面向客戶的使用案例。

團(tuán)隊(duì)與角色

任何工作職能都不容易定義，但為這個(gè)新空間的工作撰寫職位描述卻比其他工作更具挑戰(zhàn)性。我們將放棄繪制交叉職稱的維恩圖，也不對(duì)職位描述提出建議。不過(guò)，我們將承認(rèn)一個(gè)新角色--AI工程師--的存在，并討論它的位置。重要的是，我們將討論團(tuán)隊(duì)的其他成員以及如何分配職責(zé)。

注重過(guò)程而非工具

面對(duì) LLM 等新模式時(shí)，軟件工程師往往傾向于使用工具。結(jié)果，我們忽略了工具本應(yīng)解決的問(wèn)題和流程。這樣一來(lái)，許多工程師就會(huì)認(rèn)為復(fù)雜性是偶然的，從而對(duì)團(tuán)隊(duì)的長(zhǎng)期生產(chǎn)力造成負(fù)面影響。

例如，這篇文章（https://hamel.dev/blog/posts/prompt/）討論了某些工具如何為L(zhǎng)LM自動(dòng)創(chuàng)建提示。文章認(rèn)為，工程師在使用這些工具時(shí)，如果沒(méi)有首先了解解決問(wèn)題的方法或流程，最終就會(huì)承擔(dān)不必要的技術(shù)債務(wù)。

除了意外的復(fù)雜性之外，工具往往不夠規(guī)范。例如，現(xiàn)在有一種不斷發(fā)展的LLM評(píng)估工具，提供 "LLM Evaluation in a Box"，帶有毒性、簡(jiǎn)潔性、語(yǔ)氣等通用評(píng)估工具。我們看到許多團(tuán)隊(duì)在采用這些工具時(shí)，并沒(méi)有認(rèn)真思考其領(lǐng)域的具體失敗情況。而 EvalGen 則不同，它側(cè)重于向用戶傳授創(chuàng)建特定領(lǐng)域評(píng)估的過(guò)程，讓用戶深入?yún)⑴c從指定標(biāo)準(zhǔn)、標(biāo)注數(shù)據(jù)到檢查評(píng)估的每一個(gè)步驟。該軟件引導(dǎo)用戶完成如下工作流程：

EvalGen 可指導(dǎo)用戶采用最佳實(shí)踐方法來(lái)編寫LLM評(píng)估報(bào)告，即

1.定義特定領(lǐng)域的測(cè)試（從提示中自動(dòng)引導(dǎo)）。這些測(cè)試既可以定義為帶有代碼的斷言，也可以定義為 LLM-as-a-Judge。

2.使測(cè)試與人類判斷對(duì)齊的重要性，這樣用戶就能檢查測(cè)試是否捕獲了指定的標(biāo)準(zhǔn)。

3.隨著系統(tǒng)（提示等）的變化而迭代測(cè)試。

EvalGen 為開(kāi)發(fā)人員提供了評(píng)估構(gòu)建過(guò)程的心智模型，而不會(huì)將他們固定在特定的工具上。我們發(fā)現(xiàn)，在為AI工程師提供了這一背景后，他們往往會(huì)決定選擇更精簡(jiǎn)的工具或構(gòu)建自己的工具。

不斷實(shí)驗(yàn)

ML 產(chǎn)品與實(shí)驗(yàn)密切相關(guān)。不僅是 A/B、隨機(jī)對(duì)照試驗(yàn)，還包括經(jīng)常嘗試修改系統(tǒng)中盡可能小的組件并進(jìn)行離線評(píng)估。每個(gè)人都如此熱衷于評(píng)估的原因其實(shí)并不在于可信度和信心，而是為了實(shí)現(xiàn)實(shí)驗(yàn)！評(píng)估做得越好，你就能越快地迭代實(shí)驗(yàn)，從而越快地收斂到系統(tǒng)的最佳版本。

嘗試不同的方法來(lái)解決同一個(gè)問(wèn)題是很常見(jiàn)的，因?yàn)楝F(xiàn)在的實(shí)驗(yàn)成本很低。收集數(shù)據(jù)和訓(xùn)練模型的高成本已經(jīng)降到了最低--提示工程所花費(fèi)的不過(guò)是人的時(shí)間。對(duì)團(tuán)隊(duì)進(jìn)行定位，讓每個(gè)人都能學(xué)到即時(shí)工程的基礎(chǔ)知識(shí)。這將鼓勵(lì)每個(gè)人進(jìn)行實(shí)驗(yàn)，并從整個(gè)組織中產(chǎn)生不同的想法。

此外，不要只為探索而實(shí)驗(yàn)，也要利用它們進(jìn)行開(kāi)發(fā)！有新任務(wù)的工作版本嗎？考慮讓團(tuán)隊(duì)中的其他人采用不同的方法。嘗試另一種更快的方法。研究思維鏈或few-shot等提示技術(shù)，以提高質(zhì)量。不要讓你的工具阻礙了你的實(shí)驗(yàn)；如果是這樣，重建它，或者買一些東西讓它變得更好。

最后，在產(chǎn)品/項(xiàng)目規(guī)劃期間，預(yù)留時(shí)間用于建立評(píng)估和運(yùn)行多個(gè)實(shí)驗(yàn)。想想工程產(chǎn)品的產(chǎn)品規(guī)格，但在其中加入明確的實(shí)驗(yàn)標(biāo)準(zhǔn)。在繪制路線圖時(shí)，不要低估實(shí)驗(yàn)所需的時(shí)間--預(yù)計(jì)在獲得生產(chǎn)綠燈之前，需要進(jìn)行多次迭代開(kāi)發(fā)和驗(yàn)證。

讓每個(gè)人都有能力使用新的人工智能技術(shù)

隨著生成式人工智能的應(yīng)用越來(lái)越廣泛，我們希望整個(gè)團(tuán)隊(duì)，而不僅僅是專家，都能了解并有能力使用這項(xiàng)新技術(shù)。沒(méi)有比使用 LLM 更好的方法來(lái)培養(yǎng)對(duì) LLM 工作原理（如延遲、故障模式、用戶體驗(yàn)）的直覺(jué)了。LLM 相對(duì)來(lái)說(shuō)比較容易使用：您不需要知道如何編寫代碼就能提高管道的性能，而且每個(gè)人都可以通過(guò)及時(shí)工程和評(píng)估開(kāi)始貢獻(xiàn)自己的力量。

其中很重要的一部分就是教育。教育可以從簡(jiǎn)單的提示工程基礎(chǔ)知識(shí)開(kāi)始，N-shot 提示和 CoT 等技術(shù)有助于調(diào)節(jié)模型以實(shí)現(xiàn)理想的輸出。具備相關(guān)知識(shí)的人還可以從技術(shù)層面進(jìn)行教育，例如 LLM 在本質(zhì)上是如何自回歸的。換句話說(shuō)，輸入token是并行處理的，而輸出token則是順序生成的。因此，延遲與其說(shuō)是輸入長(zhǎng)度的函數(shù)，不如說(shuō)是輸出長(zhǎng)度的函數(shù)，這也是設(shè)計(jì)用戶體驗(yàn)和設(shè)定性能預(yù)期時(shí)需要考慮的關(guān)鍵因素。

還可以更進(jìn)一步，提供動(dòng)手實(shí)驗(yàn)和探索的機(jī)會(huì)。比如黑客馬拉松？雖然讓整個(gè)團(tuán)隊(duì)花幾天時(shí)間進(jìn)行投機(jī)性項(xiàng)目的工作似乎很昂貴，但結(jié)果可能會(huì)讓你大吃一驚。據(jù)我們所知，有一個(gè)團(tuán)隊(duì)通過(guò)黑客馬拉松加快了進(jìn)度，幾乎在一年內(nèi)完成了他們的三年路線圖。另一個(gè)團(tuán)隊(duì)則通過(guò)黑客馬拉松實(shí)現(xiàn)了用戶體驗(yàn)的范式轉(zhuǎn)換，而這一切都要?dú)w功于 LLMs，它們現(xiàn)在已被列為今年及以后的優(yōu)先事項(xiàng)。

不要陷入 "AI engineering is all I need"的陷阱

隨著新職位出現(xiàn)，人們最初往往會(huì)夸大這些職位的相關(guān)能力。當(dāng)這些工作的實(shí)際范圍變得清晰時(shí)，這往往會(huì)導(dǎo)致痛苦的修正。該領(lǐng)域的新人和招聘經(jīng)理可能會(huì)夸大其詞或抱有過(guò)高的期望。過(guò)去十年中的著名例子包括：

• 數(shù)據(jù)科學(xué)家："在統(tǒng)計(jì)方面比任何軟件工程師都強(qiáng)，在軟件工程方面比任何統(tǒng)計(jì)學(xué)家都強(qiáng)"。
• 機(jī)器學(xué)習(xí)工程師（MLE）：以軟件工程為中心的機(jī)器學(xué)習(xí)觀點(diǎn)

最初，許多人認(rèn)為數(shù)據(jù)科學(xué)家本身就足以完成數(shù)據(jù)驅(qū)動(dòng)型項(xiàng)目。然而，數(shù)據(jù)科學(xué)家顯然必須與軟件和數(shù)據(jù)工程師合作，才能有效地開(kāi)發(fā)和部署數(shù)據(jù)產(chǎn)品。

隨著AI工程師這一新角色的出現(xiàn)，這種誤解再次顯現(xiàn)，一些團(tuán)隊(duì)認(rèn)為AI工程師就是你所需要的全部。實(shí)際上，構(gòu)建機(jī)器學(xué)習(xí)或AI產(chǎn)品需要大量的專業(yè)角色。我們?cè)鵀槭嗉夜咎峁〢I產(chǎn)品方面的咨詢，并持續(xù)觀察到他們陷入了 "只需要AI工程師 "的誤區(qū)。結(jié)果，由于公司忽視了構(gòu)建產(chǎn)品所涉及的關(guān)鍵環(huán)節(jié)，產(chǎn)品在演示之后往往難以推廣。

例如，評(píng)估和測(cè)量對(duì)于擴(kuò)大產(chǎn)品規(guī)模，使其超越振動(dòng)檢查至關(guān)重要。有效評(píng)估的技能與機(jī)器學(xué)習(xí)工程師的一些傳統(tǒng)優(yōu)勢(shì)相吻合，而僅由人工智能工程師組成的團(tuán)隊(duì)很可能缺乏這些技能。合著者哈梅爾-侯賽因（Hamel Husain）在他最近圍繞檢測(cè)數(shù)據(jù)漂移和設(shè)計(jì)特定領(lǐng)域評(píng)估的工作中說(shuō)明了這些技能的重要性。

以下是在構(gòu)建人工智能產(chǎn)品的整個(gè)過(guò)程中，您需要的角色類型以及何時(shí)需要這些角色的粗略進(jìn)展：

首先，專注于打造產(chǎn)品。這可能包括一名AI工程師，但不一定非得如此。AI工程師在產(chǎn)品原型設(shè)計(jì)和快速迭代（用戶體驗(yàn)、Pipeline等）方面很有價(jià)值。

接下來(lái)，通過(guò)檢測(cè)系統(tǒng)和收集數(shù)據(jù)來(lái)創(chuàng)建正確的基礎(chǔ)。根據(jù)數(shù)據(jù)的類型和規(guī)模，您可能需要平臺(tái)和/或數(shù)據(jù)工程師。您還必須擁有查詢和分析這些數(shù)據(jù)的系統(tǒng)，以調(diào)試問(wèn)題。

接下來(lái)，您最終需要優(yōu)化人工智能系統(tǒng)。這不一定需要訓(xùn)練模型。基本步驟包括設(shè)計(jì)指標(biāo)、構(gòu)建評(píng)估系統(tǒng)、運(yùn)行實(shí)驗(yàn)、優(yōu)化 RAG 檢索、調(diào)試隨機(jī)系統(tǒng)等。MLE 在這方面非常擅長(zhǎng)（雖然AI工程師也能學(xué)會(huì)）。除非已經(jīng)完成了前提步驟，否則雇用一名 MLE 通常是沒(méi)有意義的。

除此之外，還需要一名領(lǐng)域?qū)＜摇Ｔ谛」荆@最好是創(chuàng)始團(tuán)隊(duì)的成員；在大公司，產(chǎn)品經(jīng)理可以扮演這一角色。了解角色的發(fā)展和時(shí)機(jī)至關(guān)重要。在錯(cuò)誤的時(shí)間聘用人員（如過(guò)早聘用一名 MLE）或以錯(cuò)誤的順序組建團(tuán)隊(duì)都會(huì)浪費(fèi)時(shí)間和金錢，并導(dǎo)致人員流失。此外，在第 1-2 階段定期檢查 MLE（但不是全職聘用）將有助于公司建立正確的基礎(chǔ)。

本文轉(zhuǎn)載自 ??AI工程化??，作者： ully