20% tất cả phản hồi web “OK” mà AI nhận được đều không ổn

Những thử nghiệm gần đây của tôi về thu thập dữ liệu web có sự hỗ trợ của AI đã cho thấy rõ mức độ ngày càng tăng của xu hướng web bị “khóa chặt”. Tất nhiên, nguyên nhân thúc đẩy sự co cụm này là sự gia tăng đáng kinh ngạc của hoạt động thu thập dữ liệu web bằng AI, với nhu cầu dữ liệu mới không ngừng có thể khiến các tên miền ngừng hoạt động.

Đây là lý do khá thuận tiện để các tên miền làm điều mà nhiều bên đã muốn thực hiện từ lâu: chỉ cho phép người dùng đã đăng nhập truy cập nội dung (dù đương nhiên, Googlebot thường được miễn trừ). Facebook hoàn tất việc áp dụng dần chính sách này vào năm 2023, còn Twitter/X cũng làm như vậy trong cùng năm. Reddit sẽ áp dụng chính sách này vào cuối tháng này.

Nhờ vậy, tên miền có thể tuân thủ các quy định cụ thể của từng quốc gia về thực thi giới hạn độ tuổi dễ dàng hơn đôi chút, vì người dùng đã đăng ký tài khoản. Quan trọng hơn, dữ liệu của người dùng có thể được lưu lại, khai thác để phân tích tại chỗ và — nếu luật pháp địa phương cho phép — bán cho các nhà môi giới dữ liệu và công ty AI.

Ở những nơi khác, các biện pháp tập trung vào việc chống bot (thay vì đăng ký người dùng) đã tăng hơn 58% so với cùng kỳ năm trước, theo Cloudflare; và toàn bộ hoạt động bot ngày càng gia tăng này đương nhiên khiến các trang web rà soát kỹ địa chỉ VPN và proxy, có thể từ chối quyền truy cập của người dùng hợp pháp cùng với mọi lưu lượng truy cập “độc hại”.

Điều tôi nhận thấy qua trải nghiệm cá nhân là mình ngày càng thường xuyên gặp các phản hồi hoặc thử thách “chặn truy cập”, đến mức có khi tôi bỏ luôn một trang web khi nó bắt đầu tải những nội dung đó; và vì các bức tường CAPTCHA được cho là khiến người dùng và khách hàng tiềm năng nản lòng, có thể hình dung áp lực khiến chủ sở hữu tên miền áp dụng chúng bất chấp nhược điểm ấy lớn đến mức nào.

Một CAPTCHA từ archive.is, một trong nhiều trang web đã áp dụng các thử thách, thường là để ứng phó với số lượng yêu cầu tự động (chứ không phải do con người gửi) quá lớn.

Tình trạng cản trở ngày càng tăng này một phần xuất phát từ khó khăn về mặt vận hành (vì không phải tên miền nào cũng đủ sức chống chọi với làn sóng yêu cầu ồ ạt), nhưng cũng thường là một kiểu chiến thuật thương lượng nhằm thăm dò xem các công ty AI có đề nghị trả thù lao riêng lẻ hay chung cho toàn bộ lượng dữ liệu mà họ khao khát đến vậy hay không — lượng dữ liệu vốn miễn phí suốt một thời gian dài cho đến tận bây giờ.

Vì trình thu thập dữ liệu của AI phải hoạt động ở quy mô lớn, chúng thường sử dụng các phiên bản Chrome “không giao diện” theo khuôn khổ Playwright. Hiện nay, với ngày càng nhiều tên miền, cách này sẽ khiến bạn nhận được lỗi 403 (“bị từ chối truy cập”) (tức là máy chủ biết bạn đang tạo lưu lượng truy cập tự động và bảo bạn biến đi):

Một bản cài đặt changedetection.io trên máy cục bộ cố gắng thăm dò một trang web, nhưng trang web không chấp nhận trình duyệt mà khuôn khổ sử dụng và nhận diện được, nên trả về phản hồi 403 (“Bị từ chối truy cập”).

Điều người ta muốn là phản hồi từ máy chủ dành cho máy khách “200” (“OK”), ngay cả khi phải bỏ ra cả đống tiền cho một mạng lưới proxy dân cư, kết hợp với đủ loại thủ thuật lén lút khác không phải do con người thực hiện để có được phản hồi đó.

Không gì tốt hơn phản hồi 200; nói cách khác, không có mã phản hồi nào dành cho máy khách thể hiện tín hiệu tích cực mạnh hơn. Đây cũng không phải là phản hồi mơ hồ; nó không bao giờ có nghĩa là “gần ổn”, “rồi sẽ ổn sau” hay “đang dần ổn hơn”; mà là “ổn!”. Nếu không ổn thì đó không phải là phản hồi 200.

Xin chào! Biến đi

Tuy nhiên, theo một bài nghiên cứu mới, việc thiếu mức độ phân biệt này có thể làm sai lệch đáng kể các tập dữ liệu AI, những ước tính thống kê và việc báo cáo trạng thái “tốt” trong khi thực tế không phải vậy.

Nghiên cứu* ước tính rằng khoảng một phần năm số phản hồi thuộc nhóm 200 hoàn toàn không chứa nội dung trang có thể sử dụng, mà thay vào đó chỉ trả về khung trang web trống, thử thách CAPTCHA, hạn chế truy cập hoặc các trang thay thế.

Bài nghiên cứu nêu:

“20,9% số trang mà một máy khách tĩnh nhận được với trạng thái 200 không chứa nội dung chính của trang: khung ứng dụng, thử thách bot, trang chặn, trang lỗi và trang giữ chỗ, cùng nội dung không đầy đủ.”

Ở khía cạnh này, các hệ thống tự động thiếu kiên nhẫn lại bị chính sự đơn giản của mình đánh lừa, vì phản hồi “200” được phép xem là dấu hiệu tải dữ liệu thành công, ngay cả khi kết quả tải chỉ là một bức tường CAPTCHA, tường phí hoặc trở ngại nào đó khác.

Bài nghiên cứu nêu ra bảy loại nội dung thường khiến phản hồi 200 trở nên phức tạp:

Bảy nhóm nội dung hoàn toàn không “ổn” trong phản hồi 200. Nguồn

Trong nghiên cứu, suốt ba ngày, 10.307 địa chỉ web được kiểm tra bằng cả một chương trình truy xuất web cơ bản lẫn một trình duyệt có khả năng tải JavaScript; các phản hồi được phân loại dựa trên nội dung được truy xuất, chứ không phải mã trạng thái HTTP.

Các nhóm phản hồi 202 ‘không thể sử dụng’ lớn nhất là những trang khung website trống và các trang lỗi hoặc trang thay thế, chiếm tổng cộng hơn hai phần ba số trường hợp thất bại.

Với những trang khung website trống, website có thể hiển thị các menu và thanh điều hướng nhưng để trống bài viết hoặc danh sách sản phẩm được yêu cầu; trong trường hợp sau, một trang không liên quan hoặc trang chủ có thể xuất hiện thay cho nội dung được yêu cầu. Tuy vậy, cả hai trường hợp đều có thể nhận cùng mã trạng thái HTTP 200 như một lần truy xuất thành công, cung cấp nội dung hữu ích và có thể sử dụng.

Để khắc phục vấn đề, bài báo khuyến nghị các công cụ truy xuất web báo cáo nội dung thực sự được truy xuất, thay vì chỉ dựa vào mã trạng thái HTTP, bởi những phép kiểm tra đơn giản nhằm phát hiện trang ngắn bất thường, chuyển hướng đáng ngờ và nội dung giống với các trang không tồn tại có thể nhận diện phần lớn trường hợp thất bại.

Sau đó, chỉ nên dùng các công cụ trình duyệt đòi hỏi nhiều tài nguyên hơn khi có dấu hiệu trang không tải đúng cách. Ngoài ra, các đánh giá AI có thể kiểm tra xem những nguồn được trích dẫn có thực sự chứa thông tin như mong đợi hay không, thay vì cho rằng phản hồi HTTP 200 đồng nghĩa với việc nội dung đã được truy xuất thành công.

Tác giả của công trình mới cũng lưu ý rằng các ‘phép suy nghiệm đơn giản’ có thể dễ dàng xác định khoảng 86% phản hồi không thể sử dụng bằng những kiểm tra cơ bản về độ dài trang, chuyển hướng và mức độ tương đồng với các trang không tồn tại:

So sánh các chiến lược truy xuất web: chỉ hiển thị những trang bị đánh dấu là đáng ngờ giúp thu được nhiều nội dung có thể sử dụng hơn một chút (81,4%) so với hiển thị mọi trang (80,3%), đồng thời giảm thời gian truy xuất trung bình mỗi trang từ 20,6 xuống còn 5,8 giây. 

Vì sao có quá nhiều phản hồi 200 sai lệch?

Trong nhiều năm qua, một số người đã tranh luận trong các cộng đồng nhà phát triển rằng lỗi 202 (‘Đã chấp nhận’) (‘Yêu cầu đã được chấp nhận nhưng chưa hoàn tất’) có thể giúp phân biệt các yêu cầu mang trạng thái 200 nhưng ‘thất bại’ này; tuy nhiên, trên thực tế, mã 202 không thể bao quát tất cả các trường hợp được nêu trong bài báo mới, và hiện cũng không có mã nào có thể làm được điều đó.

Dù bài báo không đi sâu vào vấn đề này, lý do vì sao chủ sở hữu tên miền cho phép xảy ra lỗi 200 có thể là chủ đề đáng để các nghiên cứu liên quan trong tương lai tìm hiểu thêm.

Một lý do có thể là mọi phản hồi không mang mã 200 về cơ bản đều là một dạng trang lỗi hoặc trở ngại, trong đó phổ biến nhất là lỗi 404 (‘không tìm thấy’) — khi nội dung cần tìm đơn giản là không tồn tại. Một số người tin rằng quá nhiều lỗi như vậy sẽ dẫn đến hình phạt về SEO (và có lẽ cả GEO), dù Google bác bỏ điều này.

Trên thực tế, Google xem các phản hồi 200 sai lệch là lỗi 404 ‘mềm’, và rõ ràng chúng có khả năng bị coi là vấn đề nghiêm trọng hơn lỗi 404 thông thường, bởi về bản chất đây là những kết quả ‘đánh lừa’, dù cố ý hay không.

Sự lệch lạc của trích dẫn

Nếu tất cả những điều này có vẻ quá câu nệ tiểu tiết, cần nhớ rằng dữ liệu được thu thập thường xuyên (hoặc được tìm cách thu thập) để huấn luyện AI có quy mô lên đến hàng petabyte. Nếu một phần năm dữ liệu đó không đáng tin cậy hoặc hoàn toàn mang tính đánh lừa, thì khó có thể xem nhẹ những hệ quả về sau như một dạng ‘sai lệch thứ yếu’; trái lại, các phản hồi sai lệch như vậy có thể ảnh hưởng đáng kể và tiêu cực đến phân bố dữ liệu trong các tập dữ liệu cũng như kết quả huấn luyện các mô hình AI bằng dữ liệu đó.

Chẳng hạn, một vấn đề đáng chú ý liên quan đến các phản hồi 200 sai lệch là hiện tượng ‘trích dẫn bị lệch’, trong đó câu trả lời do AI tạo ra không còn được trang web ban đầu được trích dẫn làm bằng chứng hỗ trợ; nói cách khác, trang đó có thể đã thay đổi, đoạn văn liên quan có thể đã bị xóa hoặc liên kết hiện có thể dẫn đến một nơi khác.

Nghiên cứu mới cho thấy tỷ lệ trích dẫn có vẻ bị lệch tăng từ 5,8% lên 21,9% khi mọi phản hồi HTTP 200 đều được chấp nhận là truy xuất thành công, bất kể chúng chứa nội dung gì.

Điều này có nghĩa là một nguồn có thể bị đánh giá nhầm là đã thay đổi, biến mất hoặc không còn hỗ trợ một khẳng định do AI tạo ra, chỉ vì thay vì tài liệu ban đầu, hệ thống đã truy xuất CAPTCHA, một trang trống hoặc một trở ngại khác.

Cứ khẳng định là được!

Vấn đề này cũng được thể hiện qua các thử nghiệm với những địa chỉ web không tồn tại được tạo ra có chủ đích. Khi gửi yêu cầu đến các đường dẫn ngẫu nhiên, tự tạo trên website, 13,1% số website phản hồi trả về trạng thái 200 (‘OK’), dù các trang được yêu cầu không tồn tại^†.

‘13,1% số website phản hồi với phép thử đường dẫn ngẫu nhiên đã trả về mã 200 (S1 10,5%, S2 13,3%, S3 17,3%, S4 13,7%, S5 13,1%). Theo cách thiết kế phép thử, mọi phản hồi như vậy đều là lỗi 404 mềm, nhưng không phải phản hồi nào cũng thể hiện điều đó.

“Trong một phân tích thăm dò 172 phản hồi soft 404, người gán nhãn phân loại 98 phản hồi là lỗi hoặc trang thay thế, 32 phản hồi là trang khung và 28 phản hồi là nội dung: trang chủ hoặc trang danh sách được hiển thị ở một đường dẫn ngẫu nhiên trông như một trang bình thường.”

Kết luận

Nếu vấn đề được nhận diện ở cấp độ cao hơn, IANA có thể tạo ra một mã trạng thái HTTP mới, phù hợp hơn, chẳng hạn như [X] (“Yêu cầu thành công, nhưng nội dung được yêu cầu không được cung cấp”). Dù mô tả này thực sự phản ánh điều đang xảy ra, để làm được vậy, phía máy chủ đương nhiên phải có mức độ hiểu biết về giao dịch cao đến khó tin.

Một số mã tương tự đã tồn tại, dù không mã nào thực sự phù hợp: 451 (“Không khả dụng vì lý do pháp lý”) mang nghĩa mơ hồ và khá đáng lo ngại (!); 206 (“Nội dung một phần”) chính xác về mặt kỹ thuật, nhưng được dùng cho dữ liệu (được tải về) không đầy đủ; còn mã 203 (“Thông tin không có thẩm quyền”), đến bất ngờ vì ít ai biết nó tồn tại, được tạo ra vào năm 1997 và chỉ liên quan gián tiếp đến trường hợp đang xét.

Có lẽ ứng viên gần nhất thực ra là mã 103 (“Gợi ý sớm”), một cái tên khó đoán, cho biết rằng chưa phải tất cả tài nguyên của URL đều được tải xong (dù rõ ràng cách hiểu này sẽ diễn giải sai nghiêm trọng mục đích của mã).

* Có tiêu đề “Khi 200 OK không phải là câu trả lời: Những lỗi truy xuất âm thầm khi tác nhân thu thập nội dung web”. Xin lưu ý rằng bài nghiên cứu này dường như được viết chủ yếu để máy đọc, có lẽ nhằm cho phép AI truy vấn, và bản thân nó không dễ đọc.

^† Tôi xin lỗi vì trích dẫn máy móc, nhưng như tôi đã lưu ý ở trên, toàn bộ bài nghiên cứu đều được viết theo cách này để máy có thể đọc được thay vì để con người diễn giải, dù vẫn chưa đến mức được trình bày dưới định dạng JSON.

Đăng lần đầu vào thứ Tư, ngày 4 tháng 11 năm 2026