Зниження витрат на токени агента: кешування, маршрутизація та підтримка чистоти контексту.

Перший агент зазвичай починає роботу з системного запиту на 500 токенів та двома інструментами, причому обидві ці цифри швидко зростають. Кажуть, що витеклий системний запит Claude мав довжину близько 24 000 токенів. Користувачі OpenClaw повідомляють, що вже на першому кроці до Gemini 3.1 Pro надійшло понад 150 000 токенів вхідних даних, що призвело до відповіді довжиною 29 токенів. Якщо не оптимізувати, агент, який обробляє 100 повідомлень на день, кожне з яких містить 166 тис. токенів вхідних даних, коштуватиме приблизно 996 доларів на місяць у Gemini 3.1 Pro та близько 2 490 доларів у Claude Opus 4.6. Кілька правильних рішень щодо проектування можуть знизити цю вартість до рівня приблизно 50–100 доларів.

Ідеї, які тут розглядаються, включають кешування запитів, семантичне кешування, інструменти затриманого завантаження та сервери MCP, маршрутизацію та послідовну обробку даних між моделями, делегування завдань підагентам та підтримку чистоти робочого контексту. Кожен з цих підходів дозволяє заощадити гроші по-різному, але кожен має свою ціну у вигляді складності чи якості. Жоден з них не є безкоштовним.

Матеріал поділяється на чотири групи. Перша стосується повторного використання токенів, коли це можливо, за допомогою кешування запитів та семантичного кешування. Друга — скорочення кількості токенів, які завжди присутні, таких як дані пам’яті та визначення інструментів. Третя — перерозподіл завдань між меншими моделями або переход до більших, з урахуванням ризиків для якості та можливих економій. Остання група стосується підтримки чистоти контексту задля покращення продуктивності та зниження витрат, з коротким оглядом методів компактування.

Перестаньте платити двічі за однакові токени

Витрати на роботу моделі виникають не лише через надмірну кількість запитів до неї. Вони також зумовлені постійними оплатами за обробку однакового тексту. Допомагають два зовсім різні механізми. Кешування K/V є частиною механізму кешування запитів, тоді як семантичне кешування — це окрема концепція. Для довгих системних запитів кешування запитів є простим способом економії ресурсів; семантичне кешування вимагає більше зусиль та несе більший ризик.

Як працює кеш K/V

Перш ніж модель щось створить, вона мусить обробити запит, а це потребує обчислювальних ресурсів, що призводить до затримок та додаткових витрат. Має сенс не обробляти один і той самий контент багаторазово.

Коли велика мовна модель отримує запит, текст токенізується, токени перетворюються на вектори, а в кожному шарі уваги ці вектори проєктуються у тензори K/V.

Кешування означає зберігання цих тензорів, щоб їх не доводилося обчислювати знову. Механізм інференсу вже зберігає тензори типу K/V під час генерації, адже інакше математичні операції не виконуватимуться з прийнятною швидкістю. Наступним кроком є зберігання кешу після завершення відповіді та його не видаляння.

Під час наступного запиту система перевіряє, чи початок запиту збігається з чимось, для чого у неї вже є тензори. Якщо так, вона завантажує їх та пропускає процес обробки.

Економічну ефективність легко побачити, використовуючи округлені цифри. Припустимо, обробка 2 000 токенів займає одну секунду, а запит містить 10 000 токенів. Пропуск повторного обчислення економить 5 секунд на кожен запит, хоча реальна продуктивність залежить сильно від налаштувань.

Порівняння з збереженим кешем має бути точним. Якщо змінюється хоча б один токен, тензори для цієї частини запиту більше не є актуальними, і її потрібно обробляти знову. Люди постійно стикаються з цим: додатковий пробіл, змінений порядок визначення інструменту чи часовий позначник у неправильному місці руйнують збіг.

Отже, збережений кеш прискорює запити та, в свою чергу, робить їх дешевшими. Однак зберігання кешу не є безкоштовним. Кешовані дані типу K/V займають пам’ять на сервері, тому багато постачальників видаляють записи через приблизно 5–10 хвилин.

Нікому не потрібно створювати це з нуля, адже фреймворки та постачальники API самі цим займаються, кожен за власними правилами. Команди, які хостують моделі з відкритим кодом, зазвичай використовують фреймворки для обслуговування, такі як vLLM, у яких є вбудований шар кешування. Користувачі API, у свою чергу, дотримуються правил кожного постачальника.

Кешування префіксів у vLLM

Шар кешування в vLLM розділяє запит на блоки, генерує хеш кожного блоку на основі його власних токенів та токенів, що передують йому, і зберігає тензори K/V під цими хешами. Як і у більшості конфігурацій, статична частина, яку потрібно кешувати, має знаходитися на початку запиту.

Важливі три параметри:

• --enable-prefix-caching увімкнює цю функцію.
• --block-size визначає кількість токенів у кожному блоку. При розмірі блоку 16 двигун закінчує обробку після 16 токенів та починає новий блок.
• --kv-cache-memory-bytes безпосередньо встановлює розмір кешу K/V для кожної GPU. Більше пам’яті дозволяє кешованим блокам зберігатися довше, але багато одночасних довгих запитів швидше її заповнюють, і старі блоки видаляються раніше.

Існують й інші варіанти, зокрема SGLang із RadixAttention для кешування префіксів та LMCache, призначений для інтеграції в движки обслуговування. Механізми працюють так само, як описано вище.

Кешування через постачальників API

Більшість команд використовують постачальників API, і кожен з них має свої правила, щоб запити потрапляли до кешу. Для цього запит має бути правильно структурований. OpenAI є яскравим прикладом: кешування частини запиту вимагає точного збігу префікса, тобто однакового статичного вхідного даних на початку. Тому спочатку йдуть стабільні інструкції, приклади та інструменти, а різноманітний контент — після них.

Надсилання prompt-cache-key дозволяє об’єднувати схожі запити та підвищувати частку успішних пошуків у кеші. Кешування автоматично активується для запитів довжиною 1 024 токенів або більше, проте перші 256 токенів використовуються для направлення запитів назад у той самий кеш, тому статична частина має бути довшою за 256 токенів.

Anthropic працює інакше: кешування потрібно увімкнути за допомогою параметра cache-control. Видалення даних зазвичай відбувається через 5–10 хвилин бездіяльності у обох провайдерів, і цей термін можна подовжити. Anthropic дозволяє подовжити його до години за подвійною ціною.

При самостійному хостингу заощаджений час означає також заощадження грошей. З API-провайдерами перевага полягає у дешевших токенах вхідних даних у кеші. OpenAI знижує вартість кешованих вхідних даних на 90% від звичайної ціни. Anthropic також надає таку саму знижку на кешовані дані, але стягує плату за зберігання кешу, тож неправильне використання може обійтися дорожче, ніж відсутність кешування.

Якщо 90% запиту є статичним та кеш використовується належним чином, витрати значно знижуються, як показано на графіку.

Для цього порівняння була створена інтерактивна калькулятор, щоб можна було коригувати числа. Загалом, кешування запитів — це значна перевага для тих, у кого довгий запит системи, який не змінюється.

Семантичне кешування

Семантичне кешування — це зовсім інше. Воно ґрунтується на збігу значень: якщо новий запит достатньо схожий на попередній, повертається збережена відповідь. Це звучить просто, але існують чіткі підводні камені.

Збіг тексту за значенням здійснюється за допомогою ембеддингів, які є векторами, порівнюваними за косинусовою схожістю. Висока схожість має означати схоже значення, хоча це залежить від моделі ембеддингів.

Пропозиція полягає у поєднанні схожих запитів із вже наявними відповідями. Запит на кшталт «Який столиця Франції?» та поспішний запит «Швидко, скажіть столицю Франції» мають потрапляти до однієї збереженої відповіді, без необхідності знову викликати ШІ для її генерації. Це добре працює, коли багато людей ставлять майже ідентичні універсальні запитання, а базові дані поступово стають застарілими.

То чому б не робити це скрізь? Тому що може статися багато проблем. Дизайн має вирішити кілька питань:

• Який поріг схожості вважається підходящим для поєднання.
• Як довго залишається дійсною відповідь.
• Як обробляються багатокрокові розмови.
• Що саме зберігається.
• Чи потрібен проміжний шлюз для керування.
• Як утримувати користувачів окремо один від одного.
• Що відбувається, якщо зберігається неправильна відповідь.

Термін життя даних потребує особливої уваги, адже інформація старіє з різною швидкістю для різних запитань. Механізм простий, але для практичного використання потрібні фільтри та теги метаданих, такі як користувач, робоче простір, версія корпусу, персона, обмеження сесії, розумний термін життя даних та певні правила для визначення того, чи є отримана відповідь достатньо якою. Це перетворюється на невеликий проект.

Ефективний дизайн використовує семантичний індекс для пошуку попереднього запитання та дозволяє різним запитанням посилатися на одну й ту саму збережену відповідь, що обмежує зростання обсягу зберігання. Термін життя даних може залежати від частоти використання: записи, які використовуються часто, слід зберігати довше, а решту — видаляти. Також доцільно створювати цю систему після того, як журнали показують повторення запитів, а не з самого початку, оскільки деякі сценарії використання просто не підходять для неї.

Багато баз даних можуть виконувати цю роботу, а бібліотеки займаються внутрішніми механізмами, серед них semanticcache, prompt-cache, GPTCache, vCache, Upstash semantic-cache та Redis з LangCache.

Економія може бути справжньою. Redis стверджує про зниження кількості викликів API на 68,8% та покращення затримки на 40–50%, хоча ці цифри частково є маркетинговими, оскільки вони отримані у сценарії простого запитання та відповіді. Результати повністю залежать від налаштувань. Бот для запитань та відповідей із багатьма зайвими викликами економить більше, тоді як агент для програмування, чиї виклики є унікальними, — менше.

Кешування запитів ефективне, коли змінюється запит у межах великого статичного шаблону, а семантичне кешування — коли люди постійно перефразовують одне й те саме запитання. 15% рівень семантичної відповідності дає лише незначну економію, але рівень понад 45–50% починає виглядати корисним.

Ці два підходи також відрізняються за тим, що може піти не так. Невдалий пошук у кеші запитів коштує лише звичайної ціни, тож така проблема є дешевою та помітною. Невдалий пошук у семантичному кеші також нешкідливий, але хибний успіх – ні: користувач отримує відповідь, написану для іншого запитання, у повній впевненості, і ніщо в журналах не позначає це. Саме через цю асиметрію семантичне кешування вимагає консервативних порогів схожості, визначення цільової аудиторії користувачів та способу перевірки результатів, тоді як кешування запитів переважно потребує суворої структуризації запитів.

Варто також згадати про звичайне кешування. Дорогі детерміністичні операції, такі як результати SQL-запитів, вихідні дані інструментів та результати пошуку, слід кешувати, щоб вони виконувалися не частіше, ніж це необхідно. Прикладом є інструмент, який збирає дані ключових слів для стиснення інформації, кешує їх до тих пір, поки вони не стануть застарілими, та запускає їх знову лише тоді, коли цей шлях використовується знову.

Семантичне кешування — це цікава концепція, яка дозволяє зберігати токени в певних сценаріях використання, але її ефективне застосування вимагає інженерних зусиль.

Не завантажуйте заздалегідь неактивні токени

Попередження системи може збільшуватися через об’ємні визначення інструментів або зростання обсягу пам’яті. Невеликі агенти цього не відчувають, але специфікації агентів, які постійно зростають, можна скоротити шляхом отримання інформації за потреби або принаймні спробою цього.

Тримайте шар, який завжди завантажується, невеликим

Коли попередження агента перевищує певний розмір, шар, який завжди завантажується, має залишатися невеликим та стабільним, а додаткові деталі слід зберігати окремо. Завантаження кількох сотень інструментів або надсилання повних описів сервера MCP, які постійно змінюються, створює зайвий шум у роботі системи.

Проблема полягає як у продуктивності, так і в витратах. Коли кожен шар постійно змінюється, кешування запитів стає значно складнішим. Верхній шар має бути компактним та стабільним, достатнім для того, щоб підказати моделі, де вона знаходиться та куди рухатися далі, не несучи з собою всієї інформації одразу.

Стверджується, що Claude Code дотримується такої схеми управління пам’яттю. Файл індексу завжди завантажується та не повинен перевищувати 200 рядків, тоді як детальні файли на теми знаходяться в іншому місці. Те, як агент поводиться на практиці порівняно з тим, що передбачено системою, — це окреме питання. Подібний підхід присутній у розширеному налаштуванні інструментів Claude, у шаровій структурі Claude Skills та у спробах використовувати інструменти MCP з запізнілим завантаженням замість того, щоб вказувати всі визначення серверів у запиті заздалегідь.

Чи це працює?

Принцип залишається незмінним: коли обсяг контексту зростає, у моделі виникають більші труднощі з вибором правильних дій. Ця галузь ще на початковому етапі розвитку, тож один конкретний інструмент демонструє, як це може функціонувати.

Кілька місяців тому Anthropic випустила розширену функцію пошуку інструментів, призначену для скорочення обсягу контексту навіть тоді, коли модель може доступатися до сотень інструментів. Компанія повідомляє, що до оптимізації обсяг визначень інструментів становив від 55K до 134K токенів, і що вибір неправильного інструменту є поширеною проблемою, коли обсяг контексту досягає таких розмірів.

Інструмент пошуку оптимізує контекст, дозволяючи ШІ шукати інструменти замість того, щоб визначати їх усі заздалегідь. Конфігурація виглядає так:

tools=[
        {
            "type": "tool_search_tool_bm25_20251119",
            "name": "tool_search"
        },
        {
            "name": "search_contacts",
            "description": "Find a contact by name or email.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"}
                },
                "required": ["query"]
            }
        },
        {
            "name": "send_email",
            "description": "Send an email to one or more recipients.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "to": {"type": "string"},
                    "subject": {"type": "string"},
                    "body": {"type": "string"}
                },
                "required": ["to", "subject", "body"]
            },
            "defer_loading": True
        }
    ]

Визначено один інструмент під назвою tool_search, який може використовувати готові опції — BM25 чи Regex, або ж власну реалізацію. Для ілюстрації один інструмент позначений як відкладений; це має сенс лише при наявності 10 або більше інструментів. Пошук виконується сервісом Anthropic, тому спосіб вставки схеми інструменту до системного запиту та сам процес пошуку залишаються непомітними. Як тільки знаходиться відповідний інструмент, його опис додається безпосередньо до розмови у вигляді блоку tool_reference.

Ідея є цікавою, адже вона забезпечує менший початковий контекст за рахунок додаткового кроку пошуку. Однак тестування з 4 000 інструментами дало досить посередні результати, тож потрібно більше випробувань. Крім того, інструменти мають бути достатньо детально описані, щоб їх можна було знайти, а виправлення помилок ускладнюється через непомітність проміжних кроків.

Ця схема зустрічається й в інших випадках під простою назвою якісної інженерії ШІ. Не піддають агента величезному, хаотичному контексту. Надайте йому можливість звузити обсяг інформації та дозвольте йому перевіряти або завантажувати інструмент лише тоді, коли це необхідно.

Економія тут залежить від кількості токенів, які надсилаються спочатку. Другий калькулятор порівнює пошук інструментів з кешуванням запитів.

Наведений вище приклад показує орієнтовну економію від кешування запитів у поєднанні з інструментами, які завантажуються за потреби. Обидва підходи приносять економію, але їх поєднання не створює значних додаткових змін порівняно з кожним окремо. Пошук інструментів — це не лише питання грошей, адже він також зберігає чистоту контексту для кращої продуктивності. Якщо говорити лише про економію, то впровадження принаймні одного з цих підходів — найкращий варіант.

Використовуйте дешеві моделі для дешевої роботи

У цьому розділі йдеться про направлення запитів до різних моделей та використання дешевших підагентів для певних завдань. Обидва підходи можуть зменшити витрати на токени, але водночас ставлять під загрозу якість. Багато хто стверджує, що 60% або навіть більше всіх надходжених запитань є простими та не вимагають найсильнішої моделі, тим більше такої, яка вміє міркувати.

Комерційні продукти вже частково реалізують ці функції. Як повідомляється, ChatGPT направляє запити на основі таких факторів, як тип розмови, складність, потреба у інструментах та чіткий намір користувача, наприклад „добре подумати“, тоді як Claude використовує делегування на основі опису разом із вбудованими підагентами, такими як Explore. Концепція є простою для розуміння; складною є її реалізація без погіршення якості. У наступному розглядаються методи прогностичного направлення та підходи з перевіркою результату, такі як каскадні процеси та підагенти, а ще один розділ присвятований оцінці економії.

Направлення за рівнем складності

Маршрутизація на рівні запиту оцінює складність та намір користувача ще до отримання будь-якого результату. Переваги цього підходу значні, але один неправильний вибір може зіпсувати всю сесію, тому якість є важливою проблемою. Якийсь модель маршрутизатора повинен вирішувати, куди направити кожен запит.

Сигнали маршрутизації від OpenAI не є публічними, і користувачі часто відчувають, що їх перенесли на менш потужну модель у незручний момент. У світі відкритого коду є більше можливостей для дослідження. RouteLLM від LMSYS, групи з Берклі, яка стоїть за Chatbot Arena, навчається на реальних даних про вподобання, зібраних у Arena. Він поєднує стандартні ембеддинги з невеликим модулем маршрутизації, що має знижувати витрати на хостинг, а його автори повідомляють про значне зниження витрат при збереженні більшості характеристик GPT-4. Це твердження ще не перевірялося незалежно.

У статті LLMRouterBench наводиться застережливий висновок: багато навчених маршрутизаторів ледве перевершують прості базові рішення, такі як маршрутизація за ключовими словами чи евристичні методи, а також маршрутизація на основі найближчого сусіда та алгоритму kNN.

Складніші маршрутизатори можуть не принести значного покращення порівняно з простими рішеннями. Люди не відмовляються від маршрутизації та продовжують експериментувати, але економія не є гарантованою, якщо якість відповідей не може відповідати високим стандартам. Існують також сервіси з хостингом, такі як OpenRouter Auto та Switchpoint, проте жоден з публічних джерел не описує їхню внутрішню структуру маршрутизації чи точність. Калькулятор порівнює LLMRouter, евристичні методи, самостійно розміщений класифікатор, LLM-as-router, RouteLLM та OpenRouter Auto. Для оцінки якості в реальних умовах необхідні належні тести з чіткими цифрами, що є абсолютно необхідним для цієї галузі.

Почніть з дешевого варіанту, переходьте на більш складні при низькій впевненості

Не намагаючись прогнозувати складність запиту на основі його опису, дешева модель може спочатку надати відповідь, а потім перевірка вирішить, чи залишити її чи перевести справу на більш потужну модель. У статті Google «Speculative Cascades» описано цей компроміс: спочатку використовуються невеликі моделі заради економії та швидкості, а більш потужні — лише тоді, коли це необхідно.

Дешева модель генерує відповідь, після чого легкий інструмент перевірки аналізує такі показники, як logprobs, ентропія чи невизначеність у стилі маржі, а також семантичну відповідність.

Цей підхід є привабливим, оскільки складність запиту важко прогнозувати, а більшість механізмів обробки не є ідеальними; водночас якість відповіді легше оцінити, коли вона вже є. Він має сенс лише тоді, коли більшість запитань можна вирішити за допомогою простішої моделі, адже у разі переходу на більш потужну модель доводиться оплачувати два виклики. Команди, які його використовують, стверджують, що час очікування між викликами може залишатися меншим за 20 мс.

Реалізація з відкритим кодом під назвою CascadeFlow стверджує, що порівняно з GPT-5 вона дозволяє досягти економії 69% при збереженні якості на рівні 96%. Однак запити, на яких її тестували, мали перевірені правильні відповіді, такі як розв’язки математичних задач та варіанти відповідей. Основна проблема полягає у тому, що невеликі моделі часто помиляються, тому доцільно починати з консервативних порогів та частіше їх підвищувати, що призводить до зростання витрат. Додавання системи послідовного оброблення за принципом «спочатку дешевше» до калькулятора дозволяє досягти економії близько 50%, за умови, що для деяких запитів все ж потрібні більші моделі.

Доручення підагентам

Підагенти доручають роботу ізольованим агентам, які іноді використовують менші моделі, тож це також є формою маршрутизації. Економія у цьому випадку менша. Крім того, важливо підтримувати чистоту контексту, щоб кожен агент міг повністю зосередитися на власному завданні.

Claude Code постачається з вбудованими підагентами. Підагент Explore є спеціалізованим працівником типу Haiku для дослідження та пошуку в кодовій базі, що ґрунтується на ідеї використання дешевших моделей для простіших завдань. Основна сесія також делегує обов’язки шляхом зіставлення описів непомітно, і користувач бачить лише знижену загальну суму рахунку. Оскільки оркестратор зазвичай бере участь у плануванні, синтезі та повторних спробах, економія виявляється меншою, ніж та, яку дає механізм маршрутизації.

Згідно з даними калькулятора, підагенти дозволяють знизити вартість порівняно з варіантом без маршрутизації приблизно на 11%, тому вони самі по собі не є основним засобом для скорочення витрат.

Зберігайте чистоту контексту

Хороше проектування контексту переважно стосується продуктивності, але воно також може впливати на витрати. З часом агенти накопичують зайві дані: застарілі спроби, старі плани, дубльовану інформацію про стан, журнали подій, повторювані спостереження та необроблені результати роботи інструментів. Ті, хто вперше створює агентів, особливо схильні до цього, оскільки постійно додають результати до робочого стану основного агента.

Це трапляється скрізь. Користувачі OpenClaw скаржаться на накопичення контексту, як і користувачі Claude Code, адже додавати дані простіше, ніж їх очищувати.

Складною частиною є канал обробки стану

Це проблема двох рівнів. Йдеться не лише про стиснення чату — нові дані також мають залишатися чистими під час входження до робочого стану, а це складна інженерна задача. Поганий підхід виглядає так: агент постійно додає необроблені результати до контексту:

bad state:
agent does work
→ dumps tool output into context
→ reads files
→ dumps files into context
→ runs tests
→ dumps logs into context
→ retries
→ keeps everything

Справжнім завданням є збереження правильного стану під час видалення зайвого матеріалу. Чистий результат може бути відправлений у архів, а лише необхідне залишається у активному контексті. Ворогом зазвичай є надмірна кількість даних, створених інструментами, тому зменшення кількості цих даних за замовчуванням є частиною роботи. Здоровіший активний контекст виглядає ось так:

Good active context

[system rules]
[project rules]
[user task]
[current working state]

Keep:
+ auth flow lives in auth.ts + session.ts
+ bug only happens on refresh path
+ failing test: session_refresh_keeps_user
+ likely overwrite during refresh
+ files in scope: auth.ts, session.ts, auth.test.ts

Drop:
- raw grep results
- full test logs
- duplicate file dumps
- dead-end retries

Деякі елементи контексту також можуть мати термін існування чи дату закінчення дії. Як тільки з’являється потреба у стисненні, стає легше визначити, що насправді потрібно ШІ.

У примітках Anthropic щодо завдань довгострокового характеру зазначається, що стиснення має зберігати архітектурні рішення, нерозв’язані баги та деталі реалізації. Автономне стиснення LangChain дозволяє агенту самостійно вирішувати, коли його застосувати, не чекаючи, поки контекст вже стане надмірно об’ємним, що, схоже, є підходом Anthropic. Команди починають розглядати стиснення як проблему системного рівня, з використанням показників ефективності та правил, специфічних для кожного агента, а не як звичайний трюк для стиснення тексту.

У нещодавній статті Jia та співавторів стверджується, що при стисненні у 6 разів було досягнуто зменшення обсягу токенів на 51,8–71,3%, а також покращення ефективності вирішення проблем на 5,0–9,2% у тесті SWE-bench Verified. Отже, йдеться не лише про економію ресурсів — це також покращує загальну продуктивність.

Видалення зайвого може ефективно очистити від 30 до 70% контексту, що дозволяє заощадити приблизно стільки ж у доларах. Для вікна контексту у 10 тисяч елементів очищення 30–50% під час 100 тисяч операцій може заощадити до 1 500 доларів, а при вікні у 40 тисяч ця сума зростає до 6 000 доларів. Засоби стиснення, які вже використовують дуже малі та дешеві моделі, можуть коштувати більше, ніж дозволяють заощадити. Проте чистий контекст не погіршує якість у такій мірі, як це може статися з семантичним кешуванням чи маршрутизацією, тож при правильному застосуванні це є явною перевагою. Проблема полягає у зусиллях, необхідних для цього.

Вибір серед них

Існує чотири способи знизити витрати на токени, і правильне поєднання залежить від конкретного випадку використання:

• Використовуйте кешування запитів із великими системними запитами, які залишаються незмінними під час багаторазових викликів ШІ.
• Використовуйте семантичне кешування для універсального бота для запитань та відповідей, який має залишатися дешевим.
• Перевіряйте маршрутизацію, коли агент має обробляти як прості, так і складні запитання.

Зберігайте контекст якомога чистішим, щоб уникнути надсилання зайвих токенів.