OmniRoute/docs/i18n/ka/docs/compression/COMPRESSION_GUIDE.md

🗜️ Prompt Compression Guide — OmniRoute (ქართული)

🌐 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 · 🇰🇭 km · 🇮🇳 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

---

ავტომატურად დაზოგეთ დასაშვები კონტექსტის 15-95%. სწრაფი მიმოხილვისთვის იხილეთ README-ის შეკუმშვის განყოფილება.

მიმოხილვა

OmniRoute ახორციელებს მოთხოვნის მოდულარულ შეკუმშვის კონვეიერს, რომელიც პროაქტიულად მუშაობს, სანამ მოთხოვნები გარე პროვაიდერებამდე მიაღწევს. ეს ნიშნავს, რომ ტოკენების დაზოგვა გამჭვირვალედ ხდება — თქვენს სამუშაო პროცესში ცვლილებები საჭირო არ არის.

კლიენტის მოთხოვნა
  → შეკუმშვის სტრატეგიის ამრჩევი
    → კომბინაციის გადაფარვა? → კომბინაციის პარამეტრის გამოყენება
    → ავტომატური გააქტიურების ზღვარი? → ავტომატური რეჟიმის გამოყენება
    → ნაგულისხმევი რეჟიმი? → გლობალური პარამეტრის გამოყენება
    → გამორთულია? → შეკუმშვის გამოტოვება
  → არჩეული შეკუმშვის რეჟიმი
    → გამორთული: შეკუმშვის გარეშე
    → მსუბუქი: ჰარეებისა და ფორმატირების უსაფრთხო გასუფთავება (~15%)
    → სტანდარტული: ტელეგრაფული სტილით ზედმეტი სიტყვების მოცილება (~30%)
    → აგრესიული: ისტორიის დაძველება + შეჯამება (~50%)
    → ულტრა: ევრისტიკული გაფილტვრა + კოდის ბლოკების შემჭიდროება (~75%)
    → RTK: ბრძანებების გათვალისწინებით ტერმინალის/ინსტრუმენტის გამომავალი მონაცემების გაფილტვრა (გარე პროვაიდერთან 60-90%-იანი დიაპაზონი)
    → დაწყობილი: მოწესრიგებული მრავალძრავიანი კონვეიერი, ჩვეულებრივ ჯერ RTK, შემდეგ Caveman (დასაშვები მონაცემების 78-95%-იანი დიაპაზონი)
  → შეკუმშული მოთხოვნა → პროვაიდერი

---

შეკუმშვის რეჟიმები

გამორთული

შეკუმშვა არ გამოიყენება. ყველა შეტყობინება უცვლელად გადაიცემა.

მსუბუქი რეჟიმი (~15% დაზოგვა, <1ms დაყოვნება)

ყველაზე უსაფრთხო რეჟიმი — სემანტიკური ცვლილებების გარეშე, მხოლოდ ფორმატირების გასუფთავება:

ტექნიკა	აღწერა
collapseWhitespace	ზედიზედ განლაგებული ცარიელი ხაზებისა და ხაზის ბოლოში არსებული ჰარეების გაერთიანება
dedupSystemPrompt	დუბლირებული სისტემური შეტყობინებების მოცილება
compressToolResults	ვრცელი ინსტრუმენტის/ფუნქციის შედეგების შეკუმშვა
removeRedundantContent	განმეორებითი ინსტრუქციების მოცილება
replaceImageUrls	base64-ფორმატის გამოსახულების მონაცემთა URI-ების შემოკლება

საუკეთესოა: მუდმივი გამოყენებისა და უსაფრთხოებისადმი კრიტიკული სამუშაო პროცესებისთვის.

სტანდარტული რეჟიმი (~30% დაზოგვა)

შთაგონებულია Caveman-ით — მნიშვნელობის შენარჩუნებით აშორებს ზედმეტ სიტყვებსა და გაწელილ ფორმულირებებს:

• აშორებს ზედმეტ სიტყვებს ("გთხოვთ", "ვფიქრობ", "ძირითადად", "სინამდვილეში")
• ამოკლებს გაწელილ ფრაზებს ("იმისათვის, რომ" → "რომ", "ამის შედეგად" → "რადგან")
• აშორებს თავაზიან შემარბილებელ ფორმულირებებს ("ხომ ვერ...", "თუ შეძლებდით...")
• პროგრამირების მოთხოვნებისთვის მორგებული 30-ზე მეტი რეგულარული გამოსახულების წესი

საუკეთესოა: პროგრამირების ყოველდღიური სამუშაო პროცესებისა და ხარჯებზე ორიენტირებული გუნდებისთვის.

აგრესიული რეჟიმი (~50% დაზოგვა)

ისტორიის გონივრული მართვა ხანგრძლივი სესიებისთვის:

• შეტყობინებების დაძველება — ძველი შეტყობინებები თანდათან უფრო მეტად იკუმშება
• ინსტრუმენტის შედეგების შეჯამება — ინსტრუმენტის ვრცელი გამომავალი მონაცემები შეჯამებებით ჩანაცვლდება
• სტრუქტურული მთლიანობის დამცავი მექანიზმები — უზრუნველყოფს tool_use + tool_result წყვილების თანმიმდევრულობას
• კონტექსტის ფანჯრის გათვალისწინება — იცავს თითოეული მოდელის ტოკენების ლიმიტებს

საუკეთესოა: ხანგრძლივი გამართვის სესიებისა და დიდი კოდური ბაზებისთვის.

ულტრა რეჟიმი (~75% დაზოგვა)

მაქსიმალური შეკუმშვა ტოკენების მხრივ კრიტიკული სცენარებისთვის:

• ევრისტიკული გაფილტვრა — აშორებს შესაბამისობის ზღვარზე დაბლა მყოფ შეტყობინებებს
• კოდის ბლოკების შემჭიდროება — კუმშავს განმეორებით კოდის მაგალითებს
• ორობითი ძიებით შეკვეცა — კონტექსტის ფანჯრისთვის პოულობს ოპტიმალურ ჭრის წერტილს
• მოიცავს აგრესიული რეჟიმის ყველა შესაძლებლობას

საუკეთესოა: როდესაც კონტექსტის ლიმიტებს ხშირად აწყდებით.

RTK რეჟიმი (გარე პროვაიდერთან 60-90%-იანი დიაპაზონი)

RTK რეჟიმი ოპტიმიზებულია პროგრამირების აგენტების სესიებში არსებული ვრცელი ინსტრუმენტული გამომავალი მონაცემებისთვის:

• ამოიცნობს ბრძანებების/გამომავალი მონაცემების კლასებს, როგორიცაა git status, git diff, git log, ტესტების გამშვები პროგრამები, TypeScript/Vite/Webpack-ის აგებები, ESLint/Biome/Prettier, npm-ის აუდიტები/ინსტალაციები, Docker-ის ჟურნალები, ინფრასტრუქტურის გამომავალი მონაცემები და გარსის ზოგადი გამომავალი მონაცემები
• იყენებს JSON-ფილტრების პაკეტებს open-sse/services/compression/engines/rtk/filters/-დან
• პროექტის ან გლობალური filters.toml ფაილებიდან ახდენს RTK TOML schema v1 ფილტრების იმპორტირებას, ჩაშენებული ტესტების ვალიდაციითა და პროექტის ფაილებისთვის ნდობაზე დაფუძნებული დაშვებით
• მოჰყვება 49 ჩაშენებული ფილტრი და ჩაშენებული შემოწმების ნიმუშები
• აშორებს ANSI საკონტროლო მიმდევრობებს, პროგრესის ზოლებს, განმეორებით ხაზებსა და არაპრაქტიკულ ხმაურს
• ინარჩუნებს წარუმატებლობებს, შეცდომებს, გაფრთხილებებს, შეცვლილ ფაილებს, შეჯამებებსა და გრძელი გამომავალი მონაცემების ბოლო ნაწილს
• მხარს უჭერს ნდობაზე დაფუძნებულ პროექტის ფილტრებს, გლობალურ ფილტრებსა და რედაქტირებული დაუმუშავებელი გამომავალი მონაცემების არასავალდებულო აღდგენას

საუკეთესოა: აგენტის სესიებისთვის, რომლებიც შეიცავს გარსის, აგების, ტესტების, git-ის, grep-ისა და ფაილების გამომავალი მონაცემების ჩანაწერებს.

დაწყობილი რეჟიმი (დასაშვები მონაცემების 78-95%-იანი დიაპაზონი)

დაწყობილი რეჟიმი შეკუმშვის რამდენიმე ძრავას განსაზღვრული თანმიმდევრობით უშვებს. ნაგულისხმევი კონვეიერია:

RTK -> Caveman

ეს თანმიმდევრობა ჯერ ტერმინალის/ინსტრუმენტის გამომავალ მონაცემებს ამჭიდროებს, შემდეგ კი დარჩენილ ბუნებრივ ენაზე დაწერილ მოთხოვნაზე Caveman-ის სემანტიკურ შემჭიდროებას იყენებს. დაწყობილი კონვეიერების კონფიგურაცია შესაძლებელია გლობალურად ან მარშრუტიზაციის კომბინაციებზე მინიჭებული შეკუმშვის კომბინაციების მეშვეობით.

საუკეთესოა: შერეული კონტექსტისთვის, რომელიც შეიცავს ინსტრუმენტების დიდ ჟურნალებს და ადამიანის ინსტრუქციებს ან ასისტენტის შეჯამებებს.

---

ზედა დონის დაზოგვის გამოთვლა

OmniRoute შეკუმშვით მიღებულ დანაზოგს ორი წყაროს საფუძველზე აღწერს: ზედა დონის პროექტების საორიენტაციო ტესტებისა და OmniRoute-ის საკუთარი ძრავების კომბინაციის.

წყარო	აქ გამოყენებული ზედა დონის README-ის მაჩვენებელი
Caveman	გამომავალი ტოკენების ~75%-ით ნაკლები რაოდენობა, საორიენტაციო ტესტებში გამომავალი მონაცემების საშუალოდ 65%-იანი დაზოგვა, 22-87% დიაპაზონი და შემავალი მონაცემების ~46%-იანი შეკუმშვის ხელსაწყო
RTK	ბრძანებების გამომავალი მონაცემების 60-90%-იანი დაზოგვა; სესიის მაგალითი: ~118,000 -> ~23,900 ტოკენი, ანუ დაზოგილია 79.7% (~80%)

გადაფარული ხელსაწყოს/კონტექსტის მონაცემებისთვის OmniRoute-ის ნაგულისხმევი კომბინაცია ძრავებს თანმიმდევრულად იყენებს:

RTK -> Caveman

ერთობლივი დაზოგვა მულტიპლიკაციურია და არა ადიტიური:

ერთობლივი = 1 - (1 - RTK-ის დაზოგვა) * (1 - Caveman-ის შემავალი მონაცემების დაზოგვა)
საშუალო   = 1 - (1 - 0.80) * (1 - 0.46) = 89.2%
დიაპაზონი = 1 - (1 - 0.60..0.90) * (1 - 0.46) = 78.4-94.6%

ეს 78-95% მაჩვენებელი გამოიყენება მაშინ, როდესაც RTK-სა და Caveman-ს ერთი და იმავე შემავალი მონაცემების/კონტექსტის მოცულობის შემცირება შეუძლიათ. Caveman-ის პასუხის გამომავალი რეჟიმი ცალკეა: მისი ჩართვისას გამოიყენეთ თავად Caveman-ის გამომავალი მონაცემების დაზოგვის მაჩვენებლები (საშუალოდ 65%, მთავარი მაჩვენებელი ~75%, დიაპაზონი 22-87%). ბილინგის ჯამური დაზოგვა დამოკიდებულია თქვენს მოთხოვნებსა და გამომავალ მონაცემებს შორის თანაფარდობაზე.

რას ნიშნავს სინამდვილეში „შესაფერისი“

მთავარ სათაურში მითითებული 15-95%-იანი დიაპაზონი რეალურია, მაგრამ ის მხოლოდ ჭარბ ან ზედმეტად ვრცელ შიგთავსზე ვრცელდება — განმეორებით შეცდომის სტრიქონებზე, აგების ჟურნალზე, რომელიც ერთსა და იმავე გაფრთხილებას განუწყვეტლივ იმეორებს, ან ზედმეტად დიდ grep/ფაილის წაკითხვის ამონაბეჭდზე. ეს არ ნიშნავს, რომ ყველა მოთხოვნა ამდენს დაზოგავს.

ემპირიულად დადასტურებულია (tests/unit/compression/stacked-compression-tool-result-savings.test.ts): stacked (RTK + Caveman) გაშვებამ Anthropic-ის ფორმის tool_result ბლოკზე, რომელიც 300 იდენტურ შეცდომის სტრიქონს შეიცავდა, უზრუნველყო ტოკენების 95.93%-იანი დაზოგვა / სიმბოლოების 96.26%-იანი დაზოგვა — ზუსტად რეკლამირებულ დიაპაზონში. თუმცა, იმავე კონვეიერის გაშვება ჩვეულებრივ, არაგანმეორებად ხელსაწყოს გამომავალ მონაცემებზე (grep-ის დამთხვევების სუფთა სია, მოკლე ფაილის წაკითხვა, ჩვეულებრივი სასაუბრო ტექსტი) სამართლიანად იძლევა თითქმის ნულოვან დაზოგვას, რადგან წასაშლელი განმეორებადი შიგთავსი არ არსებობს და validateCompression() (validation.ts) უარს ამბობს ისეთი გადაწერილი ვერსიის გაგზავნაზე, რომელიც კოდის ბლოკებს, URL-ებს, სათაურებს, ვერსიებს ან ALL-CAPS მუდმივების იდენტიფიკატორებს ამოიღებს ან შეცვლის.

ეს მოსალოდნელი და უსაფრთხო ქცევაა და არა ხარვეზი: პროგრამირების სესია, რომელიც ძირითადად სუფთა ფაილებს კითხულობს ან მათში grep-ით ეძებს, სრულად ჩართული შეკუმშვის შემთხვევაშიც კი ზომიერ ჯამურ დაზოგვას აჩვენებს, ხოლო სესია, რომელიც შეცდომების ციკლს ან ზედმეტად მრავალსიტყვიან ლინტერს წააწყდება, ამ ტრაფიკზე სრულ 78-95%-იან დიაპაზონს მიიღებს. ნუ გამოიყენებთ ერთი სესიის დაბალ ჯამურ დაზოგვის პროცენტს იმის მტკიცებულებად, რომ შეკუმშვა არასწორადაა კონფიგურირებული — ჯერ შეამოწმეთ, იყო თუ არა ხელსაწყოს ძირითადი გამომავალი მონაცემები რეალურად განმეორებადი.

---

ტოკენების დაზოგვის ვიზუალიზაცია

შეკუმშვის გარეშე: 47K ტოკენი იგზავნება LLM-ში
Lite-ით:          40K ტოკენი იგზავნება          (დაზოგილია 15% — უსაფრთხო, ყოველთვის ჩართული)
Standard-ით:      33K ტოკენი იგზავნება          (დაზოგილია 30% — Caveman-ის მეტყველების წესები)
Aggressive-ით:    24K ტოკენი იგზავნება          (დაზოგილია 50% — დაძველება + შეჯამება)
Ultra-თი:         12K ტოკენი იგზავნება          (დაზოგილია 75% — ევრისტიკული გასხვლა)
RTK-ით:           19K-5K ტოკენი იგზავნება       (ბრძანების/ხელსაწყოს გამომავალ მონაცემებზე დაზოგილია 60-90%)
Stacked-ით:       10K-2.5K ტოკენი იგზავნება     (შესაფერის მონაცემებზე RTK+Caveman-ის 78-95%-იანი დიაპაზონი)

---

კონფიგურაცია

მართვის პანელი

გადადით Dashboard → Context & Cache-ზე:

• Caveman — რეჟიმის არჩევა, ენის პაკეტები, წინასწარი გადახედვა და გლობალური ნაგულისხმევი პარამეტრები
• RTK — ბრძანებების ფილტრის წინასწარი გადახედვა, RTK-ის უსაფრთხოების პარამეტრები და ფილტრების კატალოგი
• Compression Combos — მარშრუტიზაციის კომბინაციებზე მინიჭებული, სახელდებული ძრავების კონვეიერები
• Auto-Trigger Threshold — შეკუმშვის ავტომატურად ჩართვა, როდესაც ტოკენების რაოდენობა ზღვრულ მნიშვნელობას გადააჭარბებს

ცალკეული კომბინაციის გადაფარვა

Dashboard → Context & Cache → Compression Combos-ში შეკუმშვის კომბინაცია მიანიჭეთ მარშრუტიზაციის კომბინაციას:

კომბინაცია: "free-tier-fallback"
  შეკუმშვის კომბინაცია: "coding-agent-stack"
  კონვეიერი: RTK -> Caveman
  სამიზნეები:
    1. if/kimi-k2.7-code
    2. if/qwen3.8-max-preview

ეს საშუალებას გაძლევთ, უფასო/პროგრამირებისთვის განკუთვნილ პროვაიდერებზე გამოიყენოთ მრავალსაფეხურიანი შეკუმშვა, ხოლო ფასიან გამოწერებზე შეინარჩუნოთ lite რეჟიმი.

ეს „ცალკეული კომბინაციის გადაფარვის“ მინიჭება განსხვავდება მარშრუტიზაციის კომბინაციის შეკუმშვის რეჟიმის გადაფარვისგან (Default/Off/Lite/Standard/Aggressive/Ultra) — ეს გადაფარვა არ ირჩევს სახელდებულ შეკუმშვის კომბინაციის კონვეიერს; ის მხოლოდ ადგენს compressionMode ველს, რომელსაც resolveCompressionPlan იყენებს. მისი დაყენება შესაძლებელია კომბინაციის ბარათზე (Dashboard → Combos) ან, начиная #6760-დან, ცალკეული მარშრუტიზაციის კომბინაციისთვის „Assign to routing“ სიაში, Dashboard → Context & Cache → Compression Combos-ში, ზემოთ აღწერილი კონვეიერის მინიჭების მოსანიშნი ველის გვერდით. ორივე ინტერფეისი მონაცემებს ინახავს ერთი და იმავე PUT /api/combos/{id} საბოლოო წერტილის მეშვეობით.

ცალკეული მოთხოვნის გადაფარვა

ერთი მოთხოვნისთვის შეკუმშვის გეგმის გადასაფარად გაგზავნეთ x-omniroute-compression მოთხოვნის სათაური. მას ყველაზე მაღალი პრიორიტეტი აქვს — ის გადაწონის მარშრუტიზაციის კომბინაციის გადაფარვას, აქტიურ პროფილს, ავტომატურ გაშვებასა და პანელის Default მნიშვნელობას. უცნობი მნიშვნელობები უგულებელყოფილია (მოთხოვნა არასოდეს უარყოფილდება), ხოლო გლობალური მთავარი გადამრთველი კვლავ ყველაფერს აკონტროლებს: როდესაც შეკუმშვა გლობალურად გამორთულია, სათაური მას ვერ ჩართავს. მნიშვნელობები:

მნიშვნელობა	ეფექტი
off	ამ მოთხოვნისთვის შეკუმშვა არ გამოიყენება.
default	პანელიდან მიღებული Default პროფილი (აქტიურ პროფილს უგულებელყოფს).
engine:<id>	ჩართული ერთი ძრავა, მაგ. engine:rtk.
<combo>	სახელდებული კომბინაცია, რომელიც ჯერ სახელით (რეგისტრის გაუთვალისწინებლად), შემდეგ კი id-ით ემთხვევა.

გამოყენებული გეგმა პასუხში აისახება X-OmniRoute-Compression: <mode>; source=<source> სათაურის სახით, სადაც <source> არის ერთ-ერთი შემდეგიდან: request-header, routing-override, active-profile, auto-trigger, default ან off.

API

# შეკუმშვის პარამეტრების მიღება
curl http://localhost:20128/api/settings/compression

# შეკუმშვის პარამეტრების განახლება
curl -X PUT http://localhost:20128/api/settings/compression \
  -H "Content-Type: application/json" \
  -d '{"defaultMode":"stacked","autoTriggerMode":"stacked","autoTriggerTokens":32000}'

# კონკრეტული RTK/stacked დატვირთვის წინასწარი გადახედვა
curl -X POST http://localhost:20128/api/compression/preview \
  -H "Content-Type: application/json" \
  -d '{"mode":"rtk","messages":[{"role":"tool","content":"npm test output here"}]}'

# RTK ფილტრების პაკეტების ჩამონათვალი
curl http://localhost:20128/api/context/rtk/filters

# RTK-ის უშუალოდ ტესტირება ბრძანების არასავალდებულო მეტამონაცემებით
curl -X POST http://localhost:20128/api/context/rtk/test \
  -H "Content-Type: application/json" \
  -d '{"command":"npm test","text":"FAIL tests/example.test.ts\nError: boom"}'

---

რა არის დაცული

შეკუმშვის ძრავა ყოველთვის ინარჩუნებს:

• ✅ კოდის ბლოკებს (შემოსაზღვრულსა და სტრიქონშიდა კოდს)
• ✅ URL-ებსა და ფაილების მისამართებს
• ✅ JSON სტრუქტურებსა და სტრუქტურირებულ მონაცემებს
• ✅ იდენტიფიკატორებსა და დაცულ ტექნიკურ ტოკენებს
• ✅ მათემატიკურ გამოსახულებებს
• ✅ ხელსაწყოების/ფუნქციების გამოძახების განსაზღვრებებს
• ✅ სისტემურ მოთხოვნებს (lite რეჟიმში)

RTK-ის დაუმუშავებელი გამომავალი მონაცემების აღდგენის მექანიზმი, მონაცემების შენახვამდე, ფარავს გავრცელებულ API გასაღებებს, bearer ტოკენებს, Slack-ის ტოკენებს, AWS-ის წვდომის გასაღებებს, პაროლებს, ტოკენებსა და საიდუმლო მონაცემებს.

---

შეკუმშვის სტატისტიკა

ყოველი შეკუმშული მოთხოვნის სტატისტიკა სერვერის ჟურნალებში აისახება:

{
  "originalTokens": 47200,
  "compressedTokens": 40120,
  "savingsPercent": 15.0,
  "techniquesUsed": ["collapseWhitespace", "dedupSystemPrompt"],
  "mode": "lite",
  "engine": "caveman",
  "compressionComboId": "coding-agent-stack",
  "durationMs": 0.8,
  "rtkRawOutputPointers": []
}

---

ფაზების სამოქმედო გეგმა

ფაზა	რეჟიმები	სტატუსი
ფაზა 1	Off, Lite	✅ გამოშვებულია
ფაზა 2	Standard, Aggressive, Ultra	✅ გამოშვებულია
ფაზა 3	RTK, Stacked, შეკუმშვის კომბინაციები	✅ გამოშვებულია
ფაზა 4	გამომავალი მონაცემების სტილები, SLM-დონის Ultra, შეფასების ინფრასტრუქტურა	✅ გამოშვებულია
ფაზა 4C	კონტექსტის ბიუჯეტის ადაპტაციური მართვა ("dial") — გამოთვლითი ძრავა + API (contextBudget მისამართზე PUT /api/settings/compression) + მართვის პანელის რეჟიმის/პოლიტიკის მართვის ელემენტები	✅ გამოშვებულია

---

მადლობები

Standard რეჟიმის შეკუმშვის წესები შთაგონებულია Caveman-ით, რომლის ავტორია JuliusBrussee (⭐ 51K+) — ვირუსულად გავრცელებული პროექტი „რატომ გამოვიყენოთ ბევრი ტოკენი, როცა ცოტაც საკმარისია“. Caveman-ის მონაცემებით, გამომავალი ტოკენების რაოდენობა მცირდება ~75%-ით, საორიენტაციო ტესტებში გამომავალი მონაცემების საშუალო ეკონომიაა 65%, გამომავალი მონაცემების ეკონომიის დიაპაზონია 22-87%, ხოლო შემავალი მონაცემების შეკუმშვის ხელსაწყოს მაჩვენებელია ~46%.

RTK რეჟიმი შთაგონებულია RTK - Rust Token Killer-ით, რომლის ავტორია RTK AI — ეს არის მაღალი წარმადობის მქონე პროექტი, რომელიც განკუთვნილია ტერმინალის, აწყობის, ტესტირების, git-ისა და ხელსაწყოების გამომავალი მონაცემების შეკუმშვისა და გაფილტვრისთვის. RTK-ის მონაცემებით, ეკონომია 60-90%-ს შეადგენს, ხოლო მის README-ში მოცემულ სესიის ნიმუშში დაზოგილია ~80%.

---

შეკუმშვის გაფართოებული სისტემები

7 სტანდარტული რეჟიმის გარდა, OmniRoute შეიცავს შეკუმშვის რამდენიმე გაფართოებულ სისტემას, რომლებიც კონტექსტის მიხედვით ავტომატურად მუშაობენ.

ქეშის გათვალისწინებით შეკუმშვა

ზოგიერთი პროვაიდერი (მაგალითად, Anthropic მოთხოვნების ქეშირებით) მხარს უჭერს მოთხოვნების ქეშირებას, რაც მათ საშუალებას აძლევს, ხარჯებისა და დაყოვნების შესამცირებლად მოთხოვნის ნაწილები დააქეშირონ. როდესაც ქეშირება ჩართულია, აგრესიულმა შეკუმშვამ შესაძლოა წარმადობა რეალურად გააუარესოს, რადგან ის ცვლის დაქეშირებულ ტოკენებს და ქეშს აუქმებს.

cachingAware.ts მოდული ამ პრობლემას ქეშირების კონტექსტის გამოვლენითა და შეკუმშვის სტრატეგიის შესაბამისი კორექტირებით წყვეტს.

როგორ მუშაობს

1. ქეშირების კონტექსტის გამოვლენა — მოთხოვნის სხეულს cache_control მარკერების მოსაძებნად ამოწმებს
2. ქეშირების მხარდამჭერი პროვაიდერების იდენტიფიცირება — ამოწმებს, აქვს თუ არა სამიზნე პროვაიდერს ქეშირების მხარდაჭერა
3. სტრატეგიის კორექტირება — ქეშირების მხარდამჭერი პროვაიდერებისთვის aggressive/ultra რეჟიმს standard-მდე აქვეითებს
4. სისტემური მოთხოვნის გამოტოვება — სისტემური მოთხოვნები, ჩვეულებრივ, დაქეშირებულია, ამიტომ ისინი არ შეკუმშოთ
5. დეტერმინისტული გარდაქმნების გამოყენება — გამოიყენება მხოლოდ ის გარდაქმნები, რომლებიც თანმიმდევრულ გამომავალ მონაცემებს ქმნიან

კოდის მაგალითი

import {
  detectCachingContext,
  getCacheAwareStrategy,
} from "@omniroute/open-sse/services/compression/cachingAware";

const body = {
  model: "anthropic/claude-sonnet-4.5",
  messages: [{ role: "user", content: "Hello" }],
  cache_control: { type: "ephemeral" }, // ← ქეშის მარკერი
};

const ctx = detectCachingContext(body, { provider: "anthropic" });
// → { hasCacheControl: true, provider: "anthropic", isCachingProvider: true }

const strategy = getCacheAwareStrategy("aggressive", ctx);
// → { strategy: "standard", skipSystemPrompt: true, deterministicOnly: true }

როდის გამოიყენება

ქეშის გათვალისწინებით შეკუმშვა ყოველთვის ჩართულია — კონფიგურაცია საჭირო არ არის. ის მხოლოდ მაშინ აქტიურდება, როდესაც:

• მოთხოვნას აქვს cache_control მარკერები
• სამიზნე პროვაიდერს აქვს მოთხოვნების ქეშირების მხარდაჭერა (Anthropic, OpenAI და სხვ.)

პროგრესული დაძველება

ხანგრძლივ საუბრებში შეტყობინებების მრავალი რაუნდი გროვდება, თუმცა ძველი რაუნდები თანდათან ნაკლებად რელევანტური ხდება. progressiveAging.ts მოდული შეტყობინებების დეტალიზაციას რაუნდის დაშორების მიხედვით ამცირებს:

• უახლესი რაუნდები (0-3): უცვლელად ინახება (სრული დეტალიზაცია)
• საშუალო ასაკის რაუნდები (4-8): Lite შეკუმშვა (ჰარების, ფორმატირების გასუფთავება)
• ძველი რაუნდები (9+): Caveman შეკუმშვა (ზედმეტი ტექსტის მოცილება, შეჯამება)
• ძალიან ძველი რაუნდები (20+): ინტენსიურად ჯამდება ან იშლება

კოდის მაგალითი

import { applyAging } from "@omniroute/open-sse/services/compression/progressiveAging";

const messages = [
  { role: "system", content: "You are a helpful assistant" },
  { role: "user", content: "What is 2+2?" },
  { role: "assistant", content: "4" },
  // ... კიდევ 50 რაუნდი ...
];

const { messages: aged, saved } = applyAging(messages, {
  verbatim: 3, // პირველი 3 რაუნდი: უცვლელად
  light: 8, // რაუნდები 4-8: lite შეკუმშვა
  moderate: 20, // რაუნდები 9-20: caveman შეკუმშვა
  // რაუნდები 21+: ინტენსიური შეჯამება
});

// saved = დაზოგილი ტოკენების რაოდენობა

როდის გამოიყენება

პროგრესული დაძველება aggressive და ultra რეჟიმებისთვის ყოველთვის ჩართულია. ის განსაკუთრებით ეფექტურია:

• ხანგრძლივი კოდირების სესიებისთვის
• მრავალდღიანი საუბრებისთვის
• მრავალი ინსტრუმენტის გამოძახების მქონე აგენტური სამუშაო პროცესებისთვის

გამოქვაბულის ადამიანის გამოტანის რეჟიმი

outputMode.ts მოდული ამატებს სისტემური მოთხოვნის ინსტრუქციებს, რათა თავად მოდელმა შექმნას შეკუმშული, ლაკონიური გამოტანა („გამოქვაბულის ადამიანის“ სტილში).

როგორ მუშაობს

შეყვანის შეკუმშვის ნაცვლად, ეს რეჟიმი ამატებს შემდეგის მსგავს სისტემურ მოთხოვნას:

„უპასუხე მინიმალური რაოდენობის სიტყვებით. გამოტოვე თავაზიანობის ფრაზები. გამოიყენე მოკლე წინადადებები.“

ეს განსაკუთრებით კარგად მუშაობს შემდეგ შემთხვევებში:

• კოდის გენერირება (უფრო ლაკონიური გამოტანა = ნაკლები ტოკენი)
• სწრაფი კითხვა-პასუხი (ვრცელი განმარტებები საჭირო არ არის)
• პაკეტური დამუშავება (გამტარუნარიანობის მაქსიმიზაცია)

როდის გამოვიყენოთ

გამოქვაბულის ადამიანის გამოტანის რეჟიმი არჩევითია — დააყენეთ ის კომბინირებული კონფიგურაციის მეშვეობით:

{
  "strategy": "auto",
  "config": {
    "auto": {
      "outputMode": "caveman"
    }
  }
}

გამოტანის სტილები (კატალოგი)

ზემოთ აღწერილი გამოქვაბულის ადამიანის გამოტანის რეჟიმი ძველი, ერთსტილიანი გზაა. მე-4 ფაზაში ის განზოგადდა კომბინირებადი გამოტანის სტილების კატალოგად: OUTPUT_STYLE_CATALOG ფაილში open-sse/services/compression/outputStyles/catalog.ts. თითოეული სტილი სისტემური მოთხოვნის ინსტრუქციაა, რომელიც თავად მოდელს უფრო ეკონომიური გამოტანის შექმნას აიძულებს; სტილები შეიძლება ერთდროულად ჩაირთოს და ისინი კატალოგის თანმიმდევრობით ემატება.

სტილი	id	რას აკეთებს	ინსტრუქციის ენები
ლაკონიური პროზა	terse-prose	აშორებს ზედმეტ სიტყვებს/არტიკლებს/თავის დაზღვევის ფრაზებს; ტექნიკურ შინაარსს ზუსტად ინარჩუნებს. ტექსტი იგივეა, რაც ძველ გამოქვაბულის ადამიანის გამოტანის რეჟიმში (მითითებით გამოიყენება და ხელახლა არ იწერება).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
ნაკლები კოდი	less-code	YAGNI-ს საფეხურები: უმცირესი მოქმედი ცვლილება, მოუთხოვნელი აბსტრაქციების გარეშე.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
ცხენისკუდა (ზარმაცი უფროსი დეველოპერი)	ponytail	„საუკეთესო კოდი ის კოდია, რომელიც არასოდეს დაწერილა“: ხელახალი გამოყენება > თავიდან დაწერა, ძირეული მიზეზი > სიმპტომი, უმოკლესი მოქმედი განსხვავება.	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
მე მაქვს ADHD (ჯერ მოქმედება)	i-have-adhd	ჯერ მოქმედება (ბრძანება/გზა/ფრაგმენტი ტექსტურ აღწერამდე), დანომრილი და შეზღუდული ნაბიჯები, ერთი კონკრეტული შემდეგი ნაბიჯი, შესავლის/შეჯამების/დასკვნითი ფრაზების გარეშე. ადაპტირებულია ayghri/i-have-adhd-დან (MIT).	en, pt-BR, es, de, fr, it, ru, zh, ja, id, vi
ლაკონიური CJK (文言)	terse-cjk	ულტრალაკონიური კლასიკური ჩინური სტილი.	zh (ლოკალით შეზღუდული: შემოთავაზებულია მხოლოდ მაშინ, როდესაც განსაზღვრული ენაა zh)

თითოეულ სტილს აქვს ინტენსივობის სამი დონე — lite, full, ultra — და ყოველი დონე სრულდება საერთო შეზღუდვების პუნქტით, რომელიც კოდის ბლოკებს, ფაილის გზებს, ბრძანებებს, შეცდომის სტრიქონებს, URL-ებსა და იდენტიფიკატორებს უცვლელად ინარჩუნებს.

როგორ მუშაობს დამატება

applyOutputStyles() (open-sse/services/compression/outputStyles/apply.ts) არჩევანს კატალოგთან ადარებს (უცნობი id-ები და ლოკალთან შეუსაბამო სტილები გამოიტოვება და შეცდომას არასოდეს იწვევს), არჩეულ ინსტრუქციებს კატალოგის თანმიმდევრობით აერთიანებს, შეზღუდვების პუნქტს ერთხელ ამატებს და შედეგს ერთი იდემპოტენტურობის მარკერის ([OmniRoute Output Styles]) შემდეგ სისტემური მოთხოვნის დასაწყისში ათავსებს — ხელახალი გამოყენება არაფერს ცვლის. როდესაც გამოვლენილი მოთხოვნის ენისთვის თარგმანი არსებობს, ინგლისურის ნაცვლად ლოკალიზებული ინსტრუქცია ემატება.

როგორ ჩავრთოთ

მართვის პანელში: კონტექსტი → პარამეტრები → შეკუმშვა — თითო სტილზე ერთი მწკრივი, ჩართვა/გამორთვის გადამრთველითა და დონის ამრჩევით. პროგრამულად, შეკუმშვის კონფიგურაცია არჩევანს შემდეგი სახით ინახავს:

{
  "outputStyles": [
    { "id": "i-have-adhd", "level": "full" },
    { "id": "less-code", "level": "lite" }
  ]
}

უკუთავსებადობა: ძველი კომბინირებული პარამეტრი outputMode: "caveman" კვლავ მუშაობს და შეესაბამება terse-prose-ს; ყოველ ძველ ენაზე ის ბაიტობრივად იდენტურია ძველი დამატებისა.

ენის არჩევა: როდესაც languageConfig.enabled ჩართულია, autoDetect ირჩევს მომხმარებლის უახლესი შეტყობინების ენას (იგივე დეტექტორით, რომელსაც შეყვანის ძრავები იყენებს); autoDetect-ის გამორთვა აფიქსირებს defaultLanguage-ს. გამორთული → ინგლისური.

სტილისა და ენის მატრიცა დაფიქსირებულია ფაილით tests/unit/compression/output-styles-i18n-matrix.test.ts: ახალი სტილი ვერ გამოვა სულ მცირე pt-BR თარგმანის გარეშე (ან ცხადად აღრიცხული გამონაკლისის გარეშე), ხოლო არსებული სტილი ლოკალს შეუმჩნევლად ვერ დაკარგავს. სტილის დასამატებლად იხილეთ EXTENDING_COMPRESSION.md.

ინსტრუმენტის შედეგების შეკუმშვა

toolResultCompressor.ts მოდული ინსტრუმენტის შედეგებისთვის (ფუნქციების გამოძახებები, აგენტების გამოტანა, ძიების შედეგები და ა.შ.) უზრუნველყოფს შეკუმშვის 5 სპეციალიზებულ სტრატეგიას:

1. ძიების შედეგების შეკუმშვა — აშორებს დუბლირებულ შედეგებს და ინარჩუნებს საუკეთესო N შედეგს
2. ფაილის წაკითხვის შეკუმშვა — ამოკლებს დიდ ფაილებს და ინარჩუნებს სათაურებს/იმპორტებს
3. კოდის შესრულების შეკუმშვა — ინარჩუნებს მხოლოდ აუცილებელ stdout/stderr-ს
4. მონაცემთა ბაზის მოთხოვნის შეკუმშვა — ზღუდავს მწკრივებს და აშორებს ჭარბ მეტამონაცემებს
5. API პასუხის შეკუმშვა — აშორებს null ველებს და ამოკლებს მასივებს

როდის გამოვიყენოთ

ინსტრუმენტის შედეგების შეკუმშვა ინსტრუმენტის გამოძახებების არსებობისას ყოველთვის ჩართულია. კონფიგურაცია საჭირო არ არის.

თანმიმდევრული კონვეიერი

თანმიმდევრული რეჟიმი რამდენიმე ძრავას მიმდევრობით უშვებს — ჩვეულებრივ, ჯერ RTK-ს (ინსტრუმენტის გამოტანაზე 60-90%-იანი ეკონომია), შემდეგ კი Caveman-ს (დარჩენილ ტექსტზე დამატებით 30%-იანი ეკონომია). ამით მიიღწევა საერთო 78-95%-იანი ეკონომია.

როგორ მუშაობს

შეყვანა (1000 ტოკენი)
  → RTK (ბრძანებების გათვალისწინებით მოქმედი ფილტრი) → 200 ტოკენი
    → Caveman (ზედმეტი სიტყვების მოცილება) → 140 ტოკენი
  → გამოტანა (140 ტოკენი, 86%-იანი ეკონომია)

როდის გამოვიყენოთ

გამოიყენეთ თანმიმდევრული რეჟიმი:

• ინსტრუმენტებით დატვირთული სამუშაო პროცესებისთვის (აგენტური კოდირება, კვლევა)
• ხარჯებისადმი მგრძნობიარე პაკეტური დამუშავებისთვის
• როდესაც ტოკენების მაქსიმალური ეკონომია გჭირდებათ

დააკონფიგურირეთ კომბინაციის მეშვეობით:

{
  "strategy": "auto",
  "config": {
    "auto": {
      "modePack": "stacked"
    }
  }
}

---

შეკუმშვის კომბინაციების გადაფარვები

შეგიძლიათ, სხვადასხვა გამოყენების შემთხვევებისთვის ქცევის ზუსტად მოსარგებად, შეკუმშვის გლობალური რეჟიმი თითოეული კომბინაციისთვის ცალ-ცალკე გადაფაროთ:

{
  "id": "coding-combo",
  "strategy": "priority",
  "config": {
    "auto": {
      "weights": { "taskFit": 0.5 },
      "modePack": "quality-first"
    }
  },
  "compressionOverride": {
    "mode": "aggressive",
    "stackedPipelines": ["rtk", "caveman"],
    "preserveToolDefinitions": true
  }
}

ეს სასარგებლოა შემდეგ შემთხვევებში:

• პროგრამირების კომბინაციები: ხანგრძლივი სესიებისთვის გამოიყენეთ aggressive რეჟიმი
• სწრაფი კითხვა-პასუხის კომბინაციები: სწრაფი პასუხებისთვის გამოიყენეთ lite რეჟიმი
• ინსტრუმენტებზე ინტენსიურად დამოკიდებული კომბინაციები: მაქსიმალური ეკონომიისთვის გამოიყენეთ stacked რეჟიმი
• საწარმოო გარემოს კომბინაციები: ქეშირების მხარდამჭერ პროვაიდერებთან გამოიყენეთ cache-aware რეჟიმი

---

აგრეთვე იხილეთ

• გარემოს კონფიგურაცია — შეკუმშვის გარემოს ცვლადები
• არქიტექტურის სახელმძღვანელო — შეკუმშვის კონვეიერის შიდა მექანიზმები
• მომხმარებლის სახელმძღვანელო — შეკუმშვის გამოყენების დაწყება
• RTK შეკუმშვა — RTK ფილტრები, ნდობის მოდელი, შემოწმების კარიბჭე, დაუმუშავებელი გამომავალი მონაცემების აღდგენა
• შეკუმშვის ძრავები — Caveman, RTK, გაერთიანებული რეჟიმი, API-ები, MCP, მართვის პანელი
• შეკუმშვის წესების ფორმატი — JSON წესების პაკეტის ფორმატი
• შეკუმშვის ენობრივი პაკეტები — ენისთვის სპეციფიკური Caveman-ის წესები