ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਆਪਣਾ ਪਹਿਲਾ ਰਿਟ੍ਰੀਵਲ ਸਿਸਟਮ (retrieval system) ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਹਰ ਦਸਤਾਵੇਜ਼ ਨੂੰ 512-ਟੋਕਨ ਦੇ ਨਿਸ਼ਚਿਤ ਚੰਕਸ (chunks) ਵਿੱਚ ਵੰਡਣਾ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵੈਕਟਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਪਾਉਣਾ, ਅਤੇ ਉਮੀਦ ਕਰਨਾ ਕਿ ਐਮਬੈਡਿੰਗ ਮਾਡਲ ਸਾਰਾ ਮੁਸ਼ਕਲ ਕੰਮ ਕਰ ਦੇਵੇਗਾ। ਉਹ ਉਮੀਦ ਤੁਹਾਨੂੰ ਇੱਕ ਡੈਮੋ (demo) ਤੱਕ ਤਾਂ ਲੈ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਅਸਲ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਮਿਲਣ 'ਤੇ ਇਹ ਟਿਕ ਨਹੀਂ ਸਕਦੀ।

ਪ੍ਰੋਡਕਸ਼ਨ (production) ਵਿੱਚ, ਇੱਕ ਕਾਨੂੰਨੀ ਇਕਰਾਰਨਾਮਾ ਉਦੋਂ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਦੇਣਦਾਰੀ ਕਲਾਜ਼ (liability clause) ਨੂੰ ਇਸਦੇ ਅਪਵਾਦਾਂ (exceptions) ਤੋਂ ਵੱਖ ਕਰ ਦਿੰਦੇ ਹੋ। API ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਉਦੋਂ ਬੇਕਾਰ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਕੋਡ ਦਾ ਇੱਕ ਨਮੂਨਾ (sample) ਉਸਦੇ ਫੰਕਸ਼ਨ ਸਿਗਨੇਚਰ (function signature) ਤੋਂ ਅਲੱਗ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਸਟਮਰ ਸਪੋਰਟ ਥ੍ਰੈਡ ਉਦੋਂ ਸ਼ੋਰ ਬਣ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸਿੰਗਲ ਸ਼ਿਕਾਇਤ ਨੂੰ ਉਸਦੀ ਗੱਲਬਾਤ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚੋਂ ਕੱਢ ਲੈਂਦੇ ਹੋ। ਸਮੱਸਿਆ ਸ਼ਾਇਦ ਪਾਈਪਲਾਈਨ ਦੇ ਅੰਤ ਵਿੱਚ ਬੈਠੇ ਲੈਂਗੂਏਜ ਮਾਡਲ ਦੀ ਨਹੀਂ ਹੁੰਦੀ। ਸਮੱਸਿਆ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਉਸਨੂੰ ਫੀਡ ਕਰਦੇ ਹੋ।

ਅਸੀਂ ਇਹ ਬਹੁਤ ਮੁਸ਼ਕਲ ਤਰੀਕੇ ਨਾਲ ਸਿੱਖਿਆ। ਸਾਡਾ ਸ਼ੁਰੂਆਤੀ ਰਿਟ੍ਰੀਵਲ ਲੇਅਰ (retrieval layer) ਸਟੈਂਡਰਡ ਲੱਗਦਾ ਸੀ ਪਰ ਇਸਦਾ ਵਿਵਹਾਰ ਅਸੰਗਤ ਸੀ। ਇਸ ਲਈ ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਸਧਾਰਨ ਵਿਚਾਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮੁੜ ਬਣਾਇਆ: ਰਿਟ੍ਰੀਵਲ ਨੂੰ ਇੱਕ ਮਾਪਿਆ ਹੋਇਆ ਬੁਨਿਆਦੀ ਢਾਂਚਾ (measured infrastructure) ਮੰਨੋ, ਜਾਦੂ ਨਹੀਂ। ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਿਆ, ਅਤੇ ਕਿਵੇਂ ਅਸੀਂ 95ਵੇਂ ਪਰਸੈਂਟਾਈਲ ਲੇਟੈਂਸੀ (95th-percentile latency) ਨੂੰ 850 ms ਤੋਂ ਘਟਾ ਕੇ 320 ms ਕਰਦੇ ਹੋਏ ਰੀਕਾਲ (recall) ਨੂੰ 95 ਪ੍ਰਤੀਸ਼ਤ ਤੱਕ ਪਹੁੰਚਾਇਆ।

ਫਿਕਸਡ-ਚੰਕ ਟ੍ਰੈਪ (The Fixed-Chunk Trap)

ਇੱਕਸਾਰ ਟੋਕਨ ਕਾਊਂਟ ਨੂੰ ਕੋਡ ਕਰਨਾ ਅਤੇ ਸਮਝਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਉਹ ਸਹੂਲਤ ਇੱਕ ਬੁਨਿਆਦੀ ਸੱਚਾਈ ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ: ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਇੱਕ ਢਾਂਚਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਉਸ ਢਾਂਚੇ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਗਨਲ (signal) ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹੋ।

ਇੱਕ ਦਸ-ਪੰਨੇ ਦੇ ਮਾਸਟਰ ਸਰਵਿਸ ਐਗਰੀਮੈਂਟ (master service agreement) ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ। 512-ਟੋਕਨ ਦਾ ਇੱਕ ਫਿਕਸਡ ਸਲਾਈਸ ਕਿਸੇ ਜ਼ਿੰਮੇਵਾਰੀ ਦੇ ਵਿਚਕਾਰ ਹੀ ਰੁਕ ਜਾਵੇਗਾ, ਜਿਸ ਨਾਲ ਇੱਕ ਕਲਾਜ਼ ਉਸੇ ਕੈਪ ਟੇਬਲ (cap table) ਤੋਂ ਵੱਖ ਹੋ ਜਾਵੇਗੀ ਜੋ ਇਸਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ। ਰਿਟ੍ਰੀਵਲ ਸਟੈਪ ਫਿਰ ਅਧੂਰਾ ਵਿਚਾਰ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਜਨਰੇਟਰ ਬਾਕੀ ਹਿੱਸੇ ਦੀ ਕਲਪਨਾ (hallucinate) ਕਰ ਲੈਂਦਾ ਹੈ। API ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਵਿੱਚ, ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਚੰਕ ਬੋਇਲਰਪਲੇਟ ਹੈਡਰਾਂ (boilerplate headers) ਨਾਲ ਐਮਬੈਡਿੰਗ ਨੂੰ ਘੱਟ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਹ ਖਾਸ ਮੈਥਡ ਦਬ ਜਾਂਦਾ ਹੈ ਜਿਸਦੀ ਡਿਵੈਲਪਰ ਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਸਪੋਰਟ ਟਿਕਟਾਂ ਵਿੱਚ, ਇੱਕ ਫਿਕਸਡ ਵਿੰਡੋ ਗੱਲਬਾਤ ਨੂੰ ਵਾਕਾਂ ਦੇ ਇੱਕ ਝੱਲੇ ਵਾਂਗ ਮੰਨਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਉਹ ਆਪਸੀ ਗੱਲਬਾਤ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਜੋ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਫੇਲ੍ਹ ਹੋਇਆ ਸੀ।

ਅਸੀਂ ਚੰਕ ਸਾਈਜ਼ (chunk size) ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਹਾਈਪਰਪੈਰਾਮੀਟਰ (hyperparameter) ਵਜੋਂ ਦੇਖਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਜਿਸਦਾ ਅਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦੇ ਸੀ। ਅਸੀਂ ਇਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਦੀ ਕਿਸਮ ਅਤੇ ਉਸਦੇ ਅੰਦਰਲੀ ਜਾਣਕਾਰੀ ਦੀ ਆਰਕੀਟੈਕਚਰ (information architecture) ਵਿਚਕਾਰ ਇੱਕ ਮੈਪਿੰਗ ਅਭਿਆਸ ਵਜੋਂ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ।

ਆਪਣੇ ਚੰਕਿੰਗ ਨੂੰ ਡੇਟਾ ਦੇ ਅਨੁਕੂਲ ਬਣਾਓ

ਇਸਦਾ ਹੱਲ ਇੱਕ ਸਹੀ ਚੰਕ ਸਾਈਜ਼ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਹੱਲ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਰਣਨੀਤੀਆਂ ਹਨ ਜੋ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਡੇਟਾ ਸ਼ੇਪਸ (data shapes) ਲਈ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।

ਕਾਨੂੰਨੀ ਦਸਤਾਵੇਜ਼ (Legal documents) ਹੁਣ ਰਿਕਰਸਿਵ ਸਪਲਿਟਿੰਗ (recursive splitting) ਤੋਂ ਗੁਜ਼ਰਦੇ ਹਨ। ਐਲਗੋਰਿਦਮ ਪਹਿ

ਉਪਭੋਗਤਾ ਆਦਰਸ਼ ਸਰਚ ਕੁਐਰੀਆਂ (search queries) ਨਹੀਂ ਲਿਖਦੇ। ਉਹ ਅਧੂਰੀਆਂ ਲੌਗ ਲਾਈਨਾਂ (log lines) ਪੇਸਟ ਕਰਦੇ ਹਨ। ਉਹ ਲਿਖਦੇ ਹਨ "ਇਹ ਖਰਾਬ ਹੈ।" ਉਹ ਅਜਿਹੀ ਸ਼ਬਦਾਵਲੀ (jargon) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਸੀ। ਜੇਕਰ ਤੁਸੀਂ ਕੱਚੀ ਕੁਐਰੀ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸ਼ੋਰ (noise) 'ਤੇ ਭਰੋਸਾ ਕਰ ਰਹੇ ਹੋ।

ਅਸੀਂ ਹੁਣ ਰੀਟ੍ਰੀਵਲ ਲੇਅਰ (retrieval layer) ਨੂੰ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਆਉਣ ਵਾਲੀ ਕੁਐਰੀ ਨੂੰ ਤਿੰਨ ਤੋਂ ਪੰਜ ਵੇਰੀਏਸ਼ਨਾਂ ਵਿੱਚ ਵਧਾ ਦਿੰਦੇ ਹਾਂ। ਇੱਕ ਵੇਰੀਏਸ਼ਨ ਸਿੱਧਾ ਪੈਰਾਫਰੇਜ਼ (paraphrase) ਹੋ ਸਕਦੀ ਹੈ। ਦੂਜੀ ਇੱਕ ਕਾਲਪਨਿਕ ਆਦਰਸ਼ ਦਸਤਾਵੇਜ਼ ਦਾ ਸਿਰਲੇਖ ਹੋ ਸਕਦੀ ਹੈ। ਤੀਜੀ ਗੱਲਬਾਤ ਵਾਲੇ ਫਿਲਰਾਂ ਨੂੰ ਹਟਾ ਕੇ ਤਕਨੀਕੀ ਕੀਵਰਡਸ ਨੂੰ ਇਕੱਠਾ ਕਰਦੀ ਹੈ। ਹਰੇਕ ਵੇਰੀਐਂਟ ਨੂੰ ਐਂਬੈਡ (embed) ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਰਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਅਸੀਂ ਉਮੀਦਵਾਰ ਪੂਲਾਂ (candidate pools) ਨੂੰ ਡਿਡੂਪਲੀਕੇਟ (deduplicate) ਅਤੇ ਮਰਜ ਕਰਦੇ ਹਾਂ।

ਇਹ ਮੁਫ਼ਤ ਨਹੀਂ ਹੈ। ਉਹ ਵਾਧੂ ਐਂਬੈਡਿੰਗ ਕਾਲਾਂ ਪੈਸੇ ਖਰਚ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਕੁਝ ਮਿਲੀਸੈਕਿੰਡ ਵਧਾ ਦਿੰਦੀਆਂ ਹਨ। ਪਰ ਰੀਕਾਲ (recall) 'ਤੇ ਇਸਦਾ ਪ੍ਰਭਾਵ ਸ਼ਾਨਦਾਰ ਸੀ: ਰੀਟ੍ਰੀਵਲ ਤੋਂ ਪਹਿਲਾਂ ਕੁਐਰੀਆਂ ਨੂੰ ਵਧਾਉਣ ਨਾਲ ਅਸੀਂ 78 ਪ੍ਰਤੀਸ਼ਤ ਤੋਂ 96 ਪ੍ਰਤੀਸ਼ਤ ਤੱਕ ਪਹੁੰਚ ਗਏ। ਕਿਉਂਕਿ ਬਿਹਤਰ ਰੀਟ੍ਰੀਵਲ ਜਨਰੇਸ਼ਨ ਵਿੰਡੋ (generation window) ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਨੂੰ ਸਹੀ ਸੰਦਰਭ (context) ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਅੰਤ ਵਿੱਚ ਪੈਸੇ ਬਚਾਏ। ਇੱਕ ਥੋੜ੍ਹਾ ਮਹਿੰਗਾ ਰੀਟ੍ਰੀਵਲ ਸਟੈਪ ਇੱਕ ਲੰਬੇ, ਭਰਮ (hallucinated) ਜਨਰੇਸ਼ਨ ਸਟੈਪ ਨਾਲੋਂ ਸਸਤਾ ਹੈ।

ਅੰਦਾਜ਼ੇ ਲਗਾਉਣਾ ਬੰਦ ਕਰੋ। ਸਰਚ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।

ਇੱਕ ਵਾਰ ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਸਹੀ ਚੰਕਿੰਗ (chunking), ਹਾਈਬ੍ਰਿਡ ਰੀਟ੍ਰੀਵਲ (hybrid retrieval), ਅਤੇ ਕੁਐਰੀ ਐਕਸਪੈਂਸ਼ਨ (query expansion) ਸੈੱਟ ਹੋ ਗਈ, ਤਾਂ ਅਸੀਂ ਫਿਰ ਵੀ ਇੱਕ ਗੁੰਝਲਦਾਰ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ। ਚੰਕ ਸਾਈਜ਼ (chunk size), ਚੰਕ ਓਵਰਲੈਪ (chunk overlap), ਟੌਪ-ਕੇ ਰੀਟ੍ਰੀਵਲ ਡੂੰਘਾਈ (top-k retrieval depth), ਰੀਰੈਂਕਰ ਕੱਟ-ਆਫ (reranker cutoffs), ਅਤੇ ਫਿਊਜ਼ਨ ਵੇਟਸ (fusion weights) ਸਭ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ। ਇੱਕ ਮੈਨੂਅਲ ਗਰਿੱਡ ਸਰਚ ਵਿੱਚ ਹਫ਼ਤੇ ਲੱਗ ਜਾਂਦੇ ਅਤੇ ਫਿਰ ਵੀ ਅਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਸਥਾਨਕ ਮੈਕਸੀਮਮ (local maximum) ਤੱਕ ਹੀ ਪਹੁੰਚ ਸਕਦੇ ਸੀ।

ਅਸੀਂ ਇਸ ਸਪੇਸ ਦੀ ਖੋਜ ਕਰਨ ਲਈ ਬੇਏਸੀਅਨ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ (Bayesian optimization) ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਹਰ ਕੰਬੀਨੇਸ਼ਨ ਦੀ exhaustive ਤਰੀਕੇ ਨਾਲ ਜਾਂਚ ਕਰਨ ਦੀ ਬਜਾਏ, ਸਰਚ ਐਲਗੋਰਿਦਮ ਇਸ ਗੱਲ ਦਾ ਅੰਦਾਜ਼ਾ ਰੱਖਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਵਾਅਦਿਆਂ ਵਾਲੇ ਖੇਤਰਾਂ ਵੱਲ ਵਧਦਾ ਹੈ।

ਇਸਦਾ ਆਉਟਪੁੱਟ ਕੋਈ ਇੱਕ ਸੰਪੂਰਨ ਸੈਟਿੰਗ ਨਹੀਂ ਹੈ। ਇਹ ਚੋਣਾਂ ਦਾ ਇੱਕ ਪਾਰੇਟੋ ਫਰੰਟੀਅਰ (Pareto frontier) ਹੈ। ਇੱਕ ਪਾਸੇ, ਸਾਡੇ ਹਾਈ-ਥਰੂਪੁੱਟ API ਸਪੋਰਟ ਐਂਡਪੁਆਇੰਟ ਲਈ ਇੱਕ ਲੀਨ (lean) ਕੌਂਫਿਗਰੇਸ਼ਨ ਹੈ: ਤੇਜ਼ ਇਨਫਰੈਂਸ (inference), ਦਰਮਿਆਨਾ ਰੀਕਾਲ, ਅਤੇ ਘੱਟ ਤੋਂ ਘੱਟ ਲੇਟੈਂਸੀ (latency)। ਦੂਜੇ ਪਾਸੇ, ਕਾਨੂੰਨੀ ਸਮੀਖਿਆ (legal review) ਲਈ ਇੱਕ ਅਗਰੈਸਿਵ (aggressive) ਕੌਂਫਿਗਰੇਸ਼ਨ ਹੈ: ਡੂੰਘਾ ਰੀਟ੍ਰੀਵਲ, ਭਾਰੀ ਰੀਰੈਂਕਿੰਗ, ਅਤੇ ਸਖ਼ਤ ਓਵਰਲੈਪ, ਜੋ ਪੂਰਨਤਾ ਲਈ ਮਿਲੀਸੈਕਿੰਡ ਦਾ ਤਿਆਗ ਕਰਦੀ ਹੈ। ਕਿਉਂਕਿ ਫਰੰਟੀਅਰ ਸਪੱਸ਼ਟ ਹੈ, ਅਸੀਂ ਇਹ ਕਹਿਣ ਦੀ ਬਜਾਏ ਕਿ ਇੱਕ ਹੀ ਸੈਟਿੰਗ ਸਭ ਲਈ ਠੀਕ ਹੈ, ਉਤਪਾਦ ਲਈ ਸਹੀ ਬਿੰਦੂ ਚੁਣ ਸਕਦੇ ਹਾਂ।

ਅਸਲ ਵਿੱਚ ਅੰਕੜੇ ਕਿਹੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ

ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਨੇ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਕਮਜ਼ੋਰ ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਇੱਕ ਮਾਪਯੋਗ ਪ੍ਰੋਡਕਸ਼ਨ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।

Recall at ten 78 ਪ੍ਰਤੀਸ਼ਤ ਤੋਂ ਵਧ ਕੇ 95 ਪ੍ਰਤੀਸ਼ਤ ਹੋ ਗਿਆ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਦੋਂ ਸਾਡੇ ਕੋਰਪਸ (corpus) ਵਿੱਚ ਸਹੀ ਉੱਤਰ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਵੀਹ ਵਿੱਚੋਂ ਉਨੀਂ ਵਾਰ ਇਸਨੂੰ ਲੱਭ ਲੈਂਦੇ ਹਾਂ।

95ਵੇਂ ਪਰਸੈਂਟਾਈਲ (percentile) 'ਤੇ ਲੇਟੈਂਸੀ 850 ms ਤੋਂ ਡਿੱਗ ਕੇ 320 ms ਹੋ ਗਈ। ਹਾਈਬ੍ਰਿਡ ਸਟੈਕ ਕਾਗਜ਼ 'ਤੇ ਭਾਰੀ ਲੱਗਦਾ ਹੈ, ਪਰ ਸਮਾਰਟ ਇੰਡੈਕਸਿੰਗ, ਛੋਟੇ ਰੀਰੈਂਕਰ, ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਹੀ ਅਗਰੈਸਿਵ ਚੰਕਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਨੇ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਤੇਜ਼ ਬਣਾ ਦਿੱਤਾ।

Hallucination rate—ਜਿਸਦੀ ਨਿਗਰਾਨੀ ਇੱਕ ਹੋਲਡ-ਆਊਟ ਗੋਲਡਨ ਡੇਟਾਸੈਟ 'ਤੇ ਮਨੁੱਖੀ ਐਨੋਟੇਟਰਾਂ ਦੁਆਰਾ ਕੀਤੀ ਗਈ ਸੀ—12 ਪ੍ਰਤੀਸ਼ਤ ਤੋਂ ਡਿੱਗ ਕੇ 3 ਪ੍ਰਤੀਸ਼ਤ ਹੋ ਗਿਆ। ਜਦੋਂ ਮਾਡਲ ਨੂੰ ਪੂਰਾ ਅਤੇ ਪ੍ਰਸੰਗਿਕ ਸੰਦਰਭ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਇਹ ਤੱਥਾਂ ਦੀ ਕਲਪਨਾ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।

ਪ੍ਰਤੀ ਕੁਐਰੀ ਲਾਗਤ $0.008 ਤੋਂ ਘਟ ਕੇ $0.005 ਹੋ ਗਈ। ਬਿਹਤਰ ਰੀਟ੍ਰੀਵਲ ਦਾ ਮਤਲਬ ਹੈ ਛੋਟੇ, ਵਧੇਰੇ ਫੋਕਸਡ LLM ਪ੍ਰੋਂਪਟ ਅਤੇ ਘੱਟ ਰਿਕਵਰੀ ਕੋਸ਼ਿਸ਼ਾਂ। ਕੁਐਰੀ ਐਕਸਪੈਂਸ਼ਨ 'ਤੇ ਵਾਧੂ ਐਂਬੈਡਿੰਗ ਖਰਚਾ ਜਨਰੇਸ਼ਨ ਵਿੱਚ ਹੋਣ ਵਾਲੀ ਬਚਤ ਦੇ ਸਾਹਮਣੇ ਬਹੁਤ ਘੱਟ ਹੈ।

ਇੱਕ ਗੋਲਡਨ ਡੇਟਾਸੈਟ ਬਣਾਓ ਅਤੇ ਰੀਟ੍ਰੀਵਲ ਨੂੰ ਕੋਡ ਵਾਂਗ ਮੰਨੋ

ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਤੋਂ ਇੱਕ ਚੀਜ਼ ਸਿੱਖਣੀ ਹੈ, ਤਾਂ ਉਹ ਹੈ ਮਾਪ ਦਾ ਅਨੁਸ਼ਾਸਨ। ਅਸੀਂ ਅਸਲ ਸਵਾਲਾਂ ਅਤੇ ਤਸਦੀਕ ਕੀਤੇ ਉੱਤਰਾਂ ਦੇ ਸਥਾਨਾਂ ਦਾ ਇੱਕ ਛੋਟਾ ਗੋਲਡਨ ਡੇਟਾਸੈਟ ਬਣਾਇਆ। ਕਿਸੇ ਵੀ ਤਬਦੀਲੀ ਦੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਉਸ ਡੇਟਾਸੈਟ 'ਤੇ ਚਲਾਈ ਜਾਂਦੀ ਹੈ। ਰੀਕਾਲ ਅਤੇ ਲੇਟੈਂਸੀ ਦੀ ਨਿਗਰਾਨੀ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਨਾ ਕਿ ਨੋਟਬੁੱਕ ਵਿੱਚ ਅੰਦਾਜ਼ੇ ਨਾਲ।

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

ਜੋ ਪਾਈਪਲਾਈਨ ਅਸੀਂ ਦੱਸੀ ਹੈ ਉਹ ਸਿਰਫ਼ ਸਿਧਾਂਤਕ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਅਸਲ ਲੇਖ [ਇੱਥੇ](https://dev.to/imus_d7584cbc8ee9b03