03 thg 5, 2025·8 phút
Xác thực, Lỗi và Trường hợp Biên trong Hệ thống Sinh bởi AI
Tìm hiểu cách các luồng AI sinh tạo ra quy tắc xác thực, nhu cầu xử lý lỗi và các trường hợp biên—và các cách thực tế để kiểm thử, giám sát và sửa chúng.
Tìm hiểu cách các luồng AI sinh tạo ra quy tắc xác thực, nhu cầu xử lý lỗi và các trường hợp biên—và các cách thực tế để kiểm thử, giám sát và sửa chúng.
Một hệ thống sinh bởi AI là bất kỳ sản phẩm nào mà mô hình AI tạo ra các output ảnh hưởng trực tiếp đến bước tiếp theo của hệ thống—những gì được hiển thị cho người dùng, những gì được lưu, những gì được gửi đến công cụ khác, hoặc những hành động được thực hiện.
Điều này rộng hơn “một chatbot.” Trong thực tế, việc sinh bởi AI có thể xuất hiện dưới dạng:
Nếu bạn đã dùng nền tảng vibe-coding như Koder.ai—nơi một cuộc trò chuyện chat có thể tạo và phát triển đầy đủ ứng dụng web, backend hoặc mobile—ý tưởng “output của mô hình trở thành luồng điều khiển” càng trở nên cụ thể. Output của mô hình không chỉ là gợi ý; nó có thể thay đổi routes, schema, lệnh API, deployment và hành vi hiển thị cho người dùng.
Khi output của AI là một phần của luồng điều khiển, quy tắc xác thực và xử lý lỗi trở thành các tính năng độ tin cậy hướng tới người dùng, không chỉ là chi tiết kỹ thuật. Thiếu một trường, một đối tượng JSON sai định dạng, hoặc một chỉ dẫn tự tin nhưng sai không đơn thuần là “bị lỗi”—nó có thể tạo UX khó hiểu, bản ghi sai, hoặc hành động rủi ro.
Vì vậy mục tiêu không phải “không bao giờ lỗi.” Lỗi là bình thường khi output có tính xác suất. Mục tiêu là lỗi được kiểm soát: phát hiện sớm, truyền tải rõ ràng, và khôi phục an toàn.
Phần còn lại của bài viết chia chủ đề thành các khu vực thực tế:
Nếu bạn coi các đường xử lý xác thực và lỗi là phần quan trọng của sản phẩm, hệ thống sinh bởi AI sẽ dễ tin cậy hơn—và dễ cải thiện theo thời gian.
Hệ thống AI giỏi tạo ra các câu trả lời có vẻ hợp lý, nhưng “hợp lý” không đồng nghĩa với “sử dụng được.” Ngay khi bạn dựa vào output của AI cho một luồng công việc thực tế—gửi email, tạo ticket, cập nhật bản ghi—những giả định ẩn của bạn biến thành các quy tắc xác thực rõ ràng.
Với phần mềm truyền thống, output thường mang tính xác định: nếu input là X, bạn mong Y. Với hệ thống sinh bởi AI, cùng một prompt có thể cho ra những cách diễn đạt khác nhau, mức độ chi tiết khác nhau, hoặc các cách hiểu khác nhau. Sự biến động này không phải lỗi tự thân—nhưng nó có nghĩa là bạn không thể dựa vào kỳ vọng không chính thức như “có lẽ sẽ bao gồm ngày” hoặc “thường trả về JSON.”
Quy tắc xác thực là câu trả lời thực tế cho: Cần gì phải đúng để output này an toàn và hữu dụng?
Một phản hồi AI có thể trông hợp lệ trong khi vẫn thất bại với yêu cầu thực tế của bạn.
Ví dụ, mô hình có thể sinh:
Thực tế bạn sẽ có hai lớp kiểm tra:
Output AI thường mơ hồ ở những chỗ con người tự giải quyết một cách trực giác, đặc biệt là quanh:
Một cách hữu ích để thiết kế xác thực là định nghĩa “hợp đồng” cho mỗi tương tác AI:
Khi đã có hợp đồng, quy tắc xác thực không giống quan liêu—chúng là cách làm cho hành vi AI đủ đáng tin để dùng.
Xác thực đầu vào là tuyến phòng thủ đầu tiên cho hệ thống sinh bởi AI. Nếu đầu vào lộn xộn hoặc không mong đợi lọt vào, mô hình vẫn có thể sinh thứ gì đó “tự tin,” và đó chính xác là lý do cần canh cửa phía trước.
Đầu vào không chỉ là hộp prompt. Nguồn thường gặp gồm:
Mỗi loại có thể thiếu, sai định dạng, quá lớn, hoặc không như bạn mong đợi.
Xác thực tốt tập trung vào quy tắc rõ ràng, có thể kiểm thử:
Những kiểm tra này giảm sự nhầm lẫn của mô hình và bảo vệ hệ thống tiếp theo (parser, DB, hàng đợi) khỏi crash.
Chuẩn hoá biến “gần đúng” thành dữ liệu nhất quán:
Chỉ chuẩn hoá khi quy tắc rõ ràng. Nếu bạn không chắc người dùng muốn gì, đừng đoán.
Một quy tắc hữu ích: auto-correct cho định dạng, từ chối cho ngữ nghĩa. Khi từ chối, trả về thông báo rõ ràng cho người dùng nêu điều cần thay đổi và lý do.
Xác thực đầu ra là chốt sau khi mô hình trả lời. Nó trả lời hai câu hỏi: (1) output có đúng dạng không? và (2) nó thực sự chấp nhận được và hữu dụng không? Trong sản phẩm thực tế, bạn thường cần cả hai.
Bắt đầu bằng cách định nghĩa schema đầu ra: dạng JSON bạn mong đợi, khóa nào phải có, kiểu và giá trị cho phép. Điều này biến “văn bản tự do” thành thứ ứng dụng bạn có thể dùng an toàn.
Một schema thực tế thường chỉ định:
answer, confidence, citations)status phải là một trong "ok" | "needs_clarification" | "refuse")Kiểm tra cấu trúc bắt được các lỗi phổ biến: mô hình trả prose thay vì JSON, quên khóa, hoặc xuất số mà bạn cần string.
Ngay cả JSON đúng cấu trúc vẫn có thể sai. Xác thực ngữ nghĩa kiểm tra nội dung có hợp lý với sản phẩm và chính sách của bạn hay không.
Ví dụ vượt qua schema nhưng sai về ý nghĩa:
customer_id: "CUST-91822" mà không tồn tại trong DBtotal là 98; hoặc mức giảm giá lớn hơn subtotalKiểm tra ngữ nghĩa thường giống quy tắc nghiệp vụ: “ID phải resolve”, “các tổng phải khớp”, “ngày phải là tương lai”, “luận điểm phải được hỗ trợ bởi tài liệu đã cung cấp”, và “không có nội dung bị cấm.”
Mục tiêu không phải là trừng phạt mô hình—mà ngăn hệ thống downstream xử lý “những điều vô nghĩa tự tin” như là lệnh.
Hệ thống sinh bởi AI đôi khi sẽ tạo output không hợp lệ, không đầy đủ, hoặc không thể dùng cho bước tiếp theo. Xử lý lỗi tốt là quyết định vấn đề nào cần dừng luồng ngay, và vấn đề nào có thể khôi phục mà không làm người dùng ngạc nhiên.
Thất bại cứng là khi tiếp tục rất có khả năng gây kết quả sai hoặc hành vi không an toàn. Ví dụ: thiếu trường bắt buộc, không parse được JSON, hoặc output vi phạm chính sách bắt buộc. Trong những trường hợp này, dừng ngay: ngừng, hiển thị lỗi rõ ràng, và tránh đoán mò.
Thất bại mềm là vấn đề có thể phục hồi khi có fallback an toàn. Ví dụ: mô hình trả đúng ý nhưng định dạng sai, phụ thuộc tạm thời không khả dụng, hoặc request timeout. Ở đây, phục hồi mềm: retry có giới hạn, re-prompt với ràng buộc chặt hơn, hoặc chuyển sang đường fallback đơn giản hơn.
Thông báo lỗi hướng người dùng nên ngắn và có thể hành động:
Tránh phơi bày stack trace, prompt nội bộ, hoặc ID nội bộ. Những chi tiết đó hữu ích—nhưng chỉ ở mức nội bộ.
Xử lý lỗi như hai output song song:
Điều này giữ sản phẩm bình tĩnh và dễ hiểu trong khi vẫn cung cấp đủ thông tin cho đội fix lỗi.
Một taxonomy đơn giản giúp team hành động nhanh:
Khi bạn gán nhãn chính xác cho một sự cố, có thể chuyển tới đúng người chịu trách nhiệm—và cải thiện quy tắc phù hợp.
Xác thực sẽ bắt được vấn đề; phục hồi quyết định người dùng thấy trải nghiệm hữu ích hay rối rắm. Mục tiêu không phải “luôn thành công”—mà là “thất bại có thể dự đoán, và giảm mức độ hỏng an toàn.”
Retry hiệu quả nhất khi lỗi có khả năng tạm thời:
Dùng retry có giới hạn với exponential backoff và jitter. Retry năm lần liên tiếp có thể biến sự cố nhỏ thành lớn.
Retry gây hại khi output cấu trúc sai hoặc ngữ nghĩa sai. Nếu validator báo “thiếu trường bắt buộc” hoặc “vi phạm chính sách,” lần gọi tiếp theo với cùng prompt có thể chỉ sinh một câu trả lời sai khác—và tiêu tốn token và thời gian. Khi đó, ưu tiên sửa prompt (yêu cầu chặt hơn) hoặc dùng fallback.
Fallback tốt là fallback bạn có thể giải thích với người dùng và đo lường nội bộ:
Ghi rõ đường nào đã dùng: lưu lại đường dẫn để sau này so sánh chất lượng và chi phí.
Đôi khi bạn có thể trả về một phần hữu dụng (ví dụ: thực thể được trích xuất nhưng không có tóm tắt đầy đủ). Đánh dấu là partial, kèm cảnh báo, và tránh lấp chỗ trống bằng những phỏng đoán. Điều này giữ được niềm tin trong khi vẫn cung cấp thứ gì đó hành động được.
Đặt timeout cho mỗi gọi và thời hạn tổng cho request. Khi bị rate-limited, tôn trọng Retry-After nếu có. Thêm circuit breaker để khi lỗi lặp lại, nhanh chóng chuyển sang fallback thay vì dồn áp lực lên mô hình/API. Điều này ngăn chuỗi chậm chạp và làm cho hành vi phục hồi nhất quán.
Trường hợp biên là những tình huống nhóm bạn chưa gặp trong demo: đầu vào hiếm, định dạng lạ, prompt gây hại, hoặc cuộc trò chuyện dài hơn dự kiến. Với hệ thống sinh bởi AI, chúng xuất hiện nhanh vì người dùng coi hệ thống như trợ lý linh hoạt—rồi thử đẩy nó ra khỏi đường chính.
Người dùng thực sự không viết như dữ liệu test. Họ dán screenshot chuyển thành text, ghi chú nửa chừng, hoặc nội dung copy từ PDF có ngắt dòng lạ. Họ còn thử prompt “sáng tạo”: yêu cầu mô hình bỏ qua quy tắc, tiết lộ prompt ẩn, hoặc xuất ở định dạng cố ý gây rối.
Ngữ cảnh dài là một edge case phổ biến khác. Người dùng có thể tải tài liệu 30 trang và yêu cầu tóm tắt có cấu trúc, rồi follow-up hàng chục câu hỏi. Ngay cả khi mô hình làm tốt ở đầu, hành vi có thể drift khi ngữ cảnh tăng dần.
Nhiều lỗi đến từ cực trị hơn là trường hợp bình thường:
Những thứ này thường lọt qua kiểm tra cơ bản vì với con người nhìn thì ổn, nhưng parser, bộ đếm hoặc luật downstream gặp lỗi.
Ngay cả khi prompt và validator ổn, tích hợp có thể mang đến edge case mới:
Một số edge case không thể dự đoán trước. Cách đáng tin cậy để phát hiện là quan sát lỗi thực tế. Logs và traces tốt nên ghi: kiểu input (an toàn), output của mô hình (an toàn), quy tắc validator nào thất bại, và đường phục hồi nào được chạy. Khi bạn có thể nhóm lỗi theo pattern, sẽ biến những bất ngờ thành quy tắc mới rõ ràng—không phải đoán mò.
Xác thực không chỉ để giữ output gọn gàng; nó còn là cách ngăn hệ thống AI làm điều không an toàn. Nhiều sự cố bảo mật trong ứng dụng có AI thực ra là vấn đề “đầu vào xấu” hoặc “đầu ra xấu” với hậu quả lớn: rò rỉ dữ liệu, hành động trái phép, hoặc lạm dụng công cụ.
Prompt injection xảy ra khi nội dung không tin cậy (message người dùng, trang web, email, tài liệu) chứa chỉ dẫn như “bỏ qua quy tắc” hoặc “gửi prompt hệ thống ẩn cho tôi.” Đây là vấn đề xác thực vì hệ thống phải quyết định chỉ dẫn nào hợp lệ và chỉ dẫn nào có ý đồ xấu.
Quan điểm thực tế: coi văn bản tiếp xúc với mô hình là không tin cậy. Ứng dụng của bạn nên xác thực ý định (hành động được yêu cầu) và thẩm quyền (người yêu cầu có quyền làm điều đó không), không chỉ định dạng.
Bảo mật tốt thường trông giống các quy tắc xác thực bình thường:
Nếu bạn cho mô hình duyệt hoặc fetch tài liệu, hãy validate nơi nó được phép đi và những gì nó có thể mang về.
Áp dụng nguyên tắc ít quyền nhất: cấp cho mỗi tool quyền tối thiểu, scope token chặt (tuổi ngắn, endpoint hạn chế, dữ liệu hạn chế). Tốt hơn là từ chối một request và yêu cầu hành động hẹp hơn thay vì cấp quyền rộng "phòng khi cần".
Với hành động có tác động lớn (thanh toán, thay đổi tài khoản, gửi email, xóa dữ liệu), thêm:
Những biện pháp này biến xác thực từ chi tiết UX thành ranh giới an toàn thực sự.
Kiểm thử hành vi sinh bởi AI hiệu quả nhất khi bạn coi mô hình như một cộng tác viên không đoán trước: bạn không thể khẳng định mọi câu chữ, nhưng có thể khẳng định ranh giới, cấu trúc, và hữu ích.
Dùng nhiều lớp kiểm thử, mỗi lớp trả lời câu hỏi khác nhau:
Quy tắc: nếu lỗi lọt tới end-to-end, thêm test nhỏ hơn (unit/contract) để bắt nó sớm hơn lần sau.
Tạo tập nhỏ, tuyển chọn các prompt đại diện cho thực tế. Với mỗi prompt, lưu:
Chạy bộ prompt vàng trong CI và theo dõi thay đổi theo thời gian. Khi có sự cố, thêm test vàng cho trường hợp đó.
Hệ thống AI thường fail ở cạnh rối. Thêm fuzzing tự động tạo:
Thay vì chụp snapshot câu chữ, dùng ngưỡng và rubric:
Cách này giữ test ổn định trong khi vẫn bắt regressions thực sự.
Quy tắc xác thực và xử lý lỗi chỉ cải thiện khi bạn thấy điều gì đang xảy ra trong thực tế. Giám sát biến "chúng tôi nghĩ là ổn" thành bằng chứng rõ ràng: gì lỗi, tần suất, và liệu độ tin cậy có được cải thiện hay trượt dần.
Bắt đầu với logs giải thích vì sao request thành công hoặc thất bại—sau đó redact hoặc tránh dữ liệu nhạy cảm mặc định.
address.postcode), lý do thất bại (mismatch schema, nội dung không an toàn, thiếu intent).Logs giúp debug một sự cố; metrics giúp phát hiện pattern. Theo dõi:
Output AI có thể thay đổi nhẹ sau khi sửa prompt, cập nhật mô hình, hoặc hành vi người dùng mới. Cảnh báo nên tập trung vào thay đổi, không chỉ ngưỡng tuyệt đối:
Dashboard tốt trả lời: “Người dùng có dùng được không?” Bao gồm bảng điểm độ tin cậy đơn giản, đường xu hướng tỷ lệ pass schema, phân tách lỗi theo category, và ví dụ lỗi phổ biến nhất (loại bỏ nội dung nhạy cảm). Liên kết tới view kỹ thuật sâu hơn cho engineers, nhưng phần trên cùng dễ đọc cho product và support.
Xác thực và xử lý lỗi không phải "làm xong một lần rồi quên." Với hệ thống sinh bởi AI, công việc thực sự bắt đầu sau khi ra mắt: mọi output lạ là manh mối cho quy tắc mới của bạn.
Xem lỗi là dữ liệu, không phải giai thoại. Vòng phản hồi hiệu quả thường kết hợp:
Đảm bảo mỗi báo cáo liên kết tới input chính xác, phiên bản mô hình/prompt, và kết quả validator để bạn có thể tái tạo sau.
Hầu hết cải tiến rơi vào vài động tác lặp lại:
Khi bạn sửa một vụ, hỏi tiếp: “Những trường hợp lân cận nào vẫn sẽ lọt qua?” Mở rộng quy tắc để bao phủ một cụm nhỏ, không chỉ một vụ duy nhất.
Version prompts, validators và mô hình như code. Triển khai với canary hoặc A/B, theo dõi các metric chính (tỷ lệ từ chối, hài lòng người dùng, chi phí/độ trễ), và giữ đường rollback nhanh.
Đây cũng là nơi tool sản phẩm hữu ích: ví dụ, nền tảng như Koder.ai hỗ trợ snapshot và rollback trong quá trình lặp ứng dụng, phù hợp với versioning prompt/validator. Khi update làm tăng lỗi schema hoặc phá kết nối, rollback nhanh biến sự cố sản xuất thành phục hồi nhanh.
Một hệ thống "AI-generated" là bất kỳ sản phẩm nào mà output của mô hình trực tiếp ảnh hưởng đến bước tiếp theo—những gì được hiển thị, lưu trữ, gửi đến công cụ khác, hoặc được thực thi như một hành động.
Nó rộng hơn chatbot: có thể bao gồm dữ liệu sinh, mã sinh, các bước luồng công việc, hoặc quyết định dùng tool/agent.
Vì khi output của AI là một phần của luồng điều khiển, độ tin cậy trở thành trải nghiệm người dùng. Một phản hồi JSON sai cấu trúc, trường thiếu, hoặc chỉ dẫn sai có thể:
Thiết kế đường xử lý lỗi và xác thực trước giúp các lỗi được kiểm soát thay vì hỗn loạn.
Tính hợp lệ cấu trúc nghĩa là output có thể phân tích cú pháp và đúng dạng mong đợi (ví dụ: JSON hợp lệ, các khóa bắt buộc có mặt, kiểu dữ liệu đúng).
Tính hợp lệ theo nghiệp vụ nghĩa là nội dung phù hợp với quy tắc thực tế của bạn (ví dụ: ID phải tồn tại, tổng phải khớp, văn bản hoàn tiền phải tuân thủ chính sách). Thông thường bạn cần cả hai lớp kiểm tra.
Một hợp đồng thực tế định rõ những gì phải đúng ở ba điểm:
Khi có hợp đồng, validator chỉ là việc tự động thi hành nó.
Hãy coi đầu vào rộng hơn hộp prompt: văn bản người dùng, file, trường form, payload API, dữ liệu truy xuất từ công cụ.
Những kiểm tra hiệu quả gồm các trường bắt buộc, giới hạn kích thước/file, enum, giới hạn độ dài, mã hoá/JSON hợp lệ và format URL an toàn. Những điều này giảm độ nhầm lẫn của mô hình và bảo vệ parser/DB phía sau.
Chuẩn hoá khi ý định rõ ràng và thay đổi có thể hoàn nguyên (ví dụ: trim khoảng trắng, chuẩn hoá chữ hoa thường cho mã quốc gia).
Từ chối khi việc "sửa" có thể thay đổi ý nghĩa hoặc che dấu lỗi (ví dụ: ngày "03/04/2025" mơ hồ, tiền tệ không mong đợi, HTML/JS đáng ngờ). Quy tắc hữu ích: auto-correct cho định dạng, từ chối cho ngữ nghĩa.
Bắt đầu với một schema đầu ra rõ ràng:
answer, status)Sau đó thêm kiểm tra ngữ nghĩa (ID phải resolve, tổng phải khớp, ngày hợp lý, trích dẫn hỗ trợ luận điểm). Nếu validation thất bại, tránh tiêu thụ output vào downstream—thay vào đó retry với ràng buộc chặt hơn hoặc dùng fallback.
Dừng ngay khi tiếp tục có thể gây sai sót hoặc nguy hiểm: không parse được output, thiếu trường bắt buộc, vi phạm chính sách.
Phục hồi mềm khi có phương án an toàn: timeout tạm thời, rate limit, lỗi định dạng nhỏ. Trong cả hai trường hợp, tách:
Retry có ích khi lỗi mang tính tạm thời (timeouts, 429, sự cố mạng ngắn). Dùng retry có giới hạn với exponential backoff và jitter.
Retry gây lãng phí khi output sai về cấu trúc hoặc ngữ nghĩa (mismatch schema, thiếu trường). Trong trường hợp đó, ưu tiên sửa prompt (ràng buộc chặt hơn), template xác định, model nhỏ hơn, cache, hoặc review thủ công tuỳ rủi ro.
Các trường hợp biên thường đến từ:
Khám phá "unknown unknowns" bằng logs có cân nhắc riêng tư, lưu rule nào thất bại và đường phục hồi đã chạy.