ਜ਼ਿਆਦਾਤਰ RAG ਟਿਊਟੋਰਿਅਲ ਉੱਥੇ ਹੀ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ ਜਿੱਥੇ ਅਸਲ ਪ੍ਰੋਡਕਸ਼ਨ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਆਪਣੇ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ 512-ਟੋਕਨ ਚੰਕਸ ਵਿੱਚ ਵੰਡਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਐਮਬੈਡਿੰਗ ਮਾਡਲ ਰਾਹੀਂ ਭੇਜਦੇ ਹੋ, ਅਤੇ ਸਧਾਰਨ top-k ਰਿਟ੍ਰੀਵਲ ਨਾਲ ਇੱਕ ਵੈਕਟਰ ਡਾਟਾਬੇਸ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹੋ। ਇੱਕ ਡੈਮੋ ਵਿੱਚ, ਇਹ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦਾ ਹੈ। ਬੋਟ ਨੂੰ ਆਪਣੀ ਕੰਪਨੀ ਦੀ ਛੁੱਟੀ ਦੀ ਨੀਤੀ ਬਾਰੇ ਪੁੱਛੋ ਅਤੇ ਇਹ ਇੱਕ ਸਪੱਸ਼ਟ ਪੈਰਾਗ੍ਰਾਫ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਹਰ ਕੋਈ ਸਿਰ ਹਿਲਾਉਂਦਾ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਡੈਮੋ ਝੂਠ ਬੋਲਦੇ ਹਨ।

ਪ੍ਰੋਡਕਸ਼ਨ ਹਰ ਸ਼ਾਰਟਕੱਟ ਨੂੰ ਉਜਾਗਰ ਕਰ ਦਿੰਦੀ ਹੈ। ਫਿਕਸਡ

ਯੂਜ਼ਰ ਦੇ ਸਵਾਲ ਦੇ ਕਈ ਵਰਜਨ ਬਣਾਉਣ ਲਈ query expansion ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਕੋਈ "server down" ਟਾਈਪ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ "service unavailable," "502 error," ਅਤੇ "connection timeout" ਲਈ ਵੀ ਖੋਜ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇਹਨਾਂ intent variants ਨੂੰ ਕਵਰ ਕਰਨ ਨਾਲ ਸਾਡਾ recall 78% ਤੋਂ ਵਧ ਕੇ 96% ਹੋ ਗਿਆ। ਇਹ ਇੱਕ ਸਿੰਗਲ ਸਟੈਪ ਹੈ, ਅਤੇ ਇਸਦਾ ਲਾਭ ਦੇ ਮੁਕਾਬਲੇ ਲਾਗਤ ਲਗਭਗ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ।

ਗੁੰਝਲਦਾਰ ਸਵਾਲਾਂ ਲਈ query decomposition ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜਦੋਂ ਕੋਈ ਯੂਜ਼ਰ ਕੁਝ ਅਜਿਹਾ ਪੁੱਛਦਾ ਹੈ ਜਿਵੇਂ ਕਿ “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?,” ਤਾਂ ਇਸਨੂੰ ਉਪ-ਸਵਾਲਾਂ (sub-questions) ਵਿੱਚ ਵੰਡ ਦਿਓ। ਇੱਕ ਉਪ-ਸਵਾਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਟੈਪਸ ਨੂੰ ਟਾਰਗੇਟ ਕਰਦਾ ਹੈ। ਦੂਜਾ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਵਿਸ਼ੇਸ਼ breaking changes ਨੂੰ ਟਾਰਗੇਟ ਕਰਦਾ ਹੈ। ਹਰ ਇੱਕ ਇੰਡੈਕਸ ਦੇ ਵੱਖਰੇ ਹਿੱਸੇ 'ਤੇ ਹਿੱਟ ਕਰਦਾ ਹੈ। ਡਾਊਨਸਟ੍ਰੀਮ ਲੈਂਗੂਏਜ ਮਾਡਲ ਇੱਕ ਸ਼ੋਰ ਵਾਲੇ context window ਵਿੱਚ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਬਜਾਏ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਰਿਟ੍ਰੀਵ ਕੀਤੇ ਗਏ chunks ਤੋਂ ਅੰਤਿਮ ਉੱਤਰ ਤਿਆਰ ਕਰਦਾ ਹੈ।

Hyperparameters ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਬੰਦ ਕਰੋ

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕਈ chunking strategies, hybrid retrieval, ਅਤੇ query transformation ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਇੱਕ combinatorial problem ਆ ਜਾਂਦੀ ਹੈ। Chunk size, overlap, fusion weights, reranker depth, ਅਤੇ expansion count ਸਾਰੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਨੂੰ ਅਲੱਗ ਤੋਂ ਬਦਲਣ ਨਾਲ ਦੂਜਾ ਵਿਗੜ ਜਾਂਦਾ ਹੈ। ਇਸ ਸਪੇਸ ਵਿੱਚ grid search ਕਰਨਾ ਬੇਕਾਰ ਅਤੇ ਹੌਲੀ ਹੈ।

ਇਸ ਦੀ ਬਜਾਏ Bayesian optimization ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਸਨੂੰ ਇੱਕ machine learning tuning job ਵਾਂਗ ਸਮਝੋ। ਆਪਣੇ objective ਨੂੰ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: latency ਨੂੰ ਇੱਕ ਸੀਮਾ ਦੇ ਅੰਦਰ ਰੱਖਦੇ ਹੋਏ recall ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰੋ। ਇੱਕ golden dataset ਬਣਾਓ — ਕੁਝ ਸੌ ਪ੍ਰਤੀਨਿਧ ਸਵਾਲ ਜਿੱਥੇ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕਿਹੜੇ chunks ਰਿਟ੍ਰੀਵ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਫਿਰ Bayesian search ਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ configuration space ਦੀ ਖੋਜ ਕਰਨ ਦਿਓ। ਇਹ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ ਉਸਦਾ ਇੱਕ probabilistic model ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਖੇਤਰਾਂ ਦਾ ਟੈਸਟ ਕਰਦਾ ਹੈ।

ਹਰ ਇੱਕ candidate configuration ਨੂੰ staging ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ golden dataset ਤੋਂ ਲੰਘਣਾ ਪਵੇਗਾ। ਜੇਕਰ ਨਵਾਂ chunk size recall ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜਾਂ ਇੱਕ ਭਾਰੀ reranker ਤੁਹਾਨੂੰ latency budget ਤੋਂ ਬਾਹਰ ਲੈ ਜਾਂਦਾ ਹੈ, ਤਾਂ optimization ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਫੜ ਲੈਂਦਾ ਹੈ। ਇਹ ਚਰਚਾ ਵਿੱਚ ਨਿੱਜੀ ਰਾਏ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਬਹਿਸ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਕਿ 256 ਜਾਂ 512 tokens "ਬਿਹਤਰ" ਹਨ ਅਤੇ ਨਤੀਜੇ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ।

ਨਤੀਜਾ

ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਬਦਲਾਅ ਦੇ ਨਤੀਜੇ ਬਿਲਕੁਲ ਉਵੇਂ ਹੀ ਮਿਲੇ ਜਿਵੇਂ ਅਸੀਂ ਉਮੀਦ ਕੀਤੀ ਸੀ।

  • Recall@10 78% ਤੋਂ ਵਧ ਕੇ 95% ਹੋ ਗਿਆ।
  • P95 latency 850 ms ਤੋਂ ਘਟ ਕੇ 320 ms ਹੋ ਗਈ।
  • Hallucination rate 12% ਤੋਂ ਘਟ ਕੇ 3% ਰਹਿ ਗਿਆ।
  • Cost per query ਵਿੱਚ 38% ਦੀ ਕਮੀ ਆਈ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਸ ਲਈ ਕਿਉਂਕਿ ਬਿਹਤਰ retrieval ਨੇ ਸਾਨੂੰ ਇੱਕ ਛੋਟੇ generation model ਅਤੇ ਘੱਟ prompt tokens ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ।

Latency ਵਿੱਚ ਕਮੀ ਨੇ ਟੀਮ ਦੇ ਕੁਝ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰ ਦਿੱਤਾ। Rerankers ਅਤੇ query expansion ਜੋੜਨ ਨਾਲ ਲੱਗਦਾ ਹੈ ਕਿ ਚੀਜ਼ਾਂ ਹੌਲੀ ਹੋ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਪਰ ਕਿਉਂਕਿ retrieval ਦੀ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ, ਇਸ ਲਈ generation model ਨੂੰ ਘੱਟ prompting, ਘੱਟ speculation, ਅਤੇ ਘੱਟ retries ਦੀ ਲੋੜ ਸੀ। ਚੰਗਾ retrieval ਹਰ ਚੀਜ਼ ਨੂੰ ਡਾਊਨਸਟ੍ਰੀਮ ਵਿੱਚ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ।

Retrieval ਨੂੰ Infrastructure ਵਾਂਗ ਸਮਝੋ

Retrieval ਕੋਈ ਅਜਿਹਾ notebook ਨਹੀਂ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਇੱਕ ਵਾਰ ਚਲਾ ਕੇ ਭੁੱਲ ਜਾਓ। ਇਹ infrastructure ਹੈ, ਅਤੇ ਇਸਨੂੰ code ਵਾਂਗ ਪ੍ਰਬਹਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਪਣੀਆਂ chunking strategies ਨੂੰ version ਕਰੋ। ਜਦੋਂ ਲੀਗਲ ਟੀਮ ਇੱਕ ਨਵਾਂ contract template ਜਾਰੀ ਕਰਦੀ ਹੈ, ਤਾਂ ਆਪਣੇ recursive splitter ਨੂੰ production ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ। ਆਪਣੇ golden dataset ਨੂੰ ਜਿਉਂਦੇ-ਜਾਗਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਜੋਂ ਰੱਖੋ, ਨਾ ਕਿ ਪਿਛਲੀ ਤਿਮਾਹੀ ਦੇ ਸਥਿਰ CSV ਵਜੋਂ। ਆਪਣੇ evaluations ਨੂੰ CI ਵਿੱਚ ਆਟੋਮੇਟ ਕਰੋ ਤਾਂ ਜੋ embedding model ਜਾਂ fusion weight ਨੂੰ ਬਦਲਣ ਵਾਲੇ pull request ਨੂੰ ਕਿਸੇ ਇਨਸਾਨ ਦੁਆਰਾ ਰਿਵਿਊ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ recall ਅਤੇ latency ਨੰਬਰਾਂ ਦੇ ਨਾਲ ਇੱਕ ਕਮੈਂਟ ਮਿਲੇ।

ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਕਦੇ ਨਹੀਂ ਪੁੱਛਣਗੇ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ embedding model ਚਲਾਉਂਦੇ ਹੋ। ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੀ chunking heuristic ਜਾਂ ਤੁਹਾਡੇ reranker architecture ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਹੋਵੇਗੀ। ਉਹਨਾਂ ਨੂੰ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਹੈ ਕਿ ਕੀ ਉੱਤਰ ਸਹੀ ਹੈ, ਕੀ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਕੀ ਉਹ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਅਜਿਹਾ pipeline ਬਣਾਓ ਜੋ ਉਹ ਭਰੋਸਾ ਕਮਾਵੇ, ਇਸਨੂੰ ਇਮਾਨਦਾਰੀ ਨਾਲ ਮਾਪੋ, ਅਤੇ retrieval ਨੂੰ ਇੱਕ ਬਾਕੀ ਰਹਿ ਗਈ ਚੀਜ਼ ਵਾਂਗ ਸਮਝਣਾ ਬੰਦ ਕਰੋ।

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community