# Dựng chương trình đánh giá GenAI cho khách: bài học từ FDE ở Arize AI

> Một LLM judge đồng thuận 85% với người chấm vẫn có thể bỏ lọt ba phần tư số lỗi mà khách thực sự lo, và việc của FDE là phát hiện điều đó trước khi khách đem judge ấy ra làm cổng kiểm duyệt.

Bản gốc: https://fdetimes.net/vi/bach-khoa/arize-ai-fde-quan-sat-va-danh-gia-genai-cho-doanh-nghiep/

Đội AI của khách mở demo trợ lý chăm sóc khách hàng và nói thêm một câu: "Bọn mình đọc tay mấy chục cuộc hội thoại rồi, ổn cả." Tuần sau họ muốn mở nó cho toàn bộ người dùng. Thứ bạn cần trả lời lúc này không còn là "nó có tốt không", mà là "khi nó hỏng thì ai biết, và biết bằng cách nào".

Ở Arize AI, đó gần như là toàn bộ công việc. Tin tuyển dụng FDE của công ty mô tả vai trò là cùng đội AI của khách thiết kế, triển khai và mở rộng các chương trình observability và evaluation GenAI ở mức production. FDE còn phải dựng integration và tooling riêng để nền tảng Arize khớp với yêu cầu của từng khách.

Bạn không làm ở Arize thì kỹ năng này vẫn dùng được. Nếu bạn đang đưa LLM vào hệ thống của khách, hãy chuẩn bị trả lời câu hỏi trên bằng số liệu thay vì bằng cảm giác.

## Quan sát và đánh giá là hai nửa của cùng một vòng

Observability trả lời câu hỏi "agent đã làm gì". Mỗi request được ghi thành một trace gồm prompt, tài liệu truy xuất, các lần gọi tool và câu trả lời cuối. Phoenix, nền tảng mã nguồn mở của Arize, dựng phần trace trên OpenTelemetry và không phụ thuộc vào nhà cung cấp, ngôn ngữ hay framework.

Chi tiết cuối này quan trọng với FDE. Khách có thể dùng bất kỳ model hay framework agent nào, và bạn chỉ cần instrument theo một chuẩn chung, không phải viết lại cho từng stack.

Evaluation trả lời câu hỏi "nó làm có đúng không". Bạn lấy trace thành bộ dữ liệu, mà Phoenix cho phép quản lý theo phiên bản để dùng cho thử nghiệm, đánh giá và fine-tune. Trong Arize AX, một experiment chạy tác vụ trên từng dòng của dataset rồi chấm bằng LLM judge, kèm lời giải thích cho từng điểm số để bạn sửa đúng kiểu lỗi.

## Ví dụ: trợ lý hoàn tiền và một judge "khá tốt"

Thử hình dung khách là một công ty bán lẻ có agent xử lý yêu cầu hoàn tiền. Bạn instrument agent, thu trace một tuần, chọn ra 100 cuộc hội thoại và lưu thành dataset `refund-v1`. Hai nhân viên chăm sóc khách hàng của khách gán nhãn tay: 80 cuộc đạt, 20 cuộc không đạt.

Tiếp theo bạn viết một LLM judge và chạy nó trên cùng 100 dòng. Judge chấm đúng cả 80 cuộc đạt, còn trong 20 cuộc lỗi thì nó chỉ bắt được 5. Kết quả như sau:

| | Người: đạt | Người: không đạt |
|---|---|---|
| Judge: đạt | 80 | 15 |
| Judge: không đạt | 0 | 5 |

Mức đồng thuận tổng là (80 + 5) / 100 = 85%, và trên slide thì con số này trông rất ổn. Nhưng recall trên nhóm lỗi chỉ là 5 / 20 = 25%, tức cứ bốn cuộc hội thoại hỏng thì judge bỏ qua ba. Arize cảnh báo đúng tình huống này: judge đồng thuận 85% vẫn có thể không dùng được nếu nó bỏ sót những lỗi bạn quan tâm.

Đoạn code tính hai con số rất ngắn, và bạn nên luôn in cả hai cạnh nhau:

```python
def judge_report(human, judge):
    # human, judge: list of "pass" / "fail"
    n = len(human)
    agree = sum(h == j for h, j in zip(human, judge))
    fails = [j for h, j in zip(human, judge) if h == "fail"]
    caught = sum(j == "fail" for j in fails)
    return {
        "agreement": agree / n,
        "fail_recall": caught / len(fails) if fails else None,
    }
```

Bước sửa bắt đầu từ lời giải thích của judge. Đọc 15 trường hợp bị bỏ lọt, bạn có thể thấy một mẫu chung: judge chỉ kiểm tra câu trả lời có lịch sự và có đúng chính sách hay không. Nó không hề biết agent đã xác nhận hoàn tiền trước khi kiểm tra trạng thái đơn hàng.

## Câu trả lời đúng chưa chắc là quy trình đúng

Lỗi trong ví dụ trên không nằm ở câu chữ mà nằm ở đường đi. Agent nói "Đơn của bạn đã được hoàn tiền" nhưng bỏ qua lần gọi tool tra đơn. Arize khuyên với agent thì phải đánh giá cả câu trả lời cuối lẫn trajectory.

Vì thế judge phiên bản hai cần được cho xem chuỗi tool call trong trace, kèm một tiêu chí rõ ràng: phải tra trạng thái đơn trước khi xác nhận hoàn tiền. Chạy lại experiment trên `refund-v1` rồi so recall trên nhóm lỗi với phiên bản trước. Dataset được giữ cố định nên mọi chênh lệch đều đến từ judge chứ không đến từ dữ liệu.

**Điểm mấu chốt:** Phiên bản đầu tiên của một LLM judge chỉ là giả thuyết, chưa phải công cụ đo.

Chỉ khi judge đã được kiểm chứng với nhãn người, Arize mới khuyên đem nó làm cổng chặn release, đưa lên dashboard hay dùng để định tuyến tự động. Thứ tự này là nguyên tắc cứng: dựng cổng trên một judge chưa kiểm chứng tức là tự động hoá luôn những điểm mù của nó.

## Làm ở khách của bạn theo thứ tự nào?

Bắt đầu bằng trace, vì không có trace thì mọi cuộc bàn về chất lượng chỉ dựa vào cảm giác. Tiếp đó, cùng khách chọn ra những kiểu lỗi họ thực sự sợ, chẳng hạn hoàn tiền sai, lộ dữ liệu hay trả lời ngoài chính sách. Danh sách này quyết định bạn đo recall trên nhóm nào.

Sau đó dựng dataset có phiên bản và xin người của khách gán nhãn, nên là người làm nghiệp vụ chứ không phải kỹ sư. Rồi viết judge, đo đồng thuận và recall, sửa dựa trên lời giải thích, và chỉ đưa judge lên làm cổng kiểm duyệt khi recall đạt mức khách chấp nhận.

Cách trình bày kết quả cũng phải hợp với người nghe. Vai trò ở Arize yêu cầu dẫn dắt thảo luận kỹ thuật với các bên từ kỹ sư đến lãnh đạo cấp cao. Kỹ sư cần bảng confusion matrix, còn lãnh đạo cần một câu: "Judge hiện bắt được 5 trên 20 lỗi hoàn tiền, nên chưa thể dùng nó để chặn release."

## Những lỗi khiến chương trình đánh giá chết yểu

Lỗi phổ biến nhất là báo cáo đúng một con số đồng thuận, như ví dụ 85% ở trên. Lỗi thứ hai là sửa dataset giữa hai lần chạy experiment, khiến không ai biết điểm tăng là nhờ prompt hay nhờ dữ liệu dễ hơn. Lỗi thứ ba là chỉ chấm câu trả lời cuối của một agent có gọi tool.

Lỗi thứ tư thuộc về cách làm việc. FDE ở Arize phải chạy song song nhiều engagement, từ lúc chốt phạm vi đến lúc bàn giao, và góp phần viết playbook cho đội. Nếu mỗi khách bạn lại dựng quy trình từ đầu thì sẽ không kịp, nên hãy biến các bước trên thành template dùng lại được.

## Kỹ năng này thể hiện trên CV thế nào?

Tin tuyển dụng của Arize yêu cầu 2-5 năm kinh nghiệm phát triển phần mềm, thấp hơn mặt bằng của nhiều vị trí FDE senior. Đổi lại, ứng viên phải từng phát triển, triển khai và liên tục cải tiến ứng dụng GenAI trên production, đồng thời nắm công cụ cloud và container.

Với tin tuyển dụng như vậy, dòng "dùng LLM-as-a-judge" trên CV không nói lên nhiều. Một dòng có sức nặng hơn sẽ trông thế này: "kiểm chứng judge với 100 nhãn người, nâng recall trên nhóm lỗi từ 25% lên mức đủ để làm cổng kiểm duyệt release". Câu đó cho người phỏng vấn thấy bạn biết đo đúng thứ cần đo.

Tuần này, hãy lấy 50 trace từ bất kỳ ứng dụng LLM nào bạn có, tự gán nhãn rồi để một judge chấm lại. Nếu recall trên nhóm lỗi làm bạn bất ngờ, thì bạn đã thấy đúng điều mà đội AI của khách chưa thấy.

**Thử ngay tuần này:**

- Lấy 50 trace từ một ứng dụng LLM bạn đang làm, tự gán nhãn đạt/không đạt, rồi chạy một LLM judge trên cùng 50 trace đó
- Tính hai con số: tỷ lệ đồng thuận tổng và recall trên nhóm không đạt; nếu recall thấp, đọc phần giải thích của judge và sửa prompt chấm điểm
- Chọn một agent có gọi tool, viết ra trình tự tool đúng cho 10 tình huống và kiểm tra trajectory thực tế có khớp không

## Nguồn

- [Forward Deployed Engineer, APJ (Arize AI, Trinity Ventures job board)](https://jobs.trinityventures.com/companies/arize-ai/jobs/78279046-forward-deployed-engineer-apj)

- [Forward Deployed AI Engineer, EMEA – Arize AI (Built In NYC)](https://www.builtinnyc.com/job/forward-deployed-ai-engineer-emea/9647110)

- [Arize-ai/phoenix (GitHub README)](https://github.com/Arize-ai/phoenix)

- [Agent evaluation with LLM judge (Arize blog)](https://arize.com/blog/agent-evaluation-llm-judge/)

- [Run experiments with an LLM judge (Arize AX docs)](https://arize.com/docs/ax/develop/tutorial/run-experiments-with-llm-judge.md)