AI Engineer, ML Engineer và FDE: cùng bộ công cụ, khác người chịu trách nhiệm

Mở mẫu JD AI Engineer của Workable, bạn sẽ gặp một dòng rất quen: thành thạo TensorFlow hoặc PyTorch. Các vị trí ML cũng đòi đúng bộ công cụ ấy.

Simplilearn còn thừa nhận một điều thẳng thắn hơn: nhà tuyển dụng thường dùng các chức danh này thay cho nhau.

Nếu công cụ giống nhau và chức danh bị dùng lẫn, câu hỏi hợp lý là AI Engineer, ML Engineer và Forward Deployed Engineer khác nhau ở đâu. Câu trả lời không nằm trong stack kỹ thuật. Nó nằm ở chỗ bạn chịu trách nhiệm trước ai, và khi nào công việc của bạn được tính là xong.

Với một developer Việt muốn chuyển sang FDE, phân biệt này quyết định cách bạn chuẩn bị. Nếu nghĩ FDE chỉ là “AI Engineer giỏi hơn”, bạn sẽ dồn thời gian học thêm framework. Trong khi đó, thứ còn thiếu thường là thói quen làm việc với người dùng thật và đo kết quả bằng cách họ dùng sản phẩm.

Bộ kỹ năng gần như trùng khít

Phần giống nhau lớn hơn nhiều người nghĩ. Các mô tả nghề AI Engineer, từ TechTarget đến Codecademy, gần như thống nhất: đây là người phát triển và huấn luyện hệ thống AI, cần kỹ năng của cả software engineer lẫn data scientist, cộng thêm data engineering.

Phần việc cũng kéo dài tới production: dựng deployment pipeline, quản lý phiên bản model, theo dõi hiệu năng theo thời gian thực, lo luồng dữ liệu và hạ tầng, rồi biến model thành API cho ứng dụng khác gọi.

ML Engineer nằm trên cùng trục đó, chỉ khác độ sâu. Coursera xếp ML engineer vào đội data science, là người nghiên cứu, xây dựng và thiết kế hệ thống ML. Simplilearn phân biệt rằng ML engineer thường đi sâu hơn vào huấn luyện, tối ưu và serving model, còn AI engineer phủ phần ứng dụng rộng hơn.

Một bên đi sâu, một bên trải rộng, nhưng vẫn dùng chung hộp đồ nghề.

Có thể suy ra FDE cũng cần hộp đồ nghề ấy. Khó hình dung ai deploy được hệ thống AI ở môi trường của khách hàng nếu không biết dựng pipeline, quản lý phiên bản và theo dõi model. Vì vậy, khác biệt phải nằm ở chỗ khác.

Ai đặt đề bài?

Futurense, một trang chuyên về định hướng nghề nghiệp, chỉ ra khác biệt cấu trúc rõ nhất. Với AI engineer, trách nhiệm hướng vào trong công ty và phạm vi bài toán do product roadmap quyết định. Với FDE, phạm vi được phát hiện dần trong quá trình làm việc với khách hàng.

FDE Academy, một blog về nghề FDE, nói cùng ý từ phía ML Engineer. Khách hàng của ML engineer là người trong công ty. FDE thì làm việc ngay bên cạnh một khách hàng cụ thể.

Nghe thì giống chuyện tổ chức, nhưng nó đổi hẳn bản chất công việc kỹ thuật. Khi đề bài đến từ roadmap, ai đó đã làm giúp bạn phần khó nhất: quyết định nên giải bài toán nào. Khi phải tự tìm phạm vi ở chỗ khách hàng, customer discovery trở thành một phần của kỹ thuật. Chọn sai bài toán thì pipeline đẹp đến mấy cũng vô nghĩa.

Thước đo đổi thì chữ “xong” cũng đổi

Futurense viết rằng thành công của FDE được đo bằng kết quả ngoài thực tế, không chỉ bằng hiệu năng model. FDE Academy nói thẳng hơn: một model xuất sắc về kỹ thuật mà không được dùng vẫn là thất bại theo tiêu chuẩn FDE. FDE được đo bằng mức độ người dùng chấp nhận và kết quả kinh doanh, và vẫn chịu trách nhiệm sau ngày launch.

Thử hình dung một tình huống giả định. Một ngân hàng cần phân loại hồ sơ vay, mỗi ngày có 200 hồ sơ. Đội kỹ thuật train được model đạt F1 0,9 trên tập kiểm thử, đóng gói thành API rồi deploy. Với một đội làm theo roadmap nội bộ, ticket này có thể đóng ở đây.

Giờ giả sử cán bộ tín dụng chỉ đưa 30 trong 200 hồ sơ qua model. Lý do là kết quả trả về không khớp với biểu mẫu họ đang dùng, nên họ quen tay làm thủ công cho nhanh. Tỷ lệ sử dụng là 15%. Chỉ số F1 không đổi, model vẫn tốt, nhưng theo tiêu chuẩn FDE thì dự án này đang thất bại.

Việc tiếp theo của FDE vì thế không phải train lại model. FDE phải ngồi cạnh cán bộ tín dụng, xem họ bỏ qua model ở bước nào, rồi sửa định dạng đầu ra hoặc điểm tích hợp. Đó vẫn là công việc kỹ thuật, chỉ khác là bài toán được xác định từ quy trình của người dùng chứ không từ tập dữ liệu.

Gộp AI Engineer và ML Engineer vào một cột, vì cả hai cùng phục vụ khách hàng nội bộ, ranh giới với FDE hiện ra rõ hơn hẳn so với đọc từng định nghĩa riêng lẻ. Dòng thước đo của cột bên trái là suy luận từ cách các mô tả FDE tự đặt mình đối lập với “chỉ hiệu năng model”:

Tiêu chí	AI Engineer / ML Engineer	FDE
Trọng tâm kỹ thuật	ML: train, tối ưu, serving; AI: build, test, deploy, đưa model thành API	Cùng nền tảng đó, đưa hệ thống vào chạy được tại khách hàng
Khách hàng	Nội bộ, thường thuộc đội data science hoặc sản phẩm	Một khách hàng cụ thể bên ngoài, làm ngay cạnh họ
Ai đặt phạm vi	Product roadmap	Phát hiện dần khi làm với khách hàng
Thước đo thành công	Nghiêng về hiệu năng model	Mức độ sử dụng và kết quả thực tế
Sau khi launch	Ticket có thể đóng	Vẫn chịu trách nhiệm

Đọc JD theo trách nhiệm, đừng đọc theo chức danh

Vì chức danh bị dùng lẫn, đọc tiêu đề JD gần như không cho bạn biết gì. Thay vào đó, hãy tìm câu trả lời cho ba câu hỏi trong bảng trên. Khách hàng là ai? Ai đặt phạm vi? Thành công đo bằng gì?

Một JD tên “AI Engineer” nhưng nhắc đến làm việc tại site khách hàng, phỏng vấn người dùng và chỉ số sử dụng thì thực chất gần với FDE. Ngược lại, một JD tên “Forward Deployed” nhưng toàn nói về benchmark model và roadmap nội bộ thì có thể chỉ là ML Engineer được gắn nhãn mới.

Nên để ý cả cách JD dùng động từ. “Cải thiện độ chính xác” hướng về model. “Đảm bảo khách hàng vận hành được” hướng về kết quả.

Developer Việt nên chuẩn bị thế nào

Nền tảng bạn đang có vẫn dùng được. Nếu bạn đã dựng pipeline, quản lý phiên bản model hay biến model thành API, bạn đã có phần chung của cả ba nghề. Đừng bỏ PyTorch để chạy theo kỹ năng mềm chung chung.

Phần cần bù là hai thói quen cụ thể. Thói quen đầu tiên là tự đi tìm phạm vi bài toán: trước khi viết code, nói chuyện với người sẽ dùng sản phẩm và ghi lại quy trình hiện tại của họ. Thói quen thứ hai là đo mức độ sử dụng sau khi deploy, không dừng ở chỉ số offline.

Nếu từng làm outsource hoặc dự án trực tiếp với khách hàng nước ngoài, có thể bạn đã có chất liệu cho cả hai mà chưa gọi đúng tên. Khi viết CV, hãy đổi dòng “train model phân loại đạt F1 0,9” thành dòng mô tả ai đã dùng nó, quy trình nào thay đổi và bạn đã sửa gì sau khi launch.

Dòng thứ hai nói đúng thứ ngôn ngữ mà FDE Academy dùng để đo FDE: mức độ người dùng chấp nhận và kết quả kinh doanh.

Khi phỏng vấn, hãy hỏi lại câu này: “Nếu model chạy tốt mà khách hàng không dùng, đó là vấn đề của ai?” Câu trả lời sẽ cho bạn biết vị trí ấy thực sự là gì, rõ hơn bất kỳ chức danh nào in trên JD.