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

一、戰(zhàn)術篇

??過去一年有關大模型應用構建的干貨經驗之戰(zhàn)術篇??

二、運營篇

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

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

數(shù)據(jù)

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

檢查開發(fā)-生產數(shù)據(jù)偏差

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

LLM 開發(fā)-生產數(shù)據(jù)偏差可分為兩類：結構性偏差和內容偏差。結構性偏差包括格式差異等問題，例如具有列表類型值的 JSON 字典與 JSON 列表之間的差異、不一致的大小寫以及錯別字或句子片段等錯誤。這些錯誤可能會導致無法預測的模型性能，因為不同的 LLM 是根據(jù)特定的數(shù)據(jù)格式進行訓練的，而提示可能會對細微變化高度敏感。基于內容或 "語義 "的偏差指的是數(shù)據(jù)含義或上下文的差異。

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

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

每天審查LLM的輸入和輸出樣本

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

來自生產的輸入輸出對是 LLM 應用的 "真實事物、真實地點"，它們是不可替代的。最近的研究強調，開發(fā)人員對什么是 "好"、什么是 "壞 "輸出的看法會隨著他們與更多數(shù)據(jù)的交互而改變（即標準漂移）。雖然開發(fā)人員可以預先制定一些標準來評估 LLM 輸出，但這些預定義的標準往往是不完整的。例如，在開發(fā)過程中，我們可能會更新提示，以增加好回答的概率，降低壞回答的概率。這種評估、重新評估和標準更新的迭代過程是必要的，因為如果不直接觀察輸出結果，就很難預測 LLM 的行為或人類的偏好。

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

使用模型

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

生成結構化輸出，便于下游集成

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

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

目前，"指導者 "和 "大綱 "是從 LLM 獲取結構化輸出的事實標準。如果你正在使用 LLM API（例如 Anthropic、OpenAI），請使用 Instructor；如果你正在使用自托管模型（例如 Hugging Face），請使用 Outlines。

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

有時，我們精心制作的提示信息在一種模型中效果極佳，但在另一種模型中就會大打折扣。當我們在不同的模型提供商之間切換時，以及在同一模型的不同版本之間升級時，就會出現(xiàn)這種情況。

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

因此，如果我們必須在不同型號之間遷移提示信息，預計這將比簡單地交換 API 端點花費更多時間。不要以為插入相同的提示符就能得到相似或更好的結果。此外，擁有可靠的自動驗證有助于衡量遷移前后的任務性能，并減少手動驗證所需的工作量。

版本化和固定模型

在任何機器學習Pipeline中，"改變任何東西都會改變一切"。這一點在我們依賴大型語言模型（LLM）等組件時尤為重要，因為這些組件不是我們自己訓練的，而且可能在我們不知情的情況下發(fā)生變化。

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

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

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

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

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

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

再以簡單的分類任務為例。像 DistilBERT（6700 萬參數(shù)）這樣的輕量級模型是一個令人驚訝的強大基線。400M 參數(shù)的 DistilBART 是另一個不錯的選擇--在開源數(shù)據(jù)上進行微調后，它可以識別幻覺，ROC-AUC 為 0.84，超過了大多數(shù) LLM，而延遲和成本卻不到 5%。

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

產品

雖然新技術提供了新的可能性，但打造優(yōu)秀產品的原則是永恒的。因此，即使我們是第一次解決新問題，我們也不必重新設計產品。將我們的 LLM 應用開發(fā)建立在堅實的產品基礎之上，可以讓我們?yōu)槲覀兯盏娜巳禾峁┱嬲膬r值。

盡早并經常參與設計

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

設計師尤其擅長將用戶需求重構為各種形式。其中一些形式比其他形式更容易解決，因此，它們可能為人工智能解決方案提供更多或更少的機會。與許多其他產品一樣，打造人工智能產品的核心應該是要完成的工作，而不是為其提供動力的技術。

重點是問自己"用戶要求這款產品為他們做什么工作？這項工作是聊天機器人擅長的嗎？自動完成怎么樣？也許會有所不同！"考慮現(xiàn)有的設計模式以及它們與待完成任務的關系。這些都是設計師為團隊能力增添的寶貴財富。

為 "Human-in-the-Loop"設計用戶體驗

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

想象一下，在一個電子商務平臺上，用戶上傳并分類他們的產品。我們可以通過以下幾種方式來設計用戶體驗：

• 用戶手動選擇正確的產品類別；LLM 定期檢查新產品并在后臺糾正分類錯誤。
• 用戶根本不選擇任何類別；LLM 定期在后臺對產品進行分類（可能會出錯）。
• LLM 實時建議產品類別，用戶可根據(jù)需要進行驗證和更新。

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

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

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

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

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

當我們考慮將我們的演示投入生產時，我們必須考慮以下需求：

• 可靠性：99.9% 的正常運行時間，堅持結構化輸出
• 無害性：不生成攻擊性、NSFW 或其他有害內容
• 事實一致性：忠實于所提供的上下文，不胡編亂造
• 有用性：與用戶的需求和要求相關
• 可擴展性：延遲 SLA、支持的吞吐量
• 成本：因為我們沒有無限的預算
• 更多安全、隱私、公平、GDPR、DMA 等。

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

根據(jù)使用案例校準風險容忍度

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

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

團隊與角色

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

注重過程而非工具

面對 LLM 等新模式時，軟件工程師往往傾向于使用工具。結果，我們忽略了工具本應解決的問題和流程。這樣一來，許多工程師就會認為復雜性是偶然的，從而對團隊的長期生產力造成負面影響。

例如，這篇文章（https://hamel.dev/blog/posts/prompt/）討論了某些工具如何為LLM自動創(chuàng)建提示。文章認為，工程師在使用這些工具時，如果沒有首先了解解決問題的方法或流程，最終就會承擔不必要的技術債務。

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

EvalGen 可指導用戶采用最佳實踐方法來編寫LLM評估報告，即

1.定義特定領域的測試（從提示中自動引導）。這些測試既可以定義為帶有代碼的斷言，也可以定義為 LLM-as-a-Judge。

2.使測試與人類判斷對齊的重要性，這樣用戶就能檢查測試是否捕獲了指定的標準。

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

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

不斷實驗

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

嘗試不同的方法來解決同一個問題是很常見的，因為現(xiàn)在的實驗成本很低。收集數(shù)據(jù)和訓練模型的高成本已經降到了最低--提示工程所花費的不過是人的時間。對團隊進行定位，讓每個人都能學到即時工程的基礎知識。這將鼓勵每個人進行實驗，并從整個組織中產生不同的想法。

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

最后，在產品/項目規(guī)劃期間，預留時間用于建立評估和運行多個實驗。想想工程產品的產品規(guī)格，但在其中加入明確的實驗標準。在繪制路線圖時，不要低估實驗所需的時間--預計在獲得生產綠燈之前，需要進行多次迭代開發(fā)和驗證。

讓每個人都有能力使用新的人工智能技術

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

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

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

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

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

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

最初，許多人認為數(shù)據(jù)科學家本身就足以完成數(shù)據(jù)驅動型項目。然而，數(shù)據(jù)科學家顯然必須與軟件和數(shù)據(jù)工程師合作，才能有效地開發(fā)和部署數(shù)據(jù)產品。

隨著AI工程師這一新角色的出現(xiàn)，這種誤解再次顯現(xiàn)，一些團隊認為AI工程師就是你所需要的全部。實際上，構建機器學習或AI產品需要大量的專業(yè)角色。我們曾為十多家公司提供AI產品方面的咨詢，并持續(xù)觀察到他們陷入了 "只需要AI工程師 "的誤區(qū)。結果，由于公司忽視了構建產品所涉及的關鍵環(huán)節(jié)，產品在演示之后往往難以推廣。

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

以下是在構建人工智能產品的整個過程中，您需要的角色類型以及何時需要這些角色的粗略進展：

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

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

接下來，您最終需要優(yōu)化人工智能系統(tǒng)。這不一定需要訓練模型。基本步驟包括設計指標、構建評估系統(tǒng)、運行實驗、優(yōu)化 RAG 檢索、調試隨機系統(tǒng)等。MLE 在這方面非常擅長（雖然AI工程師也能學會）。除非已經完成了前提步驟，否則雇用一名 MLE 通常是沒有意義的。

除此之外，還需要一名領域專家。在小公司，這最好是創(chuàng)始團隊的成員；在大公司，產品經理可以扮演這一角色。了解角色的發(fā)展和時機至關重要。在錯誤的時間聘用人員（如過早聘用一名 MLE）或以錯誤的順序組建團隊都會浪費時間和金錢，并導致人員流失。此外，在第 1-2 階段定期檢查 MLE（但不是全職聘用）將有助于公司建立正確的基礎。

本文轉載自 ??AI工程化??，作者： ully