Разработка приложений на базе больших языковых моделей (LLM) часто начинается с наивного подхода к формированию контекста. Разработчик берет системные бизнес-правила, склеивает их с пользовательским вводом и отправляет единой текстовой строкой в API. На этапе прототипа это работает. Но при выходе в продакшен такая архитектура неизбежно приводит к утечке критических данных, компрометации бизнес-логики и превращению бота в послушный инструмент злоумышленника.

Запуск LLM-ботов часто сопровождается эйфорией, которая длится ровно до получения первого счета от API-провайдера. Команды фокусируются на качестве системных промптов и задержке (latency), упуская из виду механику потребления ресурсов. Когда пользователь отправляет пятидесятое сообщение в чат, вы платите не за него. Вы платите за всю историю сессии, переотправленную заново. Если не внедрить жесткую обрезку контекста (truncation), безобидное «спасибо» в конце долгого диалога обходится проекту…

Бизнес запускает нейросеть в продакшен. Первые три дня команда празднует: бот отвечает на вопросы клиентов, пишет письма, генерирует код. На четвертый день выходит обновление продукта. Бот продолжает уверенно рассказывать старые условия тарифов. Клиенты злятся. Руководство требует: «Научите его новым правилам. Загрузите в него свежий прайс-лист».

Мы все попались на эту маркетинговую удочку. Сначала 32k казались роскошью, затем 128k стали новой нормой, а сегодня вендоры уверенно заявляют о миллионе токенов в контекстном окне. Реакция индустрии была предсказуема: зачем строить сложные пайплайны поиска, настраивать векторные базы данных (RAG) и подбирать алгоритмы семантического чанкинга? Можно просто сгрузить весь репозиторий, документацию фреймворка и логи за последний месяц в один промпт и написать: «Где баг? Сделай всё хорошо».