大模型（LLM）已經成為當前人工智能的重要部分。但是，在這個領域還沒有固定的操作標準，開發(fā)者們往往沒有明確的指導，需要不斷嘗試和摸索。

在過去兩年中，我?guī)椭嗽S多公司利用LLM來開發(fā)了很多創(chuàng)新的應用產品。基于這些經驗，我形成了一套實用的方法，并準備在這篇文章中與大家分享。

這套方法將提供一些步驟，幫助需要的小伙伴在LLM應用開發(fā)的復雜環(huán)境中找到方向。從最初的構思到PoC、評估再到產品化，了解如何將創(chuàng)意轉化為具有影響力的應用程序。

1、為什么標準化流程至關重要

大模型（LLM）的發(fā)展非?？?，幾乎每天我們都能聽到一些新的創(chuàng)新。這種快速發(fā)展讓人感到既興奮又有點亂——你可能會感到迷茫，不知道接下來該怎么辦，或者怎樣用這些大模型(LLM)來推動公司業(yè)務的發(fā)展。

采用一個標準化的流程對啟動新項目非常有幫助，主要能帶來以下幾個好處：

• 統(tǒng)一流程 — 一個統(tǒng)一的流程可以幫助團隊成員更好地協(xié)作，特別是在混亂的時候，也能讓新人更順利地加入團隊。
• 設定清晰的里程碑 — 這是一個直接的方法，幫你跟蹤工作進度，評估成效，確保你正朝著目標前進。
• 找出決策點 — 在開發(fā)大模型應用時，我們會遇到很多未知情況和需要做的小實驗(PoC)。設定清晰的決策點可以幫我們降低風險，確保開發(fā)工作始終高效。

2、大模型工程師的必備技能

與軟件研發(fā)領域的其他角色不同，專門從事大模型開發(fā)的工作需要一種全新的職業(yè)角色：大模型工程師，也就是我們常說的AI工程師。

大模型工程師需要具備多種技能，包括：

• 軟件工程技能 — 這部分工作很像拼積木，需要把各種技術組件正確組合并確保它們能夠協(xié)同工作。
• 研究技能 — 深入了解大模型的PoC性質非常重要。雖然制作一個看起來很好的演示應用相對簡單，但要將這種演示轉化成真正有用的解決方案，需要不斷試驗和調整。
• 商業(yè)和產品理解 — 了解業(yè)務目標和流程比單純遵循我們設定的技術架構更重要。能夠將手工過程轉換成自動模型是大模型工程師的一項重要技能。

在寫這篇文章的時候，大模型（LLM）工程還是一個非常新的領域，招聘合適的人才可能會有些困難。候選人可以考慮那些有后端開發(fā)、大數(shù)據(jù)或有算法背景的，他們可能會更適合這個職位。

軟件工程師可能轉換會比較順暢，因為這里的PoC工作更多的是偏向工程操作，而不像傳統(tǒng)的人工智能那樣偏算法研究。不過，我也看到很多算法工程師成功地轉換成大模型工程師，我今年年底準備出版的一本書中有介紹如何使用python編寫大模型api的介紹。只要愿意接受并學習新的軟技能，你已經走在了LLM應用的道路上了！

3、大模型(LLM)應用開發(fā)的關鍵要素

不像傳統(tǒng)的后端應用（比如CRUD），在大模型(LLM)的開發(fā)中，目前沒有一套固定的操作指南。像在人工智能領域的其他領域一樣，開發(fā)這類應用需要你具備一種研究和嘗試的心態(tài)。

要掌控這種復雜性，我們需要把大任務拆分成一系列小任務，嘗試這些任務，然后挑選出最有希望的一個繼續(xù)深入。

通過多個項目的實踐經驗，構建大模型(LLM)應用開發(fā)擁有一種嘗試的心態(tài)是極其重要的。這意味著我們需要花時間去探索一個研究方向，最終發(fā)現(xiàn)這個方向“行不通”、“不夠好”或者“不值得繼續(xù)”。這是完全可以接受的——實際上，這表示我們在找到符合我們業(yè)務的專有大模型應用。

4、嘗試的重要性：這是核心流程

有時候，我們第一個小應用可能會失敗，這時我們就需要稍微調整方向，嘗試另一個新的方向。往往這種調整后的新方向能帶來意想不到的結果。

這就是為什么在設計我們的最終解決方案之前，我們需要從簡單做起并小心規(guī)避風險。

• 設定一個“預算”或時間范圍。 我們來看看在接下來的幾周內能完成什么，然后再決定是否繼續(xù)。通常來說，2-4周的時間足以幫我們了解基本的概念驗證（PoC）。如果這個方向看起來有潛力，我們就繼續(xù)投入資源去完善它。
• 實驗(PoC) — 無論是選擇自下而上還是自上而下的方式進行PoC，我們的目標都是盡可能提高成功率。第一輪實驗結束時，應該得到一些初步的產品概念（PoC），利益相關者可以初步使用并評估這些產品。
• 復盤 — 研究階段結束時，我們能夠明確這個應用的可行性、局限性以及成本。這有助于我們決定是否將其轉化為產品，以及如何設計最終的產品和用戶體驗。
• 產品化 — 開發(fā)一個準備好投入生產的版本，并按照軟件工程的標準最佳實踐，將其與其他解決方案整合，并實施反饋與數(shù)據(jù)收集機制。

要想好好執(zhí)行這種注重實驗(PoC) 的過程，我們需要決定如何策劃和進行這些PoC：

4.1 從簡單開始：自下而上的方法

很多人一開始就直接使用成熟的Langchain或類似的復雜多鏈代理系統(tǒng)，但我發(fā)現(xiàn)，采取“自下而上”的方法往往能獲得更好的效果。

從最簡單的開始，極其簡單，遵循“一條指令掌控一切”的理念。雖然這種方法可能看起來有點非主流，一開始可能會出現(xiàn)一些不盡如人意的結果，但它能幫助我們?yōu)橄到y(tǒng)建立一個基礎水平。

從這點開始，需要持續(xù)改進prompt，使用prompt來獲得更好的結果。當發(fā)現(xiàn)簡化方案存在缺陷時，嘗試通過增加新的處理分支來彌補這些不足。

在設計大模型（LLM）工作流程圖中的每一個節(jié)點，或者說LLM專用架構時，我會遵循LLM三角原則來決定何時添加分支、何時進行分割，或者通過使用prompt來加強基礎，從而更好地利用每一次機會。

例如，若要采用自下而上的方法實現(xiàn)“本地語言 SQL 查詢”，我們會從一個基本的步驟開始：將數(shù)據(jù)庫的結構（schema）發(fā)送給大模型（LLM），讓它根據(jù)這些信息生成 SQL 查詢語句。

通常，這并不會與“自上而下的方法”沖突，而是先進行一個額外的步驟。這樣我們能快速展示一些初步成果，幫助領導層看到進展，從而決定是否繼續(xù)投入更多資源。

4.2 從總體布局著手：自上而下的策略

“我們知道，大模型（LLM）的工作流程并不簡單，為了實現(xiàn)我們的目標，我們很可能需要一些特定的工作流程或LLM專屬架構?！?/p>

自上而下的策略正是基于這個理解，從第一天起就開始設計LLM專用架構，并從一開始就實施其各個步驟和環(huán)節(jié)。

采用這種方法，我們可以將工作流架構作為一個整體進行測試，從而充分利用整個系統(tǒng)的潛力，而不是逐個細節(jié)進行優(yōu)化。

例如，使用自上而下的方法來實現(xiàn)“本地語言SQL查詢”，我們會先從設計整體架構開始，然后再開始編碼，直接進入完整的實施階段：

4.3 尋找合適的平衡點

當開始使用大模型（LLM）進行PoC時，很可能會從一個極端開始——不是過于復雜的自上而下策略，就是過于簡單的一次性嘗試。實際上，沒有哪一種方法總是最佳的。

在理想狀態(tài)下——在開始編寫代碼和進行模型試驗之前，應該制定一個有效的標準操作程序（SoP）并嘗試模擬一個專家。但實際上，模擬專家是非常困難的，有時甚至可能無法接觸到相關的專家。

在最初嘗試確定一個有效的架構或標準操作程序（SoP）時，我發(fā)現(xiàn)這個過程充滿挑戰(zhàn)，因此在開始真正產品實施之前，進行初步的驗證是非常有價值的。然而，這并不意味著所有事情都必須執(zhí)行得非常簡化。如果我們已經明白某些步驟必須細分為更小的部分，需要馬上實施并驗證。

在設計解決方案時，我們應該運用大模型三角原則（LLM Triangle Principles），并正確模擬手動過程，以確保方案的實用性和有效性。

4.4 優(yōu)化解決方案：最大化利用資源

在PoC階段，我們不斷地增加更多的復雜性層級：

• prompt 技術 — 比如使用很少的樣本來訓練模型、分配不同的角色給模型，或者利用動態(tài)樣本學習來改進。
• 擴大考慮范圍 — 從處理簡單的數(shù)據(jù)信息到處理復雜的查詢生成流程，這樣可以幫助我們得到更好的結果。
• 嘗試多種模型 — 不同的模型適合不同的任務。大模型雖然功能強大，但成本較高，尋找更專門針對某一任務的模型往往更經濟。
• 簡化prompt — 通過簡化模型的prompt和期望輸出，可以讓模型反應更快。
• 縮短prompt 長度和減少處理步驟 — 這可以減少模型需要處理的數(shù)據(jù)量。會發(fā)現(xiàn)簡化操作有時候甚至能提高處理質量！

不過要注意，過度簡化有時會影響結果的質量，因此在做出這些調整前，進行一些基本的效果測試是很重要的。

將復雜流程拆分成更小的步驟，可以使得每個子步驟的優(yōu)化更加容易實現(xiàn)，也更有效。

請注意，這種做法可能會增加解決方案的復雜度或影響性能（例如，增加處理的Tokens）。為了降低這種風險，應當盡量使用簡潔的prompt和更小的模型。

一個基本的原則是，如果系統(tǒng)提示的變化在標準操作程序（SOP）的某個環(huán)節(jié)能夠顯著提高結果，那么進行分割通常是最好的選擇。

4.5 大模型（LLM）驗證的結構

我個人比較喜歡從一個基礎的Jupyter Notebook開始PoC，這個Notebook使用Python、Pydantic和Jinja2來配置：

• 使用Pydantic：定義模型輸出的結構化模式，這是確保輸出數(shù)據(jù)符合預期格式的關鍵。
• 利用Jinja2：編寫模板來生成模型所需的提示，這對控制模型的輸入非常重要。
• 設定結構化輸出格式：采用YAML來格式化輸出。這樣可以確保模型按照既定的“思考步驟”進行，嚴格遵循我的標準操作程序（SOP）。
• 應用Pydantic的驗證功能：驗證輸出的準確性，必要時可以進行重試，這是保證輸出質量的一個重要步驟。
• 代碼結構化：將代碼組織成Python文件和包，這不僅有助于維護，也方便未來的擴展和管理。

在更廣泛的應用中，可以使用諸如openai-streaming之類的工具，這樣可以方便地實現(xiàn)流處理；使用LiteLLM，以便在不同的服務提供商之間使用標準化的大模型（LLM）軟件開發(fā)工具包（SDK）；或者使用vLLM來運行開源的大模型。這些工具都可以幫助您更有效地使用和部署大模型技術。

4.6 通過基礎測試和評估保證質量

基本測試是一種評估項目質量的有效方法，確保項目的成功率達到或超過您預先設定的標準。

為此，您需要列出一些您已經成功處理的案例，并確保這些案例能持續(xù)保持成功的狀態(tài)（或至少確保持續(xù)投入是值得的）。將這個過程視為表格驅動的測試可能會幫助您更系統(tǒng)地進行管理和評估。

評估“生成式”解決方案（比如寫作）的效果，要比使用大模型（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的解決方案時，我發(fā)現(xiàn)特別有用的是這幾個工具：DeepChecks、Ragas和ArizeAI?？梢匀チ私庖幌?。

5、關鍵決策：復盤的重要性

每次完成重要PoC或達到階段性目標后，我們都應該停下來，仔細認真復盤，然后做出關鍵決策，決定是否以及如何繼續(xù)這條路。

這時候，PoC應該已經有了一個明確的成功率基準，我們也會清楚哪些地方還需要改進。

這是一個很好的開始，討論這個解決方案如何產品化以及這將帶來哪些影響，我們需要綜合考慮以下幾個問題：

• 這個解決方案在產品中將如何實現(xiàn)？
• 我們面臨哪些限制和挑戰(zhàn)？我們將如何應對這些問題？
• 當前的響應速度如何？它能滿足我們的需求嗎？
• 應該設計怎樣的用戶體驗？我們可以利用哪些界面技巧？流式處理能起到什么作用？
• 預計將在Tokens上花費多少？我們是否可以通過使用更小的模型來降低成本？
• 什么是優(yōu)先級？有沒有什么挑戰(zhàn)可能成為項目的障礙？

如果我們認為已經達到了一個“足夠好”的基線，并且能夠解決我們面臨的問題，那么我們將繼續(xù)投資并改進這個項目，同時確保其性能不會退化，并執(zhí)行必要的基礎測試。

6、從PoC到產品：實現(xiàn)您的解決方案

最后，我們必須將我們的工作轉化為產品。像處理任何成熟的解決方案一樣，我們需要引入諸如日志記錄、監(jiān)控、依賴管理、容器化和緩存等生產工程的基本概念。

雖然這是一個復雜的領域，但幸運的是，我們可以借鑒傳統(tǒng)生產工程的許多方法，并且還可以使用很多現(xiàn)成的工具。

雖然如此，我們還需要特別關注一些與大模型（LLM）原生應用相關的細節(jié)問題：

• 反饋循環(huán) — 我們應該如何衡量成功？是僅靠簡單的“點贊/點踩”機制，還是需要一個更復雜的系統(tǒng)，來考慮我們解決方案的實際應用情況？
• 同樣重要的是要收集這些數(shù)據(jù)；隨著時間的推移，這可以幫助我們重新定義我們的基準線，或者使用動態(tài)少示例技術微調結果，或者對模型進行微調。
• 緩存 — 不同于傳統(tǒng)軟件工程，當我們的解決方案包含生成內容時，實現(xiàn)緩存可能非常有挑戰(zhàn)性。為了解決這個問題，可以探索緩存相似結果的方法（例如使用RAG），或通過設定嚴格的輸出格式來減少生成內容。
• 成本追蹤 — 許多公司傾向于從使用功能全面的模型（如GPT-4或Opus）開始，但在生產環(huán)境中，成本可能迅速增加。為了避免在最后成本上驚訝，確保測量輸入/輸出的Tokens 數(shù)量，并持續(xù)跟蹤你的工作流程的影響（沒有這些實踐，以后很難進行性能分析）。
• 可調試性和追蹤 — 確保已經部署了合適的工具來跟蹤可能出現(xiàn)的問題，并在整個過程中進行追蹤。這通常涉及保留用戶的輸入以供后續(xù)調查，并建立一個追蹤系統(tǒng)。要記?。骸芭c傳統(tǒng)軟件不同，人工智能的失敗往往沒有實際反饋可追蹤的！”

7、總結

大模型（LLM）的應用開發(fā)是一個不斷進化的過程，它涉及到擴展應用場景、解決新問題、添加新功能，并持續(xù)改進LLM產品。

在繼續(xù)進行人工智能開發(fā)的過程中，保持靈活，勇于嘗試新的方式，以最終用戶的需求為中心。這樣，我們可以不斷推動技術前進，讓產品更貼合用戶需求，更好地服務于實際應用。