
Một ngày của nhà khoa học dữ liệu vào năm 2026
Trí tuệ nhân tạo (AI) đã thay đổi mạnh mẽ quy trình làm việc hằng ngày của tôi như thế nào Bài viết Cách một nhà khoa học dữ liệu làm việc trong năm 2026 xuất hiện lần đầu trên Towards Data Science.
Khoa học Dữ liệu
Một ngày của nhà khoa học dữ liệu vào năm 2026
AI đã thay đổi đáng kể quy trình làm việc hằng ngày của tôi như thế nào
Haden Pelletier
Ngày 14/8/2026
5 phút đọc
Ảnh: Ofspace LLC trên Unsplash
Hai năm trước, một ngày của tôi hoàn toàn khác biệt
Dù khó tin, nhưng hai năm trước, tôi vẫn viết và gỡ lỗi mã hằng ngày. Từng dòng một. Gần như đập đầu vào bàn sau 2 giờ gỡ lỗi mà không có kết quả. Nghe có vẻ điên rồ, phải không?
Một ngày bình thường của tôi:
Viết (và gỡ lỗi) mọi truy vấn SQL và tập lệnh Python từ đầu.
Xây dựng các bản trình bày từng gạch đầu dòng.
Viết tài liệu mà không ai đọc cho đến khi có sự cố (và ngay cả khi đó, họ cũng hiếm khi đọc).
Tôi đã viết về một ngày làm việc của mình với tư cách là nhà khoa học dữ liệu vào năm 2024. Và gần như không có điều nào trong số đó giống với ngày thứ Ba thực tế của tôi hiện nay.
Tôi sẽ không giả vờ rằng điều đó hoàn toàn tốt. Có những ngày, tôi cảm thấy công việc của mình không hề dễ dàng hơn mà giống như nó đã âm thầm biến thành một công việc khác. Một công việc mà tôi phải học hỏi nhanh chóng, trong khi vẫn đang làm công việc cũ.
(Và vâng, tôi biết có rất nhiều nhà khoa học dữ liệu vẫn đang làm nhiều việc mà tôi đã làm hai năm trước, nhưng đây là kinh nghiệm của tôi cũng như kinh nghiệm của nhiều nhà khoa học dữ liệu mà tôi biết hiện nay).
Kỹ thuật tạo lời nhắc (Prompt Engineering) là một phần quan trọng của công việc
Hình ảnh được tạo bởi tác giả sử dụng Claude
Vâng, chúng tôi đã có ChatGPT vào năm 2024. Chúng tôi đã có kỹ thuật tạo lời nhắc. Nhưng tôi không sử dụng nó vì ChatGPT thường khiến tôi thất vọng. Việc giải thích ngữ cảnh đằng sau những gì tôi đang làm trước khi đưa mã của mình cho ChatGPT tốn nhiều công sức hơn, và ngay cả khi đó, nó vẫn dường như không thể tìm ra lỗi.
Những tiến bộ trong AI, đặc biệt là với Claude, đã thay đổi nhiều thái độ đó. Những tính năng như dự án và kỹ năng đã giúp việc thảo luận dự án của bạn với một AI đã biết ngữ cảnh và lịch sử của nó trở nên dễ dàng hơn nhiều.
Vì vậy, một phần đáng kể trong ngày của tôi hiện nay dành cho việc viết và tinh chỉnh các lời nhắc. Ban đầu, các lời nhắc của tôi rất sơ sài. Chẳng hạn như:
Tóm tắt độ chính xác dự báo cho mô hình này.
Điều này mang lại cho bạn một đoạn văn mơ hồ thường không chứa những thông tin chi tiết mà bạn thực sự muốn. Bây giờ tôi viết các lời nhắc gần giống như:
Tóm tắt độ chính xác dự báo của mô hình này trong 14 ngày qua. Báo cáo chính xác MAPE và RMSE cho mỗi ngày, đánh dấu bất kỳ ngày nào mà MAPE vượt quá 5%, và cho biết liệu xu hướng đang cải thiện hay suy giảm theo tuần. Không làm tròn các chỉ số lỗi, báo cáo chúng với hai chữ số thập phân.
Sự khác biệt về chất lượng đầu ra là rất lớn, và thành thật mà nói, đó hiện là một kỹ năng mà tôi phải tích cực củng cố.
Một vài điều hiện là một phần trong quy trình làm việc thường xuyên của tôi:
Kiểm tra kỹ đầu ra của mô hình LLM.
Kiểm tra các biến thể lời nhắc với cùng một tác vụ và so sánh các đầu ra cạnh nhau.
Viết các ràng buộc trực tiếp vào lời nhắc (đơn vị, độ chính xác thập phân, những gì không được đoán) thay vì sửa lỗi đầu ra sau đó.
Tìm kiếm các giải pháp LLM hiệu quả về chi phí và cắt giảm mức sử dụng token
Hình ảnh được tạo bởi tác giả sử dụng Claude
Các mô hình LLM rất tốn kém. Tốn kém hơn nhiều so với các mô hình XGBoost. Điều này có nghĩa là cần cân nhắc nhiều hơn khi sử dụng LLM để phân tích các tập dữ liệu lớn.
Tuy nhiên, các nguyên tắc khoa học dữ liệu tương tự vẫn được áp dụng:
Khi một phương pháp heuristic hoặc mô hình đơn giản hơn có thể thực hiện tác vụ, hãy luôn ưu tiên sử dụng phương pháp đó trước.
Luôn làm sạch dữ liệu của bạn trước khi đưa vào mô hình. Dữ liệu rác đầu vào sẽ cho ra kết quả rác.
Thực hiện chọn lọc tính năng (feature selection) và chỉ chọn các tính năng có ý nghĩa trước khi huấn luyện một mô hình học máy (ML model) để tránh đưa vào hàng trăm tính năng ngẫu nhiên, gây ra hiện tượng quá khớp (overfitting) hoặc quá nhiều nhiễu.
Những nguyên tắc này cũng rất phù hợp với các mô hình ngôn ngữ lớn (LLM). Không phải mọi tác vụ đều cần đến mô hình lớn nhất, đắt tiền nhất hiện có. Việc phân loại một phiếu hỗ trợ hoặc trích xuất ngày tháng từ một tài liệu không đòi hỏi sức mạnh xử lý tương đương với việc tóm tắt một hợp đồng dài 40 trang. Chuyển các tác vụ đơn giản cho một mô hình nhỏ hơn, rẻ hơn và dành mô hình đắt tiền cho các tác vụ cần thiết đã trở thành một đòn bẩy tiết kiệm chi phí thực sự.
Dưới đây là một số ví dụ về cách tôi hạn chế chi phí:
Làm sạch dữ liệu để giảm kích thước đầu vào (ví dụ: loại bỏ các liên kết, hình ảnh và các ký tự khác không liên quan đến mô hình khỏi một chuỗi email).
Lưu trữ bộ nhớ đệm (caching) các lệnh gọi lặp lại thay vì chạy lại cùng một lời nhắc (prompt) với cùng một đầu vào.
Sử dụng học máy truyền thống (traditional ML) khi thích hợp thay vì dùng LLM cho mọi thứ.
Theo dõi chi phí token cho mỗi tác vụ.
Nghiên cứu các phương pháp hay nhất để giảm mức sử dụng token.
Giao tiếp và Thuyết trình với các bên liên quan
Ảnh của Campaign Creators trên Unsplash
Đây là nơi phần lớn thời gian tiết kiệm được được sử dụng: các cuộc họp, các trang trình bày (slides) và việc chuyển đổi kết quả của mô hình thành thông tin mà một bên liên quan không chuyên về kỹ thuật có thể hành động.
Trước đây, tôi thường mất hàng giờ để xây dựng một bản trình bày từ đầu. Giờ đây, tôi có thể tạo một bản nháp sơ bộ của bảng điều khiển hoặc dàn ý trang trình bày sẵn sàng cho các bên liên quan chỉ trong vài phút, điều này nghe có vẻ sẽ giúp tôi có một buổi chiều rảnh rỗi. Trên thực tế, điều đó chỉ có nghĩa là tôi dành thời gian rảnh rỗi đó cho nhiều cuộc họp hơn, hướng dẫn mọi người về những gì mô hình đã tìm thấy và tại sao nó lại quan trọng, bởi vì thời gian hoàn thành nhanh đến mức các bên liên quan mong đợi được kiểm tra thường xuyên hơn.
Kỹ năng thực sự quan trọng ở đây không thay đổi: đó là biến một sự thật kỹ thuật thành một điều mà người quản lý sản phẩm hoặc giám đốc điều hành có thể đưa ra quyết định. AI có thể soạn thảo trang trình bày. Nó không thể quyết định điểm chính của trang trình bày là gì (đó vẫn là việc của tôi).
Kết luận
Ngay cả với tất cả những điều này, phần lớn công việc của tôi về cơ bản vẫn như cũ. Tôi vẫn có các cuộc họp và cần hợp tác với các thành viên trong nhóm. Tôi vẫn phải quyết định điều gì đáng để mô hình hóa ngay từ đầu. Tôi vẫn phải phát hiện khi một bản tóm tắt do AI tạo ra tự tin khẳng định điều gì đó không đúng sự thật. Tôi vẫn phải hiểu rõ lĩnh vực đủ để nhận ra khi một con số trông hơi sai thay vì sai rõ ràng. Và tôi vẫn sử dụng học máy truyền thống khi cần thiết.
Nếu có bất kỳ điều gì, thì khả năng phán đoán đó giờ đây càng quan trọng hơn, chứ không phải ít hơn, bởi vì đó là phần duy nhất trong ngày chưa bao giờ được tự động hóa.



Nguồn tin: Towards Data Science — Tác giả: Haden Pelletier. Bản dịch tiếng Việt do AI thực hiện, có thể có sai sót.