ਤੁਹਾਡਾ RAG pipeline ਇੱਕ ਸਟੈਂਡਰਡ load test ਨੂੰ ਬਹੁਤ ਹੀ ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਪਾਰ ਕਰ ਲੈਂਦਾ ਹੈ। p95 latency ਸਹੀ ਲੱਗਦੀ ਹੈ। Error rates ਲਗਭਗ ਜ਼ੀਰੋ ਹਨ। ਫਿਰ ਵੀ, ਯੂਜ਼ਰਸ ਅਜਿਹੇ ਜਵਾਬਾਂ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ ਜੋ ਸਵਾਲ ਤੋਂ ਚੁੱਕ ਜਾਂਦੇ ਹਨ, ਅਜਿਹੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ ਜੋ ਮੌਜੂਦ ਨਹੀਂ ਹਨ, ਜਾਂ ਛੇ ਮਹੀਨੇ ਪਹਿਲਾਂ ਅਪਲੋਡ ਕੀਤੇ ਗਏ ਵ੍ਹਾਈਟ ਪੇਪਰ (white paper) ਵਿੱਚੋਂ ਅਣਪਛਾਤੇ ਪੈਰਾਗ੍ਰਾਫ ਕੱਢ ਲਿਆਉਂਦੇ ਹਨ। ਡੈਸ਼ਬੋਰਡ ਕਹਿੰਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਠੀਕ ਹੈ। ਪਰ ਅਨੁਭਵ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਹ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ।
ਇਹ ਅੰਤਰ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਰਵਾਇਤੀ performance testing request-response ਸਿਸਟਮਾਂ ਲਈ ਬਣਾਈ ਗਈ ਸੀ, ਨਾ ਕਿ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਲਈ ਜੋ ਸੋਚਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ REST endpoint 'ਤੇ ਇੱਕ ਹਜ਼ਾਰ ਸਮਾਨਾਂਤਰ (parallel) ਰਿਕਵੈਸਟਾਂ ਭੇਜਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਰਵਰ ਟਿਕ ਰਹੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਪਤਾ ਲੱਗਦਾ ਕਿ ਕੀ ਤੁਹਾਡਾ retrieval layer ਸਹੀ chunks ਲਿਆ ਰਿਹਾ ਹੈ, ਕੀ ਤੁਹਾਡਾ prompt template context ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ vector store ਖਾਲੀ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕੀ ਮਾਡਲ ਆਪੇ ਸਰੋਤਾਂ (sources) ਦੀ ਕਲਪਨਾ ਕਰਦਾ ਹੈ। ਸਟੈਂਡਰਡ load testing ਸਿਰਫ਼ ਰਫ਼ਤਾਰ ਨੂੰ ਮਾਪਦੀ ਹੈ। RAG ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਮੰਗ ਹੈ ਕਿ ਤੁਸੀਂ ਸਮਝ (understanding) ਨੂੰ ਮਾਪੋ।
Status Code 200 ਤੋਂ ਪਰੇ
ਇੱਕ ਆਮ API load test ਤਿੰਨ ਚੀਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ: availability, latency, ਅਤੇ throughput। ਇਹ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੀ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਇਸ ਵਿੱਚ ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਿਆ, ਅਤੇ ਇਹ ਕਿ ਉਹ ਕਿੰਨੇ ਸਮਾਨਾਂਤਰ ਯੂਜ਼ਰਸ ਦਾ ਬੋਝ ਸਹਿ ਸਕਿਆ। ਇੱਕ RAG ਐਪਲੀਕੇਸ਼ਨ ਲਈ, ਉਹ ਨੰਬਰ ਸਿਰਫ਼ ਸ਼ਰਤਾਂ ਹਨ, ਨਤੀਜੇ ਨਹੀਂ। ਇੱਕ ਤੇਜ਼ ਗਲਤ ਜਵਾਬ ਅਜੇ ਵੀ ਇੱਕ ਗਲਤ ਜਵਾਬ ਹੀ ਹੈ, ਅਤੇ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਗਲਤ ਜਵਾਬਾਂ ਦੀ ਕੀਮਤ ਹੌਲੀ ਜਵਾਬਾਂ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਹੁੰਦੀ ਹੈ।
RAG ਹਰ ਰਿਕਵੈਸਟ ਵਿੱਚ ਦੋ ਵੱਖਰੇ ਪੜਾਅ ਜੋੜਦਾ ਹੈ। ਪਹਿਲਾਂ, ਸਿਸਟਮ ਯੂਜ਼ਰ ਦੇ ਸਵਾਲ ਨੂੰ ਇੱਕ embedding ਵਿੱਚ ਬਦਲਦਾ ਹੈ, vector store ਨੂੰ ਕੁਐਰੀ (query) ਕਰਦਾ ਹੈ, ਅਤੇ context chunks ਦਾ ਇੱਕ ਸਮੂਹ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ। ਦੂਜਾ, ਇਹ ਉਹਨਾਂ chunks ਨੂੰ ਇੱਕ prompt ਵਿੱਚ ਭਰਦਾ ਹੈ, ਸਭ ਕੁਝ ਇੱਕ language model ਨੂੰ ਭੇਜਦਾ ਹੈ, ਅਤੇ completion ਨੂੰ stream ਕਰਕੇ ਵਾਪਸ ਭੇਜਦਾ ਹੈ। ਰਵਾਇਤੀ ਟੈਸਟ ਅਕਸਰ ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ "response time" ਮੈਟ੍ਰਿਕ ਵਿੱਚ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਉਹ retrieval engine ਅਤੇ generator ਨੂੰ ਇੱਕ black box ਵਾਂਗ ਮੰਨਦੇ ਹਨ।
ਤੁਹਾਨੂੰ ਉਸ ਬਾਕਸ ਨੂੰ ਖੋਲ੍ਹਣ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ vector database load ਦੇ ਅਧੀਨ ਹੌਲੀ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ retrieval latency ਵਧ ਜਾਂਦੀ ਹੈ। LLM ਸ਼ਾਇਦ ਅਜੇ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਵੇ, ਪਰ ਇਹ ਜਲਦੀ ਵਿੱਚ ਲਿਆਂਦੇ ਗਏ ਗਲਤ (garbage) context ਦੇ ਅਧਾਰ 'ਤੇ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਦੂਜੇ ਪਾਸੇ, vector search ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਕਿ LLM queue ਲੰਬੀ ਹੁੰਦੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ time-to-first-token ਵਧ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਯੂਜ਼ਰ ਲਿਪਕਦੇ ਹੋਏ ਕਰਸਰ ਨੂੰ ਦੇਖਦੇ ਰਹਿੰਦੇ ਹਨ। ਇੱਕ ਸਿੰਗਲ end-to-end timer ਇਹਨਾਂ ਦੋਵਾਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਲੁਕਾ ਲੈਂਦਾ ਹੈ।
ਸਿਰਫ਼ ਡਾਟਾਬੇਸ ਹੀ ਨਹੀਂ, ਬਲਕਿ Retrieval ਨੂੰ ਵੀ ਟੈਸਟ ਕਰੋ
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਇੱਕ ਤੇਜ਼ vector search benchmark ਚਲਾਉਂਦੀਆਂ ਹਨ ਅਤੇ retrieval layer ਦੇ ਟੈਸਟ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰਦੀਆਂ ਹਨ। ਉਹ benchmark ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਾਪਦਾ ਹੈ ਕਿ ਡਾਟਾਬੇਸ ਇੱਕ ਚੁਣੇ ਹੋਏ query ਲਈ nearest neighbors ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਘੱਟ ਹੀ ਇਹ ਮਾਪਦਾ ਹੈ ਕਿ ਕੀ ਉਹ neighbors ਅਸਲ ਵਿੱਚ ਜਵਾਬ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ।
Retrieval ਦੀ ਗੁਣਵੱਤਾ load ਦੇ ਨਾਲ ਸੂਖਮ ਤਰੀਕਿਆਂ ਨਾਲ ਬਦ