Выбор разработчика системы искусственного интеллекта — это не просто выбор подрядчика. Это выбор технологического партнера, от которого зависит успех вашего проекта и бизнеса в целом. По статистике, более 70% AI-проектов не доходят до production, а среди дошедших — до 40% дают нестабильные результаты из-за недобросовестной разработки.
Материал основан на реальном опыте нашего CEO и десятках технических аудитов AI-систем, выполненных для заказчиков из банковского и промышленного секторов. Многие клиенты приходили к нам уже после неудачных попыток внедрения ИИ — с нестабильными моделями, отсутствием воспроизводимости и непрозрачными метриками. Эта статья — выжимка практических критериев, которые родились не в теории, а в процессе разбора реальных проектов, проб и ошибок.
Какие 10 факторов нужно проверить перед заключением договора с разработчиком AI
Выбор AI-подрядчика — это не вопрос технологий или громких кейсов, а вопрос управляемости риска. Ошибки на этом этапе почти всегда обходятся дорого: модель может работать нестабильно, не масштабироваться, терять качество в реальной эксплуатации или становиться неподдерживаемой после сдачи проекта. Проблема в том, что большинство критичных дефектов невозможно увидеть в демо или презентации — они проявляются только при нагрузке, повторных запусках и изменении данных. Именно поэтому перед подписанием договора важно проверить не обещания, а конкретные инженерные признаки зрелой AI-разработки. Ниже — ключевые факторы, которые позволяют отличить устойчивое решение от экспериментального прототипа.
Воспроизводимость результатов
🔴 Почему это критично
Главный признак качественной AI-системы — стабильность результатов. Если разработчик запускает модель на одних и тех же данных несколько раз и получает разные результаты, это говорит о серьезных проблемах в коде.
Что проверить
Вопрос разработчику:
"Если мы запустим вашу модель на одних данных 10 раз, получим ли мы идентичные результаты? Как вы обеспечиваете воспроизводимость?"
Правильный ответ должен включать:
- "Мы фиксируем все random seed (Python, NumPy, TensorFlow/PyTorch)"
- "Используем переменную окружения PYTHONHASHSEED"
- "Отключаем недетерминированные GPU операции"
- "Можем предоставить скрипт для воспроизведения результатов"
“Красные флаги” - не приемлемо:
- "Результаты могут немного различаться — это нормально для ML"
- "У нас результаты стабильны в пределах ±5%"
- "Это зависит от железа"
- Разработчик уходит от прямого ответа или подменяет вопрос общими рассуждениями. Если на конкретный технический вопрос о воспроизводимости вы слышите размытые ответы, это тревожный сигнал. Такой ответ означает, что в проекте отсутствуют формализованные практики контроля детерминизма и качества экспериментов. В реальной эксплуатации это почти гарантированно приводит к нестабильным результатам, невозможности воспроизвести баги и росту стоимости поддержки системы.
Практический тест
Попросите запустить демо-модель 3 раза подряд и сравнить выводы до последнего знака. Если есть различия — бегите.
Пример из практики:
В одном из проанализированных проектов система распознавания почерка давала разные результаты при каждом запуске из-за отсутствия фиксации random seed в sklearn алгоритмах (LocalOutlierFactor, KMeans). Это обнаружилось только на проде через 3 месяца после запуска.
Наличие автоматизированной системы тестирования
🔴 Почему это критично
AI-система без автоматических тестов — это бомба замедленного действия. Любое изменение кода может сломать работу незаметно для глаза.
Что проверить
Вопрос разработчику:
"Какие у вас есть автоматические тесты? Покажите отчет о покрытии кода тестами."
Правильный ответ должен включать:
- Unit-тесты для критичных функций (покрытие > 70%)
- Integration тесты для пайплайна обработки
- Regression тесты на эталонном датасете
- CI/CD pipeline с автозапуском тестов
Варианты плохого ответа:
- "У нас есть ручное тестирование"
- "Мы проверяем на реальных данных"
- "Тесты замедляют разработку"
- Нет метрик покрытия кода
Требование в договор
Подрядчик обязуется предоставить:
- Автоматизированные тесты с покрытием не менее 70%
- CI/CD pipeline с автоматическим запуском тестов
- Отчет о прохождении тестов при каждой поставке
Пример из практики:
В проекте распознавания изображений разработчики изменили функцию предобработки, и точность модели упала с 92% до 67%. Это обнаружилось только через месяц, когда клиент заметил увеличение жалоб. При наличии regression тестов это было бы обнаружено за минуты.
Прозрачность метрик качества
🔴 Почему это критично
"У нас точность 95%" — ничего не значит без контекста. Разработчики могут манипулировать метриками, выбирая выгодные им показатели.
Что проверить
Вопрос разработчику:
"Какие метрики ИИ вы используете? Почему именно их? Покажите confusion matrix и распределение ошибок."
Правильный ответ должен включать:
- Несколько метрик (Precision, Recall, F1-score, ROC-AUC)
- Confusion matrix с разбивкой по классам
- Анализ ошибок (где модель ошибается чаще)
- Метрики на независимом тестовом датасете
Плохой ответ AI разработчика - это:
- Названа только одна метрика (обычно Accuracy)
- "Мы тестировали на тех же данных, на которых обучали"
- Метрики без доверительных интервалов
- Отказываются показывать примеры ошибок
Минимальный набор метрик
Для классификации:
- Precision (точность положительных предсказаний)
- Recall (полнота — сколько объектов нашли)
- F1-score (баланс precision/recall)
- Confusion matrix (матрица ошибок)
Для детекции объектов:
- mAP (mean Average Precision)
- IoU (Intersection over Union)
- False Positives/Negatives rate
Требование в договор
Подрядчик предоставляет отчет с метриками:
- Precision, Recall, F1-score по каждому классу
- Confusion matrix
- Примеры правильных и ошибочных предсказаний (не менее 20)
- Метрики измерены на независимом тестовом датасете (не менее 1000 примеров)
Пример из практики:
Разработчик хвастался "точностью 98%" в системе детекции дефектов. При детальном анализе оказалось: датасет на 98% состоит из бездефектных образцов, модель просто всегда отвечает "дефектов нет".
Реальная полнота (Recall) была 12%.
Документация кода и архитектуры
🔴 Почему это критично
AI-система без документации — это черный ящик. Вы не сможете ее поддерживать, модифицировать или передать другой команде.
Что проверить
Вопрос разработчику:
"Покажите пример вашей технической документации. Как новый разработчик может разобраться в коде?"
Правильный ответ должен включать:
- Архитектурная схема (диаграмма компонентов)
- Описание пайплайна обработки данных
- Docstrings в коде (Google/NumPy style)
- README с инструкцией по запуску
- Описание гиперпараметров и их влияния
“Красные флаги” при ответе на вопрос:
- «Код self-documenting»
Заявление о том, что код «сам себя документирует», допустимо только для небольших утилит. В промышленной AI-системе это означает отсутствие описаний архитектуры, пайплайнов данных, точек принятия решений и ограничений модели. Такой код невозможно поддерживать, масштабировать или передавать другой команде без риска деградации качества.
- Документация «в головах разработчиков»
Если знания о системе не зафиксированы в виде документов, схема владения критична: смена одного ключевого инженера приводит к потере контекста, росту сроков и стоимости доработок. Для заказчика это прямой риск vendor lock-in.
- Комментарии на уровне # инициализация переменной
Формальные комментарии, описывающие очевидные действия кода, не несут инженерной ценности. В AI-проектах важны пояснения почему принято то или иное решение: выбор архитектуры, гиперпараметров, метрик, порогов, источников данных и ограничений модели.
- Отсутствие схем и диаграмм
Если нет архитектурных диаграмм (data flow, model pipeline, интеграции, точки отказа), систему невозможно адекватно оценить с точки зрения эксплуатации, безопасности и масштабирования. Это особенно критично для банков, медицины и промышленности, где требования к прозрачности и управляемости высоки.
Минимальный набор документации
1. Architecture.md — общая схема системы
2. Data_pipeline.md — как обрабатываются данные
3. Model.md — архитектура модели, гиперпараметры
4. API.md — описание всех функций и классов
5. Deployment.md — как развернуть в production
6. Troubleshooting.md — частые проблемы и решения
Требование в договор
Подрядчик предоставляет:
- Техническую документацию (не менее 20 страниц)
- Диаграммы архитектуры в редактируемом формате
- Комментарии в коде на русском/английском языке
- Видеоинструкцию по запуску системы
Пример из практики:
Компания инвестировала более 20 млн руб. в разработку ИИ-системы. Через год ключевой разработчик покинул проект, и новой команде потребовалось четыре месяца, чтобы восстановить логику работы кода из-за отсутствия документации. В результате совокупная стоимость владения системой выросла почти вдвое.
Контроль версий и история изменений
🔴 Почему это критично
Git — это не опция, это обязательный стандарт. Без версионирования невозможно откатить изменения, понять, кто и когда что сломал, и работать в команде.
Что проверить
Вопрос разработчику:
"Какую систему контроля версий вы используете? Покажите историю коммитов последнего месяца."
Правильный ответ должен включать:
- Git (GitHub/GitLab/Bitbucket)
- Осмысленные commit messages
- Feature branches + Pull Requests
- Code review перед merge
- Версионирование моделей (MLflow/DVC)
Плохой ответ разработчика -
- "Мы используем Dropbox/Google Drive"
- Commit messages типа "fix", "update", "changes"
- Все коммиты от одного человека
- Нет тегов/релизов
- Бинарные файлы моделей в Git (без Git LFS)
Признаки качественного Git-репозитория
- Регулярные коммиты
Изменения вносятся часто — не реже одного раза в 1–2 дня. Это признак живой разработки и управляемого процесса.
- Содержательные комментарии к коммитам
Из комментария должно быть понятно:
что сделано,
зачем,
какой эффект получен.
Пример:
Добавлена аугментация данных при обучении модели
– поворот изображений в диапазоне ±15°
– зеркальное отражение с вероятностью 50%
– точность на валидации выросла с 87% до 91%
– исправлена ошибка №42
или
"feat: Add data augmentation with rotation and scaling
- Implemented RandomRotation with ±15° range
- Added horizontal flip with 50% probability
- Improved validation accuracy from 87% to 91%
Fixes #42"
3. Понятная стратегия ветвления
Используется формализованный подход к работе с ветками (Git Flow или Trunk-based), а не хаотичные правки в одной ветке.
4. Фиксация версий системы
Ключевые состояния системы помечаются версиями (v1.0.0, v1.1.0), что позволяет воспроизводить результаты и безопасно обновлять решение.
Требование в договор
Подрядчик обязуется:
- Использовать Git для контроля версий
- Предоставить заказчику доступ к репозиторию
- Делать коммиты не реже 1 раза в 2 рабочих дня
- Использовать осмысленные commit messages на английском языке
- Версионировать модели через MLflow/DVC
Пример из практики:
Разработчик "забыл" передать последнюю версию кода. Через месяц клиент обнаружил, что
production-версия отличается от переданной. Git-репозиторий показал, что за неделю до сдачи
разработчик откатил критичный функционал. Без Git это осталось бы незамеченным.
Управление гиперпараметрами и экспериментами
🔴 Почему это критично
AI-разработка — это сотни экспериментов. Без систематического трекинга вы не поймете, почему одна модель работает лучше другой, и не сможете воспроизвести результаты.
Что проверить
Вопрос разработчику:
"Как вы отслеживаете эксперименты? Покажите историю обучения моделей за последний месяц."
Правильный ответ должен включать:
- MLflow/Weights&Biases/Neptune для трекинга
- Логирование всех гиперпараметров
- Сохранение метрик на каждой эпохе
- Графики обучения (loss, accuracy curves)
- Возможность сравнить эксперименты
“Красные флаги”:
- "Храним в Excel/блокноте"
- Hardcoded гиперпараметры в коде
- "Подбирали вручную, запомнили лучший вариант"
- Нет истории экспериментов
- Константы типа MAX_SCORE = 0.85394 без объяснения
Что должно логироваться
# Пример корректного трекинга
mlflow.log_params({
"learning_rate": 0.001,
"batch_size": 32,
"optimizer": "Adam",
"augmentation": "rotation+flip",
"model_architecture": "ResNet50"
})
mlflow.log_metrics({
"train_loss": 0.23,
"val_loss": 0.31,
"train_accuracy": 0.92,
"val_accuracy": 0.89,
"f1_score": 0.87
})
Требование в договор
Подрядчик предоставляет:
- Dashboard с историей всех экспериментов
- Доступ к MLflow/W&B проекту
- Описание лучшей модели с полным набором гиперпараметров
- Инструкцию по воспроизведению результатов
Пример из практики:
В коде системы распознавания была найдена константа MAX_SCORE = 0.85394. На вопрос "откуда это
значение?" разработчик ответил: "Не помню, это было год назад, работало лучше всего". Без трекинга
экспериментов восстановить логику невозможно.
Обработка граничных случаев и ошибок
🔴 Почему это критично
Модель, которая работает на "хороших" данных, но падает на граничных случаях — это не production-ready система.
Что проверить
Вопрос разработчику:
"Что произойдет, если модель получит пустое изображение? Изображение с водяным знаком? Полностью черное изображение? Покажите обработку ошибок."
Правильный ответ должен включать:
- Валидация входных данных
- Graceful degradation (корректная деградация)
- Логирование ошибок с контекстом
- Тесты на edge cases
- Fallback-стратегии
Плохой ответ:
- "Мы предполагаем, что данные всегда корректны"
- Код без try-except блоков
- При ошибке система просто падает
- Нет валидации размеров/форматов входа
- "Это должен проверять frontend"
Чек-лист нестандартных входных данных
Для компьютерного зрения:
- Пустое изображение (0 байт)
- Слишком маленькое изображение (< 10x10)
- Слишком большое изображение (> 10000x10000)
- Черное/белое изображение (одноцветное)
- Изображение с водяным знаком/логотипом
- Повернутое изображение
- Некорректный формат файла
Для NLP:
- Пустая строка
- Только спецсимволы
- Слишком длинный текст (> max_length)
- Эмодзи и Unicode символы
- HTML теги
Требование в договор
Подрядчик обеспечивает:
- Корректную обработку всех граничных случаев (список прилагается)
- Возврат понятных сообщений об ошибках
- Логирование всех исключений с контекстом
- Unit-тесты на edge cases (не менее 20)
Пример из практики:
Система OCR падала, когда получала PDF с пустыми страницами. Разработчик: "Ну кто будет загружать пустые страницы?". Оказалось — 3% пользователей, по ошибке. Результат: 3% запросов падали с кодом 500.
Масштабируемость и производительность
🔴 Почему это критично
Модель, которая обрабатывает 10 изображений в час, — это demo. Production требует обработки тысяч запросов в минуту.
Что проверить
Вопрос разработчику:
"Сколько запросов в секунду выдерживает ваша система? Проводили ли вы нагрузочное тестирование? Как система масштабируется?"
Правильный ответ должен включать:
- Benchmark на реальных данных (RPS, latency)
- Профилирование кода (где узкие места)
- Стратегия масштабирования (горизонтальная или вертикальная)
- Батчинг запросов для GPU
- Кэширование результатов
Какой ответ плохой:
- "Не проводили нагрузочное тестирование"
- "Одна модель обрабатывает 1 изображение за 10 секунд"
- Синхронная обработка без очередей
- Нет оптимизации (TensorRT, ONNX)
- Модель загружается при каждом запросе
Минимальные требования к производительности
Компьютерное зрение (inference на GPU):
- Latency: < 100ms на изображение 640x480
- Throughput: > 50 изображений/сек (batch=32)
- CPU utilization: < 80% при пиковой нагрузке
NLP (BERT-like модели):
- Latency: < 50ms на текст до 512 токенов
- Throughput: > 100 запросов/сек (batch=16)
Практический тест
Попросите разработчика:
1. Загрузить 1000 изображений
2. Обработать их системой
3. Показать время обработки и утилизацию ресурсов
Пример из практики:
Система детекции объектов обрабатывала 1 изображение за 5 секунд. Для 10,000 изображений в день требовалось 14 часов работы. После оптимизации (батчинг, TensorRT, кэширование) время сократилось до 30 минут.
Безопасность и защита от целенаправленных атак на модель (adversarial-атаки)
🔴 Почему это критично
AI-модели уязвимы к специально созданным атакам. Злоумышленник может обмануть модель, добавив шум к изображению или изменив несколько пикселей.
Что проверить
Вопрос разработчику:
"Проводили ли вы тестирование на adversarial примерах? Как модель защищена от целенаправленных атак?"
Правильный ответ должен включать:
- Тестирование на FGSM/PGD атаках
- Adversarial training (обучение на атакованных примерах)
- Input validation (проверка аномальных входов)
- Rate limiting (ограничение запросов)
- Мониторинг подозрительной активности
“Красные флаги”:
- Отсутствие понимания угроз, связанных с атаками на модели
- Подмена вопроса безопасности вопросом точности модели
- Отсутствие валидации и фильтрации входных данных
- Отсутствие логирования и мониторинга подозрительной активности
- Открытые API без аутентификации и контроля доступа
Минимальные меры безопасности
# 1. Input validation
def validate_input(image):
if image.shape[0] > 10000 or image.shape[1] > 10000:
raise ValueError("Image too large")
if np.std(image) < 0.01: # Подозрительно однородное
raise ValueError("Suspicious input")
if has_adversarial_pattern(image):
raise ValueError("Potential attack detected")
# 2. Rate limiting
@rate_limit(max_requests=100, period=60)
def predict(image):
...
# 3. Anomaly detection
def detect_anomaly(input_data):
# Проверка на аномальные паттерны
if is_out_of_distribution(input_data):
log_warning("OOD input detected")
Требование в договор
- Подрядчик обеспечивает:
- Тестирование на adversarial примерах (отчет прилагается)
- Input validation для всех входных данных
- Rate limiting (не более 1000 запросов/минуту с IP)
- Логирование всех подозрительных запросов
- Регулярное обновление модели с учетом новых атак
Пример из практики:
Система распознавания лиц в банке была обманута наклейкой на лице злоумышленника. Модель не была
обучена на adversarial примерах, и добавление паттерна в 5 пикселей позволило обойти аутентификацию.
Прозрачность состава команды и компетенций
🔴 Почему это критично
За красивой презентацией может скрываться студент-фрилансер или компания-посредник, которая сама не
пишет код.
Что проверить
Вопрос разработчику:
"Кто конкретно будет работать над проектом? Покажите их профили GitHub, публикации, примеры кода."
Правильный ответ должен включать:
- Профили GitHub с активностью (commits, pull requests)
- Публикации/статьи/доклады по ML/AI
- Портфолио с похожими проектами
- Kaggle/research опыт (если релевантно)
- Сертификаты (но не только они!)
Варианты плохого ответа:
- "Команда конфиденциальна"
- GitHub профили пустые или с копипастом
- Нет публичного кода
- Портфолио только из презентаций
- "У нас 50 ML-инженеров" (а работать будут 2 джуна)
- Резюме с пафосными/общими фразами вместо реальных проектов
Минимальный профиль команды
Для проекта требуется:
- ML Engineer (опыт > 3 лет):
- GitHub с > 500 коммитов
- Опыт с TensorFlow/PyTorch
- Публичные проекты на GitHub - Data Scientist (опыт > 2 лет):
- Kaggle Expert+ или публикации
- Опыт обработки данных (pandas, numpy) - MLOps Engineer (опыт > 2 лет):
- Docker, Kubernetes
- CI/CD для ML (MLflow, DVC)
Практическая проверка
1. Code review: Попросите решить тестовое задание
2. GitHub audit: Проверьте активность за последние 6 месяцев
3. Техническое интервью: Задайте 5-10 вопросов по архитектуре
4. Reference check: Свяжитесь с предыдущими клиентами
Требование в договор
Подрядчик предоставляет:
- Список сотрудников с указанием ролей
- Резюме ключевых специалистов
- Ссылки на профили GitHub/LinkedIn
- Запрет на замену команды без согласования с заказчиком
- Штраф за замену ключевых специалистов без согласия
Пример из практики:
Компания презентовала "команду из 10 ML-экспертов". После подписания договора выяснилось, что реально работают 2 разработчика, один из которых — студент 3 курса. GitHub показал, что весь код скопирован из open-source проектов.
Итоговый чеклист для договора
Технические требования
- Воспроизводимость результатов (100%, с фиксацией всех random seed)
- Автоматизированное тестирование:
- Unit тесты (coverage > 70%)
- Integration тесты
- Regression тесты на эталонных данных
- CI/CD pipeline - Метрики качества:
- Precision, Recall, F1-score по каждому классу
- Confusion matrix
- ROC-AUC curve
- Минимум 20 примеров ошибок с анализом - Документация:
- Архитектурная схема
- Описание пайплайна данных
- API документация
- Deployment инструкция
- Troubleshooting guide - Контроль версий:
- Git-репозиторий с историей коммитов
- Осмысленные commit messages
- Code review процесс
- Версионирование моделей (MLflow/DVC) - Эксперименты:
- Трекинг всех экспериментов
- Логирование гиперпараметров
- Графики обучения
- Возможность воспроизведения - Обработка ошибок:
- Валидация входных данных
- Graceful degradation
- Логирование с контекстом
- Тесты на edge cases (> 20) - Производительность:
- Latency < 100ms (CV) / < 50ms (NLP)
- Throughput > 50 img/sec (CV) / > 100 req/sec (NLP)
- Нагрузочное тестирование проведено - Безопасность:
- Тестирование на adversarial примерах
- Input validation
- Rate limiting
- Логирование подозрительной активности - Команда:
- Профили GitHub с активностью
- Портфолио похожих проектов
- Запрет на замену без согласования
Топ-5 сигналов, что что-то не так:
Если видите хотя бы 3 из этих признаков — не подписывайте договор:
1. "Мы используем собственный уникальный алгоритм" — скорее всего, это просто переобучение на данных или копипаст из статьи
2. Отказываются показать код или демо — "по соображениям безопасности" = нечего показывать
3. Обещают точность > 99% без оговорок — либо обманывают, либо задача тривиальная
4. Нет кейсов в production — только "исследовательские проекты" и "прототипы"
5. Ценник в 2-3 раза ниже рынка — работать будут студенты или код украден
Заключение
Выбор разработчика AI-системы — это выбор долгосрочного партнера. Не стесняйтесь задавать технические вопросы, просить примеры кода, требовать демонстрацию.
Помните золотое правило:
Хороший AI разработчик с радостью покажет код, объяснит архитектуру и предоставит метрики. Плохой разработчик будет прятаться за громкими фразами, нереалистичными обещаниями и красивыми презентациями.
Контрольные вопросы для первой встречи
- Запустите модель на моих данных 3 раза. Результаты идентичны?
- Покажите GitHub с историей коммитов за последние 3 месяца
- Какой у вас coverage автоматическими тестами
- Покажите confusion matrix на валидационных данных
- Сколько запросов в секунду выдерживает система?
- Проводили ли adversarial тестирование?
- Кто конкретно будет писать код? Покажите их профили
- Есть ли у вас кейсы? Можно ли связаться с клиентами?
- Как вы версионируете модели и эксперименты?
- Что произойдет, если модель получит некорректные данные?
Если разработчик уверенно отвечает на все 10 вопросов — это хороший знак.
Если уходит от ответов хотя бы на 3 — ищите другого партнера.
А если хотите сотрудничать с NeuroCore - просто заполните форму ниже
