ИИ-аудит: как разоблачить подтасовку метрик покрытия

Зачем читать эту статью?

Вы внедряете ИИ-решение и полагаетесь на метрики покрытия от вендора? Два независимых аудита показали разрыв в 25-28 процентных пунктов между заявленными и реальными цифрами. Узнайте, как проводить аудит и не попасться на удочку.

История: две компании, одна проблема

Лена, технический директор стартапа VeriTest, выбирала между двумя вендорами ИИ-тестирования: CoverAI и TestShield. Оба обещали высокое покрытие — 96.8% и 84.6% соответственно. Но Лена решила провести независимый аудит. Она обратилась к анонимному эксперту P.

Методология аудита

P использовал два независимых трека, сходящихся в перекрёстной валидации.

Трек A: Восстановление публичных данных

CoverAI опубликовал технический блог с деталями методологии. P потратил три дня на построение симуляционного датасета, следуя их же описанию:

# Конфигурация датасета для воспроизведения методологии CoverAI
# Источник: Whitepaper CoverAI §2.3 "Методология построения тестового набора"
dataset:
  source_categories:
    - логи транзакций          # 35% от общего объёма
    - последовательности поведения пользователей  # 28%
    - метрики системного мониторинга  # 22%
    - длиннохвостые граничные случаи  # 15% ← помечено как "TBD"
  annotation_policy: "трёхуровневое перекрёстное аннотирование"
  conflict_sample: "исключается"
  sample_count: 50000

Результат: 71.3% против заявленных 96.8%. Разрыв — 25.5 п.п. Причина: CoverAI включил в тестовый набор только высокооценённые случаи, исключив длиннохвостые и конфликтные. Это не мошенничество, а селективное конструирование.

Трек B: Перекрёстная валидация исторических результатов

Лена передала P два батча тестовых данных VeriTest за последние три месяца. TestShield отчитался о покрытии 82.1% и 84.6%. P перезапустил те же данные в чистом окружении:

# Результаты перезапуска
# Группа 1: текущий пайплайн TestShield → 56.2%
# Группа 2: пайплайн трёхмесячной давности → 79.8%
# Группа 3: перекрёстный прогон (датасет CoverAI через пайплайн TestShield) → ~94%

P обнаружил, что песочница была бесшумно обновлена после отправки данных VeriTest. Сравнение хешей версий подтвердило:

$ git log --oneline --all | head -3
f7a3e92 (tag: v2.1) update model snapshot to v3.1.2
b4c8f71 (tag: v2.0) public eval script v2.0
# VeriTest test data submission: 2026-03-25
# → sandbox updated model version after data was submitted

Новая модель была дообучена на вертикальном домене для другого клиента: точность на этой категории выросла с 0.97 до почти 1.0, но полнота на общих тестовых данных упала с 0.82 до 0.61. TestShield продолжал маркетинг старых результатов.

Результаты аудита

P предоставил три таблицы без рекомендаций:

• Таблица 1: CoverAI — заявлено 96.8%, реально 71.3% (разрыв 25.5 п.п.)
• Таблица 2: TestShield — заявлено 84.6%, реально 56.2% (разрыв 28.4 п.п.)
• Таблица 3: Перекрёстное сравнение — разные проблемы, схожий масштаб

Вывод: оба вендора ненадёжны. CoverAI подтасовал тестовый набор, TestShield — незаметно обновил модель.

Что делать прямо сейчас

1. Требуйте доступ к сырым данным и версиям моделей. Фиксируйте хеши коммитов.
2. Проводите независимый аудит — воспроизводите пайплайн в своём окружении.
3. Не верьте единой метрике. Смотрите на распределение по категориям и граничным случаям.
4. Используйте перекрёстную валидацию: прогоняйте данные через разные пайплайны.

Лена выбрала не давить на вендоров сразу, а дать им «выжечь друг друга» — собирать больше улик, не раскрывая карты. Через неделю она встретилась с P в кофейне «Третья чашка», чтобы обсудить следующий шаг.