Почему эпоха промпт-инженерии закончилась
От “как говорить” к “что показать” – игра изменилась.
Промпт-инженерия как профессия
В 2023 году появилась новая профессия.
Промпт-инженер.
“Думайте пошагово.” “Вы – эксперт с 20-летним опытом.” “Позвольте сначала показать несколько примеров.”
Такие фразы стали ноу-хау стоимостью в десятки тысяч долларов. Один и тот же вопрос давал кардинально разные ответы от ИИ в зависимости от формулировки.
Промпт-инженерия действительно работала. Одна строка Chain-of-Thought повышала математические баллы на 20%. Одно предложение с назначением роли меняло глубину экспертизы. Три примера few-shot давали полный контроль над форматом вывода.
Это не было хайпом. Это было реальностью. Так почему это заканчивается?
Почему это работало: Потому что модели были достаточно глупы
Посмотрите на причину работоспособности промпт-инженерии с позиции первых принципов. Это просто.
Ранние LLM плохо улавливали намерение пользователя. Скажите “резюмируйте” – и они переписывали. Скажите “сравните” – и они перечисляли.
Поскольку модель неверно считывала намерение, навык точной передачи намерения стал ценным. Промпт-инженерия была по сути “переводом” – преобразованием человеческого намерения в форму, понятную LLM.
Чтобы перевод имел ценность, должен существовать языковой барьер.
Что изменилось: Модели поумнели
От GPT-3.5 к GPT-4. От Claude 2 к Claude 3.5. С каждым поколением способность моделей улавливать намерение драматически возрастала.
Скажите “резюмируйте” – и они резюмируют. Скажите “сравните” – и они сравнивают. Даже без указания “думать пошагово” они самостоятельно разбивают сложные задачи на шаги.
Языковой барьер стал ниже. Ценность перевода сократилась.
Техники промптов, дававшие драматические различия в 2023 году, дают лишь маргинальные различия в 2025. Когда модель достаточно умна, формулировка значит всё меньше.
Так что тогда значит?
Контекстное окно: Закон физики
У LLM есть одно физическое ограничение.
Контекстное окно.
Будь то 128K токенов или 1M токенов – оно конечно. Только информация, помещающаяся в это конечное пространство, влияет на рассуждение. Информация за пределами окна, какой бы важной она ни была, всё равно что не существует.
Это не зависит от размера модели. Даже с триллионом параметров контекстное окно конечно. Даже при обучающих данных, охватывающих весь интернет, контекстное окно конечно.
Какой бы умной ни была модель, если в контекст попадает неверная информация – она выдаёт неверные ответы. Если нерелевантная информация заполняет контекст – она упускает важное. Если нужная информация отсутствует в контексте – она как бы неизвестна.
Промпт-инженерия была проблемой “как говорить”. Новая игра – проблема “что показать”.
Это контекст-инженерия.
Аналогия: Экзамен с открытой книгой
Вот аналогия для различия между промпт-инженерией и контекст-инженерией.
Промпт-инженерия – это хорошо составить вопросы экзамена. Вместо “выберите правильный ответ ниже” напишите “выведите пошагово ответ, удовлетворяющий всем следующим условиям” – и студент даст лучший ответ.
Контекст-инженерия – это вопрос о том, какие книги вы приносите на экзамен с открытой книгой. Как бы хорошо ни были составлены вопросы, если студент принёс не те книги, он не может ответить. Количество книг, которые можно принести, ограничено. Какие книги вы приносите – определяет вашу оценку.
Когда модель была глупой, формат вопроса (промпт) имел значение. Когда модель умна, справочный материал (контекст) имеет значение.
Эпоха агентов ускоряет сдвиг
Этот сдвиг ускоряется с появлением агентов.
Промпт-инженерия пишется людьми каждый раз. Люди пишут вопрос, люди объясняют контекст, люди указывают формат.
Агенты устроены иначе. Агенты рассуждают самостоятельно, вызывают инструменты и взаимодействуют с другими агентами. На каждом шаге они должны сами формировать контекст.
Агент вызвал внешний API и получил данные. Эти данные должны попасть в контекст для следующего раунда рассуждений. Какие части включить, а какие оставить? Какие предыдущие результаты рассуждений сохранить, а какие отбросить? Можно ли доверять информации, отправленной другим агентом?
Человек не может принимать все эти решения каждый раз. Чтобы агенты работали автономно, формирование контекста должно быть автоматизировано.
Промпт-инженерия была человеческим навыком. Контекст-инженерия должна быть системной способностью.
Промпт-инженерия не исчезает
Предотвратим недоразумение.
Я не говорю, что промпт-инженерия теряет смысл. Системные промпты по-прежнему важны. Спецификация формата вывода по-прежнему необходима. Объявление ролей и ограничений по-прежнему эффективно.
Что сокращается – это доля, которую занимает промпт-инженерия.
Если в 2023 году 70% качества вывода определялось промптом, то в 2025 году 30% определяется промптом и 70% – контекстом.
Пропорция перевернулась.
И эта тенденция не развернётся. Модели продолжат умнеть, и чем умнее они становятся, тем меньше значит формулировка и тем больше значит контекст.
Но у контекст-инженерии нет инфраструктуры
Вот суть проблемы.
У промпт-инженерии были инструменты. Шаблоны промптов, библиотеки промптов, фреймворки тестирования промптов. Целая экосистема для систематического управления “как говорить” была построена.
У контекст-инженерии этого пока нет.
Посмотрите, как контекст обрабатывается на практике прямо сейчас.
Размеры чанков пайплайнов RAG настраиваются вручную. Фоновая информация записывается в системные промпты вручную. Что хранить в памяти агента – проектируется вручную. Какие результаты поиска поместить в контекст – решается вручную.
Всё вручную.
И сырьё для всей этой ручной работы – естественный язык. Документы на естественном языке разрезаются на естественном языке и вставляются в контекст на естественном языке.
У естественного языка низкая информационная плотность. Нет источников. Нет уровней достоверности. Нет временных меток. Ненужные токены тратятся на передачу того же смысла. Нет способа автоматизировать оценку качества.
Это напоминает до-промпт-инженерную эпоху. Промпт-инженерия тоже была ручной в начале. Она опиралась на индивидуальную интуицию и опыт. Потом появились инструменты и методологии, и она систематизировалась.
Контекст-инженерия сейчас на той предшествующей стадии. Проблема осознана, но инфраструктуры нет.
Что нужно инфраструктуре
Чтобы контекст-инженерия перешла от ручной работы к системе, необходимо как минимум следующее.
Сжатие. Способ вместить больше смысла в то же окно. Уберите грамматический клей естественного языка и оставьте только смысл – и эффективный размер окна умножается – без изменения модели.
Индексация. Способ точно найти нужную информацию. Поиск на основе семантической структуры, а не сходства эмбеддингов. Поиск, при котором запрос “выручка Apple” не вытягивает “пищевую ценность яблока”.
Валидация. Способ механически отклонять информацию, не соответствующую спецификации. Подобно тому как компилятор Go ловит неиспользованные переменные как ошибки, утверждения без источников и факты без временных меток должны отфильтровываться до попадания в контекст. Самые дешёвые и детерминированные проверки должны идти первыми.
Фильтрация. Способ оценить семантическое качество. Если валидация смотрит на форму, фильтрация смотрит на содержание. Релевантность, надёжность, свежесть. Действительно ли эта информация нужна для данного раунда рассуждений?
Согласованность. Способ гарантировать внутреннюю непротиворечивость выбранного набора информации. Информация, хорошая по отдельности, может противоречить друг другу при объединении. Если генеральный директор 2020 года и генеральный директор 2024 года одновременно попадают в контекст, LLM приходит в замешательство.
Композиция. Способ оптимизировать размещение и структуру внутри окна. Одна и та же информация получает разные веса внимания в зависимости от расположения. В начале или в конце? Как она сгруппирована?
Накопление. Способ для системы учиться и расти со временем. Кэширование – это повторное использование отдельных результатов. Накопление – это изучение того, какие композиции контекста дали хорошие результаты, и рост самой базы знаний.
Эти семь элементов составляют полный стек инфраструктуры контекст-инженерии.
Это не о каком-то конкретном инструменте
Буду откровенен.
Кто построит эту инфраструктуру – открытый вопрос. Один инструмент может решить всё, или несколько инструментов могут обрабатывать по одному слою каждый.
Но то, что инфраструктура необходима, – не открытый вопрос.
Что контекстное окно конечно – физический факт. Даже если окно вырастет в 10 раз, мировая информация растёт быстрее. Что у естественного языка низкая информационная плотность – структурный факт. Что агентам нужно автоматизированное управление контекстом для автономной работы – логическая необходимость.
Как промпт-инженерии были нужны инструменты, контекст-инженерии нужны инструменты. Но на этот раз природа инструментов другая.
Инструменты промпт-инженерии были ближе к текстовым редакторам. Инструменты контекст-инженерии ближе к компиляторам.
Сжать информацию, проиндексировать, валидировать, отфильтровать, проверить согласованность, оптимизировать размещение и накопить результаты. Это не редактирование. Это инженерия.
Вот почему это называется контекст-“инженерия”.
Резюме
Промпт-инженерия была ценна, когда модели были глупы. Поскольку модели не считывали намерение, навык хорошо передать намерение имел значение.
По мере того как модели умнели, игра менялась. От “как говорить” к “что показать”. От промпта к контексту.
Появление агентов ускоряет этот сдвиг. Люди не могут собирать контекст каждый раз. Система должна делать это сама.
Но сейчас у контекст-инженерии нет инфраструктуры. Естественный язык разрезается и вставляется вручную.
Необходимая инфраструктура имеет семь слоёв: сжатие, индексация, валидация, фильтрация, согласованность, композиция, накопление.
Заканчивается не эпоха промпт-инженерии. Заканчивается эпоха, когда одной промпт-инженерии было достаточно.