AI agents కోసం self-hosted evals ఎలా నిర్మించాలి

AI agents కోసం self-hosted evals అంటే ఏమిటి

AI agents కోసం self-hosted evals అంటే మీరు మీ స్వంత repository లో నిర్వహించే నాలుగు అంశాలు: సేవ్ చేసిన cases ఉన్న ఒక file, వాటిపై agent ను run చేసే ఒక script, ప్రతి answer కు grade ఇచ్చే checks సమూహం, మరియు మీరు query చేయగల results table. ఈ జాబితాలోని ఏ అంశానికీ vendor అవసరం లేదు. మొత్తం loop ను కొన్ని వందల పంక్తుల Python మరియు ఒక SQLite file తో నిర్మించవచ్చు.

మీరు ఐదు inputs ను స్వయంగా ఎంచుకున్నారు కాబట్టి demo లో agent సరిగ్గా పనిచేసింది. రెండో వారంలో అది విఫలమైంది. కారణం prompt లోని ఒక line మారడం, model మారడం లేదా tool description మారడం కావచ్చు. వీటిలో దేనినీ ఏ measurement కూడా పరిగణించలేదు. Eval loop వల్ల "ఇప్పుడు ఇది అధ్వాన్నంగా అనిపిస్తోంది" అనే అభిప్రాయం, "commit 4f1c9ab లో pass rate 60 లో 58 నుంచి 60 లో 51 కి పడిపోయింది" అనే కొలతగా మారుతుంది.

ఈ loop కు నాలుగు దశలు ఉన్నాయి. ఈ guide లో ప్రతి దశకు ఒక section ఉంది: వాస్తవ traces ను సేకరించడం, ఆసక్తికరమైన వాటిని cases గా మార్చడం, ప్రతి change పై ప్రతి case కు grade ఇవ్వడం, మరియు ఆ pass rate ను దాన్ని సృష్టించిన commit పక్కన store చేయడం. మీరు agent ను ఏ పనిపై run చేసినా ఇదే loop పనిచేస్తుంది. run చేయదగిన self-hosted agent frameworks ఒకదానికొకటి ప్రధానంగా ఎంత trace సమాచారాన్ని స్వయంచాలకంగా అందిస్తాయనే విషయంలో మాత్రమే భిన్నంగా ఉంటాయి.

రెండో వారంలో agent ఎందుకు విఫలమవుతుంది

Agent అంటే prompt, model, tool definitions సమాహారం, అలాగే runtime సమయంలో తిరిగి పొందే context. మీ application code మారకుండానే ఈ నాలుగు అంశాల్లో ఏదైనా మారవచ్చు. అందువల్ల సాధారణ code review లో అభ్యంతరం చెప్పాల్సిన మార్పు ఏదీ కనిపించకపోవచ్చు.

అత్యంత సాధారణ కారణం prompt edit. అసభ్యమైన సమాధానం రాకుండా ఆపడానికి మీరు ఒక వాక్యాన్ని జోడిస్తారు. మళ్లీ పరీక్షించని inputs పై ఆ వాక్యం ప్రవర్తనను మార్చుతుంది. Traces దీన్ని స్పష్టంగా చూపిస్తాయి: అదే ప్రశ్నకు గత వారం trace లో create_refund tool call ఉంది, ఈ వారం trace లో అది లేదు, దాని బదులుగా సమాధానం మర్యాదపూర్వకమైన క్షమాపణగా ఉంటుంది. ఎలాంటి error రాలేదు కాబట్టి alert కూడా trigger కాలేదు.

రెండో కారణం model. ప్రతి run తో మీరు పంపిన ఖచ్చితమైన model string ను నమోదు చేయండి. claude-haiku-4-5-20251001 మీకు గుర్తున్న shorthand పై ఆధారపడకండి. Model మార్చిన రోజే pass rate తగ్గితే, ఆ model వివరాలు row లో ఉన్నప్పుడే కారణాన్ని నిర్ధారించడం సాధ్యమవుతుంది.

మూడో కారణం tools. Tool description ను మళ్లీ రాయడం వల్ల model దాన్ని ఎప్పుడు call చేయాలో తీసుకునే నిర్ణయం మారుతుంది. మీ tools VPS పై నడుస్తున్న MCP servers ద్వారా వస్తే, schema మరో process లో ఉంటుంది. అందువల్ల మీ repository లో ఎలాంటి diff లేకుండానే అది మారవచ్చు. నాలుగో కారణం retrieval: అదే ప్రశ్న రాత్రి మళ్లీ build చేసిన index ను ఉపయోగిస్తుంది, కాబట్టి సమాధానం కొత్త document ను అనుసరిస్తుంది.

ఇప్పటికే సేకరిస్తున్న traces నుండి golden set ను రూపొందించండి

eval కేసులను కల్పించవద్దు. వాటిని traffic నుండి తీసుకోండి. మీరు ఇప్పటికే మీ agent కోసం self-hosted Langfuse tracing నడుపుతుంటే, ప్రతి request దాని input, tool calls మరియు output తో నిల్వ అవుతుంది. ఒక కేసుకు అవసరమైన raw material ఇదే.

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 రాయడానికి ముందు ఒక record చదవండి. rows data కింద వస్తాయి. అయితే question మరియు reply ను కలిగి ఉన్న field names, మీ agent తన spans ను ఎలా instrument చేస్తుందో దానిపై ఆధారపడి ఉంటాయి. కాబట్టి మీరు ఊహించిన పేర్లను కాకుండా, వాస్తవంగా కనిపించే field names ను map చేయండి. తరువాత evals/cases.jsonl లో ప్రతి పంక్తికి ఒక JSON object చొప్పున cases ను చేతితో రాయండి:

{"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."}

ఈ set ఉపయోగకరంగా ఉండేందుకు ఐదు నియమాలను పాటించండి:

• ప్రారంభించడానికి 40 నుండి 80 cases సరిపోతాయి. 20 కంటే తక్కువ ఉంటే, ఒక flaky case pass rate ను 5 points మేర మార్చగలదు. కారణం లేకుండా మారే సంఖ్యను ఎవరూ పట్టించుకోరు.
• మీరు సరిచేసే ప్రతి production bug, సరిచేసిన రోజునే ఒక case గా మారాలి. ఈ అలవాటు set ను సరైన దిశలో పెంచుతుంది.
• ప్రతి case లో ఒకే behaviour ఉండాలి. refund amount మరియు tone రెండింటినీ ఒకేసారి తనిఖీ చేసే case విఫలమైతే, కారణం ఏదో అర్థం కాదు.
• id ఎప్పుడూ మారకూడదు. ఈ id ఆధారంగానే ఈరోజు run ను గత నెల run తో పోల్చగలరు.
• commit చేయడానికి ముందు redact చేయండి. ఈ file git లోకి వెళుతుంది. కాబట్టి customer names మరియు మీకు చెందినవి కాని order numbers ను తొలగించండి.

ముందుగా ఉచితమైన deterministic checks తో గ్రేడింగ్ చేయండి

సరైన సమాధానం ఖచ్చితంగా తెలిసిన అంశాలకు సాధారణ assertion ఉపయోగించండి. model call అవసరం లేదు, ఖర్చు ఉండదు, సందిగ్ధత ఉండదు. Deterministic checks నిర్మాణపరమైన regressions ను గుర్తిస్తాయి. ఇవే మీ agent చుట్టూ ఉన్న systems ను విఫలమయ్యేలా చేస్తాయి: JSON parse కాదు, tool అసలు call కాలేదు, నిషేధిత పదబంధం మళ్లీ వచ్చింది, సమాధానంలో source ఏదీ ఉదహరించలేదు.

ఒక 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 ను కూడా ఉంచండి. ఒక agent ఈరోజు ఒక case ను 3 calls లో, రేపు 11 calls లో పరిష్కరిస్తే, తుది సమాధానం సరైనదైనా అది regression అవుతుంది. ఎందుకంటే agent చేసే ప్రతి call కు మీరు చెల్లించాలి.

LLM ను నిర్ణేతగా ఉపయోగించడం, అది తప్పు దారి పట్టే నాలుగు విధానాలు

Assertions ను దాటిన వాటికి చదివి అర్థం చేసుకునే grader అవసరం. LLM judge అనేది రెండో model call. దీనికి question, agent ఇచ్చిన answer, ఒక criterion పంపితే ఇది verdict ను తిరిగి ఇస్తుంది. “Reply user అడిగినదానికి సమాధానం ఇస్తుందా” అనే విషయాన్ని grade చేయడానికి ఇది మాత్రమే ఆచరణాత్మక మార్గం.

Judge ను ఉపయోగించదగినదిగా చేయడానికి నాలుగు నియమాలు ఉన్నాయి:

• Binary verdict మాత్రమే ఇవ్వాలి; 1 నుంచి 10 వరకు score ఎప్పుడూ ఇవ్వకూడదు. Scale ఉపయోగిస్తే దాదాపు ప్రతిదానికి 7 లేదా 8 వస్తుంది. అప్పుడు number మారదు, దాని నుంచి ఏమీ నేర్చుకోలేరు.
• ప్రతి call కు ఒక criterion మాత్రమే ఉండాలి. Refund amount గురించి లేదా tone గురించి అడగాలి; రెండింటినీ ఒకేసారి అడగకూడదు.
• Case కు expected answer ఉన్నప్పుడు దాన్ని judge కు ఇవ్వాలి. Reference తో grade చేయడం, ఎలాంటి ఆధారం లేకుండా grade చేయడం కంటే చాలా సులభం.
• 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 చూద్దాం. ప్రతి దానికి ఈరోజే అమలు చేయగల test ఉంది. వాటిని అమలు చేయడం ముఖ్యం. తనిఖీ చేయని judge ఖచ్చితంగా కనిపించే, కానీ అర్థం లేని numbers ను ఉత్పత్తి చేస్తుంది.

Length bias. పొడవైన answers ఎక్కువగా pass అవుతాయి. దీన్ని test చేయడానికి judge fail చేసిన పది answers తీసుకోండి. కొత్త fact ఏదీ జోడించకుండా, నమ్మకంగా అనిపించే filler తో ప్రతి answer కు రెండు paragraphs జోడించి మళ్లీ judge చేయండి. Pass గా మారిన verdict ఏదైనా ఉంటే అది length bias. సరిచేయాల్సింది rubric.

Self-preference. Judge తరచుగా తన model family నుంచి వచ్చిన output ను, వేరే model family output కంటే సానుకూలంగా grade చేస్తుంది. దీన్ని test చేయడానికి అదే 30 answers ను రెండు వేర్వేరు families కు చెందిన judges తో grade చేసి, case వారీగా verdicts ను పోల్చండి. అవి విభేదించిన చోట మీరు స్వయంగా case ను చదవాలి.

Position bias. రెండు answers, A మరియు B, పోల్చడానికి judge ను ఉపయోగిస్తే వాటి క్రమాన్ని మార్చి మళ్లీ run చేయండి. క్రమం మార్చినప్పుడు verdict మారితే, ఆ rubric కోసం pairwise comparison ఇంకా సురక్షితం కాదు.

Rubric drift. అస్పష్టమైన criteria agreeable judges ను ఉత్పత్తి చేస్తాయి. “Answer helpful గా ఉందా” అనేది దాదాపు దేనినైనా pass చేస్తుంది. “Answer refund amount ను dollars లో పేర్కొంటుందా” అనేది మీరు ఉద్దేశించినదాన్ని మాత్రమే pass చేస్తుంది. తనిఖీ చేస్తున్న fact ను స్పష్టంగా పేర్కొనే వరకు ప్రతి criterion ను తిరిగి రాయండి.

ఈ నాలుగింటినీ ఒకే guard కవర్ చేస్తుంది. మీరు చేతితో label చేసిన 30 cases ను ఉంచుకోండి. Judge model లేదా judge prompt మార్చిన ప్రతిసారీ మీ labels తో judge ను score చేయండి. పది cases లో ఒకదానికంటే ఎక్కువ case లో అది మీతో విభేదిస్తే, అది ఉత్పత్తి చేసే pass rate ను నమ్మే ముందు rubric ను సరిచేయండి. Judge కూడా code లాంటిదే. అందువల్ల code ను version చేసి review చేసినట్లే దీన్ని కూడా version చేసి review చేయాలి.

తక్కువ ఖర్చు గల మోడల్‌తో అంచనా వేసి, అవసరమైనప్పుడు frontier మోడల్‌కు పంపండి

ప్రతి commitపై ప్రతి సందర్భాన్ని అత్యంత ఖరీదైన మోడల్‌తో అంచనా వేయడం వల్ల, పరీక్షిస్తున్న agent కంటే eval ఖర్చు ఎక్కువవుతుంది. Graderలను ధర ఆధారంగా క్రమబద్ధీకరించండి. సమాధానం స్పష్టమైన వెంటనే ఆపండి.

[
  {
    "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 US dollars, Claude Opus 5పై 9.00 ఖర్చవుతుంది. ఒక్కోసారి ఈ తేడా చిన్నదిగా కనిపిస్తుంది. కానీ దాన్ని అనేకసార్లు లెక్కిస్తే ప్రభావం పెద్దదవుతుంది. 60 సందర్భాల సెట్‌ను ప్రతి commitపై, వారానికి 40 commitsతో అంచనా వేస్తే, nightly job అమలు చేయకముందే వారానికి 2,400 judge calls అవుతాయి.

Eval పనికి రెండు తగ్గింపులు నేరుగా వర్తిస్తాయి. ఇవి రెండూ కలిపి ఉపయోగించవచ్చు. Eval runs interactive కావు. అందువల్ల Batch API asynchronous deliveryకు బదులుగా input మరియు output ధరలను రెండింటినీ సగానికి తగ్గిస్తుంది. ఇది chartలోని మొదటి వరుస. ప్రతి callలో rubric మరియు instructions byte for byte ఒకేలా ఉంటాయి. కాబట్టి prompt caching సరిపోతుంది. Cache readకు base input ధరలో పదో వంతు మాత్రమే ఖర్చవుతుంది. ఐదు నిమిషాల cache writeకు base input ధరకు 1.25 రెట్లు ఖర్చవుతుంది. అందువల్ల ఒక్క hit తర్వాతే cache తన ఖర్చును భర్తీ చేస్తుంది. ఇవి August 2026 నాటికి Anthropic list prices. Sonnet 5కు introductory pricing 31 August 2026 వరకు ఉంటుంది. కాబట్టి ఆ తేదీ తర్వాత మూడవ bar పెరుగుతుంది.

క్రమంగా ఉపయోగించాల్సిన ladder:

• ప్రతి సందర్భంలో deterministic checks. API ఖర్చు ఉండదు.
• ఆ checks దాటిన సందర్భాలపై small model judge.
• small judge fail అని చెప్పినప్పుడు లేదా తక్కువ confidenceతో pass అని చెప్పినప్పుడు మాత్రమే frontier judge.
• వారానికి ఒకసారి, చిన్న sampleపై human review.

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"]

ఈ విధానం grading accuracyలో కొంత భాగాన్ని ఖర్చు తగ్గింపుకు మారుస్తుంది. కాబట్టి దాన్ని ఊహించకుండా, ఆ మార్పును కొలవండి. నెలకు ఒకసారి మొత్తం setను strict judgeతో కూడా grade చేసి, రెండు columnsను పోల్చండి. కొన్ని సందర్భాలకంటే ఎక్కువగా అవి విభేదిస్తే, small modelకు మీ rubric చాలా సడలింపుగా ఉంది. మీరు సరిచేయాల్సింది rubricనే. Agent స్వయంగా ఖర్చు చేసే మొత్తాన్ని నియంత్రించడం వేరే పని. దాని గురించి VPSలో AI agent కోసం ఖర్చు నియంత్రణ లో వివరించబడింది.

మీ స్వంత systemలో pass rate ను కాలక్రమేణా ట్రాక్ చేయండి

ఒక commitతో అనుసంధానించలేని pass rate కేవలం ఒక అంచనా మాత్రమే. ప్రతి 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 casesపై ఒక సంవత్సరం పాటు ప్రతిరోజూ run చేస్తే సుమారు 22,000 rows అవుతాయి. కాబట్టి store స్వయంగా ఒక ప్రత్యేక projectగా మారదు. ఈ fileను machines మధ్య share చేయాల్సి వస్తే ప్రాధాన్యం పొందే settings గురించి 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ను run చేయండి. అంటే repositoryలోని ప్రతి commitపై కాకుండా prompt edits, model changes మరియు tool changesపై run చేయాలి. వేగవంతమైన subsetకు pre-push hook సరిపోతుంది:

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

పూర్తి runs నెమ్మదిగా ఉంటాయి. వాటిని scheduleలో ఉంచాలి. రాత్రిపూట నడిచే VPSలో systemd service మరియు timer deployed promptకు వ్యతిరేకంగా మొత్తం setను run చేస్తుంది. మీ repository వెలుపల నుంచి వచ్చే మార్పులను ఇది గుర్తిస్తుంది. ఉదాహరణకు, hosted tool ప్రవర్తన మారినప్పుడు ఇది గుర్తిస్తుంది.

మానవ సమీక్ష: సంపూర్ణంగా కాకుండా నమూనా ఆధారంగా

Judge ను మానవ లేబుళ్లతో calibrate చేస్తారు కాబట్టి, ఆ లేబుళ్లను ఎవరో రూపొందించాలి. ప్రతి వారం ఒక నమూనాను చదవండి: judge విఫలమైన ప్రతి case తో పాటు, యాదృచ్ఛికంగా ఎంచుకున్న పది pass అయిన cases ను కూడా పరిశీలించండి. యాదృచ్ఛికంగా ఎంచుకున్న pass cases ముఖ్యమైనవి. ఎందుకంటే judge నిశ్శబ్దంగా తప్పు సమాధానాలను pass చేయడం ప్రారంభిస్తే, దాని స్వంత verdicts ఆధారంగా రూపొందించిన ఏ dashboard లోనైనా అది సరిగ్గా పనిచేస్తున్నట్లు కనిపిస్తుంది.

ప్రతి case కు మూడు నిమిషాల చొప్పున పదిహేను cases పరిశీలించడానికి వారానికి 45 నిమిషాలు పడుతుంది. దీనివల్ల మీరు మరియు judge ఏకీభవించని చోట rubric కు corrections లభిస్తాయి. ఎవరూ ఊహించని failure types కు కొత్త cases కూడా లభిస్తాయి. మానవ verdict ను అదే table లో graded_by ను human గా set చేసి రాయండి. అప్పుడు judge మరియు మానవ సమీక్ష మధ్య agreement జ్ఞాపకంపై ఆధారపడకుండా query ద్వారా తెలుసుకోవచ్చు.

eval harness లోనే ఏవి విఫలమవుతాయి

anthropic.RateLimitError మొదటి పూర్తి run లో. ఒకేసారి పంపిన అరవై cases మీ tier కు ఉన్న request లేదా token limit ను మించవచ్చు. concurrency ను నాలుగు workers కు పరిమితం చేసి, nightly run ను Batch API కు మార్చండి.

judge నుంచి json.JSONDecodeError: Expecting value: line 1 column 1 (char 0). model prose లో సమాధానం ఇచ్చి ఉండవచ్చు లేదా JSON ను code fence లో చుట్టి ఉండవచ్చు. ఒకసారి retry చేసి, తరువాత ఆ case ను error గా నమోదు చేయండి. parse failure ను ఎప్పుడూ pass గా లెక్కించకండి. Errors ను passes గా మార్చే suite, agent పనితీరు దిగజారుతున్నప్పటికీ, 100% వైపు పెరుగుతుంది.

Flaky cases. agent తన output ను sample చేయడం వల్ల అదే input ఒక run లో pass అయి, తరువాతి run లో fail కావచ్చు. Flaky case ను మూడు సార్లు run చేసి, దాన్ని తొలగించకుండా fraction ను నమోదు చేయండి. మూడు runs లో రెండు సార్లు pass అయ్యే case నిజమైన robustness bug. దాన్ని customer గుర్తిస్తారు.

Golden set rot. suite green గా కనిపించేందుకు ఎవరైనా expected answer ను మార్చవచ్చు. agent కు సంబంధించిన diffs ను ఎంత జాగ్రత్తగా review చేస్తారో, evals/cases.jsonl కు సంబంధించిన diffs ను కూడా అంతే జాగ్రత్తగా review చేయండి. ఎందుకంటే సరైనది అంటే ఏమిటో వ్రాతపూర్వకంగా నిర్వచించేది ఆ file.

ఎప్పుడూ fail కాని suite. ఒక నెల పాటు pass rate 100% వద్దే ఉంటే, set product ను track చేయడం ఆపివేసిందని అర్థం. ఇటీవలి పది traces తీసుకుని, agent సరిగా handle చేయని వాటిని గుర్తించి, వాటిని add చేయండి.

FAQ

AI agent eval సెట్‌కు ఎన్ని కేసులు అవసరం?

40 నుంచి 80 కేసులతో ప్రారంభించి, వాస్తవ వైఫల్యాల ఆధారంగా సెట్‌ను పెంచండి. సుమారు 20 కేసుల కంటే తక్కువగా ఉంటే, ఒక్క అస్థిర ఫలితం pass rate ను 5 పాయింట్లు మార్చగలదు. అప్పుడు ఆ సంఖ్య పెద్దగా ఉపయోగకరమైన సమాచారాన్ని ఇవ్వదు. కొన్ని వందల కేసులు దాటిన తర్వాత, ప్రతి run కు నిజమైన ఖర్చు మరియు సమయం అవసరమవుతాయి. అదనంగా చేర్చిన ప్రతి కేసు coverage ను చాలా తక్కువగా మాత్రమే పెంచుతుంది. ముఖ్యమైన కొలత కేసుల సంఖ్య కాదు. మీకు తెలిసిన production failure రకాలలో కనీసం ఒక్కసారైనా సెట్‌లో కనిపించే రకాల వాటా ముఖ్యమైనది.

నా agent ను grade చేయడానికి LLM judge ను నమ్మవచ్చా?

మీ స్వంత labels తో దాని పనితీరును కొలిచిన తర్వాత మాత్రమే నమ్మాలి. మీరు చేతితో grade చేసిన 30 కేసులను ఉంచుకోండి. judge model లేదా judge prompt మార్చిన ప్రతిసారీ, వాటితో judge ను score చేయండి. Judges లో length bias కనిపిస్తుంది. అంటే, అనవసరంగా పొడిగించిన సమాధానాలు ఎక్కువగా pass అవుతాయి. Self-preference కూడా కనిపిస్తుంది. అంటే, తమ స్వంత model family నుంచి వచ్చిన output ను మరింత అనుకూలంగా grade చేస్తారు. రెండింటినీ పరీక్షించవచ్చు: fail అయిన సమాధానానికి అదనపు వాక్యాలు జోడించి మళ్లీ judge చేయండి. లేదా అదే సమాధానాలను వేరే model family కు చెందిన judge తో grade చేయండి. పది కేసుల్లో ఒకటికంటే ఎక్కువ కేసులపై judge మీ labels తో ఏకీభవించకపోతే, rubric చాలా అస్పష్టంగా ఉంది. దాన్ని ఉపయోగించకూడదు.

Evals ను grade చేయడానికి ఏ model ఉపయోగించాలి?

తక్కువ ఖర్చు గల model తో grade చేసి, అవసరమైతే అధిక సామర్థ్యం గల model కు పంపండి. Deterministic assertions కు ఖర్చు ఉండదు. కాబట్టి ప్రతి కేసులో అవే ముందుగా అమలవుతాయి. స్పష్టమైన pass ఫలితాలను small model నిర్వహిస్తుంది. Fail అయినవి మరియు తక్కువ confidence ఉన్న verdicts మాత్రమే frontier model కు పంపాలి. August 2026 లోని list prices ప్రకారం, 1,000 కేసులను judge చేయడానికి Claude Haiku 4.5 తో సుమారు 1.80 US dollars ఖర్చవుతుంది. Claude Opus 5 తో సుమారు 9.00 ఖర్చవుతుంది. Eval runs asynchronous గా జరుగుతాయి కాబట్టి, Batch API ఉపయోగిస్తే ఈ రెండు ఖర్చుల్లో ఏదైనా సగానికి తగ్గుతుంది.

Evals production monitoring ను భర్తీ చేస్తాయా?

లేదు. ఎందుకంటే అవి వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి. మీరు త్వరలో ship చేయబోయే మార్పు ఒక స్థిరమైన కేసుల సెట్‌లో పనితీరును మెరుగుపరుస్తుందా లేదా తగ్గిస్తుందా అనేది eval suite చెబుతుంది. ప్రస్తుతం వాస్తవ వినియోగదారులు ఎదుర్కొంటున్న పరిస్థితులను tracing మరియు monitoring చూపిస్తాయి. ఏ కేసులోనూ లేని inputs కూడా ఇందులో ఉంటాయి. ఇవి పరస్పరం ఉపయోగపడతాయి. Traces కొత్త కేసులను అందిస్తాయి. మీ fix నిజంగా పనిచేసిందో లేదో eval suite నిర్ధారిస్తుంది.