Cách Kỹ Sư AI Sử Dụng Bộ Dữ Liệu Để Đánh Giá Độ Tin Cậy Của Các AI Agent

Cách Kỹ Sư AI Sử Dụng Bộ Dữ Liệu Để Đánh Giá Độ Tin Cậy Của Các AI Agent

Tóm tắt:

Các cuộc thảo luận về AI agent thường tập trung vào mô hình, nhưng thực tế mô hình hiếm khi là vấn đề. Thành công hay thất bại của agent phụ thuộc nhiều vào hệ thống bao quanh — các công cụ gọi ra, lời gọi (prompt), và logic điều khiển hành vi. Bài viết này trình bày cách xây dựng và đánh giá bộ dữ liệu test thực tế, làm thế nào để điểm số theo đúng hành trình xử lý của agent, và cách tạo các bài test đối kháng giúp nhận diện agent có thật sự hiểu biết hay chỉ đơn thuần là nhận dạng mẫu.

Tại sao không huấn luyện mà tập trung vào test cases?

AI agent hiện nay thường sử dụng mô hình đã cố định, không còn điều chỉnh trọng số hay thay đổi cách mô hình suy luận. Thay vào đó, kỹ sư xây dựng:

• Các kịch bản kiểm thử thực tế từ dữ liệu logs, metrics,
• Đánh giá xem agent có thực hiện điều tra đúng quy trình không,
• Phát hiện và tận dụng các edge cases mà agent chưa xử lý tốt,
• Cải tiến lời gọi (prompts), công cụ, và logic điều khiển dựa trên kết quả test,
• Xây dựng bộ test suite ngày càng khó hơn nhằm nâng cao chất lượng agent.

Quá trình này không cải thiện mô hình trực tiếp mà làm mạnh hệ thống xung quanh, đảm bảo agent đáng tin cậy trước khi đưa vào sử dụng.

Những hành vi cần test của AI agent

Khi kiểm thử AI agent, điều cần coi trọng không phải là kiến thức trong mô hình mà là 3 hành vi chính:

• Chọn công cụ đúng và đúng thứ tự: Agent có điều tra theo quy trình hợp lý hay vội vã, đưa ra kết luận sớm khi chưa đủ dữ liệu?
• Dừng đúng lúc: Agent có nhận biết khi đã tìm ra nguyên nhân gốc rễ và dừng, hay tiếp tục vòng vòng không cần thiết?
• Lọc bỏ tín hiệu nhiễu: Trong dữ liệu có thể có các red herrings (tín hiệu gây nhiễu), agent có bị phân tâm hoặc vẫn giữ vững đường hướng điều tra đúng?

Chỉ khi đánh giá được các hành vi này mới biết được độ tin cậy thật sự của AI trong môi trường thực tế.

SRE Agent – Ví dụ điển hình

Agent SRE (Site Reliability Engineering) tự động điều tra sự cố sản xuất. Khi nhận cảnh báo, agent sẽ lấy logs, metrics phân tích các tín hiệu và đưa ra báo cáo nguyên nhân gốc rễ.

Dự án OpenSRE có bộ test trực quan với các ngữ cảnh Kubernetes và RDS Postgres. Một cảnh báo tổng hợp, ví dụ dưới dạng file JSON, giả lập tình huống thực tế kèm dữ liệu đầu vào và kỳ vọng hành trình điều tra:

opensre investigate -i tests/e2e/kubernetes/fixtures/datadog_k8s_alert.json

Bộ test mô tả chi tiết logs, metrics agent nhìn thấy, các bước điều tra dự kiến phải đi qua, nguyên nhân gốc rễ mong muốn phát hiện, và các tín hiệu nhiễu mà agent cần tránh.

Cấu trúc một test case điển hình

Mỗi test case gồm 4 phần:

• Input: logs, metrics và cảnh báo thực tế,
• Expected steps: chuỗi bước agent cần thực hiện để điều tra,
• Expected root cause: nguyên nhân gốc rễ chính xác cần tìm ra,
• Red herrings: tín hiệu gây nhiễu agent phải nhận ra nhưng không bị đánh lừa.

Ví dụ về test case RDS Postgres connection pool:

TEST_CASE = {
    "scenario": "RDS Postgres connection pool exhaustion",
    "input": {
        "logs": "...",  # logs sự cố diễn ra
        "metrics": {...},  # thông số đo lường system
        "alert": "Database latency spike - P95 latency exceeded 4000ms"
    },
    "expected_steps": [
        "check_db_connections",
        "check_active_queries",
        "check_pool_configuration",
        "recommend_pool_size_increase"
    ],
    "expected_root_cause": "connection pool exhaustion",
    "red_herrings": {
        "cpu_percent": "elevated but stable, not the cause of latency"
    },
    "should_stop_after": "check_pool_configuration"
}

Agent chạy với input trong test case rồi được đánh giá dựa trên đánh giá các bước điều tra, chính xác nguyên nhân và không bị sai đường do các red herrings.

Điểm số theo hành trình điều tra (Trajectory scoring)

Chỉ trả lời đúng nguyên nhân gốc rễ chưa đủ, chúng ta cần đánh giá hành trình agent đi đến kết luận đó có hợp lý hay không.

Ví dụ agent đúng nguyên nhân nhưng lại mò mẫm qua nhiều bước không liên quan thì không đáng tin cậy.

Hàm điểm số sẽ so sánh danh sách các bước agent thực hiện với chuỗi các bước kỳ vọng, xử lý:

• Phạt nếu thực hiện các bước ngoài dự kiến,
• Phạt nếu làm sai thứ tự bước,
• Phạt nếu tiếp tục điều tra quá mức sau khi đã tìm ra nguyên nhân.

Điểm số cuối cùng biểu thị mức độ chính xác trong điều tra, giúp định lượng giá trị thực của agent trong hoạt động.

Kiểm thử đối kháng: Phòng tránh pattern matching đơn giản

Các bài test tiêu chuẩn đánh giá agent với các tình huống đã biết. Tuy nhiên, trong thực tế sự cố thường đi kèm nhiều tín hiệu nhiễu, gây hiểu nhầm.

Adversarial tests (kiểm thử đối kháng) thiết kế các kịch bản gây nhiễu nhằm buộc agent phải giải thích và tư duy sâu hơn, tránh chỉ dò theo mẫu dữ liệu.

Ví dụ:

• Cảnh báo CPU throttling cao trông có vẻ nghiêm trọng,
• Nhưng nguyên nhân thật sự là OOMKilled do thiếu bộ nhớ,
• Agent pattern-matching sẽ chỉ tập trung vào CPU và đưa ra đề xuất lỗi thời,
• Agent có khả năng tư duy sẽ liên kết đúng nguyên nhân gốc rễ này và tránh bị đánh lừa bởi sự kiện CPU.

Tham khảo bộ test hiện có để xây dựng bộ test của bạn

Nên tìm hiểu cấu trúc và cách tổ chức của các bộ test hiện có trước khi tự xây dựng. Một số tài nguyên hữu ích:

• OpenSRE – bộ test dành cho SRE agent
• SWE-bench – đánh giá tác vụ kỹ thuật phần mềm
• AgentBench – benchmark đa môi trường cho AI agents

Các bộ test này đều tuân theo mẫu: đầu vào thực tế, hành vi kỳ vọng định nghĩa rõ, đầu ra được đánh giá.

Dữ liệu tổng hợp (Synthetic data) và giới hạn của nó

Dữ liệu tổng hợp do bạn tạo ra giúp nhanh chóng dựng các kịch bản chi tiết, điều khiển được điểm gây nhiễu. Đây là điểm khởi đầu hợp lý để xây bộ test.

Tuy nhiên, dữ liệu tổng hợp có giới hạn bởi tính sáng tạo của con người, và dần tới một ngưỡng. Các kịch bản khác lạ ngoài dự kiến không thể tự động hình thành, và agent không được thử trên các trường hợp đó sẽ mất khả năng xử lý tình huống đa dạng.

Đưa dữ liệu thực tế vào phát triển test case

Giải pháp khi dữ liệu tổng hợp đã bão hòa là sử dụng các bộ dữ liệu thực tế có gắn nhãn lỗi (labeled dataset) từ các nguồn công khai như:

• Google Dataset Search
• Kaggle Datasets

Bằng cách phân tích các đoạn dữ liệu thực tế bị lỗi, người phát triển có thể xây dựng test case chân thực, giúp agent kiểm tra khả năng xử lý tình huống phức tạp ngoài dự kiến.

import pandas as pd

df = pd.read_csv("server_machine_dataset.csv")

failure_window = df[df["label"]==1].head(100)

test_case = {
    "scenario": "server anomaly from SMD dataset machine-1-1",
    "input": {
        "metrics": failure_window[["cpu", "memory", "network_in", "network_out"]].to_dict()
    },
    "expected_root_cause": "network saturation",
    "expected_steps": [
        "check_network_throughput",
        "check_active_connections",
        "identify_traffic_source"
    ]
}

Lưu ý: nguyên nhân gốc rễ (expected_root_cause) lấy từ tài liệu kèm theo dataset để đảm bảo có ground truth chính xác cho quá trình đánh giá.

Kết luận

Việc đánh giá AI agent không phải là tiếp tục huấn luyện mô hình mà là xây dựng hệ sinh thái test cases xác thực, đo lường kỹ càng hành vi. Qua các bộ test thực tế, điểm số theo hành trình điều tra, và kiểm thử đối kháng, kỹ sư AI có thể đảm bảo agent đủ tin cậy để triển khai trong môi trường sản xuất đa dạng và phức tạp.

---

Tham khảo thêm:

• OpenSRE test suite
• Google Dataset Search
• Kaggle Datasets
• SWE-bench
• AgentBench