Критерии качества AI-функции: договор Product и ML

Где конфликт начинается на самом деле

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

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

Из-за этого спор вспыхивает уже после первого показа. ML-команда говорит: модель дала 86% на валидации, значит качество нормальное. Product отвечает: пользователи все равно не доверяют ответам и перепроверяют каждый второй. Метрика есть, а пользы нет.

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

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

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

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

Что считать пользой для пользователя

Критерии качества AI-функции начинаются не с метрики модели, а с действия человека. Если команда не может назвать одну конкретную задачу, спор о качестве начнется еще до первого теста.

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

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

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

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

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

Такой подход снимает половину лишних споров. Product смотрит не на "умность" модели, а на то, помогает ли она закончить задачу. ML понимает, какой уровень качества уже считается полезным, а какой пока нет.

Как зафиксировать порог качества

Споры о качестве начинаются не из-за модели, а из-за расплывчатых ожиданий. Product говорит: "это уже полезно". ML отвечает: "на тесте все нормально". Потом команда неделями выясняет, кто прав. Чтобы этого не было, критерии качества AI-функции лучше свести к нескольким числам еще до старта разработки.

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

Удобнее всего держать их в одной таблице. Тогда product, ML и владелец риска смотрят в один документ, а не в разные дашборды.

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

Порог запуска и порог остановки не должны совпадать. Если поставить одно число, команда начнет метаться при каждом колебании. Лучше оставить зазор. Например, запускать пилот при 72% успешно решенных задач, а останавливать раскатку только при падении ниже 65%.

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

Если этого нет на бумаге, порог качества быстро превращается в спор по памяти после первой неудачной недели пилота.

Какие стоп-сценарии нельзя пропустить

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

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

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

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

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

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

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

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

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

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

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

Полезно разделить откат на два уровня. Частичный нужен, когда ломается не вся функция, а одна зона риска. Например, можно оставить черновик ответа, но запретить автоотправку. Или отключить одну модель и перевести трафик на более предсказуемую. Если команда работает через единый шлюз, такой переход часто делается быстрее и без изменений в клиентском коде. Для компаний в Казахстане это особенно удобно, когда нужно быстро сменить провайдера, сохранить аудит-логи и не выносить чувствительные данные за пределы страны. Здесь может пригодиться AI Router на airouter.kz: он дает один OpenAI-совместимый endpoint, маршрутизацию между провайдерами, маскирование PII, rate limits и хранение данных внутри Казахстана.

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

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

У каждого триггера должен быть владелец. Обычно решение о частичном откате принимает on-call инженер или ML-владелец, а полный откат подтверждает product или руководитель сервиса. В документе нужен и срок реакции: например, 15 минут на частичный откат и 1 час на полный. Если ответственных двое, заранее укажите, кто действует первым, если второй недоступен.

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

Пример на одной функции

Возьмем простую AI-функцию: черновик ответа клиенту в банковском чате. Пользователь пишет: "Вчера с карты дважды списали 18 500 тенге за подписку. Я ее не подключал. Верните деньги и отключите автоплатеж". На одном таком запросе уже видно, где у команды расходятся ожидания.

Один запрос, три ответа

Если договор между Product и ML рабочий, команда смотрит не на "общее впечатление", а на конкретный ответ.

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

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

Плохой ответ: Деньги уже возвращены, ожидайте зачисление в течение 3-5 дней. Это явная ошибка. Ответ придумал результат проверки и создал ложное ожидание. Для финансового сценария это стоп-сигнал.

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

Что команда делает в каждом случае

После такого разбора критерии качества AI-функции перестают быть абстракцией. Для каждого класса нужен свой следующий шаг.

Хороший ответ команда засчитывает как pass в тестовом наборе и допускает в пилот. Спорный помечает как edit needed: меняет промпт, правила или модель, а до исправления оставляет только режим черновика для оператора. Плохой заносит в список стоп-сценариев, добавляет в регрессионные тесты и включает план отката AI-функции на шаблонный ответ или ручную обработку.

Так спор уходит из области вкуса. Product видит, где есть польза для клиента, а ML понимает, какой класс ошибок нельзя приносить даже в ранний запуск.

Порядок работы до старта разработки

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

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

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

После этого выберите метрики, которые правда связаны с пользой. Обычно хватает двух-трех: доля принятых ответов, среднее число правок, время до результата, доля опасных ошибок. Для каждой метрики нужен порог и объем проверки. Фраза "качество должно быть хорошим" не годится.

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

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

В конце подпишите короткий рабочий документ. Там должны быть владелец функции со стороны Product, ответственный со стороны ML, дата пересмотра, пороги, стоп-сценарии и порядок отката. Такой лист часто экономит недели споров.

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

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

Ошибки, которые дорого обходятся

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

Средняя оценка почти всегда прячет хвосты. Если функция помогает в 85% простых случаев, но в оставшихся 15% путает смысл, выдает лишние данные или советует неверное действие, пользователю не легче. Для саппорта, банка или клиники один плохой класс запросов портит доверие сильнее, чем сотня удачных ответов. Поэтому надо смотреть не только на среднее, но и на срезы: редкие типы запросов, длинные сообщения, смешанный язык, обращения без контекста.

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

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

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

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

Перед стартом полезно ответить на четыре вопроса:

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

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

Короткий список перед запуском

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

Перед запуском стоит проверить пять вещей:

• Польза описана одной фразой без двойного смысла. Не "сделать ответы умнее", а, например, "сократить время обработки обращения оператора с 6 минут до 4 без роста жалоб".
• Порог запуска назван в цифрах. Команда знает, при каком результате функцию можно выпускать, а при каком нельзя.
• Список стоп-сценариев собран заранее. Туда входят ошибки, после которых функцию нельзя оставлять в проде даже при хорошей средней метрике.
• За откат отвечает конкретный человек. У него есть право остановить функцию, если она бьет по риску, деньгам или опыту пользователя.
• Документ один для всех трех сторон. Product, ML и бизнес видят одну версию, а не пересказывают ее по памяти.

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

Если у вас несколько моделей и строгие требования к данным, эту проверку лучше сделать до разработки. Нужно заранее понять, какая модель идет по умолчанию, куда попадают логи, как проходит аудит, где включается маскирование PII и можно ли держать данные внутри страны. Для команд в Казахстане такие вопросы часто решают еще на этапе архитектуры. Если нужен единый OpenAI-совместимый шлюз с аудит-логами, пометками AI-контента, ограничениями на уровне ключа и локальным размещением части моделей, это можно закрыть через AI Router.

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