# Từ ML engineer sang FDE: khi model tốt vẫn chưa ai dùng

> Một model đạt F1 rất cao vẫn có thể nằm im trong notebook. Với một FDE, việc thật chỉ bắt đầu khi phải nối model đó vào công việc hằng ngày của khách hàng.

Bản gốc: https://fdetimes.net/vi/bach-khoa/ml-engineer-chuyen-sang-fde/

Thử hình dung bạn vừa nâng F1 của một model phân loại hồ sơ bồi thường bảo hiểm từ 0,81 lên 0,93. Hai tuần sau buổi demo, đội xử lý hồ sơ của khách hàng vẫn chia việc bằng tay trên một bảng tính. Model không sai. Nó chỉ chưa chạm tới chỗ công việc thật sự diễn ra.

Bài so sánh hai vai trò trên blog của Perspective AI tóm tắt khoảng cách này rất gọn: ML engineer làm cho model tốt, còn FDE làm cho model có ích với một tổ chức thật. Cũng nguồn đó viết rằng FDE được đánh giá theo việc một deployment có thật sự thay đổi cách khách hàng vận hành hay không.

Vì thế, kỹ năng bạn mang theo vẫn có giá trị, nhưng cách đo kết quả thì phải đổi. Điểm trên tập test không còn là thứ người ta chấm bạn. Thước đo mới là người dùng cuối có làm việc khác đi hay không.

## Thước đo đổi thì ngày làm việc cũng đổi

Ở Sierra, theo một tổng hợp trong cơ sở dữ liệu LLMOps của ZenML, kỹ sư FDE và agent engineer chịu trách nhiệm về "measurable business outcomes", tức kết quả kinh doanh đo được, thay vì uptime hay số tính năng đã giao. Cũng tổng hợp đó mô tả agent engineer là người lo trọn vòng đời của agent trên production và theo dõi nó bằng chỉ số kết quả.

Thước đo thay đổi kéo theo cả lịch làm việc. Perspective AI ước tính FDE dành khoảng 60% thời gian mỗi tuần để làm việc trực tiếp với khách hàng, còn ML engineer gần như không có.

Paraform mô tả FDE là vai trò lai, nằm giữa software engineering và triển khai trực tiếp cho khách hàng. Kỹ năng cốt lõi theo Paraform gồm một ngôn ngữ backend, cloud infrastructure, data engineering, applied AI và khả năng giao tiếp với khách hàng.

Applied AI chỉ là một mục trong năm mục đó. Một bài viết của Scaler cho rằng rào cản lớn nhất với người làm dữ liệu khi chuyển sang FDE là bước từ "Insight" sang "Integration", và gọi technical discovery với các bên liên quan là phần khó nhất của vai trò.

## Model tốt bị mắc kẹt ở đâu?

Quay lại ví dụ hồ sơ bồi thường, lần này với tư cách FDE. Việc đầu tiên không phải là mở notebook. Bạn cần lần theo đường đi của một hồ sơ, từ lúc nó đến tay công ty cho tới lúc có người xử lý xong.

Giả sử bạn phát hiện hồ sơ đến từ hai nơi: email và cổng web. Cả hai đổ vào một hệ thống quản lý hồ sơ cũ, sau đó trưởng nhóm xuất danh sách ra bảng tính để chia việc.

Tập dữ liệu bạn dùng để train là một file CSV xuất từ hệ thống cũ. Bạn chưa từng thấy luồng email, trong khi trưởng nhóm, người thực sự ra quyết định, chỉ làm việc trên bảng tính.

Nhìn như vậy thì chỗ nghẽn đã rõ. Hồ sơ từ email có thể không đi qua model, còn dự đoán không xuất hiện ở nơi trưởng nhóm chia việc. Đây đúng là loại việc ZenML nhắc tới khi kể vai trò FDE ở Palantir mở rộng dần: tích hợp dữ liệu từ nhiều nguồn rời rạc.

Thêm một điểm F1 lúc này không giúp được gì. Thứ cần có là một pipeline nhận đủ hai nguồn hồ sơ và ghi nhãn dự đoán vào đúng cột mà trưởng nhóm đang đọc.

Muốn biết những điều trên, bạn phải hỏi. Dưới đây là kịch bản ngắn cho buổi discovery 30 phút với trưởng nhóm xử lý hồ sơ.

> **FDE:** Sáng nay chị bắt đầu chia hồ sơ từ đâu?

Chị chia sẻ màn hình được không?
>
> **Trưởng nhóm:** Xuất danh sách từ hệ thống ra bảng tính rồi gán người theo loại hồ sơ.
>
> **FDE:** Hồ sơ gửi qua email có nằm trong danh sách đó không?
>
> **Trưởng nhóm:** Không, phải có người nhập tay vào trước đã.
>
> **FDE:** Nếu cột "loại hồ sơ" được điền sẵn thì chị bỏ được bước nào?

Còn khi nó điền sai, chị sẽ phát hiện ra bằng cách nào?

Lượt hỏi cuối là quan trọng nhất. Nó biến chỉ số của model thành chỉ số vận hành, ví dụ thời gian từ lúc hồ sơ đến cho tới lúc được gán người. Nó cũng cho bạn biết cần làm cơ chế phản hồi để người dùng báo lại khi model đoán sai.

## Làm từng bước tại chỗ khách hàng

Bước một là vẽ quy trình trước khi đụng vào model. Hãy ngồi cạnh người dùng thật, chụp lại từng màn hình họ mở và ghi lại mọi chỗ phải thao tác tay. Bước hai là xác định điểm ghi kết quả, tức hệ thống và trường dữ liệu mà người ra quyết định nhìn vào hằng ngày.

Bước ba là thống nhất một chỉ số vận hành với khách hàng và đo giá trị nền của nó trước khi triển khai. Bước bốn là chạy thông toàn bộ luồng thật sớm, kể cả khi lúc đầu chỉ dùng một bộ luật đơn giản thay cho model.

Bước năm là nhận trách nhiệm cho cả vòng đời: sau khi lên production, hãy theo dõi chỉ số vận hành chứ không chỉ độ chính xác.

**Điểm mấu chốt:** Model chưa nằm trong luồng làm việc hằng ngày thì chưa tạo ra kết quả nào cho khách hàng.

## Những cái bẫy quen thuộc của người làm ML

Bẫy phổ biến nhất là tiếp tục tinh chỉnh model trong khi phần tích hợp còn chưa chạy. Cảm giác tiến bộ là có thật, nhưng khách hàng không nhìn thấy nó. Bẫy thứ hai là coi file dữ liệu xuất ra là toàn bộ sự thật, trong khi một phần quy trình nằm ngoài hệ thống, như luồng email trong ví dụ.

Bẫy thứ ba là dùng demo trên notebook để chứng minh giá trị. Người dùng đánh giá công cụ trên màn hình họ mở mỗi sáng, không phải trên biểu đồ của bạn. Bẫy cuối là né các buổi nói chuyện với khách hàng vì thấy chúng "không kỹ thuật", trong khi discovery chính là nơi bạn tìm ra bài toán kỹ thuật thật.

## Đưa kỹ năng này vào CV

The Pragmatic Engineer ghi nhận nhu cầu tuyển FDE rất lớn tại Google, OpenAI và Anthropic. Trước khi sửa CV, hãy tự mở vài tin tuyển FDE và đếm xem các từ như integration, customer-facing, data pipeline xuất hiện bao nhiêu lần so với các từ về modelling. Con số bạn đếm được sẽ cho biết nên đặt kinh nghiệm nào lên đầu.

Sau đó viết lại từng dòng trong CV theo thứ tự: thay đổi trong vận hành, cách bạn tích hợp, rồi mới đến model. Chẳng hạn, "nối model phân loại vào hệ thống hồ sơ và bảng chia việc, rút ngắn thời gian gán người xử lý" nói được nhiều hơn "tăng F1 lên 0,93".

Trong phỏng vấn, hãy kể một lần bạn phát hiện bài toán thật nằm ngoài model. Kỹ năng ML vẫn là lợi thế lớn của bạn; điều cần học thêm là bám theo bài toán tới cùng, cho tới khi dự đoán của model thật sự làm công việc của khách hàng thay đổi.

**Thử ngay tuần này:**

- Chọn một model bạn từng làm và vẽ đường đi của một dự đoán, từ nguồn dữ liệu đến người hành động dựa trên nó. Đánh dấu mọi chỗ phải thao tác tay.
- Viết lại 3 dòng mô tả dự án ML trong CV. Mỗi dòng nêu một thay đổi trong vận hành thay cho một chỉ số offline.
- Mở 5 tin tuyển FDE và đếm số lần xuất hiện của các từ integration, customer-facing và data pipeline so với các từ về modelling.

## Nguồn

- [Forward Deployed Engineer vs ML Engineer: Roles, Skills, and Where They Overlap](https://getperspective.ai/blog/forward-deployed-engineer-vs-ml-engineer-roles-skills-and-where-they-overlap/markdown)

- [Can a Data Scientist Become a Forward Deployed Engineer?](https://www.scaler.com/topics/can-a-data-scientist-become-a-forward-deployed-engineer/)

- [What is a forward deployed engineer? A complete guide](https://www.paraform.com/insights/what-is-a-forward-deployed-engineer)

- [The Pulse: Forward deployed engineering heats up again](https://newsletter.pragmaticengineer.com/p/the-pulse-forward-deployed-engineering)

- [Evolution of Forward Deployed Engineering and Agent Engineering in the AI Era](https://www.zenml.io/llmops-database/evolution-of-forward-deployed-engineering-and-agent-engineering-in-the-ai-era)