AI agent-களுக்கு சொந்தமாக eval loop உருவாக்குவது எப்படி?

AI agent-களுக்கான self-hosted evals என்றால் என்ன

AI agent-களுக்கான self-hosted evals என்பது உங்கள் சொந்த repository-ல் நீங்கள் பராமரிக்கும் நான்கு விஷயங்களைக் குறிக்கும்: சேமிக்கப்பட்ட cases-களின் கோப்பு, agent-ஐ இயக்கும் script, ஒவ்வொரு பதிலையும் மதிப்பீடு செய்யும் சோதனைகள், மற்றும் நீங்கள் query செய்யக்கூடிய முடிவுகளின் அட்டவணை. இதில் எந்தவொரு vendor-ன் தேவையும் இல்லை. இந்த முழு சுழற்சியும் சில நூறு வரிகள் கொண்ட Python code மற்றும் ஒரே ஒரு SQLite கோப்பில் அடங்கிவிடும்.

நீங்கள் ஐந்து inputs-ஐ நீங்களே தேர்ந்தெடுத்ததால் demo-வில் agent சரியாக வேலை செய்தது. இரண்டாவது வாரத்தில் அது தோல்வியடைந்தது, ஏனெனில் ஒரு prompt வரி மாறியிருக்கலாம், அல்லது model மாறியிருக்கலாம், அல்லது tool-ன் விளக்கம் மாறியிருக்கலாம்; ஆனால் எதையும் அளவிட எந்த முறையும் இல்லை. ஒரு eval loop என்பது "இப்போது ஏதோ சரியாக இல்லை" என்ற உணர்வை, "commit 4f1c9ab-ல் pass rate 60-க்கு 58-லிருந்து 60-க்கு 51-ஆகக் குறைந்துள்ளது" என்ற துல்லியமான தரவாக மாற்றுகிறது.

இந்த சுழற்சி நான்கு படிகளைக் கொண்டது, இந்த வழிகாட்டியின் ஒவ்வொரு பகுதியும் ஒரு படியை விளக்குகிறது: உண்மையான traces-களைச் சேகரித்தல், முக்கியமானவற்றை cases-களாக மாற்றுதல், ஒவ்வொரு மாற்றத்தின் போதும் ஒவ்வொரு case-ஐயும் மதிப்பிடுதல், மற்றும் அந்த முடிவை உருவாக்கிய commit-க்கு அருகிலேயே pass rate-ஐச் சேமித்தல். நீங்கள் எந்த platform-ல் agent-ஐ இயக்கினாலும் இந்த சுழற்சி ஒரே மாதிரியாகவே செயல்படும், மேலும் இயக்கத் தகுதியான self-hosted agent frameworks ஒவ்வொன்றும் தங்களுக்குக் கிடைக்கும் trace தரவுகளை உங்களுக்கு எவ்வளவு எளிதாக வழங்குகின்றன என்பதில் மட்டுமே வேறுபடுகின்றன.

இரண்டாவது வாரத்தில் agent ஏன் செயலிழக்கிறது

Agent என்பது ஒரு prompt, ஒரு model, ஒரு தொகுப்பு tool definitions மற்றும் run time-ல் பெறப்படும் context ஆகியவற்றின் கலவையாகும். உங்கள் application code மாறாமலேயே இவை நான்கும் மாறக்கூடும் என்பதால், சாதாரண code review-ல் இதைக் கண்டறிய முடியாது.

இதற்கு மிக முக்கியமான காரணம் prompt-ல் செய்யப்படும் மாற்றமாகும். ஒரு கனிவற்ற பதிலை நிறுத்த நீங்கள் ஒரு வாக்கியத்தைச் சேர்க்கிறீர்கள் என்று வைத்துக்கொள்வோம். அந்த ஒரு வாக்கியம், நீங்கள் மறுபரிசோதனை செய்யாத உள்ளீடுகளிலும் (inputs) மாற்றத்தை ஏற்படுத்தும். இதை traces-ல் தெளிவாகக் காணலாம்: அதே கேள்விக்கான கடந்த வார trace-ல் ஒரு create_refund tool call இருக்கும், ஆனால் இந்த வார trace-ல் அது இருக்காது, அதற்குப் பதிலாக ஒரு கனிவான மன்னிப்பு மட்டுமே இருக்கும். எந்த பிழையும் (error) ஏற்படாததால், எந்த எச்சரிக்கையும் (alert) உருவாகாது.

இரண்டாவது காரணம் model ஆகும். ஒவ்வொரு run-க்கும் நீங்கள் பயன்படுத்தும் துல்லியமான model string-ஐப் பதிவு செய்யுங்கள். உங்கள் மனதில் வைத்திருக்கும் சுருக்கமான பெயரைப் பயன்படுத்தாமல், claude-haiku-4-5-20251001 என்ற முழுமையான பெயரைப் பயன்படுத்துங்கள். ஏனெனில், நீங்கள் model-ஐ மாற்றிய நாளில் வெற்றி விகிதம் (pass rate) குறைந்தால், அந்த model பெயர் தரவுத்தளத்தில் இருந்தால் மட்டுமே அதைக் கண்டறிய முடியும்.

மூன்றாவது காரணம் tools ஆகும். ஒரு tool-ன் விளக்கத்தை மாற்றினால், அதை எப்போது பயன்படுத்த வேண்டும் என்ற model-ன் முடிவும் மாறும். உங்கள் tools VPS-ல் இயங்கும் MCP servers வழியாக வந்தால், அதன் schema மற்றொரு process-ல் இருக்கும். எனவே, உங்கள் repository-ல் எந்த மாற்றமும் (diff) இல்லாமலேயே அது மாறக்கூடும். நான்காவது காரணம் retrieval ஆகும்: அதே கேள்வி, இரவு நேரத்தில் மீண்டும் உருவாக்கப்பட்ட (rebuilt) index-ஐ அடையும்போது, புதிய ஆவணத்தின் அடிப்படையில் பதில் அமையும்.

நீங்கள் ஏற்கனவே சேகரித்த தடயங்களிலிருந்து (traces) golden set-ஐ உருவாக்குதல்

மதிப்பீட்டு நிகழ்வுகளை (eval cases) நீங்களாக உருவாக்க வேண்டாம். அவற்றை network traffic-லிருந்து எடுத்துக்கொள்ளுங்கள். நீங்கள் ஏற்கனவே உங்கள் agent-க்காக self-hosted Langfuse tracing பயன்படுத்துகிறீர்கள் என்றால், ஒவ்வொரு கோரிக்கையும் (request) அதன் input, tool calls மற்றும் output ஆகியவற்றுடன் சேமிக்கப்படும். இதுவே ஒரு மதிப்பீட்டு நிகழ்வுக்குத் தேவையான மூலப்பொருள்.

Public API வழியாக root observations-ன் ஒரு குறிப்பிட்ட கால அளவை (window) export செய்யுங்கள். இது basic authentication-ஐப் பயன்படுத்துகிறது; இதில் உங்கள் public key பயனர்பெயராகவும் (username), secret key கடவுச்சொல்லாகவும் (password) இருக்கும்.

export LF_HOST="https://langfuse.example.com"
curl -sS -u "$LF_PUBLIC_KEY:$LF_SECRET_KEY" \
  "$LF_HOST/api/public/v2/observations?limit=50&isRootObservation=true&fromStartTime=2026-07-01T00:00:00Z" \
  | jq '.data[0]'

எந்தவொரு parsing-ஐயும் எழுதுவதற்கு முன் ஒரு பதிவை (record) வாசியுங்கள். வரிசைகள் data-ன் கீழ் வரும், ஆனால் கேள்வி மற்றும் பதிலைக் கொண்ட field பெயர்கள் உங்கள் agent அதன் spans-ஐ எவ்வாறு வடிவமைத்துள்ளது என்பதைப் பொறுத்தே அமையும். எனவே, நீங்கள் எதிர்பார்த்ததை விட, உண்மையில் எதைக் காண்கிறீர்களோ அதை map செய்யுங்கள். பின்னர், evals/cases.jsonl-ல் ஒவ்வொரு வரியிலும் ஒரு JSON object என நிகழ்வுகளை நீங்களே கைமுறையாக எழுதுங்கள்:

{"id": "refund-double-charge", "tags": ["smoke"], "input": "I was charged twice for order 41822.", "must_call": ["lookup_order", "create_refund"], "must_not_include": ["I cannot help"], "rubric": "The reply confirms exactly one refund for order 41822 and states the amount."}

இந்தத் தொகுப்பை பயனுள்ளதாக வைத்திருக்க ஐந்து விதிகள் உள்ளன:

• தொடங்குவதற்கு 40 முதல் 80 நிகழ்வுகள் போதுமானது. 20-க்கும் குறைவாக இருந்தால், ஒரு நிலையற்ற (flaky) நிகழ்வு கூட pass rate-ஐ 5 புள்ளிகள் வரை மாற்றும், இதனால் காரணமின்றி மாறும் எண்களை யாரும் கவனிக்க மாட்டார்கள்.
• நீங்கள் சரிசெய்யும் ஒவ்வொரு production bug-ம், அதைச் சரிசெய்யும் நாளிலேயே ஒரு மதிப்பீட்டு நிகழ்வாக மாற வேண்டும். இந்த வழக்கமே தொகுப்பை சரியான திசையில் வளர்க்கும்.
• ஒரு நிகழ்வுக்கு ஒரு செயல்பாடு (behaviour) மட்டுமே இருக்க வேண்டும். refund தொகையையும், தொனியையும் (tone) ஒரே நிகழ்வில் சரிபார்த்தால், அது தோல்வியடையும் போது எதனால் தோல்வியடைந்தது என்று தெரியாது.
• id ஒருபோதும் மாறக்கூடாது, ஏனெனில் இன்றைய run-ஐ கடந்த மாதத்துடன் ஒப்பிடுவதற்கு இந்த id-யே பயன்படுகிறது.
• commit செய்வதற்கு முன் தகவல்களை நீக்குங்கள் (redact). இந்த file git-க்குள் செல்வதால், வாடிக்கையாளர் பெயர்கள் மற்றும் உங்களுக்குச் சொந்தமில்லாத order எண்களை நீக்கிவிடுங்கள்.

முதலில் தீர்மானிக்கக்கூடிய (deterministic) சோதனைகளைச் செய்யவும், ஏனெனில் அவை இலவசமானவை

சரியான விடையைக் கொண்ட எதற்கும் ஒரு எளிய assertion-ஐப் பயன்படுத்தவும். இதற்கு model call தேவையில்லை, செலவும் இல்லை, குழப்பமும் இல்லை. தீர்மானிக்கக்கூடிய சோதனைகள் கட்டமைப்பு ரீதியான பின்னடைவுகளை (structural regressions) கண்டறியும். இவைதான் உங்கள் agent-ஐச் சுற்றியுள்ள அமைப்புகளைச் சிதைக்கக்கூடியவை: JSON-ஐ parse செய்ய முடியவில்லை, tool அழைக்கப்படவில்லை, தடைசெய்யப்பட்ட சொற்றொடர் வந்துவிட்டது, அல்லது விடை எந்த ஆதாரத்தையும் குறிப்பிடவில்லை.

ஒரு function மட்டுமே உங்கள் agent-ஐப் பற்றி அறிந்திருக்கும். harness-ல் உள்ள மற்ற அனைத்தும் பொதுவானவை.

import json, os, urllib.request

def run_agent(case):
    req = urllib.request.Request(
        os.environ["AGENT_URL"],
        data=json.dumps({"input": case["input"]}).encode(),
        headers={"content-type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=120) as resp:
        return json.load(resp)


def deterministic(case, result):
    text = result.get("output", "")
    called = [c["name"] for c in result.get("tool_calls", [])]
    failures = []
    for tool in case.get("must_call", []):
        if tool not in called:
            failures.append(f"tool not called: {tool}")
    for phrase in case.get("must_not_include", []):
        if phrase.lower() in text.lower():
            failures.append(f"forbidden phrase: {phrase}")
    if len(called) > case.get("max_tool_calls", 12):
        failures.append(f"too many tool calls: {len(called)}")
    return failures

tool budget-ஐ அந்தப் பட்டியலில் வைத்திருக்கவும். இன்று 3 அழைப்புகளில் ஒரு சிக்கலைத் தீர்க்கும் agent, நாளை 11 அழைப்புகளை எடுத்தால், இறுதி விடை சரியாக இருந்தாலும் அது பின்னடைவே ஆகும். ஏனெனில், அது செய்யும் ஒவ்வொரு அழைப்பிற்கும் நீங்கள் கட்டணம் செலுத்த வேண்டும்.

LLM as judge, மற்றும் அது தவறாகச் செயல்படும் நான்கு வழிகள்

Assertions-ஐத் தாண்டி எஞ்சியிருப்பவற்றைச் சரிபார்க்க, வாசிக்கக்கூடிய ஒரு grader தேவை. LLM judge என்பது இரண்டாவது model call ஆகும்: இது கேள்வி, agent-ன் பதில் மற்றும் ஒரு அளவுகோல் (criterion) ஆகியவற்றைப் பெற்று, ஒரு தீர்ப்பை வழங்குகிறது. "பயனர் கேட்ட கேள்விக்கு பதில் சரியாக உள்ளதா" என்பதை மதிப்பிட இதுவே நடைமுறைக்குச் சாத்தியமான ஒரே வழியாகும்.

ஒரு judge-ஐப் பயன்படுத்தக்கூடியதாக மாற்ற நான்கு விதிகள் உள்ளன:

• Binary தீர்ப்பு, 1 முதல் 10 வரையிலான மதிப்பெண் கூடாது. ஒரு scale-ல் பெரும்பாலானவற்றிற்கு 7 அல்லது 8 என்றே மதிப்பெண் கிடைக்கும், இதனால் எண்களில் மாற்றம் இருக்காது, எதையும் கற்றுக்கொள்ள முடியாது.
• ஒரு call-க்கு ஒரு அளவுகோல் மட்டுமே. பணத்தைத் திரும்பப் பெறுதல் (refund) அல்லது தொனி (tone) பற்றி கேட்கவும், இரண்டையும் ஒரே நேரத்தில் கேட்க வேண்டாம்.
• சரியான பதில் இருக்கும் பட்சத்தில், அதை judge-க்கு வழங்கவும். ஒரு reference-ஐ வைத்து மதிப்பிடுவது, பொதுப்படையாக மதிப்பிடுவதை விட எளிதானது.
• output-ன் வடிவத்தை கட்டாயப்படுத்தி, அதைத் துல்லியமாக parse செய்யவும்.

from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment


def judge_prompt(case, output):
    return (
        "You grade one answer against one criterion.\n"
        "Reply with JSON only, in this exact shape:\n"
        '{"verdict": "pass", "confidence": "high", "reason": "one short sentence"}\n'
        f"Criterion: {case['rubric']}\n"
        f"Question: {case['input']}\n"
        f"Answer: {output}\n"
        "Length is not a criterion. Judge only the criterion above."
    )


def judge(case, output, model):
    msg = client.messages.create(
        model=model,
        max_tokens=200,
        messages=[{"role": "user", "content": judge_prompt(case, output)}],
    )
    return json.loads(msg.content[0].text)

இப்போது தோல்வி முறைகள் (failure modes). ஒவ்வொன்றிற்கும் நீங்கள் இன்று மதியம் சோதிக்கக்கூடிய ஒரு test உள்ளது. இவற்றைச் சோதிப்பது அவசியம், ஏனெனில் கவனிக்கப்படாத judge, துல்லியமாகத் தோன்றும் ஆனால் அர்த்தமற்ற எண்களையே உருவாக்கும்.

Length bias. நீண்ட பதில்கள் அடிக்கடி தேர்ச்சி பெறுகின்றன. இதைச் சோதிக்க: judge நிராகரித்த பத்து பதில்களை எடுத்துக்கொள்ளுங்கள், ஒவ்வொன்றிலும் புதிய தகவல்கள் இல்லாத இரண்டு பத்திகளை (paragraphs) நம்பிக்கையான தொனியில் சேர்த்து, மீண்டும் மதிப்பிடவும். ஏதேனும் ஒரு தீர்ப்பு 'pass' என மாறினால், அது length bias ஆகும்; அப்போது rubric-ஐச் சரிசெய்ய வேண்டும்.

Self-preference. ஒரு judge பெரும்பாலும் தனது சொந்த model family-ன் வெளியீட்டிற்கு, மற்றொன்றை விட அதிக ஆதரவாக மதிப்பெண் வழங்குகிறது. இதைச் சோதிக்க: ஒரே 30 பதில்களை இரண்டு வெவ்வேறு family-களைச் சேர்ந்த judge-களைக் கொண்டு மதிப்பிட்டு, தீர்ப்புகளை ஒவ்வொன்றாக ஒப்பிடவும். அவை முரண்படும் இடங்களில், நீங்களே அந்தப் பதில்களை வாசித்துப் பார்க்கவும்.

Position bias. இரண்டு பதில்களை (A மற்றும் B) ஒப்பிட judge-ஐப் பயன்படுத்தினால், அவற்றின் வரிசையை மாற்றி மீண்டும் இயக்கவும். வரிசை மாற்றத்தால் தீர்ப்பு மாறினால், அந்த rubric-க்கு pairwise comparison இன்னும் பாதுகாப்பானது அல்ல என்று அர்த்தம்.

Rubric drift. தெளிவற்ற அளவுகோல்கள் இணக்கமான judge-களை உருவாக்குகின்றன. "பதில் பயனுள்ளதாக உள்ளதா" என்பது எதையும் தேர்ச்சி பெறச் செய்யும். "பதில் பணத்தைத் திரும்பப் பெறும் தொகையை டாலர்களில் குறிப்பிடுகிறதா" என்பது நீங்கள் எதிர்பார்த்ததை மட்டுமே தேர்ச்சி பெறச் செய்யும். ஒவ்வொரு அளவுகோலையும், அது சரிபார்க்கும் உண்மையை வெளிப்படையாகக் குறிப்பிடும் வரை மாற்றி எழுதவும்.

இந்த நான்கு சிக்கல்களையும் ஒரு பாதுகாப்பு முறை (guard) சரிசெய்யும். நீங்கள் கையால் label செய்த 30 cases-ஐ வைத்துக்கொள்ளுங்கள். ஒவ்வொரு முறை judge model அல்லது judge prompt-ஐ மாற்றும்போதும், உங்கள் labels-உடன் judge-ன் மதிப்பெண்களை ஒப்பிடவும். பத்தில் ஒரு case-க்கு மேல் அது உங்களுடன் முரண்பட்டால், அது வழங்கும் pass rate-ஐ நம்புவதற்கு முன் rubric-ஐச் சரிசெய்யவும். Judge என்பது code, எனவே அதை code-ஐப் போலவே version செய்து review செய்யவும்.

குறைந்த விலை மதிப்பீட்டில் தொடங்கி, உயர்நிலை மாதிரிக்கு (frontier model) உயர்த்துதல்

ஒவ்வொரு commit-இலும் மிக விலையுயர்ந்த மாதிரியைக் கொண்டு மதிப்பீடு செய்வது, சோதிக்கப்படும் agent-ஐ விட மதிப்பீட்டுச் செலவை (eval bill) அதிகரிக்கச் செய்யும். மதிப்பீட்டாளர்களை விலையின் அடிப்படையில் வரிசைப்படுத்துங்கள், விடை தெளிவாகத் தெரிந்தவுடன் நிறுத்திவிடுங்கள்.

[
  {
    "label": "Haiku 4.5, Batch API",
    "usd_per_1000_judge_calls": "0.90"
  },
  {
    "label": "Haiku 4.5",
    "usd_per_1000_judge_calls": "1.80"
  },
  {
    "label": "Sonnet 5",
    "usd_per_1000_judge_calls": "3.60"
  },
  {
    "label": "Opus 5",
    "usd_per_1000_judge_calls": "9.00"
  }
]

இந்தக் கணக்கீடுகள் ஒரு judge call-க்கு சுமார் 1,200 input tokens மற்றும் 120 output tokens எனக் கொள்கின்றன; இது ஒரு கேள்வி, ஒரு பதில் மற்றும் ஒரு அளவுகோலுக்கு (criterion) பொருத்தமான அளவாகும். 1,000 வழக்குகளை மதிப்பீடு செய்ய Claude Haiku 4.5-ல் 1.80 அமெரிக்க டாலர்களும், Claude Opus 5-ல் 9.00 டாலர்களும் செலவாகும். இதைப் பெருக்கும்போதுதான் இந்த வித்தியாசம் பெரியதாகத் தெரியும். வாரத்திற்கு 40 commits மற்றும் 60 வழக்குகள் கொண்ட தொகுப்பை ஒவ்வொரு commit-இலும் மதிப்பீடு செய்தால், nightly job-ஐ இயக்குவதற்கு முன்பே வாரத்திற்கு 2,400 judge calls தேவைப்படும்.

Eval பணிகளுக்கு இரண்டு தள்ளுபடிகள் பொருந்தும், அவற்றை ஒன்றாகப் பயன்படுத்தலாம். Eval ஓட்டங்கள் (runs) ஊடாடும் தன்மை கொண்டவை அல்ல, எனவே Batch API மூலம் asynchronous delivery-ஐப் பயன்படுத்தினால் input மற்றும் output விலைகள் பாதியாகக் குறையும்; இது அட்டவணையின் முதல் வரிசையில் உள்ளது. Rubric மற்றும் அறிவுறுத்தல்கள் ஒவ்வொரு அழைப்பிலும் மாறாமல் இருப்பதால், prompt caching பொருத்தமானது: ஒரு cache read-க்கு அடிப்படை input விலையில் பத்தில் ஒரு பங்கு மட்டுமே செலவாகும், மேலும் ஐந்து நிமிட cache write-க்கு அடிப்படை விலையை விட 1.25 மடங்கு செலவாகும், எனவே ஒரே ஒரு முறை பயன்படுத்தினாலே cache-க்கான செலவு ஈடுசெய்யப்படும். இவை ஆகஸ்ட் 2026 நிலவரப்படி Anthropic-ன் பட்டியல் விலைகள், மேலும் Sonnet 5 ஆகஸ்ட் 31, 2026 வரை அறிமுக விலையில் உள்ளது, எனவே அந்தத் தேதிக்குப் பிறகு மூன்றாவது பட்டை (bar) உயரும்.

வரிசைமுறை இதோ:

• ஒவ்வொரு வழக்கிலும் deterministic சோதனைகளைச் செய்தல். இதற்கு API செலவு ஏதுமில்லை.
• அந்தச் சோதனைகளைத் தாண்டிய வழக்குகளுக்குச் சிறிய மாதிரி மதிப்பீட்டாளரைப் (small model judge) பயன்படுத்துதல்.
• சிறிய மதிப்பீட்டாளர் தோல்வி என்று கூறினாலோ அல்லது குறைந்த நம்பிக்கையுடன் வெற்றி என்று கூறினாலோ மட்டும் உயர்நிலை மதிப்பீட்டாளரைப் (frontier judge) பயன்படுத்துதல்.
• வாரத்திற்கு ஒருமுறை சிறிய மாதிரியில் மனித மதிப்பாய்வு செய்தல்.

CHEAP = "claude-haiku-4-5-20251001"
STRICT = "claude-opus-5"


def grade(case, result):
    hard = deterministic(case, result)
    if hard:
        return False, "deterministic", "; ".join(hard)
    first = judge(case, result["output"], CHEAP)
    if first["verdict"] == "pass" and first["confidence"] == "high":
        return True, CHEAP, first["reason"]
    second = judge(case, result["output"], STRICT)
    return second["verdict"] == "pass", STRICT, second["reason"]

இது மதிப்பீட்டுத் துல்லியத்தைச் செலவிற்காகச் சற்று விட்டுக்கொடுக்கிறது, எனவே இதை ஊகிப்பதற்குப் பதிலாக அளவிடுங்கள். மாதத்திற்கு ஒருமுறை, முழுத் தொகுப்பையும் கடுமையான மதிப்பீட்டாளரைக் கொண்டு மதிப்பீடு செய்து, இரண்டு முடிவுகளையும் ஒப்பிட்டுப் பாருங்கள். சில வழக்குகளைத் தாண்டி முடிவுகள் முரண்பட்டால், உங்கள் rubric சிறிய மாதிரிக்கு மிகவும் தளர்வாக உள்ளது என்று அர்த்தம்; அப்போது rubric-ஐச் சரிசெய்ய வேண்டும். Agent-ன் செலவைக் கட்டுப்படுத்துவது தனிப்பட்ட வேலை, அது VPS-ல் AI agent-க்கான செலவுக் கட்டுப்பாடு பகுதியில் விளக்கப்பட்டுள்ளது.

நீங்கள் நிர்வகிக்கும் ஒரு அமைப்பில் காலப்போக்கில் pass rate-ஐக் கண்காணித்தல்

ஒரு commit-உடன் இணைக்க முடியாத pass rate என்பது வெறும் உணர்வு மட்டுமே. ஒவ்வொரு run-க்கும், ஒவ்வொரு case-க்கும் ஒரு row-ஐச் சேமிக்கவும்; அதில் commit மற்றும் model ஆகியவற்றை அந்த row-க்குள்ளேயே குறிப்பிடவும்.

CREATE TABLE IF NOT EXISTS results (
  run_id      TEXT NOT NULL,
  ran_at      TEXT NOT NULL,
  git_sha     TEXT NOT NULL,
  agent_model TEXT NOT NULL,
  case_id     TEXT NOT NULL,
  passed      INTEGER NOT NULL,
  graded_by   TEXT NOT NULL,
  reason      TEXT
);

SELECT run_id, git_sha, agent_model,
       count(*) AS cases,
       round(100.0 * sum(passed) / count(*), 1) AS pass_pct
FROM results
GROUP BY run_id
ORDER BY ran_at DESC
LIMIT 10;

sqlite3 evals/results.db < evals/schema.sql மூலம் schema-வை ஏற்றவும், பின்னர் sqlite3 -box evals/results.db < evals/passrate.sql மூலம் போக்கை (trend) வாசிக்கவும். ஒரு நாளைக்கு 60 cases வீதம் ஓராண்டுக்கு இயங்கும் சோதனைகள் சுமார் 22,000 rows-ஐ உருவாக்கும், எனவே இந்தத் தரவுத்தளம் ஒரு பெரிய திட்டமாக மாறாது. இந்த file பல கணினிகளுக்கு இடையே பகிரப்படும்போது கவனிக்க வேண்டிய அமைப்புகளை VPS-ல் SQLite-ஐ production-ல் இயக்குதல் விளக்குகிறது.

இந்த runner ஒரு நபருக்காக அதே தகவலை அச்சிடுகிறது:

run 2026-08-05T09:14:22Z  sha 4f1c9ab  model claude-sonnet-5  58/60 pass (96.7%)
FAIL refund-double-charge  deterministic: tool not called: create_refund
FAIL pto-policy-question   judge(opus): reply gives no dollar amount

ஒரு agent-ஐப் பாதிக்கக்கூடிய மாற்றங்களின் மீது suite-ஐ இயக்கவும். அதாவது, repository-ல் உள்ள ஒவ்வொரு commit-க்கும் பதிலாக, prompt மாற்றங்கள், model மாற்றங்கள் மற்றும் tool மாற்றங்கள் ஆகியவற்றின் மீது மட்டும் இயக்கவும். ஒரு pre-push hook வேகமான subset-ஐக் கையாளுகிறது:

cat > .git/hooks/pre-push <<'EOF'
#!/bin/sh
python3 evals/run.py --set smoke || exit 1
EOF
chmod +x .git/hooks/pre-push

முழுமையான run-கள் மெதுவானவை, எனவே அவற்றை ஒரு கால அட்டவணையில் (schedule) வைக்க வேண்டும். ஒரு nightly VPS-ல் systemd service மற்றும் timer முழு தொகுப்பையும் deployed prompt-க்கு எதிராக இயக்குகிறது. இதுவே உங்கள் repository-க்கு வெளியே இருந்து வரும் மாற்றங்களைக் கண்டறிய உதவுகிறது; உதாரணமாக, அதன் செயல்பாடு மாறிய ஒரு hosted tool-ஐ இது கண்டறியும்.

மனித மதிப்பாய்வு, முழுமையாக அல்லாமல் மாதிரி அடிப்படையில்

மனிதர்கள் வழங்கிய labels-ஐக் கொண்டுதான் judge அளவீடு செய்யப்படுகிறது, எனவே யாராவது ஒருவரை அவற்றை உருவாக்கச் செய்ய வேண்டும். ஒவ்வொரு வாரமும் ஒரு மாதிரியைச் சரிபார்க்கவும்: judge தோல்வியடைந்த அனைத்து நிகழ்வுகளையும், அதனுடன் தற்செயலாகத் தேர்ந்தெடுக்கப்பட்ட பத்து வெற்றிகரமான நிகழ்வுகளையும் பார்க்கவும். தற்செயலாகத் தேர்ந்தெடுக்கப்பட்ட வெற்றிகரமான நிகழ்வுகளே மிக முக்கியமானவை, ஏனெனில் தவறான பதில்களைச் சரியாகக் கடந்து செல்லும் ஒரு judge, அதன் சொந்தத் தீர்ப்புகளின் அடிப்படையில் உருவாக்கப்பட்ட எந்தவொரு dashboard-லும் சரியாகவே காட்சியளிக்கும்.

ஒவ்வொரு நிகழ்விற்கும் மூன்று நிமிடங்கள் வீதம் பதினைந்து நிகழ்வுகளைச் சரிபார்க்க வாரத்திற்கு 45 நிமிடங்கள் ஆகும். இது நீங்கள் மற்றும் judge ஆகியோரிடையே கருத்து வேறுபாடு உள்ள rubric-ல் திருத்தங்களைச் செய்யவும், யாரும் கற்பனை செய்யாத தோல்வி வகைகளுக்கான புதிய நிகழ்வுகளைக் கண்டறியவும் உதவும். மனிதரின் தீர்ப்பை அதே அட்டவணையில் graded_by-ஐ human என அமைத்து எழுதவும், அப்போதுதான் judge மற்றும் மனிதருக்கு இடையிலான உடன்பாடு என்பது நினைவகத்தில் இருப்பதற்குப் பதிலாக ஒரு query-ஆக மாறும்.

eval harness-ல் என்னென்ன பாதிப்புகள் ஏற்படும்

anthropic.RateLimitError முதல் முழுமையான இயக்கத்தின் போது. ஒரே நேரத்தில் அறுபது சோதனைகளை (cases) இயக்குவது உங்கள் tier-க்கான request அல்லது token வரம்பை மீறிவிடும். concurrency-ஐ நான்கு workers-ஆகக் குறைத்து, nightly run-ஐ Batch API-க்கு மாற்றவும்.

json.JSONDecodeError: Expecting value: line 1 column 1 (char 0) judge-மிடமிருந்து வரும் பிழை. model உரை வடிவில் பதிலளித்திருக்கலாம் அல்லது JSON-ஐ code fence-க்குள் அடைத்திருக்கலாம். ஒருமுறை மீண்டும் முயற்சி செய்யவும், அதன் பிறகு அந்தச் சோதனையை error எனப் பதிவு செய்யவும். parse failure-ஐ ஒருபோதும் pass எனக் கருத வேண்டாம்; ஏனெனில், பிழைகளை pass என மாற்றும் ஒரு suite, agent-ன் தரம் குறைந்தாலும் 100% வெற்றியை நோக்கிச் செல்லும்.

Flaky cases. agent தனது வெளியீட்டை sample செய்வதால், ஒரே input ஒருமுறை pass ஆகி அடுத்தமுறை fail ஆகலாம். flaky case-ஐ மூன்று முறை இயக்கி, அதை நீக்குவதற்குப் பதிலாக அதன் வெற்றி விகிதத்தைப் பதிவு செய்யவும். மூன்றில் இரண்டு முறை pass ஆகும் ஒரு சோதனை உண்மையான robustness bug ஆகும், இதை வாடிக்கையாளர்கள் நிச்சயம் கண்டறிவார்கள்.

Golden set rot. suite-ஐ green நிலைக்கு மாற்ற யாராவது எதிர்பார்க்கப்படும் விடையைத் திருத்தலாம். evals/cases.jsonl-க்கான diff-களை agent-க்கான diff-களைப் போலவே கவனமாகச் சரிபார்க்கவும், ஏனெனில் அந்த file தான் நீங்கள் வரையறுத்த சரியான விடை.

ஒருபோதும் fail ஆகாத suite. ஒரு மாதமாக 100% pass rate-ல் இருப்பது, அந்த suite தயாரிப்பின் மாற்றங்களைக் கவனிக்கவில்லை என்று பொருள். சமீபத்திய பத்து traces-ஐ எடுத்து, agent மோசமாகச் செயல்பட்டவற்றைக் கண்டறிந்து, அவற்றைச் சேர்க்கவும்.

FAQ

AI agent eval set-க்கு எத்தனை cases தேவை?

40 முதல் 80 வரையிலான எண்ணிக்கையில் தொடங்கி, உண்மையான தோல்விகளின் அடிப்படையில் அதை அதிகரிக்கவும். 20-க்கும் குறைவான cases இருந்தால், ஒருமுறை ஏற்படும் தற்காலிகத் தோல்வி (flaky result) pass rate-ஐ 5 புள்ளிகள் வரை மாற்றும், இதனால் அந்த அளவீடு நம்பகத்தன்மையை இழக்கும். சில நூறு cases-க்கு மேல் செல்லும்போது, ஒவ்வொரு முறையும் அதிக நேரமும் பணமும் செலவாகும், ஆனால் கூடுதல் பலன் மிகக் குறைவாகவே இருக்கும். இங்கே முக்கியமான அளவீடு எண்ணிக்கையல்ல: உங்களுக்குத் தெரிந்த production failure வகைகளில் எத்தனை சதவீதம் அந்த set-ல் இடம்பெற்றுள்ளன என்பதே முக்கியம்.

எனது agent-ஐ மதிப்பிட LLM judge-ஐ நம்பலாமா?

உங்கள் சொந்த labels-உடன் ஒப்பிட்டு அளவிட்ட பிறகு மட்டுமே நம்பலாம். நீங்களே கையால் மதிப்பிட்ட 30 cases-ஐ வைத்துக்கொள்ளுங்கள்; judge model அல்லது judge prompt-ஐ மாற்றும்போதெல்லாம், அந்த 30 cases-ஐ வைத்து judge-ன் துல்லியத்தைச் சோதிக்கவும். Judges-க்கு நீளமான பதில்களுக்கு அதிக மதிப்பெண் வழங்கும் (length bias) பழக்கமும், அதே model family-ல் உருவான பதில்களுக்குச் சாதகமாக மதிப்பிடும் (self-preference) போக்கும் உண்டு. இவற்றைச் சோதிக்கலாம்: தோல்வியடைந்த ஒரு பதிலை நீளமாக்கி மீண்டும் judge செய்யவும், அல்லது வேறொரு model family-ஐச் சேர்ந்த judge-ஐக் கொண்டு மதிப்பிடவும். பத்தில் ஒரு case-க்கு மேல் உங்கள் label-உடன் judge முரண்பட்டால், அந்த rubric மிகவும் தெளிவற்றது என்று பொருள்.

எந்த model-ஐக் கொண்டு evals-ஐ மதிப்பிட வேண்டும்?

குறைந்த செலவில் தொடங்கி, தேவைப்பட்டால் உயர் ரக model-க்குச் செல்லவும். Deterministic assertions-க்குச் செலவு இல்லை, எனவே அவற்றை முதலில் இயக்கவும். தெளிவான pass-களைச் சிறிய model-களே கையாண்டுவிடும். தோல்விகள் மற்றும் குறைந்த நம்பிக்கை கொண்ட முடிவுகளை மட்டும் frontier model-க்கு அனுப்பவும். ஆகஸ்ட் 2026-ன் விலைப்பட்டியல் படி, 1,000 cases-ஐ மதிப்பிட Claude Haiku 4.5 மூலம் சுமார் 1.80 அமெரிக்க டாலர்களும், Claude Opus 5 மூலம் சுமார் 9.00 டாலர்களும் செலவாகும். Eval runs asynchronous என்பதால், Batch API-ஐப் பயன்படுத்தினால் இந்தச் செலவு பாதியாகக் குறையும்.

Evals-ஆல் production monitoring-க்கு மாற்றாக இருக்க முடியுமா?

முடியாது, ஏனெனில் அவை வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன. ஒரு மாற்றம் செய்த பிறகு, அது ஏற்கனவே உள்ள cases-ன் தரத்தை உயர்த்துகிறதா அல்லது குறைக்கிறதா என்பதை eval suite சொல்லும். Tracing மற்றும் monitoring மூலம், எந்தெந்த inputs-ஐ உண்மையான பயனர்கள் எதிர்கொள்கிறார்கள் என்பதை அறியலாம்; இது eval suite-ல் இல்லாத புதிய சூழல்களைக் காட்டும். இவை ஒன்றுக்கொன்று தொடர்புடையவை: traces புதிய cases-ஐ வழங்குகின்றன, உங்கள் திருத்தம் சரியாக வேலை செய்கிறதா என்பதை eval suite உறுதிப்படுத்துகிறது.