先前我們聊到了《從零開始構建大模型(LLM)應用》，不少朋友偷偷問我：“什么是LLM的三角原則？”今天就給大家仔細講講構建LLM應用的三角原則。這套原則其實不復雜，由“3+1”(一范式三原則)個基礎組成，適合任何團隊來實踐。

說到以LLM為核心的應用，有不少人以為是高大上的模型占主導，但其實情況是這樣的：10%是那些復雜的模型，而有足足90%是實驗性的、以數據為驅動的工程作業。

當我們把LLM應用到實際產品中時，需要的不僅是代碼功底，更多的是工程上的精磨細打。如果用戶不能直接和LLM打交道，那我們就必須搭建完善的構造prompt ，確保涵蓋所有必要的細節，否則用戶的反饋可能就沒法收集完整，將會影響到后續的迭代升級！

1、LLM三角原則概念

提到LLM三角原則，你可能會覺得這是個很復雜的概念，但實際上，它就是我們構建高效LLM本地應用的一套基本指南。這套原則為開發者們提供了清晰的框架和方向，一步一步地打造出既健壯又可靠的LLM應用。有了這個原則作為指南，開發的過程將會變得更有條不紊，有效率。

1.1關鍵點

在我們打造LLM本地應用的過程中，LLM三角原則介紹了一個范式三大實用原則。

我們來看看范式：標準操作程序（SOP）。這個原則幫助我們把握好三個重要原則：模型、工程集成和上下文數據。

簡單地說，把這三部分通過SOP進行精細調整，就是打造一個高效強大LLM本地應用的秘訣。這就像是確保我們的應用在正確的軌道上高速前進，既穩定又快速。

2. 標準操作程序（SOP）

**標準操作程序（SOP）**是一個常見的概念。其實就是一本操作手冊，里面詳細記錄了每一步怎么做，確保每個員工做同一個工作時，效果都差不多，質量都很高。就像是給沒有經驗的員工一個詳細的指導書，讓他們也能像正常工作。

在我們構建LLM應用時，我們也用了這個原則。把模型想象成一個剛入行的新手，通過SOP這樣的標準操作指南來“教”它怎么像專家那樣完成任務。這樣一來，我們的應用不僅運行得更流暢，出來的成果也能保證是高質量的。

“沒有SOP，再厲害的LLM也難以保持一貫的高質量。”

在弄清楚SOP指導范式的時候，我們需要思考哪些技術工具可以幫助我們最有效地實行三大原則。

2.1 認知建模

要制定SOP，我們得先觀察那些干得最好的員工——也就是我們的業務專家。我們需要模仿他們的思考和工作方式，確保能夠達到他們同樣的成果，并且要把他們的每一步操作都記錄下來。

當我們編輯和正式化這些記錄后，就會形成一套詳盡的操作指南。這套指南能幫助經驗不夠或技術不足的員工也能夠順利完成工作。

我們自己在工作時，如果任務太復雜，就會感到頭腦負擔重。所以我們通常會把復雜的任務簡化或者分解成小步驟，可以幫助我們更輕松地完成任務。遵循這樣簡單明了的分步指導，比起那些長長的、復雜的操作流程要容易得多。

在這個過程中，我們還會注意到一些專家在不經意間采取的小小習慣，這些習慣可能看起來微不足道，但實際上對最終結果有很大的影響。

比如說，我們想要模擬一個數據分析(通常是使用SQL或者表格)的工作方式。我們可以先從訪談開始，問他們一些具體的問題，了解他們的日常工作流程：

• 當需要你分析一個業務問題時，你通常會怎么做？
• 你是如何確保你的解決方案完全符合需求的？
• 接下來，我們會把我們理解的過程反饋給受訪者看看，比如說：“所以你是這樣分析的嗎？”
• 然后詢問：“這個流程可以覆蓋你的工作過程嗎？”這樣可以讓他們糾正我們可能理解錯誤的地方。
• 諸如此類的問題。

隱性認知過程有很多種，它們的形式和表現各不相同。比如說，“業務特定定義”就是一個典型例子。拿“暢銷書”這個詞來說，對于我們的業務專家來講，這是一個非常重要的術語，他們對這個詞有著明確的理解和定義。但如果你問一般人，他們可能就不那么清楚這個詞具體是什么意思了。

到最后，我們就能擁有一套完整的SOP流程，這讓我們可以模仿我們最優秀分析師的工作方法。當我們試圖繪制這些復雜的流程時，將它們用圖表形式展示出來會非常有幫助。特別是當這些流程包括許多小步驟、條件選擇和不同分支時，圖表的方式可以讓我們更清晰地看到每一個環節，理解和執行起來也會更加直觀。這樣的方法能幫助我們更好地掌握流程，確保像那些優秀的分析師一樣執行每一步操作。

我們的最終解決方案應該嚴格按照SOP中定義的步驟來模仿執行。在設計初期，不必過多關注實現的具體細節——這部分我們可以在后續階段，針對解決方案的具體步驟或環節中逐步實施。

與其他原則不同，認知建模（即編寫SOP）是一個獨立的過程。我強烈推薦，在動手編寫代碼之前，先對整個流程進行模擬。當然，在實際實施過程中，隨著對問題的理解不斷深入，你可能需要根據新的認識對模型進行調整。

既然我們已經了解到創建一個SOP的重要性，這個SOP將指導我們更好地理解產品的問題及定位，并探討如何有效利用各種工程技術來實施這一過程。這種方法確保我們的方案既符合需求又具有執行效率。

3. 工程集成

工程集成是實施SOP并最大化模型效用的關鍵。在考慮工程集成原則時，我們需要思考：使用的“工具”里有哪些技術可以幫助我們執行和完善SOP？這些技術又如何確保模型能有效執行并滿足我們的需求？

在我們的工程技術中，有些技術僅在提示層面實施，而更多技術則需要在軟件層面才能有效運作，還有一些技術是結合了這兩個層面。

雖然每天我們都能遇到很多小調整，但在這里主要介紹兩種重要的技術：工作流/鏈路和Agents。這兩種技術對于我們的系統來說至關重要，它們幫助我們更高效地管理和執行復雜的任務。

3.1. LLM應用架構設計（工作流或鏈路）

LLM應用架構設計其實是在描述我們的LLM應用要完成任務的各個流程。

在我們的設計中，每一個步驟都是不可或缺的，各自獨立地完成特定任務。有些步驟可能只需要靠一些固定的代碼來執行；而對于其他步驟，我們可能會用到LLM（Agents）。

為了更好地構建這個架構，我們需要重新審視之前制定的標準操作程序（SOP），并思考以下幾個問題：

• 哪些SOP步驟應該合并到同一個流程中？哪些步驟需要分開處理？
• 哪些步驟應該獨立執行（雖然它們可能依賴前一個步驟的信息）？
• 哪些步驟可以通過固定步驟來實現？
• 等等。

在我們繼續深入架構或流程圖的具體步驟之前，我們應該明確一些關鍵屬性：

• 輸入和輸出：每一步需要什么輸入？我們在行動前需要準備什么？（這同樣適用于Agents的輸出格式）。
• 質量保證 —— 什么樣的響應才算是“足夠好”？有沒有需要人工介入的情況？我們可以設置哪些檢查來確保質量？
• 自主級別 —— 我們希望對結果的質量控制到什么程度？這個階段能處理哪些問題的范圍？換句話說，我們對模型在這個階段獨立工作的能力有多大的信任？
• 觸發器 —— 下一步我們要做什么？什么決定了下一步的行動？
• 非功能性要求 —— 我們需要的響應時間是多少？是否需要特別的業務監控？
• 故障轉移控制 —— 可能會出現哪些類型的故障（包括系統性和代理性）？我們準備了哪些應對措施？
• 狀態管理 —— 我們需要特殊的狀態管理機制嗎？我們如何檢索或保存狀態（確定索引鍵）？是否需要持久化存儲？這種狀態有哪些不同的應用（例如，用于緩存、記錄日志等）？

3.2. 代理(Agents)是什么?

在LLM本地架構中，LLM Agents是一個獨立的組件，它的工作就是調用一個LLM。

每個Agents都是LLM的一個實例，其中的prompt 包含了相應的上下文。但是，并不是所有的Agents都一樣——有些Agents會使用“工具”，而有些則不會；有些可能在流程中只被使用一次，而其他的可以被遞歸調用或多次調用，它們會攜帶前一個輸入和輸出。這種設計讓每個Agents都能根據需要靈活地執行任務，從而有效地支持整個LLM應用的運行。

3.2.1. Agents 與工具集

一些LLM Agents可以利用“工具”——這些工具是預先定義好的功能，可以用來執行數學計算或網絡搜索等操作。當Agents需要使用某個工具時，它會明確指出所需的工具及其輸入參數，隨后應用程序依照這些指令執行任務，并將結果反饋給Agents。

為了幫助大家更好地理解這個概念，我通過一個簡單的例子來看看如何實現工具調用。這個示例可以在沒有專門訓練用于調用工具的模型中工作：

你扮演的是一個助手，可以使用以下工具：

- calculate(expression: str) -> str - 用于計算數學表達式
- search(query: str) -> str - 用于在庫存中搜索項目

接到一個輸入后，你需要以YAML格式回應，其中包括以下鍵：`func`(字符串類型) 和 `arguments`(映射類型) 或 `message`(字符串類型)。

給定輸入

我們需要區分兩種代理：一種是帶有工具的代理（即自主Agent），另一種是其輸出可以直接導致執行動作的代理。

“自主Agent是具備獨立完成任務方法的代理。”

自主Agent擁有決定是否采取行動及其具體行動的權力。相比之下，非自主代理只是簡單地“處理”我們的請求（例如，進行分類），處理完成后，由我們的確定性代碼來執行具體動作，模型本身對這一過程沒有控制權。

隨著我們增加Agent在規劃和執行任務中的自主性，我們確實增強了決策能力。這看似一個非常好的解決方案，可以讓Agent顯得更“智能”。但是，這樣做的一個潛在風險是可能會降低我們對最終輸出質量的控制。

不要過分依賴全自主代理。雖然這類Agent的設計看起來簡單且很有吸引力，但如果在所有情況下或作為初步概念驗證使用，可能會在實際應用中產生誤導。自主Agent難以調試且其響應質量不穩定，因此通常不適合在生產環境中使用。

以經驗來看，在沒有詳細指導的情況下，Agent在規劃復雜過程時往往表現不佳，可能會忽略一些關鍵步驟。例如，在我們的“百科編輯者”示例中，Agent可能會直接開始寫作，而忽視了必要的準備工作。這說明Agent的性能很大程度上依賴于它們訓練的數據——簡單來說，Agent只能做得和它們訓練的數據一樣好。

與其讓一個或一組Agent自由地完成所有環節的任務，不如在流程或標準操作程序（SOP）中的特定區域限定它們的任務，特別是那些需要創造力和靈活性的環節。這種做法可以提高成果的質量，因為它既利用了流程的規范性，又保留了創新的空間。

以AlphaCodium(一個代碼生成任務增強流程很火的開源項目)為例：通過將固定的流程與不同功能的Agent相結合（包括一個專門負責重復編寫和測試代碼的新型代理），他們成功地將GPT-4在CodeContests上的準確率（pass@5）從19%提高到了44%。這個例子很好地說明結合流程控制和Agent創造力的重要性，以及這種結合如何有效提升任務執行的效果。

在我們利用工程集成來實施標準操作程序（SOP）和優化LLM本地應用的同時，我們也不能忽視LLM三角原則中的另一個核心要素：模型本身。

4. 模型

我們選用的模型是項目成功的關鍵因素。例如，像GPT-4或Claude Opus這樣的大模型雖然能夠提供更優質的結果，但在大規模應用時成本也相當高。相比之下，較小的模型雖然可能不那么“強大”，但有助于我們控制預算，而且在某些特定領域能達到我們想要的效果。因此，在考慮選擇模型時，我們必須清楚自己的約束條件和目標，才能確定哪種類型的模型最適合幫助我們達成這些目標。

并非所有的LLM都是相同的。要使模型與任務相匹配。

事實是，我們并不總是需要最大的模型；這取決于具體任務。為了找到合適的匹配，我們必須進行實驗過程，并嘗試我們解決方案的多種變體。

考慮到我們的“無經驗工人”類比——一個擁有眾多學術資質的非常“聰明”的工人可能會輕松完成一些任務，但他們可能對某些工作來說過于高資，雇用一個“更便宜”的候選人會更加具有成本效益。

在選擇模型時，我們需要根據可以接受的各種權衡來定義和評估不同的解決方案：

• 任務復雜度 — 對于簡單的任務，如生成摘要，一個小型模型就足夠了，但處理更復雜的推理任務通常需要較大的模型。
• 推理基礎設施 — 我們選擇在云端還是在端側上運行模型？模型的大小可能會限制設備配置的性能，但在云服務中這通常不是問題。
• 定價 — 我們能接受的最高價格是多少？結合業務影響和預期的使用頻率，這個投入是否劃算？
• 延遲 — 模型越大，其處理速度可能越慢。
• 標注數據 — 我們是否擁有足夠的標注數據來豐富模型，尤其是那些模型未曾學習過的信息？

在許多情況下，在我們積累足夠的“專業知識”之前，為了獲得經驗豐富的效果而支付額外成本是非常需要的——這對于LLMs也是適用的。這可以在初期階段幫助我們實現更好的性能和效果。

如果手頭沒有標注數據，一個好的策略是先使用一個更強大（也就是更大）的模型開始工作，通過這個模型來收集數據，但這個需要注意合規風險。然后，利用收集到的這些數據，我們可以通過少樣本學習或者對模型進行微調，從而進一步提升模型的性能。

4.1. 模型微調

在對模型進行微調之前，您必須考慮以下幾個方面：

• 隱私：如果您的數據中包含敏感或個人信息，必須對這些信息進行匿名化處理，以避免可能的法律責任。
• 法律、合規性和數據權利：訓練模型時可能涉及法律問題。例如，OpenAI的使用條款禁止未經許可使用其生成的內容來訓練模型。另外，根據歐盟的GDPR法規，用戶有權要求企業刪除其個人數據，這可能會引起關于模型是否需要重新訓練的法律問題。
• 更新延遲：與直接在上下文中嵌入新信息相比，重新訓練模型通常需要更多時間，因此更新的頻率可能較低。
• 開發和操作：建立一個可重復、可擴展并可監控的微調流程是至關重要的，同時需要持續評估性能。這一過程復雜且需要持續的維護。
• 成本：由于訓練過程的復雜性以及高密集的資源需求（如GPU），重新訓練模型通常代價高昂。

LLMs作為“上下文學習者”的功能，以及新模型支持更寬廣上下文窗口的能力，已經大大簡化了我們的應用實現。這意味著即使不進行模型微調，我們也能獲得很好的效果。因此，考慮到微調的復雜性，我們建議只在必要時才采用，或者盡可能避免使用微調。

另一方面，對于特定任務（例如生成結構化的JSON輸出）或特定領域的應用進行微調，可能會更有效。一個專為特定任務設計的小模型在處理這些任務時既高效又成本低，比大型LLMs要經濟得多。因此，在決定是否升級到更大規模的LLM訓練之前，評估所有相關因素是非常必要的。

請注意，即使是最先進的模型，也需要依賴相關而且結構合理的上下文數據，才能充分發揮其潛力。

5. 上下文數據

LLMs 是上下文學習的高手。只要我們提供相關任務的具體信息，LLM Agent就能夠在不經過特殊訓練或微調的情況下幫助我們完成這些任務。這讓我們可以很輕松地向它們“傳授”新的知識或技能。

當涉及到上下文數據的處理時，我們應該要向如何組織和建模手頭上的數據，并考慮如何在我們的prompt 中有效地整合這些數據。這樣一來，LLM就能更好地理解和執行任務，從而提高效率和效果。

要構建有效的上下文，我們需要在發送給LLM的提示（prompt）中包含相關的信息。通常，我們可以采用兩種類型的上下文：

• 嵌入上下文：這種上下文直接嵌入到prompt的文本中，作為信息的一部分提供。

你是<name>的得力助手，<name>在<company>擔任<role>。

• 附件上下文：這種上下文通過在prompt的開頭或結尾附加信息片段來提供。

在保持友好語氣的同時總結所提供的電子郵件。
---

<email_0>
<email_1>

我們通常使用“prompt模板”來實現這些上下文，比如使用jinja2、mustache或簡單的原生格式化字符串。通過這種方式，我們可以優雅地構建提示內容，同時保持其核心本質清晰：

# 帶有附件上下文的嵌入上下文
prompt = f"""
你是{name}的得力助手，{name}在{company}擔任{role}。

幫助我用{tone}語氣回復附加的電子郵件。
始終以以下簽名結尾：
{signature}

---

{email}
"""

5.1. 少樣本學習

少樣本學習是一個不需要大量調整模型就能教會LLMs新技能的方法。我們只需在prompt中加入一些準備好的示例，模型就能學會我們需要的格式、風格或怎樣完成任務。

比如，如果我們想讓LLM幫忙回復電子郵件，我們可以在prompt中加入幾個認為寫的好的回復示例。這樣，模型就能學到我們希望的回復結構和語氣。

通過提供多種不同的示例，模型可以更好地理解各種復雜的情況和細微的差異。因此，確保你的示例全面，能覆蓋所有可能的情況是非常重要的。

隨著應用程序的進步，你可以采取“動態少樣本學習”的策略，根據每個特定的輸入選擇最相關的示例。這種方式雖然更復雜，但能讓模型針對不同的情況得到最好的指導，從而在處理多種任務時提高性能，同時避免了成本高的大規模調整。

5.2. RAG

檢索增強生成（Retrieval Augmented Generation，簡稱RAG）是一種特別的技術，它會在LLM生成回答之前先查找相關的文檔，以此來提供更多的上下文信息。可以想象成，在LLM回答問題之前，它會先快速查閱相關的資料，這樣做可以幫助它給出更準確和更新的信息。

例如，在聊天機器人的應用中，RAG能夠自動查找并提取相關的幫助臺維基頁面，這些信息將直接用來支持LLM的回答。

這種方法讓LLM能夠依據最新獲取的信息來生成回答，這不僅確保了信息的及時更新，還減少了生成不準確或虛假信息的風險。對于那些需要最新數據或專門知識的任務，使用RAG特別有效，而且這樣做不需要重新訓練整個模型，既節約了時間也節省了資源。

例如，假設我們正在為產品開發一個在線支持聊天功能。在這種情況下，我們可以利用RAG技術從知識庫中檢索出相關的文檔，然后把這些信息提供給LLM Agent。接著，讓它根據提供的問題和文檔內容撰寫出合適的答案。

在部署RAG技術時，我們需要特別關注以下幾個關鍵點：

• 檢索機制：通常的做法是通過搜索相似的內容來找到相關文檔，有時候采用更簡單的搜索方法（例如，基于關鍵詞的BM-25搜索）可能更有效或成本更低。
• 索引數據結構：如果我們直接索引整篇文檔而不做預處理，可能會影響搜索結果的質量。因此，我們可能需要先進行一些數據準備，例如根據文檔內容制作一份問答對列表。
• 元數據：保留與查詢相關的元數據可以幫助我們更有效地篩選和引用信息（比如，只關注與用戶查詢直接相關的知識頁面）。這一額外的數據層可以使檢索過程更簡單。

5.3. 提供相關上下文

在提供信息給Agent時，關鍵是要把握一個度。提供很多信息似乎看起來非常有用，但是如果信息太多、太雜，反而可能會讓模型感到不堪重負，難以區分哪些信息是真正相關的。過多的無關信息可能會讓模型學到錯誤的東西，造成混淆甚至錯誤的判斷。

例如，當Gemini 1.5發布時，它能處理高達10M標記的數據，一些專家開始質疑這樣龐大的數據處理能力是否真的有效。盡管這種能力對某些特定場景（比如處理PDF文件的對話）很有幫助，但在需要對多種文檔進行綜合推理的情況下，它的效果還是非常有限。

因此，我們在提供信息時，應該盡量保證信息的相關性。這樣做不僅能減少模型處理無關數據時的計算負擔，還能提高任務的執行質量和效率，同時也能降低成本。選擇什么樣的信息提供給模型，直接影響到模型的表現和效果。

要提高我們提供給LLM的上下文信息的相關性，有很多有效的方法，這些方法主要涉及如何更好地存儲和管理數據。特別是在使用檢索增強生成（RAG）技術的應用中，加入一個準備數據的步驟會非常有幫助。例如，我們可以先從文檔中提取出問題和答案，然后只向LLM代理提供這些答案。這樣，Agent接收到的上下文就會更加簡潔明了。同時，使用一些算法對檢索到的文檔進行重新排序，也能優化最終的輸出結果。

“數據是LLM應用的核心驅動力。好的上下文數據能最大限度地發揮出它的潛力。”

6、總結

LLM三角原則提供了一個基礎框架，幫助我們在開發產品時發揮LLMs的功能。這個框架基于三個主要的元素：模型、工程集成、上下文數據，以及一套詳細的操作步驟（SOP）。

6.1關鍵要點

• 從明確的操作步驟開始：先模擬專家如何思考和操作，然后根據這些信息為你的LLM應用制定一份詳細的操作指南。這個指南將成為你實施其他步驟的基礎。
• 選擇合適的模型：在選擇模型時要考慮到性能和成本之間的平衡。你可以先從一個大模型開始，如果需要，以后再改用一個經過微調的小模型。
• 利用工程技術：建立一個LLM本地架構，并巧妙地利用代理來提升性能，同時確保能控制整個過程。試驗不同的提示技術，找到最適合你需求的方法。
• 提供相關上下文：合理利用上下文信息來增強學習，比如使用檢索增強生成（RAG），但要注意避免給模型提供太多無關的信息。
• 不斷迭代和實驗：通常，找到最好的解決方案需要不斷的測試和調整。推薦閱讀《從零開始構建大模型(LLM)應用》來獲得更多關于LLM開發過程的詳細指導。

通過這些方法，組織不僅能超越基本的概念驗證階段，還能開發出強大、準備好上線的LLM應用，最大限度地發揮這項技術的潛力。

6.2干貨推薦

在項目中，構建大模型應用時，以下幾款工具是非常實用且常用的：