Почему хороший промпт подозрительно похож на техническое задание и где заканчивается prompt engineering, а начинается настоящая работа с LLM
Без temperature, context window, system prompt и прочих слов, после которых человек вполне справедливо решает, что проще уже сделать всё самому.
Я сказал примерно так: «Сформулируй, что тебе нужно. Объясни, каким должен быть результат. Если есть ограничения, напиши их сразу. Не сваливай пять разных задач в одну. И не заставляй модель угадывать то, что существует только у тебя в голове».
На всё ушло минут пять.
А потом я понял, что почти дословно пересказал KERNEL, один из фреймворков для написания промптов.
Это сначала показалось забавным. Потом возник вопрос поинтереснее: если базовый prompt engineering действительно можно объяснить человеку за пять минут, что именно становится сложным, когда LLM переезжает из вкладки браузера в реальный продукт?
Спойлер: сам промпт оказывается только началом.
KERNEL подозрительно похож на то, что разработчики делали и до ChatGPT
KERNEL расшифровывается довольно просто.
K, Keep it simple: одна понятная цель вместо романа в трёх томах.
E, Easy to verify: должно быть понятно, как проверить результат.
R, Reproducible results: требования нужно задать так, чтобы поведение модели можно было сравнивать между запусками.
N, Narrow scope: не смешивать несколько независимых задач без необходимости.
E, Explicit constraints: ограничения лучше написать прямо.
L, Logical structure: контекст, задача, ограничения и формат ответа не должны лежать одной бесформенной кучей.
KERNEL не стандарт OpenAI или Anthropic и не академическая методология. Он появился как community-framework. Автор исходной публикации писал, что сформулировал эти правила после анализа более тысячи рабочих промптов.
В том же посте он приводит результаты собственных тестов: first-try success после применения KERNEL вырос с 72% до 94%, расход токенов снизился на 58%, а время до полезного результата на 67%. Цифры выглядят эффектно, но принимать их за доказанную эффективность KERNEL я бы не стал: автор не публикует полный набор тестов и методику, по которой их получил. Поэтому дальше мне интереснее проверить сам принцип, а не проценты.
И вот тут начинается самое любопытное: если вы хотя бы раз нормально писали техническое задание, большая часть KERNEL покажется до обидного знакомой.
Возьмём простой запрос:
Посмотри этот Python-код, найди проблемы и улучши его.
Человеку он кажется понятным. Мы примерно знаем, что значит «проблемы»: баги, безопасность, производительность, архитектура, читаемость.
У модели нет этого «примерно».
Поэтому запрос лучше выглядит так:
Проведи code review приложенного Python-модуля. Ищи ошибки, которые могут привести к падению приложения, потенциальные security issues и очевидные проблемы производительности. Архитектуру проекта целиком не пересматривай. Для каждой найденной проблемы укажи участок кода, причину, критичность и минимальное исправление. Не включай замечания, которые нельзя подтвердить по переданному коду. Ответ верни в структурированном виде.
Никакой магии здесь не произошло. Мы просто перестали перекладывать половину требований на телепатию модели.
Именно поэтому KERNEL мне и нравится. Он хорошо приземляет весь разговор про prompt engineering.
Хороший промпт всё чаще выглядит не как специальный язык общения с искусственным интеллектом, а как нормально поставленная задача.
«Ты лучший программист мира» можно оставить в прошлом
У prompt engineering долго была слегка алхимическая репутация.
«Представь, что ты эксперт с двадцатилетним опытом».
«Думай шаг за шагом».
«За хороший ответ я дам тебе 200 долларов».
«От этого зависит моя карьера».
Какие-то такие приёмы действительно могли менять поведение отдельных моделей. Проблема начиналась в момент, когда локальный трюк превращался в универсальный закон.
Сейчас это особенно заметно на reasoning-моделях. Современные модели уже умеют выполнять внутреннее рассуждение, поэтому добавленная вручную команда «думай шаг за шагом» сама по себе не гарантирует улучшения результата.
На этом фоне скучный KERNEL выглядит даже освежающе.
Не надо убеждать модель, что она гений.
Лучше нормально поставить задачу.
С буквой R начинается самое интересное
Самое спорное место KERNEL для технической аудитории, на мой взгляд, это Reproducible results.
Потому что «воспроизводимый результат» и LLM рядом звучат подозрительно.
Если понимать это как:
одинаковый input → всегда одинаковый output
то нет.
Генеративные модели вариативны. Даже при одинаковом запросе ответы могут отличаться, а обновление самой модели способно изменить поведение системы без единой правки вашего промпта.
Поэтому R я бы трактовал иначе.
Не воспроизводимый ответ, а воспроизводимые требования.
Сегодня наш reviewer проверяет три класса ошибок и возвращает четыре конкретных поля. Завтра он делает то же самое. Через месяц тоже. Мы можем сравнить версии модели, промпта и всей системы, потому что хотя бы понимаем, что именно проверяем.
В личном чате разница кажется академической. В production она очень быстро становится практической.
Допустим, мы переписали промпт для code review. Новый ответ выглядит убедительнее старого. Формулировки точнее. Замечаний больше.
Можно выкатывать?
Если единственный аргумент звучит как «по ощущениям стало лучше», у нас пока нет теста.
«Кажется, стало лучше» плохо переживает production
Представим набор из ста фрагментов кода. В части есть реальные runtime bugs, где-то спрятаны security vulnerabilities, где-то проблемы производительности, а часть кода полностью корректна.
Теперь модель можно проверять уже не по настроению.
Нашла ли она известную ошибку? Придумала ли уязвимость там, где её нет? Правильно ли определила критичность? Соблюла ли формат ответа? Не решила ли заодно переписать полпроекта, хотя её об этом никто не просил?
Вот здесь появляются evals.
Если объяснять совсем просто, evals — это заранее подготовленные проверки, на которых можно измерить, стало поведение модели лучше или хуже после изменения промпта, версии модели или логики системы.
И в этот момент фраза «этот промпт хороший» становится слишком расплывчатой.
Гораздо полезнее знать, что на вашем тестовом наборе новая версия находит больше реальных ошибок и при этом не увеличивает количество ложных срабатываний.
Тут prompt engineering уже начинает становиться инженерией в буквальном смысле.
Часть промпта рано или поздно лучше перенести в код
Вернёмся к нашему code review.
Допустим, модель должна возвращать номер строки, категорию ошибки, критичность, описание и исправление. Можно написать в промпте: «Верни JSON».
Для прототипа этого часто хватает.
Но если этот JSON затем читает другой сервис, уже не хочется надеяться на хорошее воспитание модели. Контракт ответа лучше закрепить программно через схему.
И это важный момент.
Мы начинали с идеи, что нужно написать идеальный промпт. Потом выяснили, что часть ответственности разумнее забрать у него и реализовать на уровне приложения.
Так и должно быть.
Чем ближе LLM к production, тем меньше хочется решать архитектурные проблемы красивыми формулировками.
Один хороший промпт на разных моделях живёт по-разному
Есть ещё одна вещь, которую KERNEL сам по себе не решает.
Выбор модели.
Можно идеально сформулировать задачу и отправить один и тот же prompt в GPT, Claude, Gemini или другую LLM. Результаты всё равно будут отличаться.
У моделей разные сильные стороны. Они по-разному работают с кодом, длинным контекстом, сложными инструкциями и инструментами. Отличаются скорость, стоимость, ограничения и стабильность формата.
Поэтому вопрос «какая LLM умнее?» почти всегда слишком общий.
Гораздо полезнее спросить: какая модель лучше справляется именно с моей задачей и моими критериями?
Для code review я бы смотрел на найденные реальные баги, false positives, соблюдение формата, скорость и стоимость. Для extraction будут другие метрики. Для агента с tool calling третьи.
Я периодически проверяю такие вещи в SYNTX.AI, потому что там несколько LLM можно гонять из одного пространства, не прыгая между отдельными сервисами. Для таких сравнений это удобно: берёшь один prompt, один набор примеров и смотришь, насколько результат меняется вместе с моделью.
И здесь важнее не количество логотипов в каталоге, а сам подход. Модель становится ещё одной переменной эксперимента.
А потом KERNEL заканчивается
Допустим, хороший промпт готов. Критерии определены. Несколько моделей проверены. Evals есть.
Для некоторых задач этого вполне достаточно.
Но представим внутреннего AI-ассистента компании. На один ответ ему могут понадобиться системные инструкции, вопрос пользователя, документы из RAG, история диалога, права доступа, результаты предыдущих tool calls и состояние текущей задачи.
Фраза «напишите хороший промпт» здесь уже описывает слишком маленькую часть работы.
Допустим, инструкция идеальна:
Отвечай только на основании внутренней документации.
Retrieval при этом вернул документ трёхлетней давности.
Никакой KERNEL не спасёт.
Или агенту сказали запрашивать подтверждение перед опасным действием, но описание инструмента написано настолько мутно, что модель вызвала не тот action.
Снова промпт оказался крайним совершенно зря.
Или в context window загрузили огромную историю переписки, документацию, результаты инструментов и пару сотен килобайт «на всякий случай», а потом удивились, что модель пропустила нужную деталь.
Это уже территория context engineering.
Prompt engineering отвечает на один вопрос. Context engineering на другой
Если сильно упростить, prompt engineering занимается тем, как сформулировать задачу.
Context engineering — тем, что именно модель должна знать в момент, когда эту задачу выполняет.
Разница кажется небольшой, пока вы работаете в обычном чате. В агентной системе она становится огромной.
Там приходится решать, какие документы доставать через RAG, что оставлять в истории, какие результаты инструментов передавать дальше, что выкидывать из контекста и какие данные вообще нельзя показывать модели.
Поэтому рабочая LLM-система быстро перестаёт выглядеть так:
prompt → answer
И начинает выглядеть примерно так:
instructions → context → model → tools → state → evals → application logic
KERNEL всё ещё находится внутри этой цепочки. Просто уже не пытается описать её целиком.
И всё-таки я бы оставил KERNEL
После всего этого можно решить, что простая формула из шести букв нам больше не нужна.
У меня получилось наоборот.
Потому что огромное количество запросов ломается намного раньше evals, RAG и tool calling.
Они выглядят примерно так
Изучи данные, найди проблемы, предложи улучшения, придумай стратегию и подготовь презентацию для руководства.
Что считать проблемой? Какие данные важнее? Как проверить выводы? Что именно нужно улучшить? Кто увидит презентацию? Насколько подробно всё объяснять?
Модель должна решить это сама, а потом ещё угадать, какой из возможных вариантов автор запроса держал в голове.
После этого появляется классическое:
«Что-то сегодня нейросеть тупит».
Иногда тупит.
А иногда мы просто выдали ей техническое задание уровня «сделай хорошо».
KERNEL полезен хотя бы как короткая проверка перед отправкой запроса: понятна ли задача, есть ли критерий результата, не расползся ли scope, названы ли ограничения и ясно ли, в каком виде ждать ответ.
Для бытовой работы этого часто хватает.
В production поверх этого появляются тесты, контроль структуры, правильный контекст, инструменты и выбор модели.
Для читателей Хабра у SYNTX.AI есть промокод CTRLAI со скидкой 20% на любой тариф. Если захочется проверить идею статьи на своих задачах, я бы использовал его именно для сравнения нескольких LLM на одном и том же рабочем сценарии. Один prompt, один набор примеров, разные модели. Очень быстро становится видно, где проблема была в постановке задачи, а где уже в самой модели.
К KERNEL я пришёл довольно скептически. Ещё один акроним для prompt engineering звучал как последний кандидат на то, чтобы меня чем-то удивить.
Но одна мысль после него всё-таки осталась.
Машина может довольно точно выполнить то, что вы ей сказали.
И иногда главная проблема начинается в тот момент, когда выясняется, что сказали вы совсем не то, что имели в виду.
ссылка на оригинал статьи https://habr.com/ru/articles/1068654/