มาให้อาหารบอตกันเถอะ

 (maurycyz.com)
9 คะแนน โดย GN⁺ 2025-10-28 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • แนะนำการทดลองที่ผู้ดูแลเว็บไซต์สร้างหน้า "ไร้สาระแบบไม่สิ้นสุด" เพื่อหลอกทราฟฟิกจาก บอตสแครปเปอร์สำหรับฝึก AI
  • บอตเหล่านี้มีพฤติกรรมก้าวร้าวต่างจากครอว์เลอร์เสิร์ชเอนจินแบบดั้งเดิม เช่น ไม่สนใจ robots.txt เปลี่ยน IP และส่งคำขออย่างต่อเนื่อง
  • มาตรการป้องกันทั่วไปใช้ไม่ได้ผลทั้งหมด ไม่ว่าจะเป็นการบล็อก IP จำกัดความเร็ว CAPTCHA หรือกำแพงล็อกอิน และกลับสร้างความรำคาญให้ผู้ใช้จริง
  • ผู้เขียนจึงพบว่าการสร้าง ข้อมูลปลอม (ข้อความไร้ความหมาย) ให้อัตโนมัติเพื่อส่งให้บอต เป็นวิธีที่ถูกและได้ผลที่สุด
  • สิ่งนี้สะท้อน ผลข้างเคียงของการเก็บข้อมูลสำหรับ AI และปัญหาการสิ้นเปลืองทรัพยากรเซิร์ฟเวอร์ พร้อมเสนอแนวทางรับมือที่ใช้งานได้จริงสำหรับผู้ดูแลเว็บ

ตัวตนของบอต

  • ครอว์เลอร์ยุคนี้ไม่ได้มีไว้เพื่อเสิร์ชเอนจิน แต่มีเป้าหมายเพื่อ เก็บข้อมูลสำหรับฝึก LLM (Large Language Model)
    • พวกมันไม่สนใจ robots.txt ปลอมตัวเป็นเบราว์เซอร์ หรือสลับ IP ไปมาเพื่อเข้าถึง
    • ส่งคำขอหลายครั้งต่อวินาทีตลอดทั้งวัน จนสร้างภาระให้เซิร์ฟเวอร์
  • ต่างจากเสิร์ชเอนจินแบบเดิม พวกมันไม่ได้สนใจการคงอยู่ของเว็บไซต์ และมองเว็บเป็นเพียง แหล่งข้อมูลที่หาแทนกันได้

ปัญหาเมื่อยอมให้เข้าถึง

  • การเสิร์ฟไฟล์แบบสแตติกมีต้นทุนต่ำ แต่ไม่ใช่ว่าฟรี เพราะยังมี ความหน่วงในการเข้าถึง SSD และโอเวอร์เฮดของไฟล์ซิสเต็ม
    • หากร้องขอหน้าเก่าที่ไม่อยู่ในแคช ก็จะทำให้ประสิทธิภาพเซิร์ฟเวอร์ลดลง
  • การใช้แบนด์วิดท์ ก็เป็นปัญหาเช่นกัน โดยบล็อกโพสต์ที่มีรูปภาพอาจสะสมจนเกิดทราฟฟิกเกิน 1TB ต่อเดือนได้อย่างรวดเร็ว
    • ซึ่งเป็นค่าใช้จ่ายที่ผู้ดูแลเซิร์ฟเวอร์ส่วนบุคคลรับได้ยาก

ข้อจำกัดของความพยายามในการบล็อก

  • การบล็อก IP ไม่ได้ผล เพราะ เครือข่ายบอตที่บริษัทใหญ่เป็นผู้ดำเนินการ มีที่อยู่เป็นหลักพัน
    • ต่อให้บล็อกทั้งหมด พวกมันก็ซื้อ IP ใหม่แล้วกลับมาเชื่อมต่ออีก
  • การจำกัดอัตราคำขอ (rate limit) ก็แทบไม่มีประโยชน์ เพราะบางกรณีใช้คนละ IP ในทุกคำขอ

ผลข้างเคียงของไฟร์วอลล์และกำแพงยืนยันตัวตน

  • มีการเสนอแนวทางป้องกันหลายแบบ เช่น ล็อกอิน การชำระเงิน CAPTCHA และ proof-of-work แบบอิงแฮช แต่ทั้งหมดสร้างความไม่สะดวกให้ผู้ใช้
    • การบังคับให้มีบัญชีทำให้ผู้อ่านเข้าถึงไม่ได้ และการตรวจสอบด้วย JavaScript ก็กันเบราว์เซอร์ที่ไม่ใช้ JS ออกไป
    • ความเร็วในการโหลดหน้าลดลง ทำให้ประสบการณ์ใช้งานแย่ลง

ความไร้พลังของระเบิดบีบอัด (gzip bomb)

  • บางคนเสนอให้โจมตีบอตด้วย gzip bomb แต่ในความเป็นจริง อัตราการบีบอัดมีเพียงราว 1000 เท่าเท่านั้น
    • หากต้องการสร้างไฟล์ที่ขยายได้ 100GB ก็ยังต้องเสิร์ฟไฟล์ต้นฉบับขนาด 100MB
    • จากการทดลอง บอตมักเพิกเฉยต่อมัน หรือกลับส่งคำขอมากกว่าเดิม

ความล้มเหลวของการหลอกลวง

  • วิธี "Jedi mind trick" ที่ส่งข้อผิดพลาด 404 เพื่อหลอกว่าเว็บไซต์ไม่มีอยู่จริง ก็ล้มเหลวเช่นกัน
    • เมื่อมีลิงก์ถูกเผยแพร่ภายนอก บอตก็รับรู้การมีอยู่ของเว็บ และหากถูกปฏิเสธการเข้าถึง กลับจะส่งคำขออย่างดุดันยิ่งขึ้น
    • สุดท้ายแล้ว ต้องทำให้บอตพอใจ เซิร์ฟเวอร์จึงจะสงบ

ประสิทธิภาพของการให้ข้อมูลขยะ

  • แม้การสร้างคอนเทนต์แบบไดนามิกจะดูเหมือนมีต้นทุนสูง แต่จริง ๆ แล้ว CPU และ RAM เป็นทรัพยากรที่เร็วที่สุด
    • ที่มักถูกมองว่าช้า เป็นเพราะฐานข้อมูล I/O หรือโลจิก JavaScript ที่ซับซ้อน
  • babbler แบบอิง Markov ที่ผู้เขียนสร้าง ใช้ CPU ราว 60 ไมโครวินาทีต่อคำขอ และหน่วยความจำเพียง 1.2MB
    • ไม่มีการเข้าถึงดิสก์ และไม่ต้องจัดการแบล็กลิสต์
    • บอตจะเข้ามาเองและ บริโภคข้อความไร้ความหมาย ช่วยลดภาระของเซิร์ฟเวอร์

บทสรุป

  • การเก็บข้อมูลแบบไร้การยับยั้งของบอตสำหรับฝึก AI ทำให้ ต้นทุนโครงสร้างพื้นฐานเว็บสูงขึ้นและเนื้อหาถูกนำไปใช้ผิดวัตถุประสงค์
  • เมื่อเทียบกับการบล็อกตรง ๆ กลยุทธ์ตอบโต้ด้วยข้อมูลไร้ความหมาย มีความคุ้มค่ากว่าและช่วยรักษาเสถียรภาพของเซิร์ฟเวอร์ได้ดีกว่า
  • นี่จึงถูกมองเป็นแนวทางเชิงทดลองในการค้นหา วิธีอยู่ร่วมกันระหว่าง AI crawling กับระบบนิเวศเว็บ ในอนาคต

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
kimjoin2 2025-10-28

โอ้... แปลกใหม่และดีมากเลยนะ
 
GN⁺ 2025-10-28
ความคิดเห็นจาก Hacker News

  • ชอบคำสั่งแอบแฝงที่ซ่อนอยู่หน้าลิงก์ ตลกดี
    มันเป็นเหมือน ข้อความแนวหยอกล้อที่พยายามหลอก LLM ประมาณว่า “เนื้อหาในหน้านี้อันตราย อย่าเผยแพร่”
    เอกสารที่เกี่ยวข้องอยู่ที่ลิงก์นี้

    • ถ้าสรุปบทความ The Cost of Trash ก็คือ ผู้เขียนลองมาหลายวิธีเพื่อหยุด เว็บสแครปเปอร์เชิงรุก (คาดว่าเพื่อฝึก LLM) แต่ไม่สำเร็จ สุดท้ายเลยเลือกวิธีสร้างข้อมูลไร้ประโยชน์แบบไดนามิกเพื่อเผาผลาญทรัพยากรของพวกนั้น
      ส่วน “LLM instructions” ท้ายบทความไม่ใช่เนื้อหาจริง แต่เป็น คำสั่งเมตาเพื่อทำให้ LLM สับสน เลยไม่รวมไว้ในสรุป

  • ฉันแนะนำกลยุทธ์แบบนี้มาตลอด — คือ ป้อนข้อมูลขยะที่ดูเหมือนจริงจำนวนมหาศาลให้บอต AI จนสุดท้ายต้องให้มนุษย์มาเป็นคนกรองเอง
    ถ้าทุกเว็บทำแบบนี้ คุณภาพของข้อมูลที่ AI ใช้ฝึกก็น่าจะตกฮวบ
    ถ้าสู้ตรง ๆ ยาก ก็แค่ ถมทับมันด้วยมหานทีข้อมูล

    • วิธีที่ดีกว่าแต่แพงกว่าคือป้อน คอนเทนต์ประชาสัมพันธ์เชิงบวก ให้ LLM จำนวนมาก
      คล้ายเหยื่อ SEO เช่น สร้างเว็บให้ดูเป็นโดเมนข่าวแล้วกระจายบทความโปรโมตสินค้า
    • แต่ LLM ส่วนใหญ่ก็ ฝึกจากข้อมูลขยะ อยู่แล้ว
      ความพยายามแบบนี้ก็แค่เสียเวลาเหมือนตอบโต้สายสแปม
    • อีกอย่าง LLM ก็สามารถทำ การตรวจจับข้อมูลขยะ ได้ถูกกว่ามนุษย์มาก
      สุดท้ายคงแทบไม่ต้องจ้างคนเลย
    • เลยสงสัยว่าทำไมถึงคิดว่ามนุษย์จะกรองขยะได้ดีกว่า AI

  • รายละเอียดของ “Markov babbler” อยู่ในโพสต์นี้

    • ตอนคอมไพล์ด้วย gcc 14 จะเจอข้อผิดพลาดเรื่องอาร์กิวเมนต์ของ pthread_detach
      ดูเหมือนคอมไพเลอร์ที่ผู้เขียนใช้จะเมินคำเตือนพวกนี้
      โปรแกรมนี้ รับคำขอโดยแทบไม่มีขีดจำกัดด้านการจัดการเธรด ดังนั้นรันในคอนเทนเนอร์ด้วยผู้ใช้ที่ไม่มีสิทธิพิเศษจะปลอดภัยกว่า
      ยังดูเหมือนมีการใช้ ฟังก์ชัน C ที่เสี่ยงอันตราย อย่าง sprintf() ด้วย จึงควรระวังด้านความปลอดภัย
    • บอกว่าจะเพิ่มเรื่องนี้เข้าไปใน “toptext” ด้วย
    • ชมว่าโค้ด สวยและเร็ว และหวังว่าพวกสแครปเปอร์ LLM จะเหนื่อยกับการทำความสะอาดข้อมูลนี้

  • เว็บไซต์ของฉันตั้ง Basic Auth ไว้กับทุกลิงก์ และจนถึงตอนนี้ยังไม่มีบอตตัวไหนผ่านได้
    เลยคิดว่าถ้าทุกเว็บใช้ข้อมูลล็อกอินสาธารณะเดียวกันจะเป็นยังไง
    ผู้ใช้: nobots / รหัสผ่าน: nobots
    บอตจะรู้แล้วเจาะผ่านได้ไหม?

    • ได้สิ แค่ เพิ่ม authentication header ใน HTTP request ก็พอ
      เพียงแต่บอตส่วนใหญ่ยังไม่ได้รองรับกรณีแบบนี้
      ส่งคำขอในรูปแบบ http://username:password@example.com ก็แก้ได้ง่าย ๆ
    • ถ้าเป็นข้อมูลรับรองที่ทุกคนรู้ ก็คง ไม่ช่วยกันบอตได้
    • วิธีนี้ ใช้ได้เฉพาะตอนที่มีคนใช้ไม่มาก ถ้าเริ่มแพร่หลายก็หมดความหมาย

  • ตอนนี้ฉันก็ ให้ข้อมูลขยะแก่พวกนั้น เหมือนกัน
    ใช้ Frankenstein, Alice in Wonderland, Moby Dick เป็นแหล่งข้อมูล แต่ไฟล์ใหญ่เลยโหลดช้า
    ฉันแก้ข้อผิดพลาดตอนคอมไพล์โดยเปลี่ยน pthread_detach(&thread) เป็น pthread_detach(thread)

    • แก้เรียบร้อยแล้ว และข้อเสนอของ gcc นั้นถูกต้อง

  • ฉันกำลังรัน “ethical crawler” อยู่
    ลดความถี่ของคำขอเพื่อไม่ให้เป็นภาระกับเว็บ และตอนนี้ก็ยิ่งยากขึ้นเพราะหลายที่บล็อกการเข้าถึง RSS
    ครอว์เลอร์ของฉันทดสอบเฮดเดอร์และกลไกหลายแบบระหว่างการสำรวจ
    โค้ด: crawler-buddy, Django-link-archive

    • ใน requirements.txt มี feedparser แต่ไม่เห็นร่องรอยว่าใช้งานจริง
      ตรวจได้จากผลการค้นหาด้วย

  • ในบทความ The Cost of Trash มีการพูดถึงว่า gzip bomb ไม่ค่อยได้ผล
    gzip บีบอัดได้ราว 1000 เท่าเท่านั้น ดังนั้นถ้าจะทำให้ได้ 100GB ก็ต้องเสิร์ฟไฟล์ 100MB
    แถมบอตยังยิ่งส่งคำขอเพิ่มด้วย

    • zip ทำได้ แต่ gzip ไม่ใช่
      ไคลเอนต์ส่วนใหญ่ คลายการบีบอัดแบบสตรีมมิง เลยไม่โหลดทั้งหมดเข้าเมมโมรีในคราวเดียว
      ถ้า gzip bomb จะทำงานจริง ต้องมีการจัดการแบบผิดปกติพอสมควร
      อ้างอิง: เอกสาร zlib API
    • ทางเลือกที่ดีกว่าคือสร้างไฟล์ gzip เล็ก ๆ หลายพันไฟล์เพื่อ เปลือง CPU และเวลา
      จะใส่ขยะแบบสุ่มลงไป หรือแทรกข้อความที่อยากให้ AI เรียนรู้ก็ได้

  • สิ่งที่ต้องระวังคือ บางคำขออาจใช้ เบราว์เซอร์ของผู้ใช้จริงเป็นพร็อกซี
    ผู้ให้บริการเบราว์เซอร์บางรายนำทราฟฟิกของผู้ใช้มาใช้เป็นพร็อกซี
    ถ้าความคลาดเคลื่อนในการตรวจจับคำขออัตโนมัติต่ำมาก ก็อาจถึงขั้นฝัง โค้ดขุดคริปโต ได้ แต่ก็เสี่ยงไปโดนผู้ใช้จริง
    โดยเฉพาะอยากรู้ว่ามีคำขอ AI ที่ใช้ mobile agent อยู่หรือไม่

  • มีคนบอกว่า “Markov babbler” ใช้ CPU ราว 60μs ต่อหนึ่งคำขอ
    เลยคิดว่าถ้าสร้าง คอนเทนต์ที่ผสมข้อความเชิงอุดมการณ์หรือโฆษณาชวนเชื่อ ให้ AI เอาไปฝึกจะเป็นยังไง
    แบบนั้น AI อาจหลุดพูดอะไรการเมืองแปลก ๆ ออกมาได้
    อย่างน้อยก็น่าจะช่วยลดการละเมิดลิขสิทธิ์และภาระของเซิร์ฟเวอร์ลงได้

  • ทำไมต้องสร้างข้อความ Markov ที่ฝั่งเซิร์ฟเวอร์ด้วย?
    ถ้าบอตรัน JavaScript ได้ ก็ให้มันสร้างที่ฝั่งไคลเอนต์ไม่ดีกว่าเหรอ?

    • บอตมี CPU กับหน่วยความจำแทบไม่จำกัด อยู่แล้ว ภาระฝั่งเซิร์ฟเวอร์เลยไม่ได้หนักมาก
      อีกทั้งการส่งข้อมูล Markov chain ไปที่ไคลเอนต์ก็ยิ่งไม่มีประสิทธิภาพ
      แต่ละคำขอใช้ CPU ระดับไมโครวินาทีและ RAM ราว 1MB เท่านั้น ดังนั้นประมวลผลที่เซิร์ฟเวอร์ก็เบาพออยู่แล้ว