我從 2024 年的 LLM 應用開發實踐中學到了什么？Part 1 原創
編者按： "為什么明明選擇了最先進的大語言模型，構建的 AI 產品卻總是無法達到預期效果？" —— 這大概是今年眾多技術團隊都在苦惱的問題。從選擇合適的商業場景，到組建專業團隊，再到技術架構設計，每一步都充滿挑戰。一個錯誤的決策，可能導致數月的努力付諸東流，更遑論昂貴的模型調用成本。
本文作者憑借近十年的 Web 應用和云原生開發經驗，以及 2024 年深度參與 LLM 應用開發的第一手經歷，為我們揭示了一個重要發現：成功的 LLM 應用開發需要拋棄傳統的產品開發思維，轉而采用"持續研究-實驗-評估"的創新模式。
作者 | Satwiki De
編譯 | 岳揚
大語言模型（LLMs）有望改變我們對待人工智能的方式，這一點在將 LLMs 與 Web 應用融合的創新設計中已初露端倪。自 2022 年末起，眾多框架、軟件開發工具包（SDK）和工具紛紛亮相，展示了如何將 LLMs 與 Web 應用或商業工具相結合，形成初步原型。隨著越來越多的資金投入到基于生成式 AI 的商業應用和工具的開發中，將這些原型推向生產階段并實現商業價值變得尤為重要。如果你打算投入時間和資金打造一個 LLM 原生工具，你該如何確保這一投資能夠帶來長期回報？
為此，制定一套開發 LLM 應用的最佳實踐是關鍵所在。在過去一年里，我投身于 LLM 應用的開發，這段經歷不僅令人振奮，而且收獲頗豐。基于我在設計和構建 Web 應用及云原生應用方面近十年的經驗，我認識到，傳統的產品開發模式往往不適用于 LLM 原生應用。相反，持續的研究、實驗和評估循環被證明對打造卓越的 AI 驅動產品更為有效。
為了幫助各位讀者應對 LLM 應用開發的道路上的各種挑戰，我將分享以下幾個關鍵領域的最佳實踐：商業場景挑選、團隊理念、開發策略、responsible AI 實踐以及成本控制。
01 構思階段：挑選合適的商業應用場景
是否每個問題都需要依賴 AI 來解決？答案顯然是否定的。倒不如問問自己，哪些商業場景能夠通過運用 LLMs 獲益最多？企業在開發應用之前，需要先回答這些問題。有時候，合適的商業場景就在我們眼前；有時候，通過與同事交流或在公司內部進行研究，可能會找到正確的方向。以下幾個方面可能有助于我們做出決定。
- 提出的解決方案是否滿足市場需求？針對擬定的商業場景進行市場調研，把握當前的市場形勢。找出是否存在集成了 AI 或不集成 AI 的現有解決方案，分析它們的優缺點，以及目前您提議的 LLM 應用方案能否彌補現有缺陷。這一步包括對競爭對手、行業動態和客戶反饋的分析。
- 它能幫助用戶嗎？如果您的解決方案旨在為公司內部用戶服務，衡量用戶期望的一個簡單方法是看該解決方案是否能夠通過節省時間來提升工作效率。例如，提供一個 IT 或 HR 支持的聊天機器人，幫助員工解答關于公司的日常問題。此外，通過對潛在用戶進行快速調查，也能幫助您了解 AI 可以解決哪些痛點。
- 它能否提升業務流程效率？有些應用場景可能專注于優化業務流程，從而間接惠及用戶。例如，對呼叫中心記錄進行情感分析、進行個性化推薦、總結法律和財務文件等。對于這類應用場景，自動化技術的應用是將 LLM 融入日常業務流程的關鍵。
- 我們是否擁有必要的數據？基于 LLM 的應用通常采用 RAG（檢索增強生成）技術，從特定知識庫中生成與上下文相關且基于事實的答案。基于 RAG 的解決方案的基礎在于數據的可用性、類型和質量。如果缺乏充足的知識庫或高質量數據，這種解決方案的效果可能就不盡如人意。數據的可獲取性同樣重要，因為并非所有機密或敏感數據都能輕易獲取。
- 提出的解決方案是否切實可行？決定是否采用 AI 解決方案，不僅需要考慮技術層面的可行性，還需評估倫理、法律和財務等因素。若涉及敏感數據，還需在確定商業應用場景前考慮隱私保護和合規性問題。
- 解決方案是否滿足您的業務需求？思考 AI 解決方案如何助力您的短期和長期業務目標。同時，合理管理期望值也很關鍵，過于追求短期目標可能不利于價值的實現。通常，AI 應用的投資回報是一個長期過程。
正確設定預期目標
在挑選應用場景的同時，產品負責人還需考慮為團隊設定恰當的預期目標和短期、可實現的小步驟。每個小步驟都應具備明確的目標和預定時間表，且需得到團隊的認同，這樣利益相關者才能定期檢查項目進展。這對于決定如何推進基于 LLM 的解決方案、實施生產化策略、引入用戶等方面做出明智的選擇至關重要。
02 實驗階段：培養正確的思維方式
在人工智能領域，研究和實驗是不可或缺的。開發 LLM 應用程序同樣如此。與遵循固定設計的傳統 Web 應用不同，基于 AI 的設計更依賴于實驗，并根據早期結果靈活調整。成功的關鍵在于對明確的目標進行反復試驗，并持續對每次試驗進行評估。在 LLM 原生開發中，衡量成功的標準通常是輸出的質量，這意味著我們需要專注于生成精確且相關性高的結果，無論是聊天機器人的回答、文本摘要、圖像生成，還是 LLM 定義的操作（Agentic 方法）。要穩定輸出高質量的結果，需要對語言模型有深刻理解，不斷優化提示詞，并進行嚴格評估，以確保應用達到預期標準。
團隊應具備哪些技術能力？
或許您可能會認為，只需幾位數據科學家就能構建 LLM 應用程序。但實際上，工程技能同樣重要，甚至更為關鍵，因為 LLM 應用并不完全遵循傳統的機器學習路徑。數據科學家和軟件工程師都需要調整心態，以適應這種開發方式。我見證過這樣的轉變：數據科學家開始熟悉云基礎設施和應用部署，而工程師則開始掌握模型使用和評估 LLM 輸出的細節。最終，團隊需要的 AI 實踐者不僅僅是能夠編碼，更重要的是他們能夠進行研究、協作，并不斷提升 AI 的應用潛力。
既然將采用預訓練的語言模型，我們真的還需要進行“實驗”嗎？
像 GPT-4o 這樣的流行大語言模型（LLMs）已經在大數據集上完成了訓練，能夠識別和生成文本、圖像等，因此無需我們再進行“訓練”。在極少數情況下，可能需要對模型進行微調，但這也可以輕松完成，無需傳統的機器學習（ML）方法。不過，我們要區分“實驗”與 predictive ML 中的“模型訓練”概念。如本文先前所述，應用程序的輸出質量至關重要。通過設置多次迭代實驗，我們可以逐步提升結果的質量。例如，如果你正在開發一個聊天機器人，并希望控制其輸出給最終用戶的效果，那么采用迭代和實驗性的方法來優化提示詞和調整超參數，將有助于我們找到生成最精確和最一致輸出的最佳途徑。
盡早構建原型
在項目初期，應盡可能快地構建一個僅包含必要核心功能的原型（即 MVP —— 最小可行產品），最佳時間是在 2 至 4 周內完成。若采用基于知識庫的 RAG 方法，請使用數據子集，以減少繁瑣的數據預處理工作。
通過目標用戶小范圍的快速反饋，我們可以了解解決方案是否達到了用戶的預期。
與項目利益相關者進行評審，不僅要展示正面的成果，還要討論在原型構建過程中團隊遇到的局限性和制約因素。這樣做對于早期風險防范和做出明智的交付決策至關重要。
團隊應據此確定技術選型、安全性和可擴展性需求，以便將原型進一步完善為功能齊全的產品，并規劃出合理的交付時間表。
判斷原型是否已準備好轉化為“產品”
眾多 AI 相關的樣本讓原型的構建變得非常容易，而且這些原型的初期測試往往成效顯著。當原型開發完成時，團隊可能已經對成功標準、市場調研、目標用戶群體、平臺需求等有了更深入的認識。此時，思考以下問題有助于明確產品的發展路徑：
- 原型中的功能是否真正解決了終端用戶或業務流程的核心需求？
- 在原型開發過程中遇到的問題，哪些可能會在生產階段重現？有哪些策略可以提前規避這些風險？
- 原型在遵循 responsible AI 原則（譯者注：“responsible AI” 要求技術開發者、用戶、政策制定者和其他利益相關者共同努力，確保 AI 技術的發展和應用能夠造福人類社會。）方面是否存在潛在風險？如果有，應采取哪些預防措施？（我們將在第二部分深入討論這一點）
- 若要將解決方案融入現有產品，可能會遇到哪些障礙？
- 如果該解決方案要處理敏感數據，是否采取了有效措施來保護數據隱私和安全？
- 是否需要為產品設定性能標準？原型的表現是否符合預期，或者還有提升空間？
- 產品需要滿足哪些安全標準？
- 產品是否需要用戶界面？（基于 LLM 的聊天機器人等應用，需盡早明確 UI 需求）
- 對于 MVP 階段的 LLM 使用，是否有成本預算？結合預期的生產使用規模和預算，這個預算是否合理？
在初步審查后，若您對大多數問題都有了滿意的答復，并且原型測試表現優異，那么就可以著手推進產品開發了。
敬請期待第二部分，屆時我將探討產品開發應采取的策略、如何在產品初期嵌入 responsible AI 實踐，以及成本管理的技巧。
Thanks for reading!
Hope you have enjoyed and learned new things from this blog!
About the authors
Satwiki De
Software Engineer @Microsoft | Experienced in App Dev, Cloud-native solutions, DevOps & Generative AI | Curious explorer of tech and life
END
本期互動內容 ??
?在原型轉向產品的過程中，你采取了哪些措施來控制和規避風險？有什么經驗教訓？
原文鏈接：
