Представьте: огромная гидроэлектростанция на северо-западе США. Каждый год через ее рыбоход проходит сотни тысяч лососей. По закону FERC (Федеральная комиссия по регулированию энергетики) оператор ГЭС обязан считать каждую рыбу. Вручную. Люди сидят у мониторов и кликают на проплывающих лососей.
Скучно? Да. Дорого? Очень. Ошибочно? Неизбежно.
Решение очевидно — автоматизация через компьютерное зрение. Но когда мы начали этот проект, то быстро поняли: заменить человека нейросетью полностью не получится. Нужен симбиоз. Тот самый Human-in-the-Loop, о котором все говорят, но редко показывают, как он работает в грязи реальных проектов.
Почему просто запустить YOLO недостаточно
Первая мысль у любого технаря: берем готовую модель для детекции объектов, камеры над рыбоходом, и вуаля — автоматический счетчик готов. Но реальность бьет по голове сразу с трех сторон.
Вода мутная. Рыба быстрая. Тени от волн создают ложные объекты. А еще есть пузыри, мусор, и иногда по каналу проплывает утка. Нейросеть путает утку с лососем. FERC такое не простит.
Точность в 95% звучит отлично в академической статье. Но когда речь о 500 000 рыб, 5% ошибки — это 25 000 неучтенных или лишних особей. Для экологов и регуляторов это катастрофа. Отчетность теряет смысл. Штрафы становятся реальными.
Именно здесь появляется HITL. Не как модное слово, а как производственная необходимость.
Архитектура системы: где сидит человек
Мы построили конвейер, где ИИ делает грубую работу, а человек — тонкую настройку. Вот как это работает:
- Детекция в реальном времени: Модель на базе YOLOv8 обрабатывает видеопоток, отмечает все объекты, похожие на рыбу.
- Первичная фильтрация: Алгоритм отсекает очевидный шум (пузыри, блики) по размеру и траектории движения.
- Формирование очереди на проверку: Сомнительные кадры (где уверенность модели ниже 85%) попадают в веб-интерфейс валидатору.
- Человеческое решение: Валидатор смотрит на кадр, кликает — рыба или нет. Его решение тут же идет обратно в модель для дообучения.
- Финальный отчет: Система генерирует сводку с пометками, какие данные проверены человеком, а какие — нет.
Самые болезненные ошибки (и как их избежать)
Когда мы только начинали, то наступили на все возможные грабли. Вот топ-3 ошибки, которые могут убить ваш HITL-проект.
1Ошибочная экономия на разметке
Первый инстинкт — разметить минимум данных, чтобы модель просто заработала. Мы взяли 1000 кадров, разметили силами команды разработки. Результат? Модель научилась распознавать рыбу только при определенном освещении и угле съемки. Как только погода менялась, точность падала в разы.
Решение: Использовали техники автоматизации разметки для создания первичного датасета из 50 000 кадров. Затем наняли трех ихтиологов (не айтишников!) для валидации. Они знали, как отличить молодь лосося от гольяна, что для программы было неочевидно.
2Игнорирование стейкхолдеров
Мы думали, что главный заказчик — IT-директор ГЭС. Оказалось, что реальные пользователи — биологи, которые потом используют эти данные для научных отчетов. Их потребности:
- Не просто подсчет, а распределение по видам (кижуч, чавыча, нерка)
- Отметки о поврежденных особях (для оценки воздействия турбин)
- Экспорт данных в специфичные научные форматы (не только CSV)
Пришлось переделывать интерфейс валидатора, добавлять кнопки для маркировки видов и дефектов. Как в проекте Perch от DeepMind, где ученые-орнитологи напрямую влияли на функционал.
3Неучет регуляторных требований
FERC требует не просто цифры, а доказательства их достоверности. Наш первый прототип выдавал итоговую цифру без возможности аудита. Регулятор бы его отклонил сразу.
Мы добавили:
- Сквозную трассировку: для каждой посчитанной рыбы можно посмотреть исходный кадр
- Пометки, какие кадры проверены человеком, а какие — нет
- Логи всех действий валидаторов с временными метками
Это превратилось из IT-проекта в compliance-проект. 30% времени ушло не на алгоритмы, а на создание системы, которая удовлетворяет регулятора.
Пошаговый план внедрения HITL в экологический проект
Если вы собираетесь считать животных, отслеживать вырубки или мониторить качество воды, этот план спасет вас месяцев работы.
Этап 1: Поиск экспертов, а не разметчиков
Не нанимайте фрилансеров с краудсорсинговых платформ. Найдите настоящих специалистов в вашей области. Для подсчета лосося мы договорились с местным университетом. Студенты-ихтиологи работали за практику и рекомендации. Они не просто кликали на рыбу — они комментировали, почему та или иная особь сложна для идентификации.
Эти комментарии стали золотым фондом для улучшения модели.
Этап 2: Построение петли обратной связи
Самая частая ошибка — сделать человека "последней инстанцией", чьи решения никуда не идут. В нашей системе каждый исправленный кадр немедленно попадал в датасет для дообучения.
Технически это выглядело так:
# Псевдокод петли обратной связи
for each_hour_of_operation:
predictions = model.predict(video_stream)
low_confidence_frames = filter_by_confidence(predictions, threshold=0.85)
# Отправляем сомнительные кадры валидаторам
validation_tasks = create_tasks(low_confidence_frames)
human_decisions = await validate(validation_tasks)
# Дообучаем модель на свежих данных
training_data = prepare_training_data(human_decisions)
model.partial_fit(training_data)
# Генерируем отчет для регулятора
report = generate_report(predictions, human_decisions)Этап 3: Создание прозрачной отчетности
Регуляторы не верят черным ящикам. Мы создали дашборд, где в реальном времени видно:
| Метрика | Значение | Что показывает |
|---|---|---|
| Всего обнаружено | 1247 | Автоматическая детекция |
| Проверено человеком | 189 (15%) | Уровень вмешательства |
| Исправлено ошибок | 23 | Эффективность HITL |
| Итоговый счет | 1230 | После корректировок |
Такой уровень прозрачности убедил даже скептически настроенных инспекторов FERC.
Что делать, когда моделей слишком много
В процессе мы экспериментировали с десятком архитектур: YOLO, Faster R-CNN, кастомные CNN. Возник хаос — какая модель на каких данных лучше? Воспользовались подходом из статьи про трекинг AI-моделей.
Завели реестр, где для каждой модели хранились:
- Дата обучения и версия датасета
- Точность на разных типах кадров (чистая вода, муть, блики)
- Скорость inference на нашем железе
- Какие классы объектов распознает лучше/хуже
Это позволило быстро переключаться между моделями в зависимости от условий. Утром при ярком солнце — одна модель, вечером при искусственном освещении — другая.
Главный урок: HITL — это не про технологии, а про процессы
Самый важный инсайт пришел к нам на третьем месяце проекта. Мы думали, что главная проблема — точность нейросети. Оказалось — координация людей.
Биологи работали по своему графику, инженеры — по своему. Возникали конфликты: "Почему модель опять перепутала чавычу с кижучем?" — "А почему вы не разметили достаточно примеров чавычи?"
Решение было не техническим, а организационным:
- Создали еженедельные sync-встречи биологов и ML-инженеров
- Внедрили shared backlog в Jira, где обе стороны видели приоритеты
- Разработали глоссарий терминов, чтобы "низкая точность" и "плохая разметка" означали одно и то же для всех
Без этого даже самая совершенная технологическая петля обратной связи не работала бы.
FAQ: Что спрашивают чаще всего
Насколько дороже HITL по сравнению с полной автоматизацией?
В нашем случае — на 40% дороже на этапе внедрения. Но эти затраты окупились за полгода. Без HITL система выдавала бы неточные данные, что привело бы к штрафам от FERC и необходимости переделывать отчеты за прошлые периоды. Стоимость ошибки превысила бы стоимость внедрения в 5-7 раз.
Как убедить стейкхолдеров, что частичная автоматизация — это нормально?
Мы использовали метафору автопилота в самолете. Даже в самых современных лайнерах пилоты контролируют ключевые этапы полета. Никто не доверяет полностью автоматическую систему в ответственных задачах. Так и здесь: ИИ — это автопилот, человек — пилот в сложных условиях.
Что делать, если эксперты отказываются работать с интерфейсом?
Такое случалось. Биологи жаловались, что интерфейс валидации неудобен. Вместо того чтобы убеждать их, мы посадили дизайнера наблюдать за их работой. Оказалось, им нужно видеть не один кадр, а последовательность из 3-5 кадров, чтобы отследить движение рыбы. Переделали интерфейс — возражения исчезли.
Что дальше? HITL как стандарт для экологического мониторинга
Наш кейс стал шаблоном для других проектов. Сейчас по аналогичной схеме работают системы:
- Подсчета морских котиков на лежбищах
- Мониторинга незаконных рубок леса по спутниковым снимкам
- Анализа качества воды по микроскопическим изображениям планктона
Общий принцип везде одинаковый: ИИ обрабатывает объем, человек контролирует качество, петля обратной связи постоянно улучшает систему.
Самая интересная эволюция — переход от пассивного HITL к активному. Сейчас мы экспериментируем с системой, где модель не просто просит помощи, а задает конкретные вопросы: "Это чавыча или кижуч?", "Рыба ранена или здорова?". Это сокращает время валидации на 60%.
Если вы только начинаете путь в экологическом мониторинге с ИИ, запомните одно правило: автоматизируйте не людей, а их рутину. Оставьте экспертам то, в чем они действительно хороши — принятие сложных решений. А счет, классификацию и первичный анализ доверьте машинам. Но всегда оставляйте кнопку "стоп" в человеческих руках.
Потому что когда речь идет о сохранении видов, одна ошибка алгоритма может стоить дороже, чем тысяча часов человеческой проверки.