現今LLM應用已不再侷限於單一任務，更進階的技術著重於工作流程的設計與最佳化。從代理驅動的工作流程，到狀態任務代理，再到角色委託，這些方法讓LLM能處理更複雜的任務。同時，評估LLM應用程式的效能也至關重要，離線評估和線上評估提供了不同的測試策略，從範例套件到自動化評估工具，都能幫助開發者更好地理解和最佳化LLM工作流程。
高階LLM工作流程：增強靈活性與自主性
隨著大語言模型（LLM）的持續進步與社群對新方法的探索，我們相信高階技術將變得更加普及。以下介紹的三種方法並非詳盡無遺，但希望能激發讀者在自身問題領域中思考創新解決方案。
允許LLM代理驅動工作流程
在基本LLM工作流程的討論中，任務本身使用了LLM，但工作流程仍然是傳統的管道、有向無環圖（DAG）或圖形，不涉及LLM在路由工作專案中的使用。因此，複雜性和靈活性的下一步邏輯演進是允許工作流程由LLM驅動。當你這樣做時，工作流程本身就像一個代理一樣協調和控制整體工作。
實作方法
固定任務集與路由選擇：保持可能的任務集合固定，讓工作流程代理選擇如何將工作路由到能夠正確處理它的任務。你可以透過將工作流程視為對話代理並賦予其對應於可用任務的工具來實作這一點。每當工作流程代理收到新的工作專案時，它可以選擇將其傳送到哪個任務。
任務級對話代理：除了使工作流程成為具有對應於任務的工具的對話代理之外，你還可以使任務本身成為具有專門工具的對話代理，用於處理明確定義的工作領域。這樣，工作流程真正成為了一個「代理的代理」。這裡的一個棘手部分是，任務級代理和工作流程代理仍然需要傳回特定的輸出——它們不能只是持續聊天。因此，給它們一個完成工具，以便它們可以在完成工作後提交。
動態生成任務：進一步，你可以讓工作流程代理動態生成任意任務。當工作流程確定需要執行一個任務時，它將為該任務構建一個對話代理（包括一個專門的系統訊息，概述工作的目標），並且將選擇一組被認為是滿足任務目標所必需的工具。
管理多個任務：最後，工作流程代理可以管理一個不斷增長的待辦任務列表。使用類別似於待辦列表演算法的方法，工作流程代理可以不斷優先排序和重新評估任務，並提交當前最相關的任務去執行。
狀態任務代理
到目前為止，我們將工作流程概念化為一個由任務組成的網路，這些任務負責接收、處理和轉發工作專案給後續任務。在這種情況下，一個任務不維護任何持久狀態；當接收到新的工作專案時，任務從頭開始，對先前的工作一無所知。但是，如果每個任務都被實作為一個永久與某個工作專案相關聯的代理，並且負責在需要時修改該工作專案的狀態，會怎樣呢？
示例場景
考慮這樣一個場景：工作專案是一個文字檔案，不久將包含網頁的JavaScript實作。這個文字檔案與一個程式碼編寫代理相關聯，該代理負責構建網頁程式碼，並根據外部事件在必要時更新該檔案。網站的其他部分也有其他檔案，每個檔案都有自己的關聯代理。
工作流程中的互動
在工作流程層面，有幾種方法可以與這些狀態任務代理進行互動。你可以讓工作流程代理充當協調者，向特定的任務代理傳送請求以更新其負責的資產。另一種方法是讓工作流程在建立資產時在任務代理之間建立依賴關係圖，並且隨著每個工作專案的更新，其任務代理會通知相關的任務其變更。
角色與委託
LLM為基礎的工作流程中，一個正在興起的趨勢是定義具有特定角色的代理，然後像分配給你的目標的團隊一樣委託工作給它們。我們已經提到了AutoGen。在其最簡單的用法中，AutoGen引入了兩個角色：
詳細解說
固定任務集：保持一組固定的可能任務，並讓LLM決定如何將輸入分配給這些任務。
對話式任務：不僅讓工作流程像一個對話機器人一樣運作，還讓每項任務也成為具有特定功能的對話機器人。
動態建立：讓LLM根據需求動態建立新任務，每個新任務都是一個能夠獨立運作的對話機器人。
多工管理：讓LLM管理多項平行任務，能夠根據情況變化動態調整優先順序。
狀態式處理：每個任務維護自己的狀態，能夠持續修改自己的輸出，直到達到最終結果。
角色定義與委託：定義不同角色的Agent，並根據需要委託給他們，就像管理一個團隊一樣。
這些進階的工作流程技術，讓根據LLM的系統能夠展現出更強大的自動化與智慧決策能力，不僅能夠提高效率，也能更好地適應複雜多變的實際應用場景。
此圖示展示了傳統管道與LLM驅動的工作流程之間的差異，以及LLM驅動下的不同階段。
LLM 工作流程的進階應用與挑戰
在探討 LLM（大語言模型）技術的過程中，我們面臨著一個重要的取捨：追求更廣泛的通用性或是針對特定領域的最佳化。雖然 LLM 比傳統的機器學習模型更具通用性和強大功能，但它們尚未達到完全人工通用智慧（AGI）的水平。因此，我們需要在通用性和特定領域的能力之間做出選擇。本章將探討如何利用工作流程將複雜目標分解為更小的任務，並結合傳統軟體和 LLM 解決方案來實作這些目標。
AutoGen 與 CrewAI：工作流程協調的新框架
AutoGen 提供了一種新的方法，透過建立對話代理（如 Assistant 和 UserProxy）來實作工作流程的自動化。Assistant 遵循與上一章中介紹的對話代理相同的設計模式，即具有執行背景工具選項的對話迴圈。UserProxy 則扮演人類使用者的代理角色，根據實際使用者指定的目標與 Assistant 進行互動，並在 Assistant 完成工作時提供糾正和建議。
AutoGen 的另一個重要元件是群聊管理器（group chat manager），它可以協調多個對話代理，每個代理都有自己的角色、系統訊息和工具。當向管理器提出問題時，它會根據需要將請求委派給適當的代理。
另一個類別似的框架是 CrewAI，它允許使用者組建具有不同角色、目標、背景故事和工具的代理團隊。這些代理可以被安排成不同的流程，如順序、層次或共識模式，以實作整體目標。
自行建立工作流程：從零開始的實踐
在眾多新框架中選擇合適的工具可能令人困惑。與其依賴他人的框架，不如嘗試從零開始建立自己的工作流程。一個有趣的起點是實作 UserProxy 的概念。您可以定義一個目標（如建立一個 Python 命令列數學導師），然後建立兩個對話代理：CodeAssistant 和 UserProxy。CodeAssistant 具備多種工具（如寫入檔案、執行測試等），但不知道整體目標；UserProxy 則具有明確的系統訊息，概述了整體目標，但沒有任何工具。
內容解密：
本章節主要介紹了 LLM 工作流程的新框架和實踐方法，包括 AutoGen 和 CrewAI，以及如何從零開始建立自己的工作流程。這些新框架和方法為實作複雜目標提供了新的可能性，但也需要注意簡單性和可靠性。
LLM 應用的評估
在下一章中，我們將探討如何評估 LLM 應用的表現。這是一個重要的主題，因為建立工作流程只是第一步，確保其正確性和可靠性才是真正的挑戰。我們將探討評估 LLM 應用的方法和工具，以幫助您更好地理解和最佳化您的 LLM 工作流程。
評估大語言模型應用程式
GitHub Copilot 可以說是第一個使用大語言模型（LLM）的工業級應用程式。作為第一個吃螃蟹的人，我們的一些決定在事後看來可能顯得有些愚蠢，但有一件事情我們做對了，那就是我們如何開始。Copilot 程式碼函式庫中最古老的部分不是代理程式、提示（prompts）、使用者介面，甚至不是將應用程式設定為 IDE 擴充套件的樣板程式碼。我們寫的第一段程式碼是評估程式碼，而正是這一點讓我們能夠快速成功地開發出其他功能。這是因為對於每一次的變更，我們都可以直接檢查它是否是朝正確方向邁出的一步，是一個錯誤，還是一個好的嘗試但沒有太大的影響。
評估框架的主要優勢
評估框架對於 LLM 應用程式的主要優勢在於它將指導所有未來的開發。根據應用程式和專案在其生命週期中的位置，不同型別的評估可能可用且合適。這裡有兩大類別：離線評估和線上評估。
離線評估與線上評估
- 離線評估 是對獨立於應用程式實際執行的範例案例進行評估。它不需要真實使用者，甚至在很多情況下不需要一個端對端的工作應用程式，因此通常是專案生命週期中首先實施的評估。
- 線上評估 則是在真實世界中測試應用程式，直接在使用者身上測試想法。線上評估的風險較高，因為你需要確保你的想法不會嚴重損害使用者經驗，而且你需要足夠的使用者來獲得足夠清晰的回饋。
我們究竟在測試什麼？
在探討離線和線上評估之前，我們需要問自己一個基本問題：我們究竟在測試什麼？評估可以針對三件事情：
- 你使用的模型
- 你與模型的個別互動（即你的提示）
- 許多這樣的互動如何整合到你的整體應用程式中
測試策略
思考一下代表應用程式一次執行的迴圈，就像第四章討論的那樣。在傳統的軟體測試中，嘗試測試整個互動（類別似迴歸測試）和最小的建構塊（類別似單元測試）都是有益的。許多應用程式工作流程只有一次模型呼叫，因此這種區分並不是非常有意義。但對於那些具有迭代呼叫的大型迴圈的應用程式，你需要設計一個測試框架，透過劃分迴圈的特定部分並宣告「這是我現在要測試的！」。
重點記錄資訊
在所有測試中，記錄總延遲和 token 消耗統計資料。雖然它們通常不是評估的主要焦點，但它們很容易被評估，你會想知道這裡的任何重大影響。
離線評估
離線評估套件的複雜度範圍很大。我們發現從簡單的開始是有用的。
範例套件
當你寫下你的提示的第 0 版時，你可能會開啟一個 LLM 聊天視窗，或者你可能有一個完成遊樂場環境，在那裡你可以嘗試一兩個範例。這不是可擴充套件的，但有一個可擴充套件的版本是非常有用的：範例套件。範例套件有一個簡單的設定，由三個元件組成：
- 一組 5 到 20 個輸入範例，用於你的應用程式或其核心步驟之一。
- 一個指令碼，將你的應用程式的提示生成應用於每個範例，並要求模型完成，將組合的提示和完成輸出為檔案。
- 一種方法來觀察這些檔案之間的差異，例如，將它們提交到你的儲存函式庫並檢視 git diff。
範例套件與測試套件的不同
範例套件不像軟體測試意義上的測試套件（儘管它以後可能會演變成一個）。你不會有自動化的方式知道任何變化是改進還是倒退。相反，你必須自己檢查差異，並決定是否認為它們是改進或倒退。
# 簡單範例：建立範例套件
import os
# 定義輸入範例
examples = [
"example1",
"example2",
# ...
]
# 定義模型呼叫函式
def call_model(prompt):
# 這裡實作模型呼叫邏輯
pass
# 對每個範例生成提示並取得模型輸出
for example in examples:
prompt = generate_prompt(example) # generate_prompt 需要自行實作
output = call_model(prompt)
with open(f"{example}.txt", "w") as f:
f.write(output)
內容解密：
- 定義輸入範例：首先，我們需要定義一系列的輸入範例，這些範例應該涵蓋預期場景的多樣性。
- 模型呼叫函式：
call_model函式代表對 LLM 的呼叫，這需要根據實際使用的模型 API 進行實作。 - 生成提示與輸出：對每個範例，使用
generate_prompt函式生成提示，然後呼叫模型取得輸出，最後將輸出寫入檔案。 - 比較差異：透過比較不同版本之間的輸出檔案（如使用
git diff），可以觀察到變更的效果。
評估大語言模型應用的挑戰與方法
在開發涉及大語言模型（LLM）的應用程式時，評估其效能是一項艱鉅的任務。傳統的軟體開發評估方法在這裡並不完全適用，因為LLM的輸出具有不確定性和多樣性。本篇文章將探討評估LLM應用程式的挑戰，以及如何建立有效的評估機制。
建立範例集的優勢
建立範例集（example suite）是評估LLM應用程式的第一步。範例集是一組用於測試LLM應用程式的輸入範例和預期輸出。透過建立範例集，開發者可以在早期階段就開始測試和評估LLM的效能。
範例集的兩大優勢
- 早期啟動：開發者可以在確定第一批提示（prompts）時就開始建立範例集，無需等待輸出結果的評估。
- 持續改進：隨著對範例集的熟悉，開發者可以觀察到不同提示方案的效果，並根據典型的完成情況缺陷調整提示。
實踐中的範例集
在GitHub的一個專案中，開發者需要對Pull Request（PR）進行摘要。為此，他們收集了數十個PR範例，並手動檢查了摘要結果。透過調整提示，例如新增「詳細」一詞或限制輸出段落，開發者能夠快速觀察到效果並改進提示。
程式碼實作與評估
# PR摘要範例程式碼
def summarize_pr(pr_text):
# LLM呼叫以生成摘要
summary = llm.generate_summary(pr_text)
return summary
# 調整提示以獲得更好的摘要
def improved_summarize_pr(pr_text):
detailed_summary = llm.generate_summary(pr_text, detail_level="detailed")
return detailed_summary
#### 內容解密：
此段程式碼展示瞭如何使用LLM生成PR摘要。`summarize_pr`函式呼叫LLM生成摘要，而`improved_summarize_pr`函式則透過新增「詳細」層級引數來改進摘要結果。這種調整使得開發者能夠根據需求獲得更合適的摘要。
從範例集到評估工具
當範例集擴大到數百或數千個範例時，開發者需要一個自動化的評估工具（evaluation harness）來評估LLM的效能。這需要解決兩個主要問題：
- 取得範例問題：開發者需要找到或創造大量的範例問題。
- 評估應用程式的解決方案：開發者需要自動化評估LLM對這些問題的解決方案。
取得範例的方法
- 現有資料：利用已存在的資料，例如使用者填寫的表單資料。
- 專案資料：收集專案過程中產生的資料。
- 創造資料：手動創造範例資料。
複雜互動架構的評估
對於涉及多次LLM呼叫和互動的複雜架構，評估變得更加困難。開發者可以採取以下兩種策略：
- 評估單次對話：使用預設的對話指令碼（canned conversations），評估每次LLM回應的效能。
- 模擬使用者互動：利用LLM模擬使用者的回應，以測試整個互動流程。
Plantuml評估流程
離線評估的挑戰與資料採集策略
在開發人工智慧（AI）應用程式時，特別是那些根據大語言模型（LLM）的應用，評估其效能是一個至關重要的步驟。離線評估（Offline Evaluation）是一種在實際佈署前評估模型效能的方法，但它面臨著一個基本挑戰：如何獲得足夠且相關的測試資料。
資料來源的選擇
通常，開發者可以利用現有的公開資料集來進行評估。然而，這些資料集往往與實際應用場景不完全相同。例如，GitHub Copilot 的原始問題是「使用者接下來會輸入什麼？」為瞭解決這個問題，開發團隊採取了以下步驟來生成樣本：
- 從一個開源倉函式庫中選取一個程式碼檔案，然後從該檔案中選取一個函式。
- 移除該函式的主體，模擬使用者寫到該函式實作前的狀態。
- 詢問 GitHub Copilot 接下來應該輸入什麼。
這種方法的優點是可以生成大量的樣本，但缺點是生成的樣本與實際問題不完全匹配。例如，整個函式主體的長度通常大於 Copilot 建議的典型程式碼塊。
自建資料來源的挑戰
如果現有的資料來源不足以滿足評估需求，開發者可能需要建立自己的資料來源。一個顯而易見的方法是利用應用程式自身的執行資料。然而，這種方法有幾個缺點：
- 資料需要等到第一個原型佈署後才開始累積。
- 應用程式的重大更新可能使之前的資料變得過時。
- 收集使用者遙測資料需要遵守嚴格的資料保護和隱私法規。
- 應用程式互動可以提供良好的問題示例，但不一定能提供最佳的解決方案示例。
生成樣本的替代方案
在某些情況下，開發者可以利用 LLM 自身生成樣本。這種方法在某些場景下效果很好，尤其是當可以從解決方案出發來生成問題時。或者，如果不需要「黃金標準」解決方案，那麼生成情境是 LLM 的強項。
生成樣本的階層式方法
- 請求 LLM 生成一系列主題，或提供一個主題列表。如果問題有多個方面可以組合，可以利用組合爆炸來生成大量主題。
- 如果需要比主題更多的樣本，可以請求 LLM 為每個主題生成多個樣本。這種方法通常比重複請求 LLM（使用溫度設定大於 0）生成多個選項更能產生多樣化的結果。
風險與挑戰
利用 LLM 生成樣本存在一些風險，例如生成的樣本可能過於簡單或不正確。此外，如果用於測試的 LLM 與生成樣本的 LLM 是同一個模型，那麼可能會導致評估結果的偏差。
內容解密：
本段落主要闡述了在進行離線評估時，如何採集足夠且相關的測試資料。開發者可以利用現有的公開資料集、自建資料來源或利用 LLM 生成樣本。每種方法都有其優缺點，需要根據具體情況選擇最合適的方法。同時，需要注意潛在的風險和挑戰，例如生成的樣本可能過於簡單或不正確，或評估結果的偏差等。
離線評估資料來源選擇流程
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title LLM高階工作流程與評估策略
package "系統架構" {
package "前端層" {
component [使用者介面] as ui
component [API 客戶端] as client
}
package "後端層" {
component [API 服務] as api
component [業務邏輯] as logic
component [資料存取] as dao
}
package "資料層" {
database [主資料庫] as db
database [快取] as cache
}
}
ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取
note right of api
RESTful API
或 GraphQL
end note
@enduml
此圖示展示了在進行離線評估時，選擇合適的資料來源的流程。開發者可以根據是否存在現成資料集以及是否能夠自建資料來源來決定採用哪種方法。最終，所有路徑都匯聚到評估模型效能的步驟。