20 เปอร์เซ็นต์ของคำตอบจากเว็บไซต์ที่ AI ได้รับว่า “โอเค” นั้นไม่โอเค

การทดลองล่าสุดของฉันเกี่ยวกับการดึงข้อมูลจากเว็บโดยใช้ AI ช่วย ทำให้เห็นชัดว่าเว็บกำลังถูกจำกัดการเข้าถึงมากขึ้นเรื่อย ๆ สาเหตุสำคัญที่ทำให้เกิดการถอยกลับเช่นนี้คือ การเติบโตอย่างน่าตกใจของการดึงข้อมูลจากเว็บด้วย AI ซึ่งมีความต้องการข้อมูลใหม่อย่างไม่ลดละ จนอาจทำให้โดเมนต่าง ๆ ใช้งานไม่ได้

นี่เป็นข้ออ้างอันดีให้โดเมนต่าง ๆ ทำสิ่งที่หลายแห่งอยากทำมานาน นั่นคือเปิดให้เข้าถึงเนื้อหาได้เฉพาะผู้ใช้ที่เข้าสู่ระบบเท่านั้น (แม้ตามปกติแล้ว Googlebot มักได้รับการยกเว้น) Facebook ดำเนินนโยบายนี้จนครบถ้วนหลังทยอยนำมาใช้ในปี 2023 และ Twitter/X ก็ทำเช่นเดียวกันในปีเดียวกัน ส่วน Reddit จะเริ่มใช้นโยบายนี้ในช่วงปลายเดือนนี้

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

ในด้านอื่น ๆ มาตรการที่มุ่งป้องกันบอตโดยตรง (แทนที่จะมุ่งให้ผู้ใช้ลงทะเบียน) เพิ่มขึ้นมากกว่า 58% เมื่อเทียบกับปีก่อนหน้า ตามข้อมูลของ Cloudflare ขณะที่กิจกรรมของบอตที่เพิ่มสูงขึ้นอย่างต่อเนื่องย่อมทำให้เว็บไซต์ต่าง ๆ ตรวจสอบอย่างเข้มงวดต่อที่อยู่ VPN และพร็อกซี ซึ่งอาจกีดกันผู้ใช้ที่ชอบด้วยกฎหมายไม่ให้เข้าถึงเว็บไซต์ รวมถึงปิดกั้นการรับส่งข้อมูลที่ “เป็นอันตราย” ด้วย

สิ่งที่เห็นได้จากประสบการณ์ส่วนตัวคือ ฉันพบกับคำตอบที่ “ปิดกั้น” หรือด่านทดสอบมากขึ้นเรื่อย ๆ ถึงขั้นที่อาจเลิกเข้าเว็บไซต์ที่เริ่มแสดงสิ่งเหล่านี้ และเมื่อพบว่า CAPTCHA ทำให้ผู้ใช้และลูกค้าที่อาจสนใจไม่อยากใช้บริการ ก็พอจะนึกภาพได้ว่าเจ้าของโดเมนต้องเผชิญแรงกดดันเพียงใด จึงตัดสินใจนำมาตรการเหล่านี้มาใช้ทั้งที่รู้ว่ามีข้อเสียเช่นนั้น

แคปชาจจาก archive.is ซึ่งเป็นหนึ่งในเว็บไซต์จำนวนมากที่ใช้ด่านทดสอบ โดยมักนำมาใช้เพื่อตอบสนองต่อคำขออัตโนมัติที่มากเกินไป แทนที่จะเป็นคำขอจากมนุษย์

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

เนื่องจากโปรแกรมรวบรวมข้อมูลของ AI ต้องทำงานในวงกว้าง จึงมักใช้ Chrome แบบ “ไร้ส่วนติดต่อผู้ใช้” ภายใต้เฟรมเวิร์ก Playwright ทุกวันนี้ เว็บไซต์จำนวนมากขึ้นเรื่อย ๆ จะตอบกลับด้วยข้อผิดพลาด 403 (“ไม่ได้รับอนุญาต”) เมื่อใช้วิธีนี้ (กล่าวคือ โฮสต์รู้ว่าคุณเป็นการรับส่งข้อมูลอัตโนมัติ แล้วก็ไล่คุณไปให้พ้น):

การติดตั้ง changedetection.io ในเครื่องพยายามตรวจสอบเว็บไซต์เป็นระยะ แต่เว็บไซต์ไม่ยอมรับเบราว์เซอร์ที่เฟรมเวิร์กใช้และตรวจพบ จึงตอบกลับด้วยสถานะ 403 (“ไม่ได้รับอนุญาต”)

สิ่งที่ต้องการคือคำตอบจากไคลเอนต์เป็น “200” (“โอเค”) แม้จะต้องจ่ายเงินก้อนโตให้กับเครือข่ายพร็อกซีที่ใช้ที่อยู่ IP บ้าน โดยร่วมมือกับกลเม็ดพรางตัวอื่น ๆ ที่หลากหลายและไม่ใช่มนุษย์ก็ตาม

ไม่มีคำตอบใดดีไปกว่ารหัส 200 กล่าวคือ ไม่มีรหัสตอบกลับจากไคลเอนต์ใดที่ส่งสัญญาณเชิงบวกได้ชัดเจนกว่านี้ และรหัสนี้ก็ไม่ได้กำกวม ไม่เคยหมายถึง“เกือบจะโอเค” หรือ“เดี๋ยวก็จะโอเค” หรือ“กำลังจะโอเคขึ้น” แต่หมายถึง“โอเค!” หากไม่โอเค ก็ไม่ใช่คำตอบรหัส 200

สวัสดี! ไปให้พ้น

อย่างไรก็ตาม บทความวิจัยฉบับใหม่ระบุว่า การขาดความละเอียดในการแยกแยะเช่นนี้อาจทำให้ชุดข้อมูล AI การประมาณค่าทางสถิติ และการรายงานสถานะว่า “ดี” บิดเบือนไปอย่างมาก ทั้งที่ความเป็นจริงไม่เป็นเช่นนั้น

งานวิจัย* ประเมินว่าคำตอบในกลุ่มสถานะ 200 ราวหนึ่งในห้าไม่มีเนื้อหาของหน้าเว็บที่นำไปใช้ได้เลย แต่กลับแสดงเพียงโครงหน้าเว็บไซต์เปล่า ๆ ด่าน CAPTCHA ข้อจำกัดการเข้าถึง หรือหน้าเว็บอื่นที่นำมาแสดงแทน

บทความวิจัยระบุว่า:

“หน้าเว็บ 20.9% ที่ไคลเอนต์แบบสแตติกได้รับพร้อมสถานะ 200 ไม่มีเนื้อหาหลักของหน้าเว็บ ได้แก่ โครงหน้าแอป ด่านตรวจสอบบอต หน้าบล็อกการเข้าถึง หน้าแสดงข้อผิดพลาดและหน้าแทนที่ รวมถึงเนื้อหาที่แสดงเพียงบางส่วน”

ในแง่นี้ ระบบอัตโนมัติที่ใจร้อนกลับสะดุดเพราะความเรียบง่ายของตัวเอง เนื่องจากสามารถตีความคำตอบ “200” ว่าหมายถึงการดึงข้อมูลสำเร็จได้ แม้ผลที่ได้จะเป็นเพียงกำแพง CAPTCHA กำแพงชำระเงิน หรืออุปสรรคอื่น ๆ ก็ตาม

บทความวิจัยแจกแจงเนื้อหา 7 ประเภทที่มักทำให้คำตอบสถานะ 200 ซับซ้อนขึ้นอยู่บ่อยครั้ง ดังนี้:

เนื้อหา 7 ประเภทที่ห่างไกลจากคำว่า “โอเค” ในคำตอบสถานะ 200 ที่มา

ในการศึกษานี้ ตลอดระยะเวลาสามวัน มีการทดสอบที่อยู่เว็บ 10,307 รายการด้วยทั้งโปรแกรมดึงข้อมูลจากเว็บพื้นฐานและเบราว์เซอร์ที่สามารถโหลด JavaScript ได้ โดยจำแนกผลตอบกลับตามเนื้อหาที่ดึงมาได้ ไม่ใช่ตามรหัสสถานะ HTTP

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

สำหรับหน้าเว็บเปล่าที่มีเพียงโครง เว็บไซต์อาจแสดงเมนูและแถบนำทาง แต่ปล่อยให้บทความหรือรายการสินค้าที่ร้องขอว่างเปล่า ส่วนในกรณีหลัง อาจแสดงหน้าอื่นที่ไม่เกี่ยวข้องหรือหน้าแรกแทนเนื้อหาที่ร้องขอ—แต่ทั้งสองกรณีก็อาจได้รับสถานะ HTTP 200 เช่นเดียวกับการดึงข้อมูลสำเร็จที่ได้เนื้อหาซึ่งนำไปใช้ได้และเป็นประโยชน์

เพื่อแก้ปัญหานี้ งานวิจัยเสนอให้เครื่องมือดึงข้อมูลจากเว็บรายงานว่าดึงข้อมูลอะไรมาได้จริง แทนที่จะอาศัยรหัสสถานะ HTTP เนื่องจากการตรวจสอบง่าย ๆ เช่น การตรวจหาหน้าที่สั้นผิดปกติ การเปลี่ยนเส้นทางที่น่าสงสัย และเนื้อหาที่คล้ายกับหน้าเว็บที่ไม่มีอยู่จริง อาจช่วยระบุผลลัพธ์ที่ล้มเหลวได้เกือบทั้งหมด

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

ผู้เขียนงานวิจัยชิ้นใหม่นี้ยังระบุด้วยว่า “วิธีตรวจจับแบบง่าย ๆ” สามารถระบุผลตอบกลับที่ใช้การไม่ได้ได้ราว 86% อย่างไม่ยากเย็น โดยตรวจสอบความยาวของหน้า การเปลี่ยนเส้นทาง และความคล้ายคลึงกับหน้าเว็บที่ไม่มีอยู่จริงด้วยวิธีพื้นฐาน:

เปรียบเทียบกลยุทธ์การดึงข้อมูลจากเว็บ: การเรนเดอร์เฉพาะหน้าที่ถูกระบุว่าน่าสงสัยช่วยให้กู้คืนเนื้อหาที่นำไปใช้ได้มากกว่าเล็กน้อย (81.4%) เมื่อเทียบกับการเรนเดอร์ทุกหน้า (80.3%) ขณะเดียวกันก็ลดเวลาเฉลี่ยในการดึงข้อมูลต่อหน้าจาก 20.6 วินาทีเหลือ 5.8 วินาที 

เหตุใดจึงมีผลตอบกลับ 200 ที่ผิดพลาดมากมาย?

ในชุมชนนักพัฒนามีข้อถกเถียงกันอยู่บ้างตลอดหลายปีที่ผ่านมาว่า ข้อผิดพลาด202 (“Accepted” หรือ “ยอมรับแล้ว”) (“คำขอได้รับการยอมรับแล้ว แต่ยังดำเนินการไม่เสร็จ”) อาจช่วยแยกแยะคำขอที่ล้มเหลวแต่ได้สถานะ 200 เหล่านี้ได้ แต่ในความเป็นจริง 202 ไม่อาจครอบคลุมทุกกรณีที่ระบุไว้ในงานวิจัยชิ้นใหม่นี้ และก็ไม่มีรหัสที่มีอยู่ในปัจจุบันใดทำได้เช่นกัน

แม้งานวิจัยจะไม่ได้ลงรายละเอียดเรื่องนี้มากนัก แต่เหตุผลที่เจ้าของโดเมนยอมให้เกิดข้อผิดพลาด 200 อาจเป็นประเด็นที่ควรศึกษาเพิ่มเติมในงานวิจัยที่เกี่ยวข้องในอนาคต

เหตุผลหนึ่งอาจเป็นเพราะสิ่งใดก็ตามที่ไม่ใช่ 200 มักจะเป็นหน้าแสดงข้อผิดพลาดหรือสิ่งกีดขวางบางอย่าง ซึ่งรวมถึงข้อผิดพลาดที่พบได้บ่อยที่สุดอย่าง404 (“ไม่พบ”) ที่หมายถึงไม่มีเนื้อหาปลายทางอยู่เลย ผู้ใช้บางส่วนเชื่อว่าข้อผิดพลาดลักษณะนี้ที่มีจำนวนมากเกินไปจะส่งผลให้ถูกลงโทษด้าน SEO (และสันนิษฐานว่าอาจรวมถึงGEOด้วย) แต่ Googleปฏิเสธข้อกล่าวอ้างนี้

ที่จริงแล้ว Google มองข้อผิดพลาด 200 ที่เกิดขึ้นผิดพลาดว่าเป็น404 แบบ “soft” และเห็นได้ชัดว่ามีแนวโน้มจะถูกมองว่าเป็นปัญหามากกว่าข้อผิดพลาด 404 ทั่วไป เพราะโดยพื้นฐานแล้วผลลัพธ์เหล่านี้เป็นการตอบกลับที่ “ชวนให้เข้าใจผิด” ไม่ว่าจะเกิดขึ้นโดยตั้งใจหรือไม่ก็ตาม

การคลาดเคลื่อนของการอ้างอิง

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

ตัวอย่างหนึ่งของปัญหาสำคัญที่เกี่ยวข้องกับผลตอบกลับ 200 ที่ผิดพลาดคือ“การคลาดเคลื่อนของการอ้างอิง” ซึ่งเกิดขึ้นเมื่อคำตอบที่สร้างโดย AI ไม่ได้รับการสนับสนุนจากหน้าเว็บที่เดิมอ้างถึงเป็นหลักฐานอีกต่อไป กล่าวคือ หน้าเว็บอาจเปลี่ยนแปลง ข้อความที่เกี่ยวข้องอาจถูกลบออก หรือลิงก์อาจนำไปยังที่อื่นแล้ว

งานวิจัยชิ้นใหม่นี้พบว่า การคลาดเคลื่อนของการอ้างอิงที่ดูเหมือนเกิดขึ้นเพิ่มจาก 5.8% เป็น 21.9% เมื่อถือว่าผลตอบกลับ HTTP 200 ทั้งหมดเป็นการดึงข้อมูลที่สำเร็จไม่ว่าจะมีเนื้อหาอะไรอยู่ในนั้น

หมายความว่าแหล่งข้อมูลหนึ่งอาจถูกตัดสินอย่างผิดพลาดว่าเปลี่ยนแปลงไปแล้ว หายไปแล้ว หรือไม่สนับสนุนข้อกล่าวอ้างที่สร้างโดย AI อีกต่อไป เพียงเพราะมีการดึง CAPTCHA หน้าเปล่า หรือสิ่งกีดขวางอื่นมาแทนเนื้อหาต้นฉบับ

แค่บอกว่ามี ก็ถือว่ามี!

ปัญหานี้ยังเห็นได้จากการทดสอบด้วยที่อยู่เว็บที่ไม่มีอยู่จริงโดยเจตนา เมื่อมีการร้องขอเส้นทางแบบสุ่มที่แต่งขึ้นจากเว็บไซต์ต่าง ๆ เว็บไซต์ 13.1% ที่ตอบกลับส่งสถานะ 200 (“OK”) กลับมา ทั้งที่หน้าเว็บที่ร้องขอนั้นไม่มีอยู่จริง^†

“ในบรรดาเว็บไซต์ที่ตอบสนองต่อการตรวจสอบเส้นทางสุ่ม มี 13.1% ที่ส่งสถานะ 200 กลับมา (S1 10.5%, S2 13.3%, S3 17.3%, S4 13.7%, S5 13.1%) ผลตอบกลับทุกกรณีเป็น 404 แบบ soft โดยนิยาม แต่ไม่ใช่ทุกกรณีที่ระบุเช่นนั้น

“ในการแจกแจงคำตอบแบบ soft 404 จำนวน 172 รายการเพื่อสำรวจเบื้องต้น ผู้ติดป้ายกำกับจัดให้ 98 รายการเป็นข้อผิดพลาดหรือหน้าทดแทน 32 รายการเป็นหน้าโครงเปล่า และ 28 รายการเป็นเนื้อหา กล่าวคือ หน้าแรกหรือหน้ารายการที่แสดงขึ้นเมื่อเข้าถึงเส้นทางสุ่มดูเหมือนหน้าเว็บปกติ”

บทสรุป

หากตรวจพบปัญหาในระดับที่สูงขึ้น IANA ก็อาจสร้างรหัสสถานะ HTTP ใหม่ที่เหมาะสมกว่าได้ เช่น [X] (“คำขอสำเร็จ แต่ไม่ได้ส่งเนื้อหาที่ร้องขอ”) แม้รหัสนี้จะอธิบายสิ่งที่เกิดขึ้นได้ตรงตามจริง แต่ก็ย่อมต้องอาศัยความเข้าใจธุรกรรมในฝั่งโฮสต์ในระดับที่ไม่น่าจะเกิดขึ้นได้

มีรหัสที่คล้ายกันอยู่แล้ว แม้จะไม่มีรหัสใดตรงกับกรณีนี้จริง ๆ: 451 (“ไม่พร้อมให้บริการด้วยเหตุผลทางกฎหมาย”) มีความหมายคลุมเครือและชวนให้ตื่นตระหนกอยู่ไม่น้อย (!); 206 (“เนื้อหาบางส่วน”) ตรงตามหลักเทคนิค แต่มีไว้สำหรับข้อมูลที่ดึงมาได้ไม่ครบ; และ 203 (“ข้อมูลที่ไม่ใช่ข้อมูลจากแหล่งที่มีอำนาจ”) ซึ่งน่าประหลาดใจที่มีอยู่จริงนั้น สร้างขึ้นในปี 1997 และเกี่ยวข้องกับกรณีนี้เพียงทางอ้อม

บางทีรหัสที่ใกล้เคียงที่สุดอาจเป็น 103 (“คำใบ้ล่วงหน้า”) ซึ่งมีชื่อที่ชวนให้เข้าใจผิด และหมายความว่ายังโหลดทรัพยากรของ URL ไม่ครบ (แม้การตีความเช่นนี้จะคลาดเคลื่อนจากเจตนาของรหัสอย่างมากก็ตาม)

* ชื่อเรื่องคือ “เมื่อ 200 OK ไม่ใช่คำตอบ: ความล้มเหลวเงียบในการดึงเนื้อหาเว็บโดยเอเจนต์” โปรดทราบว่า ดูเหมือนบทความวิชาการฉบับนี้เขียนขึ้นโดยมุ่งให้เครื่องอ่านเป็นหลัก และอาจใช้สืบค้นด้วย AI ได้ แต่ตัวบทก็อ่านเข้าใจได้ไม่ง่ายนัก

^†ขออภัยที่ยกข้อความเชิงกลไกมาอ้าง แต่ดังที่กล่าวไว้ข้างต้น บทความวิชาการทั้งฉบับเขียนในลักษณะนี้เพื่อให้ “เครื่องอ่านได้” มากกว่าจะให้มนุษย์ตีความ แม้จะยังไม่ได้จัดทำในรูปแบบ JSON ก็ตาม

เผยแพร่ครั้งแรกเมื่อวันพุธที่ 4 พฤศจิกายน 2026