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

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

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

1、為什么標準化流程至關(guān)重要

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

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

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

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

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

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

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

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

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

3、大模型(LLM)應(yīng)用開發(fā)的關(guān)鍵要素

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3 尋找合適的平衡點

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

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

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

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

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

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

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

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

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

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

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

4.5 大模型（LLM）驗證的結(jié)構(gòu)

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

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

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

4.6 通過基礎(chǔ)測試和評估保證質(zhì)量

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

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

評估“生成式”解決方案（比如寫作）的效果，要比使用大模型（LLM）處理其他類型的任務(wù)（如分類、提取信息等）復(fù)雜得多。對于這些任務(wù)，我們可能需要使用更高級的模型（如GPT-4、Claude Opus或LLAMA3–70B）來幫助評判效果。

另外，一個好方法是在生成性內(nèi)容輸出之前，先產(chǎn)生一些確定性的內(nèi)容。這種內(nèi)容因為更容易進行測試，所以可以幫助我們更好地評估整體輸出的質(zhì)量。

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、關(guān)鍵決策：復(fù)盤的重要性

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

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

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

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

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

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

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

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

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

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

7、總結(jié)

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

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