𝗟𝗟𝗠-𝗔𝘀-𝗝𝘂𝗱𝗴𝗲 ਦੀ ਭਰੋਸੇਯੋਗਤਾ 2026 ਵਿੱਚ
LLM-as-judge ਟੂਲ ਅੱਜਕੱਲ੍ਹ ਜ਼ਿਆਦਾਤਰ ਲੀਡਰਬੋਰਡ (leaderboards) ਅਤੇ ਮੁਲਾਂਕਣ ਪੋਸਟਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ।
ਜੂਨ 2026 ਦੀਆਂ ਅੱਠ ਨਵੀਆਂ ਖੋਜਾਂ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਖੋਜਾਂ ਸਾਹਮਣੇ ਲਿਆਉਂਦੀਆਂ ਹਨ ਕਿ AI ਜੱਜ ਅਕਸਰ ਆਪਣੇ ਆਪ ਨਾਲ ਹੀ ਅਸਹਿਮਤ ਹੁੰਦੇ ਹਨ। ਉਹ ਸਿੱਕੇ ਦੀ ਉਲਟੀ (coin flip) ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ।
ਡੇਟਾ ਤਿੰਨ ਮੁੱਖ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:
• ਘੱਟ ਭਰੋਸੇਯੋਗਤਾ: ਇੱਕ ਖੋਜ ਵਿੱਚ 29 ਕੰਮਾਂ (tasks) 'ਤੇ ਦੋ OpenAI ਜੱਜਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ। ਉਨ੍ਹਾਂ ਨੇ ਹਰੇਕ ਟੈਸਟ ਨੂੰ 50 ਵਾਰ ਦੁਹਰਾਇਆ। ਨਤੀਜੇ ਇੰਨੇ ਅਸੰਗਤ ਸਨ ਕਿ ਲੇਖਕਾਂ ਨੇ ਇਸਨੂੰ "The Coin Flip Judge" ਕਿਹਾ। ਇੱਕ ਵਾਰ ਦਾ ਫੈਸਲਾ ਜ਼ਿਆਦਾਤਰ ਸ਼ੋਰ (noise) ਹੁੰਦਾ ਹੈ।
• ਕੰਪਿਊਟ ਸੰਵੇਦਨਸ਼ੀਲਤਾ (Compute Sensitivity): ਟੈਸਟ ਦੌਰਾਨ ਤੁਸੀਂ ਕਿੰਨਾ ਕੰਪਿਊਟ (compute) ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹੋ, ਉਸ ਦੇ ਅਧਾਰ 'ਤੇ ਮਾਡਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬਦਲ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਮਾਡਲ ਲੀਡਰਬੋਰਡ 'ਤੇ ਸਿਰਫ਼ ਇਸ ਲਈ ਮਾੜਾ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਟੈਸਟ ਵਿੱਚ ਟੋਕਨ ਕੈਪ (token cap) ਘੱਟ ਸੀ। ਜੇਕਰ ਬਜਟ ਬਦਲਿਆ ਜਾਵੇ ਤਾਂ ਰੈਂਕਿੰਗ ਬਦਲ ਜਾਂਦੀ ਹੈ।
• ਬ੍ਰਾਂਡ ਪੱਖਪਾਤ (Brand Bias): ਜੱਜ GPT ਜਾਂ Claude ਵਰਗੇ ਮਸ਼ਹੂਰ ਨਾਮਾਂ ਪ੍ਰਤੀ ਤਰਜੀਹ ਦਿਖਾਉਂਦੇ ਹਨ। ਇਹ ਪੱਖਪਾਤ ਨਤੀਜਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਲਨਾ ਨੂੰ ਅਨੁਚਿਤ ਬਣਾਉਂਦਾ ਹੈ।
ਤੁਹਾਨੂੰ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:
ਇਕੱਲੇ ਡਿਵੈਲਪਰਾਂ ਲਈ: ਫਿਲਹਾਲ LLM-as-judge ਨੂੰ ਛੱਡ ਦਿਓ। 30 ਆਉਟਪੁੱਟਸ (outputs) ਨੂੰ ਹੱਥ ਨਾਲ ਲੇਬਲ ਕਰੋ। ਇੱਕ ਅਣਪਛਾਤਾ ਜੱਜ ਗਲਤ ਭਰੋਸਾ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਟੀਮਾਂ ਲਈ: ਅਜਿਹਾ ਟੂਲ ਚੁਣੋ ਜੋ ਮਨੁੱਖੀ ਲੇਬਲਿੰਗ (human labeling) ਨੂੰ ਆਸਾਨ ਬਣਾਵੇ। ਟੂਲਿੰਗ ਨਾਲੋਂ ਅਸਲ ਮਨੁੱਖੀ ਪੁਸ਼ਟੀ (human validation) ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ।
ਬੈਚ ਵਰਕਲੋਡਸ (batch workloads) ਲਈ: ਹਰੇਕ ਆਈਟਮ ਲਈ ਘੱਟੋ-ਘੱਟ 20 ਤੋਂ 50 ਟਰਾਇਲ ਚਲਾਓ। ਸ਼ੋਰ (noise) ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਬਹੁਮਤ ਵੋਟ (majority vote) ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਪ੍ਰੋਡਕਟ ਮਾਲਕਾਂ ਲਈ: ਜੇਕਰ ਕੋਈ ਵੈਂਡਰ 10 ਪੁਆਇੰਟਾਂ ਤੋਂ ਘੱਟ ਦੀ ਲੀਡ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਮੰਨ ਲਓ ਕਿ ਇਹ ਬਰਾਬਰੀ (tie) ਹੈ। ਛੋਟੇ ਅੰਤਰਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਲਈ ਨੋਇਜ਼ ਫਲੋਰ (noise floor) ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ।
ਇਹ ਪੁੱਛਣਾ ਬੰਦ ਕਰੋ ਕਿ ਕਿਹੜਾ ਜੱਜ ਸਭ ਤੋਂ ਵੱਧ ਸਕੋਰ ਕਰਦਾ ਹੈ। ਇਹ ਪੁੱਛੋ ਕਿ ਕਿਹੜਾ ਜੱਜ ਟੂਲ ਤੁਹਾਨੂੰ ਮਨੁੱਖਾਂ ਦੇ ਵਿਰੁੱਧ ਸਭ ਤੋਂ ਸਸਤੇ ਤਰੀਕੇ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਸਰੋਤ: https://dev.to/bean_bean/llm-as-judge-reliability-in-2026-what-8-june-studies-actually-show-eca