AWS ਨੇ ਆਪਣੀ Bedrock ਸੇਵਾ ਵਿੱਚ query-aware compression ਜੋੜਿਆ ਹੈ, ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਭਾਸ਼ਾ ਮਾਡਲ (language model) ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਗੈਰ-ਜ਼ਰੂਰੀ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ chunks ਨੂੰ ਛਾਂਟਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਮਾਡਲ ਤੱਕ ਜਾਣ ਵਾਲੇ tokens ਨੂੰ ਘਟਾ ਕੇ, ਇਹ ਫੀਚਰ Retrieval-Augmented Generation (RAG) pipelines ਲਈ ਕੰਪਿਊਟ ਬਿੱਲ ਨੂੰ ਘੱਟ ਕਰ ਸਕਦਾ ਹੈ।

RAG pipelines ਪੈਸੇ ਕਿਉਂ ਖ਼ਰਚ ਕਰਦੀਆਂ ਹਨ

RAG ਸਿਸਟਮ ਪਹਿਲਾਂ ਇੱਕ knowledge base ਤੋਂ ਟੈਕਸਟ ਪੈਸੇਜ (passages) ਕੱਢਦੇ ਹਨ, ਫਿਰ ਉਪਭੋਗਤਾ ਦੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਉਹਨਾਂ ਪੈਸੇਜ ਨੂੰ ਇੱਕ generative model ਨੂੰ ਭੇਜਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਲਾਗੂਕਰਨਾਂ (implementations) ਵਿੱਚ ਹਰ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ chunk ਨੂੰ ਸਿੱਧਾ ਮਾਡਲ ਨੂੰ ਭੇਜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਭਾਵੇਂ ਟੈਕਸਟ ਦੇ ਵੱਡੇ ਹਿੱਸੇ ਦਾ ਕੁਐਰੀ (query) ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਾ ਹੋਵੇ। ਹਰ ਵਾਧੂ ਸ਼ਬਦ ਇੱਕ token ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮਾਡਲ ਦੁਆਰਾ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਗਿਆ ਹਰ token ਅੰਡਰਲਾਈਂਗ API 'ਤੇ ਚਾਰਜ ਵਧਾ ਦਿੰਦਾ ਹੈ। ਛੋਟੀਆਂ ਅਤੇ ਦਰਮਿਆਨੇ ਆਕਾਰ ਦੀਆਂ ਕੰਪਨੀਆਂ ਜੋ support bots ਜਾਂ ਅੰਦਰੂਨੀ ਸਰਚ ਟੂਲ ਚਲਾਉਂਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਲਈ token ਦਾ ਖਰਚਾ ਮਾਡਲ ਕਾਲਾਂ ਦੀ ਆਪਣੀ ਲਾਗਤ ਤੋਂ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਸਕਦਾ ਹੈ।

Query-aware compression ਕੀ ਕਰਦਾ ਹੈ

ਨਵੀਂ Bedrock ਸਮਰੱਥਾ retrieval ਅਤੇ generation ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਫਿਲਟਰਿੰਗ ਸਟੈਪ ਜੋੜਦੀ ਹੈ:

  • ਸਿਸਟਮ ਅਜੇ ਵੀ ਇੱਕ ਕੁਐਰੀ ਲਈ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਉਹੀ ਸਮੂਹ ਕੱਢਦਾ ਹੈ।
  • ਮਾਡਲ ਦੁਆਰਾ ਕਿਸੇ ਵੀ ਟੈਕਸਟ ਨੂੰ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਹਲਕਾ (lightweight) ਪ੍ਰੋਸੈਸਰ ਖਾਸ ਸਵਾਲ ਦੇ ਅਧਾਰ 'ਤੇ ਹਰੇਕ ਪੈਸੇਜ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ।
  • ਸਿਰਫ਼ ਉਹ ਹਿੱਸੇ ਹੀ ਰੱਖੇ ਜਾਂਦੇ ਹਨ ਜੋ ਪ੍ਰਸੰਗਿਕ (relevant) ਮੰਨੇ ਜਾਂਦੇ ਹਨ; ਬਾਕੀ ਸਭ ਨੂੰ ਸ਼ੋਰ (noise) ਵਜੋਂ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਤੁਹਾਨੂੰ ਕਿਸੇ ਨਵੇਂ index, embedding model, ਜਾਂ fine-tuned language model ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਬਦਲਾਅ ਸਿਰਫ਼ compression layer ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ pipeline ਨੂੰ ਦੁਬਾਰਾ ਜੋੜਨਾ (re-wiring) ਹੈ।

ਵਪਾਰਕ ਪ੍ਰਭਾਵ (Business impact)

ਕਿਉਂਕਿ ਮਾਡਲ ਨੂੰ ਭੇਜੇ ਗਏ ਟੈਕਸਟ ਦੀ ਮਾਤਰਾ ਦੇ ਨਾਲ token ਫੀਸ ਵਧਦੀ ਹੈ, ਇਸ ਲਈ ਗੈਰ-ਪ੍ਰਸੰਗਿਕ ਟੁਕੜਿਆਂ ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਬਿੱਲ ਨੂੰ ਲਾਈਨ-ਦਰ-ਲਾਈਨ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਉਹ ਕੰਪਨੀਆਂ ਜਿਨ੍ਹਾਂ ਨੇ ਵਰਤੋਂ ਵਧਣ ਦੇ ਨਾਲ ਆਪਣੇ RAG ਖਰਚਿਆਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੇ ਦੇਖਿਆ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਫਾਇਦਾ ਹੋਵੇਗਾ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

  • ਆਪਣੇ ਡੇਟਾ 'ਤੇ ਫੀਚਰ ਦਾ ਪਾਇਲਟ ਚਲਾਓ: ਇੱਕ ਸਟੈਂਡਰਡ RAG ਫਲੋਅ ਅਤੇ query-aware compression ਵਾਲੇ ਫਲੋਅ ਦਾ ਸਾਈਡ-ਬਾਈ-ਸਾਈਡ (side-by-side) ਟੈਸਟ ਕਰੋ। Token ਦੀ ਗਿਣਤੀ, latency, ਅਤੇ ਜਵਾਬ ਦੀ ਪ੍ਰਸੰਗਿਕਤਾ ਨੂੰ ਮਾਪੋ।
  • ਵੈਂਡਰ ਦੀ ਪਾਰਦਰਸ਼ਤਾ: ਤੀਜੀ-ਪੱਖੀ (third-party) RAG ਪਲੇਟਫਾਰਮਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੇ ਸਮੇਂ, ਪੁੱਛੋ ਕਿ ਕੀ ਉਹ ਆਪਣੇ retrieval pipelines ਵਿੱਚ compression ਜਾਂ filtering ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇੱਕ ਵੈਂਡਰ ਜੋ raw chunks ਭੇਜਦਾ ਹੈ, ਉਹ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਉੱਚੇ ਮਹੀਨਾਵਾਰ ਇਨਵੌਇਸ ਬਣਾਏਗਾ।

ਨਿਚੋੜ (Bottom line)

ਇੱਕ ਮਾਮੂਲੀ pipeline ਤਬਦੀਲੀ—ਮਾਡਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਗੈਰ-ਪ੍ਰਸੰਗਿਕ ਟੈਕਸਟ ਨੂੰ ਫਿਲਟਰ ਕਰਨਾ—ਇੱਕ ਲੁਕਵੇਂ ਖਰਚੇ ਨੂੰ ਇੱਕ ਕੰਟਰੋਲਯੋਗ ਲਾਈਨ ਆਈਟਮ ਵਿੱਚ ਬਦਲ ਸਕਦੀ ਹੈ। ਉਹ ਸੰਸਥਾਵਾਂ ਜੋ ਪਹਿਲਾਂ ਹੀ Bedrock-ਅਧਾਰਤ RAG ਲਈ ਭੁਗਤਾਨ ਕਰ ਰਹੀਆਂ ਹਨ, ਉਹਨਾਂ ਲਈ query-aware compression ਨੂੰ ਚਾਲੂ ਕਰਨਾ ਇੱਕ ਘੱਟ ਮਿਹਨਤ ਵਾਲਾ ਪ੍ਰਯੋਗ ਹੈ, ਪਰ ਕੋਈ ਵੀ ਬਚਤ ਤੁਹਾਡੇ ਖਾਸ ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਕਰੇਗੀ।