# Từ POC lên production: vì sao nhiều dự án AI dừng lại ở buổi demo

> Phần lớn công sức của một dự án AI nằm ở những việc diễn ra sau khi khách hàng vỗ tay ở buổi demo, và FDE thường là người phải gánh phần ấy.

Bản gốc: https://fdetimes.net/vi/bach-khoa/tu-poc-len-production/

Buổi demo vừa xong, phía khách hàng rất hài lòng. Rồi người phụ trách vận hành hỏi một câu tưởng như đơn giản: "Bao giờ đội tôi dùng được thật?". Nếu bạn trả lời "vài tuần nữa" chỉ vì demo đã chạy trơn tru, nhiều khả năng bạn vừa hứa một điều mình chưa ước lượng được.

Rất nhiều dự án AI chững lại đúng ở câu hỏi ấy. Gartner dự báo ít nhất 30% dự án GenAI sẽ bị bỏ dở sau giai đoạn proof of concept vào cuối 2025.

Báo cáo The GenAI Divide của MIT NANDA còn đưa ra con số 95% thất bại với các giải pháp AI doanh nghiệp, dù đây là kết quả nghiên cứu sơ bộ trên mẫu nhỏ và không nên coi là tỷ lệ chung của cả ngành.

Với một FDE, đây là chuyện nghề nghiệp trực tiếp. Bạn được thuê để đưa hệ thống vào chạy thật ở chỗ khách hàng. Kỹ năng đáng tiền nhất vì thế là nhìn thấy khoảng cách giữa POC và production ngay từ ngày đầu, chứ không phải đến tháng thứ sáu mới phát hiện ra.

## Demo trả lời một câu hỏi khác với production

Demo trả lời câu hỏi "mô hình có làm được việc này không?". Production phải trả lời câu hỏi khó hơn: "hệ thống này có sống được trong tổ chức của khách hàng không?". Khối lượng việc để trả lời hai câu này chênh nhau rất xa.

Bài báo "Hidden Technical Debt in Machine Learning Systems" của Sculley và cộng sự ở Google, trình bày tại NeurIPS 2015, đã chỉ ra điều này từ hơn mười năm trước. Trong nhiều hệ thống ML, chỉ một phần rất nhỏ code thực sự làm việc học hoặc dự đoán.

Nhóm tác giả ước tính một hệ thống trưởng thành có thể chỉ có tối đa 5% là code ML, còn ít nhất 95% là glue code. Họ cũng nhận thấy hệ thống ML ngoài đời thực thường kéo theo chi phí bảo trì rất lớn và kéo dài.

Demo gần như chỉ gồm phần 5% đó. Vì vậy, khi bạn ước lượng thời gian dựa trên demo, bạn đang ước lượng một phần nhỏ của dự án.

## Năm khoảng trống mà demo che đi

Gartner nêu bốn lý do chính khiến dự án GenAI dừng sau POC: chất lượng dữ liệu kém, kiểm soát rủi ro chưa đủ, chi phí leo thang và giá trị kinh doanh không rõ ràng. HatchWorks, một công ty dịch vụ có blog riêng về FDE, nhấn mạnh thêm khoảng trống thứ năm là tích hợp.

Khoảng trống về dữ liệu thường bị phát hiện muộn. HatchWorks mô tả rất ngắn gọn: pilot chạy trên một bản trích xuất đã được chọn lọc, còn production phải chạy trên nguồn dữ liệu sống, vốn bẩn và luôn thay đổi. Khoảng trống về tích hợp thì hay bị ước lượng thiếu.

Theo HatchWorks, việc nối vào các hệ thống sẵn có thường chiếm phần lớn công việc thực tế, nhưng lại hay bị bỏ ra ngoài khi ngân sách được lập dựa trên demo.

Chi phí là khoảng trống khó lường. Rita Sallam của Gartner nhận xét rằng GenAI không có giải pháp dùng chung cho mọi trường hợp, và chi phí của nó khó dự đoán hơn các công nghệ khác.

Ngoài ra, MIT chỉ ra một nguyên nhân gốc mà demo không thể hiện được, gọi là "learning gap": các công cụ AI dùng chung không học hỏi và không thích nghi theo quy trình làm việc của doanh nghiệp. Theo MIT, vấn đề nằm ở đó chứ không phải ở chất lượng mô hình.

Learning gap không nên tách thành khoảng trống thứ sáu. Cách đọc hợp lý hơn là coi nó như câu hỏi nằm bên trong dòng tích hợp: hệ thống có được nối vào quy trình đủ chặt để học từ cách người dùng sửa lỗi hay không.

## Một ví dụ: bot đọc hoá đơn cho phòng kế toán

Thử hình dung bạn làm POC cho một công ty logistics: một pipeline đọc hoá đơn PDF, trích ra mã số thuế, số tiền và ngày tháng để phòng kế toán khỏi phải nhập tay. Khách gửi cho bạn vài chục hoá đơn mẫu, file nào cũng sạch và đúng định dạng. Kết quả demo gần như đúng hết.

Bây giờ hãy đi lần lượt qua năm khoảng trống. Về dữ liệu, nguồn sống thực ra là hộp thư email, trong đó có bản scan bị nghiêng, ảnh chụp bằng điện thoại và hoá đơn của nhà cung cấp nước ngoài. Về tích hợp, kết quả phải được ghi vào ERP, phải đi qua bước duyệt của kế toán trưởng và phải có cách sửa khi bot đọc sai.

Về rủi ro, một mã số thuế sai lọt vào sổ sách thì ai chịu trách nhiệm, và log nằm ở đâu? Về chi phí, mỗi hoá đơn tốn bao nhiêu token ở sản lượng thật, chứ không phải ở vài chục file demo? Về giá trị, khách đang đo gì: số phút kế toán bỏ ra cho mỗi hoá đơn, hay số lỗi phát hiện được khi kiểm toán?

Còn câu hỏi về learning gap: khi kế toán sửa một trường bị đọc sai, lần sửa đó có quay lại giúp hệ thống tốt lên không, hay biến mất luôn? Nếu biến mất, người dùng sẽ sửa cùng một lỗi mãi và đến lúc nào đó sẽ bỏ công cụ.

Việc đầu tiên nên làm là đo lại trên dữ liệu sống. Đoạn code dưới đây rất đơn giản, nhưng nó thường thay đổi hẳn cuộc trao đổi với khách:

```python
import random

def accuracy(pipeline, samples):
ok = sum(pipeline(s["file"]) == s["expected"] for s in samples)
return ok / len(samples)

curated = load_labeled("demo_set/")            # bộ khách đã chọn
live = random.sample(load_inbox_last_30_days(), 20)
live = label_by_accountant(live)               # nhờ kế toán gán nhãn

print("demo:", accuracy(extract_invoice, curated))
print("live:", accuracy(extract_invoice, live))
```

Nếu hai con số chênh nhau nhiều, bạn đã có bằng chứng cụ thể để đàm phán lại phạm vi dự án, thay vì phải giải thích vì sao trễ hẹn sau khi đã go-live.

## Bảng kiểm trước khi hứa ngày go-live

Từ ví dụ trên, bạn có thể rút ra một mẫu bảng dùng được cho hầu hết dự án. Nên điền bảng này cùng khách, ngay sau buổi demo:

| Khoảng trống | Ở POC đang có gì | Production cần gì | Ai phía khách chịu trách nhiệm |
|---|---|---|---|
| Dữ liệu | Bộ mẫu đã chọn lọc | Kết quả đo trên mẫu ngẫu nhiên từ nguồn sống | Chủ hệ thống nguồn |
| Tích hợp | File đầu ra hoặc màn hình demo | Ghi vào hệ thống thật, có bước duyệt, lần sửa của người dùng quay lại hệ thống | IT, chủ quy trình |
| Rủi ro | Không có | Người duyệt, log, cách rollback | Compliance, trưởng bộ phận |
| Chi phí | Vài chục lượt gọi | Ước tính ở sản lượng thật, có ngưỡng cảnh báo | Người giữ ngân sách |
| Giá trị | "Trông rất ổn" | Một chỉ số đo được trước và sau | Sponsor dự án |

Ô nào còn trống thì đó là rủi ro, và rủi ro đó phải được ghi thành hạng mục công việc riêng, có ước lượng riêng. Riêng dòng tích hợp nên được ước lượng tách khỏi phần AI. Nếu gộp chung, nó sẽ bị phần demo đã xong "kéo" xuống thành một con số quá thấp.

**Điểm mấu chốt:** Demo cho thấy mô hình làm được việc. Bảng kiểm cho thấy dự án còn bao nhiêu việc phải làm.

## Những lỗi khiến dự án mắc kẹt ở pilot

Lỗi thứ nhất là coi độ chính xác trong demo như một lời cam kết. Con số đó chỉ đúng với bộ dữ liệu mà khách đã chọn, và khách thường chọn những file đẹp nhất.

Lỗi thứ hai là lập kế hoạch như thể dự án chỉ có phần ML, trong khi theo nhóm của Sculley, phần lớn hệ thống là glue code và chi phí bảo trì thường rất lớn, kéo dài.

Lỗi thứ ba là tự xây mọi thứ từ đầu. Báo cáo MIT ghi nhận rằng mua giải pháp từ nhà cung cấp chuyên biệt và làm việc theo kiểu đối tác đạt tỷ lệ thành công khoảng 67%, cao hơn nhiều so với tự xây nội bộ.

Với FDE, điều này có nghĩa là nên tận dụng những gì đã chạy được, rồi dành sức cho phần gắn hệ thống vào quy trình của khách.

Lỗi cuối cùng là để giá trị kinh doanh mơ hồ cho đến lúc cần gia hạn hợp đồng. Khi không ai đo được dự án đã tiết kiệm được gì, đó là lúc sponsor phía khách dễ cắt dự án nhất.

## Cách thể hiện kỹ năng này khi đi xin việc

Nếu bạn đang chuyển từ backend hoặc data sang FDE, kinh nghiệm tích hợp là một lợi thế đáng kể, vì theo HatchWorks, việc nối vào hệ thống sẵn có thường chiếm phần lớn công việc thực tế của dự án. Khi đọc JD, hãy chú ý những cụm như "deployment", "integration with customer systems" hay "own the path to production".

Những cụm này cho biết công ty đã hiểu POC chỉ là bước đầu.

Trong CV, đừng chỉ viết "xây chatbot RAG". Hãy viết rõ bạn đã đưa hệ thống nào từ pilot lên production, đã nối nó với hệ thống gì của khách và đã đo hiệu quả bằng chỉ số nào.

Ở vòng phỏng vấn, nếu bạn kể được cách tìm ra chênh lệch giữa bộ demo và dữ liệu sống, bạn đang thể hiện đúng kỹ năng mà nhà tuyển dụng FDE cần.

Lần tới khi được hỏi "bao giờ dùng được thật?", hãy trả lời bằng bảng kiểm năm khoảng trống thay vì một con số ước chừng.

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

- Lấy một POC bạn từng làm, điền bảng kiểm năm khoảng trống trong bài và đánh dấu những ô còn trống
- Xin khách hàng hoặc team nội bộ 20 bản ghi lấy ngẫu nhiên từ nguồn dữ liệu sống, chạy lại pipeline và so kết quả với bộ demo
- Viết lại một dòng CV theo dạng 'đưa X từ pilot lên production, tích hợp với Y, đo bằng Z'

## Nguồn

- [Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025](https://www.intelligentcio.com/eu/2024/08/05/gartner-predicts-30-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025/)

- [MIT report: 95% of generative AI pilots at companies are failing](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)

- [Hidden Technical Debt in Machine Learning Systems (NeurIPS 2015, text copy)](https://object.cloud.sdsc.edu/v1/AUTH_da4962d3368042ac8337e2dfdd3e7bf3/ml-papers-txt/NeurIPS/2015/hidden_technical_debt_in_machine_learning_systems__893cc25d.txt)

- [Why AI pilots stall (HatchWorks, FDE blog; vendor source)](https://hatchworks.com/blog/fde/why-ai-pilots-stall/)