под капотом

Под капотом: как устроено направление AI в Mervey

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

Автор: Манапова Гульдана
Опубликовано: 24 августа 2026 г.

СерияПод капотом · 1

Первым берём AI — направление, вокруг которого сегодня больше всего ожиданий и меньше всего конкретики.

Запрос звучит одинаково, задачи за ним стоят разные

Заметная часть входящих обращений начинается с одной и той же фразы: нам нужен AI. За ней почти всегда стоит что-то гораздо более конкретное. Поддержка не справляется с потоком однотипных вопросов и отвечает клиентам на сутки позже, чем обещает. Юристы вручную вычитывают сотни однотипных договоров ради трёх пунктов, которые в них меняются. Руководитель собирает еженедельный отчёт из четырёх систем и почтовой переписки, тратя на это половину рабочего дня. Это разные задачи с разной экономикой, и объединяет их только предполагаемое решение. Поэтому наша работа обычно начинается не с выбора модели, а с обратной операции: мы разбираем общий запрос на конкретные задачи и говорим прямо, какие из них модель решает лучше человека, какие решает частично и требует проверки, а какие вообще не нуждаются в машинном обучении. Последний ответ клиенты слышат от нас регулярно, и мы считаем это нормальной частью работы, а не потерянным контрактом.

Три признака, по которым задача проходит отбор

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

Модель — самая маленькая часть системы

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

Качество, периметр и стоимость

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

Система должна оказаться там, где человек уже работает

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