ចង់បង្កើត AI Agent ផ្ទាល់ខ្លួន តើត្រូវរៀបចំឧបករណ៍អ្វីខ្លះ? បង្ហាញពីប្រព័ន្ធឧបករណ៍សម្រាប់អ្នកអភិវឌ្ឍន៍

នៅរសៀលថ្ងៃសុក្រមួយ មិត្តភក្តិម្នាក់បានផ្ញើវីដេໂូបង្ហាញពី Agent (ភ្នាក់ងារ AI) របស់គាត់មកឱ្យខ្ញុំ៖ អ្នកប្រើប្រាស់វាយសារតែមួយ នោះ Agent អាចស្វែងរកទិន្នន័យដោយខ្លួនឯង ហៅ API ចំនួនបី និងបញ្ចេញមកវិញនូវរបង្ខាប់សេចក្តីយ៉ាងមានរបៀបរៀបរយ។ ពិតជាអស្ចារ្យណាស់។ ខ្ញុំបានសួរគាត់ថា៖ «ដាក់ឱ្យប្រើប្រាស់ជាផ្លូវការ (Online) ហើយឬនៅ?» គាត់នៅស្ងៀមពីរវិនាទី រួចតបថា៖ «កំណែដែលដាក់ឱ្យប្រើប្រាស់នៅលើប្រព័ន្ធ (Online) ាលពីម្សិលមិញបានច្រឡំយកលេខកូដបញ្ជាទិញរបស់អតិថិជនទៅដាក់ក្នុងដំណើរការស្នើសុំប្រាក់វិញ ឥឡូវនេះពួកយើងមិនដឹងថាវាខុសនៅជំហានណានោះទេ។»

នេះគឺជាឧបសគ្គដ៏ធំមួយដែលក្រុមអភិវឌ្ឍន៍ Agent ស្ទើរតែគ្រប់រូបតែងតែជួបប្រទះ។ ការបង្ហាញមុខងារ (Demo) គឺជាផ្លូវស្រួល ប៉ុន្តែបរិយាកាសផលិតកម្ម (Production) គឺដូចជាសំណាញ់មួយអញ្ចឹងដែរ ដែលរាល់节点 (Nodes) ទាំងអស់ប្រសិនបើមានកំហុសឆ្គងកើតឡើង ខ្សែសង្វាក់ទាំងមូលនឹងត្រូវកាត់ផ្តាច់ ហើយជាញឹកញាប់អ្នកថែមទាំងមិនដឹងថាវាដាច់នៅត្រង់ចំណុចណាមួយផង។ ភាពខុសគ្នាមិនមែនស្ថិតនៅលើការដែលម៉ូដែល (Model) នោះឆ្លាតប៉ុណ្ណាហกនោះទេ ប៉ុន្តែវាស្ថិតនៅលើខ្សែសង្វាក់ឧបករណ៍ (Toolchain) នៅពីក្រោយអ្នកថាមានភាពគ្រប់គ្រាន់កម្រិតណា។

ហេតុអ្វីបានជាឆ្នាំ ២០٢៦ គឺជាសម័យកាលនៃ «ខ្សែសង្វាក់ឧបករណ៍ (Toolchain)» ជំនួសឱ្យ «ក្របខ័ណ្ឌតែមួយ (Framework)»

នៅឆ្នាំ ២០២៣ និង ២០២៤ មនុស្សគ្រប់គ្នាតែងតែសួរថា «តើត្រូវប្រើប្រាស់ក្របខ័ណ្ឌមួយណាដើម្បីបង្កើត Agent?»។ ដល់ឆ្នាំ ២០២៦ សំណួរនេះលែងត្រឹមត្រូវទៀតហើយ។ ក្របខ័ណ្ឌ (Frameworks) គ្រាន់តែជាស្រទាប់ខាងលើបំផុតតែប៉ុណ្ណោះ។ Agent មួយដែលពិតជាអាចដាក់ឱ្យដំណើរការលើប្រព័ន្ធ (Online) អាចថែទាំបាន និងអាចរកមូលហេតុពេលមានបញ្តហាកើតឡើង គឺនៅពីក្រោយមាន Stack ដែលមានការបែងចែកការងារយ៉ាងច្បាស់លាស់ ដូចជាវិស្វកម្មខាងក្រោយ (Backend engineering) គឺមិនត្រឹមតែមាន Web framework តែមួយនោះទេ ប៉ុន្តែថែមទាំងត្រូវមាន Database, Cache, Logs, Monitoring និង CI/CD ផងដែរ។

ចំណុចពិសេសរបស់ Agent គឺវាមាន «ភាពមិនប្រាកដប្រជា (Uncertainty)»។ ជាមួយនឹងទិន្នន័យបញ្ចូល (Input) ដូចគ្នា ម៉ូដែល (Model) អាចនឹងផ្តល់នូវជំហានផ្សេងគ្នា វាសម្រេចចិត្តដោយខ្លួនឯងថាតើត្រូវហៅឧបករណ៍ ឬហៅមួយណា។ ភាពមិនប្រាកដប្រជានេះធ្វើឱ្យទម្លាប់នៃការអភិវឌ្ឍន៍បែបប្រពៃណីដូចជា «សរសេររួចដំណើរការ បើខូចមើល stack trace» ក្លាយជាគ្មានប្រយោជន៍ទាំងស្រុង។ អ្នកត្រូវការស្រទាប់ឧបករណ៍ថ្មីៗ ដែលបង្កើតឡើងជាពិសេសដើម្បីដោះស្រាយបញ្ហាដូចជា «ហេតុអ្វីបានជាវាធ្វើបែបនេះ» «តើវាធ្វើត្រូវឬអត់» និង «តើវាមានបញ្ហាអ្វីកើតឡើងទៀតពេលនៅលើប្រព័ន្ធ (Online)»។

ចំណុចសំខាន់៖ ការបែងចែកខ្សែសង្វាក់ឧបករណ៍ជាប្រាំមាត្រដ្ឋាន (Six Layers)

ខ្ញុំធ្លាប់ទម្លាប់បែងចែកខ្សែសង្វាក់ឧបករណ៍របស់ Agent ដែលបង្កើតដោយខ្លួនឯងជាប្រាំមាត្រដ្ឋាន ដោយចាប់ពីលើចុះក្រោម៖

• ស្រទាប់ក្របខ័ណ្ឌ (Framework Layer)៖ កំណត់ពីរបៀបដែល Agent ត្រូវកំណត់ របៀបហៅឧបករណ៍ និងរបៀបគ្រប់គ្រងដំណើរការច្រើនជំហាន។
• ស្រទាប់ទាញយកទិន្នន័យ (RAG Layer)៖ អនុញ្ញាតឱ្យ Agent អាចអានទិន្នន័យឯកជនរបស់អ្នកបាន ជំនួសឱ្យការគ្រាន់តែទន្ទេញចាំចំណេះដឹងដែលមានស្រាប់នៅក្នុង Model។
• ស្រទាប់ប្រអប់ខ្សាច់ប្រតិបត្តិការ (Execution Sandbox Layer)៖ នៅពេលដែល Agent ត្រូវរត់កូដ (Code) ឬប្រតិបត្តិពាក្យបញ្ជា (Commands) ត្រូវផ្តល់ឱ្យវានូវកន្លែងបិទជិតមួយដែលមិនអាចចេញក្រៅបាន។
• ស្រទាប់រង្វាស់និងការសង្កេត (Observability Layer)៖ កត់ត្រារាល់ជំហាននៃការ推理 (Reasoning) និងរាល់ការហៅឧបករណ៍ (Tool call) នីមួយៗ ដើម្បីឱ្យអ្នកអាចមើលឃើញពីអ្វីដែលវាកំពុងគិត។
• ស្រទាប់វាយតម្លៃ និងសុវត្ថិភាព (Evaluation and Security Layer)៖ មុនពេលដាក់ឱ្យដំណើរការ សូមប្រើប្រាស់សំណុំសំណួរថេរដើម្បីវាស់ស្ទង់ការអនុវត្តរបស់វា និងធ្វើការធ្វើតេស្ត Red-teaming ក្នុងពេលដំណាលគ្នា។
• ស្រទាប់ដាក់ឱ្យដំណើរការ (Deployment Layer)៖ ដាក់ពង្រាយរបស់ទាំងអស់នេះទៅលើប្រព័ន្ធ (Online) យ៉ាងស្ថិតស្ថេរ និងអាចពង្រីកបាន។

មិនមែនគ្រប់គម្រោងទាំងអស់សុទ្ធតែត្រូវបើកដំណើរការទាំងប្រាំមាត្រដ្ឋាននេះទេ។ ប៉ុន្តែយ៉ាងហោចណាស់អ្នកត្រូវដឹងថាស្រទាប់នីមួយៗមានវត្តមាន និងដឹងថាខ្លួនឯងកំពុងខ្វះខាតស្រទាប់ណាមួយ។

ការបំបែកតាមស្រទាប់៖ តើស្រទាប់នីមួយៗដោះស្រាយអ្វីខ្លះ ហើយពេលណាក្រុមហ៊ុនទើបត្រូវការវា?

ស្រទាប់ក្របខ័ណ្ឌ៖ Pydantic AI និង LangChain

ក្របខ័ណ្ឌជួយអ្នកក្នុងការគ្រប់គ្រង «របៀបភ្ជាប់ម៉ូដែល ឧបករណ៍ និងដំណើរការចូលគ្នា»។ Pydantic AI គឺជាជម្រើសដែលវិស្វករ Python ជាច្រើនបានប្តូរមកប្រើប្រាស់ក្នុងរយៈពេលពីរឆ្នាំចុងក្រោយនេះ ព្រោះវាចងទិន្នន័យលទ្ធផលជាមួយនឹង type schema យ៉ាងតឹងរ៉ឹង — អ្វីដែល Agent ឆ្លើយតបមកវិញ គឺជាវត្ថុដែលមានរចនាសម្ព័ន្ធ និងត្រូវបានផ្ទៀងផ្ទាត់រួចជាស្រេច មិនមែនជាអត្ថបទ (String) ដែលត្រូវយកមកញែក (Parse) ដោយខ្លួនឯងនោះទេ។ សម្រាប់អ្នកដែលមានប្រភពមកពី backend និងធ្លាប់សរសេរកូដដែលមានកំណត់ប្រភេទប្រភេទ (Types) គឺងាយស្រួលប្រើប្រាស់ណាស់។

ចំណែកឯ LangChain គឺជាជ្រុងម្ខាងទៀត៖ វាមានប្រព័ន្ធអេកូឡូស៊ីធំបំផុត និងមានការរួមបញ្ចូលច្រើនបំផុត ដែលស្ទើរតែមានអ្វីៗគ្រប់យ៉ាងស្រាប់សម្រាប់ភ្ជាប់។ តម្លៃដែលត្រូវបង់គឺស្រទាប់អរូបី (Abstraction layer) ក្រាស់ និងកំណែប្រែរហ័ស ដែលការយកទៅប្រើប្រាស់ក្នុងគម្រោងខ្នាតតូចច្រើនតែក្លាយជាការប្រើកាំបិតសម្លាប់មាន់ទៅកាប់ក្របី។ យោបល់របស់ខ្ញុំ៖ ប្រសិនបើដំណើរការសាមញ្ញ និងលទ្ធផលត្រូវការជារចនាសម្ព័ន្ធ សូមសាកល្បង Pydantic AI មុន; ប្រសិនបើត្រូវភ្ជាប់ការរួមបញ្ចូលដែលមានស្រាប់ច្រើន ហើយក្រុមការងារបានចេះស្ទាត់ជំនាញ LangChain រួចហើយ ចាំប្រើវា។ កុំគ្រាន់តែឃើញ «អ្នកផ្សេងប្រើទាំងអស់គ្នា» ហើយជ្រើសរើសវាដោយមិនបានគិត។

ស្រទាប់ទាញយកទិន្នន័យ (RAG)៖ RAGFlow

ប្រសិនបើ Agent មិនបានភ្ជាប់ជាមួយ RAG ទេ វាអាចឆ្លើយបានតែអ្វីដែលម៉ូដែលចងចាំក្នុងពេលបណ្តុះបណ្តាលប៉ុណ្ណោះ ហើយនៅពេលជួបឯកសារផ្ទៃក្នុងរបស់ក្រុមហ៊ុនអ្នក ឬលក្ខណៈបច្ចេកទេសផលិតផលចុងក្រោយ វានឹងចាប់ផ្តើមនិយាយកុហក (Hallucination) ហើយ។ RAGFlow ដោះស្រាយផ្នែកដែលត្រូវបានគេមើលស្រាលបំផុតនៅក្នុងខ្សែសង្វាក់នេះ៖ ការកាត់បំណែកឯកសារ ការវិភាគ ការបម្លែងជា Vector និងការទាញយក។ វា 처리 ឯកសារ PDF តារាង និងឯកសារដែលមានប្លង់ស្មុគស្មាញបានល្អិតល្អន់ជាងកញ្ចប់ RAG ទូទៅ ដែលធ្វើឱ្យមានអារម្មណ៍យ៉ាងខ្លាំងនៅក្នុងសេណារីតាលក់ទំនិញនៅតៃវ៉ាន់ ដែលសហគ្រាសជាច្រើនពោរពេញទៅដោយកិច្ចសន្យា PDF និងសៀវភៅបញ្ជាក់លក្ខណៈបច្ចេកទេស។ តើពេលណាទើបត្រូវការ? ដរាបណា Agent របស់អ្នកត្រូវឆ្លើយសំណួរ «មានតែរឿងខាងក្នុងក្រុមហ៊ុនទេទើបដឹង» នោះអ្នកត្រូវការវាហើយ។

ស្រទាប់ប្រអប់ខ្សាច់ប្រតិបត្តិការ (Execution Sandbox)៖ Blaxel

នៅពេលដែល Agent របស់អ្នកចាប់ផ្តើម «សរសេរកូដដោយខ្លួនឯងហើយរត់» នោះគ្រោះថ្នាក់នឹងកើតឡើងហើយ។ វាអាចនឹងរត់ចូលទៅក្នុងរង្វង់គ្មានទីបញ្ចប់ (Infinite loop) អាចអានឯកសារដែលមិនគួរអាន ឬអាចហៅបណ្តាញខាងក្រៅ។ ប្រអប់ខ្សាច់ប្រតិបត្តិការដូចជា Blaxel ផ្តល់ឱ្យ Agent នូវបរិយាកាសដាច់ដោយឡែកមួយដើម្បីដំណើរការសកម្មភាពដែលមិនអាចគ្រប់គ្រងទាំងនេះ ហើយសូម្បីតែពេលវាខូចក៏វាមិនធ្វើឱ្យខូចម៉ាស៊ីនមេរបស់អ្នកដែរ។ ប្រសិនបើ Agent របស់អ្នកគ្រាន់តែស្វែងរកទិន្នន័យ និងហៅ API ដែលមានស្រាប់ អ្នកអាចមិនទាន់ត្រូវការវាទេ ប៉ុន្តែនៅពេលដែលវាត្រូវប្រតិបត្តិកម្មវិធីស្វ័យប្រវត្តិ ប្រអប់ខ្សាច់មិនមែនជាជម្រើសបន្ថែមទេ ប៉ុន្តែជាកាតព្វកិច្ច។

ស្រទាប់រង្វាស់និងការសង្កេត (Observability)៖ AgentOps និង Langfuse

នេះគឺជាស្រទាប់ដែលមិត្តភក្តិដែលបានរៀបរាប់នៅដើមអត្ថបទខ្វះខាតខ្លាំងបំផុត។ នៅពេលដែល Agent រត់បានច្រើនជំហាន តើមានអ្វីខ្លះត្រូវបានគេហៅនៅកណ្តាល តើជំហាននីមួយៗប្រើប្រាស់ token ប៉ុន្មាន និងតើជំហានណាដែលเริ่มខុសប្រក្រតី ប្រសិនបើគ្មានឧបករណ៍កត់ត្រាទេ អ្នកពិតជាមិនអាចមើលឃើញវាទាល់តែសោះ។ AgentOps ផ្តោតលើគន្លងប្រតិបត្តិការរបស់ Agent — ភ្ជាប់រាល់ step និង tool call នីមួយៗទៅជាបន្ទាត់ពេលវេលាដែលអាចចាក់សារថ្មីបាន ដែលវាជាសង្គ្រោះជីវិតនៅពេល debug ដំណើរការច្រើនជំហាន។ ចំណែកឯ Langfuse គឺមានទំនោរទៅរកការត្រួតពិនិត្យ និងការវិភាគតាមអ៊ីនធឺណិត (Online monitoring) ដែលស័ក្តិសមសម្រាប់ការកត់ត្រារាល់ការសន្ទនា និងរាល់តម្លៃចំណាយទាំងអស់ក្នុងបរិយាកាសផលិតកម្មដើម្បីតាមដានក្នុងរយៈពេលវែង។ មុខងារទាំងពីរនេះមានភាពត្រួតស៊ីគ្នាបន្តិច ប៉ុន្តែផ្តោតលើចំណុចខុសគ្នា ដែលខ្ញុំនឹងពិភាក្សាលម្អិតអំពីរបៀបផ្សំវានៅក្នុងអត្ថបទមួយទៀតស្តីពីការវាយតម្លៃ និងសុវត្ថិភាព។

ស្រទាប់វាយតម្លៃ និងសុវត្ថិភាព (Evaluation and Security)៖ Promptfoo

អ្វីដែលគួរឱ្យខ្លាចបំផុតរបស់ Agent មិនមែនជាការគាំង (Crash) នោះទេ ប៉ុន្តែគឺ «ការធ្វើខុសដោយស្ងៀមស្ងាត់» — វាបានផ្តល់ចម្លើយដែលមើលទៅហាក់ដូចជាមានហេតុផល ប៉ុន្តែការពិតវាខុស ហើយគ្មាននរណាម្នាក់ដឹងនោះទេ។ Promptfoo អនុញ្ញាតឱ្យអ្នកជួសជុលសំណុំករណីសាកល្បងឱ្យបានថេរ ដែលរាល់ពេលដែលអ្នកកែប្រែ prompt ឬប្តូរ model អ្នកអាចរត់វាម្តងទៀត ដើម្បីវាស់ស្ទង់មើលថាតើគុណភាពចម្លើយបានធ្លាក់ចុះដែរឬទេ ហើយក្នុងពេលជាមួយគ្នានេះធ្វើការធ្វើតេស្ត Red-teaming ដើម្បីស្វែងរកចំណុចខ្សោយដែលត្រូវបានគេរំលង។ ស្មារតីនៃស្រទាប់នេះគឺការប្តូរពី «ខ្ញុំគិតថាវាប្រសើរជាងមុន» ទៅជា «តួលេខបានប្រាប់ថាវាប្រសើរជាងមុន»។ ប្រសិនបើអ្នកចង់យល់ពីវិធីសាស្ត្រពេញលេញ អ្នកអាចបន្តអានអត្ថបទ 〈មុនពេល AI Agent ដាក់ឱ្យដំណើរការ អ្នកត្រូវតែធ្វើការត្រួតពិនិត្យការវាយតម្លៃ និងសុវត្ថិភាព〉។

ស្រទាប់ដាក់ឱ្យដំណើរការ (Deployment)៖ Northflank

ចុងក្រោយគឺការដាក់ពង្រាយប្រព័ន្ធទាំងមូលឱ្យដំណើរការលើប្រព័ន្ធ (Online)។ ការដាក់ពង្រាយ Agent គឺមានភាពស្មុគស្មាញជាងសេវាកម្ម Web ទូទៅ៖ វាត្រូវដំណើរការរយៈពេលយូរ ត្រូវរត់កិច្ចការ පසුបៀង (Background tasks) និងពេលខ្លះត្រូវគ្រប់គ្រងកុងតែន័រប្រអប់ខ្សាច់ (Sandbox containers) ផងដែរ។ វេទិកាដូចជា Northflank ជួយអ្នកក្នុងការគ្រប់គ្រងកុងតែន័រ ការពង្រីក និង CI/CD ដែលធ្វើឱ្យអ្នកមិនចាំបាច់បង្កើត Kubernetes ពីដំបូងឡើយ។ ក្រុមការងារខ្នាតតូចអាចប្រើប្រាស់វាដើម្បីសន្សំសំចៃធនធានមនុស្សផ្នែក DevOps ម្នាក់។

ក្រុមបីប្រភេទ យុទ្ធសាស្ត្របីប្រភេទ

អ្នកអភិវឌ្ឍន៍បុគ្គលនៅតៃវ៉ាន់៖ កុំគិតចង់បើកដំណើរការទាំងប្រាំមាត្រដ្ឋានក្នុងពេលតែមួយ។ ដំបូងត្រូវប្រើ Pydantic AI ដើម្បីបង្កើតដំណើរការស្នូល (Core flow) ភ្ជាប់ជាមួយ Promptfoo ដើម្បីធានាថាមិនកាន់តែអាក្រក់ទៅៗពេលកែប្រែ ហើយស្រទាប់ផ្សេងទៀតត្រូវបំពេញបន្ថែមនៅពេលដែលអ្នកពិតជាជួបបញ្ហា។ ចំនួនឧបករណ៍ដែលមនុស្សម្នាក់អាចថែទាំបានគឺមានកម្រិត ដូច្នេះសូមព្យាយាមគ្រប់គ្រងវា។

ក្រុមការងារថ្មី (Startups)៖ រង្វាស់និងការសង្កេត (Observability) ត្រូវធ្វើឡើងតាំងពីដំបូង។ ខ្ញុំធ្លាប់ឃើញក្រុមការងារជាច្រើនទុក AgentOps និង Langfuse ថា «ចាំនិយាយគ្នាពេលក្រោយ» ជាលទ្ធផលនៅពេលមានបញ្តហាកើតឡើង ក្រុមការងារទាំងមូលត្រូវរុករកនៅក្នុងកាកសំណល់ log រយៈពេលបីថ្ងៃ។ ការតភ្ជាប់វាឱ្យបានឆ្នាប់ គឺស្មើនឹងការទិញធានារ៉ាប់រង។ ចំពោះស្រទាប់ដាក់ឱ្យដំណើរការ សូមប្រើប្រាស់វេទិកាគ្រប់គ្រងដូចជា Northflank ដោយផ្ទាល់ ដើម្បីសន្សំសំចៃពេលវេលាយកទៅកែលម្អផលិតផលវិញ។

សហគ្រាស (Enterprises)៖ RAG និងសុវត្ថិភាពគឺជាអាទិភាពខ្ពស់បំផុត។ ទិន្នន័យរបស់អ្នកมีความរសើប និងមានតម្រូវការអនុលោមភាពខ្ពស់ ដែលសមត្ថភាពដាក់ពង្រាយឯកជនរបស់ RAGFlow ការធ្វើតេស្ត Red-teaming របស់ Promptfoo និងការបែងចែកប្រអប់ខ្សាច់ (Sandbox isolation) សុទ្ធតែត្រូវគ្នាយ៉ាងត្រង់ទៅនឹងសំណួរដែលនាយកដ្ឋានគ្រប់គ្រងហានិភ័យនឹងសួរ។ វាត្រូវបានណែនាំឱ្យស្វែងរកសេណារីតាតូចមួយដើម្បីដំណើរការស្រទាប់ទាំងប្រាំមាត្រដ្ឋានឱ្យបានជោគជ័យមុនសិន មុននឹងធ្វើការចម្លងវាមុខក្រោយ។

វិធីសាស្ត្រជាក់ស្តែង៖ តើควรចាប់ផ្តើមពីស្រទាប់ណា?

ប្រសិនបើថ្ងៃនេះអ្នកត្រូវចាប់ផ្តើមធ្វើការ សណ្តាប់ធ្នាប់របស់ខ្ញុំគឺ៖ ក្របខ័ណ្ឌ (Pydantic AI) → ការវាយតម្លៃ (Promptfoo) → រង្វាស់និងការសង្កេត (AgentOps) → បំពេញបន្ថែម RAG (RAGFlow) និងប្រអប់ខ្សាច់ (Blaxel) តាមតម្រូវការ → ចុងក្រោយគឺការដាក់ពង្រាយ (Northflank)។

សូមចំណាំសណ្តាប់ធ្នាប់នេះ៖ ការវាយតម្លៃ និងការសង្កេតត្រូវបានຈັດដាក់មុន RAG។ ពីព្រោះ Agent ដែលគ្មានការវាយតម្លៃ និងមើលមិនឃើញពីខាងក្នុង ទោះបីជាបន្ថែមមុខងារប៉ុណ្ណាក៏ដោយ ក៏គ្រាន់តែជាការបង្កើនរបស់ដែលមិនអាចគ្រប់គ្រងបានឱ្យកាន់តែខ្ពស់ឡើងដែរ។ ដំបូងត្រូវធ្វើឱ្យវា «អាចវាស់វែងបាន និងអាចមើលឃើញ» មុននឹងធ្វើឱ្យវា «កាន់តែខ្លាំង»។ ប្រ