OpenAI ਵਿੱਚ ਹਰ ਇੰਟਰੈਕਸ਼ਨ ਨਾਲ ਸਹਾਇਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣਾ
ਇਹ ਸਾਡੀ ਉਸ ਸੀਰੀਜ਼ ਦਾ ਹਿੱਸਾ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਇਹ ਸਾਂਝਾ ਕਰਦੇ ਹਾਂ ਕਿ OpenAI ਆਪਣੀ ਹੀ ਤਕਨਾਲੋਜੀ ਅਤੇ APIs ਨੂੰ ਅੰਦਰੂਨੀ ਤੌਰ ਤੇ ਕਿਵੇਂ ਵਰਤ ਰਿਹਾ ਹੈ. ਇਹ ਟੂਲ ਸਿਰਫ OpenAI ਵਿੱਚ ਅੰਦਰੂਨੀ ਵਰਤੋਂ ਲਈ ਹਨ, ਅਤੇ ਇੱਥੇ ਸਾਡੀਆਂ ਟੀਮਾਂ ਵਿੱਚ ਅਤਿ-ਆਧੁਨਿਕ AI ਵੱਖ-ਵੱਖ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਨੂੰ ਕਿਵੇਂ ਸਹਾਰਾ ਦੇ ਰਿਹਾ ਹੈ, ਇਸ ਦੇ ਉਦਾਹਰਨ ਵਜੋਂ ਸਾਂਝੇ ਕੀਤੇ ਗਏ ਹਨ. ਅਸੀਂ ਅੰਦਰੂਨੀ ਟੂਲਾਂ ਦੇ ਨਾਮ ਵੀ ਸਾਂਝੇ ਕਰ ਰਹੇ ਹਾਂ ਤਾਂ ਜੋ ਇਹ ਹੋਰ ਸਾਫ਼ ਹੋ ਸਕੇ ਕਿ ਅਤਿ-ਆਧੁਨਿਕ AI ਸਾਡੀਆਂ ਟੀਮਾਂ ਨੂੰ ਕੰਮ ਮੁਕੰਮਲ ਕਰਨ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ.
ਇਤਿਹਾਸਕ ਤੌਰ ਤੇ ਸਹਾਇਤਾ ਦਾ ਮਤਲਬ ਕਤਾਰਾਂ, ਟਿਕਟਾਂ ਅਤੇ ਥਰੂਪੁੱਟ ਹੁੰਦਾ ਸੀ. ਪਰ OpenAI ਵਿੱਚ ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ. ਅਸੀਂ ਕਰੋੜਾਂ ਵਰਤੋਂਕਾਰਾਂ ਦੀ ਸੇਵਾ ਕਰਦੇ ਹਾਂ, ਹਰ ਸਾਲ ਲੱਖਾਂ ਬੇਨਤੀਆਂ ਸੰਭਾਲਦੇ ਹਾਂ, ਅਤੇ ਇਹ ਮਾਤਰਾ ਹਰ ਸਾਲ ਕਈ ਗੁਣਾ ਵਧਦੀ ਵੇਖਦੇ ਹਾਂ.
ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਸਕੇਲ ਨਾਲ ਜੂਝਦੀਆਂ ਹਨ. ਇਸ ਤੋਂ ਘੱਟ ਸੰਸਥਾਵਾਂ ਸਕੇਲ ਅਤੇ ਬੇਹੱਦ ਤੇਜ਼ ਵਾਧੇ ਨਾਲ ਇਕੱਠੇ ਜੂਝਦੀਆਂ ਹਨ. ਲਗਭਗ ਕੋਈ ਵੀ ਦੋਵੇਂ ਚੀਜ਼ਾਂ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰਦੀ—ਉਹ ਵੀ ਇਸ ਦੌਰਾਨ ਕਿ ਉਹ ਉਹੀ ਤਕਨਾਲੋਜੀ ਤਿਆਰ ਕਰ ਰਹੀ ਹੋਵੇ ਜੋ ਇਹ ਸਮੀਕਰਨ ਹੀ ਬਦਲ ਸਕਦੀ ਹੈ. ਇਸ ਮਿਲਾਪ ਨੇ ਸਾਨੂੰ ਸਹਾਇਤਾ ਬਾਰੇ ਬੁਨਿਆਦ ਤੋਂ ਮੁੜ ਸੋਚਣ ਲਈ ਵਿਲੱਖਣ ਢੰਗ ਨਾਲ ਤਿਆਰ ਕੀਤਾ.
“ਸਹਾਇਤਾ ਅਸਲ ਵਿੱਚ ਕਦੇ ਵੀ ਸਿਰਫ ਟਿਕਟਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਬਾਰੇ ਨਹੀਂ ਰਹੀ. ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੀ ਲੋਕਾਂ ਨੂੰ ਉਹ ਮਿਲਦਾ ਹੈ ਜਿਸਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਹੈ, ਅਤੇ ਕੀ ਇਹ ਉਹਨਾਂ ਦੀ ਸੱਚਮੁੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੇਵਾ ਕਰਦੀ ਹੈ.”
ਸਹਾਇਤਾ ਮਾਤਰਾ ਦੀ ਚੁਣੌਤੀ ਨਹੀਂ ਹੈ. ਇਹ ਇੰਜੀਨੀਅਰਿੰਗ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਡਿਜ਼ਾਇਨ ਦੀ ਚੁਣੌਤੀ ਹੈ. ਇਸ ਲਈ ਅਸੀਂ ਕੁਝ ਵੱਖਰਾ ਬਣਾਇਆ: ਇੱਕ ਓਪਰੇਟਿੰਗ ਮਾਡਲ ਜਿੱਥੇ ਹਰ ਇੰਟਰੈਕਸ਼ਨ ਅਗਲੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ.
Ops ਟੀਮ ਸਹਾਇਤਾ ਸਵਾਲਾਂ ਨੂੰ ਟਾਲਣ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਚੈਟਬਾਟ ਵਰਤਣ ਤੋਂ ਕਾਫ਼ੀ ਅੱਗੇ ਜਾਣਾ ਚਾਹੁੰਦੀ ਸੀ. ਟੀਮ ਦੀ ਇੱਕ ਦ੍ਰਿਸ਼ਟੀ ਹੈ: ਸਹਾਇਤਾ ਨੂੰ ਇੱਕ AI ਓਪਰੇਟਿੰਗ ਮਾਡਲ ਵਜੋਂ ਮੁੜ ਕਲਪਨਾ ਕਰਨੀ ਜੋ ਲਗਾਤਾਰ ਸਿੱਖਦਾ ਅਤੇ ਸੁਧਰਦਾ ਰਹੇ.
ਕੇਂਦਰ ਵਿੱਚ ਤਿੰਨ ਬੁਨਿਆਦੀ ਹਿੱਸੇ ਹਨ:
- ਸਤਹਾਂ. ਜਿੱਥੇ ਸਹਾਇਤਾ ਪ੍ਰਣਾਲੀਆਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਚੈਟ, ਈਮੇਲ ਅਤੇ ਫੋਨ, ਪਰ ਵਧਦੇ ਤੌਰ ਤੇ ਉਤਪਾਦ ਦੇ ਅੰਦਰ ਹੀ ਸ਼ਾਮਲ ਕੀਤੀ ਮਦਦ ਵੀ.
- ਗਿਆਨ. ਸਿਰਫ ਸਥਿਰ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ, ਸਗੋਂ ਅਸਲੀ ਗੱਲਬਾਤਾਂ, ਨੀਤੀਆਂ ਅਤੇ ਸੰਦਰਭ ਤੋਂ ਨਿਕਲਿਆ ਜੀਵੰਤ ਅਤੇ ਲਗਾਤਾਰ ਸੁਧਰਦਾ ਮਾਰਗਦਰਸ਼ਨ.
- Evals ਅਤੇ classifiers. ਸਾਫਟਵੇਅਰ ਅਤੇ ਮਨੁੱਖਾਂ ਵੱਲੋਂ ਇਕੱਠੇ ਬਣਾਈਆਂ ਗਈਆਂ ਗੁਣਵੱਤਾ ਦੀਆਂ ਸਾਂਝੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ, ਨਾਲ ਹੀ ਫੀਡਬੈਕ ਨੂੰ ਮਾਪਣ, ਸੁਧਾਰਣ ਅਤੇ ਉਜਾਗਰ ਕਰਨ ਵਾਲੇ ਟੂਲ.
ਇਹ ਹਿੱਸੇ ਇਕੱਲੇ ਨਹੀਂ ਬੈਠਦੇ. ਇਹ ਇੱਕ ਚੱਕਰ ਬਣਾਉਂਦੇ ਹਨ. ਕਿਸੇ enterprise ਗੱਲਬਾਤ ਵਿੱਚ ਦਿੱਸਿਆ ਪੈਟਰਨ developer FAQ ਨੂੰ ਜਾਣਕਾਰੀ ਦੇ ਸਕਦਾ ਹੈ. ਇੱਕ ਮਾਮਲੇ ਲਈ ਲਿਖਿਆ eval ਹਜ਼ਾਰਾਂ ਹੋਰਾਂ ਲਈ ਮਾਡਲ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ. ਅਤੇ ਕਿਉਂਕਿ ਇੱਕੋ primitives ਹਰ ਸਤਹ ਨੂੰ ਤਾਕਤ ਦਿੰਦੇ ਹਨ - ਚੈਟ, ਈਮੇਲ, ਆਵਾਜ਼—ਸੁਧਾਰ ਆਪਣੇ ਆਪ ਹੀ ਸਾਰੇ ਚੈਨਲਾਂ ਵਿੱਚ ਸਕੇਲ ਹੋ ਜਾਂਦੇ ਹਨ.
ਸਹਾਇਤਾ ਪ੍ਰਤੀਨਿਧੀ ਦੀ ਭੂਮਿਕਾ ਬਦਲ ਰਹੀ ਹੈ. ਸਾਡਾ ਮਕਸਦ ਮਾਡਲ ਨੂੰ ਮੁੱਖ ਤੌਰ ਤੇ ਲੈਣ-ਦੇਣ ਵਾਲੇ ਕੰਮ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰਨ 'ਤੇ ਧਿਆਨ ਦੇਣ ਤੋਂ ਹਟਾ ਕੇ ਸਮੂਹਿਕ ਨਿਰਮਾਣ ਦਾ ਹਿੱਸਾ ਬਣਾਉਣਾ ਹੈ. ਉਹਨਾਂ ਨੂੰ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਖੁਦ ਯੋਗਦਾਨ ਪਾਉਣ ਲਈ ਸਮਰੱਥ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਸਿੱਧੇ ਤੌਰ ਤੇ ਹੇਠਲੇ ਪੱਧਰ ਤੋਂ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰਨ ਰਾਹੀਂ ਅਤੇ ਅਪਰੋਖ ਤੌਰ ਤੇ ਆਪਣੇ ਰੋਜ਼ਾਨਾ ਕੰਮ ਦੀਆਂ ਕੁਦਰਤੀ ਗਤੀਵਿਧੀਆਂ ਰਾਹੀਂ.
ਪ੍ਰਤੀਨਿਧੀ ਉਹ ਇੰਟਰੈਕਸ਼ਨਾਂ ਨੂੰ ਨਿਸ਼ਾਨਿਤ ਕਰਦੇ ਹਨ ਜੋ ਟੈਸਟ ਕੇਸ ਬਣਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਨਵੇਂ ਪੈਟਰਨ ਦਿੱਸਣ 'ਤੇ classifiers ਦਾ ਸੁਝਾਅ ਦੇਂਦੇ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸ਼ਿਪ ਕਰਦੇ ਹਨ, ਅਤੇ workflow ਦੀਆਂ ਖਾਮੀਆਂ ਨੂੰ ਕੁਝ ਦਿਨਾਂ ਵਿੱਚ ਪੂਰਾ ਕਰਨ ਲਈ ਹਲਕੀਆਂ automation ਵੀ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਦੇ ਹਨ. ਟ੍ਰੇਨਿੰਗ ਵੀ ਬਦਲਦੀ ਹੈ, ਇਹ ਸਿਰਫ ਨੀਤੀਆਂ ਬਾਰੇ ਨਹੀਂ ਰਹਿੰਦੀ, ਸਗੋਂ ਇੰਟਰੈਕਸ਼ਨਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ, ਸੰਰਚਨਾਤਮਕ ਖਾਮੀਆਂ ਪਛਾਣਣ ਅਤੇ ਸੁਧਾਰਾਂ ਨੂੰ ਵਾਪਸ ਜੋੜਣ ਬਾਰੇ ਵੀ ਹੁੰਦੀ ਹੈ.
ਇਹ ਨਵਾਂ ਰਵੱਈਆ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਸਹਾਇਤਾ ਪ੍ਰਤੀਨਿਧੀ ਸਿਰਫ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਨਹੀਂ, ਸਗੋਂ ਨਿਰਮਾਤਾ ਵੀ ਹੋਣ.
“ਏਜੰਟ ਸਿਰਫ ਟਿਕਟਾਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਰਹੇ. ਉਹ ਸਾਡੇ ਗਿਆਨ-ਅਧਾਰ ਅਤੇ ਸਾਡੀਆਂ ਨੀਤੀਆਂ ਨੂੰ ਵੀ ਜਾਣਕਾਰੀ ਦੇ ਰਹੇ ਹਨ. ਉਹਨਾਂ ਕੋਲ ਜ਼ਮੀਨੀ ਹਕੀਕਤ ਦੀ ਉਹ ਸਮਝ ਹੈ ਜੋ ਸਾਡੇ ਕੋਲ ਨਹੀਂ.”
ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਅਜਿਹਾ ਸਹਾਇਤਾ ਸੰਗਠਨ ਬਣਦਾ ਹੈ ਜੋ ਥਰੂਪੁੱਟ ਨਾਲ ਘੱਟ ਅਤੇ ਵਿਕਸਿਤ ਹੋਣ ਦੀ ਆਪਣੀ ਸਮਰੱਥਾ ਨਾਲ ਵੱਧ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ. ਹਰ ਵਿਅਕਤੀ ਨਾ ਕੇਵਲ ਵਰਤੋਂਕਾਰਾਂ ਦੀ ਸੇਵਾ ਕਰ ਰਿਹਾ ਹੈ, ਸਗੋਂ ਉਸ ਮਸ਼ੀਨਰੀ ਨੂੰ ਵੀ ਸਰਗਰਮ ਤੌਰ ਤੇ ਬਿਹਤਰ ਬਣਾ ਰਿਹਾ ਹੈ ਜੋ ਸਾਰੇ ਵਰਤੋਂਕਾਰਾਂ ਦੀ ਸੇਵਾ ਕਰਦੀ ਹੈ.
ਇਸ ਤਰੀਕੇ ਨਾਲ ਸਹਾਇਤਾ ਬਣਾਉਣਾ ਕੇਵਲ ਇਸ ਲਈ ਸੰਭਵ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ OpenAI ਦੇ stack 'ਤੇ ਬਣੇ ਹੋਏ ਹਾਂ.
- Agents SDK ਸਾਨੂੰ ਡਿਫਾਲਟ ਤੌਰ ਤੇ ਕਦਮ-ਪੱਧਰੀ traces ਅਤੇ observability ਦਿੰਦਾ ਹੈ. ਅਸੀਂ runs ਨੂੰ ਮੁੜ ਚਲਾ ਸਕਦੇ ਹਾਂ, tool calls ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਾਂ, ਅਤੇ root causes ਨੂੰ ਤੁਰੰਤ debug ਕਰ ਸਕਦੇ ਹਾਂ.
- Responses API ਟੋਨ, ਸਹੀਪਣ ਅਤੇ ਨੀਤੀ ਦੀ ਪਾਲਣਾ ਲਈ classifiers ਨੂੰ ਤਾਕਤ ਦਿੰਦਾ ਹੈ.
- Realtime API ਆਵਾਜ਼ ਸਹਾਇਤਾ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ.
- OpenAI ਦਾ Evals dashboard ਗੁਣਵੱਤਾ ਨੂੰ ਮਾਪਣਯੋਗ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਦ੍ਰਿਸ਼ਮਾਨ ਬਣਾਉਂਦਾ ਹੈ.
ਕਿਉਂਕਿ ਪਲੇਟਫਾਰਮ primitives ਤਿਆਰ-ਮੌਜੂਦ ਆਉਂਦੇ ਹਨ, ਅਸੀਂ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਜੋੜਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਲਗਾਂਦੇ ਹਾਂ ਅਤੇ ਉਸ ਕੰਮ 'ਤੇ ਵੱਧ ਧਿਆਨ ਦਿੰਦੇ ਹਾਂ ਜੋ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ: ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਕਿ ਚੰਗਾ ਕੀ ਦਿੱਸਦਾ ਹੈ, ਉਸਨੂੰ ਮਾਪਣਾ ਅਤੇ ਉਸਨੂੰ ਸੁਧਾਰਣਾ.
ਅਸੀਂ ਇੱਕ ਸਧਾਰਣ ਸਵਾਲ-ਜਵਾਬ ਕਰਨ ਵਾਲੇ ਟੂਲ ਨਾਲ ਸ਼ੁਰੂ ਕੀਤਾ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਸੀ. Agents SDK ਨਾਲ, ਅਸੀਂ refunds, invoices, incident lookups ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਤੇਜ਼ੀ ਨਾਲ dynamic actions ਤੱਕ ਵਿਸਥਾਰ ਕੀਤਾ. ਜਿਵੇਂ ਜਿਵੇਂ ਮਾਡਲ ਵੱਡੀਆਂ context windows, Deep Research, ਅਤੇ ਹੋਰ ਮਜ਼ਬੂਤ agentic ਸਮਰੱਥਾਵਾਂ ਨਾਲ ਸੁਧਰਦੇ ਜਾਂਦੇ ਹਨ, ਅਸੀਂ ਉਹ ਤਰੱਕੀਆਂ ਤੁਰੰਤ ਅਪਣਾ ਸਕਦੇ ਹਾਂ.
Evals ਰੋਜ਼ਾਨਾ ਦੀਆਂ ਗੱਲਬਾਤਾਂ ਨੂੰ production tests ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ. ਉਹ ਇਸ ਗੱਲ ਨੂੰ ਸੰਹਿਤਾਬੱਧ ਕਰਦੇ ਹਨ ਕਿ “ਸ਼ਾਨਦਾਰ” ਦਾ ਕੀ ਅਰਥ ਹੈ—ਸਿਰਫ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨਾ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਕੰਮ ਨਿਮਰਤਾ ਨਾਲ, ਸਪਸ਼ਟਤਾ ਨਾਲ ਅਤੇ ਲਗਾਤਾਰ ਇੱਕਸਾਰ ਢੰਗ ਨਾਲ ਕਰਨਾ ਵੀ. ਪ੍ਰਤੀਨਿਧੀ ਇੱਥੇ ਸਿੱਧੀ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੇ ਹਨ, ਮਜ਼ਬੂਤ ਅਤੇ ਕਮਜ਼ੋਰ ਉਦਾਹਰਨਾਂ ਨੂੰ ਨਿਸ਼ਾਨਿਤ ਕਰਦੇ ਹਨ ਜੋ evals ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ evals production ਵਿੱਚ ਲਗਾਤਾਰ ਚੱਲਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਮਾਡਲ ਦੇ ਵਰਤਾਅ ਨੂੰ ਦਿਸ਼ਾ ਮਿਲੇ.
“ਆਮ ਤੌਰ ਤੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਕੋਈ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਸਿਰਫ਼ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਮਦਦ ਚਾਹੁੰਦੇ ਹੋ. ਸਾਡੇ AI ਟੂਲ ਵਰਤ ਕੇ, ਅਸੀਂ ਉਹ ਜਵਾਬ ਕਾਫ਼ੀ ਤੇਜ਼ੀ ਨਾਲ ਦੇ ਸਕਦੇ ਹਾਂ—ਅਤੇ ਉਤਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ, ਸਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਮਾਡਲ ਨੂੰ ਕਦੋਂ ਜਵਾਬ ਨਹੀਂ ਦੇਣਾ ਚਾਹੀਦਾ,” Jay Patel, Software Engineer, Support Automation ਕਹਿੰਦੇ ਹਨ.
ਸਿੱਖਣਾ ਹੱਲ 'ਤੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ. ਪੈਟਰਨ ਮੁੜ ਗਿਆਨ, automation, ਅਤੇ ਉਤਪਾਦ ਡਿਜ਼ਾਇਨ ਵਿੱਚ ਵਾਪਸ ਜਾਂਦੇ ਹਨ. ਪ੍ਰਣਾਲੀ ਇਕੱਠੀ ਹੋ ਕੇ ਮਜ਼ਬੂਤ ਹੁੰਦੀ ਹੈ: ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਤੇਜ਼ ਜਵਾਬ, ਨਿਰਮਾਤਾਵਾਂ ਲਈ ਹੋਰ ਮਜ਼ਬੂਤ ਫੀਡਬੈਕ ਲੂਪ, ਅਤੇ ਹਰ ਸਤਹ 'ਤੇ ਗੁਣਵੱਤਾ ਲਈ ਲਗਾਤਾਰ ਉੱਚਾ ਮਿਆਰ.
ਅਤੇ ਸਿੱਖਣ ਵਾਲੀ ਸਿਰਫ AI ਹੀ ਨਹੀਂ ਹੈ. ਸੰਗਠਨ ਵੀ ਇਸ ਦੇ ਨਾਲ-ਨਾਲ ਸਿੱਖਦਾ ਹੈ. ਵਿਸ਼ੇਸ਼ਗਿਆਰ ਵੇਖਦੇ ਹਨ ਕਿ ਮਾਡਲ ਕਿੱਥੇ ਘੱਟ ਪੈਂਦੇ ਹਨ, ਨਵੇਂ classifiers ਤਿਆਰ ਕਰਦੇ ਹਨ, ਅਤੇ fine-tuning ਲਈ datasets ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਂਦੇ ਹਨ. Observability dashboards ਗੁਣਵੱਤਾ ਨੂੰ ਮਾਪਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਸਮੇਂ ਦੇ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਕਿਵੇਂ ਸੁਧਰਦਾ ਹੈ.
ਸਭ ਤੋਂ ਡੂੰਘਾ ਬਦਲਾਅ tooling ਨਹੀਂ ਹੈ, ਇਹ ਲੋਕ ਹਨ ਅਤੇ ਇਹ ਕਿ ਸੰਗਠਨ ਸਫਲਤਾ ਨੂੰ ਕਿਵੇਂ ਮਾਪਦਾ ਹੈ. ਸਹਾਇਤਾ ਵਿਸ਼ੇਸ਼ਗਿਆਰਾਂ ਨੂੰ ਸਿਰਫ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਨ ਲਈ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਗਿਆਨ ਨੂੰ ਨਿਖਾਰਨ, ਮਾਡਲਾਂ ਨੂੰ ਸੁਧਾਰਨ, ਅਤੇ ਪ੍ਰਣਾਲੀ ਨੂੰ ਖੁਦ ਵਧਾਉਣ ਲਈ ਵੀ ਮੰਨਤਾ ਮਿਲਦੀ ਹੈ. ਨੇਤਾ ਹੁਣ ਨਵੇਂ ਕਿਸਮ ਦੇ ਸਾਥੀ ਦੀ ਖੋਜ ਕਰਦੇ ਹਨ: ਕੋਈ ਐਸਾ ਵਿਅਕਤੀ ਜੋ ਫਰੰਟਲਾਈਨ ਸਮਵੇਦਨਾ ਨੂੰ ਡਿਜ਼ਾਇਨ ਸਮਝ ਨਾਲ ਜੋੜੇ, ਅਤੇ ਸਹਾਇਤਾ ਦੀ ਕਲਾ ਨੂੰ ਜਿਗਿਆਸਾ ਨਾਲ ਮਿਲਾ ਕੇ ਪ੍ਰਣਾਲੀ ਨੂੰ ਸੁਧਾਰੇ.
“ਅਸੀਂ ਡੂੰਘੀ ਕਲਾ-ਨਿਪੁਣਤਾ ਅਤੇ ਡੂੰਘੀ ਇੰਜੀਨੀਅਰਿੰਗ ਨਿਪੁਣਤਾ ਦੇ ਇਸ ਮਿਲਾਪ ਨੂੰ ਦੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਾਂ. ਵਿਭਾਗਾਂ ਦੇ ਚੱਲਣ ਦਾ ਭਵਿੱਖ ਇਹੀ ਹੈ.”
ਅਤੇ ਸਾਡੀ ਦ੍ਰਿਸ਼ਟੀ ਇਹ ਹੈ ਕਿ ਸਹਾਇਤਾ ਕੋਈ ਐਸੀ ਮੰਜ਼ਿਲ ਨਾ ਰਹੇ ਜਿੱਥੇ ਤੁਸੀਂ ਜਾਂਦੇ ਹੋ. ਇਹ ਇੱਕ ਕਾਰਵਾਈ ਬਣ ਜਾਵੇ, ਜੋ ਹਰ ਉਤਪਾਦ ਸਤਹ ਵਿੱਚ ਬੁਣੀ ਹੋਈ ਹੋਵੇ. ਵਰਤੋਂਕਾਰ “ਟਿਕਟ ਨਹੀਂ ਖੋਲ੍ਹਦੇ.” ਉਹ ਸਿਰਫ਼ ਉਹੀ ਲੈਂਦੇ ਹਨ ਜਿਸਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਹੈ, ਓਥੇ ਜਿੱਥੇ ਉਹ ਹਨ.
ਜੋ ਕੁਝ ਸਕੇਲ ਦੇ ਜਵਾਬ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਉਹ ਇਸ ਗੱਲ ਦਾ ਬਲੂਪ੍ਰਿੰਟ ਬਣ ਗਿਆ ਹੈ ਕਿ ਲੋਕ ਅਤੇ AI ਇਕੱਠੇ ਕਿਵੇਂ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ: ਸਹਿਯੋਗੀ, ਅਨੁਕੂਲਣਸ਼ੀਲ, ਅਤੇ ਲਗਾਤਾਰ ਸੁਧਰਦੇ ਹੋਏ.


