ਅਸੀਂ ਛੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਤੇਜ਼ ਪ੍ਰਤੀਕਿਰਿਆ ਵਾਲੇ ਵੌਇਸ AI ਲਈ ਰੀਅਲ-ਟਾਈਮ ਸਿਸਟਮ ਕਿਵੇਂ ਬਣਾਇਆ

ਵੌਇਸ AI ਲਈ ਇਹ ਜਾਣਨਾ ਕਿ ਕਦੋਂ ਬੋਲਣਾ ਹੈ, ਸੁਣਨ ਵਿੱਚ ਲੱਗਣ ਨਾਲੋਂ ਔਖਾ ਹੈ. ਮਨੁੱਖੀ ਬੁਲਾਰੇ ਸਕਿੰਟ ਦੇ ਇੱਕ ਹਿੱਸੇ ਵਿੱਚ ਸਹਿਜਤਾ ਨਾਲ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਬੋਲਣ ਦਾ ਮੌਕਾ ਦੇ ਦਿੰਦੇ ਹਨ, ਪਰ ਪਿਛਲੇ ਵੌਇਸ AI ਸਿਸਟਮ ਇਸ ਲੈਅ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਦੇ ਸਨ. ਉਨ੍ਹਾਂ ਦੀ ਵਾਰੀ-ਅਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ ਵਾਰੀ ਪਛਾਣਕ ਕਹੇ ਜਾਂਦੇ ਛੋਟੇ ਮਾਡਲਾਂ ਉੱਤੇ ਨਿਰਭਰ ਸੀ, ਜਿਨ੍ਹਾਂ ਅੱਗੇ ਔਖਾ ਕੰਮ ਸੀ: ਬਹੁਤ ਜਲਦੀ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਉੱਤੇ ਵਰਤੋਂਕਾਰ ਦੀ ਗੱਲ ਕੱਟੀ ਜਾਂਦੀ ਸੀ ਅਤੇ ਬਹੁਤ ਦੇਰ ਨਾਲ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਉੱਤੇ ਜਵਾਬ ਸੁਸਤ ਲੱਗਦਾ ਸੀ. ਪਛਾਣਕ ਦੇ ਫ਼ੈਸਲਾ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਕਿਤੇ ਵੱਡਾ LLM ਕੰਮ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਸੀ.

ਸਾਡੀ ਤੀਜੀ ਪੀੜ੍ਹੀ ਦਾ ਵੌਇਸ ਸਿਸਟਮ GPT‑Live⁠ ਆਡੀਓ ਮਾਰਗ ਵਿੱਚੋਂ ਵਾਰੀ ਪਛਾਣਕ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ. ਇਸ ਦਾ ਵੌਇਸ ਮਾਡਲ ਫੁੱਲ-ਡੁਪਲੈਕਸ ਹੈ, ਜਿਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਇੱਕੋ ਵੇਲੇ ਸੁਣ ਅਤੇ ਬੋਲ ਸਕਦਾ ਹੈ. ਇਸ ਨਾਲ ਵੱਖਰੇ ਪਛਾਣਕ ਦੀ ਲੋੜ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਗੱਲਬਾਤ ਵਧੇਰੇ ਤਤਕਾਲ ਤੇ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ. ਜਦੋਂ ਡੂੰਘੀ ਰੀਜ਼ਨਿੰਗ ਜਾਂ ਟੂਲ ਦੀ ਵਰਤੋਂ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ GPT‑Live ਗੱਲਬਾਤ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ GPT‑5.5 ਵਰਗੇ ਸਾਡੇ ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਦੀ ਸਲਾਹ ਵੀ ਲੈ ਸਕਦਾ ਹੈ. ਇਹ ਸਮਰੱਥਾਵਾਂ ਮਿਲ ਕੇ GPT‑Live ਨੂੰ ਗੱਲਬਾਤੀ ਪ੍ਰਤੀਕਿਰਿਆ ਅਤੇ ਇੰਟੈਲੀਜੈਂਸ ਦਾ ਬੇਮਿਸਾਲ ਸੁਮੇਲ ਦਿੰਦੀਆਂ ਹਨ.

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

ਇਹ ਆਰਕੀਟੈਕਚਰ ਮੁੱਖ ਵੌਇਸ ਮਾਰਗ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ ਵਿਚਕਾਰ ਇੱਕ ਸਪਸ਼ਟ ਸੀਮਾ ਵੀ ਬਣਾਉਂਦੀ ਹੈ. ਇਸ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਦੀ ਤੇਜ਼ੀ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਵਿਹਾਰ ਅਨੁਕੂਲਿਤ ਕਰਨਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ. ਇਹ ਨੀਂਹ ChatGPT ਵੌਇਸ ਵਿੱਚ ਵਧ ਰਹੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਤਾਕਤ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ChatGPT ਡੈਸਕਟਾਪ ਐਪ ਰਾਹੀਂ ਆਪਣੇ ਕੰਪਿਊਟਰ ਨੂੰ ਕਾਬੂ ਕਰਨ ਅਤੇ ਆਪਣੇ ਏਜੰਟਾਂ ਨਾਲ ਤਾਲਮੇਲ ਕਰਨ ਦੀ ਹਾਲ ਹੀ ਵਿੱਚ ਜਾਰੀ ਸਮਰੱਥਾ ਸ਼ਾਮਲ ਹੈ.

ਇਸ ਲੇਖ ਵਿੱਚ ਅਸੀਂ ਦੱਸਾਂਗੇ ਕਿ ਪਹਿਲਾਂ ਦੇ ਵਾਰੀ-ਅਧਾਰਿਤ ਸਿਸਟਮ ਸਾਡੀਆਂ ਲੋੜਾਂ ਕਿਉਂ ਪੂਰੀਆਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸਨ ਅਤੇ ਅਸੀਂ ਹਰ ਪਰਤ ਉੱਤੇ ਤੇਜ਼ ਪ੍ਰਤੀਕਿਰਿਆ ਲਈ ਨਵਾਂ ਸਿਸਟਮ ਕਿਵੇਂ ਬਣਾਇਆ. ਅਸੀਂ ਸਥਿਤੀ-ਅਧਾਰਿਤ ਇਨਫਰੈਂਸ, ਗਤੀਸ਼ੀਲ ਸੰਦਰਭ ਪ੍ਰਬੰਧਨ, ਅਸਮਕਾਲੀ ਡੈਲੀਗੇਸ਼ਨ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ-ਪੱਧਰੀ ਅਨੁਕੂਲਨ ਬਾਰੇ ਦੱਸਾਂਗੇ, ਜੋ ਇਕੱਠੇ ਕੰਮ ਕਰਕੇ GPT‑Live ਨੂੰ ਸੱਚਮੁੱਚ ਲਾਈਵ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ.

ਪਹਿਲੀਆਂ ਵੌਇਸ ਆਰਕੀਟੈਕਚਰਾਂ ਨੂੰ ਲਿਖਤੀ LLM ਦਾ ਵਾਰੀ-ਅਧਾਰਿਤ ਸੁਭਾਅ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਿਆ ਸੀ, ਪਰ ਹਰ ਵਾਰੀ ਨੂੰ ਲਿਖਤ ਦੀ ਥਾਂ ਆਡੀਓ ਦੇ ਵੱਖਰੇ ਇਕੱਠੇ ਹਿੱਸੇ ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਸੀ. ਲੜੀਵਾਰ ਸਿਸਟਮਾਂ ਵਿੱਚ ਬੋਲੀ-ਤੋਂ-ਲਿਖਤ, LLM ਅਤੇ ਲਿਖਤ-ਤੋਂ-ਬੋਲੀ ਇੱਕ ਤੋਂ ਬਾਅਦ ਇੱਕ ਚੱਲਦੇ ਸਨ. ਇਸ ਲੜੀਵਾਰ ਪ੍ਰਕਿਰਿਆ ਨੇ ਦੇਰੀ ਵਧਾਈ ਅਤੇ ਲਹਿਜ਼ੇ ਤੇ ਰਫ਼ਤਾਰ ਵਰਗੇ ਸੰਕੇਤਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕੀਤਾ.

ਸਪੀਚ-ਟੂ-ਸਪੀਚ ਮਾਡਲਾਂ ਨੇ ਆਡੀਓ ਨੂੰ ਸਿੱਧਾ ਪ੍ਰੋਸੈਸ ਕਰਕੇ ਇਸ ਪਹੁੰਚ ਨੂੰ ਬਿਹਤਰ ਬਣਾਇਆ. ਮਾਡਲ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਬੋਲੀ ਸਮਝਣ ਅਤੇ ਬਣਾਉਣ ਦੀ ਸਿਖਲਾਈ ਦੇਣ ਨਾਲ ਉਹ ਲਿਖਤ ਬਣਾਉਣ ਦੌਰਾਨ ਗੁਆਚਦੇ ਵੇਰਵੇ ਬਚਾ ਸਕਿਆ ਅਤੇ ਵਧੇਰੇ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਿਆ. ਪਰ ਇਨਫਰੈਂਸ ਕਦੋਂ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ, ਇਹ ਫ਼ੈਸਲਾ ਕਰਨ ਲਈ ਸਿਸਟਮ ਅਜੇ ਵੀ ਵਾਰੀ ਪਛਾਣਕ ਉੱਤੇ ਨਿਰਭਰ ਸੀ. ਮਾਡਲ ਨੇ ਪਰਸਪਰ ਕਿਰਿਆ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਸੰਭਾਲਿਆ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਵਾਰੀ-ਅਧਾਰਿਤ ਰਹੀ.

GPT‑Live ਵੌਇਸ ਮਾਡਲ ਨੂੰ ਗੱਲਬਾਤ ਦਾ ਨਿਯੰਤਰਣ ਦਿੰਦਾ ਹੈ: ਆਡੀਓ ਮਾਡਲ ਵਿੱਚ ਆਉਂਦੀ ਅਤੇ ਬਾਹਰ ਜਾਂਦੀ ਰਹਿੰਦੀ ਹੈ, ਜਦਕਿ ਡੂੰਘੀ ਰੀਜ਼ਨਿੰਗ ਅਤੇ ਟੂਲ ਦੀ ਵਰਤੋਂ ਅਸਮਕਾਲੀ ਤਰੀਕੇ ਨਾਲ ਹੁੰਦੀ ਹੈ. ਸਿਸਟਮ ਦਾ ਮੁੱਖ ਕੰਮ ਬਿਨਾਂ ਰੁਕਾਵਟ ਮੀਡੀਆ ਚੱਕਰ ਨੂੰ ਜਾਰੀ ਰੱਖਣਾ ਹੈ. ਹੋਰ ਕੰਮ, ਜਿਵੇਂ ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਨੂੰ ਸੱਦਣਾ ਅਤੇ ਗੱਲਬਾਤ ਨੂੰ ਸਥਾਈ ਤੌਰ ਉੱਤੇ ਸੰਭਾਲਣਾ, ਲਾਈਵ ਮਾਰਗ ਤੋਂ ਬਾਹਰ ਹੁੰਦਾ ਹੈ.

ਇਸ ਮੀਡੀਆ ਚੱਕਰ ਨੂੰ ਬਿਨਾਂ ਰੁਕਾਵਟ ਜਾਰੀ ਰੱਖਣਾ ਹਮੇਸ਼ਾ ਸੌਖਾ ਨਹੀਂ ਹੁੰਦਾ. ਟ੍ਰਾਂਸਪੋਰਟ, ਪ੍ਰੋਸੈਸਿੰਗ ਜਾਂ ਇਨਫਰੈਂਸ ਵਿੱਚ ਕੋਈ ਵੀ ਦੇਰੀ ਸੁਣਨਯੋਗ ਵਿਰਾਮ ਜਾਂ ਵਿਗਾੜ ਬਣ ਸਕਦੀ ਹੈ. ਪਿਛਲਾ ਵਾਰੀ-ਅਧਾਰਿਤ ਸਿਸਟਮ ਆਡੀਓ ਦੇ ਇਕੱਠੇ ਹਿੱਸੇ ਦੇ ਪਹੁੰਚਣ ਦੇ ਸਮੇਂ ਵਿੱਚ ਕੁਝ ਫ਼ਰਕ ਸਹਿ ਸਕਦਾ ਸੀ. ਪਰ ਇੱਕ ਲਾਈਵ ਮੀਡੀਆ ਸਿਸਟਮ ਨੂੰ ਹਰ ਆਡੀਓ ਫਰੇਮ ਸਮੇਂ ਸਿਰ ਪਹੁੰਚਾਉਣਾ ਪੈਂਦਾ ਹੈ.

ChatGPT ਵੌਇਸ ਅਤੇ Realtime API ਉੱਤੇ ਪਹਿਲਾਂ ਕੀਤੇ ਕੰਮ ਨੇ ਸਾਨੂੰ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਨੀਂਹ ਦਿੱਤੀ. ਅਸੀਂ ਘੱਟ ਅਤੇ ਵਧੇਰੇ ਅਨੁਮਾਨਯੋਗ ਦੇਰੀ ਨਾਲ ਆਡੀਓ ਤੇ ਵੀਡੀਓ ਨੂੰ ਆਪਣੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਸਿੱਧਾ ਸਟ੍ਰੀਮ ਕਰਨ ਲਈ ਪਹਿਲਾਂ ਹੀ ਆਪਣਾ ਵੌਇਸ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਮੁੜ ਬਣਾਇਆ ਸੀ⁠. GPT‑Live ਨੇ ਇਸ ਡਿਜ਼ਾਈਨ ਨੂੰ ਹੋਰ ਅੱਗੇ ਵਧਾਇਆ ਅਤੇ ਲਗਾਤਾਰ ਗੱਲਬਾਤ ਲਈ ਬਣੇ ਨਵੇਂ ਸਥਿਤੀ-ਅਧਾਰਿਤ ਇਨਫਰੈਂਸ ਸਿਸਟਮ ਰਾਹੀਂ ਮੀਡੀਆ ਨੂੰ ਮਾਡਲ ਤੱਕ ਸਟ੍ਰੀਮ ਕੀਤਾ.

ਹਾਲਾਂਕਿ, ਸਟ੍ਰੀਮਿੰਗ ਇਨਫਰੈਂਸ ਹੱਲ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਸੀ. ਉਤਪਾਦਨ ਵਿੱਚ ਇਸ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚਲਾਉਣ ਲਈ ਸਾਨੂੰ ਕਲਾਇੰਟ ਤੋਂ ਇਨਫਰੈਂਸ ਸਟੈਕ ਤੱਕ ਆਡੀਓ ਦੀ ਭਰੋਸੇਯੋਗ ਡਿਲੀਵਰੀ ਯਕੀਨੀ ਬਣਾਉਣ ਅਤੇ ਸਥਿਤੀ ਕਾਇਮ ਰੱਖਣ ਦੀਆਂ ਚੁਣੌਤੀਆਂ ਨਾਲ ਨਜਿੱਠਣ ਦੀ ਵੀ ਲੋੜ ਸੀ.

ਅਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਮੀਡੀਆ ਪ੍ਰਵਾਹ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਕਾਰੋਬਾਰੀ ਤਰਕ ਤੋਂ ਖ਼ਾਸ ਤੌਰ ਉੱਤੇ ਵੱਖ ਕਰਨ ਦਾ ਫ਼ੈਸਲਾ ਕੀਤਾ. ਆਡੀਓ ਕਲਾਇੰਟ ਅਤੇ ਵੌਇਸ ਮਾਡਲ ਵਿਚਕਾਰ ਇੱਕ ਸਮਰਪਿਤ ਤੇਜ਼ ਮਾਰਗ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ. ਡੈਲੀਗੇਸ਼ਨ, ਟੂਲ ਦੀ ਵਰਤੋਂ ਅਤੇ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਅਸਮਕਾਲੀ RPC ਸੀਮਾ ਦੇ ਪਿੱਛੇ ਹੁੰਦੇ ਹਨ. ਹੌਲੀ ਟੂਲ ਕਾਲ ਜਾਂ ਬੈਕਐਂਡ ਸੇਵਾ ਆਪਣੇ ਨਤੀਜੇ ਵਿੱਚ ਦੇਰੀ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਮੀਡੀਆ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਰੋਕ ਨਹੀਂ ਸਕਦੀ.

ਇਹ ਵੱਖਰੇਵਾਂ ਸਿਸਟਮ ਨੂੰ ਅਨੁਕੂਲਣ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਸੀਮਾ ਵੀ ਦਿੰਦਾ ਹੈ. ਐਪਲੀਕੇਸ਼ਨਾਂ ਆਡੀਓ ਚਲਦਾ ਰੱਖਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਮੀਡੀਆ ਫਰੰਟਐਂਡ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ ਬਿਨਾਂ ਆਪਣੇ ਟੂਲ, ਨੀਤੀਆਂ ਅਤੇ ਬੈਕਐਂਡ ਵਿਹਾਰ ਬਦਲ ਸਕਦੀਆਂ ਹਨ. ਲਾਈਵ ਮਾਰਗ ਛੋਟਾ, ਅਨੁਮਾਨਯੋਗ ਅਤੇ ਉਸ ਕੰਮ ਉੱਤੇ ਕੇਂਦਰਿਤ ਰਹਿੰਦਾ ਹੈ ਜੋ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ.

ਅਸੀਂ ਪਿਛਲੇ Python asyncio ਲਾਗੂਕਰਨ ਦੀ ਥਾਂ ਮੀਡੀਆ ਫਰੰਟਐਂਡ ਅਤੇ ਇਨਫਰੈਂਸ ਤਰਕ Go ਵਿੱਚ ਲਿਖਿਆ. ਇਸ ਨਾਲ ਫਰੇਮ ਡਿਲੀਵਰੀ ਦੀ ਨਿਰਵਿਘਨਤਾ ਕਾਫ਼ੀ ਸੁਧਰੀ ਅਤੇ ਨਵੇਂ ਸਿਸਟਮ ਦਾ p95 ਪਿਛਲੇ ਸਿਸਟਮ ਦੇ p50 ਦੇ ਬਰਾਬਰ ਹੋ ਗਿਆ.

WebRTC ਟ੍ਰਾਂਸਪੋਰਟ ਦੀ ਨੀਂਹ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ. ਇਹ ਘੱਟ-ਦੇਰੀ ਵਾਲੇ ਮੀਡੀਆ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ ਅਤੇ ਪੈਕੇਟ ਗੁਆਚਣ, ਘੜੀ ਦੇ ਖਿਸਕਾਅ ਅਤੇ ਕਲਾਇੰਟ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੌਰਾਨ ਵੀ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ. ਜੇ ਪੈਕੇਟ ਦੇਰ ਨਾਲ ਪਹੁੰਚਣ, ਤਾਂ WebRTC ਖਾਲੀ ਥਾਂਵਾਂ ਰੋਕਣ ਲਈ ਆਡੀਓ ਨੂੰ ਹੌਲੀ ਜਿਹੀ ਲੰਮੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਰੀਅਲ-ਟਾਈਮ ਨਾਲ ਮੁੜ ਮੇਲ ਕਰਨ ਲਈ ਪਲੇਬੈਕ ਨੂੰ ਥੋੜ੍ਹੀ ਦੇਰ ਵਾਸਤੇ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ.

ਪੂਰੇ ਸਿਸਟਮ ਵਿੱਚ ਬਫਰਿੰਗ ਅਤੇ ਰੁਕਾਵਟ ਘੱਟ ਕਰਕੇ ਅਸੀਂ ਇੱਕ ਸਕਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਉਹ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਕਦੇ ਹਾਂ ਜਿਸ ਦੀ ਲੋਕ ਗੱਲਬਾਤ ਤੋਂ ਉਮੀਦ ਕਰਦੇ ਹਨ.

ਸਥਿਤੀ-ਅਧਾਰਿਤ ਇਨਫਰੈਂਸ ਦੀਆਂ ਆਪਣੀਆਂ ਸੰਚਾਲਨਕ ਚੋਣਾਂ ਹਨ. ਵੌਇਸ ਸੈਸ਼ਨ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਸਰਗਰਮ ਰਹਿ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਦਾ ਸੰਦਰਭ ਲਗਾਤਾਰ ਵਧਦਾ ਹੈ ਅਤੇ ਮੰਗ ਮੁਤਾਬਕ ਮਾਡਲ ਇੰਸਟੈਂਸ ਸ਼ੁਰੂ ਤੇ ਬੰਦ ਹੁੰਦੇ ਰਹਿੰਦੇ ਹਨ.

ਇਨ੍ਹਾਂ ਚਿੰਤਾਵਾਂ ਦੇ ਹੱਲ ਲਈ ਅਸੀਂ ਮਾਡਲ ਇੰਸਟੈਂਸਾਂ ਵਿਚਕਾਰ ਨਿਰਵਿਘਨ ਹਵਾਲਗੀ ਪ੍ਰਣਾਲੀ ਬਣਾਈ. ਤਬਦੀਲੀ ਦੀ ਲੋੜ ਪੈਣ ਉੱਤੇ ਅਸੀਂ ਮੌਜੂਦਾ ਇੰਸਟੈਂਸ ਦੇ ਨਾਲ ਬਦਲਵਾਂ ਮਾਡਲ ਇੰਸਟੈਂਸ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹਾਂ, ਉਸ ਨੂੰ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਸੰਦਰਭ ਨਾਲ ਪਹਿਲਾਂ ਭਰ ਸਕਦੇ ਹਾਂ, ਦੋਵਾਂ ਉੱਤੇ ਸਮਾਂਤਰ ਇਨਫਰੈਂਸ ਚਲਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਨਵਾਂ ਇੰਸਟੈਂਸ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਹੋਣ ਉੱਤੇ ਉਸ ਵੱਲ ਬਦਲ ਸਕਦੇ ਹਾਂ.

ਇਹੀ ਬੁਨਿਆਦੀ ਪ੍ਰਣਾਲੀ ਗਤੀਸ਼ੀਲ ਸੰਦਰਭ ਕੰਪੈਕਸ਼ਨ ਦਾ ਵੀ ਸਮਰਥਨ ਕਰਦੀ ਹੈ. ਗੱਲਬਾਤ ਜਾਰੀ ਰਹਿਣ ਨਾਲ ਇਸ ਦਾ ਇਕੱਠਾ ਹੋਇਆ ਸੰਦਰਭ ਆਖ਼ਰਕਾਰ ਮਾਡਲ ਦੀ ਸੰਦਰਭ ਸੀਮਾ ਤੋਂ ਵੱਧ ਸਕਦਾ ਹੈ. ਕੰਪੈਕਸ਼ਨ ਸੰਦਰਭ ਦਾ ਆਕਾਰ ਘਟਾ ਕੇ ਉਸ ਨੂੰ ਸੀਮਾ ਅੰਦਰ ਲਿਆ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਕਾਰਵਾਈ ਵਿੱਚ ਸਮਾਂ ਲੱਗਦਾ ਹੈ. ਕਿਉਂਕਿ ਇਹ ਪਿਛਲਾ ਸੰਦਰਭ ਬਦਲਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਮਾਡਲ ਦੇ ਕੀ-ਵੈਲਿਊ (KV) ਕੈਸ਼ ਨੂੰ ਵੀ ਅਵੈਧ ਕਰ ਦਿੰਦਾ ਹੈ, ਜੋ ਪਹਿਲਾਂ ਪ੍ਰੋਸੈਸ ਕੀਤੇ ਟੋਕਨਾਂ ਦੀਆਂ ਅਟੈਂਸ਼ਨ ਕੁੰਜੀਆਂ ਅਤੇ ਮੁੱਲ ਸੰਭਾਲਦਾ ਹੈ. ਉਸ ਸਥਿਤੀ ਨੂੰ ਮੁੜ ਬਣਾਉਣ ਲਈ ਨਵਾਂ ਪ੍ਰੀਫ਼ਿਲ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਵਾਧੂ ਦੇਰੀ ਹੁੰਦੀ ਹੈ.

ਇਸ ਦੀ ਥਾਂ ਅਸੀਂ ਕੰਪੈਕਸ਼ਨ ਨੂੰ ਇੱਕ ਹੋਰ ਪ੍ਰਬੰਧਿਤ ਤਬਦੀਲੀ ਮੰਨਦੇ ਹਾਂ. ਜਦੋਂ ਮੂਲ ਮਾਡਲ ਇੰਸਟੈਂਸ ਗੱਲਬਾਤ ਜਾਰੀ ਰੱਖਦਾ ਹੈ, ਸਿਸਟਮ ਸੰਦਰਭ ਦਾ ਕੰਪੈਕਸ਼ਨ ਕਰਦਾ ਹੈ ਅਤੇ ਨਵੇਂ ਸੰਦਰਭ ਨਾਲ ਬਦਲਵਾਂ ਮਾਡਲ ਇੰਸਟੈਂਸ ਤਿਆਰ ਕਰਦਾ ਹੈ. ਉਹ ਇੰਸਟੈਂਸ ਤਿਆਰ ਹੋਣ ਉੱਤੇ ਅਸੀਂ ਮੀਡੀਆ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਉਸ ਵੱਲ ਬਦਲ ਸਕਦੇ ਹਾਂ. ਇਸ ਨਾਲ ਸਿਸਟਮ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀਆਂ ਕਾਲਾਂ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਲੋੜ ਪੈਣ ਉੱਤੇ ਕੰਪੈਕਸ਼ਨ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ.

ਭਾਰੀ ਕੰਮ ਲਾਈਵ ਮਾਰਗ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਹਵਾਲਗੀ ਦੌਰਾਨ ਵੀ ਗੱਲਬਾਤ ਦੀ ਲੈਅ ਨਹੀਂ ਟੁੱਟਦੀ.

ਮੌਜੂਦਾ ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਨੂੰ ਵਰਤਣ ਦੀ GPT‑Live ਦੀ ਸਮਰੱਥਾ ਇਸ ਨੂੰ ਬਹੁਤ ਸ਼ਕਤੀ ਦਿੰਦੀ ਹੈ ਅਤੇ ਅਸਲ ਵਿੱਚ “ਗੱਲ ਕਰਨ” ਨੂੰ ਡੂੰਘੀ “ਸੋਚ” ਤੋਂ ਵੱਖ ਕਰ ਦਿੰਦੀ ਹੈ. ਪਰ ਇਸ ਦੋ-ਮਾਡਲ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਵਰਗਾ ਮਹਿਸੂਸ ਕਰਵਾਉਣ ਲਈ ਆਪਸ ਵਿੱਚ ਜੁੜੀਆਂ ਦੋ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਨੀਆਂ ਪਈਆਂ.

ਪਹਿਲਾਂ, ਨਤੀਜਿਆਂ ਨੂੰ ਚੱਲ ਰਹੀ ਗੱਲਬਾਤ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੋਣ ਲਈ ਕਾਫ਼ੀ ਛੇਤੀ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਸ ਲਈ ਸਾਨੂੰ ਰੂਟਿੰਗ ਅਤੇ ਪ੍ਰੌਂਪਟ ਪ੍ਰੋਸੈਸਿੰਗ ਤੋਂ ਲੈ ਕੇ ਇਨਫਰੈਂਸ ਤੇ ਟੂਲ ਕਾਲਾਂ ਤੱਕ ਸਾਰੇ ਡੈਲੀਗੇਸ਼ਨ ਮਾਰਗ ਦੀ ਦੇਰੀ ਘੱਟ ਕਰਨੀ ਪਈ. ਇਸੇ ਸਮੇਂ ਉਤਪਾਦ ਦੇ ਹੋਰ ਸਿਸਟਮਾਂ ਨੂੰ ਅਜੇ ਵੀ ਵੱਖਰੇ ਸੁਨੇਹੇ ਚਾਹੀਦੇ ਹਨ, ਇਸ ਲਈ ਸਾਨੂੰ ਚੱਲ ਰਹੀ ਗੱਲਬਾਤ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀ ਸਮਝ ਵਿੱਚ ਆਉਣ ਵਾਲੇ ਰੂਪ ਵਿੱਚ ਦਰਸਾਉਣਾ ਪਿਆ.

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

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

ਫਿਰ ਅਸੀਂ ਉਸ ਇਨਫਰੈਂਸ ਸੈਸ਼ਨ ਨੂੰ ਪੂਰੀ ਵੌਇਸ ਗੱਲਬਾਤ ਦੌਰਾਨ ਉਪਲਬਧ ਰੱਖਦੇ ਹਾਂ ਅਤੇ ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ ਲਈ ਸਥਿਰ ਸੈਸ਼ਨ ਅਫਿਨਿਟੀ ਵਰਤਦੇ ਹਾਂ. ਪ੍ਰੌਂਪਟ ਕੈਸ਼ਿੰਗ ਨਾਲ ਮਿਲ ਕੇ ਇਹ ਤਕਨੀਕਾਂ ਦੇਰੀ ਘਟਾਉਂਦੀਆਂ ਹਨ, ਜਦਕਿ ਵਰਕਰ ਦੀ ਨਾਕਾਮੀ ਤੋਂ ਉੱਭਰਨਾ ਸੌਖਾ ਰਹਿੰਦਾ ਹੈ.

ਰੀਜ਼ਨਿੰਗ ਦੀ ਮਿਹਨਤ, ਆਉਟਪੁੱਟ ਸੀਮਾਵਾਂ, ਟੂਲ ਸਕੀਮਾਂ ਅਤੇ ਮਾਡਲ-ਟੂਲ ਆਉਣ-ਜਾਣ ਵੀ ਇਹ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ ਕਿ ਗੱਲਬਾਤ ਨੂੰ ਲਾਭਦਾਇਕ ਨਤੀਜਾ ਕਦੋਂ ਮਿਲਦਾ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਤੇਜ਼ ਜਵਾਬਾਂ ਵਾਸਤੇ ਇਨ੍ਹਾਂ ਨਿਯੰਤਰਕਾਂ ਨੂੰ ਢਾਲਿਆ. ਡੈਲੀਗੇਸ਼ਨ ਮਾਰਗ ਉੱਤੇ ਲੋੜੀਂਦਾ ਕੰਮ ਘੱਟ ਕਰਕੇ ਅਸੀਂ ਵੌਇਸ ਮਾਡਲ ਨੂੰ ਆਪਣੇ ਅਤਿ-ਆਧੁਨਿਕ ਮਾਡਲਾਂ ਦੇ ਨਤੀਜੇ ਛੇਤੀ ਸ਼ਾਮਲ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਇਆ.

ਭਾਵੇਂ ਵੌਇਸ ਮਾਡਲ ਬੋਲੀ ਦੀਆਂ ਲਗਾਤਾਰ ਸਟ੍ਰੀਮਾਂ ਉੱਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਬਹੁਤ ਸਾਰੇ ਸਿਸਟਮ ਅਜੇ ਵੀ ਵਰਤੋਂਕਾਰ ਅਤੇ ਸਹਾਇਕ ਦੀਆਂ ਵਾਰੀਆਂ ਉੱਤੇ ਕੰਮ ਕਰਦੇ ਹਨ. ਇਨ੍ਹਾਂ ਵਿੱਚ ChatGPT ਦਾ ਗੱਲਬਾਤ ਇੰਟਰਫੇਸ ਅਤੇ ਸਾਡੇ ਵਿਸ਼ਲੇਸ਼ਣ ਤੇ ਸੁਰੱਖਿਆ ਢਾਂਚੇ ਦੇ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹਨ. ਇਸ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਇੱਕ-ਦੂਜੇ ਉੱਤੇ ਚੜ੍ਹਦੀ ਅਤੇ ਕਦੇ-ਕਦੇ ਅਸਪਸ਼ਟ ਗੱਲਬਾਤ ਨੂੰ ਵੱਖਰੇ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ.

ਆਡੀਓ ਪਹੁੰਚਣ ਉੱਤੇ ਸਰਵਰ ਅੰਸ਼ਕ ਲਿਖਤਾਂ ਅਤੇ ਸਮਾਂ ਸੰਕੇਤਾਂ ਨਾਲ ਅੰਦਾਜ਼ਾ ਲਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਬੁਲਾਰਾ ਬੋਲ ਰਿਹਾ ਹੈ ਅਤੇ ਸੁਨੇਹਿਆਂ ਦੀ ਕਤਾਰ ਬਣਾਉਂਦਾ ਹੈ. ਸਭ ਤੋਂ ਨਵਾਂ ਸੁਨੇਹਾ ਆਰਜ਼ੀ ਰਹਿੰਦਾ ਹੈ. ਹੋਰ ਬੋਲੀ ਪਹੁੰਚਣ ਨਾਲ ਇਸ ਦੀ ਲਿਖਤ, ਸਮਾਂ ਅਤੇ ਬੁਲਾਰੇ ਦੀ ਪਛਾਣ ਸਭ ਬਦਲ ਸਕਦੇ ਹਨ. ਜਦੋਂ ਕੋਈ ਬੁਲਾਰਾ ਇੰਨਾ ਸਮਾਂ ਬੋਲ ਚੁੱਕਦਾ ਹੈ ਕਿ ਪਛਾਣ ਭਰੋਸੇਯੋਗ ਹੋਵੇ, ਤਾਂ ਸਰਵਰ ਸੰਬੰਧਿਤ ਸੁਨੇਹੇ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦਿੰਦਾ ਹੈ.

ਬੁਲਾਰਿਆਂ ਦਾ ਇੱਕੋ ਵੇਲੇ ਬੋਲਣਾ ਇਸ ਨੂੰ ਹੋਰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦਾ ਹੈ. ਵਰਤੋਂਕਾਰ ਦੇ ਬੋਲਦਿਆਂ ਸਹਾਇਕ ਦੀ ਛੋਟੀ ਜਿਹੀ ਸਹਿਮਤੀ, ਜਿਵੇਂ “ਹੂੰ ਹਾਂ” ਜਾਂ “ਠੀਕ ਹੈ”, ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ ਉੱਤੇ ਵੱਖਰਾ ਸੁਨੇਹਾ ਨਹੀਂ ਬਣਨਾ ਚਾਹੀਦਾ. ਪਰ ਸਹਾਇਕ ਦੀ ਕੋਈ ਸਾਰਥਕ ਦਖ਼ਲਅੰਦਾਜ਼ੀ ਅਕਸਰ ਵੱਖਰਾ ਸੁਨੇਹਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ. ਇਸੇ ਤਰ੍ਹਾਂ, ਵਰਤੋਂਕਾਰ ਦੇ ਵਿਚਕਾਰ ਬੋਲਣ ਉੱਤੇ ਵੀ ਅਸੀਂ ਦਿਖਾਏ ਗਏ ਸਹਾਇਕ ਜਵਾਬਾਂ ਦੀ ਇਕਸਾਰਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਾਂ.

ਹਰ ਵੰਡ ਨੀਤੀ ਨਵੀਨਤਾ ਅਤੇ ਨਿਸ਼ਚਿਤਤਾ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਬਣਾਉਂਦੀ ਹੈ. ਬਹੁਤ ਜਲਦੀ ਅੰਤਿਮ ਰੂਪ ਦੇਣ ਨਾਲ ਇਤਿਹਾਸ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ ਅਤੇ ਕ੍ਰਮ ਅਸਥਿਰ ਹੁੰਦਾ ਹੈ. ਬਹੁਤ ਦੇਰ ਉਡੀਕਣ ਨਾਲ ਲਿਖਤ ਅਤੇ ਉਸ ਉੱਤੇ ਨਿਰਭਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਦੇਰੀ ਹੁੰਦੀ ਹੈ. ਇਸ ਲਈ ਸਿਸਟਮ ਗੱਲਬਾਤ ਦੇ ਦੋ ਸੰਬੰਧਿਤ ਦ੍ਰਿਸ਼ ਰੱਖਦਾ ਹੈ: ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਅਨੁਮਾਨੀ ਦ੍ਰਿਸ਼ ਅਤੇ ਕਹੀ ਗਈ ਗੱਲ ਦਾ ਅਧਿਕਾਰਤ ਰਿਕਾਰਡ. ਐਪਲੀਕੇਸ਼ਨ ਇੰਟਰਫੇਸ ਵਿੱਚ ਗੱਲਬਾਤ ਦਾ ਦ੍ਰਿਸ਼ ਅੱਪਡੇਟ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਅਨੁਮਾਨੀ ਦ੍ਰਿਸ਼ ਵਰਤਦਾ ਹੈ. ਪਰ ਵਿਸ਼ਲੇਸ਼ਣ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਲਾਗ ਦਰਜ ਕਰਨ ਲਈ ਅੰਤਿਮ ਲਿਖਤ ਚਾਹੀਦੀ ਹੈ.

ਇਸ ਨਾਲ ChatGPT ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਨੂੰ ਲਾਈਵ ਵੌਇਸ ਮਾਰਗ ਉੱਤੇ ਵਾਰੀ-ਵਾਰੀ ਬੋਲਣ ਦੀ ਪਾਬੰਦੀ ਲਗਾਏ ਬਿਨਾਂ ਗੱਲਬਾਤ ਦਾ ਸਥਿਰ ਦ੍ਰਿਸ਼ ਮਿਲਦਾ ਹੈ.

ਤੇਜ਼ ਪ੍ਰਤੀਕਿਰਿਆ ਵਰਤੋਂਕਾਰ ਦੇ ਬਟਨ ਦਬਾਉਂਦਿਆਂ ਹੀ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ. GPT‑Live ਨਾਲ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਿਸਟਮ ਨੂੰ ਮੀਡੀਆ ਮਾਰਗ ਸਥਾਪਤ ਕਰਨਾ ਅਤੇ ਮਾਡਲ ਰਾਹੀਂ ਆਡੀਓ ਭੇਜਣੀ ਸ਼ੁਰੂ ਕਰਨੀ ਪੈਂਦੀ ਹੈ. ਇਸ ਨਾਲ ਸ਼ੁਰੂਆਤੀ ਕ੍ਰਮ ਦਾ ਹਰ ਹਿੱਸਾ ਕ੍ਰਿਟਿਕਲ ਪਾਥ ਉੱਤੇ ਆ ਜਾਂਦਾ ਹੈ.

ਜਿਵੇਂ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, WebRTC ਰੀਅਲ-ਟਾਈਮ ਲਈ ਮਜ਼ਬੂਤ ਨੀਂਹ ਦਿੰਦਾ ਹੈ, ਪਰ ਸਧਾਰਨ WebRTC ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਹੈਰਾਨੀਜਨਕ ਤੌਰ ਉੱਤੇ ਕਈ ਪ੍ਰੋਟੋਕੋਲ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਨੈੱਟਵਰਕ ਰਾਊਂਡ ਟ੍ਰਿਪ ਚਾਹੀਦੇ ਹਨ. WebRTC ਉਸ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਬਣਿਆ ਸੀ ਜਦੋਂ QUIC ਵਰਗੇ ਬਾਅਦ ਦੇ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਰੂਪ ਦੇਣ ਵਿੱਚ ਨੈੱਟਵਰਕ ਆਉਣ-ਜਾਣ ਘੱਟ ਕਰਨ ਉੱਤੇ ਧਿਆਨ ਦਿੱਤਾ ਜਾਣ ਲੱਗਾ. ਇਸ ਕਰਕੇ ਇਸ ਦੇ ਅਧਾਰਭੂਤ ਪ੍ਰੋਟੋਕੋਲ ਇਕੱਠੇ ਵਰਤੇ ਜਾਣ ਉੱਤੇ ਕਈ ਵਾਰ ਇੱਕੋ ਕੰਮ ਦੁਹਰਾਉਂਦੇ ਹਨ. ਮਿਸਾਲ ਵਜੋਂ, ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਆਪਣੀ DoS-ਰੋਕੂ ਪ੍ਰਣਾਲੀ ਸੀ, ਭਾਵੇਂ ਪੂਰੇ WebRTC ਸਟੈਕ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਉਸ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ.

ਅਸੀਂ ਸਟੈਕ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਕੇ WebRTC Abridged Roundtrip Protocol (WARP⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)) ਵਿਕਸਿਤ ਕੀਤਾ, ਜੋ ਮੀਡੀਆ ਅਤੇ ਡਾਟਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਛੇ ਨੈੱਟਵਰਕ ਰਾਊਂਡ ਟ੍ਰਿਪ ਨੂੰ ਘਟਾ ਕੇ ਸਿਰਫ਼ ਇੱਕ ਕਰ ਦਿੰਦਾ ਹੈ. WARP ਪਿਛਲੀ ਅਨੁਕੂਲਤਾ ਬਰਕਰਾਰ ਰੱਖਣ ਵਾਲੇ ਪ੍ਰੋਟੋਕੋਲ ਸੁਧਾਰਾਂ ਨਾਲ ਇਹ ਕਰਦਾ ਹੈ: ICE ਉੱਤੇ DTLS ਹੈਂਡਸ਼ੇਕ ਪਿਗੀਬੈਕ ਕਰਨਾ(SPED⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)), ਵਧੇਰੇ ਤੇਜ਼ DTLS 1.3⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਹੈਂਡਸ਼ੇਕ ਵਰਤਣਾ, SCTP ਹੈਂਡਸ਼ੇਕ ਲਈ ਪਹਿਲਾਂ ਹੀ ਸਹਿਮਤੀ ਕਰਨਾ (SNAP⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)) ਅਤੇ DCEP⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵਰਤਣ ਦੀ ਥਾਂ ਡਾਟਾ ਚੈਨਲਾਂ ਲਈ ਪਹਿਲਾਂ ਹੀ ਸਹਿਮਤੀ ਕਰਨਾ.

ਅਸੀਂ WebRTC ਭਾਈਚਾਰੇ ਦੇ ਸਹਿਯੋਗੀਆਂ ਨਾਲ ਮਿਲ ਕੇ WARP ਨੂੰ ਖੁੱਲ੍ਹੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਸਮੂਹ ਵਜੋਂ ਤਿਆਰ ਕੀਤਾ, ਤਾਂ ਜੋ ਵਿਆਪਕ ਤਕਨੀਕੀ ਪਰਿਸਥਿਤਕੀ ਤੰਤਰ ਨੂੰ ਇਸ ਕੰਮ ਦਾ ਲਾਭ ਮਿਲ ਸਕੇ. ਅਸੀਂ IETF ਦੇ TSVWG ਕਾਰਜ ਸਮੂਹ ਰਾਹੀਂ ਪ੍ਰਸਤਾਵਾਂ ਨੂੰ ਅੱਗੇ ਵਧਾ ਰਹੇ ਹਾਂ. libwebrtc ਅਤੇ Pion ਦੋਵਾਂ ਵਿੱਚ WARP ਸਮਰਥਨ ਪਹਿਲਾਂ ਹੀ ਜੋੜਿਆ ਜਾ ਚੁੱਕਾ ਹੈ ਅਤੇ ਹੋਰ WebRTC ਲਾਗੂਕਰਨਾਂ ਉੱਤੇ ਕੰਮ ਚੱਲ ਰਿਹਾ ਹੈ.

ਮੀਡੀਆ ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਇੱਕ ਬਾਕੀ ਦੇਰੀ ਸਾਫ਼ ਨਜ਼ਰ ਆਈ: WebRTC ਦੇ ਕਨੈਕਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ SDP ਮਾਪਦੰਡ ਸਾਂਝੇ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਸੰਕੇਤਕ ਅਦਾਨ-ਪ੍ਰਦਾਨ. ਉਸ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ ਕ੍ਰਿਟਿਕਲ ਪਾਥ ਤੋਂ ਹਟਾਉਣ ਲਈ ਅਸੀਂ Instant Connect ਵਿਕਸਿਤ ਕੀਤਾ. ਇਹ ਸਰਵਰ ਸਮਰੱਥਾ ਰਾਖਵੀਂ ਕੀਤੇ ਬਿਨਾਂ ਅਤੇ ਮੌਜੂਦਾ WebRTC ਲਾਗੂਕਰਨਾਂ ਵਿੱਚ ਕੋਈ ਤਬਦੀਲੀ ਕੀਤੇ ਬਿਨਾਂ ਇਨ੍ਹਾਂ ਮਾਪਦੰਡਾਂ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਸਹਿਮਤੀ ਕਰ ਲੈਂਦਾ ਹੈ.

Instant Connect ਮਿਆਰੀ ਸੰਕੇਤਕ ਪ੍ਰਵਾਹ ਦੇ ਨਾਲ-ਨਾਲ ਚੱਲਦਾ ਹੈ. ਜੇ ਪਹਿਲਾਂ ਸਹਿਮਤ ਕੀਤੇ ਮਾਪਦੰਡ ਵੈਧ ਹੋਣ, ਤਾਂ ਪਹਿਲਾ ਮੀਡੀਆ ਪੈਕੇਟ ਪਹੁੰਚਣ ਉੱਤੇ ਸਰਵਰ ਸੈਸ਼ਨ ਬਣਾ ਸਕਦਾ ਹੈ. ਜੇ ਉਹ ਪੁਰਾਣੇ ਜਾਂ ਅਵੈਧ ਹੋਣ, ਤਾਂ ਸੰਕੇਤਕ ਪ੍ਰਵਾਹ ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਬਿਨਾਂ ਵਾਧੂ ਦੇਰੀ ਦੇ ਮਿਆਰੀ ਤਰੀਕੇ ਵੱਲ ਮੁੜ ਸਕਦਾ ਹੈ.

Instant Connect ਅਤੇ WARP ਮਿਲ ਕੇ ਵਰਤੋਂਕਾਰ ਦੀ ਇੱਛਾ ਤੋਂ ਲਾਈਵ ਮੀਡੀਆ ਪ੍ਰਵਾਹ ਸ਼ੁਰੂ ਹੋਣ ਤੱਕ ਦਾ ਸਮਾਂ ਬਹੁਤ ਘਟਾ ਦਿੰਦੇ ਹਨ. SDP ਅਦਾਨ-ਪ੍ਰਦਾਨ ਕ੍ਰਿਟਿਕਲ ਪਾਥ ਤੋਂ ਬਾਹਰ ਹੋਣ ਅਤੇ WARP ਵੱਲੋਂ ਟ੍ਰਾਂਸਪੋਰਟ ਹੈਂਡਸ਼ੇਕ ਸਮੇਟਣ ਨਾਲ ਕਲਾਇੰਟ ਹੁਣ ਸਿਰਫ਼ ਇੱਕ UDP ਪੈਕੇਟ ਰਾਹੀਂ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ. ਸਰਵਰ ਤੁਰੰਤ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਬਾਕੀ ਸਿਸਟਮ ਉਹ ਕੰਮ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ ਜਿਸ ਦੀ ਵਰਤੋਂਕਾਰ ਨੂੰ ਅਸਲ ਵਿੱਚ ਪਰਵਾਹ ਹੈ: ਸੁਣਨਾ ਅਤੇ ਜਵਾਬ ਦੇਣਾ.

ਕੋਈ ਸਿਸਟਮ ਕਾਗਜ਼ਾਂ ਵਿੱਚ ਤੇਜ਼ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਅਸਲ ਵੌਇਸ ਟ੍ਰੈਫਿਕ ਦੌਰਾਨ ਫਿਰ ਵੀ ਅਟਕ ਸਕਦਾ ਹੈ. GPT‑Live ਨੂੰ ਵਰਤੋਂਕਾਰਾਂ ਨਾਲ ਗੱਲ ਕਰਨ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਇੱਕ ਮੌਨ ਜਾਂਚ ਚਲਾਈ ਜਿਸ ਨੇ ਉਤਪਾਦਨ ਦੀਆਂ ChatGPT ਵੌਇਸ ਸੈਸ਼ਨਾਂ ਦਾ ਇੱਕ ਛੋਟਾ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਵਧਦਾ ਹਿੱਸਾ ਮੌਜੂਦਾ ਐਡਵਾਂਸਡ ਵੌਇਸ ਮੋਡ ਅਨੁਭਵ ਅਤੇ ਸਾਡੇ ਨਵੇਂ ਸਿਸਟਮ ਦੋਵਾਂ ਵੱਲ ਭੇਜਿਆ. ਐਡਵਾਂਸਡ ਵੌਇਸ ਮੋਡ ਆਮ ਵਾਂਗ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਸੇਵਾ ਦਿੰਦਾ ਰਿਹਾ, ਜਦਕਿ ਪਰਛਾਵੇਂ ਵਾਲੇ ਮਾਰਗ ਨੇ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਮੋਡ ਵਿੱਚ ਇਨਫਰੈਂਸ ਚਲਾਇਆ. ਇਸ ਨਾਲ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਸੁਣਾਈ ਦੇਣ ਵਾਲੀ ਚੀਜ਼ ਬਦਲੇ ਬਿਨਾਂ ਸਿਸਟਮ ਨੂੰ ਅਸਲ ਕਲਾਇੰਟਾਂ, ਨੈੱਟਵਰਕਾਂ, ਸੈਸ਼ਨ ਮਿਆਦਾਂ ਅਤੇ ਭੂਗੋਲਿਕ ਵੰਡ ਦਾ ਸਾਹਮਣਾ ਕਰਵਾਇਆ ਗਿਆ.

ਪਹਿਲੇ ਸਬਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਸੀ ਕਿ ਸਮਰੱਥਾ ਨੂੰ ਸਿਰਫ਼ GPU ਥਰੂਪੁੱਟ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ. ਵੌਇਸ ਸੈਸ਼ਨ ਖੁੱਲ੍ਹੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਲਗਾਤਾਰ ਫਰੇਮ ਭੇਜਦੇ ਹਨ, ਇਸ ਲਈ CPU ਪਾਸੇ ਦੇ ਸਟ੍ਰੀਮ ਹੈਂਡਲਰਾਂ, ਕਤਾਰਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ਮਾਰਗਾਂ ਨੂੰ ਇਨਫਰੈਂਸ ਦੇ ਨਾਲ-ਨਾਲ ਵਧਣਾ ਚਾਹੀਦਾ ਹੈ. ਅਸਲ ਲੋਡ ਹੇਠ ਇੱਕ ਸਹਾਇਕ ਭਾਗ ਸਾਡੀਆਂ ਲੋਡ-ਜਾਂਚ ਅਟਕਲਾਂ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪੂਰੀ ਸਮਰੱਥਾ ਤੱਕ ਪਹੁੰਚ ਗਿਆ, ਜਿਸ ਕਾਰਨ ਇਨਫਰੈਂਸ ਬੇਨਤੀਆਂ ਇਕੱਠੀਆਂ ਹੋਈਆਂ ਅਤੇ ਦੇਰੀ ਵਧਦੀ ਗਈ. ਅਸੀਂ ਸਮਰੱਥਾ ਬਾਰੇ ਸਵਾਲ ਨੂੰ “ਇੱਕ GPU ਕਿੰਨੀਆਂ ਬੇਨਤੀਆਂ ਸੰਭਾਲ ਸਕਦਾ ਹੈ?” ਤੋਂ ਬਦਲ ਕੇ “ਹਰ ਫਰੇਮ ਨੂੰ ਸਮੇਂ ਸਿਰ ਰੱਖਦਿਆਂ ਸਿਸਟਮ ਇੱਕੋ ਵੇਲੇ ਕਿੰਨੇ ਸੈਸ਼ਨ ਚਲਾ ਸਕਦਾ ਹੈ?” ਕਰ ਦਿੱਤਾ.

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

ਹੋਰ ਨਾਕਾਮੀਆਂ ਸਿਰਫ਼ ਅਸਲ ਸੈਸ਼ਨ ਜੀਵਨ-ਚੱਕਰਾਂ ਦੌਰਾਨ ਸਾਹਮਣੇ ਆਈਆਂ. ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਸੈਸ਼ਨਾਂ ਨੇ ਮੈਮੋਰੀ ਅਤੇ ਸਥਾਈ ਸਟੋਰੇਜ ਉੱਤੇ ਦਬਾਅ ਉਜਾਗਰ ਕੀਤਾ. ਮੁੜ-ਕਨੈਕਸ਼ਨਾਂ ਨੇ ਕੰਪੈਕਸ਼ਨ ਅਤੇ ਸਥਿਤੀ ਬਹਾਲੀ ਨੂੰ ਪਰਖਿਆ. ਆਮ ਕਲਾਇੰਟ ਡਿਸਕਨੈਕਸ਼ਨਾਂ ਨੇ ਬੰਦ ਕਰਨ ਵਾਲੇ ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਦੌੜ ਸਥਿਤੀਆਂ ਉਜਾਗਰ ਕੀਤੀਆਂ. ਇਹ ਸਮੱਸਿਆਵਾਂ ਛੋਟੀਆਂ ਲੋਡ ਜਾਂਚਾਂ ਵਿੱਚ ਘੱਟ ਹੀ ਦਿਖੀਆਂ, ਕਿਉਂਕਿ ਇਹ ਸਮੇਂ, ਇਕੱਠੀ ਹੋਈ ਸਥਿਤੀ ਅਤੇ ਸੇਵਾ ਸੀਮਾਵਾਂ ਦੇ ਆਰ-ਪਾਰ ਵਿਹਾਰ ਉੱਤੇ ਨਿਰਭਰ ਸਨ.

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

GPT‑Live ਨੂੰ ChatGPT ਦੇ ਪੈਮਾਨੇ ਤੱਕ ਲਿਜਾਣ ਲਈ ਇੱਕ ਬੁਨਿਆਦੀ ਸਿਧਾਂਤ ਦੁਆਲੇ ਬਣੇ ਬਿਲਕੁਲ ਨਵੇਂ ਸਿਸਟਮ ਦੀ ਲੋੜ ਸੀ: ਆਵਾਜ਼ ਦਾ ਪ੍ਰਵਾਹ ਜਾਰੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ. ਸਟ੍ਰੀਮਿੰਗ ਇਨਫਰੈਂਸ ਫੁੱਲ-ਡੁਪਲੈਕਸ ਮਾਡਲ ਨੂੰ ਲਗਾਤਾਰ ਆਡੀਓ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ. ਇੱਕ ਸਮਰਪਿਤ ਮੀਡੀਆ ਮਾਰਗ ਫਰੇਮਾਂ ਦੀ ਭਰੋਸੇਯੋਗ ਡਿਲੀਵਰੀ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ. ਅਸਮਕਾਲੀ ਡੈਲੀਗੇਸ਼ਨ ਡੂੰਘੀ ਸੋਚ ਨੂੰ ਸਮਾਂਤਰ ਚੱਲਣ ਦਿੰਦਾ ਹੈ. ਅਨੁਕੂਲਿਤ ਟ੍ਰਾਂਸਪੋਰਟ ਵਰਤੋਂਕਾਰ ਤੱਕ ਪੂਰੇ ਅਨੁਭਵ ਨੂੰ ਤੇਜ਼ ਪ੍ਰਤੀਕਿਰਿਆ ਵਾਲਾ ਰੱਖਦੀ ਹੈ.

GPT‑Live ਪਿੱਛੇ ਦੀ ਆਰਕੀਟੈਕਚਰ ਪਹਿਲਾਂ ਹੀ ਰੀਅਲ-ਟਾਈਮ ਪਰਸਪਰ ਕਿਰਿਆ ਲਈ ਇੱਕ ਵਿਆਪਕ ਪਲੇਟਫਾਰਮ ਬਣ ਰਹੀ ਹੈ. ਇਹ ChatGPT ਵੌਇਸ ਨੂੰ ਤਾਕਤ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਗੱਲਬਾਤ ਤੋਂ ਏਜੰਟ-ਅਧਾਰਿਤ ਤਾਲਮੇਲ ਵੱਲ ਵਧਦੀ ਹੈ, ਅਤੇ ਆਉਣ ਵਾਲੀ GPT‑Live API ਦੀ ਨੀਂਹ ਬਣੇਗੀ. ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਵੌਇਸ ਅਨੁਭਵਾਂ ਨੂੰ ਉਸ ਤਤਕਾਲਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ ਹੋਰ ਡਿਵਾਈਸਾਂ, ਐਪਾਂ ਅਤੇ ਮਾਧਿਅਮਾਂ ਤੱਕ ਫੈਲਣ ਦੇਵੇਗੀ ਜੋ ਵੌਇਸ ਗੱਲਬਾਤ ਨੂੰ ਲਾਈਵ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ.

ਜੇ ਤੁਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਸਾਡੇ ਨਾਲ ਕੰਮ ਕਰੋ⁠.