Query rewrite-ті тестілеу: сұраудың мағынасын қалай жоғалтпау керек

Rewrite қай жерде көмектеседі, қай жерде кедергі болады

Rewrite пайдалы, егер ол шуды азайтып, тапсырманы өзгертпесе. Егер қолданушы "айфон 15 про мах" деп жазса, жүйе "мах" сөзін тыныш қана "max" деп түзете алады. Мағына өзгермейді. Бірақ егер ол "айфон 15" сұрауын "айфон 15 Pro" деп қайта жазса, бұл көмек емес, ниетті алмастыру болады.

Бұл әсіресе қысқа сұрауларда жақсы көрінеді. Екі-үш сөзде контекст аз болады, сондықтан модель өзі толықтырып жібереді. "Несие" деген сұрау шарттар, калькулятор, қайта қаржыландыру немесе бас тарту туралы шағым болуы мүмкін. Фраза неғұрлым қысқа болса, қайта жазу соғұрлым абай болуы керек.

Ұзын сұраулармен жұмыс жеңілірек, бірақ тәуекел бәрібір қалады. Егер адам "Қазақстандағы OpenAI-үйлесімді API үшін кідірісті қалай азайтуға болады" деп жазса, rewrite шынымен көмектесе алады: артық сөздерді алып тастау, фразаны іздеуге ыңғайлы формаға келтіру, өңір мен API түрін сақтау. Қате дәл сол жерде басталады, модель тым агрессивті қысқартып, "Қазақстандағы" немесе "OpenAI-үйлесімді" бөлігін түсіріп тастағанда. Онда іздеу көбірек құжат табады, бірақ керектісін емес.

Кликтердің өсуі де өздігінен ештеңені дәлелдемейді. Қолданушы шығарылған нәтижелер кеңейгендіктен немесе даулы болғандықтан көбірек басуы мүмкін. Ол біреуінің орнына үш нәтижені ашады, көбірек уақыт жұмсайды, бірақ бәрібір жауабын таппайды. Сондықтан сұрауды қайта жазуды бағалау үшін адамның керегін қаншалықты тез тапқанына және артық ауысулар азайғанына қараған дұрыс.

Ең қауіпті ақау сырттай қалыпты көрінеді. Модель бастапқыға "ұқсас" мағынаны қосады. Модельдер каталогы бойынша іздеуде бұл жиі болады. "Арзан модель суммаризация үшін" деген сұрау rewrite арқылы оңай "суммаризация үшін ең жақсы модель" болып кетеді. Бір сөз бәрін өзгертеді. "Арзан" бағалық шектеуді білдіреді, ал "ең жақсы" іздеуді сапа жағына бұрады.

Мұнда қарапайым ереже жұмыс істейді:

• қате теруді, раскладканы және анық қоқысты батыл түзетіңіз;
• қысқа сұрауларға абай болыңыз;
• жаңа шектеулерді, объектілерді және мақсаттарды қоспаңыз;
• кликтердің өсуін релеванттылық артты деген белгі деп санамаңыз.

Жақсы rewrite сұрауды ақылды етіп көрсеткен жерде емес, іздеу бастапқы мағынаны сақтап, адамды жауапқа тезірек жеткізген жерде ұтады.

Қайсысы жақсы қайта жазу

Жақсы қайта жазу сұрауды әдемірек етпейді. Ол қолданушының ниетін сақтап, іздеуге керек құжаттарды жоғарыға шығаруға көмектеседі. Егер мағына тіпті аздап жылжыса да, rewrite күмәнді болып қалады, нәтижесі толықтау көрінсе де.

Қарапайым мысал: адам "ИП үшін аударым лимиті" деп жазады. Қалыпты rewrite қысқартуды және сөз формасын ұқыпты аша алады, мысалы сұрауды жеке кәсіпкерге арналған аударым лимиттері туралы нұсқаға айналдырады. Нашар rewrite бағытты өзгертіп, оны бизнеске арналған тарифтер бойынша жалпы іздеуге айналдырады. Сөз көбейді, бірақ дәлдік төмендеді.

Жақсы нәтиже rewrite мәтінінен емес, нәтижелер тізімінен көрінеді. Қайта жазғаннан кейін жоғарғы қатарда бастапқы сұраққа тезірек әрі дәлірек жауап беретін құжаттар тұруы керек. Сонымен бірге жүйе сирек, бірақ дәл нәтижелерді жасырып тастамауы тиіс: нақты қате коды бар бет, бұйрық нөмірі немесе ішкі өнім атауы.

Қателер әсіресе қысқа, бірақ өте нақты сұрауларда жиі шығады. Қате кодтары, артикулдар, модель атаулары, аббревиатуралар, келісімшарт нөмірлері және сирек терминдерді күшті себепсіз қозғамаған дұрыс. Бір артық синоним бүкіл іздеуді бұза алады.

Бағалау үшін бірнеше қарапайым белгіні есте ұстаған пайдалы. Rewrite-тен кейін мағына өзгермеуі керек. Керек құжаттар жай ғана араласып кетпей, жоғары көтерілуі тиіс. Нақты сирек сәйкестіктер бірінші беттен жоғалмауы керек. Тағы бір маңызды белгі: егер қайта жазу керек болмаса, жүйе сұрауды сол күйі қалдыра алуы тиіс.

Өзгеріссіз қалған жағдайларды тестке міндетті түрде қосыңыз. Бұл бос категория емес. Егер қолданушы сұрауды онсыз да дәл жазса, ең жақсы rewrite — ештеңе жасамау.

Офлайн тесттерде әр мысалды мынадай түрде белгілеу пайдалы: rewrite көмектесті, әсер етпеді немесе зиян келтірді. Мұндай белгілеу жүйе қай жерде іздеуді шынымен жақсартатынын, ал қай жерде тек қайта жазу үшін қайта жазатынын тез көрсетеді.

Тексеру үшін сұраулар жинағын қалай құрастыру керек

Тест жинағы нақты іздеу ағынына ұқсауы керек. Тек түсінікті сұрауларды алсаңыз, қайта жазу көбіне пайдалы болып көрінеді. Қателер әдетте қысқа, сирек және шуылы көп формулировкаларда жасырынады.

Сұрауларды бірнеше топтан жинаңыз. Жиі кездесетіндері rewrite күнделікті іздеуде көмектесе ме, соны көрсетеді. Сирек және ұзын сұраулар ұзын құйрықты жағдайларға керек. Бөлек проблемалы формулировкаларды шығарыңыз: бір сөз, екіұшты мағына, орысша мен ағылшынша араласқан мәтін, ішкі жаргон, өнім нөмірлері, қысқартулар.

"Лас" мысалдарды да қосқан жөн. Қолданушылар қате теріп жазады, сөздердің орнын ауыстырады және команда өзі ойлап таппайтын синонимдерді қолданады. Банк үшін бұл "құжатсыз несие" және "табыс растамайтын қарыз" болуы мүмкін. Телеком-сервис үшін — "турция роумингі" және "турцияда байланыс". Егер rewrite мұндай нәрселерді түзете алса, ол бірден байқалады.

Әр сұрау үшін нені сақтау керек

Бір жол мәтін аз. Әр сұрау үшін мыналарды сақтаған дұрыс:

• бастапқы мәтінді өзгертусіз;
• қолданушы не іздегені туралы қысқа белгі;
• күтілетін 1-3 құжат немесе нәтиже санаты;
• "rewrite болады" немесе "rewrite болмайды" деген белгі;
• егер формулировканы өзгертуге болмайтын болса, себебі.

Соңғы тармақ жалған жеңістерден жиі құтқарады. Кейбір сұрауларда тіпті жұмсақ қайта жазу да мағынаны бұзады. Бұлар — заң атаулары, артикулдар, тариф нөмірлері, қате кодтары, компания атаулары, нақты модельдер және ішкі регламенттерден алынған фразалар. "deepseek v3.2" сұрауын ойланбай "deepseek-тің соңғы моделі" деп айналдыруға болмайды, ал "бұйрық 102" дегенді жалпы нормативтік актілер туралы сұрауға өзгертуге болмайды.

Түпнұсқаны қайта жазылған нұсқамен жойып тастамаңыз. Екеуін қатар сақтаңыз. Әйтпесе кейін rewrite шынымен көмектесті ме, әлде тек тапсырманы жеңілдетіп жіберді ме — түсіну қиын болады.

Бірінші цикл үшін әдетте 150-300 сұрау жеткілікті, егер олар дұрыс іріктелсе. Біртекті формулировкаларға толы үлкен кестеден гөрі, шағын бірақ адал жинақ жақсы. Егер іздеу бірнеше доменде жұмыс істесе, мысалы білім базасы, тауарлар және ішкі құжаттар бойынша, сұрауларды қолмен бөліңіз. Сонда тест орташа температураны емес, нақты әлсіз тұстарды көрсетеді.

Тесті қадам-қадаммен қалай өткізу керек

Query rewrite тестілеуді бірнеше нәрсені бірден өзгертсеңіз, оңай бұзып алуға болады. Адал тексеру үшін индекс, ранжирование, фильтрлер, деректер кезеңі және нәтиже өлшемін бекітіп қойыңыз. Өзгеретін тек rewrite болсын. Сонда сіз оның шынайы әсерін көресіз, ал көрші өзгерістерден шыққан шуды емес.

1. Алдымен rewrite-сыз базалық нәтижелерді алыңыз. Бірдей сұраулар жинағын өткізіп, әрқайсысы бойынша top-10 немесе top-20 құжатты сақтаңыз.
2. Содан кейін сол жинақты rewrite-пен іске қосыңыз. Іздеудің сол параметрлерін, сол индексті және сол нәтиже лимитін пайдаланыңыз.
3. Нәтижелерді әр сұрау бойынша салыстырыңыз, тек бүкіл жинақ бойынша орташа score-ға ғана қарамаңыз. Керек құжат қай жерде жоғары көтерілді, қай жерде орнында қалды, қай жерде жоғалды — соны белгілеңіз.
4. Сәтсіздіктерді қолмен талдаңыз. Сандар жалпы суретті көрсетеді, бірақ мағыналық қателерді көбіне көзбен бірден байқайсыз.

Практикада қарапайым кесте ыңғайлы: бастапқы сұрау, қайта жазылған сұрау, релевант құжаттың rewrite-ке дейінгі және кейінгі орны, қысқа түсініктеме. 30-50 мысалдан кейін бірдей бұзылулар қайталана бастайды.

Жақсы тест тек метриканың өсуіне емес, мағынаның сақталуына да қарайды. Мысалы, қолданушы "ИП үшін кепілсіз несие" деп іздейді, ал rewrite сұрауды "бизнеске несие" деп өзгертеді. Мәтін сырттай таза, тіпті танымал болып көрінуі мүмкін. Іс жүзінде жүйе "кепілсіз" деген шектеуді жоғалтып, басқа құжаттарды көтереді.

Қолмен талдағанда мынадай қысқа белгілер қою ыңғайлы:

• қолданушы ниетінің жоғалуы;
• сұраудың артық кеңеюі;
• термин немесе объектіні алмастыру;
• маңызды шектеудің өшіп қалуы;
• пайдасыз косметикалық қайта жазу.

Егер сұраулар көп болса, бәрін ретімен оқып шығуға тырыспаңыз. Алдымен релевант құжат қатты төмендеп кеткен немесе нәтижеден мүлде жоғалған жағдайларды алыңыз. Содан кейін rewrite айқын өсім берген сұрауларды қараңыз. Осылайша екі жағын да түсіну оңайырақ болады: қай жерде қайта жазу көмектеседі, қай жерде мағынаны бұзады.

Қандай метрикаларды бірге қарау керек

Бір метрика сирек дұрыс сурет береді. Сұрақты қайта жазу бір көрсеткішті көтеріп, екіншісін үндемей бұзып жіберуі мүмкін. Сондықтан әртүрлі қателерді ұстайтын сигналдар жинағын қараған дұрыс.

Recall@k қажетті құжаттың жоғарғы k нәтижеге кірген-кірмегенін сұрайды. Егер rewrite-ке дейін жауап табылмаса, ал кейін кемінде топ-10 ішінде пайда болса — бұл плюс. Офлайн тесттерде recall әсіресе сирек және ұзын сұрауларда пайдалы, өйткені жүйе сол жерде жиі мүлт кетеді.

NDCG@k тек табылғанын емес, нәтижелердің ретін де көрсетеді. Құжаттың топ-1-де тұруы мен тоғызыншы орында тұруы — екі бөлек қолданушы тәжірибесі. Егер recall@10 өсіп, ал NDCG@10 дерлік өзгермесе, rewrite, сірә, сұрауды кеңейткен, бірақ керекті жауапты жоғары көтермеген.

Нөлдік нәтиже үлесі бұзылған сұрауларды ұстайды. Ол rewrite маңызды терминді өшіріп тастағанын, фильтрді бұзғанын немесе сұрауды тым тар еткенін тез көрсетеді. Бірақ бұл метриканы жаман жолмен де "жақсартуға" болады. Егер қайта жазу сұрауды жалпырақ етсе, бос нәтижелер азаяды, бірақ релеванттылық төмендейді.

Сондықтан қатарда мағына дрейфінің метрикасы керек. Дрейф деп rewrite ниетті, объектіні, шектеуді немесе уақытты өзгертетін жағдайларды санауға болады. "ИП үшін абонплатасыз тариф" сұрауын шығынсыз "бизнеске арналған тарифтер" деп айналдыруға болмайды. Жүйе көбірек құжат табады, recall өседі, нөлдік нәтиже азаяды, бірақ бастапқы мағына ығысып кетеді.

Дрейфті шағын таңдамада қолмен немесе judge-модель арқылы санауға болады, бірақ даулы жағдайларды қолмен тексерген дұрыс. Ең көп қателерді әдетте сандар, терістеу, даталар, рөл атаулары және екі-үш сөзден тұратын қысқа сұраулар береді.

Қалыпты көрініс мынадай болады:

• recall@k өседі немесе кемінде төмендемейді;
• NDCG@k сонымен бірге өседі;
• нөлдік нәтиже үлесі мағына дрейфінің күрт өсуінсіз азаяды;
• сандар, даталар және нақты шектеулер бар сұрауларда дрейф төмен қалады.

Егер бір метрика жоғарылап, ал екеуі төмендесе, rewrite-ті ерте шығаруға болмайды. Ең жағымсыз жағдай графикте өте әдемі көрінеді: бос нәтижелер аз, табылған құжаттар көп, бірақ қолданушы жауабын өз сұрағына емес, басқаға оқып отыр.

Бір нақты сценарий

Банктың білім базасын алайық. Қолданушы "карта жоғалғаннан кейін қайта шығару" деп жазады. Мұндағы ниет тар. Адам картасын жоғалтып, жаңасын қалай шығару керегін, қанша уақыт алатынын және ең алдымен не істеу керек екенін білгісі келеді.

Rewrite сұрауды "картаға қолжетімділікті қалпына келтіру" деп өзгертеді. Бір қарағанда айырмашылық үлкен емес сияқты. Мағына жағынан бұл басқа сұрау. "Қолжетімділік" және "қалпына келтіру" сөздері іздеуді қосымшаға кіру, PIN-код, бұғатты ашу және жеке басын тексеру жағына тартады.

Мұндай rewrite-тен кейін іздеу дұрыс емес құжаттарды көтере бастайды. Топта "PIN-ді қалай қалпына келтіру керек", "Карта бұғатталса не істеу керек" немесе "Мобильді банкке қайта кіру жолы" сияқты мақалалар пайда болады. Олар көршілес жағдайларда пайдалы болуы мүмкін, бірақ бастапқы тапсырманы шешпейді.

Қолмен бағалау мұндай алмастыруды тез ұстайды, егер тек ұқсас сөздерге емес, қолданушының мақсатына да қарасаңыз. Тексеру үшін әдетте үш әрекет жеткілікті:

1. бастапқы сұрау мен оның rewrite-н қатар көрсету;
2. қайта жазғанға дейінгі және кейінгі top-5 нәтижені ашу;
3. бағалаушыдан қай шығарылым бастапқы тапсырманы жақсырақ шешетінін таңдауды сұрау.

Бөлек, rewrite ішінде бастапқыда жоқ жаңа мағына пайда болмады ма — соны белгілеу керек. Бұл мысалда қате бірден көрінеді. Карта бұғатталуы туралы мақала қосымша қадам ретінде орынды болуы мүмкін, өйткені жоғалған картаны дереу бұғаттау қажет болады. Бірақ егер мұндай материалдар қайта шығару нұсқаулығын ығыстырса, rewrite зиян келтірді.

Қарапайым баға қою ыңғайлы: егер нәтиже тікелей қайта шығаруға алып келсе — 2 балл; ішінара көмектессе — 1 балл; PIN, қолжетімділік немесе басқа көрші тақырыптарға бұрып жіберсе — 0 балл. Сонда мағына алмастыруы жай әсер деңгейінде емес, бағалау карточкасында көрінеді.

Мұндай кейстер жақсы ес жиғызады. Қарапайым мәтіндік ұқсастық rewrite сәтті болды дегенді білдірмейді. Егер ол қолданушының ниетін өзгертсе, офлайн метрикалар жаман емес көрінуі мүмкін, бірақ тірі өнімде адам жауабын таппай қалады.

Қай жерде көбірек қателеседі

Query rewrite тестілеудегі ең жиі қате — тек жиі сұрауларды алу. Оларда жүйе онсыз да жиі жақсы жұмыс істейді, сондықтан rewrite сирек және күрделі формулировкаларды бұзса да метрикалар өсіп кетеді. Команда әдемі есеп көреді, ал ұзын немесе бұлыңғыр сұрауы бар қолданушылар нашар нәтиже алады.

Бұл әсіресе тар мағыналы сұрауларда байқалады. Қолданушы "ИП үшін кепілсіз несие" деп жазады, ал rewrite оны "бизнеске несие" деп жеңілдетеді. CTR түспеуі мүмкін: адамдар бәрібір жоғарғы құжаттарды ашады. Бірақ мағына ығысып кеткен, ал іздеу басқа сұраққа жауап беріп тұр.

Екінші жиі қате — бәрін CTR арқылы ғана бағалау, будто ол бәрін түсіндіріп береді. CTR пайдалы, бірақ ол мағынаның сақталғанын, нәтижелердің дәлірек болғанын және керек шектеулер жоғалмағанын көрсетпейді. Егер rewrite сұрауды кеңейтсе, кейде кликтер тіпті көбейеді, өйткені нәтижелер жалпырақ көрінеді. Іздеу үшін бұл — табыс емес, тұзақ.

Көбіне бірден бірнеше нәрсе бұзылады:

• маңызды нақтылаулар жоғалады: аймақ, уақыт, баға, қолданушы рөлі;
• сирек термин танымалырақ, бірақ дәлдігі төмен сөзбен ауысады;
• аббревиатура қате ашылады;
• сұрау тым батыл қайта жазылып, адамның ниетін өзгертеді.

Тағы бір типтік мәселе — rewrite пен ранжированиені бір тестке араластыру. Егер сіз бір уақытта сұрауды қайта жазуды, ранжирлеу формуласын және дереккөздер жинағын өзгертсеңіз, өсім мен төмендеуді не бергенін түсінбей қаласыз. Мұндай тесттің пайдасы аз. Алдымен rewrite-ті бірдей индекс пен бірдей ранжирование жағдайында тексереді, тек содан кейін келесі қабатты қозғайды.

Көп команда нашар мысалдарды сақтауды ұмытады. Бұл қымбатқа түседі. Бірдей ақау жаңа релизден кейін бір айдан соң қайта оралады, өйткені оны ешкім тексеру жинағына бекітпеген. Тек сәтті сұраулар тізімі емес, қателер архиві де керек: бастапқы мәтін, rewrite нұсқасы, неге бұл жаман және қай құжат табылуы тиіс еді.

Кішкентай сәтсіздік базасы тағы мың жеңіл сұраудан пайдалырақ болуы мүмкін. Ол сіздің мағынаны жоғалтып жатқан-жоғалтпағаныңызды тез көрсетеді. Rewrite іздеуге көмектесетін нұсқа мен тек есепті әдемірек ететін нұсқа арасындағы шекара дәл осы жерде өтеді.

Іске қосар алдындағы чек-лист

Сұрақты қайта жазу шын мәнінде барынан ақылды көрінуі мүмкін. Егер салыстыруға түсінікті базаңыз болмаса, rewrite кейбір метрикаларды көтеріп, маңызды сценарийлерде мағынаны үнсіз бұзуы мүмкін.

Іске қосар алдында бес нәрсені тексеріңіз:

• rewrite жоқ іздеудің базалық нұсқасын сақтаңыз;
• күтілетін нәтижелері бар шағын, бірақ өміршең сұраулар жинағын дайындаңыз;
• rewrite қашан өткізіп жіберілуі керегін алдын ала шешіңіз;
• даулы кейстерді қолмен тексеруге жіберіңіз;
• релизге дейін қайтару шегін бекітіңіз.

Әдетте rewrite-ті дәл және навигациялық сұрауларға сирек қолданған дұрыс: атауларға, артикулдарға, келісімшарт нөмірлеріне, адамдардың аттарына және тырнақшадағы фразаларға. Ақпараттық сұрауларды батылырақ қайта жазуға болады.

Әйтпесе "бұйрық 37" сұрауы кенеттен "ішкі нормативтік құжаттар" болып кетеді де, сөз көбейгенімен релеванттылық төмендейді. Формальды түрде rewrite жұмыс істеді, мағына жағынан — жоқ.

Қолмен тексеру жүздеген мысалды қажет етпейді. Көбіне офлайн тесттер күткен нәтижеңізбен қайшы келетін 30-50 даулы жағдай жеткілікті. Екі нәрсеге қараңыз: модель нақты нені өзгертті және бұл керекті жауапты тезірек табуға көмектесті ме.

Егер rewrite бағалау үшін бірнеше модель немесе промпт қолдансаңыз, бәрін бірден өзгертпеңіз. Алдымен rewrite ережесінің өзін тексеріңіз, содан кейін модель мен баптауларды қозғатыңыз. Сонда не өсім бергенін, ал не сұрауды басқа жаққа бұрғанын түсіну жеңілірек.

Пилоттан кейін не істеу керек

Пилот сирек бүкіл трафикке ортақ бір жауап береді. Әдетте rewrite тек сұраулардың бір бөлігіне ғана көмектеседі. Егер ол қысқа, сөйлеу тіліне жақын немесе тым бұлыңғыр формулировкалар үшін сапаны тұрақты көтерсе, оны дәл сол жерде қалдырыңыз. Ал нақты артикулдары, компания атаулары, қызмет кодтары және цитаталары бар сұраулар үшін бастапқы мәтінді сақтаған дұрыс.

Пилоттан кейін жұмыс аяқталмайды. Енді сізде алғашқы деректер бар, соның негізінде rewrite-ті барлық жерде емес, тек мағына жоғалтпай пайда әкелетін жерлерде қосуға болады.

Әр сұрау класы бойынша төрт шешімнің бірін қабылдаған ыңғайлы:

• rewrite-ті әдепкі бойынша қосу;
• оны тек базалық іздеу әлсіз нәтиже бергенде ғана қосу;
• бастапқы сұрауды өзгертпеу;
• сұрау класын ережелерді немесе промптты жетілдіруге жіберу.

Бөлек журналда rewrite мағынаны өзгертетін қателерді жинаңыз. Ол өте тез ақталады. Әр жазбаға төрт жол жеткілікті: бастапқы сұрау, қайта жазылған нұсқа, нақты не жоғалды немесе не қосылды, және іздеу бірінші қандай құжатты көрсетті.

Мұндай журнал қайталанатын сәтсіздіктерді көруге көмектеседі. Мысалы, қолданушы "ИП үшін кепілсіз несие" деп жазады, ал модель сұрауды "бизнес несиесі" деп ықшамдайды. Мәтін қысқа әрі таза болды, бірақ маңызды шарт жоғалды. Осындай мысалдарды тұрақты regression-жинақта ұстап, rewrite-тің әр жаңа нұсқасынан өткізіп тұру керек.

Егер rewrite үшін бірнеше LLM салыстырсаңыз, модельді тез ауыстырып, интеграцияны әр жолы қайта жазбау маңызды. Мұндай прогондарға airouter.kz ішіндегі AI Router сәйкес келуі мүмкін: бұл OpenRouter-үйлесімді API шлюзі, онда модельдерді бір OpenAI-үйлесімді эндпоинт арқылы ауыстырып, бұрынғы SDK, код пен промпттарды сақтауға болады. Бағалау тұрғысынан бұл — бірдей сұраулар жинағын әртүрлі модельдер арқылы артық обвязкасыз өткізуге ыңғайлы тәсіл.

Пилоттың жақсы нәтижесі қарапайым көрінеді: сізде rewrite қосуға болатын сұрау кластарының тізімі, бөлек мағыналық қателер журналы және келесі прогонға арналған тест жинағы бар. Сонда rewrite іздеудің ішіндегі "сиқыр" болып кетпейді. Ол команда тексеріп, бақылауда ұстайтын жүйенің қалыпты бөлігі болып қалады.