Loop អន់ផ្ញើកូដអន់លឿនជាង៖ Evals គឺជាវិន័យពិតប្រាកដ

នេះជាប្រយោគដែលគួរតែបិទនៅពីលើតុរបស់ក្រុមសរសេរកូដ agent គ្រប់ក្រុម៖ loop អន់ផ្ញើកូដអន់លឿនជាង។ យើងបានសរសេរវាជាលើកដំបូងដោយឆ្លងកាត់នៅក្នុង ការរចនា Agent Loop ដែលដំណើរការខណៈអ្នកដេក ហើយវាកាន់តែពិតឡើងៗ។ ឧស្សាហកម្មទាំងមូលកំពុងបង្កើនប្រសិទ្ធភាពសម្រាប់ភាពស្វយ័ត — ការដំណើរការវែងជាង agent ស្របគ្នាច្រើនជាង ការឃ្លាំមើលដោយមនុស្សតិចជាង។ មនុស្សតិចជាងច្រើនកំពុងបង្កើនប្រសិទ្ធភាពសម្រាប់រឿងដែលពិតជាសម្រេចថា តើភាពស្វយ័តជាទ្រព្យសម្បត្តិ ឬជាបន្ទុក៖ ការផ្ទៀងផ្ទាត់។

តក្កវិជ្ជានេះមិនអនុគ្រោះទេ។ នៅពេលដែល agent អាចផលិតកូដបានថោក ស្របគ្នា ពេញមួយយប់ ការផលិតលែងជាឧបសគ្គទៀតហើយ។ ដូចដែលយើងបាននិយាយនៅក្នុង The Code Agent Orchestra ថា “ឧបសគ្គលែងជាការផលិតទៀតហើយ វាជាការផ្ទៀងផ្ទាត់។” ហើយ generator លឿនមួយដែលត្រូវបានភ្ជាប់ទៅ verifier ខ្សោយមួយ មិនមែនជាម៉ាស៊ីនបង្កើនផលិតភាពទេ — វាជាម៉ាស៊ីនសម្រាប់ផលិតកំហុសដែលមើលទៅគួរឱ្យជឿ ក្នុងល្បឿនមួយដែលគ្មានមនុស្សណាអាចពិនិត្យបាន។ Loop កាន់តែលឿន ច្រកកាន់តែសំខាន់។ អត្ថបទនេះនិយាយអំពីច្រកនោះ។

ច្រកផ្ទៀងផ្ទាត់ និងហេតុអ្វីវាត្រូវតែមកមុនគេ

Agentic loop គ្រប់ loop មានពេលមួយដែលវាសម្រេចថា “ការងារនេះបានបញ្ចប់ហើយ”។ ការសម្រេចចិត្តនោះគឺជាច្រកផ្ទៀងផ្ទាត់ ហើយវាអាចត្រូវបានសាងសង់ពីសម្ភារៈជាច្រើន៖ tests, linters, type checks, security scans, golden dataset មួយ ឬ reviewer model ឯករាជ្យមួយ។ គុណភាពនៃច្រកនោះ គឺនិយាយ ឱ្យត្រង់ ជាគុណភាពនៃអ្វីៗគ្រប់យ៉ាងដែល loop ផ្ញើ។

កំហុសដែលកើតមានញឹកញាប់បំផុត — និងថ្លៃបំផុត — គឺការទុកឱ្យ loop ដំណើរការមុនពេលច្រកអាចទុកចិត្តបាន។ វាមើលទៅដូចជាការរីកចម្រើន៖ agent រវល់ diffs កំពុងចូលជាធរមាន backlog កំពុងតូចទៅៗ។ ប៉ុន្តែបើច្រកមិនអាចបែងចែកត្រឹមត្រូវ ពីខុសបានដោយជឿទុកចិត្ត ល្បឿនទាំងអស់នោះត្រូវបានដាក់ទិសដៅចៃដន្យ។ អ្នកមិនកំពុងផ្ញើលឿនជាងទេ អ្នកកំពុងប្រមូលផ្ដុំការងារខុសលឿនជាង ហើយរកឃើញវាក្រោយ នៅពេលដែលការស្រាយវាចេញវិញថ្លៃជាង។ សាងសង់ច្រក មុន ពេលអ្នកបើក throttle មិនមែនក្រោយទេ។

នេះភ្ជាប់ដោយផ្ទាល់ទៅនឹងគំនិតពីរដែលយើងបានអះអាងនៅកន្លែងផ្សេង។ វាជាព្រំដែន maker/checker ដូចគ្នាពី របៀបដែល agent ពិតជាវែកញែក — បំបែក model ដែល សរសេរ ចេញពីអ្វីដែល ពិនិត្យ — ដែលត្រូវបានពង្រីកឡើងដើម្បីគ្រប់គ្រង pipeline ទាំងមូល។ ហើយវាជាហានិភ័យលាក់ខ្លួននៅក្នុង harness ដែលកែខ្លួនឯង៖ agent ដែលបង្កើនប្រសិទ្ធភាពខ្លួនវាប្រឆាំងនឹង eval អន់មួយ មិនកាន់តែប្រសើរទេ វា កាន់តែខុសដោយជឿជាក់ លឿនជាង។ Eval គឺជារឿងដែលអ្វីៗគ្រប់យ៉ាងផ្សេងទៀតកំពុងតម្រង់ទៅរក។ បើវាចង្អុលខុសទិស កម្លាំងសេះច្រើនជាងគ្រាន់តែធ្វើឱ្យឈឺចាប់។

Evals គឺជា test suite ថ្មី

អស់រយៈពេលជាច្រើនទសវត្សរ៍ artifact ដែលអ៊ិនកូដ “តើនេះត្រឹមត្រូវឬ?” គឺជា test suite។ នៅយុគសម័យ agentic វា artifact នោះគឺ eval — ហើយឆ្នាំ ២០២៦ បានប្រែការរចនា eval ឱ្យក្លាយជាវិន័យដោយខ្លួនឯង។ រូបរាងដែលកំពុងលេចចេញនៅលើក្រុមដ៏ធ្ងន់ធ្ងរមើលទៅដូចនេះ៖

• Golden dataset មួយ ដែលដកស្រង់ចេញពីភាពបរាជ័យពិតប្រាកដ។ មិនមែនជាករណីសិប្បនិម្មិតលេងសើចទេ — ជាសំណុំដែលត្រូវបានរៀបចំ ដែលសាងសង់ឡើងពីរបៀបពិតប្រាកដដែលប្រព័ន្ធរបស់អ្នកបានដំណើរការខុសក្នុងផលិតកម្ម។ ប្រវត្តិឧប្បត្តិហេតុរបស់អ្នកគឺជាសម្ភារៈ eval ដ៏មានតម្លៃបំផុតរបស់អ្នក។
• ការលាយ scorers ដែលឋិតិវន្ត និងផ្អែកលើការវិនិច្ឆ័យ។ ការត្រួតពិនិត្យថោក ត្រឹមត្រូវ (តើវា compile ឬ tests ជោគជ័យឬ output មានទ្រង់ទ្រាយល្អឬ) ចាប់ភាពបរាជ័យមេកានិច ឯ judge ផ្អែកលើ LLM ចាប់ភាពបរាជ័យអត្ថន័យដែល regex មិនដែលអាចចាប់បាន។
• Judge មួយ ដែលត្រូវបាន calibrate ប្រឆាំងនឹង reviewer ជាមនុស្ស។ LLM-as-judge អាចទុកចិត្តបានត្រឹមកម្រិតដែលវាយល់ស្របជាមួយមនុស្សដែលអ្នកទុកចិត្ត។ Calibration មិនមែនជាជម្រើសទេ — judge ដែលមិនបាន calibrate គ្រាន់តែជាអ្នកស្មានដ៏ជឿជាក់ម្នាក់ទៀតប៉ុណ្ណោះ។
• CI gate មួយ ដែលរារាំង regressions។ Eval ដំណើរការនៅរាល់ការផ្លាស់ប្ដូរ ហើយ បញ្ឈប់ ការផ្លាស់ប្ដូរទាំងឡាយដែលធ្វើឱ្យអ្វីៗកាន់តែអាក្រក់។ នេះជាអ្វីដែលប្រែ evals ពី dashboard ដែលអ្នកមើលឆ្លងកាត់ ឱ្យក្លាយជាច្រកដែលពិតជាទប់បាន។

ក្រុមដែលសាងសង់រឿងនេះ — កម្មវិធី eval ពិតប្រាកដមួយ ដែលមាន incident taxonomy, golden datasets, ការលាយ scorer ឋិតិវន្ត-បូក-judge និង CI regression gates — ទទួលបានគុណសម្បត្តិគុណភាព ជារចនាសម្ព័ន្ធ។ មិនមែន demo លឿនជាងទេ ប៉ុន្តែជាប្រព័ន្ធដែលនៅគង់វង្សត្រឹមត្រូវ ខណៈវាពង្រីក។

ពី dashboard ទៅ runtime៖ agent-as-judge

ការវិវឌ្ឍន៍ឆ្នាំ ២០២៦ ពីរ ជំរុញរឿងនេះឱ្យឆ្ងាយជាងនេះ ហើយទាំងពីរសមនឹងដឹង។ ទីមួយគឺ eval-driven development ដែល evals មុនផលិតកម្ម មិនត្រឹមតែរស់នៅក្នុង CI ប៉ុណ្ណោះទេ — ពួកវាប្រែទៅជា runtime guardrails។ ពិន្ទុ eval ចាប់ផ្ដើមគ្រប់គ្រងថា agent ត្រូវបានអនុញ្ញាតឱ្យធ្វើអ្វីខ្លះ៖ ឧបករណ៍ណាដែលវាអាចហៅ ពេលណាដែលវាត្រូវតែបញ្ជូនបន្តទៅមនុស្ស តើសកម្មភាពមួយផ្ញើឬអត់។ Eval លែងជា report card ហើយក្លាយជាការគ្រប់គ្រងសកម្មនៅក្នុង loop សម្រេចចិត្ត — ស្រទាប់ guardrail ដែលត្រូវបានចិញ្ចឹមដោយការវាស់វែងផ្ទាល់។

ទីពីរគឺ agent-as-judge។ ជំនួសឱ្យការដាក់ពិន្ទុតែ output ចុងក្រោយ judge-agent ស្វយ័តមួយ សង្កេតមើល ជំហានកណ្ដាល — វាអាន action log ប្រើឧបករណ៍ ហើយវែកញែកអំពី trajectory ខណៈ worker agent កំពុងដំណើរការ។ វាអាចចង្អុលបង្ហាញថា តម្រូវការណាដែលត្រូវបានខកខាន និងជំហានណាដែលដំណើរការខុស មិនមែនត្រឹមតែថាលទ្ធផលចុងក្រោយបរាជ័យទេ។ នៅពេលដែល agent ទទួលយកភារកិច្ចវែងជាង ច្រើនជំហានជាង ការវិនិច្ឆ័យដំណើរ ជាជាងគ្រាន់តែទិសដៅ គឺជារបៀបដែលអ្នកចាប់កំហុសនៅជំហានទី ៣ ជំនួសឱ្យការបង់ថ្លៃវានៅជំហានទី ៣០។ លំនាំនេះផ្គូផ្គង evaluator ដែលត្រូវបាន distill ថោក ដែលដំណើរការជាបន្តបន្ទាប់ ជាមួយ agent-judge ធ្ងន់ជាងដែលត្រូវបានហៅដោយជ្រើសរើស សម្រាប់ការផ្ទៀងផ្ទាត់ស៊ីជម្រៅ — លឿន និងហ្មត់ចត់ ដោយមិនបង់ថ្លៃ ឱ្យហ្មត់ចត់នៅរាល់ការហៅ។

ហេតុអ្វីនេះជាការងារដែលមានឥទ្ធិពលលើកខ្ពស់បំផុតនៅក្នុងតំបន់

វាងាយស្រួលក្នុងការអាន “evals” ជាការតម្លើងបំពង់ទឹកគ្មានភាពទាក់ទាញ។ វាគឺផ្ទុយស្រឡះ — វាជាវិស្វកម្មដែលអាចការពារបានបំផុត អាចកាន់កាប់បានបំផុត ដែលមាននៅពេលនេះ ហើយវាត្រូវបានធ្វើរូបរាងសម្រាប់ចំណុចខ្លាំងរបស់អាស៊ីអាគ្នេយ៍។

នេះជាមូលហេតុ។ Eval អ៊ិនកូដ អ្វីដែលត្រឹមត្រូវមានន័យសម្រាប់បញ្ហារបស់អ្នក — ហើយនោះជារឿងក្នុងស្រុកដែលមិនអាចកាត់បន្ថយបាន។ Frontier lab មួយអាចប្រគល់ឱ្យអ្នកនូវ model ដ៏អស្ចារ្យ និង test harness ទូទៅមួយ។ វាមិនអាចប្រាប់អ្នកថា តើ invoice ភាសាខ្មែរ ត្រូវបាន parse ត្រឹមត្រូវឬ តើច្បាប់អនុលោមភាពកម្ពុជា ត្រូវបានបំពេញពិតប្រាកដឬ ឬថា “បញ្ចប់” មានន័យអ្វីសម្រាប់កំណត់ត្រារបស់សហករណ៍កសិកម្មនោះទេ។ ការវិនិច្ឆ័យនោះរស់នៅក្នុង golden dataset នៃភាពបរាជ័យពិតប្រាកដ របស់អ្នក និង judge ដែលត្រូវបាន calibrate ប្រឆាំងនឹង អ្នកជំនាញ domain របស់អ្នក។ វាត្រូវបានសាងសង់ពីចំណេះដឹងក្នុងស្រុក ហើយវាមិនអាចត្រូវបាននាំចូលបានឡើយ។ នេះជាសម្មតិកម្មដូចគ្នាទៅនឹង spec-driven development ដែលមើលពីម្ខាងទៀត៖ spec និយាយថាត្រូវសាងសង់អ្វី eval បង្ហាញថាវាត្រូវបានសាងសង់ត្រឹមត្រូវ ហើយទាំងពីរជាការងារសរសេរ-និង-វិនិច្ឆ័យ មិនមែនការចំណាយ GPU ទេ។

ហើយឥទ្ធិពលនេះកើនទ្វេ។ ក្រុមដែលកាន់កាប់ eval ដែលអាចទុកចិត្តបាន អាចបង្កើនភាពស្វយ័តដោយសុវត្ថិភាព — ដំណើរការ agent ច្រើនជាង វែងជាង ដោយការត្រួតពិនិត្យតិចជាង — ព្រោះច្រកចាប់អ្វីដែលរអិល។ ក្រុមដែលគ្មានវាមិនអាចទេ ទោះ model របស់វាល្អប៉ុណ្ណាក៏ដោយ។ Eval គឺជាអ្វីដែលអនុញ្ញាតឱ្យក្រុមតូចមួយ ដែលមានដើមទុនស្រាល នៅភ្នំពេញ ឬ Da Nang ពង្រីក output ដោយមិនពង្រីកហានិភ័យ។ វាជាសន្លឹកអនុញ្ញាតសម្រាប់អ្វីៗគ្រប់យ៉ាងផ្សេងទៀតនៅក្នុង agentic stack។

អ្វីដែលត្រូវយកពីរឿងនេះ

សាងសង់ច្រកមុនពេលអ្នកបើក throttle។ ចាប់ផ្ដើម golden dataset ពីឧប្បត្តិហេតុពិតប្រាកដរបស់អ្នកនៅថ្ងៃនេះ ទោះតូចមួយក៏បាន។ លាយការត្រួតពិនិត្យឋិតិវន្តថោកជាមួយ judge មួយ ហើយ calibrate judge ប្រឆាំងនឹងមនុស្សដែលអ្នកទុកចិត្ត។ ដាក់ eval នៅក្នុង CI ជាច្រកដែលរារាំង regressions រួចបញ្ចូលវាបន្តទៅជា runtime guardrail។ ហើយចាត់ទុក eval ជា artifact ឋានៈទីមួយ ដែលត្រូវបានកាន់កាប់ — ព្រោះវាអ៊ិនកូដនូវរឿងតែមួយដែល frontier lab មិនដែលអាចផ្ញើឱ្យអ្នកបាន៖ អ្វីដែលត្រឹមត្រូវមានន័យ នៅទីនេះ។

ការប្រណាំងដែលមនុស្សគ្រប់គ្នាមើលឃើញ គឺការប្រណាំងធ្វើឱ្យ agent ប្រព្រឹត្ត។ ការប្រណាំងដែលពិតជាសម្រេចអ្នកឈ្នះ គឺស្ងាត់ជាង៖ ការធ្វើឱ្យពួកវាប្រព្រឹត្ត ឱ្យបានត្រឹមត្រូវ ដែលអាចបញ្ជាក់បាន ក្នុងទ្រង់ទ្រាយធំ។ Loop អន់ផ្ញើកូដអន់លឿនជាង។ Eval ល្អ គឺជារបៀបដែលអ្នកធានាថា loop នោះជា loop ល្អមួយ។