Паттерны промпт-инжиниринга для backend-разработчика

Паттерны промпт-инжиниринга для backend-разработчика

Зачем разработчику инженерный подход к промптам

LLM проник в ежедневный цикл: генерация кода, ревью, описание API, рефакторинг, помощь с миграциями. Промпт - это интерфейс к этой системе, и работа с ним должна быть такой же дисциплинированной, как работа с любым другим API.

Промпт-инжиниринг - не «секретные слова», не магия и не «опыт интуиции». Это набор переиспользуемых паттернов с известными плюсами, минусами и областью применения. Их можно изучить, выбрать подходящий под задачу и комбинировать - точно так же, как GoF-паттерны в коде.

Этот урок даёт ровно ту структуру, которая нужна инженеру: что использовать в каком случае, чего лучше избегать, как промпт встраивается в систему.

Базовые паттерны: формулировка задачи

Zero-shot - простой инструктаж

Дать модели задачу одной формулировкой, без примеров.

Переведи следующий русский текст на английский.
Текст: "Привет, мир"

Когда работает: задача общая, знакомая модели, формат ответа предсказуем.

Когда не работает: нестандартный домен, тонкие требования, специфический формат вывода. Без примера модель додумывает, как именно «надо», и попадает не туда.

Анти-паттерн: «сделай хорошо», «оптимизируй», «отрефактори». Эти инструкции невыполнимы - модель не знает критерия. Замените на «сократи функцию до ≤ 20 строк, сохрани сигнатуру и тесты».

Few-shot - инструктаж с примерами

Та же инструкция, но с 2-5 парами вход → выход.

Переведи на эсперанто.

Вход: "Привет"
Выход: "Saluton"

Вход: "Спасибо"
Выход: "Dankon"

Вход: "До свидания"
Выход: ?

Когда работает: нестандартный формат, специфический стиль, узкий домен. Примеры дают модели «настройку» лучше, чем многословная инструкция.

Сколько примеров достаточно: обычно 3-5. Меньше - модель не уловит паттерн. Больше - перегруз контекста, экспоненциальный рост стоимости запроса.

Подводный камень: примеры формируют не только формат, но и набор ошибок. Если в одном из примеров есть опечатка - модель решит, что это часть стиля, и будет её воспроизводить.

In-Context Learning - обучение в моменте

Расширенная версия few-shot: примеры подаются с пояснениями, иногда с правилом, выведенным из них.

Правило: для отрицания добавляем "ne-" перед глаголом.
Пример 1: "идти" → "ne-идти"
Пример 2: "видеть" → "ne-видеть"

Задача: образуй отрицание от "знать".

Модель не «учится» в смысле обновления весов - но в рамках одной сессии следует выведенному правилу.

Когда применять: задачи с явной логикой, которую можно сформулировать одной фразой. Если правило сложное и многоуровневое - переходи к Chain-of-Thought.

Рассуждение и декомпозиция

Chain-of-Thought (CoT) - заставить модель рассуждать вслух

Просите модель показать ход рассуждений перед ответом. Магическая фраза: «Подумай шаг за шагом» / «Let's think step by step».

В корзине 5 яблок. Я отдал 2, потом купил ещё 3.
Сколько яблок в корзине? Подумай шаг за шагом.

Модель отвечает не сразу финальной цифрой, а сначала разворачивает рассуждение: «было 5, отдали 2 → осталось 3, купили 3 → стало 6». Это резко уменьшает ошибки на задачах с арифметикой, логикой, многошаговым выводом.

Почему работает: без CoT модель «прыгает» к ответу, сокращая внутренние шаги вывода. Просьба развернуть рассуждение запускает более полную цепочку токенов, где ошибка на одном шаге не отравляет финальный ответ.

Где применять для backend-задач:

• «Проанализируй вот этот SQL-запрос - почему он медленный? Подумай шаг за шагом»
• «Какие у этой схемы JSON могут быть проблемы с обратной совместимостью? Разбери шаг за шагом»
• «Этот код упал с паникой. Какие есть гипотезы? Перечисли в порядке вероятности»

Self-Consistency - несколько ответов, выбор большинством

Запустить CoT не один раз, а несколько (5-10), получить разные рассуждения и финальные ответы, выбрать наиболее частый.

Стоит дороже в N раз, но повышает точность на сложных задачах с одним правильным ответом (математика, логика).

Когда применять: критичные задачи, где одиночный ответ ненадёжен. Например, бинарная классификация в production-пайплайне, где false-positive дорого стоит.

Когда не применять: задачи с творческим ответом, генерация текстов, ревью кода - там разные ответы равно хороши, и majority vote не имеет смысла.

Least-to-Most - от простого к сложному

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

Пример: «Реализуй бэкап PostgreSQL в S3 с шифрованием».

Разбиение:

1. Какая команда делает дамп? → pg_dump
2. Как направить вывод в gzip? → pg_dump ... | gzip
3. Как зашифровать? → добавь openssl enc -aes-256-cbc
4. Как залить в S3? → aws s3 cp
5. Собери в одну команду

Каждый шаг проверяется отдельно. На любом этапе можно остановиться и поправить.

Аналогия с инженерной декомпозицией: это та же DDD-декомпозиция - сложный use-case разбивается на маленькие, у каждого свой ответственный.

Tree of Thoughts - дерево рассуждений

Развитие CoT: модель генерирует несколько вариантов на каждом шаге, оценивает их, выбирает лучший, идёт дальше. Получается дерево, а не цепочка.

Дорого по токенам и по времени. Имеет смысл для задач, где ошибка на ранних шагах катастрофична (планирование, поиск пути, доказательство теорем).

В практическом backend-применении встречается редко - чаще достаточно CoT + повторного прогона.

Program of Thought - мысли как код

Просить модель не «рассуждать словами», а написать программу, которая решит задачу. Дальше эту программу можно выполнить (если есть исполнитель), либо «прогнать в голове».

Найди все простые числа от 1 до 100. Напиши Python-код.

Сильная сторона: там, где задача алгоритмическая, программа надёжнее рассуждения - её можно запустить и проверить. Современные модели часто выполняют свой код прямо в ответе через tool-use.

Системные паттерны: промпт как часть архитектуры

Prompt Chaining - цепочка промптов

Вместо одного большого промпта - несколько последовательных, где выход одного является входом следующего.

Пример: «Сделай code review этого PR и подготовь комментарий для автора».

Цепочка:

1. Промпт A: «Найди в этом коде все потенциальные баги. Выведи список»
2. Промпт B (вход - результат A): «Для каждого пункта оцени критичность (high/medium/low) и предложи исправление»
3. Промпт C (вход - результат B): «Сформулируй вежливый комментарий PR-ревью на основе списка с критичностью»

Архитектурный смысл: это event-driven подход на уровне промптов. Каждый шаг отвечает за одно, легко тестируется и улучшается отдельно. Сбой на одном шаге не отравляет остальные.

Когда применять: многоэтапные задачи, где промежуточный результат имеет ценность. Когда хочется кеш, повторяемость, наблюдаемость.

RAG - Retrieval-Augmented Generation

Перед генерацией - поиск релевантных фрагментов в базе знаний, затем промпт с этим контекстом.

Архитектура:

Решает: галлюцинации на узких темах, устаревшие знания модели, нужда в источниках.

Не решает: проблемы качества базы знаний. Если документы плохие или поиск возвращает не то - RAG усиливает ошибку.

Backend-применение: ответы на вопросы по внутренней документации, поиск по тикетам, генерация ответов support'а на базе FAQ.

ReAct - Reasoning + Acting

Модель чередует «рассуждение» и «действия» (вызовы инструментов). Каждая итерация:

1. Thought: «Чтобы ответить, мне нужно узнать X»
2. Action: вызов инструмента (поиск, API, выполнение кода)
3. Observation: получили результат
4. → новый Thought

Цикл продолжается, пока модель не решит, что достаточно данных для финального ответа.

Пример: «Когда последний раз падал сервис checkout?»

• Thought: нужны логи incident-tracker
• Action: search_incidents(service="checkout", limit=10)
• Observation: список инцидентов
• Thought: достаточно, формирую ответ
• Final: «Последний падёж 12 мая 2026, длился 4 минуты»

Архитектура: ReAct - основа большинства современных «AI-агентов». Backend-эквивалент - оркестратор, который дёргает микросервисы по плану, который сам же и составляет.

Self-Refine - модель сама себя редактирует

Двухпроходный паттерн:

1. Первый промпт: «Сделай X»
2. Второй промпт: «Вот твой ответ. Найди проблемы и улучши»

Можно повторить третий раз, если есть бюджет.

Когда работает: задачи с критериями качества, которые модель сама умеет оценивать (стилистика, грамматика, читаемость кода).

Когда не работает: задачи, где модель сама не знает критерия. Если она не отличает правильный SQL от неправильного - не отличит и при self-refine.

Meta-Prompting - промпт, который пишет промпт

Просите модель сначала написать хороший промпт для задачи, а потом этот промпт уже использовать. Полезно, когда задача не ваша и вы не уверены, как её сформулировать.

У меня есть задача: "найти в логах причину тормозов".
Напиши идеальный промпт, который я смогу скормить тебе для решения.

Получите детальный многоступенчатый промпт, который иначе бы пришлось писать самому.

Constitutional AI - встроенные правила

Промпт с явными ограничениями: «не давай советы по обходу закона», «не раскрывай PII», «отвечай только на тему X».

В production-системе - обычно отдельный слой проверок (input/output filter), не часть основного промпта. В прототипах - быстро встроить в системный промпт.

Анти-паттерны - что НЕ работает

1. «Сделай как можно лучше» - не критерий. Дай измеримое условие.
2. Один гигантский промпт на всё - модель путается в приоритетах. Разбей на цепочку.
3. Слишком много примеров (10+) - больше шум, чем сигнал. Контекст переполняется, релевантность падает.
4. Полагаться на CoT в задачах без рассуждения - «Подумай шаг за шагом, какая столица Франции» работает хуже, чем просто «Какая столица Франции».
5. Считать, что Self-Refine исправляет любую ошибку - не исправляет, если модель не отличает правильный ответ от неправильного.
6. Промпт без формата вывода - получите свободный текст вместо JSON. Всегда указывайте формат, особенно для машинной обработки.

Шпаргалка: когда что применять

Итог

Промпт-инжиниринг - это набор паттернов. Не один «правильный» промпт, а коллекция приёмов под разные классы задач. Backend-разработчику полезно знать их по тем же причинам, по которым полезно знать GoF: чтобы быстро узнать форму задачи и применить проверенное решение, не изобретая велосипед.

Когда вы пишете промпт, спросите себя:

1. Это знакомая модели задача? → Zero-shot.
2. Формат особенный? → Few-shot.
3. Нужно рассуждение? → CoT.
4. Это многошаговая задача? → Chain.
5. Нужны внешние знания? → RAG.

В следующих уроках мы разберём конкретные кейсы: ревью кода, генерация миграций, описание API, и подходы к промпт-цепочкам в production.