6 quyết định quan trọng mà mọi AI Engineer đều phải đối mặt

Phần lớn các khóa học AI và machine learning thường tập trung vào cách làm cho model chính xác hơn. Nhưng khi bước vào production thực tế, những vấn đề khó nhất lại thường xuất hiện sau khi model đã chạy được.

Ví dụ, khi nào nên tự động hóa hoàn toàn và khi nào vẫn cần con người kiểm tra? Khi nào prompt engineering là đủ, còn khi nào fine-tuning mới thật sự đáng đầu tư? Hay việc chọn real-time inference thay vì batch inference thực sự ảnh hưởng thế nào tới chi phí hạ tầng khi hệ thống bắt đầu scale?

Theo bài viết, đây là những câu hỏi hầu như không được dạy trong trường học, nhưng lại xuất hiện gần như ngay tuần đầu tiên khi làm production AI.

Bài viết này phân tích 6 trade-off phổ biến nhất trong AI engineering hiện đại — không phải để đưa ra “đáp án đúng”, mà để giúp hiểu rõ hậu quả thực tế của từng lựa chọn trong môi trường production.

1. Build hay Buy trong kỷ nguyên LLM?

Nếu vài năm trước câu hỏi phổ biến còn là “có nên tự train model không?”, thì tới năm 2026, phần lớn doanh nghiệp gần như không còn tự huấn luyện model từ đầu nữa. Thay vào đó, team AI hiện thường đứng trước ba hướng lựa chọn: dùng API từ nhà cung cấp AI, fine-tune model mã nguồn mở, hoặc tự xây và tự host toàn bộ stack AI riêng.

Theo khảo sát của Omdia năm 2025 với hơn 370 stakeholder kỹ thuật và kinh doanh, có tới 95% đồng ý rằng tự xây giúp tăng khả năng tùy biến và kiểm soát hệ thống. Nhưng đồng thời, 91% cũng cho rằng dùng nền tảng dựng sẵn giúp ra sản phẩm nhanh hơn nhiều.

Vấn đề là cả hai điều này đều đúng.

Với hệ thống dưới khoảng 100.000 request mỗi ngày, dùng API như GPT-4o Mini thường là lựa chọn hợp lý nhất vì tốc độ triển khai nhanh và overhead thấp. Nhưng khi hệ thống vượt khoảng 1 triệu request/ngày, chi phí token bắt đầu ảnh hưởng rõ rệt tới lợi nhuận.

Tuy nhiên, nhiều team lại đánh giá sai chi phí self-hosting. Một nghiên cứu năm 2024 cho thấy phần cứng và điện chỉ chiếm khoảng 20–30% tổng chi phí vận hành hệ thống AI. Phần lớn chi phí thực ra nằm ở engineer, maintenance và vận hành lâu dài.

Đây là lỗi rất phổ biến trong các bài toán “build vs buy”: doanh nghiệp tính tiền GPU rất kỹ nhưng lại quên chi phí con người.

Ngoài ra còn có vấn đề framework lock-in. Khi Hugging Face Text Generation Inference chuyển sang maintenance mode cuối năm 2025, nhiều team self-host phải migration khá vất vả. Trong khi đó, các team chỉ dùng API gần như không cần thay đổi gì.

Vì vậy, bài viết cho rằng một workflow khá thực tế hiện nay là: bắt đầu bằng API, theo dõi chặt chẽ chi phí và latency ngay từ đầu, rồi chỉ chuyển sang self-host khi dữ liệu usage thật sự cho thấy điều đó đáng làm.

2. Model Complexity và Maintainability

Một paper nổi tiếng của Google từng đưa ra nguyên tắc CACE — “Changing Anything Changes Everything”. Ý tưởng nghe khá đơn giản nhưng lại phản ánh đúng thực tế của production ML: chỉ cần thay đổi nhỏ ở một phần pipeline cũng có thể gây ảnh hưởng dây chuyền tới toàn bộ hệ thống. Điều này đặc biệt dễ xảy ra với ensemble model hoặc neural network phức tạp.

Technical debt trong machine learning thường không nằm ở code model mà nằm ở data dependency. Dữ liệu khó theo dõi hơn, khó version hơn và cũng khó giải thích hơn cho người phải maintain hệ thống vài tháng sau đó.

Nghiên cứu về ML technical debt còn cho thấy phần “model code” thực ra chỉ là một phần rất nhỏ trong production AI system. Phần lớn hệ thống nằm ở feature store, pipeline, monitoring, retraining trigger và lớp glue logic kết nối mọi thứ lại với nhau.

Trong thực tế, rất nhiều team chấp nhận tăng độ phức tạp hệ thống chỉ để đổi lấy thêm khoảng 2% accuracy, nhưng sau đó lại phải trả giá bằng hàng tháng debugging và retraining.

Trước khi deploy một model quá phức tạp, nên tự hỏi: “Ai sẽ maintain hệ thống này sau một năm nữa?”

Nếu câu trả lời chưa rõ ràng, đó có thể đã là dấu hiệu cần xem lại quyết định.

3. Data Quantity hay Data Quality?

Trong thời đại foundation model, nhiều người mặc định rằng càng nhiều dữ liệu thì model sẽ càng tốt. Nhưng bài viết cho rằng điều đó không phải lúc nào cũng đúng với applied machine learning.

Nghiên cứu cho thấy khi noise vượt quá một ngưỡng nhất định, việc thêm nhiều dữ liệu chất lượng thấp không còn giúp model cải thiện, thậm chí còn làm hiệu suất giảm xuống. Đây cũng là nguyên nhân dẫn tới hiện tượng “data swamp” trong doanh nghiệp — nơi team lưu trữ mọi dữ liệu có thể vì nghĩ rằng “biết đâu sau này sẽ cần”.

Kết quả là pipeline trở nên cồng kềnh, dữ liệu khó làm sạch, chi phí lưu trữ tăng mạnh nhưng kết quả mô hình lại không cải thiện tương xứng.

Medical AI là ví dụ khá rõ cho vấn đề này. Nhiều dataset nhỏ nhưng được chuyên gia gán nhãn chính xác thường outperform dataset lớn nhưng annotation kém chất lượng.

Câu hỏi hữu ích hơn trong production không phải: “Chúng ta có thêm dữ liệu không?”. Mà là: “Dữ liệu hiện tại nhiễu tới mức nào, và thêm một giờ cleaning có giá trị hơn hay thêm một ngày thu thập dữ liệu mới sẽ hiệu quả hơn?”

4. Throughput và Latency: Batch Hay Real-Time?

Batch inference và real-time inference thực chất là hai kiểu kiến trúc hệ thống hoàn toàn khác nhau.

Batch inference tạo prediction theo lịch cố định như mỗi giờ hoặc mỗi ngày rồi lưu kết quả vào database. Hướng tiếp cận này rẻ hơn, đơn giản hơn và dễ debug hơn, nhưng prediction có thể không hoàn toàn mới theo thời gian thực. Trong khi đó, real-time inference tạo prediction ngay khi người dùng gửi request. Hệ thống luôn cập nhật nhưng đổi lại phải duy trì hạ tầng hoạt động liên tục 24/7 với chi phí cao hơn đáng kể.

Sai lầm phổ biến nhất là nhiều team mặc định chọn real-time chỉ vì nó “nghe hiện đại hơn”.

Nhưng trên thực tế, rất nhiều bài toán kinh doanh hoàn toàn không cần prediction dưới một giây. Ví dụ như churn score cập nhật hàng đêm, recommendation refresh theo ngày hoặc fraud model cập nhật định kỳ — tất cả đều phù hợp với batch inference hơn nhiều.

Một nguyên tắc thực tế là: Nếu người dùng không nhận ra sự khác biệt giữa prediction cũ 5 phút và 5 mili-giây, batch inference thường là lựa chọn hợp lý hơn.

5. Prompt Engineering hay Fine-Tuning?

Đây là vấn đề đã trở nên rõ ràng hơn rất nhiều trong vài năm gần đây. Prompt engineering có lợi thế rất lớn về tốc độ, chi phí và khả năng thử nghiệm nhanh. Với phần lớn task hiện nay, chỉ cần prompt tốt là đã đủ để đạt kết quả khá ổn.

Tuy nhiên, điểm yếu của prompt engineering là tính “mong manh”. Chỉ cần thay đổi nhỏ trong input cũng có thể khiến output khác đi đáng kể, đặc biệt ở edge case.

Ngược lại, fine-tuning tốn nhiều compute, thời gian chuẩn bị dữ liệu và engineering effort hơn, nhưng đổi lại mang tính ổn định cao hơn khi hệ thống scale.

Lấy ví dụ thực tế: fine-tune GPT-4o cho chatbot chăm sóc khách hàng có thể tiêu tốn khoảng 10.000 USD compute cùng 6 tuần chuẩn bị dữ liệu, trong khi giải pháp RAG tương tự chỉ mất khoảng 2 tuần để triển khai.

Hướng tiếp cận hợp lý hiện nay là bắt đầu bằng prompt engineering, sau đó chỉ chuyển sang fine-tuning khi prompt không còn giải quyết được failure mode nữa.

Một nghiên cứu năm 2025 còn cho thấy các kỹ thuật tối ưu prompt như DSPy thậm chí outperform fine-tuning trên một số benchmark trong khi dùng ít rollout hơn rất nhiều.

Hiện nay, nhiều production system đang dùng hybrid approach: fine-tune để định hình style và behavior, kết hợp RAG để đảm bảo factual grounding.

6. Automation hay Human Oversight?

Câu hỏi quan trọng nhất trong production AI không phải: “Có thể tự động hóa được không?”. Mà là: “Nếu AI sai, ai sẽ chịu hậu quả?”

Human-in-the-loop (HITL) tồn tại trên cả một phổ rộng. Ở một đầu là hệ thống mà con người review mọi output trước khi AI hành động. Ở đầu còn lại là full automation, nơi con người chỉ giám sát anomaly.

Đa số production system hiện nằm somewhere in between — AI tự xử lý phần lớn trường hợp, nhưng những decision confidence thấp hoặc rủi ro cao sẽ được chuyển cho con người kiểm tra.

Tuy nhiên, human review cũng có chi phí rất thật. Việc kiểm tra thủ công không scale tốt, phản hồi giữa các reviewer dễ thiếu nhất quán và can thiệp real-time thường khiến hệ thống chậm hơn đáng kể.

Vì vậy, nhiều team hiện chuyển sang selective HITL — chỉ kích hoạt human review ở edge case hoặc high-stakes decision.

Trong healthcare, finance hay legal, đây gần như là yêu cầu bắt buộc vì chi phí của sai sót quá lớn để fully automate.

Có thể hình dung sự phân chia vai trò khá rõ: AI xử lý tốc độ, khối lượng và pattern recognition. Con người xử lý những quyết định mang tính không thể đảo ngược.

Trong production AI, chi phí thực sự của một quyết định thường không xuất hiện ngay tại thời điểm quyết định được đưa ra.

Một model phức tạp có thể khiến team trả giá bằng hàng tháng maintenance sau này. Một real-time system có thể kéo theo chi phí hạ tầng 24/7 trong nhiều năm. Dữ liệu bẩn khiến retraining trở nên tốn kém, còn prompt “quá thông minh” có thể dễ vỡ ở edge case.

kỹ năng quan trọng nhất của AI engineer hiện đại không chỉ là build model tốt — mà là hiểu rõ chi phí dài hạn của từng trade-off trước khi hệ thống đi vào production thực tế.