🟩 В условиях стремительной цифровизации промышленности, логистики, ритейла и безопасности системы компьютерного зрения становятся критически важными компонентами бизнес-процессов. Споры между заказчиками и исполнителями интеллектуальных систем (IT-интеграторами, вендорами алгоритмов, исследовательскими лабораториями) относительно объема фактически выполненных работ приобретают особую сложность, поскольку результат труда здесь — это не материальный объект, а сложный программно-алгоритмический комплекс, включающий модели глубокого обучения, базы данных размеченных изображений, модули предобработки, API-интерфейсы и пользовательские интерфейсы. Заказчик часто полагает, что оплатил «полноценную систему распознавания объектов», а исполнитель предоставляет «демонстрационный прототип с ограниченной точностью». В такой ситуации только глубокая IT-экспертиза, опирающаяся на методы статического и динамического анализа кода, тестирование на репрезентативных выборках, оценку метрик производительности (precision, recall, mAP, F1-score) и сопоставление с техническим заданием, позволяет объективно установить, какой объем работ был реально выполнен и соответствует ли он контрактным обязательствам. В настоящей статье мы системно разбираем все этапы такой экспертизы, методологические подходы и сложности, возникающие при оценке алгоритмических систем, а также приводим развернутые практические кейсы из деятельности Союза «Федерация судебных экспертов», где удалось восстановить истину в спорах о недопоставке интеллектуальных продуктов.

💻 Раздел 1. Определение предмета и объектов IT-экспертизы систем компьютерного зрения

• Предметом данной экспертизы является установление фактического объема и качества выполненных работ по созданию или адаптации системы компьютерного зрения, включая проверку соответствия реализованного функционала условиям договора, техническому заданию (ТЗ), спецификациям и общепринятым отраслевым стандартам. Объектами исследования выступают: исходный и исполняемый код программных модулей, обученные нейросетевые модели (файлы весов, архитектуры), наборы данных для обучения и валидации, логи работы системы, API-документация, пользовательские интерфейсы, отчеты о тестировании, а также вся сопутствующая проектная документация. Эксперт должен понять, что система компьютерного зрения — это не монолит, а совокупность взаимосвязанных компонентов: модуль захвата кадров, модуль предобработки (нормализация, аугментация), детектор, классификатор, трекер, модуль постобработки (подавление ложных срабатываний), модуль вывода результатов и интеграции с внешними системами. Каждый из этих компонентов может быть реализован в различной степени полноты, и эксперт обязан оценить каждый из них по отдельности, а также их совокупное взаимодействие.

🎯 Раздел 2. Типичные основания для возникновения споров о неполной реализации

• На практике споры чаще всего возникают по следующим причинам. Первая и самая распространенная — несоответствие заявленной точности распознавания: исполнитель предоставляет отчеты о метриках на ограниченном тестовом наборе, а в реальных условиях система работает неприемлемо низко. Вторая причина — отсутствие заявленных функций: вместо обещанного распознавания 100 классов объектов реализовано только 15, либо вместо видеопотока в реальном времени работает пакетная обработка с задержкой в несколько секунд. Третья причина — использование открытых библиотек и предобученных моделей без существенной доработки, тогда как по ТЗ требовалась разработка уникальных алгоритмов. Четвертая — неполная документация и отсутствие инструкций по развертыванию, что делает систему непригодной к эксплуатации силами заказчика. Пятая — поставка «сырого» кода без комментариев, модульных тестов и системы сборки, что фактически обесценивает результат, так как заказчик не может его сопровождать и развивать. Все эти случаи требуют детального экспертного исследования, выходящего далеко за рамки простого сравнения «есть/нет» функции.

🧩 Раздел 3. Анализ технического задания как первичный этап экспертизы

• Первым и ключевым этапом работы эксперта является изучение технического задания или иного аналогичного документа, фиксирующего объем требований к системе. Эксперт выделяет функциональные требования (что система должна делать), нефункциональные (быстродействие, масштабируемость, надежность), требования к точности (метрики), к составу поставляемой документации и к обучению персонала. Важно, что ТЗ часто содержит как жесткие требования («система должна детектировать не менее 95% пешеходов»), так и «гибкие» формулировки («система должна быть удобной»), которые сложно операционализировать. Эксперт проверяет, насколько каждый пункт ТЗ реализован, документирован и протестирован, и если пункт имеет нечеткую формулировку — предлагает свою интерпретацию, основанную на отраслевых стандартах (например, ГОСТ 34.602-2020 для автоматизированных систем). В случае отсутствия полноценного ТЗ (что тоже бывает в IT-контрактах), эксперт использует коммерческие предложения, переписку сторон и общеизвестные аналоговые системы в качестве эталона разумных ожиданий.

🛠️ Раздел 4. Статический анализ исходного кода: оценка архитектуры и соответствия стандартам

• Статический анализ выполняется без запуска программы и позволяет оценить архитектурные решения, стиль кодирования, наличие комментариев, модульность, использование паттернов проектирования, а также соблюдение лицензионных требований для сторонних библиотек. Эксперт использует такие инструменты, как SonarQube, ESLint, Pylint, Checkstyle, а также проводит ручной обзор наиболее критичных модулей. Оценивается, насколько код соответствует современным стандартам для промышленной разработки (DRY, SOLID, KISS), есть ли юнит-тесты и их покрытие, а также насколько легко код может быть модифицирован другим разработчиком. Если в коде обнаруживаются «заглушки» (недоделанные функции, возвращающие заглушечные значения), бесконечные циклы, утечки памяти или некорректная обработка исключений — это серьезный признак неготовности системы. В рамках статического анализа также проверяется наличие и корректность документации внутри кода (docstrings, комментарии на сложные участки) и наличие файлов конфигурации, необходимых для развертывания.

📊 Раздел 5. Динамический анализ и нагрузочное тестирование

• Динамический анализ подразумевает запуск системы на контрольных примерах, которые приближены к реальным условиям эксплуатации, с регистрацией всех выходных данных, времени отклика и использования вычислительных ресурсов. Эксперт формирует тестовый набор изображений и видеопоследовательностей, покрывающий все заявленные сценарии: разные условия освещения, ракурсы, масштабы объектов, частичные перекрытия, а также «пограничные» случаи (экстремально мелкие объекты, сильно переэкспонированные кадры). Для каждой тестовой выборки вычисляются метрики: precision (точность), recall (полнота), mAP (средняя точность), а также F1-score как гармоническое среднее. Если исполнитель заявлял определенные значения метрик, то эксперт проверяет, были ли они достигнуты на независимой выборке, а также сравнивает производительность на различных аппаратных конфигурациях (GPU, CPU). Важным аспектом является стабильность работы — система не должна падать или «зависать» при длительной эксплуатации, а также корректно обрабатывать ошибки ввода/вывода.

🤖 Раздел 6. Анализ обученных нейросетевых моделей: архитектура, объем данных, дообучение

Для систем компьютерного зрения ключевым элементом являются модели глубокого обучения. Эксперт исследует архитектуру модели (например, YOLOv8, EfficientNet, ResNet, трансформеры), количество параметров, использованные функции потерь и оптимизаторы. Важно определить, была ли модель обучена «с нуля» на специфических данных заказчика, или же была взята предобученная на открытых датасетах (ImageNet, COCO) и лишь незначительно дообучена. На практике второй вариант часто является основанием для снижения стоимости работ, если по ТЗ требовалась «разработка оригинального решения». Также эксперт оценивает объем и разнообразие датасета, использованного для обучения: если заказчик передавал 50 000 уникальных изображений, а исполнитель обучился только на 5 000 из них, это явное невыполнение обязательств. Проверяется наличие аугментации, балансировка классов, а также корректность разбиения на тренировочную, валидационную и тестовую выборки. В заключении фиксируется, достигает ли модель заявленных метрик на репрезентативном тесте, а при несоответствии — указывается, связано ли это с недостатком данных, неправильной архитектурой или ошибками в коде.

🔍 Раздел 7. Оценка качества размеченных данных и аннотаций

Качество системы компьютерного зрения прямо зависит от качества разметки обучающих данных. Эксперт проверяет, соблюдены ли стандарты аннотирования (формат COCO, YOLO, Pascal VOC), нет ли грубых ошибок (неправильные классы, пропущенные объекты, некорректные bounding boxes), а также оценивает межэкспертную согласованность, если разметка выполнялась разными людьми. Если исполнитель использовал сторонние сервисы краудсорсинга без контроля качества, это отражается на точности модели. В рамках экспертизы может быть проведена повторная разметка небольшой случайной выборки и сравнение с исходной; при существенных расхождениях делается вывод о невалидности обучающего датасета. Это особенно важно, если заказчик оплачивал создание размеченного датасета как отдельную работу — тогда некачественная разметка является прямым нарушением договора.

💾 Раздел 8. Проверка целостности и актуальности версионного контроля

Современная разработка IT-систем обязана вестись с использованием систем контроля версий (Git, SVN), и экспертиза обязательно включает анализ репозитория: количество коммитов, их регулярность, наличие осмысленных сообщений, ветвление, а также наличие тегов релизов. Это позволяет установить, велась ли работа систематически или же код был написан «в авральном режиме» за несколько дней до сдачи. Отсутствие системы контроля версий или ее использование с нарушениями (например, все изменения сделаны одним коммитом без истории) является косвенным, но весомым признаком непрофессионализма и, возможно, невыполнения полного объема работ. Эксперт также проверяет, соответствует ли текущая версия кода тому, что было продемонстрировано на приемочных испытаниях, и нет ли расхождений между обещанными и фактически реализованными функциями.

🧪 Раздел 9. Документирование API и наличие интерфейсов взаимодействия

Система компьютерного зрения редко существует изолированно — она должна интегрироваться с внешними системами заказчика (ERP, WMS, видеорегистраторы, системы контроля доступа). Поэтому наличие качественной документации API (REST, gRPC, WebSockets) и примеров вызовов является критическим. Эксперт проверяет, все ли заявленные эндпоинты (endpoints) реализованы, корректно ли обрабатываются параметры запроса и возвращаются ли ответы в установленном формате (JSON, XML, Protocol Buffers). Также оценивается наличие механизмов аутентификации, ограничения частоты запросов, логирования ошибок и мониторинга. Если API отсутствует или реализован частично, это означает, что система не готова к промышленной эксплуатации, и объем выполненных работ снижается пропорционально.

📂 Раздел 10. Анализ документации пользователя и администратора

Договоры по разработке IT-систем почти всегда предусматривают поставку эксплуатационной документации: руководство пользователя, руководство администратора, описание архитектуры, инструкция по развертыванию и восстановлению. Эксперт оценивает полноту, актуальность и качество этих документов. Если документация составлена формально, содержит множество ошибок, не соответствует реальному коду или отсутствует вовсе — это существенное нарушение, поскольку заказчик не может самостоятельно эксплуатировать и обслуживать систему. В судебной практике нередки случаи, когда стоимость документации составляет до 20–30% от общего бюджета проекта, и ее отсутствие является основанием для пропорционального уменьшения оплаты.

📊 Раздел 11. Оценка метрик производительности в реальных сценариях

Лабораторные тесты часто показывают лучшие результаты, чем эксплуатация «в поле». Поэтому эксперт обязательно проводит оценку системы на данных, максимально приближенных к реальным условиям заказчика: с учетом уровня шума, засветов, динамических сцен, движения камеры. Для этого может быть использован метод «field testing» — выезд на объект или использование архивных видеозаписей, предоставленных заказчиком. Измеряется частота кадров (FPS), задержка (латентность), количество ложных срабатываний в минуту, а также поведение системы при пиковых нагрузках (например, одновременная обработка 10 видеопотоков). Если реальные показатели отличаются от заявленных более чем на 30%, эксперт фиксирует несоответствие. При этом он учитывает аппаратное обеспечение, на котором проводились тесты, чтобы исключить фактор недостаточной мощности «железа» заказчика.

🧬 Раздел 12. Проверка соблюдения лицензионной чистоты кода

Многие проекты компьютерного зрения используют библиотеки с открытым исходным кодом, распространяемые под лицензиями GPL, MIT, Apache и т.д. Однако коммерческие системы могут требовать отсутствия «вирусных» лицензий (GPL), которые заставляют раскрывать весь исходный код. Эксперт с помощью инструментов (FOSSology, ScanCode) анализирует зависимости проекта и выявляет возможные лицензионные конфликты. Если исполнитель использовал библиотеки с ограничительными лицензиями без согласования с заказчиком, это может сделать систему непригодной для коммерческого использования и является существенным дефектом. Также проверяется, не содержит ли код фрагментов, скопированных из чужих репозиториев без указания авторства — это не только этическая, но и правовая проблема.

🧠 Раздел 13. Оценка уровня инновационности и оригинальности алгоритмов

В некоторых контрактах отдельно оговаривается создание новых научно-технических решений, а не использование готовых моделей. Эксперт сравнивает архитектуру и обученные веса модели с популярными открытыми решениями (например, из библиотек Hugging Face, PyTorch Hub) и определяет степень модификации. Если единственным отличием является смена последних слоев классификатора, а основная часть модели (backbone) осталась стандартной — это трудно признать разработкой. С другой стороны, если исполнитель предложил новую функцию потерь, специфическую аугментацию или оригинальную схему ансамблирования, это повышает ценность работы. Эксперт дает оценку «глубины доработки» на основе сравнения с известными научными публикациями и открытыми реализациями.

📊 Раздел 14. Экономическая оценка объема фактически выполненных работ

На основе всех перечисленных параметров эксперт составляет заключение о проценте выполнения каждого этапа проекта (в соответствии с календарным планом или вехами). Например: «Модуль детекции выполнен на 95% по функционалу, но только на 60% по точности; модуль трекинга — на 30%; документация — на 10%; обучение персонала — не проводилось». Далее с использованием методов стоимостного инжиниринга определяется фактическая стоимость выполненных работ, исходя из трудоёмкости, рыночных ставок и стоимости материалов (серверные мощности, лицензии). Эксперт также может указать, какие доработки необходимы для приведения системы к требованиям ТЗ, и оценить их стоимость и сроки. Это особенно важно, если суд принимает решение о соразмерном уменьшении цены.

📝 Раздел 15. Роль эксперта в судебном процессе: дача пояснений и ответы на вопросы

После выдачи письменного заключения эксперт часто вызывается в суд для устных пояснений. Он должен быть готов ответить на технические вопросы сторон, объяснить значение метрик, обосновать выбор методов тестирования, а также показать, почему он интерпретирует ТЗ именно таким образом. В Союзе «Федерация судебных экспертов» проводится специальная подготовка специалистов к судебным выступлениям, включая тренировки по перекрестному допросу. Эксперт сохраняет нейтральный тон, оперирует исключительно фактическими данными и расчетами, избегая оценочных суждений в адрес участников спора. В случае возникновения новых вопросов от суда эксперт может дать письменные дополнения к заключению.

📌 Раздел 16. Распространенные ошибки исполнителей и способы их выявления

За годы практики Союза «Федерация судебных экспертов» выявлены типичные уловки недобросовестных подрядчиков. Например, передача модели, обученной на открытом датасете, но с измененными именами файлов, чтобы скрыть источник. Или использование «синдрома демонстрации»: показ заказчику превосходных результатов на заранее подготовленных красивых видео, а в реальности работа с «сырыми» данными дает сбой. Часто встречается «мертворожденный код» — проект компилируется, но при попытке изменить любой параметр падает. Также распространено завышение числа классов распознавания: в коде заявлены 50 классов, но для большинства из них нет весов, либо они с нулевой точностью. Эксперт обнаруживает такие махинации путем проверки наличия и размера файлов весов, анализа логов обучения и сравнения с заявленной архитектурой. Все эти факты фиксируются в заключении и служат основанием для признания работ невыполненными в полном объеме.

📋 Раздел 17. Развернутые практические кейсы из деятельности Союза «Федерация судебных экспертов»

Кейс 1. Спор между логистическим оператором и разработчиком о системе распознавания повреждений грузов на конвейере. Заказчик оплатил разработку системы, которая должна была автоматически обнаруживать дефекты коробок (вмятины, разрывы, намокание) на движущейся ленте со скоростью 2 м/с с точностью не менее 97%. После внедрения система работала нестабильно: при ярком освещении выдавала 95% точности, но при облачности падала до 60%, а также не распознавала 12 из 20 типов повреждений, указанных в ТЗ. Эксперты Союза «Федерация судебных экспертов» провели статический анализ кода и выявили, что разработчик использовал стандартную модель ResNet-50 без дообучения на специфических данных заказчика, а в качестве датасета взял открытые изображения поврежденных коробок из другого региона. Динамическое тестирование на реальных записях с конвейера в течение 8 часов показало среднюю точность лишь 67%. Эксперты также обнаружили, что в коде отсутствует модуль калибровки освещения и нормализации цветового баланса, что было прямым нарушением ТЗ. В результате суд снизил стоимость контракта на 78% (с 12 млн до 2,6 млн рублей), обязал исполнителя вернуть остаток, а также оплатить неустойку за простой линии из-за перестройки системы, который составил 14 рабочих дней. Дополнительно эксперты предоставили детальный план доработок с оценкой трудоемкости 560 человеко-часов, что помогло заказчику выбрать нового подрядчика.

Кейс 2. Конфликт в сфере безопасности: система распознавания лиц для пропускного пункта в бизнес-центре. Разработчик утверждал, что поставил полностью функционирующую систему с точностью 99,5% на базе собственной нейросети. Однако после монтажа система пропускала посторонних (более 15 ошибок в день) и отказывала сотрудникам при изменении прически или очках. Эксперты провели исследование файлов весов модели и обнаружили, что она была скачана с открытого репозитория (архитектура MobileNet с предобучением на датасете VGGFace2) и лишь переобучена на 300 фотографиях сотрудников, тогда как по ТЗ требовалось обучение на 5000 уникальных изображений в разных ракурсах и условиях. Также была проверена система аугментации — она оказалась отключена, что объясняло низкую устойчивость к изменениям внешности. Эксперты провели собственное тестирование на 2500 кадрах, снятых в коридорах бизнес-центра, и получили F1-score всего 0,82 при заявленных 0,99. Суд признал систему не соответствующей договору, обязал исполнителя возвратить 80% аванса (6,5 млн рублей из 8,1 млн) и дополнительно взыскал 1,2 млн рублей за ущерб репутации, так как в прессе появились негативные отзывы о «ненадежной охране». Экспертное заключение детально описывало кривую обучения, показавшую отсутствие сходимости на валидационной выборке, что свидетельствовало о переобучении на малом наборе данных — это стало ключевым аргументом.

Кейс 3. Разбирательство между производителем сельхозтехники и IT-компанией о системе выявления сорняков на поле. Система должна была работать на беспилотном опрыскивателе, распознавая 7 типов сорняков с точностью 94% в реальном времени. Однако в поле система путала лебеду с полынью, а также пропускала мелкие сорняки. Эксперты Союза «Федерация судебных экспертов» проанализировали размеченные данные и выявили систематическую ошибку: аннотаторы перепутали классы в 18% изображений, а также не размечали сорняки на заднем плане. Кроме того, код содержал ошибку в обработке изображений с разным разрешением — модуль ресайза некорректно обрезал края, теряя до 12% площади кадра. При динамическом тестировании на 6 часах видеозаписей с различных типов почв реальная точность составила 61% для всех классов, а для мелких — менее 30%. Эксперты рассчитали, что для исправления требуется полное переобучение с новым датасетом объемом не менее 200 000 аннотаций, что соответствует 60% первоначальной стоимости проекта. В итоге суд обязал исполнителя вернуть 4,3 млн рублей из 7,8 млн, а заказчику были переданы все наработки и сырые данные для их использования с другим подрядчиком. Интересно, что эксперт дополнительно указал на несоблюдение методологии кросс-валидации, что подтверждалось анализом журналов обучения — это был весомый технический довод.

Кейс 4. Спор о поставке модуля распознавания дефектов сварных швов для трубопроводного завода. Срок выполнения контракта истек, но подрядчик сдал «пре-релизную» версию, отказавшись от гарантийных обязательств. Заказчик потребовал признать работы невыполненными. Экспертиза показала, что в коде присутствуют 17 «todo-комментариев» (недоделанных функций), модуль сварки не интегрирован с производственной базой данных, а пользовательский интерфейс представляет собой консольное приложение без графического отображения дефектов, несмотря на требование ТЗ о визуализации. Также в репозитории отсутствовали тесты, а файл с обученными весами имел размер всего 17 МБ, что было аномально мало для заявленной архитектуры (ожидалось не менее 200 МБ). При попытке запуска системы на эталонных сварных швах она выдавала ошибку «module not found» для библиотеки, которая не была включена в требования. Эксперт сделал вывод, что фактически выполнено не более 15% от общего объема работ, и стоимость этих работ не превышает 350 тыс. рублей из 4,2 млн, уплаченных в качестве аванса. Суд поддержал позицию эксперта, и исполнитель был обязан возвратить разницу с процентами за пользование чужими денежными средствами. Важным моментом стало то, что эксперт провел анализ временных меток файлов, показавший, что основная часть кода была написана в последнюю неделю перед сдачей, что косвенно подтверждало «штурмовщину».

Кейс 5. Масштабный спор о системе мониторинга лесных пожаров с использованием дронов и компьютерного зрения. Государственный заказчик требовал систему, способную обнаруживать очаги возгорания с вероятностью 98% при дальности до 5 км на основе тепловизионных и оптических каналов. Исполнитель сдал систему, но на первом же тестовом полете она выдала 47 ложных тревог на обычные костры туристов и пропустила реальный контролируемый пал, заложенный комиссией. Эксперты Союза «Федерация судебных экспертов» провели всесторонний анализ: оказалось, что модель обучена только на дневных оптических снимках высокого разрешения, а ночной и тепловизионный каналы вообще не интегрированы. Более того, в коде отсутствовал алгоритм фильтрации стационарных объектов (дым от заводов, пар из труб) — это было прямое нарушение раздела ТЗ о «различении антропогенных и природных источников тепла». Эксперты также выявили, что метрики, предоставленные заказчику, были рассчитаны на тестовом наборе, содержащем только ясные дни, тогда как ТЗ требовало все погодные условия. Сумма контракта составляла 96 млн рублей; эксперт определил, что реально выполнена лишь работа по созданию базового детектора (около 22% от общего объема) и то с грубыми ошибками. В итоге суд расторг контракт, обязал исполнителя вернуть 70 млн рублей, а заказчик получил право использовать исходный код как базовый, но с полной переработкой системы. Эксперт также разработал рекомендации по организации независимых приемочных испытаний для будущих проектов.

📌 Раздел 18. Рекомендации заказчикам и исполнителям для предотвращения споров

Чтобы избежать дорогостоящих судебных разбирательств, рекомендуем фиксировать в ТЗ не только конечные метрики, но и промежуточные этапы с четкими критериями приемки: например, точность на валидационной выборке не менее 90% к третьему месяцу. Необходимо предусмотреть в договоре порядок проведения независимого тестирования и обязанность исполнителя предоставлять не только исполняемый код, но и среду воспроизведения (Docker-контейнеры), а также все датасеты с детальным описанием. Заказчику следует включать в приемочную комиссию технических специалистов, обладающих компетенциями в машинном обучении, либо привлекать внешнего независимого аудитора на ранних этапах. Исполнителям же полезно документировать каждый этап в системе контроля версий, а также регулярно предоставлять демонстрации работающих прототипов с фиксацией достигнутых показателей — это создает прозрачную историю разработки и снижает риск претензий.

Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте 🔴 https://krimexpert.ru