Гибридная схема — это система, в которой большую часть потока обрабатывают обычные детерминированные правила, а языковая модель включается только на том, что правила не смогли закрыть. В модельном примере этой статьи через модель проходит 22 % обращений вместо 100 %, и месячная эксплуатация падает со 102 200 ₽ до 59 320 ₽ при том же качестве ответа.
Такую архитектуру редко предлагают в коммерческих предложениях, и причина не в технической сложности. Гибрид дешевле в эксплуатации, а значит, дешевле в сопровождении: подрядчику выгоднее продать вариант, где каждое обращение идёт через модель, потому что он и звучит современнее, и стоит дороже в месяц. Плюс к тому детерминированный слой — это скучная работа: разобрать сто типовых формулировок, привести номера заказов к одному виду, вычистить справочник. Она не показывается на демонстрации.
Ниже — устройство трёх слоёв, точная граница между ними, расчёт экономии с разбивкой по строкам, порог потока, ниже которого гибрид не нужен, и два требования к техзаданию, без которых схема через год перестаёт быть выгодной.
Три слоя и что отсекается на каждом
Слои идут строго по возрастанию цены обработки. Каждое обращение сначала пытается закрыться самым дешёвым способом и уходит наверх, только если внизу не получилось.
- 1Слой 1. Нормализация и правила
Сообщение приводится к единому виду независимо от канала: кто написал, когда, телефон, номер заказа, артикул, дата. Сущности вытаскиваются справочниками и шаблонами, а не моделью: «заказ 45219», «№45219», «45219» и «заказ от 12.08» — это один и тот же номер. Дальше срабатывают правила: если в тексте найден номер заказа и он есть в базе, ответ о статусе собирается из полей учётной системы. Стоимость обработки — доли копейки, ответ воспроизводим до символа.
- 2Слой 2. Маршрутизатор
Решает, что делать с тем, что не закрылось правилами. Смотрит на три признака: распознана ли сущность и найдена ли она в базе; попадает ли тема в список известных; нет ли в обращении стоп-темы. По совокупности отправляет обращение либо назад к правилам с уточняющим вопросом, либо в модель, либо сразу человеку. Каждое решение маршрутизатора пишется в журнал с указанием причины — без этого через месяц невозможно понять, почему поток уехал в дорогой слой.
- 3Слой 3. Модель с базой знаний
Получает только то, что действительно требует свободного текста: жалобы, нестандартные просьбы, комбинации условий, разбор присланного документа. Отвечает по базе знаний со ссылкой на источник, работает в цикле с проверкой результата и имеет те же числовые границы и стоп-темы, что и любой агент. Стоимость обработки — рубли за обращение.
Вертикальная схема снизу вверх. Внизу широкий блок «Слой 1: нормализация и правила» с подписью «10 000 обращений на входе, закрывает 7 800 — 78 %». Над ним блок «Слой 2: маршрутизатор» с тремя подписанными признаками: «сущность найдена в базе», «тема в списке известных», «стоп-тема». От маршрутизатора три стрелки: влево «назад к правилам с уточнением», вверх «Слой 3: модель с базой знаний — 2 200 обращений, 22 %», вправо «сразу человеку». У каждого слоя сбоку подписана цена обработки: «доли копейки», «доли копейки», «3,2 ₽ за обращение». Чертёжный стиль, подписи по-русски.
Часть системы, которая на одном и том же входе всегда выдаёт один и тот же выход. Правило «нашёл номер заказа — верни поля статуса и даты из учётной системы» детерминировано: его результат можно записать в тест и сравнивать посимвольно. Модель недетерминирована по устройству: на один и тот же вопрос она даёт разные по формулировке ответы, и проверять её приходится по смыслу, а не по строке.
Где именно проходит граница
Граница между слоями определяется одним вопросом: где лежит правильный ответ. Если он лежит в поле базы данных или в справочнике — это правила. Если его надо собрать из текста, взвесить условия или проявить хоть какую-то интерпретацию — это модель. Всё остальное — вопрос удобства, а не архитектуры.
| Обращение | Слой | Почему | Риск при передаче модели |
|---|---|---|---|
| «Где мой заказ 45219?» | Правила | Ответ однозначно лежит в полях заказа | Плата за вызов плюс шанс, что дата будет пересказана неточно |
| «Есть артикул 3-105 в наличии?» | Правила | Точное совпадение по справочнику номенклатуры | Округление или подмена числа остатка при пересказе |
| «Пришлите реквизиты и адрес склада» | Правила | Константа справочника, меняется раз в год | Ответ из устаревшего документа в базе знаний |
| «Перенести запись на четверг после 16:00» | Правила плюс подтверждение | Свободные слоты и коридор дат берутся из расписания | Предложение слота, которого нет в расписании |
| «Товар пришёл битый, что делать» | Модель | Свободная формулировка, нужен маршрут и человеческий тон | — |
| «Можно оплатить частями и отгрузить на другой адрес?» | Модель | Комбинация нестандартных условий, готового поля нет | — |
| «Вот скан накладной, посмотрите вес» | Модель | Разбор присланного документа | — |
| Возврат денег, жалоба на сотрудника, вопрос о здоровье | Ни один: сразу человеку | Стоп-тема, цена ошибки выше выигрыша | — |
Первые четыре строки — это и есть те самые 78 % в типичной клиентской переписке. Доля зависит от бизнеса: в оптовой торговле и у сервисных компаний она уходит к верхней границе диапазона 70–85 %, потому что поток однородный, а в консалтинге и сложных B2B-продажах падает ниже 50 %, и там гибрид почти не даёт выигрыша. Считать её надо по своей выгрузке за три месяца, а не брать из статьи. Как разложить входящий поток по темам до начала проекта, разобрано в статье про классификацию обращений клиентов.
Если в системе есть поле «статус заказа» и в нём написано «передан в доставку 12.08», то любая обработка этого факта моделью может только ухудшить результат: добавить вежливости она может, точности — нет, а вот перепутать дату или пересказать статус своими словами вполне. Модель имеет смысл там, где готового поля не существует.
Считаем на потоке 10 000 обращений в месяц
Модельная компания: интернет-магазин с собственным складом, 10 000 обращений в месяц из четырёх каналов, база знаний на 340 документов, уровень автономности — действие с подтверждением. Сравниваем два варианта одной и той же системы: в первом каждое обращение идёт через модель, во втором работает гибрид с долей правил 78 %. Удельные величины взяты те же, что и в разборе стоимости одного обращения: 3,2 ₽ переменной части на обращение и 700 ₽/час полной ставки оператора.
Обратите внимание, где именно возникает экономия. Вызовы модели дают 24 960 ₽ из 42 880 ₽ — чуть больше половины. Остальное приходится на две строки, о которых в презентациях не говорят: выборочный контроль и перепроверка после обновления модели. Проверять надо только недетерминированные ответы, а их в гибриде в четыре с половиной раза меньше, поэтому и часы контроля падают пропорционально.
Две вертикальные столбчатые диаграммы с накоплением, ось Y в рублях за месяц. Левый столбец «Всё через модель — 102 200 ₽» с сегментами: вызовы модели 32 000, инфраструктура 12 000, сопровождение 25 000, контроль 14 000, база знаний 7 200, перепроверка версий 12 000. Правый столбец «Гибрид — 59 320 ₽» с сегментами: вызовы модели 7 040, инфраструктура 12 000, сопровождение 27 000, контроль 3 080, база знаний 7 200, регрессионный прогон 3 000. Между столбцами скоба с подписью «42 880 ₽/мес». Все сегменты подписаны по-русски.
Теперь про цену самой надстройки. Гибрид требует работы, которой нет в обычной смете агента: нормализация входящего сообщения, набор детерминированных правил, маршрутизатор с журналом решений и автотесты на детерминированный слой. В модельном проекте это 180 000 ₽ сверх базовой сметы: 45 000 ₽ на нормализацию, 60 000 ₽ на 24 правила по частым темам, 45 000 ₽ на маршрутизатор и 30 000 ₽ на 120 регрессионных тестов. При экономии 42 880 ₽ в месяц надстройка окупается за 4,2 месяца.
Побочный выигрыш: слой, который можно протестировать
Экономия на вызовах модели — не главная причина строить гибрид. Главная в том, что детерминированный слой воспроизводим, а значит, его можно закрыть автотестами раз и навсегда. 120 тестов на правила — это 120 пар «входящее сообщение → ожидаемый ответ», которые прогоняются за минуты и сравниваются посимвольно. Тест либо зелёный, либо красный, никаких оценок «в целом похоже».
Это меняет эксплуатацию системы сильнее, чем кажется. В варианте «всё через модель» любое изменение — новая версия модели у провайдера, правка промпта, обновление базы знаний — требует ручной перепроверки на наборе случаев, потому что ответ каждый раз формулируется заново. В гибриде та же смена версии модели затрагивает только 22 % потока, а по остальным 78 % достаточно прогнать автотесты. Разбор того, как ведут себя тесты промптов и почему они принципиально мягче, — в статье про версионирование и тесты промптов.
| Что проверяем | Детерминированный слой | Модельный слой |
|---|---|---|
| Как формулируется тест | Вход → точный ожидаемый ответ | Вход → набор обязательных фактов и запретов |
| Чем сравнивается результат | Посимвольно, автоматически | Человеком или второй моделью, по смыслу |
| Время прогона 120 случаев | Минуты, без участия человека | 3–5 часов работы методиста |
| Что ловит смена версии модели | Ничего: слой её не касается | Изменение тона, длины, полноты ответа |
| Что ловит правка справочника | Падение конкретных тестов сразу | Ничего: расхождение всплывёт по жалобе |
| Цена одного полного прогона | Около 3 000 ₽ вместе с разбором падений | 12 000 ₽ и календарный день |
Самый неприятный сценарий эксплуатации выглядит так: в справочнике поменяли условия доставки, система продолжает отвечать по-старому, ошибка обнаруживается через три недели по жалобе клиента и разбирается ещё неделю. В детерминированном слое такая правка ломает конкретный тест в тот же день, с указанием, какое именно правило перестало сходиться. В чисто модельной схеме её не поймает ничто, кроме выборочного контроля, а выборка — это 4 % обращений.
Два требования в ТЗ, без которых схема стареет за год
Гибрид выгоден до тех пор, пока его можно менять по частям. Ломается это в двух местах: когда меняется канал связи и когда меняется поставщик модели. За последние полтора года в России произошло и то и другое, поэтому оба требования стоит записать в техзадание заранее, а не в момент, когда выбора уже нет.
Требование, по которому любое входящее сообщение приводится к единому внутреннему виду до того, как попадает в слой правил. Ни правила, ни маршрутизатор, ни модель не знают, из какого мессенджера пришло обращение, — они видят одинаковую структуру. Подключение нового канала сводится к одному адаптеру. Подробно механику переезда мы разбирали на примере перевода клиентских коммуникаций на MAX.
Требование, по которому обращение к модели идёт через собственный внутренний интерфейс, а не напрямую в конкретный сервис. Промпты, ограничения и разбор ответа лежат у вас, а конкретный провайдер — GigaChat, YandexGPT, локальная модель на своём сервере — подключается адаптером. Смена поставщика при этом стоит недели и прогона тестов, а не переписывания системы.
Оба требования добавляют к проекту около 40 000–50 000 ₽ и примерно неделю работы. Проверить их наличие можно одним вопросом на приёмке: «покажите, где в коде указан конкретный мессенджер и конкретный поставщик модели». Если ответ — «в одном файле настроек и в одном адаптере», абстракция есть. Если конкретные названия рассыпаны по обработчикам, следующая замена обойдётся в полную стоимость связки. Сценарии на случай ограничений канала мы собрали отдельно — план Б, если канал связи ограничат.
Карта архитектуры в три зоны. Слева четыре узла каналов: MAX, Telegram, почта, форма сайта, каждый через маленький блок «адаптер». В центре широкий блок «Ядро: нормализация, 24 правила, маршрутизатор, журнал решений» с пометкой «78 % потока не покидает ядро». Справа три узла моделей: GigaChat, YandexGPT, локальная модель на своём сервере, каждый через блок «адаптер провайдера». Подписи на стрелках: слева «единый формат сообщения», справа «единый формат запроса к модели». В углу пометка «абстракции: 40 000–50 000 ₽ и одна неделя».
Порядок сборки: правила пишутся по журналу, а не по памяти
Самая частая ошибка при переходе на гибрид — собраться и придумать двадцать четыре правила. Придуманные правила почти всегда покрывают темы, которые кажутся частыми: их называют по памяти руководитель отдела и старший менеджер. Реальная частота выглядит иначе, и расхождение обычно составляет два-три раза по верхним темам. Порядок должен быть обратным: сначала журнал, потом правила.
- 1Месяц-два копить журнал. Система работает как есть — через модель, через людей или в смешанном режиме, — но каждое обращение записывается с темой, каналом, длительностью и указанием, откуда взялся ответ: из поля базы, из базы знаний или из головы сотрудника. Без этого шага любой процент доли правил — предположение.
- 2Разложить по темам и отсортировать по частоте. В однородном потоке 20 тем обычно закрывают около 80 % обращений, и уже на этом шаге видно, где вообще есть смысл что-то автоматизировать. Здесь же отсекаются темы-призраки: то, что все вспоминают, но что случается трижды в квартал.
- 3Отобрать темы, у которых ответ лежит в поле базы. Это и есть кандидаты в правила. Частая тема, ответ на которую нужно собирать из свободного текста, в правила не идёт, какой бы частой она ни была: детерминированное правило на неоднозначном ответе даёт уверенные ошибки вместо честной эскалации.
- 4Писать правило и тест одновременно. Каждое новое правило приходит в систему вместе с пятью-десятью примерами формулировок и ожидаемым ответом. Это не бюрократия: именно из этих пар потом складывается тот самый набор регрессионных тестов, который позволяет менять модель, не проверяя руками 78 % потока.
У такого порядка есть побочный эффект, ради которого его стоит соблюдать, даже если гибрид в итоге не построят. Разложенный по частоте журнал обращений — это карта того, на чём стоит очередь в вашей компании. В половине случаев после такой раскладки выясняется, что самая частая тема закрывается не автоматизацией, а исправлением процесса: например, три четверти вопросов «где мой заказ» возникают потому, что клиенту вообще не приходит уведомление об отгрузке. Уведомление стоит одного дня работы, агент — сотен тысяч рублей.
Когда гибрид не нужен
Надстройка стоит денег и не масштабируется вниз: маршрутизатор на 1 000 обращений в месяц устроен так же сложно, как на 10 000, а экономит в четыре раза меньше. Ниже — та же экономия, посчитанная на разных потоках при неизменной надстройке в 180 000 ₽.
| Обращений в месяц | Экономия гибрида | Окупаемость надстройки в 180 000 ₽ |
|---|---|---|
| 10 000 | 42 880 ₽/мес | 4,2 месяца |
| 5 000 | 24 940 ₽/мес | 7,2 месяца |
| 3 000 | 17 760 ₽/мес | 10,1 месяца |
| 1 500 | 12 380 ₽/мес | 14,5 месяца |
График с двумя осями. Ось X — поток обращений в месяц: 1 500, 3 000, 5 000, 10 000. Левая ось Y — экономия в рублях в месяц, столбцы: 12 380, 17 760, 24 940, 42 880. Правая ось Y — окупаемость надстройки в 180 000 ₽ в месяцах, линия: 14,5, 10,1, 7,2, 4,2. Вертикальная штриховая линия на отметке 3 000 подписана «порог: дальше окупаемость дольше десяти месяцев». Все числа подписаны на графике, единицы указаны на осях.
- Поток ниже 3 000 обращений в месяц. Надстройка окупается дольше десяти месяцев, а поддерживать приходится вдвое больше кода. На таких объёмах разумнее выбрать что-то одно: либо правила без модели вообще, либо простой агент без маршрутизатора.
- Поток однородный настолько, что модель не нужна. Если 95 % обращений — это четыре одинаковых вопроса, вам нужен не гибрид, а обычный скрипт. Порог, за которым появляется смысл в модели, разобран в статье ИИ-агент или автоматизация по правилам.
- Поток неоднородный настолько, что правила не за что зацепить. В сложных B2B-продажах и в консалтинге доля типовых обращений падает ниже 50 %, и 24 правила покроют не 78 %, а 30 % потока. Экономия при этом падает более чем вдвое, а надстройка стоит столько же.
- Нет справочников в порядке. Правила работают на точных данных: артикул, номер заказа, слот в расписании. Если номенклатура дублируется, а телефоны записаны в свободной форме, детерминированный слой начнёт ошибаться чаще модели. Сначала — порядок в данных, и только потом маршрутизация; о том, что именно приводится в порядок, — в разборе данных перед внедрением.
И честная оговорка про сам расчёт. 42 880 ₽ в месяц — это экономия на эксплуатации системы, которая в любом случае должна окупаться сама по себе. Если агент на вашем потоке не окупается в чистой схеме, гибрид не сделает его выгодным: он уменьшает расходы примерно вдвое, но не превращает минус в плюс там, где поток слишком мал. Порядок решений всегда один — сначала объём, потом архитектура.
Модель — дорогой инструмент. Её включают там, где готового поля в базе не существует, и не включают там, где оно есть.
