背景：Elastic 的 agent 版圖與評估難題
Elastic 是 Elasticsearch 與 Kibana 的開發商，許多企業把資料放進 Elasticsearch，再套用到各自的場景。Stack Overflow、Uber、GitHub、Tinder 等服務，背後都用到這類搜尋與檢索工具。Elastic 內部則在 Elasticsearch 之上建構可觀測性（observability）與安全（security）產品，並替使用者打造可重用的 AI agent 工具。
在安全領域，有一個名為 attack discovery 的功能，它讓 AI agent 從大量日誌中找出可能的攻擊，取代人工逐筆翻找。這類場景之所以關鍵，是因為像某個大型銀行客戶，為了網路安全用途，把 PB 級（petabytes）的資料持續攝取進 Elastic。當資安事件發生，他們得在這些日誌中篩選、擷取出正確資訊。另一個案例是企業聊天機器人，讓使用者以自家存放在 Elasticsearch 的專有資料為基礎，打造問答系統。
問題在於，這些 agent 上線後必須反覆測試、估計回應品質，並在每次改動時防止效能回歸，但又不能全部仰賴人工。這就帶出評估（evaluation）的需求，也帶出 Elastic 後來的架構轉變。
早期，Elastic 各團隊各自為政。安全 AI agent 團隊自行建立資料集與評估器，企業聊天機器人團隊也做一套，追蹤資料存放位置不同，評估也在不同地方執行。安全團隊與資安分析師、研究員合作，設計出新型態的攻擊情境，再測試 agent 能否辨識；他們同時準備大量良性（benign）情境，並使用 precision 與 recall 來比對警示 ID，避免 attack discovery 產生幻覺。此外還用上相似度分數、factuality 分數，以及 MITRE tactics——那是一套資安領域用來分類攻擊型態的戰術分類法，用來確認模型不會胡亂生成不存在的戰術。
企業聊天機器人團隊則完全不同。他們建立的是問答型測試案例，關注檢索與回應品質，使用 precision、recall、factuality，另加上回應相關性與完整性。他們還特別在意 ES QL 的語法正確性。ES QL 是 Elastic 自家開發的查詢語言，同類的還有 KQL 與 Painless script。當使用者要求產生 ES QL 查詢時，agent 必須輸出正確語法，團隊甚至讓 agent 能呼叫工具來格式化或檢查查詢。這對聊天機器人團隊很重要，對安全團隊則不是重點。
追蹤：評估的基礎
Susan Chang 強調，追蹤（tracing）是整個評估體系的地基。Elastic 大量使用 LangSmith 與 Phoenix，因為 Elastic 本身長期具備可觀測性能力。由於產業變動極快，團隊刻意試用不同工具，尋找最貼合自身場景的選項。
追蹤的價值在於看見 AI agent 的中間行為。假設你用 LangGraph 設計了一個 agent，當使用者問「能不能幫我解決某個 Elasticsearch 索引的問題」，agent 底下可能先跑向量搜尋、再跑關鍵字搜尋，最後才給出答案。若你只看最終結果，你不會知道它其實查錯了資料庫、或選錯了工具，只看到最後數字不對。有了逐層追蹤，才能針對特定工具呼叫各自評估，也才知道該從哪裡修正。
LangSmith 的 Add to Dataset 功能特別受到青睞。當使用者對回應按下不喜歡，或察覺某個回應出錯，就能把該案例加入測試資料集，日後每次評估都拿來驗證 agent 是否已經改善。在某些產業，完整記錄所有資料並不可行，團隊只能仰賴代理訊號（proxy signal）或明確、隱性的回饋，這與推薦系統等機器學習場景中使用點擊流資料的做法相通。
共享評估框架的運作與構建模組
為了擺脫每個團隊從零重寫評估的負擔，Elastic 把不同團隊的評估方式整合成一套共享框架，讓新專案能快速長出完整評估。舉例來說，團隊做了一個 AI 規則生成功能：規則是 YAML 或 JSON 設定檔，有固定結構，但使用者未必懂，於是讓 agent 接受自然語言指令，例如「幫我建立一條偵測週末登入這類異常行為的規則」。有了共享框架，評估能快速套用，力氣就能留給其他工作。
共享工具包的主要構件包括：匯入不同型態的資料集，並以標準化 schema 統一；trace-based 評估器，處理 token 用量、延遲、工具呼叫、效能等可觀測性指標；共享的 RAG 評估器，RAG 指的是檢索增強生成，先從資料庫取回相關內容再交給模型生成答案；以及各團隊所需的客製評估器。一次評估執行的流程大致是：資料集帶著輸入與輸出，呼叫任務或執行 agent，跑程式化評估器、LLM-as-a-judge 與 trace-based 評估器，這些會依用例客製，最後把結果存回 Elastic 或其他工具。
其中一項值得注意的工程轉折，是程式語言的選擇。Elastic 的生產程式碼大量以 TypeScript 撰寫，但資料科學團隊原本慣用 Python 寫評估、載入資料集、呼叫對應的 agent。這造成評估與生產環境之間的落差。團隊後來與軟體工程師合作，並借助 Claude、Cursor 等工具，把大量工具從 Python 轉到 TypeScript，讓評估更貼近實際生產。他們採用 Playwright——一套執行測試與 API 的框架——並在其上客製出名為 Scout 的系統，負責載入資料集、執行以 TypeScript 實作的 agent、收集結果並評估，也能在本機執行並在終端機輸出分數。
評估方法上，Elastic 把 LLM-as-a-judge 與規則式、程式化評估混搭使用。LLM-as-a-judge 是用語言模型評估另一個語言模型的輸出，適合開放式任務、語氣與品牌風格、連貫性等模糊場景，還能用思維鏈自我解釋評分理由。但它的缺點是粒度不足、同一模型跨次執行結果可能不一致，也難以判斷產品 ID 這類內部資訊是否存在，因此需要與程式化評估互補。
規則式或程式化評估則用 Python、TypeScript 直接檢查生成程式碼是否可執行、以啟發式方法擷取實體、確認是否輸出正確產品 ID、驗證語法。它的優點是沒有模糊空間、成本低、速度快，不必每次都呼叫模型；缺點是面對大段自然語言與較大問題空間時不易擴展，也較弱於開放式任務。因此兩者互補最理想。另外，團隊還發現模型家族偏誤的問題：若用同一家族的模型，例如用 Llama 評估 Llama，會傾向認為 Llama 模型表現較好。Meta 與 CrowdStrike 也有類似發現。Anthropic 於今年一月發布的部落格，也印證了 Elastic 內部一年多來累積的許多觀察。
哪些無法被抽象
共享框架雖然收斂了大量重複工作，但有些東西無法抽象，必須由各團隊自行負責。
首先是客製資料集的建立。在資安用例中，仍需要資安分析師與研究員提供使用者視角；若 agent 的目標是幫分析師更快找出攻擊，好不好用必須由真正的終端使用者判斷，而非軟體工程師或資料科學家。這種領域專業無法被自動化取代。其次是產品輸入：與產品團隊合作定義什麼是正向、負向行為，哪些情況算小錯，再把這些納入評分機制。回歸（regression）對不同 agent 的意義也不同。例如安全 agent 在某次更新後，即使餵給它全是良性資料，也開始誤判有人正在攻擊環境，團隊就得調整評估來捕捉這類行為。這一切都充滿迭代性，很難事先預測所有正負案例。
最後是校準（calibration）。若評估器本身不穩定，例如同一情境跑三次卻給出不同評價，那產出的結果就是垃圾。校準高度依賴領域專業與各團隊自身經驗，無法放進共享框架裡。
經驗教訓與限制
Susan Chang 提出的經驗，多半圍繞先建置、後整合的現實。若重來一次，她會更早開始溝通，並以合作與整合為目標，而不是各團隊各做各的、臨時用 Okta 把對方加入團隊。早期也別跳過產品與領域專業，雖然用 LLM 生成大量測試資料能擴充規模，但仍要錨定在真實使用者需求上。
起步時，評估資料集可以先從 20 到 50 筆樣本開始，之後再擴大。Eugene Yan（現於 Anthropic）也曾提過類似做法。初期採用哪個追蹤工具不必過度糾結，Elastic 早期用 LangGraph 建 agent，自然搭配 LangSmith，其他團隊用 Phoenix 或 Elastic Observability，這種分歧可以接受，重點是開始累積。當 agent 數量增加，就必須認真考慮整併工具與評估，否則會出現太多各自為政的評估，帶來後續痛苦。Elastic 也做過 agent 層級的整合，把原本要在下拉選單切換的多個安全 agent，收斂成能自動辨識對話對象的流程。
在評估結果如何決定是否發布方面，Elastic 的做法是把 precision、recall、factuality 等細項分數，依重要性加權，合成單一分數，再設門檻，要求不只改善、還要高於門檻。決策者通常只看這個合成分數，但團隊仍會檢視細部指標，並在發布前手動試用產品做最後確認。
Elastic 也公開部分評估結果與對外建議，尤其在安全領域，但並非全部。這麼做一方面接受外部檢視，一方面也證明評估確實有助於向組織內外推薦可行的做法。整體而言，這套共享評估框架解決的是重複建置與標準不一的問題，讓不同團隊能更快獲得可信的評估；但它無法取代領域專業、資料校準與產品判斷，這些仍得由人與各團隊自己承擔，這也是導入 agentic AI 時最容易被低估的部分。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。