# Braintrust cho FDE: biến lỗi production thành bộ eval chặn merge

> Ở site khách, câu "prompt mới có tốt hơn không?" chỉ đáng tin khi có điểm số chạy trên mỗi pull request. Braintrust được dựng để làm đúng việc đó.

Bản gốc: https://fdetimes.net/vi/cong-cu/braintrust-eval-va-quan-sat-ung-dung-llm/

Một prompt được sửa lúc 5 giờ chiều, demo cho khách thấy ổn, merge. Sáng hôm sau, chatbot hỗ trợ của khách bắt đầu trích sai điều khoản hoàn tiền mà trước đó nó trả lời đúng. Ai làm FDE đủ lâu đều từng gặp cảnh này, và nó không đến từ code tệ mà đến từ chỗ không có gì đo chất lượng trước khi merge.

Braintrust nhắm thẳng vào lỗ hổng đó. Công ty tự gọi mình là nền tảng observability chủ động cho agent, với vòng lặp được mô tả gọn: tìm pattern trong production, biến chúng thành eval, và cải thiện chất lượng qua mỗi lần release. Với FDE, đó là cách biến cảm giác "hình như tốt hơn" thành một con số mà cả bạn lẫn khách cùng nhìn được.

## Một eval gồm những gì?

Docs của Braintrust chia mỗi eval thành ba phần. Data là các ví dụ cần đánh giá, gồm input và tuỳ chọn expected output hoặc metadata. Task là hàm gọi ứng dụng của bạn để sinh output. Scores là các hàm chấm điểm.

Scorer là nơi kỹ năng của FDE lộ ra. Braintrust cho ba lựa chọn: autoevals dựng sẵn, LLM-as-a-judge, hoặc code tuỳ biến. Autoevals là thư viện mã nguồn mở theo giấy phép MIT, và ví dụ chính thức truyền scorer Factuality thẳng vào tham số scores của Eval().

Scorer tuỳ biến có hợp đồng rất đơn giản. Hàm nhận input, output, expected, metadata và trả về một số từ 0 đến 1, hoặc một object có score kèm name và metadata tuỳ chọn. Nếu bỏ trống name, Braintrust lấy tên hàm làm khoá điểm, nên hãy đặt tên hàm như đặt tên một chỉ số kinh doanh.

## Ví dụ: chatbot hoàn tiền của một chuỗi bán lẻ

Thử hình dung khách là một chuỗi bán lẻ, chatbot phải trả lời câu hỏi đổi trả và luôn dẫn đúng mã chính sách. Factuality giúp kiểm tra nội dung có khớp expected hay không, nhưng quy tắc "phải nhắc mã chính sách" là luật cứng, nên kiểm bằng code sẽ rẻ và ổn định hơn là để một model khác phán xử. Một bản phác thảo bằng Python:

```python
from braintrust import Eval
from autoevals import Factuality

def cites_policy_code(input, output, expected, metadata):
code = metadata["policy_code"]
return 1 if code in output else 0

Eval(
"refund-bot",
data=lambda: load_cases(),   # 40 câu hỏi thật từ log
task=lambda input: refund_bot(input),
scores=[Factuality, cites_policy_code],
)
```

Thử tính bằng một con số cụ thể. Giả sử bộ data có 40 câu, prompt cũ dẫn đúng mã ở 36 câu, tức cites_policy_code đạt 0,9. Prompt mới viết lại cho "thân thiện hơn" chỉ dẫn đúng 28 câu, tức hụt 8 câu, và điểm rơi xuống 0,7, trong khi câu trả lời đọc lên vẫn rất trơn tru.

Không có eval, 8 câu sai đó, tương đương 20 điểm phần trăm, chỉ lộ ra khi khách phàn nàn. Có eval, nó hiện ngay trên pull request. Việc đầu tiên nên làm ở khách vì thế không phải chọn công cụ, mà là ngồi với đội vận hành để chép ra những câu chatbot từng trả lời sai và viết expected cho chúng.

## Đưa điểm số vào CI thì chặn được gì?

Docs khuyến nghị chạy eval trên mỗi pull request để bắt regression trước khi lên production. Braintrust có GitHub Action chính thức với mục tiêu ghi rõ: chạy eval trên mỗi PR, chặn merge theo kết quả, và tự báo điểm cho team.

Action, nằm ở repo braintrustdata/eval-action, tự đăng comment kết quả lên PR, nên workflow cần quyền pull-requests: write. Có hai input đáng chú ý: report_scores để lọc những điểm hiện trong comment, và terminate_on_failure với mặc định là false.

Đừng để mặc định quyết định thay bạn; hãy chọn có chủ đích xem eval lỗi có làm dừng workflow hay không, và ghi lý do vào README cho đội của khách.

Nếu khách dùng GitLab hay Jenkins thay vì GitHub, cách làm vẫn đơn giản: đặt BRAINTRUST_API_KEY trong môi trường CI để lệnh bt eval đọc. Ở các khách hàng doanh nghiệp, đây thường là chỗ vướng nhất, vì xin cấp secret mới cho pipeline có khi mất cả tuần, nên hãy hỏi việc này từ ngày đầu.

**Điểm mấu chốt:** Bộ eval tốt nhất không được viết từ trí tưởng tượng mà từ những lỗi khách đã gặp.

## Công cụ không làm thay phần khó

Braintrust lo phần hạ tầng: chạy, lưu, so sánh, comment. Nó không biết câu nào là quan trọng với khách của bạn. Bốn mươi ví dụ chọn bừa cho ra một con số đẹp nhưng vô nghĩa.

LLM-as-a-judge cũng cần thận trọng. Đó là một model chấm một model khác, nên trước khi tin nó làm cổng chặn merge, bạn nên tự chấm tay một mẫu nhỏ và xem judge có đồng ý với người hay không. Quy tắc nào kiểm được bằng code thì nên viết bằng code.

Một điểm thực tế nữa: scorer có thể định nghĩa inline trong script, đẩy lên Braintrust từ file bằng CLI, hoặc tạo trong UI. Ở site khách, nên giữ scorer trong repo cùng code để review được qua PR, thay vì để chúng sống rải rác trong giao diện web.

## Học gì trước, ghi gì vào CV

Thứ tự hợp lý là dựng một Eval() chạy local với một scorer autoevals, sau đó viết một scorer bằng code, cuối cùng mới gắn vào CI. Nếu JD của một vị trí FDE hay applied AI engineer nhắc đến evals, regression testing cho ứng dụng LLM hay LLM observability, đó chính là kỹ năng bạn đang luyện.

Trên CV, đừng viết "có kinh nghiệm Braintrust". Hãy viết bạn đã dựng bộ eval bao nhiêu ví dụ từ log thật, scorer kiểm tra quy tắc gì, và cổng CI đã chặn được regression nào. Nhà tuyển dụng FDE không mua tên công cụ; họ mua khả năng biến nỗi lo của khách thành một con số chặn được merge.

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

- Lấy 20 câu hỏi thật mà chatbot ở dự án của bạn trả lời sai, viết expected output cho từng câu và dựng thành data cho một Eval()
- Viết một scorer bằng code kiểm tra một quy tắc nghiệp vụ cứng (mã chính sách, định dạng số tiền) và trả điểm 0 hoặc 1
- Thêm braintrustdata/eval-action vào một repo thử, cấp quyền pull-requests: write và mở một PR đổi prompt để xem comment điểm

## Nguồn

- [Braintrust - The active observability platform for agents](https://www.braintrust.dev/)

- [Evaluate systematically](https://www.braintrust.dev/docs/evaluate)

- [Custom code evaluators](https://www.braintrust.dev/docs/evaluate/custom-code)

- [Run experiments in CI/CD](https://www.braintrust.dev/docs/evaluate/run-in-ci.md)

- [GitHub - braintrustdata/eval-action](https://github.com/braintrustdata/eval-action)

- [GitHub - braintrustdata/autoevals](https://github.com/braintrustdata/autoevals)