Длинные запросы к LLM: когда они вредят, а когда помогают
Когда работаете с языковыми моделями, кажется логичным: чем подробнее объяснишь, тем лучше результат.
Разберём, когда длинный запрос полезен, а когда только мешает.
Почему люди пишут длинные запросы
Хотят максимально точный результат. Боятся, что модель неправильно поймёт.
Добавляют контекст, уточнения, примеры, ограничения. Запрос раздувается до нескольких абзацев.
Иногда это работает. Но часто создаёт проблемы.
Проблемы длинных запросов
Шум заглушает суть
Модель пытается учесть всё, что написали. Включая незначительные детали.
Если запрос перегружен информацией, модель может зацепиться за второстепенное и упустить главное.
Пример плохого длинного запроса: «Напиши мне статью про кофе, но не слишком длинную, где-то на 500 слов, может чуть больше или меньше, это не критично, главное чтобы была интересной, расскажи про его историю, но не углубляйся сильно, и про разные виды кофе, может эспрессо, капучино, латте, но если считаешь что нужно про другие, то ок, и ещё было бы круто упомянуть про пользу и вред, но не делай это слишком медицинским, пиши проще, для обычных людей».
- Нечёткую длину (500, но можно больше или меньше)
- Расплывчатые темы (история, но не углубляться)
- Противоречивые указания (интересно, но просто)
Результат будет посредственным.
Противоречивые инструкции
Длинный запрос часто содержит противоречия.
«Напиши кратко, но подробно». «Будь формальным, но дружелюбным». «Опиши всё, но не перегружай деталями».
Модель пытается угодить всем требованиям и получается компромисс, который никого не устраивает.
Потеря фокуса
В длинном запросе легко размыть цель.
Начали с одного, добавили ещё что-то, потом ещё. В итоге сами не уверены, что хотите.
Модель отражает вашу неопределённость.
Когда длинный запрос работает
Когда нужен очень специфический результат
Если задача сложная и нетипичная, детали важны.
Пример хорошего длинного запроса: «Напиши функцию на Python, которая принимает список словарей с ключами 'name' и 'age', фильтрует только тех, кому больше 18, сортирует по возрасту в убывающем порядке, и возвращает список имён. Используй list comprehension и встроенную сортировку. Добавь docstring с описанием параметров и возвращаемого значения».
Здесь каждая деталь важна. Без них результат был бы слишком общим.
Когда даёте примеры
Примеры — один из лучших способов направить модель.
«Перепиши эти предложения в более разговорном стиле: Исходное: 'В случае возникновения проблемы обратитесь в службу поддержки' Переписанное: 'Если что-то пошло не так, напишите в поддержку'
Исходное: 'Осуществите проверку корректности введённых данных' Переписанное: 'Проверьте, правильно ли вы всё ввели'
Теперь перепиши: 'Необходимо произвести оплату в течение трёх рабочих дней'»
Примеры показывают нужный стиль лучше, чем абстрактные описания.
Когда выстраиваете структуру
Если нужен результат определённого формата, лучше явно его задать.
«Создай резюме по этому шаблону:
Имя: [имя] Должность: [должность] Опыт работы:
Данные для заполнения: [текст]»
Чёткая структура в запросе даёт чёткую структуру в ответе.
Когда короткий запрос лучше
Для простых задач
«Переведи на английский: [текст]»
«Исправь грамматические ошибки: [текст]»
«Сократи этот текст в два раза»
Не нужно объяснять, как делать. Задача очевидна.
Когда модель уже понимает контекст
Если разговор идёт несколько сообщений, контекст уже есть.
Вы: «Расскажи про блокчейн простым языком» Модель: [объяснение] Вы: «А теперь объясни, как будто мне 10 лет»
Второй запрос короткий, потому что модель помнит тему.
Для творческих задач
«Напиши короткий рассказ про кота, который думает, что он собака»
Не нужно уточнять детали. Творчество требует свободы.
Чем меньше ограничений, тем интереснее результат.
Как писать эффективные запросы
Начните с чёткой цели
Одно предложение: что вы хотите получить?
«Нужна функция для проверки email».
«Нужен текст для рекламного поста».
«Нужно объяснение термина простым языком».
Добавьте необходимые детали
Не все, а только те, что влияют на результат.
Для кода: язык, входные данные, формат вывода.
Для текста: стиль, длина, целевая аудитория.
Для перевода: контекст, если термины специфические.
Уберите лишнее
Перечитайте запрос. Что можно удалить без потери смысла?
«Пожалуйста, если тебе не сложно, напиши...» — лишнее. Модель не обижается.
«...но только если считаешь, что это правильно» — размывает инструкцию.
Тестируйте итеративно
Начните с короткого запроса. Посмотрите результат.
Не то, что хотели? Уточните один аспект.
Пошаговое уточнение лучше, чем сразу писать огромный запрос.
Структура хорошего запроса
- Роль (опционально): «Ты опытный программист Python»
- Задача: «Напиши функцию, которая...»
- Контекст (если нужен): «Это для веб-приложения, где...»
- Формат: «Добавь комментарии и docstring»
- Ограничения (если есть): «Не используй внешние библиотеки»
Не обязательно всё включать. Только то, что действительно важно.
Частые ошибки
Извинения и вежливость
«Извини, что беспокою, но не мог бы ты...»
Модель не человек. Ей не нужны извинения. Это просто шум в запросе.
Объяснение очевидного
«Ты же знаешь, что Python это язык программирования, вот мне нужно...»
Модель знает. Не тратьте токены.
Многократные повторы
«Напиши кратко, не делай слишком длинным, короткий ответ будет достаточно».
Сказали одно и то же трижды. Достаточно «Напиши кратко».
Когда использовать системные промпты
Если работаете через API, можно задать системный промт — инструкции, которые применяются ко всем запросам.
Например: «Ты пишешь в разговорном стиле без формальностей».
Тогда каждый конкретный запрос может быть короче. Стиль уже задан глобально.
В веб-интерфейсах (ChatGPT, Claude) нет системных промтов. Но можно начать диалог с общих инструкций.
«В этом разговоре пиши код с подробными комментариями и проверкой ошибок».
Дальше запросы могут быть короче.
Эксперимент: сравнение длинного и короткого
Длинный запрос: «Мне нужно написать пост в соцсети про новый продукт, это приложение для планирования задач, целевая аудитория молодые профессионалы 25-35 лет, пост должен быть не очень длинным, может 100-150 слов, тон дружелюбный но профессиональный, упомяни ключевые фичи: синхронизация между устройствами, умные напоминания, интеграция с календарём, но не перечисляй их списком, а вплети в текст естественно, и ещё добавь призыв к действию в конце».
Короткий запрос: «Напиши пост в соцсети (100-150 слов) про приложение для планирования задач. Аудитория: профессионалы 25-35 лет. Тон: дружелюбный. Фичи: синхронизация, умные напоминания, интеграция с календарём. Добавь призыв к действию».
Второй короче, но содержит ту же информацию. Структурированнее. Проще парсить.
Результат будет лучше, проверьте.
Итоговые принципы
Короткий запрос для простых задач. Длинный для сложных и специфических.
Детали добавляйте, только если они влияют на результат.
Структурируйте информацию. Списки, пункты, чёткие категории.
Убирайте вежливость, извинения, лишние объяснения.
Итеративно уточняйте. Не пытайтесь написать идеальный запрос с первого раза.
Проверяйте каждое предложение: оно меняет результат? Нет — удаляйте.
Длина ради длины не работает. Работает чёткость.
Модель не читает между строк. Не понимает намёки. Говорите прямо.
Хороший запрос — это не обязательно длинный. Это чёткий, конкретный, без лишнего.