Mga eval: mula sa mga eksperimento sa AI tungo sa kumpiyansang produksyon

• Bagama't humusay ang mga foundation model, ang tunay na pagbabagong nagbigay-daan sa kumpiyansang paggamit sa produksyon ay nagmula sa disiplinadong pagsusuri.

• Tinutulungan ng mahuhusay na eval ang mga product manager, pinuno ng pamamahala sa AI, at CTO na ligtas na mag-deploy ng mga AI agent sa malawakang saklaw, kaya nagiging bentahe sa kompetisyon ang AI sa halip na laruan lamang na nakahiwalay sa iba.

• Nagmumula ang kumpiyansang iyon sa pagsusuri ng gawi ng AI agent gamit ang mga tunay na query ng user, edge case, at sitwasyong partikular sa domain na sumasalamin sa aktuwal na konteksto ng iyong negosyo—hindi sa isang pampublikong benchmark na nagsasabing “ang modelong ito ang pinakamahusay.”

• Layunin nitong bigyang-katwiran ang kumpiyansang iyon sa pamamagitan ng mga nasusukat na resulta. Ang tagumpay ay ang pagtukoy sa "mahusay" sa kongkreto at nasusukat na paraang naaayon sa mga pangangailangan at kakayahang tumanggap ng panganib ng iyong negosyo—maging ito man ay katumpakan ng impormasyon, angkop na tono, bilis, o kahusayan sa gastos.

• Sa pagsasama ng pagsusuri sa iyong buong sistema—instrumentation, logging, A/B testing, at guardrails—at pagbabalanse ng pagiging masusi at mahusay, mas mapapabilis ng mga team ang deployment at mapatitibay ang sistema.

Komportable ang karamihan ng negosyo na hayaang mag-eksperimento ang kanilang mga empleyado sa ChatGPT o Gemini. Ngunit hindi pa karaniwan ang paggamit ng mga LLM sa mga workflow o sitwasyong mataas ang nakataya.

Madalas na makatwiran ang mga dahilan: hindi pare-pareho ang kalidad, at mas mabigat ang panganib ng hallucination o hindi kanais-nais na gawi kaysa sa mga posibleng pakinabang ng teknolohiya.

Malaki ang ipinagbago ng balanseng iyon sa pagitan ng panganib at pakinabang nitong nakaraang taon. Bagama't maipapaliwanag ang ilan dito ng paghusay ng mga foundation model, malaking bahagi nito ang bunga ng lumalaking disiplina sa pagsusuri (o “mga eval”). Binibigyan kami at ang aming mga kliyente ng mga eval ng kumpiyansang mag-deploy ng malawakang mga agent na humaharap sa kliyente sa loob lamang ng ilang linggo.

Ipapaliwanag ng gabay na ito ang mga pangunahing elemento ng eval, kung paano idisenyo at ipatupad ang mga ito, at kung paano patakbuhin ang mga ito para sa mga gamit sa produksyon.

Ang layunin ng pagsusuri ay hindi makahanap ng perpektong modelo, kundi makabuo ng makatwirang kumpiyansa na kumikilos ang iyong modelo ayon sa mga pangangailangan ng negosyo, inaasahan ng mga user, at kakayahang tumanggap ng panganib ng iyong organisasyon.

Nasa pundasyon ng anumang estratehiya sa pagsusuri ang isang simpleng tanong: Ano ang maituturing na “mahusay”? Dapat maging tiyak ang sagot. Para sa isang organisasyon, ang “mahusay” ay maaaring mangahulugan ng katumpakan ng impormasyon sa loob ng mahihigpit na limitasyon; para sa iba, maaaring unahin nito ang bilis, kahusayan sa gastos, o natatanging tono. Hinuhubog ng bawat limitasyong kinakaharap mo—mula sa kung anong data ang maaaring gamitin hanggang sa mga naaangkop na obligasyon sa regulasyon—ang kahulugang ito.

Higit sa lahat, kailangang may mga bahaging talagang masusukat ang 'mahusay'. Kung ang tagumpay ay pagbibigay ng kapaki-pakinabang na gabay sa pananalapi, kailangang maipahayag ang pagiging kapaki-pakinabang sa pamamagitan ng mga katangiang ito: wastong impormasyon, angkop na disclaimer, personalisadong pangangatwiran, at ligtas na mga hangganan. Kapag natukoy na ang ‘mahusay’ sa nasusukat na paraan, ang susunod na tanong ay kung paano mo susuriin at bibigyang-kahulugan ang mga resulta. Ang pagkilos batay sa mga resultang ito ang ginagawang isang pamamaraan ang pagsusuri, sa halip na simpleng paghatol lamang.

Nakabatay ang bawat pipeline ng pagsusuri sa tatlong magkakaugnay na haligi:

1. Mga Input/Benchmark: Mga kumakatawang halimbawa mula sa tunay na mundo para sa pangkalahatang performance, at maingat na piniling internal dataset upang subukan ang pagiging angkop sa domain.

2. Gawi ng Modelo: Kung paano tinatawag ang modelo (retrieval-augmented generation, pagbubuod, pagkuha ng naka-structure na impormasyon, paggamit ng tool).

3. Mga Sukatan: Kung paano mo sinusukat at binibigyang-kahulugan ang performance.

Kailangang kumatawan ang mga input sa mundong haharapin ng iyong sistema. Nagmumula ang pinakamakabuluhang insight sa mga tunay na halimbawa: mga query ng customer, sitwasyong pinansyal, o kasong partikular sa industriya. Sa pagsusuri lamang gamit ang mga ito mo malalaman kung tunay na nauunawaan ng modelo ang mga detalyeng kailangan ng iyong mga user at natutugunan nito ang pangangailangan ng negosyo.

Kasinghalaga ng modelo mismo ang gawi nito—gaya ng paraan ng pag-prompt dito, pag-oorkestra ng retrieval o paggamit ng tool, at pagbibigay ng konteksto. Maaaring lubhang magkaiba ang gawi ng dalawang magkaparehong modelo depende sa paraan ng pag-deploy sa mga ito. Samakatuwid, kailangang isama ang layer na ito sa disenyo ng iyong pagsusuri.

Panghuli, narito ang mga sukatan. Bihirang maipakita ng mga numero lamang ang buong larawan, ngunit ginagawang mas madaling maunawaan ng mahuhusay na napiling sukatan ang gawi ng sistema. Kapag pinagsama, ang latency, katumpakan, kaligtasan, pagkakaugnay-ugnay, bias, gastos, at kasiyahan ng user ay bumubuo ng multidimensional na larawan ng isang sistemang nasa produksyon. Ang susi ay ang pagpili ng mga sukatang naaayon sa mga KPI ng iyong proyekto o negosyo at nagbibigay-linaw sa mga katangiang pinakamahalaga sa iyong mga user. Madalas na mas tumpak at mas mura ang mas simpleng sukatan, samantalang maaaring iligaw ang mga team ng maling pagpili ng sukatan. Ganito dapat pag-isipan ang pagpili ng sukatan:

Mga halimbawa ng mahusay na pagpili ng sukatan:

• Chatbot para sa customer service: Rate ng paglutas sa unang pakikipag-ugnayan (nalutas ba ang problema ng user nang hindi kailangang i-escalate?), average na oras ng pag-asikaso, marka ng kasiyahan ng user, at rate ng pag-escalate sa mga taong agent

• Tool sa pananaliksik na pinansyal: Katumpakan ng citation (% ng mga pahayag na may wastong source), katumpakan ng impormasyong napatunayan laban sa ground truth, kaugnayan ng retrieval (nahanap ba nito ang mga tamang dokumento?), at pagkakaugnay-ugnay ng pangangatwirang minarkahan ng mga eksperto sa domain

• Assistant sa pagbuo ng code: Wastong syntax, test pass rate, bilang ng kahinaan sa seguridad, at oras bago makabuo ng gumaganang solusyon

Mga halimbawa ng hindi mahusay na pagpili ng sukatan:

• Paggamit lamang sa haba ng tugon bilang batayan ng kalidad (mas mahaba ≠ mas mahusay)

• Pagsukat ng bilis nang hindi isinasaalang-alang ang kapalit nitong epekto sa katumpakan

• Pagsubaybay sa mga confidence score ng modelo nang hindi inihahambing ang mga ito sa aktuwal na kawastuhan

• Pag-asa lamang sa internal model perplexity nang walang validation na nakatuon sa user

Mga karaniwang problema sa sukatan na dapat iwasan:

• Magkasalungat na sukatan: Sabay na pag-optimize para sa bilis at pagiging komprehensibo nang hindi kinikilala ang kapalit na epekto

• Sobrang pag-angkop sa mga benchmark: Pagkamit ng 95% sa test set ngunit pagkabigo sa produksyon dahil iba ang gawi ng mga tunay na user

Para sa isang kliyente sa serbisyong pinansyal na mahigpit na kinokontrol, pinakamahalaga ang katumpakan ng kanilang solusyon sa malalimang pananaliksik. Gumawa kami ng mga QA dataset na binuo ng mga eksperto at sinamahan ng mga dataset na ginawa ng tool. Dahil dito, nasuri namin ang katumpakan, kakayahan ng sistema na pumili ng tamang tool, at pagkuha ng tamang impormasyon—na nagbigay ng balanseng larawan ng katumpakan at kalidad ng pangangatwiran. Ang susi ay pagsukat sa maraming dimensyon: katumpakan ng impormasyon (validation ng eksperto), kalidad ng retrieval (precision/recall ng mga kaugnay na dokumento), at pagkakaugnay-ugnay ng pangangatwiran (naka-structure na pagsusuri sa lohikal na daloy).

Kailan gagamit ng LLM-as-a-judge para sa mas masusing pagsusuri ng kalidad

Gumagamit ang LLM-as-a-judge ng pangalawang modelo ng AI bilang tagasuri, na pinapalitan ang pagsusuri ng tao ng nasusukat at automated na pagmamarka sa kalidad. Madalas na maling ginagamit ang LLM-as-a-judge kapag sapat na ang mas simpleng sukatan upang makuha ang kinakailangang katumpakan. Maaari itong makatulong kapag hindi kayang sukatin ng mga deterministic check ang kalidad, gaya kapag semantic ang sukatan—pagiging kapaki-pakinabang, pagkakabatay sa source, kalidad ng pangangatwiran, tono, o interpretasyon ng patakaran—at hindi posible ang deterministic na pagmamarka. Maaaring kailangan mo ng nasusukat na feedback sa maraming variant ng prompt/modelo, pati ng malinaw na rubric at schema ng naka-structure na output. Upang maging epektibo ito para sa iyo, sundin ang mga hakbang na ito:

• Malinaw na tukuyin ang mga dimensyon ng rubric: kawastuhan, pagkakabatay sa source, pagsunod sa patakaran, kakayahang maisagawa, at tono.

• Gumamit ng mga naka-structure na output (JSON schema) para sa mga tugon ng judge.

• Itala ang mga binary gate score at diagnostic text para sa pagsusuri ng pagkabigo.

• I-calibrate ang mga output ng judge gamit ang mga sample na nilagyan ng label ng tao sa bawat release cycle.

• Gumamit ng dalawang judge o pana-panahong consensus check para sa mga domain na mataas ang nakataya.

• Subaybayan sa paglipas ng panahon ang drift ng judge at rate ng hindi pagkakasundo.

Ang benchmark dataset ay isang nakapirmi at maingat na piniling hanay ng mga test example na may mga alam na sagot, na ginagamit upang palaging pareho ang pagsusuri sa mga modelo at patas na maihambing ang mga resulta ng iba't ibang version. Karaniwan itong may mga input (hal., mga query ng user), inaasahang output o reference judgment, at pamantayan/label sa pagsusuri para sa pagmamarka. Ginagamit ang mga pampublikong benchmark test upang ihambing ang performance ng mga makabagong modelo, at maaari itong maging kapaki-pakinabang na panimulang sanggunian sa pagdidisenyo ng iyong sistema at pagpili ng modelong maaaring gamitin.

Gayunman, hindi mo maaaring gamitin ang mga benchmark na ito bilang pamalit sa pagsukat ng performance ng sarili mong sistema sa konteksto ng iyong negosyo dahil may mga kilalang problema ang mga ito:

• Kontaminasyon: Maaaring sinanay ang mga modelo gamit ang benchmark data; ang pagsusuri gamit ang parehong dataset ay parang pagmamarka habang may kodigo.

• Saturation: Nasa pinakamataas na marka na ang lahat ng nangungunang modelo, kaya ilang percentage point lamang ang posibleng paghusay o paghina ng performance at madalas ay pasok pa ito sa likas na pagbabago-bago ng mga resulta ng test.

• Limitadong saklaw: Hindi sinasalamin ng benchmark data ang iyong mga aktuwal na gawain dahil lubos itong pinili at nilinis. Ang ilan ay binuo pa ng LLM at hindi magpapakita ng pagiging kumplikado at mga edge case sa iyong data, gaya ng typo, di-karaniwang pananalita, at malabong larawan.

Humihingi ang isang mag-aaral ng tulong sa application upang malutas ang mga word problem.

Halimbawa ng pampublikong benchmark na maaari mong gamitin: GSM8K (pangangatwiran sa matematika sa grade school)

• Opsyonal na mas mahirap na set: MATH.

Bakit kapaki-pakinabang ang benchmark na ito:

• Mabilis na maihahambing kung aling modelo ang mas mahusay sa pangkalahatang pangangatwiran sa matematika,

• Mahusay na paunang filter bago mamuhunan sa kumpletong mga eval ng produkto.

Bakit kailangan mo pa rin ng sarili mong dataset:

May mga kinakailangan ang iyong app na hindi sinusuri ng GSM8K:

• Pananalita at pagkakasunod-sunod ng paksa sa iyong kurikulum,

• Paraan ng pagpapaliwanag para sa iyong pangkat ng edad,

• Paano aasikasuhin ang malabo o maraming typo na tanong ng mag-aaral,

• Mga patakaran (hal., kailan magbibigay ng pahiwatig sa halip na kumpletong sagot).

Nakabatay ang epektibong validation sa pagbuo ng mga benchmark sa pagsusuri na partikular sa iyong application. Dapat magmula ang mga dataset na ito sa mga tunay na pakikipag-ugnayan, karaniwang edge case, at posibleng paraan ng pagkabigo. Maaaring mahirap itong gawin kapag nagpapatupad ng bagong produkto o proseso. Gayunman, sa karamihan ng kaso ay posibleng mangolekta ng data mula sa kasalukuyang produkto o sa pinakamaagang pagkakataon, kahit sa paunang yugto ng testing. Matapos mabuo ang iyong application, dapat umunlad ang mga benchmark kasabay ng iyong produkto at maging mas kumpleto at mas kumakatawan sa tunay na paggamit sa paglipas ng panahon.

Napakahalaga ng ugnayan ng benchmark na partikular sa iyong application at ng pagpili ng modelo. Hindi lamang ipinapakita ng iyong benchmark kung gumagana ang solusyon, kundi pati kung anong kombinasyon ng laki ng modelo at mga post-training technique ang naghahatid ng kinakailangang performance sa pinakamababang gastos. Ang pinakamalalaking pagpapahusay sa mga pre-trained na modelo—ang ‘PT’ sa ChatGPT—ay nagmumula hindi sa muling pagsasanay, kundi sa mga paraang "post-training".

Nakatuon ang mga paraang ito sa paghubog sa impormasyong maa-access ng modelo, kung paano nakaayos ang impormasyong iyon, at kung paano ginagabayan at inoorkestra ang modelo sa inference time. Mga post-training technique gaya ng:

• Chain-of-thought prompting at dynamic compute allocation (mag-isip nang mas matagal para sa mas mahihirap na problema)

• Self-consistency, kung saan bumubuo ng maraming output at pinipili ang pinakamahusay

• Pagbuo at pag-oorkestra ng konteksto, gaya ng Retrieval-Augmented Generation (RAG), mga few-shot na halimbawa, at mga agentic workflow

• Paggamit ng tool at pag-access sa panlabas na kaalaman, na nagbibigay-daan sa modelo na kumilos nang lampas sa mga internal parameter nito

• Mga estratehiya sa representasyon at pag-iimbak ng kaalaman, na idinisenyo para sa mahusay na retrieval at pangangatwiran gamit ang naka-structure at hindi naka-structure na data

Bagama't lubos na mapahuhusay ng mga post-training technique na ito ang performance ng sistema, may kaakibat din itong mga kapalit. Pinatataas ng bawat karagdagang layer ng orchestration, retrieval, o pangangatwiran ang pagiging kumplikado ng sistema, inference time, at gastos sa operasyon. Gayunman, kapag maingat na inilapat, madalas na nagbibigay-daan ang tamang kombinasyon ng mga post-training technique na gumamit ng mas maliit, mas mabilis, at mas murang modelo habang natutugunan pa rin ang mga kinakailangan sa performance. Sa halip na palakihin ang modelo, nakakamit ang performance sa pamamagitan ng mas mahusay na disenyo ng sistema.

Likas na nakadepende sa application ang paghahanap ng balanseng ito, at dapat gamitin ang mga eval na partikular sa iyong application upang matukoy ang pinakamainam na kumbinasyon ng mga technique. Matutulungan ka nitong matukoy kung kailan hindi na nagbibigay ng makabuluhang pakinabang ang karagdagang orchestration, upang mapili ng mga team ang pinakamababang antas ng post-training complexity na kailangan para sa target nilang performance.

Kailangang ituring ang isang solusyong AI bilang buong sistema: mga database, API, user interface, orchestration layer, imprastraktura sa monitoring, at iba pa. Samakatuwid, kailangang saklawin ng pagsusuri ang buong stack. Dapat mong subaybayan ang mahahalagang bahagi ng sistema upang makita ang mga posibleng problema at responsableng mapabilis ang pag-unlad.

Ang pagsubaybay sa mahahalagang bahagi ng sistema ay nangangahulugan ng:

• Paglalagay ng instrumentation sa iyong mga pipeline para sa mga nasusukat na resulta.

• Pag-log ng mga eksperimento upang makita ang epekto ng bawat pagbabago.

• Paggamit ng simpleng paghahambing na A/B bago mag-deploy ng malalaking pagbabago upang masuri ang mga posibleng regression.

Pinaikli ng pag-ulit na batay sa data ang landas mula prototype hanggang produksyon nang walang blind spot. Mahalaga rin ang logging at monitoring upang maunawaan ang aktuwal na paggamit sa application. Narito ang isang halimbawa upang matiyak ang observability:

• Hakbang 1: Pumapasok ang request ng user kasama ang request_id, user_segment, intent.

• Hakbang 2: Itinatala ng trace ang version ng modelo, version ng prompt, retrieval docs, at tool calls.

• Hakbang 3: Minamarkahan ng LLM judge ang tugon (correctness, groundedness, policy_risk).

• Hakbang 4: Sinusuri ng rule engine ang mga threshold.

• Hakbang 5: Kung lumabag sa threshold, mag-trigger ng alert + i-route sa fallback/pagsusuri ng tao.

• Hakbang 6: Idinaragdag ang pagkabigo sa triage queue at pagkatapos ay sa benchmark backlog.

Bihirang kumilos ang mga tunay na user nang eksakto sa inaasahan ng mga designer. Mali ang pagkaunawa ng ilan sa mga tagubilin. Sadyang susubukan naman ng iba ang mahihinang bahagi. Hindi anomalya ang mga edge case na ito, kundi mahahalagang signal. Kinukuha at sinusuri ng maayos na ipinatupad na pipeline ng pagsusuri ang mga ito, saka isinasama sa mga susunod na test. Posible lamang ang mabilis na pag-ulit nang walang blind spot kapag bahagi na ng sistema ang pagsusuri, hindi idinaragdag lamang matapos ang development.

Inirerekomenda naming isama ang mga guardrail at monitoring mula sa unang araw:

• Regular na subaybayan ang mga sukatan at regression ng modelo gamit ang benchmark na partikular sa iyong application.

• Kunin at suriin ang mga edge case o adversarial input, at idagdag ang mga ito sa benchmark dataset na partikular sa iyong application.

• Tiyaking nakaayon ang mga sukatang ito sa pagsusuri sa iyong mga pangunahing KPI.

• Regular na kuwestiyunin ang iyong dataset at benchmark upang matiyak na hindi mo napapansin ang mga bagong panganib o naaapektuhan ng mga bias.

• Magpatupad ng mga automated alert para sa paghina ng sukatan (hal., kung bumaba sa 85% ang katumpakan, mag-trigger ng pagsusuri).

• Panatilihin ang proseso ng pagsusuri ng tao para sa mga desisyong mataas ang nakataya (legal na payo, medikal na gabay, at transaksyong pinansyal).

Gumagamit ng compute at enerhiya ang bawat pagpapatakbo ng benchmark. Pinatataas ng bawat paulit-ulit at hindi kailangang eksperimento ang gastos. Dapat balansehin ng responsableng pagsusuri ang pagiging masusi at mahusay.

Maaaring gawin ang ilang praktikal na hakbang upang hindi lumobo ang paggamit ng enerhiya at gastos:

• Gumamit ng mas maliliit na modelo kapag posible, patakbuhin ang mga paunang eksperimento sa mas murang modelo, at mag-scale up lamang kapag napatunayan na ang pamamaraan.

• I-cache ang mga prompt at API call.

• Gumamit ng energy-aware scheduling (batch processing, spot instances, flex priority).

• Subaybayan ang paggamit ng compute kasabay ng performance.

Manatiling alerto rin sa mga umuusbong na regulasyon sa AI. Kahit walang nakalaang batas, naaangkop pa rin ang mga umiiral na framework at kinakailangang hakbang, gaya ng:

Proteksyon ng data:

• Tiyaking walang PII ang mga benchmark dataset kung walang wastong pahintulot

• Magpatupad ng mga patakaran sa pagpapanatili ng data para sa mga naka-log na query

• Maglaan ng mga mekanismo para sa mga kahilingang mag-delete ng data

Pagkakapantay-pantay at bias:

• Subukan ang performance sa iba't ibang demograpikong grupo

• Magsama ng magkakaibang representasyon sa pagbuo ng benchmark

Mga karapatang pantao at transparency:

• Malinaw na idokumento para sa mga user ang mga limitasyon ng modelo

• Magbigay ng mga paliwanag para sa mga desisyong mataas ang nakataya

• Bigyang-daan ang pangangasiwa ng tao sa mga kritikal na application

Ang pagsusuri ay hindi minsanang gawain, kundi isang sistemang patuloy na umuunlad. Sa larangang mabilis magbago, nakasalalay ang iyong bentahe sa bilis ng iyong pagsubok, pagkatuto, at pag-angkop upang mas epektibong makapag-deploy ng mga modelo at bagong solusyon.

Sa pagsasama ng pagsusuri bilang isang pangunahing gawain sa engineering at product management, mas mabilis at mas ligtas na makakagawa ng inobasyon ang mga team. Magsimula sa pagtukoy kung ano ang maituturing na mahusay sa konteksto ng iyong AI application, magtatag ng platform sa pagsusuri, at patuloy itong paunlarin upang magkaroon ka ng benchmark na partikular sa application at nagbibigay ng kumpiyansa sa kahandaan para sa produksyon sa bawat pag-ulit.