Đã đọc 0/11 mục · còn khoảng 4 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Bài 7 — Ráp thành Pipeline: eval + golden chạy tự động trong CI/CD

Đến giờ bạn có: trace (bài 2), evals (bài 3), đo completion (bài 4), radar loop/drift (bài 5), golden tests (bài 6). Rời rạc thì dễ quên chạy. Bài này ráp chúng thành một pipeline tự động chạy mỗi khi ai đó đổi prompt/model/tool — biến "hy vọng nó vẫn ổn" thành "chứng minh nó vẫn ổn".

Kiến trúc pipeline đánh giá

Thay đổi (prompt/model/tool)
   -> [1] Chạy eval suite   -> pass_rate, completion_rate
   -> [2] Chạy golden suite -> danh sách diff
   -> [3] Kiểm guardrails    -> loop_rate, avg_steps, cost
   -> [4] Cổng chặn (gate)   -> so với ngưỡng & baseline
        ├─ Đạt   -> cho merge/deploy + lưu report
        └─ Trượt -> chặn + báo cáo ca fail

Định nghĩa "cổng chặn" (quality gate)

Gate là tập điều kiện phải thỏa để được deploy. Ví dụ ngưỡng:

gate:
  completion_rate: ">= 0.85"       # không thấp hơn 85%
  regression_vs_baseline: "<= 0"   # không được tụt so với baseline
  golden_hard_diffs: "== 0"        # không hồi quy trên ca "hard"
  loop_rate: "<= 0.02"             # tối đa 2% ca bị loop
  p95_cost_per_task: "<= 0.05"     # trần chi phí mỗi nhiệm vụ

Điểm mấu chốt: so với baseline, không chỉ ngưỡng tuyệt đối. Một thay đổi làm completion từ 92% xuống 88% — vẫn trên 85% nhưng là hồi quy, cần cảnh báo.

Các bước dựng pipeline

Đóng gói eval/golden thành lệnh chạy được một dòng: python run_evals.py --suite all --report out.json.
Kích hoạt trên mỗi pull request thay đổi prompt/model/tool (GitHub Actions/GitLab CI).
Sinh report có cấu trúc (JSON + bảng người đọc được): pass rate, completion, diff list, top ca fail.
Áp gate: script đọc report, so ngưỡng + baseline, trả exit code khác 0 nếu trượt → CI đỏ.
Cập nhật baseline có kiểm soát: chỉ khi thay đổi được duyệt là cải thiện, ghi baseline mới kèm commit.
Đăng report vào PR để reviewer thấy tác động ngay (comment tự động).

Ví dụ bước gate trong CI

report = json.load(open("out.json"))
base   = json.load(open("baseline.json"))
fail = []
if report["completion_rate"] < 0.85: fail.append("completion < 85%")
if report["completion_rate"] < base["completion_rate"] - 0.01: fail.append("hồi quy so baseline")
if report["golden_hard_diffs"] > 0:  fail.append("hồi quy golden hard")
if report["loop_rate"] > 0.02:       fail.append("loop_rate quá cao")
if fail:
    print("GATE FAIL:", "; ".join(fail)); sys.exit(1)
print("GATE PASS")

Chi phí & tốc độ: giữ pipeline chạy được

Tách 2 tầng: smoke suite nhỏ (~20 ca, chạy mỗi commit, vài chục giây) + full suite (chạy trước deploy/nightly).
Cache trace cho ca không đổi; chỉ chạy lại ca bị ảnh hưởng.
Batch LLM-judge và giới hạn nó cho phần thật cần.
Song song hóa: các ca độc lập nhau, chạy đồng thời để rút thời gian tường (wall time).

Đọc report như một reviewer

Một report tốt trả lời ba câu trong vài giây: (1) con số tổng có tụt so với baseline không? (2) ca nào mới fail (so lần trước)? (3) thay đổi này đánh đổi gì (nhanh/rẻ hơn nhưng completion thấp hơn?). Vì vậy report nên có phần "delta so với baseline" đặt lên đầu, kèm danh sách ca vừa chuyển từ pass sang fail — đây mới là thứ reviewer cần, không phải bảng số khô khan. Comment tự động vào PR nên là bản tóm tắt delta này, không phải toàn bộ log.

Ai sở hữu baseline?

Baseline là "hợp đồng chất lượng" của agent. Nó nên nằm trong repo (một file baseline.json có version) và chỉ đổi qua pull request có người duyệt — hệt như code. Khi ai đó muốn nâng baseline (vì đã cải tiến thật), họ mở PR sửa file đó, đính kèm report chứng minh. Cách này khiến mọi lần "chất lượng thay đổi" đều để lại dấu vết truy được, không ai âm thầm hạ chuẩn.

Khung tư duy: "3 câu hỏi trước mỗi lần deploy agent"

Bộ eval có chạy trên đúng thay đổi này không?
Có hồi quy so với baseline (completion/golden/loop) không?
Nếu trượt, report có chỉ đúng ca nào hỏng để sửa không?

Sai lầm thường gặp

Chạy eval thủ công, tùy hứng: Sớm muộn sẽ quên đúng lúc quan trọng. Phải tự động trên PR.
Chỉ dùng ngưỡng tuyệt đối, bỏ baseline: Bỏ lọt hồi quy nhỏ nhưng tích lũy.
Suite quá chậm/đắt nên bị tắt: Không tách smoke/full → cả đội skip. Tối ưu để nó luôn bật.
Gate đỏ nhưng vẫn merge (bỏ qua): Gate mất ý nghĩa. Trượt là chặn, muốn qua phải duyệt tường minh.
Cập nhật baseline tự động: Che giấu hồi quy dần dần. Baseline chỉ đổi khi có người duyệt.

Checklist kết bài

[ ] Eval + golden chạy tự động trên mỗi PR liên quan.
[ ] Gate so cả ngưỡng tuyệt đối và baseline.
[ ] Report chỉ rõ ca fail; đăng vào PR.
[ ] Tách smoke/full để pipeline luôn đủ nhanh để bật.

Bài cuối: vận hành trong production — monitoring, alert và cải tiến liên tục.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi

Bài 7 — Ráp thành Pipeline: eval + golden tự động trong CI/CD