Что должен содержать рабочий запрос к ИИ?
Рабочий запрос должен указывать ожидаемый результат, аудиторию, цель и материалы, которые можно использовать в ответе. Затем задайте важные ограничения: объём, тон, факты, которые нужно сохранить, сведения, которые нельзя выводить из предположений, и порядок действий при нехватке информации. Чёткие границы полезнее, чем просьба к инструменту звучать как эксперт.
Предположим, вымышленная консалтинговая компания проводит практический семинар по составлению проектных заданий. Утверждённые факты: онлайн-занятие, рабочий лист и ответы на вопросы в конце. Запрос не должен побуждать модель придумывать клиентов, результаты, срочность или причину, по которой конкретному потенциальному клиенту нужен этот семинар.
Итоговый результат
Что именно вы получаете в ответ: письмо, таблицу, краткую справку на одну страницу, три варианта.
Читатель и цель
Кто будет это читать и какие решения или действия станут доступны читателю после прочтения.
Одобренные материалы
Факты, заметки или документы, на которые может опираться ответ, и ничего сверх этого.
Недопустимые выводы
Утверждения, выдуманность которых особенно нежелательна для проверяющего: результаты, рекомендации, даты, цены, ограниченность предложения.
Недостающая информация
Указание перечислить недостающую информацию в виде вопросов, а не восполнять пробелы.
Как может выглядеть запрос для практической задачи?
Пример запроса: Подготовьте короткое письмо с приглашением для операционных руководителей. Используйте только эти факты: онлайн-семинар о том, как яснее формулировать задания на проекты, рабочий лист для практики и время для вопросов. Пишите прямо и по делу, помогая читателю. Не выдумывайте имена клиентов, число участников, результаты или ограничения по количеству мест. Если не хватает полезного факта, добавьте вопрос о нём после черновика.
Запрос даёт проверяющему основу для сравнения с ответом. Можно проверить соответствие аудитории, исходным фактам и запретам на определённые выводы, не зная, что происходило внутри модели. Это пример задания, а не обещание, что конкретный запрос всегда даст правильный ответ.
Как тот же подход работает для внутренней задачи?
Та же структура подходит для внутренней работы, где риск обычно связан с уверенным изложением, скрывающим разногласия. Возьмём вымышленный интернет-магазин товаров для дома «Уикер энд Пайн» с командой из 30 человек, где координатору операционной работы нужно кратко изложить основателю три предложения поставщиков.
Слабый запрос: какого поставщика нам выбрать? Скорее всего, в ответе будет рекомендован один поставщик с убедительно оформленным обоснованием, хотя основатель так и не указал критерии, а в одном из коммерческих предложений не учтена стоимость доставки.
Рабочий запрос: сравните три коммерческих предложения поставщиков ниже для основателя компании, который на следующей неделе выберет поставщика упаковки. Критерии в порядке важности: цена за единицу при нашем обычном объёме заказа, стоимость доставки, минимальный заказ и срок выполнения заказа. Представьте таблицу с одной строкой на каждого поставщика. Если какая-либо информация в предложении отсутствует, напишите «не указано». Не рекомендуйте поставщика. После таблицы перечислите вопросы, которые нам следует задать каждому поставщику перед принятием решения. [вставьте предложения].
В проверенном результате в ячейке со стоимостью доставки одного из поставщиков стоит «не указано» и добавлен вопрос с просьбой её подтвердить. Эта единственная ячейка — самое полезное на странице: она не даёт предложению, которое выглядит дешевле из-за недостающих данных, оказаться победителем.
Хотите узнать, как это связано с конкретной должностью?
Ознакомиться с планируемой пробной программой для команды ↗Как улучшить первый ответ?
Проверьте результат, прежде чем писать более длинный запрос, а затем дайте одно конкретное указание по доработке. Определите, в чём именно проблема: возможно, призыв к действию неясен, инструмент сам предположил дату или в черновике повторяется расплывчатое утверждение. Оставьте утверждённые исходные материалы прикреплёнными к задаче.
Например: уберите утверждение о том, что семинар кардинально повышает продуктивность. Спросите читателя, хочет ли он получить программу, вместо того чтобы предполагать, что он готов записаться. Не меняйте предоставленные факты о семинаре. Такая переработка проверяет умение принимать решения с учётом доказательств и аудитории, а не просто просить более убедительный тон.
Укажите предложение
Укажите конкретную строку с ошибкой, а не просите предложить вариант получше.
Объясните почему
Опишите проблему в нескольких словах: нет подтверждения, не та аудитория, слишком длинно, просьба теряется в тексте.
Сохраняйте источник
Напомните инструменту, какие факты неизменны, чтобы при доработке он от них не отклонился.
Остановитесь, когда результат станет достаточно хорошим
Черновик, который вы можете вручную отредактировать за две минуты, не требует ещё трёх запросов.
Какие ошибки чаще всего встречаются в рабочих запросах к ИИ?
Самая частая ошибка — просить убедительный текст, не предоставив подтверждений, и тогда инструмент придумывает их сам. Слова вроде «захватывающий», «сильный» и «убедительный» подталкивают к превосходным степеням, выдуманным доказательствам и срочности, для которых ваши факты не дают оснований.
Вторая ошибка — скрывать решение, которое на самом деле требуется принять. Запрос на краткое изложение, когда читателю нужна рекомендация, или на рекомендацию, когда читателю нужно понять плюсы и минусы вариантов, даёт гладкий ответ не на тот вопрос. Третья ошибка — вставлять материалы, для работы с которыми инструмент не одобрен. Соблюдайте политику компании в отношении того, каким инструментам разрешён доступ к клиентским или персональным данным, а для практики используйте вымышленные примеры.
Что должен объяснить обучающийся?
Попросите предоставить исходный запрос, черновик, окончательную версию и краткую заметку о проверке. В заметке нужно указать один недостающий факт, одно удалённое предположение и одну причину, по которой итоговая версия подходит аудитории. Эти детали позволят предметно обсудить практическую работу с руководителем или коллегой.
Не считайте длину запроса или уверенный ответ доказательством компетентности. Короткий запрос с подходящей проверкой может быть полезнее подробного запроса, за которым скрывается неподтверждённое утверждение. Повторите упражнение с другим исходным материалом, прежде чем делать выводы о том, как учащийся справится с другими рабочими задачами.
Вокруг этого цикла создаётся Tosheo.ai: запланированы уроки по должностям, завершающиеся практическим заданием с реальным инструментом ИИ, оценкой по открытым критериям и возможностью отправить оценку на пересмотр. Разработка продукта ещё не началась, поэтому воспринимайте это как замысел, а не как измеренные результаты.
Когда улучшение запроса не решает проблему?
Даже более качественный запрос не поможет, если не хватает фактов, решение должен принимать уполномоченный человек или результат имеет юридические, финансовые либо трудовые последствия. В таких случаях соберите факты, привлеките ответственного за решение или обратитесь к квалифицированному специалисту для проверки. Практическое руководство NIST по управлению рисками ИИ подчёркивает необходимость документировать роли и ответственность в этой области; в небольшой компании для этого может быть достаточно указать, кто утверждает работу, выполненную с помощью ИИ, прежде чем её передадут за пределы команды.
Общие принципы, лежащие в основе этих примеров, включая продвинутые приёмы и различия в рекомендациях разработчиков разных инструментов, описаны в руководстве по составлению запросов. Готовые варианты этих запросов для повторного использования приведены в руководстве по шаблонам запросов.