Повторный анализ звонка: новая версия правила и прежний результат

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

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

Сотрудник отдела качества открывает звонок месячной давности, видит оценку 62 из 100 и не узнаёт разговор: в записи менеджер дважды уточнил бюджет, а в разметке это поле пустое. Через день тот же звонок в отчёте уже стоит с баллом 78, и никто не может сказать, что именно изменилось — правило, расшифровка или модель. Это условная сцена, но она точно описывает задачу, которую разбираем: как вести повторный анализ так, чтобы новый результат не выглядел как второй, отдельный разговор и не читался как изменение поведения сотрудника.

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

Оценка как след, а не как свойство записи

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

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

В инженерной практике для этого давно есть понятие прогона эксперимента: каждый запуск фиксирует входные данные, параметры и результат, а не только финальную метрику. Документация MLflow по отслеживанию экспериментов описывает именно такую логику — прогоны, параметры и артефакты, привязанные к конкретному запуску (MLflow: Experiment tracking). Нам не нужно тащить весь аппарат экспериментов, но сама идея «результат без контекста запуска бесполезен» здесь работает напрямую.

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

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

Что именно ломается, когда версии не подписаны

Самая частая и самая невидимая поломка — отчёт, который смешал версии. Руководитель смотрит на средний балл отдела за квартал и не знает, что половина звонков посчитана по старым критериям, а половина — по новым. Цифра выглядит цельной, а на деле это среднее по двум разным линейкам. Вывод «стало хуже» или «стало лучше» в такой ситуации не значит ничего.

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

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

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

Версия повторного расчёта: карточка версии расчёта

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

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

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

Два эпизода: правило поменяли, и текст поправили

Первый эпизод условный. Компания решила, что критерий «уточнил бюджет» должен засчитываться только при явной цифре, а не при общих словах вроде «ориентируемся на рынок». Правило переписали, версия сменилась с 2.0 на 2.1. Пересчитали архив за март — 214 звонков. У части звонков балл вырос, у части упал. Если бы карточек не было, отдел увидел бы, что «сотрудники за март стали работать иначе», хотя изменилась только линейка. С карточками видно: причина — смена правила, область — март, инициатор — аналитик, дата — 14-е. Поведение людей не менялось ни на грамм.

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

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

Почему «модель другая» — самый неудобный случай

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

Отсюда практическое следствие: смену модели нельзя проводить «тихо», как обновление приложения. Её стоит прогонять на контрольной выборке звонков, где результат уже известен и разобран людьми, и смотреть не на средний балл, а на то, какие конкретно звонки поменяли оценку и почему. Документация Microsoft по подходам к оценке генеративных приложений прямо подчёркивает, что качество оценивается набором методов и на размеченных данных, а не одной цифрой (Microsoft: Evaluation of generative AI applications). Это не про наш продукт, а про общий принцип: оценку проверяют на эталоне, а не на вере.

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

Расшифровка как отдельный источник версий

Многие команды недооценивают, насколько балл зависит от текста, а не от разговора. Расшифровка — это первый слой, на котором работает всё остальное, и у неё свои версии: движок распознавания, настройки, ручные правки. Microsoft в быстром старте по распознаванию речи показывает, что результат зависит от выбранного режима и параметров (Microsoft: Speech to text quickstart) — то есть один и тот же файл при разных настройках даёт разный текст. Нам важен вывод, а не конкретный сервис: текст — это не «сырьё», а полноценная версия.

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

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

Версия повторного расчёта на экране сотрудника

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

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

Второе — явная область. Перерасчёт должен требовать указания периода или выборки, а не молча брать «всё». Кнопка «пересчитать всё» имеет право на существование, но за отдельным подтверждением и с записью в карточку.

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

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

Версия повторного расчёта: исключения и проверка условий

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

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

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

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

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

Как проверить, что схема версий работает

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

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

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

Практикум: разбор одного перерасчёта по шагам

Возьмём другой пример, чтобы не повторять арифметику из начала. Условная компания обновила правило оценки приветствия: раньше засчитывалось любое упоминание имени, теперь — только если менеджер представился в первые пятнадцать секунд. Правило сменилось с 1.4 на 1.5. Нужно пересчитать архив за апрель и не сломать сравнение с мартом.

Шаг первый — зафиксировать причину. В карточке версии пишем: смена правила, с 1.4 на 1.5, инициатор — руководитель отдела качества, дата — условное 3 мая. Это одна строка, которая потом сэкономит часы объяснений.

Шаг второй — определить область. Пересчитываем только апрель, март оставляем на версии 1.4. Сразу договариваемся, что сравнение март-апрель будет помечено как сравнение двух версий, а не как динамика поведения.

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

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

Шаг пятый — обновить отчёт. Везде, где встречается апрель, появляется пометка о версии правила. Средний за два месяца либо не строится, либо строится с явной оговоркой.

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

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

Где здесь место продукту и где — проверке

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

Что в итоге должно остаться после перерасчёта

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

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

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

Смежный вопрос разобран отдельно: Оспаривание оценки звонка: как разобрать спор по реплике.