Работа с ИИ без хаоса: Как ставить задачи нейросети и получать полезный результат

Почему нейросеть отвечает не на тот вопрос

10:18. Мария вставила в окно нейросети сообщение клиента и добавила:

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

Через несколько секунд появился готовый текст:

«Здравствуйте! Приносим извинения за проблему с доступом. Доступ восстановим сегодня до 18:00. В качестве компенсации продлим подписку на месяц. Благодарим за терпение».

Мария прочитала ответ дважды. Он был вежливым, коротким и без ошибок — и совершенно не годился для отправки клиенту. Срок восстановления никто не подтверждал, продление подписки никто не обещал. Мария хотела успокоить человека, а получила два новых обязательства, которые команда не могла выполнить.

«Это какая-то случайная ошибка», — сказала она Илье, когда тот заглянул в кабинет.

«Может быть, — ответил он. — А что именно ты попросила модель сделать?»

«Подготовить ответ клиенту».

«А где в переписке сказано, что мы уже проверили доступ?»

Мария открыла переписку. Там этого не было.

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

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

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

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

Разрыв между тем, что нужно, и тем, что сказано

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

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

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

Задача Марии была не просто «подготовить ответ». Ей нужен был короткий текст для клиента, который можно отправить после проверки фактов. В запросе не были указаны ни формат, ни известные сведения, ни обещания, которых следовало избегать. Слово «вежливо» тоже не объясняло, что именно будет считаться удачным ответом.

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

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

Три причины переделок

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

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

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

Илья спросил Марию:

«Если бы я получил ровно этот запрос, смог бы понять, когда восстановят доступ?»

«Нет».

«А модель откуда должна была бы это узнать?»

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

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

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

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

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

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

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

Неопределённость расползается по ответу

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

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

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

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

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

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

Где заканчивается ошибка запроса

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

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

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

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

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

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

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

Даже когда факты переданы, проблема может оказаться в формате или критериях. Допустим, Мария сообщила, что причина отсутствия доступа пока неизвестна, обращение передано технической команде, промежуточный статус ожидается завтра до полудня, а продление подписки не согласовано. Если при этом она попросит просто «подготовить ответ», модель может вернуть пять вариантов с длинными пояснениями, хотя ей нужен один короткий текст. Здесь дело уже не в нехватке сведений, а в незаданной форме.

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

Когда ответ не тот: короткий разбор

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

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

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

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

Возвращаясь к запросу Марии

Восстановив недостающие условия, Мария отправила новую версию:

«Подготовь одно короткое сообщение для клиента в чате, не больше трёх предложений. Клиент сообщил, что уже неделю не может открыть уроки и обращается по этому поводу второй раз; причину и статус оплаты мы пока не проверили. Мы передали обращение в техническую команду и ждём промежуточный статус завтра до 12:00. Дежурный специалист свяжется с клиентом не позднее 13:00 завтра, даже если к этому времени доступ ещё не будет восстановлен. Продление подписки не согласовано. Признай повторное обращение, извинись и сообщи следующий шаг. Не обещай срок восстановления или компенсацию, если они не подтверждены. Не проси клиента повторно сообщать сведения, которые уже есть в переписке».

На этот раз появился другой текст:

«Здравствуйте. Простите, что вы уже неделю не можете открыть уроки и вынуждены обращаться к нам повторно. Мы передали обращение технической команде и не позднее 13:00 завтра сообщим вам результат проверки, даже если к этому времени доступ ещё не восстановится».

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

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

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

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

В третий раз переделки потребовал формат. Для внутренней встречи Мария попросила «сделать памятку по ответам на жалобы» и получила связный текст на несколько экранов. Он мог пригодиться как справочный материал, но сотрудникам, которые отвечали на обращения, нужны были короткие реплики и ясный порядок действий. Сведений хватало; не были заданы ситуация использования и форма. Когда Мария попросила сгруппировать материал по типам жалоб и для каждой группы указать, что признать, что проверить и какой следующий шаг назвать, результат стал удобнее. Причина переделки была иной, хотя первоначальная оценка звучала так же: «получилось не то».

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

От раздражения к диагностике

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

После неудачного ответа не обязательно сразу искать формулу «правильного запроса». Сначала полезно спросить себя: что должно было измениться в моей работе после ответа? Что я сообщила модели? Что она добавила от себя? Какой факт, формат или критерий мог бы изменить результат? Эти вопросы полезнее, чем просьба «сделай лучше»: они связывают качество запроса с реальной задачей.

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

Сначала работа, потом запрос

Глава 2. Сначала работа, потом запрос

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

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

— Может, отдадим нейросети всю переписку? Пусть читает письма, проверяет заказы и отвечает клиентам. Тогда хотя бы перестанем тратить время на типовые случаи.

Илья предложил начать с черновиков. Ольга, отвечавшая за внутренние процессы, задала другой вопрос:

— Что именно мы будем считать готовым ответом? Красивый текст или сообщение, в котором клиенту сообщили проверенный статус и не пообещали невозможного?

Вопрос помог отделить работу от ее внешнего результата. Службе поддержки недостаточно написать письмо: нужно понять просьбу клиента, проверить сведения, выбрать допустимое действие, объяснить его и зафиксировать, кто отвечает за следующий шаг. Текст — лишь одно звено в этой цепочке.

Сначала — результат работы

Для разбора команда взяла конкретное обращение. Клиентка Анна написала: «Заказ обещали привезти вчера. Деньги списали, а товара нет. Если сегодня не доставите, отменяйте и верните деньги». В письме были номер заказа, фамилия, телефон и адрес доставки. Сотруднику эти сведения могут пригодиться, но для обсуждения процесса их можно заменить условными обозначениями. Реальные данные следует передавать только в разрешенную для этого среду и в объеме, необходимом для задачи.

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

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

Мария записала рабочую карточку:

Результат для клиента — понять, где находится заказ и что будет дальше.

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

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

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

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

Владелец результата — сотрудник поддержки, который ведет обращение.

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

Маршрут одного обращения

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

Первый шаг. Понять, что пришло

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