Блог · 1 августа 2026 · 4 мин

Вечерняя сводка врала собственнику, и мы этого не видели

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

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

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

Что происходило

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

Сводка уходит в фиксированное время. Мы проверили, какая доля звонков дня успевала пройти весь путь к этому моменту. Получилось 50,0% в один день, 29,8% в другой, 34,0% в третий.

То есть собственник читал отчёт, в котором честные цифры описывали от трети до половины его дня. Ни одной выдуманной цифры в сводке не было. Была неполная картина, поданная как итог дня.

Почему это опаснее, чем кажется

У нас есть наблюдение, ради которого стоит написать эту статью. Клиент спокойно относится к недоделкам продукта: чего-то нет, что-то неудобно, где-то надо подождать. Это нормальная жизнь любой рабочей системы.

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

Мы видели это своими глазами на живом показе: собственник открыл ленту обращений и сам поймал разговор, который отображался дважды. Разговор был один, номера разные, потому что данные приходили из двух источников телефонии. Мы это чинили, но первым его вопросом было не «почему дубль», а «а остальному можно верить».

Почему очередь не успевала

Причина оказалась не в мощности сервера, а в лимитах поставщика модели. Один разбор звонка занимает примерно 5-6 тысяч токенов, а минутный лимит на ключе 12 тысяч. Физический потолок получается два-три разбора в минуту, и никакое увеличение размера пачки его не поднимает.

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

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

Что мы поменяли

Главное изменение не в коде. Мы завели метрику, которой раньше не было: доля звонков дня, разобранных к моменту отправки сводки. Целевое значение выше 90%.

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

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

Что из этого стоит забрать

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

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