ਤੁਹਾਡੇ Evals ਵੀ Flaky ਹਨ: ਉਸ Pass Rate 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਬੰਦ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਦੁਬਾਰਾ ਪੈਦਾ ਨਹੀਂ ਕਰ ਸਕਦੇ

ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਜਾਣਦੇ ਹਨ ਕਿ AI agents non-deterministic ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਇੱਕੋ ਜਿਹਾ prompt ਭੇਜਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਵੱਖਰੇ outputs ਮਿਲਦੇ ਹਨ।

ਅਸੀਂ ਇਸ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲਿਆ। ਅਸੀਂ ਇਹਨਾਂ agents ਨੂੰ ਗ੍ਰੇਡ ਕਰਨ ਲਈ LLMs ਨੂੰ judges ਵਜੋਂ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ।

ਪਰ ਅਸੀਂ ਇੱਕ ਵੱਡੀ ਗਲਤੀ ਕੀਤੀ। ਅਸੀਂ ਮੰਨ ਲਿਆ ਕਿ ਸਾਡੇ judges deterministic ਸਨ। ਉਹ ਨਹੀਂ ਹਨ।

ਤੁਹਾਡੀ eval suite ਇੱਕ ਰੈਂਡਮ ਸਿਸਟਮ ਹੈ ਜੋ ਦੂਜੇ ਰੈਂਡਮ ਸਿਸਟਮ ਨੂੰ ਗ੍ਰੇਡ ਕਰ ਰਹੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਮਾਪਦੇ ਨਹੀਂ ਹੋ ਕਿ ਤੁਹਾਡਾ grader ਕਿੰਨਾ ਡੋਲਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ quality gate ਨਹੀਂ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਸਿੱਕੇ ਦੀ ਉਛਾਲ (coin flip) ਹੈ।

ਮੈਂ ਇੱਕ support agent ਨਾਲ ਅਜਿਹਾ ਹੁੰਦੇ ਦੇਖਿਆ। ਡੈਸ਼ਬੋਰਡ ਹਫ਼ਤਿਆਂ ਤੱਕ ਹਰਾ (green) ਰਿਹਾ। ਫਿਰ, ਗਾਹਕਾਂ ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਵਧ ਗਈਆਂ। ਮੈਂ 200 ਪੁਰਾਣੇ ਜਵਾਬਾਂ 'ਤੇ ਉਹੀ eval ਚਲਾਇਆ। ਉਹਨਾਂ ਵਿੱਚੋਂ 14 ਨੇ ਆਪਣਾ ਫੈਸਲਾ (verdict) ਬਦਲ ਦਿੱਤਾ। Agent ਨਹੀਂ ਬਦਲਿਆ ਸੀ। Judge ਨੇ ਆਪਣਾ ਮਨ ਬਦਲ ਲਿਆ ਸੀ।

ਇੱਕ flaky gate ਦਾ ਹੋਣਾ ਨਾ ਹੋਣ ਨਾਲੋਂ ਵੀ ਮਾੜਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਝੂਠਾ ਭਰੋਸਾ ਦਿੰਦਾ ਹੈ।

ਤੁਹਾਡੇ evals ਅਸਫਲ ਹੋਣ ਦੇ ਤਿੰਨ ਕਾਰਨ ਹਨ:

  • The judge model: ਹਰ LLM judge ਵਿੱਚ variance ਹੁੰਦਾ ਹੈ। Temperature 0 'ਤੇ ਵੀ, providers ਇੱਕੋ ਜਿਹੇ ਨਤੀਜੇ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੇ। ਇੱਕ ਚੁੱਪਚਾਪ ਮਾਡਲ ਅੱਪਡੇਟ ਰਾਤੋ-ਰਾਤ ਤੁਹਾਡੇ baseline ਨੂੰ ਬਰਬਾਦ ਕਰ ਸਕਦਾ ਹੈ।
  • The harness: ਜੇਕਰ ਤੁਹਾਡੇ runs ਦੇ ਵਿਚਕਾਰ ਤੁਹਾਡਾ context ਜਾਂ tool outputs ਬਦਲ ਜਾਂਦੇ ਹਨ, ਤਾਂ judge ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਦੇਖਦਾ ਹੈ। Input drift ਹੋ ਗਿਆ।
  • The rubric: "ਕੀ ਇਹ ਵਧੀਆ ਹੈ?" ਵਰਗੇ ਅਸਪਸ਼ਟ ਨਿਯਮ variance ਪੈਦਾ ਕਰਦੇ ਹਨ। ਸਖ਼ਤ, ਖਾਸ ਨਿਯਮ ਇਸਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।

ਤੁਹਾਨੂੰ flaky evals ਨਾਲ flaky software tests ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ship ਨਾ ਕਰੋ। ਉਹਨਾਂ ਨੂੰ quarantine ਕਰੋ। Flake rate ਨੂੰ ਮਾਪੋ।

ਸਿਰਫ਼ ਇੱਕ pass rate ਦੀ ਰਿਪੋਰਟ ਕਰਨਾ ਬੰਦ ਕਰੋ। Agreement ਦੀ ਰਿਪੋਰਟ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।

ਹਰੇਕ judge call ਨੂੰ ਕਈ ਵਾਰ ਚਲਾਓ। ਜੇਕਰ judge ਆਪਣੇ ਆਪ ਨਾਲ ਸਹਿਮਤ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਤਾਂ verdict ਕੋਈ signal ਨਹੀਂ ਹੈ। ਇਹ UNSTABLE ਹੈ।

ਇੱਕ UNSTABLE ਨਤੀਜਾ ਤੁਹਾਡੇ CI/CD pipeline ਵਿੱਚ ਇੱਕ first-class outcome ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਨੂੰ ਸਾਫ਼ ਤੌਰ 'ਤੇ (fail loud) ਫੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਕ ਅਸਥਿਰ eval ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਦੋ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੈ:

  1. A scoring layer: ਇਹ stability ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ PASS, FAIL, ਜਾਂ UNSTABLE ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
  2. A tracing layer: ਤੁਹਾਨੂੰ ਹਰ run ਲਈ raw bytes, ਸਹੀ prompt, ਅਤੇ tool outputs ਦੇਖਣੇ ਚਾਹੀਦੇ ਹਨ।

Traces ਤੋਂ ਬਿਨਾਂ, ਤੁਹਾਨੂੰ ਲੱਗੇਗਾ ਕਿ ਮਾਡਲ ਸਿਰਫ਼ ਰੈਂਡਮ ਹੈ। ਤੁਸੀਂ temperature ਘਟਾਓਗੇ ਅਤੇ ਸੋਚੋਗੇ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਠੀਕ ਕਰ ਦਿੱਤਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕੀਤਾ। ਤੁਸੀਂ ਸਿਰਫ਼ bug ਨੂੰ ਸ਼ਾਂਤ ਕਰ ਦਿੱਤਾ ਹੈ।

ਅਸਲ ਕੁਆਲਿਟੀ ਬਣਾਉਣ ਲਈ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ:

  • ਸਿਰਫ਼ averages ਨਹੀਂ, agreement ਦੀ ਰਿਪੋਰਟ ਕਰੋ।
  • ਆਪਣੇ pipeline ਵਿੱਚ UNSTABLE ਨੂੰ ਇੱਕ failing state ਬਣਾਓ।
  • ਆਪਣੇ judge model versions ਨੂੰ pin ਕਰੋ।
  • ਜਦੋਂ ਕੋਈ check ਫੇਲ ਹੋ ਜਾਵੇ ਤਾਂ traces ਪੜ੍ਹੋ।

ਇੱਕ ਹਰਾ (green) dashboard ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਦੁਬਾਰਾ ਪੈਦਾ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਉਹ ਕੋਈ signal ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਕਹਾਣੀ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਸੁਣਾਉਂਦੇ ਹੋ।

Source: https://dev.to/saurav_bhattacharya/your-evals-are-flaky-too-stop-trusting-a-pass-rate-you-cant-reproduce-6pk

Optional learning community: https://t.me/GyaanSetuAi