OmniRoute/docs/i18n/km/docs/compression/COMPRESSION_ENGINES.md

Compression Engines (ខ្មែរ)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

---

ការបង្ហាប់របស់ OmniRoute ត្រូវបានបង្កើតឡើងដោយផ្អែកលើកិច្ចសន្យារបស់ engine។ mode មួយអាចដំណើរការ engine មួយដោយផ្ទាល់ (caveman ឬ rtk) ឬ pipeline ជាជង់ដែលមានលក្ខណៈកំណត់ច្បាស់លាស់ ហើយប្រតិបត្តិ engine ជាច្រើនតាមលំដាប់។

Mode

Mode	ផ្លូវរបស់ engine	ទិន្នន័យបញ្ចូលដែលសមស្រប
off	គ្មាន	រក្សា prompt ឱ្យនៅដដែលទាំងស្រុង
lite	ឧបករណ៍ជំនួយ Caveman lite	ការសម្អាតជាប្រចាំដែលមានហានិភ័យទាប
standard	Caveman	ការបង្រួម prompt ជាភាសាធម្មជាតិ
aggressive	Caveman + ឧបករណ៍សង្ខេបប្រវត្តិ/tool	session ជជែកដែលមានរយៈពេលវែង
ultra	Caveman + ឧបករណ៍ជំនួយកាត់ចេញ	ការស្ដារឡើងវិញនៅពេលឈានដល់ដែនកំណត់ context
rtk	RTK	លទ្ធផល terminal, shell, build, test និង git
omniglyph	OmniGlyph	context ជារូបភាពនៅលើខ្សែបញ្ជូន native របស់ provider
stacked	Pipeline, លំនាំដើម rtk -> caveman	tool log និងអត្ថបទចម្រុះ ដើម្បីសន្សំបានអតិបរមា

Profile បង្ហាប់របស់ OmniGlyph

engine omniglyph (package omniglyph, 1.4.0+) ទទួលយក semantic profile ដែលមានឈ្មោះ ដោយកំណត់ ជាសកលតាមរយៈ omniglyph.profile ក្នុងការកំណត់ការបង្ហាប់ ឬកំណត់សម្រាប់ជំហាននីមួយៗតាមរយៈ ការកំណត់រចនាសម្ព័ន្ធជំហានរបស់ pipeline ជាជង់៖

Profile	ព្រំដែន
aggressive	លំនាំដើម។ គោលការណ៍ដែល receipt ដែលបានបោះពុម្ពផ្សាយបានវាស់វែង — បម្លែង system, ឯកសារ tool និងប្រវត្តិក្រាស់ទៅជារូបភាព
balanced	រក្សា state ដែលកំពុងដំណើរការជា native ការពារ 8 turn ចុងក្រោយ និងបង្រួមប្រវត្តិចាស់ដែលបានបិទរួច
coding-safe	រក្សា authority, schema របស់ tool និងលទ្ធផល tool ដែលកំពុងដំណើរការជា native ហើយការពារ 12 turn ចុងក្រោយ
passthrough	បញ្ជូនបន្តដោយមិនបំប្លែង; engine ត្រូវបានរំលង

profile គឺជា ពិដាន មិនមែនជាបាត៖ mergeCompressionProfileOptions នៅក្នុង package បដិសេធមិនឱ្យការកំណត់ override របស់អ្នកហៅបើក lane ដែលមានការបាត់បង់ឡើងវិញ ដែល profile បានបិទនោះទេ ដូច្នេះ preserveSystemPrompt: false ក្នុងជំហាននីមួយៗ មិនអាចបើកការបង្ហាប់ system ឡើងវិញក្រោម coding-safe បានទេ។

តាមការវាស់វែងលើ codebase នេះ៖ coding-safe និង balanced បង្កើន minCompressChars ដល់ តម្លៃអតិបរមារបស់វា ហើយរក្សា system, schema របស់ tool និងលទ្ធផល tool ជា native ដូច្នេះ session ដែលមិនទាន់ បានប្រមូលប្រវត្តិ នឹងឈប់នៅ below_min_chars ហើយ engine មិនបំប្លែងអ្វីទាំងអស់។ នេះហើយជា មូលហេតុដែលលំនាំដើមគឺ aggressive ជំនួសឱ្យ profile ដែលមានសុវត្ថិភាពបំផុត។

package នេះកំណត់ model scope និង profile របស់ខ្លួនពីការកំណត់រចនាសម្ព័ន្ធ environment របស់វា។ OmniRoute មិនដែលប្រគល់សិទ្ធិសម្រេចចិត្តនេះទៅកន្លែងផ្សេងទេ៖ adapter ចាក់សោ model gate ទៅ scope ដ៏តឹងរ៉ឹងបំផុតរបស់ package ដូច្នេះការកំណត់ environment របស់ host អាចត្រឹមតែបង្រួម allowlist ប៉ុណ្ណោះ មិនអាច ពង្រីកវាឱ្យលើសពី receipt ដែល OmniRoute បានវាស់វែងឡើយ។

បញ្ជីចុះឈ្មោះ Engine

បញ្ជីចុះឈ្មោះមានទីតាំងនៅក្នុង open-sse/services/compression/engines/registry.ts។ Engine ទាំងឡាយបង្ហាញកិច្ចសន្យារួមមួយ៖

• id: លេខសម្គាល់ engine ដែលមានស្ថិរភាព ដូចជា caveman ឬ rtk
• apply(text, config): ផ្លូវប្រតិបត្តិចាស់ដែលប្រើដោយ pipeline ជាន់គ្នា
• compress(input, config): ផ្លូវប្រតិបត្តិចម្បងដែលត្រឡប់អត្ថបទ + ស្ថិតិ
• getConfigSchema(): ត្រឡប់ទម្រង់ស្រដៀង JSON-Schema នៃ config ដែលត្រឹមត្រូវ
• validateConfig(config): ត្រឡប់ { valid, errors[] }

ការចុះឈ្មោះប្រើ registerCompressionEngine(engine) (ឬ registerEngine សម្រាប់ករណីកម្រិតខ្ពស់) ដែលហៅ assertValidEngine() និង validateConfig(defaultConfig) មុនពេលទទួលយក។ ប្រើ unregisterCompressionEngine(id) ដើម្បីដក engine មួយចេញនៅពេលដំណើរការ។

strategySelector.ts ចុះឈ្មោះ engine ដែលភ្ជាប់មកជាស្រេច មុនពេលការបង្ហាប់ដំណើរការ។ វាអនុញ្ញាតឱ្យការមើលជាមុន ការបង្ហាប់ពេលដំណើរការ របៀបជាន់គ្នា ការធ្វើតេស្ត និង engine នាពេលអនាគត ប្រើផ្លូវប្រតិបត្តិដូចគ្នា។

ការបង្ហាប់សេចក្ដីពិពណ៌នា MCP (ពាក់ព័ន្ធ)

បញ្ជីចុះឈ្មោះដាច់ដោយឡែកមួយ បង្ហាប់ metadata នៃសេចក្ដីពិពណ៌នា tool របស់ MCP នៅកម្រិតបញ្ជីចុះឈ្មោះ — សូមមើល open-sse/mcp-server/descriptionCompressor.ts និង MCP-SERVER.md។ វាប្រើច្បាប់ Caveman ឡើងវិញ ប៉ុន្តែដំណើរការលើ metadata របស់ tool មិនមែនលើ payload នៃ request ទេ។

Engine ភ្ជាប់មកជាស្រេចបន្ថែម

ក្រៅពី Caveman, RTK និង LLMLingua-2 បញ្ជីចុះឈ្មោះមានភ្ជាប់មកជាមួយ engine ឯកទេសមិនបាត់បង់ទិន្នន័យ / មានរចនាសម្ព័ន្ធជាច្រើន (ប្រើដោយ pipeline ជាន់គ្នា playground និងការធ្វើតេស្ត)៖

Engine	Id	អ្វីដែលវាធ្វើ
CCR	ccr	Content-Compress-Retrieve (H4)៖ ជំនួសប្លុកអត្ថបទជាប់គ្នាធំៗដោយឯកសារយោងដែលកំណត់អត្តសញ្ញាណតាមខ្លឹមសារ ដូច្នេះប្លុកដែលធំ ឬត្រូវបានប្រើម្ដងហើយម្ដងទៀត នឹងត្រូវផ្ញើតែម្ដង ហើយបន្ទាប់មកយោងទៅវា។
headroom	headroom	SmartCrusher (H3 + N5)៖ ការបង្រួមជាតារាងដោយមិនបាត់បង់ទិន្នន័យ សម្រាប់ payload អារេ JSON ដែលមានលក្ខណៈដូចគ្នា ទៅជាទម្រង់តាមជួរឈរ [N rows]។
ionizer	ionizer	ការយកគំរូជួរដេកពីផ្នែកក្បាល/កណ្ដាល/កន្ទុយ សម្រាប់ប្លុកមានលក្ខណៈដូចគ្នាដែលធំខ្លាំង ដោយរក្សាទុកផ្នែកកណ្ដាលដែលបានលុបចេញជាឯកសារយោង CCR ដែលកំណត់អត្តសញ្ញាណតាមខ្លឹមសារ។
session-dedup	session-dedup	ការលុបទិន្នន័យស្ទួនឆ្លងវេន ដែលកំណត់អត្តសញ្ញាណតាមខ្លឹមសារ (បានបំផុសគំនិតពី TokenMizer)៖ លុបអត្ថបទដែលបានឃើញរួចហើយនៅវេនមុនៗនៃ session ដូចគ្នា។

សេចក្ដីណែនាំអំពី retrieve-protocol របស់ CCR (#8033)៖ នៅលើកដំបូងដែល CCR ជំនួសប្លុក ≥1 ក្នុង request មួយ engine នឹងបន្ថែមពីមុខនូវសារ system តែមួយដែលមានលក្ខណៈ idempotent (ចាប់ផ្ដើមដោយ sentinel [CCR protocol]) ដើម្បីបង្រៀនអ្នកហៅអំពីកិច្ចសន្យា marker → tool៖ អត្ថន័យរបស់ marker [CCR retrieve hash=<24hex> chars=N] ថា hash ត្រូវតែចម្លងឱ្យដូចទាំងស្រុង (តួអក្សរ hex ទាំង 24 — hash ដែលចម្លងខុសទំនងជាមូលហេតុនៃបញ្ហា "រកមិនឃើញប្លុក" ) និងថា marker [dedup:ref sha=...] មានន័យថា "មើលត្រឡប់ទៅក្នុងប្រវត្តិ" មិនមែន "ហៅ tool" ទេ។ កំណត់ចំណាំនេះត្រូវបានបញ្ចូល តែនៅពេលដែល tools[] ដែលអ្នកហៅបានប្រកាស បញ្ជាក់ថាវា ពិតជាអាចចូលប្រើ omniroute_ccr_retrieve បាន (callerSupportsCcrRetrieve() ក្នុង open-sse/services/compression/engines/ccr/protocolInstruction.ts) — អ្នកហៅដែលឆបគ្នាជាមួយ OpenAI ធម្មតា ហើយគ្មាន tool នោះ នឹងមិនទទួលបានសេចក្ដីណែនាំឱ្យហៅអ្វីមួយដែលវាមិនអាចចូលប្រើ បានទេ។ លក្ខណៈ idempotent ត្រូវបានអនុវត្តដោយស្កេនប្រវត្តិសារ ដើម្បីស្វែងរក sentinel មុនពេលបញ្ចូល ដូច្នេះ request ច្រើនវេន (ដែលចាក់សារមុនៗឡើងវិញ) នឹងមិនបង្គរកំណត់ចំណាំ មួយដងក្នុងមួយវេនឡើយ។

Caveman

របៀប Caveman ផ្តោតលើការបង្រួមអត្ថន័យនៃអត្ថបទធម្មតា៖

• រក្សាទុកប្លុកកូដ URLs, JSON, paths និងទិន្នន័យដែលមានរចនាសម្ព័ន្ធ
• លុបពាក្យបំពេញ ការប្រើពាក្យបែបមិនប្រាកដប្រជា បរិបទដដែលៗ និងឃ្លាតភ្ជាប់វែងអន្លាយ
• គាំទ្រកញ្ចប់ច្បាប់ឯកសារដែលយល់ដឹងអំពីភាសានៅក្នុង open-sse/services/compression/rules/
• នៅតែអាចប្រើបានតាមរយៈរបៀបចាស់ standard, aggressive និង ultra

ផ្ទាំងគ្រប់គ្រងរបស់វាគឺ Dashboard -> Context & Cache -> Caveman។

ប្រភពដើម Caveman រាយការណ៍ថា output tokens តិចជាងមុន ~75% និងសន្សំ output ជាមធ្យម 65% ក្នុងការធ្វើ benchmark ជាមួយនឹងចន្លោះ 22-87% ព្រមទាំងឧបករណ៍បង្រួម input ប្រហែល ~46%។ OmniRoute ប្រើតួលេខផ្នែក input របស់ Caveman ពេលរៀបរាប់អំពីការសន្សំ prompt/context ដែលដាក់ជាស្រទាប់ៗគ្នា។ របៀប output របស់ Caveman នៅតែជាមុខងារ ឥរិយាបថឆ្លើយតបដាច់ដោយឡែក។

RTK

របៀប RTK ផ្តោតលើ output របស់ command និង tool៖

• រកឃើញប្រភេទ output ដូចជា git status, git branch, git diff, Vitest/Jest/Pytest, ការធ្វើតេស្ត Cargo/Go, ការ build TypeScript/Vite/Webpack, ESLint, ការ audit/install របស់ npm, Docker logs, shell find/grep, stack traces និង logs ទូទៅ
• អនុវត្ត JSON filters ចំនួន 49 ពី open-sse/services/compression/engines/rtk/filters/
• គាំទ្រ pipeline បែបប្រកាសរបស់ RTK៖ ការដក ANSI, ការជំនួស, ការបញ្ចប់ភ្លាមៗនៅពេល match-output, ការដក/រក្សាទុកបន្ទាត់ ការកាត់បន្ថយក្នុងមួយបន្ទាត់ ការកាត់បន្ថយ head/tail/max-line និង fallback នៅពេលទទេ
• គាំទ្រ project filters ដែលមានការកំណត់សិទ្ធិដោយផ្អែកលើការទុកចិត្តនៅក្នុង .rtk/filters.json និង global filters នៅក្នុង DATA_DIR/rtk/filters.json
• ដក ANSI sequences, progress noise, បន្ទាត់ដដែលៗ និង boilerplate ដែលមិនមានប្រយោជន៍
• រក្សាទុក failures ដែលអាចចាត់វិធានការ warnings, summaries, ឯកសារដែលបានផ្លាស់ប្តូរ និង tail context
• អាចរក្សាទុក raw output ដែលបានលាក់ព័ត៌មានសម្ងាត់ជាជម្រើស សម្រាប់ការសង្គ្រោះ/បំបាត់កំហុស តាមរយៈ management routes ដែលបានផ្ទៀងផ្ទាត់អត្តសញ្ញាណ

ផ្ទាំងគ្រប់គ្រងរបស់វាគឺ Dashboard -> Context & Cache -> RTK។

ព័ត៌មានលម្អិតអំពីប្រតិបត្តិការសម្រាប់ custom filters, trust, verify និងការសង្គ្រោះ raw-output មាននៅក្នុង RTK_COMPRESSION.md។

ប្រភពដើម RTK រាយការណ៍ថាសន្សំបាន 60-90% សម្រាប់ការបង្រួម command-output។ ឧទាហរណ៍ក្នុង README របស់វាបង្ហាញថា Claude Code session រយៈពេល 30 នាទីបានថយចុះពី ~118,000 tokens មក ~23,900 ដែលស្មើនឹងសន្សំបាន 79.7%។

LLMLingua-2 (ការកាត់ចេញតាមអត្ថន័យ)

របៀប LLMLingua-2 អនុវត្ត ការកាត់ token តាមអត្ថន័យ លើអត្ថបទដោយប្រើ ONNX token classifier តូចមួយ ដើម្បីបំពេញបន្ថែមដល់ engines Caveman និង RTK ដែលផ្អែកលើច្បាប់៖

• បង្រួមតែអត្ថបទក្នុង messages ដែលមិនមែនជា system ប៉ុណ្ណោះ។ ប្លុកកូដដែលមានរបង និងរចនាសម្ព័ន្ធដែលត្រូវរក្សាទុក ផ្សេងទៀតមិនត្រូវបានកែប្រែឡើយ
• ដំណើរការ backend @atjsh/llmlingua-2 (ONNX តាមរយៈ @huggingface/transformers) នៅក្នុង worker thread ដូច្នេះ model inference មិនរារាំង request event loop ឡើយ
• អាច ដាក់ជាស្រទាប់បាន (stackPriority 35)៖ ក្នុង pipeline ដែលដាក់ជាស្រទាប់ វាដំណើរការបន្ទាប់ពី structural engines (CCR, session-dedup, headroom, Caveman) ប៉ុន្តែមុន ultra ពីព្រោះ ការកាត់ចេញតាមអត្ថន័យមានប្រសិទ្ធភាពបំផុតលើអត្ថបទដែលបានបង្រួមតាមរចនាសម្ព័ន្ធរួចហើយ — ឧ. rtk -> caveman -> llmlingua
• បន្តដំណើរការដោយបើកចំហនៅពេលមានកំហុសណាមួយ (ខ្វះ optional deps, ការបង្កើត worker, ការផ្ទុក model, inference ឬ timeout) → អត្ថបទដើមត្រូវបានត្រឡប់ដោយមិនផ្លាស់ប្តូរ មិនដែលត្រឡប់កំហុសឡើយ

ទីតាំង engine៖ open-sse/services/compression/engines/llmlingua/។ ផ្ទាំងគ្រប់គ្រងរបស់វា គឺ Dashboard -> Context & Cache -> LLMLingua។

Models

model លំនាំដើមគឺ TinyBERT (atjsh/llmlingua-2-js-tinybert-meetingbank, ~57 MB, លឿន)។ model BERT-base ដែលមានភាពត្រឹមត្រូវខ្ពស់ជាង (Arcoldd/llmlingua4j-bert-base-onnx, ~710 MB) អាចប្រើបានតាមរយៈ field model ក្នុងការកំណត់រចនាសម្ព័ន្ធ engine។ @huggingface/transformers ទាញយក model ដែលបានជ្រើសរើសតាមតម្រូវការពី HuggingFace Hub ទៅក្នុង ${DATA_DIR}/models/llmlingua នៅពេលហៅលើកដំបូង (modelStore.ts)។ ការកំណត់ជំនួស modelPath នឹងចង្អុលទៅកាន់ច្បាប់ចម្លងនៅក្នុងម៉ាស៊ីនជំនួសវិញ (សម្រាប់ការដំឡើង offline / air-gapped)។

Optional dependencies និងការដំឡើងតាមតម្រូវការ

prunable LLMLingua runtime peer stack គឺជា ជម្រើស។ packages ពីរត្រូវបានប្រកាសជា optionalDependencies ក្នុង package.json និងរក្សាទុកជា external ដោយ production build (scripts/build/prepublish.ts មិន bundle ពួកវាទេ)៖

Package	កំណែ (បានចាក់សោ)	កំណត់សម្គាល់
@atjsh/llmlingua-2	2.0.5	package ចម្បង ដែលប្រកាស package ផ្សេងទៀតជា peers
js-tiktoken	^1.0.20	Tokenizer

@huggingface/transformers ត្រូវបានចាក់សោនៅ ^4.2.0 (ប្រើរួមជាមួយ local embeddings path និង ត្រូវបាន trace ចូលទៅក្នុង standalone bundle ផងដែរ)។ @atjsh/llmlingua-2@2.0.5 កំណត់វាជា peer ជាមួយ "^3.5.2 || ^4.0.0" ដូច្នេះទាំង Transformers.js v3 និង v4 ត្រូវបានគាំទ្រ។ ចាប់ពី 2.0.4 មក @atjsh/llmlingua-2 លែងត្រូវការ @tensorflow/tfjs ទៀតហើយ ដែលបានដកសមាសភាគធំបំផុតតែមួយ (TensorFlow.js) ចេញពី SLM stack។ មានតែ packages ពីរខាងលើប៉ុណ្ណោះដែលជា prunable SLM peers។ npm install ស្តង់ដារ (dev) ដំឡើង optional stack ដោយស្វ័យប្រវត្តិ លុះត្រាតែ optional dependencies ត្រូវបានរំលង។

ហេតុអ្វីត្រូវដំឡើងតាមតម្រូវការ៖ package ដែលបានបោះពុម្ពលើ npm, standalone bundle និង Docker image ត្រូវបានចែកចាយ ដោយគ្មាន deps ទាំងនេះ ដើម្បីរក្សាទំហំឱ្យតូច។ នៅពេលពួកវាមិនមាន dependency gate របស់ worker (ការស្ទង់ resolve របស់ @atjsh/llmlingua-2 ក្នុង worker.ts) នឹងបរាជ័យ ហើយ engine នឹង បន្តដំណើរការដោយស្ងាត់នៅពេលមានកំហុស — ការជ្រើស LLMLingua នឹងមិនធ្វើអ្វីទេ (អត្ថបទត្រូវបានត្រឡប់ដោយមិនផ្លាស់ប្តូរ និងគ្មាន កំហុសត្រូវបានកត់ត្រា)។ ដើម្បីបើកដំណើរការវាក្នុងបរិស្ថានដែលបានកាត់បន្ថយ សូមដំឡើង optional stack៖

# ចាក់សោកំណែទៅតាមកំណែដែលបានប្រកាសក្នុង package.json optionalDependencies
npm install @atjsh/llmlingua-2@2.0.5 js-tiktoken

ការដក @tensorflow/tfjs ចេញ (2.0.4+) លុបបំបាត់សមាសភាគប្រហែល ~800 MB ដែលធ្លាប់មានទំហំធំបំផុត — ទំហំដែលនៅសល់គឺ runtimes របស់ transformers.js + onnxruntime-node បូករួមនឹង model TinyBERT (~57 MB) ដែលត្រូវបានទាញយកពេលប្រើលើកដំបូង (មិនមែនតាម npm ទេ)។

សម្រាប់បរិស្ថាននីមួយៗ៖

• Dev / npm install — ត្រូវបានដំឡើងដោយស្វ័យប្រវត្តិ លុះត្រាតែអ្នកបានបញ្ជូន --omit=optional (ឬ --no-optional)។ មិនចាំបាច់ធ្វើអ្វីទេ។
• Global npm (npm i -g omniroute) / standalone — ដំណើរការពាក្យបញ្ជាដំឡើងខាងលើនៅក្នុង ថតកញ្ចប់ដែលបានដំឡើង ឬដំឡើងឡើងវិញដោយមិនរំលង optional deps។
• Docker — បន្ថែមពាក្យបញ្ជាដំឡើងទៅក្នុងស្រទាប់ derived image មួយ; image ដែលបានចេញផ្សាយ ត្រូវបានរៀបចំឱ្យមានទំហំតូចតាមការរចនា។
• VPS (PM2) — ដំឡើងទៅក្នុង node_modules របស់កម្មវិធី បន្ទាប់មកចាប់ផ្ដើម process ឡើងវិញ ដើម្បីឱ្យ worker ពិនិត្យ gate ឡើងវិញ។
• Raw Next standalone (npm run build → .build/next/standalone/server.js) — standalone trace មិនភ្ជាប់មកជាមួយទាំង worker និង optional deps ទេ ដូច្នេះ engine បើកឱ្យឆ្លងកាត់ដោយស្ងៀមស្ងាត់ នៅពេលបរាជ័យ។ scripts/build/colocate-standalone.mjs អនុវត្តទាំងពីរឡើងវិញ (worker esbuild + optional-dep closure ទៅក្នុង standalone tree); វាដំណើរការដោយស្វ័យប្រវត្តិតាមរយៈ postbuild npm hook បន្ទាប់ពីរាល់ការបង្កើត build។ អាចដំណើរការឡើងវិញបានដោយមិនបង្កផលប៉ះពាល់ និងបរាជ័យដោយទន់ភ្លន់នៅពេលគ្មាន deps។

ផ្ទៀងផ្ទាត់ថាវាកំពុងសកម្ម: នៅពេលជ្រើសរើស LLMLingua អត្ថបទពិតប្រាកដនឹងត្រូវបានបង្រួម (engine ឈប់បើកឱ្យឆ្លងកាត់នៅពេលបរាជ័យ) ហើយ request ដំបូងនឹងចាប់ផ្ដើមការទាញយក model ទៅក្នុង ${DATA_DIR}/models/llmlingua។ gate ពិនិត្យតែ @atjsh/llmlingua-2 ដោយចេតនា — peers ផ្សេងទៀតគាំទ្រតែ ESM ហើយ require.resolve បង្កើតកំហុសលើពួកវា ទោះបីជាមានវត្តមានក៏ដោយ — ដូច្នេះ worker នៅតែបើកឱ្យឆ្លងកាត់នៅពេលបរាជ័យ ប្រសិនបើ peer ណាមួយពិតជាបាត់នៅពេល import()។

បំពង់ដំណើរការដែលដាក់ជាជង់

របៀបដាក់ជាជង់ដំណើរការជំហាននៃបំពង់ដំណើរការតាមលំដាប់។ លំនាំដើមគឺ៖

rtk -> caveman

ប្រើវាសម្រាប់សម័យ coding-agent ដែល prompt មួយរួមបញ្ចូលលទ្ធផល command ជាមួយនឹងអត្ថបទរបស់មនុស្ស ឬ assistant។ RTK កាត់បន្ថយកំណត់ហេតុឧបករណ៍ដែលមានភាពរំខានជាមុនសិន បន្ទាប់មក Caveman បង្ហាប់ភាសាធម្មជាតិដែលនៅសល់។

ជំហាននៃបំពង់ដំណើរការត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយប្រើ stackedPipeline នៅក្នុងការកំណត់ការបង្ហាប់ ឬតាមរយៈបន្សំការបង្ហាប់។

នៅពេលម៉ាស៊ីនទាំងពីរកាត់បន្ថយ payload ដូចគ្នាដែលមានសិទ្ធិ អត្រាសន្សំនឹងបូកបន្តគ្នា៖

combined = 1 - (1 - RTK savings) * (1 - Caveman input savings)
average  = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
range    = 1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%

តម្រងមែកធាងភាពងាយស្រួលប្រើប្រាស់ MCP

តម្រងឆ្លាតវៃសម្រាប់មែកធាងភាពងាយស្រួលប្រើប្រាស់ MCP គឺជាស្រទាប់បង្ហាប់ក្រោយការប្រតិបត្តិ ដែលដំណើរការលើ លទ្ធផលឧបករណ៍ MCP មិនមែនលើ prompt ឬ context ទេ។ វាផ្តោតលើ payload នៃមែកធាងភាពងាយស្រួលប្រើប្រាស់ និង snapshot របស់ browser ដែលមានខ្លឹមសារច្រើនលើសលប់ ដែលត្រូវបានត្រឡប់ដោយឧបករណ៍ដូចជា Playwright, computer-use និងម៉ាស៊ីនបម្រើ MCP សម្រាប់ browser-automation។

អ្វីដែលវាធ្វើ

1. ការដកភាពរំខានចេញ — ដកធាតុ generic/text ទទេចេញ (- generic:, - text: "")
2. ការបង្រួមធាតុកម្រិតដូចគ្នា — នៅពេលបន្ទាត់ជាប់ៗគ្នាចំនួន ≥ collapseThreshold (លំនាំដើម 30) ជាធាតុរចនាសម្ព័ន្ធដដែលៗ វានឹងបង្រួមពួកវាទៅជាបន្ទាត់ដំបូងចំនួន collapseKeepHead (លំនាំដើម 10) + សេចក្តីសង្ខេបចំនួន + បន្ទាត់ចុងក្រោយចំនួន collapseKeepTail (លំនាំដើម 5)
3. ការរក្សាទុក ref — anchor [ref=eXX] ដែល Playwright/computer-use ត្រូវការ នឹងមិនត្រូវបានកែប្រែឡើយ
4. ការកាត់ផ្តាច់ដោយកំណត់រឹង — ប្រសិនបើអត្ថបទក្រោយការបង្រួមនៅតែលើស maxTextChars (លំនាំដើម 50,000) វានឹងកាត់ផ្តាច់អត្ថបទដោយភ្ជាប់ជាមួយការណែនាំអំពីការរុករក ដើម្បីឱ្យ agent អាចបន្តធ្វើការបាន

ទីតាំងម៉ាស៊ីន

open-sse/services/compression/engines/mcpAccessibility/
  index.ts            ← ចំណុចចូល smartFilterText()
  collapseRepeated.ts ← ក្បួនដោះស្រាយសម្រាប់បង្រួមធាតុកម្រិតដូចគ្នា
  constants.ts        ← DEFAULT_MCP_ACCESSIBILITY_CONFIG

ការកំណត់រចនាសម្ព័ន្ធ

គ្រប់គ្រងដោយ compression.mcpAccessibility នៅក្នុងការកំណត់សកល (migration 056)។ ការកំណត់រចនាសម្ព័ន្ធលំនាំដើម៖

{
  "enabled": true,
  "maxTextChars": 50000,
  "collapseThreshold": 30,
  "collapseKeepHead": 10,
  "collapseKeepTail": 5,
  "minLengthToProcess": 2000
}

តម្រងនេះត្រូវបានអនុវត្តតែលើ payload នៃលទ្ធផលឧបករណ៍ដែលមាន type ជា "text" និងមានប្រវែងលើស minLengthToProcess ប៉ុណ្ណោះ។ វាមិនប៉ះពាល់ដល់ការបង្ហាប់ prompt ឬ payload នៃសំណើទេ។

អត្រាសន្សំដែលរំពឹងទុក

60–80% លើលទ្ធផលឧបករណ៍ snapshot របស់ browser អាស្រ័យលើភាពស្មុគស្មាញនៃទំព័រ។ ក្បួនដោះស្រាយបង្រួមមានភាពស្មុគស្មាញ O(n) តាមចំនួនបន្ទាត់ និងបន្ថែម latency តិចតួចដែលអាចមិនយកមកគិតបាន។

តម្រងនេះធៀបនឹងម៉ាស៊ីនបង្ហាប់ខាងលើ

ទិដ្ឋភាព	Caveman / RTK / Stacked	តម្រងភាពងាយស្រួលប្រើប្រាស់ MCP
គោលដៅ	Prompt / context នៃសំណើ	លទ្ធផលឧបករណ៍ MCP
កត្តាបង្កឱ្យដំណើរការ	ការកំណត់របៀបបង្ហាប់	compression.mcpAccessibility.enabled
វិសាលភាព	សារ SSE ទាំងអស់	លទ្ធផលឧបករណ៍ប៉ុណ្ណោះ
Anchor ref	មិនអនុវត្ត	ត្រូវបានរក្សាទុកដោយគ្មានលក្ខខណ្ឌ

---

បន្សំការបង្ហាប់

បន្សំការបង្ហាប់គឺជាប្រូហ្វាល់ការបង្ហាប់ដែលមានឈ្មោះ និងអាចកំណត់ឱ្យបន្សំកំណត់ផ្លូវបាន៖

• compression_combos: រក្សាទុកម៉ូដ pipeline ការកំណត់រចនាសម្ព័ន្ធ RTK ការកំណត់រចនាសម្ព័ន្ធភាសា និងសញ្ញាសម្គាល់លំនាំដើម
• compression_combo_assignments: ផ្គូផ្គងបន្សំការបង្ហាប់មួយទៅនឹងបន្សំកំណត់ផ្លូវមួយ
• ការរួមបញ្ចូលពេលដំណើរការកំណត់បន្សំការបង្ហាប់ដែលបានផ្ដល់ជាមុនសិន មុននឹងការកំណត់ជំនួសបន្សំទូទៅ
• ទិន្នន័យវិភាគរួមមាន compression_combo_id និង engine

ទីតាំងនៅលើផ្ទាំងគ្រប់គ្រង៖ Dashboard -> Context & Cache -> Compression Combos។

ផ្ទៃ API

ផ្លូវ	គោលបំណង
/api/settings/compression	ការកំណត់ការបង្ហាប់សកល (រួមមានការកំណត់រចនាសម្ព័ន្ធ mcpAccessibility)
/api/compression/preview	មើលជាមុននូវម៉ូដការបង្ហាប់ណាមួយ
/api/compression/language-packs	រាយបញ្ជីកញ្ចប់ភាសា Caveman ដែលមាន
/api/context/caveman/config	ឈ្មោះជំនួសសម្រាប់ការកំណត់ Caveman
/api/context/rtk/config	តម្លៃលំនាំដើម និងការកំណត់ RTK
/api/context/rtk/filters	កាតាឡុកតម្រង RTK
/api/context/rtk/test	endpoint សម្រាប់មើលជាមុន/សាកល្បង RTK
/api/context/rtk/raw-output/[id]	ការសង្គ្រោះ raw-output ដែលបានលាក់ព័ត៌មានរសើប និងបានផ្ទៀងផ្ទាត់អត្តសញ្ញាណ
/api/context/combos	CRUD សម្រាប់បន្សំការបង្ហាប់
/api/context/combos/[id]/assignments	CRUD សម្រាប់ការផ្ដល់ទៅឱ្យបន្សំកំណត់ផ្លូវ
/api/context/analytics	ឈ្មោះជំនួសសម្រាប់ទិន្នន័យវិភាគការបង្ហាប់

ផ្លូវគ្រប់គ្រងតម្រូវឱ្យមានការផ្ទៀងផ្ទាត់អត្តសញ្ញាណសម្រាប់ការគ្រប់គ្រង ឬការត្រួតពិនិត្យគោលការណ៍ API-key។

ឧបករណ៍ MCP

ការបង្ហាប់ផ្ដល់ឧបករណ៍ MCP ចំនួនប្រាំ៖

ឧបករណ៍	វិសាលភាព	គោលបំណង
omniroute_compression_status	read:compression	ការកំណត់ ទិន្នន័យវិភាគ និងស្ថិតិ cache
omniroute_compression_configure	write:compression	ធ្វើបច្ចុប្បន្នភាពការកំណត់សកល
omniroute_set_compression_engine	write:compression	កំណត់ម៉ូដ និង pipeline ជាជម្រើស
omniroute_list_compression_combos	read:compression	រាយបញ្ជីបន្សំការបង្ហាប់
omniroute_compression_combo_stats	read:compression	អានទិន្នន័យវិភាគបន្សំ/engine

វិសាលភាព និងការលើកលែង

Embeddings មិនត្រូវបានបង្ហាប់ជាដាច់ខាត។ open-sse/handlers/embeddings.ts មិនដែលហៅ engine ការបង្ហាប់ណាមួយឡើយ — body នៃ request/response ត្រូវបានបញ្ជូនត្រង់ទៅ executor ដោយមិនមានការកែប្រែ។ បច្ចុប្បន្ន នេះជារចនាសម្ព័ន្ធប្រព័ន្ធ (embeddings និង chat completions មាន handler ដាច់ដោយឡែកពីគ្នា) មិនមែនជា ការត្រួតពិនិត្យពេលដំណើរការទេ ប៉ុន្តែវាមានន័យថា កង្វល់អំពីការប្រែប្រួល vector នៅក្នុង #8034 មិនមានផ្ទៃដែលអាចរងផលប៉ះពាល់ នៅក្នុងផ្លូវ embeddings ឡើយ។

តម្រងលើកលែងតាម model/endpoint (#8034)។ សម្រាប់ chat completions ប្រតិបត្តិករអាចកំណត់ឈ្មោះ model ids / គោលដៅ provider/model ដែលមិនត្រូវបានបង្ហាប់ជាដាច់ខាត — ជាវិធានការការពារដែលមានប្រយោជន៍ ប្រសិនបើ ការបង្ហាប់ត្រូវបានភ្ជាប់កាន់តែជិតទៅនឹងផ្លូវដែលនៅជិត embeddings នៅពេលក្រោយ ហើយជាទូទៅក៏មានប្រយោជន៍ សម្រាប់ model ណាមួយដែល prompt របស់វាត្រូវតែដូចគ្នាបេះបិទតាម byte (ការវាយតម្លៃកំណត់ជាមុន prefix ដែលពឹងផ្អែកលើ cache ជាដើម)។

• វាលការកំណត់៖ exclusions?: string[] នៅលើការកំណត់រចនាសម្ព័ន្ធការបង្ហាប់សកល (GET/PUT /api/settings/compression) ដែលរក្សាទុកតាមរយៈ namespace ការបង្ហាប់ key_value ដែលមានស្រាប់ (src/lib/db/compression.ts) — មិនមាន table ថ្មីទេ។
• ផ្ទាំងនៅលើ Dashboard៖ Dashboard → Compression → Exclusions (/dashboard/compression/exclusions)។
• វាក្យសម្ព័ន្ធ pattern៖ * គឺជា wildcard តែមួយគត់។ regex metacharacter ផ្សេងទៀតទាំងអស់នៅក្នុង pattern ត្រូវបាន escape មុនពេលផ្គូផ្គង ដូច្នេះ gpt-5.6 ផ្គូផ្គងតែ string តាមព្យញ្ជនៈប៉ុណ្ណោះ មិនដែលផ្គូផ្គង gpt-5x6 ទេ (មានសុវត្ថិភាពពី ReDoS មានដែនកំណត់ និងគ្មាន quantifier ត្រួតគ្នា)។ Pattern ត្រូវបានផ្គូផ្គងដោយមិនប្រកាន់តួអក្សរធំតូចទៅនឹង ទាំង model id ដាច់ដោយឡែក និងទម្រង់រួម provider/model — gpt-5-6, openai/gpt-5-6, និង openai/* សុទ្ធតែដំណើរការ ហើយ * តែឯងនឹងលើកលែងគ្រប់ model ទាំងអស់។
• ការផ្គូផ្គង៖ isCompressionExcluded() / normalizeCompressionExclusions() នៅក្នុង open-sse/services/compression/exclusions.ts។ chatCore.ts ត្រួតពិនិត្យគោលដៅដែលត្រូវបានលើកលែង ភ្លាមៗបន្ទាប់ពីកំណត់ការកំណត់ការបង្ហាប់បានហើយ មុនពេល engine ណាមួយដំណើរការ ហើយចាត់ទុកការផ្គូផ្គង ដូចគ្នាបេះបិទនឹងការបិទការបង្ហាប់ជាសកល — request body ត្រូវបានធានាថា ដូចគ្នាបេះបិទតាម byte។ ការរំលងនេះត្រូវបានកត់ត្រាតាមរយៈ writeCompressionSkip(..., "excluded") ដើម្បីឱ្យ អាចមើលឃើញនៅក្នុងទិន្នន័យវិភាគ។
• លំនាំដើម (បញ្ជីទទេ/មិនមាន)៖ ដូចគ្នាបេះបិទនឹងឥរិយាបថមុន #8034 — គ្មានអ្វីត្រូវបានលើកលែងទេ។

ដែនកំណត់ដែលបានដឹង

• LLMLingua-2 (SLM) តម្រូវឱ្យ dependency ជាជម្រើសស្ថិតនៅរួមទីតាំង។ worker ដំណើរការនៅក្នុង production build តែនៅពេល @atjsh/llmlingua-2 + peer dependency របស់វាត្រូវបានដាក់រួមទីតាំងក្នុង dist/node_modules ប៉ុណ្ណោះ (សូមមើល scripts/build/colocateOptionals.mjs, #4286)។ ប្រសិនបើគ្មានពួកវា engine នឹង fail-open (ត្រឡប់អត្ថបទដើម)។ ការកំណត់ទីតាំង worker លែងពឹងផ្អែកលើ import.meta.url ទៀតហើយ (វាបរាជ័យក្នុង standalone bundle) — វាកំណត់គោលដោយផ្អែកលើ runtime cwd / argv[1]។
• កញ្ចប់ភាសា Caveman de / fr / ja មានតែផ្នែកខ្លះ។ ពួកវាផ្តល់ជូនច្បាប់ context + filler + structural ប៉ុន្តែមិនមានកញ្ចប់ dedup / ultra ទេ ដូច្នេះកម្រិត ultra មិនខ្លាំងជាង full សម្រាប់ភាសាទាំងនោះទេ (ពួកវាប្រើតែច្បាប់ផ្ទាល់ខ្លួនប៉ុណ្ណោះ — មិនមានការ fallback ដោយស្ងាត់ទៅកាន់ច្បាប់ dedup/ultra ជាភាសាអង់គ្លេស ដែលអាចធ្វើឱ្យអត្ថបទភាសាបរទេសខូចទ្រង់ទ្រាយឡើយ)។ en / es / id / pt-BR មានពេញលេញ។ យើងស្វាគមន៍ការរួមចំណែក dedup.json + ultra.json សម្រាប់កញ្ចប់ដែលមានតែផ្នែកខ្លះ។
• ទិន្នន័យ telemetry បែប stacked រាយតែ engine ដែលបានបង្ហាប់ប៉ុណ្ណោះ។ ជំហាននៃ stacked-pipeline ដែល engine បានដំណើរការ ប៉ុន្តែសន្សំបាន 0 % នឹងត្រឡប់ stats:null ដូច្នេះវាមិនបង្ហាញក្នុង engineBreakdown ទេ — ដែលមិនអាចសម្គាល់ខុសគ្នាពីជំហានដែលត្រូវបានរំលងឡើយ។ ការបែងចែកភាពខុសគ្នារវាង "បានដំណើរការ, 0 %" និង "បានរំលង" នឹងតម្រូវឱ្យមានការផ្លាស់ប្តូរ breakdown-model ហើយត្រូវបានពន្យារពេល។

ការផ្ទៀងផ្ទាត់

ច្រកត្រួតពិនិត្យដែលផ្តោតលើផ្នែកនេះមានដូចខាងក្រោម៖

node --import tsx/esm --test tests/unit/compression/rtk-*.test.ts tests/unit/compression/pipeline-integration.test.ts tests/unit/compression/context-compression-api.test.ts
node --import tsx/esm --test tests/unit/compression/*.test.ts tests/golden-set/*.test.ts tests/integration/compression-pipeline.test.ts tests/unit/api/compression/compression-api.test.ts
node --import tsx/esm --test tests/unit/compression/mcpAccessibility*.test.ts
npm run typecheck:core