Trả lời ngắn: Dataset là tập dữ liệu phục vụ một mục đích; evaluation set là tập case giữ để đo output theo version. Quản lý tốt cần provenance, label policy, split, slice, leakage check, owner và freeze gate. Trong case này, support classifier chỉ được tin khi high-impact cases và lỗi dữ liệu không bị giấu.

Đọc xong, bạn sẽ hiểu:

  • Dataset dùng để xây và evaluation set dùng để đo khác nhau thế nào.
  • Cách ghi nguồn, permission, timestamp và label policy.
  • Vì sao duplicate, future data và high-impact slice làm metric sai.
  • Cách khóa golden set và review version trước khi dùng làm bằng chứng.

Lưu ý giáo dục: Bài chỉ dùng ticket giả và public/synthetic examples. Không dán customer transcript, PII, credential hay dữ liệu riêng vào dataset. Số lượng và tỷ lệ trong bảng chỉ minh họa quy trình, không phải benchmark.

1. Dataset và evaluation set khác nhau thế nào?

Case giả có support classifier route request tới billing, account access, technical hoặc product feedback. Team có 1.000 message examples và nói “đã đủ data”. Nhưng 1.000 dòng có thể toàn request rõ, thiếu refund/high-impact, có duplicate, hoặc chứa answer của tương lai. Chỉ nhìn row count không cho biết dataset có giúp ta đánh giá đúng không.

Dataset là tập dữ liệu phục vụ một mục đích đã xác định. Nó có thể dùng để phát triển, phân tích, tạo prompt hoặc xây test. Evaluation set là tập case giữ để đo output ngoài quá trình tạo hoặc chọn system version. Khi cùng một câu xuất hiện trong quá trình tuning và eval, metric có thể đẹp vì system đã “thấy đề”.

Ta tách vai trò:

Nhóm Mục đích Điều cần giữ
Development Thử prompt/rule/flow Có thể thay đổi, ghi version
Validation Chọn giữa các phương án Chỉ owner được đổi
Evaluation Đo release candidate Giữ ngoài loop tạo
Golden set So qua nhiều version Freeze, change có approval

Hình 1 — Nhiều dòng dữ liệu chưa đủ; cần đi qua label, split, audit và freeze trước khi gọi là evidence.

Ví dụ đời thường: bộ đề luyện, đề thử và đề thi không nên trộn lẫn. Nếu học sinh xem đáp án đề thi trước, điểm cao không chứng minh hiểu bài. Evaluation set cũng cần sự tách biệt để đo có ý nghĩa.

2. Dataset card, provenance và label policy

Provenance là thông tin về nguồn, thời điểm và đường đi của dữ liệu. Dataset card giả nên có:

Field Ví dụ synthetic Câu hỏi kiểm
Purpose Route support request Dùng để build hay eval?
Source 800 synthetic, 200 public examples Có permission không?
Time window 2025-01 đến 2025-06 giả Có trộn future không?
Fields text, language, label, source_id Field nào chứa PII?
Label policy Một request có một primary queue Ambiguous xử lý sao?
Owner/version QA owner, card v2 Ai approve thay đổi?

Label policy là quy tắc gán nhãn nhất quán cho annotator. “Refund” có phải billing, account access hay needs review? Policy cần definition, inclusion, exclusion, example và rule cho ambiguity. Hai annotator bất đồng không nên bị ép chọn im lặng; ghi disagreement để adjudication, tức quy trình giải quyết bất đồng bằng người có trách nhiệm.

PII phải được tối thiểu hóa và redact trước khi lưu. Nếu một example cần email để kiểm format, dùng token giả như [EMAIL], không dùng email thật. Provenance cũng phải ghi permission và retention; public không đồng nghĩa được copy vô hạn. Người quản lý dataset chịu trách nhiệm biết data từ đâu và ai được đọc.

Hình 2 — Dataset card giúp reviewer truy từ một label về source, policy, owner và version.

3. Split, slice và leakage control

Split là cách chia data thành nhóm dùng cho mục đích khác nhau. Split ngẫu nhiên có thể phù hợp một số case, nhưng ticket cùng user hoặc cùng template cần entity split để không rò context. Dữ liệu có timestamp cần time split: train ở quá khứ, eval ở tương lai mô phỏng thực tế.

Leakage là thông tin từ evaluation lọt vào quá trình tạo hoặc chọn output. Các ví dụ:

  • Duplicate hoặc near-duplicate nằm cả development và eval.
  • Nhãn tương lai hoặc outcome đã biết được đưa vào input.
  • Người chọn prompt đọc failure của golden set rồi tinh chỉnh tới khi pass.
  • Template của test xuất hiện nguyên văn trong examples.
Check Cách tìm Nếu fail
Exact duplicate Hash normalized text Loại hoặc chỉ giữ một split
Near duplicate Similarity review synthetic Gắn nhóm, không chia đôi mù
Future leakage So timestamp và outcome Chuyển split/time window
High-impact coverage Đếm slice refund/access/safety Bổ sung hoặc block release
Golden contamination Audit người tạo và log Freeze lại, ghi reason

Slice là nhóm case có đặc điểm chung cần đo riêng: language, long text, missing field, high-impact, ambiguity và policy version. Averages không được che slice đỏ. Nếu classifier đạt 94% clear case nhưng 55% refund case, release gate cần thấy con số thứ hai.

Hình 3 — Split và leakage audit bảo đảm điểm eval nói về generalization, không nói về việc system đã thấy đề.

4. Review, quality và version gate

Chất lượng dataset không chỉ là label accuracy. Checklist có thể gồm coverage, label agreement, ambiguity, privacy, provenance, slice balance, duplicate rate và freshness. Khi annotator bất đồng, giữ cả hai nhãn và decision của adjudicator; đừng xóa dấu vết để agreement trông đẹp.

Trước khi freeze evaluation set, review owner kiểm:

  1. Dataset card có source, permission, time window, fields và retention.
  2. Label policy có positive, negative, ambiguous examples.
  3. Split không có duplicate/future leakage chưa xử lý.
  4. High-impact slice có đủ case và expected handling.
  5. Golden set có version, checksum giả, owner và reason khi đổi.
  6. Eval report tách average, slice, failure sample và uncertainty.

Azure evaluation guidance khuyến nghị đánh giá RAG theo nhiều chiều như groundedness, relevance và completeness; nguyên tắc tương tự áp dụng cho dataset classifier: metric chỉ có nghĩa khi biết slice, evidence và limitation. NIST AI RMF đặt đo lường và quản trị trong lifecycle, không chỉ lúc demo. Azure RAG evaluation và NIST AI RMF Core

5. Sai lầm, giới hạn và fallback

  • Row-count worship: thêm dòng mà không thêm coverage. Fallback là gap map và slice count.
  • Label noise: policy mơ hồ làm annotator gán khác nhau. Fallback là adjudication và sửa guideline.
  • Hidden PII: raw transcript lọt vào artifact. Fallback là redact, delete from working copy theo policy và audit access; không log giá trị.
  • Leakage: duplicate/future answer làm eval quá đẹp. Fallback là reset split và ghi contamination incident.
  • Unbalanced class: clear case áp đảo high-impact. Fallback là report per-slice và gate slice quan trọng.
  • Stale golden: policy đổi nhưng golden set không đổi. Fallback là version mới, giữ bản cũ để so và approval.
  • Benchmark gaming: chọn case dễ hoặc sửa nhãn sau khi thấy output. Fallback là freeze trước eval và tách người tạo với người chấm.

Dataset cũng có giới hạn: nhãn người không luôn là truth, public data không đại diện user thật, và một golden set không bao quát mọi drift. Khi coverage không đủ, nói NOT_VERIFIED cho slice đó. A dataset tốt giúp biết mình chưa biết gì; nó không biến uncertainty thành accuracy.

6. Practice Bridge 15 phút

Mở notes hoặc Google Sheets miễn phí, tạo cột purpose, source, permission, time, label policy, split, slice, leakage check, owner, version, decision. Dùng 10 ticket giả, không dùng dữ liệu thật và không upload lên tool lạ.

Mẫu đối chiếu đã điền

Case Card/split evidence Risk và owner Quyết định
D-01 clear Synthetic, policy v1, time window rõ QA owner Cho development
D-02 duplicate Cùng normalized text ở dev/eval Eval owner Loại duplicate, chưa freeze
D-03 high-impact thiếu Không có refund/access slice Safety owner Block golden set
D-04 ambiguous label Hai annotator khác nhãn Adjudicator Giữ disagreement, review policy

Sau 15 phút, hãy nói được vì sao D-01 dùng để develop nhưng D-02–D-04 chưa đủ cho eval. Nếu provenance, permission hoặc owner thiếu, ghi UNKNOWN và dừng.

7. Tổng kết: data là evidence có nguồn

a. Năm ý chính

  • Dataset và evaluation set có mục đích khác nhau; golden set cần freeze để so version.
  • Dataset card phải ghi provenance, permission, timestamp, fields, label policy và owner.
  • Split theo entity/time khi cần, kiểm duplicate, future leakage và contamination trước khi tin metric.
  • Slice high-impact, language, missing field và ambiguity phải hiện trong report, không bị average che.
  • Disagreement, PII, stale golden hoặc coverage thiếu là tín hiệu review, không phải lỗi nên giấu.

b. Câu hỏi tự kiểm tra

  • Vì sao duplicate trong dev và eval làm metric sai?
  • Dataset card cần provenance và label policy để làm gì?
  • Khi annotator bất đồng, nên xóa một nhãn hay giữ decision trail?
  • Golden set đổi thì cần evidence và owner nào?

c. Gợi ý đáp án

Xem gợi ý câu 1

System có thể đã thấy cùng nội dung trong quá trình tạo, nên điểm eval không phản ánh generalization. Xem lại mục 1 và mục 3.

Xem gợi ý câu 2

Chúng giúp truy nguồn, permission, thời điểm, cách gán nhãn và người chịu trách nhiệm. Xem lại mục 2.

Xem gợi ý câu 3

Giữ disagreement và quyết định adjudication để policy có thể được xem lại; không xóa để làm agreement đẹp. Xem lại mục 2 và mục 4.

Xem gợi ý câu 4

Cần version/reason, audit split, impact report và owner approval; giữ bản cũ để so. Xem lại mục 4 và mục 5.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Dataset Tập dữ liệu phục vụ một mục đích đã xác định.
Evaluation set Tập case giữ để đo output ngoài quá trình tạo model.
Provenance Thông tin về nguồn, thời điểm và đường đi của dữ liệu.
Label policy Quy tắc gán nhãn nhất quán cho annotator.
Split Cách chia data thành nhóm dùng cho mục đích khác nhau.
Slice Nhóm case có đặc điểm chung cần đo riêng.
Leakage Thông tin từ eval lọt vào quá trình tạo hoặc chọn output.
Golden set Bộ eval chuẩn được giữ ổn định để so version.
Adjudication Quy trình giải quyết bất đồng nhãn bằng người có trách nhiệm.

e. Nguồn tham khảo

Bài trước là AI Requirements và Acceptance Criteria #19. Bài tiếp theo là Prompt, Model và Workflow Versioning #21.

Lưu ý giáo dục: Chỉ dùng dataset giả, ghi provenance và redact PII. Không tin evaluation set nếu chưa kiểm leakage, slice high-impact, label disagreement, version và owner approval.