Forward Deployed Engineer: người đưa AI từ bản demo vào công việc thật

Một bản demo AI có thể rất ấn tượng. Nhập một câu, hệ thống đọc tài liệu, tạo báo giá rồi soạn sẵn email. Nhưng từ màn hình demo đến một quy trình được sử dụng mỗi ngày là một khoảng cách khá dài.

Ai chịu trách nhiệm nếu báo giá sai? Dữ liệu khách hàng nằm ở đâu? Nhân viên có tin kết quả không? Nếu phần mềm kế toán ngừng phản hồi, công việc có tiếp tục được không?

Mình nghĩ khoảng cách ấy là nơi vai trò Forward Deployed Engineer trở nên đáng chú ý.

Một kỹ sư đứng gần vấn đề

Trong cách Palantir mô tả vai trò này, kỹ sư làm việc trực tiếp với khách hàng để đưa các khả năng của nền tảng vào bài toán cụ thể.¹ Forward Deployed Engineer không phải khái niệm mới xuất hiện cùng AI, và cũng không mặc nhiên là một chức danh chỉ làm AI.

Trong bối cảnh bài viết, mình dùng “kỹ sư chuyển đổi AI” để nói về một hướng ứng dụng của cách làm đó: người đi cùng doanh nghiệp từ việc hiểu quy trình đến thiết kế, triển khai và theo dõi hệ thống có AI tham gia.

Điểm khác biệt không nằm ở việc người ấy biết nhiều công cụ hơn. Nó nằm ở chỗ họ có thể nối hai cuộc trò chuyện: cuộc trò chuyện về công nghệ và cuộc trò chuyện về công việc thực tế.

Bắt đầu bằng việc ngồi cạnh người đang làm

Giả sử một bộ phận bán hàng phải xử lý yêu cầu báo giá từ email. Bản mô tả quy trình có thể chỉ gồm bốn bước. Nhưng khi quan sát công việc, ta có thể thấy những ngoại lệ không nằm trên sơ đồ: khách quen có giá riêng, mã hàng được viết tắt, tồn kho cập nhật chậm, một số đơn bắt buộc quản lý duyệt.

Đó là tình huống minh họa. Nhưng nó giúp hình dung vì sao xây agent trước khi hiểu công việc thường khiến ta tự động hóa một phiên bản quá đơn giản của thực tế.

Mình muốn người kỹ sư ghi lại đầu vào, quyết định, ngoại lệ, hệ thống liên quan và người chịu trách nhiệm của từng bước. Có những bước nên dùng quy tắc rõ ràng. Có những bước phù hợp với AI. Cũng có những bước nên để con người tiếp tục làm.

Biến quy trình thành một hệ thống có thể kiểm chứng

Sau khi hiểu công việc, mới đến lúc xác định vai trò của AI. Trong ví dụ báo giá, AI có thể đọc yêu cầu và đề xuất mã hàng. Giá và tồn kho cần được lấy từ nguồn đáng tin cậy qua công cụ có phân quyền. Một nhân viên duyệt trước khi báo giá được gửi đi.

Kỹ sư phải thiết kế cả phần không hào nhoáng: kết nối hệ thống cũ, quản lý bí mật truy cập, giới hạn quyền của công cụ, xử lý tác vụ bị lặp, ghi lại lịch sử và tạo đường lui khi có lỗi.

Một luồng được định nghĩa sẵn đôi khi hợp lý hơn một agent được tự do lựa chọn mọi hành động. Sự phân biệt giữa workflow và agent của Anthropic là tài liệu khởi đầu hữu ích cho quyết định này.²

Đo xem công việc có thực sự tốt hơn

Một hệ thống chạy được chưa chắc đã được sử dụng. Người làm trực tiếp có thể thấy giao diện bất tiện, không hiểu vì sao AI đề xuất như vậy hoặc mất quá nhiều thời gian sửa kết quả.

Mình sẽ đo một nhóm chỉ số nhỏ: thời gian hoàn thành một yêu cầu, mức độ chính xác, số lần phải làm lại và phản hồi của nhân viên. Với các hành động ảnh hưởng khách hàng, cần xem cả khiếu nại và chất lượng xử lý ngoại lệ.

Việc theo dõi này không nên chỉ diễn ra sau khi bàn giao. Nó là một phần của thiết kế. Những phản hồi từ người dùng cần quay lại bộ kiểm thử, cách lấy dữ liệu và cách phân công giữa AI với con người.

Năng lực quan trọng nhất là nối được hai phía

Theo mình, người làm vai trò này cần nền tảng phần mềm, hiểu dữ liệu và đủ khả năng làm việc với hệ thống thực. Nhưng cũng cần biết hỏi, biết lắng nghe và giải thích một đánh đổi kỹ thuật bằng ngôn ngữ của người sử dụng.

Không phải doanh nghiệp nào cũng cần tuyển ngay một vị trí mới. Một nhóm nhỏ gồm người hiểu nghiệp vụ, kỹ sư và người có quyền ra quyết định có thể cùng đảm nhiệm trách nhiệm ấy. Điều quan trọng là không để khoảng trống giữa “demo chạy rồi” và “mọi người dùng được” bị bỏ quên.

Mình thích nghĩ về kỹ sư chuyển đổi AI như một người làm cầu nối. Không đem công nghệ đến để yêu cầu doanh nghiệp thích nghi bằng mọi giá, mà cùng doanh nghiệp tìm một cách làm việc tốt hơn.