智慧體改進迴圈中的人類判斷

AI智慧體在反映團隊長期積累的知識和判斷時表現最佳。然而，許多組織的關鍵知識並非以文件形式存在，而是隱藏在員工的頭腦中，這就是隱性知識。為了將這些隱性知識融入智慧體，需要建立一個包含領域專家輸入的改進迴圈。

本文以一家金融服務公司的交易員助手構建為例，生動展示瞭如何將人類判斷融入智慧體開發的每個環節。該智慧體的目標是自動回答交易員關於市場資料的問題。傳統流程中，交易員需向資料科學團隊提問，資料科學家編寫SQL查詢並返回結果。利用LLM強大的SQL生成能力，這一工作流可以自動化：交易員能更快獲得響應，資料科學家也能解放出來專注於更有價值的工作。但要使系統可靠執行，智慧體必須理解金融領域的隱性規則（如“今日敞口”或“近期波動率”的解讀）以及資料庫的實際情況（哪些表是權威的，哪些查詢模式容易出錯）。這些都需要與領域專家協作才能獲得。

智慧體由多個元件構成，每個元件都可以透過人類判斷得到改進。首先，工作流設計：雖然LLM能自主規劃行動，但在高風險場景中，使用確定性程式碼定義部分工作流可降低延遲、節省token並確保關鍵步驟執行。例如，在交易員助手中，允許LLM生成SQL查詢，但新增程式碼強制驗證結果是否符合風險與合規要求，這需要風險與合規專家的輸入。其次，工具設計：開發者需實現工具並配置名稱、引數和描述，這些會影響LLM的呼叫決策。交易員助手的工具可能包括資料庫schema檢查、查詢執行和文件檢索。一個關鍵權衡是靈活性vs.控制：通用的execute_sql步驟允許靈活查詢但風險較高，引數化查詢工具更安全但能力有限。需要執行評估來確定績效和風險特徵。第三，上下文工程：早期智慧體通常只給一個系統提示和工具定義，而業界已轉向在初始階段提供更豐富的上下文。例如，Anthropic的Skills標準允許團隊預先策劃文件、示例和領域規則，執行時讓智慧體按需獲取。這使智慧體能利用更多知識而不使系統提示臃腫。上下文工程也涉及在任務推進過程中如何演進LLM呼叫中的資訊。人類利益相關者對輸出和評估分數的反饋會影響端到端的上下文工程設計。

接下來，我們來看如何將人類判斷融入智慧體的改進迴圈。LangChain與數百家組織合作的經驗表明，最成功的團隊遵循緊密的迭代迴圈：快速構建智慧體，部署到生產或類生產環境，收集每一步的資料來指導改進。快速迭代至關重要，因為決定智慧體行為的是LLM的即時推理而非程式碼，只有將智慧體置於使用者面前才能收集到成功所需的資料。改進迴圈包括三個階段：實現第一個版本、上線後監控並收集生產資料、實現並測試改進版本。

在進入具體階段前，需要強調一個貫穿整個開發生命週期的原則：人力時間高回報的關鍵在於自動化評估，且這些評估必須與人類判斷對齊。團隊應讓人類幫助設計和校準自動化評估器，而非手動審查大量輸出。LangSmith的Align Evaluator功能提供了使用者介面，使用精心挑選的示例和主題專家反饋來校準LLM作為裁判的評估器。這對於任何旨在模擬非開發者利益相關者判斷的評估器都推薦使用。

具體到交易員助手的開發階段，工程師首先應建立少量用例場景和期望行為作為測試用例，確認核心任務正確。隨後與產品經理和主題專家協作，構建更全面的測試套件。使用LangSmith的資料集功能手動建立ground truth資料集，包含自然語言問題與正確答案的配對，以及好的SQL示例。開發過程中利用評估功能執行測試，LangSmith UI允許技術和非技術成員檢視註釋結果。透過手動測試中遇到的有趣案例擴充資料集，逐步自動化反饋迴圈，確保在v1釋出前擁有全面的測試套件。

部署後，需要確保可靠性並快速識別問題。傳統滿意度調查衡量的是使用者說的而非實際行為，LLM作為裁判的評估器提供了更穩健的方法。在LangSmith中設定線上評估器，自動檢測使用者沮喪情緒並標記相關互動供審查。團隊的某個成員可以調查trace，決定問題是bug、知識缺口還是工作流弱點。例如，設定自動程式碼檢查來檢測緩慢或危險的SQL查詢，以及LLM作為裁判的評估器來檢測使用者不滿。

總之，透過將人類判斷轉化為自動化評估，團隊可以在減少人工審查負擔的同時，持續、廣泛地測試智慧體。LangSmith的Align Evaluator功能正是實現這一目標的關鍵工具。最終，透過不斷迴圈這一改進流程，智慧體將逐步吸收團隊的知識和判斷，實現更高的效能與可靠性。