29/09/2026 · VietTechies · Biên tập
Hệ thống AI trong production vẫn có thể gặp sự cố dù mô hình và container ứng dụng không thay đổi. Một cấu hình truy xuất cung cấp nhiều ngữ cảnh hơn có thể kéo dài thời gian sinh nội dung, làm quá tải năng lực suy luận và khiến yêu cầu xếp hàng. Khi đó, chỉ rollback container sẽ không giải quyết được vấn đề.
Xác định đầy đủ phạm vi bản phát hành
Đơn vị triển khai thực tế phải là tổ hợp đã được kiểm thử, gồm mã ứng dụng, phiên bản mô hình, prompt, chỉ mục truy xuất và embedding, hợp đồng công cụ, cấu hình phục vụ cùng dữ liệu đánh giá. Một release manifest có quản lý phiên bản có thể liên kết các thành phần này và chỉ rõ bản phát hành tương thích trước đó.
Manifest nên tham chiếu đến các cấu hình và artifact được lưu giữ, bao gồm những thiết lập thực thi như giới hạn token, batching, timeout và vị trí tài nguyên. Nếu dữ liệu thay đổi liên tục, manifest cần ghi lại mốc ingestion và cấu hình chỉ mục. Với thông tin bí mật, chỉ lưu tham chiếu thay vì giá trị thực.
Cách làm này không bảo đảm khả năng tái tạo giống hệt từng bit. Dịch vụ bên ngoài có thể thay đổi, quá trình sinh nội dung vẫn có tính bất định và một số nhà cung cấp không hỗ trợ snapshot mô hình bất biến. Các giới hạn đó cần được ghi nhận rõ, thay vì mô tả một alias luôn biến động như một phiên bản cố định.
Kiểm thử nhiệm vụ của người dùng
Một endpoint trả về HTTP 200 chưa chứng minh tính năng AI hoạt động đúng. Chẳng hạn, bộ đánh giá dành cho trợ lý tài liệu có thể cần kiểm tra trích dẫn nguồn, độ chính xác về phiên bản sản phẩm và khả năng từ chối bịa ra hướng dẫn khi không có đủ bằng chứng.
Bộ kiểm thử nên bao quát tác vụ thông thường, lỗi đã biết, yêu cầu mơ hồ, trường hợp thiếu bằng chứng và các nỗ lực vượt ranh giới phân quyền. Một tập dữ liệu tách riêng giúp giảm nguy cơ overfitting khi chỉnh sửa prompt. Các phép kiểm tra xác định có thể xác thực schema, đối số công cụ, mã trích dẫn và quyền truy cập; còn đánh giá ngữ nghĩa cần rubric rõ ràng cùng quá trình rà soát của con người. Mô hình chấm điểm có thể hỗ trợ ưu tiên rà soát, nhưng không phải là ground truth.
Quy trình đánh giá phải kiểm thử đồng thời truy xuất, sinh nội dung và xác thực đầu ra. Tiêu chí chấp nhận cần bao gồm chất lượng, vi phạm kiểm soát truy cập, độ trễ và chi phí dưới tải đại diện. Khi một cổng đánh giá thất bại, hệ thống phải giữ lại mã bản phát hành, các trường hợp lỗi và trace liên quan để phục vụ điều tra.
Đo lường và rollback toàn bộ hệ thống
Kiểm thử tải nên thay đổi độ dài đầu vào và đầu ra, mức đồng thời, các đợt yêu cầu tăng đột biến cùng trạng thái cache. Thời gian đến token đầu tiên, tốc độ sinh token, tổng thời gian hoàn tất và thời gian chờ trong hàng đợi phản ánh những khía cạnh trải nghiệm khác nhau. Trace đầu cuối giúp phân biệt độ trễ đến từ truy xuất, lập lịch, suy luận hay dịch vụ phía sau.
Triển khai canary tạo ra phép so sánh có kiểm soát, nhưng không có tỷ lệ lưu lượng nào an toàn trong mọi trường hợp. Trước khi mở rộng triển khai, nhóm vận hành cần xác định người chịu trách nhiệm, điều kiện dừng và yêu cầu quan sát tối thiểu. Họ cũng phải đối chiếu các mục tiêu dịch vụ tuyệt đối, vì một dependency dùng chung có thể làm suy giảm cả bản ứng viên lẫn bản đối chứng.
Rollback phải khôi phục cả những dependency tương thích, gồm chỉ mục truy xuất và cache, chứ không chỉ đưa trọng số mô hình về phiên bản cũ. Các lượt sinh nội dung đang xử lý và tác dụng phụ từ công cụ cần chính sách riêng về drain, hủy tác vụ và idempotency. Sau mỗi sự cố, trường hợp thất bại nên được bổ sung vào bộ đánh giá để kinh nghiệm vận hành trực tiếp cải thiện các bản phát hành tiếp theo.
Ảnh minh họa do AI tạo, không phải ảnh tư liệu.