Ảo tưởng GPU và thực tế 2%

Khi nói đến AI hay Machine Learning, đa số người hình dung kỹ sư ngồi trước rack GPU, chỉnh hyperparameter và chờ model thông minh hơn. Media nuôi dưỡng hình ảnh đó — headline luôn nhấn model mới, benchmark mới, chip mới.

Nhưng nếu hỏi người làm ML production, câu trả lời khá khác.

Trong giới ML có câu nói nửa đùa nửa thật: khoảng 50% công việc nằm ở evaluation, 40% ở làm sạch dữ liệu, 8% ở tích hợp hệ thống, còn training chỉ ~2%. Con số không phải định luật, nhưng phản ánh đúng thứ tự ưu tiên thời gian của đa số đội — đặc biệt sau giai đoạn proof-of-concept.

Training vẫn quan trọng. Nhưng phần lớn rủi ro và chi phí nằm ở chỗ khác, và nhiều team mới đang đầu tư sai chỗ.

Phân bổ thời gian công việc ML thực tế (meme nội bộ ngành)

Model không cứu được ontology sai

Lý do cốt lõi: model không học được thứ không có trong data, và không sửa định nghĩa sai từ đầu.

Ví dụ tưởng chừng đơn giản: AI phân loại email spam. Trên slide là binary classification kinh điển. Thực tế, câu hỏi nhân lên:

  • Email quảng cáo Shopee có phải spam không?
  • Email khuyến mãi ngân hàng thì sao?
  • User đã opt-in nhận email, còn gọi spam không?
  • Email sếp đính kèm marketing — xếp vào đâu?

Trước khi viết dòng training đầu tiên, con người phải tranh luận và thống nhất quy tắc. Tập hợp định nghĩa, ranh giới và quan hệ khái niệm đó gọi là ontology — "cách chúng ta định nghĩa thế giới cho AI".

Ontology sai hoặc không nhất quán, model học từ dữ liệu mâu thuẫn. Không kiến trúc nào suy luận ra đáp án đúng khi ground truth đang tranh cãi với chính mình.

Ảo tưởng phổ biến
  • 80% thời gian train trên GPU cluster
  • Thắng nhờ model benchmark cao hơn
  • Vấn đề = chọn architecture đúng
  • Ship khi loss curve hội tụ
Thực tế production
  • 90% thời gian ontology + data + eval
  • Thắng nhờ hiểu bài toán và label nhất quán
  • Vấn đề = định nghĩa 'đúng' mâu thuẫn
  • Ship khi ground truth ổn định

Mâu thuẫn từ y tế đến xe tự lái

Trong chẩn đoán ung thư, hai bác sĩ nhìn cùng ảnh X-quang: một gắn "khối u", một gắn "bình thường" — model không biết tin ai. Accuracy lúc đó chỉ đo mức nhất quán của sự không nhất quán.

Trong xe tự lái, team phải định nghĩa rõ người đi bộ, xe đạp, xe máy, vật cản. Xe máy đôi khi label "xe đạp", đôi khi "ô tô" — perception model mạnh vẫn học thế giới mâu thuẫn. Edge case trên đường không phải surprise; là hệ quả ontology lỏng.

Đó là lý do đội ML dành nhiều thời gian tranh luận ontology, đánh giá và sửa dữ liệu — thường nhiều hơn model.fit().

Ontology quyết định trần của model

Model không học được khái niệm không có trong data và không sửa label disagreement. GPU và thuật toán chỉ tối ưu trong không gian định nghĩa đã thống nhất — ontology sai thì mọi metric chỉ đo mức nhất quán của sự mâu thuẫn.

Evaluation và data cleaning — 90% thời gian thực

Evaluation (50%) không chỉ chạy accuracy. Đó là vòng lặp: model sai ở đâu — data noise, label sai, distribution shift, hay định nghĩa lỗi thời? Mỗi lần phân loại lỗi, team quay về sửa ontology hoặc relabel.

Data cleaning (40%) không chỉ drop null. Là duplicate gắn nhãn khác nhau, outlier do log sai, bias sampling, leakage train/test. Dữ liệu "bẩn" ở tầng định nghĩa tốn thời gian nhất.

Integration (8%) là nơi project thường chết: latency, monitoring drift, fallback khi uncertain, versioning label schema. Training 2% đôi khi ít drama nhất.

  1. 1Định nghĩa ontologyThống nhất ranh giới, quy tắc label, edge case — trước mọi dòng code
  2. 2Thu thập & làm sạchRelabel mâu thuẫn, fix bias sampling, loại leakage — ~40% thời gian
  3. 3Train modelChạy experiment, tune hyperparameter — thường chỉ ~2% tổng effort
  4. 4Evaluation sâuPhân loại lỗi, quay lại sửa ontology hoặc data — ~50% thời gian
  5. 5Integrate & monitorDeploy, drift monitoring, review label schema khi thế giới đổi

Production không chấm dứt ontology

Sau khi model production, nhãn cũ vẫn phải review. Thế giới đổi, hành vi user đổi, "đúng" hôm qua có thể sai hôm nay. Email marketing từng OK có thể thành spam theo quy định mới.

Công ty AI mạnh thường không thắng chỉ nhờ model tốt hơn. Họ thắng vì data tốt hơn, label nhất quán, và hiểu bài toán sâu hơn.

Kết luận

Đừng chỉ hỏi "model nào mạnh nhất?" Hãy hỏi: ontology đã thống nhất chưa? Label disagreement rate bao nhiêu? Evaluation có đo đúng thứ user care không?

Phần khó nhất không nằm ở GPU hay thuật toán. Nó nằm ở câu hỏi tưởng đơn giản: "Rốt cuộc, thế nào mới được gọi là đúng?"

Train model dễ nhìn thấy. Định nghĩa "đúng" mới quyết định project sống hay chết.