В Дне 2 мы управляли формой ответа. Сегодня — глубже: учимся управлять самим способом, которым модель приходит к ответу. И понимаем, почему один способ даёт 50% точности, а другой на той же задаче — 90%.
Модель отвечает на запрос, прогоняя свой внутренний процесс мышления. Этим процессом можно управлять — и от того, как ты его построишь, зависит качество ответа. Сегодня — четыре фундаментальных подхода: прямой ответ, цепочка рассуждений (Chain-of-Thought), мета-промптинг и мульти-перспективный анализ. На сложных задачах разница в точности между подходами доходит до 2-3 раз.
Когда модель отвечает «с лёту», она выдаёт первый правдоподобный ответ — тот, который статистически наиболее вероятен для такого входа. Это часто работает: «столица Франции», «синоним к слову X», «переведи на английский». Простые задачи.
Но как только задача становится сложной — требует расчёта, сравнения вариантов, проверки логики — модель, отвечая сразу, часто ошибается. Не потому что не умеет. А потому что у неё не было пространства подумать.
Хороший промпт не только говорит модели что сделать, но и задаёт как именно подойти к решению. На сложных задачах это даёт больше прироста качества, чем смена модели.
Это и есть смысл понятия «промпт-инжиниринг»: ты не просто формулируешь вопрос, ты конструируешь процесс размышления модели. Ниже — четыре фундаментальных способа это сделать.
Возьмём одну и ту же задачу и посмотрим, как меняется поведение модели на каждом подходе. Кликни по табу:
Простейший подход: задал вопрос — получил ответ. Никаких дополнительных инструкций про процесс.
Как выглядит промпт: «Сколько литров краски нужно, чтобы покрасить комнату 4×5 метров при высоте потолков 2.7 м, если краска расходуется 200 г на квадратный метр и в банке 2.5 кг? Дай число».
Что произойдёт: модель попытается посчитать в один проход. Может правильно, может с ошибкой в одном из шагов. На сложных вычислениях точность падает заметно.
Когда использовать: простые задачи, где правильный ответ очевиден за один шаг. Классификация, перевод, простое извлечение. Когда нужна максимальная скорость и минимум токенов.
Добавляешь в промпт инструкцию «реши пошагово, объясняй каждый шаг». Модель сначала проговаривает рассуждение, потом даёт финальный ответ.
Как выглядит промпт: та же задача про комнату + «Реши пошагово: сначала посчитай площадь стен, затем расход краски, затем количество банок».
Почему работает: модель генерирует токен за токеном. Когда она пишет «сначала посчитаю площадь...», у неё уже есть промежуточный результат в контексте, на который она опирается при следующем шаге. Без CoT все вычисления должны произойти «в один токен» — невозможно.
Эффект: на математических, логических, многошаговых задачах точность вырастает в полтора-два раза. Это один из самых мощных и дешёвых приёмов в промпт-инжиниринге.
Вариация: «Reasoning models» (o1, o3, Claude Sonnet с extended thinking) делают CoT автоматически внутри себя — тебе не нужно его просить, но платишь больше.
Двухшаговый подход: на первом запросе ты не просишь решить задачу, а просишь модель написать оптимальный промпт для этой задачи. На втором запросе используешь этот промпт.
Как выглядит: «Я хочу получить точный ответ на задачу про комнату [...]. Напиши мне промпт, который заставит другую LLM решить её максимально качественно. Включи в промпт нужный контекст, формат ответа и подход к решению». Получаешь промпт. Используешь его в новом запросе.
Почему работает: модели хорошо знают, что они сами хорошо понимают. Они могут описать «как лучше всего меня спрашивать» — и затем сами же лучше отвечают на оптимизированный запрос.
Эффект: особенно полезно, когда задача сложная и ты сам не уверен, как её правильно сформулировать. Это экстернализация промпт-инжиниринга — отдаёшь его модели.
Стоимость: два запроса вместо одного. На повторяющихся задачах — окупается, потому что сгенерированный промпт можно переиспользовать.
Просишь модель ответить как нескольких разных экспертов с разной перспективой, потом — синтезировать общее решение.
Как выглядит: «Ответь на эту задачу как: (а) точный математик, который проверит расчёты; (б) практик-маляр, который укажет на реальные нюансы; (в) скептик, который найдёт слабые места в твоём ответе. Затем дай итоговое решение, учитывающее все три голоса».
Почему работает: заставляешь модель посмотреть на задачу с разных углов. Каждая «роль» подсвечивает то, что не видит другая. Финальный синтез учитывает больше факторов.
Эффект: хорошо работает на задачах, где нет одного правильного ответа, а есть взвешенное решение: аналитика, стратегия, оценка рисков, продуктовые решения.
Минус: много токенов, медленно. И иногда модель «соглашается со всеми» — финальный ответ становится размытым.
На простом «сколько 2+2» все четыре подхода дадут одно и то же. На задачах посерьёзнее — расхождение огромное.
Не «один подход лучше всех». У каждого свой класс задач, где он сильнее.
Классификация, извлечение полей, перевод, простое преобразование. Когда правильный ответ — это один токен или короткая фраза, и нет «процесса».
Математика, логика, планирование, любые задачи, где есть промежуточные результаты. Самый дешёвый способ поднять качество на 30-50%.
Когда сам не понимаешь, как лучше сформулировать. Запустил мета — получил черновик промпта — допилил руками — переиспользуешь.
Стратегия, оценка, дизайн, продукт — где нет одного правильного ответа, но важно не упустить угол зрения.
Да. На сложных задачах — это норма. Например: сначала мета-промптом получаешь оптимальную формулировку, в этой формулировке требуешь CoT-рассуждения, дополнительно просишь оценку с трёх углов. Получаешь самый качественный ответ — за самые большие деньги.
Это и есть AI-инжиниринг: каждый «слой» добавляет качество, но и стоимость, и latency. Твоя задача — найти точку, где качество достаточное, а цена приемлемая.
Современные «думающие» модели (OpenAI o1/o3, Anthropic Claude с extended thinking, DeepSeek-R1) делают CoT-рассуждения автоматически внутри себя. Ты не видишь промежуточные шаги, но платишь за них как за обычный output.
Альтернатива — взять обычную модель и попросить CoT в промпте. Дешевле и быстрее. Но качество на действительно сложных задачах часто ниже, чем у reasoning-модели.
Правило: для повседневных задач (90% случаев) хватает обычной модели с CoT-инструкцией. Reasoning-модель бери, когда задача правда сложная: математические доказательства, сложный код, аналитика данных, головоломки.
Когда модель рассуждает в открытую — пользователь видит весь поток мысли. Это иногда полезно (видно, как принято решение), иногда — лишнее (длинно, замусоривает интерфейс).
Решение: попросить модель завершать ответ тегированной финальной частью — например, «после рассуждения дай ответ в теге <result>...</result>». Твой код извлекает только финал, рассуждения можно логировать, но не показывать.
«Реши пошагово» в задаче «классифицируй настроение отзыва как positive/negative» — лишний оверхед. CoT занимает токены и время. Если задача решается одним токеном — пусть и решается одним.
Правило: CoT — для задач, где есть промежуточные шаги, которые модели нужно где-то «положить». На атомарных задачах он бесполезен.
Подход с экспертами выглядит впечатляюще («модель сама себя проверила!»), но на технических задачах с одним правильным ответом — он чаще запутывает, чем помогает. Каждый «эксперт» может тянуть в свою сторону, итоговый синтез превращается в компромисс ради компромисса.
Экспертов используют, когда правильного ответа нет — есть выбор из приемлемых, и важна полнота охвата перспектив.
Модель порассуждала, в конце выдала число. Ты автоматически берёшь последнюю строку и считаешь её ответом — но иногда модель добавляет постскриптум, или ответ оказывается в середине, а конец — это уточнение.
Лечение: всегда требуй разделитель. «После рассуждения дай ответ в формате FINAL: число» или в теге <answer>...</answer>. Парсер ищет маркер, не «последнюю строку».
Возьми задачу типа: «Поезд идёт из А в Б со скоростью 60 км/ч, обратно — 40 км/ч. Расстояние 120 км. Какая средняя скорость на всём пути?» (Подсказка: ответ — не 50). В плейграунде задай её обычной модели без CoT — получишь, скорее всего, неправильный ответ (50 км/ч — частая ошибка). Затем — с инструкцией «реши пошагово, объясни каждый шаг». Сравни.
Возьми задачу, в которой ты сам не уверен в формулировке — например, «помоги составить план изучения новой технологии для меня». Сначала спроси напрямую — получишь общий, бесполезный ответ. Затем попроси: «Я хочу составить план изучения X. Напиши промпт, который заставит другую LLM дать мне реально полезный, индивидуальный план. Включи, какие уточнения у меня нужно собрать заранее». Используй полученный промпт в новом запросе. Заметишь разницу в качестве.
Возьми любую свою идею (бизнес, проект, решение). Попроси: «Оцени эту идею с трёх позиций: (а) оптимистичный венчурный инвестор, который ищет потенциал; (б) циничный аналитик, который ищет проблемы; (в) пользователь, на которого это рассчитано. Затем — синтез». Сравни, насколько глубже получился разбор по сравнению с обычным «оцени мою идею».