OpenAI ਨੇ GPT-Live ਬਣਾਇਆ ਹੈ, ਜੋ ਇੱਕ voice-first ਚੈਟਬੋਟ ਹੈ ਜੋ ਇੱਕੋ ਸਮੇਂ ਸੁਣਦਾ ਅਤੇ ਬੋਲਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਭਾਰੀ "ਪਹਿਲਾਂ ਬੋਲੋ ਫਿਰ ਸੁਣੋ" ਵਾਲੇ ਵਿਰਾਮਾਂ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸਹਾਇਕ (assistants) ਵਰਤਦੇ ਹਨ। ਇਸ ਸੇਵਾ ਦਾ ਉਦੇਸ਼ ਅਜਿਹੀ ਗੱਲਬਾਤ ਕਰਵਾਉਣਾ ਹੈ ਜੋ ਰੁਕ-ਰੁਕ ਕੇ ਹੋਣ ਵਾਲੀਆਂ ਗੱਲਾਂ ਦੀ ਬਜਾਏ ਮਨੁੱਖੀ ਸੰਵਾਦ ਵਾਂਗ ਵਹੇ।
ਪੁਰਾਣਾ ਮਾਡਲ ਕਿਉਂ ਖਰਾਬ ਲੱਗਦਾ ਸੀ
ਆਮ ਵੌਇਸ ਸਹਾਇਕ (voice assistants) ਵਾਕੀ-ਟਾਕੀ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਖਤਮ ਕਰਦੇ ਹੋ, ਡਿਵਾਈਸ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਆਡੀਓ ਨੂੰ ਕਲਾਉਡ 'ਤੇ ਭੇਜਦਾ ਹੈ, ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਵਾਪਸ ਚਲਾਉਂਦਾ ਹੈ। ਇਹ round-trip ਇੱਕ ਮਹਿਸੂਸ ਹੋਣ ਵਾਲਾ lag ਪੈਦਾ ਕਰਦਾ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਦਖਲ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਇੰਸਟੈਂਟ ਮੈਸੇਜਿੰਗ ਵਾਲੀ ਪੀੜ੍ਹੀ ਲਈ, ਇਹ ਦੇਰੀ ਬਹੁਤ ਪੁਰਾਣੀ ਲੱਗਦੀ ਹੈ।
OpenAI ਨੇ ਇੱਕ turn-less ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਇਸਦਾ ਜਵਾਬ ਦਿੱਤਾ। ਹਰ ਸੈਕਿੰਡ ਵਿੱਚ, GPT-Live ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਸੁਣਨਾ ਜਾਰੀ ਰੱਖਣਾ ਹੈ, ਬੋਲਣਾ ਜਾਰੀ ਰੱਖਣਾ ਹੈ, ਜਾਂ ਰੁਕਣਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਜਵਾਬ ਦੇ ਵਿਚਕਾਰ ਹੀ ਸਹਾਇਕ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ ਜਾਂ ਪੂਰੇ ਜਵਾਬ ਦੇ ਚੱਕਰ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਅਗਲਾ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹੋ।
ਫੁੱਲ-ਡਿਊਪਲੈਕਸ (full-duplex) ਸਟੈਕ ਨੂੰ ਸਰਲ ਸ਼ਬਦਾਂ ਵਿੱਚ
- ਵੱਖਰੀ ਆਡੀਓ ਲੂਪ ਅਤੇ reasoning path – ਇੱਕ fast path ਲਗਾਤਾਰ ਆਡੀਓ ਐਕਸਚੇਂਜ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇੱਕ slow path ਵੈੱਬ ਸਰਚ ਜਾਂ tool calls ਵਰਗੇ ਭਾਰੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਜਦੋਂ slow path ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, fast path ਗੱਲਬਾਤ ਨੂੰ ਜਾਰੀ ਰੱਖਦਾ ਹੈ, ਜਿਸ ਨਾਲ "ਮੈਂ ਸੋਚ ਰਿਹਾ ਹਾਂ ਜਦੋਂ ਚੁੱਪ" ਵਾਲਾ ਡਰਾਉਣਾ ਪਲ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।
- WARP ਪ੍ਰੋਟੋਕੋਲ – ਰਵਾਇਤੀ ਵੈੱਬ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਆਡੀਓ ਵਹਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਈ handshakes ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜੋ ਅਕਸਰ ਛੇ round-trips ਹੁੰਦੇ ਹਨ। OpenAI ਦਾ ਕਸਟਮ ਪ੍ਰੋਟੋਕੋਲ ਉਹਨਾਂ ਕਦਮਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਟ੍ਰਿਪ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸੈਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਲਗਭਗ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।
- Latency ਦੀ ਇਕਸਾਰਤਾ ਲਈ Python ਦੀ ਬਜਾਏ Go ਦੀ ਵਰਤੋਂ – ਟੀਮ ਨੇ ਰੀਅਲ-ਟਾਈਮ ਕੰਪੋਨੈਂਟਸ ਨੂੰ ਤੇਜ਼ ਵਿਕਾਸ ਲਈ ਜਾਣੇ ਜਾਂਦੇ Python ਤੋਂ ਹਟਾ ਕੇ Go ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਹੈ, ਜੋ ਕਿ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ execution times ਦਿੰਦਾ ਹੈ। ਵੌਇਸ AI ਵਿੱਚ, ਔਸਤ ਰਫਤਾਰ ਨਾਲੋਂ ਸਭ ਤੋਂ ਵੱਧ ਹੋਣ ਵਾਲੀ ਦੇਰੀ (worst-case delay) ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ; ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਰੁਕਾਵਟ ਵੀ ਅਨੁਭਵ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਇਕਸਾਰ latency ਹੀ ਜਿੱਤਦੀ ਹੈ।
- GPU ਤੋਂ ਪਰੇ Scaling – ਕਰੋੜਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨਾਲ, ਰੁਕਾਵਟ ਮਾਡਲ ਦੇ compute cores ਤੋਂ ਹਟ ਕੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ (infrastructure) 'ਤੇ ਆ ਗਈ। OpenAI ਨੇ ਪਾਇਆ ਕਿ GPUs ਤੋਂ ਪਹਿਲਾਂ CPUs ਅਤੇ ਨੈੱਟਵਰਕ ਲਿੰਕ ਭਰ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੇ ਬਾਕੀ ਸਟੈਕ ਨੂੰ ਬਿਨਾਂ ਪ੍ਰਭਾਵਿਤ ਕੀਤੇ GPUs ਨੂੰ ਕੰਮ ਕਰਵਾਉਣ ਲਈ ਸਮਾਰਟ ਰੂਟਿੰਗ ਅਤੇ connection-management ਜੋੜਿਆ।
ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਸਦਾ ਕੀ ਮਤਲਬ ਹੈ
- ਆਡੀਓ ਹੈਂਡਲਿੰਗ ਨੂੰ business logic ਤੋਂ ਵੱਖ ਕਰੋ – ਇੱਕ ਹਲਕਾ (lightweight), ਹਮੇਸ਼ਾ ਚਾਲੂ ਰਹਿਣ ਵਾਲਾ ਲੂਪ ਰੱਖੋ ਜੋ ਮਾਈਕ੍ਰੋਫੋਨ ਇਨਪੁਟ ਅਤੇ ਸਪੀਕਰ ਆਉਟਪੁੱਟ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ। ਜੋ ਵੀ ਚੀਜ਼ ਇੰਤਜ਼ਾਰ ਕਰ ਸਕਦੀ ਹੈ—ਜਿਵੇਂ database queries, ਬਾਹਰੀ API calls—ਉਸਨੂੰ ਇੱਕ ਵੱਖਰੇ thread ਜਾਂ service ਨੂੰ ਸੌਂਪ ਦਿਓ।
- Latency ਸਥਿਰਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿਓ – ਜਵਾਬ ਦੇ ਸਮੇਂ ਨੂੰ ਮਾਪੋ, ਸਿਰਫ ਔਸਤ 'ਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਬਜਾਏ ਸਭ ਤੋਂ ਵੱਧ ਹੋਣ ਵਾਲੀ ਦੇਰੀ (worst-case delays) 'ਤੇ ਧਿਆਨ ਦਿਓ। ਉਹ ਭਾਸ਼ਾਵਾਂ ਅਤੇ runtimes ਜੋ scheduling 'ਤੇ ਬਿਹਤਰ ਕੰਟਰੋਲ ਦਿੰਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ Go, Rust), ਵਾਧੂ ਇੰਜੀਨੀਅਰਿੰਗ ਕੋਸ਼ਿਸ਼ ਦੇ ਲਾਇਕ ਹੋ ਸਕਦੇ ਹਨ।
- Connection overhead ਨੂੰ ਘਟਾਓ – ਹਰ ਵਾਧੂ handshake ਮਿਲੀਸੈਕਿੰਡ ਵਧਾਉਂਦਾ ਹੈ ਜੋ ਇਕੱਠੇ ਹੋ ਕੇ ਵੱਧ ਜਾਂਦੇ ਹਨ। Authentication, stream negotiation, ਅਤੇ codec selection ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਐਕਸਚੇਂਜ ਵਿੱਚ ਬੰਨ੍ਹ ਦਿਓ, ਅਤੇ ਉਪਭੋਗਤਾ ਅੰਤਰ ਮਹਿਸੂਸ ਕਰਨਗੇ।
Trade-offs ਅਤੇ ਖੁੱਲ੍ਹੇ ਸਵਾਲ
ਫੁੱਲ-ਡਿਊਪਲੈਕਸ ਡਿਜ਼ਾਈਨ ਗੁੰਝਲਤਾ ਵਧਾਉਂਦਾ ਹੈ।