Я — техлид группы разработки шины обмена данными в компании «Передовые Платежные Решения» и неформальный лидер команды внутренних ИИ-проектов. В этой статье делюсь опытом внедрения ИИ с нуля: как за 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 и классификаторов.

Проект начали с простого рабочего контура. За первые три недели:

1. Взяли транскрипты звонков как входные данные.
2. Разработали два классификатора на BERT — для услуг и возражений. Обучили на полутора тысячах транскриптов.
3. Подготовили две векторные базы знаний на FAISS: описание услуг и скрипты отработки возражений.
4. Связали всё через промпты с облачной моделью GPT.
5. За день собрали интерфейс на Django для вывода подсказок.

Через три недели мы представили proof-of-concept бизнесу. Прототип работал с задержкой 10–15 секунд из-за облачной модели, но идея получила зелёный свет. После этого начали дорабатывать систему под требования: скорость, стабильность, интеграции.

От монолита к реальности

Вдохновлённые курсами, мы сначала спроектировали сложный монолитный архитектурный проект, включавший:

• Собственный аудиоконвейер: захват аудио с микрофона и колонок, транскрибация через локальный Whisper. Но это было медленно и нестабильно.
• Несколько классификаторов: параллельная обработка текста для определения услуги и типа возражения. Разметка данных заняла больше всего времени.
• Дообученная LLM: планировали fine-tuning Qwen или Llama на скриптах продаж. Отказались из-за высоких трудозатрат и риска ухудшения качества.
• Самообучающаяся система: успешные ответы должны были попадать в базу знаний и дообучать модель. Но реализация заняла бы 12–18 месяцев.

Мы пересмотрели подход и отказались от всего, что не вписывалось в сроки и требования.

Отказ от fine-tuning

Fine-tuning требовал большого объёма размеченных диалогов. У нас не было ни данных, ни разметчиков. Вместо этого выбрали RAG — Retrieval-Augmented Generation. Модель не учится всему заранее, а получает релевантную информацию из базы знаний в нужный момент.

Это сократило время разработки и снизило риск галлюцинаций.

Отказ от собственной транскрибации

В нашей телефонии Voximplant уже есть встроенный и качественный модуль транскрибации. Мы начали использовать его REST-интерфейс, получая готовые текстовые сегменты.

Это сэкономило минимум 2 месяца разработки и дало стабильный входной поток.

Упрощение классификаторов

Изначально у нас был многоклассовый классификатор возражений. Но после анализа реальных диалогов мы поняли: для MVP важнее не тип возражения, а его наличие.

Заменили классификатор на бинарный (есть/нет). Это резко повысило точность. Детализацией теперь занимается LLM, ищущая релевантные скрипты по ключевым словам.

Запуск на удалённой машине с мощным GPU ускорил обработку.

Замена векторной БД на JSON-словари

Для RAG мы подготовили базы знаний: справочник услуг и скрипты отработки возражений. Объём — несколько мегабайт.

Подключать тяжёлые векторные базы (Weaviate, Qdrant) было избыточно. Вместо этого загрузили структурированные JSON-файлы в память.

Поиск стал быстрым и не требовал сетевых вызовов. Сработал принцип KISS.

Облако vs локальная модель

Сначала тестировали GPT и другие облачные модели. Задержка — 7–20 секунд. Кроме того, ИБ запрещает передавать транскрипты во внешние сервисы.

Решение — развернуть модель на своём сервере. Установили Qwen 8B на GPU-сервер.

Ответы были чуть короче, чем у 32B-версии, но для подсказок этого хватало. Задержка стабилизировалась на уровне 2 секунд, все данные остались внутри периметра.

Вместо CRM — простой интерфейс за день

Интеграция с CRM была бы идеальной, но система переживала миграцию. Чтобы не ждать, бэкендер за день собрал интерфейс на Django: одна кнопка и поле вывода.

Этого хватило, чтобы показать прототип.

Финальная архитектура

Система превратилась в конвейер, отрабатывающий за 2 секунды:

1. Транскрибация через Voximplant → текстовые сегменты.
2. Классификация услуги и бинарная детекция возражения (BERT).
3. Поиск релевантных скриптов в JSON-базе.
4. Генерация подсказки через локальную Qwen 8B.
5. Вывод результата на интерфейс.

Ключевые сложности и решения

Каждый ИИ-проект сталкивается с тремя вызовами: данные, инфраструктура, дедлайны. Вот как мы справились с основными.

Разметка — тонны ручной работы

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

Менеджеры-наставники размечали в разы быстрее. Мы поняли: в живом диалоге главное — понять, есть ли критическое возражение прямо сейчас.

Переформулировали задачу: не «научить ИИ думать», а «дать доступ к нужной информации в нужный момент».

Заменили многоклассовый классификатор на бинарный. Классификацию возражения теперь делает LLM при генерации подсказки. Это чуть увеличило задержку, но ускорило прогресс и улучшило качество.

2 секунды — не пожелание, а физическое ограничение

Подсказка должна приходить за 1,5–2 секунды. Иначе рушится динамика разговора.

Облачные API (GPT, DeepSeek) давали задержку 7–20 секунд. Плюс зависимость от внешней нагрузки и необходимость маскировки данных.

Развернули Qwen 8B на своём GPU-сервере. Ответы уложились в 2 секунды. Пожертвовали детализацией ради скорости и предсказуемости.

Безопасность данных — не бюрократия, а необходимость

Передача транскриптов с персональными данными во внешние сервисы нарушала политики ИБ. Рассматривали PII-маскер, но это добавило бы:

• Месяц разработки для загруженной команды ИБ.
• 200–500 мс задержки на запрос.
• Риск искажения контекста при маскировке.

Согласовали архитектуру с обработкой внутри периметра:

1. Транскрибация — в облаке (Voximplant), но данные приходят в периметр.
2. Обработка текста — на наших серверах.
3. Генерация — локальной моделью на нашем железе.

Решение удовлетворило ИБ и решило проблему скорости.

Сложности связаны между собой

Мы поняли: проблемы взаимосвязаны. Задержки облачных моделей и требования безопасности — нашли единое решение в локальном развёртывании. Сложности с разметкой и скоростью — побеждены упрощением архитектуры.

Мы не боролись с проблемами — перепроектировали систему так, чтобы их не было. Этот подход оказался эффективнее точечных решений.

Метрики по итогам пилота

Технические показатели:

• Средняя задержка — 2 секунды. В 2–3% случаев — до 3 секунд (не критично).
• Точность классификации услуг — более 70%. Достаточно для MVP; знаем, как поднять до 90%.
• Качество распознавания речи — от 92%, зависит от качества связи.

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

Выводы и рекомендации

Поделимся принципами, которые помогли нам и могут быть полезны другим командам.

Лучший ИИ решает конкретную боль

Начинайте не с «что можно сделать с ИИ», а с «какую проблему, которая стоит денег или времени, мы можем решить?».

Когда за технологией видна бизнес-цель, поддержку и ресурсы получить проще.

Чтобы провалидировать идеи, задавайте шесть вопросов:

• Рискуем ли деньгами или чем-то ещё из-за проблемы?
• Повторяется ли она массово?
• Можно ли получить эффект за 6–12 месяцев? Или решить без ИИ быстрее?
• Что даст применение ИИ в этом проекте? (если эффект разовый и дорогой — смысл теряется)
• Можно ли встроить решение в текущие процессы без революции?
• Можно ли масштабировать результат?

Инвестиции в своих людей окупаются

Можно было нанять внешних ML-инженеров. Вместо этого мы обучили своих IT-специалистов.

Получили экспертов, которые понимают ML и глубоко знают бизнес-процессы: CRM, телефонию, ограничения ИБ.

Они говорят на одном языке с заказчиками. Внешний эксперт потратил бы месяцы на погружение.

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

Двигайтесь маленькими, но быстрыми шагами

Ключевой результат — рабочий прототип уже через 3 недели. Пусть с задержкой и простым интерфейсом — но он работал. Это дало команде уверенность, а бизнесу — веру в проект.

Мы придерживались правила: «сначала закройте 90% потребности простым способом». Последовательно отказывались от «важных, но не критичных» функций — fine-tuning, векторные базы, петля обратной связи — ради скорости.

Разбивали путь на короткие итерации с явным результатом. Делали не «идеально», а «работоспособно и полезно».

Коммуникация — часть технического дизайна

Сначала хотели молча разработать решение за несколько месяцев. Вовремя остановились и начали регулярно синхронизироваться с ИБ, инфраструктурой и бизнесом.

Рекомендуем с первого спринта включать ключевых стейкхолдеров: ИБ, инфраструктуру, комплаенс. Короткие демо и встречи раз в 1–2 недели помогают избежать переделок и ускоряют разработку.

Вместо MLOps — ML-стек под задачу

Наш финальный стек: FastAPI, PostgreSQL, локальная LLM, BERT-классификаторы. Без сложных MLOps-пайплайнов на старте.

Это дало контроль над производительностью и безопасностью.

«Коробочное» решение потребовало бы почти столько же усилий по интеграции, но лишило бы гибкости и скорости.

Выбирайте самый простой и контролируемый стек, который решает задачу сейчас. Например, локальная быстрая модель часто лучше облачной — продвинутой, но нестабильной.

Итог

Внедрение ИИ — это больше об инженерной культуре, управлении ожиданиями и умении делать сложные выборы. Главный навык, который мы получили, — отличать must have от could have и без сожаления отказываться от второго ради скорости и результата.

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

Если вы задумываетесь, можно ли стартовать ИИ-проект с бэкенд- или фулстек-разработчиками — наш опыт говорит: да, можно. Но готовьтесь к вызовам не в алгоритмах, а в системном дизайне, инфраструктуре и управлении данными.

Привет, Хабр!Я техлид группы разработки шины обмена данных в компании «Передовые Платежные Решения». И помимо этого, неформальный лидер команды внутренних ИИ проектов. В статье хочу поделиться нашим опытом внедрения ИИ с нуля: как за 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 и классификаторы.

Проект начали с создания хоть и примитивного, но уже рабочего контура. Вот что сделали за первые три недели:

1. Взяли транскрипты звонков (текст) как входные данные.
2. Написали два классификатора на BERT — по услугам и по возражениям. Обучили их примерно на полутора тысячах транскриптов звонков.
3. Подготовили две простые векторные базы знаний FAISS с описаниями услуг и скриптами отработки возражений.
4. Связали всё через промпты с облачной моделью GPT.
5. Набросали за день интерфейс на 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 мс задержки на каждый запрос,
• риск искажения контекста при маскировке важных для понимания сущностей.

В итоге мы согласовали с ИБ иную архитектуру, предусматривающуюполный цикл обработки внутри защищённого периметра компании:

1. Транскрибация — силами нашего провайдера (Voximplant). Это единственное, что происходит в облаке, а не в периметре. Из облака в периметр приходят запросы с транскрибациями.
2. Обработка текста — на наших серверах.
3. Генерация ответов — локальной моделью на нашем железе.

Это решение одновременно удовлетворило строгие требования безопасностиирешило проблему скорости — за счёт отказа от облачных моделей.

Сложности связаны между собой

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

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

Метрики по итогам пилота

Технические метрики:

• Средняя задержка формирования подсказки —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»и без сожаления отказываться от второго ради скорости и результата.

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

Если вы задумываетесь, можно ли стартовать ИИ-проект с существующей командой бэкенд- или фулстек-разработчиков — наш опыт говорит: да, можно. Но я бы советовал готовиться к неочевидным вызовам, которые лежат не в плоскости алгоритмов, а в системном дизайне, инфраструктуре и управлении данными.