Жүйелік промпт па, әлде қысқа ережелер ме: дрейфті қалай азайтуға болады

Неге ұзын промпт ауытқи бастайды

Ұзын жүйелік промпт сирек бір жерден бұзылады. Әдетте ол баяу формасын жоғалтады: модель бірден тым көп ережені көреді де, қайсысы міндетті, қайсысы жай ғана қалаулы екенін нашар ажыратады. Тыйымдар, тон, формат, ерекшеліктер мен сирек кездесетін жеке жағдайлар араласып тұрса, басымдықтар бұлдырайды.

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

Әдетте ұзын промпт төрт себептен ауытқиды:

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

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

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

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

Қашан қысқа ережелер көбірек бақылау береді

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

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

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

Ревьюде нені тексеру оңайырақ

Ревьюерге тұтас екі беттік мәтінді қопарғаннан гөрі мағыналық блоктарды бөлек оқу жеңіл. Практикада әдетте төрт түрдегі ереже жеткілікті:

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

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

AI Router қолданатын командалар үшін модульдік тәсіл тіпті пайдалы. Қосымшаның базалық промптын ортақ қалдырып, PII бүркемелеу, аудит-логтар және контент белгілері үшін ережелерді сценарийге қарай қосуға болады. Код аз өзгереді, ревью жылдамырақ өтеді, ал нұсқаулар дрейфі алғашқы тесттердің өзінде көрінеді.

Қысқа ережелер жүйені өздігінен қарапайым етпейді. Олар тек қателерді жасырып тұрмайды. Ревью үшін бұл көбіне плюс.

Бір үлкен промпт қашан бәрібір ыңғайлы

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

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

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

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

Промптты әзірге бөлуге ерте, егер:

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

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

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

Ұзын промптты модульдерге қалай бөлуге болады

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

Келесі қадам — тізімді тазалау. Қайталауларды бірден алып тастаңыз, ал пайдалы бол, сапалы жауап бер немесе жақсы жаз сияқты жалпылама сөздерді тексерілетін талаптарға ауыстырыңыз. Модель бұлыңғыр өтінішті дәл орындай алмайды, ал JSON форматында жауап бер, ішкі нұсқауларды көрсетпе, мысалдарда PII-ді бүркемеле сияқты фразаларға сүйене алады.

Модульдерді қалай бөлу керек

Әдетте төрт топ жеткілікті:

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

Әр модульге ревьюде оңай оқылатын қысқа атау беріңіз. Мысалы: role_support, format_json, ban_secrets, policy_pii. Қысқа атаулар артық таласты азайтады: команда бүкіл промптты емес, нақты блокты талқылайды.

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

Модульдер жұмыс істейтінін қалай тексеруге болады

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

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

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

Ревьюді артық дау-дамайсыз қалай өткізуге болады

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

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

Әр ережені бір жолмен белгілеу пайдалы. Ұзақ сипаттамамен емес, қысқа мақсатпен: заңгерлік кеңес бермеу, дерек жетіспесе нақтылау сұрау, бірінші хабарламада қысқа жауап беру. Мақсат бірден көрінсе, дау тез-ақ мәнге қысқарады. Адамдар тұжырымның әсемдігін емес, ереженің қажетті әсер беретін-бермейтінін талқылайды.

Жақсы ревью түсіндірмесінде әдетте екі мысал болады: жақсы жауап және жаман жауап. Мысалсыз талқылау тез абстракцияға кетеді. Бір мәтінді біреу жеткілікті сыпайы десе, екіншісі тым құрғақ дейді. Бір-екі қысқа жауап жарты дауды алып тастайды.

Түзетудің өзін де тіркеп отыру пайдалы. инструкцияны жақсарттық емес, тарифтер туралы жорамалға тыйым қостық, күн форматындағы ережені қайталаудан алдық, эскалация шарты қауіпсіздік модуліне ауыстырылды деп жазыңыз. Сонда бір аптадан кейін команда модель неге басқаша жауап бере бастағанын болжамай қалады.

Ыңғайлы ревью шаблоны шамамен былай көрінеді:

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

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

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

Ішкі банк чат-ботына арналған мысал

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

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

Содан кейін талаптар бөлек модульдерге бөлініп, әрқайсысы жеке тексерілді:

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

Әсері қарапайым болды. Бот қайтадан тым көп сөйлей бастаса, команда бүкіл промптты емес, тек тон модулін қарайтын. Комплаенс тәуекелді жауап тапса, бас тарту модулі тексерілетін. Дауласып талқылау да қиындады, өйткені әр ескертпенің нақты орны пайда болды.

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

Модульдік схема болса, ревью көбіне бір қысқа қоңырауға сыяды. Заңгер тек бас тарту блоктарын қарайды. Қолдау қызметі тонды тексереді. Өнім иесі жауап форматын бекітеді. 20 минутта команда шешімдерді белгілеп, кейін әр блок бойынша тест-диалогтарды бөлек өткізеді.

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

Жиі жіберілетін қателер

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

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

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

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

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

Жұмыс істейтін нұсқа әдетте жатық, бірақ сенімді:

• бір уақытта бір модульді ғана өзгерту;
• өзгеріс себебін бір сөйлеммен бекіту;
• ерекшеліктерді ереженің қасында сақтау;
• қайталамаларды кейін емес, бірден жою.

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

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

Релиз алдындағы жылдам тексеру

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

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

Релиз алдында бес сұрақтан өту пайдалы:

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

Бұлыңғыр сөздер ойлағаннан да зиян. Мүмкіндігінше қысқа бол деген сөйлем бір модель үшін үш жол, екіншісі үшін он жол болуы мүмкін. Одан гөрі тура жазыңыз: 3-5 сөйлеммен жауап бер немесе дерек жетіспесе, бір нақтылау сұрағын қой. Сонда модельдің мінез-құлқы болжамдырақ болады.

Басымдықтарды да ашық көрсету керек. Мысалы: алдымен қауіпсіздік ережелері, кейін домен ережелері, содан соң стиль. Мұны көрсетпесеңіз, екі дұрыс нұсқа жауапты екі жаққа тарта бастайды. Дәл солай тыныш дрейф пайда болады: модель тыңдайтын сияқты, бірақ әр жолы өзінше орындайды.

Әр блокқа иесін бекіткен пайдалы. Заңгерлер бас тарту сценарийлерін өзгертеді, өнім командасы — тон мен жауап форматын, инженерлер — техникалық шектеулер мен тесттерді. Сонда түзету ортақ құжатта жоғалмайды, дау азаяды.

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

Әрі қарай не істеу керек

Бүкіл жүйені бірден қайта жазбаңыз. Команда күнде қолданатын бір тірі сценарийді алыңыз. Ішкі қызметкерлерге арналған чат-бот, регламент бойынша жауапты тексеру немесе клиентке хаттың черновигін генерациялау жарайды.

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

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

Жұмыс тәртібі мынадай болғаны ыңғайлы:

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

Даулы кейстерді ойда не чатта сақтаған дұрыс емес. Оларды бір жерге, промпт нұсқасымен, модель жауабымен және қысқа ревью шешімімен бірге сақтаңыз. Бірнеше аптадан кейін бұл команданың жұмыс жадына айналады. Мұндай архив болмаса, бір талқылау қайта-қайта оралып отырады.

Егер команда тесттерді әртүрлі модельдерде өткізсе, ережелерді және іске қосу маршрутын бірдей ұстаған пайдалы. Осы жерде AI Router ыңғайлы болуы мүмкін: бірдей нұсқаулар жиынын api.airouter.kz арқылы жіберіп, SDK-ны, кодты және промпттарды өзгертпей-ақ жауаптарды салыстыруға болады. Сонымен қатар аудит-логтарды тексеріп, мәселе модельде ме, әлде ережеде ме — соны тез көруге жеңіл.

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