AI agent-களுக்கான self-hosted evals உருவாக்குவது எப்படி

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

AI agent-களுக்கான self-hosted evals என்பது உங்கள் சொந்த repository-ல் நீங்கள் வைத்திருக்கும் நான்கு விஷயங்களைக் குறிக்கும்: சேமிக்கப்பட்ட cases அடங்கிய ஒரு கோப்பு, agent-ஐ இயக்கும் ஒரு script, ஒவ்வொரு பதிலையும் மதிப்பீடு செய்யும் சோதனைகள், மற்றும் நீங்கள் query செய்யக்கூடிய முடிவுகளின் அட்டவணை. இதில் எந்தவொரு vendor-ன் உதவியும் தேவையில்லை. இந்த முழு சுழற்சியும் (loop) சில நூறு வரிகள் கொண்ட 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-ஐச் சேமித்தல். நீங்கள் எந்த framework-ல் agent-ஐ இயக்கினாலும் இந்த சுழற்சி ஒரே மாதிரியாகவே செயல்படும், மேலும் இயக்கத் தகுதியான self-hosted agent frameworks ஒவ்வொன்றும் தங்களுக்குக் கிடைக்கும் trace தரவுகளை உங்களுக்கு எந்த அளவிற்கு வழங்குகின்றன என்பதில் மட்டுமே வேறுபடுகின்றன.

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

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

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

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

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

ஏற்கனவே சேகரிக்கப்பட்ட traces-லிருந்து golden set-ஐ உருவாக்குதல்

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

Public API வழியாக root observations-ன் ஒரு குறிப்பிட்ட கால அளவை 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-ஐயும் எழுதும் முன் ஒரு பதிவை வாசியுங்கள். வரிசைகள் data-ன் கீழ் வரும், ஆனால் கேள்வி மற்றும் பதிலைக் கொண்ட field பெயர்கள் உங்கள் agent அதன் spans-ஐ எவ்வாறு instrument செய்கிறது என்பதைப் பொறுத்தது. எனவே, நீங்கள் எதிர்பார்த்ததை விட, உண்மையில் எதைக் காண்கிறீர்களோ அதை 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 சோதனைகளைச் செய்யவும், ஏனெனில் இவை கட்டணமில்லாதவை

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

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

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-ஐ நடுவராகப் பயன்படுத்துதல் மற்றும் அதில் ஏற்படும் நான்கு சிக்கல்கள்

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

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

• இருமத் தீர்ப்பு (Binary verdict) மட்டுமே வழங்க வேண்டும், 1 முதல் 10 வரையிலான மதிப்பெண் கூடாது. ஒரு அளவுகோல் பெரும்பாலும் 7 அல்லது 8 என்றே மதிப்பெண்களை வழங்கும், இதனால் எவ்வித முன்னேற்றத்தையும் அறிய முடியாது.
• ஒரு அழைப்பிற்கு ஒரு அளவுகோல் மட்டுமே இருக்க வேண்டும். பணத்தைத் திரும்பப் பெறுதல் (refund amount) அல்லது தொனி (tone) என ஏதேனும் ஒன்றைப் பற்றி மட்டும் கேட்கவும், இரண்டையும் ஒரே நேரத்தில் கேட்க வேண்டாம்.
• சரியான விடை இருக்கும் பட்சத்தில், அதை நடுவரிடம் வழங்கவும். ஒரு குறிப்பு விடையுடன் (reference) ஒப்பிட்டு மதிப்பிடுவது, பொதுப்படையாக மதிப்பிடுவதை விட எளிதானது.
• வெளியீட்டின் வடிவத்தை (output shape) கட்டாயப்படுத்தி, அதைத் துல்லியமாகப் பகுப்பாய்வு (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). ஒவ்வொன்றிற்கும் நீங்கள் இன்று மதியமே ஒரு சோதனையைச் செய்து பார்க்க முடியும். இவற்றைச் சோதிப்பது அவசியம், ஏனெனில் கவனிக்கப்படாத நடுவர் வழங்கும் எண்கள் துல்லியமாகத் தெரிந்தாலும், அவை எந்த அர்த்தமும் அற்றவையாக இருக்கலாம்.

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

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

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

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

இந்த நான்கு சிக்கல்களையும் ஒரு பாதுகாப்பு வழிமுறை சரிசெய்யும். நீங்கள் கையால் மதிப்பிட்ட 30 விடைகளை வைத்துக்கொள்ளுங்கள். நடுவர் model-ஐயோ அல்லது prompt-ஐயோ மாற்றும்போதெல்லாம், உங்கள் மதிப்பீடுகளுடன் நடுவரின் முடிவுகளை ஒப்பிட்டுப் பாருங்கள். பத்தில் ஒரு பங்கிற்கும் மேலாக நடுவர் உங்களுடன் முரண்பட்டால், அது வழங்கும் தேர்ச்சி விகிதத்தை நம்புவதற்கு முன் rubric-ஐச் சரிசெய்யவும். நடுவர் என்பது ஒரு code, எனவே அதை code போலவே version செய்து, review செய்யவும்.

குறைந்த விலை மாதிரிகளைப் பயன்படுத்துதல், தேவைப்பட்டால் உயர்தர மாதிரிக்கு மாறுதல்

ஒவ்வொரு 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 என எடுத்துக்கொள்கின்றன; இது ஒரு கேள்வி, ஒரு பதில் மற்றும் ஒரு மதிப்பீட்டு அளவுகோலுக்குத் தேவையான யதார்த்தமான அளவு. 1,000 வழக்குகளை மதிப்பீடு செய்ய Claude Haiku 4.5-ல் 1.80 அமெரிக்க டாலர்களும், Claude Opus 5-ல் 9.00 டாலர்களும் செலவாகும். இதைப் பெருக்கும்போதுதான் இந்த விலை வித்தியாசம் பெரியதாகத் தெரியும். வாரத்திற்கு 40 commits மற்றும் 60 வழக்குகளைக் கொண்ட ஒரு தொகுப்பை ஒவ்வொரு முறையும் மதிப்பீடு செய்தால், nightly job-ஐ இயக்குவதற்கு முன்பே வாரத்திற்கு 2,400 judge calls தேவைப்படும்.

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

படிக்கட்டு முறை (வரிசைப்படி):

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

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-க்கான செலவுக் கட்டுப்பாடு பகுதியில் விளக்கப்பட்டுள்ளது.

நீங்கள் நிர்வகிக்கும் அமைப்பில் காலப்போக்கில் வெற்றி விகிதத்தைக் கண்காணித்தல்

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

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 case-களுக்கு ஒரு நாளைக்கு ஒருமுறை என ஓராண்டுக்கு இயக்கும்போது சுமார் 22,000 rows உருவாகும். எனவே, இந்தத் தரவுத்தளம் ஒரு பெரிய திட்டமாக மாறாது. VPS-ல் SQLite-ஐ production-ல் இயக்குதல் என்ற பகுதி, இந்த file பல கணினிகளுக்கு இடையே பகிரப்படும்போது கவனிக்க வேண்டிய அமைப்புகளை விளக்குகிறது.

இந்த 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 மூலம், deploy செய்யப்பட்ட prompt-க்கு எதிராக முழு தொகுப்பையும் இயக்கலாம். இதுவே உங்கள் repository-க்கு வெளியே இருந்து வரும் மாற்றங்களைக் கண்டறிய உதவும்; உதாரணமாக, அதன் செயல்பாடு மாறிய ஒரு hosted tool-ஐ இது கண்டறியும்.

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

மனிதர்கள் வழங்கிய லேபிள்களைக் கொண்டுதான் 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 அதன் வெளியீட்டை sampling செய்வதால், ஒரே input ஒருமுறை pass ஆகி அடுத்த முறை fail ஆகலாம். அத்தகைய சோதனையை நீக்குவதற்குப் பதிலாக, மூன்று முறை இயக்கி அதன் விகிதத்தைப் பதிவு செய்யவும். மூன்றில் இரண்டு முறை pass ஆகும் ஒரு சோதனை உண்மையான robustness bug ஆகும், அதை வாடிக்கையாளர்கள் நிச்சயம் கண்டறிவார்கள்.

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

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

FAQ

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

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

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

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

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

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

Evals-ஆல் production monitoring-ஐ மாற்ற முடியுமா?

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