Привет, Хабр читатели!
Меня зовут Алексей, и я руковожу направлением искусственного интеллекта в одном из крупнейших федеральных холдингов России — более 15k сотрудников, работающих от Калининграда до Владивостока. Компания — лидер в своей отрасли, обладает развитой автоматизацией, но не является IT-компанией. И это меняет всё.
Сегодня я хочу поделиться не просто тем, что мы сделали — а как мы это сделали. Потому что в крупной организации внедрение ИИ — это не про алгоритмы, а про людей, их страхи, их восприятие и готовность к изменениям.
Если ты будешь выполнять свою работу неверно — от того, как ты внедряешь ИИ в компании с большим количеством людей — ты будешь сеять настроение и отношения к искусственному интеллекту. А это может определить, будет ли ИИ в вашей компании развиваться — или останется "магией", которой боятся.
1. Введение: Моя роль и контекст
Я пришёл в компанию как руководитель направления ИИ. Задача: найти точки внедрения ИИ, показать ценность технологий — и определить стратегию, по которой мы будем двигаться.
? Не «создать систему» — а создать стратегию, которая позволит нам показать, что ИИ — это не магия, а удобный, полезный и понятный инструмент.
Организация не имела представления о том, что такое ИИ. Никто не мог ответить: «Что такое нейросеть? Как она работает? Что она может сделать для нас?»
Даже популярные LLM (Large Language Models) были «черным ящиком» — пока не покажешь, не поверят.
Но здесь есть нюанс: люди были очарованы генеративными моделями, которыми пользовались в повседневной жизни. Они видели, как модель генерирует текст, рисует картинки, пишет письма — и думали: «Это же просто!»
Но они не понимали нюансов:
Модели могут галлюцинировать.
Они могут выдавать правдоподобную, но ложную информацию.
Они могут «забывать», «путать» или «выдумывать» факты.
И это было важно показать — не как недостаток, а как особенность. Чтобы люди начали понимать: «ИИ — это помощник, но не замена разума».
2. Первоначальная ошибка: попытка внедрить ИИ без подготовки
Я предполагал, что можно сразу приступить к внедрению ИИ-решений. Ошибка.
Формула ошибки:
E = I × C
где
E
— эффективность внедрения,
I
— инвестиции в технологии,
C
— культура восприятия технологий.
ПриC ≈ 0
, дажеI → ∞
даётE ≈ 0
.
Люди не готовы к ИИ — значит, нужно начинать не с кода, а с образования и доверия.
3. Диагностика и образование: как я стал "переводчиком"
Я провёл серию презентаций и встреч с каждым отделом. Цель: объяснить, что такое ИИ, какие типы ИИ существуют, и как они могут быть применены.
Разбил задачи по типам:
Компьютерное зрение — работа с изображениями и видео.
Звуковой анализ — обработка аудио, распознавание речи, сегментация.
Предиктивные модели — прогнозирование будущего на основе прошлых данных.
? Важное уточнение:
Очень многие хотят начать именно с предиктивных моделей — ведь всем хочется знать, что будет впереди, чтобы сделать правильный выбор сегодня.
Но здесь кроется опасность: люди часто довольствуются теми данными, которые у них есть, считая, что этого достаточно для прогноза. А на самом деле — это иллюзия.
Построить адекватную предиктивную модель на исторических данных за 2 года — практически невозможно. Особенно если данные разреженные, неполные или не покрывают полный цикл.
Даже если модель покажет высокую точность (например, 95% accuracy), она может быть неадекватной — то есть не отражать реальную картину.
Что значит «адекватная точность»? Это когда модель не просто точно предсказывает, показывая стремящуюся к 99.999% точность, а при этом опирается и оперирует всеми влияющими факторами — сезонностью, внешними событиями, внутренними процессами.
Например: если вы собрали данные за весну, лето и осень — и пытаетесь предсказать зиму — даже при высокой метрике, результат будет недостоверным. Потому что зима — это другой режим работы системы.
Есть исключения — например, сезонные явления: летом ёлки не продаются, а в декабре — продаются очень хорошо. Здесь модель может работать, но только если учтена сезонность.
Так что — да, хочется сразу строить «магические» предиктивные модели. Но без понимания данных и контекста — они станут не помощниками, а источником ложного доверия.
4. Сбор требований и построение дорожной карты
Собрал заявки от отделов — около 50+ идей. Классифицировал их по:
Типу задачи (например, классификация, регрессия, генерация)
Сложности реализации
Бизнес-эффекту
Применил принцип Парето (80/20):
20% задач дадут 80% эффекта — сосредоточился на них.
? Формула выбора задач:
S = Σ(w_i × e_i)
где
w_i
— вес задачи (по важности для бизнеса),
e_i
— ожидаемый эффект (экономия времени, снижение ошибок, рост удовлетворённости).
Выбирал задачи с максимальнымS
.
Но то, что я думал, можно будет реализовать и доказать, что это необходимо, оказалось совсем не так.
На все мои аргументы были ответы:
«Это долго»,
«Это дорого»,
«У нас нет времени».
Поэтому задачи выбирались так, чтобы можно было сделать быстро — и при этом показать эффект.
Не идеально, не масштабно — но видимо и ощутимо.
5. Адаптация стратегии: от «большой машины» к «маленьким шагам»
Получил обратную связь от руководства: «Не нужно большую машину — нужен быстрый результат».
Понял, что в не-IT компании результат должен быть видимым уже через 2–4 недели.
Переформулировал задачу: вместо одного большого проекта — множество маленьких, с ярким эффектом.
⚙️ Методология:
Применил итеративный подход с MVP на каждом этапе — каждый бот, каждая модель становилась частью единой архитектуры.
После этого пришлось собрать множество маленьких проектов — и выстроить из них логическую схему, которая позволила бы потом объединить их в нечто большое, что может принести большой эффект.
И вот это хорошо сработало.
6. Прототипирование до MVP: как я "показывал, а не рассказывал"
Организация не имела представления о LLM, нейросетях, GPU — пока не увидят, не поверят.
Решил: делать прототипы за 1–2 недели, чтобы показать эффект.
Пример: прототип Telegram-бота, который автоматически создаёт документ — показал эффект за 7 дней.
Это дало доверие и позволило двигаться дальше.
? Цикл прототипирования:
Идея → Прототип (1–2 недели) → Демо → Фидбэк → MVP
7. Архитектура системы: как я соединил маленькие решения в единое целое
Создал центральный сервер с микросервисами — каждый сервис отвечает за свою нейросеть.
Интегрировал интерфейсы: Telegram, Android-приложения, веб-панели.
Реализовал унифицированный API для взаимодействия с легаси-системами.
? Системная архитектура:
User Interface → API Gateway → Microservices (AI Models) → Legacy System
Каждый компонент может развиваться независимо, но работает в единой экосистеме.
Ох сколько на этом этапе пришлось съесть собак/лягушек и пудов соли— ну это уже прошлое.
Когда ты собираешь архитектуру для того, чтобы показать её через Telegram, веб-интерфейс или мобильное приложение — всё складывается замечательно.
Но как только ты начинаешь интегрировать это с легаси-системами — начинается адский ад.
Не потому что нет возможностей — а потому что:
В каждом отделе свои планы.
В каждой структурной единице — своя работа, свои сроки.
Где-то перерабатывают, потому что физически не успевают исполнять все задачи.
И это нормально — так устроены большие компании.
Но это делает интеграцию сложной, медленной и требующей терпения, гибкости и постоянного диалога.
8. Управление ограничениями: финансовые, временные, человеческие и технологические
В крупной организации, особенно не IT-ориентированной, ресурсы всегда ограничены — не только по деньгам, но и по времени, людям, и даже по технологической инфраструктуре.
Финансовые ограничения
Бюджет на создание полноценной команды из 15 джунов? Нет.
Поэтому я использовал гибридный подход:
Внутренние сотрудники — для поддержки и управления проектами.
Аутсорсинг и фриланс — для выполнения специфических задач. Это позволило мне сохранить контроль над качеством, не перегружая бюджет.
Человеческие ресурсы
Обучал внутренних сотрудников, создавал «ядро» команды — людей, которые понимают ИИ, могут общаться с разработчиками и объяснять бизнесу, что происходит «под капотом».
Это было ключевым — без этого даже самые крутые модели не будут приняты.
Временные ограничения
Фокусировался на быстрых победах — потому что в бизнесе результат должен быть видимым уже через 2–4 недели.
Если не показать эффект — проект умрёт.
Технологические ограничения: GPU, облака и открытые модели
Здесь — самая большая боль для разработчика ИИ.
? В компании отсутствуют GPU-серверы — и это не ошибка, а осознанный выбор.
Для бизнеса они не нужны — пока.
Но для работы нейросетей — они строго необходимы.
Чтобы решить эту проблему, пришлось:
Выбрать облачные провайдеры, которые соответствуют требованиям безопасности и аккредитации компании.
Пройти сложную процедуру аккредитации — это отдельная история, требующая недель работ с юристами, ИБ-специалистами и аудиторами.
Отказаться от идеи собирать свои модели с нуля — хотя именно этого я хотел больше всего.
Почему? Потому что:
? Я — разработчик нейросетей. Я хочу собирать свои модели, обучать их на своих данных, чтобы они работали именно в тех условиях, в которых это требуется компании — по всей её широте и долготе, от Калининграда до Владивостока.
Но реальность была жесткой: экспериментов не было. Нельзя было потратить несколько месяцев на обучение модели и сотни Килорублей, если нужно показать результат за 2 недели.
Поэтому пришлось пойти на компромисс:
✅ Использовать предобученные модели с открытыми лицензиями — те, что можно бесплатно использовать, модифицировать и внедрять в коммерческие проекты.
? Конкретные примеры предобученных моделей (с открытыми лицензиями)
?️ Компьютерное зрение:
YOLOv8 (Ultralytics) — MIT License — легковесная, быстрая, отлично работает на мобильных устройствах.
EfficientDet (Google) — Apache 2.0 — точная модель для детекции объектов.
MobileNetV3 — Apache 2.0 — оптимизирована для мобильных устройств и edge-вычислений.
?️ Звуковой анализ:
Whisper (OpenAI) — MIT License — распознавание речи, работает на русском.
Vosk — Apache 2.0 — лёгкая библиотека для распознавания речи, работает офлайн.
SpeechBrain — Apache 2.0 — фреймворк для задач обработки речи.
? Текст / NLP:
Sentence Transformers (SBERT) — Apache 2.0 — для семантического поиска и сравнения текстов.
FastText (от запрещенной в РФ компании КнигиЛиц) — MIT License — классификация текста, работа с морфологией.
ONNX Runtime — MIT License — позволяет запускать модели на любом устройстве, включая мобильные.
Эти модели стали основой нашей системы — они работают быстро, легко интегрируются, и главное — не требуют GPU. Мы используем их в облаке, на CPU, и они дают достаточный результат для бизнес-задач.
Да, это не «идеальные» модели — но они работают здесь и сейчас.
А это — главный критерий успеха в крупной компании.
? Мой вывод как разработчика ИИ:
Иногда лучшее — враг хорошего.
Когда ты хочешь собрать свою модель, но бизнес требует результата — ты выбираешь то, что работает.
И это — не слабость. Это — стратегия.
9. Минимизация человеческих ошибок: стратегия для центрального офиса
Центральный офис перегружен — задача: минимизировать ошибки в рутинных операциях.
Применил подход: автоматизация повторяющихся действий.
Пример: бот, который автоматически проверяет фото и выдаёт предварительный вывод — эксперт лишь подтверждает.
? Цель:
Minimize(Error Rate) = f(Automation Level, Human Oversight)
Автоматизация должна быть достаточной, чтобы снизить ошибки, но не полной — эксперт остаётся контролёром.
10. Научный подход к управлению: метрики, гипотезы, итерации
Для каждой задачи формулировал гипотезу: «Если мы внедрим X, то Y увеличится на Z%».
Измерял результаты: время выполнения, количество ошибок, удовлетворённость пользователей.
Корректировал подход на основе данных — это был экспериментальный цикл.
? Цикл научного управления:
Гипотеза → Эксперимент → Измерение → Анализ → Корректировка
11. Результат: как компания начала понимать ИИ
Сотрудники перестали бояться ИИ — начали видеть его как инструмент, а не угрозу.
Появилось понимание: «ИИ — это не замена, а усиление».
? Метафора:
«ИИ забирает у человека мотыгу и даёт ему пульт от дистанционно управляемого трактора» — это стало внутренним слоганом.
12. Выводы и перспективы
Внедрение ИИ в крупной компании — это не техника, а управление изменениями.
Нужно начинать с диагностики, образования и построения системы.
Научный подход, принцип Парето и итеративность — ключевые инструменты успеха.
? Главный вывод:
От тебя зависит, будут ли сотрудники бояться ИИ или доверять ему.
Если ты внедряешь ИИ как "волшебную палочку" — люди будут бояться.
Если ты внедряешь ИИ как "инструмент, который делает их работу проще" — они будут его любить.
Сейчас мы строим платформу для масштабирования ИИ-решений по всему холдингу.
? Перспективы:
Автоматизация 80% рутинных операций.
Внедрение Generative AI для создания документов.
Создание внутреннего центра компетенций по ИИ.
Если эта история была тебе интересна — подписывайтесь, будет ещё больше кейсов из мира внедрения ИИ в крупные компании!
NeriaLab
Да, LLM можно "сделать" за 1-2 недели, но такое не "прокатит" с LBS и CESP системами, они годами создаются, если всё делать с 0. Или, можно взять один из форков Soar и сделать его "под себя", за месяц. У LBS/CESP систем гигантские преимущества перед LLM: им не надо "вычищать" данные; их обслуживание в разы дешевле, от 10 до 100 раз; работают с большим объёмом данных; быстрее; "умнее" и т.д.