Tin, rồi kiểm, rồi kiểm lại lần nữa

Hệ generative hỏng khác với phần mềm thông thường. Chúng không crash. Chúng tạo ra thứ gì đó nghe hợp lý, trôi chảy, và thi thoảng sai, ở quy mô lớn, với vẻ mặt tỉnh bơ. Đẩy output của chúng ra thế giới bên ngoài mà không có bộ máy nào chắn ở giữa là tắc trách. Của chúng tôi phải vượt qua ba bức tường.

Bức tường một: evidence gate

Mọi khẳng định do máy đưa ra đều phải kèm bằng chứng, và bằng chứng phải có cấu trúc, chứ không phải cảm tính:

{
  "claim": "business site has no online booking flow",
  "evidence": {
    "url": "https://example-biz.com/reserve",
    "fetched_at": "2026-03-11T02:14:09Z",
    "check": "booking CTA selectors absent in rendered DOM",
    "screenshot": "sha256:9f2c11ab..."
  },
  "verdict": "pass"
}

Không có evidence object thì không pass. Khớp kiểu mập mờ trong khi luật đòi khớp chính xác thì không pass. Đáng kinh ngạc là có bao nhiêu ảo giác chết ngay trước một yêu cầu đơn giản: chỉ cho tôi xem anh đọc được điều đó ở đâu.

Bức tường hai: identity gate, và con bug dạy chúng tôi bài học khiêm tốn

Một pipeline viết về các doanh nghiệp có thật thì trước hết phải chứng minh nó đang nhìn đúng doanh nghiệp cần nhìn. Identity gate đầu tiên của chúng tôi đem tên doanh nghiệp so với tên miền và bỏ qua mọi thứ không khớp. Nghe hợp lý, và sai tai hại ở một thị trường nơi doanh nghiệp mang tên tiếng Hàn còn tên miền lại viết bằng chữ Latin. Cái gate đó âm thầm vứt đi 98% mục tiêu hợp lệ. Cách sửa là thôi tin vào chuỗi tên miền, chuyển sang xác minh danh tính từ chính nội dung trang, tên, địa chỉ, số điện thoại đối chiếu chéo với hồ sơ. Tỷ lệ pass nhảy từ 2% lên 71% và từ đó tới nay không còn vụ nhầm thực thể nào. Bài học rút ra rộng hơn: một cái gate hỏng theo kiểu đóng có thể sai chẳng kém một cái gate hỏng theo kiểu mở, và chỉ có đo đạc mới cho anh biết mình đang dính kiểu hỏng nào.

Bức tường ba: lượt rà đối kháng

Cách nâng chất lượng rẻ nhất mà chúng tôi biết là bảo một instance model thứ hai tấn công output của instance thứ nhất. Không phải cải thiện. Mà bác bỏ. Prompt của reviewer nói rõ việc của nó là tìm ra lỗ hổng, và khi lưỡng lự thì cứ kết luận là bác bỏ, vì bỏ sót một lỗi tốn của chúng tôi nhiều hơn là vứt nhầm một kết quả tốt. Một reviewer chỉ có mỗi việc tìm lỗ hổng sẽ moi ra đúng những lỗi mà một reviewer kiểu hợp tác sẽ lịch sự cho qua. Những phát hiện còn trụ lại chính là những cái đáng để ra tay.

Đứng sau cả ba bức tường là bộ regression suite, khoảng 3,900 case, số ca hỏng kỳ vọng bằng không, cứ mỗi sự cố lại thêm một case. Chẳng thứ nào trong đây làm pipeline chậm đi đáng kể. Tất cả gộp lại chính là thứ cho phép chúng tôi chĩa bộ máy generative vào những hậu quả đời thực mà vẫn ngủ ngon.