Aitomatic và nghề FDE trong nhà máy: việc khó nằm ngoài model

“Một câu trả lời sai nhưng tự tin là điều nguy hiểm trên sàn fab.” Câu này không nằm trong tài liệu an toàn lao động. Nó nằm trên trang chủ của Aitomatic, công ty đang bán thứ họ gọi là “Digital Engineers” cho công nghiệp vật lý.

Với người muốn làm FDE, câu đó đáng đọc hơn nhiều bản mô tả công việc. Chưa tìm thấy tin tuyển FDE công khai nào của Aitomatic, nên mọi hình dung về vị trí này ở công ty chỉ nên được xem là suy luận.

Nhưng các tài liệu công khai về công ty cùng gợi ý một hướng khá rõ. Trong AI nhà máy, phần khó của deployment nhiều khả năng nằm ngoài model: lấy được tri thức trong đầu kỹ sư, nối nó với dữ liệu sản xuất, rồi chứng minh hệ thống biết lúc nào mình có thể sai. Nếu bạn nhắm tới mảng này, đó là những thứ cần luyện.

Model nền mở chưa nói hết câu chuyện

SemiKong, mô hình mã nguồn mở cho bán dẫn của Aitomatic, được xây trên Llama 3.1 70B, theo case study của Meta. Riêng chi tiết này chưa cho biết việc khó nằm ở đâu, vì tinh chỉnh một model nền cho bán dẫn cũng có thể rất vất vả.

Manh mối rõ hơn nằm ở cách người ta mô tả công ty. Meta viết rằng Aitomatic giúp doanh nghiệp bán dẫn nắm bắt và nhân rộng chuyên môn sâu của họ, thông qua Domain-Expert Agents (DXA).

Một bài phân tích tình huống trên blog của Zilliz năm 2024 kể về kiến trúc OpenSSA, tức các agent chuyên biệt cỡ nhỏ, với quy trình mở đầu bằng việc thu nhận tri thức từ kỹ sư quy trình và chuyên gia thiết bị.

Model nền mở thì nhiều người có thể tải về, còn chuyên môn trong đầu kỹ sư của một nhà máy thì phải đến tận nơi mới lấy được. Đó là lý do để suy luận rằng phần việc khó của người triển khai nằm ở đây.

Vì thế, việc đầu tiên nhiều khả năng là một cuộc nói chuyện chứ không phải một dòng code. Nếu bạn chưa từng luyện kỹ năng này có chủ đích, hãy bắt đầu từ đây.

Thử hình dung bạn hỏi một kỹ sư thiết bị: “Khi nào anh dừng máy?” Anh ấy đáp: “Khi thấy tín hiệu này hơi lạ.” Câu trả lời đó chưa dùng được, và hỏi thêm về quy trình chung cũng ít khi giúp ích.

Hãy hỏi về ba lần dừng máy gần nhất. Tín hiệu nào lạ, lạ so với cái gì, có lần nào thấy lạ mà vẫn chạy tiếp không, và ai được quyền quyết định. Mỗi câu chuyện như vậy cho bạn một quy tắc nháp cùng một test case lấy từ đời thật.

Phoenix cho thấy chỗ nghẽn nằm ở đâu

Vì sao phải khổ công đến vậy với tri thức của chuyên gia? Bài trên blog của Zilliz lấy ví dụ TSMC: dùng cùng công nghệ nhưng kết quả giữa các dự án fab vẫn khác nhau, và fab ở Phoenix, Arizona gặp khó vì thiếu chuyên môn tại chỗ.

Chỗ nghẽn này không chỉ xuất hiện ở Mỹ. VnEconomy, trong bài đăng ngày 13/03/2025 dịp AISC 2025, tóm tắt quan điểm của CEO Aitomatic rằng Việt Nam vẫn thiếu chuyên gia AI và kỹ sư bán dẫn trình độ cao. Hai bối cảnh rất khác, nhưng đều xoay quanh con người có chuyên môn.

Chi tiết đáng chú ý là tin tuyển AI Forward Deployed Engineer của TSMC Arizona, cũng ở Phoenix. Đừng vội coi hai chuyện là nguyên nhân và kết quả của nhau. Điều đáng đọc là một dòng yêu cầu trong tin: hiểu vững nền tảng kỹ thuật phần mềm và phương pháp phát triển agile.

Một dòng không nói lên toàn bộ tin tuyển dụng, nhưng đủ để rút ra một lời khuyên. Muốn vào AI nhà máy, bạn không nên bỏ nghề để học lại bán dẫn từ đầu. Kỹ thuật phần mềm vẫn là vé vào cửa, còn hiểu biết về nhà máy là thứ bạn phải học thêm đủ nhanh để nói chuyện được với người đứng máy.

Sáu đầu mục trên trang chủ là một bài tập dữ liệu

Trang chủ Aitomatic mô tả ngữ cảnh sản xuất bán dẫn bằng sáu thứ: thiết bị, recipe, lot, trạng thái quy trình, chất lượng và yield. Đọc như một engineer, đây gần như đề bài của tuần đầu tại khách hàng.

Thử hình dung yield của một lot tụt xuống và kỹ sư hỏi agent vì sao. Để trả lời, hệ thống phải biết lot đó đã qua thiết bị nào, chạy recipe nào, trạng thái quy trình lúc ấy ra sao, và kết quả chất lượng gắn với lần chạy nào.

Bây giờ giả sử mã lot trong hệ thống chất lượng không khớp với mã trong log thiết bị. Khi đó, dù model giỏi đến đâu, câu trả lời vẫn dựa trên hai bản ghi bị ghép nhầm, mà giọng vẫn rất tự tin.

Vì vậy, việc nên làm đầu tiên là chọn đúng một câu hỏi thật, vẽ đường đi của dữ liệu cho câu hỏi đó, rồi kiểm tra từng khớp nối trước khi động vào prompt.

94% vẫn có thể là 144 lần sai mỗi ca

Aitomatic tự công bố một kết quả trong bán dẫn: 2.400 lỗi được phân loại mỗi ca với độ chính xác 94%. Đây là tuyên bố của công ty, chưa có đánh giá độc lập, vì vậy hãy xem nó là chỗ bắt đầu đặt câu hỏi chứ chưa phải kết luận.

Phép tính đơn giản: nếu tỷ lệ đó áp cho cả ca, 6% của 2.400 là 144 lần phân loại sai. Con số 94% không cho biết 144 lần ấy rơi vào đâu.

Giả sử trong ca có 100 lỗi thuộc loại có thể làm hỏng cả lot. Về lý thuyết, hệ thống vẫn đạt 94% ngay cả khi phân loại sai toàn bộ 100 lỗi này, và cũng đạt 94% nếu cả 144 lần sai đều rơi vào những lỗi ít hại.

Cùng một con số có thể là một rủi ro lớn hoặc một công cụ tốt, và chỉ phân tích theo từng lớp lỗi mới tách được hai trường hợp đó.

Ở khách hàng, việc của bạn bắt đầu từ đây. Hãy hỏi kỹ sư loại lỗi nào họ không thể bỏ sót, đo riêng loại đó, và thiết kế một nhánh để hệ thống chuyển trường hợp không chắc cho người xem thay vì đoán. Lời cảnh báo về sàn fab ở đầu bài, khi viết thành code, trông chính là nhánh này.

Ghép các tín hiệu thành kế hoạch luyện tập

Mỗi tài liệu trên chỉ hé lộ một phần công việc. Bảng dưới đây ghép các phần đó lại; cột giữa và cột phải là suy luận và lời khuyên, không phải mô tả công việc chính thức.

Tín hiệu công khai	Việc có thể gặp tại khách hàng	Cách luyện và cách chứng minh
Thu nhận tri thức từ kỹ sư quy trình, thiết bị	Phỏng vấn người đứng máy, viết lại thành quy tắc	Biến ba sự cố thật thành test case, đưa cả ví dụ vào portfolio
Ngữ cảnh gồm thiết bị, recipe, lot, yield	Nối dữ liệu giữa nhiều hệ thống, xử lý mã không khớp	Viết truy vết một lỗi xuyên ít nhất hai nguồn dữ liệu
Agent chuyên biệt cỡ nhỏ (OpenSSA)	Khoanh một bài toán hẹp thay vì trợ lý đa năng	Làm một agent chỉ giải một loại câu hỏi và nêu rõ phạm vi từ chối
Sai mà tự tin là nguy hiểm; 94% tự công bố	Đo theo từng lớp lỗi, thiết kế nhánh chuyển cho người	Công bố confusion matrix và tỷ lệ chuyển cho người, không chỉ accuracy
Triển khai sản xuất kèm tối ưu liên tục	Theo dõi và sửa hệ thống sau go-live	Kể lại một lần hệ thống của bạn xuống cấp và bạn phát hiện ra thế nào
TSMC đòi nền tảng phần mềm và agile	Viết code sản xuất, không chỉ làm demo	Giữ test, CI và code review trong dự án mẫu

Công việc có thể không chỉ ở Aitomatic

Tháng 2/2025, Aitomatic công bố nền tảng DXA Factory được ITOCHU Techno-Solutions và FPT chọn để triển khai toàn cầu, trong đó FPT hướng tới AI công nghiệp. Nếu mô hình này mở rộng, phần lớn việc triển khai có thể đi qua các nhà tích hợp hệ thống.

Đây mới là suy luận, nhưng nó gợi ý một cách tìm việc rộng hơn. Đừng chỉ tìm tiêu đề “FDE” trên trang của một công ty AI.

Hãy đọc cả tin tuyển dụng từ các nhà tích hợp và các nhà máy, rồi tìm dấu hiệu thật: làm việc trực tiếp với kỹ sư quy trình hay thiết bị, ai giữ hệ thống sau go-live, và dữ liệu sản xuất có nằm trong phạm vi công việc không.

Cũng trong thông báo đó, giai đoạn cuối của vòng đời DXA là triển khai sản xuất kèm tối ưu liên tục. Hãy lấy câu ấy làm khuôn cho CV: một dòng chỉ nói “xây agent cho nhà máy” nói rất ít, còn một dòng nêu bạn đã lấy quy tắc từ ai, đo lớp lỗi nào, và sửa gì sau khi lên production thì kể được cả công việc.

Trong phỏng vấn, bạn cũng có thể đảo vai bằng một câu hỏi: “Lần gần nhất hệ thống của các anh chị trả lời sai một cách tự tin, chuyện gì đã xảy ra sau đó?” Cách họ trả lời cho bạn biết công việc thật sự nằm ở đâu.

Bản demo có thể thắng nhờ câu trả lời trơn tru. Trên sàn fab, thước đo khó hơn nhiều: lần đầu hệ thống của bạn nói “không chắc”, kỹ sư đứng ca vẫn tin nó.