Mỗi lần có khách hỏi về tích hợp AI vào phần mềm, chúng tôi thấy câu hỏi đầu tiên gần như lúc nào cũng giống nhau. Nên gắn AI vào hệ thống đang chạy, hay dựng lại từ đầu theo một kiến trúc lấy AI làm trung tâm? Câu hỏi nghe qua có vẻ đơn giản. Nhưng phía sau nó là hàng loạt quyết định vừa mang tính kỹ thuật vừa mang tính kinh doanh. Trong bài này, đội ngũ của chúng tôi chia sẻ cách nhìn nhận vấn đề, kèm vài tình huống thực tế để bạn dễ hình dung hơn.

Khi nào nâng cấp phần mềm hiện có là lựa chọn hợp lý?

Theo kinh nghiệm của chúng tôi, nâng cấp thường là phương án an toàn hơn. Nếu hệ thống hiện tại vẫn vận hành ổn định và có bộ kiểm thử đủ tốt để bạn tự tin thay đổi, thì thêm một tính năng AI dưới dạng module độc lập thường mang lại giá trị nhanh hơn nhiều. Bạn không cần chạm vào toàn bộ codebase. Vận hành không bị gián đoạn. Và cũng không phải thuyết phục cả công ty chấp nhận rủi ro của một dự án làm lại từ đầu.

Chúng tôi từng làm việc với một công ty phần mềm quản lý kho đã chạy hơn tám năm. Họ muốn bổ sung tính năng gợi ý nhập hàng dựa trên lịch sử bán. Thay vì viết lại, đội ngũ tách phần dự đoán thành một service riêng. Service này nhận dữ liệu qua API nội bộ và trả kết quả gợi ý về để giao diện cũ hiển thị. Chỉ mất vài tuần, và phần lõi cũ gần như không bị ảnh hưởng. Đó là kiểu thắng lợi bạn có thể đạt được khi thiết kế ranh giới rõ ràng ngay từ đầu.

Dấu hiệu để nhận ra bạn nên đi theo hướng này khá rõ. Chi phí di chuyển sang hệ thống mới cao hơn nhiều so với giá trị AI mang lại. Và tính năng bạn cần có thể tách khỏi phần còn lại mà không gây xáo trộn lớn. Nếu cả hai điều kiện đó đúng, nâng cấp gần như luôn là lựa chọn khôn ngoan. Điều này cũng đúng với những sản phẩm vừa có thiết kế giao diện tốt vừa cần giữ trải nghiệm người dùng ổn định, vì bạn không phải làm lại toàn bộ luồng thao tác mà người dùng đã quen.

Khi nào nên viết lại theo kiến trúc AI-first?

Viết lại không phải cách để làm sản phẩm trông hiện đại hơn. Nó chỉ thật sự đáng giá khi có lý do cụ thể. Lý do đầu tiên là nợ kỹ thuật đã nặng đến mức mỗi lần gắn thêm AI lại kéo theo một loạt giải pháp tạm. Chính những giải pháp tạm ấy lại sinh ra nợ mới. Khi đó, vá thêm chỉ làm hệ thống khó đoán hơn.

Lý do thứ hai là khi AI không còn là tiện ích phụ mà đã trở thành lõi của mô hình kinh doanh. Nếu sản phẩm tạo ra giá trị chủ yếu nhờ năng lực AI, kiến trúc cần được thiết kế quanh luồng dữ liệu, mô hình và vòng phản hồi ngay từ ngày đầu. Gắn AI lên một nền tảng sinh ra cho nghiệp vụ khác thường chỉ cho ra kết quả chắp vá.

Lý do thứ ba, và thường bị bỏ qua nhất, là mô hình dữ liệu hiện tại không phù hợp với cách AI cần truy cập thông tin. Schema được thiết kế cho nghiệp vụ cũ hay thiếu những trường, quan hệ hoặc lịch sử thay đổi mà mô hình học máy cần. Lúc này, sửa từng bảng một có thể khó hơn xây lại. Dù vậy, bạn vẫn phải cân nhắc kỹ, vì chi phí di chuyển dữ liệu không hề nhỏ.

• Codebase có nợ kỹ thuật nghiêm trọng, thêm AI nào cũng phải vá víu.
• AI là năng lực cốt lõi của sản phẩm, không chỉ là tính năng bổ sung.
• Mô hình dữ liệu cần thiết kế lại để AI truy cập đúng cách.

Cách so sánh hai phương án bằng con số thực tế

Đừng đưa ra quyết định chỉ dựa trên cảm giác. Đội ngũ chúng tôi thường bắt đầu bằng việc ước tính tổng chi phí của cả hai hướng. Với nâng cấp, bạn cần tính thời gian kỹ sư, chi phí xử lý nợ kỹ thuật đang có và phần phát sinh khi bảo trì module AI mới. Với viết lại, con số lớn hơn nhiều: thời gian phát triển, rủi ro di chuyển dữ liệu, thời gian gián đoạn và chi phí đào tạo người dùng quen với giao diện mới.

Sau đó, hãy ước tính chi phí bảo trì dài hạn cho từng phương án trong khoảng ba đến năm năm. Một hệ thống viết lại có thể đắt hơn lúc đầu nhưng rẻ hơn về sau, hoặc ngược lại. Không có công thức chung cho mọi trường hợp, chỉ có phép tính riêng cho từng sản phẩm và từng đội. Nếu muốn hình dung rõ hơn những bài toán nên ưu tiên trước, bạn có thể tham khảo thêm nội dung về tự động hóa doanh nghiệp bằng AI, nơi các bài toán vận hành được phân tích theo hướng thực tế.

Yếu tố thời điểm cũng quan trọng không kém. Đôi khi đối thủ đã ra mắt tính năng AI và bạn không thể chờ một dự án viết lại kéo dài hai năm. Khi ấy, một bản tích hợp nhanh, dù chưa hoàn hảo về kỹ thuật, lại có giá trị hơn một kiến trúc đẹp nhưng đến muộn. Tất nhiên, bạn cần lên kế hoạch để sau đó vẫn có thể tái cấu trúc khi điều kiện cho phép.

Công cụ và thói quen giúp quyết định nhanh hơn

Khi làm việc với đội kỹ thuật, chúng tôi hay dùng một bảng tính đơn giản để chấm điểm từng phương án theo vài tiêu chí: chi phí, rủi ro, tốc độ ra mắt, khả năng mở rộng và mức phụ thuộc vào nhà cung cấp mô hình. Bảng này không thay thế được đánh giá chuyên sâu. Nhưng nó giúp cả nhóm nhìn cùng một bức tranh thay vì tranh luận theo cảm tính từng người. Các bộ công cụ số hỗ trợ cả đội kỹ thuật lẫn thiết kế cũng đáng khảo sát. Bạn có thể bắt đầu từ danh sách trên winner-design.com.

Một thói quen khác đáng giá hơn bạn nghĩ là chạy thử một bản mẫu nhỏ trước khi cam kết. Chỉ trong vài ngày, bạn có thể kiểm chứng AI có thực sự cải thiện trải nghiệm người dùng hay không. Bạn cũng biết được dữ liệu hiện có có đủ chất lượng hay không. Nhiều dự án đã dừng đúng ở bước này và tiết kiệm được hàng tháng công sức, thay vì phát hiện vấn đề khi đã đi được nửa đường.

Kết luận: bối cảnh của sản phẩm mới là thứ quyết định

Không có đáp án đúng cho mọi trường hợp. Nâng cấp hay viết lại đều có thể là lựa chọn tốt, tùy vào tình trạng codebase, yêu cầu kinh doanh và những ràng buộc thực tế của đội ngũ. Điều quan trọng là đừng áp dụng các thực hành chung chung một cách máy móc. Hãy đọc kỹ hệ thống của chính mình trước khi quyết định.

Đội nào làm tốt bước phân tích này thường tránh được cả hai cực đoan. Một là đập đi làm lại một hệ thống vẫn còn giá trị. Hai là vá víu mãi một nền tảng đã chạm đến giới hạn. Hãy bắt đầu bằng việc nhìn thẳng vào hiện trạng, rồi chọn con đường phù hợp nhất với sản phẩm của bạn.