𝗔𝘀𝘆𝗻𝗰 𝗦𝗰𝗿𝗮𝗽𝗶𝗻𝗴 𝗜𝘀 𝗕𝗲𝘁𝘁𝗲𝗿 𝗳𝗼𝗿 𝗥𝗔𝗚 𝗜𝗻𝗴𝗲𝘀𝘁𝗶𝗼𝗻
ระบบ RAG มักจะล้มเหลวเนื่องจากข้อมูลที่ล้าสมัย หน้าเว็บมีการเปลี่ยนแปลงแต่ดัชนี (index) ของคุณยังเหมือนเดิม ส่งผลให้ AI ของคุณให้คำตอบที่ผิดพลาดด้วยความมั่นใจสูง
หลายคนพยายามแก้ไขปัญหานี้ด้วย synchronous scraper แบบง่ายๆ โดยการดึงหน้าเว็บ สกัดข้อมูล และอัปเดต vector store ของคุณ วิธีการนี้มักจะสร้างปัญหาเมื่อนำไปใช้งานจริง (production)
ปัญหาหลักของการทำ synchronous scraping:
- การโหลดหน้าเว็บใช้เวลานานเนื่องจาก JavaScript หรือแบนเนอร์คุกกี้
- API ของคุณต้องรอให้ scraper ทำงานเสร็จ ซึ่งทำให้ผู้ใช้งานของคุณต้องรอนานขึ้น
- หน่วยความจำ (memory) เต็ม หรือมีการเปิด socket ค้างไว้มากเกินไปเมื่อรันงานแบบขนาน (parallel)
- ข้อผิดพลาดอย่าง timeout หรือ rate limit จัดการได้ยาก
การทำ async scraping จะใช้กระบวนการแบบ submit, poll และ retrieve โดยคุณส่งงาน (submit task) รับ job ID มา แล้วค่อยกลับมาตรวจสอบผลลัพธ์ในภายหลัง วิธีนี้จะช่วยให้แอปพลิเคชันของคุณทำงานได้อย่างรวดเร็ว
วิธีการสร้าง ingestion pipeline ที่เชื่อถือได้:
- แยกการทำ scraping ออกจากการจัดการ request แอปของคุณไม่ควรต้องรอให้เบราว์เซอร์โหลดหน้าเว็บเสร็จ
- เก็บสถานะของงาน (job states) ไว้ในฐานข้อมูล โดยติดตาม URL, สถานะ และข้อผิดพลาดต่างๆ
- ใช้ content hashes หากเนื้อหาในหน้าเว็บไม่มีการเปลี่ยนแปลง ก็ไม่จำเป็นต้องทำ re-embed ใหม่ ซึ่งจะช่วยประหยัดทั้งเงินและเวลา
- ใช้ dead-letter queues หากงานล้มเหลวครบสามครั้ง ให้หยุดพยายามใหม่ (retry) และย้ายงานนั้นไปยังรายการที่ตรวจสอบได้เพื่อให้คุณสามารถแก้ไขได้
- ตรวจสอบความถูกต้องของข้อมูล (validate data) โดยใช้ schema เพื่อเช็คข้อมูลที่สกัดมาได้ก่อนที่จะส่งไปยัง vector store เพราะการได้ค่าว่าง (empty string) มานั้นแย่ยิ่งกว่าการที่งานล้มเหลวเสียอีก
การทำ async scraping เหมาะที่สุดสำหรับการอัปเดตเบื้องหลัง (background updates) และการรีเฟรชข้อมูลตามกำหนดเวลา (scheduled refreshes) แต่มันไม่เหมาะกับความต้องการแบบเรียลไทม์ที่ผู้ใช้ต้องรอหน้าเว็บที่สดใหม่ทันที
หากผู้ใช้ต้องการข้อมูลในทันที ให้แสดงเนื้อหาจากแคช (cached content) ไปก่อน แล้วค่อยอัปเดตดัชนีในเบื้องหลัง
Optional learning community: https://t.me/GyaanSetuAi