使用 AWS 上的 LangSmith 評估深度智慧體

本文由 LangChain 合作伙伴負責人 Karan Singh 共同撰寫。

驗證 AI 智慧體在生產前的行為是應用 AI 中最棘手的問題之一。智慧體是非確定性的、多步驟的，早期步驟的錯誤可能會影響下游結果。一次錯誤工具呼叫可能導致整個工作流出現問題。AWS 上的 LangSmith 提供了評估框架，幫助提前發現這些問題、在生產中跟蹤它們，並在整個生命週期中持續改進智慧體的可靠性。

本文結合了 LangChain 在評估深度智慧體方面的工作和 Anthropic 關於揭秘 AI 智慧體評估的指南，形成了一篇實用教程。您將學習：1）應用五種深度智慧體評估模式；2）使用 pytest 和 LangSmith 構建離線評估；3）為生產配置線上監控。示例中使用基於 Amazon Bedrock 的文本到 SQL 深度智慧體，覆蓋從開發到生產的完整生命週期。

Amazon Nova 2 Lite 模型

Amazon Nova 2 Lite 是 Amazon Bedrock 中提供的一種快速、高價效比的推理模型。它支援可配置預算級別（低、中、高）的擴充套件思考，可接受文本、影像、影片和文件輸入，上下文視窗達 100 萬 token。Nova 2 Lite 在指令遵循、函式呼叫和程式碼生成方面表現出色，非常適合本文中文本到 SQL 智慧體這樣的智慧體工作負載。

智慧體評估的結構

評估是對 AI 系統的測試：給 AI 輸入，應用評分邏輯對其輸出進行評分，並衡量成功與否。對於大語言模型（LLM）呼叫，這很直接。對於智慧體，每個元件都變得更加複雜。

**關鍵術語**：

• **任務**：具有定義輸入和成功標準的單個測試。例如，“有多少客戶來自加拿大？”期望答案是 8。
• **試驗**：對任務的單次嘗試。由於模型輸出是非確定性的，每個任務執行多次試驗可產生更可靠的結果。
• **評分器**：對智慧體表現的某些方面進行評分的邏輯。一個任務可以有多個評分器，每個評估不同維度。
• **記錄**：試驗的完整記錄，包括工具呼叫、推理步驟、中間結果和互動。在 LangSmith 中，這是完整軌跡，可用於除錯。
• **結果**：試驗結束時環境的最終狀態。智慧體可能說“答案是 8”，但結果是它是否真的對資料庫執行了正確的 SQL 查詢。
• **評估框架**：端到端執行評估的基礎設施。它提供指令和工具，併發執行任務，記錄步驟，對輸出評分，並聚合結果。
• **評估套件**：旨在衡量特定能力或行為的任務集合。

為什麼智慧體評估更難

三個特性使智慧體評估與直接評估 LLM 輸出有本質不同：

• **非確定性**：智慧體行為在不同執行間變化。同一任務可能 90% 成功、10% 失敗。單一的透過/失敗結果提供的資訊有限。需要多次試驗來估計實際效能。兩個有用指標：pass@k（衡量 k 次嘗試中至少一次成功的機率）和 pass^k（所有 k 次試驗都成功的機率）。當一次成功足夠時使用 pass@k；當一致性重要時使用 pass^k。
• **錯誤傳播**：在多步驟智慧體中，第 3 步的錯誤可能級聯到後續步驟。文本到 SQL 智慧體如果早期錯誤識別了 Schema，將構建錯誤的 JOIN，導致最終答案錯誤。僅評估最終輸出會遺漏問題發生的位置。
• **創造性解決方案**：前沿模型有時會找到評估設計者未曾預料到的有效方法。

可評估的內容

對於智慧體執行，有三個可測試的類別：

• **軌跡**：呼叫的工具序列和生成的引數。是否探索了 Schema？是否在執行前使用了 sql_db_query_checker？
• **最終響應**：返回給使用者的最終輸出。答案是否正確？格式是否良好？
• **其他狀態**：智慧體產生的其他工件，如寫入的檔案、建立的 TODO 計劃、儲存的中間結果。

AI 智慧體的評估模式

智慧體評估通常組合三種型別的評分器，有效設計的關鍵是為用例選擇正確的組合。

**程式碼基礎評分器**：使用確定性邏輯驗證特定條件：字串匹配、正規表示式、二進位制透過/失敗測試、靜態分析、工具呼叫驗證、記錄分析（輪次、token 使用）。優點：快速、廉價、客觀、可重複、易於除錯。缺點：對於與預期模式不完全匹配的變化可能過於嚴格。

示例：驗證是否呼叫了工具：

tool_names = [tc["name"] for tc in tool_calls]
assert "sql_db_query" in tool_names, "Agent must execute sql_db_query"

**模型基礎評分器（LLM 作為裁判）**：使用另一個 LLM 評估智慧體的輸出。方法包括基於規則的評分、自然語言斷言、成對比較、多裁判共識。優點：靈活、可擴充套件、捕捉細微差別，處理開放式任務和自由格式輸出。缺點：非確定性、比程式碼更昂貴，需要與人類評分器校準。

示例：對複雜分析答案評分：

rubric = """Score the agent's answer on these dimensions (0.0 to 1.0):
1. correctness: Does it identify the right top employee? (Jane Peacock)
2. completeness: Does it include revenue broken down by country?
3. clarity: Is the answer well-formatted and easy to understand?
Return JSON: {"correctness": float, "completeness": float, "clarity": float}"""
judge_response = model.invoke(rubric.format(answer=answer))
scores = json.loads(judge_response.content)

LangSmith 的 Align Evaluator 功能可幫助將 LLM 作為裁判的評估器與人類專家反饋進行校準，可用於資料集上的離線評估或線上評估。

**人工評分器**：人類評分器（主題專家評審、眾包判斷、抽樣檢查）通常被視為主觀質量評估的金標準。但相比程式化評估，成本高、速度慢，但對於校準模型基礎評分器至關重要。建議：最初用專家人工判斷校準 LLM 裁判規則，然後定期進行人工審查，確保自動評分器沒有漂移。

**組合評分器的實際建議**：儘可能使用確定性評分器，在需要細微差別時使用 LLM 評分器，使用人類評分器進行校準。對於文本到 SQL 智慧體：程式碼基礎評分器檢查是否呼叫了 sql_db_query、答案是否包含“8”、是否執行了 DML 語句（INSERT, DELETE）；LLM 作為裁判處理複雜查詢（分析是否正確、完整、結構良好）；人類評分器進行定期抽查。

能力評估與迴歸評估

並非所有評估目的相同：

• **能力評估**：問“這個智慧體擅長什麼？”應針對當前困難的任務，為團隊提供進步階梯。從較低透過率開始，逐步提高。
• **迴歸評估**：問“智慧體還能處理以前的任務嗎？”應接近 100% 透過率。下降表示出了問題。

隨著智慧體成熟，達到高透過率的能力評估可以升級為迴歸評估。曾經衡量“能否做到”的任務現在衡量“是否還能可靠地做到”。

評估深度智慧體

深度智慧體（使用規劃、工具使用、檔案系統後端和漸進式上下文載入來處理複雜多步驟任務的系統）打破了傳統假設：每個測試用例可透過相同應用邏輯執行並由相同評估器評分。LangChain 在過去幾個月中釋出了四個基於深度智慧體架構的應用，並識別了四種廣泛適用的模式。

**模式 1：每個資料點的自定義測試邏輯** 傳統 LLM 評估對每個資料點相同對待：透過相同應用執行，由相同評估器評分。深度智慧體打破了這一假設。每個測試用例可能有自己的成功標準，這些標準可能涉及對智慧體軌跡和狀態的具體斷言，而不僅僅是最終訊息。

考慮文本到 SQL 智慧體：“有多少客戶來自加拿大？”只有一個正確答案（8），可透過字串匹配檢查。但“哪個員工創造了最多收入，來自哪些國家？”需要 LLM 裁判評估正確性、完整性和清晰度，因為有效答案的格式差異很大。

LangSmith 的 Pytest 整合支援此模式。可以對每個測試用例的智慧體軌跡、最終訊息和狀態做出不同斷言：

@pytest.mark.langsmith
def test_canada_customer_count(sql_agent):
    result = sql_agent.invoke({"messages": [{"role": "user", "content": "How many customers are from Canada?"}]})
    answer = result["messages"][-1].content
    assert "8" in answer

@pytest.mark.langsmith
def test_revenue_by_employee(sql_agent, model):
    result = sql_agent.invoke({"messages": [{"role": "user", "content": "Which employee generated the most revenue?"}]})
    scores = llm_judge(model, result["messages"][-1].content)
    assert scores["correctness"] >= 0.5

**模式 2：單步評估** LangChain 大約一半的深度智慧體測試用例是單步評估：智慧體在特定輸入後立即決定做什麼？這對於驗證單個決策點特別有用。是否呼叫了正確的工具和引數？迴歸通常發生在單個決策點，而非整個執行序列。對於文本到 SQL 智慧體，單步評估可能驗證智慧體的第一個動作是探索資料庫 Schema（呼叫 sql_db_list_tables 或 sql_db_schema），而不是直接編寫查詢。

@pytest.mark.langsmith
def test_agent_calls_sql_tools_first(sql_agent):
    result = sql_agent.invoke({"messages": [{"role": "user", "content": "How many customers are from Canada?"}]})
    tool_calls = extract_tool_calls(result["messages"])
    tool_names = [tc["name"] for tc in tool_calls]
    sql_tools = {"sql_db_list_tables", "sql_db_schema", "sql_db_query", "sql_db_query_checker"}
    assert sql_tools & set(tool_names), "Agent must use SQL tools"

單步評估類似於單元測試：快速、聚焦、token 高效。

**模式 3：完整智慧體回合** 單步評估測試單個決策，而完整智慧體回合顯示整體情況。在單個輸入上端到端執行智慧體並進行評估。

（原文截斷，但上述內容已涵蓋主要模式。）

透過結合這些模式，團隊可以構建可靠的評估流程，確保深度智慧體在生產中表現穩定。