Ответ модели плохой: что менять в запросе

Когда модель не понимает: диагноз перед лечением

Представьте, что вы просите объяснить механизм кэширования в распределённых системах. Первый ответ звучит как учебник: «Кэш — это промежуточное хранилище для ускорения доступа к данным». Второй перечисляет команды без объяснения их смысла: «Вот команды SET, GET, EXPIRE, но я не помню, как они связаны с политиками вытеснения». Третий выдаёт таблицу с колонками «Команда», «Время выполнения», «Пример», но без пояснений, почему именно такие параметры важны. Все три ответа формально верны, но ни один не решает вашу задачу.

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

1. Ответ не о том Модель уходит в сторону, пересказывает общие факты или придумывает несуществующие детали. Например, вместо объяснения механизма инвалидации кэша в Redis выдаёт историю развития баз данных. Причина: запрос не содержит ограничений или примеров, которые бы сузили тему.

2. Ответ о том, но поверхностный Модель называет ключевые термины, но не объясняет их связь. Например, перечисляет параметры конфигурации PostgreSQL, но не показывает, как они влияют на производительность при разных нагрузках. Причина: запрос не требует глубины анализа.

3. Ответ правильный, но неудобный Информация верна, но подана в виде сплошного текста без структуры или с избыточными деталями. Например, инструкция по настройке CI/CD в GitHub Actions начинается с объяснения, что такое CI/CD, хотя целевая аудитория — опытные разработчики. Причина: модель не знает, что вам уже известно, и не умеет угадывать предпочтения по форме.

Проблемы часто смешиваются. Например, ответ может быть одновременно не о том и неудобным. В таких случаях начинайте с исправления содержания: если модель не понимает, о чём речь, форма уже не важна.

Что работает: конкретика вместо надежд на догадки

Модели не умеют читать мысли. Если вы надеетесь, что она «сама догадается», что вам нужно, — скорее всего, получите общий ответ. Вот что действительно помогает:

1. Покажите пример нужного ответа

Не «Объясни, как работает кэш», а «Объясни механизм кэширования в Redis на примере команды, которая записывает данные с автоматическим удалением через заданный промежуток времени. Ответ должен выглядеть так:

• Что делает команда: описание её назначения
• Как это работает: механизм удаления данных по истечении времени
• Почему это полезно: сценарии использования в реальных системах».

Пример задаёт не только содержание, но и структуру. Модель копирует формат, а не придумывает его заново.

2. Назовите читателя

«Для разработчика, который уже знает, что такое HTTP-заголовки» и «Для новичка, который только начал изучать веб» — это два разных ответа. Без указания аудитории модель выберет средний уровень, который не устроит никого. Формулировка может быть такой: «Объясни механизм работы CORS-заголовков. Целевая аудитория: frontend-разработчики с опытом работы с fetch, но без глубокого понимания безопасности браузера».

3. Задайте форму вывода

Модели проще следовать шаблону, чем придумывать его. Вот несколько рабочих форматов:

• Список шагов: «Как настроить HTTPS на сервере с Nginx. Ответ в виде списка команд с пояснениями, что делает каждая».
• Таблица: «Сравнение PostgreSQL и MySQL по параметрам: максимальный размер таблицы, поддержка JSON, транзакции. Ответ в виде таблицы с колонками: Параметр, PostgreSQL, MySQL».
• Код с комментариями: «Пример Dockerfile для Python-приложения. Ответ: блок кода с комментариями на каждой строке, объясняющими её назначение».
• Вопросы и ответы: «Частые ошибки при работе с Kubernetes. Ответ в формате FAQ: вопрос — краткий ответ — развёрнутое объяснение».

4. Дайте материал вместо надежды на память модели

Модели не помнят всё. Если вы просите «Объясни, как работает алгоритм PageRank», а в запросе нет ни формулы, ни примера, модель может выдать упрощённое объяснение без ключевых деталей. Решение: добавьте в запрос ссылку на документацию или скопируйте нужный фрагмент. Например: «Объясни механизм работы алгоритма PageRank по этой формуле: [формула]. Ответ должен включать:

• Что означает каждый символ в формуле
• Как рассчитывается вес страницы
• Пример расчёта для небольшого графа».

Что не работает: мифы о «волшебных словах»

Есть несколько распространённых советов, которые либо не помогают, либо помогают слабо. Их часто рекомендуют, но на практике они не решают проблему:

1. Вежливость и «пожалуйста»

«Пожалуйста, объясни» вместо «Объясни» не меняет содержание ответа. Модели не реагируют на вежливость как на инструкцию. Исключение: если вы работаете с моделью, которая специально обучена на вежливых запросах (например, в корпоративных чат-ботах), но даже там это влияет скорее на тон, чем на содержание.

2. Заглавные буквы и восклицательные знаки

«ОБЪЯСНИ МНЕ ЭТО!!!» не заставит модель дать более точный ответ. Восклицательные знаки могут даже ухудшить результат, потому что модель может начать имитировать эмоциональный стиль вместо того, чтобы сосредоточиться на содержании.

3. Обещания награды

«Я заплачу тебе $100» или «Это очень важно для моей карьеры» не влияют на качество ответа. Модели не понимают ценности денег или карьерных перспектив в человеческом смысле. Такие фразы могут только отвлечь модель от основной задачи.

4. «Ты эксперт»

«Ты эксперт по Kubernetes» не сделает ответ более точным. Модели не обладают экспертными знаниями в человеческом смысле — они генерируют текст на основе статистики. Если вы хотите, чтобы ответ был написан в стиле эксперта, лучше указать: «Ответ должен быть написан в стиле технического блога для опытных инженеров, с примерами кода и объяснением, почему выбраны именно такие решения».

Почему длинный запрос не значит хороший

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

Объясни, как работает Git. Напиши ответ для новичка, но не слишком упрощённо. Включи команды для работы с ветками, но не углубляйся в merge-конфликты. Расскажи про внутреннее устройство, но не вдавайся в детали реализации. Ответ должен быть не длиннее [определённого объёма].

Здесь четыре противоречащих друг другу условия:

1. Для новичка, но не слишком упрощённо.
2. Включи команды, но не углубляйся в конфликты.
3. Расскажи про внутреннее устройство, но не вдавайся в детали.
4. Не превышай заданный объём.

Модель не сможет удовлетворить все условия одновременно. Вместо этого лучше разбить запрос на части:

• Сначала попросите объяснение для новичка с основными командами.
• Затем отдельно попросите объяснение внутреннего устройства, если это нужно.

Правило: один запрос — одна задача. Если задача сложная, разбейте её на шаги.

Разбить задачу на шаги: когда это оправдано

Разбиение задачи на шаги помогает, когда:

1. Задача состоит из независимых частей. Например, «Напиши Dockerfile для Python-приложения и объясни, как его деплоить в Kubernetes» лучше разбить на два запроса: сначала Dockerfile, потом деплой.
2. Ответ на каждый шаг требует проверки. Например, если вы просите модель написать SQL-запрос, а потом объяснить, как он работает, лучше сначала получить запрос, проверить его, а потом попросить объяснение.
3. Вы не уверены, что модель справится с задачей целиком. Например, если вы просите модель написать статью, лучше сначала попросить план, согласовать его, а потом писать текст по разделам.

Разбиение не помогает, когда:

1. Шаги зависят друг от друга. Например, если вы просите модель сначала объяснить, как работает алгоритм, а потом написать его реализацию, лучше сделать это в одном запросе, чтобы модель могла согласовать объяснение и код.
2. Задача простая и не требует промежуточных проверок. Например, «Объясни, что такое REST API» не нужно разбивать на шаги.
3. Вы не знаете, как проверить промежуточные результаты. Если вы не понимаете, как работает алгоритм, вы не сможете проверить, правильно ли модель объяснила его на первом шаге.

Как понять, что дело не в запросе, а в задаче

Иногда модель не может дать хороший ответ не потому, что запрос плохой, а потому, что задача выходит за пределы её возможностей. Вот признаки, по которым видно, что модель здесь не поможет:

1. Модель не понимает контекст Если вы просите объяснить, как работает конкретная функция в вашем коде, а в запросе нет ни кода, ни документации, модель не сможет дать точный ответ. Она не знает ваш код и не умеет читать его по описанию.

2. Модель выдумывает детали Если модель начинает придумывать команды, параметры или факты, которых не существует, это признак того, что она не знает ответа и пытается заполнить пробелы. Например, если вы просите «Напиши команду для настройки таймаутов в Nginx», а модель выдаёт несуществующий параметр, это значит, что она не знакома с этой частью документации.

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

4. Модель не может решить задачу даже после нескольких попыток Если вы пробуете разные формулировки, показываете примеры, разбиваете задачу на шаги, а модель всё равно даёт неверные или поверхностные ответы, скорее всего, задача слишком сложная или специфичная для текущей модели.

Тупик: править формулировку по кругу

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

Как выйти из тупика:

1. Остановитесь и проверьте ответ Прежде чем менять запрос, спросите себя: «Чего именно не хватает в ответе?». Если не хватает примеров — добавьте в запрос требование примеров. Если не хватает глубины — укажите, какие детали нужны.

2. Измените не формулировку, а подход Если модель не понимает задачу в виде текста, попробуйте другой формат. Например, вместо «Объясни, как работает алгоритм» попросите «Напиши псевдокод алгоритма с комментариями на каждом шаге».

3. Попробуйте другой инструмент Если модель не справляется с задачей, возможно, вам нужен не промпт, а другой подход. Например, если вы пытаетесь заставить модель написать SQL-запрос, а она постоянно ошибается, возможно, лучше использовать специализированный инструмент для работы с базами данных.

Позиция редакции

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

Главный критерий эффективности запроса: можно ли проверить ответ, не зная предмет? Если да — запрос хороший. Если нет — его нужно доработать. Например, запрос «Объясни механизм кэширования в Redis» плохой, потому что проверить ответ без знания Redis невозможно. Запрос «Объясни механизм работы команды SET в Redis с параметром, который задаёт время жизни данных. Ответ должен включать:

• Назначение команды
• Механизм удаления данных по истечении времени
• Сценарии использования» — хороший, потому что проверить ответ можно по документации Redis.

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

Условие, при котором позиция неверна: если вы работаете с моделью, которая специально обучена на вашем контексте (например, корпоративная модель, обученная на вашей документации и коде), конкретность запроса может быть менее критичной. В таких случаях модель может «догадываться» о контексте, но даже там лучше давать как можно больше деталей.