Oversight មានសមត្ថភាពកំណត់៖ ហេតុអ្វី human review កាន់តែច្រើនអាចធ្វើឱ្យ agent មានសុវត្ថិភាពតិចជាង

ពេល agent មួយចាប់ផ្ដើមធ្វើសកម្មភាពដែលពិបាកដកវិញ — run shell command, កែឯកសារ, push deploy — ការផ្លាស់ប្ដូរសុវត្ថិភាពស្ដង់ដារគឺជាសភាវគតិ ហើយមើលទៅត្រឹមត្រូវយ៉ាងច្បាស់៖ ដាក់មនុស្សក្នុង loop។ សកម្មភាពប្រថុយផ្អាក ហើយរង់ចាំមនុស្សអនុម័ត។ Review កាន់តែច្រើន សុវត្ថិភាពកាន់តែច្រើន។ វាជា pattern ដែលស្ទើរតែគ្រប់ក្រុមឈោងចាប់ជាមុនគេ ហើយវាជា pattern ដែលការសិក្សាឆ្នាំ ២០២៦ មួយទើបធ្វើឱ្យស្មុគស្មាញតាមរបៀបមួយដែលមិនស្រួល៖ ហួសពីចំណុចមួយ oversight របស់មនុស្សកាន់តែច្រើនធ្វើឱ្យប្រព័ន្ធមានសុវត្ថិភាពតិចជាង។

នោះមិនមែនជា paradox ដើម្បីខ្លួនវាទេ។ វាធ្លាក់ចេញពីការពិតមួយដែលគ្រប់គ្នាដឹង ហើយការរចនាសុវត្ថិភាពភាគច្រើនមិនអើពើ — មនុស្សដែលធ្វើ review ជាធនធានមានកំណត់ ហើយអស់កម្លាំង។ ចាត់ទុកមនុស្សនោះថាគ្មានកំណត់ ហើយអ្នកសាងសង់ gate ដែលឈប់ដំណើរការស្ងាត់ៗពិតប្រាកដនៅពេលដែលអ្នកពឹងលើវាខ្លាំងបំផុត។

Approval gate និងតម្លៃលាក់របស់វា

Human-in-the-loop approval gate ពិតជាការរចនាល្អសម្រាប់សកម្មភាពត្រឹមត្រូវ។ បើ agent មួយរៀបនឹងលុប production database ឬផ្ទេរប្រាក់ អ្នកចង់ឱ្យមនុស្សមើលជាមុន។ Logic ត្រឹមត្រូវ ហើយសម្រាប់សកម្មភាព stakes ខ្ពស់ irreversible វាជា pattern ត្រឹមត្រូវ។

បញ្ហាចាប់ផ្ដើមពេលសភាវគតិដូចគ្នាត្រូវបានអនុវត្តទៅ អ្វីៗគ្រប់យ៉ាង ដែលមើលទៅប្រថុយ។ ការ escalate នីមួយៗចំណាយឯកតានៃធនធានកម្រ៖ ការយកចិត្តទុកដាក់របស់មនុស្ស។ ហើយការយកចិត្តទុកដាក់របស់មនុស្សមិនថយចុះដោយរលូនក្រោមបន្ទុកទេ — វាដួលរលំ។ Reviewer ដែលត្រូវបានស្នើឱ្យអនុម័តសកម្មភាពប្រាំដែលត្រូវបានជ្រើសរើសដោយប្រុងប្រយ័ត្នក្នុងមួយថ្ងៃ អានសកម្មភាពនីមួយៗ។ Reviewer ដូចគ្នាដែលត្រូវបានស្នើឱ្យអនុម័តពីរយ ចាប់ផ្ដើម pattern-match បន្ទាប់មកបោះត្រាបោះ បន្ទាប់មកចុច “approve” ដោយសភាវគតិដើម្បីសម្អាត queue។ Gate នៅតែមាននៅលើ org chart។ វាបានឈប់ជា gate ក្នុងការពិត។

ដូច្នេះតម្លៃនៃការ escalate សកម្មភាពមួយមិនមែនសូន្យទេ ហើយវាមិនថេរផង — រាល់ការ escalate ដែលមិនចាំបាច់ធ្វើឱ្យគុណភាពនៃ review ថយចុះលើ រាល់ ការ escalate ផ្សេងទៀត រួមទាំងការ escalate ដែលពិតជាសំខាន់។

Inverted-U៖ oversight កាន់តែច្រើន សុវត្ថិភាពតិចជាង

នេះជាអ្វីដែលឯកសារឆ្នាំ ២០២៦ Oversight Has a Capacity (arXiv 2606.08919) បានចេញវាស់ ពិតប្រាកដក្នុង setting ដែលសំខាន់៖ “LLM agent [ចាប់ផ្ដើម] ធ្វើសកម្មភាពពិត irreversible (shell command, ការកែឯកសារ, deploy)” ការពារដោយ “human-in-the-loop approval gate”។ ការរកឃើញសំខាន់របស់វាត្រង់៖ “oversight របស់មនុស្សកាន់តែច្រើនអាចធ្វើឱ្យប្រព័ន្ធមានសុវត្ថិភាពតិចជាង ហើយ guard ដែលល្អបំផុតផ្នែកសុវត្ថិភាព escalate ក្រោម full escalation។”

រូបរាងរបស់វាជា inverted-U។ Escalate តិចពេក ហើយសកម្មភាពប្រថុយរអិលកាត់ដោយមិន review — មិនមានសុវត្ថិភាពច្បាស់។ ប៉ុន្តែ escalate ច្រើនពេក ហើយអ្នកលិច reviewer គុណភាព review ធ្លាក់ ហើយសកម្មភាពគ្រោះថ្នាក់រអិលកាត់ ដែលត្រូវបានអនុម័ត — ក៏មិនមានសុវត្ថិភាពដែរ ហើយកាន់តែលាក់កំបាំង ព្រោះឥឡូវវាផ្ទុកត្រារបស់មនុស្ស។ សុវត្ថិភាពពិតប្រាកដឡើងដល់កំពូលនៅកន្លែងណាមួយនៅកណ្ដាល នៅ escalation rate មធ្យម។ “Escalate អ្វីៗគ្រប់យ៉ាង” មិនមែនជាចុងសុវត្ថិភាពនៃ dial ទេ វាហួសពីកំពូលនៃខ្សែកោង ហើយចុះម្ខាងទៀត។

វាគួរស្រមៃរបៀបដែលការបរាជ័យពិតជាមកដល់ ព្រោះវាមិន dramatic ទេ។ គ្មាននរណាសម្រេចចិត្តឈប់ review។ Queue គ្រាន់តែកើនឡើង៖ នៅពេលរសៀលមានការអនុម័តកំពុងរង់ចាំសែសិប អូ ហុកសិប ការនីមួយៗមើលទៅដូចហាសិបការមុន ហើយ reviewer — ក្រោមសម្ពាធដើម្បី unblock agent និងមនុស្សដែលរង់ចាំពួកវា — ស្ថិតក្នុងចង្វាក់នៃការ skim និងអនុម័ត។ ការអនុម័តទីកៅសិបមួយក្នុងថ្ងៃនោះជាការដែល drop table មួយ ហើយវាបានជិះកាត់ក្នុងពេលពីរវិនាទីដោយចុចមួយ ព្រោះនៅពេលនោះការចុច ជា review។ Gate មិនបានបរាជ័យឮៗទេ។ វាបានសឹករិចរិលស្ងាត់ៗ ក្រោម volume ពិតប្រាកដដែល “escalate អ្វីៗគ្រប់យ៉ាង” ធានា។ នោះជាអន្ទាក់៖ policy ដែលមានអារម្មណ៍ប្រុងប្រយ័ត្នបំផុតជា policy ដែលផលិតលក្ខខណ្ឌសម្រាប់គ្រោះមហន្តរាយដែលត្រូវបានគ្រវីឱ្យកាត់។

សភាវគតិដើម្បីបង្កើន oversight ឱ្យអតិបរមា ម្យ៉ាងវិញទៀត គឺ optimize បរិមាណខុស។ អ្នកមិនចង់បាន escalation អតិបរមាទេ។ អ្នកចង់បាន review ប្រសិទ្ធភាព អតិបរមា ហើយចំនួនពីរនោះញែកគ្នាពេលមនុស្សអស់កម្លាំង។

Oversight ជា budget មិនមែន checkbox

ការ reframe ដែលឯកសារផ្ដល់ជាផ្នែកមានប្រយោជន៍៖ “oversight របស់ agent … មិនមែនត្រឹមតែជា classification problem ទេ ប៉ុន្តែជា resource-allocation problem ផង៖ ការយកចិត្តទុកដាក់របស់មនុស្សមានកំណត់ ហើយ escalation policy របស់ guard ចំណាយវា។” ប្រយោគនោះគួរផ្លាស់ប្ដូររបៀបដែលអ្នករចនា gate។

ការចាត់ទុក oversight ជា classification — តើសកម្មភាពនេះប្រថុយ បាទ ឬទេ escalate បើបាទ — សន្មតដោយប្រយោលថាមនុស្សអាចស្រូប case “បាទ” ប៉ុន្មានក៏ដោយដែល classifier ផលិត។ ការចាត់ទុកវាជា resource allocation ចាប់ផ្ដើមពីបរិវេណផ្ទុយ៖ អ្នកមាន attention budget ថេរក្នុង reviewer ក្នុងម៉ោង ហើយការងាររបស់ escalation policy គឺ ចំណាយ budget នោះកន្លែងដែលវាទិញសុវត្ថិភាពបានច្រើនបំផុត។ រាល់ escalation ជាការដក។ ចំណាយវាលើការសម្រេចចិត្តដែលពិតជាមិនច្បាស់លាស់ blast radius ខ្ពស់ irreversible កុំចំណាយវាលើសកម្មភាព stakes ទាបមួយពាន់ដែល classifier បានដាក់ទង់គ្រាន់តែដើម្បីសុវត្ថិភាព ព្រោះការដកនីមួយៗនោះទុកក្នុង account តិចជាងសម្រាប់ការសម្រេចចិត្តដែលសំខាន់។

មានការរកឃើញទីពីរដែលធ្វើឱ្យវិធីសាស្ត្រ classifier ផុយកាន់តែអាក្រក់៖ ហានិភ័យជារឿង subjective។ ឯកសាររាយការណ៍ថា reviewer មនុស្ស “យល់ស្របគ្នាត្រឹមមធ្យមថាអ្វីប្រថុយ (Fleiss’ kappa = 0.52)” — គ្មាន label ត្រឹមត្រូវតែមួយសម្រាប់សកម្មភាពណាដែលគ្រោះថ្នាក់។ ដូច្នេះ gate ដែលសាងសង់ជា risk classifier ច្បាស់មិនត្រឹមតែចំណាយ budget អាក្រក់ទេ វាចំណាយវាប្រឆាំងនឹង target ដែលមនុស្សសមហេតុផលថែមទាំងមិនយល់ស្របគ្នា។ បញ្ហារចនាមិនមែន “សាងសង់ risk detector ល្អឥតខ្ចោះ” ទេ។ វាជា “បែងចែកធនធានដែលប្រកែកគ្នា និងមានកំណត់ដោយឆ្លាតវៃក្រោមភាពមិនច្បាស់លាស់”។

ការរចនា gate មិនមែនត្រឹមតែតម្លើងវា

បើ oversight ជា budget escalation policy ជារបៀបដែលអ្នកចំណាយវា ហើយគោលការណ៍ពីរបីធ្លាក់ចេញដោយផ្ទាល់៖

• ដាក់សកម្មភាពតាម tier ដោយ reversibility និង blast radius មិនមែនដោយ surface risk។ សកម្មភាពដែល reversible ឬ sandboxed ដោយងាយស្រួលស្ទើរតែមិនត្រូវការមនុស្ស មិនថាវាមើលទៅគួរឱ្យខ្លាចយ៉ាងណា សកម្មភាព irreversible blast ទូលំទូលាយត្រូវការមនុស្សទោះវាមើលទៅធម្មតា។ នេះជាកន្លែងដែល ការ sandbox agent ផ្ដល់ dividend ទីពីរ៖ រាល់សកម្មភាពដែល blast radius របស់វាអ្នកបានកំណត់ព្រំដែនរួចហើយ ជាសកម្មភាពដែលអ្នក មិន ត្រូវចំណាយការយកចិត្តទុកដាក់របស់មនុស្ស។ Containment និង oversight ដោះដូរគ្នា — អ្នកញែកកាន់តែច្រើន អ្នកត្រូវ escalate កាន់តែតិច។
• ឱ្យ agent self-escalate ពេលការលំបាកឡើង។ Agent ដែលលើក rate នៃការ check in ផ្ទាល់ខ្លួនរបស់វាពេល task កាន់តែលំបាក មិនច្បាស់លាស់ ឬ stakes ខ្ពស់ កំពុងផ្ដល់សញ្ញាស្មោះត្រង់ជាង confidence score តែមួយ — ហើយវាប្រមូលផ្ដុំ budget របស់មនុស្សលើពេលវេលាដែលត្រូវការវាពិតប្រាកដ។
• ការពារ reviewer ពីភាពអស់កម្លាំងដែលបំបែក gate។ កំណត់ escalation rate បង្វិល reviewer ហើយចាត់ទុក queue ដែលលិចជា safety incident មិនមែនរំខាន staffing — ព្រោះ reviewer ដែលអស់កម្លាំងជា gate ដែលបរាជ័យដែលនៅតែរាយការណ៍ “approved”។ វាស់វា៖ បើ approval rate របស់អ្នកជា 99% ហើយ median review time របស់អ្នកជាពីរវិនាទី អ្នកមិនមាន oversight layer ទេ អ្នកមាន latency tax ដែលផលិត record មិនពិតនៃការវិនិច្ឆ័យរបស់មនុស្ស។ ចំនួនពីរនោះជាការព្រមានដំបូងថា budget ត្រូវបានចំណាយលើស។

ខ្សែទាញ៖ human-in-the-loop មិនមែនជា feature សុវត្ថិភាពដែលអ្នកបើកទេ វាជាប្រព័ន្ធដែលអ្នក tune។ យើងបានធ្វើអំណះអំណាងដូចគ្នាអំពី guardrail layer ជា product surface ពិតប្រាកដ ជាជាងរបស់បន្ថែម ហើយវាជាអ្វីដែលឱ្យអ្នក run agent loop ដោយគ្មានការមើលថែខណៈអ្នកដេក — loop ទាំងនោះនៅសុវត្ថិភាពតែប្រសិនបើ policy សម្រាប់ ពេលណាដែលត្រូវដាស់មនុស្ស ត្រូវបាន calibrate ទៅមនុស្សដែលមិនអាចត្រូវដាស់មួយរយដងក្នុងមួយយប់។

ហេតុអ្វីនេះអនុគ្រោះអាស៊ីអាគ្នេយ៍

នេះជាផ្នែកដែលសំខាន់សម្រាប់តំបន់នេះ ហើយវាជារូបរាងធ្លាប់ស្គាល់ឥឡូវ។ ការរចនា escalation policy ដែលបាន calibrate — ដាក់សកម្មភាពតាម tier កំណត់ self-escalation trigger ធ្វើ budget ការយកចិត្តទុកដាក់របស់ reviewer — ជា systems judgment សុទ្ធ។ វាមិនចំណាយ GPU មិនចំណាយ frontier model មិនចំណាយដើមទុនទេ។ វាជាការងារនៃការគិតដោយប្រុងប្រយ័ត្នថាការសម្រេចចិត្តណាដែលពិតជាត្រូវការមនុស្ស ហើយរបៀបរក្សាមនុស្សនោះឱ្យមុត ហើយវា run ទាំងស្រុងលើវិន័យវិស្វកម្ម។

នោះជា edge ព្រោះការផ្លាស់ប្ដូរសភាវគតិនៅគ្រប់កន្លែងផ្សេងគឺ “បន្ថែមមនុស្សក្នុង loop” ហើយហៅវាថាសុវត្ថិភាព — ដែលដូចការស្រាវជ្រាវបង្ហាញ អាចផលិត reviewer អស់កម្លាំងបោះត្រាបោះ queue មួយ ពោលគឺសុវត្ថិភាព តិចជាង ស្លៀកសម្លៀកបំពាក់នៃច្រើនជាង។ ក្រុមនៅភ្នំពេញ ឬ Da Nang ដែលផ្ទុយទៅវិញចាត់ទុក oversight ជា budget កម្រ — escalate តិចជាងតែ review បានល្អជាង — សាងសង់ agent ដែលពិតជាមានសុវត្ថិភាពជាងក្នុងការ deploy លើការងារដែលមានផលវិបាក ត្រូវបានគ្រប់គ្រង ហើយធ្វើវាដោយមិនចំណាយមួយដុល្លារច្រើនជាងគូប្រកួតដែលកំពុងពន្លិច reviewer របស់ខ្លួន។ ពេល agent ទទួលយកសកម្មភាព irreversible កាន់តែច្រើន ក្រុមដែលឈ្នះការទុកចិត្តនឹងមិនមែនជាក្រុមដែលមាន oversight ច្រើនបំផុតទេ។ ពួកគេនឹងជាក្រុមដែលចំណាយ attention budget របស់មនុស្សដែលមានកំណត់កន្លែងដែលវាពិតជាសំខាន់។