AI முகவர்களின் மதிப்பீடு: evals-ஐ உருவாக்கி உணர்வின்றி நம்பகத்தன்மையை அளப்பது

AI முகவர் வேலை செய்கிறது என்பது தெரிந்தாலும் ஏன் மதிப்பீடு தேவை

உண்மையில் அது சரியாகத் தெரியவில்லை. ஒரு வாரத்தில் முகவர் ஒரு முறையும் prompt மாற்றத்துக்குப் பின் சிக்காமல் இருந்தது — அது சரிசெய்ததா, அல்லது அது ஒரு வாரம் முழுக்க எளிய பணிகளா? ஒரு பொறியாளர் புதிய வார்ப்புரு எல்லாவற்றையும் மாற்றியது என்று நம்புகிறார், இன்னொருவர் அதே பதிவைப் பார்த்தும் எந்த வேறுபாடும் காணவில்லை. இருவரும் எதையும் கணக்கிடாத வரை மட்டுமே சரியானவர்கள்.

AI முகவர் மதிப்பீடு (evals) உணர்வை ஒரு எண்ணால் மாற்றுகிறது. நிலையான பணித் தொகுப்பை எடுக்கிறீர்கள், முகவரை ஓட்டுகிறீர்கள், முடிவை தானாகச் சரிபார்க்கிறீர்கள், மாற்றத்துக்கு முன்னும் பின்னும் அளவீடுகளை ஒப்பிடுகிறீர்கள். அப்போது «சிறப்பாகிவிட்டதா» என்ற விவாதம் அதிகாரத்தால் அல்ல, அட்டவணையால் தீர்க்கப்படுகிறது.

evals இல்லாமல் harness-இன் எந்த மாற்றமும் — prompt, AGENTS.md, கருவித் தொகுப்பு, மாதிரி — கண்மூடித்தனமான பந்தயம். evals-உடன் அது அளவிடக்கூடிய முடிவுடன் ஒரு சோதனை.

«உணர்வு» ஏன் ஏமாற்றுகிறது

முகவரின் வேலை பற்றிய உணர்வில் மூன்று முறையான பிழைகள் உள்ளன, அனைத்தும் தவறான நம்பிக்கையை நோக்கித் தள்ளுகின்றன.

• தப்பிப்பிழைத்தவரின் பிழை. வெற்றிகரமான ஓட்டங்கள் நினைவில் நிற்கின்றன, சக ஊழியர்களுக்குக் காட்டப்படுகின்றன; தோல்வியடைந்தவை மீண்டும் ஓட்டப்பட்டு மறக்கப்படுகின்றன. வெற்றிகரமான ஓட்டங்களிலிருந்து கணக்கிடப்பட்ட நம்பகத்தன்மை முகவர் எங்கே உண்மையில் உடைகிறது என்பதைச் சொல்வதில்லை.
• சிறிய மாதிரி. தொடர்ச்சியாக மூன்று வெற்றிகரமான பணிகள் — பாதி நேரம் வெற்றி பெறும் முகவருக்கும் கூட இது சாதாரண நிகழ்வு. அதன் நிகழ்தகவு 0,5³ = 12,5%, அதாவது ஏறத்தாழ ஒவ்வொரு எட்டாவது தொடர்.
• உறுதியான தொனி. முகவர் «தயார், எல்லா சோதனைகளும் தேறுகின்றன» என்று சரியாக இருந்தாலும் தவறாக இருந்தாலும் ஒரே நம்பிக்கையுடன் எழுதுகிறது. மாதிரியின் நம்பிக்கை அளவுத்திருத்தப்படவில்லை: பதிலின் தொனி சரியான தன்மைக்கான சமிக்ஞை அல்ல.

எனவே விதி: எழுதப்படாததும் மீண்டும் கணக்கிடப்படாததும் அளக்கப்படாததாகவே கருதப்படும்.

pass@k மற்றும் pass^k: குழப்பிக்கொள்ளப்படும் இரண்டு அளவீடுகள்

முகவர் நிர்ணயிக்கப்படாதது: அதே பணி மீண்டும் ஓடும்போது வெற்றி பெறலாம், தோல்வியடையலாம். எனவே ஒரு பணியை பல முறை ஓட்டி இரண்டு அளவீடுகளில் ஒன்றைக் கணக்கிடுகிறார்கள்.

pass@k — k முயற்சிகளில் குறைந்தது ஒன்று வெற்றி

இந்த அளவீடு குறியீடு உருவாக்க மதிப்பீட்டிலிருந்து வந்தது. «பல முயற்சிகள் கொடுத்தால் அமைப்பு கொள்கையளவில் பணியைத் தீர்க்க முடியுமா» என்ற கேள்விக்கு அது பதில் சொல்கிறது. மனிதர் பல விருப்பங்களில் சிறந்ததைத் தேர்ந்தெடுக்கும் சூழ்நிலைக்கு, அல்லது தோல்விகளை வடிகட்டும் நம்பகமான தானியங்கிச் சரிபார்ப்பு இருக்கும் சூழ்நிலைக்கு இது நேர்மையான அளவீடு.

pass^k — k முயற்சிகளும் வெற்றி

இந்த அளவீடு வேறு கேள்விக்குப் பதில் சொல்கிறது: «முகவர் இந்தப் பணியை எவ்வளவு நிலையாகத் தீர்க்கிறது». மேற்பார்வையின்றி வேலை செய்வதை அது விவரிக்கிறது — முகவர் பல முறை ஓடுகிறது, ஒவ்வொரு தோல்வியும் பணம் அல்லது நேரம் செலவழிக்கிறது.

இரண்டிற்குமிடையிலான வேறுபாடு மிகப் பெரியது. ஒரு முயற்சியில் முகவர் பணியை 70% நிகழ்தகவுடன் தீர்க்கிறது என்றும், முயற்சிகள் சுதந்திரமானவை என்றும் வைத்துக்கொள்ளுங்கள்:

pass@5 படி முகவர் கிட்டத்தட்ட சரியானதாகத் தெரிகிறது, pass^5 படி நம்பகமற்றது. இரண்டு எண்களும் சரியானவை, வெறுமனே வெவ்வேறு விஷயங்களை விவரிக்கின்றன. முகவரை சுயமாக வேலை செய்ய விட நினைத்தால், pass^k-ஐப் பாருங்கள்: நீங்கள் உண்மையான வேலையில் காண்பதற்கு அது நெருக்கமானது.

நடைமுறையில் எப்படிக் கணக்கிடுவது

ஒவ்வொரு பணியையும் n முறை (உதாரணமாக 5) ஓட்டி வெற்றிகளின் எண்ணிக்கை c-ஐ எழுதுங்கள். pass^k ஏறத்தாழ, k தொடர்ச்சியாக அனைத்தும் வெற்றி பெற்ற ஓட்டங்களின் விகிதத்திற்குச் சமம்; அதை எளிதாக, வெற்றி நிகழ்தகவை p = c / n எனக் கொண்டு அடுக்கில் உயர்த்தலாம். பணித் தொகுப்புக்கு பணிகளின் சராசரி எடுக்கவும்.

import json
from statistics import mean

# results.jsonl: {"task": "add-pagination", "runs": [true, true, false, true, true]}
rows = [json.loads(line) for line in open("results.jsonl")]

def pass_at_k(runs, k):
    p = sum(runs) / len(runs)
    return 1 - (1 - p) ** k

def pass_pow_k(runs, k):
    p = sum(runs) / len(runs)
    return p ** k

for k in (1, 3, 5):
    print(k,
          round(mean(pass_at_k(r["runs"], k) for r in rows), 3),
          round(mean(pass_pow_k(r["runs"], k) for r in rows), 3))

n சிறியதாக இருக்கும்போது p-இன் அடுக்கு மதிப்பீடு கரடுமுரடானது, ஆனால் harness பதிப்புகளை ஒன்றுக்கொன்று ஒப்பிட அது பொதுவாகப் போதுமானது. முக்கியமானது: ஒப்பீடுகளுக்கு இடையே n-உம் பணித் தொகுப்பும் மாறக்கூடாது.

மதிப்பீட்டுக்கான பணித் தொகுப்பை எப்படி உருவாக்குவது

பணித் தொகுப்பே முக்கிய சொத்து. சரியில்லாத பணிகளில் சிறந்த அளவீடு தவறானதையே அளக்கும்.

உங்கள் சொந்த யதார்த்தத்திலிருந்து பணிகளை எடுங்கள்

SWE-bench போன்ற பொது benchmark-கள் மாதிரிகளை ஒப்பிட உதவுகின்றன, ஆனால் அவற்றின் பணிகள் தேர்ந்தெடுக்கப்பட்டவை: தெளிவான விளக்கம், ஆயத்தச் சோதனைகள். உங்கள் களஞ்சியத்தில் தேவைகள் மங்கலானவை, சில இடங்களில் சோதனைகளே இல்லை, எனவே benchmark எண் உங்கள் சூழலில் முகவர் காட்டுவதை விடக் கிட்டத்தட்ட எப்போதும் அதிகமாக இருக்கும். சிறந்த ஆதாரம்: மூடப்பட்ட tickets மற்றும் பதிவில் உள்ள முகவரின் உண்மையான தோல்விகள்.

தொகுப்பின் அமைப்பு

• தொடக்கத்தில் 20–50 பணிகள். குறைவானால் சத்தம் பதிப்புகளுக்கிடையிலான வேறுபாட்டை விழுங்கிவிடும். அதிகமானால் ஓட்டம் விலை உயர்ந்ததாகி, அதை யாரும் ஓட்ட மாட்டார்கள்.
• வெவ்வேறு வகைகள்: புதிய அம்சம், பிழை திருத்தம், மறுசீரமைப்பு, வேறொரு தொகுதியின் பணி, பொறி உள்ள பணி (சரியான பதில் «அப்படிச் செய்யக்கூடாது» அல்லது «தெளிவுபடுத்தல் தேவை»).
• ஓட்டத்தில் தோற்ற ஒவ்வொரு பணியும் ஒரு சோதனையாகிறது. இப்படித் தொகுப்பு முகவர் எங்கே பலவீனமானது என்ற புரிதலுடன் வளர்கிறது, பின்னடைவுகள் கவனிக்கப்படாமல் திரும்புவதில்லை.
• நிலையான தொடக்க நிலை: குறிப்பிட்ட commit, உறைந்த சார்புகள், ஒரே சூழல். இல்லாவிட்டால் நீங்கள் முகவரை அல்ல, சூழலின் நகர்வை அளக்கிறீர்கள்.

பணியின் வடிவம்

ஒவ்வொரு பணியும் ஒரு விளக்கம், ஒரு தொடக்க நிலை, மனிதர் இல்லாமல் சரிபார்க்கக்கூடிய வெற்றி அளவுகோல் ஆகியவற்றைக் கொண்டது.

id: add-pagination
repo_ref: 3f2c1ab
prompt: |
  Добавь пагинацию в GET /payments: параметры limit (по умолчанию 20, максимум 100)
  и cursor. Ответ содержит next_cursor.
check:
  - pytest tests/test_payments_pagination.py
  - mypy app/
limits:
  max_changed_files: 6

கவனியுங்கள்: வெற்றி அளவுகோல் என்பது கட்டளைகளில் எழுதப்பட்ட Definition of Done. ஒரு பணிக்கான அளவுகோலை எழுத முடியாவிட்டால், அது முகவருக்கும் தெளிவற்ற முறையில் கொடுக்கப்பட்டுள்ளது என்பதற்கான சமிக்ஞை.

தானியங்கிச் சரிபார்ப்புகளா அல்லது LLM நடுவரா

முடிவை குறியீட்டாலோ இன்னொரு மாதிரியாலோ சரிபார்க்கலாம். ஒவ்வொரு முறைக்கும் அதற்கே உரிய எல்லை உண்டு.

விதி: முதலில் குறியீடு, நடுவர் அதன் மேலே

நிர்ணயமாகச் சரிபார்க்கக்கூடிய அனைத்தையும் நிர்ணயமாகச் சரிபாருங்கள். LLM நடுவரை குறியீட்டால் வெளிப்படுத்த முடியாத பண்புகளுக்கு மட்டும் சேர்க்கவும், ஒருபோதும் சோதனைகளுக்குப் பதிலாக அல்ல.

LLM நடுவரை பயனுள்ளதாக்குவது எப்படி

• உருவாக்குநருடன் வேறு சூழல். நடுவர் முகவரின் காரணங்களைப் பார்க்கக் கூடாது — பணி, அளவுகோல்கள், இறுதி diff மட்டுமே. இல்லாவிட்டால் அது அதே பிழைகளை மீண்டும் செய்யும்: இது N-பதிப்பு முறை, ஒரு பார்வைக்குப் பதில் இரண்டு சுயாதீனப் பார்வைகள்.
• «பத்து புள்ளி அளவில் மதிப்பிடு» என்பதற்குப் பதில் வழிகாட்டி (rubric). ஆம்/இல்லை பதில் தரும் குறிப்பான கேள்விகள்: «limit > 100-க்கான சரிபார்ப்பு உள்ளதா», «app/payments-க்கு வெளியே கோப்புகள் மாற்றப்பட்டனவா».
• கைமுறைக் குறியிடலில் அளவுத்திருத்தம். 20–30 முடிவுகளைக் கைமுறையாகக் குறியிட்டு நடுவரின் தீர்ப்புகளுடன் ஒப்பிடுங்கள். பொருத்தம் குறைவாக இருந்தால், நடுவரை அதிகம் நம்புவதற்குப் பதில் வழிகாட்டியை மாற்றுங்கள்.
• பிழைகளின் சமச்சீரற்ற தன்மை. தவறான «தயார்» என்பது தவறான «தயாரில்லை» என்பதை விடச் செலவு மிக்கது: முதலாவது உற்பத்திக்குச் செல்கிறது, இரண்டாவது ஒரு மறுஓட்டத்தின் செலவு மட்டுமே. சந்தேகம் வரும்போது நடுவர் நிராகரிக்கும் விதத்தில் அமைக்கவும்.

வெற்றி விகிதத்தைத் தவிர எந்த அளவீடுகளைக் கணக்கிடுவது

தீர்க்கப்பட்ட பணிகளின் விகிதம் மேல்பரப்பு மட்டுமே. எங்கே சரிசெய்ய வேண்டும் என்பதைக் கண்டறிய, பாரம்பரியப் பொறியியலின் நம்பகத்தன்மை அளவீடுகள் தேவை.

• MTBF — முகவர் சிக்குவதற்கு முன் எத்தனை படிகள் அல்லது பணிகளைக் கடக்கிறது. அது எவ்வளவு அரிதாக உடைகிறது என்பதைக் காட்டுகிறது.
• MTTR — தோல்விக்குப் பிறகு வேலை செய்யும் நிலைக்குத் திரும்ப எவ்வளவு நேரம் ஆகிறது. அதைக் குறைப்பது MTBF-ஐ உயர்த்துவதை விடப் பெரும்பாலும் மலிவானது: நல்ல முன்னேற்றக் கோப்பும் மீண்டும் உருவாக்கக்கூடிய சூழலும் மீட்பை பல மடங்கு குறைக்கின்றன.
• பாதிப்பின் ஆரம் — ஒரு தோல்வியான படி எவ்வளவு குறியீட்டைச் சேதப்படுத்துகிறது. diff வரம்பும் வேலை நகலின் தனிமைப்படுத்தலும் அதைக் கட்டுப்படுத்துகின்றன.
• தவறான «தயார்» விகிதம் — முகவர் வெற்றியை அறிவித்தும் சரிபார்ப்பு தோல்வியடைந்த பணிகள். மிக ஆபத்தான அளவீடு: முகவரின் அறிக்கையை நம்பலாமா என்பதை அதுவே காட்டுகிறது.
• செலவும் நேரமும் — பணிக்கான token-கள் மற்றும் நிமிடங்கள். வெற்றியை 5% உயர்த்தி செலவை இரட்டிப்பாக்கும் harness எப்போதும் வெல்வதில்லை.

தோல்விகளின் பதிவேடு: அன்றாட வேலையிலிருந்து evals

ஒவ்வொரு குழுவும் உடனே ஓட்டப்பந்தய அமைப்பை உருவாக்கத் தயாராக இருப்பதில்லை. குறைந்தபட்ச மதிப்பீடு மூன்று நெடுவரிசைத் தோல்விகளின் பதிவேடு.

| Задача                  | Результат                          | Слой          |
|-------------------------|------------------------------------|---------------|
| пагинация /payments     | «готово», 2 теста красные          | верификация   |
| фикс таймаута webhook   | 30 мин на pip install              | среда         |
| рефакторинг refunds     | старый синтаксис ORM               | контекст      |

«அடுக்கு» என்பது முகவர் உடையக்கூடிய ஐந்து இடங்களில் ஒன்று: பணியின் விவரக்குறிப்பு, சூழல், செயல்படுத்தும் சூழல், சரிபார்ப்புப் பின்னூட்டம், நிலை நிர்வாகம். இருபது பதிவுகளுக்குப் பிறகு உண்மையான தடை தெரியவரும், அது பெரும்பாலும் நீங்கள் நினைத்த இடத்தில் இருக்காது. பதிவேட்டின் ஒவ்வொரு வரியும் evals-இன் பணித் தொகுப்புக்கான வேட்பாளர்.

சக்திவாய்ந்த மாதிரி ஏன் உதவாது

முகவரின் தோல்விகளுக்கு முதல் எதிர்வினை — விலை உயர்ந்த மாதிரியைத் தேர்ந்தெடுப்பது. சில நேரங்களில் உதவும், ஆனால் பெரும்பாலும் benchmark-க்கும் உங்கள் யதார்த்தத்துக்கும் உள்ள இடைவெளியை மூடுவது மாதிரி அல்ல, அதைச் சுற்றியுள்ள சூழல்.

முகவர் சூழலை எழுப்ப அரை மணி நேரம் எடுத்தால் — அது சூழல் அடுக்கு, முதல்தர மாதிரியும் அதே அரை மணி நேரம் எடுக்கும். சோதனைகள் சிவப்பாக இருக்கும்போதும் முகவர் «தயார்» என்றால் — அது சரிபார்ப்பு அடுக்கு: உண்மையைச் சொல்லும் கட்டளை அதற்கு இல்லை. அது திட்டத்தின் மரபுகளைப் பின்பற்றாமல் குறியீடு எழுதினால் — திட்டத்தின் மரபுகள் அதற்குக் கொடுக்கப்படவில்லை. இவற்றில் எந்தப் பிரச்சினையும் மாதிரியின் அறிவைப் பற்றியது அல்ல.

evals இதை நேர்மையாகச் சரிபார்க்க அனுமதிக்கின்றன. தற்போதைய மாதிரியுடனும் விலை உயர்ந்த மாதிரியுடனும் தொகுப்பை ஓட்டுங்கள்; பின்னர் தற்போதைய மாதிரியுடனும் சரிபார்ப்புக் கட்டளைகளுடன் கூடிய AGENTS.md-உடனும். பெரும்பாலும் இரண்டாவது மாற்றம் முதலாவதை விட அதிக பலனைத் தருகிறது, செலவு பூஜ்ஜியம். ஆனால் வார்த்தைக்காக நம்பாதீர்கள்: இத்தகைய ஒப்பீடுகளுக்காகவே தொகுப்பு தேவை.

படிப்படியான திட்டம்: ஒரு வாரத்தில் AI முகவர் மதிப்பீடு

1. நாள் 1. தோல்விகளின் பதிவேட்டைத் தொடங்குங்கள்; முகவரின் ஒவ்வொரு தோல்வியையும் அடுக்குடன் எழுதுங்கள்.
2. நாள் 2. மூடப்பட்ட tickets மற்றும் பதிவேட்டிலிருந்து 20 பணிகளைத் தேர்ந்தெடுங்கள். ஒவ்வொன்றுக்கும் commit-ஐப் பதிவு செய்து வெற்றி அளவுகோலைக் கட்டளைகளில் எழுதுங்கள்.
3. நாள் 3. ஓட்டுநரை எழுதுங்கள்: சுத்தமான வேலை நகல், பணியின் prompt உடன் முகவரை ஓட்டுதல், சரிபார்ப்புகளை ஓட்டுதல், முடிவை JSONL-இல் எழுதுதல்.
4. நாள் 4. ஒவ்வொரு பணியையும் 3–5 முறை ஓட்டுங்கள். pass@1, pass^3, தவறான «தயார்» விகிதம், சராசரிச் செலவு ஆகியவற்றைக் கணக்கிடுங்கள்.
5. நாள் 5. harness-இல் ஒரே ஒரு விஷயத்தை மாற்றி மீண்டும் ஓட்டுங்கள். ஒரே தொகுப்பு, ஒரே மறுஓட்ட எண்ணிக்கை இருக்கும்போது மட்டுமே ஒப்பிடுங்கள்.

ஒரு நேரத்தில் ஒரு மாறியை மாற்றுங்கள். ஒரே சோதனையில் மாதிரி, prompt, கருவிகள் ஆகிய மூன்றையும் மாற்றினால், எது வேலை செய்தது என்பது தெரியாது.

முகவர் மதிப்பீட்டில் பொதுவான தவறுகள்

• ஒவ்வொரு பணிக்கும் ஒரு ஓட்டம். முகவரின் நிர்ணயமின்மை அந்த முடிவை லாட்டரியாக்குகிறது. குறைந்தபட்சம் மூன்று மறுஓட்டங்கள்.
• ஒப்பீடுகளுக்கு இடையே தொகுப்பு மாறுகிறது. புதிய பணிகளைச் சேர்த்து அதே நேரத்தில் prompt-ஐ மாற்றினால், எண்களை ஒப்பிட முடியாது.
• முகவர் சரிபார்ப்புச் சோதனைகளைப் பார்க்கிறது. சோதனைகள் களஞ்சியத்தில் இருந்தால், முகவர் குறியீட்டை அவற்றுக்கேற்ப வளைக்கலாம், அல்லது சோதனைகளையே மாற்றலாம். மறைந்த சரிபார்ப்புகளை வேலை நகலுக்கு வெளியே வைத்து, முகவர் சோதனைக் கோப்புகளைத் தொடவில்லை என்பதைச் சரிபாருங்கள்.
• சரிபார்ப்புக்குப் பதில் முகவரின் அறிக்கை. பதிலில் «எல்லா சோதனைகளும் தேறின» என்பது முடிவல்ல. முடிவு என்பது ஓட்டுநர் இயக்கிய கட்டளையின் திரும்பும் குறியீடு.
• pass@k மட்டுமே. விளக்கக்காட்சிக்கு அழகான எண், சுயாதீன வேலைக்கு மோசமான முன்கணிப்பு.

சுருக்கமாக

AI முகவர் மதிப்பீடு என்பது நிலையான உண்மையான பணிகளின் தொகுப்பு, தானியங்கிச் சரிபார்ப்புகள், மற்றும் harness மாற்றத்துக்குப் பின் மீண்டும் கணக்கிடப்படும் அளவீடுகள். pass@k முகவர் என்ன திறன் கொண்டது என்பதைக் காட்டுகிறது, pass^k அதை மேற்பார்வையின்றி நம்பலாமா என்பதைக் காட்டுகிறது. தானியங்கிச் சரிபார்ப்புகள் உண்மையைத் தருகின்றன; அளவுகோலுடனும் தனிச் சூழலுடனும் உள்ள LLM நடுவர் குறியீடு இயலாத இடங்களில் அவற்றை நிரப்புகிறது. ஐந்து அடுக்குகளின் தோல்விப் பதிவேடு முதலில் எதைச் சரிசெய்ய வேண்டும் என்பதைக் காட்டுகிறது, பெரும்பாலும் அது மாதிரி அல்ல. நம்பகத்தன்மை அளவீடுகளும் கண்டறிதல் சுழற்சியும் harness பற்றிய பாடத்தில் நடைமுறையில் விளக்கப்பட்டுள்ளன.