Петли исправлений пользователей для ИИ‑продуктов, которые быстро улучшаются

Почему мёртвые формы обратной связи не работают

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

Этот момент — самый важный. Пользователь уже показывает, что пошло не так, удалив фразу, исправив имя или переписав весь результат. Если продукт не фиксирует это изменение, вы теряете самый ясный сигнал.

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

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

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

У мёртвых форм есть ещё более простая причина провала: ими никто не владеет. Комментарии скапливаются в очереди, таблице или системе поддержки и ждут, пока у кого‑то появится свободное время. Большинство команд так и не превращают их в eval'ы, обновления подсказок или продуктовые правила.

Результат предсказуем. Модель снова сделает ту же ошибку на следующей неделе. Пользователь снова исправит её. Команда получит ещё один низкий рейтинг без полезной детали.

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

Что захватывать в момент трения

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

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

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

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

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

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

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

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

Как сортировать каждую правку по причине

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

Большинство команд могут отнести почти любую правку к одной из этих корзин:

• factual miss: ассистент дал неверную информацию, использовал устаревшие данные или взял неправильный источник
• prompt issue: факты в порядке, но тон, формат, длина или формулировка не соответствуют требованиям
• product rule gap: ассистенту нужны жёсткие правила, шаги или проверки разрешений вне подсказки
• one-off preference: пользователь предпочёл личный стиль, который не должен менять продукт для всех

Factual miss обычно указывает на проблемы с извлечением или данными. Проверьте, индексировались ли нужные документы, не отфильтровались ли нужные записи и достаточно ли свежие данные. Если бот поддержки говорит, что возврат средств занимает 30 дней, а политика изменилась на прошлой неделе, новая подсказка надолго не исправит ситуацию.

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

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

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

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

Простой поток маршрутизации, который может запустить команда

Начните с малого. Выберите одну задачу, где пользователи уже часто вносят правки — например, доработка AI‑черновиков писем или исправление извлечённых полей перед сохранением записи. Если вы начнёте с пяти задач сразу, команда захлебнётся в хаотичной обратной связи.

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

Используйте простой поток:

1. Сохраните исходный вывод, правку пользователя и окружающий контекст.
2. Отметьте каждое исправление одной причиной.
3. Сгруппируйте похожие случаи и посчитайте, как часто появляется каждая группа.
4. Превратите повторяющиеся случаи в eval'ы, которые команда сможет прогонять после каждого изменения.
5. Исправляйте причину в нужном месте: подсказка, правило продукта, извлечение или рабочий процесс.

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

Реалистичный пример из ассистента продаж

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

Одна такая правка выглядит как личное предпочтение. Если команда видит только одну отредактированную версию, её можно отложить как стиль и закрыть вопрос.

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

Это меняет диагноз. Команда уже не считает правку случайной. Они помечают эти исправления как несоблюдение правила, а не как вопрос тона, потому что менеджер восстановила бизнес‑правило.

Теперь урок можно направить в нужное место. Сначала добавляют eval с реальными примерами: когда клиент спрашивает о цене, упоминается ли правильно годовой план и ставится ли нужный вопрос? Затем обновляют подсказку и логику продукта, чтобы ассистент проверял правила планов перед генерацией ответа.

Также добавляют проверку перед отправкой: если в ответе упоминается цена, но пропущено правило по годовым планам, продукт блокирует черновик и просит менеджера исправить. Это строже, но экономит переписки и не даёт менеджерам рассылать противоречивые сообщения.

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

Распространённые ошибки, которые учат неправильно

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

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

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

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

Эти корзины не должны приводить к одному и тому же исправлению. Реальные ошибки требуют изменения подсказки, правила продукта, исправления извлечения или создания eval'а. Стилевые правки — в настройки пользователя, шаблоны или сохранённые предпочтения.

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

Худшая потеря данных — когда команда сохраняет только финальный текст. Тогда никто не может сравнить первый ответ и изменённый. Нужна полная цепочка: цель пользователя, исходный вывод, точные правки и состояние экрана в момент правки. Без этого нельзя понять, провалилась ли модель, подтолкнул ли продукт пользователя к лишней работе или это просто предпочтение.

Плохие уроки накапливаются тихо. Через несколько недель продукт кажется более загруженным, но не умнее. Чистые данные о правках не дадут вам исправлять не те вещи.

Короткий чек‑лист перед каждым релизом

Релиз становится рискованным, когда команда меняет подсказки или правила, не проверив, что реально исправляли пользователи. Исправление не начинается с дашборда — оно начинается с нескольких привычек, которые сохраняют сигнал чистым.

Если какая‑то проверка не проходит — приостановите изменение. Быстрая доставка полезна. Но выпуск фикса, который нельзя измерить, обычно создаёт новую проблему.

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

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

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

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

За чем следить после деплоя изменений

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

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

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

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

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

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

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

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

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

Следующие шаги для небольшой команды

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

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

Лёгкой рутины достаточно. Захватывайте исходный вывод и финальную правку каждый раз, когда пользователь меняет ответ. Добавляйте короткую причину только если это не замедляет пользователя. Просматривайте небольшую партию раз в неделю, даже если она крошечная. Повторяющиеся паттерны переводите в eval'ы, подсказки или правила продукта. Потом проверяйте выпущенные исправления на наборе eval'ов перед следующим релизом.

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

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

Если вашей команде нужна помощь с настройкой этого потока, Oleg Sotnikov at oleg.is работает с малыми компаниями над практическими AI‑системами и может помочь сопоставить правки с eval'ами, подсказками и правилами продукта. Короткий внешний обзор может сэкономить недели проб и ошибок.

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