Нейросети без мусора: Как отличать качество от генеративного шума

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

Ролевые ограничения определяют, чьё решение нельзя подменять. Например: «подготовь варианты для обсуждения с юристом», а не «определи, что делать по закону»; «сформулируй вопросы врачу», а не «назначь лечение»; «сделай предварительный анализ данных», а не «подтверди причину падения продаж».

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

Антипримером служит запрос: «Сделай текст убедительным и добавь конкретики». Нейросеть может добавить конкретику из собственных вероятностных догадок. Безопаснее написать: «Добавь конкретные сведения только из приложенного прайс-листа. Если для аргумента не хватает данных, поставь пометку “нужно подтвердить”, не подставляй примерные цифры».

Условия остановки

Хорошее задание должно сообщать не только, что делать, но и когда нельзя продолжать. Это особенно важно при неполных данных.

Скрипт для такой границы может выглядеть так:

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

Эта формулировка превращает неизвестность из дефекта в часть результата. Вместо выдуманного пункта пользователь получает список недостающих данных.

Для анализа документа можно добавить:

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

Для подготовки письма:

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

Такие ограничения не делают нейросеть умнее. Они лишь уменьшают область, в которой она может выдать правдоподобный шум.

Что было бы, если исходных данных нет

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

Это должна быть не инструкция, а проект структуры для последующего заполнения.

Запрос может звучать так:

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

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

Что было бы, если аудитория неоднородна

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

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

Рабочий запрос в таком случае:

«Подготовь общий алгоритм для всех сотрудников, затем добавь два небольших блока: “Если вы оформляете командировку впервые” и “Что проверяет руководитель”. Не смешивай действия сотрудника с действиями бухгалтерии. Термины, необходимые только специалистам, вынеси в примечание».

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

Что было бы, если нужен не текст, а решение

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

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

Рабочая постановка будет другой:

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

В этом варианте нейросеть не просто «пишет красиво». Она получает процедуру рассуждения, которую можно проверить.

Как описать критерии готовности

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

«Результат готов, если…»

Например, для инструкции:

«Результат готов, если сотрудник может по нему определить последовательность действий, комплект документов, срок передачи и случаи, требующие уточнения».

Для сравнительного обзора:

«Результат готов, если сравнение проведено по заранее заданным критериям, исходные данные указаны, различия между фактами и оценками отмечены, а вывод связан с конкретным сценарием использования».

Для письма:

«Результат готов, если адресат понимает, о каком случае идёт речь, какое действие от него требуется, к какому сроку и какие материалы приложены».

Для учебного объяснения:

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

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

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

От расплывчатого запроса к рабочему заданию

Возьмём ещё один пример. Исходная команда:

«Сделай пост для клиентов о переходе на электронные чеки. Напиши понятно и без лишней официальности».

В ней есть тема, аудитория и общий тон, но нет цели и условий. Что должен сделать клиент? Понять, что чек теперь приходит в электронном виде? Проверить номер телефона? Обратиться в поддержку, если сообщение не пришло? Пост должен сообщить об изменении или убедить, что новый порядок безопасен?

Разберём задачу по шагам.

Сначала цель: после прочтения клиент должен понять, где найти чек и что делать, если он не пришёл.

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

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

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

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

Рабочий запрос:

«Подготовь короткое уведомление для клиентов о переходе на электронные чеки. Цель — объяснить, где клиент найдёт чек после покупки и что делать, если документ не появился. Аудитория не обязана знать внутренние названия систем. Используй только факты из приложенного описания процесса: способ отправки, срок появления, канал повторного запроса и контакты поддержки. Не добавляй обещаний о сроках, которых нет в исходных данных. Структура: короткое сообщение об изменении, где искать чек, что делать при отсутствии, куда обратиться. Тон спокойный, без рекламных формулировок. Готовый текст должен позволять клиенту выполнить действие без дополнительного объяснения».

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

Скрипты для разных типов задач

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

Для инструкции:

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

Для анализа:

«Проанализируй [данные] для [лица, принимающего решение]. Цель — [решение или выбор]. Раздели факты, интерпретации и гипотезы. Не делай выводов о [граница]. Сравни варианты по [критерии]. Для каждого вывода укажи основание и ограничение. Результат готов, если по нему можно [следующий шаг]».

Для письма:

«Составь письмо от имени [отправитель] для [адресат] по поводу [конкретный случай]. Цель письма — [действие адресата]. Укажи [факты, даты, документы], не добавляй [неподтверждённые обвинения или обещания]. Тон — [наблюдаемые признаки тона]. Результат готов, если адресат понимает, что произошло, что требуется и к какому сроку».

Для черновика, когда информации пока мало:

«Создай не готовый текст, а структуру будущего материала по теме [тема]. Для каждого раздела укажи, какие данные нужно предоставить. Не заполняй пробелы вымышленными сведениями. В конце составь список вопросов, без ответов на которые публикация невозможна».

Последний скрипт особенно ценен. Он не заставляет нейросеть изображать завершённость там, где рабочий процесс ещё не готов.

Дерево решения перед отправкой запроса

Если нужно быстро проверить постановку, можно использовать короткую последовательность «если — то».

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

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

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

Если исходные материалы есть, отделите обязательные правила от примеров, оценок и предположений.

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

Если результат нельзя принять по наблюдаемым признакам, сформулируйте критерий готовности.

Если в запросе всё ещё остаются слова «качественно», «понятно», «профессионально», «интересно» или «убедительно», замените их описанием того, что должен увидеть или сделать читатель.

Эта проверка не требует специального инструмента. Её можно выполнить в заметке перед обращением к модели. Главное — не путать подготовку запроса с украшением команды.

Маленькая практика: перепишите одну задачу

Возьмите реальный запрос, который вы недавно отправляли нейросети. Не выбирайте учебный пример. Подойдёт письмо, план покупки, объяснение для коллеги, описание услуги или сводка документа.

Сначала выпишите исходную тему в одной строке. Затем продолжите пятью фразами:

«После результата человек должен…»

«Пользоваться результатом будет…»

«Надёжными исходными данными являются…»

«Нельзя допускать…»

«Я приму результат, если…»

После этого добавьте условие остановки: «Если данных недостаточно, модель должна…»

Теперь сравните две версии. Вторая может оказаться длиннее, но её ценность не в объёме. Она уменьшает число решений, которые нейросеть вынуждена принимать вместо вас.

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

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

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