Khi AI bảo xong việc nhưng cơ sở dữ liệu nói không

Một món đồ gia dụng trị giá 745 USD bị kẹt ở trung tâm phân phối suốt 15 ngày vì sự cố giao hàng. Khách hàng gửi thư khiếu nại. Hệ thống AI tiếp nhận, đọc dữ liệu, kích hoạt công cụ xử lý rồi phản hồi bằng một bức thư lịch thiệp, cam kết đơn hàng đã được cập nhật lộ trình mới. Nhưng khi kỹ sư kiểm tra lại bảng dữ liệu trong cơ sở dữ liệu máy chủ, mã vận đơn vẫn nằm chết dí ở trạng thái lỗi cũ.

Tình huống này vừa được Microsoft và Hugging Face đưa ra khi công bố bộ công cụ kiểm thử ThinkingBox. Nó phản ánh một sự thật trớ trêu mà nhiều đội ngũ kỹ thuật đang gặp phải: mô hình ngôn ngữ có thể viết ra một câu trả lời hoàn hảo, nhưng trạng thái hệ thống bên dưới lại chẳng hề nhúc nhích.

Đánh giá bằng vết ghi dữ liệu thay vì câu chữ

Trong suốt hai năm qua, phần lớn các phép đo AI vẫn xoay quanh chất lượng văn bản đầu ra. Người ta chấm điểm xem câu trả lời có trôi chảy, đúng ngữ pháp hay giải thích logic hợp lý hay không. Nhưng khi bước sang mô hình agent - tức AI được trao quyền gọi API và can thiệp vào quy trình thực tế - thước đo đó đã lỗi thời.

Một lượt gọi công cụ thành công không đồng nghĩa với một kết quả nghiệp vụ thành công. Agent có thể nhận được mã phản hồi HTTP 200 từ một API bên thứ ba, nhưng dữ liệu thực tế lưu vào PostgreSQL hay MongoDB lại thiếu một trường khóa ngoại, hoặc giao dịch bị hủy giữa chừng do vi phạm ràng buộc dữ liệu.

ThinkingBox giải quyết chuyện này bằng cách chấm điểm agent dựa trên trạng thái cuối cùng của hệ thống lưu trữ và các tác động phụ ngoài ý muốn mà nó để lại, thay vì chấm điểm câu chữ. Quy trình kiểm thử dựng một phiên làm việc độc lập qua giao thức MCP (Model Context Protocol) và OpenEnv, buộc agent phải thao tác với các dịch vụ tìm kiếm như Typesense hay cơ sở dữ liệu thực. Điểm mấu chốt nằm ở chỗ: công cụ không chỉ hỏi AI có làm được hay không, mà hỏi nó có làm đúng liên tiếp hai mươi lần hay không.

Sự khác biệt giữa việc làm đúng một lần và làm đúng hai mươi lần liên tiếp chính là khoảng cách giữa một bản demo hào nhoáng và một hệ thống chạy production. Khi yêu cầu độ ổn định tăng lên, chi phí suy luận cũng tăng theo đường cong phi tuyến tính. Nếu một agent chỉ đạt độ tin cậy 80% cho từng bước, thì sau một chuỗi năm thao tác liên hoàn, xác suất để toàn bộ quy trình chạy trơn tru chỉ còn khoảng một phần ba.

Ranh giới giữa mở toang nền tảng và khép kín hạ tầng

Trong khi giới nghiên cứu đau đầu với bài toán nhất quán dữ liệu, các ông lớn công nghệ lại chọn những ngã rẽ rất khác nhau để đưa agent đến tay người dùng.

Tại sự kiện DevDay gần đây, OpenAI định vị ChatGPT như một lớp thực thi phần mềm mới, cạnh tranh trực diện với mô hình kho ứng dụng truyền thống của Apple và Google. Với 1,2 tỷ người dùng hằng tuần, ChatGPT không còn là nơi chỉ để gõ vài câu lệnh hỏi đáp. Hệ thống agent mang tên Dots được thiết kế để điều phối tác vụ qua hơn 4.000 dịch vụ kết nối. Người dùng có thể mở các bảng điều khiển tương tác ngay bên cạnh khung chat để dùng Figma hoặc Adobe mà không cần tải ứng dụng riêng lẻ về máy. Khi nhận diện nhu cầu, hệ thống sẽ tự đề xuất công cụ phù hợp ngay giữa cuộc trò chuyện.

Ở thái cực hoàn toàn đối lập, IBM lại đưa nền tảng phát triển phần mềm tự động Bob vào các môi trường tự lưu trữ (self-hosted) và ngắt kết nối Internet hoàn toàn (air-gapped). Với Bob, toàn bộ chu trình từ đọc hiểu mã nguồn, lập kế hoạch thay đổi, thực thi qua BobShell đến kiểm thử đều diễn ra bên trong mạng nội bộ của doanh nghiệp.

Đây là hai triết lý vận hành trái ngược nhau:

• Mô hình phân tán qua đám mây: Người dùng ủy quyền toàn bộ dữ liệu ngữ cảnh cho nền tảng của nhà cung cấp, đổi lại sự tiện lợi và khả năng kết nối hàng nghìn dịch vụ tức thì.
• Mô hình cô lập tại chỗ: Doanh nghiệp tự mua bản quyền mô hình, tự dựng máy chủ suy luận, chấp nhận chi phí vận hành cao để giữ toàn bộ mã nguồn và dữ liệu nghiệp vụ không lọt ra ngoài một byte nào.

Đối với các hệ thống tài chính, viễn thông hay y tế, lựa chọn thứ hai gần như là con đường khả dĩ duy nhất. Bạn không thể để một con bot tự do gọi webhook ra ngoài Internet khi đang thao tác trên cơ sở dữ liệu khách hàng cốt lõi.

Bài toán hạn ngạch và sự cần thiết của trần ngân sách cứng

Càng đẩy mạnh việc tự động hóa, chi phí tài nguyên tính toán càng trở thành gánh nặng nhãn tiền. Điều này thể hiện rất rõ qua động thái mới đây của Google đối với ứng dụng Gemini.

Google bắt đầu siết chặt các tầng mô hình dựa trên mức tiêu thụ tính toán. Người dùng miễn phí bị đẩy hẳn về phiên bản Flash-Lite, không còn được chạm tay vào Flash hay Pro. Người dùng gói trả phí AI Plus giá 4,99 USD mỗi tháng cũng bị cắt quyền dùng bản Pro, chỉ còn lại Flash và Flash-Lite. Bản Pro giờ chỉ dành cho các gói đắt tiền hơn như AI Pro hay AI Ultra để bù đắp chi phí vận hành cho các tính năng suy luận sâu như Deep Think.

Khi các nhà cung cấp bắt đầu tính toán chi li từng chu kỳ GPU, các kỹ sư trực tiếp xây dựng hệ thống agent phải đối mặt với một rủi ro khác: vòng lặp tài nguyên vô tận. Chuyên gia Simon Willison gần đây đã đưa ra một cảnh báo rất thực tế: chúng ta sắp phải áp dụng trần ngân sách cứng (hard budget cap) mặc định cho hầu như mọi thứ.

Một con bot được cấp quyền tự sửa lỗi mã nguồn có thể chạy lặp đi lặp lại hàng chục lần một bài test thất bại, đốt sạch hàng trăm USD tiền API chỉ trong một đêm. Tệ hơn, nếu logic gọi công cụ gặp lỗi vòng lặp hoặc bị tấn công gián tiếp qua dữ liệu đầu vào không sạch, agent có thể vô tình tạo ra các cuộc tấn công từ chối dịch vụ (DDoS) vào chính hệ thống nội bộ thông qua hàng loạt yêu cầu ghi dữ liệu dồn dập.

Kỹ sư vận hành cần chuẩn bị gì?

Cơn sốt xây dựng agent bằng mọi giá đang dần nhường chỗ cho bài toán kỹ thuật thực chất: làm sao để hệ thống chạy ổn định, an toàn và không làm thủng ngân sách. Nếu đang chuẩn bị triển khai agent vào quy trình nội bộ, có vài điểm mấu chốt bạn nên cân nhắc ngay từ khâu thiết kế:

Thứ nhất, hãy ngừng đánh giá agent bằng mắt thường. Đừng nhìn vào câu trả lời trơn tru trên giao diện chat rồi kết luận rằng quy trình đã hoàn tất. Cần xây dựng các bộ kiểm thử tự động đo đạc trực tiếp trạng thái của cơ sở dữ liệu sau khi agent kết thúc lượt chạy. Kiểm tra xem bản ghi có bị trùng lặp không, các trường dữ liệu quan trọng có bị ghi đè sai lệch không, và liệu agent có dọn dẹp các tác động phụ khi gặp lỗi giữa chừng hay không.

Thứ hai, thiết kế các API dành cho agent theo hướng mang tính khả quy (idempotent). Vì mô hình ngôn ngữ vốn dĩ không có tính tiền định tuyệt đối, việc nó gọi lại một API hai lần cho cùng một tác vụ là điều rất dễ xảy ra. Nếu endpoint không xử lý tốt tính khả quy, hệ thống của bạn sẽ nhanh chóng ngập trong các giao dịch rác hoặc đơn hàng bị tạo trùng.

Thứ ba, luôn cài đặt trần chặn cứng về số bước thực thi và chi phí gọi mô hình. Bất kỳ phiên làm việc nào của agent vượt quá số bước suy luận tối đa hoặc chạm ngưỡng chi phí cho phép đều phải bị ngắt kết nối ngay lập tức, sau đó chuyển trạng thái về cho con người can thiệp thủ công.

Kỷ nguyên xem AI như một món đồ chơi biết làm thơ hay tóm tắt văn bản đã qua. Khi giao quyền can thiệp dữ liệu cho các mô hình tự hành, trách nhiệm kiểm soát thuộc về các kỹ sư hạ tầng. Mô hình có thể hứa hẹn rất nhiều điều trong câu chữ, nhưng chỉ có dữ liệu thực tế nằm lại trên đĩa cứng mới là thứ quyết định hệ thống của bạn đang vận hành trơn tru hay đang âm thầm sụp đổ.