Создание по-настоящему работающих ИИ-приложений — это не столько искусство составления идеальных промптов, сколько контроль над информацией, которую вы подаете в модель. Если вы когда-нибудь вели долгий диалог с ассистентом и вдруг понимали, что он забыл что-то, сказанное десять минут назад, вы уже ощутили на себе последствия ошибок в проектировании контекста (context engineering). Легко предположить, что у ИИ плохая память. На самом деле вы просто столкнулись с жесткими ограничениями контекстного окна.

Чтобы создавать надежные и отзывчивые системы, необходимо понимать три основы: токены, контекстные окна и разницу между контекстом и памятью.

Токены — это настоящая валюта

Токен — это не слово. Когда вы отправляете текст модели, токенизатор разбивает его на более мелкие части. Короткие распространенные слова, такие как «cat» или «the», могут занимать один токен. Сложный технический термин, вроде «internationalization», разбивается на несколько. Знаки препинания, пробелы и специальные символы тоже учитываются. Это важно, потому что токены определяют всё: ваш счет за API, скорость ответа и качество результата.

Разработчик, который планирует расходы, подсчитывая слова, действует вслепую. Промпт из ста слов, заполненный программными скобками и длинными именами переменных, может раздуться гораздо сильнее, чем ожидалось. Вот почему токенизаторы существуют как отдельные инструменты. Прежде чем выпускать фичу, прогоните типичные полезные нагрузки (payloads) через один из них. Вы часто будете обнаруживать, что системные инструкции, шаблонное форматирование и история чата съедают больше бюджета, чем сам запрос пользователя. Относитесь к токенам как к дефицитному ресурсу с первого же дня.

Контекстное окно — это фиксированная маркерная доска

Контекстное окно — это общий объем информации, который модель может видеть в рамках одного запроса. Представьте его в виде маркерной доски фиксированного размера. Вы можете заполнить её системными правилами, историей разговора, извлеченными документами и текущим вопросом. Но как только поверхность будет полностью занята, что-то должно уступить место. Старые заметки придется стереть, сфотографировать и резюмировать, иначе доска просто переполнится.

Современные модели рекламируют контекстные окна объемом от нескольких тысяч до сотен тысяч токенов. Велик соблазн воспринимать большое окно как безграничное хранилище. Но это не так. У доски всё равно есть края. Когда история превышает лимит, приложение должно либо отбрасывать старые сообщения, либо сжимать их. Понимание этого ограничения поможет вам перестать относиться к окну как к базе данных и начать воспринимать его как активное рабочее пространство.

Контекст — это не память

Вот различие, на котором спотыкаются даже опытные разработчики. Сама модель не имеет состояния (stateless). Она не помнит вас со вчерашнего дня, с прошлой недели или с того, что вы говорили десять минут назад в другой сессии. Когда ИИ, кажется, вспоминает, что вы предпочитаете Python вместо JavaScript или любите краткие ответы, эта память находится на уровне приложения, а не модели.

Приложение сохраняет эти факты в базе данных, кэше или хранилище памяти. При каждом новом запросе оно снова внедряет соответствующие данные профиля в промпт. Модель просто читает сценарий, в который включены её реплики из первого акта. У неё нет постоянного «я». Как только вы осознаете это различие, ваша архитектура изменится. Вы перестанете просить модель «вспомнить» и начнете проектировать системы, которые извлекают нужный контекст в нужное время.

Почему избыток контекста может навредить

Здравый смысл подсказывает, что больше фоновой информации должно приводить к лучшим ответам. Часто происходит наоборот. Избыточный контекст создает шум. Если вы передадите модели всю кодовую базу, когда нужно исправить всего одну функцию, вы заставите её искать сигнал в статическом шуме. Исследователи выявили эффект «Lost in the Middle» (потеря в середине): модели часто уделяют больше внимания деталям в начале и в конце промпта, в то время как информация, погребенная в центре, размывается или игнорируется. Это не баг, который можно исправить хитрой формулировкой. Это структурная особенность архитектур на базе трансформеров.

Раздутые промпты также бьют по самому больному. Каждый дополнительный токен требует вычислений. Задержка (latency) растет. Расходы увеличиваются. Терпение пользователя иссякает. Промпт, набитый нерелевантными документами, вносит противоречия, отвлекает модель второстепенными деталями и повышает вероятность того, что ответ зациклится на неверной проблеме. Объем — враг точности.

Как проектировать лучший контекст

Качественное проектирование контекста — это упражнение в беспощадном редактировании. Вот как применить это на практике.

Отправляйте только то, что требуется для выполнения задачи. Если пользователь спрашивает о политике возврата средств, не нужно включать руководство для сотрудников, документацию API и маркетинговые материалы за прошлый квартал. Релевантность важнее полноты.

Используйте RAG для поиска релевантных документов. Retrieval-Augmented Generation позволяет искать по обширной базе знаний и вставлять в промпт только наиболее подходящие фрагменты. Вместо того чтобы закидывать в окно контекста тысячестраничное руководство, вы создаете эмбеддинги ваших документов, выполняете семантический поиск по запросу пользователя и включаете три наиболее подходящих абзаца. Модель получает именно то, что ей нужно, а ваш бюджет токенов остается в сохранности.

Резюмируйте старые диалоги. Полные транскрипты чатов обходятся дорого и создают лишний «шум». Заменяйте длинную историю сообщений краткими резюме. Например, вместо того чтобы скармливать модели тридцать сообщений из переписки, сохраните один абзац: «Пользователь спрашивал о развертывании Django, столкнулся с ошибкой статических файлов и исправил права доступа. Текущая проблема — сбой миграции базы данных на Postgres 14». Такое резюме сохраняет состояние системы, не загромождая «доску».

Отделяйте долгосрочную память от активного чата. Предпочтения пользователя, настройки проекта и история аккаунта должны храниться во внешнем хранилище памяти. Делайте к этому хранилищу выборочные запросы. В текущем окне контекста должна находиться только непосредственная задача и кратчайший личный контекст, необходимый для поддержания непрерывности диалога.

Контролируйте использование токенов в продакшене. Скачки задержки (latency) часто напрямую связаны с раздуванием контекста. Настройте оповещения, когда запросы приближаются к лимиту вашей модели. Анализируйте логи, чтобы выявить промпты, содержащие «мертвый груз». Оптимизация всегда начинается с одного и того же вопроса: что мы можем удалить, не нарушив выполнение задачи?

Главный вывод

Лучшие ИИ-приложения побеждают не потому, что у них самые большие окна контекста. Они побеждают, потому что дисциплинированно управляют контекстом. Огромная доска бесполезна, если она исписана каракулями. Создавайте системы, которые извлекают, резюмируют и фильтруют информацию. Ваши пользователи будут получать ответы быстрее, затраты на инфраструктуру останутся предсказуемыми, а ваши модели, наконец, начнут обращать внимание на то, что действительно важно.

Источник: AI Context Engineering: Tokens, Context Windows, & Memory

Сообщество: GyaanSetu AI on Telegram