LLM сұрауларының идемпотенттілігі және қосарланған шегерімсіз

Не бұзылады идемпотенттілік болмаса

Идемпотенттілік болмаса, бір ғана сұрау оңай екі операцияға айналып кетеді. Бұл үшін сирек баг қажет емес. Тек "Жіберу" батырмасын екі рет басу, таймауттан кейін автоматты ретрай немесе стримнің соңғы үзінділерінде желінің үзілуі жеткілікті.

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

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

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

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

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

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

Сондықтан идемпотенттілік "әдемі архитектура" үшін керек емес. Ол пайдаланушы бір әрекет деп қабылдаған нәрсенің API, биллинг және логтар үшін де бір әрекет болып қалуы үшін қажет.

Қайталанулар мен артық шегерімдер қайдан пайда болады

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

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

Дубликаттардың тағы бір көзі — қысқа таймауты бар прокси немесе API-шлюз. Ол 10-15 секунд күтеді де, сұрау тұрып қалды деп санап, оны қайта жібереді. Бірақ модель сол уақыттың бәрінде бірінші сұрауды тыныш өңдеп жатқан болуы мүмкін. Екі әрекет те соңына жеткенде, команда екі нәтиже алып, екі есе төлейді.

Стримингте шатасу одан да көп. Модель жауаптың бәріне жуық бөлігін жасап қойған, клиент токендердің бір бөлігін алып үлгерді, содан кейін байланыс үзілді. Пайдаланушы кесілген мәтінді көріп, "Қайта орындау" батырмасын басады. Жүйе сол prompt-ты тағы бір рет жібереді, ал есептеу әлдеқашан жасалған.

Типтік сценарий былай көрінеді:

• браузер чатқа хабарлама жіберді;
• модель жауапты аяқтады;
• стрим соңғы үзінділерде үзілді;
• бет жаңартылды немесе пайдаланушы қайта басты;
• қосымша дәл сондай тағы бір сұрау құрды.

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

Бір және сол операция деп нені санау керек

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

LLM-де мұны жауапқа және бағаға әсер ететін контекст бойынша анықтаған ыңғайлы. Әдетте мыналарды тексеру жеткілікті:

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

Егер осы элементтердің кем дегенде біреуі өзгерсе, бұл жаңа операция. Тіпті болмашы түзету де мәнін өзгертеді. Пайдаланушы prompt-қа бір жол қосты, модельді ауыстырды, max_tokens не temperature мәнін көтерді — демек, жаңа идемпотенттік кілт керек.

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

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

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

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

Идемпотенттік кілт қалай жұмыс істейді

Идемпотенттік кілтті сұрауды жібермей тұрып жасау керек, қате шыққаннан кейін емес. Клиент немесе бэкенд бір операция үшін бірегей идентификатор жасайды: чаттағы бір хабарламаға, бір есеп генерациясына, бір құрал шақыруына. Бұл кілт сұраумен бірге жіберіледі.

Кейін сервис қарапайым нәрсе істейді. Ол осы кілт, операция статусы және кіріс деректерінің отпечатогы бар жазбаны сақтайды. Отпечаток әдетте нәтижеге және құнға әсер ететін өрістер бойынша есептеледі: model, messages, temperature, tools және басқа параметрлер.

Негізгі сценарий былай көрінеді:

1. Клиент сұрауды жібермей тұрып кілт жасайды.
2. Сервер сұрауды қабылдап, in_progress статусы бар жазбаны резервтейді.
3. Сәтті жауаптан кейін сервер соңғы нәтижені немесе оған сілтемені сақтап, жазбаны done күйіне ауыстырады.
4. Егер сол кілт қайта келсе, сервер жаңа генерацияны бастамайды, сақталған жауапты немесе ағымдағы күйді қайтарады.

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

Маңызды ереже бар: бірдей кілтті басқа сұрау денесімен қолдануға болмайды. Егер клиент бірдей idempotency key жіберіп, бірақ prompt-ты немесе модельді өзгертіп жіберсе, сервер конфликт қайтаруы керек. Әйтпесе қорғаныс мәнін жоғалтады: сырт көзге бұл қайталау сияқты, ал іс жүзінде бұл жаңа операция.

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

Жақсы ереже қысқа: бір пайдаланушы ниеті, бір кілт, бір нәтиже.

Қайта қосылуларсыз қалай енгізуге болады

Идемпотенттілікті бір ғана нүктеде емес, бүкіл сұрау тізбегі бойымен енгізген дұрыс. Тек фронтендті немесе тек модельге шақыруды қорғау жеткіліксіз — саңылаулар бәрібір қалады.

Алдымен кілтті кім жасайтынын шешіңіз. Веб-чатта және мобильді қосымшада оны хабарламаны жіберу сәтінде клиент жағында жасау ыңғайлы. Егер клиенттерге сенім аз болса немесе сұраулар бірнеше жүйеден келсе, кілтті бэкенд бере алады. Практикада жиі аралас тәсіл жұмыс істейді: фронтенд өз әрекет идентификаторын жібереді, ал бэкенд оған пайдаланушыны, операция түрін және басқа қажетті өрістерді қосады.

Келесі маңызды нәрсе — реті. Әуелі кілтпен in_progress статусы бар жазбаны резервтейсіз. Содан кейін ғана сыртқы LLM API-ға барасыз. Керісінше істесеңіз, сыртқы шақыру мен нәтиже жазу арасында гонкаға арналған терезе пайда болады. Сол терезенің өзі екінші процестің сол сұрауды қайта жіберуіне жеткілікті.

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

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

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

Чат пен таймаут мысалы

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

Оператор қате көріп, батырманы тағы басады. Адам үшін бұл сол бір сұрау. Қорғаныссыз жүйе үшін — екі бөлек шақыру. Міне, осылай қосарланған шегерімдер мен тарихтағы бір-біріне ұқсас екі жауап пайда болады.

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

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

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

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

LLM кәдімгі API сияқты емес қай тұста

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

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

Стриминг нені өзгертеді

LLM-де жауап жиі ағынмен келеді. Клиент алғашқы токендерді алып үлгерді, бірақ usage әлі келмеді. Дәл осы сәтте желі тұрып қалса немесе пайдаланушы батырманы қайта басса, сервер бірінші генерация әлі тірі тұрғанда қайталанған сұрау алуы мүмкін.

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

Тағы бір жағымсыз нәрсе — сыртқы әрекеттер. Егер function calling өтінім құруды, SMS жіберуді немесе CRM-ге жазба жасауды іске қосса, ретрай сол құралды тағы бір рет шақырып жіберуі мүмкін. Сонда сізде чаттағы екі ұқсас жауап емес, екі нақты әрекет болады.

Неліктен кэш жеткіліксіз

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

Қарапайым мысал: пайдаланушы хабарлама жіберді, модель тапсырысты рәсімдеу үшін tool шақырды, содан кейін клиент стримнің соңын күтпей, сұрауды қайта жіберді. Кэш жұмыс істемеуі мүмкін, өйткені екінші жауап сәл басқа болады. Тіпті кэш жұмыс істесе де, ол әлдеқашан орындалған сыртқы шақыруды жоймайды.

Сондықтан кэш пен идемпотенттілікті араластырмау керек. Кэш пайдалы нәтижені сақтайды. Идемпотенттік кілт нақты операцияны сіз әлдеқашан бастағаныңызды немесе аяқтағаныңызды сақтайды.

Іске асырудағы жиі қателер

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

Бірінші жиі қате — бірдей prompt-ы бар барлық сұрауды бір операция деп санау. Бұл жеткіліксіз. Егер отпечатокқа модель, temperature, max_tokens, жүйелік prompt, құралдар және нәтижеге әсер ететін басқа параметрлер кірмесе, сервис әртүрлі операцияларды бір жерге жабыстырып тастайды.

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

Үшінші қате — бір кілтті әртүрлі пайдаланушы немесе tenant үшін қолдану. Кілттің өз аймағы болуы керек: пайдаланушы, жоба, операция. Әйтпесе бірдей кілті бар екі клиент біртүрлі жауап алмасып кетеді.

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

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

Өзін-өзі тексерудің пайдалы минимумы мынадай:

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

Іске қоспас бұрын жылдам тексеру

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

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

Мұны қолмен де, автотесттермен де тексеріңіз:

• "Жіберу" батырмасын қайта басу модельге екінші рет жүгінуге және жаңа есептен шығаруға әкелмейді;
• клиент таймаут алса, сервер алдымен кілт бойынша жазбаны іздейді, сосын ғана көзсіз жаңа сұрау жібереді;
• стрим және кәдімгі жауап бір есепке алу сценарийімен жүреді;
• логтарда идемпотенттік кілт, пайдаланушы, модель, сұрау параметрлері және usage байланысып тұрады;
• команда сұраудың жолын статустар арқылы көреді: received, sent_to_provider, first_token, completed, failed, expired.

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

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

Продакшнда не істеу керек

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

Бір жақсы қорғалған ағын — нақты жүктемедегі тексеріссіз абстрактілі "идемпотенттілік қолдауы" дегеннен пайдалырақ.

Содан кейін бақылаудың шағын жиынтығын жинаңыз:

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

Бұл метрикалар жүйенің қай жерінен ағып жатқанын тез көрсетеді. Көбіне мәселе қосымшада емес, ретрайлар төменірек жерде қосылып кеткенінде болады: SDK-да, кезекте, API-проксиде немесе балансировщикте. Пайдаланушының бір сұрауы әр қабат оны өз ережесімен қайталап жіберсе, екі-үш шақыруға оңай айналады.

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

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

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