𝗔𝘀𝘆𝗻𝗰 𝗦𝗰𝗿𝗮𝗽𝗶𝗻𝗴 𝗜𝘀 𝗕𝗲𝘁𝘁𝗲𝗿 𝗳𝗼𝗿 𝗥𝗔𝗚 𝗜𝗻𝗴𝗲𝘀𝘁𝗶𝗼𝗻
RAG সিস্টেমগুলো প্রায়শই stale ডেটার কারণে ব্যর্থ হয়। পেজ পরিবর্তিত হয় কিন্তু আপনার ইনডেক্স একই থাকে। ফলে আপনার AI উচ্চ আত্মবিশ্বাসের সাথে ভুল উত্তর দেয়।
অনেকেই সাধারণ synchronous scraper দিয়ে এটি সমাধান করার চেষ্টা করেন। আপনি একটি পেজ ফেচ করেন, ডেটা এক্সট্র্যাক্ট করেন এবং আপনার vector store আপডেট করেন। প্রোডাকশনে এই পদ্ধতিটি বিভিন্ন সমস্যা তৈরি করে।
Synchronous scraping-এর প্রধান সমস্যাগুলো হলো:
- JavaScript বা cookie banner-এর কারণে পেজ লোড হতে অনেক সময় লাগে।
- আপনার API scraper-এর কাজ শেষ হওয়া পর্যন্ত অপেক্ষা করে, যা ব্যবহারকারীদের গতি কমিয়ে দেয়।
- প্যারালাল টাস্ক চালানোর সময় মেমরি বা open socket শেষ হয়ে যেতে পারে।
- Timeout বা rate limit-এর মতো ত্রুটিগুলো ম্যানেজ করা কঠিন।
Async scraping একটি submit, poll, এবং retrieve ফ্লো ব্যবহার করে। আপনি একটি টাস্ক সাবমিট করেন, একটি job ID পান এবং পরে ফলাফল চেক করেন। এটি আপনার অ্যাপ্লিকেশনকে দ্রুত রাখে।
একটি নির্ভরযোগ্য ingestion pipeline কীভাবে তৈরি করবেন:
- Scraping-কে request handling থেকে আলাদা করুন। আপনার অ্যাপ্লিকেশনের ব্রাউজার লোড হওয়ার জন্য অপেক্ষা করা উচিত নয়।
- একটি ডাটাবেসে job states সংরক্ষণ করুন। URL, status এবং error ট্র্যাক করুন।
- Content hashes ব্যবহার করুন। যদি পেজের কন্টেন্ট পরিবর্তিত না হয়, তবে সেটি পুনরায় embed করবেন না। এতে সময় ও অর্থ সাশ্রয় হয়।
- Dead-letter queues ব্যবহার করুন। যদি একটি job তিনবার ব্যর্থ হয়, তবে পুনরায় চেষ্টা করা বন্ধ করুন। এটিকে একটি দৃশ্যমান তালিকায় সরিয়ে নিন যাতে আপনি এটি ঠিক করতে পারেন।
- আপনার ডেটা ভ্যালিডেট করুন। Vector store-এ পৌঁছানোর আগে এক্সট্র্যাক্ট করা ডেটা পরীক্ষা করতে একটি schema ব্যবহার করুন। একটি empty string একটি failed job-এর চেয়েও খারাপ।
Async scraping ব্যাকগ্রাউন্ড আপডেট এবং শিডিউল করা রিফ্রেশ-এর জন্য সবচেয়ে ভালো কাজ করে। এটি রিয়েল-টাইম প্রয়োজনের জন্য নয় যেখানে একজন ব্যবহারকারী একটি নতুন পেজের জন্য অপেক্ষা করেন।
যদি কোনো ব্যবহারকারীর তাৎক্ষণিক ডেটা প্রয়োজন হয়, তবে তাদের cached কন্টেন্ট দেখান এবং ব্যাকগ্রাউন্ডে ইনডেক্স আপডেট করুন।
Optional learning community: https://t.me/GyaanSetuAi