เหนือกว่า API: เหตุใดองค์กร 65% จึงทำ web scraping เพื่อฝึก AI

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

การพัฒนา generative AI ได้เขียนกฎนี้ใหม่ทั้งหมด จากข้อมูลหลายแหล่ง องค์กร 65% ที่พัฒนาหรือฝึกโมเดล AI ใช้ web scraping เป็นแหล่งข้อมูลหลักหรือแหล่งเสริมร่วมกับ API หรือแม้กระทั่งใช้แทน API นี่ไม่ใช่ความผิดปกติชั่วคราวหรือทางเลือกอ้อมสำหรับผู้ที่หา API ที่เหมาะสมไม่ได้ แต่เป็นการเปลี่ยนแปลงพื้นฐานในมุมมองของบริษัทต่อข้อมูลในฐานะสินทรัพย์

หากบริษัทของคุณสร้าง ML pipeline ฝึก LLM ด้วยข้อมูลเฉพาะโดเมนของตนเอง หรือสนับสนุนระบบ RAG ด้วยข้อมูลสาธารณะที่อัปเดต คำถามจะเปลี่ยนจาก “เราต้องทำ scraping หรือไม่?” เป็น “เราจะขยายงาน scraping ให้ถูกต้องตามกฎหมายและมีเสถียรภาพได้อย่างไร?” ในที่นี้ โครงสร้างพื้นฐานคือสิ่งที่กำหนดทุกอย่าง

ข้อเท็จจริงสำคัญ:

• LLM ต้องใช้ข้อมูลจำนวนมหาศาลที่เจาะจงตามภูมิศาสตร์และเป็นปัจจุบันในการฝึก เพื่อให้ตอบได้อย่างมีคุณค่า
• API ให้ข้อมูลในปริมาณจำกัดและไม่ได้รีเฟรชแบบเรียลไทม์ อีกทั้งยังข้ามแหล่งข้อมูลมีค่าจำนวนมาก เช่น ฟอรัมท้องถิ่น ที่อาจไม่มี API endpoint
• Scraping ใช้แทน API ได้ เพราะช่วยให้รับข้อมูลได้ไม่จำกัดจากหลายแหล่ง กำหนดเป้าหมายเนื้อหาตามภูมิศาสตร์ และไม่พลาดการเปลี่ยนแปลงใด ๆ
• ความสำเร็จของ scraping ไม่ได้กำหนดด้วยโค้ดของ scraper เท่านั้น แต่ยังขึ้นอยู่กับโครงสร้างพื้นฐานที่ช่วยควบคุม session กระจาย traffic ตั้งค่าพารามิเตอร์การกำหนดเป้าหมาย และเลียนแบบพฤติกรรมผู้ใช้จริงเพื่อหลีกเลี่ยงการถูกปฏิเสธ
• DataImpulse เป็นผู้ให้บริการ proxy อย่างมีจริยธรรม ที่มี residential proxy, mobile proxy และ datacenter proxy พร้อมสำหรับ scraping ใน 195 พื้นที่ ด้วย proxy pool 90M+ พร้อมรูปแบบคิดค่าบริการตาม GB, traffic ที่ไม่หมดอายุ และการสนับสนุนจากมนุษย์ตลอด 24/7 ทำให้ proxy ของ DataImpulse เหมาะไม่เพียงสำหรับ web scraping แต่ยังสำหรับการรวบรวมข้อมูล AI การติดตามราคา ad verification การติดตาม SERP และอีกมากมาย

เหตุใด API จึงไม่ตอบโจทย์ทีม AI อีกต่อไป

API เหมาะอย่างยิ่งเมื่อผู้ให้บริการข้อมูลรู้แน่ชัดว่าคุณต้องการอะไรและยินยอมให้ข้อมูลนั้นแก่คุณ อย่างไรก็ตาม การฝึกโมเดลสมัยใหม่ต้องใช้แนวทางที่ต่างออกไปโดยสิ้นเชิง

• ปริมาณข้อมูลจำกัด – API ส่วนใหญ่ส่งกลับเฉพาะข้อมูลในปริมาณที่ผู้ให้บริการเลือกจะให้ ข้อมูลย้อนหลัง หน้าเฉพาะกลุ่ม รูปภาพความละเอียดต้นฉบับ และ markup ของหน้า ล้วนมักถูกตัดออกจากผลลัพธ์ API
• Rate limit ถูกออกแบบมาเพื่อผลิตภัณฑ์ ไม่ใช่ ML เดิมทีข้อจำกัด API ตั้งขึ้นตามความต้องการของการเชื่อมต่อระหว่างแอป ซึ่งต้องเรียกใช้งานตั้งแต่หลักร้อยถึงหลักพันครั้งต่อวัน แต่การรับข้อมูลเพื่อฝึกโมเดล ML ต้องใช้ request หลายล้านครั้ง ขนาดงานจึงไม่สอดคล้องกัน
• ความหน่วงระหว่างเหตุการณ์กับเวลาที่ข้อมูลพร้อมใช้ – สำหรับบางโมเดล การเข้าใจเนื้อหาปัจจุบัน เช่น ราคาของคู่แข่ง ข่าว และแนวโน้มโซเชียลมีเดีย เป็นเรื่องสำคัญยิ่ง คุณค่าของข้อมูลลดลงทุกชั่วโมงที่ล่าช้า และ API รีเฟรชตามตารางของผู้ให้บริการ ไม่ใช่ตามการเปลี่ยนแปลงแบบเรียลไทม์หรือความต้องการของคุณ
• ต้นทุน – แผน API ระดับองค์กรที่ออกแบบมาสำหรับโหลดปริมาณสูง มักแพงกว่าการสร้าง data pipeline ของคุณเองหลายเท่า โดยเฉพาะเมื่อเกี่ยวข้องกับข้อมูลหลายรูปแบบ เช่น รูปภาพ วิดีโอ ไฟล์ PDF เป็นต้น นอกจากนี้ API ก็ไม่ได้ให้ข้อมูลดิบสำหรับสิ่งเหล่านั้น
• ข้อจำกัดของแหล่งข้อมูลที่มีอยู่ – ส่วนใหญ่ของ WEB เช่น ฟอรัมท้องถิ่น marketplace ระดับรอง เว็บไซต์ข่าวภูมิภาค และแหล่งข้อมูลเฉพาะกลุ่ม ไม่มี API ของตนเองสำหรับดึงข้อมูล แต่ทั้งหมดก็เป็นแหล่งข้อมูลมีค่าที่คุณตัดทิ้งไม่ได้ Web scraping คือหนทางเดียวสำหรับแหล่งเหล่านี้

ทีม AI มองหาอะไรจริง ๆ บน Web

คำว่า “ข้อมูลสำหรับ AI” อาจฟังดูกว้างเกินไป จนกว่าจะรู้แน่ชัดว่าทีมองค์กรกำลังมองหาข้อมูลอะไร:

• คลังข้อความเฉพาะโดเมนสำหรับฝึก LLM เช่น เอกสารกฎหมาย สิ่งพิมพ์ทางการแพทย์ และเอกสารเทคนิคเฉพาะกลุ่ม ซึ่งโมเดลทั่วไปให้ผลลัพธ์ไม่ดี
• ข้อมูลราคาและความหลากหลายของสินค้าคู่แข่ง สำหรับฝึกโมเดลข่าวกรองราคาแบบไดนามิก
• ชุดข้อมูลหลายรูปแบบ เช่น ภาพสินค้า แบบแปลนสถานที่ และข้อความหน้าปก สำหรับโมเดล computer vision
• แนวโน้มและการเปลี่ยนแปลงอารมณ์จากฟอรัม รีวิว และโซเชียลมีเดีย สำหรับโมเดลที่คาดการณ์อุปสงค์หรือความเสี่ยงด้านชื่อเสียง
• Alt-data สำหรับโมเดลการเงิน เช่น ประกาศงาน ภาพคลังสินค้า และความคิดเห็นพนักงาน ทุกสิ่งที่ช่วยให้ได้เปรียบแหล่งข้อมูลดั้งเดิมหลายชั่วโมง

ทุกกรณีเหล่านี้มีสิ่งหนึ่งร่วมกัน คือข้อมูลที่กระจายอยู่ตามโดเมนต่าง ๆ และรีเฟรชทุกวินาที ไม่มี API ใดครอบคลุมทั้งหมดได้

ปัญหาของ scraping ระดับองค์กรคืออะไร

scraping pipeline ของคุณอาจทำงานได้สมบูรณ์ในโครงการนำร่องที่มี 500 request แต่หลังทดสอบสำเร็จและย้ายไปทำ scraping จริงด้วย request หลายล้านครั้ง ก็อาจล้มเหลวขึ้นมากะทันหัน เพราะขนาดงานจะเผยปัญหาที่มองไม่เห็นหากไม่มีโหลดสูง

• การปฏิเสธ IP

เว็บไซต์ตรวจพบกิจกรรมผิดปกติจาก IP เดียวได้ภายในไม่กี่นาที Datacenter IP ที่ส่ง request จำนวนมากจะถูกขึ้นบัญชีดำเร็วกว่าที่กระบวนการเก็บข้อมูลจะเสร็จสิ้น

• เนื้อหาเฉพาะตามภูมิศาสตร์

ราคา ความพร้อมจำหน่าย และโฆษณาที่กำหนดเป้าหมายตามภูมิภาค ข้อมูลทั้งหมดนี้จะไม่มีอยู่ หาก request ของคุณมาจากสถานที่ “ผิด” หากโมเดลต้องเข้าใจตลาดบราซิล เยอรมนี หรือญี่ปุ่น traffic ต้องดูเหมือนมาจากที่นั่น

• CAPTCHA และ browser fingerprinting

ระบบป้องกัน bot สมัยใหม่ไม่ได้พึ่งการวิเคราะห์ IP เพียงอย่างเดียว แต่ยังพิจารณารูปแบบพฤติกรรม TLS fingerprint, request headers และสัญญาณอื่น ๆ โดยทั่วไปการตรวจจับเกิดขึ้นผ่าน 5 ชั้น หากแม้แต่สัญญาณเดียวดูน่าสงสัย scraper ก็มีแนวโน้มจะถูกบล็อก และ pipeline ทั้งหมดจะไร้ทางทำงานจนกว่านักพัฒนาจะแก้ไข

• คุณภาพข้อมูล

เพื่อให้มีประสิทธิภาพ โมเดลของคุณต้องใช้ข้อมูลที่แม่นยำในการฝึก เมื่อ scraper ถูกบล็อกซ้ำ ๆ เก็บข้อมูลได้เพียงบางส่วนหรือข้อมูลที่เสียความน่าเชื่อถือ หรือไปติด honey pot และกับดักอื่น ๆ สำหรับ scraper โมเดลจะเรียนรู้สัญญาณที่ผิด และความช่วยเหลือของมันก็น่าสงสัย ที่แย่ที่สุดคือคุณอาจเพิ่งรู้เรื่องนี้หลังลงทุนเงินจำนวนมากกับ scraping และการฝึกไปแล้ว

• ความเสี่ยงด้านกฎหมายและ compliance

ทีมองค์กรไม่อาจทำ scraping ไปก่อนแล้วค่อยดูว่าจะเกิดอะไรขึ้นได้ พวกเขาต้องการโครงสร้างพื้นฐานที่ช่วยควบคุมความถี่ของ request ทำงานสอดคล้องกับ robots.txt และจัดทำเอกสารแหล่งข้อมูลเพื่อการตรวจสอบ โดยเฉพาะในกลุ่มธุรกิจและประเทศที่มีการกำกับเข้มงวด

เมื่อแยกกัน ปัญหาแต่ละข้อแก้ได้ แต่ปัญหาเหล่านี้ไม่ได้เกิดแยกกัน มันมาเป็นชุด การแก้ไขจึงเป็นงานอีกประเภทหนึ่ง ไม่ใช่การตั้งค่าครั้งเดียว

เมื่อโครงสร้างพื้นฐานเป็นตัวชี้ขาด

scraper ที่ดีที่สุดก็ไร้ประโยชน์ หากถูกแพลตฟอร์มเป้าหมายบล็อกตั้งแต่นาทีที่สอง โค้ดสำคัญ แต่ระบบโดยรอบก็ไม่ควรถูกมองข้าม

• การหมุนเวียน IP – proxy pool ช่วยกระจาย request เพื่อไม่ให้ IP แต่ละรายการเข้าใกล้การตรวจจับ นี่คือการเลียนแบบรูปแบบ traffic ที่เป็นธรรมชาติและพบได้ทั่วไปในผู้ใช้ ในแง่หนึ่ง scraper ของคุณก็เป็นผู้ใช้ที่พยายามทำความเข้าใจข้อมูลจำนวนมหาศาล
• การกำหนดเป้าหมายตามภูมิศาสตร์อย่างแม่นยำ – request ต้องมาจากสถานที่ที่โมเดลจะนำไปใช้คาดการณ์และทำงานในภายหลัง หากตั้งใจใช้โมเดลพยากรณ์ราคาในญี่ปุ่น แต่ใช้ข้อมูลจากยุโรป โมเดลจะให้คำตอบที่ไม่เกี่ยวข้องกับพื้นที่เป้าหมายในภายหลัง และสิ่งนี้จะเกิดในขั้น production ซึ่งมีค่าใช้จ่ายในการแก้ไขสูงที่สุด
• ความน่าเชื่อถือ – SLA ของ uptime และเวลา response ของ proxy กำหนดว่าทีมนักพัฒนาต้องใช้เวลาแก้ pipeline มากเพียงใด แทนที่จะฝึกและอัปเกรดโมเดลเอง สำหรับองค์กร downtime มีต้นทุนเป็นการเลื่อนการเปิดตัว
• การควบคุม session – เมื่อจำเป็นต้องคง session เดิมไว้โดยไม่ให้ IP ถูกบล็อก แม้ scraper ที่ซับซ้อนที่สุดเพียงลำพังก็ไม่เพียงพอหากไม่มี proxy
• Compliance – ผู้ให้บริการ proxy ระดับองค์กรที่จัดหา IP pool อย่างมีจริยธรรมและปฏิบัติตามข้อบังคับท้องถิ่น ช่วยรับภาระด้านกฎหมายบางส่วนจากทีม AI ซึ่งมิฉะนั้นจะตกเป็นของทีม compliance

สรุป

บริษัทที่เพิ่งเริ่มพัฒนาโมเดลของตนเองมักมองโครงการนำร่องที่มี request หลักร้อย และโครงการเต็มรูปแบบที่มี request หนึ่งล้านครั้งว่าเป็นสิ่งเดียวกัน เพียงแค่ขยายขนาด ในความจริง ทั้งสองเป็นสิ่งที่ต่างกันและต้องใช้แนวทางต่างกัน เพราะสำหรับระบบระดับ production จุดอ่อนมิใช่ scraper เอง แต่คือความจำเป็นต้องได้ข้อมูลฝึกอย่างถูกต้องตามกฎหมาย รวดเร็ว และมีเสถียรภาพ ดังนั้นคำถามไม่ใช่ “เราจำเป็นต้องเปลี่ยนจาก API มาทำ scraping ข้อมูล และต้องใช้ proxy เพื่อสิ่งนั้นจริงหรือ?” แต่คือ “การเสียเวลาอีกหนึ่งสัปดาห์กับข้อมูลจำกัดที่ API ให้ ขณะที่คู่แข่งเปิดตัวโมเดลใหม่และขยายการเก็บข้อมูล มีต้นทุนเท่าไร?”

คำถามที่พบบ่อย