RAG Ingestion ਲਈ Async Scraping ਬਿਹਤਰ ਹੈ
RAG ਸਿਸਟਮ ਅਕਸਰ ਪੁਰਾਣੇ (stale) ਡੇਟਾ ਕਾਰਨ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਪੇਜ ਬਦਲ ਜਾਂਦਾ ਹੈ ਪਰ ਤੁਹਾਡਾ ਇੰਡੈਕਸ ਉਹੀ ਰਹਿੰਦਾ ਹੈ। ਫਿਰ ਤੁਹਾਡਾ AI ਬਹੁਤ ਭਰੋਸੇ ਨਾਲ ਗਲਤ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਇਸਨੂੰ ਸਧਾਰਨ synchronous scrapers ਨਾਲ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਤੁਸੀਂ ਇੱਕ ਪੇਜ ਫੈਚ (fetch) ਕਰਦੇ ਹੋ, ਡੇਟਾ ਕੱਢਦੇ ਹੋ, ਅਤੇ ਆਪਣੇ vector store ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹੋ। ਇਹ ਤਰੀਕਾ production ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।
Synchronous scraping ਨਾਲ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ:
- JavaScript ਜਾਂ cookie banners ਕਾਰਨ ਪੇਜ ਲੋਡ ਹੋਣ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
- ਤੁਹਾਡੀ API scraper ਦੇ ਖਤਮ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦੀ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਯੂਜ਼ਰਸ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੰਦੀ ਹੈ।
- ਟਾਸਕਾਂ ਨੂੰ parallel ਵਿੱਚ ਚਲਾਉਣ ਵੇਲੇ ਮੈਮੋਰੀ ਜਾਂ open sockets ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ।
- Timeouts ਜਾਂ rate limits ਵਰਗੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
Async scraping ਇੱਕ submit, poll, ਅਤੇ retrieve ਫਲੋਅ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਟਾਸਕ ਸਬਮਿਟ ਕਰਦੇ ਹੋ, ਇੱਕ job ID ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਨਤੀਜੇ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹੋ। ਇਹ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਰੱਖਦਾ ਹੈ।
ਇੱਕ ਭਰੋਸੇਯੋਗ ingestion pipeline ਕਿਵੇਂ ਬਣਾਈਏ:
- Scraping ਨੂੰ request handling ਤੋਂ ਵੱਖ ਕਰੋ। ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਲੋਡ ਹੋਣ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ।
- Job states ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰੋ। URL, status, ਅਤੇ errors ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ।
- Content hashes ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਪੇਜ ਦਾ ਕੰਟੈਂਟ ਨਹੀਂ ਬਦਲਿਆ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਦੁਬਾਰਾ re-embed ਨਾ ਕਰੋ। ਇਸ ਨਾਲ ਪੈਸੇ ਅਤੇ ਸਮੇਂ ਦੀ ਬਚਤ ਹੁੰਦੀ ਹੈ।
- Dead-letter queues ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਕੋਈ job ਤਿੰਨ ਵਾਰ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿਓ। ਇਸਨੂੰ ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਲਿਸਟ ਵਿੱਚ ਭੇਜ ਦਿਓ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਸਨੂੰ ਠੀਕ ਕਰ ਸਕੋ।
- ਆਪਣੇ ਡੇਟਾ ਦੀ ਜਾਂਚ (validate) ਕਰੋ। Vector store ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਕੱਢੇ ਗਏ ਡੇਟਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ schema ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇੱਕ ਖਾਲੀ string ਇੱਕ ਫੇਲ ਹੋਏ job ਨਾਲੋਂ ਵੀ ਮਾੜੀ ਹੁੰਦੀ ਹੈ।
Async scraping background updates ਅਤੇ scheduled refreshes ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ। ਇਹ real-time ਲੋੜਾਂ ਲਈ ਨਹੀਂ ਹੈ ਜਿੱਥੇ ਯੂਜ਼ਰ ਇੱਕ ਤਾਜ਼ੇ ਪੇਜ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ।
ਜੇਕਰ ਕਿਸੇ ਯੂਜ਼ਰ ਨੂੰ ਤੁਰੰਤ ਡੇਟਾ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ cached content ਦਿਖਾਓ ਅਤੇ background ਵਿੱਚ index ਨੂੰ ਅਪਡੇਟ ਕਰੋ।
ਵਿਕਲਪਿਕ ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi