ਜਿਸ LLM ਬੈਂਚਮਾਰਕ ਸਕੋਰ ਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ, ਉਹ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਹੈ
ਜ਼ਿਆਦਾਤਰ LLM ਲੀਡਰਬੋਰਡ ਤੁਹਾਨੂੰ ਝੂਠ ਬੋਲਦੇ ਹਨ।
ਪਿਛਲੇ ਮਹੀਨੇ ਮੈਂ ਇੱਕ agentic pipeline ਲਈ ਮਾਡਲਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ। ਮੈਨੂੰ ਕੋਡ ਜਨਰੇਸ਼ਨ ਅਤੇ multi-step reasoning ਦੀ ਲੋੜ ਸੀ। ਮੈਂ ਇੱਕ ਪ੍ਰਸਿੱਧ ਲੀਡਰਬੋਰਡ ਤੋਂ ਸਭ ਤੋਂ ਉੱਪਰਲੇ ਮਾਡਲ ਨੂੰ ਚੁਣਿਆ। ਮੈਂ ਇਸਨੂੰ ਲਾਂਚ ਕੀਤਾ। ਪਰ ਇਹ ਬੁਨਿਆਦੀ tool-use ਕੰਮਾਂ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ।
ਲੀਡਰਬੋਰਡ ਸਕੋਰ ਅਸਲੀ ਸੀ। ਪਰ ਇਹ ਮੇਰੇ ਕੰਮ ਲਈ ਬੇਕਾਰ ਸੀ।
ਪਬਲਿਕ ਬੈਂਚਮਾਰਕ ਮਾਡਲਾਂ ਦਾ ਇਕੱਲੇ ਟੈਸਟ ਕਰਦੇ ਹਨ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ, ਤੁਸੀਂ agents ਚਲਾਉਂਦੇ ਹੋ। Agents ਟੂਲਸ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਵੈੱਬ 'ਤੇ ਸਰਚ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੋਡ ਚਲਾਉਂਦੇ ਹਨ। ਸਟੈਂਡਰਡ ਬੈਂਚਮਾਰਕ ਇਸਨੂੰ ਨਹੀਂ ਮਾਪਦੇ।
LXT ਰਿਪੋਰਟਾਂ ਇੱਕ ਵੱਡਾ ਅੰਤਰ ਦਿਖਾਉਂਦੀਆਂ ਹਨ। ਫਰਵਰੀ 2026 ਵਿੱਚ, tool access ਦੇ ਨਾਲ, ਸਕੋਰ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਸਨ:
• Claude Opus 4.6: 53.1% • GPT-5.3 Codex: 36% • GLM-5: 32%
ਬਿਨਾਂ tool access ਦੇ, ਇਹ ਸਕੋਰ ਡਿੱਗ ਜਾਂਦੇ ਹਨ। Tool-assisted ਅਤੇ non-tool ਸਕੋਰਾਂ ਵਿਚਕਾਰ ਦਾ ਅੰਤਰ ਹੀ ਇਕਲੌਤਾ ਮਾਪਦੰਡ ਹੈ ਜੋ agents ਲਈ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
ਉਹ ਮਾਡਲ ਜੋ trivia ਜਾਂ static ਟੈਸਟਾਂ ਵਿੱਚ ਜਿੱਤਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਇੱਕ ਸਿੰਗਲ function call ਲਿਖਣ ਵਿੱਚ ਵੀ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਜੇਕਰ ਤੁਸੀਂ agents ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹਨਾਂ ਤਿੰਨ ਖੇਤਰਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ:
- Tool call reliability। ਕੀ ਮਾਡਲ ਵਿਘਨ (distraction) ਦੇ ਬਾਵਜੂਦ ਕਾਲਾਂ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਫਾਰਮੈਟ ਕਰਦਾ ਹੈ? ਕੀ ਇਹ ਗਲਤੀਆਂ ਤੋਂ ਸੁਧਾਰ ਕਰ ਸਕਦਾ ਹੈ?
- Context window economics। ਕੁਝ tool setups 10x ਤੋਂ 32x ਜ਼ਿਆਦਾ tokens ਦੀ ਲਾਗਤ ਪਾਉਂਦੇ ਹਨ। ਜੇਕਰ ਇੱਕ ਵੱਡੀ context window ਹਰ ਕਾਲ 'ਤੇ ਤੁਹਾਡੇ ਬਜਟ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਬੇਕਾਰ ਹੈ।
- Multi-step planning। ਕੀ ਮਾਡਲ 5-ਸਟੈਪ ਯੋਜਨਾ ਨੂੰ ਬਣਾਈ ਰੱਖ ਸਕਦਾ ਹੈ? ਬਹੁਤ ਸਾਰੇ ਮਾਡਲ ਤੀਜੇ ਸਟੈਪ ਤੱਕ ਹੀ ਸੰਦਰਭ (thread) ਗੁਆ ਲੈਂਦੇ ਹਨ।
ਪਬਲਿਕ ਲੀਡਰਬੋਰਡਾਂ ਨੂੰ ਆਪਣੇ ਇਕਲੌਤੇ ਮਾਰਗਦਰਸ਼ਕ ਵਜੋਂ ਵਰਤਣਾ ਬੰਦ ਕਰੋ। ਇਸ ਦੀ ਬਜਾਏ ਇਹ ਕਰੋ:
• ਇੱਕ mini-benchmark ਚਲਾਓ। ਆਪਣੇ logs ਵਿੱਚੋਂ 20 ਤੋਂ 50 ਅਸਲੀ tool calls ਦੀ ਵਰਤੋਂ ਕਰੋ। ਆਪਣੇ ਖਾਸ schema 'ਤੇ ਸ਼ੁੱਧਤਾ ਨੂੰ ਮਾਪੋ। • Error conditions ਦਾ ਟੈਸਟ ਕਰੋ। ਦੇਖੋ ਕਿ ਜਦੋਂ ਕੋਈ tool ਗਲਤੀ ਜਾਂ ਖਾਲੀ ਡੇਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ ਤਾਂ ਮਾਡਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। • ਪ੍ਰਤੀ ਟਾਸਕ ਲਾਗਤ ਨੂੰ ਮਾਪੋ। ਇੱਕ ਮਾਡਲ ਜੋ 5% ਬਿਹਤਰ ਹੈ ਪਰ 3x ਮਹਿੰਗਾ ਹੈ, ਉਹ ਅਕਸਰ ਗਲਤ ਚੋਣ ਹੁੰਦੀ ਹੈ। • ਵਿਸ਼ੇਸ਼ ਲੀਡਰਬੋਰਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਸਮੁੱਚੀ ਰੈਂਕਿੰਗ ਦੀ ਬਜਾਏ BenchLM.ai 'ਤੇ tool-use ਅਤੇ coding agent ਸਕੋਰਾਂ ਨੂੰ ਦੇਖੋ।
#3 ਰੈਂਕ ਵਾਲਾ ਮਾਡਲ ਇੱਕ ਸਿੰਗਲ prompt ਲਈ ਸੰਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਇਹ ਇੱਕ agent ਲਈ ਬਹੁਤ ਮਾੜਾ ਹੋ ਸਕਦਾ ਹੈ।
ਆਪਣੇ ਟੂਲਸ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਦੁਪਹਿਰ ਬਿਤਾਓ। ਇਹ ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਡੇ debugging ਦਾ ਇੱਕ ਹਫ਼ਤਾ ਬਚਾ ਲਵੇਗਾ।
ਤੁਸੀਂ ਆਪਣੇ ਮਾਡਲਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਿਵੇਂ ਕਰ ਰਹੇ ਹੋ? ਮੈਨੂੰ ਜਵਾਬਾਂ ਵਿੱਚ ਦੱਸੋ।
Optional learning community: https://t.me/GyaanSetuAi