Ang pagpapatakbo ng agent ay hanya ang unang hakbang.May-akda ng artikulo: elune
Ipinagsasalin ng artikulo, pinagkukunan: ME News
Ang pagpapatakbo ng agent ay hanya ang unang hakbang.
Ang totoong hirap ay masukat: kung ito ay matatag, kung ito ay tama, o kung ito ay bumaba nang tahimik dahil sa isang prompt o pag-update ng modelo.
Ang mga sumusunod na 10 paraan ng pagtataya, dapat malaman ng bawat AI engineer.
1. Golden Set
Handa ang isang set ng mga fixed at frozen test case.
Pagkatapos ng bawat pagbabago sa prompt, model, tool, o workflow, i-re-run ang set ng mga kaso upang masukat kung ang sistema ay nagiging mas mabuti o kung may mga sitwasyon kung saan ito ay nagkakaroon ng pagkabigo nang tahimik.
Ito ay ang pinakabasehan sa sistema ng pagtataya ng Agent.
Mga rekomendadong kasangkapan: OpenAI Evals
Gagamitin upang buuin ang isang set ng benchmark na maaaring i-run muli, at ihambing ang performance ng iba’t ibang modelo o bersyon ng sistema.
2. LLM Judge | LLM bilang Hukom
Gumamit ng ibang malaking language model upang husgahan ang mga bukas na sagot batay sa naka-una naisulat na mga pamantayan.
Lalo itong epektibo kapag ang gawain ay walang iisang tamang sagot at hindi maaaring masuri ang tama o mali sa pamamagitan ng pagkakasunod-sunod ng mga string o fixed output.
Halimbawa, maaaring gamitin ang model na nagtataya upang suriin kung ang sagot ay tama, kompletong, may kaugnayan, at sumusunod sa mga hiling ng user.
Mga inirerekomenda: OpenEvals
Magbigay ng mga handa na evaluator para sa LLM applications, upang mabilis na itayo ang automated review process.
3. Maraming dimensyon na pagmamarka | Rubric Scoring
Huwag magbigay ng isang pangkalahatang “score ng kalidad” lamang sa Agent.
Dapat isa-isang paghuhusgaan:
- Kakamtin
- Integrity
- Expression style
- Security
- Response time
- Cost ng pagtawag
Isang komprehensibong marka ay maaaring magtago ng tunay na problema.
Halimbawa, ang pagbaba ng kabuuang puntos ay hindi kasalungat ng maling sagot, kundi maaaring dahil sa biglaang pagtaas ng gastos sa pagtawag ng kasangkapan; ang pagtaas ng kabuuang puntos ay maaari ring batay sa pagbaba ng kaligtasan.
Mga inirerekomenda: DeepEval
Sumasupport sa paglikha ng custom indicators at sa pagbibigay ng independiyenteng rating sa iba’t ibang aspeto ng kalidad.
4. Pagtataya ng Trajectory | Trajectory Eval
Huwag lamang isusuri ang huling sagot na ibinigay ng Agent, kundi ang buong proseso nito sa pagkumpleto ng gawain.
Kasama ang:
- Tama ba ang napiling kasangkapan?
- Tama ba ang pagkakasunod-sunod ng paggamit ng mga kasangkapan?
- May pag-uulit ba ng hindi epektibong aksyon?
- Nawawala ba ang kailangang hakbang?
- Tama ba ang pag-adjust ng desisyon batay sa resulta ng kasangkapan?
Ang agent ay maaaring makamit ang tamang sagot sa huli, ngunit ang intermediate process ay maaaring maging hindi epektibo, mahina, o kahit na may panganib.
Mga inirerekomendang kasangkapan: AgentEvals
Maaaring i-check ang mga aksyon, desisyon, at pagtawag sa mga kasangkapan ng Agent sa buong trahektorya ng pagpapatupad.
5. Mga Pagsusulit sa Unit ng Kasangkapan | Tool Unit Tests
Isulat ang hiwalay na pagsubok para sa bawat kasangkapan na ginagamit ng Agent.
Gumamit ng fixed input, i-verify ang fixed output, huwag pahintulutan ang model na makilahok.
Maaari itong hatiin ang problema:
Saan ba nanggaling ang problema—sa pag-iisip ng Agent, o sa mga panao, interface, o MCP Server na base?
Kailangan muna siguraduhin na ang kasangkapan ay kapani-paniwala bago masukat kung tama ang paggamit nito ng Agent.
Mga rekomendadong kasangkapan: MCP Inspector
Gagamitin para sa pagsusuri at pagsubok ng MCP Server, mga parametrong kasangkapan, at mga resultang ibinabalik.
6. Regression Suite
I-save ang mga nakaraang totoong runtime case, at i-re-run ito pagkatapos ng bawat pag-update sa prompt, model, o toolset.
Pagkatapos ay ihambing ang mga resulta ng bagong at lumang bersyon, suriin:
- Nabigo ba ang orihinal na tamang gawain?
- Nagbago ba ang output format?
- Nagdagdag ba ang paggamit ng mga kasangkapan?
- Bumaba ba ang delay at gastos
- Kumakasalang ba ang ilang edge cases?
Mas mabuting average performance ng bagong bersyon, hindi ibig sabihin na ito ay hindi nagpabagabag sa mga lumang kakayahan.
Mga inirerekomendang kasangkapan: Promptfoo
Suporta ang pagpapatakbo ng isang maaaring ulitin na suite ng pagsusuri, pagkuha ng regression issues, at pagkonekta sa CI ang proseso ng pagsusuri.
7. A/B Testing sa Production
Ibahagi nang random ang tunay na trapiko ng user sa dalawang iba't ibang bersyon at ihambing ang kanilang pagganap sa tunay na kaligiran.
Maaaring subukan:
- Dalawang set ng prompt
- Dalawang modelo
- Dalawang Agent workflow
- Different tool combinations
- Mga iba’t ibang estratehiya sa pagpapalit
Ang mas mataas na offline score ay hindi nangangahulugan na mas mataas ang tagumpay ng user.
Ang tunay na mahalaga ay ang mga praktikal na resulta, tulad ng rate ng pagkumpleto ng gawain, rate ng pagtanggap ng user, rate ng conversion, rate ng pagkukuha ng tao, at rate ng paglutas ng problema.
Mga inirerekomendang kasangkapan: GrowthBook
Magbigay ng switch ng tampok, kontroladong eksperimento, at kakayahan sa pag-analisa ng produkto.
8. Pagsusuri ng tao | Human Review
Regular sampling of actual trading records, reviewed and scored by human reviewers.
Ang manual na pagsusuri ay hindi lamang nakakatuklas ng mga problema na naliligaw ng automated na pagtataya, kundi maaari rin itong gamitin para sa pagkalkula ng mga hurado ng LLM.
Kailangang suriin nang mabuti:
- Kasunduan ba ng评分 ng model sa pagtataya ng tao?
- Sapat ba ang clarity ng mga pamantayan sa pagmamarka?
- Nakikilala ba ng modelong panghukom ang mas mahabang sagot?
- Automatically evaluate if any critical errors are missed
Hindi maaaring ganap na palitan ng automated assessment ang tao na pagtataya.
Mga inirerekomendang kasangkapan: Argilla
Tulungan ang team na kumalap ng manu-manong feedback, suriin ang mga output ng modelo, at i-convert ang mga resulta bilang mataas na kalidad na dataset.
9. Shadow Run
Irun ang candidate version sa tunay na trapiko, ngunit huwag ipakita ang output nito sa mga user.
Ang lumang bersyon ay patuloy na ginagamit sa production habang ang bagong bersyon ay ginagamit lamang sa backend para ihambing ang kanilang performance.
Ang paraang ito ay angkop para sa mga mataas na panganib na pag-update, tulad ng:
- Palitan ang pangunahang modelo
- I-rerewrite ang system prompt
- Magdagdag ng mga bagong panlabas na kasangkapan
- I-edit ang lohika ng pagdedesisyon ng Agent
- Palawakin ang mga pahintulot ng kasangkapan
Ang shadow running ay nakakatulong sa mga team na makahanap ng mga problema sa tunay na trapiko bago ang opisyal na paglalabas, habang iiwasan ang direkta epekto sa mga user.
Mga inirerekomendang kasangkapan: Langfuse
Masusuri ang produksyon, ihambing ang mga kandidatong bersyon, at subaybayan ang mga resulta ng pagtataya.
10. Red Teaming
Magsagawa ng aktibong pag-atake sa sarili mong sistema bago ang attacker.
Ang sakop ng pagsubok ay kasama ang:
- Escape attack
- Prompt injection
- Leak ng sensitibong data
- Bypass ng pahintulot
- Pang-abuso ng kasangkapan
- Malignant file or webpage content
- Hindi inaasahang panlabas na pagkilos
Mahalaga ang red team testing para sa mga Agent na makakapag-call ng database, magpapadala ng email, baguhin ang mga file, patakbuhin ang code, o makakapag-access sa mga internal na sistema.
Mga inirerekomendang kasangkapan: Garak
Makakascan ng mga butas sa kaligtasan at hindi ligtas na pag-uugali sa LLM system.
Ang offline evaluation ay nagpapakita na ang sistema ay gumagana nang maayos sa test environment.
Ang online assessment ay nagpapakita na ang sistema ay patuloy na gumagana pagkatapos ng paglunsad.
Hindi mo kailangang magtatag ng lahat ng 10 na mekanismo ng pagtataya nang sabay-sabay.
Mas praktikal na paraan ay:
Iwasan ang huling pagkabigo ng Agent, at priorahin ang pag-deploy ng dalawang paraan ng pagsusuri na maaaring makatulong na masukat ang problema nang maaga.
Kadalasan, maiiwasan ang malaking bilang ng simpleng insidente kung ikokompara muna ang golden test set, tapos ay idadagdag ang regression test o manual inspection.
Kapaki-pakinabang na i-save.