ਜ਼ਿਆਦਾਤਰ RAG ਪ੍ਰੋਟੋਟਾਈਪ ਅੰਦਰੋਂ ਇੱਕੋ ਜਿਹੇ ਲੱਗਦੇ ਹਨ। ਕੋਈ ਇੱਕ ਪਾਈਪਲਾਈਨ ਵਿੱਚ PDF ਪਾਉਂਦਾ ਹੈ, ਟੈਕਸਟ ਨੂੰ ਸਾਫ਼ 512-ਟੋਕਨਾਂ ਦੇ ਚੰਕਸ (chunks) ਵਿੱਚ ਕੱਟਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਵੈਕਟਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਪਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੰਮ ਪੂਰਾ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। ਇੱਕ ਡੈਮੋ ਲਈ, ਇਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗ ਸਕਦਾ ਹੈ। ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ, ਇਹ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਫਿਕਸਡ ਚੰਕ (fixed chunk) ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦਾ ਕਿ ਉਹ ਕੀ ਕੱਟ ਰਿਹਾ ਹੈ। ਇਹ ਇੱਕ ਕਾਨੂੰਨੀ ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਇੰਡੈਮਨਿਟੀ ਕਲਾਜ਼ (indemnity clause) ਦੇ ਵਿਚਕਾਰੋਂ ਹੀ ਵੰਡ ਦੇਵੇਗਾ। ਇਹ ਪੰਜ ਅਣਸੰਬੰਧਿਤ API endpoints ਨੂੰ ਇੱਕੋ ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਵਿੱਚ ਭਰ ਦੇਵੇਗਾ ਅਤੇ ਮਾਡਲ ਨੂੰ ਸ਼ੋਰ (noise) ਵਿੱਚ ਡੁਬੋ ਦੇਵੇਗਾ। ਇਹ ਤੁਹਾਨੂੰ ਲੋੜ ਤੋਂ ਵੱਧ ਫਰੈਗਮੈਂਟਸ (fragments) ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰੇਗਾ, ਜਿਸ ਨਾਲ ਲੇਟੈਂਸੀ (latency) ਵਧੇਗੀ ਅਤੇ ਟੋਕਨਾਂ ਦੀ ਬਰਬਾਦੀ ਹੋਵੇਗੀ। ਨਤੀਜਾ ਅਧੂਰੇ ਜਵਾਬ, ਹੈਲੂਸੀਨੇਸ਼ਨ (hallucinations), ਅਤੇ ਨਿਰਾਸ਼ ਉਪਭੋਗਤਾ ਹੁੰਦੇ ਹਨ।

ਅਸੀਂ ਆਪਣੇ ਰਿਟ੍ਰੀਵਲ ਲੇਅਰ (retrieval layer) ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖੋਲ੍ਹ ਕੇ ਦੁਬਾਰਾ ਬਣਾਇਆ। ਇਸ ਦਾ ਨਤੀਜਾ ਇੱਕ ਅਜਿਹਾ ਸਿਸਟਮ ਸੀ ਜਿਸ ਨੇ ਲੇਟੈਂਸੀ ਨੂੰ 40 ਪ੍ਰਤੀਸ਼ਤ ਘਟਾਉਂਦੇ ਹੋਏ 95 ਪ੍ਰਤੀਸ਼ਤ ਰੀਕਾਲ (recall) ਪ੍ਰਾਪਤ ਕੀਤਾ। ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਅਸੀਂ ਇਹ ਬਿਲਕੁਲ ਕਿਵੇਂ ਕੀਤਾ।

ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਫਿਕਸਡ ਚੰਕਸ ਕਿਉਂ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੇ ਹਨ

512-ਟੋਕਨ ਦਾ ਡਿਫੌਲਟ ਕੋਈ ਡਿਜ਼ਾਈਨ ਚੋਣ ਨਹੀਂ ਹੈ। ਇਹ ਸ਼ੁਰੂਆਤੀ ਐਮਬੈਡਿੰਗ ਮਾਡਲ ਕੰਟੈਕਸਟ ਵਿੰਡੋਜ਼ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ ਡਿਫੌਲਟਸ ਦਾ ਇੱਕ ਉਪ-ਉਤਪਾਦ (by-product) ਹੈ। ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਹੈ ਪਰ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਭਿਆਨਕ ਹੋ ਸਕਦਾ ਹੈ।

ਦਸਤਾਵੇਜ਼ ਇੱਕੋ ਜਿਹੇ ਨਹੀਂ ਹੁੰਦੇ। ਇੱਕ ਕਾਨੂੰਨੀ ਕਲਾਜ਼ ਬਿਨਾਂ ਕਿਸੇ ਸਪੱਸ਼ਟ ਬ੍ਰੇਕ ਦੇ ਸੱਤ ਸੌ ਟੋਕਨਾਂ ਤੱਕ ਲੰਬੀ ਹੋ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਪੰਜ ਸੌ ਬਾਰਾਂ 'ਤੇ ਕੱਟਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੋ ਅਧੂਰੇ ਫਰੈਗਮੈਂਟਸ ਬਣਾ ਦਿੰਦੇ ਹੋ। ਜਦੋਂ ਕੋਈ ਵਕੀਲ ਜਾਂ ਕੰਪਲਾਇੰਸ ਅਫਸਰ ਲਾਇਬਿਲਟੀ ਕੈਪਸ (liability caps) ਬਾਰੇ ਪੁੱਛਦਾ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਅੱਧਾ ਜ਼ੋਰ/ਜ਼ਿੰਮੇਵਾਰੀ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਭਾਸ਼ਾ ਮਾਡਲ ਗੁੰਮ ਹੋਏ ਅੱਧੇ ਹਿੱਸੇ ਬਾਰੇ ਹੈਲੂਸੀਨੇਸ਼ਨ ਕਰਦਾ ਹੈ, ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, ਇਹ ਮੰਨਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ ਕਿ ਕੈਪ ਮੌਜੂਦ ਹੈ।

API ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਨੂੰ ਉਲਟ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਇੱਕ ਪੰਜ ਸੌ-ਟੋਕਨ ਦਾ ਚੰਕ ਇੱਕ ਪੂਰਾ ਮੋਡਿਊਲ ਨਿਗਲ ਸਕਦਾ ਹੈ: ਆਥੈਂਟੀਕੇਸ਼ਨ ਹੈਡਰਜ਼ (authentication headers), ਐਰਰ ਕੋਡਸ (error codes), ਰੇਟ ਲਿਮਿਟਸ (rate limits), ਅਤੇ ਵੈੱਬਹੂਕ ਸਕੀਮਾ (webhook schemas)। ਜਦੋਂ ਕੋਈ ਡਿਵੈਲਪਰ ਪੁੱਛਦਾ ਹੈ ਕਿ AUTH_4027 ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਣਾ ਹੈ, ਤਾਂ ਰਿਟ੍ਰੀਵਰ ਅਣਸੰਬੰਧਿਤ ਫੰਕਸ਼ਨਾਂ ਦਾ ਇੱਕ ਮਿਸ਼ਰਣ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਮਾਡਲ ਕੋਲ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਆਮ ਜਵਾਬ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਇਲਾਵਾ ਕੋਈ ਹੋਰ ਚਾਰਾ ਨਹੀਂ ਹੁੰਦਾ।

ਮਾੜੀ ਚੰਕਿੰਗ ਲੇਟੈਂਸੀ ਨੂੰ ਵੀ ਵਧਾਉਂਦੀ ਹੈ। ਕਮਜ਼ੋਰ ਫਰੈਗਮੈਂਟਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਿਸੇ ਵਿਸ਼ੇ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਵੱਡੇ top-k ਦੀ ਲੋੜ ਹੈ। ਵਧੇਰੇ ਚੰਕਸ ਦਾ ਮਤਲਬ ਹੈ ਲੰਬੇ ਪ੍ਰੋਂਪਟਸ (prompts)। ਲੰਬੇ ਪ੍ਰੋਂਪਟਸ ਦਾ ਮਤਲਬ ਹੈ ਹੌਲੀ ਜਨਰੇਸ਼ਨ ਅਤੇ ਵਧੇਰੇ ਬਿੱਲ। ਉਪਭੋਗਤਾ ਅਨੁਭਵ (user experience) ਹੌਲੀ-ਹੌਲੀ ਖਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ।

ਚੰਕ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਦੇ ਅਨੁਕੂਲ ਬਣਾਓ

ਅਸੀਂ ਟੋਕਨਾਂ ਦੀ ਗਿਣਤੀ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਅਤੇ ਸਮੱਗਰੀ ਨੂੰ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਸਹੀ ਚੰਕਿੰਗ ਰਣਨੀਤੀ ਸਰੋਤ ਦੀ ਬਣਤਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਕਾਨੂੰਨੀ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ ਕਲਾਜ਼-ਜਾਣਕਾਰੀ ਵਾਲੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਨਾਲ ਰਿਕਰਸਿਵ ਕੈਰੇਕਟਰ ਚੰਕਿੰਗ (recursive character chunking) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਪਲਿਟਰ (splitter) ਲੜੀਵਾਰਤਾ (hierarchy) ਦਾ ਸਤਿਕਾਰ ਕਰਦਾ ਹੈ: ਇਹ ਪਹਿਲਾਂ ਸੈਕਸ਼ਨ ਹੈਡਰਾਂ, ਫਿਰ ਨੰਬਰ ਵਾਲੇ ਪੈਰ੍ਹਿਆਂ, ਅਤੇ ਫਿਰ ਕੁਦਰਤੀ ਵਾਕਾਂ ਦੇ ਬ੍ਰੇਕਾਂ ਨੂੰ ਲੱਭਦਾ ਹੈ। ਇਹ ਕਦੇ ਵੀ ਕਿਸੇ ਸਬ-ਕਲਾਜ਼ ਨੂੰ ਨਹੀਂ ਕੱਟਦਾ ਜਾਂ ਕਿਸੇ ਜ਼ਿੰਮੇਵਾਰੀ ਵਾਲੇ ਵਾਕ ਨੂੰ ਚੰਕਸ ਵਿੱਚ ਨਹੀਂ ਵੰਡਦਾ। ਜਦੋਂ ਤੁਸੀਂ ਇੰਡੈਮਨੀਫਿਕੇਸ਼ਨ ਬਾਰੇ ਕੋਈ ਪੈਰਾਗ੍ਰਾਫ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਪੂਰੀ ਕਲਾਜ਼, ਕੈਪ, ਅਤੇ ਅਪਵਾਦ ਮਿਲਦੇ ਹਨ।

API ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਲਈ ਸਟ੍ਰਕਚਰ-ਜਾਣਕਾਰੀ ਵਾਲੀ ਚੰਕਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਸੀਂ ਟ

We run both in parallel. BM25 and vector search operate independently over the same corpus. Their result lists are merged using Reciprocal Rank Fusion, which reorders candidates by balancing their positional ranks. You do not need calibrated weights. You simply get the precision of exact match and the intuition of semantic search in a single ranked list.

Then we add a cross-encoder reranker. This is a separate model that scores each passage against the original query, producing a relevance signal far finer than either retriever alone. It adds about 50 milliseconds of latency. It increases recall by 15 percent. If you care about answer quality, that trade is non-negotiable.

Query Expansion: Fix the Search Before It Starts

Bad queries are the dirty secret of every retrieval system. Users do not write like your embedding space. They type "it broke." They paste truncated stack traces. They use internal jargon your index has never seen.

We transform the query before it ever touches the index. First, we expand a single query into three to five diverse search terms. If the original is "payment failed," we also search for "transaction error," "billing declined," and "charge unsuccessful