Jinsi ya kutengeneza tathmini za AI agents mwenyewe

Tathmini zinazojiendesha (self-hosted evals) kwa ajili ya AI agents ni nini

Tathmini zinazojiendesha kwa ajili ya AI agents ni vitu vinne unavyohifadhi kwenye hazina (repository) yako mwenyewe: faili la visa vilivyohifadhiwa, hati (script) inayoendesha agent kupitia visa hivyo, seti ya ukaguzi inayopima kila jibu, na jedwali la matokeo unaloweza kuuliza maswali. Hakuna kitu katika orodha hiyo kinachohitaji mtoa huduma. Mzunguko mzima ni mistari mia chache ya Python na faili moja la SQLite.

Agent ilifanya kazi katika onyesho kwa sababu ulichagua viingizo vitano mwenyewe. Ilivunjika katika wiki ya pili kwa sababu mstari wa prompt ulibadilika, au modeli ilibadilika, au maelezo ya zana yalibadilika, na hakuna kipimo kilichoshughulikia yoyote kati ya hayo. Mzunguko wa tathmini hubadilisha "inahisi vibaya zaidi sasa" kuwa "kiwango cha kufaulu kilishuka kutoka 58 kati ya 60 hadi 51 kati ya 60 kwenye commit 4f1c9ab".

Mzunguko huu una hatua nne, na mwongozo huu ni sehemu moja kwa kila hatua: kukusanya nyayo (traces) halisi, kupandisha zile za kuvutia kuwa visa, kupima kila kisa kwa kila mabadiliko, na kuhifadhi kiwango cha kufaulu kando ya commit iliyokizalisha. Mzunguko huo huo hufanya kazi bila kujali unaiendesha agent kwenye nini, na mfumo wa agent unaojiendesha unaofaa kuutumia hutofautiana zaidi katika kiasi cha nyayo wanazokupa bure.

Kwa nini wakala huvunjika katika wiki ya pili

Wakala ni prompt, modeli, seti ya ufafanuzi wa zana, na muktadha wowote unaorejeshwa wakati wa utekelezaji. Vyote vinne vinaweza kubadilika bila kubadili msimbo wa programu yako, kwa hivyo ukaguzi wa kawaida wa msimbo hautaona hitilafu yoyote.

Sababu ya kawaida ni mabadiliko ya prompt. Unaongeza sentensi moja ili kuzuia jibu lisilo na adabu. Sentensi hiyo inabadilisha tabia kwenye maingizo ambayo hakuna aliyeyajaribu tena, na kumbukumbu za ufuatiliaji (traces) zinaonyesha wazi: ufuatiliaji wa wiki iliyopita kwa swali lilelile una create_refund tool call, wa wiki hii hauna, na jibu ni msamaha wa heshima badala yake. Hakuna kilichotoa error, kwa hivyo hakuna tahadhari iliyotumwa.

Sababu ya pili ni modeli. Rekodi kamba kamili ya modeli uliyotuma katika kila utekelezaji, claude-haiku-4-5-20251001 badala ya kifupi unachokikumbuka kichwani, kwa sababu kiwango cha mafanikio kinachoshuka siku uliyobadilisha modeli kinaweza kutambulika tu wakati modeli hiyo iko kwenye mstari husika.

Ya tatu ni zana. Kubadilisha maelezo ya zana hubadilisha wakati modeli inapoamua kuitumia. Ikiwa zana zako zinakuja kupitia MCP servers running on a VPS, schema huishi katika mchakato mwingine, kwa hivyo inaweza kubadilika bila wewe kujua na bila tofauti yoyote kwenye hazina (repository) yako. Ya nne ni urejeshaji (retrieval): swali lilelile linagonga index iliyojengwa upya usiku kucha, na jibu linafuata hati mpya.

Jenga mkusanyiko wa msingi (golden set) kutoka kwa mienendo uliyokusanya

Usibuni visa vya tathmini. Vichukue kutoka kwa trafiki halisi. Ikiwa tayari unatumia self-hosted Langfuse tracing kwa ajili ya agent wako, kila ombi huhifadhiwa pamoja na ingizo lake, miito ya zana (tool calls), na pato lake, ambayo ndiyo malighafi kamili inayohitajika kwa ajili ya kisa cha tathmini.

Hamisha (export) dirisha la uchunguzi wa mizizi (root observations) kupitia API ya umma. Inatumia uthibitishaji wa kimsingi (basic authentication), ukitumia public key yako kama jina la mtumiaji na secret key yako kama nenosiri.

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

Soma rekodi moja kabla ya kuandika utaratibu wowote wa kuchakata data (parsing). Safu hurejeshwa chini ya data, lakini majina ya sehemu (field names) yanayoshikilia swali na jibu hutegemea jinsi agent wako anavyo-instrument spans zake, kwa hivyo ramani kile unachokiona badala ya kile ulichotarajia. Kisha andika visa hivyo kwa mkono, kitu kimoja cha JSON kwa kila mstari, katika evals/cases.jsonl:

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

Kanuni tano huufanya mkusanyiko huu kuwa na thamani ya kuutumia:

• Visa 40 hadi 80 vinatosha kuanza. Chini ya 20, kisa kimoja kisichotabirika hubadilisha kiwango cha ufaulu kwa pointi 5, na namba inayoruka bila sababu hupuuzwa.
• Kila hitilafu ya uzalishaji (production bug) unayorekebisha inakuwa kisa siku unayorekebisha. Tabia hiyo ndiyo inayoufanya mkusanyiko kukua katika mwelekeo sahihi.
• Tabia moja kwa kila kisa. Kisa kinachokagua kiasi cha marejesho (refund) na sauti ya mazungumzo (tone) kwa pamoja hakikupi taarifa yoyote kikifeli.
• id haibadiliki kamwe, kwa sababu id ndiyo njia ambayo majaribio ya leo hulinganishwa na ya mwezi uliopita.
• Futa taarifa nyeti (redact) kabla ya kufanya commit. Faili hili linaingia kwenye git, kwa hivyo ondoa majina ya wateja na namba zozote za oda ambazo si zako.

Fanya tathmini kwa kutumia ukaguzi wa kideterministi kwanza, kwa sababu haugharimu chochote

Kila kitu chenye jibu sahihi hupata uthibitisho wa moja kwa moja. Hakuna wito wa model, hakuna gharama, na hakuna utata. Ukaguzi wa kideterministi hubaini hitilafu za kimuundo, na hizo ndizo zinazovuruga mifumo inayozunguka wakala wako: JSON haisomeki, zana haikutumika, maneno yaliyopigwa marufuku yamejitokeza, au jibu halina chanzo.

Kazi moja tu ndiyo inayojua kuhusu wakala wako. Kila kitu kingine katika mfumo wa majaribio ni cha jumla.

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

Weka bajeti ya zana katika orodha hiyo. Wakala anayetatua kesi kwa wito 3 leo na 11 kesho amepata mdororo hata kama jibu la mwisho ni sahihi, kwa sababu unalipia kila wito anaoufanya.

LLM kama mwamuzi, na njia nne zinazoweza kusababisha makosa

Chochote kinachopita majaribio ya assertions kinahitaji mfumo wa tathmini unaoweza kusoma. Mwamuzi wa LLM ni wito wa pili wa modeli: hupokea swali, jibu la wakala, na kigezo kimoja, kisha hutoa uamuzi. Hii ndiyo njia pekee ya kivitendo ya kutathmini kama "jibu linajibu kile mtumiaji alichouliza".

Sheria nne hufanya mwamuzi kuwa na manufaa:

• Uamuzi wa binary, kamwe usitumie alama za 1 hadi 10. Mizani ya alama hutoa 7 na 8 kwa karibu kila kitu, kwa hivyo namba haibadiliki na hujifunzi chochote.
• Kigezo kimoja kwa kila wito. Uliza kuhusu kiasi cha marejesho (refund), au kuhusu toni, si vyote kwa wakati mmoja.
• Mpe mwamuzi jibu linalotarajiwa wakati wowote kesi inapokuwa na jibu sahihi. Kutathmini dhidi ya rejeleo ni kazi rahisi zaidi kuliko kutathmini kwa nadharia.
• Lazimisha umbo la matokeo na uyafanyie parsing kwa ukali.

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)

Sasa, njia za kufeli. Kila moja ina jaribio unaloweza kulifanya mchana huu, na kuyafanya majaribio hayo ni muhimu, kwa sababu mwamuzi asiyedhibitiwa hutoa namba zinazoonekana kuwa sahihi lakini hazina maana yoyote.

Upendeleo wa urefu (Length bias). Majibu marefu hupita mara nyingi zaidi. Lifanyie jaribio: chukua majibu kumi ambayo mwamuzi aliyakataa, ongeza aya mbili za maneno ya kujiamini ambayo hayana ukweli wowote mpya, kisha uyatathmini tena. Uamuzi wowote unaobadilika na kuwa "pass" ni upendeleo wa urefu, na mwongozo wa tathmini (rubric) ndio kitu cha kurekebishwa.

Upendeleo wa binafsi (Self-preference). Mwamuzi mara nyingi hutathmini matokeo kutoka kwa familia yake ya modeli kwa upole zaidi kuliko matokeo kutoka kwa familia nyingine. Lifanyie jaribio: tathmini majibu yaleyale 30 kwa kutumia waamuzi kutoka familia mbili tofauti na ulinganishe maamuzi hayo kesi kwa kesi. Pale wanapokinzana, soma kesi hiyo mwenyewe.

Upendeleo wa nafasi (Position bias). Ikiwa unatumia mwamuzi kulinganisha majibu mawili, A na B, badilisha mpangilio na uendeshe tena. Uamuzi unaobadilika baada ya kubadilisha mpangilio unamaanisha kuwa kulinganisha kwa jozi (pairwise comparison) bado si salama kwa mwongozo huo wa tathmini.

Kuteleza kwa mwongozo (Rubric drift). Vigezo visivyo wazi huzalisha waamuzi wanaokubaliana na kila kitu. "Je, jibu ni la kusaidia" hupitisha karibu kila kitu. "Je, jibu linataja kiasi cha marejesho kwa dola" hupitisha kile ulichokusudia pekee. Andika upya kila kigezo hadi kitaje ukweli unaochunguzwa.

Kinga moja inashughulikia yote manne. Hifadhi kesi 30 ulizozitathmini kwa mkono, na uupime mwamuzi dhidi ya lebo zako kila wakati unapobadilisha modeli ya mwamuzi au prompt ya mwamuzi. Ikiwa hakubaliani na wewe katika zaidi ya kesi moja kati ya kumi, rekebisha mwongozo wa tathmini kabla ya kuamini kiwango chochote cha "pass" kinachozalishwa. Mwamuzi ni msimbo (code), kwa hivyo hupata toleo (versioned) na kukaguliwa kama msimbo mwingine wowote.

Panga bei nafuu, panda hadi modeli ya kiwango cha juu

Kuhukumu kila kisa kwa kutumia modeli ghali zaidi katika kila commit ndiyo njia inayofanya bili ya tathmini (eval) kuwa kubwa kuliko wakala (agent) inayojaribiwa. Panga wahukumu kulingana na bei, na usitishe mchakato mara tu jibu linapokuwa wazi.

[
  {
    "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"
  }
]

Takwimu hizo zinachukulia wastani wa token 1,200 za kuingiza na token 120 za kutoa kwa kila wito wa kuhukumu, ambacho ni ukubwa halisi kwa swali moja, jibu moja na kigezo kimoja. Kuhukumu visa 1,000 kunagharimu 1.80 dola za Marekani kwenye Claude Haiku 4.5 na 9.00 kwenye Claude Opus 5. Tofauti hiyo inaonekana ndogo hadi utakapozidisha. Seti ya visa 60, inayohukumiwa katika kila commit, kwa commit 40 kwa wiki, ni wito 2,400 wa kuhukumu kwa wiki kabla ya mtu yeyote kuendesha kazi ya usiku (nightly job).

Punguzo mbili hutumika vizuri kwa kazi ya tathmini, na zinaweza kujumlishwa. Uendeshaji wa tathmini si wa mwingiliano (interactive), kwa hivyo Batch API hupunguza bei za kuingiza na kutoa kwa nusu kwa kubadilishana na utoaji wa asynchronous, ambayo ndiyo safu ya kwanza ya chati. Rubriki na maelekezo ni sawa kabisa kwa kila wito, kwa hivyo prompt caching inafaa: usomaji wa cache unagharimu sehemu ya kumi ya bei ya msingi ya kuingiza, na uandishi wa cache wa dakika tano unagharimu mara 1.25 ya bei ya msingi ya kuingiza, kwa hivyo cache hujilipia yenyewe baada ya hit moja. Hizi ni bei za orodha za Anthropic kufikia Agosti 2026, na Sonnet 5 iko kwenye bei ya utangulizi hadi 31 Agosti 2026, kwa hivyo upau wa tatu utapanda baada ya tarehe hiyo.

Ngazi ya utekelezaji, kwa mpangilio:

• Ukaguzi wa kideterministic (deterministic checks) kwa kila kisa. Hakuna gharama ya API kabisa.
• Mhukumu wa modeli ndogo kwa visa vilivyopita ukaguzi huo.
• Mhukumu wa kiwango cha juu (frontier judge) pale tu mhukumu mdogo anaposema kisa kimefeli, au anaposema kimepita kwa kujiamini kidogo.
• Mapitio ya kibinadamu kwa sampuli ndogo, mara moja kwa wiki.

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

Hii inabadilisha usahihi wa kuhukumu kwa gharama, kwa hivyo pima mabadiliko hayo badala ya kuyadhani. Mara moja kwa mwezi, hukumu seti nzima na mhukumu mkali pia na ulinganishe safu hizo mbili. Ikiwa hawakubaliani katika visa vingi, rubriki yako ni legevu sana kwa modeli ndogo, na rubriki ndiyo unayopaswa kurekebisha. Kudhibiti kile ambacho wakala yenyewe inatumia ni kazi tofauti, inayoshughulikiwa katika udhibiti wa gharama kwa wakala wa AI kwenye VPS.

Fuatilia kiwango cha mafanikio (pass rate) kwa muda katika mfumo unaomiliki

Kiwango cha mafanikio ambacho huwezi kukiunganisha na commit ni hisia tu. Hifadhi safu moja kwa kila kisa (case) kwa kila mzunguko wa majaribio (run), ukiwa na commit na model ndani ya safu hiyo.

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;

Pakia schema kwa kutumia sqlite3 evals/results.db < evals/schema.sql, kisha soma mwelekeo (trend) kwa kutumia sqlite3 -box evals/results.db < evals/passrate.sql. Mwaka mmoja wa majaribio ya kila siku kwa visa 60 ni takriban safu 22,000, kwa hivyo hifadhi hii haitakuwa mradi mkubwa peke yake. Kutumia SQLite katika production kwenye VPS kunashughulikia mipangilio inayopata umuhimu faili hili likishirikiwa kati ya mashine mbalimbali.

Mwendeshaji (runner) huchapisha taarifa hiyo hiyo kwa ajili ya binadamu:

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

Endesha suite kwenye mabadiliko yanayoweza kuvunja wakala (agent), ambayo inamaanisha kuhariri prompt, mabadiliko ya model na mabadiliko ya zana (tool) badala ya kila commit popote kwenye repository. Hook ya pre-push inashughulikia subset ya haraka:

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

Majaribio kamili ni ya polepole na yanapaswa kufanyika kwa ratiba. systemd service na timer kwenye VPS ya kila usiku huendesha seti nzima dhidi ya prompt iliyotumwa (deployed), jambo ambalo ndilo hugundua mabadiliko yanayotoka nje ya repository yako, kama vile zana inayohudumiwa (hosted tool) ambayo tabia yake imebadilika.

Uhakiki wa kibinadamu, kwa sampuli badala ya ukamilifu

Jaji hupimwa dhidi ya lebo za kibinadamu, kwa hivyo ni lazima mtu azitengeneze. Soma sampuli kila wiki: kila kisa ambacho jaji alishindwa, pamoja na visa kumi vilivyofaulu vilivyochaguliwa bila mpangilio. Visa vilivyofaulu bila mpangilio ndivyo nusu muhimu, kwa sababu jaji ambaye ameanza kimyakimya kupitisha majibu mabaya huonekana mkamilifu kwenye dashibodi yoyote iliyojengwa kutokana na maamuzi yake mwenyewe.

Visa kumi na tano kwa dakika tatu kila kimoja ni dakika 45 kwa wiki, na hurejesha marekebisho kwenye mwongozo ambapo wewe na jaji hamukubaliani, pamoja na visa vipya vya aina za kushindwa ambavyo hakuna aliyewahi kuvifikiria. Andika uamuzi wa kibinadamu kwenye jedwali lilelile huku graded_by ikiwa imewekwa kuwa human, ili makubaliano kati ya jaji na binadamu yawe swali la kutafuta (query) badala ya kumbukumbu.

Nini kinachoharibika kwenye mfumo wa tathmini (eval harness) wenyewe

anthropic.RateLimitError kwenye mzunguko wa kwanza kamili. Kesi sitini zinazotekelezwa kwa wakati mmoja zinazidi kikomo cha maombi au tokeni kwa kiwango chako cha huduma. Punguza idadi ya wafanyakazi (workers) hadi wanne, na uhamishe utekelezaji wa usiku kwenye Batch API.

json.JSONDecodeError: Expecting value: line 1 column 1 (char 0) kutoka kwa mwamuzi. Model ilijibu kwa lugha ya kawaida, au ilifunga JSON yake ndani ya code fence. Jaribu tena mara moja, kisha rekodi kesi hiyo kama hitilafu. Usiruhusu kamwe hitilafu ya uchanganuzi (parse failure) ihesabike kama kufaulu, kwa sababu suite inayobadilisha hitilafu kuwa mafanikio hupanda kuelekea 100% wakati wakala (agent) anazidi kuwa mbaya.

Kesi zisizotabirika (Flaky cases). Ingizo lilelile linafaulu kwenye mzunguko mmoja na kufeli kwenye mwingine, kwa sababu wakala huchagua sampuli ya matokeo yake. Tekeleza kesi hiyo isiyotabirika mara tatu na urekodi uwiano badala ya kuifuta kesi hiyo. Kesi inayofaulu mara mbili kati ya tatu ni hitilafu halisi ya uthabiti, na mteja ataigundua.

Kuoza kwa seti ya dhahabu (Golden set rot). Mtu anahariri jibu linalotarajiwa ili kufanya suite ionekane imefaulu. Kagua mabadiliko (diffs) kwenye evals/cases.jsonl kwa uangalifu kama unavyokagua mabadiliko kwenye wakala, kwa sababu faili hilo ndilo ufafanuzi wako ulioandikwa wa usahihi.

Suite ambayo haifeli kamwe. Kiwango cha kufaulu kilichokwama kwenye 100% kwa mwezi mmoja kinamaanisha kuwa seti hiyo imeacha kufuatilia bidhaa. Vuta mfuatano (traces) kumi wa hivi karibuni, tafuta wale ambao wakala aliwashughulikia vibaya, na uwaongeze.

FAQ

Ni kesi ngapi seti ya tathmini ya AI agent inahitaji?

Anza na kesi 40 hadi 80 kisha uiongeze kulingana na hitilafu halisi. Chini ya kesi 20, matokeo moja yasiyo thabiti yanaweza kubadilisha kiwango cha ufaulu kwa asilimia 5, hivyo idadi hiyo inapoteza maana yake. Zaidi ya kesi mia chache, kila jaribio linagharimu muda na pesa, huku kesi za ziada zikiongeza thamani ndogo. Kipimo cha msingi si idadi ya kesi: ni sehemu ya aina za hitilafu unazozijua katika uzalishaji (production) zinazojitokeza katika seti hiyo angalau mara moja.

Je, ninaweza kuamini LLM judge kutathmini agent wangu?

Fanya hivyo tu baada ya kuipima dhidi ya lebo zako mwenyewe. Hifadhi kesi 30 ulizozikagua kwa mikono, na uipime judge dhidi ya hizo kila unapobadilisha modeli ya judge au prompt ya judge. Majaji hawa huonyesha upendeleo wa urefu, ambapo majibu marefu hufaulu mara nyingi zaidi, na upendeleo wa ndani, ambapo matokeo kutoka kwa familia ya modeli hiyo hiyo hukaguliwa kwa upole zaidi. Yote haya yanaweza kupimwa: ongeza maneno kwenye jibu lililofeli na uikague tena, au kagua majibu yaleyale kwa kutumia judge kutoka familia nyingine. Ikiwa judge atatofautiana na lebo zako katika zaidi ya kesi moja kati ya kumi, basi mwongozo wa tathmini (rubric) hauko wazi vya kutosha kutumika.

Ni modeli ipi inapaswa kukagua tathmini?

Kagua kwa gharama nafuu na uongeze nguvu inapohitajika. Uthibitishaji wa kideterministic haugharimu chochote, hivyo hufanyika kwanza kwa kila kesi. Modeli ndogo hushughulikia majibu yaliyo wazi. Ni kesi zilizofeli na zile zenye kiwango cha chini cha uhakika pekee ndizo zinazopelekwa kwenye modeli ya hali ya juu (frontier model). Kwa bei za orodha za Agosti 2026, kukagua kesi 1,000 kunagharimu takriban 1.80 dola za Marekani kwa kutumia Claude Haiku 4.5 na takriban 9.00 kwa Claude Opus 5, na kwa sababu majaribio ya tathmini ni ya asynchronous, Batch API hupunguza gharama hizo kwa nusu.

Je, tathmini huchukua nafasi ya ufuatiliaji wa uzalishaji (production monitoring)?

Hapana, kwa sababu hujibu maswali tofauti. Seti ya tathmini inakuambia ikiwa mabadiliko unayotaka kuyaweka yanafanya seti fulani ya kesi kuwa bora au mbaya zaidi. Ufuatiliaji (tracing and monitoring) hukuambia kile watumiaji halisi wanachokumbana nacho sasa hivi, ikiwemo maingizo ambayo hayajajumuishwa kwenye kesi zozote. Hujengana: traces hutoa kesi mpya, na seti ya tathmini huamua ikiwa marekebisho yako yamefanya kazi kweli.