Bản demo vừa chạy xong. Một prompt được nhập vào, câu trả lời hiện ra trôi chảy, và cả phòng đã có thể hình dung ra một sản phẩm hoàn chỉnh. Rồi những câu hỏi kém hào nhoáng hơn xuất hiện: đầu vào mơ hồ thì sao, nguồn dữ liệu thiếu thì sao, model phản hồi chậm hay trả lời sai thì sao, và cùng một người dùng diễn đạt khác đi đôi chút thì hệ thống có còn nhất quán không?
Bản demo có một nhiệm vụ rất đáng giá: làm cho khả năng mới trở nên dễ thấy. Nó giúp cả nhóm cảm nhận nhanh cách tương tác, lợi ích và hình hài ban đầu của trải nghiệm. Vì thế, demo thường được chuẩn bị cho luồng thuận lợi nhất. Không có gì sai ở đó, miễn là ta nhớ nó mở đầu cuộc thảo luận chứ chưa phải lời cam kết với người dùng.
Đưa AI vào production nghĩa là phải nói rõ lời cam kết ấy. Hệ thống nhận loại đầu vào nào và từ chối loại nào? Khi thiếu dữ kiện, nó hỏi lại hay tự đoán? Bằng chứng nào được đưa ra cùng câu trả lời? Dữ liệu gì được ghi log, dữ liệu gì tuyệt đối không? Nếu nhà cung cấp gặp sự cố, ngữ cảnh đã cũ, hoặc người dùng muốn một mức chắc chắn mà sản phẩm không thể thành thật đáp ứng, sản phẩm sẽ làm gì?
Việc đầu tiên là đánh giá bằng những trường hợp đủ đại diện, không chỉ vài ví dụ đẹp. Bộ eval không cần đồ sộ, nhưng nên có đầu vào dễ, mơ hồ, cố tình gây nhiễu, rỗng, quá dài, đa ngôn ngữ và đặc thù lĩnh vực. Mục tiêu không phải chứng minh model không bao giờ sai. Mục tiêu là biết vùng nào hệ thống làm tốt, vùng nào nó thất bại rõ ràng, và ở đâu con người vẫn phải giữ quyền quyết định.
Việc thứ hai là chuẩn bị đường lui. Một câu trả lời sai bớt nguy hiểm hơn nhiều nếu sản phẩm biết hiển thị nguồn, đánh dấu phần chưa chắc, hỏi lại cho hẹp hơn, chuyển sang người xử lý, thử lại an toàn hoặc chỉ lưu bản nháp thay vì tự hành động. AI càng đụng tới tiền, quyền riêng tư, uy tín hay niềm tin của khách hàng, đường phục hồi càng phải cụ thể và được thử trước.
Việc thứ ba là quan sát hành vi thật. Mã HTTP 200 chỉ cho biết request đã quay về, không cho biết người dùng có chấp nhận câu trả lời, sửa nó, thử lại, bỏ ngang hay báo lỗi. Thiếu những tín hiệu này, cả nhóm đang lái sản phẩm bằng ký ức về buổi demo. Đầu vào đổi, ngữ cảnh đổi, model được cập nhật; vì vậy observability là một phần của tính năng, không phải việc để dành sau khi ra mắt.
Giữa hào hứng sản phẩm và trách nhiệm kỹ thuật còn có một khoảng cách về ngôn ngữ. Demo nói: “Thứ này có thể làm được.” Đặc tả production phải nói thêm: “Đây là điều chúng ta hứa, đây là điều chưa hứa, và đây là cách phát hiện lời hứa đang bị phá vỡ.” Rắc rối bắt đầu khi câu đầu được đối xử như thể đã bao gồm cả câu sau.
Vì vậy, cạnh mỗi bản demo AI nên có một danh sách ngắn: đầu vào được hỗ trợ, quy tắc từ chối, cách trình bày bằng chứng, các ca eval, phương án dự phòng, ranh giới riêng tư, giới hạn chi phí, mục tiêu độ trễ và người chịu trách nhiệm xem lại. Nó không dập tắt hứng thú. Nó chỉ làm căn phòng chậm vừa đủ để mọi người nhìn thấy phần việc còn lại.
Bản demo giành được sự chú ý; production phải giành được niềm tin. Cây cầu giữa hai bên không được xây bằng một câu trả lời bóng bẩy hơn, mà bằng những failure mode được gọi đúng tên, những trường hợp bình thường được thử kỹ và một sản phẩm biết phải làm gì khi model nói rất hay nhưng tình huống ngoài đời không hề đơn giản.