మీ Evals కూడా అస్థిరంగా ఉన్నాయి: మీరు తిరిగి సృష్టించలేని పాస్ రేట్‌ను నమ్మడం ఆపండి

AI ఏజెంట్లు నాన్-డిటర్మినిస్టిక్ (non-deterministic) అని చాలా మందికి తెలుసు. మీరు ఒకే ప్రాంప్ట్‌ను పంపినా, వేర్వేరు అవుట్‌పుట్‌లు వస్తాయి.

మేము దీనిని అంగీకరించాము. ఈ ఏజెంట్లను గ్రేడ్ చేయడానికి LLMలను జడ్జీలుగా (judges) ఉపయోగించడం ప్రారంభించాము.

కానీ మేము ఒక పెద్ద తప్పు చేశాము. మా జడ్జీలు డిటర్మినిస్టిక్ (deterministic) అని మేము అనుకున్నాము. కానీ అవి అలా కావు.

మీ eval suite అనేది మరొక రాండమ్ సిస్టమ్‌ను గ్రేడ్ చేసే ఒక రాండమ్ సిస్టమ్ మాత్రమే. మీ గ్రేడర్ ఎంత అస్థిరంగా (wobbles) ఉందో మీరు కొలవకపోతే, మీకు క్వాలిటీ గేట్ (quality gate) లేదు. అది కేవలం ఒక నాణెం వేయడం (coin flip) లాంటిది.

ఒక సపోర్ట్ ఏజెంట్‌తో ఇలా జరగడం నేను చూశాను. డ్యాష్‌బోర్డ్ వారాల తరబడి గ్రీన్ (green) గానే ఉంది. ఆ తర్వాత, కస్టమర్ ఫిర్యాదులు ఒక్కసారిగా పెరిగాయి. నేను 200 పాత స్పందనలపై అదే evalను రన్ చేశాను. వాటిలో 14 తీర్పులు మారిపోయాయి. ఏజెంట్ మారలేదు, జడ్జి తన నిర్ణయాన్ని మార్చుకుంది.

అస్థిరమైన గేట్ (flaky gate) లేని గేట్ కంటే ప్రమాదకరమైనది. అది మీకు తప్పుడు నమ్మకాన్ని కలిగిస్తుంది.

మీ evals విఫలం కావడానికి మూడు కారణాలు ఉన్నాయి:

  • జడ్జి మోడల్ (The judge model): ప్రతి LLM జడ్జీలో వైవిధ్యం (variance) ఉంటుంది. టెంపరేచర్ 0 వద్ద కూడా, ప్రొవైడర్లు ఒకే ఫలితాన్ని ఇస్తామని గ్యారెంటీ ఇవ్వరు. ఒక నిశ్శబ్ద మోడల్ అప్‌డేట్ మీ బేస్‌లైన్‌ను రాత్రికి రాత్రే పాడు చేయవచ్చు.
  • హార్నెస్ (The harness): రన్‌ల మధ్య మీ కాంటెక్స్ట్ లేదా టూల్ అవుట్‌పుట్‌లు మారితే, జడ్జికి వేరే ప్రశ్న కనిపిస్తుంది. ఇన్‌పుట్ డ్రిఫ్ట్ (drift) అయింది.
  • రూబ్రిక్ (The rubric): "ఇది బాగుందా?" వంటి అస్పష్టమైన నియమాలు వైవిధ్యానికి దారితీస్తాయి. కచ్చితమైన, నిర్దిష్టమైన నియమాలు దానిని తగ్గిస్తాయి.

అస్థిరమైన (flaky) evalsను అస్థిరమైన సాఫ్ట్‌వేర్ టెస్ట్‌ల వలె పరిగణించాలి. వాటిని షిప్ (ship) చేయకండి. వాటిని క్వారంటైన్ (quarantine) చేయండి. ఫ్లేక్ రేట్‌ను (flake rate) కొలవండి.

కేవలం ఒకే పాస్ రేట్‌ను రిపోర్ట్ చేయడం ఆపండి. అగ్రిమెంట్‌ను (agreement) రిపోర్ట్ చేయడం ప్రారంభించండి.

ప్రతి జడ్జి కాల్‌ను బహుళ సార్లు రన్ చేయండి. జడ్జి తన నిర్ణయంతో తానే ఏకీభవించలేకపోతే, ఆ తీర్పు ఒక సిగ్నల్ కాదు. అది UNSTABLE.

మీ CI/CD పైప్‌లైన్‌లో ఒక UNSTABLE ఫలితం అనేది ఒక ముఖ్యమైన అవుట్‌కమ్ (outcome) కావాలి. అది స్పష్టంగా ఫెయిల్ (fail) అవ్వాలి.

అస్థిరమైన evalను సరిచేయడానికి మీకు రెండు విషయాలు కావాలి:

  1. స్కోరింగ్ లేయర్ (A scoring layer): ఇది స్థిరత్వాన్ని లెక్కిస్తుంది మరియు ఫలితాలను PASS, FAIL, లేదా UNSTABLE గా మారుస్తుంది.
  2. ట్రేసింగ్ లేయర్ (A tracing layer): మీరు ప్రతి రన్ కోసం రా (raw) బైట్‌లు, ఖచ్చితమైన ప్రాంప్ట్ మరియు టూల్ అవుట్‌పుట్‌లను చూడాలి.

ట్రేస్‌లు (traces) లేకపోతే, మోడల్ కేవలం రాండమ్‌గా పనిచేస్తుందని మీరు అనుకుంటారు. మీరు టెంపరేచర్‌ను తగ్గించి, దాన్ని సరిచేసేశామని అనుకుంటారు. కానీ మీరు దాన్ని సరిచేయలేదు. మీరు కేవలం బగ్‌ను (bug) నిశ్శబ్దంగా మార్చారు అంతే.

నిజమైన నాణ్యతను నిర్మించడానికి ఈ నియమాలను పాటించండి:

  • కేవలం సగటులను (averages) మాత్రమే కాకుండా, అగ్రిమెంట్‌ను రిపోర్ట్ చేయండి.
  • మీ పైప్‌లైన్‌లో UNSTABLE ను ఫెయిలింగ్ స్టేట్‌గా (failing state) మార్చండి.
  • మీ జడ్జి మోడల్ వెర్షన్లను పిన్ (pin) చేయండి.
  • చెక్ ఫెయిల్ అయినప్పుడు ట్రేస్‌లను చదవండి.

మీరు తిరిగి సృష్టించలేని (reproduce చేయలేని) గ్రీన్ డ్యాష్‌బోర్డ్ ఒక సిగ్నల్ కాదు. అది మీరు మీకు మీరు చెప్పుకునే కథ మాత్రమే.

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