3.3. Что я сделал бы иначе

Закладывал бы MLOps с первого дня, а не «сначала модель, потом инфраструктура». Параллельно — дешевле.

Автоматизировал бы тестирование данных раньше. Самые неприятные баги — не в коде, а в «тихом» изменении распределения.

Завёл бы playbook для инцидентов. Когда что-то падает в три часа ночи, нужен чеклист, а не паника.

Глава 4. Чеклист: готов ли проект к масштабированию

Это самая практичная часть — её можно унести с собой.

От диплома до продакшена. Часть 1: Что я хотел … Часть 2: Техническая реализация … Часть 3: Архитектура нейросети … Часть 4: Обучение и валидация … Часть 5: Интеграция с устройствами …

… И ВОТ ТЕПЕРЬ …

Если вы используете умный дом: Настройки… Проверьте разрешения приложений Сеть… Включите WPA3 на Wi-Fi Приватность… Регулярно очищайте историю команд Физическая безопасность…

Техническое решение: Установка камер на уровне лица с углом обзора 120°, обеспечивающих:

Видимость лиц при входе/выходе

Точность до 99.5%+

Сохранение соответствия DPDPA (90 дней хранения для отладки, затем удаление изображений)

Экономическое обоснование (для 56 автобусов):

Стоимость установки: 23.7 млн₽

Дополнительная защита: 12–20 млн₽/год

ROI: 51–84% годовых

Срок окупаемости: 14–23 месяца

Но главное: защита от системных рисков (штрафы, репутация, мошенничество)

Статус: Веду переговоры по интеграции с компанией, которая предоставляет доступ к системам электробусов. Это позволит нам расширить покрытие и снизить затраты на установку.

Что сработало хорошо

MQTT — надёжный и простой протокол для умного дома

Плагин-архитектура — легко добавлять новые устройства

Обработка ошибок — система устойчива к сбоям

Очередь команд — предотвращает конфликты

Что можно улучшить

Поддержка больше протоколов — Zigbee, Z-Wave, Matter

Голосовая обратная связь — подтверждение команд голосом

Сценарии — поддержка сложных сценариев (макросов)

Машинное обучение — адаптация под привычки пользователя

Советы для разработчиков

Начинайте с простого — начните с одного устройства, затем масштабируйте

Тестируйте надёжность — тестируйте в реальных условиях

Обрабатывайте ошибки — устройства могут быть недоступны

Документируйте API — облегчает добавление новых устройств

Мы едим хлеб, а не смотрим на замешивание теста

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

Мы должны руководствоваться достижением цели, а не удобством процессов.

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

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

Как руководитель отдела ИИ с опытом внедрения решений в холдингах на 15 000+ сотрудников, я вижу, что только системный инженерный подход спасает проекты от превращения в «дорогой гараж».

Эпоха 1: Точность на обучении 21.10%, на валидации 94.55%
Высокая валидация на первой эпохе — случайное совпадение. Модель ещё не обучилась, но случайная инициализация весов дала хороший результат на маленькой валидационной выборке.

Эпоха 2-3: Точность на валидации упала до 0%
Модель начала переобучаться на обучающей выборке. Это нормальное явление на ранних этапах обучения.

Эпоха 20: Стабилизация на уровне 78.90% (train) и 27.27% (val)
Начало сходимости модели. После этой эпохи точность на валидации начинает расти.
....
и это всё было на ресурсах Goole-Colab, даже не всегда получалось попасть на GPU. От сюда и выбор размерности батча, для обучения

def get_features_all(y, sr):
"""
Получаем различные параметры аудио которые в сумме дадут уникальный набор признаков
"""
# Частота цветности
chst = librosa.feature.chroma_stft(y=y, sr=sr)
# Среднеквадратичные колебания (энергия сигнала)
rmse = librosa.feature.rms(y=y)
# Пересечения нуля (частота смены знака сигнала)
zcr = librosa.feature.zero_crossing_rate(y)
# Центр масс звука (спектральный центр)
spe_c = librosa.feature.spectral_centroid(y=y, sr=sr)
# Ширина полосы частот
spe_b = librosa.feature.spectral_bandwidth(y=y, sr=sr)
# Спектральный спад частоты
rol = librosa.feature.spectral_rolloff(y=y, sr=sr)
# Значимые для обработки частоты (MFCC)
mfcc = librosa.feature.mfcc(y=y, sr=SR, n_mfcc=50,
n_mels=50, hop_length=1024)
return chst, rmse, zcr, spe_c, spe_b, rol, mfcc

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

«Я имею в виду, когда человек читает книгу или в телевизоре происходит какое-то действие, то оно происходит примерно на одной волне, в небольшом диапазоне разброса. А когда человек подаёт команду, то у него меняется выборка голоса. Он становится плотнее и громче. В общем, на цифрах это хорошо заметно, и здесь нейросеть как раз способна извлечь необходимые паттерны для того, чтобы отделить команду от повседневной бытовой речи.»

Понимание сложности интеграции

Я понимал, что технологии, которые я запланировал, требуют много работы и много навыков в различных отраслях. Это не просто нейросеть, которая распознаёт команды — это целая экосистема взаимодействующих систем.

"Чтобы управление от устройства понимания, в котором расположены веса модели и алгоритм отправки команды, имело механическое действие — необходимо согласование этих механизмов."

«ИИ забирает у человека мотыгу и даёт ему пульт от дистанционно управляемого трактора».

Но в этом проекте пульт показал кое-что ещё: трактор ехал не туда, куда говорил водитель.

Этот проект — один из девяти в моём портфеле. Но он особенный, потому что демонстрирует три ключевых принципа моей работы:

Стратегия важнее технологии. Я выбрал поэтапный подход, а не «идеальное решение сразу» — и это спасло проект.

Финансовое мышление. Каждый технический риск я переводил на язык потерь и ROI. Это позволило защищать бюджеты и масштабировать решения.

Международный масштаб. Я доказал, что российский ИИ-руководитель может успешно внедрять проекты за рубежом, соблюдая местное законодательство и работая с локальными партнёрами.

Очень многие хотят начать именно с предиктивных моделей — ведь всем хочется знать, что будет впереди, чтобы сделать правильный выбор сегодня.
Но здесь кроется опасность: люди часто довольствуются теми данными, которые у них есть, считая, что этого достаточно для прогноза. А на самом деле — это иллюзия.
Построить адекватную предиктивную модель на исторических данных за 2 года — практически невозможно. Особенно если данные разреженные, неполные или не покрывают полный цикл.
Даже если модель покажет высокую точность (например, 95% accuracy), она может быть неадекватной — то есть не отражать реальную картину. Придумал этот термин для пояснения глубины предиктивных исследований (предиктивный происходит от английского predict – «предсказывать, пророчить)
Что значит «адекватная точность»? Это...

Я не делал «крутой ИИ».
Я сделал систему, которая не давала людям уйти обратно к старым процессам.

Первый этап — показал простоту. Второй — показал надёжность. Третий — показал интеллект.

Именно поэтому этот проект стал основой для всей команды ИИ в компании.
Потому что мы доказали:

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

Если вы тоже работаете в корпорации, где «это невозможно», где «нет бюджета», где «это не наша задача» —
начните с каркаса.
Сделайте так, чтобы сегодня стало легче.
И завтра — уже сами будут просить: «А теперь ты сможешь…?»

Привет, Хабр!

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

Сегодня хочу поделиться историей о том, как мы внедряли сервис на основе Telegram-бота с элементами искусственного интеллекта для решения конкретной бизнес-задачи. Это история про то, как мы начали с MVP, постепенно добавляли ИИ, и как это помогло сотрудникам сэкономить время и повысить точность выполнения операций.

Набирая It-специалистов для решения разного рода задач, компании или департаменты стараются брать от middle и выше, казалось бы, это удобно. Вот придёт такой человек в компанию, рассказали о структуре - он вник в структуру, разъяснили как коммуницировать - коммуницирует, описали задачу - сразу приступит к работе над своим блоком и решает. В том числе и все имеющиеся подзадачи - закрывает, и кампания (департамент / компания) идет семимильными шагами к релизу продукта. А потом?!

Но где их набраться, таких специалистов, которые сразу станут не только "пломбировочным материалом в дырах проекта", но и в дальнейшем станут заниматься развитием проекта!?

На такие задачи есть HR-мудрецы! Скажете Вы.

Да. Они могут найти решение, но им заявку кто подаёт?! Тот кому нужны ответы на вопросы: Сможешь? - Смогу. Как..? - Вот так. Ок, берём.

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