Models ធៀបនឹង Agents៖ ព្រំដែនដែលកំពុងផ្លាស់ប្ដូរ

នេះជាគំរូមួយដែលអ្នកសាងសង់ជាមួយ AI agent បានឆ្លងកាត់។ អ្នកចំណាយពេលជាច្រើនសប្ដាហ៍សាងសង់ scaffolding ព័ទ្ធជុំវិញ model — ខ្សែសង្វាក់ prompt ដ៏ប្រុងប្រយ័ត្នដើម្បីបង្ខំឱ្យមានការរៀបផែនការម្ដងមួយជំហានៗ ស្រទាប់ routing ដើម្បីជ្រើសរើសឧបករណ៍ត្រឹមត្រូវ កូដភ្ជាប់ (glue code) ដើម្បីបំបែកភារកិច្ចធំមួយទៅជាភារកិច្ចតូចៗ។ វាដំណើរការ។ អ្នកដាក់ឱ្យប្រើ។ បន្ទាប់មក model បន្ទាប់ចេញមក ធ្វើរឿងទាំងអស់នោះដោយ native ហើយ scaffolding ដ៏ឆ្លាតវៃរបស់អ្នកក្លាយជាបន្ទុកស្លាប់ដែលអ្នកត្រូវដកចេញភ្លាមៗ។

រឿងនេះកើតឡើងម្ដងហើយម្ដងទៀត ហើយវាលើកឡើងនូវសំណួរស្ថាបត្យកម្មដ៏ពិបាកមួយយ៉ាងពិតប្រាកដ — ប្រហែលជា សំណួរ ស្ថាបត្យកម្មនៃយុគសម័យ agentic៖ ខណៈដែល base model ស្រូបយកកាន់តែច្រើននៃអ្វីដែល agent framework ត្រូវបានសាងសង់ឡើងដើម្បីផ្ដល់ តើ scaffolding នៅសល់ប៉ុន្មានដែលនៅតែសំខាន់? តើស្រទាប់ agent ជាឈើច្រត់បណ្ដោះអាសន្នដែល model កំពុងលេបយកជាលំដាប់ — ឬជាផ្នែកដែលពិតជាប្រមូលផ្ដុំតាមពេលវេលា?

នេះមិនមែនជាការជជែកដេញដោលឥតបានការទេ។ ចម្លើយកំណត់កន្លែងណាដែលអ្នកគួរចំណាយកម្លាំងវិស្វកម្មរបស់អ្នកនៅពេលនេះ។ តោះយើងយកចិត្តទុកដាក់លើជ្រុងទាំងពីរយ៉ាងម៉ត់ចត់។

ស្រទាប់ពីរ stack មួយ

ដំបូង និយមន័យ ព្រោះការសន្ទនានេះកំពុងលង់ក្នុងពាក្យដែលត្រួតស៊ីគ្នា — SDK, scaffolding, framework, harness, agent។ Cobus Greyling និងអ្នកដទៃបានចំណាយកម្លាំងពិតប្រាកដក្នុងការបំបែកវាចេញពីគ្នា ហើយភាពខុសគ្នាដែលសំខាន់គឺសាមញ្ញ។ មានស្រទាប់ពីរ៖

• The model។ សមត្ថភាពឆៅ៖ ការវែកញែក ចំណេះដឹង ការរៀបផែនការ សមត្ថភាពក្នុងការជ្រើសរើស និងហៅឧបករណ៍។ អ្វីដែលអ្នកទទួលបានពី weights។
• The scaffolding ព័ទ្ធជុំវិញវា។ អ្វីៗគ្រប់យ៉ាងដែលប្រែ model ឆៅទៅជា agent ដែលដឹកនាំដោយគោលដៅ — prompt ម៉ូឌុល, memory, ការតភ្ជាប់ឧបករណ៍ និង orchestration ដែល ZBrain និងអ្នកដទៃពិពណ៌នាថា “scaffolding”។ នេះជា harness និង រង្វិលជុំ ដែលយើងបានសរសេរអំពី៖ runtime ដែលមិនមែនជា model ដែលធ្វើឱ្យ model ធ្វើ អ្វីៗបានដោយអាចទុកចិត្តបាន។

ការជជែក “models ធៀបនឹង agents” ទាំងមូលពិតជាសំណួរអំពីព្រំដែនរវាងស្រទាប់ទាំងពីរនេះ — ហើយសំខាន់បំផុត ទិសដៅណាដែលវាកំពុងផ្លាស់ប្ដូរ។ សមត្ថភាពមិនអង្គុយនៅស្ងៀមនៅជ្រុងណាមួយទេ។ វាផ្លាស់ទីលំនៅ។ ហើយទិសដៅនៃការផ្លាស់ទីលំនៅ គឺជាអ្វីដែលកំពុងមានជម្លោះ។

អំណះអំណាងសម្រាប់ “model កំពុងលេបយក agent”

កំណែខ្លាំងនៃជ្រុងមួយ ដែលត្រូវបានអះអាងយ៉ាងម៉ឺងម៉ាត់ដោយ DevIQ ក្នុងចំណោមអ្នកដទៃ គឺថា model កំពុងលេបយក agent។ ម៉ូដែលជួរមុខ (frontier model) ជំនាន់នីមួយៗស្រូបយកសមត្ថភាពដែលពីមុនត្រូវការ scaffolding ខាងក្រៅ៖

• ការរៀបផែនការ និងការបំបែក។ Agent ដំបូងៗត្រូវការខ្សែសង្វាក់ prompt ដ៏ល្អិតល្អន់ដើម្បីបង្ខំ model ឱ្យបំបែកភារកិច្ចទៅជាជំហានៗ។ Model ថ្មីៗរៀបផែនការដោយ native ក្នុងការហៅតែម្ដង ច្រើនតែល្អជាងខ្សែសង្វាក់ដែលសាងសង់ដោយដៃទៅទៀត។
• ការជ្រើសរើសឧបករណ៍។ តក្កវិជ្ជា routing ដើម្បីសម្រេចចិត្តថាត្រូវប្រើឧបករណ៍ណា កាន់តែលែងចាំបាច់ — model គ្រាន់តែជ្រើសរើសបានត្រឹមត្រូវ ប្រសិនបើផ្ដល់ការពិពណ៌នាឧបករណ៍ល្អ។
• ការវែកញែក និងការប្រតិបត្តិច្រើនជំហាន។ រង្វិលជុំ think-act-observe ដែល framework ត្រូវបានសាងសង់ឡើងដើម្បីដាក់បង្ខំ កំពុងក្លាយជាអ្វីដែល model ធ្វើនៅខាងក្នុង។

ផលប៉ះពាល់នេះមិនស្រួលសម្រាប់នរណាម្នាក់ដែលបានវិនិយោគយ៉ាងធ្ងន់ទៅលើ framework មួយ៖ scaffolding agent ភាគច្រើនគឺ បណ្ដោះអាសន្ន។ វាមានវត្តមានដើម្បីទូទាត់សងសម្រាប់ដែនកំណត់របស់ model ហើយនៅពេលដែលដែនកំណត់នោះបាត់ មូលហេតុនៃ scaffolding ក៏បាត់ដែរ។ តាមទស្សនៈនេះ ការភ្នាល់ស្ថាបត្យកម្មរបស់អ្នកលើដំណើរការដែលរៀបចំដោយដៃយ៉ាងល្អិតល្អន់ គឺការភ្នាល់ប្រឆាំងនឹងរបស់តែមួយដែលបានកែលម្អដោយអាចទុកចិត្តបាន៖ គឺ model ខ្លួនឯង។

នេះជាបាតុភូតពិតប្រាកដ និងកើតឡើងម្ដងហើយម្ដងទៀត។ ប្រសិនបើអ្នកធ្លាប់ដកខ្សែសង្វាក់រៀបផែនការចេញ ព្រោះ model ថ្មីមិនត្រូវការវា អ្នកបានដឹងអារម្មណ៍ព្រំដែនកំពុងផ្លាស់ប្ដូរ។ បំភ្លេចជ្រុងនេះ ហើយអ្នកនឹងបន្តសាងសង់ scaffolding ដែលមានអាយុកាលពាក់កណ្ដាល (half-life) ត្រឹមការចេញផ្សាយ model តែមួយ។

អំណះអំណាងសម្រាប់ harness

ប៉ុន្តែមានអំណះអំណាងប្រឆាំងដែលធ្ងន់ធ្ងរស្មើគ្នា ហើយវាជាអំណះអំណាងដែលយើងយល់ឃើញថាគួរឱ្យជឿជាងសម្រាប់កន្លែងណាដែល leverage ពិតជានៅ។

ការងារខ្សែមួយក្នុងឆ្នាំ ២០២៦ បានរៀបក្របខណ្ឌសំណួរនេះឡើងវិញជា system scaling ធៀបនឹង model scaling។ ទ្រឹស្ដី៖ model scaling (weights ធំជាង ឆ្លាតជាង) និង system scaling (memory, routing, orchestration, verification, governance) គឺជា អ័ក្សផ្សេងគ្នា។ Model ដែលកាន់តែល្អ មិនផ្ដល់ឱ្យអ្នកដោយខ្លួនវាផ្ទាល់នូវ memory ដែលស្ថិតស្ថេរនៅទូទាំងការដំណើរការវែង ការសម្របសម្រួល agent ច្រើន ការតាមដានសវនកម្ម (audit trail) សម្រាប់ការសម្រេចចិត្តដែលត្រូវបានគ្រប់គ្រង ឬជំហាន verification ដែលចាប់កំហុសដ៏មានទំនុកចិត្តរបស់ model ទេ។ ទាំងនោះជាលក្ខណៈនៅកម្រិត system។ វាមកពី harness មិនមែនពី weights ទេ។

ហើយនេះជាផ្នែកដែលផ្ទុយនឹងវិចារណញាណ៖ ខណៈដែល model កាន់តែ មានសមត្ថភាព ហើយអ្នកទុកចិត្តពួកវាជាមួយការងារ horizon វែងជាង គ្រោះថ្នាក់ខ្ពស់ជាង តម្រូវការនៅកម្រិត system មិនរួញតូចទេ — វា រីកធំ។ Agent ដែលស្វយ័តជាងត្រូវការ verification ច្រើនជាង មិនមែនតិចជាងទេ។ Agent ដែលធ្វើការជាច្រើនម៉ោងត្រូវការ memory និងការគ្រប់គ្រង context ដ៏ស្មុគស្មាញជាង មិនមែនតិចជាងទេ។ Agent ដែលធ្វើការសម្រេចចិត្តដ៏សំខាន់ត្រូវការ governance និង observability ច្រើនជាង មិនមែនតិចជាងទេ។ អំណះអំណាងគឺថា harness ត្រូវតែស្រូបយកសមត្ថភាព លឿនបំផុត ត្រឹមតែខណៈ model កែលម្អ។

ដូច្នេះ រឿងទាំងពីរពិតក្នុងពេលតែមួយ ដែលជាមូលហេតុដែលធ្វើឱ្យរឿងនេះពិបាកយ៉ាងពិតប្រាកដ៖ model កំពុងលេបយក scaffolding កម្រិតទាប (ខ្សែសង្វាក់រៀបផែនការ កូដភ្ជាប់ routing) ខណៈ harness កម្រិត system (memory, orchestration, verification, governance) ក្លាយជាសំខាន់ជាង មិនមែនតិចជាងទេ។ ព្រំដែនមិនកំពុងផ្លាស់ប្ដូរស្មើៗគ្នាក្នុងទិសដៅតែមួយទេ។ វាកំពុងផ្លាស់ប្ដូរឡើងលើ stack — លេបយកស្រទាប់មេកានិក បង្ហាញនូវស្រទាប់ស្ថាបត្យកម្ម។

ឧទាហរណ៍ជាក់ស្ដែងមួយធ្វើឱ្យការបំបែកនេះច្បាស់។ ពីរឆ្នាំមុន ការធ្វើឱ្យ model បំបែក “refactor module នេះ” ទៅជា sub-step តាមលំដាប់បានដោយអាចទុកចិត្តបាន ត្រូវការ prompt រៀបផែនការដែលសាងសង់ដោយដៃ — scaffolding សុទ្ធ ហើយជាប្រភេទដែល model បានលេបយកសព្វថ្ងៃនេះ។ ប៉ុន្តែ ការធ្វើឱ្យ agent បី refactor module បីស្របគ្នា ចែករំលែកនូវអ្វីដែលម្នាក់ៗបានរៀន ផ្សះផ្សាការកែប្រែដែលប៉ះទង្គិចគ្នា ហើយបង្កើត audit trail ដែលអ្នកត្រួតពិនិត្យអាចទុកចិត្តបានពេលក្រោយ? គ្មានការកែលម្អ model ណាផ្ដល់ឱ្យអ្នកនូវរឿងនោះដោយឥតគិតថ្លៃទេ។ វាជា orchestration និង verification — ការរចនា system ដែលអ្នកសាងសង់ ដែលប្រមូលផ្ដុំ ហើយដែលអតិថិជនដែលត្រូវបានគ្រប់គ្រងនឹង តម្រូវ កាន់តែខ្លាំងឡើង។ Prompt រៀបផែនការគឺអាចបោះចោលបាន។ Orchestration គឺជាទ្រព្យសម្បត្តិ។

កែវ Bitter Lesson

ការរៀបក្របខណ្ឌដ៏ជ្រៅជ្រះបំផុតនៃភាពតានតឹងនេះមកពី Ethan Mollick ដែលផ្អែកលើ “Bitter Lesson” ដ៏ល្បីរបស់ Rich Sutton។ Bitter Lesson ដែលត្រូវបានរៀនម្ដងហើយម្ដងទៀតនៅទូទាំងប្រវត្តិសាស្ត្រ AI គឺថា វិធីសាស្ត្រទូទៅដែលប្រើ computation និងការរៀន ទីបំផុតយកឈ្នះវិធីសាស្ត្រដែលរៀបចំដោយដៃ និងវិស្វកម្មដោយមនុស្ស។ អនុវត្តនៅទីនេះ៖ តើការរៀន model ទូទៅនឹងយកឈ្នះ scaffolding agent ដែលរៀបចំយ៉ាងល្អិតល្អន់នៅទីបំផុតឬទេ?

ចម្លើយដ៏ស្មោះត្រង់របស់ Mollick គឺថា យើងជិតនឹងដឹងហើយ — ហើយគាត់ដាក់វាជាសំណួរបើកចំហនៃពេលនេះ៖ តើដំណើរការ (process) សំខាន់ឬទេ? ប្រសិនបើ Bitter Lesson កាន់រហូតដល់ខាងក្រោម នោះដំណើរការ agent ដ៏ល្អិតល្អន់គឺជាការភ្នាល់ដែលចាញ់ប្រឆាំងនឹង scale ហើយ model លេបយកស្ទើរតែអ្វីៗគ្រប់យ៉ាង។ ប្រសិនបើវាមិនមែន — ប្រសិនបើមានស្រទាប់នៃការរចនា system ដែលមិនអាចកាត់បន្ថយបាន ដែលគ្មាន scale model ប៉ុន្មានផលិតបានដោយឥតគិតថ្លៃ — នោះ harness គឺជាកន្លែងដែលតម្លៃស្ថិតស្ថេររស់នៅ។

ការអានរបស់យើង៖ Bitter Lesson គឺពិត ហើយនឹងបន្តលុបបំបាត់ scaffolding កម្រិតទាប ប៉ុន្តែវាដំណើរការ នៅខាងក្នុង system ដែលនៅតែត្រូវរចនា។ Model ដែលរៀនបានល្អជាងធ្វើឱ្យរង្វិលជុំដែលសាងសង់ល្អកាន់តែល្អ វាមិនសរសេររង្វិលជុំ មិនកំណត់ “រួចរាល់” មិនធានាថាទិន្នន័យត្រឹមត្រូវ ឬមិនសម្រេចថា agent ត្រូវបានអនុញ្ញាតឱ្យធ្វើអ្វីទេ។ Bitter Lesson លេបយកភាពឆ្លាតវៃ។ វាមិនលេបយកវិស្វកម្មទេ។

ច្បាប់មេដៃជាក់ស្ដែង

ប្រសិនបើអ្នកកំពុងធ្វើការសម្រេចចិត្តស្ថាបត្យកម្មសព្វថ្ងៃ នេះជាច្បាប់ដែលធ្លាក់ចេញពីរឿងទាំងអស់នេះ៖ សាងសង់ scaffolding ដែលថោកក្នុងការលុបចោល ហើយវិនិយោគដោយស្ថិតស្ថេរទៅលើផ្នែកដែលរស់រានពីការ upgrade model។

ជាក់ស្ដែង៖

• ចាត់ទុក scaffolding កម្រិតទាបជារបស់អាចបោះចោលបាន។ ខ្សែសង្វាក់រៀបផែនការ តក្កវិជ្ជា routing និងការលេងសៀក prompt ដើម្បីបញ្ចុះបញ្ចូលឱ្យមានឥរិយាបថមួយ — សាងសង់ពួកវាស្រាលៗ រំពឹងថានឹងបោះវាចោល ហើយកុំទុកឱ្យពួកវាក្លាយជារឹងនៅក្នុងស្ថាបត្យកម្មរបស់អ្នក។ មួយៗគឺជាការភ្នាល់ប្រឆាំងនឹង model បន្ទាប់ ហើយអ្នកនឹងចាញ់ការភ្នាល់នោះច្រើនលើក។
• វិនិយោគយ៉ាងធ្ងន់ទៅលើស្រទាប់ដែលប្រមូលផ្ដុំ។ Evaluation, គុណភាពទិន្នន័យ, verification, ស្ថាបត្យកម្ម memory, observability និង governance មិនត្រូវបានធ្វើឱ្យហួសសម័យដោយការចេញផ្សាយ model — ពួកវាក្លាយជា មានតម្លៃ ជាងពេលអ្នកទុកចិត្ត agent ច្រើនជាង។ ការងាររបស់ McKinsey ស្ដីពីការ scale agentic AI ក្នុងសហគ្រាសក៏ដល់កន្លែងតែមួយ៖ មូលដ្ឋានគ្រឹះដែលស្ថិតស្ថេរគឺនៅកម្រិតអង្គភាព និង system មិនមែន model ឬ framework ជាក់លាក់ណាមួយទេ។
• ប្រើកែវបីស្រទាប់។ ដូចដែលយើងបានអះអាងនៅក្នុង អត្ថបទ loop-engineering របស់យើង៖ ទទួលយក harness, សាងសង់រង្វិលជុំ, scale ជាមួយ orchestration។ Harness ក្លាយជាទំនិញធម្មតា (commoditizes) model កែលម្អនៅខាងក្រោមអ្នក — គែមដ៏ស្ថិតស្ថេររបស់អ្នកគឺស្រទាប់កណ្ដាល និងស្រទាប់ខាងលើ ដែលរចនាឡើងដោយសន្មតថា model នឹងបន្តកាន់តែប្រសើរ។

ក្រុមដែលត្រូវរលាកគឺក្រុមដែលសាងសង់ moat ចេញពីភាពឆ្លាតវៃដែលទូទាត់សង model។ ក្រុមដែលប្រមូលផ្ដុំគឺក្រុមដែលការវិនិយោគរបស់ពួកគេក្លាយជា មានតម្លៃ ជាងរៀងរាល់ពេលដែល model កែលម្អ។

សេចក្ដីសន្និដ្ឋាន

Models ធៀបនឹង agents មិនមែនជាសំណួរដែលមានអ្នកឈ្នះតែម្នាក់ទេ — វាជាព្រំដែនដែលផ្លាស់ប្ដូរ ហើយជំនាញគឺការដឹងថាអ្នកកំពុងសាងសង់នៅជ្រុងណានៃវា។ Model ពិតជាកំពុងលេបយក scaffolding agent កម្រិតទាប ហើយវានឹងបន្តធ្វើដូច្នេះ ការភ្នាល់ប្រឆាំងនឹងវាគឺការភ្នាល់ប្រឆាំងនឹងនិន្នាការដែលអាចទុកចិត្តបានបំផុតក្នុងវិស័យនេះ។ ប៉ុន្តែ harness កម្រិត system — memory, orchestration, verification, governance — មិនកំពុងត្រូវបានលេបយកទេ។ វាកំពុងក្លាយជាសំខាន់ជាង ព្រោះសមត្ថភាពដែលអ្នកមិនអាចទុកចិត្ត សវនកម្ម ឬបញ្ឈប់បាន មិនមែនជាសមត្ថភាពដែលអ្នកអាចដាក់ឱ្យប្រើបានទេ។

សាងសង់សម្រាប់រឿងនោះ។ ធ្វើឱ្យ scaffolding របស់អ្នកថោកក្នុងការលុបចោល ហើយ verification, ទិន្នន័យ និង orchestration របស់អ្នកស្ថិតស្ថេរ។ ភ្នាល់លើស្រទាប់ដែលរស់រានពី model បន្ទាប់ — ព្រោះនឹងតែងតែមាន model បន្ទាប់ជានិច្ច។

នេះជាប្រភេទនៃការសម្រេចចិត្តស្ថាបត្យកម្មដែលយើងជួយក្រុមឱ្យធ្វើបានត្រឹមត្រូវនៅ Inference Loops។ ប្រសិនបើអ្នកកំពុងសម្រេចចិត្តថាត្រូវវិនិយោគនៅកន្លែងណាក្នុង stack agent របស់អ្នក — និងអ្វីដែលត្រូវទុកជារបស់អាចបោះចោលបាន — តោះយើងពិភាក្សាគ្នា។