Привет, Хабр!
Я техлид группы разработки шины обмена данных в компании «Передовые Платежные Решения». И помимо этого, неформальный лидер команды внутренних ИИ проектов. В статье хочу поделиться нашим опытом внедрения ИИ с нуля: как за 6 месяцев команда из 12 разработчиков (backend, без опыта с ML/ AI) создала и вывела в пилот голосового ИИ-ассистента.
Статья может быть полезна компаниям, которые с интересом смотрят на внедрение ИИ, и выбирают между «сделать самим» или «нанять/ привлечь экспертизу со стороны». Или хотят сделать похожий внутренний продукт.
Технические параметры ассистента:
Задача: классификация услуг + детекция возражений → RAG → генерация ответа.
Входные данные: поток текстовых сегментов от встроенного транскрайбера телефонии.
Задержка: строго 1,5–2 секунды на генерацию ответа.
Стек: Python, FastAPI, PostgreSQL, дообученные BERT, локальная Qwen 8B.
Архитектура: on-premise (требование ИБ), интеграция с Voximplant API.
Далее подробно разберу эволюцию от переусложнённого монолита до работающей схемы. Поделюсь техническими компромиссами, на которые пришлось пойти ради скорости. И практическими выводами для команд, которые начинают путь в ИИ без опытных data scientists в штате.
О проекте
«Суфлёр» — это голосовой ИИ-ассистент, который в реальном времени помогает менеджерам по продажам и сервису во время звонков с клиентами. «Суфлёр» анализирует диалог, распознаёт, о каком продукте идёт речь, определяет наличие возражений в диалоге и мгновенно выдаёт релевантную текстовую подсказку на экран менеджеру.
В нашей экосистеме более 35 продуктов. Это огромный массив информации, который нужно держать в голове менеджеру, чтобы эффективно работать с возражениями и закрывать сделки. B2B-цикл длинный, и важно, чтобы на каждом этапе диалога с клиентом у сотрудника были под рукой релевантные скрипты и аргументы. AI-ассистент помогает повысить эффективность продаж за счет лучших практик, зашитых в модель. А также сократить время выхода новых сотрудников на KPI.
Этапы разработки: от обучения до прототипа
Путь от первых идей о применении ИИ в компании до полноценного MVP первого ИИ-проекта занял около двух лет. Ключевая фаза активной разработки уложилась в 6 месяцев.
12 наших инженеров (бэкенд, тимлиды и техлиды команд) прошли обучение и с нуля освоили архитектуру нейросетей, работу с LLM, эмбеддинги и векторные базы. К концу обучения у нас была команда с общим пониманием, что такое RAG, fine-tuning и классификаторы.
Проект начали с создания хоть и примитивного, но уже рабочего контура. Вот что сделали за первые три недели:
Взяли транскрипты звонков (текст) как входные данные.
Написали два классификатора на BERT — по услугам и по возражениям. Обучили их примерно на полутора тысячах транскриптов звонков.
Подготовили две простые векторные базы знаний FAISS с описаниями услуг и скриптами отработки возражений.
Связали всё через промпты с облачной моделью GPT.
Набросали за день интерфейс на Django, куда выводилась подсказка.
Через три недели с помощью этого proof-of-concept мы успешно защитили идею перед бизнесом, хоть прототип из-за облачной модели и давал подсказки с задержкой в 10–15 секунд. Уже получив зелёный свет, мы стали доводить прототип до требований, описанных в начале статьи, улучшать стабильность, интерфейс и прорабатывать интеграции.
Архитектура проекта: от монолита к реальности
Вдохновлённые учебными курсами, мы в первый месяц нарисовали большой монолитный проект, который включал:
Собственный аудиоконвейер. Набросали приложение, которое просто захватывает аудиопоток с микрофона и колонок. Тестировали на звонках в Zoom. Здесь зарыты часы работы с лагами и качеством: Whisper для транскрибации мы локально разворачивали на каждой машине, что в итоге работало довольно медленно.
Несколько классификаторов. Полученный текст параллельно отправляется в две нейросети: одна определяет одну из 15+ услуг, другая — один из 15+ типов возражений. Для каждой нужны свои датасеты, разметка, настройка. Разметка в итоге заняла больше всего времени.
Дообученная LLM. Мы планировали взять большую языковую модель (Qwen или Llama) и дообучить её через fine-tuning на наших скриптах продаж. Модель самостоятельно готовила бы подсказку на основе данных из RAG. Но оценили трудозатраты и риски ухудшения качества данных, и в итоге отказались от этой идеи.
Векторная база знаний с петлёй обратной связи. Все успешные ответы должны были автоматически попадать в базу знаний, на которой обучалась бы модель — получился бы самообучающийся контур.
Но срок реализации проекта в такой версии стал бы 12–18 месяцев, а риск провала был довольно высок. Мы оценили разные варианты, и отбросили те, что не вписывались в критерии.
Отказываемся от fine-tuning
Fine-tuning требовал большого объема верно размеченных диалогов. А у нас не было ни диалогов, ни разметчиков, и для разметки потребовалось бы очень много времени. Поэтому вместо тяжёлой модели мы решили использовать более простой и контролируемый подход — RAG (Retrieval-Augmented Generation, генерация, дополненная поиском). То есть не учить модель всему с нуля, а давать ей в нужный момент релевантную информацию из нашей базы знаний. Так мы сэкономили время на разработку, и снижали риск галлюцинаций модели.
Отказываемся от своей транскрибации
В нашей телефонии Voximplant уже есть встроенный и хорошо работающий модуль транскрибации. REST-запросами из него можно получать готовые текстовые сегменты. Если бы мы писали и обрабатывали свой аудиотракт (как сначала хотели), удлинили бы разработку минимум на 2 месяца. А с Voximplant сразу получили на вход чистый и правильный текст.
Упрощаем классификаторы до предела
Наш дуэт классификаторов оказался неповоротливым. После анализа реальных диалогов мы поняли, что для первого MVP главное — не тип возражения, а его наличие. И заменили многоклассовый классификатор возражений на бинарный (есть/нет). Это в разы увеличило точность ответов. Детализацией типа возражения теперь занимается LLM, которая просто ищет релевантные скрипты по ключевым словам из диалога. Ускорили мы это все через запуск на удаленной машине с мощным видеоускорителем.
Меняем векторную БД на словари
Мы подготовили базы знаний для RAG — справочник услуг и базу скриптов отработки возражений. Получилось несколько мегабайт текста. Подключать для них тяжёлую векторную базу типа Weaviate или Qdrant было избыточно. Так что мы просто загрузили структурированные JSON-файлы в память. Поиск по JSON-файлам быстрый и не требует сетевых запросов. Сработал принцип KISS.
Облако vs локальная модель
Изначально мы тестировали GPT и другие облачные модели. Но получили результат, который нас не устроил: задержку ответа от 7 до 20 секунд. К тому же, ИБ запрещает отправлять транскрипты настоящих диалогов во внешние сервисы.
Оставалось ставить модель на свое железо. Мы получили сервер с GPU и развернули Qwen 8B. Её ответы были чуть лаконичнее, чем у 32B-версии, но для подсказок менеджеру это подходило. Задержка стабилизировалась примерно на двух секундах, а все данные остались в контуре.
Вместо CRM — HTML-страница за день
Нам хотелось интегрировать подсказки прямо в интерфейс CRM, но в тот момент он переживал миграцию. Чтобы не ждать долго, наш бэкендер за день накодил интерфейс на Django — с одной кнопкой и полем для вывода ответа. Теперь можно было показывать прототип.
Финальная архитектура
В итоге наша система превратилась в конвейер, который отрабатывал за 2 секунды:
С какими сложностями мы столкнулись и как справились
Каждый ИИ-проект сочетает как минимум три вида проблем — с данными, с инфраструктурой и с дедлайнами. Наш путь не был исключением. Расскажу чуть подробнее о трех ключевых вызовах, которые заставили нас пересмотреть подходы и найти нестандартные решения.
Разметка — это тонны ручной работы
Теория машинного обучения предписывает итеративный процесс: сбор данных, их очистка и анализ, обучение модели, а затем возврат к данным для улучшения результата. Мы взяли 200 записей звонков, разделили их между 12 участниками команды (напомню, разметчиков в ней не было) и... уперлись в стену.
Оказалось, что разметка диалогов — это кропотливый и медленный процесс, требующий в том числе личной оценки и экспертизы. Нужно не просто выделить фразы, а понять контекст возражения, классифицировать его по сложной схеме и оценить реакцию менеджера. Менеджер-наставник, погруженный в процесс продаж, анализирует данные в разы быстрее, чем разработчики.
Мы освободили проект от долгой разметки, когда поняли: в сложной фазе диалога с клиентом менеджеру в первую очередь нужно понимать, есть ли критическое возражение прямо сейчас.
Эта мысль помогла нам переформулировать задачу с «научить ИИ думать» на «дать ИИ доступ к нужной информации в нужный момент». Мы заменили многоклассовый классификатор с более чем 15 типами возражений на бинарный детектор — есть возражение или нет. А классификацию возражения переложили на LLM, пока она готовит рекомендацию. Это чуть увеличило время ответа, но было быстрее и качественнее, чем продолжать итеративно мучить BERT.
Две секунды — не пожелание, а физическое ограничение диалога
Подсказка оператору должна приходить за 1,5–2 секунды, и любая задержка здесь разрушает динамику живого разговора. Наши первые эксперименты с облачными API (OpenAI GPT, DeepSeek и другие) были неутешительны. В среднем ответ приходил за 7–10 секунд, иногда за 3, а иногда и за 20. К тому же мы здесь полностью зависели от нагрузки сторонних сервисов. Облачные модели при всей своей мощности слишком медленны и нестабильны для нашей задачи в реальном времени. Они требуют прокси для запросов, а также инжекторов для маскировки чувствительных данных.
Как упоминалось выше, мы развернули локальную языковую модель на выделенном GPU-сервере. Qwen 32B выдавала качественные и детальные ответы, но за 5–7 секунд. Qwen 8B — более короткие, но при этом содержательные, да еще и укладывалась примерно в 2 секунды. Так что мы пожертвовали красноречием модели ради скорости и предсказуемости.
Безопасность данных — не бюрократия, а необходимость
Передача транскриптов телефонных разговоров с потенциальными персональными данными во внешние облачные сервисы нарушала наши внутренние политики. Прежде чем прийти к финальному решению, мы рассматривали внедрение PII-маскера — инжектора для скрытия чувствительных данных. Но это грозило новыми проблемами:
плюс месяц на разработку и интеграцию — причем для сильно загруженной команды ИБ,
дополнительные 200–500 мс задержки на каждый запрос,
риск искажения контекста при маскировке важных для понимания сущностей.
В итоге мы согласовали с ИБ иную архитектуру, предусматривающую полный цикл обработки внутри защищённого периметра компании:
Транскрибация — силами нашего провайдера (Voximplant). Это единственное, что происходит в облаке, а не в периметре. Из облака в периметр приходят запросы с транскрибациями.
Обработка текста — на наших серверах.
Генерация ответов — локальной моделью на нашем железе.
Это решение одновременно удовлетворило строгие требования безопасности и решило проблему скорости — за счёт отказа от облачных моделей.
Сложности связаны между собой
Один из ценных уроков проекта — в том, что ключевые проблемы были взаимосвязаны. Казалось, что задержки облачных моделей и требования информационной безопасности — это разные вызовы, но они оба нашли единое решение в локальном развёртывании. Сложности в разметке данных и низкая скорость были побеждены через радикальное упрощение архитектуры.
Мы не боролись с проблемами, а перепроектировали систему так, чтобы эти проблемы в ней не возникали. Этот подход оказался эффективнее любого точечного решения.
Метрики по итогам пилота
Технические метрики:
Средняя задержка формирования подсказки — 2 секунды. В 2–3% случаев подскакивало до 3 секунд, но это не критично.
Услуги классифицировались «Суфлёром» с точностью более 70%. Для MVP этого достаточно, и мы знаем, как увеличить этот показатель до 90%.
Качество распознавания речи — от 92% в зависимости от качества связи.
«Суфлёр» прошел обкатку в пилотной группе и показал первые качественные и количественные результаты (обратную связь, юзабилити, снижение нагрузки на наставников и пр.). Но для статистически значимых цифр по конверсии и KPI нужно время и масштабирование на все команды. Сейчас мы сфокусированы на доработке архитектуры и бесшовной интеграции в CRM. Как только накопим чистые данные на потоке — обязательно вернемся с цифрами.
Выводы и рекомендации
Поделюсь принципами, которые, на наш взгляд, будет полезно учесть командам, начинающим подобный путь внедрения ИИ.
Лучший ИИ — тот, что решает конкретную боль, а не демонстрирует технологию
Начинайте не с вопроса «Что мы можем сделать с ИИ?», а с вопроса «Какую конкретно проблему, которая сейчас стоит денег или времени, мы можем решить? И стоит ли ее вообще решать с помощью ИИ?». Когда за технологией видна бизнес-цель, которую она достигает, то поддержку и ресурсы предоставят с большей вероятностью.
Чтобы провалидировать все идеи, к которым хочется прикрутить ИИ, мы рекомендуем анализировать каждую с помощью шести вопросов:
Рискуем ли мы деньгами или чем-то еще из-за проблемы прямо сейчас?
Повторяется ли проблема массово?
Можно ли с внедрением ИИ получить эффект в течение 6–12 месяцев? Или решение можно найти без ИИ, и за сроки короче?
Что в дальнейшем нам даст применение в этом проекте ИИ? (если это разовый кейс применения, который к тому же обошелся дороже, то какой смысл в ИИ)
Можно ли встроить решение в текущие процессы без революции?
Можно ли масштабировать результат?
Инвестиции в своих людей окупаются синергией, которую не купить на стороне
В нашем случае можно было нанять дорогих внешних ML-инженеров вендора и долго погружать их в свой бизнес. Вместо этого мы решили инвестировать в обучение своих проверенных и заинтересованных IT-специалистов. Так мы получили экспертов, которые достаточно владеют ML, а главное — глубоко понимают внутренние процессы.
Важней всего интегрировать ИИ в процессы, что уже работают в компании, а для этого нужно хорошо владеть этими процессами. Наша команда уже знала внутреннюю кухню: как устроена CRM, как работает телефония, какие есть ограничения у ИБ. Они говорили на одном языке с бизнес-заказчиками, потому что сами годами решали их задачи. Внешний эксперт потратил бы месяцы только на погружение в контекст.
Мы рекомендуем рассматривать внутренние ИИ-проекты не только как способ получить продукт, но и как инструмент развития экспертизы и удержания талантов. Команда, которая вырастила решение с нуля, будет его защищать, развивать и масштабировать с эффективностью, недостижимой для внешних подрядчиков.
Движение маленькими, но быстрыми шагами
На мой взгляд, ключевой результат нашей команды не в самом продукте (мы не первые, кто делает ИИ-ассистента). А скорее в том, что мы показали работающий прототип уже через 3 недели. Пусть и с задержкой в 15 секунд, пусть с интерфейсом на скорую руку — но он работал. Классика Agile :) Это дало команде веру в свои силы, а бизнесу — уверенность, что мы движемся в верном направлении.
Мы придерживались подхода «сначала закройте 90% потребности простым способом». Последовательно отказывались от «важных, но не критичных» функций — fine-tuning, векторные базы, петля обратной связи — чтобы сохранить критичную - скорость.
Нам оказалось полезно разложить путь на короткие итерации с явным результатом в конце каждой. И делать не «идеально», а «работоспособно и полезно».
Коммуникация со смежными командами — необходимая часть технического дизайна
Вначале мы хотели показать бизнесу уже готовое решение, а до этого несколько месяцев плотно заниматься разработкой. Но вовремя остановились и стали проводить регулярные синхронизации с ИБ, отделом инфраструктуры и бизнес-заказчиком.
Мы рекомендуем с самого первого спринта включать в процесс ключевых стейкхолдеров: ИБ, инфраструктуру, комплаенс и пр. Короткие демо и уточняющие встречи раз в неделю-две перестрахуют от экстренных переделок на финишной прямой. И, в конечном счете, ускорит разработку и сократит возможные риски, как было в нашем случае.
Вместо MLOps - ML-стек под конкретную задачу
Наш финальный техстек: FastAPI, PostgreSQL, локально запущенная легкая LLM, классификаторы на базе BERT. Без сложных MLOps-пайплайнов на первом этапе. Это помогло получить контроль над производительностью и безопасностью.
«Коробочное» решение потребовало бы от нас 60–80% тех же усилий по интеграции, адаптации данных и встраиванию в процессы, но лишило бы гибкости, скорости изменений и применения накопленной экспертизы.
Выбирайте самый простой и контролируемый стек, который может решить задачу сейчас. Например, локальная и быстрая модель часто лучше облачной — продвинутой, но нестабильной.
На мой взгляд, внедрение ИИ — это больше об инженерной культуре, управлении ожиданиями и умении делать сложные выборы. Важный навык, который мы с коллегами получили благодаря кейсу «Суфлёра», — способность отличать «must have» от «could have» и без сожаления отказываться от второго ради скорости и результата.
Команда проекта прошла путь от группы разработчиков до внутреннего центра компетенций, который тиражирует успешный опыт на новые бизнес-задачи. Например, сейчас мы планируем адаптировать «Суфлера» для работы с оттоком - и это только один из многих внутренних ИИ-проектов. Считаю, это тоже ценный результат.
Если вы задумываетесь, можно ли стартовать ИИ-проект с существующей командой бэкенд- или фулстек-разработчиков — наш опыт говорит: да, можно. Но я бы советовал готовиться к неочевидным вызовам, которые лежат не в плоскости алгоритмов, а в системном дизайне, инфраструктуре и управлении данными.
