Leaderboard កុហកអំពី Agent របស់អ្នក
នេះជាលេខគួរឱ្យកត់សម្គាល់ពិតប្រាកដមួយ។ OSWorld — benchmark ដែលដាក់ agent ចូលក្នុង operating system ពិត ហើយសុំឱ្យវាធ្វើរបស់ពិតៗ៖ បើក app, click menu, កែ file, navigate GUI — បានបើកដំណើរការក្នុងឆ្នាំ ២០២៤ ដោយមនុស្សទទួលបាន 72.36% នៃ task ហើយ AI agent ល្អបំផុតធ្វើបានត្រឹម 12.24%។ គម្លាតប្រាំមួយដង គឺប្រភេទដែលនិយាយថា “មិនជិតទេ”។ ពីរឆ្នាំក្រោយ ប្រព័ន្ធ computer-use កំពូលៗលើ benchmark ដូចគ្នានោះ ត្រូវបានរាយការណ៍ថាកំពុងខិតជិត human baseline។ Agent បានឆ្លងពីគ្មានសង្ឃឹមទៅជិតកម្រិតមនុស្សក្នុងការដំណើរការកុំព្យូទ័រ ក្នុងរយៈពេលប្រហែលពីរឆ្នាំ។
នោះជា milestone ពិតប្រាកដ ហើយវាសមនឹងបានចំណងជើង។ វាក៏ពិតជាប្រភេទនៃលេខតែមួយដែលនឹងនាំអ្នកឱ្យយល់ច្រឡំ ប្រសិនបើអ្នកឱ្យវាធ្វើ — ព្រោះសម្រាប់ agent មួយ success rate ចុងក្រោយ ស្ទើរតែជារបស់ដែលមានប្រយោជន៍តិចបំផុតដែលអ្នកអាចដឹង។
ពី 12% ទៅជិតមនុស្ស ក្នុងពីរឆ្នាំ
យកការលោតផ្លោះសមត្ថភាពមកគិតយ៉ាងម៉ត់ចត់ជាមុនសិន ព្រោះវាស័ក្តិសម។ ការដំណើរការកុំព្យូទ័រតាមរបៀបដែលមនុស្សធ្វើ — យល់ឃើញ screen, សម្រេចថា click អ្វី, recover ពេល dialog box លេចឡើងកន្លែងដែលអ្នកមិនបានរំពឹង — គឺពិបាកពិតប្រាកដ ហើយការលោតពី 12.24% ទៅជិតមនុស្សលើ OSWorld តំណាងឱ្យវឌ្ឍនភាពពិតក្នុង perception, planning, និង tool use។ Computer-use agent កំពុងឆ្លងពី demo ទៅ deployable សម្រាប់ task មួយក្រុមកាន់តែទូលាយ។
ដូច្នេះការល្បួងច្បាស់ណាស់៖ អាន leaderboard យកពិន្ទុកំពូល ship agent នោះ។ ពិន្ទុបានឆ្លងបន្ទាត់មនុស្ស ប្រាកដជាមានន័យថាវារួចរាល់។ នេះជាកន្លែងដែលបញ្ហាចាប់ផ្ដើម ហើយ framework ឆ្នាំ ២០២៦ មួយពន្យល់ច្បាស់ថាហេតុអ្វី។
“Success rate” ជាលេខខុសសម្រាប់ agent
Framework នោះគឺ AgentAtlas (arXiv 2605.20530) ហើយការសង្កេតបើកដំបូងរបស់វាជាបញ្ហាទាំងមូល៖ agent “evaluations often collapse behavior into final task success”។ សម្រាប់ static model ដែលឆ្លើយសំណួរ final success ជាភាគច្រើននៃអ្វីដែលសំខាន់។ សម្រាប់ agent ដែលធ្វើ action ក្នុងពិភពលោក វាជាប្រភាគនៃអ្វីដែលសំខាន់ — ព្រោះ outcome ដូចគ្នាអាចទៅដល់ដោយ path ខុសគ្នាដ៏ខ្លាំង ហើយ path ជាកន្លែងដែលហានិភ័យរស់នៅ។
ស្រមៃ task “សម្អាត downloads folder របស់ខ្ញុំ”។ Agent ពីរទាំងពីរបញ្ចប់ ទាំងពីរទទួលពិន្ទុ 1.0។ ទីមួយអាន folder កំណត់សំរាមច្បាស់ៗ ផ្លាស់វាទៅ trash ហើយទុករបស់ដែលមិនច្បាស់ឱ្យនៅ។ ទីពីរ rm -rf folder ទាំងមូល ហើយ re-download file មួយចំនួនដែលវាអាច re-fetch — task បញ្ចប់ជាបច្ចេកទេស ឯកសារពន្ធរបស់អ្នកបាត់ជារៀងរហូត។ លើ leaderboard ដែលផ្អែកលើ outcome តែប៉ុណ្ណោះ agent ទាំងពីរនេះមិនអាចបែងចែកគ្នាបាន។ ក្នុង production ពួកវាមិនមែនជា product ដូចគ្នាសូម្បីបន្តិចទេ ហើយភាពខុសគ្នា — មើលឃើញតែក្នុង trajectory — ជាសំណួរទាំងមូលថាតើអ្នកអាចទុកចិត្តរបស់នោះបានឬអត់។
ចលនាស្នូលរបស់ AgentAtlas គឺ “separat[e] outcome success from control-decision quality and trajectory quality”។ Agent ពីរអាចទាំងពីរបញ្ចប់ task ហើយទទួលពិន្ទុដូចគ្នាលើ leaderboard ខណៈប្រព្រឹត្តខុសគ្នាទាំងស្រុងតាមផ្លូវ។ មួយសុំ confirmation មុនជំហានដែលមិនអាចត្រឡប់វិញ refuse ផ្នែកដែលនៅក្រៅ scope ហើយ recover ស្អាតពេលវាជួប error។ មួយទៀតបុកឆ្លងគ្រប់ prompt សំណាងល្អដែល click ដ៏ប្រហែសរបស់វាចៃដន្យចុះត្រូវ ហើយនឹងបានលុប file របស់អ្នកលើ run ខុសគ្នាបន្តិច។ ពិន្ទុដូចគ្នា។ របស់ខុសគ្នាដ៏ខ្លាំងដែលត្រូវ deploy។ Framework ដាក់ឈ្មោះវាជាមួយ vocabulary ប្រាំមួយ state សម្រាប់អ្វីដែល agent សម្រេចនៅជំហាននីមួយៗ — Act, Ask, Refuse, Stop, Confirm, Recover — ព្រោះ “តើវាជោគជ័យឬ?” មិនអាចបែងចែក agent ដែលដឹងពេលដែលត្រូវ ask ពីមួយដែលដឹងតែរបៀប act។
លេខ task-success ខ្ពស់ប្រាប់អ្នកថា agent អាចទៅដល់គោលដៅ។ វាប្រាប់អ្នកស្ទើរតែគ្មានអ្វីអំពីថាតើអ្នកនឹងរស់រានពេលឱ្យវាធ្វើ។
Ranking ក៏មិនមានស្ថិរភាពផង
វាកាន់តែអាក្រក់សម្រាប់អ្នកណាដែលទុកចិត្តលំដាប់ leaderboard។ AgentAtlas បង្ហាញហានិភ័យរង្វាស់ពីរដែលគួរធ្វើឱ្យជំនឿលើការប្រៀបធៀបលេខតែមួយរញ្ជួយ៖ “mapped label agreement can change substantially when the explicit label menu is removed, and axis choice can change apparent rankings”។ ទីពីរនោះជាអ្នកសម្លាប់។ Ranking មិនមែនជាការពិតអំពី agent ទេ វាមួយផ្នែកជា artifact នៃ axis ណាដែលអ្នកសម្រេចដាក់ពិន្ទុ។ Rank តាម outcome success ហើយ agent មួយឈ្នះ rank តាម trajectory quality ឬ control-decision quality ហើយមួយផ្សេងឈ្នះ។ គ្មាន leaderboard ពិតតែមួយទេ — មាន leaderboard មួយក្នុងមួយ axis ហើយពួកវាមិនព្រមគ្នា។
យើងបានឃើញជំងឺដូចគ្នាពីមុំផ្សេងក្នុង គម្លាតភាពជឿជាក់៖ នៅទីនោះ ranking បានបញ្ច្រាសរវាង single-attempt capability និង long-horizon reliability។ នៅទីនេះពួកវាបញ្ច្រាសរវាង outcome និង process។ មេរៀនរំជួល — ពិន្ទុតែមួយដាក់លំដាប់សរុបលើរបស់ដែលគ្មានលំដាប់នោះ។ AgentAtlas ប្រុងប្រយ័ត្នអំពីការអះអាងផ្ទាល់ខ្លួនរបស់វាដែរ៖ ការសិក្សាជាឧទាហរណ៍របស់វា “is not a public benchmark release and should not be read as a definitive model comparison” ដែលពិតជាភាពបន្ទាបខ្លួនដែល leaderboard ដែលវារិះគន់គ្មាន។ (វាបាន audit benchmark agent ដប់ប្រាំ សម្រាប់ behavior អ្វីដែលពួកវាគ្របដណ្ដប់ពិតប្រាកដ — ហើយរកឃើញថាភាគច្រើនគ្របដណ្ដប់មួយចំណិត ហើយរាយការណ៍វាជាទាំងមូល។)
អ្វីដែលត្រូវវាស់ពិតប្រាកដ
ប្រសិនបើលេខចំណងជើងមិនអាចទុកចិត្ត តើអ្នកធ្វើអ្វីជំនួសវិញ? អ្នកវាយតម្លៃ agent លើ axis ដែលផ្គូផ្គងនឹងរបៀបដែលវានឹងធ្វើបាបឬជួយអ្នកពិតប្រាកដក្នុង production — ហើយសម្រាប់ agent ដែលធ្វើ action ពិត របស់ទាំងនោះភាគច្រើនអំពី trajectory មិនមែនទិសដៅ។
ជាក់ស្ដែង៖ តើ agent ask ឬ confirm មុន action ដែលមិនអាចត្រឡប់វិញ ជាជាងគ្រាន់តែ act? នោះជាភាពខុសគ្នារវាង deploy សុវត្ថិភាព និងគ្រោះមហន្តរាយ ហើយវាភ្ជាប់ដោយផ្ទាល់នឹងមូលហេតុដែល oversight ជា resource ដែលមានកម្រិត និងត្រូវរចនា — agent ដែលមិនដែល ask មិនមែនមានប្រសិទ្ធភាពទេ វាគ្មានការគ្រប់គ្រង។ តើវាបានយក path សុវត្ថិភាព ឬ ជោគជ័យរបស់វាអាស្រ័យលើ trajectory ដ៏ប្រហែសដែល blast radius របស់វាអ្នកគួរតែបាន sandbox ឱ្យហើយ? តើវា recover ពី error ឬគ្រាន់តែចៃដន្យមិនជួបណាមួយ run នេះ? Outcome ✓ ដែលទៅដល់ដោយ path គ្រោះថ្នាក់ មិនមែនជាជ័យជម្នះដែលអ្នកអាចទុកក្នុងធនាគារ — វាជា liability ដែលទទួលពិន្ទុល្អ។ Agent ដែលអ្នកចង់បានជាមួយដែលជោគជ័យ ហើយ ធ្វើការសម្រេចចិត្តល្អក្នុងការទៅដល់ ហើយមានតែការវាយតម្លៃ multi-axis ទើបអាចបែងចែកទាំងពីរ។
កំណែជាក់ស្ដែងថោកជាងវាស្ដាប់ទៅ។ អ្នកមិនត្រូវការផលិតឡើងវិញនូវ audit ដប់ប្រាំ benchmark ទេ អ្នកត្រូវការ run task ពិត របស់អ្នក ហើយបន្ទាប់មកអាន trace មិនមែនគ្រាន់តែ column pass/fail — ដាក់ពិន្ទុ សូម្បីមិនផ្លូវការ ថាតើ agent act ញឹកញាប់ប៉ុណ្ណាពេលវាគួរ ask, តើ trajectory អាក្រក់បំផុតរបស់វាបំផ្លាញប៉ុណ្ណា, ហើយតើវា recover ឬសំណាងល្អ។ ធ្វើនោះលើ task តំណាងម្ភៃ ហើយអ្នកនឹងរៀនច្រើនជាងអំពី agent ណាដែលត្រូវ deploy ជាង leaderboard សាធារណៈទាំងមូលនឹងប្រាប់អ្នក។ លេខចំណងជើងឥតគិតថ្លៃ ហើយនាំឱ្យយល់ច្រឡំ ការ review trace ថោក ហើយដាច់ខាត ហើយស្ទើរតែគ្មាននរណាធ្វើ — ដែលពិតជាមូលហេតុដែលវាជាគុណសម្បត្តិ។
ហេតុអ្វីនេះអនុគ្រោះអាស៊ីអាគ្នេយ៍
នេះជាផ្នែកដែលសំខាន់សម្រាប់តំបន់នេះ ហើយវាជារូបរាងដ៏ស៊ាំឥឡូវ។ ការវាយតម្លៃ agent ឱ្យបានត្រឹមត្រូវ — លើ trajectory និង control-decision quality មិនមែនគ្រាន់តែលេខចំណងជើង — ជា វិន័យរង្វាស់ និងការវិនិច្ឆ័យ មិនមែនដើមទុន។ វាមិនចំណាយ GPU ទេ និងគ្មាន frontier model។ វាជាការងារនៃការសម្រេចថា axis ណាសំខាន់សម្រាប់ use case របស់អ្នក សាងសង់ harness ដែលដាក់ពិន្ទុពួកវា និងបដិសេធមិនឱ្យលេខតែមួយធ្វើឱ្យចាប់អារម្មណ៍។ នោះ run លើ laptop និងក្បាលច្បាស់។
ហើយវាជាគុណសម្បត្តិពិតប្រាកដ ព្រោះទីផ្សារនៅសល់កំពុងធ្វើផ្ទុយ៖ អានកំពូល leaderboard ហើយ ship វា។ ក្រុមមួយនៅភ្នំពេញ ឬ Da Nang ដែលផ្ទុយទៅវិញវាយតម្លៃតាមរបៀបដែល AgentAtlas អះអាង — outcome ហើយ process ទូទាំង axis ដែលផ្គូផ្គង task ពិតរបស់វា — នឹងជ្រើស agent ដែលសុវត្ថិភាពពិតប្រាកដក្នុងការ deploy លើការងារដែលមានផលវិបាក និងគ្រប់គ្រងដោយបទប្បញ្ញត្តិ ខណៈដៃគូប្រកួតដែលមានទុនច្រើនជាង deploy អ្វីដែលឈរលើកំពូល benchmark ដែលវាស់របស់ខុស។ Milestone computer-use ពិតប្រាកដ និងសមនឹងអបអរ។ គ្រាន់តែកុំច្រឡំ “ឆ្លង human baseline” ជាមួយ “រួចរាល់សម្រាប់អាជីវកម្មរបស់អ្នក” — ទាំងនោះជាការអះអាងខុសគ្នា ហើយមានតែមួយក្នុងចំណោមនោះនៅលើ leaderboard។