Kupima wakala wa AI: jinsi ya kujenga evals na kupima uaminifu, si hisia tu

Kwa nini kupima wakala wa AI ikiwa tayari inaonekana kwamba anafanya kazi

Kuona ndicho kisichosaidia vya kutosha. Wakala ameshindwa mara moja tu kwa wiki baada ya kubadilisha prompt: je, ni marekebisho au ni wiki yenye kazi rahisi? Mhandisi mmoja ana uhakika kwamba kiolezo kipya kimebadilisha kila kitu, wa pili aliangalia kumbukumbu hiyo hiyo na hakuona tofauti. Wote wako sahihi kwa kiasi ambacho hawajahesabu chochote.

Kupima wakala wa AI (evals) kunabadilisha hisia kuwa nambari. Unachukua seti maalum ya kazi, unaendesha wakala, unakagua matokeo kiotomatiki, kisha unalinganisha vipimo kabla na baada ya mabadiliko. Hapo mjadala wa "je, imekuwa bora" unatatuliwa kwa jedwali, si kwa mamlaka ya mtu.

Bila evals, mabadiliko yoyote ya harness — prompt, AGENTS.md, seti ya zana, modeli — ni kubashiri gizani. Kwa evals, ni jaribio lenye matokeo yanayopimika.

Kwa nini "hisia" hudanganya

Hisia kuhusu kazi ya wakala ina makosa matatu ya kimfumo, na yote yanasukuma kwenye uhakika wa uongo.

• Upendeleo wa aliyebaki hai. Majaribio yaliyofanikiwa yanakumbukwa na kuonyeshwa kwa wenzako; yaliyoshindwa yanaendeshwa tena na kusahaulika. Uaminifu uliohesabiwa kwa majaribio yaliyofanikiwa hausemi chochote kuhusu mahali ambapo wakala kweli huvunjika.
• Sampuli ndogo. Kazi tatu zilizofanikiwa mfululizo ni tukio la kawaida hata kwa wakala anayefanikiwa nusu ya wakati. Uwezekano wake ni 0.5³ = 12.5%, yaani takriban mfululizo mmoja kati ya minane.
• Sauti ya uhakika. Wakala anaandika "imekamilika, majaribio yote yanapita" kwa uhakika uleule iwe ni kweli au si kweli. Uhakika wa modeli haujapimwa; sauti ya jibu si ishara ya usahihi.

Kwa hiyo kanuni ni hii: kila kitu ambacho hakijaandikwa na kuhesabiwa upya kinachukuliwa kuwa hakijapimwa.

pass@k na pass^k: vipimo viwili vinavyochanganywa

Wakala si wa kubashiri: kazi ileile inaweza kupita mara moja na kushindwa mara nyingine. Kwa hiyo kazi moja inaendeshwa mara kadhaa, na mojawapo ya vipimo viwili huhesabiwa.

pass@k: angalau jaribio moja kati ya k limefanikiwa

Kipimo hiki kinatoka kwenye tathmini ya uzalishaji wa msimbo. Kinajibu swali "je, mfumo kwa kanuni unaweza kutatua kazi, ukipewa majaribio kadhaa". Ni kipimo cha haki kwa hali ambayo binadamu huchagua bora kati ya chaguo kadhaa, au ambapo kuna ukaguzi wa kuaminika wa kiotomatiki unaoondoa zilizoshindwa.

pass^k: majaribio yote k yamefanikiwa

Kipimo hiki kinajibu swali tofauti: "wakala anatatua kazi kwa uthabiti kiasi gani". Kinaelezea kazi bila usimamizi — pale wakala anapoendeshwa mara nyingi na kila kushindwa kunagharimu fedha au muda.

Tofauti kati yao ni kubwa. Acha wakala atatue kazi kwa uwezekano wa 70% kwa jaribio moja, na majaribio yakiwa huru:

Kwa pass@5 wakala anaonekana karibu mkamilifu, kwa pass^5 hategemewi. Nambari zote mbili ni sahihi; zinaelezea mambo tofauti. Ukitaka kumwachia wakala kazi bila usimamizi, angalia pass^k: iko karibu zaidi na kile utakachokiona katika kazi halisi.

Jinsi ya kuhesabu kwa vitendo

Endesha kila kazi mara n (kwa mfano 5) na uandike idadi ya mafanikio c. Kwa kazi, pass^k ni takriban sehemu ya uendeshaji ambapo majaribio k yote mfululizo yamefanikiwa; kwa urahisi, kadiria uwezekano wa mafanikio p = c / n kisha uinue kwa nguvu. Kwa seti ya kazi, wastani kwa kazi.

import json
from statistics import mean

# results.jsonl: {"task": "add-pagination", "runs": [true, true, false, true, true]}
rows = [json.loads(line) for line in open("results.jsonl")]

def pass_at_k(runs, k):
    p = sum(runs) / len(runs)
    return 1 - (1 - p) ** k

def pass_pow_k(runs, k):
    p = sum(runs) / len(runs)
    return p ** k

for k in (1, 3, 5):
    print(k,
          round(mean(pass_at_k(r["runs"], k) for r in rows), 3),
          round(mean(pass_pow_k(r["runs"], k) for r in rows), 3))

Kukadiria kwa p kwa nguvu ya k ni mbaya kidogo wakati n ni ndogo, lakini kwa kulinganisha matoleo ya harness wenyewe kwa wenyewe kwa kawaida inatosha. Muhimu zaidi ni kwamba n na seti ya kazi visibadilike kati ya ulinganisho.

Jinsi ya kukusanya seti ya kazi za evals

Seti ya kazi ndiyo mali kuu. Kipimo kizuri kwenye kazi mbovu kinapima kitu kisichofaa.

Chukua kazi kutoka uhalisia wako

Benchmark za umma kama SWE-bench zinafaa kulinganisha modeli, lakini kazi zake zimechaguliwa: maelezo wazi, majaribio tayari. Kwenye hazina yako mahitaji ni ya kutatanisha na majaribio mengine hayapo, kwa hiyo nambari ya benchmark karibu kila mara ni ya juu kuliko atakayoonyesha wakala wako. Chanzo bora cha kazi ni tiketi zilizofungwa na kushindwa halisi kwa wakala kutoka kwenye jarida.

Muundo wa seti

• Kazi 20–50 kuanzia. Chini ya hapo kelele inameza tofauti kati ya matoleo. Zaidi ya hapo uendeshaji unakuwa ghali na hautaendeshwa tena.
• Aina tofauti: kipengele kipya, kurekebisha hitilafu, urekebishaji wa msimbo, kazi kwenye moduli ya mtu mwingine, kazi yenye mtego (ambapo jibu sahihi ni "hivi haviruhusiwi" au "inahitaji ufafanuzi").
• Kila kazi iliyoshindwa kazini inakuwa jaribio. Seti inakua pamoja na uelewa wa mahali wakala ni dhaifu, na urudiaji wa hitilafu hauzuiliki bila kugunduliwa.
• Hali ya kuanzia isiyobadilika: commit maalum, utegemezi uliofungwa, mazingira yale yale. Vinginevyo unapima mabadiliko ya mazingira, si wakala.

Muundo wa kazi

Kila kazi ni maelezo, hali ya kuanzia, na kigezo cha mafanikio kinachoweza kukaguliwa bila binadamu.

id: add-pagination
repo_ref: 3f2c1ab
prompt: |
  Ongeza paginesheni kwenye GET /payments: vigezo limit (chaguo-msingi 20, kiwango cha juu 100)
  na cursor. Jibu lina next_cursor.
check:
  - pytest tests/test_payments_pagination.py
  - mypy app/
limits:
  max_changed_files: 6

Angalia kwamba kigezo cha mafanikio ni Definition of Done iliyoandikwa kwa amri. Ukishindwa kuandika kigezo cha kazi, hiyo ni ishara kwamba kazi hiyo pia imepewa wakala kwa utata.

Ukaguzi wa kiotomatiki au hakimu wa LLM

Matokeo yanaweza kukaguliwa kwa msimbo au kwa modeli nyingine. Kila njia ina eneo lake.

Kanuni: kwanza msimbo, hakimu juu yake

Kila kitu kinachoweza kukaguliwa kwa uamuzi, kikaguliwe kwa uamuzi. Hakimu wa LLM ongeza tu kwa sifa ambazo msimbo hauwezi kuzieleza, na kamwe usitumike badala ya majaribio.

Jinsi ya kumfanya hakimu wa LLM kuwa wa msaada

• Muktadha tofauti na mzalishaji. Hakimu asione hoja za wakala — aone kazi, vigezo na diff ya mwisho pekee. Vinginevyo atarudia makosa yale yale: hii ndiyo N-toleo, maoni mawili huru badala ya moja.
• Orodha ya vigezo badala ya "kadiria kwa kipimo cha kumi". Maswali mahususi yenye jibu ndiyo/hapana: "je, kuna uthibitishaji wa limit > 100", "je, faili nje ya app/payments zimebadilishwa".
• Urekebishaji kwa uwekaji alama wa mkono. Weka alama kwa mkono matokeo 20–30 kisha linganisha na hukumu za hakimu. Mechi ikiwa ndogo, badilisha orodha ya vigezo badala ya kumwamini hakimu zaidi.
• Kutokulingana kwa makosa. "Imekamilika" ya uongo ni ghali zaidi ya "haijakamilika" ya uongo: ya kwanza inaenda kwenye uzalishaji, ya pili inagharimu uendeshaji mmoja upya. Mpangilie hakimu akatae pale kuna shaka.

Vipimo vingine vya kuhesabu zaidi ya asilimia ya mafanikio

Idadi ya kazi zilizotatuliwa ni sehemu ya juu tu. Ili kuona hasa pa kurekebisha, zinahitajika vipimo vya uaminifu kutoka uhandisi wa kawaida.

• MTBF — idadi ya hatua au kazi ambazo wakala hupita kabla ya kukwama. Inaonyesha kwa uchache kiasi gani anavunjika.
• MTTR — muda unaochukua kurudi kwenye hali ya kazi baada ya hitilafu. Kupunguza hiki mara nyingi ni rahisi kuliko kuongeza MTBF: faili nzuri ya maendeleo na mazingira yanayorudiwa vinapunguza urejeshaji mara nyingi.
• Eneo la uharibifu — msimbo ngapi hatua moja mbaya inauharibu. Unadhibitiwa kwa kikomo cha diff na kutenganisha nakala ya kazi.
• Sehemu ya "imekamilika" za uongo — kazi ambazo wakala alitangaza mafanikio lakini ukaguzi ukashindwa. Ndicho kipimo hatari zaidi: kinaonyesha kama ripoti ya wakala inaweza kuaminika.
• Gharama na muda — tokeni na dakika kwa kazi. Harness iliyoongeza mafanikio kwa 5% lakini ikaongeza gharama mara mbili si mshindi kila wakati.

Daftari la kushindwa: evals kutoka kazi za kila siku

Si kila timu iko tayari kujenga kiendeshaji kamili mara moja. Toleo dogo la kupima ni daftari la kushindwa lenye safu tatu.

| Kazi                    | Matokeo                            | Tabaka        |
|-------------------------|------------------------------------|---------------|
| paginesheni /payments   | "imekamilika", majaribio 2 nyekundu | uthibitishaji |
| kurekebisha timeout webhook | dakika 30 za pip install       | mazingira     |
| urekebishaji wa refunds | sintaksia ya zamani ya ORM         | muktadha      |

Tabaka ni mojawapo ya maeneo matano ambako wakala huvunjika: maelezo ya kazi, muktadha, mazingira ya utekelezaji, maoni ya uthibitishaji, usimamizi wa hali. Baada ya rekodi ishirini utaona kikwazo halisi, na karibu kamwe hakipo pale ulipodhani. Kila mstari wa daftari ni mgombea wa kazi kwenye seti ya evals.

Kwa nini modeli yenye nguvu haisaidii

Mwitikio wa kwanza kwa kushindwa kwa wakala ni kuchukua modeli ghali zaidi. Wakati mwingine husaidia, lakini mara nyingi pengo kati ya benchmark na uhalisia wako halifungwi na modeli, bali na mazingira yanayoizunguka.

Ikiwa wakala anatumia nusu saa kuinua mazingira, hiyo ni tabaka la mazingira, na modeli ya bendera itatumia nusu saa ile ile. Ikiwa wakala anasema "imekamilika" majaribio yakiwa nyekundu, ni tabaka la uthibitishaji: hana amri inayosema ukweli. Ikiwa anaandika msimbo kwa mtindo wa mtu mwingine, hajapewa kanuni za mradi. Hakuna hata moja ya matatizo haya ni kuhusu akili ya modeli.

Evals zinakuwezesha kuthibitisha hili kwa uaminifu. Endesha seti kwa modeli ya sasa na kwa modeli ghali zaidi; kisha kwa modeli ya sasa pamoja na AGENTS.md iliyoongezwa amri za ukaguzi. Mara nyingi mabadiliko ya pili yanatoa faida kubwa kuliko ya kwanza, bila gharama yoyote. Lakini usiamini hilo kwa neno tu: seti ipo kwa ajili ya ulinganisho kama huu.

Mpango wa hatua kwa hatua: kupima wakala wa AI kwa wiki moja

1. Siku ya 1. Anzisha daftari la kushindwa na uandike kila hitilafu ya wakala, pamoja na tabaka lake.
2. Siku ya 2. Chagua kazi 20 kutoka tiketi zilizofungwa na daftari. Kwa kila moja, rekodi commit na andika kigezo cha mafanikio kwa amri.
3. Siku ya 3. Andika kiendeshaji: nakala safi ya kazi, kuendesha wakala kwa prompt ya kazi, kuendesha ukaguzi, kuandika matokeo kwenye JSONL.
4. Siku ya 4. Endesha kila kazi mara 3–5. Hesabu pass@1, pass^3, sehemu ya "imekamilika" za uongo, na wastani wa gharama.
5. Siku ya 5. Badilisha jambo moja kwenye harness na uendeshe tena. Linganisha tu kwa seti ile ile na idadi ile ile ya marudio.

Badilisha kigezo kimoja kwa wakati. Ukibadilisha modeli, prompt na zana kwa mara moja katika jaribio moja, hutajua kilichofanya kazi.

Makosa ya kawaida katika kupima wakala

• Uendeshaji mmoja kwa kazi. Kutokuwa na uamuzi kwa wakala kunafanya matokeo kuwa bahati nasibu. Angalau marudio matatu.
• Seti inabadilika kati ya ulinganisho. Umeongeza kazi mpya na pia umebadilisha prompt kwa wakati mmoja — nambari haziwezi kulinganishwa.
• Wakala anaona majaribio ya kukagua. Majaribio yakiwa kwenye hazina, wakala anaweza kurekebisha msimbo ili yapite au kuyabadilisha moja kwa moja. Weka ukaguzi uliofichwa nje ya nakala ya kazi, na thibitisha kwamba wakala hakugusa faili za majaribio.
• Ripoti ya wakala badala ya ukaguzi. "Majaribio yote yamepita" kwenye jibu la modeli si matokeo. Matokeo ni msimbo wa kutoka wa amri iliyoendeshwa na kiendeshaji.
• pass@k pekee. Nambari nzuri kwa wasilisho, na utabiri mbaya kwa kazi bila usimamizi.

Kwa ufupi

Kupima wakala wa AI ni seti maalum ya kazi halisi, ukaguzi wa kiotomatiki, na vipimo vinavyohesabiwa upya baada ya kila mabadiliko ya harness. pass@k inaonyesha wakala anaweza nini, pass^k inaonyesha kama anaweza kuaminiwa bila usimamizi. Ukaguzi wa kiotomatiki unatoa ukweli; hakimu wa LLM mwenye orodha ya vigezo na muktadha tofauti anasaidia pale msimbo hauwezi. Daftari la kushindwa lenye tabaka tano linaonyesha nini cha kurekebisha kwanza, na mara nyingi si modeli. Vipimo vya uaminifu na mzunguko wa utambuzi vinafafanuliwa kwa vitendo katika kozi ya harness engineering.