ਵਿਸ਼ਾਲ ਲੀਡਰਬੋਰਡਾਂ 'ਤੇ ਕਿਸੇ ਮਾਡਲ ਦੀ ਬੈਂਚਮਾਰਕਿੰਗ ਤੁਹਾਨੂੰ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਉਹ ਟ੍ਰਿਵੀਆ ਅਤੇ ਮਿਆਰੀ ਟੈਸਟਾਂ ਨੂੰ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਇਹ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮਾਂ ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਸਾਹਮਣੇ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਗੁੰਝਲਦਾਰ ਅਤੇ ਸੀਮਤ ਸਮੱਸਿਆਵਾਂ ਰਾਹੀਂ ਕਿਵੇਂ ਤਰਕ (reasoning) ਕਰੇਗਾ। ਕਿਸੇ ਵੀ ਲਾਰਜ ਲੈਂਗੂਏਜ ਮਾਡਲ ਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਪਹੁੰਚਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇੱਕ ਅਜਿਹੇ ਹਾਰਨੈਸ (harness) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਲੋੜਾਂ ਅਨੁਸਾਰ ਵਿਸ਼ੇਸ਼ ਬੌਧਿਕ ਪੈਟਰਨਾਂ ਦੀ ਪਰਖ ਕਰੇ। ਰੀਜ਼ਨਿੰਗ ਬੈਂਚਮਾਰਕ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਮਾਡਲ ਚੈਟਬੋਟਾਂ ਤੋਂ ਵੱਖਰੇ ਹੋ ਕੇ ਆਪਣੀ ਕਾਬਲੀਅਤ ਸਾਬਤ ਕਰਦੇ ਹਨ।

ਇਹ ਗਾਈਡ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇੱਕ ਕੇਂਦਰਿਤ ਰੀਜ਼ਨਿੰਗ ਬੈਂਚਮਾਰਕ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਬਾਰੇ ਦੱਸਦੀ ਹੈ। ਤੁਸੀਂ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਆਰਕੀਟੈਕਚਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋਗੇ: DeepSeek R1 671B MoE, Llama 3.3 70B, ਅਤੇ Qwen 3 32B। GPU ਕਲੱਸਟਰਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇਹਨਾਂ ਤਿੰਨਾਂ ਨੂੰ Oxlo.ai ਰਾਹੀਂ ਚਲਾਓਗੇ। ਮੁਲਾਂਕਣ ਲਈ, ਤੁਸੀਂ ਰੀਜ਼ਨਿੰਗ ਦੀ ਸਪਸ਼ਟਤਾ, ਸਹੀ ਹੋਣ ਅਤੇ ਕੋਡ ਦੀ ਗੁਣਵੱਤਾ ਦੇ ਆਧਾਰ 'ਤੇ ਆਊਟਪੁੱਟ ਨੂੰ ਸਕੋਰ ਕਰਨ ਲਈ Kimi K2.6 ਨੂੰ ਜੱਜ ਵਜੋਂ ਵਰਤੋਗੇ।

ਰੀਜ਼ਨਿੰਗ (Reasoning) ਪਹਿਲਾਂ ਕਿਉਂ ਟੁੱਟਦੀ ਹੈ

ਪ੍ਰੋਡਕਸ਼ਨ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਕਾਰਨ ਬਹੁਤ ਘੱਟ ਹੀ ਵਿਆਕਰਨਿਕ ਗਲਤੀਆਂ ਜਾਂ ਇਨਕਾਰ ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਇਹ ਸੂਖਮ ਤਰਕਸ਼ੀਲ ਗਲਤੀਆਂ ਵਾਂਗ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਮਾਡਲ ਕਿਸੇ ਸੀਮਾ (constraint) ਨੂੰ ਗਲਤ ਸਮਝਦੇ ਹੋਏ, ਕੋਈ ਕਦਮ ਛੱਡਦੇ ਹੋਏ, ਜਾਂ ਵਿਚਕਾਰ ਹੀ ਕਿਸੇ ਵੇਰੀਏਬਲ ਨੂੰ ਚੁੱਪਚਾਪ ਬਦਲਦੇ ਹੋਏ, ਆਤਮ-ਵਿਸ਼ਵਾਸ ਨਾਲ ਭਰਪੂਰ ਲਿਖਤ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਜਨਤਕ ਬੈਂਚਮਾਰਕ ਅਕਸਰ ਡੂੰਘਾਈ ਦੀ ਬਜਾਏ ਵਿਸ਼ਾਲਤਾ ਨੂੰ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਮਾਡਲ ਕਿਸੇ ਔਖੀ ਕੰਬੀਨੇਟੋਰੀਅਲ (combinatorial) ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕੀਤੇ ਬਿਨਾਂ ਵੀ ਵਧੀਆ ਸਕੋਰ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਨਿਸ਼ਾਨਾ ਬਣਾਇਆ ਗਿਆ ਬੈਂਚਮਾਰਕ ਇਸ ਮੁੱਦੇ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ। ਇਹ ਹਰ ਮਾਡਲ ਨੂੰ ਇੱਕੋ ਜਿਹੀ ਸੀਮਤ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਟਾਸਕ ਦਿੰਦਾ ਹੈ, ਇੱਕ ਪਛਾਣਨਯੋਗ ਚੇਨ ਆਫ ਥੌਟ (chain of thought) ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਮਾਪਦਾ ਹੈ ਕਿ ਕੀ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੱਲ ਅਸਲ ਵਿੱਚ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਮਾਡਲ ਡਿਸਕਰੀਟ ਮੈਥ (discrete math) ਰਾਹੀਂ ਲਗਾਤਾਰ ਤਰਕ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਉਹ ਤੁਹਾਡੇ ਇਨਵੈਂਟਰੀ ਅਲੋਕੇਸ਼ਨ, ਸ਼ਡਿਊਲਿੰਗ ਇੰਜਣ, ਜਾਂ ਰਿਸੋਰਸ ਰਾਊਟਰ ਨੂੰ ਵੀ ਭਰੋਸੇਮੰਦ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਸੰਭਾਲ ਸਕੇਗਾ।

ਮਾਡਲ ਅਤੇ ਪਲੇਟਫਾਰਮ

DeepSeek R1 671B MoE ਇੱਕ mixture-of-experts ਡਿਜ਼ਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਦਿੱਤੇ ਗਏ ਟੋਕਨ ਲਈ ਇਸਦੇ 671 ਬਿਲੀਅਨ ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਹੀ ਐਕਟੀਵੇਟ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਿ ਲਾਗਤ-ਤੋਂ-ਪ੍ਰਦਰਸ਼ਨ (cost-to-performance) ਕਰਵ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕਦੇ-ਕਦੇ ਇਸਦੀ ਰੀਜ਼ਨਿੰਗ ਦੇ ਤਰੀਕੇ ਨੂੰ ਵੀ ਬਦਲ ਦਿੰਦਾ ਹੈ। Llama 3.3 70B ਇੱਕ ਡੈਂਸ (dense) ਮਾਡਲ ਹੈ, ਅਤੇ Qwen 3 32B ਇੱਕ ਛੋਟੇ ਪੱਧਰ 'ਤੇ ਹੈ ਜਿਸ ਵਿੱਚ ਮਜ਼ਬੂਤ ਮਲਟੀਲਿੰਗੁਅਲ ਅਤੇ ਕੋਡਿੰਗ ਯੋਗਤਾਵਾਂ ਹਨ। ਇਹਨਾਂ ਤਿੰਨਾਂ ਦੀ ਤੁਲਨਾ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਕੀ ਰੀਜ਼ਨਿੰਗ ਦੀ ਗੁਣਵੱਤਾ ਕੁੱਲ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਗਿਣਤੀ, ਐਕਟਿਵ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਗਿਣਤੀ, ਜਾਂ ਟ੍ਰੇਨਿੰਗ ਵਿਧੀ ਨਾਲ ਸਬੰਧਤ ਹੈ।

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

ਤੁਹਾਨੂੰ Python 3.10 ਜਾਂ ਇਸ ਤੋਂ ਨਵਾਂ, OpenAI Python ਲਾਇਬ੍ਰੇਰੀ, ਅਤੇ ਇੱਕ Oxlo.ai API ਕੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।

ਕਦਮ 1: ਐਂਡਪੁਆਇੰਟ (Endpoint) ਨਾਲ ਜੁੜੋ

ਕਿਉਂਕਿ Oxlo.ai ਇੱਕ OpenAI-ਅਨੁਕੂਲ API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ

DeepSeek R1, Llama 3.3 70B, ਅਤੇ Qwen 3 32B ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਪ੍ਰੋਂਪਟ (prompt) ਦਿਓ। ਪੂਰੇ ਟੈਕਸਟ ਜਵਾਬਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਅੰਤਿਮ ਕੋਡ ਬਲਾਕਾਂ ਨੂੰ। ਉਹਨਾਂ ਨੂੰ ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਮਾਡਲ ਆਈਡੈਂਟੀਫਾਇਰਾਂ (identifiers) ਦੇ ਨਾਲ ਸਟੋਰ ਕਰੋ। ਕਿਉਂਕਿ Oxlo.ai ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਦੇ ਹਿਸਾਬ ਨਾਲ ਕੀਮਤ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਪੈਸੇ ਬਚਾਉਣ ਲਈ ਆਪਣੇ ਪ੍ਰੋਂਪਟ ਨੂੰ ਛੋਟਾ ਕਰਨ ਜਾਂ ਸਪਸ਼ਟ ਕਰਨ ਵਾਲੀਆਂ ਹਦਾਇਤਾਂ ਨੂੰ ਹਟਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਸਹੀ ਹੋਣ ਲਈ ਖਰਚ ਕਰ ਸਕਦੇ ਹੋ। ਉਹ ਸਥਿਰਤਾ ਤੁਹਾਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਖਰਚੇ ਦੀ ਚਿੰਤਾ ਦੇ ਪ੍ਰੋਂਪਟ ਡਿਜ਼ਾਈਨ ਨੂੰ ਵਾਰ-ਵਾਰ ਸੁਧਾਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਸਾਫ਼ ਪ੍ਰਯੋਗ ਅਤੇ ਵਧੇਰੇ ਨਿਰਭਰਯੋਗ ਨਤੀਜੇ ਮਿਲਦੇ ਹਨ।

ਜੇਕਰ ਤੁਹਾਡਾ ਬਜਟ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਤਾਂ ਹਰੇਕ ਮਾਡਲ ਨੂੰ ਕਈ ਵਾਰ ਚਲਾਓ। Reasoning ਮਾਡਲਾਂ ਵਿੱਚ stochastic generations ਦੇ ਅਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖਤਾਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਇਹ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕੀ ਇੱਕ ਉੱਚ ਸਕੋਰ ਲਗਾਤਾਰ ਯੋਗਤਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਾਂ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਕਿਸਮਤ ਵਾਲਾ ਨਮੂਨਾ ਹੈ।

ਕਦਮ 4: LLM ਜੱਜ ਨਾਲ ਗ੍ਰੇਡ ਕਰੋ

ਮੈਨੂਅਲ ਸਕੋਰਿੰਗ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਪਰ ਸਿਰਫ਼ ਨੰਬਰਾਂ ਵਾਲੇ ਰੂਬਰਿਕਸ (rubrics) ਸੂਖਮਤਾਵਾਂ ਨੂੰ miss ਕਰ ਦਿੰਦੇ ਹਨ। ਵਿਚਕਾਰਲਾ ਰਸਤਾ ਇੱਕ LLM ਜੱਜ ਹੈ। ਇੱਥੇ, ਤੁਸੀਂ Kimi K2.6 ਦੀ ਵਰਤੋਂ ਕਰੋਗੇ। ਇਸਨੂੰ ਅਸਲ ਸਮੱਸਿਆ, ਰੂਬਰਿਕ, ਅਤੇ ਹਰੇਕ ਉਮੀਦਵਾਰ ਜਵਾਬ ਦਿਓ। ਇਸਨੂੰ ਤਿੰਨ ਖਾਸ ਪਹਿਲੂਆਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਕਹੋ:

  • Reasoning clarity: ਕੀ ਵਿਆਖਿਆ ਅਸਲ ਵਿੱਚ ਤਰਕ (logic) ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ, ਜਾਂ ਇਹ ਸਿਰਫ਼ ਉਪਰ-ਉਪਰੋਂ ਗੱਲਾਂ ਕਰਦੀ ਹੈ?
  • Correctness: ਕੀ ਪ੍ਰਸਤਾਵਿਤ ਹੱਲ ਸਾਰੇ ਦੱਸੇ ਗਏ ਨਿਯਮਾਂ (constraints) ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ?
  • Code quality: ਕੀ Python ਸਾਫ਼, ਚਲਾਉਣਯੋਗ ਅਤੇ ਸਪਸ਼ਟ ਬੱਗਾਂ ਤੋਂ ਮੁਕਤ ਹੈ?

ਜੱਜ ਨੂੰ JSON ਫਾਰਮੈਟ ਵਿੱਚ ਸਕੋਰ ਵਾਪਸ ਕਰਨ ਲਈ ਕਹੋ। ਸਟ੍ਰਕਚਰਡ ਆਉਟਪੁੱਟ ਨਾਲ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ, ਰੁਝਾਨਾਂ (trends) ਨੂੰ ਪਲਾਟ ਕਰਨਾ, ਅਤੇ ਅਗਲੇਰੀ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਵਰਤਣਾ ਬਹੁਤ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੱਜ ਪ੍ਰੋਂਪਟ ਨੂੰ ਸਖ਼ਤ ਰੱਖੋ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ "ਉੱਤਰ ਨੂੰ ਰੇਟ ਕਰੋ" ਵਰਗੀ ਅਸਪਸ਼ਟ ਹਦਾਇਤ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਅਸਪਸ਼ਟ ਨਤੀਜੇ ਮਿਲਣਗੇ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਇੱਕ ਸਹੀ bin-packing ਹੱਲ ਕੀ ਹੈ। ਸਮਰੱਥਾ (Capacities) ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਹਰ ਆਈਟਮ ਨੂੰ ਅਸਾਈਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੋਡ ਸਿੰਟੈਕਟਿਕਲੀ (syntactically) ਵੈਲਿਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡੇ ਮਾਪਦੰਡ ਜਿੰਨੇ ਵਧੇਰੇ ਸਪਸ਼ਟ ਹੋਣਗੇ, ਤੁਹਾਡੇ ਗ੍ਰੇਡ ਉਨੇ ਹੀ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਹੋਣਗੇ।

ਹਮੇਸ਼ਾ ਜੱਜ ਦੀ ਜਾਂਚ (spot-check) ਕਰਦੇ ਰਹੋ। ਜੇਕਰ Kimi K2.6 ਸਿਰਫ਼ ਉਪਰਲੇ ਪੱਧਰ ਦੀ ਚਮਕ (polish) ਦੇ ਕਾਰਨ ਲਗਾਤਾਰ ਇੱਕ ਮਾਡਲ ਨੂੰ ਜ਼ਿਆਦਾ ਰੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਬੈਂਚਮਾਰਕ ਖਰਾਬ ਹੈ। ਇੱਕ ਛੋਟਾ ਮਾਨਵੀ ਆਡਿਟ ਲੇਅਰ "garbage-in-garbage-out" ਮੁਲਾਂਕਣ ਨੂੰ ਰੋਕਦਾ ਹੈ।

ਕਦਮ 5: ਰਿਪੋਰਟ ਬਣਾਓ

JSON ਸਕੋਰਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਾਡਲ ਦੇ ਅਸਲ ਆਉਟਪੁੱਟ ਦੇ ਅੰਸ਼ਾਂ (excerpts) ਨਾਲ ਜੋੜੋ। ਸਭ ਕੁਝ ਇੱਕ ਸਿੰਗਲ ਫਾਈਲ ਵਿੱਚ ਪਾ ਦਿਓ ਜੋ ਤੁਹਾਡੇ ਰੈਪੋਜ਼ਟਰੀ (repository) ਵਿੱਚ ਰਹੇ। ਜਦੋਂ ਤੁਸੀਂ ਮਾਡਲ ਵਰਜ਼ਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ ਜਾਂ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਬਦਲਾਅ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ pull request ਵਿੱਚ ਅੰਤਰ (diff) ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਵਿਵਹਾਰ ਕਿਵੇਂ ਬਦਲਿਆ। ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਰੱਖਿਆ ਗਿਆ ਬੈਂਚਮਾਰਕ ਇੱਕ ਜਿਉਂਦੀ-ਜਾਗਦੀ ਦਸਤਾਵੇਜ਼ੀ (documentation) ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਪ੍ਰੋਡਕਸ਼ਨ ਪਾਈਪਲਾਈਨ ਇੱਕ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਦੂਜੇ ਨਾਲੋਂ ਕਿਉਂ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਚੁੱਪਚਾਪ ਹੋਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ (regressions) ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ।

ਰਿਪੋਰਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕਰੋ ਕਿ ਕੋਈ ਸਾਥੀ ਕੋਡ ਚਲਾਏ ਬਿਨਾਂ ਇਸਨੂੰ ਪੜ੍ਹ ਸਕੇ। ਇਸ ਵਿੱਚ ਸਮੱਸਿਆ ਦਾ ਕਥਨ (problem statement), ਪ੍ਰੋਂਪਟ ਟੈਂਪਲੇਟ, ਸਕੋਰ, ਅਤੇ ਹਰੇਕ ਮਾਡਲ ਦੇ reasoning trace ਤੋਂ ਪ੍ਰਤੀਨਿਧ ਕੋਟਸ (quotes) ਸ਼ਾਮਲ ਕਰੋ। ਪਾਰਦਰਸ਼ਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇਕਰ DeepSeek R1 ਉੱਚ ਸਕੋਰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਪਰ ਕਿਸੇ ਨਿਯਮ (constraint) ਨੂੰ ਗਲਤ ਦੱਸਦਾ ਹੈ (hallucinates), ਤਾਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਉਹ ਟੈਕਸਟ ਅੰਸ਼ ਵਿੱਚ ਦਿਖਾਈ ਦੇਵੇ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਔਸਤ ਵਿੱਚ ਦਬਿਆ ਹੋਵੇ।

ਪਾਈਪਲਾਈਨ ਨੂੰ ਆਟੋਮੇਟ ਕਰਨਾ

ਇੱਕ ਬੈਂਚਮਾਰਕ ਜੋ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਰਹਿੰਦਾ ਹੈ, ਉਹ ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਅੰਦਰ ਭੁੱਲਿਆ ਜਾਂਦਾ ਹੈ। ਇਸਨੂੰ ਰਾਤਰੀਨ (nightly) CI ਜੌਬ ਵਿੱਚ ਬਦਲ ਦਿਓ। ਹਰ ਰਾਤ, ਹਾਰਨੈੱਸ (harness) ਚੱਲਦਾ ਹੈ, Oxlo.ai 'ਤੇ ਮੌਜੂਦਾ ਮਾਡਲ ਵਰਜ਼ਨਾਂ ਨੂੰ ਕੁਐਰੀ (query) ਕਰਦਾ ਹੈ, bin-packing ਟਾਸਕ ਚਲਾਉਂਦਾ ਹੈ, ਆਉਟਪੁੱਟ ਨੂੰ ਗ੍ਰੇਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਕਮਿਟ (commit) ਕਰਦਾ ਹੈ। ਜੇਕਰ ਮਾਡਲ ਅੱਪਡੇਟ ਕਾਰਨ ਸਹੀ ਹੋਣ ਵਿੱਚ ਦਸ-ਅੰਕਾਂ ਦੀ ਗਿਰਾਵਟ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਆਪਣੇ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ।

ਇੱਕ ਵਾਰ ਜਦੋਂ ਮੁੱਖ ਹਾਰਨੈੱਸ ਸਥਿਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਵਧਾਓ। ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਗੈਰ-ਜ਼ਰੂਰੀ ਦਸਤਾਵੇਜ਼ ਭਰ ਕੇ long-context ਵੇਰੀਐਂਟਸ ਦਾ ਟੈਸਟ ਕਰੋ, ਫਿਰ bin-packing ਸਵਾਲ ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖੋ। ਵੱਡੇ context windows ਬੇਕਾਰ ਹਨ ਜੇਕਰ noise ਦੇ ਅਧੀਨ reasoning ਟੁੱਟ ਜਾਂਦੀ ਹੈ। ਦੇਖੋ ਕਿ ਕਿਹੜੇ ਮਾਡਲ ਤਰਕਸ਼ੀਲ ਅਨੁਸ਼ਾਸਨ ਬਣਾਈ ਰੱਖਦੇ ਹਨ ਜਦੋਂ ਸਿਗਨਲ ਦਸ ਹਜ਼ਾਰ ਟੋਕਨਾਂ ਦੇ ਵਿਗਾੜ ਵਿੱਚ ਦਬਿਆ ਹੋਵੇ।

ਅਸਲ ਸਿੱਖਿਆ

ਜਨਤਕ ਲੀਡਰਬੋਰਡ ਆਮ ਗਿਆਨ ਨੂੰ ਮਾਪਦੇ ਹਨ। ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਕੁਝ ਵਧੇਰੇ ਸੀਮਤ ਅਤੇ ਔਖਾ ਮਾਪਦੀ ਹੈ। ਇੱਕ ਸਧਾਰਨ, ਦੁਹਰਾਉਣਯੋਗ ਹਾਰਨੈੱਸ ਜੋ ਮਾਡਲਾਂ ਨੂੰ constrained optimization ਰਾਹੀਂ ਤਰਕ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਨਿਰੰਤਰ ਮਾਪਦੰਡਾਂ ਨਾਲ ਗ੍ਰੇਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ git ਵਿੱਚ ਵਰਜ਼ਨ ਕਰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਇਕੱਠੇ ਸਕੋਰ ਨਾਲੋਂ ਵਧੇਰੇ ਕਾਰਜਸ਼ੀਲ ਜਾਣਕਾਰੀ ਦੇਵੇਗਾ। ਉਹ ਬੈਂਚਮਾਰਕ ਬਣਾਓ ਜੋ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਦੇ ਅਨੁਕੂਲ ਹੋਵੇ, ਇਸਨੂੰ ਉਹਨਾਂ ਆਰਕੀਟੈਕਚਰਾਂ 'ਤੇ ਚਲਾਓ ਜੋ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਆਪਣੇ ਪ੍ਰੋਡਕਸ਼ਨ ਚੋਣ ਦਾ ਫੈਸਲਾ ਕਰਨ ਦਿਓ।

ਸਰੋਤ: DeepSeek R1 Model Architecture and Benchmarks

ਕਮਿਊਨਿਟੀ: GyaanSetu AI on Telegram