Mga nadagdag:
- Kakayahang kilalanin ang tahimik na mga sanhi ng pagkasira ng modelo (data drift, concept drift, upstream error) at magtatag ng tatlong-layer (operational, input, output) na pagsubaybay
- Kakayahang suriin ang mga LLM system sa maraming layer na may mga pagsusuri sa panuntunan, LLM-referee at pagsusuri ng tao, at i-calibrate gamit ang LLM-referee human anchor
- Kakayahang magdisenyo ng eval set na naglalaman ng mga edge at security cases at gawing permanenteng test case ang bawat nahuli na error
Kapag ang isang modelo ay pumasok sa produksyon, ang iyong trabaho ay hindi tapos; Magsisimula pa lang ang tunay na responsibilidad. Dahil ang modelo ay maaaring tahimik na masira kapag walang nakatingin. Sa yunit na ito, sinasaklaw namin ang dalawang pantulong na disiplina: pagsusuri (sistematikong pagsukat sa kalidad ng modelo) at pagsubaybay (patuloy na pagsubaybay sa modelo sa produksyon). Lalo na sa mga LLM system, ang eval ay mas mahirap at nangangailangan ng higit na pangangalaga kaysa sa classical na ML.
Kung bakit tahimik na nasisira ang production model
Nagka-crash ang isang bug, nagpi-print ang log, tumunog ang alarm. Ang isang modelo ng ML, sa kabilang banda, ay maaaring mali nang hindi nagdudulot ng mga error. Tatlong pangunahing sanhi ng pagkasira:
- Data drift: Ang pamamahagi ng input data ay nagbabago sa paglipas ng panahon (mga bagong produkto, pagbabago ng gawi ng user, seasonality). Ang modelo ay nananatiling pareho ngunit ang mundo ay nagbabago.
- Concept drift: Nagbabago ang input-output relationship. Ang mga taktika ng pandaraya at mga pattern ng spam ay nagbabago; Kung ano ang tama kahapon ay magiging mali ngayon.
- Upstream na katiwalian: Ang isang data source ay nagbabago ng format, ang isang lugar ay nagiging libre; Ang modelo ay tahimik na naglalaway sa sira na input.
Ang pagsubaybay ay ginagawang maririnig ang mga tahimik na pagbaluktot na ito.
Ano ang dapat panoorin: tatlong layer
Ang mahusay na pagsubaybay ay sumasaklaw sa tatlong layer:
- Mga sukatan sa pagpapatakbo: Latency, rate ng error, dami ng kahilingan, paggamit ng mapagkukunan. "Nakatayo ba ang sistema?"
- Mga sukatan ng data/input: Ang pamamahagi ba ng input ay katulad ng sa pagsasanay? Tumaas ba ang nawawalang halaga? May dumating na mga bagong kategorya? "Nakikita ba ng modelo ang pamilyar na data?"
- Mga sukatan ng modelo/output: Log ng pamamahagi ng hula? Bumaba ba ang mga marka ng kumpiyansa? At kung maaari, ano ang katumpakan kumpara sa ground truth? "Sakto pa ba ang modelo?"
Ang ikatlong layer ay ang pinakamahalaga ngunit ang pinakamahirap; dahil ang tunay na resulta ay kadalasang may pagkaantala (ito ay nagiging malinaw pagkatapos ng mga buwan kung ang isang utang ay babayaran o hindi).
Tip: Kung naantala ang aktwal na resulta, subaybayan muna ang pamamahagi ng input at hula. Ang paglilipat ng pamamahagi ng input ay isang maagang tanda ng pagkasira ng katumpakan at maaaring magtaas ng alarma nang hindi naghihintay ng aktwal na resulta.
Pagsusuri sa mga sistema ng LLM: ang espesyal na hamon
Sa klasikal na ML, ang "tamang sagot" ay malinaw (klase 0 o 1). Ang resulta ng LLM, sa kabilang banda, ay bukas: maaaring maraming tamang sagot sa parehong tanong, ang "katumpakan" ay hindi magkasya sa isang numero. LLM eval approach:
- Mga na-refer na sukatan: Paghahambing ng output sa perpektong sagot. Limitado; dahil ito ay maaaring isaalang-alang ang tamang sagot na ipinahayag sa ibang paraan bilang "mali".
- Mga pagsusuring batay sa mga panuntunan: Wasto ba ang output na JSON? Mayroon bang anumang mga ipinagbabawal na salita? Naglalaman ba ito ng mga gustong field? Mura, maaasahan, masikip.
- LLM-judge (LLM-as-judge): Huwag magtanong sa isang modelo ng "maganda ba ang sagot na ito ayon sa pamantayang ito?" Nag-i-scale ito, ngunit ang referee mismo ay dapat ma-verify.
- Human review: Gold standard ngunit mahal at mabagal. Ito ay ginagamit sa sample.
Sa pagsasagawa, ang mga ito ay ginagamit nang magkasama: murang mga pagsusuri sa panuntunan sa bawat output, LLM-hukom sa isang malaking sample, pagsusuri ng tao sa isang maliit ngunit mahigpit na sample.
Mahinang diskarte / Malakas na diskarte
Mahina: "LLM-Tinanong ko ang referee, 92% ng aming mga sagot ay maganda. Ang sistema ay mahusay."
Güçlü: "Una naming nilagyan ng label ng tao ang 100 printout. Pinatakbo namin ang LLM-judge sa parehong 100 printout at sinukat ang kasunduan ng human-judge — 85% na kasunduan, katanggap-tanggap. Naidokumento namin kung saan sistematikong nagkamali ang hukom (isang tendensiyang makahanap ng mahabang sagot na hindi patas na maganda) at naayos ang kanyang prompt. Noon lang kami nagtiwala sa marka ng hukom."
Ang pagkakaiba: ang malakas na diskarte ay nagpapatunay sa referee na may anchor ng tao, hindi nang walang taros. Ang hindi na-verify na LLM-referee ay nagbibigay ng maganda ngunit maling kumpiyansa.
Pansin: Ang LLM-referee ay isa ring modelo; hallucinogenic, biased (pabor sa mahaba/tiwala na mga sagot), ay maaaring hindi tugma. I-calibrate ang mga score ng referee gamit ang mga human tag bago gumawa ng mga desisyon sa produksyon.
Set ng pagsusuri: maingat na idinisenyo
Ang isang mahusay na hanay ng eval ay kumakatawan sa iba't ibang tunay na paggamit at mahirap na mga kaso. Ang isang eval na puno ng mga madaling halimbawa ay mag-iiwan sa iyo sa maling kumpiyansa. Siguraduhing ilagay ito sa eval cluster:
- Edge cases: Walang laman na input, napakahabang input, hindi pangkaraniwang format.
- Mga kilalang mahirap na kaso: Mga halimbawa kung saan nagkamali ang modelo sa nakaraan (bilang isang pagsubok sa regression).
- Mga insidente sa seguridad: Mga agarang pagtatangka sa pag-iniksyon, mga nakakahamak na kahilingan, mga bitag sa paglabag sa privacy.
Lumalaki ang eval cluster sa paglipas ng panahon: ang bawat bagong bug na nahuli mo sa produksyon ay nagiging test case para sa susunod na pagsusuri.
Alarm at interbensyon
Nananatiling hindi kumpleto ang pagsubaybay nang walang alarma. Dapat ay mayroong threshold at isang plano sa pagtugon para sa bawat mahalagang sukatan: "I-notify ang engineer kung ang input drift ay lumampas sa X", "Auto roll back kung ang rate ng error ay lumampas sa Y." Panatilihing makabuluhan ang mga alarm — masyadong maraming maling alarma ang nagpapa-desensitize sa team at nawalan sila ng tunay na alarma.
tatlong mini case
Kaso 1 - Maagang babala. Ang tunay na katumpakan ng isang modelo ng forecast ng demand ay naging maliwanag lamang sa katapusan ng linggo. Sinusubaybayan ng team ang pamamahagi ng input at nakita ang biglaang pagtaas ng bagong kategorya ng produkto noong Martes — bagay na hindi pa nakikita ng modelo. In-update nila ang modelo nang hindi naghihintay ng pagbaba ng katumpakan. Na-save na araw ang pagsubaybay sa input.
Case 2 - Hindi na-verify na referee. Iniulat ng isang team na "mahusay ang aming kalidad" batay sa LLM-reviewer. Nang tumaas ang mga reklamo ng customer, ipinakilala ang pagsubaybay ng tao: itinuring ng referee ang tiwala ngunit hindi tamang mga sagot bilang "mabuti." Kapag na-calibrate ang referee gamit ang mga human tag, ang tunay na kalidad ay nahayag at mas mababa. Aral: huwag magtiwala sa referee nang hindi ito bini-verify.
Kaso 3 - Pagsusuri ng regression. Nalutas ng isang agarang pagbabago ang isang isyu habang tahimik na sinira ang isa pa. Ngunit ang koponan ay pinanatili ang mga nakalipas na mga bug sa eval bucket; Nang masuri ang bagong pagbabago sa cluster na ito, agad na nahuli ang sirang case at naayos ang pagbabago. Aralin: ang bawat naayos na bug ay dapat maging isang permanenteng kaso ng pagsubok.
Mga nakopyang template
Gumawa ng plano sa pagsubaybay para sa modelong ito ng produksyon. Saklaw ang tatlong layer:1) Operasyon (latency, error rate, volume)2) Input/data (distribution shift, nawawalang value, bagong kategorya)3) Model/output (prediction distribution, confidence, accuracy if possible)Model: [description]. Gaano katagal bago dumating ang aktwal na resulta: [duration]Magdagdag ng threshold at rekomendasyon ng interbensyon para sa bawat sukatan.
Magmungkahi ng diskarte sa pagsusuri (eval) para sa LLM system na ito.Gawain: [paglalarawan]Tukuyin ang mga layer:- Aling mga pagsusuring nakabatay sa panuntunan ang dapat tumakbo sa bawat output?- Anong pamantayan ang dapat suriin ng LLM-arbitrator at paano dapat i-validate ang mga ito (human anchor)?- Saang sample dapat isagawa ang pagsusuri ng tao? Ilista ang gilid at mga kaso ng kaligtasan na dapat kong ilagay sa eval set.
Suriin itong LLM-referee prompt:- Malinaw ba o subjective ang pamantayan sa pagsusuri?- Mahilig ba sa haba/confidence bias?- Paano ko i-calibrate ang referee gamit ang mga human tag? Referee prompt: [prompt]
Sumulat ng runbook ng tugon para sa alarma sa pagsubaybay na ito. Alarm: [hal. lumampas ang input drift threshold]Dapat maglaman ng: mga paunang hakbang sa pagkontrol, mga posibleng dahilan, pamantayan ng rollback, kung sino ang dapat ipaalam.
Pagkasira sanhi ng talahanayan
pagbaluktot
sintomas
Paraan sa maagang pagtuklas
data drift
Mga pagbabago sa pamamahagi ng input
Pagsubaybay sa pamamahagi ng input
paglilipat ng konsepto
Ang katuwiran ay nahuhulog nang tahimik
Hula + aktwal na paghahambing
upstream error
Nagiging bakante/mga pagbabago sa format ang mga field
Pagpapatunay ng schema + nawawalang rate
Hindi pagkakapare-pareho ng modelo
Mga pagbabago sa pamamahagi ng output
Pagsubaybay sa pamamahagi ng output
Mga karaniwang pagkakamali
- Hindi nagtatatag ng pagsubaybay. Ang modelo ay nasira nang tahimik, walang nakakakita nito.
- Subaybayan ang mga sukatan ng pagpapatakbo lamang. Nakaayos na ang sistema, ngunit maaaring mali ang mga hula.
- Paggamit ng LLM nang hindi bini-verify ang referee. Nagbibigay ito ng maling pagtitiwala.
- Eval na may madaling halimbawa. Hindi ito nagpapahiwatig ng tunay na kahirapan.
- Hindi kasama ang mga nakaraang error sa eval. Ang parehong error ay bumalik muli.
- Malakas na alarma. Ang koponan ay nagiging desensitized, nawawala ang tunay na alarma.
Sa buod
Ang modelo ay maaaring hindi tumpak nang hindi nagiging sanhi ng mga error sa produksyon; kaya ang eval at pagsubaybay ay kasinghalaga ng pag-unlad. Magtatag ng pagsubaybay sa tatlong layer (operational, input, output); Gamitin ang input drift bilang isang maagang babala kung ang aktwal na resulta ay naantala. Sa mga sistema ng LLM, ang eval ay bukas; Gamitin ang mga pagsusuri sa panuntunan, LLM-referee, at pagsusuri ng tao nang magkasama — ngunit tiyaking patunayan ang LLM-referee gamit ang isang anchor ng tao. Pagyamanin ang iyong Eval cluster na may mga edge at security cases at gawing permanenteng test case ang bawat nahuli na error.
Gawain ng aplikasyon
Sumulat ng tatlong-layer na plano sa pagsubaybay para sa isang modelo ng produksyon (o malapit sa produksyon) at tukuyin ang threshold + alarm para sa hindi bababa sa isang sukatan ng pamamahagi ng input. Kung mayroon kang LLM system: mag-tag ng 30 output sa mga tao, magpatakbo ng LLM-referee sa parehong mga output, at sukatin ang kasunduan ng human-referee; Pansinin ang sistematikong bias ng referee. Magdagdag ng kahit man lang 3 gilid at 2 kaso ng seguridad sa iyong eval cluster.
checklist
- [ ] Sinasaklaw ng pagsubaybay ang lahat ng tatlong layer (operational, input, output).
- [ ] Gumagamit ako ng input drift bilang isang maagang babala kung ang aktwal na resulta ay naantala.
- [ ] Na-calibrate ko ang LLM-arbitrator na may mga label ng tao.
- [ ] Ang Eval cluster ay naglalaman ng mga edge at security cases.
- [ ] Ginawa kong permanenteng test case ang bawat bug na nahuli ko.
- [ ] Ang bawat mahalagang sukatan ay may hangganan at plano ng pagtugon.