- Với sự xuất hiện của API LLM, nhà khoa học dữ liệu và MLE đã bị gạt khỏi tuyến đường trọng yếu để phát hành AI, nhưng bản chất của công việc thực tế — thiết kế thí nghiệm, đo lường chỉ số, gỡ lỗi hệ thống xác suất — không hề biến mất
- Cả trường hợp Codex của OpenAI lẫn dự án auto-research của Karpathy đều cho thấy cốt lõi là harness gồm test, chỉ số và stack quan sát; và phần lớn harness này chính là khoa học dữ liệu
- 5 cạm bẫy eval lặp đi lặp lại ngoài thực tế — chỉ số chung chung, mô hình giám khảo chưa được kiểm chứng, thiết kế thí nghiệm sai, dữ liệu và nhãn kém chất lượng, tự động hóa quá mức — đang làm suy giảm chất lượng của các hệ thống AI
- Nguyên nhân chung của từng cạm bẫy là thiếu nền tảng khoa học dữ liệu, và lời giải vẫn chính là các phương pháp vốn có như phân tích dữ liệu khám phá, đánh giá mô hình, thiết kế thí nghiệm, thu thập dữ liệu và production ML
- "Tự mình nhìn vào dữ liệu" là hoạt động có ROI cao nhất nhưng lại thường xuyên bị bỏ qua nhất, và vai trò của nhà khoa học dữ liệu vẫn là cốt lõi ngay cả trong kỷ nguyên LLM
Sự trở lại của nhà khoa học dữ liệu
- Nhà khoa học dữ liệu từng được gọi là "nghề quyến rũ nhất thế kỷ 21" và nhận mức đãi ngộ cao
- Đòi hỏi tổ hợp kỹ năng phức hợp như mô hình hóa dự đoán, đo lường quan hệ nhân quả, khám phá mẫu dữ liệu
- Sau đó, công việc mô hình hóa dự đoán được tách riêng thành Machine Learning Engineer (MLE)
- Sự xuất hiện của LLM (mô hình ngôn ngữ lớn) đã tạo ra thay đổi khi doanh nghiệp triển khai AI mà không còn cần nhà khoa học dữ liệu hay MLE trong tuyến bắt buộc
- Thông qua Foundation Model API, các nhóm có thể tự tích hợp AI một cách độc lập
- Nhưng huấn luyện mô hình không phải là toàn bộ công việc của nhà khoa học dữ liệu, và thiết kế thí nghiệm, gỡ lỗi, thiết kế chỉ số vẫn là phần việc cốt lõi
- Chỉ gọi API LLM không làm những công việc này biến mất
- Bài trình bày “The Revenge of the Data Scientist” tại PyAI Conf bàn về điều này bằng các ví dụ cụ thể, nhấn mạnh rằng vai trò của khoa học dữ liệu vẫn rất quan trọng
Bản chất của Harness chính là khoa học dữ liệu
- Khái niệm Harness Engineering của OpenAI mô tả cấu trúc trong đó tác tử tự chủ phát triển mã trong một môi trường được bao quanh bởi test và đặc tả
- Harness bao gồm stack quan sát như log, metric, trace, giúp tác tử tự phát hiện hành vi bất thường
- Dự án auto-research của Andrej Karpathy cũng cho thấy cùng một mẫu hình là tối ưu lặp dựa trên chỉ số validation loss
- "Gọi LLM như một API" không xóa bỏ công việc thiết kế thí nghiệm, gỡ lỗi và thiết kế chỉ số; phần lớn harness chính là khoa học dữ liệu
- Trước đây, người ta dành nhiều thời gian để kiểm tra dữ liệu, xác nhận tính nhất quán của nhãn và thiết kế metric
- Hiện nay lại có xu hướng dựa vào “cảm giác” của mô hình, hoặc dùng nguyên xi thư viện metric mã nguồn mở
- Đặc biệt trong các lĩnh vực RAG (Retrieval-Augmented Generation) và Evals, có rất nhiều hiểu lầm do thiếu hiểu biết về dữ liệu
- Có những tuyên bố như RAG is dead, evals are dead, nhưng chính các đội ngũ đưa ra tuyên bố đó lại đang xây dựng những hệ thống phụ thuộc vào các khái niệm ấy
- Hiện tượng các kỹ sư không có nền tảng dữ liệu sợ và né tránh những gì họ không hiểu đặc biệt rõ trong mảng retrieval và evals
- "Gọi LLM như một API" không xóa bỏ công việc thiết kế thí nghiệm, gỡ lỗi và thiết kế chỉ số; phần lớn harness chính là khoa học dữ liệu
5 cạm bẫy Eval
-
Cạm bẫy 1: Chỉ số chung chung (Generic Metrics)
- Các chỉ số chung chung như helpfulness score, coherence score, hallucination score quá rộng để chẩn đoán sự cố thực tế của ứng dụng
- Nhà khoa học dữ liệu sẽ không chấp nhận ngay các chỉ số đó mà trực tiếp khám phá dữ liệu và trace để xác định trước "thực sự cái gì đang hỏng"
- "Nhìn vào dữ liệu" nghĩa là trực tiếp đọc trace, tự tạo trace viewer tùy biến và làm error analysis để phân loại thất bại
- Các chỉ số tương đồng chung chung như ROUGE, BLEU hầu như không phù hợp với đầu ra LLM; cần những chỉ số đặc thù ứng dụng như "Calendar Scheduling Failure" hay "Failure to Escalate To Human"
- Nhìn vào dữ liệu là hoạt động có ROI cao nhất nhưng cũng thường xuyên bị lược bỏ nhất
-
Cạm bẫy 2: Mô hình giám khảo chưa được kiểm chứng (Unverified Judges)
- Phần lớn các đội dùng LLM làm giám khảo đều không có câu trả lời cho câu hỏi "làm sao tin được giám khảo này"
- Nhà khoa học dữ liệu đối xử với giám khảo như một classifier, thu thập nhãn từ con người rồi chia thành train/dev/test để đo độ tin cậy
- Ví dụ few-shot được lấy từ tập huấn luyện, prompt cho giám khảo được cải thiện bằng dev set, còn test set được giữ lại để kiểm tra overfitting
- Khi báo cáo kết quả, nên dùng precision và recall thay vì chỉ accuracy — ngay cả khi failure mode chỉ chiếm 5%, accuracy vẫn có thể che giấu hiệu năng thực tế
- Việc kiểm chứng classifier đã trở thành một kỹ năng bị thất truyền trong AI hiện đại
-
Cạm bẫy 3: Thiết kế thí nghiệm tệ (Bad Experimental Design)
- Xây dựng test set: đa số các đội chỉ yêu cầu LLM “hãy tạo 50 truy vấn kiểm thử”, nhưng cách này sinh ra dữ liệu chung chung không mang tính đại diện
- Nhà khoa học dữ liệu sẽ xem dữ liệu production thực tế trước, xác định các chiều quan trọng rồi tạo ví dụ tổng hợp phù hợp với các chiều đó
- Cần tạo dữ liệu tổng hợp dựa trên log hoặc trace thực tế, đồng thời đưa thêm các edge case
- Thiết kế chỉ số: đưa toàn bộ rubric vào một lần gọi LLM duy nhất rồi mặc định dùng thang Likert 1–5 là cách che giấu sự mơ hồ và trì hoãn những quyết định khó về hiệu năng hệ thống
- Nên thay bằng phán định nhị phân (pass/fail) cho các tiêu chí có phạm vi hẹp
-
Cạm bẫy 4: Dữ liệu và nhãn kém chất lượng (Bad Data and Labels)
- Vì việc gán nhãn không hào nhoáng, nó thường bị giao cho đội phát triển hoặc thuê ngoài; nhưng nhà khoa học dữ liệu sẽ yêu cầu chuyên gia miền trực tiếp gán nhãn
- Ngoài chất lượng nhãn còn có một lý do sâu hơn: khái niệm "criteria drift" được xác thực trong các bài báo của Shreya Shankar và cộng sự — người dùng cần tiêu chí để đánh giá đầu ra, nhưng chính trong quá trình đánh giá đầu ra họ mới định hình được tiêu chí. Tức là họ không biết mình muốn gì cho đến khi nhìn thấy đầu ra của LLM
- Cần đặt chuyên gia miền và PM trước dữ liệu thô, chứ không phải trước điểm tóm tắt
-
Cạm bẫy 5: Tự động hóa quá mức (Automating Too Much)
- LLM có thể giúp viết plumbing code, tạo boilerplate và nối các bước đánh giá
- Nhưng việc trực tiếp nhìn vào dữ liệu thì không thể tự động hóa — vì "không biết mình muốn gì cho đến khi thấy đầu ra"
- Các cạm bẫy bổ sung khác được nhắc đến gồm: lạm dụng điểm tương đồng, hỏi giám khảo những câu mơ hồ như "có hữu ích không?", bắt người chú thích đọc raw JSON, báo cáo điểm chưa hiệu chỉnh mà không có khoảng tin cậy, data drift, overfitting, sampling sai, dashboard khó hiểu
Ánh xạ với nền tảng khoa học dữ liệu
- Cả 5 cạm bẫy đều có cùng một nguyên nhân gốc là thiếu nền tảng khoa học dữ liệu
- Tương ứng giữa từng cạm bẫy và các phương pháp luận hiện có:
- Đọc trace và phân loại thất bại → phân tích dữ liệu khám phá (EDA)
- Kiểm chứng giám khảo LLM bằng nhãn con người → đánh giá mô hình (Model Evaluation)
- Xây dựng test set đại diện dựa trên dữ liệu production → thiết kế thí nghiệm (Experimental Design)
- Chuyên gia miền gán nhãn → thu thập dữ liệu (Data Collection)
- Giám sát sản phẩm vận hành trong production → production ML
- Tên gọi đã thay đổi, nhưng bản chất công việc vẫn như cũ
- Python vẫn là bộ công cụ tối ưu để khám phá và xử lý dữ liệu
- Công bố công cụ phân tích pipeline eval và chẩn đoán phần sai lệch thông qua plugin mã nguồn mở (evals-skills)
2 bình luận
Ý kiến trên Hacker News
Đây là những thực hành tốt khi xây dựng giải pháp GenAI, nhưng tôi không nghĩ sự thay đổi này đảm bảo tính bền vững của vị trí data scientist
Trước đây, data scientist được chú ý vì khả năng tự xây dựng mô hình để tạo ra giá trị kinh doanh
Nhưng giờ đây, các nhà cung cấp LLM và những kỹ sư gọi API đang thay thế vai trò đó. Việc điều chỉnh hành vi của LLM giống một kiểu black magic, nhưng không nhất thiết đòi hỏi kiến thức toán học
Giờ phần việc còn lại là đánh giá và giám sát, nhưng xét từ góc độ kinh doanh thì đây không có vẻ là ‘giá trị cốt lõi’. Với những tổ chức muốn tung prototype thật nhanh, nó thậm chí còn bị xem là yếu tố cản trở
Cuối cùng rơi vào tình huống phải thuyết phục rằng “data scientist nên là người gác cổng cho việc xây dựng LLM”, nhưng tôi nghi ngờ lập luận đó sẽ thuyết phục đến đâu
Tuy vậy, tôi vẫn nghĩ ngoài LLM ra vẫn còn nhiều lĩnh vực cần mô hình ML tùy chỉnh. Ví dụ như xếp hạng tìm kiếm của AirBnB hay thuật toán ghép nối của Uber thì không thể thay bằng LLM
Cuối cùng thì đúng là thị trường đã thu hẹp, nhưng chưa biến mất hoàn toàn
Nhưng quá trình đó buộc ta phải định nghĩa rõ “ta đang muốn giải quyết điều gì”. Đôi khi câu trả lời có thể là “sản phẩm này không đáng để làm”
Chỉ là hầu như chẳng ai muốn nghe điều đó
AI engineer xuất thân từ SWE thường còn phù hợp hơn. Vì tư duy “đánh giá = kiểm thử tự động” đến với họ rất tự nhiên
Thực tế trong nhiều dự án agent, vai trò của DS gần như đang biến mất
Đây là lời khuyên tôi thường dành cho data scientist
Nếu muốn dùng LLM làm giám khảo, thì bản thân mô hình đó rốt cuộc cũng phải học in-context từ dữ liệu ví dụ tốt
Tôi đã tổng hợp nội dung liên quan trong cuốn sách của mình
Tuy nhiên, khi một mô hình phải đánh giá đầu ra của mô hình khác thì nó trở thành một cấu trúc siêu cấp, và cuối cùng ở đâu đó vẫn phải cố định một ‘đáp án đúng’ thực sự
Tôi có nền tảng về data science/engineering
Việc dùng AI giống như khám phá không gian lời giải. Đó là quá trình tìm điểm tối ưu trong hàng tỷ tổ hợp tham số
Ta dùng prompt để thu hẹp không gian tìm kiếm, rồi dùng heuristic dựa trên ngữ nghĩa để tìm lời giải tốt hơn
Nhiều khi bị kẹt ở cực trị cục bộ, hoặc đi hẳn sang một hướng sai. Vì thế mỗi tuần tôi lại bắt đầu mới codebase để đơn giản hóa hoặc thêm tính năng. Làm vậy mới có thể tìm ra lời giải tốt hơn
Tôi nghĩ các trường hợp như pg_textsearch được nhắc gần đây là ví dụ cho thấy kiểu phát triển này rất phù hợp
Khi có test case và benchmark rõ ràng thì xác suất thành công sẽ cao
Nhưng trong phát triển greenfield, việc định nghĩa test case khó ngang hoặc còn khó hơn cả viết code
Ngoài ra, LLM thường có xu hướng mắc kẹt ở cực tiểu cục bộ. Khi cấu trúc code đã cứng lại, nó gần như không thử các đợt refactor lớn. Đây là hiện tượng khá giống overfitting
Có người nói cốt lõi của thử nghiệm AI là kiểm chứng xem mô hình khái quát hóa tốt đến mức nào với dữ liệu mới, nhưng trên thực tế lại thiếu mất bước xác nhận rõ ràng “dữ liệu là gì”
Vì nhiều khi dữ liệu mọi người hình dung khác với dữ liệu thực tế
Với tôi, thay vì tạo ra một workflow LLM-làm-giám-khảo phức tạp, việc quan sát trực tiếp hành vi của agent đem lại nhiều insight hơn hẳn
Hôm qua tôi đã thử áp dụng cách tiếp cận autoresearch của Karpathy vào một bài toán ML
Sau nhiều lần thử nghiệm, tôi ngạc nhiên trước kết quả mà mô hình cho ra. Nếu Kaggle vẫn còn sôi động như trước, có lẽ AI đã thắng phần lớn các bài toán rồi
Nhưng công việc data science ngoài đời thực thì phần lớn là những người còn chưa nắm vững cả công cụ cơ bản. Chỉ đưa AI cho họ cũng không khiến họ đột nhiên giỏi lên
Rốt cuộc các chuyên gia vẫn sẽ tiếp tục sai junior làm việc, còn những người không chuyên thì loay hoay trong các kết quả chắp vá
Nhưng công việc DS thực tế chủ yếu là xử lý dữ liệu không hoàn chỉnh và mục tiêu mơ hồ
Một DS giỏi phải biết nói “cái này không làm được”. Trong khi đó LLM thì lúc nào cũng chỉ nói “được đấy, ý tưởng hay đấy!”
Cuối cùng thì phát triển với AI cũng là một vòng lặp tương tự — “định nghĩa thế nào là kết quả tốt, đo khoảng cách tới đó, rồi cải thiện lặp đi lặp lại”
Chỉ là những người đã suy nghĩ theo cách này từ lâu thì đi trước prompt engineer rất xa
Không rõ ở đây có các anh/chị DS nào đã để lại bình luận chưa. Có vẻ như mọi người đều đang nhìn từ góc độ của lập trình viên...