Основы инженерии запросов: практический справочник

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

Что такое запрос на самом деле

Запрос — это всё, что вы отправляете модели перед тем, как она сгенерирует ответ: инструкции, контекст, примеры и сам вопрос или задача. Большинство современных чат-моделей разделяют это на роли: системное сообщение (задаёт поведение и ограничения), сообщения пользователя (сама просьба) и иногда сообщения ассистента (предыдущие ходы или примеры). Если вы используете API вроде OpenAI или Anthropic, вы задаёте их явно в коде. Если вы используете чат-интерфейс, системный запрос часто скрыт или устанавливается один раз в начале разговора.

Почему на один вопрос получаются разные ответы

Языковые модели предсказывают следующий токен на основе всего, что было раньше, включая вашу фразировку, порядок слов и даже пунктуацию. Спросите «Объясни рекурсию» — получите скучный учебный ответ. Спросите «Объясни рекурсию младшему разработчику, который понимает циклы, но не понимает рекурсию, используя один пример на Python с базовым случаем и рекурсивным случаем» — получите что-то намного полезнее. Конкретность вашего входного текста напрямую влияет на конкретность результата. Вот главное, что нужно понять новичкам: модель не читает ваши мысли, она ищет совпадения с вашими словами.

Основные методы, которые стоит изучить в первую очередь

Zero-shot prompting — это прямой вопрос без примеров: «Напишите regex для поиска номеров телефонов США». Это работает для обычных, хорошо определённых задач.

Few-shot prompting — это даёте модели один или несколько примеров паттерна вход/выход перед тем, как попросить её продолжить паттерн. Если вы хотите, чтобы модель отнесла обращения в поддержку к категориям, показав ей сначала три помеченных примера, вы получите более устойчивые результаты, чем если просто описать категории текстом.

Chain-of-thought prompting просит модель рассуждать пошагово перед финальным ответом, часто буквально добавляя «думай пошагово» или попросив показать работу. Это помогает при решении математических, логических и многоэтапных задач, хотя увеличивает расход токенов и длину ответа.

Role prompting назначает модели персону — «Ты старший инженер по безопасности, проверяющий код на уязвимости» — что может изменить тон, словарь и то, на какие детали она обращает внимание. Это не даёт модели новых способностей, но закрепляет стиль её ответов.

Структура важнее находчивости

Новички часто думают, что инженерия запросов — это поиск волшебной фразы. На практике структура выигрывает почти всегда. Разбейте запрос на ясные части: контекст, задача, ограничения и формат. Например:

Контекст: Вы проверяете приложение Python Flask для аудита безопасности.
Задача: Найдите риски SQL-инъекций в коде ниже.
Ограничения: Помечайте только проблемы в маршрутах /login и /search.
Формат: Верните нумерованный список с номером строки и однострочным объяснением.

Такое явное форматирование снижает неясность и облегчает разбор результатов программным путём, если вы связываете запросы вместе в скрипте.

Частые ошибки в начале

Одна частая ошибка — неясность под видом краткости: просить «сделай это лучше» без определения, что значит «лучше» (быстрее? читабельнее? безопаснее?). Другая — запихать в один запрос пять не связанных между собой задач, что обычно даёт поверхностные ответы на все пять вместо хорошего ответа на один. Новички также забывают, что модели не помнят предыдущие вызовы API, если вы не передадите историю разговора явно, что создаёт проблемы при создании чего-то stateful.

Тестирование и итерация как инженер

Относитесь к запросам как к коду, который вы версионируете и тестируете, а не как к одноразовому тексту. Ведите логирование вариаций запросов и их результатов, особенно для переиспользуемого в production, как чат-бот поддержки или помощник по проверке кода. Небольшие изменения формулировок — «кратко» вместо «кратко в ровно трёх пунктах» — могут дать существенно разные результаты, и единственный способ узнать, что работает в вашем случае, — провести сравнение самому вместо того, чтобы предполагать.

Где это вписывается в создание реальных вещей

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

Если вы хотите пойти дальше, посмотрите разделы Korra Studio о работе с LLM API в Python и о создании небольших инструментов на основе AI с нуля.