Trước khi nối AI với bảng hàng, viết 6 phép kiểm cho dữ liệu động

Một chủ tiệm chuẩn bị nối bảng hàng với công cụ soạn trả lời khách. Trước khi bật cho dữ liệu thật, chị tạo một bản ghi thử có đúng ba trường dễ gây hậu quả nếu sai:

Giá hiện tại: 329.000 đồng
Tồn kho màu xanh: 4
Ngày giao dự kiến: [TRỐNG]

Việc đầu tiên không phải viết câu trả lời mẫu. Chị xóa giá rồi chạy thử. Sau đó khôi phục giá, xóa tồn kho. Cuối cùng thay giá 329.000 thành 349.000 đồng. Mỗi lần chỉ có một câu hỏi: hệ thống có phản ứng đúng với dữ liệu vừa thay đổi không?

Đây là bước Improve khác với việc kiểm từng câu trả lời trước khi gửi. Khi một loại lỗi đã lặp lại, bạn có thể biến nó thành phép kiểm cố định cho quy trình. Bài dùng dữ liệu giả lập; không có kết quả thử nghiệm nào được trình bày như hiệu năng của một model hay nền tảng bán hàng cụ thể.

Sáu phép kiểm thay cho một lời nhắc “đừng bịa”

Tạo một tệp hoặc trang tính nhỏ với sáu hàng. Mỗi hàng chỉ thay một điều trong dữ liệu đầu vào và ghi điều bắt buộc phải xảy ra ở đầu ra.

Phép kiểm	Thay đổi ở đầu vào	Điều bắt buộc ở đầu ra
1	Xóa giá	Không xuất hiện giá; phải báo cần kiểm tra giá
2	Đổi giá 329.000 → 349.000	Chỉ dùng 349.000
3	Xóa tồn kho	Không được nói “còn hàng”, “sắp hết” hay tự tạo số lượng
4	Tồn kho = 0	Không được viết như sản phẩm đang có sẵn
5	Xóa ngày giao dự kiến	Không được hứa ngày nhận cụ thể
6	Chỉ giữ “có giao tại TP.HCM”	Không được biến khu vực phục vụ thành cam kết “nhận thứ Hai”

Sáu hàng này là ma trận kiểm tra, không phải sáu mẫu trả lời cho khách. Câu chữ có thể thay đổi; điều được kiểm là ranh giới dữ liệu. Nếu công cụ viết Giá hiện tại cần được nhân viên xác nhận thay vì một nhãn cố định, phép kiểm 1 vẫn có thể đạt. Nếu nó viết khoảng 329.000 đồng sau khi giá đã bị xóa, phép kiểm trượt dù câu nghe tự nhiên.

NIST AI 600-1 mô tả confabulation như một rủi ro của AI tạo sinh: nội dung sai có thể được trình bày tự tin. Với cửa hàng, cách giảm rủi ro không chỉ là nhắc người dùng đọc kỹ hơn; bạn còn có thể thiết kế phép kiểm để phát hiện lúc hệ thống lấy một dữ kiện không có trong nguồn hiện tại.

Viết quy tắc theo dạng “nếu nguồn thiếu thì đầu ra phải…”

Sau khi có ma trận, mới viết chỉ dẫn cho công cụ. Phần quan trọng không phải lời văn dài mà là quan hệ giữa trường dữ liệu và hành vi đầu ra:

Chỉ dùng dữ liệu trong <du_lieu_hien_tai>.

QUY TẮC KIỂM TRA:
- Nếu “Giá hiện tại” trống: không nêu giá; đánh dấu cần nhân viên kiểm tra.
- Nếu “Tồn kho hiện tại” trống: không nêu trạng thái còn/hết/sắp hết.
- Nếu “Tồn kho hiện tại” bằng 0: không mô tả sản phẩm là đang có sẵn.
- Nếu “Ngày giao dự kiến” trống: không hứa ngày nhận cụ thể.
- “Khu vực có thể giao” chỉ nói nơi phục vụ, không chứng minh ngày nhận.

Sau khi soạn, liệt kê trường nào trong ba trường trên chưa đủ dữ liệu để gửi.

Hướng dẫn prompt của OpenAI khuyến nghị cung cấp chỉ dẫn rõ và ngữ cảnh liên quan. Ở đây, ngữ cảnh là bản ghi bán hàng hiện tại; còn ma trận sáu phép kiểm là cách của bạn để xác minh rằng chỉ dẫn đang tạo đúng ranh giới cần thiết. Tài liệu OpenAI không chứng minh sáu phép kiểm này là một chuẩn chung.

Chạy ma trận trên dữ liệu giả trước khi chạm dữ liệu khách

Bắt đầu bằng một sản phẩm tưởng tượng. Không cần tên khách, số điện thoại, địa chỉ hay lịch sử mua hàng. Với mỗi hàng trong ma trận:

1. tạo đúng trạng thái đầu vào đã ghi;
2. chạy cùng một chỉ dẫn;
3. chỉ đánh dấu ĐẠT khi điều bắt buộc ở cột cuối được giữ;
4. nếu trượt, lưu lại đầu vào và đầu ra gây trượt trước khi sửa chỉ dẫn.

Đừng sửa ba thứ cùng lúc. Nếu phép kiểm 3 trượt, sửa ràng buộc liên quan tồn kho rồi chạy lại cả sáu hàng. Một sửa đổi có thể chữa lỗi này nhưng làm hỏng trường khác.

Bạn cũng không cần yêu cầu câu chữ giống hệt giữa các lần chạy. Mục tiêu là kiểm tính chất của đầu ra: dữ liệu thiếu không được biến thành dữ liệu có vẻ chắc chắn, và dữ liệu mới phải thay thế dữ liệu cũ.

Một lỗi trượt cho biết nên sửa ở đâu

Giả sử phép kiểm 2 trượt: đầu vào đã đổi giá thành 349.000 đồng nhưng bản nháp vẫn viết 329.000 đồng. Đừng vội thêm câu hãy cẩn thận hơn. Hãy tìm đường đi của dữ liệu. Công cụ có còn nhìn thấy bản ghi cũ trong cuộc trò chuyện không? Hệ thống tích hợp có gửi cả hai giá không? Trường nào được coi là nguồn hiện hành?

Nếu phép kiểm 5 trượt và công cụ hứa nhận thứ Hai khi ngày giao đang trống, vấn đề lại khác: quy tắc đang cho phép suy từ khu vực giao sang ngày nhận. Khi đó cần tách hai trường trong dữ liệu và trong chỉ dẫn, thay vì chỉ đổi giọng văn của câu trả lời.

Ma trận vì thế giúp chủ tiệm phân biệt lỗi dữ liệu đi vào sai với lỗi AI diễn giải vượt quá dữ liệu. Hai lỗi này cần cách sửa khác nhau.

Chỉ cân nhắc tự động hóa khi phép kiểm vẫn chạy được sau thay đổi

Khi cả sáu hàng đạt, chưa có nghĩa hệ thống đủ an toàn để tự gửi cho khách. Sáu tình huống chỉ bao phủ ba loại dữ liệu đang được kiểm. Nếu cửa hàng thêm khuyến mãi, phí giao, đổi trả hoặc nhiều kho, hãy thêm phép kiểm tương ứng trước khi mở rộng quyền của hệ thống.

Một cách vận hành thực tế là giữ ma trận này mỗi khi thay prompt, đổi nguồn dữ liệu hoặc đổi công cụ. Chạy lại trên dữ liệu giả trước. Nếu một hàng từng đạt nay trượt, giữ chế độ bản nháp và sửa nguyên nhân trước khi cho quy trình đi xa hơn.

Với dữ liệu thật, chỉ dùng công cụ và tài khoản được cửa hàng cho phép. Không đưa thông tin khách hàng hoặc dữ liệu kinh doanh nhạy cảm vào dịch vụ chưa được phê duyệt. NIST cũng lưu ý rủi ro dữ liệu và quyền riêng tư trong hệ thống AI tạo sinh.

Bước tiến ở đây không phải thêm một mẫu câu có ô [CẦN KIỂM TRA]. Nó là biến ba ranh giới kinh doanh — giá, tồn kho, giao hàng — thành các phép kiểm có thể chạy lại. Khi quy trình thay đổi, bạn không cần nhớ mình từng gặp lỗi gì; ma trận sẽ hỏi lại đúng sáu câu đó.

Nguồn để đối chiếu

• NIST AI 600-1 — Generative Artificial Intelligence Profile — dùng để đối chiếu rủi ro confabulation, dữ liệu và quyền riêng tư; tài liệu không xác nhận ma trận sáu phép kiểm cụ thể trong bài.
• OpenAI — Prompt engineering — hỗ trợ nguyên tắc viết chỉ dẫn rõ và cung cấp ngữ cảnh liên quan; việc chuyển lỗi bán hàng thành ma trận kiểm tra là thiết kế biên tập của bài này.

Nguồn tham khảo

1. nvlpubs.nist.gov
2. developers.openai.com