Мәнін жоғалтпай LLM контекстін қысқарту: терезелер мен қысқаша қорытындылар

Неге диалог фокусын жоғалтады

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

Модель қазір көріп тұрғанына көбірек сүйенеді. Егер бастапқыда сіз қатаң ережелерді, жауап форматын және тапсырма шекарасын беріп, кейін жиырма хабарламаға жаңа деталь қоссanız, алғашқы шарттар артқа ығысады. Формалды түрде олар әлі тарихта бар. Іс жүзінде кейінгі репликалар оларды басып қалады.

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

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

Көбіне контекст терезесін төрт түрлі артық мәтін толтырады:

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

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

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

Тарихта нені сақтау керек

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

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

Көбіне мынадай детальдарды қол астында ұстау керек:

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

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

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

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

Тағы бір жиі кездесетін артық мәтін — сәлемдесу, растау және бос нақтылаулар. «Рахмет», «қабылданды», «істей бер», «тағы бір рет байқап көр» сияқты тіркестер сирек мән береді. Қайталаулар да керек емес, әсіресе модель әлдеқайда жаңа тұжырым алған болса.

Жақсы бағдар мынау: тарихтың әр бөлігі «бұл неге қажет, егер алып тастасақ не бұзылады?» деген сұраққа жауап беруі тиіс. Егер ештеңе бұзылмаса, өшіріңіз. Егер шектеу, сан немесе шешілмеген таңдау жоғалса, қалдырыңыз. Сонда контекст терезесі әңгіменің өзін емес, тапсырманы жұмысқа қосады.

Контекст терезесі қалай жұмыс істейді

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

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

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

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

Жақсы мысал — ішкі қолдау чаты. Пайдаланушы бес хабарлама бойы қайтарымды талқылады, кейін жеткізу туралы сұрады, содан соң қайтадан қайтарымға оралды. Егер тек соңғы репликаларды сақтасаңыз, модель әңгімені оңай басқа жаққа бұрып жібереді. Ал жанында «клиент тапсырыс нөмірін растады және бір тауарға қайтарым сұрайды» деген қысқа қорытынды тұрса, тақырып ауысқаннан кейін де жауап дәл қалады.

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

Тарихты қадамдап қалай қысқартуға болады

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

1. Алдымен ағымдағы қадамның мақсатын бір сөйлеммен жазыңыз. «Диалогты жалғастыру» емес, нақты әрекет болсын: «қайтарым бойынша клиентке жауап дайындау» немесе «келісімнің екі нұсқасын салыстыру».
2. Сосын жауап бұзылып кететін фактілерді белгілеңіз. Әдетте бұлар — сандар, күндер, нысандардың атауы, таңдалған формат, бұрын қабылданған шешімдер және модель сүйенуі тиіс мәтін үзінділері.
3. Әңгіменің ескі бөлігін 5-7 жолдық қысқа қорытындыға ықшамдаңыз. Тек мағынаны қалдырыңыз: пайдаланушы не қалағанын, неге келгеніңізді, не тексерілгенін, қандай нұсқалардан бас тартылғанын.
4. Контекст терезесінде шектеулер мен ашық міндеттер қалғанын тексеріңіз. Шектеулер көбіне бірінші болып жоғалады, ал дәл солар жауапты шеңберде ұстап тұрады.
5. Осыдан кейін ғана сұрауды жіберіңіз. Егер токен әлі көп болса, мысалдарды, қайталауларды және ескі түсіндірмелерді қысқартыңыз. Ережелерді, фактілерді және жабылмаған сұрақтарды қысқартпаңыз.

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

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

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

Қорытынды толық логтан қашан жақсы

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

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

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

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

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

Қорытындыны ұзақ сессияның соңында емес, әр маңызды шешімнен кейін жаңартқан дұрыс. Сонда бот жадı бірқалыпты болады, секіріс пен жоғалту азаяды. Жаңа шешім болмаса, ештеңені қайта жазудың қажеті жоқ.

Жақсы ереже қарапайым: дәлдік үшін толық лог сақтаңыз, жұмыс үшін қорытындыны ұстаңыз. Белсенді терезеде 30-40 хабарламадан кейін көбіне мақсат, шектеулер, қабылданған шешімдер және даулы сұрақтар бар 6-8 жол жеткілікті.

Нақты сценарийдегі мысал

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

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

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

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

Жұмысқа жарайтын қорытынды қалай көрінеді

Толық логтың орнына жүйеге қысқа жазба жеткілікті:

• тапсырыс №48173
• бір позиция бойынша қайтарым сұрауы өңдеуге қабылданды
• тапсырыстың қалған бөлігі үшін жеткізу мекенжайы өзгертілді
• агент өзгерістерді 18:00-ге дейін растайтынын айтты

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

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

Командалар қай жерде қателеседі

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

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

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

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

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

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

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

Сұрау жіберер алдындағы жылдам тексеріс

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

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

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

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

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

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

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

Жалпы схема түсінікті болса, оны бірден өндіріске көшірмеңіз. Алдымен LLM контекстін қысқартуды құны мен жауап сапасы көрінетін қысқа тексеріс жиынына айналдырыңыз.

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

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

Мұндай тексеріс үшін қысқа жоспар жеткілікті:

• өнімнен 10-15 типтік диалог жинау
• оларды толық логпен және қорытындымен өткізу
• токен санын, кідірісті және жауап сапасын салыстыру
• 20-30 қадамдық ұзақ тізбектерді бөлек тексеру
• жүйе қорытындыны қай сәтте жаңартатынын жазу

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

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

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

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