# Compression Engines (ខ្មែរ)

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

---

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

## របៀប

| របៀប         | ផ្លូវម៉ាស៊ីន                                                                              | ការបញ្ចូលដែលបានគ្រោងទុក                          |
| ------------ | ----------------------------------------------------------------------------------------- | ------------------------------------------------ |
| `off`        | គ្មាន                                                                                     | ការរក្សាប្រអប់បញ្ចូលឱ្យបានត្រឹមត្រូវ             |
| `lite`       | ជំនួយការ Caveman lite                                                                     | ការសម្អាតដែលមានហានិភ័យទាប និងដំណើរការជានិច្ច     |
| `standard`   | Caveman                                                                                   | ការបង្រួមប្រអប់បញ្ចូលភាសាធម្មជាតិ                |
| `aggressive` | Caveman + សង្ខេបប្រវត្តិ/ឧបករណ៍                                                           | វគ្គជជែកវែងៗ                                     |
| `ultra`      | Caveman + ជំនួយការកាត់បន្ថយ                                                               | ការស្ដារឡើងវិញនូវដែនកំណត់បរិបទ                   |
| `rtk`        | RTK                                                                                       | លទ្ធផល Terminal, shell, build, test, និង git     |
| `omniglyph`  | OmniGlyph                                                                                 | បរិបទជាទម្រង់រូបភាពនៅលើខ្សែអ្នកផ្តល់សេវាដើម      |
| `stacked`    | បំពង់បង្ហូរ។ លំនាំដើមនៃការស្នើសុំគឺ `session-dedup -> lite`។ `rtk -> caveman` គឺជាជម្រើស។ | កំណត់ហេតុឧបករណ៍ចម្រុះ និងអត្ថបទ, ការសន្សំអតិបរមា |

### ទម្រង់ការបង្ហាប់ OmniGlyph

ម៉ាស៊ីន `omniglyph` (កញ្ចប់ `omniglyph`, 1.4.0+) ទទួលយកទម្រង់ន័យវិទ្យាដែលមានឈ្មោះ ដែលត្រូវបានកំណត់
ជាសកលតាមរយៈ `omniglyph.profile` នៅក្នុងការកំណត់ការបង្ហាប់ ឬតាមជំហាននីមួយៗតាមរយៈ
ការកំណត់ជំហានរបស់បំពង់បង្ហូរដែលបានដាក់ជង់៖

| ទម្រង់        | ដែនកំណត់                                                                                              |
| ------------- | ----------------------------------------------------------------------------------------------------- |
| `aggressive`  | លំនាំដើម។ គោលការណ៍ដែលបង្កាន់ដៃដែលបានបោះពុម្ពបានវាស់វែង — ប្រព័ន្ធរូបភាព ឯកសារឧបករណ៍ និងប្រវត្តិក្រាស់ |
| `balanced`    | រក្សាស្ថានភាពបច្ចុប្បន្នជាដើម ការពារវេន ៨ ចុងក្រោយ បង្រួមប្រវត្តិដែលបានបិទចាស់ៗ                       |
| `coding-safe` | រក្សាអាជ្ញាធរ គ្រោងការណ៍ឧបករណ៍ និងលទ្ធផលឧបករណ៍បច្ចុប្បន្នជាដើម ការពារវេន ១២ ចុងក្រោយ                  |
| `passthrough` | បញ្ជូនបន្តដោយមិនបំប្លែង; ម៉ាស៊ីនត្រូវបានរំលង                                                          |

ទម្រង់នេះគឺជា **កម្រិតខ្ពស់បំផុត មិនមែនកម្រិតទាបបំផុតទេ**៖ `mergeCompressionProfileOptions` នៅក្នុងកញ្ចប់
បដិសេធមិនអនុញ្ញាតឱ្យអ្នកហៅបដិសេធបើកឡើងវិញនូវផ្លូវបាត់បង់ដែលទម្រង់បានបិទ ដូច្នេះ `preserveSystemPrompt: false` ក្នុងមួយជំហាន
មិនអាចបើកការបង្ហាប់ប្រព័ន្ធឡើងវិញក្រោម `coding-safe` បានទេ។

វាស់វែងលើមូលដ្ឋានកូដនេះ៖ `coding-safe` និង `balanced` បង្កើន `minCompressChars` ដល់កម្រិតអតិបរមរបស់វា ហើយរក្សាប្រព័ន្ធ គ្រោងការណ៍ឧបករណ៍ និងលទ្ធផលឧបករណ៍ជាដើម ដូច្នេះវគ្គដែលមិនទាន់បានប្រមូលប្រវត្តិនៅឡើយ នឹងឈប់នៅ `below_min_chars` ហើយម៉ាស៊ីនមិនបំប្លែងអ្វីទាំងអស់។ នោះហើយជាមូលហេតុដែលលំនាំដើមគឺ `aggressive` ជំនួសឱ្យទម្រង់ដែលមានសុវត្ថិភាពបំផុត។

កញ្ចប់នេះដោះស្រាយវិសាលភាពម៉ូដែល និងទម្រង់ផ្ទាល់ខ្លួនរបស់វាពីការកំណត់រចនាសម្ព័ន្ធបរិស្ថានរបស់វា។ OmniRoute មិនដែលផ្ទេរការសម្រេចចិត្តទេ៖ អាដាប់ទ័រភ្ជាប់ច្រកម៉ូដែលទៅនឹងវិសាលភាពដែលតឹងរ៉ឹងបំផុតរបស់កញ្ចប់ ដូច្នេះការកំណត់បរិស្ថានម៉ាស៊ីនអាចត្រឹមតែបង្រួមបញ្ជីអនុញ្ញាតប៉ុណ្ណោះ មិនអាចពង្រីកវាហួសពីបង្កាន់ដៃដែលបានវាស់វែងរបស់ 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](../frameworks/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_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៖

```bash
# ចាក់សោកំណែទៅតាមកំណែដែលបានប្រកាសក្នុង 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()`។

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

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

```txt
rtk -> caveman
```

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

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

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

```txt
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 អាចបន្តធ្វើការបាន

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

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

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

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

```json
{
  "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 ហើយត្រូវបានពន្យារពេល។

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

ច្រកដែលផ្តោតសំខាន់សម្រាប់ផ្នែកនេះគឺ៖

```bash
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
```