May mga prompt ang iyong team na nakakalat sa codebase. Ang ilan ay nasa config file. Ang ilan ay mga hardcoded string. Ang ilang mga kritikal ay nakatira sa isang Google Doc na pinapanatili ng isang tao. Walang nakakaalala kung bakit ang prompt ng system para sa feature ng pagbubuod ay nagsasabing "tumugon bilang isang kapaki-pakinabang na British librarian" — ngunit ang pag-alis sa pariralang iyon ay nagpapalala ng output, kaya nananatili ito.
Ganito pinapamahalaan ng karamihan sa mga team ang mga prompt, at halos katumbas ito ng pagsulat ng code na walang kontrol sa bersyon noong 2005. Gumagana ito hanggang sa hindi ito gumana, at kapag huminto ito sa paggana, wala kang ideya kung ano ang nagbago o kung paano ito ayusin.
Ang maagap na engineering retrospective ay nagdadala ng parehong disiplina sa LLM na mga pakikipag-ugnayan na dinala ng engineering retrospective sa pagbuo ng software: sistematikong pagsusuri, nakabahaging pag-aaral, at incremental na pagpapabuti. Narito kung paano ito aktwal na gawin.
Ang Problema sa Ad-Hoc Prompting
Karamihan sa mga team ay bumuo ng mga prompt sa pamamagitan ng isang cycle na ganito ang hitsura: may sumulat ng prompt, sumubok ito laban sa ilang mga halimbawa, ipinadala ito, at nagpapatuloy. Kapag bumababa ang kalidad ng output o may lumabas na bagong failure mode, may nag-aayos ng prompt batay sa partikular na kaso ng bagsak, maaaring masira ang tatlong iba pang mga kaso sa proseso, at mauulit ang ikot.
Ang mga isyu sa tambalang ito ng diskarte:
Walang kasaysayan. Kapag binago mo ang isang prompt, wala na ang lumang bersyon. Kung ang bagong bersyon ay mas masahol pa, hindi mo madaling maibalik. Kung may magtatanong ng "bakit sinasabi ito ng prompt?", walang nakakaalam.
Walang nakabahaging pag-aaral. Ang taong nakaisip na ang pagdaragdag ng "mag-isip nang hakbang-hakbang" sa prompt ng pangangatuwiran ay nagpabuti ng katumpakan sa pamamagitan ng isang kapansin-pansing margin ay hindi nagbabahagi ng pananaw na iyon. Ang taong sumulat ng susunod na prompt ay natututo ng parehong aral mula sa simula.
Walang sistematikong pagsubok. Nasusuri ang mga prompt laban sa anumang mga halimbawang naiisip, na kadalasan ay ang mga madaling kaso. Ang mga Edge case, adversarial input, at distribution shift ay hindi nasusubok hanggang sa mabigo ang mga ito sa produksyon.
Walang pagsukat. "Mukhang mas maganda ang output" ay ang pinakakaraniwang paraan ng pagsusuri. Mas mabuti kung paano? Kung ikukumpara sa ano? Sinusukat kanino? Kung walang pare-parehong pagsusuri, hindi mo malalaman kung ang mga pagbabago ay talagang mga pagpapabuti.
Ang isang regular na prompt retrospective ay tumutugon sa lahat ng apat na problemang ito.
Ano ang Ire-review sa isang Prompt Retrospective
Kolektahin ang Iyong Ebidensya
Bago ang retrospective, tipunin ang:
Mga pagkabigo sa produksyon. Anumang pagkakataon kung saan ang isang feature na pinapagana ng LLM ay gumawa ng masamang output na napansin ng isang user. Kunin ang input, ang prompt, at ang output. Kung mayroon kang feedback ng user (thumbs down, reklamo, pagwawasto), isama iyon.
Mga agarang pagbabago mula noong huling retro. Anong mga senyas ang nagbago, ano ang layunin sa likod ng pagbabago, at ano ang nangyari pagkatapos? Kung kinokontrol mo ang bersyon ng iyong mga prompt (dapat ikaw), isa itong diff review. Kung hindi ka, ito ang unang item ng pagkilos mula sa iyong retro.
Mga trend ng sukatan ng kalidad. Kung nagpapatakbo ka ng mga awtomatikong pagsusuri (higit pa dito sa ibaba), dalhin ang mga trend. Bumubuti ba ang mga bagay? Lumalala? Patag?
Data ng gastos at latency. Direktang nakakaapekto sa pareho ang mga prompt. Ang isang verbose system prompt na nagpapahusay ng kalidad sa maliit na margin ngunit nagdodoble sa iyong paggamit ng token ay isang tradeoff na dapat tahasang talakayin.
Ang Pag-uusap
Ang isang magandang prompt retrospective ay sumasaklaw sa tatlong tanong:
1. Saan nabigo ang aming mga prompt, at bakit?
Uriin ang iyong mga pagkabigo. Mga karaniwang kategorya:
- Sumusunod na tagubilin: Hindi ginawa ng modelo ang hiniling ng prompt. Karaniwang nangangahulugan na ang pagtuturo ay hindi maliwanag o sumasalungat sa isa pang bahagi ng prompt.
- Mga paglabag sa format: Ibinalik ng modelo ang JSON kapag gusto mo ng plain text, o vice versa. Karaniwang naaayos na may mas malinaw na mga detalye ng format at mga halimbawa.
- Hallucination: Ang modelo ay nakabuo ng impormasyon na hindi sinusuportahan ng ibinigay na konteksto. Maaaring ito ay isang agarang isyu (mahinang mga tagubilin sa saligan) o isang limitasyon ng modelo.
- Tone/style drift: Iba ang tunog ng output kaysa sa nilalayon. Kadalasang nangyayari kapag mahaba ang mga senyas at nabaon ang mga tagubilin sa istilo.
- Mga pagkabigo sa gilid ng case: Gumagana ang prompt para sa mga karaniwang input ngunit nasira sa mga hindi pangkaraniwang input. Dito pinakamasakit ang kawalan ng sistematikong pagsubok.
Para sa bawat kategorya ng pagkabigo, itanong: ito ba ay isang agarang problema, isang problema sa modelo, o isang problema sa pag-input? Ang pag-aayos ay iba para sa bawat isa.
2. Ano ang natutunan natin tungkol sa pag-udyok sa modelong ito?
Ang bawat modelo ay may mga kakaiba. Iba ang tugon ng GPT-4 sa parehong prompt kaysa kay Claude, at pareho silang nagbabago ng gawi sa mga update. Ang iyong team ay nag-iipon ng kaalaman tungkol sa mga kakaibang ito sa pamamagitan ng pang-araw-araw na gawain — ang ⟦RETRO⟧ ay kung saan ang kaalaman ay ibinabahagi at naidokumento.
Mga kapaki-pakinabang na bagay na kukunan:
- Mga diskarteng mapagkakatiwalaang nagpapabuti sa output (at para sa kung aling mga uri ng mga gawain)
- Mga diskarte na tila dapat gumana ngunit hindi
- Mga pagbabago sa gawi ng modelo pagkatapos ng mga update ng provider
- Mga pattern ng pag-prompt na gumagana nang maayos para sa iyong partikular na mga kaso ng paggamit
Gumagawa ito ng isang base ng kaalaman ng pangkat na pumipigil sa lahat sa muling pagtuklas ng parehong mga aralin.
3. Ano ang susunod na dapat nating baguhin o subukan?
Batay sa mga pagkabigo at natutunan, tukuyin ang mga partikular na eksperimento. Ang magagandang eksperimento ay:
- Makitid ang saklaw (baguhin ang isang bagay sa isang pagkakataon)
- Masusukat (tukuyin kung ano ang ibig sabihin ng "mas mahusay" bago mo subukan)
- Time-boxed (tumatakbo para sa isang partikular na panahon o bilang ng mga pagsusuri)
Halimbawa: "Susubukan namin kung ang pagdaragdag ng dalawang halimbawa ng gustong format ng output sa prompt ng serbisyo sa customer ay binabawasan ang mga paglabag sa format mula 12% hanggang 5%, na nasusukat sa mahigit 200 query sa produksyon."
Pagbuo ng Maagap na Kasanayan sa Pamamahala
⟦RETROSC⟧ ay mas epektibo kapag mayroon kang pangunahing agarang pamamahala sa lugar. Hindi mo kailangan ng magarbong tooling para magsimula — ilang mga kasanayan lang.
Kontrolin ng Bersyon ang Iyong Mga Prompt
Itrato ang mga prompt tulad ng code. I-store ang mga ito sa iyong repository, suriin ang mga pagbabago sa mga PR, at mga bersyon ng tag. Nagbibigay ito sa iyo ng kasaysayan, kakayahang mag-rollback, at pangangasiwa sa pagsusuri. Kung ang isang mabilis na pagbabago ay nagpapababa ng kalidad, makikita mo kung ano mismo ang nagbago at ibabalik ito.
Para sa mga team na may maraming senyas, isaalang-alang ang isang nakalaang istraktura ng direktoryo:
mga senyas/
pagbubuod/
system.txt
few-shot-examples.json
serbisyo sa customer/
system.txt
escalation-rules.txt
klasipikasyon/
system.txt
label-definitions.json
Bumuo ng Set ng Pagsusuri
Para sa bawat pangunahing prompt, panatilihin ang isang hanay ng mga kaso ng pagsubok: mga pares ng input-output kung saan alam mo kung ano ang hitsura ng magandang output. Hindi ito kailangang maging napakalaki — 20-50 kaso bawat prompt na sumasaklaw sa karaniwang paggamit, mga gilid na kaso, at kilalang mga failure mode.
Patakbuhin ang iyong hanay ng pagsusuri sa tuwing babaguhin mo ang isang prompt. Nakakakuha ito ng mga regression bago sila umabot sa produksyon. Ito ay tumatagal ng oras upang mabuo sa simula, ngunit higit na nakakatipid ng oras kaysa sa pag-debug ng mga pagkabigo sa produksyon.
Idokumento ang Iyong mga Desisyon
Kapag gumawa ka ng agarang pagbabago, sumulat ng maikling tala: ano ang problema, ano ang binago mo, at bakit mo inaasahan na makakatulong ito. Ito ay parang overhead hanggang tatlong buwan mamaya kapag nakatitig ka sa isang prompt at nagtataka kung bakit kasama nito ang isang tila random na pagtuturo na lumalabas na kritikal.
I-prompt ang ⟦RETROC⟧ Mga Format na Gumagana
Hindi lahat ng retro ay kailangang pareho. Narito ang dalawang format na mahusay na gumagana sa magkaibang mga cadence:
Ang Mabilisang Pagsusuri (30 minuto, bi-lingguhan)
Para sa mga koponan na mabilis na umuulit. Suriin ang mga pagkabigo sa produksyon mula noong nakaraang session, talakayin ang anumang mga agarang pagbabagong ginawa, ibahagi ang bawat isa na nag-uudyok na insight, at piliin ang pinakamataas na priyoridad na eksperimento para sa susunod na dalawang linggo. Panatilihing mahigpit at nakatuon sa pagkilos.
Ang Deep Dive (90 minuto, buwanan)
Para kapag kailangan mong umatras at tingnan ang mas malaking larawan. Suriin ang mga sukatan at trend ng kalidad sa lahat ng prompt. Piliin ang prompt na pinakamasama ang pagganap at magsagawa ng masusing pagsusuri: maglakad sa mga pagkabigo, talakayin ang ugat na dahilan, mga diskarte sa brainstorming, at magdisenyo ng tamang eksperimento. Suriin din ang iyong maagap na library at dokumentasyon para sa pagkasira — mayroon bang anumang mga prompt na luma na o hindi na ginagamit?
Ang Pagsusuri ng Insidente (ad-hoc)
Kapag ang isang maagang pagkabigo ay nagdulot ng isang tunay na insidente na nakaharap sa user, gumawa ng isang nakatutok na pagsusuri sa loob ng ilang araw. Ano ang nangyari, bakit nabigo ang prompt, bakit hindi ito nakuha ng aming pagsubok, at ano ang idinaragdag namin sa aming hanay ng pagsusuri upang maiwasan ang klase ng pagkabigo?
Mga Karaniwang Pitfalls
Mga prompt ng over-engineering. Ang mas mahabang prompt ay hindi palaging mas mahusay. Ang bawat pagtuturo na iyong idaragdag ay maaaring makipag-ugnayan sa bawat iba pang pagtuturo sa mga hindi mahuhulaan na paraan. Kung ang iyong prompt ay higit sa 500 salita, isaalang-alang kung sinusubukan mong gumawa ng masyadong marami sa isang prompt at dapat itong hatiin sa isang chain.
Pag-optimize para sa maling sukatan. Ang isang prompt na nakakakuha ng mahusay na marka sa mga automated na sukatan ngunit gumagawa ng mga output na sa tingin ng mga user ay hindi nakakatulong ay hindi isang magandang prompt. Isama ang pagsusuri ng tao sa iyong proseso, hindi lamang ang awtomatikong pagmamarka.
Pagbabalewala sa gastos. Ang mga agarang pagpapahusay na nagdodoble sa iyong paggamit ng token ay maaaring hindi katumbas ng pakinabang ng kalidad. Subaybayan ang gastos sa bawat query kasama ng kalidad at tahasang gumawa ng mga tradeoff.
Pag-aayos ng mga sintomas sa halip na mga sanhi. Kung patuloy mong ita-patch ang parehong prompt para sa mga bagong failure mode, malamang na kailangan ng prompt ng muling disenyo sa halip na isa pang band-aid. Ipapakita ng iyong retrospective data ang pattern na ito — isang prompt na lumilitaw sa mga listahan ng pagkabigo sa maraming mga retro ay nangangailangan ng higit na pangunahing atensyon.
Hindi sumusubok gamit ang mga adversarial input. Gagawin ng iyong mga user ang mga bagay na hindi mo inaasahan. Ang iyong retrospective ay dapat na pana-panahong may kasamang pagsusuri sa kung ano ang mangyayari kapag ang prompt ay nakatanggap ng mga hindi pangkaraniwang, pagalit, o wala sa saklaw na mga input. Huwag maghintay para sa isang insidente ng produksyon upang matuklasan na ang iyong prompt ay walang mga guardrail.
Pagsisimula
Hindi mo kailangang ihanda ang lahat para magsimula. Narito ang kaunting unang hakbang:
- Piliin ang iyong pinakamahalagang feature na pinapagana ng LLM.
- Mangolekta ng 10 kamakailang pagkabigo (masamang output, reklamo ng user, anumang suboptimal).
- Gumugol ng 30 minuto sa pag-uuri ng iyong koponan kung bakit nabigo ang bawat isa.
- Tukuyin ang pinakakaraniwang pattern ng pagkabigo at magdisenyo ng isang eksperimento upang matugunan ito.
- Patakbuhin ang eksperimento at suriin ang mga resulta sa loob ng dalawang linggo.
Iyan ang iyong unang prompt retrospective. Gawin itong muli, at muli, at bubuo ka ng kalamnan. Ang mga koponan na may pinakamahusay na kalidad ng output ng AI ay hindi ang mga may pinakamatalinong senyas — sila ang mga sistematikong natututo mula sa kanilang mga pagkabigo at hindi kailanman gumawa ng parehong pagkakamali nang dalawang beses.
Subukan ang NextRetro libre — Pag-uri-uriin ang mga agarang pagkabigo sa mga kategorya, bumoto sa mga priyoridad, at subaybayan ang mga eksperimento sa pagpapahusay sa mga sprint.
Huling Na-update: Pebrero 2026
Oras ng Pagbasa: 7 minuto
