Files
OmniRoute/docs/i18n/ka/docs/compression/RTK_COMPRESSION.md
Diego Rodrigues de Sa e Souza 8feea123bb feat(docs): mirror every docs/ page in all 65 locales (#14106)
* feat(docs): mirror every docs/ page in all 65 locales

Extends the documentation mirrors from the 22-page core set (#13940) to
every Markdown page under docs/: 152 sources x 65 locales = 9,880 mirrors
(6,208 new), language bars rewritten for the full locale list, state
adopted so the blocking drift gate now covers all 152 pages.

run-translation.mjs: an oversized block made only of table rows or list
items (PROVIDER_REFERENCE.md 244-row table, FREE_TIERS.md 71-item list) is
cut at item boundaries and rejoined without a blank line — the single
16-40 KB request outlived the backend socket for verbose scripts. 48
older mirrors whose tables had lost rows were retranslated with --force.

* docs(i18n): refresh mirrors for the sources the base changed since the branch cut

Section-level retranslation of the 29 docs (and README.md) whose source
or mirrors moved on release/v3.8.51 during the run, then state adoption;
the drift gate is green again on the merged tree.
2026-09-18 13:16:46 -03:00

66 KiB
Raw Blame History

RTK Compression (ქართული)

🌐 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


RTK შეკუმშვა არის OmniRoute-ის ბრძანებების მცოდნე შეკუმშვის ძრავა ტერმინალისა და ხელსაწყოების გამოტანისთვის. ის შექმნილია კოდის წერის აგენტების სესიებისთვის, რომლებშიც კონტექსტის ზრდის უდიდესი ნაწილი მოდის ტესტების ჟურნალებზე, აგების გამოტანაზე, პაკეტების მენეჯერების ხმაურზე, გარსის ტრანსკრიპტებზე, Docker-ის გამოტანაზე, git-ის გამოტანასა და სტეკის კვალზე.

RTK შეიძლება უშუალოდ გაეშვას defaultMode: "rtk"-ით ან მრავალსაფეხურიანი კონვეიერის პირველ ნაბიჯად, ჩვეულებრივ:

rtk -> caveman

ეს მიმდევრობა ჯერ ხმაურიან მანქანურ გამოტანას კუმშავს, შემდეგ კი Caveman-ს დარჩენილი პროზის შემოკლების საშუალებას აძლევს.

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

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

რას კუმშავს

ჩაშენებული კატალოგი ამჟამად ამ კატეგორიებში განაწილებულ 49 ფილტრს შეიცავს:

კატეგორია მაგალითები
git git status, git branch, git diff, git log
test Vitest, Jest, Pytest, Playwright, Go-ის ტესტები, Cargo-ს ტესტები
build TypeScript, ESLint, Biome, Prettier, Vite, Webpack, Turbo, Nx
package npm install, npm audit, pip, uv sync, Poetry, Bundler
shell ls, find, grep, ზოგადი გარსის ჟურნალები
docker docker ps, Docker-ის ჟურნალები
infra Terraform, OpenTofu, systemctl status
generic JSON გამოტანა, სტეკის კვალი, ზოგადი გამოტანის სარეზერვო ვარიანტი

open-sse/services/compression/engines/rtk/commandDetector.ts-ში არსებული დეტექტორი ფილტრის არჩევამდე გამოტანის კლასიფიკაციას ახდენს. ფილტრებს ასევე შეუძლიათ ბრძანების ნიმუშით ან გამოტანის რეგულარული გამოსახულებით დამთხვევა, როდესაც ბრძანების კლასი საკმარისი არ არის.

ფილტრების განსაზღვრა

RTK ფილტრებს შემდეგი თანმიმდევრობით ტვირთავს:

  1. პროექტის ფილტრები .rtk/filters.toml-დან და .rtk/filters.json-დან, მხოლოდ ნდობის არსებობისას.
  2. გლობალური ფილტრები DATA_DIR/rtk/filters.toml-დან და DATA_DIR/rtk/filters.json-დან.
  3. ჩაშენებული ფილტრები open-sse/services/compression/engines/rtk/filters/-დან.

ერთი და იმავე არეალის ფარგლებში RTK TOML სქემის v1 ფილტრებს OmniRoute JSON ფილტრებთან შედარებით უპირატესობა ენიჭება. TOML-ის match_command გამოსახულებები ბრძანების ტიპით დამთხვევამდე მოწმდება, რათა იმპორტირებულმა, კონკრეტული ბრძანებისთვის განკუთვნილმა ფილტრმა ამ არეალში უფრო ზოგადი ფილტრი ჩაანაცვლოს. ფაილის ფორმატის მიუხედავად, პროექტის არეალს კვლავ ენიჭება უპირატესობა გლობალურ არეალთან შედარებით.

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

  • rtkConfig.trustProjectFilters არის true.
  • დაყენებულია OMNIROUTE_RTK_TRUST_PROJECT_FILTERS=1.
  • .rtk/trust.json შეიცავს პროექტის ფილტრის ფაილის შესაბამის SHA-256 ჰეშს.

ნდობის ფაილის მაგალითი:

{
  "filtersSha256": "0123456789abcdef...",
  "filtersTomlSha256": "fedcba9876543210..."
}

ჰეშები განცალკევებულია: filtersSha256 ნდობას ანიჭებს .rtk/filters.json-ს, ხოლო filtersTomlSha256 ნდობას ანიჭებს .rtk/filters.toml-ს. რომელიმე ფაილის რედაქტირება მხოლოდ მის საკუთარ ნდობის ჩანაწერს აბათილებს. გლობალური ფაილები ადმინისტრატორის მიერაა დაყენებული და გლობალური ფილტრებისთვის უკვე არსებულ ნდობის მექანიზმს იყენებს.

მორგებული ფილტრები შეიძლება წარმოდგენილი იყოს ერთი ფილტრის ობიექტის ან ფილტრის ობიექტების მასივის სახით. არასწორი მორგებული ფილტრები გამოიტოვება და მათ შესახებ ინფორმაცია /api/context/rtk/filters დიაგნოსტიკაში აისახება. არასწორი ჩაშენებული ფილტრების აღმოჩენისას მუშაობა დაუყოვნებლივ წყდება.

RTK TOML სქემის v1-თან თავსებადობა

OmniRoute-ს შეუძლია RTK TOML სქემის v1-ის გამოყენებით დეკლარაციული ფილტრების ფაილების დამუშავება, ვალიდაცია, ტესტირება და დაყენება. მხარდაჭერილი ველებია description, match_command, strip_ansi, filter_stderr, strip_lines_matching, keep_lines_matching, replace, match_output, truncate_lines_at, head_lines, tail_lines, max_lines, on_empty და [[tests.<filter>]] ჩაშენებული ტესტები. უცნობი ველები, არასწორი ან სახიფათო რეგულარული გამოსახულებები, ერთდროული strip/keep წესები, 1 MiB-ზე დიდი ფაილები და უცნობ ფილტრებზე მითითებები უარყოფილია. ფაილი, რომლის ჩაშენებული ტესტებიც წარუმატებელია, შესამოწმებლად შეიძლება ვალიდირდეს, მაგრამ მისი დაყენება ან ჩატვირთვა შეუძლებელია. მორგებული ფაილის ჩატვირთვის შეცდომებისას კვლავ მოქმედებს fail-open მიდგომა: არასწორი ფაილი გამოტოვებულია, ხოლო დარჩენილი ფილტრები მუშაობას განაგრძობს.

OmniRoute ხელსაწყოს გამოტანილ მონაცემებს იღებს მას შემდეგ, რაც კლიენტმა ისინი უკვე ჩაიწერა, ამიტომ filter_stderr = true პროცესის მონაცემთა ჩაწერას ვერ შეცვლის. ველი მიიღება როგორც ოპერაციის არშემსრულებელი და ვალიდაცია გაფრთხილებას აბრუნებს. ეს განზრახ არის აღწერილი როგორც RTK TOML სქემის v1-თან თავსებადობა და არა სრული თავსებადობა RTK შესრულებად ფაილთან, გარსის ჰუკებთან, Rust ბრძანებების იმპლემენტაციებთან ან მისი ნდობის საცავის სტრუქტურასთან.

მართვის პანელის გაფართოებული RTK ხედი იღებს ჩასმულ ან ატვირთულ TOML-ს. ვალიდაცია მხოლოდ წაკითხვადია. დაყენებისას DATA_DIR/rtk/filters.toml ატომურად, შეზღუდული ნებართვებით იწერება და მოქმედი ფილტრების კატალოგი გადატვირთვის გარეშე განახლდება. არსებული ფაილის ჩანაცვლება მოითხოვს overwrite დადასტურებას და ჯერ ქმნის DATA_DIR/rtk/filters.toml.bak-ს.

ფილტრების DSL

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

stripAnsi -> filterStderr -> replace -> matchOutput -> ხაზების მოცილება/ჩართვა
  -> truncateLineAt -> head/tail/maxLines -> onEmpty

მნიშვნელოვანი ველები:

ველი დანიშნულება
rules.stripAnsi დამთხვევამდე ტერმინალის ფერის/მართვის მიმდევრობების მოცილება
rules.filterStderr დამთხვევამდე/გაფილტვრამდე გავრცელებული stderr პრეფიქსების ნორმალიზება
rules.replace დალაგებული რეგულარული გამოსახულებების ჩანაცვლებების გამოყენება
rules.matchOutput კომპაქტური შეჯამების დაბრუნება, როდესაც გამოტანილი მონაცემები ცნობილ პირობას ემთხვევა
rules.matchOutput[].unless შემოკლებული დამუშავების გამოტოვება შეცდომის/წარუმატებლობის ნიმუშის არსებობისას
rules.dropPatterns ხმაურიანი ხაზების მოცილება
rules.includePatterns ქმედითი ხაზებისთვის უპირატესობის მინიჭება
rules.collapsePatterns განმეორებადი დამთხვეული ხაზების შეკუმშვა
rules.deduplicate ცალკეული ფილტრისთვის არჩევითი ფუნქცია: ზედიზედ განმეორებული ხაზების შეკუმშვა
rules.truncateLineAt Unicode-ისთვის უსაფრთხო თითოეული ხაზის შეკვეცა
rules.onEmpty სარეზერვო შეტყობინება, თუ ყველა ხაზი გაიფილტრა
tests[] verify gate-ის მიერ გამოყენებული ჩაშენებული ნიმუშები

ჩაშენებული ფილტრები, წესით, უნდა შეიცავდეს ჩაშენებულ tests[] ნიმუშებს. მორგებულ ფილტრებშიც რეკომენდებულია მათი დამატება, განსაკუთრებით მაშინ, როცა ისინი რამდენიმე პროექტში გამოიყენება.

სტრიქონების დუბლიკატების მოცილება (ორი დონე)

RTK დუბლირებულ სტრიქონებს ორ დამოუკიდებელ დონეზე აერთიანებს:

  1. თითოეული ფილტრის deduplicate (არჩევითი, ნაგულისხმევად false). ფილტრს შეუძლია დააყენოს rules.deduplicate: true, რათა შეკვეცამდე გააერთიანოს მიმდევრობით განლაგებული დუბლირებული სტრიქონები ამ ფილტრის მიერ დამთხვევით მიღებულ შედეგში. ეს სრულდება lineFilter.ts-ის შიგნით. მოძველებული ფილტრებისთვის ის ავტომატურად ირთვება, როდესაც ფილტრი განსაზღვრავს collapsePatterns-ს. სქემა: deduplicate: z.boolean().default(false) ფაილში open-sse/services/compression/engines/rtk/filterSchema.ts.
  2. ძრავის მასშტაბის deduplicateThreshold (ნაგულისხმევად 3). ყველა ფილტრის შესრულების შემდეგ ძრავა მთელ შედეგში აერთიანებს ერთმანეთის მიმდევრობით განლაგებული იდენტური სტრიქონების ნებისმიერ სერიას, რომლის სიგრძეც არის >= deduplicateThreshold (deduplicateRepeatedLines, გამოყენებული engines/rtk/index.ts-ში). ნორმალიზაციისას მნიშვნელობა იზღუდება 2100 დიაპაზონით.

თითოეული ფილტრის დამუშავება სრულდება პირველად (ფილტრის შიგნით), ხოლო ძრავის მასშტაბის დამუშავება — ბოლოს (გაერთიანებულ შედეგზე), ამიტომ ეს ორი მექანიზმი ორმაგი დათვლის გარეშე თავსდება ერთმანეთთან.

სტრიქონების დაჯგუფება (enableGrouping)

როდესაც rtkConfig.enableGrouping არის true (ნაგულისხმევად false), RTK დუბლიკატების მოცილების შემდგომ შედეგზე ასრულებს დამატებით groupSimilarLines დამუშავებას, რომელიც აერთიანებს მიმდევრობით განლაგებულ თითქმის ეკვივალენტურ (და არა ბაიტობრივად იდენტურ) სტრიქონთა სერიებს. rtkConfig.groupingThreshold (ნაგულისხმევად 3) არის სერიის მინიმალური სიგრძე, რომელიც დაჯგუფებას ააქტიურებს. ეს არის deduplicateThreshold-ის სტრუქტურული ანალოგი: დუბლიკატების მოცილება ამუშავებს ზუსტ გამეორებებს, ხოლო დაჯგუფება — „ერთი და იმავე ფორმის, მცირედ განსხვავებულ“ სტრიქონებს. ორივე პარამეტრი არის rtkConfig JSON-ის ნაწილი, რომელიც ინახება key_value ცხრილში (იხილეთ კონფიგურაცია ზემოთ), ამიტომ პარამეტრი ხელახალი გაშვებების შემდეგაც ნარჩუნდება.

კოდის კომენტარების მოცილება (stripCodeComments / preserveDocstrings)

როდესაც rtkConfig.applyToCodeBlocks ჩართულია, RTK-ს ასევე შეუძლია შემოსაზღვრული კოდის ბლოკებიდან კომენტარების მოცილება:

  • stripCodeComments (ნაგულისხმევად false) — არჩევითი. როდესაც არის true, RTK JavaScript-ისა და TypeScript-ის შემოსაზღვრული ბლოკებიდან კომენტარებს შლის. ისტორიულად ეს პარამეტრი იკითხებოდა, მაგრამ არასდროს გამოიყენებოდა, ამიტომ წარმოებაში ფარული ცვლილების თავიდან ასაცილებლად ნაგულისხმევი მნიშვნელობა კვლავ „შენარჩუნებაა“.
  • preserveDocstrings (ნაგულისხმევად true) — კომენტარების მოცილებისას JSDoc//** … */ ბლოკური კომენტარები ნარჩუნდება (ისინი შეიცავს API-ის დოკუმენტაციას, რომლის ღირებულებაც მათ მიერ დაკავებულ ბაიტებზე მეტია). მათი მოსაცილებლადაც დააყენეთ false.

კომენტარების მოცილება განხორციელებულია open-sse/services/compression/engines/rtk/codeStripper.ts-ში. ის იყენებს TypeScript-ის პარსერს (და არა რეგულარულ გამოსახულებას), რათა სტრიქონული, შაბლონური და რეგულარული გამოსახულების ლიტერალები კომენტარებად არასდროს იქნეს შეცდომით მიჩნეული; JSX-ის აღმოჩენისას კი დამუშავებას მთლიანად წყვეტს (რათა JSX-ის გამოსახულების კონტეინერებში არსებული კომენტარები არასდროს დაზიანდეს). ამჟამად კომენტარების მოცილება ვრცელდება მხოლოდ JavaScript-სა და TypeScript-ზე — მოცილების მოდულის CodeLanguage სიმრავლის სხვა ენებისთვის (Python, Rust, Go, Ruby, Java) ცარიელი სტრიქონები და ჰარების მიმდევრობები იკუმშება, თუმცა კომენტარები არ იშლება. დამუშავებულ ბლოკს rulesApplied-ში ენიჭება ტეგი rtk:code-strip.

შენიშვნა — GCF / ტაბულარული კოდირება ცალკე ძრავია. RTK არ შეიცავს „GCF“ (Graph Compact Format) ტაბულარულ/სვეტურ JSON-კოდერს. ეს კოდერი — რომელმაც ძველი omni-tabular კოდერი ჩაანაცვლა — განთავსებულია headroom ძრავაში (open-sse/services/compression/engines/headroom/, ხოლო პროექტში ჩაშენებული კოდეკი მდებარეობს headroom/gcf/-ში). ის აქ აღწერილ RTK-ის ფილტრების კონვეიერთან დაკავშირებული არ არის.

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

გლობალური პარამეტრები ხელმისაწვდომია /api/settings/compression-ის მეშვეობით. RTK-სპეციფიკური პარამეტრები ასევე ხელმისაწვდომია /api/context/rtk/config-ის მეშვეობით.

{
  "defaultMode": "stacked",
  "autoTriggerMode": "stacked",
  "autoTriggerTokens": 32000,
  "stackedPipeline": [
    { "engine": "rtk", "intensity": "standard" },
    { "engine": "caveman", "intensity": "full" }
  ],
  "rtkConfig": {
    "enabled": true,
    "intensity": "standard",
    "applyToToolResults": true,
    "applyToCodeBlocks": false,
    "applyToAssistantMessages": false,
    "enabledFilters": [],
    "disabledFilters": [],
    "maxLinesPerResult": 120,
    "maxCharsPerResult": 12000,
    "deduplicateThreshold": 3,
    "customFiltersEnabled": true,
    "trustProjectFilters": false,
    "rawOutputRetention": "never",
    "rawOutputMaxBytes": 1048576,
    "enableGrouping": false,
    "groupingThreshold": 3,
    "stripCodeComments": false,
    "preserveDocstrings": true
  }
}

enabledFilters და disabledFilters იყენებს ფილტრების იდენტიფიკატორებს, მაგალითად test-vitest ან git-diff.

rtkConfig-ის სრული სტრუქტურა განსაზღვრულია RtkConfig / DEFAULT_RTK_CONFIG-ით ფაილში open-sse/services/compression/types.ts. მთლიანი ობიექტი ინახება, როგორც ერთი JSON-მნიშვნელობა, SQLite-ის key_value ცხრილში, namespace = "compression", key = "rtkConfig"-ის ქვეშ (src/lib/db/compression.ts), ხოლო წაკითხვისას ნორმალიზდება normalizeRtkConfig-ის მიერ. ამიტომ ქვემოთ მოცემული თითოეული ველი — მათ შორის enableGrouping, groupingThreshold, stripCodeComments და preserveDocstrings — იმავე საცავში სრულ ციკლს გადის და გადატვირთვის შემდეგაც ნარჩუნდება.

გასაღები ნაგულისხმევი დანიშნულება
deduplicateThreshold 3 მთელი ძრავისთვის: შესაკუმშად საჭირო ზედიზედ იდენტური ხაზების მინიმუმი (2100)
enableGrouping false არჩევითი: თითქმის ეკვივალენტური ზედიზედ მიმდევარი ხაზების შეკუმშვა
groupingThreshold 3 ზედიზედ მსგავსი ხაზების მინიმალური რაოდენობა, რომელიც დაჯგუფებას ააქტიურებს
stripCodeComments false არჩევითი: შემოსაზღვრული კოდის ბლოკებიდან კომენტარების წაშლა (საჭიროა applyToCodeBlocks)
preserveDocstrings true კომენტარების წაშლისას JSDoc//** … */ ბლოკების შენარჩუნება

API

მარშრუტი მეთოდი დანიშნულება
/api/context/rtk/config GET RTK-ის კონფიგურაციის წაკითხვა
/api/context/rtk/config PUT RTK-ის კონფიგურაციის განახლება
/api/context/rtk/filters GET ფილტრების კატალოგისა და ჩატვირთვის დიაგნოსტიკის ჩამონათვალი
/api/context/rtk/import POST RTK TOML schema v1 ფაილების შემოწმება ან დაყენება
/api/context/rtk/test POST ერთი ტექსტური დატვირთვისთვის RTK შეკუმშვის წინასწარი ნახვა
/api/context/rtk/raw-output/[id] GET შენახული, რედაქტირებული დაუმუშავებელი გამოტანის წაკითხვა
/api/compression/preview POST შეკუმშვის ნებისმიერი რეჟიმის წინასწარი ნახვა

RTK-ის სატესტო დატვირთვა:

{
  "command": "npm test",
  "text": "FAIL tests/example.test.ts\nAssertionError: expected true\nTest Files 1 failed",
  "config": {
    "intensity": "standard"
  }
}

შეკუმშვის წინასწარი ნახვის დატვირთვა:

{
  "mode": "stacked",
  "messages": [
    {
      "role": "tool",
      "content": "FAIL tests/example.test.ts\nAssertionError: expected true\nTest Files 1 failed"
    }
  ],
  "config": {
    "rtkConfig": {
      "rawOutputRetention": "failures"
    }
  }
}

მართვის მარშრუტები საჭიროებს მართვის პანელის ადმინისტრაციულ ავთენტიფიკაციას ან შესაბამის API-გასაღების პოლიტიკას.

RTK TOML-ის შემოწმების დატვირთვა:

{
  "action": "validate",
  "content": "schema_version = 1\n\n[filters.my-tool]\nmatch_command = \"^my-tool\\\\b\"\nmax_lines = 20\n"
}

შემოწმებული ფაილის გლობალურად დასაყენებლად გამოიყენეთ "action": "install". "overwrite": true დაამატეთ მხოლოდ არსებული გლობალური ფაილის ჩანაცვლების გადახედვისა და დადასტურების შემდეგ.

ნედლი გამომავალი მონაცემების აღდგენა

RTK ჩვეულებრივ მხოლოდ შეკუმშულ ტექსტს აბრუნებს. გამართვისთვის rawOutputRetention-ს შეუძლია შეინახოს რედაქტირებული ნედლი გამომავალი მონაცემები:

მნიშვნელობა ქცევა
never არ შეინახოს ნედლი გამომავალი მონაცემები
failures შეინახოს მხოლოდ სავარაუდო შეცდომების გამომავალი მონაცემები
always რედაქტირების შემდეგ შეინახოს RTK-ის ყველა შეკუმშული ნედლი გამომავალი

შენახული ფაილები იწერება შემდეგ მისამართზე:

DATA_DIR/rtk/raw-output/

მუდმივ საცავში ჩაწერამდე საიდუმლო მონაცემები რედაქტირდება, მათ შორის გავრცელებული bearer-ტოკენები, API-გასაღებები, Slack-ის ტოკენები, AWS-ის წვდომის გასაღებები და მინიჭების სტილის token=..., secret=..., password=... მნიშვნელობები. ანალიტიკა ინახავს მხოლოდ მაჩვენებლის id-ს, ზომასა და ჰეშის მეტამონაცემებს.

შემოწმების კარიბჭე

ფოკუსირებული შემოწმების კარიბჭე უშვებს ჩაშენებული inline-ფილტრების ტესტებს გარე ბრძანებების shell-ით გაშვების გარეშე:

node --import tsx/esm --test tests/unit/compression/rtk-verify.test.ts

RTK-ის უფრო ფართო კარიბჭეა:

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

RTK-ის გაფართოება

  1. დაამატეთ ან განაახლეთ ფილტრის JSON-ფაილი.
  2. ჩართეთ სულ მცირე ერთი tests[] ნიმუში, რომელიც მნიშვნელოვან ქცევას ადასტურებს.
  3. ახალი ბრძანებების ოჯახებისთვის დაამატეთ ფიქსტურა tests/unit/compression/fixtures/rtk/-ში.
  4. ახალი გამომავალი მონაცემების კლასის დამატებისას დაამატეთ ბრძანების აღმოჩენის დაფარვა.
  5. გაუშვით შემოწმების და RTK-ის ფართო კარიბჭეები.
  6. თუ ფილტრი პროექტისთვის ლოკალურია, დაამატეთ commit-ში .rtk/filters.json და განაახლეთ .rtk/trust.json მხოლოდ განხილვის შემდეგ.

ინტენსივობის დონეები (v3.8.16+)

RTK მხარს უჭერს ინტენსივობის 3 დონეს, რომლებიც აბალანსებს შეკუმშვის აგრესიულობასა და უსაფრთხოებას. დონე ძრავის კონფიგურაციაში config.intensity-ის მეშვეობით დგინდება.

3 დონე

დონე შეკვეცის ზღვარი ტოკენების დაზოგვა რისკი საუკეთესოდ შეეფერება
minimal 24 ხაზი სექციაზე ~20-40% ძალიან დაბალი საწარმოო გარემოს კრიტიკული კონტექსტით
standard (ნაგულისხმევი) 24 ხაზი სექციაზე ~50-70% დაბალი ყოველდღიური კოდირების სესიები
aggressive 16 ხაზი სექციაზე ~70-90% საშუალო ხანგრძლივი სესიები, მაქსიმალური დაზოგვა

სად ხდება შეკვეცა

შეკვეცის ზღვარი გავლენას ახდენს lineFilter.ts-ზე:

// წყარო: open-sse/services/compression/engines/rtk/index.ts:329-330
config.intensity === "aggressive" ? 16 : 24,
config.intensity === "aggressive" ? 16 : 24,

თითოეული სექციის დასაწყისიც და ბოლოც შენარჩუნებულია; შეკვეცის ამოქმედებისას შუა შიგთავსი იშლება.

რა რჩება და რა იჭრება

შიგთავსი minimal standard aggressive
შეცდომები / სტეკის ტრასირებები შენარჩუნებულია შენარჩუნებულია შენარჩუნებულია
ტესტების წარუმატებლობები შენარჩუნებულია შენარჩუნებულია შენარჩუნებულია
აგების შეცდომები შენარჩუნებულია შენარჩუნებულია შენარჩუნებულია
წარმატებული ტესტები (ვრცელი) შენარჩუნებულია 🟡 შეკუმშულია 🟡 შეკუმშულია
რუტინული გამომავალი (info-ლოგები) 🟡 შეკუმშულია 🟡 შეკუმშულია წაშლილია
პროგრესის ზოლები 🟡 შეკუმშულია წაშლილია წაშლილია
ბანერი / ASCII-გრაფიკა 🟡 შეკუმშულია წაშლილია წაშლილია

სწორი ინტენსივობის არჩევა

                  კონტექსტის დაკარგვა კატასტროფულია?
                  │
      ┌───────────┼───────────┐
      │           │           │
    დიახ         არა       არ ვარ დარწმუნებული
      │           │           │
      ▼           │           │
   minimal        │           │
      │           │           │
      │           ▼           ▼
      │      რამდენად კრიტიკულია  ჯერ სცადეთ `standard`
      │      გამტარუნარიანობა?    (მუშაობს შემთხვევათა
      │           │              80%-ში)
      │      ┌────┴────┐
      │      │         │
      │   დაბალი     მაღალი
      │      │         │
      │      ▼         ▼
      │   standard   aggressive
      │      │         │
      └──────┴─────────┘

ინტენსივობის კონფიგურაცია

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

{
  "combo": "my-coding-combo",
  "routing": {/* ... */},
  "compression": {
    "engine": "rtk",
    "intensity": "aggressive"
  }
}

პროგრამულად:

rtkEngine (@omniroute/open-sse/services/compression/engines/rtk) არის CompressionEngine და არ აქვს updateConfig მეთოდი. ამის ნაცვლად ძრავის კონფიგურაცია რეესტრის დამხმარე ფუნქციის მეშვეობით განაახლეთ:

import { updateEngineConfig } from "@omniroute/open-sse/services/compression/engines/registry";

updateEngineConfig("rtk", { intensity: "aggressive" });

ეფექტის შემოწმება

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

import { runRtkFilterTests } from "omniroute/compression/engines/rtk/verify";

const result = runRtkFilterTests({ intensity: "aggressive" });
if (!result.passed) {
  console.error("Filters failed at aggressive intensity");
}

მორგებული ფილტრების შემუშავება (v3.8.16+)

engines/rtk/filters/ დირექტორია შეიცავს 49+-ზე მეტ ჩაშენებულ ფილტრის JSON ფაილს. შეგიძლიათ დაამატოთ საკუთარი ფილტრები იმ მორგებული ხელსაწყოების გამოტანის შესაკუმშად, რომლებსაც ნაგულისხმევი ფილტრები არ ფარავს.

ფილტრის სქემა (Zod)

{
  "id": "string",                      // სავალდებულო. ფილტრის იდენტიფიკატორი (kebab-case, მაგ., "python-traceback")
  "label": "string",                   // სავალდებულო. ადამიანისთვის გასაგები ფილტრის სახელი
  "description": "string",             // არასავალდებულო (ნაგულისხმევი: ""). ფილტრის მოქმედების მოკლე აღწერა
  "category": "git|test|build|shell|docker|package|infra|cloud|generic",
  "priority": number,                  // არასავალდებულო (0-100, ნაგულისხმევი: 50). შესრულების რიგითობა (უფრო მაღალი = პირველი)
  "match": {
    "commands": ["string"],            // შესატყვისი ბრძანებების სახელები (მაგ., "python", "pytest")
    "patterns": ["string"],            // გამოტანასთან შესატყვისი რეგულარული გამოსახულებები
    "outputTypes": ["string"]          // აღმოჩენილი გამოტანის კლასები (მაგ., "test-failure")
  },
  "rules": {
    "stripAnsi": boolean,              // არასავალდებულო (ნაგულისხმევი: false). ANSI ფერის კოდების მოცილება
    "replace": [                       // ძიებისა და ჩანაცვლების წესები (ნაგულისხმევი: [])
      { "pattern": "regex", "replacement": "..." }
    ],
    "matchOutput": [                   // ნიმუშის დამთხვევისას მოკლე ჩართვა (ნაგულისხმევი: [])
      {
        "pattern": "regex",
        "message": "short summary",
        "unless": "regex"              // გამოტოვება, თუ ეს ნიმუში ემთხვევა
      }
    ],
    "includePatterns": ["string"],     // შესანარჩუნებელი ხაზები (რეგულარული გამოსახულებები, ნაგულისხმევი: [])
    "dropPatterns": ["string"],        // ამოსაღები ხაზები (რეგულარული გამოსახულებები, ნაგულისხმევი: [])
    "collapsePatterns": ["string"],    // ერთ ეგზემპლარამდე დასაკეცი ხაზები (ნაგულისხმევი: [])
    "deduplicate": boolean,            // არასავალდებულო (ნაგულისხმევი: false). დუბლირებული ხაზების წაშლა
    "truncateLineAt": number,          // არასავალდებულო (ნაგულისხმევი: 0). ხაზების მაქსიმალურ სიმბოლოებამდე შეკვეცა
    "maxLines": number,                // არასავალდებულო (ნაგულისხმევი: 0). ხაზების საერთო რაოდენობის მკაცრი ზღვარი
    "headLines": number,               // არასავალდებულო (ნაგულისხმევი: 20). დამთხვევის მქონე გამოტანის პირველი N ხაზის შენარჩუნება
    "tailLines": number,               // არასავალდებულო (ნაგულისხმევი: 20). დამთხვევის მქონე გამოტანის ბოლო N ხაზის შენარჩუნება
    "onEmpty": "string",               // არასავალდებულო (ნაგულისხმევი: ""). სარეზერვო შეტყობინება, თუ ყველა ხაზი გაიფილტრა
    "filterStderr": boolean            // არასავალდებულო (ნაგულისხმევი: false). stderr გამოტანის გაფილტვრაც
  },
  "preserve": {
    "errorPatterns": ["string"],       // ნიმუშები, რომლებიც ყოველთვის უნდა შენარჩუნდეს (ნაგულისხმევი: [])
    "summaryPatterns": ["string"]      // საბოლოო შემაჯამებელი ხაზის ნიმუშები (ნაგულისხმევი: [])
  },
  "tests": [                           // ჩაშენებული ტესტები შემოწმებისთვის (ნაგულისხმევი: [])
    {
      "name": "string",               // სავალდებულო. ტესტის სახელი
      "input": "sample output",        // სავალდებულო. გამოტანის ტექსტის ნიმუში
      "expected": "expected output",   // სავალდებულო. მოსალოდნელი შეკუმშული გამოტანა
      "command": "optional command"    // არასავალდებულო. ბრძანების კონტექსტი
    }
  ]
}

მაგალითი: Python Traceback ფილტრი

{
  "id": "python-traceback",
  "label": "Python Traceback Filter",
  "description": "Compresses Python tracebacks to essential file/line locations and error type",
  "category": "test",
  "priority": 60,
  "match": {
    "commands": ["python", "python3", "pytest", "uv", "poetry"],
    "patterns": ["Traceback \\(most recent call last\\)", "Error", "Exception"],
    "outputTypes": ["error-traceback"]
  },
  "rules": {
    "stripAnsi": true,
    "includePatterns": [
      "Traceback \\(most recent call last\\)",
      "^\\s*File \".+\", line \\d+",
      "^\\s*[A-Z][a-zA-Z]+Error:",
      "^\\s*[A-Z][a-zA-Z]+Exception"
    ],
    "dropPatterns": ["site-packages/", "^\\s+[a-z_]+\\([^)]*\\)$"],
    "headLines": 5,
    "tailLines": 3,
    "maxLines": 25,
    "filterStderr": true
  },
  "preserve": {
    "errorPatterns": ["Error:", "Exception:", "Traceback"],
    "summaryPatterns": ["^[A-Z][a-zA-Z]+(?:Error|Exception):"]
  },
  "tests": [
    {
      "name": "preserves-error-type-and-location",
      "input": "Traceback (most recent call last):\n  File \"app.py\", line 42, in main\n    do_thing()\n  File \"lib/utils.py\", line 17, in helper\n    return 1 / 0\nZeroDivisionError: division by zero",
      "expected": "Traceback (most recent call last):\n  File \"app.py\", line 42, in main\n  File \"lib/utils.py\", line 17, in helper\nZeroDivisionError: division by zero",
      "command": "python app.py"
    }
  ]
}

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

განათავსეთ ფაილი ერთ-ერთ ამოცნობილ მდებარეობაზე:

~/.omniroute/rtk/filters/my-filter.json     # მომხმარებლის დონე
<project>/.rtk/filters/my-filter.json      # პროექტის დონე

ფილტრები გაშვებისას ავტომატურად იტვირთება open-sse/services/compression/engines/rtk/filterLoader.ts-ში არსებული loadRtkFilters()-ის მეშვეობით. ჩამტვირთავი ფილტრებს შემდეგი ადგილებიდან აღმოაჩენს:

  • ჩაშენებული კატალოგი: open-sse/services/compression/engines/rtk/filters/
  • მომხმარებლის დირექტორია: ~/.omniroute/rtk/filters/
  • პროექტის დირექტორია: <project>/.rtk/filters/

ფილტრების პროგრამულად ჩასატვირთად:

import { loadRtkFilters } from "@omniroute/open-sse/services/compression/engines/rtk/filterLoader";

// პარამეტრები: customFiltersEnabled (მომხმარებლის/პროექტის ფილტრების ჩატვირთვა, ნაგულისხმევად ჩართულია),
// trustProjectFilters, refresh.
const filters = loadRtkFilters({ customFiltersEnabled: true });

ვალიდაცია

ჩატვირთვისას ფილტრების ვალიდაცია Zod სქემის მიხედვით ხდება. არასწორი სტრუქტურის მქონე ფილტრი ვერ ჩაიტვირთება და შეცდომა ჟურნალში ჩაიწერება:

RTK_FILTER_LOADER: filter "my-filter" failed validation:
  - rules.replace.0.pattern: Invalid regex
  - match.commands: must not be empty

ყველა დაინსტალირებული ფილტრის ვალიდაციისთვის გამოიძახეთ runRtkFilterTests(), რომელიც ექსპორტირებულია open-sse/services/compression/engines/rtk/verify.ts-დან.

საუკეთესო პრაქტიკები

  1. ყოველთვის ჩართეთ tests[] — ისინი ადასტურებენ, რომ თქვენი ფილტრი მუშაობს და ხელს უშლიან რეგრესიებს
  2. მოკლე ჩართვებისთვის გამოიყენეთ matchOutput — თუ ერთი სტრიქონი სრულ სურათს გადმოსცემს, ჩაანაცვლეთ მთელი ბლოკი
  3. უპირატესობა მიანიჭეთ keep-ს და არა strip-ს — მკაფიო წესები „ყოველთვის შეინარჩუნე“ უფრო უსაფრთხოა, ვიდრე „ყოველთვის წაშალე“
  4. ტესტირება სამივე ინტენსივობის დონეზე ჩაატარეთminimal-მა არაფერი უნდა შეცვალოს, ხოლო aggressive-მა შეცდომები მაინც უნდა შეინარჩუნოს
  5. გამოიყენეთ ველი unless — დაიცავით მოკლე ჩართვები პირობით: „არ გააქტიურდეს, თუ X არსებობს“

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

როდესაც RTK გამოტანას აგრესიულად კუმშავს, გამართვის, აუდიტის ან ხელახლა გაშვების მიზნით შეგიძლიათ ორიგინალი ტექსტის აღდგენა.

როგორ მუშაობს დაუმუშავებელი გამოტანის აღდგენა

ორიგინალი გამოტანა (10K ტოკენი)
        │
        ▼
RTK-ის შეკუმშვა (rawOutput.enabled=true პარამეტრით)
        │
        ├─▶ შეკუმშული გამოტანა (2K ტოკენი)  ──▶ LLM-ს
        │
        └─▶ ორიგინალი გამოტანა (10K ტოკენი) ──▶ ინახება DB-ში
                                                  (დაკავშირებულია request_id-ით)

დაუმუშავებელი გამოტანის შენახვის ჩართვა

თითოეული მოთხოვნისთვის (კომბინირებულ კონფიგურაციაში):

{
  "compression": {
    "engine": "rtk",
    "intensity": "aggressive",
    "rawOutput": {
      "enabled": true,
      "maxBytes": 1048576 // 1MB ლიმიტი
    }
  }
}

ნაგულისხმევი მნიშვნელობა: rawOutput.enabled: false (ზოგავს საცავის სივრცეს).

შენახვის ღირებულება

თითოეული მოთხოვნისთვის 1MB ლიმიტი 10MB ლიმიტი
საშუალო შეკუმშული გამოტანა ~5KB ~5KB
შენახული დაუმუშავებელი გამოტანა ~50-500KB ~500KB-5MB
დღეში 1000 მოთხოვნის შემთხვევაში 50-500MB/დღე 500MB-5GB/დღე

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

ორიგინალის აღდგენა

import { readRtkRawOutput } from "omniroute/compression/engines/rtk/rawOutput";

const raw = readRtkRawOutput(pointerId); // pointerId შეკუმშვის სტატისტიკიდან
if (raw) {
  console.log("Original output:", raw);
}

pointerId შეკუმშვის შემდეგ ბრუნდება CompressionStats.rtkRawOutputPointers[]-ში. ფუნქციის სიგნატურა იხილეთ open-sse/services/compression/engines/rtk/rawOutput.ts:102-ში.

ვერიფიკაციის ბარიერი

RTK-ის ფილტრების ვერიფიკაცია (open-sse/services/compression/engines/rtk/verify.ts) ყველა ფილტრს მათი tests[]-ის მიხედვით ამოწმებს და უზრუნველყოფს, რომ ისინი ინტენსივობის სამივე დონეზე სწორად მუშაობდნენ.

ვერიფიკაციის გასაშვებად გამოიძახეთ runRtkFilterTests():

import { runRtkFilterTests } from "open-sse/services/compression/engines/rtk/verify";

const result = runRtkFilterTests();
console.log(`Passed: ${result.outcomes.filter((o) => o.passed).length}`);
console.log(`Failed: ${result.outcomes.filter((o) => !o.passed).length}`);
if (!result.passed) {
  console.error("Filters failed verification");
  result.outcomes
    .filter((o) => !o.passed)
    .forEach((o) => {
      console.error(
        `  - ${o.filterId} / ${o.testName}: expected "${o.expected}", got "${o.actual}"`
      );
    });
}

რას ამოწმებს:

  1. ყველა ფილტრი იტვირთება და სქემის ვალიდაციას წარმატებით გადის
  2. tests[]-ის ყოველი ჩანაწერი მოსალოდნელ გამოტანას წარმოქმნის
  3. minimal ინტენსივობა არაფერს ცვლის (ინარჩუნებს ორიგინალს და მხოლოდ სტრუქტურულ ფილტრებს იყენებს)
  4. aggressive ინტენსივობა ინარჩუნებს შეცდომებს, ტესტების წარუმატებლობებსა და სტეკის ტრასებს
  5. შეკუმშული გამოტანა არასოდეს არის ორიგინალ შეყვანაზე დიდი
  • წყარო: open-sse/services/compression/engines/rtk/ (63 ფაილი, ~70KB)

  • ფილტრის ცვლილების გაერთიანებამდე — ყოველთვის დარწმუნდით, რომ ტესტები წარმატებით სრულდება

  • RTK ძრავის განახლების შემდეგ — შესაძლოა, სქემა შეცვლილი იყოს

  • პერიოდულად, მონიტორინგის ფარგლებში — იცავს სატესტო ფიქსჩერების აცდენისგან

  • ახალი ხელსაწყოს ან ბრძანებების ოჯახის დამატებისას — ადასტურებს, რომ ახალი ფილტრი მუშაობს


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

  • COMPRESSION_GUIDE.md — შეკუმშვის სრული კონვეიერის მიმოხილვა
  • COMPRESSION_ENGINES.md — ძრავების რეესტრი და ჩაშენებული ძრავები
  • EXTENDING_COMPRESSION.md — მორგებული ძრავები, ენის პაკეტები, მრავალდონიანი კონვეიერები
  • წყარო: open-sse/services/compression/engines/rtk/ (63 ფაილი, ~70KB)