Модельді шығынсыз ауыстыру үшін диалог күйін қайда сақтау керек?

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

Қате «бізде conversation ID бар ғой» деген сөзден басталады. Мұндай ID-дің бір API-ден тыс әмбебап мағынасы жоқ. Ол сақталған тарихқа, бір жауапқа, ішкі орындау графына немесе қысқа сақтау мерзіміне ғана сілтеме жасауы мүмкін. Өнімді осы көрсеткішке байлаған кезде команда сессияны қалпына келтіруді, инцидентті зерттеуді және көшіруді провайдерге тапсырады.

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

Диалог күйі үш түрлі нәрседен тұрады

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

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

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

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

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

Практикалық ең аз құрылым мынадай:

conversation           - иесі, tenant, сақтау саясаты, күйі
conversation_event     - реплика немесе пәндік оқиғаның өзгермейтін жазбасы
context_snapshot       - қысқаша мазмұн, қамтылған оқиғалар аралығы, промпт нұсқасы
run                    - модельдің бір іске қосылуы, модель, параметрлер, трассировка
 tool_call             - атауы, аргументтері, idempotency_key, күйі, нәтижесі
provider_cursor        - провайдер, API түрі, сыртқы ID, белгілі болса жарамдылық мерзімі

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

Провайдердегі жад тізбекті жылдамдатады, бірақ оған байлайды

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

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

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

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

Провайдерде күй сақтау мына үш жағдайда орынды:

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

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

Модель ауыстыру JSON форматына емес, семантикаға байланысты бұзылады

OpenAI-мен үйлесімді хабарлама форматы жаңа endpoint қосуға көмектеседі, бірақ ол әңгіменің автоматты түрде тасымалданатынын білдірмейді. Өрістер бірдей көрінгенімен, рөлдердің, құралдардың, құрылымдалған шығыстың, суреттердің және жасырын reasoning деректерінің мағынасы әртүрлі болуы мүмкін.

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

Нақты вендордың түрлерін қайталамайтын канондық оқиғалар қабаты қажет. Мысалы:

{
  "event_id": "evt_01JX...",
  "conversation_id": "conv_8f2...",
  "sequence": 42,
  "kind": "tool_result",
  "actor": "application",
  "occurred_at": "2026-07-23T10:14:08Z",
  "payload": {
    "tool_name": "get_invoice_status",
    "call_id": "call_73a...",
    "input": {"invoice_id": "inv_481"},
    "output_ref": "obj://conversation-artifacts/evt_01JX...",
    "status": "succeeded"
  },
  "schema_version": 1
}

Мұнда kind бір модельдің ішкі рөлін емес, қолданба оқиғасын сипаттайды. Әдеттегі пайдалы типтерге user_message, assistant_message, tool_call_requested, tool_result, human_approval_requested, human_approval_resolved, context_compacted және policy_decision жатады. Әр ұсақ нәрсеге жеке тип қоспаңыз. Жаңа оқиға қауіпсіз қалпына келтіруге болатын нәрсені өзгертсе ғана тип қосыңыз.

Көшіру кезінде екі бағытта адаптерлер құрасыз:

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

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

Құпиялылық деректер жүретін бүкіл жолмен анықталады

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

Жұмысты кестеден емес, өрістерді жіктеуден бастаңыз. Пайдаланушы репликасында шарт нөмірі, медициналық сипаттама, төлем деректері немесе коммерциялық құпия болуы мүмкін. Құрал нәтижесі кейде сұрақтың өзінен де қауіпті: оператор «тапсырыс қайда?» деп сұрайды, ал CRM мекенжайды, телефонды және сатып алулардың толық тізімін қайтарады.

Әр дерек түрі үшін төрт нәрсені анықтаңыз: жазбаны кім оқиды, ол келесі сұрауда қайда кетуі мүмкін, қанша уақыт өмір сүреді және оны қалай жоюға болады. «Деректер шифрланған» деген жауап бұл сұрақтардың ешқайсысын шешпейді. Шифрлау тасымалдаушыны қорғайды, бірақ толық промпттың неліктен отладка журналына түскенін және оны басқа команда қызметкері неге оқи алатынын түсіндірмейді.

Жақсы архитектура редакциялауды контекст жинаудың бөлігі етеді. Модельді шақырмас бұрын жеке қабат:

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

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

Маршрутизация тағы бір айнымалы қосады. Агрегаторда бір үйлесімді endpoint модельдер мен провайдерлер арасындағы таңдауды жасыруы мүмкін. Мысалы, OpenRouter құжаттамасында маршрутизация параметрлері провайдерлердің ретін көрсетуге, fallback-ке тыйым салуға, белгілі параметрлерді қолдауды талап етуге, деректер сақталатын маршруттарды шектеуге және ZDR endpoints таңдауға мүмкіндік береді. Мәселе осы өрістерді кез келген стекке көшіруде емес. Деректер саясаты сұрау жіберілмей тұрып маршрут таңдауға қатысуы керек, код оқымайтын жеке PDF болып қалмауы тиіс.

Контекст бюджет пен мақсатқа сай жиналуы керек

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

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

Контекст жинаушы әдетте мына ретпен жұмыс істейді:

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

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

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

Сессияны қалпына келтіру идемпотенттіліктен басталады

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

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

1. tool_call_requested оқиғасын pending күйімен жазу.
2. conversation_id және call_id негізінде idempotency_key құру.
3. Сыртқы сұрауды осы кілтпен орындау.
4. tool_result оқиғасын succeeded немесе failed күйімен жазу.
5. Нәтижені модельге тек содан кейін жіберу.

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

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

Қолмен растау үшін тек «approved» белгісін сақтамаңыз. Сұрау кезіндегі аргументтердің снапшоты, кім растағаны, қашан растағаны, орындауға дейін не өзгергені және шешімнің жарамдылық мерзімі қажет. Әйтпесе оператор 10 000 теңгелік қайтарымды мақұлдап, қайталап іске қосу өзгерген сомаға сол растауды қолдануы мүмкін.

Сыртқы cursor түсінікті бас тартуы бар кэш болуы керек

Провайдердегі алдыңғы жауаптың ID-сін немесе server-side conversation-ды сақтау пайдалы. Бұл ұзақ тарихты жіберу шығыны мен кідірісті азайтады. Бірақ қолданба оны кэш деп санауы тиіс: үйлесімді әрі қолжетімді болса қолданыңыз, әйтпесе жеке журналдан сұрауды қайта жинаңыз.

provider_cursor кемінде провайдерді, модельді немесе модельдер отбасын, API түрін, сыртқы ID-ді, жасалған уақытты, нұсқаулар нұсқасын және саясат өзгергеннен кейін оны пайдалануға бола ма деген белгіні қамтуы керек. Tenant, құралдар жиыны немесе деректерді өңдеу режимі өзгергеннен кейін cursor-ды қайта пайдаланбаңыз. Формалды түрде әңгіме сол болуы мүмкін, бірақ шарттар өзгерді.

Қолданар алдындағы пайдалы тексеріс:

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

кері жағдайда:
- контекстті оқиғалардан жинау;
- жаңа іске қосу жасау;
- жаңа cursor-ды тек сәтті жауаптан кейін сақтау.

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

Деректерді сақтау моделін қате бағасына қарай таңдаңыз

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

Жеке деректері бар клиенттік чатта оқиғаларды, қолжетімділіктерді, маскалау ережелерінің нұсқаларын және аудитті өзіңізде сақтаңыз. Провайдерге ең аз жұмыс контекстін беріңіз. API тізбектерді сақтауды ұсынса, нақты деректер класы үшін сақтау, жою және маршрутизация шарттарын тексергеннен кейін ғана қосыңыз.

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

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

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