สิ่งสำคัญដែលអ្នកត្រូវធ្វើការវាយតម្លៃ និងត្រួតពិនិត្យសុវត្ថិភាព មុនពេលដាក់ឱ្យដំណើរការ AI Agent

ក្រុមហ៊ុន ناش្មើនីមួយៗដែលបង្កើត Customer Service Agent បានជួបប្រទះបញ្ហាអតិថិជនប្តឹងតវ៉ាកាន់តែច្រើនឡើងៗនៅសប្តាហ៍ទីបីនៃការដាក់ឱ្យដំណើរការ។ ពួកគេមានការងឿងឆ្ងល់យ៉ាងខ្លាំង ពីព្រោះពេលធ្វើតេស្តគឺដំណើរការត្រូវទាំងអស់។ ក្រោយមក នៅពេលដែលពួកគេទាញកំណត់ត្រាមកពិនិត្យមើល ទើបដឹងថា៖ មានបញ្ហាប្រភេទមួយ ដែល Agent តែងតែដកស្រង់សម្តីយ៉ាងមុតមាំនូវ «បទបញ្ញត្តិស្តីពីការសងប្រាក់វិញរបស់ក្រុមហ៊ុន មាត្រាទី ៧» ប៉ុន្តែការពិតទៅ គោលការណ៍នោះមិនមានមាត្រាទី ៧ នោះទេ។ វាពុំមែនថាមិនចេះនោះទេ ប៉ុន្តែវាបាននិយាយរឿងដែលមិនមានឱ្យទៅជាដូចរឿងពិត ហើយសំណុំេតេស្តមុនពេលដាក់ឱ្យដំណើរការនោះ គឺពុំបានគ្របដណ្តប់លើបញ្ហាប្រភេទនេះឡើយ។

នេះគឺជាទម្រង់នៃការបរាជ័យដ៏គ្រោះថ្នាក់បំផុតរបស់ Agent — វាមិនបង្ហាញសញ្ញាពណ៌ក្រហម និងមិន throw exception នោះទេ។ វាធ្វើខុសដោយស្ងៀមស្ងាត់ ប្រកបដោយភាពសុភាពរាបសា និងមានរបៀបរៀបរយ បន្ទាប់មកអ្នកប្រើប្រាស់របស់អ្នកក៏ជឿជាក់តែម្តង។

ហេតុអ្វីបានជា Agent អាច «បរាជ័យដោយស្ងៀមស្ងាត់»

កូដទន់ (Software) បែបប្រពៃណីពេលមានកំហុស គឺច្រើនតែបុកឱ្យអ្នកឃើញ៖ ចេញ Error, ឆ្លើយតបលេខ 500 និងបង្ហាញ stack trace ចង្អុលចំជួរទីប៉ុន្មាន។ ប៉ុន្តែ Agent គឺខុសគ្នា។ លទ្ធផលរបស់វាគឺទទួលបានពីការ «បង្កើតឡើង (Generate)» ដែលភាសាគឺរលូនជានិច្ច ហេតុនេះហើយបានជាកំហុសត្រូវបានខ្ចប់មកជាមួយគ្នាមើលទៅដូចនឹងចម្លើយដែលត្រឹមត្រូវបេះបិទ។

អ្វីដែលកាន់តែស្មុគស្មាញទៀតនោះ គឺជំហានច្រើន។ Agent ដំណើរការម្តងអាចនឹងហៅ Tool ប្រាំ ឬប្រាំ៦ដង ដោយក្នុងចំណោមនោះមានជំហានណាមួយ lệch (ខុសគន្លង) ដូចជា ការស្វែងរកទិន្នន័យខុស ការបញ្ជូនប៉ារ៉ាម៉ែត្រខុស ឬការខកខានលក្ខខណ្ឌណាមួយនោះ ជំហានក្រោយៗទៀតនឹងបន្តការសន្និដ្ឋានផ្អែកលើកំហុសនេះ ហើយចុងក្រោយផ្តល់ឱ្យអ្នកនូវលទ្ធផលមួយដែល «មានភាពស៊ីសង្វាក់គ្នា ប៉ុន្តែខុស»។ នៅពេលអ្នកក្រឡេកមើលចម្លើយចុងក្រោយ គឺអ្នកមិនអាចមើលដឹងថាកន្លែងណាខុសនោះឡើយ។

ហេតុដូច្នេះហើយ ការធានាគុណភាព (QA) របស់ Agent គឺមិនអាចពឹងផ្អែកលើការត្រួតពិនិត្យដោយមនុស្ស ឬ «ខ្ញុំរត់មើល vài ដងហើយឃើញថាអាចទទួលយកបាន» នោះទេ។ អ្នកត្រូវមានសំណុំយន្តការដែលអាចវាស់វែងបាន អាចចាក់សារថ្មី (Replay) និងអាចតាមដានជាបន្តបន្ទាប់នៅលើប្រព័ន្ធអនឡាញ។ នេះគឺជាអ្វីដែលបានរៀបរាប់នៅក្នុងអត្ថបទ 〈ចង់បង្កើត AI Agent ដោយខ្លួនឯង តើត្រូវត្រៀមឧបករណ៍អ្វីខ្លះ〉 អំពីស្រទាប់ទាំងបីគឺ ការវាយតម្លៃ (Evaluation) សុវត្ថិភាព និងភាពអាចសង្កេតបាន (Observability) ដែលជាកន្លែងត្រូវប្រើប្រាស់យ៉ាងពិតប្រាកដក្នុងដំណាក់កាលដាក់ឱ្យដំណើរការ។

ចំណុចសំខាន់៖ រឿង៤យ៉ាងដែលត្រូវត្រួតពិនិត្យឱ្យបានហ្មត់ចត់មុនពេលដាក់ឱ្យដំណើរការ

• ការវាយតម្លៃក្រៅបណ្តាញ (Offline Evaluation): ប្រើប្រាស់សំណុំសំណួរថេរមួយ ដើម្បីវាស់វែងថាគុណភាពមានការថយចុះបន្ទាប់ពីការកែប្រែនីមួយៗដែរឬទេ។
• ការធ្វើតេស្តក្រុមក្រហម (Red Teaming): ស្វែងរកចំណុចខ្សោយរបស់វាដោយសកម្ម — តើការបញ្ចូលបែបណាដែលនឹងធ្វើឱ្យវាហួសដែនកំណត់ និយាយភូត និងបែកធ្លាយទិន្នន័យ។
• ការបំបាត់កំហុសច្រើនជំហាន (Multi-step Debug): អាចចាក់សារថ្មីពេញមួយខ្សែ្សនៃការប្រតិបត្តិនៅពេលមានកំហុសកើតឡើង ដើម្បីកំណត់ទីតាំងថាជំហានណាដែលបានខុសគន្លង។
• ការតាមដានលើបណ្តាញ និងរបាំងការពារ (Online Monitoring & Guardrails): បន្តតាមដានគុណភាព និងថ្លៃដើមក្រោយពេលដាក់ឱ្យដំណើរការ និងដាក់បម្រាមមុនពេលមានសកម្មភាពគ្រោះថ្នាក់ណាមួយកើតឡើង។

រឿងទាំងបួននេះ ប្រសិនបើខ្វះសូម្បីតែមួយ គឺស្មើនឹងការលេងល្បែងស៊ីសងពេលអ្នកដាក់ឱ្យដំណើរការ។

វិធីសាស្ត្រធ្វើតេស្ត៖ Promptfoo

ស្មារតីស្នូលនៃការវាយតម្លៃក្រៅបណ្តាញ គឺការប្តូរពាក្យថា «ខ្ញុំគິດថាវាប្រសើរជាងមុន» ទៅជា «តួលេខប្រាប់ខ្ញុំថាវាប្រសើរជាងមុន»។ Promptfoo អនុញ្ញាតឱ្យអ្នកបង្កើតសំណុំករណីធ្វើតេស្តមួយចំនួន — រួមមាន ការបញ្ចូល (Input) អាកប្បកិរិយាដែលរំពឹងទុក និងស្តង់ដារវិនិច្ឆ័យ — បន្ទាប់មកជារៀងរាល់ពេលដែលអ្នកកែប្រែ Prompt ប្តូរ Model ឬកែតម្រូវ Parameter គឺត្រូវរត់សំណុំទាំងមូលដើម្បីមើលការប្រែប្រួលពិន្ទុ។

ស្តង់ដារវិនិច្ឆ័យអាចជាការប្រៀបធៀបអក្សរ (String matching) កន្សោម రెగ్యులರ್ (Regex) ឬក៏អាចប្រើ Model ផ្សេងទៀតធ្វើជាผู้ตัดสิน (LLM-as-judge) ដើម្បីវាយតម្លៃថា «តើចម្លើយនេះបានដកស្រង់ប្រភពដើមបានត្រឹមត្រូវដែរឬទេ?»។ ប្រសិនបើក្រុមហ៊ុន Startup ដែលបានរៀបរាប់នៅពេលដើមមានលក្ខខណ្ឌអះអាងថា «លេខមាត្រាគោលការណ៍ដែលបានរៀបរាប់នៅក្នុងចម្លើយ ត្រូវតែមានពិតប្រាកដ» នោះមាត្រាទី ៧ នោះគឺមិនអាចដាក់ឱ្យដំណើរការបានឡើយ។

ការធ្វើតេស្តក្រុមក្រហម (Red Teaming) ក៏ត្រូវបានធ្វើឡើងនៅស្រទាប់នេះផងដែរ។ Promptfoo អាចដំណើរការសំណុំនៃការបញ្ចូលប្រឆាំង (Adversarial inputs) ដែលព្យាយាមធ្វើឱ្យ Agent លេចធ្លាយ system prompt គេចវេសពីកម្រិតកំណត់ និងប្រតិបត្តិសកម្មភាពដែលមិនគួរធ្វើ។ ប្រសិនបើអ្នកមិនវាយប្រហារវាទេ នោះអ្នកប្រើប្រាស់ (ឬអ្នកមានចេតនាអាក្រក់) នឹងវាយប្រហារជំនួសអ្នក។ ដូច្នេះគួរតែរៀបចំការវាយប្រហារដោយខ្លួនឯងជាមុនសិន។

វិធីសាស្ត្រ Debug៖ AgentOps

ការវាយតម្លៃប្រាប់អ្នកថា «ចម្លើយខុសហើយ» ប៉ុន្តែវាមຶ່ງមិនប្រាប់អ្នកថា «ខុសនៅជំហានទីប៉ុន្មាន» នោះទេ។ ការបំបាត់កំហុសច្រើនជំហាន (Multi-step debug) គឺត្រូវពឹងផ្អែកលើ AgentOps។

វាភ្ជាប់ការប្រតិបត្តិពេញមួយជុំរបស់ Agent ទៅជាបន្ទាត់ពេលវេលាដែលអាចចាក់សារថ្មីបាន៖ ជំហានទីមួយបានហៅ Tool អ្វី បញ្ជូន Parameter អ្វី ទទួលបានអ្វីមកវិញ ចាយ Token អស់ប៉ុន្មាន ជំហានទីពីរផ្អែកលើអ្វីដើម្បីសម្រេចចិត្តជំហានបន្ទាប់... គឺបង្ហាញចេញមកទាំងអស់។ ចំពោះឧទាហរណ៍នៃគោលការណ៍សងប្រាក់វិញនោះ វានឹងត្រូវបានមើលឃើញយ៉ាងច្បាស់នៅក្នុង AgentOps — បំណែកឯកសារដែលត្រូវបានទាញយកមកវិញនៅជំហានជាក់លាក់ណាមួយគឺខុសស្រាប់ទៅហើយ ចំណែកឯជំហានក្រោយៗទៀតសុទ្ធតែជាការសន្និដ្ឋានសមហេតុផលដែលផ្អែកលើទិន្នន័យខុស។ បើគ្មានខ្សែ្សដំណើរការនេះទេ អ្នកនឹងអង្គុយមើលចម្លើយចុងក្រោយដោយទាល់តម្រិះ។

វិធីសាស្ត្រតាមដាន៖ Langfuse

ការដាក់ឱ្យដំណើរការមិនមែនជាទីបញ្ចប់នោះទេ ប៉ុន្តែវាគឺជាការចាប់ផ្តើមមួយផ្សេងទៀត។ ការបញ្ចូលទិន្នន័យនៅក្នុងបរិយាកាសផលិតកម្ម (Production) គឺមានភាពចម្រុះជាខ្លាំង ហើយអ្នកប្រើប្រាស់នឹងសួរសំណួរដែលអ្នកមិនធ្លាប់នឹកគិតដល់សូម្បីតែពេលកំពុងធ្វើតេស្ត។ Langfuse ទទួលខុសត្រូវក្នុងការកត់ត្រារាល់ការសន្ទនាអនឡាញ តម្លៃ Token នីមួយៗ និងការពន្យារពេល (Latency) នីមួយៗក្នុងរយៈពេលវែង ដែលអនុញ្ញាតឱ្យអ្នកតាមដានថាតើគុណភាពមានការរសាត់អណ្តែត (Drift) តាមពេលវេលាដែរឬទេ ប្រភេទបញ្ហាណាដែលឆ្លើយបានយ៉ាប់បំផុត និងថាតើថ្លៃដើមមិនអាចគ្រប់គ្រងបានដែរឬទេ។

ការបែងចែកការងាររវាងវា និង AgentOps គឺ៖ AgentOps ប្ររោសទៅលើការ Debug ស៊ីជម្រៅតែមួយដងក្នុងដំណាក់កាលអភិវឌ្ឍន៍ ចំណែកឯ Langfuse ប្ររោសទៅលើការតាមដានជាក្រុមរយៈពេលវែងនៅលើអនឡាញ។ នៅក្នុងការអនុវត្តជាក់ស្តែង ក្រុមការងារជាច្រើនគឺប្រើប្រាស់ទាំងពីរ។ ចំណុចសំខាន់គឺ — អ្នកត្រូវតែមានកន្លែងមួយដែលអាចឆ្លើយបានគ្រប់ពេលវេលាថា «តើ Agent របស់ខ្ញុំមានដំណើរការយ៉ាងដូចម្តេចខ្លះនៅសប្តាហ៍នេះ?»។ ប្រសិនបើអ្នកមិនអាចឆ្លើយបានទេ គឺស្មើនឹងអ្នកកំពុងដើរអាក្រាតកាយ។

របាំងការពារ (Guardrails): ស្រទាប់ស្ទាក់ចាប់ចុងក្រោយ

ការវាយតម្លៃ ការ Debug និងការតាមដាន គឺជា «ការដឹងក្រោយពេលកើតហេតុ ឬមុនពេលកើតហេតុ» ចំណែកឯរបាំងការពារ (Guardrails) គឺ «ការស្ទាក់ចាប់ភ្លាមៗនៅពេលនោះ»។ មុនពេល Agent ធ្វើសកម្មភាពគ្រោះថ្នាក់ — ការបង់ប្រាក់ ការលុបទិន្នន័យ ការផ្ញើចេញក្រៅ ការប្រតិបត្តិបញ្ជាប្រព័ន្ធ — គឺត្រូវបន្ថែមស្រទាប់ពិនិត្យច្បាប់ ឬការបញ្ជាក់ពីមនុស្ស។

អ្វីដែលរបាំងការពារគួរស្ទាក់ចាប់៖ លាក់បាំងទិន្នន័យផ្ទាល់ខ្លួន ឬទិន្នន័យសម្ងាត់នៅពេលបង្ហាញលទ្ធផល បញ្ជូនបន្តទៅមនុស្សនៅពេលចំនួនទឹកប្រាក់លើសកម្រិតកំណត់ និងបញ្ឈប់នៅពេលរកឃើញការបញ្ចូល prompt injection។ ស្រទាប់នេះគឺត្រូវប្រើគូគ្នាជាមួយនឹងប្រអប់ខ្សាច់ប្រតិបត្តិ (Execution sandbox) នៅក្នុង Toolchain (ឧទាហរណ៍ដូចជា Blaxel) — ប្រអប់ខ្សាច់កំណត់វាថា «អាចរត់អ្វីបាន» ចំណែកឯរបាំងការពារកំណត់វាថា «អាចធ្វើអ្វីបាន»។

ចំណុចសំខាន់នៃការត្រួតពិនិត្យសម្រាប់ក្រុមការងារបីប្រភេទ

អ្នកអភិវឌ្ឍន៍ផ្ទាល់ខ្លួននៅតៃវ៉ាន់: យ៉ាងហោចណាស់ត្រូវភ្ជាប់ Promptfoo ចូលគ្នា។ ទោះបីជាមានករណីធ្វើតេស្តត្រឹមតែម្ភៃក៏ដោយ ក៏នៅតែប្រសើរជាងការកែប្រែរួចហើយពឹងផ្អែកលើអារម្មណ៍ដែរ។ សម្រាប់ការធ្វើតេស្តក្រុមក្រហម សូមជ្រើសរើសផ្ទៃវាយប្រហារដ៏គ្រោះថ្នាក់បំផុតចំនួនបន្តិចបន្តួចដើម្បីរត់ កុំស្វែងរកភាពពេញលេញហួសហេតុពេក។

ក្រុម Startup: គួរតែប្រញាប់ប្រញាលភ្ជាប់ AgentOps និង Langfuse ឱ្យបានឆាប់។ ផលិតផលរបស់អ្នកនៅតែស្ថិតក្នុងដំណាក់កាលអភិវឌ្ឍន៍លឿន ប្រសិនបើគ្មានភាពអាចសង្កេតបានទេ រាល់ពេលដែលមានបញ្តហាកើតឡើង គឺក្រុមការងារទាំងមូលត្រូវរុករកនៅក្នុងកងសមុទ្រ log ដែលពេលវេលារុករកនោះគឺគ្រប់គ្រាន់សម្រាប់អ្នកបង្កើតមុខងារថ្មីពីរផ្សេងទៀតទៅហើយ។ របាំងការពារគួរតែផ្តល់អាទិភាពដល់ការការពារសកម្មភាព «ចាយលុយ» និង «មិនអាចដកថយវិញបាន»។

សហគ្រាសធំៗ: ការធ្វើតេស្តក្រុមក្រហម និងរបាំងការពារ គឺជាបន្ទាត់ក្រហមនៃការអនុលោមតាមច្បាប់ (Compliance)។ សំណួរដែលផ្នែកសន្តិសុខ និងផ្នែកច្បាប់នឹងសួរគឺ «តើទិន្នន័យនឹងលេចធ្លាយដែរឬទេ?» «តើអាចធ្វើសវនកម្មលើការសម្រេចចិត្តនីមួយៗបានដែរឬទេ?» ចម្លើយគឺត្រូវបានលាក់ទុកនៅក្នុងកំណត់ត្រាតេស្តប្រឆាំងរបស់ Promptfoo និងដានដំណើរការរបស់ AgentOps។ ការរក្សាទុកកំណត់ត្រាទាំងនេះ គឺស្មើនឹងការរៀបចំភស្តុតាងសវនកម្មទុកជាមុន។

បញ្ជីត្រួតពិនិត្យមុនពេលដាក់ឱ្យដំណើរការ (Checklist)

អនុវត្តតាមនេះផ្ទាល់៖

• មានសំណុំសំណួរធ្វើតេស្តដែលយ៉ាងហោចណាស់គ្របដណ្តប់លើស្ថានភាពទូទៅ និងស្ថានភាពគែម (Edge cases) ដែលរត់នៅលើ Promptfoo
• រាល់ពេលដែលកែប្រែ prompt ឬប្តូរ model គឺត្រូវរត់ការវាយតម្លៃពេញលេញ ហើយពិន្ទុមិនត្រូវថយចុះឡើយទើបដាក់ឱ្យដំណើរការ
• បានធ្វើការធ្វើតេស្តក្រុមក្រហមយ៉ាងហោចណាស់ម្តង ដោយបានសាកល្បង prompt injection ការហួសដែនកំណត់ និងការនិយាយភូត
• ចំពោះចម្លើយប្រភេទ «ការអះអាងពីការពិត» គឺមានការពិនិត្យអះអាងថាប្រភពមានពិតប្រាកដ
• ដំណើរការច្រើនជំហានត្រូវបានភ្ជាប់ជាមួយ AgentOps ដែលអាចចាក់សារថ្មីដើម្បីកំណត់ទីតាំងខុសនៅពេលមានកំហុស
• បានតភ្ជាប់ Langfuse នៅលើអនឡាញ ដែលអាចមើលឃើញការរសាត់អណ្តែតនៃគុណភាព និងថ្លៃដើម
• មានរបាំងការពារ ឬការបញ្ជាក់ពីមនុស្សមុនពេលធ្វើសកម្មភាពគ្រោះថ្នាក់ (ការបង់ប្រាក់ ការលុប ការផ្ញើចេញក្រៅ)
• បានកំណត់ដែនកំណត់ Token និងថ្លៃដើម ដើម្បីជៀសវាងការដុតលុយពី Agent ផ្ទៃខាងหลัง
• ការប្រតិបត្តិ კូដដែលមានគ្រោះថ្នាក់ត្រូវបានរត់នៅក្នុងប្រអប់ខ្សាច់ (Sandbox)
• មានមនុស្សម្នាក់ដែលដឹងថាត្រូវមើលកន្លែងណាដំបូងគេនៅពេលមានបញ្ហាកើតឡើង

TheAIacademy ការសន្ដិដ្ឋាននិងមតិយោបល់

ហានិភ័យដ៏ធំបំផុតនៃការដាក់ឱ្យដំណើរការ Agent មិនដែលមែនមកពីបច្ចេកវិទ្យាមិនសប្ដាប់ខ្លាំងនោះទេ ប៉ុន្តែគឺមកពី «អ្នកមិនដឹងថាវាធ្វើខុសនៅពេលណានោះទេ។» ការវាយតម្លៃធ្វើឱ្យអ្នកដឹងមុន ភាពអាចសង្កេតបានធ្វើឱ្យអ្នកអាចស្រាវជ្រាវក្រោយពេលកើតហេតុ និងរបាំងការពារធ្វើឱ្យអ្នកស្ទាក់ចាប់បានភ្លាមៗ — តម្លៃនៃរឿងទាំងបីនេះ គឺកម្រនឹងមានអារម្មណ៍ដឹងណាស់ក្នុងពេលធម្មតា ប៉ុន្តែវានឹងជួយសង្គ្រោះជីវិតអ្នកនៅថ្ងៃដែលមានបញ្ហាកើតឡើង។

«Agent ដែលអ្នកមិនអាចមើលឃើញផ្នែកខាងក្នុង និងមិនអាចវាស់វែងគុណភាពបាន ទោះបីជាដំណើរការរលូនយ៉ាងណាក៏ដោយ ក៏វាជាគ្រាប់បែកពេលកំណត់ដែរ។ ភាពមធ្យមដែលត្រូវបានត្រួតពិនិត្យគឺប្រសើរជាងភាពឆ្លាតវៃដែលមើលមិនឃើញជាច្រើនဆណាស់។»

យោបល់ជាក់ស្តែងសម្រាប់អ្នកអាននៅតៃវ៉ាន់៖ មុនពេលដាក់ឱ្យដំណើរការ សូមបង្ខំខ្លួនឯងឱ្យឆ្លើយសំណួរមួយ — «ប្រសិនបើថ្ងៃស្អែកវាធ្វើខុសមួយរឿងនៅចំពោះមុខអតិថិជន តើខ្ញុំត្រូវការពេលប៉ុន្មានទើបអាចរកឃើញថាវាខុសនៅជំហានណា និងដោយសារមូលហេតុអ្វី?» ប្រសិនបើមិនអាចឆ្លើយថា «ក្នុងរយៈពេលដប់នាទី» ទេ សូមកុំទាន់ដាក់ឱ្យដំណើរការអី សូមត្រឡប់ទៅបំពេញបន្ថែមស្រទាប់ Promptfoo, AgentOps និង Langfuse ទាំងបីនេះសិន។ ចំពោះរបៀបផ្គុំ Toolchain ពេញលេញ អ្នកអាចមើលអត្ថបទមុន 〈ដ្យាក្រាមបង្ហាញពី Toolchain របស់អ្នកអភិវឌ្ឍន៍ឆ្នាំ 2026 全图解〉។