‹ Tất cả Domain 4 Làm quiz

Domain 4 · 16% đề thi · Evaluation & Testing

Đánh giá, kiểm thử và tối ưu

Hãy coi eval là một hợp đồng về độ tin cậy: hệ thống đảm bảo điều gì, với loại input nào, và chuyện gì xảy ra khi không đạt.

5 tiêu chí đánh giá

Bộ dữ liệu eval

Bẫy đề thi

Con số tổng che giấu lỗi. Độ chính xác 94% vẫn có thể đi kèm lỗi nặng ở một nhóm người dùng. Hãy chấm riêng theo từng nhóm (stratified scoring).

Cách chấm điểm

Nếu judge luôn chấm cao hơn người, rubric đang bị lệch. Để phát hiện lỗi mới trong các kết quả model rất tự tin, hãy lấy mẫu ngẫu nhiên theo từng nhóm tài liệu.

Các loại test

Nâng phiên bản model

Rủi ro lớn là chất lượng an toàn giảm dần mà không ai biết. Hãy giữ một bộ test đối kháng cố định và ghi điểm theo từng phiên bản, để mỗi lần nâng cấp đều được đo trên cùng một bộ trước khi đưa lên production.

Đã đối chiếu tài liệu chính thức

Docs khuyên test phải sát phân bố công việc thật và có ca biên, tự động chấm khi có thể, và ưu tiên nhiều câu chấm tự động hơn ít câu chấm tay. Với LLM-based grading, nên dùng model khác với model tạo ra kết quả. Xem docs

A/B test đúng cách

  1. Mỗi lần chỉ đổi một biến: model, phiên bản prompt, hoặc độ sâu retrieval.
  2. Xác định chỉ số và cỡ mẫu trước khi chạy.
  3. Chia traffic thật để các phiên bản chạy song song trên cùng loại dữ liệu.
  4. Quyết định dựa trên kết quả có ý nghĩa thống kê, không dựa trên cảm nhận.

Khi sửa system prompt, hãy chạy regression suite trong CI/CD trước. Qua được rồi mới đưa vào A/B test.

Tìm nguyên nhân gốc

Hai đáp án cần đọc kỹ

Với tình huống “refusal tăng 30%, code không đổi”, nguồn ôn tập có hai đáp án khác nhau: Domain 2 nói nghi alias model, Domain 4 nói nghi traffic thay đổi. Hãy dựa vào chi tiết trong đề:

  • Đề nhắc đến alias: kiểm tra alias trước.
  • Model đã pin phiên bản: kiểm tra traffic drift trước.
  • Docs nêu thêm: với model ID đã pin, hạ tầng phục vụ như router và safety classifier vẫn có thể đổi. Docs coi đây là nguyên nhân khả dĩ nhất khi hành vi khác đi, dù thường chỉ là khác biệt nhỏ. Xem docs

Câu trả lời mâu thuẫn với tài liệu đã lấy

Nếu retrieval không đổi mà model bắt đầu trả lời trái với nguồn, hãy làm hai việc: kiểm tra chỉ dẫn grounding trong system prompt còn nguyên không, và chạy lại trên phiên bản model trước để xem có phải do model. Đổi embedding, giảm temperature hay tăng context không giúp tìm ra nguyên nhân.

Mẹo xử lý thêm

Các cách tối ưu

Ghép lại thành kiến trúc định tuyến: yêu cầu tương tác dùng tier nhanh, streaming và prefix đã cache. Việc nặng suy luận dùng tier mạnh. Việc số lượng lớn, không gấp dùng Batch API.

Message Batches API

Công thức thời gian

Tổng thời gian = thời gian chờ đến lô kế tiếp + 24 giờ. Nếu cam kết trả trong 30 giờ thì thời gian chờ tối đa là 6 giờ, nên phải gửi lô ít nhất 6 giờ một lần.

Có request lỗi trong lô? Dùng custom_id để tìm đúng các request đó, sửa (ví dụ chia nhỏ tài liệu quá dài) rồi chỉ gửi lại chúng.

Đã đối chiếu tài liệu chính thức

Mỗi lô tối đa 100.000 request hoặc 256 MB. Lô chưa xong sau 24 giờ thì hết hạn, và request hết hạn không bị tính phí. Kết quả được giữ 29 ngày. Xem docs

Khi nào cần người

Lấy mẫu khi không thể duyệt hết

Dùng risk-stratified sampling: duyệt toàn bộ kết quả có độ tin cậy thấp hoặc tác động lớn, và một mẫu ngẫu nhiên nhỏ của phần còn lại. Lấy mẫu đều mọi kết quả sẽ tốn công vào các ca rủi ro thấp.

Thiết kế quy trình người duyệt

Lưu quyết định của người duyệt thành dữ liệu có nhãn và đưa dần vào tập eval. Người duyệt phải được phép không đồng ý với model, nếu không dữ liệu đó sẽ vô giá trị.

Bẫy đề thi

Độ tự tin do model tự báo không phải cổng kiểm soát đáng tin. Hãy dùng các tín hiệu từ code.

Discernment: đánh giá kết quả AI

Discernment là một trong 4 năng lực của khung AI Fluency (Delegation, Description, Discernment, Diligence), nghĩa là đánh giá chính xác mức độ hữu ích của kết quả và hành vi của AI.

Bẫy đề thi

Đừng duyệt ra mắt chỉ vì một chỉ số đẹp. Hãy hỏi chỉ số đó có thực sự đo đúng chất lượng cần đo không.

Nhớ nhanh

Quiz Domain 4

3 bài · 30 câu