Промпт кэші: LLM шотын қашан шынымен азайтады

Неліктен бірдей промпттар бәрібір ақша тұрады

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

API үшін мұндай сұраулардың әрқайсысы жаңа болып саналады. Егер сіз бірдей 2 000 токендік system prompt-ты 10 000 рет жіберсеңіз, модель сол 2 000 токенді 10 000 рет алып, өңдеді. Биллинг үшін бұл «сол мәтін» емес, 20 млн кіріс токені.

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

Шығын қайда тығылады

Әдетте шотты төрт нәрсе үлкейтеді: рөлі мен шектеулері бар ұзын system prompt, әр шақырудағы few-shot мысалдары, жауап форматына қатысты қайталанатын нұсқаулар және сессиялар мен тапсырмалар арасында қайта жіберілетін бірдей контекст.

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

Қолдау ботын елестетіңіз. Клиенттің сұрағы 8–15 токен ғана. Модельдің жауабы — шамамен 120 токен. Ал system prompt, тон ережелері, тыйым салынған әрекеттер тізімі және жауап схемасы 2 500 токенге дейін барады. Мұндай жағдайда сіз негізінен «ақылды жауап» үшін емес, бірдей нұсқауларды қайта-қайта тасымалдау үшін төлейсіз.

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

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

Кэш қашан жұмыс істейді

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

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

Толық сәйкестік және ортақ префикс

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

Бірақ практикада жиі көмектесетіні — толық сәйкестік емес, ортақ префикс. Яғни, мысалы, алғашқы 1 000–2 000 токен сұрауларда бірдей болады, ал соңғы бөлігі ғана өзгереді. Мұндай жағдай қолдауда жиі кездеседі: команда ботқа ұзын нұсқау береді де, соңында жаңа клиент сұрағын қояды.

Қарапайым сценарийде алғашқы 1 500 токен — рөлі, ережелер, анықтама және жауап форматы, ал соңғы 100 токен — пайдаланушының жаңа сұрағы. Мұнда кэш ақша үнемдеуді дәл сол ортақ бастапқы бөлікке жасайды.

Кэшке түсуін көбіне не бұзады

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

Әдетте мына детальдар кедергі жасайды:

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

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

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

Мұны өз деректеріңізде қалай есептеуге болады

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

Тек толық сұрауға емес, оның бөліктеріне де қараңыз. Әдетте бүкіл промпт емес, ұзын тұрақты негіз қайталанады: system prompt, ережелер, рөл сипаттамасы, жауап шаблоны, формат нұсқаулары және RAG-контекст үзінділері.

Әр сұрауды бірнеше бөлікке бөлген ыңғайлы:

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

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

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

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

Кішкентай мысал шатаспауға көмектеседі. Айталық, орташа сұрауда 1 000 кіріс токені бар, оның 700 токені — тұрақты шаблон. Егер бұл шаблон шақырулардың 35%-ында қайталанса және кэштен оқу кәдімгі кірістен айтарлықтай арзан болса, үнем байқалады. Бірақ шот 35%-ға емес, шамамен 700 x 35% кіріс бөлігіне тең мөлшерде, минус жазу мен оқу ақысы төмендейді.

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

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

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

Қандай шектен кейін үнем айқын көрінеді

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

5–10% деңгейіндегі қайталанулар әдетте ақшалай тұрғыда байқалмайды. Бұл қысқа чаттарға тән: ортақ префикс 30–80 токен ғана, ал қалғаны әр сұрауда өзгереді. Кэш кейде жұмыс істесе де, айлық шотты айтарлықтай түсіретіндей токен үнемделмейді.

Төменде шамамен бағдар беретін ориентир бар:

• 5–10% қайталану — үнем көбіне әлсіз, кейде өлшеу қатесінің шегінде
• 20–30% — егер ортақ префикс ұзын болса, әсері байқала бастайды, кемінде 300–500 токен
• 40–60% — кэшті әдетте қосып, шындап есептеу керек
• 70%-дан жоғары — шығынды сапаны жоғалтпай азайтудың ең оңай тәсілдерінің бірі болуы мүмкін

Енді ортақ префикстің ұзындығына келейік. Егер сізде «сыпайы жауап бер» сияқты қысқа чат болса және үстіне клиенттің сұрағы қосылса, 50% қайталану да скромды нәтиже беруі мүмкін. Ал егер әр сұрау үлкен жүйелік нұсқаудан, комплаенс талаптарынан, жауап форматынан және бірнеше абзац анықтамадан басталса, дәл сол қайталану деңгейі мүлде басқа сан береді.

Практикалық ереже мынау: қайталаным 20–30% болса, егер сәйкес бөлік бүкіл кірістің шамамен үштен бірінен ұзын болса, кэшті сынап көру керек. 40–60% болса, ол ұзын шаблондарда әдетте өзін ақтайды. Қайталану 70%-дан асса, орташа ұзын префикстің өзінде де айқын үнем береді.

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

Тағы бір ескерту бар: провайдерлер кэшті әртүрлі есептейді. Бірінде cached input үшін жеңілдік көбірек, бірінде сәйкестік ережелері қатаңырақ, кэштің өмір сүру мерзімі қысқарақ немесе қолдайтын модельдер тізімі шектеулі. Сондықтан абстракт шекке емес, нақты токен бағасына және логтардағы шынайы түсу үлесіне қарау керек. Қысқасы: 5–10% әдетте қуантпайды, 20–30% қызықты бола бастайды, 40% және жоғары деңгейлер есепте көрінетін әсер береді.

Қарапайым сценарийдегі мысал

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

Әр сұрауда үш блок қайталанады: 700 токендік жүйелік нұсқау, 500 токендік қайтару мен жеткізу ережелері және 250 токендік жауап форматы мен JSON схемасы. Барлығы 1 450 токен дерлік әрдайым бірдей. Өзгеретіні — қысқа бөлік: клиенттің хабарламасы, тапсырыс нөмірі, қала және CRM-дегі бірнеше өріс. Әдетте бұл тағы 100–150 токен.

Айталық, қолдау айына 20 000 сұрау жібереді. Кэшсіз орташа сұрау — 1 570 кіріс токені. Бұл айына 31,4 млн кіріс токені.

Енді қарапайым есеп жасайық. Провайдер кэшке түскен префиксті кәдімгі кірістен 10 есе арзан деп есептейді, ал префикс бойынша сәйкестік сұраулардың 85%-ында бар делік. Сонда көрініс өзгеріп кетеді.

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

Бірақ дәл осы тәсіл басқа сценарийде көп көмектеспейді. Егер оператор әр жолы ұзын диалог тарихын, клиенттің жаңа карточкасын, бұрынғы тапсырыстар тізімін және менеджердің жазбаларын қосса, қайталанатын бөлік, айталық, 200–300 токенге дейін қысқарады. Қалған 1 500–2 000 токен бірегей болады. Онда жеңілдік бар, бірақ жалпы шотта ол дерлік байқалмай қалады.

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

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

Жауап сапасын қалай бұзбауға болады

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

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

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

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

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

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

Жаңа мысалдармен тексеру әрдайым қажет. Соңғы 20–30 сұрауды алып, кэшпен және кэшсіз өткізіп, жауаптарды салыстырыңыз. Тек бағаны емес, жаңалықты, форматты және жеке деректердің сақталуын да қараңыз.

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

Жиі кездесетін қателер

Ең жиі қате қарапайым: командалар бәрін бірдей кэшке салады, тіпті өте қысқа промпттарды да. Егер шаблон 30–80 токен болса, пайдасы көп жағдайда байқалмайды. Кэш логикасын қосасыз, инвалидацияны қадағалайсыз, түсініксіз промахтарды ұстайсыз, ал үнем өте аз.

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

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

Деректерді кемінде мына белгілер бойынша бөлу пайдалы:

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

Тағы бір жиі проблема сырттай қарағанда жалықтырады, бірақ нәтижені бұзады. Шаблон бірдей сияқты көрінеді, бірақ іс жүзінде әр сағатта өзгереді. Ішіне ағымдағы дата, менеджер аты, сессия ID-і, эксперимент нұсқасы немесе debug үшін кездейсоқ жол кіріп кетеді. Кэш үшін бұл енді басқа сұрау.

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

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

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

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

Алдымен ортақ префиксті табыңыз. Ол system prompt, жауап ережелері, JSON форматы, қауіпсіздік саясаты немесе үлкен шаблон болуы мүмкін. Егер бұл бөлік көп токен алып, өте сирек өзгерсе, үнем ықтималдығы жоғары.

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

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

Одан кейін жауап сапасын тексеріңіз. 50–100 нақты сұраудан тұратын жинақты алып, кэш қосылғанға дейін және кейін нәтижені салыстырыңыз. Тек бағаны емес, дәлдікті, деректердің жаңалығын және персонализацияны да қараңыз.

Ал кэшті қашан тазалау керегін алдын ала келісіп алыңыз. Егер system prompt, өрістерді шығару шаблоны, анықтамалық немесе модерация ережелері өзгерсе, ескі жазбаларды бірден өшірген дұрыс.

Практикада осындай шағын аудиттің өзі жеткілікті болады. Айталық, қолдау күніне 800 өтініш өңдейді, және әр сұрауда 1 200 токендік бірдей нұсқау бар. Тіпті орташа кэшке түсу үлесінің өзінде үнем бірінші айда-ақ байқалады.

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

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

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

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

Алдымен кэшсіз базаны өлшеңіз. Жалпы әсер емес, бірдей кезеңге арналған қарапайым сандар керек: қанша токен жұмсалды, трафик қанша тұрды, кідіріс қанша болды және пайдаланушылар қаншалықты жиі түсініксіз жауаптарға шағымданды. Тіпті 5–7 күннің өзі де, егер ағын тым шағын болмаса, жақсы сурет береді.

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

Жұмыс реті қарапайым:

• айқын қайталануы бар бір сценарийді таңдау
• іске қоспас бұрын бағаны, кэшке түсу үлесін, кідірісті және сапаны өлшеу
• 1–2 апта кэш қосып, содан кейін сол деректерді қайта жинау
• сол сценарийді бір емес, 2–3 модельде де өткізу

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

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

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

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