អត្ថបទ
ឈប់បោះ SOP ចូលទៅឱ្យ AI Agent ទាំងដុល៖ ប្រើ RFC 2119 (MUST/SHOULD/MAY) ដើម្បីគ្រប់គ្រង Behavior របស់ Agent ឱ្យចំគោលដៅ
ការញាត់ SOP របស់មនុស្សចូលទៅ LLM ទាំងដុល តែងតែធ្វើឱ្យ Agent ដំណើរការត្រូវម្ដង ហើយខូចការបីដង។ អត្ថបទនេះនឹងបង្ហាញពីការប្រើប្រាស់ MUST, SHOULD, MAY នៃ RFC 2119 ដើម្បីសរសេរ System Prompt និង Agent Skill ឡើងវិញ ដោយបែងចែកព្រំដែនច្បាស់លាស់រវាងការបង្ខំដាច់ខាត ការណែនាំយ៉ាងម៉ឺងម៉ាត់ និងការសម្រេចចិត្តដោយស្វ័យភាព ព្រមទាំងភ្ជាប់មកជាមួយនូវគោលការណ៍អនុវត្តជាក់ស្ដែងចំនួនបី។
· អាន 1 នាទី
ក្រុមការងារជាច្រើននៅពេលយក Agent ទៅ implement ជាក់ស្ដែង កំហុសដែលជួបញឹកញាប់បំផុតគឺការយក «SOP របស់មនុស្ស» ទាំងស្រុងពី Word/Notion ទៅញាត់ឱ្យ LLM ដោយរំពឹងថាវានឹងចាត់ចែងដោយស្វ័យប្រវត្តិ។ ប៉ុន្តែលទ្ធផលជារឿយៗគឺដូចជាការទិញឆ្នោត៖ ដំណើរការត្រូវម្ដង តែខូចការដល់ទៅបីដង។
បញ្ហាមិនមែនមកពីសមត្ថភាព model មិនគ្រប់គ្រាន់នោះទេ ប៉ុន្តែដោយសារតែ SOP របស់មនុស្សបង្កប់ទៅដោយ «Tacit Knowledge (ចំណេះដឹងយល់ដោយមិនបាច់ប្រាប់)» យ៉ាងច្រើន។ ខួរក្បាលមនុស្សអាចវាយតម្លៃដោយស្វ័យប្រវត្តិថា «ចំនួនទឹកប្រាក់តិចជាង 500 មិនបាច់សុំអនុម័តទេ» ឬ «បើជំហាននេះជួប error អាចរំលងសិនបាន»។ ប៉ុន្តែសម្រាប់ LLM វិញ អត្ថបទដែលគ្មានទម្រង់រៀបរយ (unstructured text) គឺគ្មានព្រំដែនកម្រិតធ្ងន់ស្រាលនោះឡើយ ដូច្នេះវាមានតែដំណើរការតាមតែចិត្ត។
ដើម្បីឱ្យ behavior របស់ Agent មានភាពច្បាស់លាស់ (deterministic) ជំហានដំបូងមិនមែនជាការប្តូរទៅប្រើ model ធំជាងមុននោះទេ ប៉ុន្តែគឺការយកស្តង់ដារបុរាណនៃលក្ខណៈបច្ចេកទេស network protocol មកប្រើ៖ កម្រិតអត្ថន័យនៃ RFC 2119។
សង្ខេបចំណុចសំខាន់ជាមុន៖ កំណត់តែ compliance, security និង core Schema ប៉ុណ្ណោះជា MUST ហើយព្រំដែនផ្សេងទៀតទុកឱ្យ SHOULD និង MAY ចំណែកឯចំណុចដែលមានហានិភ័យខ្ពស់ ត្រូវប្រគល់ឱ្យមនុស្សជាអ្នក review។
ហេតុអ្វីបានជា RFC 2119?#
នៅពេលសរសេរ System Prompt, Agent Skill ឬ Workflow Rule ពាក្យមិនច្បាស់លាស់ដូចជា «សូមប្រយ័ត្ន», «ល្អបំផុតគួរតែ», «ព្យាយាមឱ្យអស់ពីលទ្ធភាព» គឺគ្មានកម្លាំងកំណត់ព្រំដែនសម្រាប់ model ឡើយ។ ការប្តូរមកប្រើកម្រិតកិរិយាស័ព្ទច្បាស់លាស់ អាចជួយគូសព្រំដែននៃការសម្រេចចិត្តបានយ៉ាងដាច់ណាត់។
MUST / REQUIRED៖ ការបង្ខំដាច់ខាត គ្មានការយោគយល់#
- អត្ថន័យ：ដាច់ខាតមិនអាចរំលងបាន គ្មានករណីលើកលែង។
- ស្ថានភាពប្រើប្រាស់：ការផ្ទៀងផ្ទាត់ទិន្នន័យ (Data validation), ការត្រួតពិនិត្យសុវត្ថិភាព, លក្ខខណ្ឌកំណត់ Schema output, ការទប់ស្កាត់ហានិភ័យខ្ពស់។
- ឧទាហរណ៍：「មុនពេល call វិក្កយបត្រ API,
MUST ផ្ទៀងផ្ទាត់ជាមុនថាតើលេខសម្គាល់បុគ្គលិកមានឬអត់ បើសិនជា return មកទទេ, MUST បញ្ឈប់ execution ភ្លាមៗ。」
SHOULD / RECOMMENDED៖ ការណែនាំយ៉ាងម៉ឺងម៉ាត់ ប៉ុន្តែអនុញ្ញាតឱ្យងាកចេញដោយសមហេតុផល#
- អត្ថន័យ：ត្រូវតែគោរពតាម លើកលែងតែមានហេតុផល Context គ្រប់គ្រាន់យ៉ាងខ្លាំង បើមានការងាកចេញ Agent ត្រូវតែបញ្ជាក់ពី Reasoning ឱ្យបានច្បាស់លាស់។
- ស្ថានភាពប្រើប្រាស់：ការជ្រើសរើស algorithm strategy, ចំណង់ចំណូលចិត្តក្នុងការចាត់ថ្នាក់ (classification preference), retry logic។
- ឧទាហរណ៍：「ចំពោះ Ticket ប្រភេទសាកសួររបស់អតិថិជន,
SHOULD ផ្តល់អាទិភាព assign ទៅកាន់ first-line support ប៉ុន្តែប្រសិនបើពាក់ព័ន្ធនឹងជម្លោះលំហូរសាច់ប្រាក់ ត្រូវបានអនុញ្ញាតឱ្យ assign បន្តទៅក្រុម audit ហិរញ្ញវត្ថុ。」
MAY / OPTIONAL：ជម្រើសស្វ័យភាព ការសម្រេចចិត្តដោយសេរី#
- អត្ថន័យ：Model អាចសម្រេចចិត្តដោយខ្លួនឯងថានឹង execute ឬអត់ ដោយផ្អែកលើធនធាន Context បច្ចុប្បន្ន ឬ token budget។
- ស្ថានភាពប្រើប្រាស់：ការពន្យល់បន្ថែម, ការផ្ដល់យោបល់ពង្រីកការគិត, ទម្រង់ log ដែលជាជម្រើសបន្ថែម។
- ឧទាហរណ៍：「នៅពេលបង្កើត summary នៃដំណើរការ,
MAY ភ្ជាប់បន្ថែមនូវ Ticket ID នៃប្រវត្តិករណីស្រដៀងគ្នា 1～2。」
គោលការណ៍អនុវត្តជាក់ស្ដែងទាំងបី#
1. បដិសេធការប្រើ MUST ពេញមួយទំព័រ ត្រូវទុកចន្លោះសម្រាប់ Reasoning#
ការសរសេរ rule ទាំងអស់ជា MUST គឺស្មើនឹងការយក LLM មកប្រើដូចជា Deterministic Compiler ដែលងាយនឹងបង្កឱ្យមាន rule ជាន់គ្នា ឬកើតជា logic deadlock បន្ទាប់ពី Context រីកធំខ្លាំង។ គួរសម្គាល់ត្រឹមតែ «compliance, security, core Schema» ជា MUST ប៉ុណ្ណោះ ហើយព្រំដែនដែលនៅសល់ត្រូវប្រគល់ឱ្យ SHOULD។
2. ប្រើប្រាស់រួមគ្នាជាមួយទម្រង់ structured Markdown blocks#
បំបែក Prompt ជាបួន blocks ខាងក្រោម ដើម្បីឱ្យ Scope នៃកម្រិតអត្ថន័យអាចមើលឃើញយ៉ាងច្បាស់ភ្លាមៗ៖
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. ចំណុចដែលមានហានិភ័យខ្ពស់ត្រូវភ្ជាប់ជាមួយ Human-in-the-loop#
នៅពេលលក្ខខណ្ឌ trigger ព្រំដែន MUST សំខាន់ៗ (ដូចជាចំនួនទឹកប្រាក់ក្នុងមួយប្រតិបត្តិការ > $5,000, ការកែប្រែសិទ្ធិ Admin) behavior តែមួយគត់ដែលជា MUST របស់ Agent គឺ «ផ្អាក pipeline ហើយរង់ចាំមនុស្សចុះពិនិត្យចុច OK» ជាជាងការសម្រេចចិត្តជំនួសមនុស្ស។
សេចក្ដីសន្និដ្ឋាន៖ ពីរបស់លេង Demo ឆ្ពោះទៅកាន់ Production-Ready#
ចាត់ទុក Agent ដូចជាខ្សែច្រវាក់ផលិតកម្មឧស្សាហកម្មមួយ មិនមែនជា «កំពូលមនុស្សស៊ីឈ្នួលធ្វើការរាយរង» គ្រប់យ៉ាងតែឯងនោះឡើយ។ តាមរយៈការបង្កើតកិច្ចសន្យា behavior ដោយប្រើ RFC 2119 ទើប Agent របស់អ្នកអាចវិវត្តពីរបស់លេង Demo ឆ្ពោះទៅកាន់កម្រិត Production-Ready ពិតប្រាកដ។