GLM-5.3 “thinking: disabled” ਫਲੈਗ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਜਿਸ ਨੇ {"thinking":{"type":"disabled"}} ਪਾਸ ਕੀਤਾ ਸੀ, ਉਹ ਹੁਣ ਜਵਾਬ ਦੀ ਬਜਾਏ ਇੱਕ ਐਰਰ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਸ ਬਦਲਾਅ ਨੇ ਰਾਤੋ-ਰਾਤ ਦਰਜਨਾਂ ਟੈਸਟ ਸੂਟਾਂ ਨੂੰ ਖਰਾਬ ਕਰ ਦਿੱਤਾ ਹੈ ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਆਪਣੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਰੱਖਣ ਲਈ ਕੋਡ ਦੀ ਇੱਕ ਲਾਈਨ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।
ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
GLM-5.2 ਵਿੱਚ, API ਕਾਲਰਾਂ ਨੂੰ ਮਾਮੂਲੀ ਪ੍ਰੋਂਪਟਸ ਲਈ thinking mode ਬੰਦ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਸੀ। ਉਹ ਵਿਕਲਪ ਆਟੋਮੇਸ਼ਨ ਸਕ੍ਰਿਪਟਾਂ, ਬੈਚ-ਪ੍ਰੋਸੈਸਿੰਗ ਪਾਈਪਲਾਈਨਾਂ ਅਤੇ ਲੋਅ-ਲੈਂਟੈਂਸੀ ਬੋਟਸ ਵਿੱਚ ਇੱਕ ਆਮ ਪੈਟਰਨ ਸੀ। GLM-5.3 ਨੇ ਇਸ ਫਲੈਗ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੱਤਾ ਹੈ ਅਤੇ ਤਿੰਨ ਕੋਸ਼ਿਸ਼ ਦੇ ਪੱਧਰ—low, high ਅਤੇ max—ਜਾਣੇ ਗਏ ਹਨ, ਜਿਸ ਵਿੱਚ max ਡਿਫੌਲਟ ਹੈ। ਨਵਾਂ ਮਾਡਲ ਹਮੇਸ਼ਾ ਇੱਕ ਰੀਜ਼ਨਿੰਗ ਟ੍ਰੇਸ (reasoning trace) ਤਿਆਰ ਕਰਦਾ ਹੈ; ਇਸ ਨੂੰ ਹੁਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਚੁੱਪ ਨਹੀਂ ਕਰਾਇਆ ਜਾ ਸਕਦਾ।
ਕੀ ਖਰਾਬ ਹੋਇਆ ਅਤੇ ਇਹ ਕਿਵੇਂ ਫੈਲਦਾ ਹੈ
ਜਦੋਂ ਰਿਕੁਐਸਟ ਬਾਡੀ ਵਿੱਚ "type":"disabled" ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਪੇਲੋਡ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਆਮ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਜਵਾਬ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਕੋਈ ਆਥੈਂਟੀਕੇਸ਼ਨ ਜਾਂ ਸਿੰਟੈਕਸ ਐਰਰ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੇ, ਇਸ ਲਈ ਸਮੱਸਿਆ ਨੂੰ ਉਦੋਂ ਤੱਕ ਪਛਾਣਨਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇੱਕ ਪੂਰਾ ਰਿਗਰੈਸ਼ਨ ਰਨ ਫੇਲ ਨਹੀਂ ਹੋ ਜਾਂਦਾ। ਕਿਉਂਕਿ ਇਹ ਫਲੈਗ ਕਈ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ, ਰੀਯੂਜ਼ੇਬਲ ਹੈਲਪਰ ਫੰਕਸ਼ਨ ਵਿੱਚ ਸੀ, ਇਸ ਦਾ ਪ੍ਰਭਾਵ ਵੱਡੇ ਟੈਸਟ ਸੂਟਾਂ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਐਂਡਪੁਆਇੰਟਸ ਦੋਵਾਂ 'ਤੇ ਪਿਆ।
ਸਹੀ ਕੋਡ ਤਬਦੀਲੀ
ਪੁਰਾਣਾ ਪੇਲੋਡ ਬਦਲੋ:
extra_body = {"thinking": {"type": "disabled"}}
GLM-5.3-ਅਨੁਕੂਲ ਵਰਜ਼ਨ ਨਾਲ:
extra_body = {"thinking": {"type": "enabled", "effort": "low"}}
"type":"enabled" ਕੀ (key) ਰੀਜ਼ਨਿੰਗ ਇੰਜਣ ਨੂੰ ਮੁੜ ਸਰਗਰਮ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ "effort":"low" ਨਵੇਂ ਮਾਡਲ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਪੁਰਾਣੇ ਡਿਸਏਬਲਡ ਮੋਡ ਦੀ ਗਤੀ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ।
ਪਰਫਾਰਮੈਂਸ 'ਤੇ ਪ੍ਰਭਾਵ
ਲੋਅ-ਐਫੋਰਟ (low-effort) ਸੈਟਿੰਗ ਨਾਲ ਉਹੀ ਕੋਡ-ਰਿਵਿਊ ਪ੍ਰੋਂਪਟਸ ਚਲਾਉਣ ਨਾਲ ਅਜਿਹੇ ਨਤੀਜੇ ਮਿਲਦੇ ਹਨ ਜੋ "ਪੁਰਾਣੀ ਗਤੀ ਦੇ ਨੇੜੇ" ਹਨ ਪਰ ਬਿਲਕੁਲ ਉਹੀ ਨਹੀਂ ਹਨ। ਮਾਡਲ ਅਜੇ ਵੀ ਇੱਕ ਰੀਜ਼ਨਿੰਗ ਟ੍ਰੇਸ ਜਾਰੀ ਕਰਦਾ ਹੈ, ਜੋ ਕੁਝ ਵਾਧੂ ਟੋਕਨ ਅਤੇ ਲੈਂਟੈਂਸੀ ਵਿੱਚ ਥੋੜ੍ਹਾ ਵਾਧਾ ਕਰਦਾ ਹੈ। ਹਾਈ-ਥਰੂਪੁੱਟ ਜਾਂ ਲੈਂਟੈਂਸੀ-ਕ੍ਰਿਟੀਕਲ ਵਰਕਲੋਡਸ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਆਪਣੇ ਡੇਟਾ ਦਾ ਬੈਂਚਮਾਰਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਇਹ ਵਾਧਾ ਸਵੀਕਾਰਯੋਗ ਹੈ।
ਲਾਗਤ ਦੇ ਬਾਵਜੂਦ ਮਾਈਗ੍ਰੇਟ ਕਿਉਂ ਕਰੀਏ
GLM-5.3 ਆਪਣੇ ਪੂਰਵਜ ਦੇ 744-ਬਿਲੀਅਨ-ਪੈਰਾਮੀਟਰ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦਾ ਹੈ ਪਰ ਕੋਡਿੰਗ ਅਤੇ ਏਜੈਂਟਿਕ ਕੰਮਾਂ 'ਤੇ ਮੁੜ ਕੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ। ਸੁਤੰਤਰ ਬੈਂਚਮਾਰਕਸ (Terminal-Bench 3.0) ਸਕੋਰਾਂ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ਅੰਦਰੂਨੀ ਟੈਸਟਾਂ ਨੇ ਕਈ ਫਾਈਲਾਂ ਵਿੱਚ ਲੌਜਿਕ ਐਰਰਾਂ ਦੀ ਬਿਹਤਰ ਪਛਾਣ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ ਹੈ। ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਜੋ ਗੁੰਝਲਦਾਰ ਕੋਡ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਮਾਡਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ, ਪਰਫਾਰਮੈਂਸ ਵਿੱਚ ਹੋਣ ਵਾਲਾ ਵਾਧਾ ਟੋਕਨ ਦੀ ਖਪਤ ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਛੋਟੇ ਵਾਧੇ ਨਾਲੋਂ ਵੱਧ ਹੋ ਸਕਦਾ ਹੈ।
ਸਮਝੌਤਾ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਕਰ ਸਕਦੇ
ਜੇਕਰ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੱਚਮੁੱਚ ਜ਼ੀਰੋ-ਥਿੰਕਿੰਗ ਜਵਾਬਾਂ ਦੀ ਲੋੜ ਹੈ—ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਪਿਓਰ ਟੋਕਨ-ਕੰਪਲੀਸ਼ਨ ਸਰਵਿਸ