Jinsi ya kujenga mfumo wa tathmini kwa AI agents

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 chochote katika orodha hiyo kinachohitaji mtoa huduma wa nje. Mzunguko mzima ni mistari michache ya Python na faili moja la SQLite.

Agent ilifanya kazi kwenye 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 hayo. Mzunguko wa tathmini hubadilisha "inahisi kuwa mbaya 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 una 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 uleule hufanya kazi bila kujali unaiendesha agent yako wapi, na mfumo wa agent unaojiendesha unaofaa kuutumia hutofautiana zaidi katika kiasi cha nyayo wanazokupa bila malipo.

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 la kijeuri. Sentensi hiyo hubadilisha tabia kwenye maingizo ambayo hakuna aliyeyajaribu upya, na mfuatano wa matukio (traces) huonyesha wazi: mfuatano wa wiki iliyopita kwa swali lilelile una wito wa zana wa create_refund, wa wiki hii hauna, na jibu ni msamaha wa heshima badala yake. Hakuna kilichotoa hitilafu, 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 safu husika.

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

Jenga seti ya msingi (golden set) kutoka kwa data uliyokusanya

Usibuni visa vya tathmini (eval cases). Vichukue kutoka kwenye traffic. Ikiwa tayari unatumia self-hosted Langfuse tracing kwa ajili ya agent yako, kila ombi huhifadhiwa pamoja na input yake, tool calls, na output yake, ambayo ndiyo malighafi kamili inayohitajika kwa ajili ya kesi.

Hamisha (export) dirisha la root observations kupitia public API. Inatumia basic authentication, ambapo public key yako ni username na secret key yako ni 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]'

Soma rekodi moja kabla ya kuandika parsing yoyote. Safu hurejeshwa chini ya data, lakini majina ya field yaliyoshikilia swali na jibu hutegemea jinsi agent yako inavyo-instrument spans zake, kwa hivyo ramani (map) kile unachokiona badala ya kile ulichotarajia. Kisha andika kesi hizo kwa mkono, JSON object moja kwa kila mstari, ndani ya 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 huifanya seti hii kuwa na thamani ya kuendeshwa:

• Kesi 40 hadi 80 zinatosha kuanzia. Chini ya 20, kesi moja isiyo na uthabiti (flaky case) hubadilisha kiwango cha ufaulu kwa pointi 5, na namba inayoruka bila sababu hupuuzwa.
• Kila mdudu wa uzalishaji (production bug) unaourekebisha huwa kesi siku unayourekebisha. Tabia hiyo ndiyo inayofanya seti kukua katika mwelekeo sahihi.
• Tabia moja kwa kila kesi. Kesi inayokagua kiasi cha refund na toni ya mazungumzo kwa pamoja haikupi taarifa yoyote inapofeli.
• id haibadiliki kamwe, kwa sababu id ndiyo njia ambayo run ya leo inalinganishwa na ya mwezi uliopita.
• Futa taarifa nyeti (redact) kabla ya kufanya commit. Faili hili huenda 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 agent wako: JSON haisomeki, tool haikuitwa, maneno yaliyopigwa marufuku yamejitokeza, au jibu halina chanzo.

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

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 tool katika orodha hiyo. Agent anayetatua kesi kwa wito 3 leo na 11 kesho amepata hitilafu hata kama jibu la mwisho ni sahihi, kwa sababu unalipia kila wito anaoufanya.

LLM kama mwamuzi, na njia nne zinazoweza kusababisha makosa

Kila kitu kinachopita majaribio ya assertions kinahitaji mkaguzi anayeweza kusoma. LLM judge ni mwito wa pili wa model: inapokea swali, jibu la agent, na kigezo kimoja, kisha inatoa uamuzi. Hii ndiyo njia pekee ya kivitendo ya kukagua kama "jibu linajibu kile mtumiaji alichouliza".

Kanuni nne hufanya mwamuzi aweze kutumika:

• Uamuzi wa ndiyo au hapana (binary), kamwe usitumie alama 1 hadi 10. Mizani hutoa 7 na 8 kwa karibu kila kitu, kwa hivyo namba haibadiliki na hujifunzi chochote.
• Kigezo kimoja kwa kila mwito. Uliza kuhusu kiasi cha marejesho (refund), au kuhusu toni, si vyote kwa wakati mmoja.
• Mpe mwamuzi jibu linalotarajiwa kila wakati kesi inapokuwa na jibu sahihi. Kukagua dhidi ya rejeleo ni kazi rahisi zaidi kuliko kukagua 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 ni njia za kufeli. Kila moja ina jaribio unaloweza kulifanya mchana huu, na kuyajaribu ni muhimu, kwa sababu mwamuzi asiyekaguliwa hutoa namba zinazoonekana kuwa sahihi lakini hazina maana yoyote.

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

Upendeleo wa binafsi (Self-preference). Mwamuzi mara nyingi hukagua matokeo kutoka kwa familia yake ya model kwa upole zaidi kuliko matokeo kutoka kwa familia nyingine. Lijaribu: kagua majibu yaleyale 30 kwa kutumia waamuzi kutoka familia mbili tofauti na ulinganishe maamuzi 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 rubric hiyo.

Kuteleza kwa rubric (Rubric drift). Vigezo visivyo wazi huzalisha waamuzi wanaokubali 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 unaokaguliwa.

Kinga moja inashughulikia yote manne. Hifadhi kesi 30 ulizozikagua kwa mkono, na ukague mwamuzi dhidi ya lebo zako kila wakati unapobadilisha model ya mwamuzi au prompt ya mwamuzi. Ikiwa inakinzana na wewe katika zaidi ya kesi moja kati ya kumi, rekebisha rubric kabla ya kuamini kiwango chochote cha "pass" inachozalisha. Mwamuzi ni code, kwa hivyo inapaswa kuwekwa kwenye version control na kukaguliwa kama code nyingine yoyote.

Panga bei nafuu, panda hadi frontier model

Kuhukumu kila kisa kwa kutumia model ghali zaidi katika kila commit ndiyo njia inayofanya gharama za tathmini (eval) kuzidi gharama za agent inayojaribiwa. Panga wahukumu (graders) 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, ambayo 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 za eval, na zinaongezeka. Eval runs si za mwingiliano (interactive), kwa hivyo Batch API hupunguza bei za kuingiza na kutoa kwa nusu badala ya utoaji wa asynchronous, ambayo ndiyo safu ya kwanza ya chati. Rubric 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 baada ya hit moja tu. 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, kwa mpangilio:

• Ukaguzi wa kideterministic (deterministic checks) kwa kila kisa. Hakuna gharama ya API kabisa.
• Model ndogo ya kuhukumu kwenye visa vilivyopita ukaguzi huo.
• Frontier judge pale tu ambapo model ndogo inasema imefeli, au inasema imepita kwa kujiamini kidogo.
• Mapitio ya kibinadamu kwenye 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 kudhani. Mara moja kwa mwezi, hukumu seti nzima na mhukumu mkali pia na ulinganishe safu hizo mbili. Ikiwa hazikubaliani kwenye visa zaidi ya vichache, rubric yako ni legevu sana kwa model ndogo, na rubric ndiyo unayopaswa kurekebisha. Kudhibiti kile ambacho agent yenyewe inatumia ni kazi tofauti, inayoshughulikiwa katika udhibiti wa gharama kwa AI agent kwenye VPS.

Fuatilia kiwango cha mafanikio kwa muda katika mfumo unaomiliki

Kiwango cha mafanikio ambacho huwezi kukiunganisha na commit ni hisia tu. Hifadhi safu moja kwa kila kisa kwa kila mzunguko wa majaribio, ukiweka 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 kwa kutumia sqlite3 -box evals/results.db < evals/passrate.sql. Mwaka mmoja wa mizunguko ya kila siku kwa visa 60 ni takriban safu 22,000, kwa hivyo hifadhi hii haitakuwa mradi mkubwa peke yake. Kuendesha SQLite katika production kwenye VPS kunashughulikia mipangilio inayozidi kuwa muhimu ikiwa faili hili litashirikiwa 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 agent, ambayo inamaanisha kuhariri prompt, mabadiliko ya model na mabadiliko ya zana 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

Mizunguko kamili ni ya polepole na inapaswa kufanyika kwa ratiba. systemd service na timer kwenye VPS ya kila usiku huendesha seti nzima dhidi ya prompt iliyotumika, jambo ambalo ndilo hugundua mabadiliko yanayotoka nje ya repository yako, kama vile zana inayohifadhiwa (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 vilivyopita vilivyochaguliwa bila mpangilio. Visa vilivyopita bila mpangilio ndivyo nusu muhimu, kwa sababu jaji ambaye ameanza kupitisha majibu mabaya kimya kimya huonekana kuwa 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 badala ya kumbukumbu.

Nini kinachofeli ndani ya mfumo wa eval wenyewe

anthropic.RateLimitError kwenye jaribio la kwanza kamili. Kesi sitini zinazotekelezwa kwa wakati mmoja zinazidi kikomo cha maombi au tokeni kwa tier yako. Punguza concurrency hadi wafanyakazi wanne, na uhamishe utekelezaji wa usiku kwenye Batch API.

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

Kesi zisizotabirika (Flaky cases). Input ileile hufaulu kwenye jaribio moja na kufeli kwenye lingine, kwa sababu wakala huchagua sampuli ya output yake. Tekeleza kesi hiyo isiyotabirika mara tatu na urekodi sehemu iliyofaulu badala ya kuifuta kesi hiyo. Kesi inayofaulu mara mbili kati ya tatu ni hitilafu halisi ya uthabiti, na mteja ataigundua.

Kuoza kwa golden set. Mtu anahariri jibu linalotarajiwa ili kuifanya suite ionekane imefaulu (green). Kagua diffs za evals/cases.jsonl kwa uangalifu kama unavyokagua diffs za wakala, kwa sababu faili hilo ndilo ufafanuzi wako ulioandikwa wa usahihi.

Suite ambayo haifeli kamwe. Kiwango cha kufaulu kilichokwama kwenye 100% kwa mwezi mmoja inamaanisha kuwa seti hiyo imeacha kufuatilia bidhaa. Vuta traces kumi za hivi karibuni, tafuta zile ambazo wakala alizishughulikia vibaya, na uongeze hizo. Kisha haribu kitu kwa makusudi na uthibitishe kuwa jaribio linakuwa jekundu, ambayo ndiyo ukaguzi mutation testing inavyotumika kwenye test suite na njia pekee ya kujua kama seti yako bado ina uwezo wa kutambua makosa.

FAQ

Je, seti ya tathmini ya wakala wa AI inahitaji visa vingapi?

Anza na visa 40 hadi 80 na uongeze seti hiyo kutokana na hitilafu halisi. Chini ya visa 20, matokeo moja yasiyo thabiti hubadilisha kiwango cha ufaulu kwa pointi 5, hivyo namba hiyo inapoteza maana yake. Zaidi ya mamia machache, kila jaribio hugharimu pesa na muda, huku visa vya ziada vikiongeza ufunikaji mdogo tu. Kipimo cha maana si idadi ya visa: ni sehemu ya aina za hitilafu unazozijua katika production ambazo zinajitokeza angalau mara moja kwenye seti hiyo.

Je, ninaweza kuamini jaji wa LLM kutathmini wakala wangu?

Fanya hivyo tu baada ya kuipima dhidi ya lebo zako mwenyewe. Hifadhi visa 30 ulivyotathmini kwa mkono, na uipime jaji dhidi ya visa hivyo kila unapobadilisha modeli ya jaji au prompt ya jaji. Majaji huonyesha upendeleo wa urefu, ambapo majibu marefu hufaulu mara nyingi zaidi, na upendeleo wa kibinafsi, ambapo matokeo kutoka kwa familia ya modeli yao wenyewe hutathminiwa kwa upole zaidi. Yote haya yanaweza kupimwa: ongeza maneno kwenye jibu lililofeli na ulijaribu tena, au tathmini majibu yaleyale kwa kutumia jaji kutoka familia nyingine. Ikiwa jaji atatofautiana na lebo zako katika zaidi ya kisa kimoja kati ya kumi, basi mwongozo wa tathmini ni wa jumla sana kiasi cha kutoweza kutumika.

Ni modeli ipi inapaswa kutathmini tathmini (evals)?

Tathmini kwa gharama nafuu na upandishe daraja inapohitajika. Uthibitishaji wa kideterministic haugharimu chochote, hivyo hufanyika kwanza kwa kila kisa. Modeli ndogo hushughulikia ufaulu ulio wazi. Ni hitilafu na maamuzi yenye kiwango cha chini cha uhakika pekee ndiyo hupelekwa kwa modeli ya kiwango cha juu (frontier model). Kwa bei za orodha za Agosti 2026, kutathmini visa 1,000 hugharimu 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 hufanyika kwa njia ya asynchronous, Batch API hupunguza gharama hizo kwa nusu.

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

Hapana, kwa sababu hujibu maswali tofauti. Seti ya tathmini hukuambia ikiwa mabadiliko unayotaka kuyaweka yanafanya seti fulani ya visa kuwa bora au mbaya zaidi. Ufuatiliaji (tracing na monitoring) hukuambia kile watumiaji halisi wanachokumbana nacho sasa hivi, ikiwemo pembejeo ambazo hazijajumuishwa kwenye kisa chochote. Husaidiana: traces hutoa visa vipya, na seti ya tathmini huamua ikiwa marekebisho yako yamefanya kazi kweli.