Nagpadala ka ng feature na pinapagana ng LLM anim na buwan na ang nakalipas. Sinubukan ito ng mabuti bago ilunsad. Ang mga gumagamit ay tila masaya sa simula. Ngunit kamakailan lamang, ang mga tiket ng suporta tungkol sa kalidad ng AI ay gumagapang. Ang provider ng modelo ay nagtulak ng update noong nakaraang buwan na hindi mo talaga nasuri. Ang iyong dataset ng pagsusuri ay hindi na-refresh mula nang ilunsad. At ang team na bumuo ng feature ay lumipat sa iba pang mga proyekto, nag-check in lang kapag may nasira nang husto upang humingi ng atensyon.
Ito ang default na trajectory para sa mga feature na LLM nang walang patuloy na pagsusuri. Nagbabago ang modelo, nagbabago ang data, nagbabago ang mga inaasahan ng user, at walang nakakapansin ng pagbaba ng kalidad hanggang sa maging totoong problema ito.
LLM pagsusuri retrospective ay ang kasanayang pumipigil sa mabagal na pagkabulok na ito. Hindi isang beses na yugto ng pagsubok bago ilunsad, ngunit isang umuulit na ugali ng pagsukat ng kalidad, pag-unawa sa mga pagkabigo, at sistematikong pagpapabuti.
Bakit LLM Ang Pagsusuri ay Pangunahing Naiiba
Kung nanggaling ka sa tradisyonal na software development, maliligaw ka ng iyong instincts tungkol sa pagsubok gamit ang LLMs. Narito kung bakit:
Ang mga output ay hindi deterministiko. Ang parehong input ay maaaring makagawa ng iba't ibang mga output sa bawat oras. Nangangahulugan ito na hindi ka maaaring sumubok gamit ang simpleng "inaasahang output ay katumbas ng aktwal na output" na mga pahayag. Kailangan mong suriin ang kalidad ng output sa isang spectrum, hindi sa isang binary pass/fail.
Ang kawastuhan ay subjective. Para sa maraming LLM gawain, walang iisang tamang sagot. Isang mahusay na buod, isang kapaki-pakinabang na tugon sa serbisyo sa customer, isang mahusay na pagkakasulat na email — kabilang dito ang mga tawag sa paghatol na hindi sinasang-ayunan ng mga makatwirang tao. Kailangang hawakan ng iyong evaluation framework ang subjectivity na ito nang tahasan.
Tahimik na bumababa ang kalidad. Malakas na nasira ang tradisyunal na software: mga error, pag-crash, mga nabigong pagsubok. Ang kalidad ng LLM ay unti-unting bumababa: bahagyang hindi gaanong tumpak ang mga output, bahagyang naiiba ang tono, bahagyang hindi gaanong nauugnay na mga tugon. Sa oras na may mapansin, maaaring bumaba ang kalidad nang ilang linggo.
Nagbabago ang modelo sa ilalim mo. Kung gumagamit ka ng API-based na modelo (na karamihan sa mga team ay), maaaring i-update ng provider ng modelo ang modelo anumang oras. Karaniwang pinapabuti ng mga update na ito ang mga bagay sa pangkalahatan, ngunit maaari nilang baguhin ang gawi para sa iyong partikular na kaso ng paggamit sa mga paraang hindi mo inaasahan.
Ang mga pagkakaibang ito ay nangangahulugan na kailangan mo ng tuluy-tuloy na kasanayan sa pagsusuri, hindi isang pagsubok-pagkatapos na diskarte.
Ano ang Susukatin
Hindi mo kailangang sukatin ang lahat. Kailangan mong sukatin ang mga bagay na mahalaga para sa iyong partikular na kaso ng paggamit, at sukatin ang mga ito nang pare-pareho nang sapat upang makita ang mga uso. Narito ang isang praktikal na balangkas.
Katumpakan at Katapatan
Naglalabas ba ang modelo ng tamang impormasyon? Ang dimensyong ito ay pinakamahalaga para sa mga makatotohanang gawain: pagsagot sa tanong, pagbubuod, pagkuha ng data, pagsusuri.
Paano magsuri: Kumuha ng sample ng mga kamakailang produksyon na output. Hayaang suriin ng isang tagasuri ng tao ang bawat isa para sa mga makatotohanang error, guni-guni (impormasyon na hindi suportado ng ibinigay na konteksto), at mga pagtanggal (mahalagang impormasyon na available ngunit hindi kasama).
Ano ang susubaybayan: Ang rate ng mga factual na error sa bawat sample, at kung nagte-trend pataas o pababa ang rate na iyon. Subaybayan din ang kalubhaan ng mga error — ang isang maling spelling na pangalan ay hindi gaanong nauukol kaysa sa isang maling halaga sa pananalapi.
Pagsunod sa Tagubilin
Ginagawa ba ng modelo ang ipinagagawa mo? Sinasaklaw nito ang pagsunod sa format, pagsunod sa hadlang, at pagkumpleto ng gawain.
Paano magsuri: Tukuyin ang malinaw na pamantayan para sa kung ano ang hitsura ng isang "tama" na pagpapatupad ng gawain. Ang output ba ay tumutugma sa hiniling na format? Iginagalang ba nito ang mga hadlang sa haba? Nananatili ba ito sa loob ng tinukoy na saklaw? Ang mga ito ay mas obhetibong nasusukat kaysa sa kalidad ng mga paghatol.
Ano ang susubaybayan: Ang porsyento ng mga output na sumusunod sa lahat ng mga tagubilin. Ikategorya ang mga paglabag — ang mga ito ba ay mga isyu sa format, mga paglabag sa hadlang, o pag-anod ng saklaw? Ang bawat isa ay tumuturo sa ibang pag-aayos.
Kalidad na Inaalam ng User
Nakikita ba ng mga user na kapaki-pakinabang, mahusay ang pagkakasulat, at kapaki-pakinabang ang mga output? Ito ang pinakamahirap sukatin ngunit masasabing pinakamahalaga.
Paano magsuri: Gumagana nang maayos ang dalawang diskarte. Una, mga in-product na senyales: thumbs up/down, tahasang rating, follow-up na mga tanong (kung nagtanong ang user ng follow-up, maaaring hindi kumpleto ang unang tugon). Pangalawa, pana-panahong pagsusuri ng tao: kumuha ng sample at i-rate ito sa isang rubric na tumutukoy kung ano ang ibig sabihin ng "mabuti" para sa iyong feature.
Ano ang susubaybayan: Pangkalahatang mga trend ng kasiyahan at ang mga partikular na dimensyon ng kalidad kung saan ang mga user ay nagpapahayag ng kawalang-kasiyahan.
Kaligtasan at Pag-align
Ang modelo ba ay gumagawa ng mga output na nakakapinsala, may kinikilingan, o hindi naaangkop? Ang dimensyong ito ay table stakes — ang mga pagkabigo dito ay may napakalaking epekto.
Paano suriin: Patakbuhin nang regular ang iyong suite ng pagsubok sa kaligtasan (hindi lamang sa paglulunsad). Isama ang adversarial testing: mga input na idinisenyo upang pukawin ang mga mapaminsalang output. Suriin ang anumang mga output na na-flag ng iyong content moderation layer.
Ano ang susubaybayan: Ang rate ng mga paglabag sa kaligtasan, kabilang ang mga near-miss na nahuli ng mga filter. Subaybayan ang mga resulta ng adversarial test sa mga update ng modelo — isang modelo na ligtas bago ang isang update ay maaaring hindi matapos.
Ang Pagsusuri ⟦RETROC⟧
Indayog
Buwanang gumagana nang maayos para sa karamihan ng mga koponan. Mas madalas kung nasa domain ka na may mataas na stakes (pangangalaga sa kalusugan, pananalapi, legal) o kung mabilis kang umuulit sa mga prompt. Mas madalang kung ang iyong feature ay stable at mababa ang panganib — ngunit hindi bababa sa quarterly.
Paghahanda
Ang ⟦RETRO⟧ ay kasing ganda lang ng data na dinadala mo dito. Kailangang maghanda ng isang tao sa koponan (iikot ang tungkuling ito):
Dashboard ng panukat. Ang iyong mga pangunahing sukatan ng kalidad para sa kasalukuyang panahon, kumpara sa nakaraang panahon. Panatilihing nakatutok ito — 4-6 na sukatan ang maximum, direktang nauugnay sa mga dimensyon sa itaas.
Mga sample na resulta ng pagsusuri. Patakbuhin ang iyong evaluation suite at dalhin ang mga resulta. Kung gumagawa ka ng pagsusuri ng tao, kumpletuhin ito bago ang pulong, hindi sa panahon nito.
Mga halimbawa ng pagkabigo. Ang 5-10 pinakamasamang output mula sa panahon. Isama ang buong konteksto: input, prompt, output, at kung bakit ito masama. Ang mga konkretong halimbawang ito ay kung saan nangyayari ang pinakaproduktibong talakayan.
Changelog. Anumang mga pagbabago na maaaring nakaapekto sa kalidad: mga prompt na update, mga pagbabago sa bersyon ng modelo, mga update sa data, mga pagbabago sa feature, mga pagbabago sa mga pattern ng paggamit.
Istruktura ng Pulong (60 minuto)
Pagsusuri ng mga sukatan (10 minuto). Bubuti ba tayo, bumababa, o flat sa bawat dimensyon? Anumang mga sukatan na lumagpas sa isang limitasyon na pinapahalagahan namin? Anumang hindi inaasahang pagbabago na hindi namin maipaliwanag?
Failure deep-dive (25 minuto). Maglakad sa mga halimbawa ng pagkabigo. Para sa bawat isa, dapat talakayin ng pangkat ang:
- Ano ang partikular na naging mali?
- Ito ba ay isang bagong failure mode o isa na nakita na natin dati?
- Ano ang pangunahing dahilan — prompt, modelo, data, o iba pa?
- Paano namin ito awtomatikong mahuhuli sa hinaharap?
Ang layunin ay hindi ayusin ang bawat pagkabigo sa pulong. Ito ay upang maunawaan ang mga pattern at bigyang-priyoridad.
Pagsusuri sa proseso ng pagsusuri (10 minuto). Talaga bang sinusukat ng aming pagsusuri ang mga tamang bagay? Mayroon bang mga failure mode na hindi natin nahuhuli? Kailangan ba nating i-update ang ating mga test case? Naaayon pa rin ba ang aming pamantayan sa pagsusuri sa kung ano ang pinapahalagahan ng mga user?
Ang meta-review na ito ay mahalaga. Ang mga proseso ng pagsusuri ay maaaring maging lipas tulad ng iba pa. Kung ang iyong mga pagsubok na kaso ay mula sa anim na buwan na ang nakalipas at ang mga pangangailangan ng iyong mga user ay nagbago, ang iyong pagsusuri ay nagbibigay sa iyo ng maling pakiramdam ng seguridad.
Mga item ng pagkilos (15 minuto). Pumili ng 2-3 partikular na pagpapabuti. Karaniwang nahahati ang mga ito sa mga kategorya:
- Mga agarang pagbabago upang matugunan ang mga partikular na pattern ng pagkabigo
- Mga pagpapahusay sa pagsusuri (mga bagong kaso ng pagsubok, na-update na rubrics, mas mahusay na automation)
- Mga update sa guardrail (mga bagong filter ng kaligtasan, karagdagang mga pagsusuri pagkatapos ng pagproseso)
- Mga gawain sa pagsisiyasat (hukay sa isang hindi maipaliwanag na pagbabago sa kalidad, i-profile ang isang partikular na mode ng pagkabigo)
Pagbuo ng Iyong Evaluation Stack
Hindi mo kailangan ng mamahaling tool para magsimula. Narito ang isang praktikal na pag-unlad.
Phase 1: Manu-manong Pagsusuri (Magsimula Dito)
Lingguhan, sample ng 20-30 production output. Magkaroon ng dalawang miyembro ng koponan na independyenteng i-rate ang bawat isa sa iyong rubric ng kalidad. Ihambing ang kanilang mga rating — kung madalas silang hindi sumasang-ayon, kailangang maging mas partikular ang iyong rubric. Subaybayan ang mga rating na ito sa isang spreadsheet.
Ito ay hindi nakakaakit ngunit epektibo. Matututo ka pa tungkol sa gawi ng iyong modelo mula sa pagbabasa ng 30 totoong output kaysa sa anumang naka-automate na sukatan.
Phase 2: Semi-Automated Evaluation
Bumuo ng isang dataset ng pagsusuri: 100-200 halimbawa na may input, inaasahang mga katangian ng output (hindi kinakailangang eksaktong mga output), at mga anotasyon ng kalidad. Awtomatikong patakbuhin ito sa tuwing babaguhin mo ang mga prompt o modelo. Gamitin ang mga resulta upang mahuli ang mga regression bago sila umabot sa produksyon.
Idagdag ang LLM-as-judge na pagsusuri para sa mga dimensyon kung saan ito gumagana nang maayos: pagsunod sa format, pagsunod sa pagtuturo, pangunahing pag-verify sa katotohanan. Gumamit ng pagsusuri ng tao para sa mga dimensyon kung saan hindi ito: nuance, helpfulness, tone appropriateness.
Phase 3: Patuloy na Pagsubaybay
Mag-set up ng mga awtomatikong pagsusuri sa kalidad sa trapiko ng produksyon. Hindi kailangang mahuli ng mga ito ang lahat — kailangan nilang mahuli nang sapat upang alertuhan ka kapag malaki ang pagbabago sa kalidad. Isang simpleng diskarte: random na sample ng maliit na porsyento ng mga query sa produksyon, magpatakbo ng mga awtomatikong pagsusuri, at alerto kung ang rate ng pagkabigo ay lumampas sa isang threshold.
Nakadagdag ito sa halip na palitan ang iyong pagsusuri ng tao. Mabilis na nahuhuli ng awtomatikong pagsubaybay ang mga biglaang pagbabago. Nahuhuli ng pagsusuri ng tao ang banayad na pag-anod ng kalidad na hindi nakuha ng mga automated na sukatan.
Mga Karaniwang Pagkakamali sa Pagsusuri
Pagsusuri lamang sa mga madaling halimbawa. Kung ang iyong dataset ng pagsusuri ay walang kasamang mahirap na kaso, sinusukat mo ang pinakamahusay na kaso ng pagganap, hindi ang pagganap sa totoong mundo. Isama ang mga adversarial input, hindi malinaw na mga query, content na tukoy sa domain, at ang mga uri ng magugulong input na ipinapadala ng iyong aktwal na mga user.
Paggamit ng mga automated na sukatan bilang ang tanging sukat. Ang mga automated na sukatan (BLEU, ROUGE, BERTScore) ay kapaki-pakinabang para sa pagsubaybay sa mga trend ngunit hindi gaanong nauugnay sa mga paghuhusga sa kalidad ng tao para sa maraming gawain. Kung ang iyong mga automated na sukatan ay nagsasabing ang kalidad ay maayos ngunit ang mga user ay nagrereklamo, magtiwala sa mga user.
Paghahambing ng mga modelo sa iba't ibang hanay ng pagsusuri. Kung sinusuri mo kung lilipat ng mga modelo, gamitin ang eksaktong parehong hanay ng pagsusuri para sa pareho. Kung susubukan mo ang Model A sa isang hanay ng mga halimbawa at Model B sa ibang hanay, ang paghahambing ay walang kabuluhan.
Hindi sinusubaybayan ang inter-rater na kasunduan. Kung hindi sumasang-ayon ang iyong mga human evaluator sa 40% ng mga rating, maingay ang iyong data ng pagsusuri. Pahusayin ang iyong rubric, magbigay ng higit pang pagsasanay, o tanggapin na ang gawain ay likas na subjective at idisenyo ang iyong mga sukatan nang naaayon.
Ang pag-evaluate ay masyadong madalang. Ang buwanang pagsusuri na may lingguhang mga pagbabago sa modelo ay nangangahulugan na palagi kang tumitingin sa lipas na data. Itugma ang iyong ritmo ng pagsusuri sa iyong ritmo ng pagbabago.
Paggawa ng Pagsusuri na Bahagi ng Kultura
Ang pinakamahirap na bahagi ng LLM na pagsusuri ay hindi ang pamamaraan — ito ay pagpapanatili ng kasanayan. Ang pagsusuri ay parang overhead, lalo na kapag ang mga bagay ay maayos. Totoo ang tuksong laktawan ang "ngayong buwan lang."
Ano ang nakakatulong: gawing nakikita ang mga resulta ng pagsusuri. Ibahagi ang mga ito sa mga channel ng koponan. Ipagdiwang ang mga pagpapabuti ng kalidad. Tratuhin ang mga de-kalidad na regression bilang mga insidente na karapat-dapat sa pagsisiyasat. Kapag natuklasan ng pagsusuri ang isang problema bago ito mapansin ng mga user, gawin din itong nakikita — binibigyang-katwiran nito ang patuloy na pamumuhunan.
Sa paglipas ng panahon, ang mga koponan na may malakas na kasanayan sa pagsusuri ay nagkakaroon ng mas mahusay na mga intuwisyon tungkol sa kanilang mga modelo. Inaasahan nila ang mga mode ng pagkabigo. Gumagawa sila ng mga agarang pagbabago nang may higit na kumpiyansa. Mas mabilis nilang nahuhuli ang mga isyu kapag nangyari ang mga ito. Ang retrospective ay ang mekanismong bumubuo sa kaalamang ito sa institusyon.
Subukan ang NextRetro nang libre — Buuin ang iyong pagsusuri retrospective na may mga yugto para sa pagsusuri ng sukatan, pagsusuri sa pagkabigo, at pagpaplano ng pagpapabuti.
Huling Na-update: Pebrero 2026
Oras ng Pagbasa: 8 minuto
