Ускорили dispatch-копилот и сделали его в 4 раза предсказуемее — та же модель

Ускорили dispatch-копилот и сделали его в 4 раза предсказуемее — та же модель

Средний случай стал быстрее. Хвостовые задержки исчезли. Теперь каждый прогон укладывается в узкий коридор — больше никаких непредсказуемых скачков на 12–14 ходов.

Проблема

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

Трейсы до проекта показывали именно второе. Большинство happy-path-ов укладывалось в десять ходов и примерно сорок секунд wall-clock. Но заметное меньшинство скакало до двенадцати или четырнадцати ходов, потому что модель выдумывала ID заказа, по которому UI не мог кликнуть, или пропускала рендер обязательной кнопки, или задавала вопрос, на который поток уже ответил. Это были десять–пятнадцать лишних секунд непредсказуемого торможения, и подрядчики их запоминали.

Что мы изменили

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

Результат

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

Как мы это измеряли

Wall-clock брался из слоя оркестрации, по ходам, суммированный по trace. Мы прогоняли happy-path трейсы лоб в лоб против того же staging-бэкенда в один день, чтобы контролировать сетевой разброс. Но важнее — мы следили за хвостом: в двухнедельном окне продакшен-трейсов после приземления набора изменений мы искали случаи выдуманных ID и прогоны, превышавшие двенадцать ходов. Тот класс хвостового поведения, вокруг которого мы строили проект, не вернулся.

Вот часть, которую стоит выделить для любого оператора, читающего это: мы не делали бенчмарк на одном happy path и не объявляли победу. Мы следили за классом отказов, который нас волновал, по репрезентативному окну, и сокращение удержалось.

Что это значит для вашего копилота

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

Если хотите оценку своего копилота, пришлите нам один репрезентативный trace и ваш system prompt. Мы скажем вам за час, какой класс отказов доминирующий и применим ли тот же паттерн.

FAQ

Вы меняли модель?

Нет. Та же модель, тот же tier, тот же вендор. Каждая цифра в этом кейсе получена на исходном выборе модели.

Это разовый бенчмарк задержки или устойчивый результат?

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

Работает ли это для копилотов, не диспетчерского типа?

Да, когда продукт — это чат-агент, ведущий пользователя через структурированный операционный workflow: тикеты, графики, маршруты, заполнение формы по структурированным записям. Чем дальше продукт от этой формы (например, чисто открытый Q&A), тем меньше применим паттерн.

Почему «разброс обвалился» важнее, чем «среднее стало быстрее»?

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

Подробнее