ਜ਼ਿਆਦਾਤਰ RAG ਟਿਊਟੋਰਿਅਲ ਨੋਟਬੁੱਕ (notebook) 'ਤੇ ਹੀ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ। ਉਹ ਕੁਝ ਸਾਫ਼-ਸੁਥਰੀਆਂ PDF ਫਾਈਲਾਂ ਲੋਡ ਕਰਦੇ ਹਨ, ਹਰ ਇੱਕ ਹਜ਼ਾਰ ਅੱਖਰਾਂ ਬਾਅਦ ਟੈਕਸਟ ਨੂੰ ਵੰਡਦੇ ਹਨ, ਟੁਕੜਿਆਂ ਨੂੰ ਵੈਕਟਰ ਡਾਟਾਬੇਸ (vector database) ਵਿੱਚ ਭਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਕਹਿ ਦਿੰਦੇ ਹਨ। ਸ਼ੁੱਕਰਵਾਰ ਦੀ ਦੁਪਹਿਰ ਨੂੰ, ਉਹ ਡੈਮੋ ਬਿਲਕੁਲ ਸਹੀ ਚੱਲਦਾ ਹੈ। ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ (production) ਵਿੱਚ, ਉਹੀ ਪਾਈਪਲਾਈਨ ਚੁੱਪਚਾਪ ਇੱਕ ਮੁਸੀਬਤ ਬਣ ਜਾਂਦੀ ਹੈ।
ਰਿਟ੍ਰੀਵਲ ਸਿਸਟਮ (retrieval system) ਵਿੱਚ ਅਸਲ ਰੁਕਾਵਟ ਬਹੁਤ ਘੱਟ ਹੀ ਮਾਡਲ ਜਾਂ ਪ੍ਰੋਂਪਟ (prompt) ਹੁੰਦੀ ਹੈ। ਇਹ ਇੰਜੈਸਸ਼ਨ (ingestion) ਹੈ। ਇੱਕ RAG ਪਾਈਪਲਾਈਨ ਸਿਰਫ਼ ਉਹੀ ਚੀਜ਼ ਰਿਟ੍ਰੀਵ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ਇਸਨੂੰ ਦਿੱਤੀ ਗਈ ਹੋਵੇ, ਅਤੇ ਜੇਕਰ ਫੀਡ ਸ਼ੋਰ ਵਾਲੀ (noisy), ਪੁਰਾਣੀ (stale), ਜਾਂ ਅਧੂਰੀ ਹੈ, ਤਾਂ ਮਾਡਲ ਭਰੋਸੇਮੰਦ ਲੱਗਣ ਵਾਲਾ ਬੇਤੁਕਾ ਜਵਾਬ ਦੇਵੇਗਾ। ਜਦੋਂ ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ ਕਿ ਬੋਟ ਨੇ ਹਲੂਸੀਨੇਸ਼ਨ (hallucinated) ਕੀਤਾ ਹੈ, ਤਾਂ ਅਕਸਰ ਦੋਸ਼ ਡਾਟਾ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਕੋਈ ਵੀ ਨੇੜਿਓਂ ਨਿਗਰਾਨੀ ਨਹੀਂ ਕਰਦਾ।
ਵ੍ਹਾਈਟਬੋਰਡ ਟ੍ਰੈਪ (The Whiteboard Trap)
ਆਰਕੀਟੈਕਚਰ ਡਾਇਗ੍ਰਾਮ ਇੰਜੈਸਸ਼ਨ ਨੂੰ "Documents → Vector DB" ਲੇਬਲ ਵਾਲੇ ਇੱਕ ਸਿੰਗਲ ਤੀਰ ਵਾਂਗ ਦਿਖਾਉਂਦੇ ਹਨ। ਅਸਲੀਅਤ ਇਸ ਤੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਉਲਝੀ ਹੋਈ ਹੈ। ਸਰੋਤ ਸਿਸਟਮ (source systems) ਬਿਨਾਂ ਕਿਸੇ ਸੂਚਨਾ ਦੇ ਬਦਲ ਜਾਂਦੇ ਹਨ। HTML ਲੇਆਉਟ ਨੂੰ ਰੀਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। URL ਆਮ ਲੈਂਡਿੰਗ ਪੇਜਾਂ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਹੋ ਜਾਂਦੇ ਹਨ। JavaScript ਫਰੇਮਵਰਕ ਸ਼ੁਰੂਆਤੀ HTTP ਰਿਸਪਾਂਸ ਤੋਂ ਬਾਅਦ ਸਮੱਗਰੀ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਇੰਜੈਸਸ਼ਨ ਨੂੰ ਇੱਕ ਵਾਰ ਦੇ ਸੈੱਟਅੱਪ ਕਾਰਜ ਵਜੋਂ ਮੰਨਣਾ ਪਹਿਲੀ ਗਲਤੀ ਹੈ। ਇਹ ਇੱਕ ਲਗਾਤਾਰ ਚੱਲਣ ਵਾਲੀ ਡਾਟਾ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੱਸਿਆ ਹੈ ਜਿਸ ਨੂੰ ਕਿਸੇ ਵੀ ETL ਪਾਈਪਲਾਈਨ ਵਾਂਗ ਹੀ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਣ ਦੀ ਲੋੜ ਹੈ।
RAG ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਫੀਡ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਕਿਉਂ ਹੁੰਦੀਆਂ ਹਨ
ਇਸ ਦੀ ਕਲਪਨਾ ਕਰੋ: ਇੱਕ ਯੂਜ਼ਰ ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਸਹਾਇਕ (internal assistant) ਤੋਂ ਮੌਜੂਦਾ ਰਿਫੰਡ ਪਾਲਿਸੀ ਬਾਰੇ ਪੁੱਛਦਾ ਹੈ। ਮਾਡਲ ਵੈਕਟਰ ਸਟੋਰ ਤੋਂ ਸਭ ਤੋਂ ਉੱਪਰਲਾ ਚੰਕ (chunk) ਕੱਢਦਾ ਹੈ ਅਤੇ 30 ਦਿਨਾਂ ਦੀ ਮਿਆਦ ਦੱਸਦਾ ਹੈ। ਅਸਲ ਪਾਲਿਸੀ ਪਿਛਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਬਦਲ ਕੇ 60 ਦਿਨਾਂ ਦੀ ਹੋ ਗਈ ਸੀ। LLM ਨੇ ਗਲਤ ਜਵਾਬ ਨਹੀਂ ਘੜਿਆ ਸੀ। ਇਸ ਨੇ ਗਲਤ ਇਨਪੁਟ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ ਸੀ। ਰਿਟ੍ਰੀਵਲ ਲੇਅਰ ਨੇ ਇੱਕ ਪੁਰਾਣਾ ਪੇਜ ਦਿਖਾਇਆ, ਅਤੇ ਕਿਉਂਕਿ ਐਮਬੈਡਿੰਗ (embedding) ਅਰਥ ਦੇ ਹਿਸਾਬ ਨਾਲ ਕਾਫ਼ੀ ਨੇੜੇ ਲੱਗੀ, ਮਾਡਲ ਨੇ ਇਸਨੂੰ ਸੱਚ ਮੰਨ ਲਿਆ।
ਇਹ ਪੈਟਰਨ ਲਗਾਤਾਰ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਟੈਂਪਰੇਚਰ (temperature) ਅਤੇ top-k ਨੂੰ ਠੀਕ ਕਰਨ ਵਿੱਚ ਕਈ ਘੰਟੇ ਬਰਬਾਦ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਜਦੋਂ ਕਿ ਉਹਨਾਂ ਦਾ ਕੋਰਪਸ (corpus) ਨੈਵੀਗੇਸ਼ਨ ਫੁੱਟਰ, ਡੁਪਲੀਕੇਟ ਪ੍ਰੈਸ ਰਿਲੀਜ਼ਾਂ, ਅਤੇ ਅਜਿਹੇ ਚੰਕਾਂ ਨਾਲ ਭਰਿਆ ਹੁੰਦਾ ਹੈ ਜੋ ਟੇਬਲਾਂ ਨੂੰ ਅੱਧ ਵਿਚਕਾਰੋਂ ਵੰਡ ਦਿੰਦੇ ਹਨ। ਜਨਰੇਸ਼ਨ (generation) ਨੂੰ ਆਪਟੀਮਾਈਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਸ ਗੱਲ ਦੀ ਜਾਂਚ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਕੀ ਜਾਣਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ।
ਸੱਤ ਜਾਲ ਜੋ ਇੰਜੈਸਸ਼ਨ ਨੂੰ ਬਰਬਾਦ ਕਰ ਦਿੰਦੇ ਹਨ
1. ਪਹਿਲੀ ਰਨ ਇੱਕ ਝੂਠ ਹੈ
ਤੁਹਾਡੇ ਸ਼ੁਰੂਆਤੀ ਕ੍ਰੌਲ (crawl) 'ਤੇ ਇੱਕ ਹਰਾ ਚੈੱਕਮਾਰਕ ਹੋਣ ਦਾ ਲਗਭਗ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਡਾਟਾ ਜਿਉਂਦਾ ਹੁੰਦਾ ਹੈ। ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਪੇਜਾਂ ਨੂੰ ਰੀਫੈਕਟਰ (refactor) ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਬਲੌਗ ਪਰਮਲਿੰਕ ਟੁੱਟ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਸਾਈਟਮੈਪ ਚੁੱਪਚਾਪ ਸੈਕਸ਼ਨਾਂ ਨੂੰ ਹਟਾ ਦਿੰਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹ ਜਾਂਚ ਕਰਦੇ ਹੋ ਕਿ ਪਾਈਪਲਾਈਨ ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ ਦੇ ਪੂਰੀ ਹੋ ਗਈ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅੰਨ੍ਹੇਵਾਹ ਚੱਲ ਰਹੇ ਹੋ। ਤੁਹਾਨੂੰ ਆਉਟਪੁੱਟ (output) ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਚੈੱਕ ਕਰੋ ਕਿ ਉਮੀਦ ਕੀਤੇ ਗਏ ਦਸਤਾਵੇਜ਼ ਮੌਜੂਦ ਹਨ, ਕੀ ਉਹਨਾਂ ਦਾ ਢਾਂਚਾ ਅਜੇ ਵੀ ਪਾਰਸ (parse) ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੀ ਟੈਕਸਟ ਦੀ ਕੁੱਲ ਮਾਤਰਾ ਇਸ ਲਈ ਘੱਟ ਤਾਂ ਨਹੀਂ ਗਈ ਕਿਉਂਕਿ ਕਿਸੇ ਸਰੋਤ ਨੇ ਨਤੀਜਿਆਂ ਨੂੰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਪੇਜ (paginate) ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।
2. ਕ੍ਰੌਲਿੰਗ (Crawling) ਇੰਜੈਸਸ਼ਨ ਨਹੀਂ ਹੈ
HTML ਪ੍ਰਾਪਤ ਕਰਨਾ ਸੌਖਾ ਹਿੱਸਾ ਹੈ। ਇੱਕ ਰੌਅ ਕ੍ਰੌਲ (raw crawl) ਸਭ ਕੁਝ ਕੈਪਚਰ ਕਰ ਲੈਂਦਾ ਹੈ: ਕੁਕੀ ਬੈਨਰ, "ਸਬੰਧਤ ਲੇਖ" (Related Articles) ਸਾਈਡਬਾਰ, ਵਿਗਿਆਪਨ ਬਲਾਕ, ਅਤੇ ਫੁੱਟਰ ਕਾਪੀਰਾਈਟ ਨੋਟਿਸ। ਜੇਕਰ ਤੁਸੀਂ ਉਸ ਰੌਅ HTML ਨੂੰ ਬਿਨਾਂ ਸੋਚੇ-ਸਮਝੇ ਚੰਕ ਵਿੱਚ ਵੰਡਦੇ ਹੋ, ਤਾਂ ਟੈਕਸਟ ਦਾ ਹਰ ਇੱਕ ਟੁਕੜਾ ਨੈਵੀਗੇਸ਼ਨ ਮੀਨੂ ਦੇ ਟੁਕੜੇ ਵੀ ਨਾਲ ਲੈ ਆਉਂਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਯੂਜ਼ਰ API ਰੇਟ ਲਿਮਿਟਾਂ ਬਾਰੇ ਪੁੱਛਦਾ ਹੈ, ਤਾਂ ਰਿਟ੍ਰੀਵਰ ਇੱਕ ਅਜਿਹਾ ਚੰਕ ਦਿਖਾ ਸਕਦਾ ਹੈ ਜੋ 40 ਪ੍ਰਤੀਸ਼ਤ ਸਾਈਡਬਾਰ ਲਿੰਕਾਂ ਨਾਲ ਭਰਿਆ ਹੋਵੇ। ਸਾਫ਼ ਐਕਸਟਰੈਕਸ਼ਨ (extraction) ਮਹੱਤਵਪੂਰਨ ਹੈ। ਤੁਹਾਨੂੰ ਮੁੱਖ ਸਮੱਗਰੀ ਵਾਲੇ ਖੇਤਰ ਦੀ ਪਛਾਣ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਬੋਇਲਰਪਲੇਟ (boilerplate) ਨੂੰ ਹਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਤੱਤਾਂ ਨੂੰ ਹਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਹਰ ਪੇਜ 'ਤੇ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਕੋਈ ਗਿਆਨ ਭੰਡਾਰ (knowledge base) ਨਹੀਂ ਬਣਾ ਰਹੇ ਹੋ। ਤੁਸੀਂ ਵੈੱਬਸਾਈਟ ਦੇ ਵਾਧੂ ਹਿੱਸਿਆਂ (website chrome) ਲਈ ਇੱਕ ਸਰਚ ਇੰਜਣ ਬਣਾ ਰਹੇ ਹੋ।
3. ਚੰਕਿੰਗ (Chunking) ਅਰਥ ਨੂੰ ਤੋੜ ਦ
ਇੱਕ ਅੰਦਰੂਨੀ ਵਿਕੀ ਦਾ ਸਥਿਰ ਸਨੈਪਸ਼ਾਟ ਸਧਾਰਨ ਮੋਡ ਹੈ। ਲਾਈਵ ਵੈੱਬ ਤੋਂ ਲਗਾਤਾਰ ਡਾਟਾ ਇਨਜੈਸਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ। ਤੁਹਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕੋਈ ਪੇਜ ਆਖਰੀ ਵਾਰ ਕਦੋਂ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਕੀ ਉਸ ਤੋਂ ਬਾਅਦ ਉਸ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਹੋਇਆ ਹੈ, ਅਤੇ ਉਹ ਜਾਣਕਾਰੀ ਕਿੰਨੇ ਸਮੇਂ ਤੱਕ ਵੈਧ ਰਹੇਗੀ। ਪੁਰਾਣੇ (stale) ਡਾਟਾ ਦਾ ਮਤਲਬ ਹਮੇਸ਼ਾ ਇਹ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਉਸ ਉੱਤੇ ਕੋਈ ਪੁਰਾਣੀ ਤਾਰੀਖ ਦਿਖਾਈ ਦੇ ਰਹੀ ਹੈ। ਕਈ ਵਾਰ ਇੱਕ ਪੇਜ ਆਪਣੇ ਟੈਕਸਟ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਪਰ ਉਹੀ URL ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਡਾ ਸਿਸਟਮ ਕੰਟੈਂਟ ਹੈਸ਼ਿੰਗ (content hashing) ਤੋਂ ਬਿਨਾਂ ਕਦੇ ਵੀ ਇਸ ਦਾ ਨੋਟਿਸ ਨਹੀਂ ਕਰ ਪਾਵੇਗਾ। ਸਰੋਤ ਦੀ ਅਸਥਿਰਤਾ (volatility) ਦੇ ਅਧਾਰ 'ਤੇ ਸਪਸ਼ਟ ਰਿਫ੍ਰੈਸ਼ ਨਿਯਮ ਬਣਾਓ। ਇੱਕ ਵਿੱਤੀ ਡਾਟਾ ਫੀਡ ਨੂੰ ਹਰ ਘੰਟੇ ਚੈੱਕ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ ਕੰਪਨੀ ਦੇ 'About' ਪੇਜ ਨੂੰ ਤਿਮਾਹੀ ਚੈੱਕ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਟਾਈਮਸਟੈਂਪ ਰਿਕਾਰਡ ਕਰੋ ਅਤੇ time-to-live ਦੀਆਂ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਤ ਕਰੋ, ਖਾਸ ਕਰਕੇ ਜੇਕਰ ਤੁਹਾਡਾ ਡੋਮੇਨ ਨਿਯਮਿਤ ਜਾਂ ਸੁਰੱਖਿਆ-ਅਹਿਮ ਮਾਰਗਦਰਸ਼ਨ ਨਾਲ ਸਬੰਧਤ ਹੈ ਜਿੱਥੇ ਪੁਰਾਣੇ ਤੱਥ ਅਸਲ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹਨ।
5. ਡੁਪਲੀਕੇਟ ਪ੍ਰਦੂਸ਼ਣ (Duplicate Pollution)
ਵੈੱਬਸਾਈਟਾਂ ਦੁਹਰਾਓ (repetition) ਨਾਲ ਭਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਉਹੀ ਉਤਪਾਦ ਵਰਣਨ ਕੈਟਾਗਰੀ ਪੇਜ, ਉਤਪਾਦ ਪੇਜ, ਅਤੇ ਇੱਕ ਪ੍ਰਮੋਸ਼ਨਲ ਲੈਂਡਿੰਗ ਪੇਜ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਉਹੀ ਪ੍ਰੈਸ ਰਿਲੀਜ਼ /news/, /press/, ਅਤੇ /blog/ ਦੇ ਅਧੀਨ ਹੁੰਦੀ ਹੈ। ਵੈਕਟਰ ਸਰਚ (Vector search) ਆਪਣੇ ਆਪ ਡਿਡੂਪਲੀਕੇਸ਼ਨ ਨਹੀਂ ਕਰਦਾ। ਜੇਕਰ ਤੁਹਾਡੇ ਡਾਟਾਬੇਸ ਵਿੱਚ ਦਸ ਲਗਭਗ ਇੱਕੋ ਜਿਹੇ ਚੰਕਸ (chunks) ਹਨ, ਤਾਂ ਉਹ ਤੁਹਾਡੇ top-k ਰਿਟ੍ਰੀਵਲ ਵਿੱਚ ਵਿਭਿੰਨ ਅਤੇ ਪ੍ਰਸੰਗਿਕ ਨਤੀਜਿਆਂ ਨੂੰ ਘੱਟ ਕਰ ਸਕਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਐਮਬੈਡਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਕੈਨੋਨੀਕਲ ਟ੍ਰੈਕਿੰਗ ਜਾਂ ਕੰਟੈਂਟ ਡਿਡੂਪਲੀਕੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਦੋ ਚੰਕਸ ਇੱਕੋ ਗੱਲ ਕਹਿੰਦੇ ਹਨ, ਤਾਂ ਅਧਿਕਾਰਤ ਸਰੋਤ ਨੂੰ ਰੱਖੋ ਅਤੇ ਕਾਪੀਆਂ ਨੂੰ ਡ੍ਰੌਪ ਕਰ ਦਿਓ। ਤੁਹਾਡੇ ਰਿਟ੍ਰੀਵਰ ਕੋਲ ਸੀਮਤ ਸਲਾਟ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਬਰਬਾਦ ਨਾ ਹੋਣ ਦਿਓ।
6. ਗੁੰਮ ਹੋਇਆ ਮੈਟਾਡਾਟਾ (Missing Metadata)
ਮੈਟਾਡਾਟਾ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਵੈਕਟਰ ਡਾਟਾਬੇਸ ਸਿਰਫ਼ ਇੱਕ ਸੰਘਣਾ ਟੈਕਸਟ ਸਰਚ ਇੰਜਣ ਹੈ ਜਿਸ ਕੋਲ ਸੰਦਰਭ (context) ਦੀ ਕੋਈ ਯਾਦਦਾਸ਼ਤ ਨਹੀਂ ਹੁੰਦੀ। ਸਮਾਰਟ ਰਿਟ੍ਰੀਵਲ ਫਿਲਟਰਿੰਗ ਅਤੇ ਰੈਂਕਿੰਗ ਸਿਗਨਲਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਕੱਚੇ (raw) ਐਮਬੈਡਿੰਗਸ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਸਰੋਤ URL, ਕੈਪਚਰ ਮਿਤੀ, ਦਸਤਾਵੇਜ਼ ਦੀ ਸ਼੍ਰੇਣੀ, ਅਤੇ ਵਰਜ਼ਨ ਨੰਬਰ ਨੂੰ ਸਟੋਰ ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ API ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਇਨਜੈਸਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਵਰਜ਼ਨਿੰਗ ਜ਼ਰੂਰੀ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ, ਇੱਕ ਕੁਐਰੀ v1 ਅਤੇ v2 ਸਪੈਕਸ ਨੂੰ ਇੱਕੋ ਜਵਾਬ ਵਿੱਚ ਮਿਲਾ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ HR ਨੀਤੀਆਂ ਇਨਜੈਸਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਖੇਤਰ ਜਾਂ ਵਿਭਾਗ ਦੁਆਰਾ ਟੈਗਿੰਗ ਤੁਹਾਨੂੰ ਮਾਡਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਨਤੀਜਿਆਂ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਮੈਟਾਡਾਟਾ ਇੱਕ ਟੈਕਸਟ ਡੰਪ ਨੂੰ ਇੱਕ ਸੰਚਾਲਿਤ ਗਿਆਨ ਪ੍ਰਣਾਲੀ (curated knowledge system) ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
7. JavaScript ਗੈਪਸ (JavaScript Gaps)
ਆਧੁਨਿਕ ਸਾਈਟਾਂ ਆਪਣਾ ਕੰਟੈਂਟ ਪਹਿਲੇ HTML ਪੇਲੋਡ ਵਿੱਚ ਨਹੀਂ ਭੇਜਦੀਆਂ। ਉਹ ਇੱਕ ਸਕੇਲੇਟਨ ਭੇਜਦੀਆਂ ਹਨ ਅਤੇ ਇਸਨੂੰ JavaScript ਕਾਲਾਂ ਨਾਲ ਹਾਈਡ੍ਰੇਟ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਬੇਸਿਕ HTTP ਰਿਕਵੈਸਟ ਵਿੱਚ ਲੋਡਿੰਗ ਸਪਿਨਰ ਅਤੇ ਇੱਕ ਲੇਆਉਟ ਸ਼ੈੱਲ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਵੀ ਨਹੀਂ ਦਿਖਾਈ ਦੇ ਸਕਦਾ। ਜੇਕਰ ਤੁਹਾਡਾ ਪਾਈਪਲਾਈਨ JavaScript ਨੂੰ ਚਲਾ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਤੁਸੀਂ ਖਾਲੀ ਪੇਜ ਜਾਂ ਅਧੂਰੇ ਟੁਕੜੇ ਇਨਜੈਸਟ ਕਰੋਗੇ ਅਤੇ ਤੁਹਾਨੂੰ ਕਦੇ ਪਤਾ ਵੀ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ ਕੁਝ ਗਲਤ ਹੈ। ਇੱਕ ਹੈੱਡਲੈੱਸ ਬ੍ਰਾਊਜ਼ਰ (headless browser) ਦੀ ਵਰਤੋਂ ਰੈਂਡਰਿੰਗ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ ਪਰ ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵੀ ਲਿਆਉਂਦੀ ਹੈ: ਵਧੇਰੇ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ, ਹੌਲੀ ਥਰੂਪੁੱਟ, ਅਤੇ ਬੋਟ ਡਿਟੈਕਸ਼ਨ ਵਾਲਾਂ। ਆਪਣੇ ਸਮਝੌਤਿਆਂ (trade-offs) ਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ ਚੁਣੋ, ਪਰ ਇਹ ਮਹਿਸੂਸ ਨਾ ਕਰੋ ਕਿ ਹਰ ਸਰੋਤ ਲਈ ਇੱਕ ਸਧਾਰਨ curl ਬਰਾਬਰ ਹੀ ਕਾਫ਼ੀ ਹੈ।
ਇੱਕ ਵਿਵਹਾਰਕ ਇਨਜੈਸਸ਼ਨ ਚੈੱਕਲਿਸਟ (A Practical Ingestion Checklist)
ਜੇਕਰ ਤੁਸੀਂ RAG ਫੀਡ ਬਣਾ ਰਹੇ ਹੋ ਜਾਂ ਉਸਦੀ ਸਮੀਖਿਆ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋ:
- ਸਰੋਤ ਦੀ ਕਵਰੇਜ ਅਤੇ ਪੇਜਨੇਸ਼ਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਇੱਕ ਸਾਈਟਮੈਪ ਕਿਸੇ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਸਿਰਫ਼ ਪਹਿਲੇ ਦਸ ਲੇਖਾਂ ਦੀ ਸੂਚੀ ਦੇ ਸਕਦਾ ਹੈ। ਡੂੰਘਾਈ ਨਾਲ ਕ੍ਰੌਲ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੇਜਨੇਟਡ ਜਾਂ ਡਾਇਨਾਮਿਕਲੀ ਲੋਡ ਕੀਤਾ ਗਿਆ ਕੰਟੈਂਟ ਅਸਲ ਵਿੱਚ ਕੈਪਚਰ ਕੀਤਾ ਗਿਆ ਹੈ।
- ਚੰਕਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਬੁਆਇਲਰਪਲੇਟ (boilerplate) ਨੂੰ ਹਟਾਓ। ਨੈਵੀਗੇਸ਼ਨ, ਇਸ਼ਤਿਹਾਰ, ਫੁੱਟਰ, ਅਤੇ ਵਾਰ-ਵਾਰ ਆਉਣ ਵਾਲੇ ਕਾਨੂੰਨੀ ਡਿਸਕਲੇਮਰਾਂ ਨੂੰ ਹਟਾ ਦਿਓ। ਜੇਕਰ ਕੋਈ ਵਾਕ ਹਰ ਪੇਜ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਸ਼ੋਰ (noise) ਹੈ।
- ਸਟ੍ਰਕਚਰ-ਅਵੇਅਰ ਚੰਕਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਹੈਡਿੰਗਾਂ, ਬੁਲੇਟ ਲਿਸਟਾਂ, ਅਤੇ ਟੇਬਲਾਂ ਦਾ ਸਨਮਾਨ ਕਰੋ। ਅੱਖਰਾਂ ਦੀ ਗਿਣਤੀ ਦੇ बजाय ਅਰਥ-ਪੂਰਨ ਸੀਮਾਵਾਂ (semantic boundaries) 'ਤੇ ਵੰਡੋ।
- ਰਿਚ ਮੈਟਾਡਾਟਾ ਨਾਲ ਜੋੜੋ। URL, ਕੈਪਚਰ ਮਿਤੀ, ਕੰਟੈਂਟ ਸ਼੍ਰੇਣੀ, ਅਤੇ ਵਰਜ਼ਨ ਸ਼ਾਮਲ ਕਰੋ। ਇਹਨਾਂ ਫੀਲਡਾਂ ਨੂੰ ਆਪਣੇ ਰਿਟ੍ਰੀਵਲ ਕੁਐਰੀਆਂ ਵਿੱਚ ਫਿਲਟਰ ਕਰਨ ਯੋਗ ਬਣਾਓ।
- ਡਾਟਾ ਦੀ ਅਸਥਿਰਤਾ ਦੇ ਅਧਾਰ 'ਤੇ ਰਿਫ੍ਰੈਸ਼ ਫ੍ਰੀਕੁਐਂਸੀ ਸੈੱਟ ਕਰੋ। ਉੱਚ-ਪਰਿਵਰਤਨ ਵਾਲੇ ਸਰੋਤਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਰੀ-ਕ੍ਰੌਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਥਿਰ ਆਰਕਾਈਵਜ਼ ਨੂੰ ਨਹੀਂ।
- ਸਿਰਫ਼ ਜੌਬ ਸਟੇਟਸ ਨੂੰ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਕੋਰਪਸ (corpus) ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ। ਇੱਕ ਪਾਈਪਲਾਈਨ ਕੂੜਾ ਪੈਦਾ ਕਰਦੇ ਹੋਏ ਵੀ ਕੋਡ ਜ਼ੀਰੋ ਨਾਲ ਬਾਹਰ ਨਿਕਲ ਸਕਦੀ ਹੈ। ਡ੍ਰਿਫਟ ਅਤੇ ਗੁਣਵੱਤਾ ਲਈ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਚੰਕਸ ਦੇ ਨਮੂਨਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ।
- ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਡਿਲੀਸ਼ਨ ਲਈ ਨਿਯਮ ਨਿਰਧਾਰਤ ਕਰੋ। ਜਦੋਂ ਕੋਈ ਸਰੋਤ ਪੇਜ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਉਸਦੇ ਚੰਕਸ ਨੂੰ ਡਿਲੀਟ ਕਰ ਦਿਓ। ਜਦੋਂ ਇਹ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਜਾਂ ਵਰਜ਼ਨ ਕਰੋ। ਅਣਜਾਣ (orphaned) ਡਾਟਾ ਇੱਕ ਚੁੱਪ ਕਤਲ ਕਰਨ ਵਾਲਾ ਹੈ।
ਐਮਬੈਡਿੰਗਜ਼ ਬਾਰੇ ਕੜਵਾ ਸੱਚ (The Hard Truth About Embeddings)
ਕੋਈ ਵੀ ਐਮਬੈਡਿੰਗ ਮਾਡਲ, ਚਾਹੇ ਉਹ ਕਿੰਨਾ ਵੀ ਉੱਨਤ ਕਿਉਂ ਨਾ ਹੋਵੇ, ਗੁੰਮ ਹੋਏ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜੇਕਰ ਤੁਹਾਡੀ ਫੀਡ ਅਜੇ ਵੀ ਪਿਛਲੇ ਸਾਲ ਦੀ ਕਾਪੀ ਰੱਖਦੀ ਹੈ, ਤਾਂ ਇਹ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾ ਸਕਦਾ ਕਿ ਪੇਜ ਪਿਛਲੇ ਹਫਤੇ ਅਪਡੇਟ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਟੇਬਲ ਰੋਅ ਦੇ ਸੰਦਰਭ ਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾ ਸਕਦਾ ਜੋ ਇੱਕ ਖਰਾਬ ਚੰਕ ਬਾਊਂਡਰੀ ਦੁਆਰਾ ਇਸਦੇ ਹੈਡਰ ਤੋਂ ਵੱਖ ਹੋ ਗਿਆ ਹੈ। ਐਮਬੈਡਿੰਗਜ਼ ਅਰਥ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦੇ ਹਨ, ਪਰ ਜਿੱਥੇ ਇਨਜੈਸਸ਼ਨ ਲੇਅਰ ਇਸਨੂੰ ਬਚਾਉਣ ਵਿੱਚ ਅਸਫਲ ਰਹੀ ਹੈ, ਉੱਥੇ ਉਹ ਅਰਥ ਪੈਦਾ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਰਿਟ੍ਰੀਵਲ ਦੀ ਗੁਣਵੱਤਾ ਇਨਜੈਸਸ਼ਨ ਲੇਅਰ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਉਹ ਲੇਅਰ ਇਹ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡਾ RAG ਸਿਸਟਮ ਇੱਕ ਉਪਯੋਗੀ ਟੂਲ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਵੈਕਟਰ ਡਾਟਾਬੇਸ ਦੇ ਪਿੱਛੇ ਇੱਕ ਭਰੋਸੇਮੰਦ ਝੂਠਾ ਹੈ।
ਅਸਲ ਸਿੱਖਿਆ (The Real Takeaway)
ਸਿਰਫ਼ ਪਾਈਪਲਾਈਨ ਡੈਸ਼ਬੋਰਡਾਂ ਰਾਹੀਂ ਇਨਜੈਸਸ਼ਨ ਦੀ ਸਿਹਤ ਨੂੰ ਮਾਪਣੀ ਬੰਦ ਕਰੋ। ਸਫਲ ਜੌਬਸ ਅਤੇ ਸਾਫ਼ ਲੌਗਸ ਇਸ ਗੱਲ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੇ ਕਿ ਤੁਹਾਡਾ ਕੋਰਪਸ ਸਾਫ਼ ਹੋਵੇਗਾ। ਡਾਟਾਬੇਸ ਖੋਲ੍ਹੋ ਅਤੇ ਉਹ ਅਸਲ ਚੰਕਸ ਪੜ੍ਹੋ ਜੋ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਪ੍ਰਾਪਤ ਕਰਨਗੇ। ਜੇਕਰ ਟੈਕਸਟ ਕਾਪੀਰਾਈਟ ਨੋਟਿਸਾਂ, ਟੁੱਟੀਆਂ ਹੋਈਆਂ ਟੇਬਲਾਂ ਅਤੇ ਪੁਰਾਣੇ ਪਾਲਿਸੀ ਪੇਜਾਂ ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਸਮੱਸਿਆ LLM ਨਹੀਂ ਹੈ। ਪਹਿਲਾਂ ਫੀਡ ਨੂੰ ਠੀਕ ਕਰੋ। ਬਾਕੀ ਸਭ ਕੁਝ ਕੂੜੇ ਦੇ ਉੱਪਰ ਟਿਊਨਿੰਗ ਕਰਨ ਦੇ ਬਰਾਬਰ ਹੈ।