វិស្វកម្ម Context៖ Context Window ជាឧបសគ្គពិតប្រាកដរបស់ Agent របស់អ្នក

មានការសន្មតស្ងាត់មួយនៅពីក្រោមការខកចិត្តជាច្រើនអំពី agent៖ ថាបើ agent បរាជ័យ អ្នកត្រូវការ model ឆ្លាតជាង។ សម្រាប់ agent ដែលដំណើរការយូរ ការសន្មតនោះជាធម្មតាខុស។ របស់ដែលខូចមុនគេមិនមែនបញ្ញារបស់ model ទេ — វាជា context window។ ហើយដំណោះស្រាយមិនមែន window ធំជាង ឬ model ល្អជាងទេ។ វាជាការរចនាអ្វីដែល model ឃើញនៅរាល់ជំហាន។ វិន័យនោះឥឡូវនេះមានឈ្មោះ — វិស្វកម្ម context — ហើយវាកំពុងក្លាយជាជំនាញទ្រទ្រង់ទម្ងន់នៃយុគ agentic ស្ងាត់ៗ។

ផ្នែកដែលផ្ទុយនឹងវិចារណញាណជាកន្លែងដែលវាគួរឱ្យចាប់អារម្មណ៍។ សភាវគតិគឺផ្ដល់ឱ្យ agent នូវ context ច្រើនជាង — ប្រវត្តិពេញលេញ រាល់លទ្ធផលឧបករណ៍ ការសន្ទនាទាំងមូល — លើទ្រឹស្ដីថាព័ត៌មានច្រើនអាចតែជួយ។ ភស្តុតាងនិយាយផ្ទុយ។ Context ច្រើនជាង ហួសពីចំណុចមួយ ធ្វើឱ្យ agent អាក្រក់ជាង។

លេខដែលគួរផ្លាស់ប្ដូរគំនិតរបស់អ្នក

ការសិក្សាឆ្នាំ ២០២៦ Less Context, Better Agents បានដាក់រឿងនេះទៅការសាកល្បងស្អាត។ អ្នកស្រាវជ្រាវដំណើរការ agent GPT-5 ឆ្លងកាត់ការវាស់ស្ទង់ភារកិច្ច ៥០ នៃការរាយចំណាយ — ពិតជាប្រភេទការងារ horizon វែង ធ្ងន់ឧបករណ៍ ដែល context កកកុញលឿន — ក្រោមគោលនយោបាយ context ខុសៗគ្នា។

Agent ប្រវត្តិពេញលេញ ដែលកាន់រាល់ការហៅឧបករណ៍ និងការឆ្លើយតប ទទួលបាន ៧១,០% នៃការរាយពេញលេញ។ វាដុត token ប្រហែល ១,៤៨ លាន និងចំណាយ ១៤,៥៦ ម៉ោង។ Agent ដែលរក្សាតែ ការហៅឧបករណ៍ប្រាំចុងក្រោយបូកនឹងសេចក្ដីសង្ខេបបន្ត នៃអ្វីដែលវាបានបណ្ដេញ ទទួលបាន ៩១,៦% — ហើយធ្វើវាលើ token ៥៥៣,០០០ ក្នុង ៥,៧៩ ម៉ោង។ នោះជាការ កាត់បន្ថយ token ៦៣,៩% និង ពេលវេលាជាក់ស្ដែងតិចជាង ៦០,២% ខណៈ ទទួលបាន ភាពត្រឹមត្រូវជាងម្ភៃពិន្ទុ។ លទ្ធផលនៅតែឋិតថេរពេលពួកគេប្ដូរ GPT-5 ទៅ Claude Sonnet 4.5។

អានវាម្ដងទៀត ព្រោះវាបញ្ច្រាសវិចារណញាណ។ Agent ដែលឃើញ តិចជាង មានភាពត្រឹមត្រូវជាង ថោកជាងយ៉ាងខ្លាំង និងលឿនជាងច្រើន។ ប្រវត្តិពេញលេញមិនបានជួយ model ទេ — វាកំពុងពន្លិចវា។

ហេតុអ្វី context ច្រើនធ្វើឱ្យ agent អាក្រក់ជាង៖ “context rot”

យន្តការនៅពីក្រោយរឿងនេះមានឈ្មោះក្នុងវិស័យឥឡូវនេះ៖ context rot។ ពេលចំនួន token កើនឡើង ការចងចាំ ប្រសិទ្ធភាព របស់ model ថយចុះ — យូរមុនពេលវាប៉ះដែនកំណត់ context រឹង។ Window ២០០K token មិនមានន័យថា model ប្រើ ២០០K token នៃព័ត៌មានដោយអាចទុកចិត្តបានទេ។ យូរមុនពិដាននោះ សញ្ញាដែលវាត្រូវការត្រូវបានកប់ក្រោមការ dump ឧបករណ៍កកកុញ ជំហានកម្រិតមធ្យមចាស់ និងផ្លូវស្លាប់ដែលវាបានបោះបង់រួចហើយ។ Window ពេញដោយរបស់របរ ហើយរបស់របរភាគច្រើនជាសំឡេងរំខាន។

នេះជាហេតុអ្វី agent ដែលដំណើរការយូរថយចុះក្នុងវគ្គមួយ ទោះបីវាមិនដែល “អស់” context តាមបច្ចេកទេស។ រាល់ការឆ្លើយតបឧបករណ៍ដែលវាបន្ថែម ធ្វើឱ្យការសម្រេចចិត្ត បន្ទាប់ ពិបាកបន្តិចក្នុងការចាក់គ្រឹះលើអ្វីដែលសំខាន់ពិតប្រាកដ។ សមត្ថភាពមិនធ្លាក់ពីច្រាំងថ្មទេ វាសឹករិចរិល វេនម្ដងៗ។ កាន់តែ agent ដំណើរការយូរ កាន់តែ rot គុណ — ហើយដំណើរការយូរពិតជាទិសដៅដែលវិស័យទាំងមូលកំពុងផ្លាស់ទៅ។

Context ជាធនធានដែលគ្រប់គ្រង

ការក្រឡេកមើលដែលមានផលិតភាពគឺឈប់ចាត់ទុក context window ជាកំណត់ហេតុអកម្មដែល agent សរសេរទៅ ហើយចាប់ផ្ដើមចាត់ទុកវាជា ធនធានកម្រ ដែលគ្រប់គ្រងសកម្ម — តាមរបៀបដូចគ្នាដែលប្រព័ន្ធប្រតិបត្តិការចាត់ទុកអង្គចងចាំរូបវ័ន្ត។ ភាពស្រដៀងនោះមិនរលុងទេ៖ ការស្រាវជ្រាវឆ្នាំ ២០២៦ អំពីការគ្រប់គ្រង context ខ្ចីផ្ទាល់ពីការរចនា OS បុរាណ — ទ្រឹស្ដី working-set, virtual memory, demand paging — ដោយ page ព័ត៌មានពាក់ព័ន្ធ ចូល តាមតម្រូវការ ជាជាងរក្សាអ្វីៗទាំងអស់រស់នៅ។ ការយកចិត្តទុកដាក់របស់ model ជា RAM។ ការងាររបស់អ្នកជាអ្នកគ្រប់គ្រងអង្គចងចាំ។

ក្នុងការអនុវត្ត វិស្វកម្ម context ប្រមូលផ្ដុំលើចលនាមួយក្ដាប់ — វិស័យសង្ខេបពួកវាជា write, select, compress, isolate — ហើយនីមួយៗជាឥទ្ធិពលដែលអ្នកគ្រប់គ្រងដោយមិនប៉ះ model៖

• Compress (compaction + summarization)។ ស្រង់វេនចាស់ទៅសេចក្ដីសង្ខេបបង្រួមដែលរក្សាការសម្រេចចិត្ត ហើយបោះបង់ប្រតិចារិក។ នេះជាចលនាដែលជំរុញលទ្ធផលការវាស់ស្ទង់ខាងលើ៖ បណ្ដេញការហៅឧបករណ៍ឆៅ រក្សាសេចក្ដីសង្ខេបបន្ត។ អ្នកបាត់សំឡេងរំខានពាក្យសំដី ហើយរក្សាសញ្ញា។
• Write (បញ្ចេញ state ខាងក្រៅ)។ ឱ្យ agent បញ្ចេញផែនការ ការរកឃើញ និងវឌ្ឍនភាពទៅឃ្លាំងផ្ទុកគង់វង្ស — scratchpad, ឯកសារវឌ្ឍនភាព, ប្រវត្តិ git — ជាជាងកាន់អ្វីៗទាំងអស់ក្នុង window។ Window កាន់អ្វីដែលត្រូវការ ឥឡូវ ឯនៅសល់រស់នៅខាងក្រៅវា ហើយ page ត្រឡប់ចូលពេលពាក់ព័ន្ធ។
• Select (ទាញតាមតម្រូវការ)។ ទាញតែឯកសារ ឯកសារ ឬលទ្ធផលមុនជាក់លាក់ដែលជំហានបច្ចុប្បន្នត្រូវការ ជាជាងផ្ទុកមុនអ្វីៗទាំងអស់ដែល agent អាច ប្រើ។
• Isolate (sub-agents)។ ផ្ដល់ឱ្យភារកិច្ចរងឯករាជ្យនូវ context window ផ្ដោតផ្ទាល់ខ្លួន ជាជាង window រួមធំមួយ។ នេះជាអំណះអំណាងវិស្វកម្ម context សម្រាប់លំនាំ multi-agent ដែលយើងបានគ្របដណ្ដប់ក្នុង វង់តន្ត្រី code agent៖ sub-agent ដែលស្គាល់តែឯកសារមួយវែកញែកល្អជាង agent ដែលលេងសៀក codebase ទាំងមូល — ផ្នែកខ្លះ ព្រោះ window របស់វាមិន rot។

ការឆ្លងកាត់ window ច្រើន៖ long-running harness

កំណែពិបាកបំផុតនៃបញ្ហានេះគឺ agent ដែលត្រូវធ្វើការឆ្លងកាត់ window ច្រើន — ភារកិច្ចធំពេកមិនអាចសមក្នុងវគ្គមួយទាល់តែសោះ។ ការណែនាំវិស្វកម្មឆ្នាំ ២០២៦ របស់ Anthropic អំពី long-running harnesses ត្រង់ៗអំពីការលំបាកស្នូល៖ “រាល់វគ្គថ្មីចាប់ផ្ដើមដោយគ្មានការចងចាំអ្វីដែលមកមុន”។ ហើយវាក៏ត្រង់ៗស្មើគ្នាថា compaction តែឯងមិនជួយសង្គ្រោះអ្នកទេ — សូម្បី frontier model ដូច Opus 4.5 បរាជ័យក្នុងការសាងសង់កម្មវិធីគុណភាព production ពី prompt កម្រិតខ្ពស់ ពេលអ្វីដែលវាមានគ្រាន់តែ window ដែលបង្ហាប់។

ចម្លើយរបស់ពួកគេជាស្ថាបត្យកម្ម ហើយវាជាវិស្វកម្ម context សុទ្ធ។ Harness ពីរផ្នែក៖ initializer agent ដែលរៀបចំបរិស្ថានម្ដង — ឯកសារវឌ្ឍនភាព បញ្ជី feature រចនាសម្ព័ន្ធជាមួយធាតុរាប់រយដែលសម្គាល់ថា passing ឬ failing និង init.sh ដើម្បីដំណើរការគម្រោង — បន្ទាប់មក coding agent ដែលរាល់វគ្គ អានឯកសារវឌ្ឍនភាព និង git log ជ្រើស feature មួយ អនុវត្តវា ផ្ទៀងផ្ទាត់វាជាមួយការសាកល្បង end-to-end ពិតប្រាកដ commit ហើយទុក artifacts ស្អាតសម្រាប់វគ្គបន្ទាប់។ Context window កំណត់ឡើងវិញរាល់វគ្គ ឯ state គង់វង្សនៅខាងក្រៅវា ក្នុងឯកសារដែល agent បន្ទាប់ page ត្រឡប់ចូល។ វឌ្ឍនភាពបន្តិចម្ដងៗ feature មួយក្នុងពេលតែមួយ ដោយ window ត្រូវបានរក្សាឱ្យស្ដើងដោយចេតនា។

នេះជាការយល់ដឹងដូចគ្នានឹងការវាស់ស្ទង់ ធ្វើមាត្រដ្ឋានឡើង៖ ការចងចាំគង់វង្សមិនរស់នៅក្នុង context window ទេ។ វារស់នៅក្នុង artifacts ដែល harness រៀបចំជុំវិញវា។ Window ជាការចងចាំការងារ ឯឯកសារជា disk។ យើងបានអះអាងពីមុនថា harness ជាផលិតផល — ការគ្រប់គ្រង context ជាផ្នែកនៃ harness ដែលសម្រេចថាតើ agent ដែលដំណើរការយូរនៅតែស៊ីសង្វាក់ ឬ rot ស្ងាត់ៗ ហើយវាជាអ្វីដែលឱ្យ loops ដំណើរការដោយគ្មានអ្នកមើលពេលអ្នកដេក ដោយមិនរសាត់ចេញពីផ្លូវ។

ហេតុអ្វីនេះជាជំនាញឥទ្ធិពលខ្ពស់បំផុត ដើមទុនទាបបំផុតក្នុង stack

នេះជាផ្នែកដែលសំខាន់បំផុតសម្រាប់តំបន់នេះ ហើយវាជាកំណែមុតស្រួចបំផុតនៃអំណះអំណាងដែលយើងតែងតែធ្វើ។ វិស្វកម្ម context ត្រូវការ គ្មាន GPU គ្មានដើមទុន និងគ្មាន frontier lab — វាជាការវិនិច្ឆ័យប្រព័ន្ធស្ទើរសុទ្ធ។ លទ្ធផលការវាស់ស្ទង់ខាងលើមិនត្រូវបានឈ្នះដោយការបណ្ដុះបណ្ដាល model ល្អជាងទេ។ វាត្រូវបានឈ្នះដោយនរណាម្នាក់សម្រេច ដោយប្រុងប្រយ័ត្ន ថា model គួរ និងមិនគួរឃើញអ្វីនៅរាល់ជំហាន។ ការសម្រេចចិត្តនោះជាវិស្វកម្ម ហើយវាជាប្រភេទដែលដំណើរការលើ laptop។

ទម្រង់នោះសមនឹងអ្នកអភិវឌ្ឍអាស៊ីអាគ្នេយ៍ពិតប្រាកដ។ ក្រុមតូចនៅភ្នំពេញ ឬ Da Nang មិនអាច out-train OpenAI ហើយមិនចាំបាច់។ វាអាច out-engineer យុទ្ធសាស្ត្រ context របស់គូប្រកួតបានពិតប្រាកដ — ហើយផលតបស្នងផ្ទាល់៖ token តិចជាង ៦៤% គឺ ៦៤% ចេញពីវិក្កយបត្រ inference និងភាពត្រឹមត្រូវខ្ពស់ជាងពីលើ។ វិស្វកម្ម context ប្រែការគិតប្រុងប្រយ័ត្នត្រង់ទៅជាថ្លៃទាបជាង និងលទ្ធផលល្អជាង ដែលជាឥទ្ធិពលប្រសិទ្ធភាពដើមទុនបំផុតក្នុង stack agentic ទាំងមូល។ វាជា សមត្ថភាពគង់វង្ស គ្មាន GPU ដូចគ្នាដែលយើងតែងតែអះអាងថាតំបន់គួរសាងសង់ ហើយវាគុណ៖ រាល់ domain — workflow ឯកសារខ្មែរ អនុលោមភាពក្នុងស្រុក កំណត់ត្រារបស់សហករណ៍កសិកម្ម — ត្រូវការចម្លើយ ផ្ទាល់ខ្លួន របស់វាចំពោះអ្វីដែល agent គួររក្សាក្នុងការចងចាំការងារ ហើយចម្លើយនោះអាចត្រូវបានរចនាតែពីក្នុងបញ្ហា។

Frontier lab នឹងជួលឱ្យអ្នកនូវ window លាន​ token។ អ្វីដែលវាមិនអាចធ្វើគឺសម្រេចថាអ្វីជារបស់ក្នុងវា។ ការសម្រេចចិត្តនោះ — អ្វីដែល model ឃើញ ពេលណា និងអ្វីដែលត្រូវ page ចេញ — ជាការងារ។ ហើយឥឡូវនេះ វាជាការងារវិស្វកម្មដែលត្រូវបានគេមើលស្រាលបំផុតក្នុង AI។