譯者 | 朱先忠

審校 | 重樓

引言

大型語言模型（LLM）正在迅速成為現(xiàn)代人工智能的基石。然而，目前還沒有出現(xiàn)公認的最佳實踐，而且先驅們往往沒有明確的開發(fā)路線圖。因此，這種狀況急需要有人重新發(fā)明有關輪子；否則，將會使人陷入困境。

在過去的兩年里，我?guī)椭恍┙M織利用LLM構建了創(chuàng)新型應用程序。通過這次經(jīng)歷，我開發(fā)了一種經(jīng)得住考驗的方法來創(chuàng)建創(chuàng)新型LLM應用解決方案（受LLM.org.il社區(qū)的啟發(fā)而形成），我將在本文中與大家共同分享。

具體來說，本文將為讀者朋友在LLM原生開發(fā)的復雜環(huán)境中導航提供一幅清晰的路線圖。你將學習如何從構思轉變?yōu)閷嶒灐⒃u估和產(chǎn)品化的全過程，從而有助于釋放出你創(chuàng)建開創(chuàng)性應用程序的所有潛力。

本圖使用Dall-E3創(chuàng)建?

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

當今，LLM領域是如此充滿活力，以至于我們幾乎每天都能夠聽到新的突破性創(chuàng)新。這很令人興奮，但也讓人陷于迷茫——你可能會發(fā)現(xiàn)自己在這個過程中迷失了方向，不知道該做什么，或者如何將你的新穎的想法付諸實踐。

長話短說，如果你是一位想要有效地構建LLM原生應用程序的人工智能創(chuàng)新者（經(jīng)理或從業(yè)者），本文正是你的選擇。

實施標準化流程有助于啟動新項目，并提供以下幾個關鍵好處：

1. 標準化流程——有助于調整團隊成員，并確保新成員順利入職（尤其是在這種混亂的情況下）。?
2. 定義明確的里程碑——這是一種簡單的方法，用于跟蹤和衡量你的工作，并確保你沿著正確的道路前行。?
3. 確定決策點——LLM原生開發(fā)充滿了未知和“小實驗”（見下文）。清晰的決策點使我們能夠輕松地降低風險，并始終使我們的開發(fā)努力保持清晰而高效。?

LLM工程師的基本技能

與軟件研發(fā)中的任何其他既定角色不同，LLM原生開發(fā)絕對需要一個新角色：LLM工程師或AI工程師。

LLM工程師是一種獨特的綜合技能成員，涉及不同（既定）角色的技能：

• 軟件工程技能——像大多數(shù)軟件工程師一樣，大多數(shù)工作都涉及到將工程組件拼合在一起，并將其粘成一體。?
• 研究技能——正確理解LLM的原生實驗性質至關重要。雖然構建一些簡易的酷的演示程序非常容易，但這些酷的演示程序和實際解決方案之間的距離需要實驗證明并具備一定的靈活性。?
• 深入的業(yè)務/產(chǎn)品理解——由于模型的脆弱性，理解業(yè)務目標和過程至關重要，而不是拘泥于我們定義的架構。對LLM工程師來說，建立手動流程模型的能力是一項黃金技能。?

在寫這篇文章的時候，LLM工程仍然是全新的，相應的崗位招聘可能非常具有挑戰(zhàn)性。因此，企業(yè)較早些時間招聘具有后端/數(shù)據(jù)工程或數(shù)據(jù)科學背景的候選人可能是個好主意。

軟件工程師可能會期待一個更平穩(wěn)的過渡，因為實驗過程更“工程師化”，而不是“科學化”（與傳統(tǒng)的數(shù)據(jù)科學工作相比）。話雖如此，我看到許多數(shù)據(jù)科學家也在做這種轉變。只要你對自己必須接受新的“軟技能”這一事實感到滿意，那么你就已經(jīng)走在了正確的道路上！

LLM原生開發(fā)的關鍵要素

與經(jīng)典的后端應用程序（如CRUD）不同，這里沒有循序漸進的開發(fā)方案。像“人工智能”中的其他一切一樣，LLM原生應用程序需要開發(fā)人員具備研究和實驗的心態(tài)。

要“馴服一頭巨獸”，你必須分而治之，把你的工作劃分成更小的實驗模塊，測試其中的一些，最后再選擇最有希望的實驗組件。

我再怎么強調研究心態(tài)的重要性也不為過。這意味著，你可能會花時間探索一項研究內容，發(fā)現(xiàn)它“不可能”、“不夠好”或“不值得”。這完全沒關系——這意味著我們已經(jīng)走在了正確的道路上。

使用LLM進行實驗是構建LLM原生應用程序的唯一方法（并避免前進中的“陷阱”）（使用Dall-E3創(chuàng)建）

擁抱實驗——過程的核心

有時，你的“實驗”會失敗，然后你稍微調整一下你的工作，從而使得另一項實驗取得更好的效果。

這正是為什么，在設計最終解決方案之前，我們必須從簡單開始，盡可能規(guī)避風險。

1. 定義“預算”或時間表。讓我們看看在X周內我們能做什么，然后決定如何做或是否繼續(xù)。通常，2-4周的時間來了解基本的PoC（Proof of Concept：為觀點提供證據(jù)）就足夠了。如果它看起來很有希望——繼續(xù)投入資源來改善它。?
2. 實驗——無論你在實驗階段選擇自下而上還是自上而下的方法，你的目標都是最大限度地提高結果的連續(xù)性。在第一次實驗迭代結束時，你應該有一些PoC（與你的工作相關的其他成員可以使用）和你已經(jīng)實現(xiàn)的基本內容。?
3. 回顧性——在我們的研究階段結束時，我們可以了解構建這樣一個應用程序的可行性、局限性和成本。這有助于我們決定是否將其產(chǎn)品化，以及如何設計最終產(chǎn)品及其用戶體驗。?
4. 產(chǎn)品化——通過遵循標準軟件工程師最佳實踐并實施反饋和數(shù)據(jù)收集機制，開發(fā)項目的最終商業(yè)版本，并將其與解決方案的其余部分集成。?

LLM原生應用程序開發(fā)生命周期（圖片由作者提供）?

為了很好地實施以實驗為導向的過程，我們必須在處理和構建這些實驗時做出明智的決定：

精益起步——自下而上的方法

【譯者注】精益即“l(fā)ean”，起源于日本豐田的創(chuàng)作理念。

雖然許多早期采用者很快就進入了具有成熟Langchain或類似功能的“最先進”多鏈代理系統(tǒng)，但我發(fā)現(xiàn)采用“自下而上的方法”通常會產(chǎn)生更好的結果。

開始精益，非常精益，信奉“one prompt to rule them all（一個提示，統(tǒng)治他們所有人）”的哲學吧。盡管這種策略看起來可能是非常規(guī)的，而且一開始可能會產(chǎn)生糟糕的結果，但它可以為你的系統(tǒng)打開基礎。

從那里開始，然后不斷迭代和完善提示，采用提示工程技術來優(yōu)化結果。當你發(fā)現(xiàn)精益解決方案中的弱點時，通過添加分支來解決這些缺點，從而對流程進行拆分。

在設計我的LLM工作流程圖或LLM原生架構的每一片“葉子”時，我都會遵循魔幻三角形（The Magic Triangle）原則來確定何時何地修剪樹枝、拆分樹枝或加厚根部（通過提示工程技術），并擠出更多的檸檬。

自下而上方法示意圖（作者圖片）?

例如，要用自下而上的方法實現(xiàn)“原生語言SQL查詢”，我們可以從以原生方式將模式發(fā)送到LLM并要求它生成查詢開始。

自下而上的方法示例（圖片由作者提供）?

通常，這與“自上而下的方法”并不矛盾，而是在它之前邁出的又一步。這種方案有利于我們能夠快速獲勝，吸引更多的項目投資。

大局在前：自上而下的戰(zhàn)略

“我們知道LLM工作流并不容易，為了實現(xiàn)我們的目標，我們可能最終會采用一些工作流或LLM原生架構。”

自上而下的方法認識到了這一點，并從第一天開始就著手設計LLM原生架構，并探索實現(xiàn)其不同的步驟/鏈。

通過這種方式，你可以將工作流架構作為一個整體進行測試，并擠壓整個“檸檬”，而不是單獨精煉每一片“葉子”。

自上而下的方法過程：設計一次架構，然后實現(xiàn)架構并進行測試和測量（作者圖片）

例如，為了用自上而下的方法實現(xiàn)“原生語言SQL查詢”，我們將在開始編碼之前就開始設計體系結構，然后跳到完整的實現(xiàn)：

自上而下方法的一個例子（作者圖片）?

找到正確的平衡

當你開始試驗LLM時，你可能會從其中一個極端開始（過于復雜的自上而下或超級簡單的一次性）。事實上，沒有這樣的贏家。

理想情況下，在對模型進行編碼和實驗之前，你將定義一個好的SoP（標準操作流程），并為專家建模。在現(xiàn)實中，建模是非常困難的；有時，你可能無法接觸到這樣的專家。

我發(fā)現(xiàn)從一開始就要確定一個好的架構/SoP很有挑戰(zhàn)性，所以在投入使用之前，值得先進行一些嘗試。然而，這并不意味著一切都必須過于精簡。如果你已經(jīng)有了一個預先的理解，即某些東西必須被分解成更小的部分——那么就這樣做吧。

在任何情況下，在設計解決方案時，你都應該利用“魔幻三角形”原則，正確地對手動流程進行建模。

優(yōu)化你的解決方案——擠壓“檸檬”

在實驗階段，我們不斷擠壓“檸檬”，增加更多的復雜“層”：

• 提示工程技術——比如少樣本、角色分配，甚至動態(tài)少樣本。?
• 將上下文窗口從簡單的變量信息擴展到復雜的RAG流可以幫助改進結果。?
• 用不同的模型進行實驗——不同的模型在不同的任務上表現(xiàn)不同。此外，大型LLM通常不是很劃算，值得嘗試更多特定于任務的模型。?
• 提示節(jié)約——我了解到，在“節(jié)約”中使用標準操作流程（特別是提示和要求的輸出）通常會提高延遲。通過減少提示詞大小和模型需要經(jīng)歷的步驟，我們可以減少模型需要生成的輸入和輸出。你會感到驚訝，但提示節(jié)約（prompt dieting）有時甚至可以提高質量！?請注意，提示節(jié)約也可能導致質量下降。因此，在這樣做之前進行理智測試很重要。?
• 將流程拆分為更小的步驟也非常有益，并使優(yōu)化SOP的子流程變得更容易和可行。?

請注意，這可能會增加解決方案的復雜性或損害性能（例如，增加處理的符號數(shù)量）。為了緩解這種情況，請使用簡潔的提示和較小的模型。

根據(jù)經(jīng)驗，當系統(tǒng)提示的顯著變化為SOP的這一部分產(chǎn)生更好的結果時，通常最好進行拆分。

擠壓AI檸檬（使用Dall-E3創(chuàng)建）?

LLM實驗的剖析

就我個人而言，我更喜歡從一個簡單的Jupyter筆記本開始，使用Python、Pydantic和Jinja2：

1. 使用Pydantic從模型中定義我的輸出模式。?
2. 使用Jinja2編寫提示模板。?
3. 定義結構化輸出格式（在YAML文件中）。這將確保模型遵循“思維步驟”，并以我的SOP為指導。?
4. 通過Pydantic驗證確保此輸出；如果需要，請重試。?
5. 穩(wěn)定你的工作——使用Python文件和包將代碼組織成工作單元。?

在更廣泛的范圍內，你可以使用不同的工具，如??OpenAI流媒體???來輕松利用流媒體（和工具），??LiteLLM???在不同的提供商之間擁有標準化的LLM SDK，或??vLLM??來服務開源LLM。

通過健全測試和評估確保質量

健全性測試評估項目的質量，并確保項目質量不會低于你預先定義的成功率基準線。

把你的解決方案/提示詞庫想象成一條毯子——如果你把它拉得太長，它可能會突然無法覆蓋它曾經(jīng)覆蓋的一些使用場景。

要做到這一點，可以先定義一組你已經(jīng)成功覆蓋的案例，并確保你保持這種狀態(tài)（或者至少值得這樣做）。將其視為表驅動的??測試??可能會更易于操作。

請注意，評估“生成”解決方案（例如，編寫文本）的成功與否比使用LLM執(zhí)行其他任務（例如分類、實體提取等）要復雜得多。對于這類任務，你可能希望使用更智能的模型（如GPT4、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.

當前，已經(jīng)存在一些尖端的比較有前景的解決方案值得研究。我發(fā)現(xiàn)它們在評估基于RAG的解決方案時特別有用：你可以進一步了解??DeepChecks???、??Ragas???或??ArizeAI??。

做出明智的決策：復盤的重要性

在每個主要的/時間框架的實驗或里程碑之后，我們應該停下來，就如何以及是否繼續(xù)采用這種方法做出明智的決策。

在這一點上，你的實驗將有一個明確的成功率基準線，你將知道需要改進什么。

這也是開始討論該解決方案的產(chǎn)品化含義并從“產(chǎn)品工作”開始的一個好觀點：

1. 在產(chǎn)品中會是什么樣子？?
2. 限制/挑戰(zhàn)是什么？你將如何緩解這些問題？?
3. 你當前的延遲是多少？它足夠好嗎？?
4. 用戶體驗應該是什么？你可以使用哪些UI技巧？流媒體有幫助嗎？?
5. 代幣的預計支出是多少？我們能用更小的模型來減少開支嗎？?
6. 優(yōu)先級事項是什么？這些挑戰(zhàn)中的任何一項都是引人注目的嗎？?

假設我們達到的基準線“足夠好”，并且我們相信我們可以緩解我們提出的問題。在這種情況下，我們將繼續(xù)投資和改進該項目，同時確保它永遠不會降級并使用健全性測試。

本圖使用Dall-E3創(chuàng)建?

從實驗到產(chǎn)品：將你的解決方案變?yōu)楝F(xiàn)實

最后，但同樣重要的是，我們必須將我們的工作產(chǎn)品化。與任何其他生產(chǎn)級解決方案一樣，我們必須實現(xiàn)生產(chǎn)工程概念，如日志記錄、監(jiān)控、依賴關系管理、容器化、緩存等。

這是一個龐大的世界，但幸運的是，我們可以借鑒經(jīng)典的生產(chǎn)工程中的許多機制，甚至可以采用許多現(xiàn)有的工具。

話雖如此，還需要格外注意LLM原生應用程序的細微差別：

• 反饋循環(huán)——我們如何衡量成功？它只是一個“同意/反對”的機制，還是考慮采用我們的解決方案的更復雜的機制？?收集這些數(shù)據(jù)也很重要；今后，這可以幫助我們重新定義我們的理智“基線”，或者通過動態(tài)少樣本微調我們的結果，或者微調模型。?
• 緩存——與傳統(tǒng)的軟件工程不同，當我們在解決方案中涉及生成方面時，緩存可能非常具有挑戰(zhàn)性。為了緩解這種情況，探索緩存類似結果的選項（例如，使用RAG技術）和/或減少生成輸出（通過具有嚴格的輸出模式）。?
• 成本跟蹤——許多公司發(fā)現(xiàn)從“強大的模型”（如GPT-4或Opus）開始非常誘人；然而，在生產(chǎn)中，成本可能會迅速上升。避免對最終賬單感到驚訝，并確保始終計算輸入/輸出符號，并跟蹤你的工作流程影響。?
• 可調試性和跟蹤——確保你已經(jīng)設置了正確的工具來跟蹤“帶有錯誤”的輸入并在整個過程中跟蹤它。這通常包括保留用戶輸入以備日后調查和建立跟蹤系統(tǒng)。記住：“與過渡性軟件不同，人工智能會悄無聲息地失敗！”?

結語：你在推進LLM原生技術方面的作用

這可能是本文的結束，但肯定不是我們工作的結束。LLM原生開發(fā)是一個迭代過程，它涵蓋了更多的用例、挑戰(zhàn)和功能，并不斷改進我們的LLM產(chǎn)品。

當你繼續(xù)你的人工智能開發(fā)之旅時，保持敏捷，大膽地進行實驗，并牢記最終用戶。與社區(qū)分享你的經(jīng)驗和見解，我們可以一起推動LLM原生應用程序的發(fā)展。不斷探索、學習和建設——可能性是無窮的。

我希望本文能夠成為你LLM原生開發(fā)之旅中的寶貴伴侶！

本文使用縮略語

【1】SoP/SOP：標準操作流程，這是從魔幻三角形文章借鑒的概念。

【2】YAML：我發(fā)現(xiàn)使用YAML來構建輸出在LLM中效果更好。為什么？我的理論是，它去掉了不相關的標記，表現(xiàn)得很像原生語言。

【3】魔幻三角形（The Magic Triangle）：LLM原生開發(fā)藍圖；請繼續(xù)關注，并在它的藍圖發(fā)布時關注我已進行閱讀。

附：

原文標題：Building LLM Apps: A Clear Step-By-Step Guide，作者：Almog Baku

鏈接：https://towardsdatascience.com/building-llm-apps-a-clear-step-by-step-guide-1fe1e6ef60fd

譯者介紹

朱先忠，51CTO社區(qū)編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。