Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 3 — Đánh giá (Eval) chất lượng mô hình đa phương thức

Vì sao eval là kỹ năng sống còn của AI PM

Với sản phẩm truyền thống, bạn đo bằng conversion, retention. Với sản phẩm AI, bạn phải đo thêm chất lượng đầu ra của mô hình - và đây là phần nhiều PM bỏ qua rồi phải trả giá. Không có eval nghiêm túc, bạn không biết mô hình có tốt hơn sau khi đổi phiên bản không, không biết feature nào đang làm hỏng trải nghiệm.

Eval multimodal khó hơn eval text vì bạn phải đo chất lượng trên nhiều loại đầu vào và sự tương tác giữa chúng.

Ba tầng eval PM cần biết

  • Eval offline (bộ test cố định): xây một tập dữ liệu vàng (golden set) gồm các cặp đầu vào - đầu ra đúng. Chạy mô hình trên tập này mỗi khi thay đổi để so sánh. Đây là "unit test" cho AI.
  • Eval online (A/B, shadow): đo trên người dùng thật. Shadow mode: chạy mô hình mới song song nhưng không hiển thị, so kết quả với mô hình cũ.
  • Eval con người (human eval): chuyên gia chấm điểm mẫu ngẫu nhiên theo tiêu chí. Không thể thay thế hoàn toàn bằng máy, đặc biệt với tác vụ chủ quan.

Chọn metric theo modality

  • Text đầu ra: độ chính xác (accuracy), độ liên quan (relevance), tỷ lệ bịa (hallucination rate), grounding (bám dữ liệu nguồn).
  • Trích xuất từ ảnh (OCR/vision): field-level accuracy (đúng từng trường), character error rate, tỷ lệ đọc sai số.
  • Audio (Speech-to-Text): Word Error Rate (WER) - đo tỷ lệ từ sai; đo riêng theo accent, độ ồn.
  • Sinh ảnh/audio: cần human eval hoặc metric chuyên biệt vì "đẹp/tự nhiên" khó đo tự động.
Khung tư duy quan trọng: mỗi metric phải gắn với một ngưỡng chấp nhận (threshold) do nghiệp vụ quyết định. Ví dụ với app tài chính, tỷ lệ đọc sai số tiền phải dưới 0,5%; nếu không đạt, không được ship.

LLM-as-a-judge và cạm bẫy của nó

Dùng một mô hình mạnh để chấm điểm đầu ra của mô hình khác giúp mở rộng eval rẻ và nhanh. Nhưng cẩn thận:

  • Mô hình chấm có thể thiên vị câu trả lời dài, trôi chảy dù sai.
  • Cần "calibrate" (hiệu chỉnh) bằng cách so kết quả judge với chấm điểm của con người trên một mẫu.
  • Không dùng cùng một mô hình vừa sinh vừa tự chấm cho các quyết định quan trọng.

Ví dụ cụ thể: Eval cho app đọc hóa đơn

Golden set: 500 hóa đơn đã gán nhãn tay (số tiền, ngày, nhà cung cấp). Metric chính: field-level accuracy cho từng trường. PM đặt ngưỡng: số tiền ≥ 99,5%, ngày ≥ 98%. Phân tích thêm theo lát cắt (slice): hóa đơn viết tay vs in, ảnh sáng vs tối. Nếu accuracy tổng là 97% nhưng ảnh tối chỉ 80%, đó là tín hiệu cần cải thiện tiền xử lý ảnh, không phải mô hình chính.

Checklist eval trước khi ship

  • [ ] Có golden set đại diện cho dữ liệu thật (kể cả case khó) chưa?
  • [ ] Mỗi metric đã gắn ngưỡng chấp nhận theo nghiệp vụ chưa?
  • [ ] Đã phân tích theo slice (accent, ánh sáng, loại người dùng) chưa?
  • [ ] Có quy trình chạy lại eval mỗi lần đổi mô hình/prompt không?
  • [ ] Nếu dùng LLM-as-judge, đã hiệu chỉnh với con người chưa?

Sai lầm thường gặp

  • Chỉ nhìn số tổng: accuracy trung bình đẹp nhưng che giấu nhóm người dùng bị phục vụ tệ (ví dụ accent vùng miền).
  • Golden set quá dễ: chỉ chứa case lý tưởng, khiến mô hình "đậu" trên test nhưng "rớt" ngoài đời.
  • Tin tuyệt đối vào LLM-as-judge mà không hiệu chỉnh.
  • Không eval lại sau mỗi thay đổi: đổi prompt hay bản mô hình mới nhưng không đo, đến khi người dùng phàn nàn mới biết bị suy giảm (regression).

Tổng kết

Eval là la bàn của AI PM. Với multimodal, hãy đo từng modality bằng metric phù hợp, luôn gắn ngưỡng nghiệp vụ, phân tích theo slice và không tin mù quáng vào máy chấm máy. Eval tốt giúp bạn ship tự tin và bắt regression trước khi người dùng bắt được bạn.

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