Phát triển AI theo yêu cầu (custom AI development) là quá trình xây dựng một giải pháp trí tuệ nhân tạo được thiết kế riêng cho bài toán, dữ liệu, quy trình và hệ thống cụ thể của một doanh nghiệp — thay vì mua một phần mềm đóng gói dùng chung cho mọi khách hàng. Giải pháp AI đặt làm có thể là chatbot trả lời dựa trên tài liệu nội bộ, hệ thống trích xuất thông tin từ chứng từ, mô hình dự báo nhu cầu, hay trợ lý tri thức cho nhân viên — điểm chung là mọi thành phần, từ dữ liệu huấn luyện đến cách tích hợp vào hệ thống sẵn có, đều được xây dựng xoay quanh nghiệp vụ thật của doanh nghiệp đó. Bài viết này giải thích phát triển AI theo yêu cầu là gì, khác gì với phần mềm đóng gói, các loại giải pháp thường được đặt làm, quy trình 7 bước từ khảo sát nghiệp vụ đến vận hành và bảo trì, cách viết yêu cầu dự án (RFP), tiêu chí nghiệm thu và những rủi ro cần phòng tránh.
Phát triển AI theo yêu cầu là gì?
Phát triển AI theo yêu cầu là việc thiết kế và xây dựng một hệ thống AI riêng cho một tổ chức cụ thể, dựa trên bài toán nghiệp vụ, dữ liệu và quy trình của chính tổ chức đó. Khác với việc mua một phần mềm AI có sẵn rồi điều chỉnh cách làm việc của mình cho khớp với phần mềm, phát triển theo yêu cầu đi theo hướng ngược lại: hệ thống được xây để khớp với cách doanh nghiệp đang vận hành — hoặc cách doanh nghiệp muốn vận hành sau khi cải tiến. Sản phẩm cuối cùng thuộc về doanh nghiệp ở mức độ đã thỏa thuận: doanh nghiệp sở hữu dữ liệu, sở hữu quy trình, và tùy hợp đồng có thể sở hữu cả mã nguồn, mô hình đã tinh chỉnh và tài liệu hệ thống.
Để hiểu rõ khái niệm, hãy hình dung ba cấp độ “may đo” của giải pháp AI. Cấp độ thứ nhất là dùng công cụ AI có sẵn: doanh nghiệp đăng ký tài khoản một dịch vụ AI chung (ví dụ công cụ chatbot, công cụ tạo nội dung) và dùng ngay, không tùy chỉnh gì ngoài một vài thiết lập. Cấp độ thứ hai là cấu hình và tích hợp giải pháp có sẵn: doanh nghiệp mua một nền tảng AI rồi cấu hình theo nhu cầu — nạp tài liệu nội bộ vào chatbot, kết nối với CRM, đặt quy tắc trả lời riêng. Cấp độ thứ ba mới là phát triển theo yêu cầu: đội ngũ xây dựng giải pháp từ đầu hoặc tùy biến sâu trên nền tảng có sẵn — thiết kế kiến trúc dữ liệu riêng, huấn luyện hoặc tinh chỉnh mô hình trên dữ liệu của doanh nghiệp, xây logic nghiệp vụ đặc thù, và tích hợp chặt với hệ thống hiện có. Ba cấp độ này không có cấp nào “tốt hơn” tuyệt đối; lựa chọn đúng phụ thuộc vào mức độ đặc thù của bài toán và nguồn lực của doanh nghiệp — phần so sánh dưới đây sẽ giúp xác định khi nào nên đặt làm và khi nào không nên.
Một điểm cần làm rõ ngay: “phát triển theo yêu cầu” không đồng nghĩa với “huấn luyện mô hình ngôn ngữ lớn từ đầu”. Trên thực tế, gần như không doanh nghiệp nào — kể cả tập đoàn lớn — tự huấn luyện một mô hình nền tảng từ con số không, vì chi phí dữ liệu và tính toán là rất lớn. Phát triển AI theo yêu cầu trong thực tế doanh nghiệp thường có nghĩa là: dùng mô hình nền tảng có sẵn (mô hình ngôn ngữ lớn, mô hình thị giác, mô hình dự báo) rồi tinh chỉnh (fine-tuning) hoặc bổ sung dữ liệu riêng qua RAG (Retrieval-Augmented Generation — kỹ thuật truy xuất tài liệu nội bộ để mô hình trả lời dựa trên dữ liệu của doanh nghiệp), kết hợp với logic nghiệp vụ, giao diện và tích hợp hệ thống được xây riêng. Hiểu đúng điều này giúp doanh nghiệp đặt kỳ vọng thực tế về thời gian, chi phí và kết quả — và tránh bị những lời chào hàng hứa hẹn “xây mô hình AI riêng từ đầu” đánh lừa.
Phát triển AI theo yêu cầu khác mua phần mềm đóng gói như thế nào?
Câu hỏi này là quyết định đầu tiên và quan trọng nhất: không phải bài toán nào cũng cần đặt làm. Bảng dưới đây so sánh hai lựa chọn theo các tiêu chí mà doanh nghiệp thực sự quan tâm khi ra quyết định.
| Tiêu chí | Phần mềm AI đóng gói (SaaS / có sẵn) | Phát triển AI theo yêu cầu |
|---|---|---|
| Mức độ khớp với nghiệp vụ | Khớp một phần; doanh nghiệp phải điều chỉnh quy trình theo phần mềm | Khớp cao; hệ thống xây theo quy trình và dữ liệu riêng của doanh nghiệp |
| Thời gian đưa vào dùng | Nhanh — thường vài ngày đến vài tuần | Chậm — thường 2–6 tháng cho dự án vừa, lâu hơn với hệ thống phức tạp |
| Chi phí ban đầu | Thấp; trả theo tháng hoặc theo mức dùng | Cao; chi phí xây dựng, tích hợp và kiểm thử ban đầu lớn |
| Chi phí dài hạn | Phí thuê bao tích lũy theo năm; tăng khi mở rộng người dùng | Chi phí vận hành và bảo trì; thường rẻ hơn về dài hạn nếu dùng nhiều và lâu dài |
| Kiểm soát dữ liệu | Dữ liệu nằm trên hệ thống nhà cung cấp; phụ thuộc điều khoản của họ | Doanh nghiệp kiểm soát nơi lưu trữ và cách xử lý dữ liệu của mình |
| Khả năng tùy biến | Giới hạn trong các thiết lập cho phép | Gần như không giới hạn, theo đúng yêu cầu nghiệp vụ |
| Tích hợp hệ thống sẵn có | Tích hợp chuẩn với các hệ thống phổ biến; hệ thống đặc thù khó kết nối | Tích hợp sâu với ERP, CRM, phần mềm nội bộ kể cả hệ thống cũ |
| Rủi ro chính | Phụ thuộc nhà cung cấp; nhà cung cấp đổi giá, đổi tính năng hoặc ngừng dịch vụ | Dự án kéo dài, vượt ngân sách; chất lượng phụ thuộc đội ngũ triển khai |
| Phù hợp khi | Bài toán phổ biến (chatbot FAQ, tạo nội dung, họp trực tuyến); cần dùng ngay; ngân sách hạn chế | Bài toán đặc thù, dữ liệu nhạy cảm, quy trình riêng, cần tích hợp sâu hoặc tạo lợi thế cạnh tranh |
Quy tắc thực hành được nhiều chuyên gia khuyên dùng: hãy mua trước khi xây. Trước khi quyết định đặt làm, doanh nghiệp nên kiểm tra xem thị trường đã có giải pháp đóng gói nào đáp ứng được 80% yêu cầu hay không — vì 20% còn lại thường có thể bù bằng cách điều chỉnh quy trình, thay vì bỏ tiền xây mới toàn bộ. Chỉ đặt làm khi bài toán có ít nhất một trong bốn đặc điểm sau: quy trình nghiệp vụ đặc thù đến mức không phần mềm nào trên thị trường đáp ứng được; dữ liệu quá nhạy cảm để đưa lên hệ thống của nhà cung cấp bên ngoài; giải pháp AI là lợi thế cạnh tranh cốt lõi của doanh nghiệp (ví dụ mô hình chấm điểm riêng, mô hình dự báo riêng); hoặc cần tích hợp sâu với hệ thống cũ mà phần mềm đóng gói không kết nối được. Ngược lại, nếu bài toán là chatbot FAQ thông thường, tóm tắt văn bản hay tạo nội dung marketing — những việc mà nhiều công cụ có sẵn đã làm tốt — thì đặt làm thường là lãng phí.
Ngoài ra còn có lựa chọn trung gian mà nhiều doanh nghiệp đang áp dụng: tùy biến trên nền tảng có sẵn — mua nền tảng AI rồi thuê đơn vị triển khai cấu hình sâu, nạp dữ liệu nội bộ, xây thêm tính năng riêng. Cách này nhanh hơn phát triển từ đầu, rẻ hơn, nhưng vẫn đạt mức khớp nghiệp vụ khá cao. Khi làm việc với đơn vị triển khai, doanh nghiệp nên hỏi rõ giải pháp đề xuất nằm ở cấp độ nào trong ba cấp độ trên — dùng sẵn, tùy biến trên nền tảng, hay xây mới hoàn toàn — vì mỗi cấp độ có chi phí, thời gian và rủi ro rất khác nhau, và không ít báo giá “phát triển theo yêu cầu” thực chất chỉ là cấu hình một nền tảng có sẵn với giá của dự án xây mới.
Các loại giải pháp AI đặt làm phổ biến trong doanh nghiệp
Dưới đây là năm loại giải pháp AI được doanh nghiệp đặt làm nhiều nhất hiện nay, kèm mô tả cách hoạt động, dữ liệu cần có và giới hạn thực tế của từng loại. Hiểu rõ từng loại giúp doanh nghiệp mô tả đúng bài toán của mình khi làm việc với đơn vị triển khai — và nhận ra ngay khi có ai hứa hẹn vượt quá khả năng thật của công nghệ.
Chatbot nội bộ và trợ lý tri thức
Chatbot nội bộ (trợ lý tri thức) là hệ thống trả lời câu hỏi của nhân viên hoặc khách hàng dựa trên tài liệu và dữ liệu riêng của doanh nghiệp: quy định, quy trình, chính sách, hướng dẫn sản phẩm, dữ liệu khách hàng. Về mặt kỹ thuật, đa số hệ thống này dùng kiến trúc RAG: tài liệu nội bộ được chia nhỏ, chuyển thành vector và lưu trong cơ sở dữ liệu vector; khi có câu hỏi, hệ thống tìm các đoạn tài liệu liên quan nhất, đưa vào ngữ cảnh cho mô hình ngôn ngữ lớn rồi sinh câu trả lời kèm trích dẫn nguồn. Điểm mạnh của RAG là mô hình không cần huấn luyện lại khi tài liệu thay đổi — chỉ cần cập nhật kho tài liệu. Điểm yếu là chất lượng câu trả lời phụ thuộc trực tiếp vào chất lượng tài liệu: tài liệu lỗi thời, mâu thuẫn nhau hay viết mơ hồ sẽ cho ra câu trả lời lỗi thời, mâu thuẫn hay mơ hồ. Dữ liệu cần có: bộ tài liệu nội bộ đã được rà soát, cập nhật và phân quyền truy cập theo vai trò (nhân viên kho chỉ xem được tài liệu kho, nhân viên kinh doanh chỉ xem được tài liệu bán hàng). Giới hạn cần biết: chatbot RAG trả lời dựa trên tài liệu, không “hiểu” nghiệp vụ như con người; với câu hỏi vượt ngoài tài liệu, hệ thống tốt sẽ nói “không tìm thấy thông tin” thay vì bịa ra câu trả lời — và doanh nghiệp nên yêu cầu hành vi này trong tiêu chí nghiệm thu.
Xử lý tài liệu tự động (IDP)
Xử lý tài liệu thông minh (Intelligent Document Processing — IDP) là hệ thống tự động đọc, trích xuất và phân loại thông tin từ tài liệu: hóa đơn, hợp đồng, chứng từ vận chuyển, hồ sơ nhân sự, đơn đặt hàng. Hệ thống kết hợp nhận dạng ký tự quang học (OCR) để đọc chữ trong ảnh hoặc file scan, mô hình ngôn ngữ để hiểu ngữ cảnh và trích xuất đúng trường thông tin (số tiền, ngày tháng, tên đối tác, mã hàng), và logic kiểm tra để đối chiếu với dữ liệu trong hệ thống (ví dụ hóa đơn có khớp với đơn đặt hàng không). Giá trị lớn nhất của IDP nằm ở khối lượng: một doanh nghiệp xử lý hàng nghìn chứng từ mỗi tháng sẽ tiết kiệm được rất nhiều giờ nhập liệu thủ công và giảm lỗi sai sót. Dữ liệu cần có: mẫu tài liệu thật (ít nhất vài trăm mẫu cho mỗi loại chứng từ để huấn luyện và kiểm thử), và quy tắc nghiệp vụ về cách xử lý từng trường hợp (chứng từ thiếu thông tin thì làm gì, sai lệch số tiền thì chuyển cho ai). Giới hạn cần biết: IDP đạt độ chính xác cao với tài liệu có mẫu ổn định (hóa đơn của cùng một nhà cung cấp), nhưng độ chính xác giảm với tài liệu viết tay, scan mờ, hoặc mẫu chứng từ thay đổi liên tục — vì vậy hợp đồng nên quy định rõ độ chính xác cam kết theo từng loại tài liệu, không phải một con số chung cho mọi loại.
Dự báo và phân tích dự đoán
Mô hình dự báo (predictive analytics) dùng dữ liệu lịch sử để dự đoán sự kiện tương lai: dự báo nhu cầu sản phẩm, dự báo khách hàng có khả năng rời bỏ, chấm điểm khách hàng tiềm năng, dự báo dòng tiền. Về mặt kỹ thuật, đây là bài toán học máy có giám sát (supervised learning): mô hình học mối quan hệ giữa các yếu tố đầu vào (lịch sử mua hàng, mùa vụ, giá, chương trình khuyến mãi) và kết quả cần dự đoán, rồi áp dụng mối quan hệ đó cho dữ liệu mới. Khác với chatbot dùng mô hình ngôn ngữ lớn có sẵn, mô hình dự báo thường được huấn luyện riêng trên dữ liệu của doanh nghiệp, vì mỗi doanh nghiệp có đặc điểm nhu cầu và hành vi khách hàng khác nhau. Dữ liệu cần có: dữ liệu lịch sử đủ dài (thường ít nhất 12–24 tháng cho dự báo theo mùa), đủ sạch và có các trường liên quan; nếu dữ liệu lịch sử chỉ có vài tháng hoặc thiếu trường quan trọng, mô hình sẽ không đáng tin. Giới hạn cần biết: dự báo là xác suất, không phải chắc chắn — một mô hình tốt cho ra dự báo kèm khoảng tin cậy và sai số đo được, chứ không cho ra “con số chính xác tuyệt đối”; và mô hình cần được huấn luyện lại định kỳ khi thị trường thay đổi, nếu không độ chính xác sẽ suy giảm dần theo thời gian (hiện tượng dữ liệu trôi — data drift).
Thị giác máy tính (Computer Vision)
Thị giác máy tính là hệ thống AI “nhìn” và hiểu hình ảnh hoặc video: kiểm tra chất lượng sản phẩm trên dây chuyền, đếm và phân loại hàng hóa trong kho, nhận diện biển số xe, giám sát an toàn lao động, phân loại hình ảnh sản phẩm. Về mặt kỹ thuật, các hệ thống này dùng mạng nơ-ron tích chập (CNN) hoặc các kiến trúc thị giác hiện đại (Vision Transformer) để phát hiện đối tượng, phân loại hoặc phân đoạn hình ảnh. Phần lớn dự án thị giác máy tính đặt làm không huấn luyện mô hình từ đầu mà tinh chỉnh một mô hình đã được huấn luyện trước trên dữ liệu hình ảnh lớn, bằng dữ liệu hình ảnh riêng của doanh nghiệp — ví dụ ảnh sản phẩm lỗi và sản phẩm đạt chuẩn do chính doanh nghiệp chụp trong điều kiện ánh sáng và góc máy thật của nhà xưởng. Dữ liệu cần có: bộ ảnh thật được gắn nhãn (labelled) cẩn thận — thường cần hàng nghìn ảnh cho mỗi loại đối tượng cần nhận diện, chụp trong đúng điều kiện vận hành thật. Giới hạn cần biết: mô hình thị giác rất nhạy với điều kiện môi trường — đổi ánh sáng, đổi góc camera hay đổi mẫu mã sản phẩm là độ chính xác có thể giảm mạnh; vì vậy dự án cần bao gồm cả việc chuẩn hóa điều kiện thu hình (đèn, camera, vị trí) chứ không chỉ phần mềm.
Trợ lý AI cho quy trình nghiệp vụ (AI Agent theo quy trình)
Trợ lý AI theo quy trình — thường được gọi là AI Agent — là hệ thống không chỉ trả lời mà còn thực hiện nhiều bước công việc: đọc email, tra cứu dữ liệu, soạn thảo, gửi đi sau khi được phê duyệt, cập nhật hệ thống. Về mặt kỹ thuật, agent dùng mô hình ngôn ngữ làm “bộ não” ra quyết định, gọi công cụ (API, cơ sở dữ liệu, email) làm “tay chân”, và lặp lại chu trình suy luận – hành động – quan sát cho đến khi hoàn thành nhiệm vụ. Loại giải pháp này đang được quan tâm nhiều vì nó tự động hóa cả quy trình chứ không chỉ một bước, nhưng cũng là loại rủi ro nhất: agent hành động trên hệ thống thật nên sai sót có thể gây hậu quả thật (gửi nhầm email, cập nhật sai dữ liệu). Vì vậy, dự án agent đặt làm bắt buộc phải có cơ chế “con người phê duyệt” (human-in-the-loop) tại các bước nhạy cảm, giới hạn số bước tối đa, và nhật ký đầy đủ mọi hành động để truy vết. Doanh nghiệp chỉ nên đặt làm agent sau khi đã có kinh nghiệm với các loại giải pháp đơn giản hơn, và chỉ cho một quy trình cụ thể, có quy tắc rõ ràng — không nên bắt đầu hành trình AI bằng một agent đa năng.
Quy trình phát triển AI theo yêu cầu: 7 bước từ phân tích nghiệp vụ đến vận hành
Một dự án AI đặt làm thành công không bắt đầu bằng code mà bắt đầu bằng nghiệp vụ, và không kết thúc khi bàn giao mà kết thúc khi hệ thống vận hành ổn định và tạo ra giá trị đo được. Quy trình dưới đây gồm 7 bước, áp dụng cho hầu hết các loại giải pháp AI đặt làm. Mỗi bước có đầu ra cụ thể — doanh nghiệp nên yêu cầu đơn vị triển khai bàn giao đúng đầu ra của từng bước trước khi chuyển sang bước sau, thay vì để dự án trôi từ ý tưởng thẳng tới sản phẩm mà không có điểm kiểm chứng giữa chừng.
Bước 1: Khảo sát nghiệp vụ và xác định bài toán
Khảo sát nghiệp vụ (business discovery) là bước tìm hiểu sâu về cách doanh nghiệp đang vận hành: quy trình hiện tại chạy như thế nào, ai làm gì, dữ liệu chảy ra sao, điểm đau nằm ở đâu, và kết quả mong muốn là gì. Đầu ra của bước này là một bản mô tả bài toán (problem statement) viết bằng ngôn ngữ nghiệp vụ, không phải ngôn ngữ kỹ thuật — ví dụ: “Nhân viên chăm sóc khách hàng mất trung bình 12 phút để tra cứu chính sách đổi trả cho mỗi yêu cầu, và 20% câu trả lời bị sai do tra cứu nhầm phiên bản chính sách cũ”. Một bản mô tả bài toán tốt trả lời được năm câu hỏi: ai gặp vấn đề, vấn đề xảy ra khi nào và thường xuyên ra sao, hậu quả hiện tại là gì (tiền, thời gian, sự hài lòng), kết quả mong muốn đo bằng chỉ số nào, và phạm vi của bài toán (chỉ một bộ phận hay toàn công ty).
Bước này thường kéo dài 1–3 tuần, gồm phỏng vấn người dùng cuối, quan sát quy trình thật, và xem xét tài liệu và hệ thống hiện có. Sai lầm lớn nhất ở bước này là để đội kỹ thuật tự suy ra bài toán từ mô tả chung chung của lãnh đạo, mà không nói chuyện với người trực tiếp làm công việc đó mỗi ngày. Người làm công việc thật luôn biết những ngoại lệ, những “mẹo” không có trong quy trình viết sẵn, và những trường hợp mà hệ thống AI sẽ xử lý sai nếu không được biết trước. Doanh nghiệp nên yêu cầu đơn vị triển khai dành thời gian ngồi cùng người dùng cuối, xem họ làm việc thật, trước khi viết bất kỳ tài liệu thiết kế nào. Chi phí của vài ngày khảo sát kỹ là rất nhỏ so với chi phí sửa một hệ thống đã xây sai bài toán.
Bước 2: Xác định bài toán AI và tiêu chí thành công
Xác định bài toán AI là bước chuyển bài toán nghiệp vụ thành bài toán kỹ thuật: xác định rõ hệ thống AI sẽ nhận đầu vào gì, cho ra đầu ra gì, và thành công được đo như thế nào. Ví dụ: bài toán nghiệp vụ “trả lời yêu cầu đổi trả nhanh hơn và chính xác hơn” trở thành bài toán kỹ thuật “hệ thống nhận câu hỏi của khách hàng bằng tiếng Việt, truy xuất chính sách đổi trả hiện hành từ kho tài liệu, và trả lời kèm trích dẫn nguồn, với độ chính xác tối thiểu 90% trên bộ kiểm thử 200 câu hỏi thật”. Bước này cũng quyết định loại giải pháp phù hợp: bài toán này cần RAG hay cần huấn luyện mô hình riêng? Cần xử lý văn bản, hình ảnh hay dữ liệu dạng bảng? Cần trả lời theo thời gian thực hay xử lý theo lô là đủ?
Phần quan trọng nhất của bước 2 là tiêu chí thành công đo được. Doanh nghiệp và đơn vị triển khai phải thống nhất trước: độ chính xác tối thiểu là bao nhiêu, đo trên bộ dữ liệu nào, thời gian phản hồi tối đa là bao lâu, và chỉ số kinh doanh nào sẽ cải thiện (thời gian xử lý, chi phí, mức độ hài lòng). Nếu không thống nhất tiêu chí thành công ở bước này, giai đoạn nghiệm thu về sau sẽ rơi vào tranh cãi “hệ thống có tốt hay không” mà không có thước đo chung. Một thực hành tốt là xây bộ kiểm thử (test set) ngay ở bước 2: thu thập 50–200 trường hợp thật kèm đáp án đúng, và dùng chính bộ này để đánh giá hệ thống ở mọi giai đoạn sau. Bộ kiểm thử này phải do phía nghiệp vụ cung cấp hoặc phê duyệt — không để đội kỹ thuật tự tạo bộ kiểm thử rồi tự chấm điểm sản phẩm của mình.
Bước 3: Thu thập, đánh giá và chuẩn hóa dữ liệu
Chuẩn bị dữ liệu là bước tốn nhiều thời gian nhất trong đa số dự án AI — thường chiếm 50–70% tổng thời gian dự án — và cũng là bước quyết định chất lượng cuối cùng của hệ thống. Công việc gồm: thu thập dữ liệu từ các hệ thống nguồn (ERP, CRM, file, email, kho tài liệu); đánh giá chất lượng (đầy đủ, chính xác, nhất quán, cập nhật); làm sạch (loại trùng lặp, sửa lỗi, chuẩn hóa định dạng); gắn nhãn nếu cần (ví dụ gắn nhãn ảnh sản phẩm lỗi/đạt chuẩn, gắn nhãn email theo loại yêu cầu); và chia dữ liệu thành tập huấn luyện, tập kiểm chứng và tập kiểm thử — ba tập tách biệt, không trùng lặp, để việc đánh giá mô hình là trung thực.
Ba vấn đề thường phát sinh ở bước này. Thứ nhất là dữ liệu không đủ: doanh nghiệp tưởng mình có nhiều dữ liệu nhưng khi gom lại mới thấy thiếu trường quan trọng hoặc lịch sử quá ngắn — lúc này phải quyết định thu thập thêm, thu hẹp phạm vi bài toán, hoặc đổi sang bài toán khác khả thi hơn. Thứ hai là dữ liệu nhạy cảm: dữ liệu chứa thông tin cá nhân khách hàng, bí mật kinh doanh hay dữ liệu tài chính — cần xử lý ẩn danh, mã hóa hoặc giới hạn quyền truy cập ngay từ bước thu thập, và tuân thủ Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân. Thứ ba là dữ liệu mâu thuẫn: cùng một thông tin nhưng các hệ thống ghi khác nhau (giá khác nhau, tên khách hàng viết khác nhau) — cần thống nhất nguồn dữ liệu chuẩn (single source of truth) cho từng loại thông tin trước khi đưa vào huấn luyện. Đầu ra của bước 3 là một báo cáo chất lượng dữ liệu: dữ liệu nào đã có, chất lượng ra sao, đã xử lý những gì, và còn hạn chế nào ảnh hưởng tới độ chính xác của mô hình. Báo cáo này phải được phía doanh nghiệp xác nhận — vì nó là cơ sở để đặt kỳ vọng đúng về kết quả ở các bước sau.
Bước 4: Thiết kế giải pháp — kiến trúc, mô hình và tích hợp
Thiết kế giải pháp (solution design) là bước vẽ ra toàn bộ hệ thống trên giấy trước khi xây: kiến trúc tổng thể, lựa chọn mô hình, cách dữ liệu chảy qua hệ thống, cách tích hợp với hệ thống sẵn có, giao diện người dùng, và cơ chế bảo mật, giám sát. Tài liệu thiết kế tốt trả lời được: hệ thống gồm những thành phần nào và mỗi thành phần làm gì; dữ liệu đi từ đâu tới đâu; khi mô hình sai thì hệ thống xử lý ra sao; khi API nhà cung cấp mô hình gặp sự cố thì có phương án dự phòng không; ai được xem dữ liệu nào; và hệ thống được giám sát bằng chỉ số gì sau triển khai.
Quyết định kỹ thuật quan trọng nhất ở bước này là chọn mô hình: dùng mô hình có sẵn qua API, tinh chỉnh mô hình có sẵn, hay huấn luyện mô hình riêng. Với đa số dự án doanh nghiệp, lựa chọn đúng là một trong hai phương án đầu: dùng mô hình ngôn ngữ lớn qua API kết hợp RAG cho bài toán văn bản, hoặc tinh chỉnh mô hình có sẵn cho bài toán dự báo và thị giác. Quyết định này cần cân nhắc bốn yếu tố: độ chính xác yêu cầu, chi phí vận hành (giá API tính theo lượng dùng so với chi phí tự vận hành mô hình), yêu cầu về dữ liệu (dữ liệu có được phép gửi lên API bên ngoài không), và khả năng đổi nhà cung cấp sau này (hệ thống có bị khóa chặt vào một nhà cung cấp không). Một thiết kế tốt luôn tách lớp mô hình ra khỏi logic nghiệp vụ — để sau này đổi mô hình khác mà không phải viết lại toàn bộ hệ thống. Doanh nghiệp nên yêu cầu đơn vị triển khai trình bày ít nhất hai phương án kiến trúc kèm ưu – nhược điểm và chi phí ước tính, thay vì chấp nhận ngay phương án đầu tiên được đề xuất.
Bước 5: Huấn luyện, tinh chỉnh và kiểm thử mô hình
Huấn luyện và tinh chỉnh mô hình là bước kỹ thuật trung tâm: với mô hình dự báo hoặc thị giác, đội ngũ huấn luyện mô hình trên tập dữ liệu đã chuẩn bị; với giải pháp dùng mô hình ngôn ngữ lớn, đội ngũ tinh chỉnh (fine-tuning) trên dữ liệu riêng của doanh nghiệp hoặc xây kho tri thức RAG và viết prompt hệ thống, rồi kiểm thử trên tập kiểm thử đã thống nhất ở bước 2. Nguyên tắc quan trọng: mô hình chỉ được đánh giá trên dữ liệu mà nó chưa từng thấy trong quá trình huấn luyện — đánh giá trên dữ liệu huấn luyện sẽ cho ra con số đẹp giả tạo. Ngoài độ chính xác tổng thể, cần đo thêm các chỉ số theo từng nhóm: mô hình có chính xác với mọi loại tài liệu, mọi nhóm khách hàng hay chỉ đúng với nhóm phổ biến nhất? Có trường hợp biên nào mô hình sai nghiêm trọng không? Thời gian phản hồi có đáp ứng yêu cầu không?
Bước 5 thường diễn ra theo vòng lặp: huấn luyện → đo → phân tích lỗi → cải thiện dữ liệu hoặc điều chỉnh mô hình → đo lại. Phân tích lỗi là phần tạo ra giá trị lớn nhất: xem 20–30 trường hợp mô hình sai, phân loại nguyên nhân (dữ liệu sai, tài liệu mâu thuẫn, câu hỏi mơ hồ, mô hình hiểu sai), rồi sửa đúng nguyên nhân đó — thay vì chỉ “huấn luyện thêm” một cách mù quáng. Doanh nghiệp nên yêu cầu báo cáo kiểm thử sau mỗi vòng lặp: độ chính xác hiện tại, các loại lỗi còn tồn tại, và dự kiến cần bao nhiêu vòng lặp nữa để đạt tiêu chí đã thống nhất. Nếu sau 2–3 vòng lặp mà độ chính xác không cải thiện, đó là tín hiệu cần xem lại bài toán hoặc dữ liệu — chứ không phải cứ tiếp tục huấn luyện với hy vọng điều kỳ diệu xảy ra.
Bước 6: Tích hợp, triển khai và đào tạo người dùng
Tích hợp và triển khai là bước đưa hệ thống AI vào vận hành thật: kết nối với ERP, CRM, email, kho dữ liệu; xây giao diện người dùng; thiết lập phân quyền; và triển khai lên môi trường vận hành (production). Đây là bước mà nhiều dự án kỹ thuật tốt vẫn thất bại, vì tích hợp với hệ thống cũ luôn phức tạp hơn dự kiến: API không có tài liệu đầy đủ, dữ liệu hai hệ thống không khớp định dạng, hệ thống cũ không chịu được tải truy vấn mới. Vì vậy, bước 6 nên bắt đầu bằng một đợt triển khai thử (pilot) giới hạn: một bộ phận, một nhóm người dùng, một phần lưu lượng thật — chạy song song với cách làm cũ trong 2–4 tuần, so sánh kết quả, sửa lỗi, rồi mới mở rộng dần.
Song song với triển khai kỹ thuật là đào tạo người dùng và thay đổi quy trình. Người dùng cần biết: hệ thống làm được gì và không làm được gì, khi nào nên tin kết quả của AI và khi nào phải kiểm tra lại, làm gì khi AI sai, và ai là người hỗ trợ khi gặp sự cố. Quy trình làm việc phải được viết lại chính thức: bước nào do AI làm, bước nào do người làm, điểm chuyển giao ở đâu, và ai chịu trách nhiệm cuối cùng. Một thực hành tốt là chỉ định một nhóm người dùng “đại sứ” (champion users) — những người dùng đầu tiên, hiểu rõ hệ thống và hỗ trợ đồng nghiệp — thay vì đào tạo ồ ạt một lần rồi để mọi người tự xoay xở. Nghiệm thu chỉ nên diễn ra sau khi hệ thống đã chạy thử với người dùng thật, không phải ngay khi code vừa xong.
Bước 7: Vận hành, giám sát và bảo trì
Vận hành và bảo trì là bước dài nhất trong vòng đời của một hệ thống AI — kéo dài nhiều năm sau khi dự án “kết thúc” — nhưng lại là bước hay bị bỏ quên nhất trong hợp đồng. Mô hình AI không giống phần mềm thông thường: chất lượng của nó suy giảm theo thời gian khi dữ liệu thực tế thay đổi (khách hàng mới, sản phẩm mới, cách viết mới), khi tài liệu nội bộ được cập nhật mà kho tri thức chưa cập nhật theo, hoặc khi nhà cung cấp mô hình thay đổi phiên bản. Vì vậy, hệ thống AI cần được giám sát liên tục: độ chính xác theo thời gian, tỷ lệ người dùng chấp nhận hay sửa lại kết quả của AI, thời gian phản hồi, chi phí vận hành, và số lần hệ thống gặp lỗi.
Hợp đồng bảo trì nên quy định rõ: ai giám sát hệ thống hằng ngày; mô hình được huấn luyện lại hoặc kho tri thức được cập nhật với tần suất nào và theo quy trình nào; khi độ chính xác giảm xuống dưới ngưỡng nào thì phải can thiệp; thời gian phản hồi sự cố là bao lâu; và chi phí bảo trì gồm những gì. Một điểm cần thỏa thuận ngay từ đầu là quyền sở hữu sau bàn giao: doanh nghiệp sở hữu dữ liệu, mô hình đã tinh chỉnh, mã nguồn và tài liệu ở mức nào; và khi kết thúc hợp đồng với đơn vị triển khai, doanh nghiệp có thể tự vận hành hoặc chuyển cho đơn vị khác mà không bị khóa chặt hay không. Nhiều doanh nghiệp chỉ nhận ra mình bị “khóa” khi muốn đổi nhà cung cấp — lúc đó mới biết mã nguồn, dữ liệu huấn luyện và tài liệu hệ thống đều nằm trong tay đơn vị cũ. Hãy làm rõ điều này trước khi ký hợp đồng, không phải sau khi dự án kết thúc.
| Bước | Đầu ra chính | Ai chịu trách nhiệm chính | Dấu hiệu bước làm tốt |
|---|---|---|---|
| 1. Khảo sát nghiệp vụ | Bản mô tả bài toán bằng ngôn ngữ nghiệp vụ | Phía doanh nghiệp + đơn vị triển khai | Bài toán viết được trong một đoạn văn, có chỉ số đo |
| 2. Xác định bài toán AI | Đặc tả kỹ thuật + tiêu chí thành công + bộ kiểm thử | Đơn vị triển khai, doanh nghiệp phê duyệt | Bộ kiểm thử 50–200 trường hợp thật đã sẵn sàng |
| 3. Chuẩn bị dữ liệu | Báo cáo chất lượng dữ liệu, dữ liệu đã làm sạch | Doanh nghiệp cung cấp, đơn vị triển khai xử lý | Biết rõ dữ liệu còn thiếu gì và ảnh hưởng ra sao |
| 4. Thiết kế giải pháp | Tài liệu thiết kế kiến trúc, lựa chọn mô hình | Đơn vị triển khai | Có ít nhất 2 phương án kèm ưu – nhược điểm |
| 5. Huấn luyện, tinh chỉnh | Mô hình đạt tiêu chí trên tập kiểm thử | Đơn vị triển khai | Báo cáo kiểm thử từng vòng lặp, phân tích lỗi cụ thể |
| 6. Tích hợp, triển khai | Hệ thống chạy thử với người dùng thật | Cả hai bên | Chạy pilot 2–4 tuần song song cách làm cũ |
| 7. Vận hành, bảo trì | Dashboard giám sát, quy trình cập nhật mô hình | Doanh nghiệp vận hành, đơn vị hỗ trợ | Độ chính xác được theo dõi liên tục, có ngưỡng can thiệp |
Cách viết yêu cầu dự án AI (RFP) để nhà cung cấp báo giá đúng
Một bản yêu cầu dự án (Request for Proposal — RFP) tốt là điều kiện tiên quyết để nhận được báo giá đúng và so sánh được các nhà cung cấp với nhau. Ngược lại, một RFP chung chung (“chúng tôi muốn ứng dụng AI để nâng cao hiệu quả”) sẽ nhận về những báo giá chênh lệch gấp nhiều lần mà không thể so sánh — vì mỗi nhà cung cấp hiểu một kiểu. RFP cho dự án AI cần có bảy phần sau.
1. Bối cảnh và bài toán nghiệp vụ: doanh nghiệp làm gì, quy trình hiện tại ra sao, vấn đề gặp phải là gì, và hậu quả hiện tại đo bằng con số nào (thời gian, chi phí, tỷ lệ lỗi). Kèm theo dữ liệu về quy mô: mỗi tháng có bao nhiêu tài liệu, bao nhiêu yêu cầu khách hàng, bao nhiêu giao dịch liên quan.
2. Mục tiêu và tiêu chí thành công: hệ thống phải đạt được gì, đo bằng chỉ số nào, ngưỡng tối thiểu là bao nhiêu. Ví dụ: “độ chính xác trích xuất thông tin hóa đơn tối thiểu 95% trên 500 hóa đơn thật” rõ ràng hơn nhiều so với “hệ thống chính xác cao”.
3. Phạm vi và giới hạn: hệ thống làm gì và không làm gì; người dùng là ai, bao nhiêu người; ngôn ngữ sử dụng (tiếng Việt là yêu cầu riêng cần ghi rõ, vì độ chính xác của mô hình với tiếng Việt khác với tiếng Anh); hệ thống chạy trên cloud hay on-premise.
4. Dữ liệu: doanh nghiệp có dữ liệu gì, ở đâu, định dạng nào, khối lượng bao nhiêu, và dữ liệu nào là nhạy cảm. Nêu rõ ai chịu trách nhiệm cung cấp dữ liệu và thời gian cung cấp. Nếu dữ liệu chưa sẵn sàng, ghi rõ việc chuẩn bị dữ liệu thuộc phạm vi của nhà cung cấp hay của doanh nghiệp.
5. Tích hợp và yêu cầu kỹ thuật: hệ thống AI phải kết nối với những hệ thống nào (tên phần mềm, phiên bản, có API không); yêu cầu về bảo mật, phân quyền, sao lưu; yêu cầu về thời gian phản hồi và số người dùng đồng thời.
6. Quyền sở hữu và bảo trì: doanh nghiệp sở hữu gì sau bàn giao (dữ liệu, mô hình đã tinh chỉnh, mã nguồn, tài liệu); thời gian bảo hành và bảo trì bao lâu; thời gian phản hồi sự cố; điều khoản chuyển giao khi kết thúc hợp đồng.
7. Quy trình lựa chọn: thời hạn nộp đề xuất, các vòng đánh giá (hồ sơ, thuyết trình, bản thử nghiệm), và tiêu chí chấm điểm — ví dụ kinh nghiệm dự án tương tự chiếm bao nhiêu phần trăm, phương án kỹ thuật bao nhiêu, giá bao nhiêu. Một thực hành tốt là yêu cầu nhà cung cấp làm bản thử nghiệm nhỏ (proof of concept) trên dữ liệu thật của doanh nghiệp trước khi ký hợp đồng chính thức: một nhà cung cấp dám làm thử nghiệm trên dữ liệu thật và cho xem kết quả đo được thường đáng tin hơn nhiều so với bản trình bày PowerPoint đẹp mắt.
Khi đánh giá đề xuất, doanh nghiệp nên cảnh giác với bốn dấu hiệu: nhà cung cấp hứa độ chính xác 99–100% mà chưa xem dữ liệu thật; báo giá rẻ bất thường so với các nhà cung cấp khác (thường đồng nghĩa với việc cắt bớt bước kiểm thử, bảo trì hoặc dùng giải pháp có sẵn đội lốt “xây mới”); không nêu rõ ai sở hữu dữ liệu và mô hình sau bàn giao; và không có kế hoạch vận hành, giám sát sau triển khai. Bất kỳ dấu hiệu nào trong bốn dấu hiệu này cũng đủ lý do để yêu cầu làm rõ trước khi ký hợp đồng.
Tiêu chí nghiệm thu giải pháp AI đặt làm
Nghiệm thu là bước xác nhận hệ thống đã làm đúng những gì đã cam kết, trên dữ liệu và quy trình thật của doanh nghiệp. Khác với phần mềm thông thường — nơi nghiệm thu chủ yếu là kiểm tra tính năng có chạy hay không — nghiệm thu AI phải kiểm tra cả chất lượng của mô hình, vì một hệ thống AI “chạy được” vẫn có thể cho ra kết quả sai ở tỷ lệ không chấp nhận được. Dưới đây là checklist nghiệm thu mà doanh nghiệp nên đưa vào hợp đồng ngay từ đầu.
- Độ chính xác trên tập kiểm thử độc lập: hệ thống đạt ngưỡng đã thống nhất (ví dụ 90% câu trả lời đúng) trên bộ kiểm thử 50–200 trường hợp thật mà đội kỹ thuật chưa dùng để huấn luyện. Bộ kiểm thử do phía nghiệp vụ cung cấp hoặc phê duyệt.
- Độ chính xác theo từng nhóm: không chỉ đo con số tổng thể mà đo theo từng loại tài liệu, từng nhóm khách hàng, từng loại câu hỏi — để phát hiện trường hợp hệ thống đúng với nhóm phổ biến nhưng sai nhiều với nhóm ít gặp.
- Hành vi khi không biết: với câu hỏi ngoài phạm vi tài liệu, hệ thống nói “không tìm thấy thông tin” hoặc chuyển cho người xử lý, thay vì bịa ra câu trả lời. Kiểm thử ít nhất 10–20 câu hỏi ngoài phạm vi để xác nhận hành vi này.
- Thời gian phản hồi: hệ thống trả lời trong giới hạn đã cam kết với lưu lượng người dùng thật, không chỉ khi kiểm thử với một người dùng duy nhất.
- Tích hợp hoạt động được: dữ liệu chảy đúng giữa hệ thống AI và ERP/CRM/email; phân quyền theo vai trò hoạt động đúng; dữ liệu cá nhân được xử lý đúng quy định.
- Khả năng giải thích và truy vết: với chatbot RAG, mỗi câu trả lời kèm trích dẫn nguồn tài liệu; với mô hình dự báo, có nhật ký đầu vào – đầu ra để kiểm tra lại khi cần.
- Người dùng cuối chấp nhận: nhóm người dùng thử nghiệm (pilot) xác nhận hệ thống dùng được trong công việc thật, sau ít nhất 2 tuần chạy thử — không nghiệm thu chỉ dựa trên demo của đội kỹ thuật.
- Tài liệu bàn giao đầy đủ: tài liệu kiến trúc, hướng dẫn vận hành, hướng dẫn xử lý sự cố, báo cáo kiểm thử, và danh mục dữ liệu đã dùng để huấn luyện.
- Quyền sở hữu đã chuyển giao: mã nguồn, mô hình đã tinh chỉnh, dữ liệu huấn luyện và tài liệu đã được bàn giao theo đúng điều khoản hợp đồng, và doanh nghiệp đã kiểm tra có thể tự vận hành hoặc chuyển giao cho đơn vị khác.
- Kế hoạch vận hành sau bàn giao: dashboard giám sát đã hoạt động, ngưỡng can thiệp đã đặt, lịch cập nhật mô hình hoặc kho tri thức đã thống nhất, và đầu mối hỗ trợ sự cố đã rõ ràng.
Một nguyên tắc nghiệm thu quan trọng: không nghiệm thu theo cảm nhận, chỉ nghiệm thu theo số liệu và checklist. Mỗi tiêu chí cần có cách đo cụ thể và bằng chứng đi kèm — báo cáo kiểm thử, nhật ký chạy thử, xác nhận của người dùng. Nếu một tiêu chí chưa đạt, hợp đồng nên quy định rõ: đơn vị triển khai có bao nhiêu thời gian để sửa, sửa không đạt thì xử lý thế nào (giảm giá, kéo dài bảo hành, hay chấm dứt hợp đồng). Thỏa thuận này phải có trước khi nghiệm thu, không phải đợi đến khi tranh chấp mới bàn.
Rủi ro thường gặp khi phát triển AI theo yêu cầu và cách phòng tránh
| Rủi ro | Dấu hiệu | Cách phòng tránh |
|---|---|---|
| Xây sai bài toán | Hệ thống chạy tốt về kỹ thuật nhưng không ai dùng, hoặc không giải quyết được vấn đề thật | Khảo sát nghiệp vụ kỹ ở bước 1, ngồi cùng người dùng cuối; thống nhất bản mô tả bài toán trước khi thiết kế |
| Dữ liệu không đủ tốt | Độ chính xác giậm chân tại chỗ dù đã huấn luyện nhiều vòng; mô hình sai với dữ liệu mới | Đánh giá chất lượng dữ liệu ở bước 3 trước khi cam kết độ chính xác; đặt kỳ vọng theo đúng thực trạng dữ liệu |
| Dự án kéo dài, vượt ngân sách | Phạm vi cứ phình ra; mỗi tuần lại thêm yêu cầu mới; không có mốc kiểm chứng | Chốt phạm vi trong RFP; chia dự án thành giai đoạn, mỗi giai đoạn có đầu ra và nghiệm thu riêng; mọi thay đổi phạm vi đều phải đánh giá lại thời gian và chi phí |
| Mô hình “ảo tưởng” (hallucination) | Chatbot trả lời tự tin nhưng sai sự thật, bịa chính sách hoặc con số không có trong tài liệu | Dùng RAG với trích dẫn nguồn; yêu cầu hệ thống nói “không biết” khi ngoài tài liệu; kiểm thử riêng các câu hỏi ngoài phạm vi |
| Rò rỉ dữ liệu nhạy cảm | Dữ liệu khách hàng hoặc bí mật kinh doanh bị gửi lên hệ thống bên ngoài không kiểm soát | Rà soát điều khoản dữ liệu của nhà cung cấp mô hình; ẩn danh dữ liệu trước khi huấn luyện; phân quyền theo vai trò |
| Phụ thuộc nhà cung cấp (vendor lock-in) | Muốn đổi đơn vị triển khai nhưng không có mã nguồn, dữ liệu huấn luyện hay tài liệu | Quy định quyền sở hữu trong hợp đồng; yêu cầu bàn giao mã nguồn, mô hình và tài liệu; tách lớp mô hình khỏi logic nghiệp vụ |
| Mô hình suy giảm chất lượng theo thời gian | Độ chính xác giảm dần sau vài tháng; người dùng phàn nàn ngày càng nhiều | Giám sát liên tục với ngưỡng can thiệp; lên lịch huấn luyện lại và cập nhật kho tri thức định kỳ; ghi rõ trách nhiệm bảo trì trong hợp đồng |
| Người dùng không chấp nhận | Hệ thống bàn giao xong nhưng nhân viên vẫn làm theo cách cũ | Đào tạo theo vai trò; chỉ định người dùng đại sứ; chạy pilot song song cách làm cũ; thiết kế lại quy trình chính thức |
| Thiên vị và quyết định không công bằng | Mô hình cho kết quả khác nhau một cách hệ thống giữa các nhóm khách hàng hoặc ứng viên | Kiểm thử thiên vị trước triển khai trên các nhóm khác nhau; ghi nhật ký quyết định; có người rà soát các quyết định quan trọng |
| Chi phí vận hành vượt dự kiến | Hóa đơn API tăng vọt khi mở rộng người dùng; chi phí tính toán vượt ngân sách | Ước tính chi phí theo lưu lượng thật ngay từ thiết kế; đặt ngân sách và cảnh báo chi phí; cân nhắc mô hình nhỏ hơn cho tác vụ đơn giản |
Nhìn chung, hầu hết rủi ro của dự án AI đặt làm đều có thể phòng tránh được bằng ba thói quen: thống nhất mọi thứ bằng văn bản có số liệu trước khi xây (bài toán, tiêu chí thành công, quyền sở hữu); kiểm chứng từng bước bằng dữ liệu thật thay vì chờ đến cuối dự án; và giữ lại quyền kiểm soát — về dữ liệu, về mô hình, về khả năng chuyển đổi nhà cung cấp — trong tay doanh nghiệp. Một dự án AI đặt làm thành công không phải là dự án dùng công nghệ mới nhất, mà là dự án giải quyết đúng bài toán, với dữ liệu đủ tốt, được người dùng thật chấp nhận, và vẫn tạo ra giá trị sau 6–12 tháng vận hành.
Liên hệ AIA qua hotline 0939 936 168 để được tư vấn phát triển giải pháp AI theo yêu cầu phù hợp với bài toán và hệ thống của doanh nghiệp bạn.
Câu hỏi thường gặp (FAQs)
Phát triển AI theo yêu cầu là gì?
Phát triển AI theo yêu cầu là quá trình xây dựng một giải pháp trí tuệ nhân tạo được thiết kế riêng cho bài toán, dữ liệu, quy trình và hệ thống cụ thể của một doanh nghiệp, thay vì mua phần mềm đóng gói dùng chung cho mọi khách hàng. Giải pháp đặt làm có thể là chatbot trên tài liệu nội bộ, hệ thống xử lý chứng từ tự động, mô hình dự báo nhu cầu hay trợ lý AI theo quy trình. Trong thực tế, phát triển theo yêu cầu thường có nghĩa là dùng mô hình nền tảng có sẵn rồi tinh chỉnh hoặc bổ sung dữ liệu riêng của doanh nghiệp qua RAG, kết hợp với logic nghiệp vụ và tích hợp hệ thống được xây riêng — chứ không phải huấn luyện một mô hình ngôn ngữ lớn từ con số không.
Khi nào doanh nghiệp nên phát triển AI theo yêu cầu thay vì mua phần mềm có sẵn?
Doanh nghiệp nên đặt làm khi bài toán có ít nhất một trong bốn đặc điểm: quy trình nghiệp vụ đặc thù đến mức không phần mềm nào trên thị trường đáp ứng được; dữ liệu quá nhạy cảm để đưa lên hệ thống của nhà cung cấp bên ngoài; giải pháp AI là lợi thế cạnh tranh cốt lõi; hoặc cần tích hợp sâu với hệ thống cũ mà phần mềm đóng gói không kết nối được. Ngược lại, nếu bài toán là chatbot FAQ thông thường, tóm tắt văn bản hay tạo nội dung — những việc nhiều công cụ có sẵn đã làm tốt — thì mua phần mềm có sẵn nhanh hơn và rẻ hơn nhiều. Quy tắc thực hành là hãy kiểm tra giải pháp có sẵn trước khi quyết định xây mới.
Phát triển AI theo yêu cầu mất bao lâu?
Thời gian phụ thuộc vào độ phức tạp của bài toán và mức độ sẵn sàng của dữ liệu, nhưng một dự án vừa (ví dụ chatbot trên tài liệu nội bộ hoặc hệ thống xử lý chứng từ) thường mất 2–6 tháng từ khảo sát nghiệp vụ đến vận hành thật. Trong đó, bước chuẩn bị dữ liệu thường chiếm 50–70% tổng thời gian, vì thu thập, làm sạch và gắn nhãn dữ liệu là công việc tốn thời gian nhất. Dự án phức tạp hơn — như hệ thống thị giác máy tính trong nhà xưởng hay AI Agent đa bước — có thể kéo dài hơn. Doanh nghiệp nên yêu cầu đơn vị triển khai chia dự án thành giai đoạn, mỗi giai đoạn có đầu ra và mốc nghiệm thu riêng, thay vì chấp nhận một mốc bàn giao duy nhất sau nhiều tháng.
Phát triển AI theo yêu cầu gồm những bước nào?
Quy trình gồm 7 bước: (1) khảo sát nghiệp vụ và xác định bài toán; (2) xác định bài toán AI và tiêu chí thành công đo được; (3) thu thập, đánh giá và chuẩn hóa dữ liệu; (4) thiết kế giải pháp — kiến trúc, mô hình và tích hợp; (5) huấn luyện, tinh chỉnh và kiểm thử mô hình; (6) tích hợp, triển khai và đào tạo người dùng; (7) vận hành, giám sát và bảo trì. Mỗi bước có đầu ra cụ thể và nên được nghiệm thu trước khi chuyển sang bước sau. Bước dài nhất trong vòng đời hệ thống là bước 7 — vận hành và bảo trì kéo dài nhiều năm, vì mô hình AI cần được giám sát và cập nhật liên tục khi dữ liệu thực tế thay đổi.
Cần chuẩn bị dữ liệu như thế nào trước khi phát triển AI theo yêu cầu?
Doanh nghiệp cần chuẩn bị ba thứ: dữ liệu thật của bài toán (tài liệu nội bộ, chứng từ mẫu, dữ liệu lịch sử), quyền sử dụng dữ liệu đó cho mục đích huấn luyện AI, và người hiểu rõ dữ liệu (data owner) để trả lời khi đội kỹ thuật cần làm rõ. Dữ liệu lịch sử nên đủ dài — thường ít nhất 12–24 tháng cho bài toán dự báo — và dữ liệu hình ảnh cần được gắn nhãn cẩn thận. Trước khi cam kết độ chính xác, đơn vị triển khai phải đánh giá chất lượng dữ liệu thực tế và báo cáo rõ dữ liệu còn thiếu gì, vì chất lượng dữ liệu quyết định trực tiếp chất lượng của hệ thống AI cuối cùng.
Làm sao nghiệm thu một giải pháp AI đặt làm?
Nghiệm thu AI phải kiểm tra cả tính năng và chất lượng mô hình. Doanh nghiệp nên yêu cầu: độ chính xác đạt ngưỡng đã thống nhất trên bộ kiểm thử độc lập gồm 50–200 trường hợp thật do phía nghiệp vụ cung cấp; độ chính xác theo từng nhóm tài liệu và nhóm khách hàng; hành vi đúng khi gặp câu hỏi ngoài phạm vi (nói “không biết” thay vì bịa câu trả lời); thời gian phản hồi với lưu lượng thật; tích hợp với hệ thống sẵn có hoạt động được; người dùng cuối xác nhận sau ít nhất 2 tuần chạy thử; và tài liệu cùng quyền sở hữu (mã nguồn, mô hình, dữ liệu huấn luyện) đã được bàn giao đầy đủ. Không nghiệm thu theo cảm nhận — mỗi tiêu chí cần có cách đo cụ thể và bằng chứng đi kèm.
Rủi ro lớn nhất khi phát triển AI theo yêu cầu là gì?
Rủi ro lớn nhất là xây sai bài toán: hệ thống chạy tốt về kỹ thuật nhưng không giải quyết được vấn đề thật của doanh nghiệp, hoặc không ai dùng vì quy trình không thay đổi theo. Rủi ro này phòng tránh bằng cách khảo sát nghiệp vụ kỹ, ngồi cùng người dùng cuối, và thống nhất bản mô tả bài toán có chỉ số đo trước khi thiết kế. Các rủi ro lớn khác gồm dữ liệu không đủ tốt, mô hình bịa thông tin (hallucination), rò rỉ dữ liệu nhạy cảm, phụ thuộc nhà cung cấp do không sở hữu mã nguồn và dữ liệu huấn luyện, và mô hình suy giảm chất lượng theo thời gian do không được giám sát và cập nhật. Tất cả đều có thể phòng tránh bằng hợp đồng rõ ràng, kiểm chứng từng bước bằng dữ liệu thật, và kế hoạch vận hành sau bàn giao.
Doanh nghiệp có sở hữu giải pháp AI đặt làm sau khi bàn giao không?
Điều này phụ thuộc hoàn toàn vào hợp đồng, vì vậy doanh nghiệp phải thỏa thuận rõ trước khi ký. Thông thường, doanh nghiệp luôn sở hữu dữ liệu của mình và mô hình đã được tinh chỉnh trên dữ liệu đó; mã nguồn, tài liệu hệ thống và quyền tiếp tục vận hành độc lập cần được ghi rõ trong hợp đồng — bao gồm cả điều khoản chuyển giao khi kết thúc hợp tác với đơn vị triển khai. Nếu hợp đồng không quy định, doanh nghiệp có thể rơi vào tình trạng bị “khóa” với một nhà cung cấp duy nhất: muốn đổi đơn vị khác cũng không được vì không có mã nguồn, dữ liệu huấn luyện hay tài liệu hệ thống. Hãy làm rõ quyền sở hữu trước khi ký, không phải sau khi dự án kết thúc.
