從零開始構建大模型(LLM)應用
大模型（LLM）已經成為當前人工智能的重要部分。但是，在這個領域還沒有固定的操作標準，開發者們往往沒有明確的指導，需要不斷嘗試和摸索。
在過去兩年中，我幫助了許多公司利用LLM來開發了很多創新的應用產品。基于這些經驗，我形成了一套實用的方法，并準備在這篇文章中與大家分享。
這套方法將提供一些步驟，幫助需要的小伙伴在LLM應用開發的復雜環境中找到方向。從最初的構思到PoC、評估再到產品化，了解如何將創意轉化為具有影響力的應用程序。
1、為什么標準化流程至關重要
大模型（LLM）的發展非常快，幾乎每天我們都能聽到一些新的創新。這種快速發展讓人感到既興奮又有點亂——你可能會感到迷茫，不知道接下來該怎么辦，或者怎樣用這些大模型(LLM)來推動公司業務的發展。
采用一個標準化的流程對啟動新項目非常有幫助，主要能帶來以下幾個好處：
- 統一流程 — 一個統一的流程可以幫助團隊成員更好地協作，特別是在混亂的時候，也能讓新人更順利地加入團隊。
- 設定清晰的里程碑 — 這是一個直接的方法，幫你跟蹤工作進度，評估成效，確保你正朝著目標前進。
- 找出決策點 — 在開發大模型應用時，我們會遇到很多未知情況和需要做的小實驗(PoC)。設定清晰的決策點可以幫我們降低風險，確保開發工作始終高效。
2、大模型工程師的必備技能
與軟件研發領域的其他角色不同，專門從事大模型開發的工作需要一種全新的職業角色：大模型工程師，也就是我們常說的AI工程師。
大模型工程師需要具備多種技能，包括：
- 軟件工程技能 — 這部分工作很像拼積木，需要把各種技術組件正確組合并確保它們能夠協同工作。
- 研究技能 — 深入了解大模型的PoC性質非常重要。雖然制作一個看起來很好的演示應用相對簡單，但要將這種演示轉化成真正有用的解決方案，需要不斷試驗和調整。
- 商業和產品理解 — 了解業務目標和流程比單純遵循我們設定的技術架構更重要。能夠將手工過程轉換成自動模型是大模型工程師的一項重要技能。
在寫這篇文章的時候，大模型（LLM）工程還是一個非常新的領域，招聘合適的人才可能會有些困難。候選人可以考慮那些有后端開發、大數據或有算法背景的，他們可能會更適合這個職位。
軟件工程師可能轉換會比較順暢，因為這里的PoC工作更多的是偏向工程操作，而不像傳統的人工智能那樣偏算法研究。不過，我也看到很多算法工程師成功地轉換成大模型工程師，我今年年底準備出版的一本書中有介紹如何使用python編寫大模型api的介紹。只要愿意接受并學習新的軟技能，你已經走在了LLM應用的道路上了！
3、大模型(LLM)應用開發的關鍵要素
不像傳統的后端應用（比如CRUD），在大模型(LLM)的開發中，目前沒有一套固定的操作指南。像在人工智能領域的其他領域一樣，開發這類應用需要你具備一種研究和嘗試的心態。
要掌控這種復雜性，我們需要把大任務拆分成一系列小任務，嘗試這些任務，然后挑選出最有希望的一個繼續深入。
通過多個項目的實踐經驗，構建大模型(LLM)應用開發擁有一種嘗試的心態是極其重要的。這意味著我們需要花時間去探索一個研究方向，最終發現這個方向“行不通”、“不夠好”或者“不值得繼續”。這是完全可以接受的——實際上，這表示我們在找到符合我們業務的專有大模型應用。
4、嘗試的重要性：這是核心流程
有時候，我們第一個小應用可能會失敗，這時我們就需要稍微調整方向，嘗試另一個新的方向。往往這種調整后的新方向能帶來意想不到的結果。
這就是為什么在設計我們的最終解決方案之前，我們需要從簡單做起并小心規避風險。
- 設定一個“預算”或時間范圍。 我們來看看在接下來的幾周內能完成什么，然后再決定是否繼續。通常來說，2-4周的時間足以幫我們了解基本的概念驗證（PoC）。如果這個方向看起來有潛力，我們就繼續投入資源去完善它。
- 實驗(PoC) — 無論是選擇自下而上還是自上而下的方式進行PoC，我們的目標都是盡可能提高成功率。第一輪實驗結束時，應該得到一些初步的產品概念（PoC），利益相關者可以初步使用并評估這些產品。
- 復盤 — 研究階段結束時，我們能夠明確這個應用的可行性、局限性以及成本。這有助于我們決定是否將其轉化為產品，以及如何設計最終的產品和用戶體驗。
- 產品化 — 開發一個準備好投入生產的版本，并按照軟件工程的標準最佳實踐，將其與其他解決方案整合，并實施反饋與數據收集機制。
要想好好執行這種注重實驗(PoC) 的過程，我們需要決定如何策劃和進行這些PoC：
4.1 從簡單開始：自下而上的方法
很多人一開始就直接使用成熟的Langchain或類似的復雜多鏈代理系統，但我發現，采取“自下而上”的方法往往能獲得更好的效果。
從最簡單的開始，極其簡單，遵循“一條指令掌控一切”的理念。雖然這種方法可能看起來有點非主流，一開始可能會出現一些不盡如人意的結果，但它能幫助我們為系統建立一個基礎水平。
從這點開始，需要持續改進prompt，使用prompt來獲得更好的結果。當發現簡化方案存在缺陷時，嘗試通過增加新的處理分支來彌補這些不足。
在設計大模型（LLM）工作流程圖中的每一個節點，或者說LLM專用架構時，我會遵循LLM三角原則來決定何時添加分支、何時進行分割，或者通過使用prompt來加強基礎，從而更好地利用每一次機會。
例如，若要采用自下而上的方法實現“本地語言 SQL 查詢”，我們會從一個基本的步驟開始：將數據庫的結構（schema）發送給大模型（LLM），讓它根據這些信息生成 SQL 查詢語句。
通常，這并不會與“自上而下的方法”沖突，而是先進行一個額外的步驟。這樣我們能快速展示一些初步成果，幫助領導層看到進展，從而決定是否繼續投入更多資源。
4.2 從總體布局著手：自上而下的策略
“我們知道，大模型（LLM）的工作流程并不簡單，為了實現我們的目標，我們很可能需要一些特定的工作流程或LLM專屬架構。”
自上而下的策略正是基于這個理解，從第一天起就開始設計LLM專用架構，并從一開始就實施其各個步驟和環節。
采用這種方法，我們可以將工作流架構作為一個整體進行測試，從而充分利用整個系統的潛力，而不是逐個細節進行優化。
例如，使用自上而下的方法來實現“本地語言SQL查詢”，我們會先從設計整體架構開始，然后再開始編碼，直接進入完整的實施階段：
4.3 尋找合適的平衡點
當開始使用大模型（LLM）進行PoC時，很可能會從一個極端開始——不是過于復雜的自上而下策略，就是過于簡單的一次性嘗試。實際上，沒有哪一種方法總是最佳的。
在理想狀態下——在開始編寫代碼和進行模型試驗之前，應該制定一個有效的標準操作程序（SoP）并嘗試模擬一個專家。但實際上，模擬專家是非常困難的，有時甚至可能無法接觸到相關的專家。
在最初嘗試確定一個有效的架構或標準操作程序（SoP）時，我發現這個過程充滿挑戰，因此在開始真正產品實施之前，進行初步的驗證是非常有價值的。然而，這并不意味著所有事情都必須執行得非常簡化。如果我們已經明白某些步驟必須細分為更小的部分，需要馬上實施并驗證。
在設計解決方案時，我們應該運用大模型三角原則（LLM Triangle Principles），并正確模擬手動過程，以確保方案的實用性和有效性。
4.4 優化解決方案：最大化利用資源
在PoC階段，我們不斷地增加更多的復雜性層級：
- prompt 技術 — 比如使用很少的樣本來訓練模型、分配不同的角色給模型，或者利用動態樣本學習來改進。
- 擴大考慮范圍 — 從處理簡單的數據信息到處理復雜的查詢生成流程，這樣可以幫助我們得到更好的結果。
- 嘗試多種模型 — 不同的模型適合不同的任務。大模型雖然功能強大，但成本較高，尋找更專門針對某一任務的模型往往更經濟。
- 簡化prompt — 通過簡化模型的prompt和期望輸出，可以讓模型反應更快。
- 縮短prompt 長度和減少處理步驟 — 這可以減少模型需要處理的數據量。會發現簡化操作有時候甚至能提高處理質量！
不過要注意，過度簡化有時會影響結果的質量，因此在做出這些調整前，進行一些基本的效果測試是很重要的。
將復雜流程拆分成更小的步驟，可以使得每個子步驟的優化更加容易實現，也更有效。
請注意，這種做法可能會增加解決方案的復雜度或影響性能（例如，增加處理的Tokens）。為了降低這種風險，應當盡量使用簡潔的prompt和更小的模型。
一個基本的原則是，如果系統提示的變化在標準操作程序（SOP）的某個環節能夠顯著提高結果，那么進行分割通常是最好的選擇。
4.5 大模型（LLM）驗證的結構
我個人比較喜歡從一個基礎的Jupyter Notebook開始PoC，這個Notebook使用Python、Pydantic和Jinja2來配置：
- 使用Pydantic：定義模型輸出的結構化模式，這是確保輸出數據符合預期格式的關鍵。
- 利用Jinja2：編寫模板來生成模型所需的提示，這對控制模型的輸入非常重要。
- 設定結構化輸出格式：采用YAML來格式化輸出。這樣可以確保模型按照既定的“思考步驟”進行，嚴格遵循我的標準操作程序（SOP）。
- 應用Pydantic的驗證功能：驗證輸出的準確性，必要時可以進行重試，這是保證輸出質量的一個重要步驟。
- 代碼結構化：將代碼組織成Python文件和包，這不僅有助于維護，也方便未來的擴展和管理。
在更廣泛的應用中，可以使用諸如openai-streaming之類的工具，這樣可以方便地實現流處理；使用LiteLLM，以便在不同的服務提供商之間使用標準化的大模型（LLM）軟件開發工具包（SDK）；或者使用vLLM來運行開源的大模型。這些工具都可以幫助您更有效地使用和部署大模型技術。
4.6 通過基礎測試和評估保證質量
基本測試是一種評估項目質量的有效方法，確保項目的成功率達到或超過您預先設定的標準。
為此，您需要列出一些您已經成功處理的案例，并確保這些案例能持續保持成功的狀態（或至少確保持續投入是值得的）。將這個過程視為表格驅動的測試可能會幫助您更系統地進行管理和評估。
評估“生成式”解決方案（比如寫作）的效果，要比使用大模型（LLM）處理其他類型的任務（如分類、提取信息等）復雜得多。對于這些任務，我們可能需要使用更高級的模型（如GPT-4、Claude Opus或LLAMA3–70B）來幫助評判效果。
另外，一個好方法是在生成性內容輸出之前，先產生一些確定性的內容。這種內容因為更容易進行測試，所以可以幫助我們更好地評估整體輸出的質量。
cities:
- New York
- Tel Aviv
vibes:
- vibrant
- energetic
- youthful
target_audience:
age_min: 18
age_max: 30
gender: both
attributes:
- adventurous
- outgoing
- culturally curious
# ignore the above, only show the user the `text` attr.
text: Both New York and Tel Aviv buzz with energy, offering endless activities, nightlife, and cultural experiences perfect for young, adventurous tourists.有一些前沿而有前途的解決方案非常值得探索。在評估基于RAG的解決方案時，我發現特別有用的是這幾個工具：DeepChecks、Ragas和ArizeAI。可以去了解一下。
5、關鍵決策：復盤的重要性
每次完成重要PoC或達到階段性目標后，我們都應該停下來，仔細認真復盤，然后做出關鍵決策，決定是否以及如何繼續這條路。
這時候，PoC應該已經有了一個明確的成功率基準，我們也會清楚哪些地方還需要改進。
這是一個很好的開始，討論這個解決方案如何產品化以及這將帶來哪些影響，我們需要綜合考慮以下幾個問題：
- 這個解決方案在產品中將如何實現？
- 我們面臨哪些限制和挑戰？我們將如何應對這些問題？
- 當前的響應速度如何？它能滿足我們的需求嗎？
- 應該設計怎樣的用戶體驗？我們可以利用哪些界面技巧？流式處理能起到什么作用？
- 預計將在Tokens上花費多少？我們是否可以通過使用更小的模型來降低成本？
- 什么是優先級？有沒有什么挑戰可能成為項目的障礙？
如果我們認為已經達到了一個“足夠好”的基線，并且能夠解決我們面臨的問題，那么我們將繼續投資并改進這個項目，同時確保其性能不會退化，并執行必要的基礎測試。
6、從PoC到產品：實現您的解決方案
最后，我們必須將我們的工作轉化為產品。像處理任何成熟的解決方案一樣，我們需要引入諸如日志記錄、監控、依賴管理、容器化和緩存等生產工程的基本概念。
雖然這是一個復雜的領域，但幸運的是，我們可以借鑒傳統生產工程的許多方法，并且還可以使用很多現成的工具。
雖然如此，我們還需要特別關注一些與大模型（LLM）原生應用相關的細節問題：
- 反饋循環 — 我們應該如何衡量成功？是僅靠簡單的“點贊/點踩”機制，還是需要一個更復雜的系統，來考慮我們解決方案的實際應用情況？
- 同樣重要的是要收集這些數據；隨著時間的推移，這可以幫助我們重新定義我們的基準線，或者使用動態少示例技術微調結果，或者對模型進行微調。
- 緩存 — 不同于傳統軟件工程，當我們的解決方案包含生成內容時，實現緩存可能非常有挑戰性。為了解決這個問題，可以探索緩存相似結果的方法（例如使用RAG），或通過設定嚴格的輸出格式來減少生成內容。
- 成本追蹤 — 許多公司傾向于從使用功能全面的模型（如GPT-4或Opus）開始，但在生產環境中，成本可能迅速增加。為了避免在最后成本上驚訝，確保測量輸入/輸出的Tokens 數量，并持續跟蹤你的工作流程的影響（沒有這些實踐，以后很難進行性能分析）。
- 可調試性和追蹤 — 確保已經部署了合適的工具來跟蹤可能出現的問題，并在整個過程中進行追蹤。這通常涉及保留用戶的輸入以供后續調查，并建立一個追蹤系統。要記住：“與傳統軟件不同，人工智能的失敗往往沒有實際反饋可追蹤的！”
7、總結
大模型（LLM）的應用開發是一個不斷進化的過程，它涉及到擴展應用場景、解決新問題、添加新功能，并持續改進LLM產品。
在繼續進行人工智能開發的過程中，保持靈活，勇于嘗試新的方式，以最終用戶的需求為中心。這樣，我們可以不斷推動技術前進，讓產品更貼合用戶需求，更好地服務于實際應用。
