Quản lý prompt, mô hình và logic quy trình như một bản phát hành AI

Bản phát hành AI phải bao gồm toàn bộ cấu hình có thể đổi hành vi phục vụ, không chỉ prompt hay endpoint mô hình. Hạ phiên bản mô hình nhưng giữ prompt, schema công cụ, quyền hoặc nhánh retry mới không khôi phục trạng thái đã biết là tốt. Một mã chung cho biết cấu hình nào được đánh giá, cấu hình nào xử lý yêu cầu có vấn đề và gói tương thích nào có thể nhận lại traffic.

Những gì phải được tính là một bản phát hành AI?

Bản phát hành phải bao trùm mọi phụ thuộc có thể đổi hành vi, quyền hạn, rủi ro, chi phí, độ trễ hoặc khả năng quan sát. NIST nhấn mạnh quan hệ phụ thuộc trong vòng đời AI và việc kiểm kê cả thành phần bên thứ ba; Google Cloud cũng mô tả hệ thống ML sản xuất rộng hơn mã mô hình. Ranh giới cụ thể tùy hệ thống, nhưng không được bỏ sót thành phần có thể đổi kết quả phục vụ.

• Prompt hệ thống, mẫu prompt, biến chèn và quy tắc dựng ngữ cảnh.
• Định danh mô hình đã phân giải, snapshot nhà cung cấp và toàn bộ tham số suy luận có hiệu lực.
• Schema công cụ, quyền gọi, bước phê duyệt, chính sách, guardrail và hành động bị cấm.
• Cấu hình truy xuất, nguồn dữ liệu hoặc ngữ cảnh, logic định tuyến, mã workflow và nhánh xử lý ngoại lệ.
• Schema đầu vào, đầu ra, phụ thuộc runtime, feature flag và binding môi trường ảnh hưởng đến từng yêu cầu.

Tập dữ liệu đánh giá, bộ chấm, rubric và ngưỡng không thường nằm trên đường phục vụ nhưng vẫn quyết định ứng viên có được đi tiếp. Hãy phiên bản hóa và liên kết chúng như tài sản bảo đảm, tách khỏi manifest runtime. Mọi thay đổi ảnh hưởng hành vi ở prompt, snapshot, tham số, policy, công cụ, workflow, schema, truy xuất, phụ thuộc hoặc binding đều phải tạo ứng viên mới.

Làm thế nào khóa toàn bộ ngăn xếp hành vi vào manifest?

Manifest ứng viên phải bất biến và lưu định danh ổn định cùng thiết lập có hiệu lực. Các trường tối thiểu gồm mã phát hành, thời điểm tạo, chủ sở hữu, dịch vụ đích, trạng thái, điều kiện dừng, người phụ trách khôi phục và bản tốt trước đó. Mỗi thành phần dùng phiên bản đã phân giải, commit, digest, content hash hoặc tham chiếu ổn định tương đương. “Production” và “latest” chỉ là con trỏ, không phải bằng chứng về đích đã kiểm thử.

Manifest cũng ghi feature flag, định tuyến, kết nối được duyệt, tham chiếu dữ liệu hoặc truy xuất và binding môi trường ảnh hưởng cách xử lý, nhưng không chứa bí mật. MLflow cho thấy phiên bản prompt có thể bất biến trong khi bí danh hoặc cấu hình liên quan vẫn đổi; OpenAI lưu ý hành vi prompt có thể khác giữa các snapshot. Vì vậy, hồ sơ phải giữ đích đã phân giải và cấu hình hiệu lực, không chỉ mã prompt hay tên họ mô hình.

• Ứng viên support-assistant-r18 khóa prompt p-42, snapshot m-2026-07, tham số suy luận và giới hạn đầu ra hiệu lực.
• Cùng manifest khóa schema công cụ CRM t-9, chính sách quyền policy-12, commit workflow wf-a71, schema đầu ra reply-6 và tệp khóa phụ thuộc runtime.
• Gói bằng chứng liên kết riêng với bộ đánh giá eval-23, phiên bản bộ chấm, kết quả so sánh với r17 và quyết định của người duyệt.
• support-assistant-r17 chỉ được chỉ định làm đích khôi phục sau khi xác nhận tương thích với trường due-date và escalationReason mới.

Tỷ lệ lưu lượng, quy tắc cohort, thời điểm và kết quả quan sát thuộc bản ghi thăng cấp liên kết, không sửa manifest. Tăng exposure đã duyệt trước có thể dùng cùng ứng viên; thay đổi routing làm đổi ngữ cảnh, quyền hoặc hành vi từng yêu cầu phải nhận mã mới. Nhờ đó, ứng viên vẫn bất biến trong khi lịch sử vận hành được ghi riêng.

Bất kỳ thứ gì có thể đổi hành vi phục vụ — hoặc đổi bằng chứng dùng để cho phép hành vi đó — đều cần một danh tính đã phân giải trong hồ sơ phát hành.

Bằng chứng nào quyết định ứng viên có được đi tiếp?

Ứng viên chỉ đi tiếp khi chính cấu hình đầy đủ vượt qua các cổng phù hợp và có quyết định do một chủ sở hữu chịu trách nhiệm. Ghi chú phát hành cần nêu mục tiêu hành vi, phụ thuộc thay đổi, tình huống và giao diện bị ảnh hưởng, bằng chứng, giới hạn, rủi ro còn lại, kế hoạch thăng cấp và đích khôi phục. Theo định hướng đánh giá có tài liệu của NIST, hồ sơ phải kết thúc bằng “thăng cấp”, “giữ lại” hoặc “loại bỏ”, không chỉ một bảng điểm.

Các cổng cần kiểm tra build và hợp đồng, chất lượng tác vụ, an toàn, quyền hạn, hành vi công cụ, độ tin cậy, độ trễ, chi phí và phân khúc quan trọng so với bản hiện tại. Đánh giá tổng quát không thay thế tình huống thật, ca hiếm nhưng tốn kém hoặc kiểm tra bộ chấm tự động. Điểm trung bình không được che lỗi nghiêm trọng về schema, quyền, an toàn hay phân khúc. Dataset, rubric, bộ chấm và ngưỡng phải có phiên bản vì thay đổi cổng có thể đổi cách diễn giải kết quả.

Bản phát hành rủi ro cao có thể tách người tạo thay đổi khỏi người thăng cấp và dùng cơ chế bảo vệ để bắt buộc phê duyệt. Nhóm nhỏ có thể kiêm nhiệm nhưng vẫn phải ghi người quyết định, bằng chứng và ngoại lệ. Ngưỡng đạt phải theo mục tiêu cùng mức phơi nhiễm của dịch vụ, không sao chép từ hệ thống khác.

Cùng một ứng viên nên đi vào production theo các nấc nào?

Cùng một ứng viên đã phân giải phải đi qua mọi nấc mà không bị sửa. Khi khả thi, bắt đầu bằng shadow hoặc phát lại không kích hoạt hành động, với công cụ ghi và tác dụng hệ quả khác bị tắt hoặc sandbox. Sau đó mở cho nhóm nội bộ, cohort production ổn định, exposure rộng hơn rồi toàn bộ traffic. Mỗi nấc so sánh tín hiệu tác vụ, an toàn, công cụ, độ tin cậy, độ trễ và chi phí với bản hiện tại.

1. Phát lại các yêu cầu đại diện với mọi công cụ ghi bị vô hiệu hóa, rồi so sánh trace đầy đủ với bản hiện tại.
2. Mở cho nhóm vận hành nội bộ trong khi vẫn giữ bước duyệt đối với mọi hành động ra hệ thống ngoài.
3. Đưa ứng viên vào một cohort production có gán ổn định để tránh người dùng nhảy qua lại giữa hai cấu hình.
4. Mở rộng sau khi đủ bằng chứng theo kế hoạch đã duyệt; ghi allocation, thời gian quan sát và quyết định dưới dạng sự kiện triển khai.
5. Chuyển sang toàn bộ traffic, tiếp tục giám sát theo mã phát hành và giữ đích khôi phục trong thời hạn do dịch vụ xác định.

Tỷ lệ traffic, lượng mẫu và cửa sổ quan sát phải theo rủi ro, lưu lượng, độ trễ phát hiện và năng lực vận hành; không có con số chung. Shadow không phản ánh đầy đủ tác động khi công cụ được kích hoạt, còn canary có thể bỏ sót hành vi hiếm hoặc nhóm traffic chưa xuất hiện. Canary vì thế chỉ là bằng chứng trực tuyến có giới hạn. Nếu prompt, mô hình, quyền, policy, retrieval, workflow, schema hoặc binding đổi, phải tạo ứng viên mới.

Khi nào phải dừng, và khôi phục cần đưa những gì trở lại?

Bản phát hành phải dừng khi có vi phạm an toàn hoặc policy, hành vi công cụ trái phép, lỗi hợp đồng hay sự cố độ tin cậy nghiêm trọng đã xác định trước. Suy giảm khác dùng giới hạn riêng của dịch vụ; phát hiện mơ hồ có thể dẫn tới tạm dừng để điều tra. Mọi sự kiện cần trạng thái, thời điểm, bằng chứng và người chịu trách nhiệm. Điều kiện dừng phải được thống nhất trước exposure.

Khi khôi phục, đưa traffic về toàn bộ bản phát hành đã biết là tốt và còn tương thích, không chỉ hạ phiên bản mô hình. Trước đó, kiểm tra schema, trạng thái, migration, khả năng cung cấp, hợp đồng công cụ, routing và binding môi trường. Google Cloud khuyến nghị lưu con trỏ và diễn tập khôi phục phiên bản trước. Diễn tập phải xác nhận việc chuyển traffic cùng các kiểm tra sau chuyển, để r17 là đích đã thử chứ không chỉ là một dòng trong hồ sơ.

Khôi phục cấu hình chỉ kiểm soát yêu cầu tương lai; nó không xóa thư, đảo ngược dữ liệu, hủy phê duyệt hay gỡ tác vụ CRM đã tạo. Trace gắn mã phát hành và mã hành động giúp khoanh vùng ảnh hưởng, còn cô lập, đối soát, sửa chữa, thông báo hoặc bù trừ phải theo runbook riêng và đúng thẩm quyền. Với support-assistant-r18, đội có thể tắt đường tạo tác vụ, tìm ID từ trace và dùng quy trình sửa CRM; chuyển về r17 không xóa tác vụ cũ.

Hồ sơ nào giúp dựng lại một bản phát hành AI về sau?

Hồ sơ bền vững phải dựng lại được cấu hình hiệu lực, bằng chứng và căn cứ quyết định. Tối thiểu, hãy giữ manifest bất biến; định danh và tham số đã phân giải; binding môi trường; kết quả tương thích; phiên bản cùng kết quả đánh giá; phê duyệt; sự kiện triển khai; phân bổ traffic; trace; phát hiện; khôi phục và trạng thái cuối. Google Cloud cũng khuyến nghị ghi phiên bản, thời điểm, tác nhân thực thi, tham số, hiện vật, kết quả đánh giá và con trỏ tới phiên bản trước.

Gắn mã phát hành vào trace để quy lượt sinh, lệnh gọi công cụ, bàn giao, guardrail, thời gian và kết quả về đúng cấu hình. Khi có, lưu mã yêu cầu của nhà cung cấp và mã trace ứng dụng để điều tra qua ranh giới hệ thống. Trace không cần chứa mọi prompt, đầu vào công cụ, đầu ra mô hình hay payload khách hàng; dữ liệu nhạy cảm, quyền truy cập và thời hạn lưu giữ phải theo chính sách tổ chức.

Mục tiêu là tái dựng cấu hình và quyết định, không phải tạo lại đầu ra giống từng byte. Snapshot ghim, tham số lưu và request ID chỉ giúp thu hẹp bất định; mô hình ngẫu nhiên hoặc dịch vụ lưu trữ vẫn có thể phản hồi khác. Gói phát hành nhỏ nhất vẫn phải nhận diện ứng viên, bằng chứng, quyết định thăng cấp và đích khôi phục. Thay đổi liên quan dữ liệu nhạy cảm, quyền hệ quả, quy trình được quản lý hoặc nghĩa vụ lưu giữ cần chuyên gia phù hợp.