Cách đánh giá AI Agents trong môi trường Production: Hệ thống 3 lớp chúng tôi áp dụng trên Live Traces

Cách đánh giá AI Agents trong môi trường Production: Hệ thống 3 lớp chúng tôi áp dụng trên Live Traces

Đánh giá AI agents trong production nghĩa là chấm điểm toàn bộ lộ trình đa bước của agent, không chỉ câu trả lời cuối cùng, dựa trên lưu lượng truy cập thực tế: kiểm tra từng bước suy luận, xác thực rằng agent đã gọi đúng công cụ với các đối số phù hợp, và liên tục giám sát tỷ lệ thành công, chi phí cũng như độ an toàn sau khi triển khai, bởi vì các agent thường thất bại một cách âm thầm và không xác định.

Trong một lần chạy pipeline nội dung Techsy của chúng tôi vào tháng 6 năm 2026, agent đã xuất bản một bài blog trông hoàn hảo và điểm số đầu ra cuối cùng đã cho nó đạt chuẩn. Mọi thứ có vẻ sạch sẽ. Ngoại trừ việc ở ba bước trước đó, tác nhân tạo brief (brief-creator) đã gọi nhầm công cụ tra cứu liên kết nội bộ, khiến một nửa các liên kết trong cụm trỏ đến trang trống. Biết cách đánh giá AI agents trong production nghĩa là phải chấm điểm toàn bộ con đường mà agent đã đi, chứ không chỉ là câu trả lời mà nó tình cờ đạt được.

Những điểm chính:

• Chấm điểm toàn bộ lộ trình, không chỉ câu trả lời cuối cùng: một câu trả lời đúng thông qua một con đường sai vẫn là thất bại.
• Xác thực lệnh gọi công cụ (tool calls) trên ba trục: đúng công cụ, đúng đối số, đúng bước.
• Chạy cùng các chỉ số cả offline và online, trên các live production traces, trong một vòng lặp liên tục.
• Ng chặn việc triển khai (deploy) dựa trên các lỗ hổng bảo mật (jailbreak, rò rỉ PII, lạm dụng công cụ), không chỉ dựa trên điểm độ chính xác thấp.

Tại sao việc đánh giá AI agents trong production lại khác với đánh giá LLM?

Việc đánh giá AI agents trong production khó hơn so với đánh giá mô hình vì một agent thực hiện nhiều bước, gọi các công cụ bên ngoài và thay đổi trạng thái thực tế, và nó thực hiện tất cả những điều đó một cách không xác định. Cùng một đầu vào có thể tạo ra một chuỗi lệnh gọi công cụ khác nhau giữa các lần chạy, vì vậy một bước sai duy nhất ở giai đoạn đầu có thể làm hỏng mọi bước sau đó.

Hướng dẫn này giả định rằng bạn đã nắm vững kiến thức chung về đánh giá LLM. Nếu chưa, hãy bắt đầu với hướng dẫn đầy đủ về đánh giá LLM của chúng tôi, sau đó quay lại để xem những gì thay đổi khi mô hình trở thành một agent. (Vẫn đang xây dựng các agent mà bạn sắp đánh giá? Bài tổng quan về các framework AI agent tốt nhất của chúng tôi bao quát lớp nền tảng bên dưới.)

Bốn yếu tố sẽ phá vỡ mọi thứ ngay khi LLM của bạn bắt đầu hành động độc lập:

• Đa bước. Một agent hỗ trợ khách hàng có thể tìm kiếm cơ sở kiến thức, gọi API đơn hàng, sau đó soạn thảo phản hồi. Nếu chỉ chấm điểm phản hồi, bạn sẽ mù quáng trước hai bước quyết định nên kết quả đó.
• Không xác định. Nhiệt độ (temperature), cập nhật trọng số mô hình và độ trễ công cụ có nghĩa là cùng một yêu cầu sẽ đi theo một con đường khác nhau trong mỗi lần chạy. Quy trình đánh giá của bạn phải tồn tại được trước mục tiêu luôn di chuyển này.
• Có trạng thái (Stateful). Các agent ghi vào cơ sở dữ liệu, gửi email, hoàn tiền đơn hàng. Một hành động sai không phải là một câu văn tệ, mà là một tác dụng phụ mà bạn không thể thu hồi.
• Tích lũy lỗi. Một bước hơi sai ở bước 2 trong quy trình 12 bước sẽ đầu độc mọi thứ phía sau, và câu trả lời cuối cùng vẫn có thể trông ổn.

Báo cáo State of Eval Engineering tháng 2 năm 2026 của Galileo, khảo sát hơn 500 chuyên gia, phát hiện ra rằng 84,9% các đội gặp sự cố AI trong vòng sáu tháng sau khi triển khai. Đội ngũ kỹ thuật của Anthropic diễn đạt rõ ràng trong bài luận về đánh giá agent: các agent thất bại xuyên suốt các bước, công cụ và ý định, không chỉ ở đầu ra cuối cùng.

Một agent trả về câu trả lời đúng thông qua một lộ trình sai chưa phải là đã vượt qua. Nó đã thất bại một cách âm thầm, và nó sẽ thất bại một cách ồn ào vào lần tiếp theo khi sự may mắn không còn xảy ra.

Những chỉ số nào thực sự quan trọng đối với AI agents trong production?

Các chỉ số quan trọng nhất cho agents trong production vượt xa khỏi độ chính xác: tỷ lệ thành công của nhiệm vụ, chi phí cho mỗi nhiệm vụ thành công, phân vị độ trễ, độ chính xác của lệnh gọi công cụ, tính trung thực, tỷ lệ can thiệp của con người, độ trôi (drift) và tỷ lệ vượt qua cổng bảo mật. Cùng với nhau, các chỉ số đánh giá AI agent này phát hiện những thất bại âm thầm, không xác định mà một điểm số đầu ra duy nhất bỏ sót.

Đây là tám chỉ số mà chúng tôi thực sự theo dõi trong các lần chạy của mình. Hãy chú ý xem có bao nhiêu chỉ số trong số đó quan tâm đến việc câu trả lời cuối cùng có đọc hay không:

Hầu hết các chỉ số này dựa vào LLM-as-a-judge (một mô hình chấm điểm đầu ra của mô hình khác). Đây là thủ thuật tiêu chuẩn và có khả năng mở rộng, nhưng nó gây nhiễu: giám khảo thường chia sẻ điểm mù với agent, vì vậy hãy coi điểm số của nó như tín hiệu, không phải chân lý. Chúng tôi sẽ quay lại việc hiệu chỉnh giám khảo ở phần bảy.

Một chỉ số đáng được nêu bật riêng. Chi phí cho mỗi nhiệm vụ thành công là con số sống sót qua cuộc rà soát ngân sách. Chi phí thuần túy cho mỗi nhiệm vụ thưởng cho các lỗi rẻ tiền, bởi vì một agent từ bỏ nhanh chóng và sai lầm trông có vẻ hiệu quả trên bảng tính.

Làm thế nào để chấm điểm lộ trình của agent thay vì chỉ câu trả lời cuối cùng?

Để chấm điểm lộ trình của agent, bạn đánh giá trace: bản ghi có thứ tự của mọi bước suy luận, lệnh gọi công cụ và đầu ra trung gian mà agent tạo ra. Đánh giá cấp độ span (span-level evaluation) chấm điểm từng bước riêng lẻ (span) để bạn có thể xác định chính xác bước nào bị lỗi, thay vì chỉ biết rằng toàn bộ lần chạy đã sai.

Hãy nghĩ về một trace như một stack trace cho quá trình suy luận. Mỗi span là một bước: một thao tác truy xuất, một lệnh gọi công cụ, một bàn giao cho sub-agent. Khả năng quan sát (Observability) ghi lại các span đó; quá trình đánh giá chấm điểm chúng. (Chưa có tracing? Hướng dẫn về AI observability của chúng tôi bao quát lớp giám sát mà quá trình chấm điểm nằm trên đó, và bài so sánh LangGraph, CrewAI và OpenAI Agents SDK cho thấy trace trông như thế nào trong từng hệ thống.)

Tại sao lại chấm điểm mọi span thay vì chỉ điểm cuối? Vì lỗi tích lũy. Nếu bước 2 truy xuất sai tài liệu, các bước từ 3 đến 12 sẽ xây dựng trên rác rưởi, và một cách diễn đạt cuối cùng may mắn vẫn có thể lọt qua bài kiểm tra chỉ dựa trên đầu ra. Chấm điểm cấp độ span cho bạn biết lần chạy đã thất bại ở bước 2, chứ không chỉ là nó đã thất bại ở đâu đó.

Dưới đây là phiên bản không phụ thuộc framework (một khẳng định thuần túy trên đối tượng trace), sau đó là cách tắt (shortcut) của DeepEval sử dụng chỉ số Hoàn thành Nhiệm vụ dựa trên trace của nó:

# Framework-agnostic: did the trajectory reach the goal via valid steps?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: score the whole multi-step trace for task completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # your researcher -> brief -> writer -> validator run
    return final_post

Khẳng định không phụ thuộc framework hoạt động tốt cho các kiểm tra cứng, xác định. Task Completion là thứ bạn cần khi sự thành công mơ hồ hơn một phép kiểm tra bình đẳng: nó trích xuất nhiệm vụ dự định và kết quả đạt được từ trace và chấm điểm mức độ phù hợp giữa chúng.

Làm thế nào để xác thực rằng agent đã gọi đúng công cụ?

Để xác thực lệnh gọi công cụ của agent, hãy kiểm tra ba điều riêng biệt: lựa chọn công cụ (nó có chọn đúng công cụ không), tính chính xác của đối số (nó có truyền đúng tham số và giá trị không) và tính hợp lệ của đường dẫn thực thi (nó có gọi công cụ đó ở đúng bước, theo đúng thứ tự không). Một câu trả lời cuối cùng đạt chuẩn nhưng với lệnh gọi công cụ sai là một lỗi chưa bộc lộ.

Đây là bài đánh giá đặc thù nhất cho agent, và là bài mà hầu như không ai đề cập sâu. Việc đánh giá sử dụng công cụ đa agent chia thành ba câu hỏi:

1. Lựa chọn. Trong số các công cụ có sẵn, agent có chọn đúng cái không? Gọi bất kỳ công cụ nào không giống với gọi đúng công cụ.
2. Đối số. Nó có truyền đúng tham số không? Đúng công cụ nhưng với slug sai hoặc ngày tháng bị định dạng sai vẫn là một thất bại.
3. Đường dẫn thực thi. Nó có gọi công cụ đó ở đúng bước, theo đúng thứ tự không? Hoàn tiền trước khi xác minh đơn hàng là sử dụng đúng công cụ nhưng sai trình tự.

Chỉ số Tool Correctness của DeepEval xử lý cả ba điều này: nó so sánh tools_called với expected_tools, có thể khớp theo tham số đầu vào, và với should_consider_ordering=True, nó cũng chấm điểm trình tự.

# Framework-agnostic: right tool, right args, right step
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: score tool selection + arguments, order-aware
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Giá trị 0.0 đó chính là lỗi chính xác mà chúng tôi đã bắt gặp trong pipeline của mình: agent đã sử dụng sitemap_search trong khi công cụ dự kiến là internal_link_lookup. Bài viết hoàn thiện vẫn vượt qua điểm số đầu ra. Chỉ số tool-call là thứ duy nhất báo hiệu con đường bị hỏng.

Làm thế nào để chạy evals online trên các live production traces?

Đánh giá trực tuyến (Online evaluation) chạy các chỉ số của bạn trên các live production traces theo thời gian thực, thay vì chỉ trên bộ thử nghiệm trước khi triển khai. Đây là lớp thứ ba của hệ thống ba lớp: kiểm tra offline trên bộ dữ liệu vàng (golden set), cổng QA trước khi triển khai, sau đó là evals online trên lưu lượng truy cập thực tế, với các production traces được tuyển chọn ngược lại vào các bộ dữ liệu để vòng lặp tiếp tục cải thiện.

Kiểm tra offline phát hiện các hồi quy (regressions) trước khi chúng được triển khai. Nhưng các agent gặp phải các đầu vào trong production mà không bộ golden set nào dự đoán trước, vì vậy các chỉ số tương tự phải tiếp tục chạy sau khi ra mắt. Dưới đây là vòng lặp đầy đủ mà sơ đồ ở đầu bài phác họa:

1. Offline. Chạy các chỉ số của bạn trên bộ dữ liệu vàng trong CI. Hủy build nếu có hồi quy.
2. Cổng QA trước khi triển khai. Một điểm kiểm soát do con người sở hữu: liệu điều này có vượt qua ngưỡng độ chính xác và ngưỡng bảo mật (phần sáu) không?
3. Online. Chấm điểm các live production traces theo thời gian thực với cùng các chỉ số.
4. Tuyển chọn (Curate). Tự động thu thập các trace thực tế (đặc biệt là các lỗi) trở lại vào bộ dữ liệu eval của bạn.
5. Chạy lại. Bộ golden set của bạn phát triển từ thực tế thay vì 20 ví dụ bạn viết tay vào ngày đầu tiên.

Việc kết nối một online eval sử dụng cùng công cụ instrumentation như tracing, cộng với thu thập chỉ số. Confident AI chạy 50+ bộ chấm điểm từ DeepEval trên các live traces, và nó tương thích với OpenTelemetry, vì vậy LangGraph, CrewAI, OpenAI và Vercel AI SDK xuất dữ liệu mà không cần các adapter tùy chỉnh:

# Same metrics you ran in dev, now scoring live production traffic
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # your live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# The collection's metrics now run on every trace, in real time.

Phần thưởng lớn nhất là bước tuyển chọn. Mọi lỗi production thực tế trở thành một bài kiểm tra hồi quy vĩnh viễn, vì vậy bộ công cụ của bạn ngừng là một ảnh chụp tĩnh và bắt đầu theo dõi những gì agent của bạn thực sự gặp phải trong môi trường thực tế.

Đặt cổng dựa trên bảo mật, không chỉ độ chính xác

Một cổng bảo mật chặn việc triển khai dựa trên lỗ hổng bảo mật, không chỉ dựa trên điểm độ chính xác thấp. Đối với các agent, điều đó có nghĩa là các evals đối nghịch và red-team dò tìm các lỗ hổng jailbreak, lạm dụng công cụ và rò rỉ PII, được chạy cả trước khi triển khai và online. Một vụ jailbreak không phải là điểm số thấp mà bạn có thể trung bình hóa. Nó là một rào cản phát hành.

Mọi đối thủ cạnh tranh đều coi an toàn là một chỉ số trong số nhiều chỉ số. Điều đó là ngược lại đối với các agent, vốn có thể bị dụ dỗ gọi một công cụ thực tế lên một hệ thống thực tế. Vì vậy, hãy tách biệt các cổng: cổng độ chính xác trung bình hóa điểm số; cổng bảo mật là đỗ/trượt dựa trên việc liệu bất kỳ cuộc thăm dò đối nghịch nào có lọt qua hay không. Bắt đầu bằng cách ánh xạ các chế độ lỗi của agent sang các framework mà các kiểm toán viên đã nhận diện:

Sau đó, chạy các evals đối nghịch chống lại các danh mục đó. Top 10 của OWASP cho ứng dụng LLM, Khung quản lý rủi ro AI của NIST và MITRE ATLAS cung cấp cho bạn vốn từ vựng chung; red-teaming cung cấp cho bạn bài kiểm tra. DeepTeam, framework red-teaming mã nguồn mở từ cùng đội ngũ đứng sau DeepEval, cung cấp 120+ lỗ hổng trên 8 danh mục và 20+ vectơ tấn công, mỗi cái được ánh xạ tới OWASP, NIST AI RMF và MITRE ATLAS.

Một sắc thái trung thực về công cụ: DeepTeam OSS là con đường miễn phí và bao phủ tập hợp lỗ hổng; module red-teaming được quản lý, trong nền tảng của Confident AI là tính năng cấp Enterprise, không phải thứ mà gói Starter $9.99 bao gồm. Dù bằng cách nào, hãy tích hợp red-teaming như một cổng hạng nhất, không phải là suy nghĩ muộn màng mà bạn chạy một lần trước khi ra mắt.

Những gì chúng tôi phát hiện khi chạy hệ thống này trên pipeline của mình

Chúng tôi chạy hệ thống ba lớp này trên pipeline nội dung đa agent của chính mình: bốn agent (researcher, brief-creator, content-writer, validator) bàn giao công việc theo chuỗi. Việc tích hợp DeepEval v4.0.5 vào pipeline đó trong tháng 6 và tháng 7 năm 2026, trên workspace Confident AI của chúng tôi, là cách chúng tôi phát hiện ra lỗi từ phần giới thiệu. Đầu ra của bộ chấm điểm trông như sau:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

Bài đăng đã vượt qua điểm số chất lượng đầu ra của nó. Không có gì về bài viết hoàn thiện trông có vẻ sai. Chỉ có đánh giá lộ trình mới nhìn thấy bước bị hỏng, chính xác là loại lỗi mà bài kiểm tra chỉ dựa trên đầu ra bỏ qua.

Nếu bạn theo dõi các chuyên gia trên r/LLMDevs, r/MachineLearning hoặc r/LocalLLaMA, cùng một handful phàn nàn xuất hiện liên tục, và chúng gần như khớp từng điểm một với những gì hệ thống ba lớp được xây dựng để phát hiện:

• Vấn đề "ổn thứ Hai, lỗi thứ Tư". Tính không xác định khiến cùng một đầu vào đi theo một con đường khác nhau trong mỗi lần chạy, vì vậy các đội học cách bỏ qua các evals không ổn định. Chấm điểm cấp độ span trên live traces hiệu quả hơn một bộ golden set lớn hơn.
• Mệt mỏi với bộ dữ liệu vàng. Hàng tuần dành để dán nhãn thủ công một bộ công cụ mà một thay đổi suy luận duy nhất làm lỗi thời. Tự động tuyển chọn production traces hiệu quả hơn việc duy trì một tệp tĩnh bằng tay.
• Không tin tưởng vào LLM judge. Lời than phiền lặp đi lặp lại là giám khảo chia sẻ điểm mù với agent, đó chính xác là lý do tại sao các đội giữ con người trong vòng lặp.

Điểm cuối cùng đó là quan trọng nhất. Các chuyên gia lĩnh vực chú thích các đầu ra mà giám khảo không chắc chắn, và các nhãn đó được đưa trở lại vào việc căn chỉnh chỉ số, cùng một vòng lặp kín mà chúng tôi đã mô tả trong bài đánh giá Confident AI và liền kề với cách chúng tôi xử lý bộ nhớ agent. Giám khảo giúp mở rộng quy mô; con người giữ cho nó trung thực.

Nền tảng nào phù hợp với stack của bạn?

Không có công cụ duy nhất nào phù hợp với mọi đội, vì vậy hãy khớp nền tảng với vị trí hiện tại của bạn. Dưới đây là cách các tùy chọn chính so sánh về năm khả năng mà hướng dẫn này dựa vào, cộng với cách bạn bắt đầu:

Đứng đầu cho trường hợp sử dụng doanh nghiệp và chéo nhóm là Confident AI. Nó bao phủ toàn bộ vòng đời chất lượng tại một nơi (evals thời gian dev, observability production, bảo mật đối nghịch qua DeepTeam, cổng chất lượng toàn tổ chức), và điểm khác biệt thực sự của nó là truy cập no-code cho team: các kỹ sư thiết lập nó một lần, sau đó PMs, QA và các chuyên gia lĩnh vực tự chạy các chu kỳ eval đầy đủ. Mức vào là $9.99/người/tháng với gói miễn phí. Nó đứng #1 trong bài tổng hợp công cụ đánh giá LLM và #2 trong so sánh nền tảng AI observability của chúng tôi, vì vậy đây không phải là lần đầu tiên nó đứng đầu danh sách đối với chúng tôi.

Được định vị riêng biệt là DeepEval, framework mã nguồn mở hàng đầu, được xây dựng bởi cùng một đội ngũ, với 50+ bộ chấm điểm và kiểm tra native pytest. Confident AI là nền tảng; DeepEval là thư viện OSS, không phải là phiên bản cắt giảm của nó. Chọn cái này nếu:

• DeepEval: bạn muốn tiêu chuẩn mã nguồn mở và làm việc trong Python và pytest.
• Langfuse: bạn muốn tracing mã nguồn mở mà bạn có thể tự host.
• LangSmith: stack của bạn là LangChain và LangGraph từ đầu đến cuối.
• Arize Phoenix: bạn muốn tracing native OpenTelemetry hoàn toàn mã nguồn mở.
• Braintrust: bạn muốn evals all-in-one cộng với experiments với gói miễn phí hào phóng.
• Promptfoo: bạn làm việc trong CLI và muốn red-teaming trong cùng một công cụ.
• Ragas: agent của bạn thực sự là một pipeline RAG và bạn muốn các chỉ số cụ thể cho truy xuất.
• Galileo: bạn muốn một chỉ số ảo giác và chất lượng được quản lý sẵn.
• Maxim: bạn muốn quy trình simulation-and-eval cho các agent đa lượt.
• W&B Weave: bạn đã ở trong Weights & Biases và muốn tracing bên cạnh các lần chạy training.

Một hạn chế trung thực về Confident AI: module red-teaming được quản lý và triển khai on-prem là cấp Enterprise, và cư trú dữ liệu US/EU là tính năng Team/Enterprise chứ không phải nút bật universal khi đăng ký. Một nhà phát triển solo triển khai một agent có thể bắt đầu với DeepEval OSS miễn phí và thêm nền tảng khi cả một đội cần chạy evals.

Về tác giả

Mert Batur Gurbuz, Đồng sáng lập tại Techsy.io (Đại học Birmingham). Mert Batur Gurbuz là Đồng sáng lập của Techsy.io, nơi đội ngũ cung cấp các AI agents, hệ thống tự động hóa và pipeline voice/SDR cho khách hàng B2B. Anh ấy đang học tại Đại học Birmingham và viết về stack công cụ LLM mà đội Techsy thực sự sử dụng trong production. Kết nối trên LinkedIn.

Câu hỏi thường gặp

Đánh giá AI agent là gì?

Đánh giá AI agent là thực hành chấm điểm toàn bộ hành vi của một agent tự động, không chỉ câu trả lời cuối cùng của nó. Nó đo lường lộ trình đa bước, các công cụ nó đã gọi, thành công của nhiệm vụ, chi phí, độ trễ và độ an toàn. Vì các agent hành động không xác định và thay đổi trạng thái thực tế, việc đánh giá chạy liên tục, trong quá trình phát triển và trên lưu lượng production trực tiếp.

Làm thế nào để đánh giá lộ trình của agent so với đầu ra cuối cùng của nó?

Đánh giá đầu ra cuối cùng chỉ chấm điểm câu trả lời cuối cùng. Đánh giá lộ trình chấm điểm toàn bộ trace: mọi bước suy luận, lệnh gọi công cụ và kết quả trung gian. Chấm điểm cấp độ span xếp hạng từng bước để bạn có thể tìm ra chính xác bước nào bị lỗi. Một lần chạy có thể tạo ra câu trả lời đúng thông qua một lộ trình bị hỏng, điều mà đánh giá lộ trình phát hiện và các bài kiểm tra chỉ dựa trên đầu ra bỏ sót.

Làm thế nào để xác thực rằng agent đã gọi đúng công cụ?

Kiểm tra ba điều riêng biệt: lựa chọn công cụ (đúng công cụ cho nhiệm vụ), tính chính xác của đối số (đúng tham số và giá trị) và tính hợp lệ của đường dẫn thực thi (đúng bước và thứ tự). Các framework như chỉ số Tool Correctness của DeepEval so sánh các công cụ thực sự được gọi với các công cụ dự kiến, khớp theo tham số đầu vào và có thể xếp hạng thứ tự gọi khi bạn kích hoạt nó.

Những chỉ số nào quan trọng nhất đối với AI agents trong production?

Tỷ lệ thành công của nhiệm vụ và chi phí cho mỗi nhiệm vụ thành công đứng đầu, sau đó là các phân vị độ trễ (p50, p90, p99), độ chính xác của lệnh gọi công cụ, tính trung thực, tỷ lệ can thiệp của con người, độ trôi và tỷ lệ vượt qua cổng bảo mật. Chi phí cho mỗi nhiệm vụ thành công quan trọng hơn chi phí thô, vì chi phí thuần túy cho mỗi nhiệm vụ âm thầm thưởng cho các agent thất bại nhanh và rẻ.

Sự khác biệt giữa evals agent offline và online là gì?

Evals offline chạy các chỉ số của bạn trên một bộ dữ liệu vàng cố định trước khi triển khai, thường trong CI, để phát hiện hồi quy. Evals online chạy cùng các chỉ số trên các live production traces theo thời gian thực, sau khi ra mắt. Bạn cần cả hai: offline phát hiện các chế độ lỗi đã biết, online phát hiện các đầu vào mà không bộ golden set nào dự đoán trước và đưa chúng trở lại vào bộ dữ liệu của bạn.

Bạn nên chạy lại đánh giá agent thường xuyên như thế nào?

Chạy evals offline trên mọi thay đổi về prompt, mô hình hoặc công cụ, được gated trong CI. Chạy evals online liên tục trên lưu lượng truy cập trực tiếp, vì độ trôi và cập nhật trọng số mô hình làm suy giảm agents một cách âm thầm giữa các lần deploy. Tái tuyển chọn bộ dữ liệu vàng của bạn bất cứ khi nào production xuất hiện một chế độ lỗi mới, để bộ công cụ theo dõi thực tế thay vì các ví dụ bạn đã viết vào ngày đầu tiên.

Làm thế nào để phát hiện jailbreaks và rò rỉ PII trước khi chúng được triển khai?

Chạy các evals red-team đối nghịch như một cổng trước khi deploy, và giữ chúng chạy online. Ánh xạ các chế độ lỗi sang Top 10 OWASP cho LLMs, NIST AI RMF và MITRE ATLAS, sau đó mô phỏng các cuộc tấn công chống lại từng danh mục với một framework như DeepTeam mã nguồn mở. Chặn việc phát hành trên bất kỳ lỗ hổng nào lọt qua, không chỉ dựa trên điểm trung bình thấp.

Bạn nên tự xây dựng hay mua một nền tảng đánh giá AI agent?

Xây dựng với các công cụ mã nguồn mở (DeepEval cho chỉ số, Promptfoo cho kiểm tra CLI và red-teaming) khi bạn là nhà phát triển solo hoặc một đội kỹ thuật nhỏ thoải mái với code. Mua một nền tảng như Confident AI khi cả một đội cần truy cập no-code toàn tổ chức, kiểm tra bảo mật được quản lý và observability production được chuẩn hóa trên các dự án. Hầu hết các đội bắt đầu với OSS và nâng cấp sau.

LLM-as-a-judge có đáng tin cậy để chấm điểm agents không?

Nó hữu ích nhưng gây nhiễu. Một LLM judge mở rộng quy mô lên hàng nghìn traces với chi phí thấp, nhưng nó không xác định và thường chia sẻ điểm mù với agent, vì vậy nó có thể đóng dấu phê duyệt cho một câu trả lời hợp lý nhưng sai. Hiệu chỉnh nó dựa trên nhãn của con người hoặc chuyên gia lĩnh vực trên một mẫu, coi điểm số là tín hiệu định hướng, và gate các quyết định quan trọng trên các kiểm tra xác định khi có thể.

Hệ thống 3 lớp, tóm gọn trong một hơi

Chấm điểm lộ trình, không chỉ câu trả lời. Xác thực lệnh gọi công cụ trên ba trục: đúng công cụ, đúng đối số, đúng bước. Chạy cùng các chỉ số offline và online, trên live traces, trong một vòng lặp tuyển chọn các lỗi thực tế trở lại vào bộ dữ liệu của bạn. Và gate việc deploy dựa trên bảo mật, không chỉ độ chính xác.

Bắt đầu với lớp nào gây đau đớn nhất: nếu bạn đang triển khai trong mù quáng, hãy kết nối online evals trước; nếu bạn đang triển khai không an toàn, hãy xây dựng cổng bảo mật trước. Xây dựng nó với DeepEval và Promptfoo mã nguồn mở, hoặc mua một nền tảng như Confident AI khi cả một đội cần truy cập no-code và bảo mật được quản lý. Và nếu bạn thích để các kỹ sư thiết lập toàn bộ vòng lặp cho bạn, đó là loại dịch vụ mà đội ngũ của chúng tôi thực hiện mỗi tuần.