ГлавнаяБлогКак найти подделку в AI-продукте: история одного аудита
Собеседования

Как найти подделку в AI-продукте: история одного аудита

Реальная история технического аудита AI-платформы: как инженер раскрыл подделку датасета и спас $18M. Узнайте, как проверять AI-продукты на честность.

Al
Редакция Algolitalgolit.ru
9 мин чтения25 июня 2026 г.

Как выявить подделку в AI-продукте: история одного технического аудита

Представьте: вы пишете чек на $18 миллионов за AI-платформу, которая якобы находит 89% дефектов в продакшене. Но что, если эти цифры — подделка? В этой статье мы разберём реальную историю технического аудита, где инженер за две недели раскрыл фальсификацию датасета и спас инвесторов от катастрофы. Вы узнаете, на какие детали смотреть при проверке AI-продуктов и почему чистота данных важнее любых метрик.

Предыстория: увольнение и контракты

Марка уволили после того, как компания превратила его 12-летний опыт в AI-скилл с точностью диагностики 96.8%. Через шесть недель после миграции с RabbitMQ на Kafka никто не перезапустил валидацию, и AI-скилл выполнил старую логику ретраев в 450 мс — смертельно для Kafka. В 4:12 утра CTO предложил Марку пятикратную зарплату за двухнедельный контракт. Марк согласился. За два года он взял ещё одиннадцать контрактов, получив прозвище «человек-аудит». Он понял: компании, внедряющие AI в продакшен, не понимают собственных систем.

Запрос от венчурного фонда

Однажды Марку написал партнёр венчурного фонда: «Компания Pulse AI. Series B. Юридический due diligence пройден. Технический — нужен кто-то, кто реально понимает, на что смотрит. CEO отчитывается о 89% обнаружения дефектов в продакшене. Но мы выписываем чек на $18 миллионов, а не на $18 тысяч. Посмотрите». Марк согласился на две недели. Перед звонком он открыл вкладку с архитектурным постом CTO Pulse AI и заметил в схеме конвейера данных: /pulse/ingestion/{env}/{source} — точно такое же именование, как в конвейере AI-скилла его старой компании. Совпадение? Он записал.

Технический due diligence: первые трещины

Во вторник CTO Pulse, Торрес, продемонстрировал Pulse Benchmark: автоматизированный конвейер от коммита до метрики обнаружения дефектов. Марк попросил показать данные evaluation set. Торрес ответил: «Конечно, подготовим». Но данные пришли только в среду, после дня задержки. Марк не торопил: он ждал трещин, которые появляются, когда кто-то лихорадочно чистит данные. Evaluation set содержал 1247 сэмплов дефектов в JSON. Каждый — с кодом, стектрейсом, классификацией ошибки. Выглядело идеально. Но Марк заметил в метаданных строку: processed_by: Apex-Lens-Cleaner v1.0.0. Незнакомый модуль. Он запомнил.

Анализ сэмплов: 44 точных совпадения

Марк просмотрел сэмплы по одному. На 30-м остановился: Java NullPointerException со стектрейсом из четырёх слоёв — без шума. В продакшене NPE обычно содержат 7-8 слоёв с логами потоков и GC. «Продакшен-данные грязные. Эти — нет», — подумал Марк. Он написал скрипт поиска ключевых слов и перекрёстно проверил evaluation set по трём открытым базам дефектов. Результат: 44 точных совпадения — исходники, номера строк, типы исключений совпали построчно. Ещё 54 сэмпла явно были сконструированы вручную. Итого 98 из 1247 — 7.9%. Этого достаточно, чтобы утверждать: данные сфальсифицированы. Марк не стал звонить партнёру сразу. Он ждал.

Разговор с командой оценки

На следующий день Марк встретился с командой оценки — три PhD без PM и Торреса. Он спросил: «Сколько раундов редактирования проходит дефект от продакшен-репорта до сэмпла?» Лидер команды ответил: «Два-три. В основном удаление шума и стандартизация формата». Марк понял: PhD сам не уверен в чистоте данных. «Удаление шума» — из 48-строчного NPE сделали 12 строк. Удалили не шум, а отпечатки реальных продакшен-данных. Марк не стал спорить. После встречи он прошёл мимо столов ops-команды и заметил: угол клавиатурных подставок, бейджи — всё идентично его старой компании. «Не совпадение. Привычка», — записал он.

Обратная разработка: трансплантация

Ночью Марк сделал то, за что ему не платили: он восстановил топологию конвейера данных из статьи Pulse Benchmark. В статье утверждалось, что evaluation set собран из «реальных продакшен-репортов». Но в методологии была фраза: «Набор данных был вручную отобран из репортов о дефектах за 14 месяцев». Марк сравнил её с документацией AI-скилла, сохранённой до увольнения. Дословное совпадение. Он написал пять строк: «44 точных совпадения + 54 ручной работы = 7.9%. Именование конвейера: /pulse/ingestion/{env}/{source} — идентично старому /knowledge/ingestion/{env}/{source}. Стандарты рабочих мест и бирки активов — трансплантированы. Язык статьи — дословная копия. Модуль Apex-Lens-Cleaner v1.0.0 обработал evaluation set, но не упоминается в публичной архитектуре. Модуль, который официально не существует, работает». Марк отправил партнёру короткое письмо: «Минимум 44 точных совпадения с публичными базами. Ещё 54 — ручная фабрикация. Рекомендую перезапустить Benchmark после удаления всех сэмплов, пересекающихся с публичными базами». Он не написал, что fuzzy-поиск утроил бы число. Пусть противник гадает, что ещё у вас в рукаве.

Звонок в 3:50 утра

В 3:50 утра позвонил Торрес. После десяти секунд молчания он сказал: «CEO хочет поднять метрику Benchmark до 95% перед Series C. У меня шесть месяцев. Те 44 — моя команда взяла из публичных баз. 54 — мы написали сами, потому что не нашли подходящих замен. Я не пытаюсь украсть деньги. Я пытаюсь сначала получить метрику, собрать раунд, а потом построить реальный конвейер за год». Марк не стал спорить. Он спросил: «Кто построил ваш конвейер приёма данных?» Пауза в три секунды. Марк сказал: «Я видел /pulse/ingestion/{env}/{source} раньше. До моего увольнения конвейер AI-скилла назывался /knowledge/ingestion/{env}/{source}. Вы были там». Торрес молчал. Марк подождал пять секунд и повесил трубку. Он не имел прямых доказательств, что конвейеры построены одним человеком. Но молчание в 3:50 утра — это подтверждение. Марк открыл ноутбук и дописал: «Торрес не отрицал. Молчание — ответ». Партнёр ответил: «Продолжай». Марк закрыл ноутбук. Он не сказал партнёру настоящую причину, по которой взял этот заказ: он узнал подпись инженера Калеба, который сидел напротив него три месяца и всегда спрашивал «Почему 450 миллисекунд?». Калеб исчез после массовых увольнений. А его именование конвейера появилось в Pulse.

Вывод: как защититься от поддельных метрик AI

Эта история — не про детектив, а про методологию аудита. Что делать, если вы проверяете AI-продукт?

  1. Всегда запрашивайте сырые данные evaluation set. Не верьте агрегированным метрикам. Смотрите на отдельные сэмплы.
  2. Проверяйте чистоту данных. Продакшен-данные грязные. Если сэмплы выглядят идеально — это подозрительно.
  3. Ищите пересечения с публичными базами. Напишите скрипт для поиска точных совпадений. Fuzzy-поиск даст ещё больше.
  4. Обращайте внимание на мелкие детали. Именование конвейеров, метаданные, нестандартные модули — всё это может выдать подделку.
  5. Не торопитесь с выводами. Ждите, когда оппонент начнёт заметать следы. Трещины появятся сами.
Прямо сейчас: если вы используете AI-инструмент с «высокой точностью», попросите у вендора доступ к evaluation set и проверьте его на пересечения с публичными базами. Это займёт пару часов, но может сэкономить миллионы.

#AI-аудит#проверка данных#технический due diligence#фальсификация метрик#история из практики
Al
Редакция Algolit

Пишем про алгоритмы, подготовку к собеседованиям и карьеру в IT — так, чтобы было понятно и полезно.

Хочешь закрепить знания на практике?

Решай задачи на Algolit — интерактивная платформа для обучения

Начать бесплатно →
Как найти подделку в AI-продукте: история одного аудита | Algolit