ਲੋਕ RAG ਲਈ ਸ਼ਰਧਾਂਜਲੀਆਂ ਲਿਖ ਰਹੇ ਹਨ। ਤੁਸੀਂ ਸ਼ਾਇਦ ਹੁਣ ਤੱਕ ਸੁਰਖੀਆਂ ਦੇਖ ਲਈਆਂ ਹੋਣਗੀਆਂ। ਲੰਬੇ context windows ਨੇ ਇਸਨੂੰ ਖ਼ਤਮ ਕਰ ਦਿੱਤਾ। Agents ਨੇ ਇਸਦੀ ਜਗ੍ਹਾ ਲੈ ਲਈ। ਪੂਰਾ ਪੈਟਰਨ ਹੀ ਬੇਕਾਰ ਹੋ ਗਿਆ ਹੈ। ਸੱਚਾਈ ਵਧੇਰੇ ਸੀਮਤ ਅਤੇ ਕਿਤੇ ਜ਼ਿਆਦਾ ਉਪਯੋਗੀ ਹੈ। RAG ਮਰਿਆ ਨਹੀਂ ਹੈ। ਅਸਲ ਵਿੱਚ ਉਹ ਆਰਾਮਦਾਇਕ ਭਰਮ ਟੁੱਟਿਆ ਹੈ ਕਿ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਢੇਰ ਨੂੰ ਚੰਕਸ (chunks) ਵਿੱਚ ਵੰਡ ਸਕਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ vector database ਵਿੱਚ ਪਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਅਚਾਨਕ ਇੱਕ ਭਰੋਸੇਯੋਗ, ਸੱਚਾ AI ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਇਸਦਾ ਪ੍ਰਸਤਾਵ ਆਪਣੀ ਸਾਦਗੀ ਵਿੱਚ ਬਹੁਤ ਆਕਰਸ਼ਕ ਸੀ। ਆਪਣੇ ਗਿਆਨ ਦੇ ਅਧਾਰ (knowledge base) ਨੂੰ embed ਕਰੋ। ਇਸਨੂੰ ਇੱਕ LLM ਨਾਲ ਜੋੜੋ। ਇੱਕ ਸਵਾਲ ਪੁੱਛੋ, ਅਤੇ ਦੇਖੋ ਕਿ ਮਾਡਲ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਨਿਯੰਤਰਿਤ ਡੈਮੋ ਅਤੇ ਛੋਟੇ FAQ bots ਲਈ, ਇਹ ਸੱਚਮੁੱਚ ਕੰਮ ਕਰਦਾ ਸੀ। ਇੱਕ ਵੀਹ-ਪੰਨੇ ਦੀ help desk manual। ਇੱਕ ਸਾਫ਼-ਸੁਥਰੀ internal wiki। ਬੋਟ ਲਗਭਗ ਸਹੀ ਪੈਰਾਗ੍ਰਾਫ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਸੀ, ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਨੇ ਪਾਇਲਟ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇ ਦਿੱਤੀ। ਪਰ ਪਾਇਲਟ ਪ੍ਰੋਜੈਕਟ ਅਸਲ production ਨਹੀਂ ਹੁੰਦੇ। ਪ੍ਰੋਟੋਟਾਈਪਸ ਵਿੱਚ ਅਸਲ ਵਪਾਰਕ ਕਾਰਜਾਂ ਦੀਆਂ ਚੁਣੌਤੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ।

Production ਡੇਟਾ ਬਹੁਤ ਉਲਝਿਆ ਹੋਇਆ ਹੁੰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀ troubleshooting note ਦਰਜਨਾਂ ਫਾਈਲਾਂ ਵਿੱਚ ਕਾਪੀ ਕੀਤੀ ਹੋਈ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਦਾ ਸਮਾਂ (timestamp) ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਅਤੇ ਸਟੇਟਸ ਲੇਬਲ ਆਪਸੀ ਟਕਰਾਅ ਵਾਲੇ ਹੁੰਦੇ ਹਨ। ਇਸ ਵਿੱਚ ਗੁੰਝਲਦਾਰ ਟੇਬਲਾਂ ਹੁੰਦੇ ਹਨ ਜੋ ਪੰਨਿਆਂ 'ਤੇ ਫੈਲੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਕੋਈ splitter ਉਹਨਾਂ ਨੂੰ ਵਿਚਕਾਰੋਂ ਕੱਟਦਾ ਹੈ ਤਾਂ ਉਹ ਬੇਤੁਕਾ ਨਤੀਜਾ ਦਿੰਦੇ ਹਨ। ਇਹ ਬਿਨਾਂ ਕਿਸੇ ਮੁਆਵਜ਼ੇ ਦੇ ਵਿਰੋਧਾਭਾਸ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ। 2023 ਦੀ ਪਾਲਿਸੀ ਮੈਨੂਅਲ ਕੁਝ ਹੋਰ ਕਹਿੰਦੀ ਹੈ। ਮਾਰਚ 2024 ਦਾ ਸੋਧ (amendment) ਕੁਝ ਹੋਰ ਕਹਿੰਦਾ ਹੈ। ਪੁਰਾਣੀ PDF ਨੂੰ ਕਦੇ ਆਰਕਾਈਵ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ। ਚੰਕ (chunk), ਸਟੋਰ (store), ਅਤੇ ਰੀਟ੍ਰੀਵ (retrieve) ਦਾ ਨਾ ਸਮਝਦਾਰ ਪੈਟਰਨ ਹਰ ਪੈਰਾਗ੍ਰਾਫ ਨੂੰ ਇੱਕ ਅਲੱਗ ਟਾਪੂ ਵਾਂਗ ਮੰਨਦਾ ਹੈ। ਇਸ ਨੂੰ ਹਾਇਰਾਰਕੀ (hierarchy), ਵਰਜ਼ਨ ਹਿਸਟਰੀ, ਜਾਂ ਟਕਰਾਅ ਦੇ ਹੱਲ ਦੀ ਕੋਈ ਸਮਝ ਨਹੀਂ ਹੈ। ਮਾਡਲ ਇਸ ਲਈ ਹਲੂਸੀਨੇਟ (hallucinate) ਨਹੀਂ ਕਰਦਾ ਕਿਉਂਕਿ LLM ਖਰਾਬ ਹੈ, ਸਗੋਂ ਇਸ ਲਈ ਕਿਉਂਕਿ ਇਸਨੂੰ ਮਿਲਿਆ context ਟੁਕੜਿਆਂ ਵਿੱਚ ਸੀ, ਅਧੂਰਾ ਸੀ, ਜਾਂ ਬਿਲਕੁਲ ਗਲਤ ਸੀ।

ਕੁਝ ਨਿਰੀਖਕਾਂ ਦਾ ਦਾਅਵਾ ਹੈ ਕਿ ਮਿਲੀਅਨ-ਟੋਕਨ context windows ਰੀਟ੍ਰੀਵਲ (retrieval) ਨੂੰ ਬੇਕਾਰ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਦਾ ਤਰਕ ਸਿੱਧਾ ਹੈ। ਸਾਰਾ ਡੇਟਾ (corpus) ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਪਾ ਦਿਓ ਅਤੇ ਮਾਡਲ ਨੂੰ ਸਭ ਕੁਝ ਪੜ੍ਹਨ ਦਿਓ। ਇਹ ਸੁਣਨ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਲੱਗਦਾ ਹੈ। ਪਰ ਇਹ ਖ਼ਤਰਨਾਕ ਤੌਰ 'ਤੇ ਆਸ਼ਾਵਾਦੀ ਵੀ ਹੈ। ਇੱਕ ਮਾਡਲ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟੇ ਨਾਵਲ ਦੇ ਬਰਾਬਰ ਟੈਕਸਟ ਨੂੰ ਅੰਸ਼ਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਵੀ ਉਸ ਵਿਸ਼ਾਲਤਾ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਖਾਸ ਕਲਾਉਜ਼ (clause) ਲੱਭਣਾ ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰੀ ਸਮਰੱਥਾ ਹੈ। ਘਾਹ ਦੇ ਢੇਰ ਵਿੱਚ ਸੂਈ ਲੱਭਣਾ ਅਜੇ ਵੀ ਮੁਸ਼ਕਲ ਹੈ। ਲੰਬੇ context windows ਉਪਲਬਧ ਕੈਨਵਸ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ, ਪਰ ਉਹ ਇਹ ਫੈਸਲਾ ਲੈਣ ਦੀ ਮੁਸ਼ਕਲ ਕਾਰਜ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦੇ ਕਿ ਕੈਨਵਸ 'ਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਮੱਸਿਆ ਕਦੇ ਵੀ ਸਿਰਫ਼ ਰੀਟ੍ਰੀਵਲ ਦੀ ਨਹੀਂ ਸੀ। ਇਹ ਹਮੇਸ਼ਾ ਤੋਂ context assembly ਦੀ ਰਹੀ ਹੈ।

ਨਾ ਸਮਝਦਾਰ ਰੀਟ੍ਰੀਵਲ ਤੋਂ Context Engineering ਤੱਕ

2026 ਵਿੱਚ, ਇਹ ਖੇਤਰ ਪਰਿਪੱਕ ਹੋ ਰਿਹਾ ਹੈ। ਅਸੀਂ ਉਸ ਪੜਾਅ ਤੋਂ ਅੱਗੇ ਵਧ ਰਹੇ ਹਾਂ ਜਿੱਥੇ RAG ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਲੀਨੀਅਰ ਪਾਈਪਲਾਈਨ ਵਜੋਂ ਮੰਨਿਆ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਇੱਕ ਅਜਿਹੇ ਆਰਕੀਟੈਕਚਰ ਵੱਲ ਵਧ ਰਹੇ ਹਾਂ ਜੋ context ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਤਿਆਰ ਕੀਤੇ ਗਏ ਉਤਪਾਦ (engineered product) ਵਜੋਂ ਮੰਨਦਾ ਹੈ।

ਸ਼ੁੱਧ semantics ਦੀ ਬਜਾਏ ਹਾਈਬ੍ਰਿਡ ਸਰਚ (Hybrid search)। Semantic similarity意 (intent) ਨੂੰ ਸਮਝਣ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਪਰ ਇਹ ਸਹੀ ਪਛਾਣਕਰਤਾਵਾਂ (identifiers) ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਇੰਜੀਨੀਅਰ ERR_CONNECTION_REFUSED ਵਰਗਾ ਕੋਈ ਖਾਸ ਐਰਰ ਕੋਡ ਜਾਂ v3.2.1 ਵਰਗਾ ਸਾਫਟਵੇਅਰ ਵਰਜ਼ਨ ਪੁੱਛਦਾ ਹੈ, ਤਾਂ ਸ਼ੁੱਧ ਵੈਕਟਰ ਸਰਚ ਸੰਕਲਪਤ ਰੂਪ ਵਿੱਚ ਸਮਾਨ ਪਰ ਅਸਲ ਵਿੱਚ ਅਪ੍ਰਸੰਗਿਕ ਨਤੀਜਿਆਂ ਦੇ ਸਮੁੰਦਰ ਵਿੱਚ ਸਹੀ ਮੈਚ ਨੂੰ ਘਟਾ ਸਕਦੀ ਹੈ। ਇੱਥੇ ਵਿਕਾਸ ਸਿੱਧਾ ਹੈ। ਆਧੁਨਿਕ ਪ੍ਰਣਾਲੀਆਂ embeddings ਦੇ ਨਾਲ-ਨਾਲ BM25 ਜਾਂ inverted indexes ਵਰਗੀਆਂ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, keyword search ਦੇ ਨਾਲ-ਨਾਲ dense vector retrieval ਨੂੰ ਜੋੜਦੀਆਂ ਹਨ। ਸਹੀ ਨਾਮ, ਐਰਰ ਕੋਡ, ਵਰਜ਼ਨ ਸਟ੍ਰਿੰਗਾਂ, ਅਤੇ ਪ੍ਰੋਡਕਟ IDs ਨੂੰ keyword ਲੇਅਰ ਦੁਆਰਾ ਫੜ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸੰਕਲਪਤ ਸੂਖਮਤਾ (nuance) ਨੂੰ ਵੈਕਟਰ ਲੇਅਰ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ।

ਜਨਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਰੀ-ਰੈਂਕਿੰਗ (Reranking)। ਰੀਟ੍ਰੀਵਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ recall ਵੱਲ ਝੁਕਿਆ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਚਾਲੀ ਜਾਂ ਪੰਜਾਹ ਚੰਕਸ (chunks) ਕੱਢਦੇ ਹੋ ਕਿਉਂਕਿ ਤੁਸੀਂ ਉਸ ਇੱਕ ਸੁਨਹਿਰੀ ਪੈਰਾਗ੍ਰਾਫ ਨੂੰ ਗੁਆਉਣ ਤੋਂ ਡਰਦੇ ਹੋ। ਪਰ ਉਸ ਸਾਰੇ ਸ਼ੋਰ (noise) ਨੂੰ ਇੱਕ ਵੱਡੇ ਮਾਡਲ ਵਿੱਚ ਪਾਉਣਾ ਟੋਕਨਾਂ ਨੂੰ ਬਰਬਾਦ ਕਰਦਾ ਹੈ ਅਤੇ ਸਹੀ ਜਾਣਕਾਰੀ (signal) ਨੂੰ ਦਬਾ ਦਿੰਦਾ ਹੈ। ਰੀ-ਰੈਂਕਿੰਗ ਇਸਨੂੰ ਇੱਕ ਦੂਜੇ, ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੇ ਮਾਡਲ ਨਾਲ ਹੱਲ ਕਰਦਾ ਹੈ ਜੋ ਖਾਸ ਕੁਐਰੀ (query) ਦੇ ਵਿਰੁੱਧ ਹਰੇਕ ਉਮੀਦਵਾਰ ਦੀ ਪ੍ਰਸੰਗਿਕਤਾ ਨੂੰ ਸਕੋਰ ਕਰਦਾ ਹੈ। ਚੋਟੀ ਦੇ ਪੰਜ ਪੈਰੇ ਅੱਗੇ ਵਧਦੇ ਹਨ। ਬਾਕੀ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਰੀਟ੍ਰੀਵਲ ਅਤੇ ਜਨਰੇਸ਼ਨ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਟੀਕ ਫਿਲਟਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਮਹਿੰਗਾ ਰੀਜ਼ਨਿੰਗ ਮਾਡਲ ਸਿਰਫ਼ ਉਹੀ ਪੜ੍ਹੇ ਜੋ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਸੰਦਰਭਿਕ ਰੀਟ੍ਰੀਵਲ (Contextual retrieval) ਜੋ ਅਰਥ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ। ਚੰਕਿੰਗ (Chunking) ਇੱਕ ਹਿੰਸਕ ਕਾਰਜ ਹੈ। ਇੱਕ splitter ਕਿਸੇ ਪੈਰਾਗ੍ਰਾਫ ਨੂੰ ਉਸਦੇ ਸੈਕਸ਼ਨ ਹੈਡਰ, ਉਸਦੀ ਟੇਬਲ ਕੈਪਸ਼ਨ, ਉਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਕਾਨੂੰਨੀ ਡਿਸਕਲੇਮਰ, ਜਾਂ ਉਸ ਫੁੱਟਨੋਟ ਤੋਂ ਵੱਖ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਇਸਦੇ ਅਰਥ ਨੂੰ ਬਦਲਦਾ ਹੈ। Contextual retrieval ਇਸਨੂੰ ਮਾਡਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਟੁਕੜਿਆਂ ਨੂੰ ਅਮੀਰ ਬਣਾ ਕੇ ਘੱਟ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਮੂਲ (provenance) ਦਰਸਾਉਣ ਵਾਲਾ ਮੈਟਾਡਾਟਾ ਜੋੜਦੇ ਹੋ: ਇਹ ਅੰਸ਼ Q3 2024 ਦੀ ਘਟਨਾ ਰਿਪੋਰਟ, Database Outage ਸੈਕਸ਼ਨ, Severity Critical ਨਾਲ ਸਬੰਧਤ ਹੈ। ਮਾਡਲ ਸਿਰਫ਼ ਇੱਕ ਤੈਲ ਰਿਹਾ ਵਾਕ ਨਹੀਂ ਦੇਖਦਾ ਬਲਕਿ ਇੱਕ ਸਥਿਤ ਜਾਣਕਾਰੀ ਦੇ ਟੁਕੜੇ ਨੂੰ ਦੇਖਦਾ ਹੈ। ਟੁਕੜਾ ਆਪਣਾ ਸਹੀ ਸੰਦਰਭ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ।

ਇਰਾਦੇ (intent) ਅਨੁਸਾਰ ਮੋਡਿਊਲਰ ਰੂਟਿੰਗ। ਹਰ ਸਵਾਲ ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਨਾਲ ਭਰੇ ਵੈਕਟਰ ਸਟੋਰ ਵਿੱਚ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਕਰਨ ਬਾਰੇ ਪੁੱਛਣ ਵਾਲੇ ਯੂਜ਼ਰ ਨੂੰ ਸ਼ਾਇਦ ਇੱਕ ਹੈਲਪ ਆਰਟੀਕਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਪਿਛਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਉੱਤਰ-ਪੂਰਬ ਵਿੱਚ ਆਮਦਨ ਕਿਉਂ ਘਟੀ, ਇਹ ਪੁੱਛਣ ਵਾਲੇ ਯੂਜ਼ਰ ਨੂੰ ਡਾਟਾ ਵੇਅਰਹਾਊਸ ਵਿਰੁੱਧ SQL ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ ਖੇਤਰੀ ਵਿਕਰੀ ਰਣਨੀਤੀ ਬਾਰੇ ਅਰਥਵਤ ਰੂਪ ਵਿੱਚ ਸਮਾਨ ਪੈਰਾਗ੍ਰਾਫ ਦੀ। ਪਰਿਪੱਕ ਪ੍ਰਣਾਲੀਆਂ ਹੁਣ ਇਰਾਦੇ ਅਨੁਸਾਰ ਕੁਐਰੀਆਂ ਨੂੰ ਰੂਟ ਕਰਦੀਆਂ ਹਨ, ਉਚਿਤ ਟੂਲ ਦੀ ਚੋਣ ਕਰਦੀਆਂ ਹਨ। ਪ੍ਰਕਿਰਿਆ ਲਈ ਡਾਕੂਮੈਂਟੇਸ਼ਨ। ਸਟ੍ਰਕਚਰਡ ਐਨਾਲਿਟਿਕਸ ਲਈ ਰਿਲੇਸ਼ਨਲ ਡਾਟਾਬੇਸ। ਟ੍ਰੇਸ ਡੀਬੱਗਿੰਗ ਲਈ ਲੌਗ ਐਗਰੀਗੇਟਰ। ਲਾਈਵ ਸਟੇਟਸ ਲਈ APIs। ਰਿਟ੍ਰੀਵਲ ਲੇਅਰ ਇੱਕ ਡਿਸਪੈਚਰ ਬਣ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਮੋਨੋਕਲਚਰ।

ਏਜੈਂਟਿਕ ਰੀਜ਼ਨਿੰਗ ਲੂਪਸ। ਕੁਝ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਇੱਕ ਸਿੰਗਲ ਸਰਚ ਸਟੈਪ ਨਾਲ ਨਹੀਂ ਦਿੱਤਾ ਜਾ ਸਕਦਾ। ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਰੂਪ ਦੇਣ (reformulation) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਅਸਪਸ਼ਟ ਸ਼ੁਰੂਆਤੀ ਕੁਐਰੀ ਨੂੰ ਸਪਸ਼ਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਦਾਅਵਿਆਂ ਦੀ ਦੂਜੇ ਸਰੋਤ ਨਾਲ ਕਰੌਸ-ਚੈੱਕ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜੇਕਰ ਡਾਕੂਮੈਂਟੇਸ਼ਨ API ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਦੇ ਉਲਟ ਹੈ, ਤਾਂ ਪ੍ਰਣਾਲੀ ਵਿਚਕਾਰਲਾ ਰਸਤਾ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਟਕਰਾਅ ਨੂੰ ਫਲੈਗ ਕਰਦੀ ਹੈ। ਮਾਡਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਦੋਂ ਦੁਬਾਰਾ ਸਰਚ ਕਰਨਾ ਹੈ, ਕਦੋਂ ਆਪਣੀ ਕੁਐਰੀ ਨੂੰ ਸੁਧਾਰਨਾ ਹੈ, ਅਤੇ ਕਦੋਂ ਉਸ ਕੋਲ ਜਵਾਬ ਦੇਣ ਲਈ ਕਾਫ਼ੀ ਸਬੂਤ ਇਕੱਠੇ ਹੋ ਗਏ ਹਨ। ਇਹ ਵਨ-ਸ਼ੌਟ ਰਿਟ੍ਰੀਵਲ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸਟ੍ਰਕਚਰਡ ਰੀਜ਼ਨਿੰਗ ਹੈ ਜੋ ਸਰਚ ਨੂੰ ਇੱਕ ਸਬਰੂਟੀਨ ਵਜੋਂ ਵਰਤਦੀ ਹੈ।

ਰਿਲੇਸ਼ਨਲ ਸਵਾਲਾਂ ਲਈ GraphRAG। ਕੁਝ ਵਪਾਰਕ ਸਵਾਲ ਸੰਬੰਧਾਂ ਬਾਰੇ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਵਾਕਾਂ ਬਾਰੇ। ਕਿਸ ਕੰਪੋਨੈਂਟ ਦੀ विफलता (failure) ਨੇ ਕਿਹੜੇ ਡਾਊਨਸਟ੍ਰੀਮ ਅਲਰਟਸ ਨੂੰ ਟ੍ਰਿਗਰ ਕੀਤਾ? ਕਿਹੜਾ ਸਪਲਾਇਰ ਕਿਸ ਫੈਕਟਰੀ ਨੂੰ ਸਪਲਾਈ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਿਕਲਪਿਕ ਰਸਤਾ ਕੀ ਹੈ? ਸੰਗਠਨ ਵਿੱਚ ਕਿਸ ਕੋਲ ਇਸ ਖਾਸ ਬਜਟ ਲਾਈਨ 'ਤੇ ਫੈਸਲਾ ਲੈਣ ਦੇ ਅਧਿਕਾਰ ਹਨ? ਫਲੈਟ ਟੈਕਸਟ ਚੰਕਸ ਇਹਨਾਂ ਸਬੰਧਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਟੋਪੋਲੋਜੀ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਨੌਲੇਜ ਗ੍ਰਾਫ (Knowledge graphs) ਅਜਿਹਾ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਸਵਾਲ ਪ੍ਰਭਾਵ, ਲਿਨੀਏਜ, ਪੈਟਰਨ, ਜਾਂ ਨੈੱਟਵਰਕ ਸਟ੍ਰਕਚਰ ਬਾਰੇ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਗ੍ਰਾਫ ਰਾਹੀਂ ਜਾਣਕਾਰੀ ਲੈਣਾ ਅਜਿਹਾ ਸੰਦਰਭ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਪੈਰਾਗ੍ਰਾਫ ਰਿਟ੍ਰੀਵਲ ਨਾਲ ਨਕਲ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ।

ਉਹ ਸਵਾਲ ਜੋ ਅਸਲ ਵਿੱਚ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ

RAG ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀ ਗੱਲਬਾਤ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਪੁੱਛਣਾ ਬੰਦ ਕਰੋ ਕਿ ਇੱਕ ਆਮ RAG ਪਾਈਪਲਾਈਨ ਕਿਵੇਂ ਬਣਾਈ ਜਾਵੇ। ਇਹ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰੋ ਕਿ ਮਾਡਲ ਨੂੰ ਕਿਹੜਾ ਖਾਸ ਕੰਮ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਸਹੀ ਹੋਣ ਲਈ ਇਸਨੂੰ ਕਿਹੜੇ ਸਹੀ ਡਾਟਾ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ ਕਿ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਸੰਦਰਭ (context) ਕਾਫ਼ੀ ਹੈ। ਇਹ ਸਵਾਲ ਤੁਹਾਨੂੰ ਡਾਟਾ ਕੁਆਲਿਟੀ, ਸ਼ੀਮਾ ਡਿਜ਼ਾਈਨ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਲੂਪਸ, ਅਤੇ ਸਰੋਤ ਪ੍ਰੋਵੇਨੈਂਸ (source provenance) ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ। ਉਹ ਇਹ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਨੌਲੇਜ ਬੇਸ ਆਟੋਮੇਟਡ ਵਰਤੋਂ ਲਈ ਯੋਗ ਵੀ ਹੈ ਜਾਂ ਨਹੀਂ।

RAG ਹੁਣ ਕੋਈ ਸਿੰਗਲ ਲੀਨੀਅਰ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਰਹੀ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਇੱਕ ਵਾਰ ਇੰਸਟਾਲ ਕਰੋ ਅਤੇ ਭੁੱਲ ਜਾਓ। ਇਹ ਸਹੀ ਸੰਦਰਭ ਇਕੱਠਾ ਕਰਨ ਦਾ ਇੱਕ ਅਨੁਸ਼ਾਸਨ ਹੈ ਤਾਂ ਜੋ ਮਾਡਲ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਰੀਜ਼ਨ ਕਰ ਸਕੇ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਰਿਟ੍ਰੀਵਲ ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਸਮੱਸਿਆ ਵਜੋਂ ਦੇਖਣਾ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਇੰਪੋਰਟ ਵਜੋਂ।

ਟੂਲ ਹੋਰ ਵੀ ਤੇਜ਼ ਹੋ ਰਹੇ ਹਨ। ਸਰਚ ਹਾਈਬ੍ਰਿਡ ਹੈ। ਰੂਟਿੰਗ ਇੰਟੈਲੀਜੈਂਟ ਹੈ। ਰਿਟ੍ਰੀਵਲ ਰੈਂਕਡ, ਐਨਰਿਚਡ ਅਤੇ ਵੈਰੀਫਾਈਡ ਹੈ। 2022 ਦੇ ਸਾਧਾਰਨ ਭਰਮ ਟੁੱਟਣੇ ਜ਼ਰੂਰੀ ਸਨ ਤਾਂ ਜੋ ਕੁਝ ਅਸਲ ਵਿੱਚ ਲਾਭਦਾਇਕ ਉਹਨਾਂ ਦੀ ਜਗ੍ਹਾ ਲੈ ਸਕੇ। ਤੁਹਾਡਾ ਕੰਮ ਹੁਣ ਸਿਰਫ਼ ਡਾਟਾਬੇਸ ਤੋਂ ਟੈਕਸਟ ਰਿਟ੍ਰੀਵ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਇਹ ਅਜਿਹੇ ਸਿਸਟਮ ਬਣਾਉਣਾ ਹੈ ਜੋ ਮਾਡਲ ਦੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹੋਣ ਕਿ ਮਾਡਲ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਖੇਤਰ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ GyaanSetu ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ ਉਹਨਾਂ ਲੋਕਾਂ ਨਾਲ ਵਿਵਹਾਰਕ ਨੋਟਸ ਸਾਂਝੇ ਕਰਨ ਲਈ ਇੱਕ ਸਹੀ ਜਗ੍ਹਾ ਹੈ ਜੋ ਅਜਿਹੀਆਂ ਹੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਹਨ: https://t.me/GyaanSetuAi