Качество ответа после релиза: кто за что отвечает

Почему после релиза начинаются споры

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

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

Один инцидент может звучать сразу в четырех версиях:

• продакт: "сценарий оплаты счета больше не работает";
• саппорт: "клиент считает ответ опасным и ждет реакцию сегодня";
• платформа: "после смены маршрута выросли таймауты и пошли повторы";
• ML-команда: "новый системный промпт сделал ответ слишком уверенным".

Все эти версии могут быть правдой одновременно. Это особенно заметно там, где один endpoint отправляет запросы в разные модели и к разным провайдерам. Пользователь видит только плохой ответ. Команды видят разные причины.

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

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

Что считать качеством ответа

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

Обычно хватает четырех:

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

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

Поэтому критерии лучше писать не в духе "ответ должен быть хорошим", а как рабочие правила. Например: "в 95% случаев модель правильно выбирает статус обращения", "не показывает ПДн в открытом тексте", "укладывается в 3 предложения", "если не уверена, просит уточнение, а не выдумывает".

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

Есть еще один важный момент. Спорные ответы должен принимать не тот, кто говорит громче, а заранее назначенная роль. Обычно факт и риск подтверждает владелец процесса или продакт, техническую причину разбирают платформа и ML-команда, а саппорт приносит реальные примеры из обращений. Если команда использует RU LLM, спор упрощают история запроса, встроенные аудит-следы и маскирование PII. Тогда разговор идет не о вкусах, а о проверяемых критериях.

Где проходит граница ролей

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

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

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

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

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

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

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

Как собрать матрицу ответственности

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

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

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

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

После этого полезно разделить инциденты по приоритету:

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

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

Один реалистичный сценарий сбоя

Банк запускает чат-помощника для статуса заявки. Клиент спрашивает, почему ему отказали в кредите. Модель отвечает спокойно и уверенно, но делает сразу две ошибки: называет не ту причину отказа и пишет в тоне, который звучит почти как обвинение.

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

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

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

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

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

Так спор "кто виноват" превращается в понятную цепочку действий, где у каждого свой участок работы.

Какие сигналы смотрит каждая команда

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

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

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

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

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

Один разбор вместо четырех

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

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

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

Где команды ошибаются чаще всего

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

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

Не менее частая проблема - жалобы живут отдельно от логов, версии промпта и версии модели. Саппорт хранит текст обращения в CRM, продукт ведет свой трекер, ML-команда смотрит на отдельные выборки. Через неделю никто не может связать жалобу с конкретным запросом. Если команда работает через шлюз для LLM, без model_id, провайдера, версии промпта и trace запроса разбор быстро превращается в гадание.

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

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

Полезный минимум выглядит так:

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

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

Короткий чек-лист на неделю

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

Хватает пяти простых проверок:

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

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

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

Что делать после первой версии матрицы

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

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

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

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

В карточке инцидента обычно хватает четырех полей:

• ID запроса и время;
• версия промпта или конфигурации;
• модель, провайдер и маршрут вызова;
• тег инцидента и итог разбора.

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

Где помогает единый слой

Если логи, резервные копии и биллинг должны оставаться внутри РФ, это лучше решить до того, как матрица начнет жить в проде. В таком случае RU LLM может упростить работу: это единый endpoint, совместимый с OpenAI, с маршрутизацией к разным моделям и провайдерам, встроенными аудит-следами, маскированием PII и хранением логов и бэкапов в РФ.

Это полезно не только для требований 152-ФЗ. Когда у продакта, платформы и ML-команды один ID запроса и одна история маршрута, инциденты разбираются заметно быстрее.

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