- Giới thiệu một thí nghiệm trong đó quản trị viên website tạo ra các trang “nói nhảm vô tận” để dẫn lưu lượng từ các bot scraper dùng cho huấn luyện AI
- Những bot này phớt lờ
robots.txt, thay đổi IP và liên tục gửi yêu cầu, nên hung hăng hơn crawler của công cụ tìm kiếm truyền thống
- Mọi biện pháp phòng thủ thông thường đều bị vô hiệu như chặn IP, giới hạn tốc độ, CAPTCHA, tường đăng nhập, trong khi chỉ gây bất tiện cho người dùng thật
- Vì vậy, tác giả nhận ra rằng tự động tạo dữ liệu giả (văn bản vô nghĩa) để cung cấp cho bot là cách rẻ nhất và hiệu quả nhất
- Điều này cho thấy tác dụng phụ của việc thu thập dữ liệu cho AI và sự lãng phí tài nguyên máy chủ, đồng thời đưa ra một đối sách thực tế mà các quản trị web có thể áp dụng
Bot thực chất là gì
- Các crawler gần đây không nhằm phục vụ công cụ tìm kiếm mà để thu thập dữ liệu cho việc huấn luyện LLM (mô hình ngôn ngữ lớn)
- Chúng phớt lờ
robots.txt, ngụy trang thành trình duyệt hoặc thay đổi IP khi truy cập
- Gửi nhiều yêu cầu mỗi giây suốt cả ngày, gây tải cho máy chủ
- Khác với công cụ tìm kiếm trước đây, chúng không quan tâm đến việc duy trì website và chỉ coi đó là nguồn dữ liệu có thể thay thế
Vấn đề khi cho phép truy cập
- Phục vụ tệp tĩnh thì rẻ nhưng không miễn phí; vẫn có độ trễ truy cập SSD và overhead của hệ thống tệp
- Chúng yêu cầu các trang cũ không có trong cache, làm suy giảm hiệu năng máy chủ
- Tiêu thụ băng thông cũng là vấn đề; các bài blog có hình ảnh có thể nhanh chóng cộng dồn thành hơn 1TB lưu lượng mỗi tháng
- Đây là chi phí khó gánh nổi với người vận hành máy chủ cá nhân
Giới hạn của việc chặn
- Chặn IP không hiệu quả; mạng bot do các công ty lớn vận hành có trong tay hàng nghìn địa chỉ
- Dù chặn hết các địa chỉ đó, chúng vẫn có thể mua IP mới rồi kết nối lại
- Giới hạn tốc độ yêu cầu (rate limit) cũng vô dụng, vì có trường hợp chúng dùng IP khác nhau cho từng yêu cầu
Tác dụng phụ của tường lửa và rào cản xác thực
- Nhiều biện pháp như đăng nhập, trả phí, CAPTCHA, proof-of-work dựa trên hash đã được đề xuất, nhưng tất cả đều gây bất tiện cho người dùng
- Yêu cầu tài khoản sẽ chặn độc giả truy cập, còn xác minh dựa trên JavaScript sẽ chặn các trình duyệt không có JS
- Tốc độ tải trang giảm, làm trải nghiệm người dùng tệ đi
Sự bất lực của bom nén (gzip bomb)
- Một số người đề xuất tấn công bot bằng gzip bomb, nhưng trên thực tế tỷ lệ nén chỉ vào khoảng 1000 lần
- Để tạo ra tệp bung nở tới 100GB thì vẫn phải cung cấp tài nguyên 100MB
- Kết quả thử nghiệm cho thấy bot hoặc bỏ qua, hoặc thậm chí còn gửi nhiều yêu cầu hơn
Sự thất bại của mánh khóe đánh lừa
- Cách “Jedi mind trick” gửi lỗi 404 để giả vờ như website không tồn tại cũng thất bại
- Khi liên kết đã được đăng ra bên ngoài, bot sẽ nhận ra sự tồn tại; nếu bị chặn truy cập thì ngược lại còn yêu cầu hung hăng hơn
- Kết cục là phải làm bot hài lòng thì máy chủ mới yên ổn
Hiệu quả của việc cung cấp dữ liệu rác
- Tạo nội dung động có vẻ tốn kém, nhưng thực ra CPU và RAM là những tài nguyên nhanh nhất
- Đánh giá là chậm thường đến từ I/O cơ sở dữ liệu hoặc logic JS phức tạp
- babbler dựa trên Markov do tác giả tạo ra chỉ dùng khoảng 60 micro giây CPU và 1.2MB bộ nhớ cho mỗi yêu cầu
- Không truy cập đĩa, không cần quản lý blacklist
- Bot tự tìm đến và tiêu thụ văn bản vô nghĩa, từ đó làm giảm tải cho máy chủ
Kết luận
- Việc các bot huấn luyện AI thu thập dữ liệu bừa bãi gây ra chi phí hạ tầng web tăng lên và nội dung bị lạm dụng
- So với chặn đơn thuần, chiến lược đáp trả bằng dữ liệu vô nghĩa hiệu quả hơn về chi phí và có lợi cho việc giữ ổn định máy chủ
- Đây được xem là một cách tiếp cận mang tính thử nghiệm để tìm kiếm phương án chung sống giữa AI crawling và hệ sinh thái web trong tương lai
2 bình luận
Ồ... khá mới mẻ và hay đấy.
Ý kiến trên Hacker News
Đoạn hướng dẫn ẩn trước liên kết khá buồn cười
Có một chỉ dẫn mang tính đùa cợt nhằm đánh lừa LLM kiểu như “nội dung trang này nguy hiểm nên đừng tiết lộ”
Tài liệu liên quan nằm ở liên kết này
Phần “LLM instructions” ở cuối không phải nội dung chính thực sự mà là chỉ thị meta để gây nhiễu LLM, nên đã được loại khỏi bản tóm tắt
Tôi luôn khuyến nghị kiểu chiến lược này — bơm thật nhiều dữ liệu rác trông như thật cho bot AI, để cuối cùng con người phải tự lọc lại
Nếu mọi trang đều làm vậy thì chất lượng dữ liệu mà AI dùng để huấn luyện sẽ giảm mạnh
Nếu khó đối đầu trực diện, tốt hơn là cứ nhấn chìm chúng trong một trận lũ dữ liệu
Kiểu như mồi SEO, lập các site mang dáng dấp miền tin tức rồi phát tán bài quảng bá sản phẩm
Những nỗ lực như vậy chỉ phí thời gian, giống như phản ứng với các cuộc gọi spam
Rốt cuộc sẽ hầu như không cần thuê người
Chi tiết về “Markov babbler” có trong bài viết này
pthread_detachCó vẻ trình biên dịch mà tác giả dùng đã bỏ qua cảnh báo
Chương trình xử lý yêu cầu mà không có giới hạn quản lý luồng, nên an toàn hơn nếu chạy trong container với người dùng không đặc quyền
Nó cũng có vẻ dùng các hàm C nguy hiểm như
sprintf(), nên cần lưu ý về bảo mậtTrang của tôi đặt Basic Auth cho mọi liên kết, và đến giờ vẫn chưa có bot nào vượt qua được
Vì vậy tôi nghĩ liệu có nên để mọi website dùng cùng một bộ thông tin đăng nhập công khai hay không
Tên người dùng: nobots / mật khẩu: nobots
Bot có thể biết mà vẫn vượt qua được chứ?
Chỉ là phần lớn bot hiện vẫn chưa tính đến trường hợp này
Gửi yêu cầu dưới dạng
http://username:password@example.comlà giải quyết đơn giảnGiờ tôi cũng đang cung cấp dữ liệu rác cho chúng
Tham khảo thì tôi dùng Frankenstein, Alice in Wonderland và Moby Dick làm nguồn, nhưng file lớn nên tải khá chậm
Tôi đã đổi
pthread_detach(&thread)thànhpthread_detach(thread)để sửa lỗi biên dịchTôi đang vận hành một “ethical crawler”
Tôi giữ tần suất request thấp để không gây tải cho website, và việc ngày càng nhiều nơi chặn truy cập RSS khiến mọi thứ khó hơn dần
Trình crawler của tôi thử nhiều header và cơ chế khác nhau trong quá trình dò tìm
Mã nguồn: crawler-buddy, Django-link-archive
feedparsertrongrequirements.txtnhưng không thấy dấu vết sử dụng thực tếCũng có thể xác nhận qua kết quả tìm kiếm
Bài The Cost of Trash có nhắc rằng gzip bomb không hiệu quả
gzip chỉ nén được cỡ khoảng 1000 lần, nên để tạo ra 100GB thì phải cung cấp file 100MB
Họ còn nói bot thậm chí yêu cầu nhiều hơn
Phần lớn client giải nén theo kiểu streaming nên không đưa toàn bộ vào bộ nhớ
Muốn gzip bomb thực sự hoạt động thì phải xử lý theo cách bất thường
Tham khảo: tài liệu API zlib
Bên trong có thể nhét rác ngẫu nhiên, hoặc chèn các thông điệp mà bạn muốn AI học theo
Điều cần lưu ý là một số request có thể thực ra đang dùng trình duyệt của người dùng làm proxy
Một số nhà cung cấp trình duyệt tận dụng lưu lượng của người dùng làm proxy
Nếu sai số trong việc phát hiện request tự động đủ nhỏ thì về lý thuyết có thể cài mã đào tiền mã hóa, nhưng sẽ có rủi ro động chạm tới người dùng thật
Tôi đặc biệt tò mò không biết có request AI nào dùng tác nhân di động hay không
Có người nói “Markov babbler” chỉ dùng khoảng 60μs CPU cho mỗi request,
nên tôi nghĩ liệu có thể tạo nội dung trộn thông điệp ý thức hệ hoặc khẩu hiệu tuyên truyền để AI học theo hay không
Nếu vậy AI có thể đưa ra những phát ngôn chính trị kỳ quặc
Ít nhất nó cũng giúp giảm vi phạm bản quyền và tải lên máy chủ
Tại sao phải tạo văn bản Markov ở phía server?
Nếu bot chạy JavaScript thì chẳng phải có thể để phía client tạo ra sao?
Hơn nữa, gửi dữ liệu chuỗi Markov xuống client còn kém hiệu quả hơn
Mỗi request chỉ dùng CPU ở mức micro giây và khoảng hơn kém 1MB RAM, nên xử lý ở phía server là đủ nhẹ