Агент поддержки уже умеет отвечать на «где мой заказ» без человека. Проблема в другом действии: когда тот же агент сам жмёт «оформить возврат» или «отменить бронь», а решение оказалось неверным, откатить запись в биллинге или в системе бронирований гораздо дороже, чем переписать вежливый абзац. Именно этот разрыв - между дешёвым ответом и дорогой ошибкой записи - и есть тема свежего июльского препринта.
3 июля 2026 года независимые исследовательские дайджесты подхватили препринт, который предлагает так называемый difficulty-routed control для retail и airline service operations. Идея простая на словах: не гнать все запросы через один тяжёлый пайплайн, а сортировать их по сложности и подключать усиленную проверку только там, где агент собирается что-то реально записать в backend. Ниже - что именно предложили авторы, как собрать такую двухконтурную схему у себя и где её опасно тащить в прод.
Если ты строишь поддержку на LLM и уже обжигался на автономных действиях агента, дальше - по делу.
Что вообще случилось 3 июля
Событие - не релиз продукта, а научная публикация. По данным препринта на arXiv (идентификатор 2607.01426), авторы описывают контроль, маршрутизированный по сложности задачи: difficulty-routed control для операций клиентского сервиса в ритейле и у авиакомпаний. В тот же день, 3 июля 2026, разбор вышел в независимом ньюслеттере Neurals Weekly, а обзорная площадка Moonlight опубликовала свой разбор той же работы.
Сразу важная оговорка, которую делают и сами авторы, и обзоры: это препринт и бенчмарк на human-verified задачах, а не доказательство production-эффекта. То есть у нас есть проверенные людьми тестовые сценарии и заявленная механика, но нет данных, что в живом контакт-центре это даст такой же результат. Любую цифру из подобной работы нельзя переносить на свой поток обращений без собственного пилота. Дальше я буду отделять то, что заявляют авторы, от того, что додумывает индустрия.
Что такое difficulty-routed control простыми словами
Смысл маршрутизации по сложности - в том, что не все обращения одинаково опасны. «Когда придёт посылка» и «отмените бронь на троих и верните деньги» требуют разного уровня осторожности, хотя формулируются одинаково спокойно.
Схема, которую описывает препринт, двухконтурная. Первый контур - дешёвый быстрый путь для рутинных запросов: статус заказа, часы работы, справка по тарифу. Здесь агент отвечает сразу, без тяжёлых проверок, потому что цена ошибки - неточный текст, а не испорченная запись. Второй контур включается, когда запрос ведёт к рискованной backend-записи: возврат средств, отмена заказа, изменение брони, смена адреса доставки. Перед таким действием система прогоняет усиленную проверку - и только потом позволяет агенту тронуть базу.
Ключевое слово тут - «запись». Difficulty routed control в формулировке customer service agents backend writes ставит границу не по теме диалога, а по последствию: читаем мы состояние системы или меняем его. Чтение статуса - дёшево и обратимо. Запись возврата - дорого и почти необратимо на уровне денег и учёта.
Как выглядит быстрый контур для рутины
Начнём с простого - с дешёвого пути. Его задача: закрыть максимум обращений без эскалации и без записи. Здесь агент работает как обычный retrieval-ответчик: понял вопрос, достал факт, ответил.
Практический минимум для быстрого контура выглядит так. Ты классифицируешь входящий запрос по намерению и сразу отвечаешь на вопрос: приведёт ли это намерение к записи в backend. Если нет - отвечаешь и закрываешь. Если да - не отвечаешь, а передаёшь запрос во второй контур. На этом этапе полезно логировать, какой процент диалогов вообще ушёл в тяжёлую ветку: это твоя будущая экономика.
# Быстрый контур: только чтение, никаких записей
ROUTINE = {"order_status", "faq", "hours", "tariff_info"}
WRITE_INTENTS = {"refund", "cancel_order", "change_booking", "change_address"}
def route(intent: str) -> str:
if intent in WRITE_INTENTS:
return "reinforced" # усиленная проверка
if intent in ROUTINE:
return "fast" # дешёвый ответ
return "reinforced" # неизвестное - в безопасную ветку
Обрати внимание на последнюю строку: неизвестное намерение уходит не в быстрый путь, а в усиленную проверку. Это осознанный перекос в сторону безопасности. Лучше лишний раз замедлить редкий странный запрос, чем случайно позволить агенту выполнить запись, потому что классификатор не узнал формулировку.
Быстрый контур - это место, где стоимость модели важнее её «ума»: тебе нужен дешёвый и быстрый ответ на типовое обращение. Здесь удобно держать лёгкую модель, а тяжёлую подключать только во втором контуре.
Как устроен усиленный контур перед записью
Второй контур - это то, ради чего вообще нужна вся маршрутизация. Здесь агент собирается изменить состояние системы, и именно здесь по замыслу препринта включается дополнительная проверка перед действием.
Механику можно разложить на три шага. Первый - собрать полную предпосылку: какой заказ, какая сумма, какая политика возврата применима, какие ограничения по времени. Второй - проверить действие против правил до вызова API: подпадает ли кейс под условия возврата, не нарушает ли отмена уже оказанную услугу. Третий - сформировать обратимый план: сначала подтверждение, потом запись, и всегда - идемпотентный ключ, чтобы повтор запроса не создал два возврата.
def reinforced_write(order, action, policy):
# 1. предпосылка
ctx = gather_context(order) # сумма, статус, политика
# 2. проверка до записи
if not policy.allows(action, ctx):
return escalate_to_human(order, reason="policy_block")
# 3. обратимый, идемпотентный вызов
key = f"{order.id}:{action}" # один и тот же key -> одна запись
return backend.execute(action, ctx, idempotency_key=key)
Здесь два защитных приёма важнее любой модели. Идемпотентный ключ гарантирует, что даже при ретрае агент не оформит два возврата на один заказ. Явная проверка политики до вызова backend означает, что решение «можно ли записывать» принимает детерминированный код, а не свободный текст модели. Модель предлагает действие, правила его разрешают, backend исполняет - в таком порядке.
Отдельный вопрос - какую модель ставить на разбор сложных кейсов во втором контуре. На практике для тяжёлой ветки хочется модель посильнее, а для рутины - подешевле, и удобно, когда обе доступны через один интерфейс. Через единый API у provod.ai, совместимый с OpenAI и Anthropic SDK, можно дёргать разные модели (Claude, GPT, Gemini, DeepSeek, Qwen) сменой ключа и base_url - лёгкую на быстрый контур, тяжёлую на усиленный, не разводя два разных стека. Это удобство маршрутизации, а не замена самой логики проверки: правила безопасности всё равно пишешь ты.
from openai import OpenAI
client = OpenAI(api_key="...", base_url="https://api.provod.ai/v1")
Где эта схема ломается
Теперь честно про грабли. Двухконтурная маршрутизация выглядит аккуратно на слайде, но у неё есть предсказуемые точки отказа, и большинство из них - не про модель, а про границы.
Первый режим отказа - ошибка классификатора на входе. Если намерение «верните деньги» замаскировано под «а вообще у вас как с возвратами», лёгкая модель может отправить запрос в быстрый контур. Отсюда правило «неизвестное - в усиленную ветку»: ты сознательно жертвуешь скоростью на пограничных формулировках.
Второй режим - ложная уверенность второго контура. Усиленная проверка проверяет то, что ты в неё заложил. Если политика возврата в коде не учитывает частичные возвраты или промо-товары, агент честно пройдёт проверку и запишет неверное. Проверка перед записью защищает от нарушения известных правил, а не от дыр в самих правилах.
Третий режим - экономика наизнанку. Весь смысл маршрутизации в том, что дорогой путь используется редко. Если в твоём потоке доля запросов на запись высокая, экономия испаряется: ты платишь за тяжёлый контур почти на каждом диалоге. Поэтому первое, что стоит измерить в пилоте, - реальную долю обращений, ведущих к backend-записи. Без этой цифры вся модель затрат - фантазия.
Четвёртый режим - самый коварный: перенос бенчмарка на прод. Препринт заявляет результаты на human-verified задачах. Это контролируемые сценарии. Живой контакт-центр даёт шум, редкие формулировки, злоупотребления и региональную специфику, которых в бенчмарке нет. Как отмечают и независимые разборы Neurals Weekly и Moonlight, работа - это предложение механики, а не гарантия эффекта в проде.
Быстрый контур или усиленный: как решать
Чтобы не гадать в каждом кейсе, зафиксируй границу таблицей. Она отвечает на один вопрос: обратимо ли действие и трогает ли оно деньги или обязательства.
| Признак запроса | Быстрый контур | Усиленный контур |
|---|---|---|
| Что делает агент | читает состояние | пишет в backend |
| Пример | статус заказа, тариф, часы | возврат, отмена, смена брони |
| Цена ошибки | неточный текст | потерянные деньги, откат учёта |
| Обратимость | полная | частичная или никакой |
| Кто решает «можно» | модель | детерминированная политика |
| Идемпотентность | не нужна | обязательна |
| Неизвестное намерение | не сюда | сюда по умолчанию |
Таблица нужна не для красоты, а как контракт между продуктом и разработкой: если завтра появляется новое действие, вы сначала отвечаете, пишет ли оно в backend, и только потом решаете, в какой контур его класть. Всё, что меняет состояние, по умолчанию едет в усиленную ветку.
Как выкатывать это без сюрпризов
Раз это препринт, а не готовый продукт, внедрять стоит как эксперимент, а не как замену текущей поддержки. Ниже - минимальный, честный порядок пилота.
Сначала опиши инвентарь действий: выпиши все намерения и промаркируй каждое как чтение или запись. Это скучная, но самая ценная работа - именно она определяет границу контуров. Потом включи усиленный контур в режиме «предложить, но не исполнять»: агент готовит запись, проверка отрабатывает, а финальную кнопку жмёт человек. Так ты собираешь статистику ложных срабатываний без риска для денег.
Дальше измерь три вещи: долю запросов, ушедших в усиленный контур; сколько из них проверка заблокировала верно, а сколько - зря; и сколько кейсов усиленная проверка пропустила бы к записи ошибочно. Только после этого имеет смысл давать агенту право на автономную запись, и то - на самых дешёвых и обратимых действиях, а дорогие оставить за человеком. Возврат крупной суммы или отмена группового бронирования - плохие кандидаты на полную автономию на старте.
И держи в голове главную оговорку источника: цифры из препринта - это его бенчмарк, а не прогноз для твоего потока. Свою долю записей, свою частоту ошибок политики и свою экономику ты узнаешь только на собственных данных.
Чего эта схема не решает
Difficulty-routed control - это про то, когда замедлиться перед записью, а не про то, чтобы поддержка стала правильной сама по себе. Несколько честных границ.
Она не чинит плохие правила. Если политика возврата в коде неполная, усиленный контур пропустит ошибку с чистой совестью. Она не заменяет продуктовые и юридические решения: что вообще подлежит возврату - это не задача маршрутизатора. Она не даёт production-гарантий: у нас препринт и бенчмарк, а не отчёт о внедрении. Она не отменяет человека на дорогих и необратимых действиях - как минимум на старте пилота. И она не заменяет автоматизацию бизнес-процессов, on-prem инфраструктуру или те возможности, что доступны только внутри платной подписки конкретного вендора: маршрутизация решает, какой путь выбрать, а не строит за тебя контур интеграций.
FAQ
Это уже можно ставить в прод? По состоянию на 3 июля 2026 это препринт (arXiv 2607.01426) с бенчмарком на human-verified задачах. Механику брать можно, результаты - только через собственный пилот.
Чем difficulty-routing отличается от обычной эскалации? Классическая эскалация переключает на человека по теме или по тону. Здесь граница проходит по последствию действия: читаем состояние - быстрый путь, пишем в backend - усиленная проверка.
Зачем идемпотентный ключ? Чтобы ретрай или двойной клик не создали два возврата на один заказ. Для операций записи это не украшение, а обязательное условие.
Куда девать непонятные запросы? По умолчанию в усиленный контур. Скорость на пограничных формулировках дешевле, чем ошибочная запись в backend.
Где тут экономия? Только если доля запросов на запись мала, и дорогой путь включается редко. Эту долю надо измерить на своих данных до всякой оптимизации затрат.
Если ты хочешь развести лёгкую модель на быстрый контур и тяжёлую на усиленную проверку, не поднимая два разных стека, подключить их через один API provod.ai можно сменой ключа и base_url в привычном OpenAI или Anthropic SDK.
Открой provod.ai, заведи рублёвый баланс через карту, СБП или счёт и собери свой быстрый и усиленный контуры на разных моделях - без VPN и зарубежных карт, с договором и закрывающими документами для бухгалтерии.
Источники
- Препринт (первичное исследование): arXiv 2607.01426 - difficulty-routed control для retail и airline service operations, https://arxiv.org/abs/2607.01426
- Независимый разбор: Neurals Weekly, выпуск от 3 июля 2026, https://neurals.ca/newsletter/2026-07-03/
- Независимый обзор: Moonlight, разбор difficulty-routed control в customer service, https://www.themoonlight.io/en/review/when-should-service-agents-reconsider-difficulty-routed-control-in-customer-service-operations
provod.ai — Russian LLM API aggregator. One OpenAI-compatible endpoint to all flagship models: OpenAI (GPT-5.6, GPT-5.5), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus. Provider prices at the CBR rate, no token markup. Pay in rubles to a Russian legal entity with full closing documents.
Try: provod.ai · model catalog · docs
Top comments (0)