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

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

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

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

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

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

Ситуация ухудшается, когда никто не ведёт счёт. Один говорит: «На прошлой неделе было лучше». Другой — новая версия быстрее. Третий вспоминает хороший пример вчера. Память — плохой метод тестирования, и часто побеждает самое громкое мнение.

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

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

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

Выберите задачи, которые модель должна решать

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

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

«Задача» — это чёткий пользовательский результат, а не расплывчатый навык. «Отвечать на вопросы поддержки по возвратам» — это задача. «Быть полезным» — нет. «Извлекать суммы из счетов в загруженных PDF» — это задача. «Понимать документы» — слишком общее.

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

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

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

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

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

Соберите небольшой тестовый набор из реальной работы

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

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

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

Для еженедельной оценки не нужен гигантский датасет. Начните с 20–50 кейсов. Этого достаточно, чтобы заметить явные падения качества, не создавая работы по поддержанию, которую команда бросит.

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

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

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

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

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

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

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

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

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

Короткий бланк оценки обычно достаточен:

• Пройдено/не пройдено для точных задач
• Точность от 1 до 5
• Безопасность от 1 до 5
• Формат от 1 до 5
• Одна фраза, почему вы выбрали эти оценки

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

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

Простой пример для команды поддержки: модель составляет 20 черновиков в неделю. Один ответ получил точность 4, безопасность 5 и формат 2 с пометкой «Хороший ответ, но проигнорировал требуемый список в виде маркеров». Вы быстро находите проблему и знаете, где её исправлять.

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

Проводите еженедельный обзор за 30 минут

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

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

Запускайте один и тот же небольшой тест каждую неделю. Держите его стабильным достаточно долго, чтобы заметить движение. Даже 20–40 кейсов могут рано ловить регрессии, если эти кейсы отражают реальные пользовательские задачи.

30 минут обычно хватает. Потратьте ~5 минут на запуск кейсов и запись оценок, 5 минут на сравнение результата с прошлой неделей, 10 минут на чтение кейсов, у которых изменилась оценка, и 10 минут на запись действий и назначение владельца.

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

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

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

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

SaaS-команда использует AI, чтобы готовить черновики ответов по возвратам до того, как человек их отправит. Черновики экономят время, но только если формулировка соответствует текущей политике возвратов.

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

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

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

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

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

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

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

Ошибки, которые делают оценки бесполезными

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

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

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

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

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

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

Держите пять вещей зафиксированными и видимыми:

• Точная версия тестового набора
• Версия рубрики
• Версия модели
• Версия подсказки
• Оценки по сегментам, а не только среднее

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

Быстрые проверки, прежде чем доверять оценке

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

Еженедельная оценка полезна только если выборка соответствует живой работе. Если 60% запросов пользователей — ответы поддержки и вопросы по биллингу, а половина вашего набора — креативные писательские подсказки, оценка будет лживая.

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

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

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

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

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

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

Что делать дальше, когда оценки падают

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

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

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

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

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

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

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

Если команде нужна помощь выстроить эту привычку, Oleg Sotnikov at oleg.is работает со стартапами и небольшими компаниями по практическому продукту, инфраструктуре и рекомендациям на уровне CTO. Лёгкая внешняя проверка помогает выстроить процесс, который подходит реальной работе, а не превращается в тяжёлый QA-ритуал.