Продакшндегі JSON-нан кейін артық мәтінсіз стоп-тізбектер

Неге модель керек жерден кейін де жауап бере береді

Модель жауап шекарасын сіздің кодыңыз көргендей көрмейді. Оны JSON, хат немесе дәйексөз жай ғана мәтіннің жалғасы болып көрінеді. Генерация лимитке, stop-жолға немесе нақты тоқтату сигналына тірелгенше, ол көбіне әрі қарай жаза береді.

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

Ең жаманы — мұндай қате ұзақ уақыт байқалмай қалады. Қысқа жауаптарда бәрі дұрыс сияқты көрінеді. Сосын ұзақ сұраным келеді, температура сәл көтеріледі де, керек жақша жабылғаннан кейін соңына бірдеңе қосылып кетеді. Егер сіз бірнеше модельді бір API немесе AI Router сияқты шлюз арқылы өткізіп жатсаңыз, бұл бірден көрінеді: бір модель }-тен кейін тоқтайды, ал екіншісі сол бірдей нұсқаумен тағы бір жол қосады. Демек, мәселе тек prompt-та емес. Жауаптың соңын анық көрсету керек.

Stop-тізбектер қай жерде шынымен керек

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

Көбіне бұл төрт жағдайда болады:

• артық мәтінсіз JSON
• хаттар мен жауап шаблондары
• интерфейстегі дәйексөздер немесе қысқа жолдар
• түсіндірмесіз SQL, YAML, HTML және код

JSON-да мәселе қарапайым: объект жабылды, бірақ модель "Дайын" деп қосып жібереді. Хатта ол қызметтік ескерту немесе кеңес тіркеуі мүмкін. Дәйексөзде жабылатын тырнақшадан кейін бір жол қосылса да, интерфейсте артық мәтін пайда болады. Продакшнда мұндай жалғалар ең қарапайым сценарийлерді бұзады: парсинг құлайды, ретрай көбейеді, кезек баяулай бастайды.

Stop-тізбектер қалай жұмыс істейді

Механикасы қарапайым. Сіз API-ға алдын ала жауап қай жерде тоқтауы керек екенін білдіретін бір немесе бірнеше жол бересіз. Генерация кезінде сервис жиналып жатқан мәтінді сол тізіммен салыстырады. Дәл сәйкестік көрінген сәтте шығысты тоқтатады.

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

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

Жақсы stop-жол үш нәрсе береді:

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

Бір тырнақша, бір жақша немесе END сияқты ортақ сөздер тым қысқа болғандықтан, көбіне жалған іске қосылады.

Stop-жолды форматыңызға қалай таңдау керек

Stop-жол әдемі белгіге емес, жауаптың нақты шекарасына сай болуы керек. JSON үшін бір } — нашар таңдау. Ол ішкі объектілерде де кездеседі және жауапты ерте тоқтатуы мүмкін.

Оның орнына объектінің өзіне кірмейтін бөлек аяқтау маркерін қосқан дұрысырақ.

Верни только JSON.
После JSON выведи строку END_JSON

Сонда API-да \nEND_JSON үшін stop қоюға болады. Сіз бүкіл блоктың соңын ұстайсыз, арадағы кездейсоқ жақшаны емес.

Хаттарда да логика бірдей. Модель өтпеуі тиіс шекараны іздеңіз: қызметтік блок, ішкі ескерту, CRM-дегі қолтаңбаның бастауы. "Рақмет" немесе "Құрметпен" сияқты жай сөздер жарамайды. Олар хаттың ортасында да оңай пайда болады.

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

Сирек маркер әдетте тыныс белгісінен сенімдірек. Тәжірибелік нұсқалар әдемі көрінбеуі мүмкін, бірақ болжамды жұмыс істейді: END_JSON_7X2, [[END_REPLY]], \u003cEND_QUOTE\u003e. Міндетті түрде бос орындар мен жол ауысуларын тексеріңіз. Бір бос орындағы қате stop-ты кодтағы қате сияқты-ақ бұзады.

Мұның бәрін қадам-қадаммен қалай баптау керек

Жауап форматынан бастаңыз, stop-жолдар тізімінен емес. Егер сізге тек JSON керек болса, соны анық жазыңыз: бір JSON объекті, түсіндірме жоқ, сәлемдесу жоқ, жабылатын жақшадан кейін мәтін жоқ. Егер хат шаблоны немесе бір дәйексөз керек болса, шекараны prompt-та тікелей көрсетіңіз.

Сосын API-ға stop қосыңыз. Әдетте жауаптың аяқталғанын анық білдіретін бір жол жеткілікті. Егер сұранымдарды OpenAI-үйлесімді шлюз арқылы жіберсеңіз, схема өзгермейді: сұранымда prompt пен stop массиві болады. AI Router жағдайында да логика солай, өйткені сервис OpenAI-үйлесімді эндпоинтті қолданады.

Одан кейін қысқа жұмыс тәртібі пайдалы:

1. Бір сәтті мысалды емес, 20-30 нақты сұранымды алыңыз.
2. Әр сұраным үшін жауап қай жерде аяқталуы керек екенін белгілеңіз.
3. Егер модель керек жерден кейін мәтінді жиі жалғастырса, temperature-ті төмен қойыңыз.
4. Жауаптарды продакшнда жұмыс істейтін сол парсер арқылы өткізіңіз.
5. Тек сәтті жауаптарға емес, сирек қателерге де қараңыз.

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

Соңғы тексеру қарапайым: сіздің кодыңыз жауапты қолмен қиып алмай, regular expression-дерсіз және inference-тен кейінгі кездейсоқ "құтқару" тәсілдерінсіз қабылдауы керек. Егер постөңдеусіз бәрі әлі дұрыс болмаса, себеп көбіне әлсіз prompt-та, сәтсіз stop-жолда немесе генерация параметрлерінің тым еркін болуында.

Продакшн мысалы

Кәдімгі сценарий: сервис өтінімді тексеріп, модельден status және reason деген екі өрісі бар JSON қайтаруды сұрайды. Одан кейін бұл жауапты код бірден оқиды. JSON таза болса, жүйе адам араласуынсыз әрі қарай жүреді.

Мәселе жабылатын жақшадан кейін басталады. Модель объектіні дұрыс береді, бірақ содан кейін операторға тағы бір жол қосады. Адам үшін бұл ұсақ нәрсе. Парсер үшін — қате.

{"status":"reject","reason":"неверный формат документа"}
Пояснение для оператора: попросите клиента загрузить фото без бликов.

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

Мұны әдетте қарапайым жолмен түзетеді. Команда қызметтік аяқтау маркерін қосады: мысалы, модельден объектіден кейін \u003cEND_JSON\u003e жолын бастауды сұрайды, ал API-да сол маркерге stop қояды. Модель объектінің соңына жетеді, жалғастыруға тырысады, тоқтау ережесіне тіреледі де, клиентке тек JSON келеді.

Схема қарапайым:

• prompt бір JSON объектісін талап етеді
• объектіден кейін модель \u003cEND_JSON\u003e жолын бастауы керек
• API шығысты \u003cEND_JSON\u003e кезінде тоқтатады
• парсер тек объектіні көреді

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

Нені көбірек бұзады

Көп сәтсіздік форматтағы ұсақ нәрселерден шығады.

Ең жиі қате — stop-жолдың тым қысқа болуы. Егер }-ті тоқтату сигналы ретінде қойсаңыз, модель бірінші кездескен объектіні жауып, JSON-ның қалғанын жазбай қоюы мүмкін. Бұл бір тырнақшада, бос жолда немесе END сияқты ортақ сөзде де болады.

Екінші мәселе — stop-маркер пайдалы деректердің ішінде кездеседі. Егер JSON ішіндегі мән END немесе ### қамтуы мүмкін болса, модель керек емес жерде тоқтап қалады. Бұл көбіне хаттарда, дәйексөздерде және тауар карточкаларында шығады.

Үшінші мәселе — бос орындар мен жол ауыстырулар. Бір модель \n\n### кезінде дұрыс тоқтайды, екіншісі ###-тың алдында артық бос орын қояды, сөйтіп ереже іске қосылмай қалады. Егер команда бірнеше модель қолданса, мұндай айырмашылық тез білінеді.

Және ең қарапайымы: чатта бәрі тексерілген, ал продакшн кодқа сол stop параметрі мүлде берілмей қалған. Бұл жиі болады.

Релизге дейін мына бес нәрсені жылдам тексерген дұрыс:

• stop-жол тым қысқа емес пе
• ол деректердің ішінде кездеспей ме
• әртүрлі модельдерде бос орын мен жол ауысуы бірдей ме
• API тест стендтегідей сол stop-ты жіберіп тұр ма
• prompt соңғы жауаптан кейін түсіндірме сұрамай ма

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

Бір stop-жол аз болғанда

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

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

Генерация режимдерін бөліңіз

Барлық форматқа бірдей stop-жолдар жиынын қолданбаңыз. Егер сервис кейде JSON, кейде хат, кейде қысқа дәйексөз қайтарса, әр режимге өз ережелерін бөлек ұстаңыз. Әйтпесе хатты жақсы кесетін маркер JSON-ды өрістің ортасында тоқтатып тастайды.

Практикада режимдерді былай бөлуге болады:

• json — құрылымдалған жауапқа арналған stop ғана
• email — қолтаңба мен хаттан кейінгі артық блоктарға арналған stop
• quote — дәйексөзді жабуға арналған stop
• free_text — ең аз шектеу

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

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

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

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

Қою алдында не тексеру керек

• Қысқа, бос, ұзын және шуылы көп енгізулерді өткізіңіз.
• Stop-маркер қолданушы мәтінінің ішінде кездейсоқ пайда болмайтынына көз жеткізіңіз.
• Тек модель жауабына емес, парсердің мінезіне де қараңыз.
• Логқа тоқтау себебін жазыңыз: модель қай маркер бойынша тоқтады және ол қай қадамда болды.
• Staging пен production әртүрлі ережемен өмір сүрмес үшін stop-жолдар жиынын конфигте және команда құжаттамасында сақтаңыз.

Бір практикалық тест көп уақыт үнемдейді. Мынадай шаблон алыңыз: {"status":"ok","message":"..."} және оны нақты енгізулерде өткізіңіз: бос сұраным, ұзын хат, лог үзіндісі, тырнақшасы бар мәтін, коды бар мәтін. Егер кем дегенде бір жағдайда модель жабылатын жақшадан кейін комментарий жазса, мұндай баптауды шығару ерте.

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

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

Жауаптың шағын тірі мысалдар жинағынан бастаңыз. Өзіңіздің ағыныңыздан формат маңызды болатын 15-30 сұраным алыңыз: интеграция үшін JSON, CRM үшін хат, интерфейс үшін дәйексөз, ішкі процесс үшін қысқа шаблон. Тек "мінсіз" мысалдармен шектелмеңіз. Модель бұрын-ақ жақшадан, қолтаңбадан немесе тырнақшадан кейін жалғастырып кеткен жағдайларды да қосыңыз.

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

Төрт нәрсені тексеріңіз:

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

Осыдан кейін тексеруді CI-ға бекітіңіз. Егер модель JSON, хат немесе дәйексөзден кейін құйрық қайтарса, сборка құлауы керек. Тест өте қарапайым болуы мүмкін: бірнеше эталон prompt жіберіп, жауапты күту және күтілген аяқталудан кейін артық таңба жоқ екеніне көз жеткізу. Егер құйрық шықса, тест проблемалы жауапты сақтап қалуы тиіс.

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