ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਅਜੇ ਵੀ ਆਪਣਾ ਪਹਿਲਾ ਰਿਟ੍ਰੀਵਲ ਪਾਈਪਲਾਈਨ (retrieval pipeline) ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਤਿਆਰ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਇੱਕ ਨਿਸ਼ਚਿਤ ਟੋਕਨ ਸੀਮਾ ਚੁਣਦੇ ਹਨ, ਸ਼ਾਇਦ 512, ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਇੱਕੋ ਜਿਹੇ ਬਲਾਕਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਬਲਾਕਾਂ ਨੂੰ ਵੈਕਟਰ ਡੇਟਾਬੇਸ (vector database) ਵਿੱਚ ਪਾ ਦਿੰਦੇ ਹਨ। ਸਧਾਰਨ ਪ੍ਰਸ਼ਨਾਂ ਵਾਲੇ ਛੋਟੇ ਡੇਟਾਸੈੱਟ 'ਤੇ, ਇਹ ਜਾਦੂਈ ਲੱਗਦਾ ਹੈ। ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ (production) ਵਿੱਚ, ਇਹ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।

ਜਦੋਂ ਕੋਈ ਕਲਾਜ਼ (clause) ਵਾਕ ਦੇ ਵਿਚਕਾਰ ਹੀ ਕੱਟ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕਾਨੂੰਨੀ ਇਕਰਾਰਨਾਮੇ (legal contracts) ਬੇਮਤਲਬ ਦੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਜੇਕਰ ਇੱਕ ਸਿੰਗਲ ਚੰਕ (chunk) ਤਿੰਨ ਅਸੰਬੰਧਿਤ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਆਪਣੇ ਅੰਦਰ ਸਮੋ ਲੈਂਦਾ ਹੈ, ਤਾਂ API ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਇੱਕ ਰੌਲੇ-ਰੱਪੇ ਵਾਲੇ ਮਿਸ਼ਰਣ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਸੈਗਮੈਂਟਾਂ ਵਿਚਕਾਰ ਕੋਈ ਓਵਰਲੈਪ (overlap) ਨਾ ਹੋਣ ਕਾਰਨ ਕਸਟਮਰ ਸਪੋਰਟ ਟਿਕਟਾਂ ਆਪਣਾ ਸਾਰਾ ਵਿਸ਼ਾ (narrative thread) ਗੁਆ ਲੈਂਦੀਆਂ ਹਨ। ਇਸਦਾ ਨਤੀਜਾ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਲੱਗਣਯੋਗ ਹੈ: ਵਧਿਆ ਹੋਇਆ ਲੇਟੈਂਸੀ (latency), ਕਮਜ਼ੋਰ ਰੀਕਾਲ (recall), ਅਤੇ ਅਜਿਹੇ ਉੱਤਰ ਜੋ ਜਨਰੇਟਰ ਨੂੰ ਹੈਲੂਸੀਨੇਟ (hallucinate) ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ।

ਅਸੀਂ ਆਪਣੇ ਰਿਟ੍ਰੀਵਲ ਲੇਅਰ ਨੂੰ ਖ਼ਤਮ ਕਰਕੇ ਦੁਬਾਰਾ ਬਣਾਇਆ। ਇਸਦਾ ਨਤੀਜਾ ਰੀਕਾਲ ਵਿੱਚ 78 ਪ੍ਰਤੀਸ਼ਤ ਤੋਂ 95 ਪ੍ਰਤੀਸ਼ਤ ਤੱਕ ਦਾ ਉਛਾਲ, ਲੇਟੈਂਸੀ ਵਿੱਚ 62 ਪ੍ਰਤੀਸ਼ਤ ਦੀ ਕਮੀ, ਅਤੇ ਇੱਕ ਅਜਿਹੀ ਪਾਈਪਲਾਈਨ ਸੀ ਜੋ ਅਖੀਰਕਾਰ ਇੱਕ ਵੀਕੈਂਡ ਹੈਕ (weekend hack) ਦੀ ਬਜਾਏ ਅਸਲੀ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਵਾਂਗ ਕੰਮ ਕਰਦੀ ਹੈ। ਇੱਥੇ ਉਹ ਦੱਸਿਆ ਗਿਆ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰ ਗਿਆ।

ਸਮਾਰਟ ਚੰਕਿੰਗ: ਟੋਕਨਾਂ ਦੀ ਬਜਾਏ ਢਾਂਚੇ ਨੂੰ ਤਰਜੀਹ

ਪਹਿਲੀ ਗਲਤੀ ਇਹ ਮੰਨਣਾ ਹੈ ਕਿ ਹਰ ਦਸਤਾਵੇਜ਼ ਇੱਕੋ ਭਾਸ਼ਾ ਬੋਲਦਾ ਹੈ। 512-ਟੋਕਨ ਦਾ ਚੰਕ (chunk) ਕਹਾਣੀ ਵਾਲੀ ਗਦਰੀ (narrative prose) ਲਈ ਤਾਂ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਹੋਰ ਕਿਤੇ ਨਹੀਂ। ਅਸੀਂ ਇੱਕ ਅਜਿਹੀ ਰਣਨੀਤੀ ਵੱਲ ਵਧੇ ਜੋ ਸਰੋਤ ਦੀ ਬਣਤਰ (anatomy) ਦਾ ਸਤਿਕਾਰ ਕਰਦੀ ਹੈ।

ਕਾਨੂੰਨੀ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ, ਅਸੀਂ ਰੀਕਰਸਿਵ ਚੰਕਿੰਗ (recursive chunking) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਐਲਗੋਰਿਦਮ ਪਹਿਲਾਂ ਸੈਕਸ਼ਨਾਂ ਅਤੇ ਆਰਟੀਕਲਾਂ ਵਰਗੀਆਂ ਉੱਚ-ਪੱਧਰੀ ਸੀਮਾਵਾਂ 'ਤੇ ਵੰਡਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਸੈਕਸ਼ਨ ਅਜੇ ਵੀ ਬਹੁਤ ਲੰਬਾ ਹੈ, ਤਾਂ ਇਹ ਸਬ-ਸੈਕਸ਼ਨਾਂ, ਫਿਰ ਪੈਰੇ, ਅਤੇ ਫਿਰ ਵਾਕਾਂ ਦੀ ਭਾਲ ਕਰਦਾ ਹੈ। ਇਹ ਕਲਾਜ਼ਾਂ ਦੀ ਤਰਕਪੂਰਨ ਨੈਸਟਿੰਗ (nesting) ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ। ਇੱਕ ਨਾਨ-ਕੰਪੀਟ ਐਗਰੀਮੈਂਟ (non-compete agreement) ਅਖੀਰ ਤੱਕ ਸਹੀ ਰਹਿੰਦਾ ਹੈ। ਪਰਿਭਾਸ਼ਾਵਾਂ ਇੰਡੈਮਨਿਟੀ ਸ਼ਰਤਾਂ (indemnity terms) ਵਿੱਚ ਨਹੀਂ ਮਿਲਦੀਆਂ।

API ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਲਈ ਸਟ੍ਰਕਚਰ-ਅਵੇਅਰ ਚੰਕਿੰਗ (structure-aware chunking) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਫੰਕਸ਼ਨ ਸਿਗਨੇਚਰ (function signature), ਉਸਦੀ ਪੈਰਾਮੀਟਰ ਟੇਬਲ, ਅਤੇ ਉਸਦੀ ਉਦਾਹਰਣ ਰਿਕਵੈਸਟ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਨਿਸ਼ਚਿਤ ਟੋਕਨ ਗਿਣਤੀ ਤੋਂ ਬਾਅਦ ਵੰਡਣ ਨਾਲ ਅਕਸਰ ਪੈਰਾਮੀਟਰ ਇੱਕ ਚੰਕ ਵਿੱਚ ਅਤੇ ਉਦਾਹਰਣਾਂ ਦੂਜੇ ਚੰਕ ਵਿੱਚ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ। ਇਸਦੀ ਬਜਾਏ ਅਸੀਂ ਦਸਤਾਵੇਜ਼ ਆਬਜੈਕਟ (document object) ਦੇ ਅਨੁਸਾਰ ਚੰਕਿੰਗ ਕਰਦੇ ਹਾਂ। ਇੱਕ ਚੰਕ ਇੱਕ ਪੂਰਾ ਐਂਡਪੁਆਇੰਟ (endpoint) ਜਾਂ ਇੱਕ ਸਿੰਗਲ ਫੰਕਸ਼ਨ ਨੂੰ ਰੱਖਦਾ ਹੈ। ਰਿਟ੍ਰੀਵਰ ਫਿਰ ਇੱਕ ਅਜਿਹਾ ਸਵੈ-ਨਿਰਭਰ ਹਵਾਲਾ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਪ੍ਰਸ਼ਨ ਦਾ ਉੱਤਰ ਦਿੰਦਾ ਹੈ।

ਸਪੋਰਟ ਟਿਕਟਾਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਸੈਮੈਂਟਿਕ ਚੰਕਿੰਗ (semantic chunking) ਲਈ ਢੁਕਵੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਟੋਕਨ ਸੀਮਾ 'ਤੇ ਕੱਟਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਪਤਾ ਲਗਾਵਾਂਗੇ ਕਿ ਵਿਸ਼ਾ (topic) ਕਿੱਥੇ ਬਦਲ ਰਿਹਾ ਹੈ। ਇੱਕ ਟਿਕਟ ਜੋ ਲੌਗਇਨ ਦੀ ਸ਼ਿਕਾਇਤ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬਿਲਿੰਗ ਦੇ ਸਵਾਲ ਵੱਲ ਮੁੜਦੀ ਹੈ, ਉਹ ਦੋ ਸਪਸ਼ਟ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੀ ਜਾਂਦੀ ਹੈ। ਹਰੇਕ ਹਿੱਸਾ ਲੋੜੀਂਦਾ ਮੈਟਾਡਾਟਾ (metadata) ਆਪਣੇ ਨਾਲ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਮਾਡਲ ਨੂੰ ਹੁਣ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ ਕਿ ਉਪਭੋਗਤਾ ਅਸਲ ਵਿੱਚ ਕਿਸ ਸਮੱਸਿਆ ਬਾਰੇ ਚਿੰਤਤ ਹੈ।

ਅੰਦਰੂਨੀ ਵਿਕੀ (Internal wikis) ਵਧੇਰੇ ਉਲਝਣ ਵਾਲੇ ਹੁੰਦੇ ਹਨ। ਉਹਨਾਂ ਵਿੱਚ ਗਦਰੀ, ਟੇਬਲਾਂ, ਡਾਇਗ੍ਰਾਮ ਅਤੇ ਇਨਬੈਡਡ ਥ੍ਰੈਡਸ (embedded threads) ਦਾ ਮਿਸ਼ਰਣ ਹੁੰਦਾ ਹੈ। ਇਹਨਾਂ ਲਈ, ਅਸੀਂ ਏਜੈਂਟਿਕ ਚੰਕਿੰਗ (agentic chunking) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਇੱਕ ਛੋਟਾ ਭਾਸ਼ਾ ਮਾਡਲ ਅੱਗੇ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਵਿਸ਼ਾ-ਵਸਤੂ ਪੂਰੀ ਇਕਾਈ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ। ਇਹ ਇੰਜੈਸਸ਼ਨ (ingestion) ਸਮੇਂ ਥੋੜ੍ਹਾ ਜ਼ਿਆਦਾ ਖਰਚਾ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਹਰ ਨਵੇਂ ਪੇਜ ਫਾਰਮੈਟ ਲਈ ਨਿਯਮਾਂ ਨੂੰ ਹੱਥ ਨਾਲ ਟਿਊਨ ਕਰਨ ਦੀ ਮਨੁੱਖੀ ਮਿਹਨਤ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ।

ਹਾਈਬ੍ਰਿਡ ਰਿਟ੍ਰੀਵਲ: ਆਪਣੇ ਸਾਰੇ ਪਹਿਲੂਆਂ ਨੂੰ ਕਵਰ ਕਰੋ

ਵੈਕਟਰ ਸਰਚ (Vector search) ਅਸਪਸ਼ਟ ਅਰਥਾਂ ਨੂੰ ਫੜਨ ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਸਲੋਅ ਅੱਪਲੋਡ ਬਾਰੇ ਪੁੱਛਦੇ ਹੋ, ਤਾਂ ਇਹ ਖੁਸ਼ੀ-ਖੁਸ਼ੀ ਲੇਟੈਂਸੀ ਅਤੇ ਬੈਂਡਵਿਡਥ ਬਾਰੇ ਪੈਰੇ ਵਾਪਸ ਕਰ ਦੇਵੇਗਾ। ਪਰ ਇਹ ਸਹੀ ਮੈਚ (exact matches) ਨੂੰ ਵਿਗਾੜਨ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਡਿਵੈਲਪਰ ਐਰਰ ਕੋਡ ERR_CONNECTION_REFUSED ਲੱਭਦਾ ਹੈ, ਤਾਂ ਡੈਂਸ ਐਮਬੈਡਿੰਗਜ਼ (dense embeddings) ਅਕਸਰ ਇਸਨੂੰ ਇੱਕ ਆਮ ਰੌਲੇ ਵਜੋਂ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ।

BM25, ਜੋ ਕਿ ਇੱਕ ਕਲਾਸਿਕ ਕੀਵਰਡ ਐਲਗੋਰਿਦਮ ਹੈ, ਇਸਦਾ ਉਲਟ ਕਰਦਾ ਹੈ। ਇਹ ਸਹੀ ਸਟ੍ਰਿੰਗਾਂ ਅਤੇ ਦੁਰਲੱਭ ਸ਼ਬਦਾਂ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਫੜਦਾ ਹੈ, ਫਿਰ ਵੀ ਇਹ ਸੈਮੈਂਟਿਕ ਸੂਖਮਤਾ (semantic nuance) ਨੂੰ ਗੁਆ ਦਿੰਦਾ ਹੈ। ਇਕਰਾਰਨਾਮੇ 'ਤੇ ਦਸਤਖਤ ਕਰਨ ਬਾਰੇ ਇੱਕ ਪੁੱਛਗਿੱਛ ਸ਼ਾਇਦ ਕਦੇ ਵੀ 'ਕੰਟਰੈਕਟ ਨੂੰ ਲਾਗੂ ਕਰਨ' (executing the contract) ਨਾਲ ਟੈਗ ਕੀਤੇ ਗਏ ਕੰਟੈਂਟ ਨੂੰ ਸਾਹਮਣੇ ਨਾ ਲਿਆਵੇ।