AI agents साठी self-hosted evals कसे तयार करावे

AI agents साठी self-hosted evals म्हणजे काय

AI agents साठी self-hosted evals म्हणजे तुम्ही तुमच्या स्वतःच्या repository मध्ये ठेवलेल्या चार गोष्टी: जतन केलेल्या cases ची file, त्या cases वर agent चालवणारी script, प्रत्येक उत्तराचे मूल्यमापन करणाऱ्या checks चा संच आणि तुम्ही query करू शकणारी results table. या यादीतील कोणत्याही गोष्टीसाठी vendor आवश्यक नाही. संपूर्ण loop काहीशे lines च्या Python आणि एका SQLite file मध्ये तयार होतो.

Demo मध्ये agent योग्यरीत्या चालला, कारण पाच inputs तुम्ही स्वतः निवडले होते. दुसऱ्या आठवड्यात तो अयशस्वी झाला, कारण prompt मधील एखादी line, model किंवा tool description बदलले; आणि यापैकी कोणत्याही बदलासाठी measurement नव्हते. Eval loop मुळे "आता ते अधिक खराब वाटते" याचे रूपांतर "commit 4f1c9ab वर pass rate 60 पैकी 58 वरून 60 पैकी 51 झाला" यात करता येते.

या loop मध्ये चार steps आहेत आणि या guide मध्ये प्रत्येक step साठी एक section आहे: प्रत्यक्ष traces गोळा करा, महत्त्वाच्या traces चे cases मध्ये रूपांतर करा, प्रत्येक बदलावर प्रत्येक case चे grading करा आणि pass rate निर्माण करणाऱ्या commit च्या शेजारी तो साठवा. Agent कोणत्या कामावर चालवत असलात तरी हा loop कार्य करतो. चालवण्यास योग्य self-hosted agent frameworks यांच्यातील मुख्य फरक म्हणजे ते trace मधील किती माहिती तुम्हाला आपोआप उपलब्ध करून देतात.

एजंट दुसऱ्या आठवड्यात का बिघडतो

एजंट म्हणजे prompt, model, tool definitions चा संच आणि run time ला मिळवला जाणारा संदर्भ. तुमच्या application code मध्ये बदल न करता या चारही गोष्टी बदलू शकतात. त्यामुळे नेहमीच्या code review मध्ये आक्षेप घेण्यासारखे काहीही दिसत नाही.

सर्वात सामान्य कारण म्हणजे prompt मध्ये केलेला बदल. उद्धट उत्तर थांबवण्यासाठी तुम्ही एक वाक्य जोडता. त्या वाक्यामुळे पुन्हा तपासल्या न गेलेल्या input वरचे वर्तन बदलते. Traces मध्ये हे स्पष्ट दिसते: मागील आठवड्यात त्याच प्रश्नाच्या trace मध्ये create_refund tool call असतो, तर या आठवड्यात तो नसतो आणि त्याऐवजी उत्तरात नम्र माफी मागितली जाते. कोणतीही error निर्माण होत नाही, त्यामुळे कोणताही alert सुरू होत नाही.

दुसरे कारण म्हणजे model. प्रत्येक run सोबत पाठवलेला अचूक model string नोंदवा, claude-haiku-4-5-20251001; मनात ठेवलेल्या shorthand वर अवलंबून राहू नका. Model बदललेल्या दिवशी pass rate कमी झाला असेल, तर त्या row मध्ये model नोंदलेला असल्यासच त्याचे निदान करता येते.

तिसरे कारण म्हणजे tools. Tool description ची मांडणी बदलल्यास model ते call करण्याचा निर्णय कधी घेते हे बदलते. तुमचे tools VPS वर चालणाऱ्या MCP servers मार्फत मिळत असतील, तर schema दुसऱ्या process मध्ये असतो. त्यामुळे तुमच्या repository मध्ये कोणताही diff नसतानाही त्यात तुमच्या नकळत बदल होऊ शकतो. चौथे कारण म्हणजे retrieval: तोच प्रश्न रात्री पुन्हा build केलेल्या index कडे जातो आणि उत्तर नवीन document नुसार दिले जाते.

आधीपासून संकलित केलेल्या traces मधून golden set तयार करा

eval cases स्वतः तयार करू नका. ती traffic मधून घ्या. तुमच्या agent साठी self-hosted Langfuse tracing आधीपासून चालू असल्यास, प्रत्येक request त्याच्या input, tool calls आणि output सह साठवली जाते. Case साठी आवश्यक असलेला कच्चा data याच ठिकाणी मिळतो.

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 चे instrumentation कसे करतो यावर अवलंबून असतात. त्यामुळे अपेक्षित field names न वापरता प्रत्यक्ष दिसणाऱ्या field names चे mapping करा. त्यानंतर प्रत्येक ओळीत एक JSON object ठेवून evals/cases.jsonl मध्ये 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 पेक्षा कमी cases असल्यास एक flaky case pass rate मध्ये 5 points चा बदल घडवते आणि विनाकारण बदलणाऱ्या संख्येकडे दुर्लक्ष केले जाते.
• Production मधील प्रत्येक bug दुरुस्त केल्याच दिवशी एक case बनवा. या सवयीमुळे set योग्य दिशेने वाढतो.
• प्रत्येक case मध्ये एकच behaviour तपासा. Refund amount आणि tone एकत्र तपासणारा case fail झाल्यास नेमके काय बिघडले हे कळत नाही.
• id कधीही बदलू नका, कारण आजच्या run ची तुलना मागील महिन्याच्या run शी करण्यासाठी id वापरला जातो.
• Commit करण्यापूर्वी redact करा. ही file git मध्ये जाईल. त्यामुळे customer names आणि तुमच्या मालकीचे नसलेले order numbers काढून टाका.

प्रथम deterministic checks वापरून मूल्यमापन करा, कारण ते विनामूल्य असतात

ज्या बाबींना एकच योग्य उत्तर असते, त्यांसाठी साधे assertion वापरा. Model call, खर्च किंवा संदिग्धता यांची गरज नसते. Deterministic checks मुळे structural regressions पकडता येतात. याच regressions मुळे तुमच्या agent भोवतालची systems बिघडतात: JSON parse होत नाही, tool कधीच call केले जात नाही, निषिद्ध phrase पुन्हा येते किंवा उत्तरात कोणत्याही 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

त्या list मध्ये tool budget समाविष्ट ठेवा. एखादा agent आज एखादे प्रकरण 3 calls मध्ये सोडवतो आणि उद्या 11 calls घेतो, तर अंतिम उत्तर बरोबर असले तरी regression झालेला आहे. कारण तो केलेल्या प्रत्येक call साठी तुम्हाला पैसे मोजावे लागतात.

LLM as judge, आणि ते चुकण्याचे चार मार्ग

Assertions मधून वाचलेल्या उत्तरांचे मूल्यमापन वाचून करणाऱ्या grader कडून करावे लागते. LLM judge म्हणजे दुसरा model call असतो. त्याला question, agent चे answer आणि एक criterion दिले जाते. त्यानंतर तो verdict परत करतो. “उत्तराने वापरकर्त्याने विचारलेल्या प्रश्नाचे उत्तर दिले का?” याचे मूल्यमापन करण्यासाठी हीच एक व्यावहारिक पद्धत आहे.

Judge वापरण्यायोग्य होण्यासाठी चार नियम पाळा:

• Binary verdict द्या; 1 ते 10 score कधीही देऊ नका. Scale वापरल्यास जवळजवळ प्रत्येक गोष्टीला 7 किंवा 8 मिळते. त्यामुळे number बदलत नाही आणि त्यातून काहीही शिकता येत नाही.
• प्रत्येक call मध्ये एकच criterion ठेवा. Refund amount बद्दल किंवा tone बद्दल विचारा; दोन्ही एकाच वेळी विचारू नका.
• एखाद्या case साठी expected answer उपलब्ध असल्यास तो judge ला द्या. Reference शी तुलना करून grading करणे, कोणत्याही आधाराशिवाय grading करण्यापेक्षा खूप सोपे असते.
• Output shape निश्चित करा आणि त्याचे strict parsing करा.

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 चालवू शकता. हे tests चालवणे महत्त्वाचे आहे, कारण तपासणी न केलेला judge अचूक दिसणारे पण अर्थहीन numbers तयार करतो.

Length bias. मोठी answers अधिक वेळा pass होतात. Test करा: judge ने fail केलेली दहा answers घ्या. प्रत्येकात नवीन तथ्य न जोडणारे, आत्मविश्वासपूर्ण filler असलेले दोन paragraphs जोडा आणि त्यांचे पुन्हा grading करा. कोणताही verdict pass मध्ये बदलल्यास तो length bias आहे. अशा वेळी rubric दुरुस्त करा.

Self-preference. Judge अनेकदा स्वतःच्या model family मधील output ला इतर model family मधील output पेक्षा अधिक अनुकूलपणे grade करतो. Test करा: त्याच 30 answers चे grading दोन वेगळ्या families मधील judges कडून करा आणि case नुसार verdicts ची तुलना करा. ज्या cases मध्ये मतभेद आहेत ते स्वतः वाचा.

Position bias. दोन answers, A आणि B, यांची तुलना करण्यासाठी judge वापरत असल्यास त्यांचा क्रम बदला आणि test पुन्हा चालवा. क्रम बदलल्यावर verdict बदलल्यास त्या rubric साठी pairwise comparison अजून सुरक्षित नाही.

Rubric drift. अस्पष्ट criteria मुळे judge सहज सहमत होतो. “उत्तर उपयुक्त आहे का” या criterion मध्ये जवळजवळ कोणतेही उत्तर pass होऊ शकते. “उत्तरात refund amount dollars मध्ये दिला आहे का” या criterion मध्ये फक्त अपेक्षित उत्तर pass होते. तपासला जाणारा fact स्पष्टपणे नमूद होईपर्यंत प्रत्येक criterion पुन्हा लिहा.

हे चारही प्रकार टाळण्यासाठी एकच guard पुरेसा आहे. तुम्ही स्वतः हाताने label केलेली 30 cases जतन करा. Judge model किंवा judge prompt बदलताना प्रत्येक वेळी judge चे score तुमच्या labels शी तुलना करा. दहा cases पैकी एकापेक्षा जास्त cases मध्ये तो तुमच्याशी असहमत असल्यास, त्याने तयार केलेल्या कोणत्याही pass rate वर विश्वास ठेवण्यापूर्वी rubric दुरुस्त करा. Judge हा code आहे. त्यामुळे code प्रमाणेच त्याचे versioning आणि review करा.

स्वस्त grader वापरा आणि गरज पडल्यास frontier model कडे जा

प्रत्येक commit वर प्रत्येक प्रकरणाचे मूल्यमापन सर्वात महागड्या model ने करणे म्हणजे eval चा खर्च तपासल्या जाणाऱ्या agent पेक्षा जास्त वाढवणे. 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 गृहीत धरते. एका प्रश्नासाठी, एका उत्तरासाठी आणि एका criterion साठी हा वास्तववादी आकार आहे. 1,000 cases चे मूल्यमापन Claude Haiku 4.5 वर 1.80 US dollars आणि Claude Opus 5 वर 9.00 खर्च करते. हा फरक लहान वाटतो, पण calls ची संख्या वाढवल्यावर तो लक्षणीय होतो. 60 cases चा संच प्रत्येक commit वर आणि आठवड्याला 40 commits वर तपासल्यास, nightly job चालवण्यापूर्वीच दर आठवड्याला 2,400 judge calls होतात.

Eval कामासाठी दोन सवलती थेट लागू होतात आणि त्या एकत्र वापरता येतात. Eval runs परस्परसंवादी नसतात. त्यामुळे asynchronous delivery स्वीकारल्यास Batch API input आणि output दोन्हींच्या किमती निम्म्या करते. Chart मधील पहिली row याच दराची आहे. Rubric आणि instructions प्रत्येक call मध्ये byte-by-byte समान असतात, त्यामुळे prompt caching योग्य ठरते. Cache read साठी base input price च्या एक-दशांश किंमत लागते. पाच मिनिटांच्या cache write साठी base input price च्या 1.25 पट किंमत लागते. त्यामुळे एकाच hit नंतर cache चा खर्च भरून निघतो. हे Anthropic चे August 2026 मधील list prices आहेत. Sonnet 5 साठी introductory pricing 31 August 2026 पर्यंत आहे. त्यामुळे त्या तारखेनंतर तिसरा bar उंचावतो.

ही पायरीवार रचना वापरा:

• प्रत्येक case वर deterministic checks. API cost अजिबात नाही.
• त्या checks मधून पुढे गेलेल्या cases साठी small model judge.
• small judge ने fail सांगितलेल्या किंवा कमी confidence सह pass सांगितलेल्या cases साठीच 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 काही प्रमाणात कमी होऊन खर्च कमी होतो. त्यामुळे गृहीत धरण्याऐवजी हा trade मोजा. महिन्यातून एकदा संपूर्ण set चे strict judge नेही grading करा आणि दोन्ही columns ची तुलना करा. काही मोजक्या cases पेक्षा जास्त cases मध्ये मतभेद असल्यास small model साठी तुमचा rubric पुरेसा स्पष्ट नाही. त्यामुळे सुधारणा rubric मध्ये करा. Agent स्वतः किती खर्च करतो हे नियंत्रित करणे वेगळे काम आहे. त्यासाठी VPS वरील AI agent साठी खर्च नियंत्रण पहा.

तुमच्या मालकीच्या प्रणालीतील pass rate कालांतराने नोंदवा

ज्या pass rate ला 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 cases वर दररोज एक वर्ष runs घेतल्यास सुमारे 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 चालवा. यामध्ये repository मधील प्रत्येक commit ऐवजी prompt edits, model changes आणि tool changes यांचा समावेश होतो. जलद 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

Full runs अधिक संथ असतात. ते schedule वर चालवणे योग्य आहे. nightly VPS वरील systemd service आणि timer deployed prompt विरुद्ध संपूर्ण set चालवते. त्यामुळे तुमच्या repository च्या बाहेरून आलेले बदलही आढळतात. उदाहरणार्थ, hosted tool चे behaviour बदलले असल्यास तो बदल पकडला जातो.

मानवीय पुनरावलोकन, संपूर्ण तपासणीऐवजी नमुना-आधारित

परीक्षकाचे मानांकन मानवी लेबल्सशी जुळवून घेतले जाते, त्यामुळे ही लेबल्स कोणीतरी तयार करणे आवश्यक आहे. दर आठवड्याला एक नमुना वाचा: परीक्षक ज्या प्रत्येक प्रकरणात चुकला ती सर्व प्रकरणे, तसेच यादृच्छिकपणे निवडलेली दहा उत्तीर्ण प्रकरणे. यादृच्छिकपणे निवडलेली उत्तीर्ण प्रकरणे अधिक महत्त्वाची आहेत. कारण स्वतःच्या निर्णयांवर आधारित डॅशबोर्डवर, चुकीची उत्तरे उत्तीर्ण म्हणून नोंदवू लागलेला परीक्षकही निर्दोष दिसू शकतो.

दर आठवड्याला पंधरा प्रकरणे, प्रत्येकी तीन मिनिटे, म्हणजे एकूण 45 मिनिटे लागतात. त्यातून तुमचे आणि परीक्षकाचे मतभेद असलेल्या rubric मधील दुरुस्त्या मिळतात. तसेच, यापूर्वी कोणाच्याही लक्षात न आलेल्या अपयशाच्या प्रकारांसाठी नवीन प्रकरणेही मिळतात. मानवी निर्णय त्याच तक्त्यात लिहा आणि graded_by ची किंमत human ठेवा. त्यामुळे परीक्षक आणि मानव यांच्यातील सहमती स्मरणावर अवलंबून न राहता query द्वारे तपासता येते.

eval harness मध्येच काय बिघडते

पहिल्या पूर्ण रनमध्ये anthropic.RateLimitError. एकाच वेळी 60 प्रकरणे पाठवल्यास तुमच्या 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 मध्ये गुंडाळले. एकदा पुन्हा प्रयत्न करा आणि त्यानंतर ते प्रकरण error म्हणून नोंदवा. parse failure ला कधीही pass मानू नका. कारण errors चे passes मध्ये रूपांतर करणारा suite agent ची कामगिरी खालावत असतानाही 100% च्या दिशेने जातो.

Flaky cases. agent त्याचे output sample करत असल्यामुळे तोच input एका run मध्ये pass आणि पुढील run मध्ये fail होतो. flaky case तीन वेळा चालवा आणि ते प्रकरण हटवण्याऐवजी त्याचा fraction नोंदवा. तीनपैकी दोन runs मध्ये pass होणारे प्रकरण हा वास्तविक robustness bug आहे आणि customer तो शोधून काढेल.

Golden set rot. suite green करण्यासाठी कोणी expected answer संपादित करतो. evals/cases.jsonl मधील diffs चे पुनरावलोकन agent मधील diffs इतक्याच काळजीपूर्वक करा, कारण ती file म्हणजे योग्य output ची तुमची लिखित व्याख्या आहे.

कधीही fail न होणारा suite. pass rate एका महिन्यासाठी 100% वर स्थिर राहिल्यास set ने product चे tracking करणे थांबवले आहे. अलीकडील दहा traces घ्या, agent ने चुकीच्या पद्धतीने हाताळलेले traces शोधा आणि ते जोडा.

FAQ

AI agent eval set मध्ये किती cases आवश्यक आहेत?

40 ते 80 cases पासून सुरुवात करा आणि प्रत्यक्ष failures वरून set वाढवा. सुमारे 20 cases पेक्षा कमी असतील, तर एका अस्थिर result मुळे pass rate मध्ये 5 points चा फरक पडतो. त्यामुळे ही संख्या उपयुक्त माहिती देत नाही. काहीशे cases पेक्षा जास्त झाल्यावर प्रत्येक run साठी प्रत्यक्ष खर्च आणि वेळ लागतो, पण प्रत्येक अतिरिक्त case मुळे coverage मध्ये फारशी वाढ होत नाही. महत्त्वाचे मोजमाप case ची संख्या नाही. तुमच्या production मधील ज्ञात failure types पैकी किती प्रकार set मध्ये किमान एकदा दिसतात, हा त्याचा वाटा महत्त्वाचा आहे.

माझ्या agent चे grading करण्यासाठी LLM judge वर विश्वास ठेवता येईल का?

तुमच्या स्वतःच्या labels विरुद्ध त्याचे मोजमाप केल्यानंतरच. तुम्ही हाताने grade केलेले 30 cases ठेवा. Judge model किंवा judge prompt बदलल्यावर प्रत्येक वेळी त्या cases विरुद्ध judge चा score तपासा. Judges मध्ये length bias दिसतो. Padding केलेली answers अधिक वेळा pass होतात. Self-preference देखील दिसतो. म्हणजे त्याच model family मधील output अधिक अनुकूलपणे grade केला जातो. दोन्ही गोष्टी तपासता येतात. Failed answer मध्ये padding जोडा आणि त्याचे पुन्हा grading करा. किंवा त्याच answers चे grading दुसऱ्या model family मधील judge कडून करून घ्या. Judge तुमच्या labels शी दहा cases पैकी एकापेक्षा जास्त cases मध्ये असहमत असेल, तर rubric वापरण्यासाठी खूप अस्पष्ट आहे.

Evals चे grading करण्यासाठी कोणते model वापरावे?

स्वस्त model वापरून grading करा आणि आवश्यक असल्यास पुढील स्तरावरील model कडे पाठवा. Deterministic assertions साठी कोणताही खर्च येत नाही. त्यामुळे त्या प्रत्येक case वर सर्वप्रथम चालवा. स्पष्टपणे pass होणारे cases small model हाताळू शकते. फक्त fails आणि low-confidence verdicts frontier model कडे पाठवा. August 2026 मधील list prices नुसार, 1,000 cases चे grading Claude Haiku 4.5 वापरल्यास सुमारे 1.80 US dollars आणि Claude Opus 5 वापरल्यास सुमारे 9.00 खर्च होते. Eval runs asynchronous असल्यामुळे Batch API वापरल्यास दोन्हीपैकी कोणताही खर्च निम्मा होतो.

Evals production monitoring ची जागा घेतात का?

नाही. कारण ते वेगवेगळ्या प्रश्नांची उत्तरे देतात. Eval suite मुळे तुम्ही deploy करणार असलेल्या बदलामुळे fixed set मधील cases चांगले किंवा खराब झाले आहेत का, हे समजते. Tracing आणि monitoring मुळे सध्या प्रत्यक्ष users कोणते inputs वापरत आहेत, हे समजते. यात कोणत्याही case मध्ये समाविष्ट नसलेले inputs देखील येतात. हे दोन्ही एकमेकांना input देतात. Traces मधून नवीन cases मिळतात आणि तुमचा fix प्रत्यक्षात काम केला का, हे eval suite ठरवते.