Công ty ứng dụng AI nào cũng có bộ slide rất đẹp. Biểu đồ bắt mắt, các từ khóa như học máy hay chatbot thông minh xuất hiện dày đặc. Chúng tôi từng thấy nhiều doanh nghiệp gật gù ký hợp đồng chỉ sau một buổi thuyết trình. Theo kinh nghiệm của đội ngũ, khoảng cách giữa một bản đề xuất đẹp và một hệ thống chạy ổn ngoài đời thật có thể rất lớn.
Bài viết này dành cho bạn, người đang cân nhắc quyết định nhưng không phải dân kỹ thuật. Chúng tôi muốn chỉ cho bạn biết nên đọc gì trong kiến trúc đề xuất và nên hỏi điều gì trước khi chuyển khoản. Không cần biết code, bạn vẫn có thể phân biệt được đâu là lời hứa, đâu là thiết kế.
Vì sao bản đề xuất đẹp chưa chắc là bản chạy được
Một bản trình bày khéo léo khiến người nghe dễ tin rằng mọi việc đã được giải quyết. Tuy nhiên, rủi ro của dự án AI thường nằm ở những chỗ không hiện trên slide. Khi đối tác nói họ dùng AI, bạn nên hiểu đó mới chỉ là một nhãn chung chung. Nó chưa phải cam kết cụ thể về cách hệ thống vận hành bên trong.
Điểm dễ bị bỏ qua nhất là dữ liệu và ranh giới của hệ thống. Một mô hình chỉ thông minh tới đâu khi dữ liệu học và quyền truy cập của nó cho phép. Nếu bản đề xuất không nói rõ dữ liệu lấy từ đâu, lưu ở đâu và kết nối với phần nào trong doanh nghiệp, thì các con số đẹp mắt gần như chỉ là minh họa.
Có bản đề xuất còn không phân định việc nào AI làm, việc nào vẫn cần người can thiệp. Những lời hứa về độ chính xác thường được đo trên bộ dữ liệu mẫu lý tưởng, chứ không phải trên dữ liệu thật đầy lỗi và thiếu sót của công ty bạn. Đó là lý do bạn nên đòi hỏi con số được đo trong điều kiện gần với thực tế nhất.
Vì vậy, trước khi ký, đội kỹ thuật hoặc một người hiểu công nghệ nên soi kỹ phần kiến trúc. Họ không cần chấm slide đẹp hay xấu. Chỉ cần trả lời một câu hỏi: hệ thống này có khả thi với dữ liệu, hạ tầng và ngân sách hiện có hay không. Bỏ qua bước này nghĩa là bạn đang đặt cược dựa trên cảm giác.
Bảy câu hỏi kỹ thuật nên hỏi trước khi chốt
Bạn không cần biết lập trình vẫn có thể hỏi đúng. Dưới đây là bảy câu hỏi mà chúng tôi khuyên bạn mang theo mỗi lần trao đổi với một công ty ứng dụng AI. Mục đích không phải làm khó đối tác, mà để xem họ có thật sự hiểu hệ thống mình đang bán hay không.
Câu đầu tiên là dữ liệu nằm ở đâu và ai được chạm vào. Dữ liệu sẽ được lưu trên hạ tầng nào, có gửi cho bên thứ ba xử lý không, và những ai có quyền truy cập? Đây là nền tảng của bảo mật, và đối tác nghiêm túc nào cũng trả lời được rõ ràng. Tiếp theo là rủi ro rò rỉ được kiểm soát ra sao. Một đối tác đáng tin sẽ nói cụ thể về phân quyền, mã hóa và quy trình xử lý khi có sự cố, thay vì trấn an chung chung rằng mọi thứ đều an toàn.
Câu thứ ba: khi AI trả lời sai thì có cơ chế dự phòng không? Mọi mô hình đều có lúc nhầm lẫn. Hãy hỏi khi kết quả bất thường, hệ thống có chuyển sang quy trình thủ công không, hay có lớp kiểm tra nào chặn lỗi trước khi đến tay người dùng. Câu thứ tư liên quan đến quản lý phiên bản mô hình. Bạn đang dùng phiên bản nào, ai cập nhật, và làm sao quay lại bản cũ nếu bản mới hoạt động kém đi? Thiếu thông tin này, việc tìm nguyên nhân khi chất lượng sụt giảm sẽ rất khó.
Câu thứ năm là kế hoạch khi nhà cung cấp nền tảng tăng giá hoặc ngừng dịch vụ. Nhiều giải pháp AI đang dựa trên dịch vụ của bên thứ ba. Nếu họ đổi giá hay đóng cửa, hệ thống của bạn có bị kẹt không, và chi phí chuyển sang giải pháp khác là bao nhiêu? Câu thứ sáu là khả năng mở rộng. Khi số người dùng hay khối lượng dữ liệu tăng nhiều lần, hệ thống còn chạy ổn không? Một kiến trúc tốt phải tính trước cho quy mô tương lai, không chỉ chạy đẹp ở bản demo nhỏ.
Câu cuối cùng là sau khi bàn giao, ai sẽ bảo trì và chi phí vận hành dài hạn là bao nhiêu. Phí phát triển ban đầu thường chỉ là phần nổi của tảng băng. Chi phí hạ tầng, cập nhật mô hình và nhân sự vận hành mới là phần âm thầm nhưng tốn kém hơn nhiều. Hãy yêu cầu đối tác liệt kê con số này bằng văn bản.
Nếu một câu trả lời khiến đối tác lúng túng hoặc né tránh, đó là tín hiệu để bạn tìm hiểu sâu hơn. Bạn có thể tham khảo thêm các tài liệu nền tảng về cách một hệ thống phần mềm được thiết kế, để hiểu rõ từng câu hỏi trên và tự tin trao đổi với đội kỹ thuật của đối tác. Nếu muốn xem kỹ hơn cách một hệ thống được xây dựng, bạn cũng có thể đọc checklist kỹ thuật khi hợp tác với một công ty ứng dụng AI cho dự án web của bạn, nơi liệt kê những hạng mục nên kiểm tra theo từng giai đoạn.
Cách nhận diện đối tác làm thật so với bán slide
Có bộ câu hỏi trong tay rồi, bước tiếp theo là phân biệt một đối tác thực sự làm sản phẩm với một đối tác chỉ giỏi trình bày. Sự khác biệt thường lộ ra khi bạn đưa ra những đề nghị có thể kiểm chứng.
Cách hiệu quả nhất là yêu cầu một bản thử nghiệm nhỏ, thường gọi là PoC, chạy trên chính dữ liệu thật của bạn thay vì xem một demo dựng sẵn. Demo luôn hoàn hảo vì đã được chọn lọc kỹ. Dữ liệu thật của doanh nghiệp thì lộn xộn và thiếu nhất quán, nhưng đó mới là môi trường hệ thống phải sống mỗi ngày. Đối tác làm thật sẵn sàng thử, kể cả khi kết quả ban đầu chưa đẹp, và họ giải thích được vì sao.
Một vài dấu hiệu giúp bạn nhận ra đối tác đáng tin. Họ sẵn sàng làm thử trên dữ liệu thật và thẳng thắn về giới hạn của giải pháp. Họ phân định rõ phần nào máy làm tốt, phần nào vẫn cần người kiểm tra lại. Họ có quy trình bàn giao tài liệu, mã nguồn và hướng dẫn vận hành rõ ràng. Quan trọng nhất, họ nói được về rủi ro và phương án dự phòng, chứ không chỉ kể về lợi ích.
Ngược lại, hãy cẩn trọng nếu đối tác chỉ chăm chăm vào hiệu ứng hình ảnh, liên tục dùng thuật ngữ thời thượng nhưng không trả lời được câu hỏi cụ thể, hoặc lảng tránh khi bạn đề nghị thử trên dữ liệu thật. Cũng nên tránh các sai lầm quen thuộc như chỉ nhìn vào giá rẻ, bỏ qua phần bảo trì, hay tin vào lời hứa độ chính xác tuyệt đối. Những sai lầm này dễ khiến doanh nghiệp mất tiền mà không nhận lại giá trị tương xứng.
Hỏi kỹ phần kỹ thuật là cách rẻ nhất để tiết kiệm
Đầu tư vào AI có thể mang lại lợi ích thật, nhưng giá trị đó chỉ đến khi bạn chọn đúng đối tác và hiểu rõ mình đang mua gì. Hỏi kỹ phần kỹ thuật không làm chậm dự án. Ngược lại, đó là cách rẻ nhất để tránh chi phí sửa sai về sau. Vài giờ đặt câu hỏi cẩn thận có thể giúp bạn tiết kiệm đáng kể khi hệ thống đi vào vận hành.
Hãy nhìn vào sự khác biệt giữa hai loại đề xuất. Đề xuất chỉ đẹp trên slide thường nói chung chung về dữ liệu, không rõ nguồn gốc. Đề xuất khả thi sẽ chỉ rõ nguồn dữ liệu, nơi lưu trữ và quyền truy cập. Về ranh giới, đề xuất yếu hứa AI làm tất cả, còn đề xuất tốt phân định rõ phần máy và phần người. Về kiểm chứng, bên yếu chỉ có demo dựng sẵn, còn bên mạnh sẵn sàng thử trên dữ liệu của bạn.
Về vận hành dài hạn, bên mạnh minh bạch về phương án dự phòng, quản lý phiên bản và tổng chi phí trong suốt vòng đời, còn bên yếu thường không nhắc tới. Đây là điểm đáng để bạn đặt thêm câu hỏi trước khi ký.
Tóm lại, hãy mang bảy câu hỏi này vào mọi buổi trao đổi: dữ liệu ở đâu, ai được chạm vào, kiểm soát rò rỉ thế nào, cơ chế dự phòng ra sao, quản lý phiên bản mô hình thế nào, kế hoạch khi nhà cung cấp đổi giá là gì, khả năng mở rộng và chi phí vận hành dài hạn. Trên hết, ưu tiên sự minh bạch về kiến trúc hơn những lời hứa hoa mỹ. Một đối tác dám nói thật về giới hạn của mình thường đáng tin hơn nhiều so với đối tác hứa mọi thứ đều hoàn hảo. Nếu còn băn khoăn, đừng ngại hỏi ý kiến một người có kinh nghiệm kỹ thuật trước khi ký hợp đồng.
