Качество данных — измеримые свойства данных, от которых зависит поведение ИИ-системы: полнота, актуальность, согласованность, машиночитаемость, однозначность владельца. В ИИ-проекте это не общая оценка «хорошие или плохие», а конкретные проверки с числовым результатом: доля заполненных полей, доля записей старше регламента, число нарушенных связей.
Свойства, которые измеряются, а не обсуждаются
Полнота — доля записей с заполненными обязательными полями. Пропуски модель не игнорирует, как человек, а заполняет правдоподобным значением: пустое поле «срок поставки» превращается в уверенный ответ «14 дней». Цена пропуска в ИИ выше, чем в отчётной таблице, — дефект тиражируется в ответы.
Актуальность — соответствие текущему регламенту. Измеряется долей записей старше установленного срока пересмотра. Устаревшая цена или отменённая процедура дают уверенный неверный ответ; пользователь не перепроверяет то, что система говорит уверенно.
Согласованность — отсутствие противоречий. Внутри записи суммы сходятся с итогами, статусы не конфликтуют; между записями ссылки ведут на существующие объекты. Каждое правило согласованности формулируется проверкой, а не пожеланием.
Машиночитаемость — доступность данных алгоритму. Сканы без текстового слоя, даты в свободной форме, таблицы картинками — данные формально есть, но недоступны; про перевод изображений в текст — статья «Распознавание документов (OCR)».
Однозначность владельца — у набора данных есть человек. Отвечающий за состояние конкретных данных, а не «ИТ вообще». Набор без владельца деградирует всегда: некому заметить и некого спросить; свойство организационное, но без него остальные быстро сходят на нет.
Как оценивать: автопроверки и выборочный аудит
Автоматические проверки гоняются постоянно и дёшево. Форматы — даты, ИНН, адреса почты; связи — ссылки на существующие записи; статистика — доля пустых полей, дубликаты, выбросы значений. Ловят структурные дефекты, не зависящие от смысла.
Выборочный аудит видит смысл, автоматика — нет. Случайная выборка 50–200 записей проверяется вручную по чек-листу: верно ли содержание, а не только формат. Выборка порядка сотни записей даёт оценку доли дефектов с точностью до единиц процентных пунктов — для решения «чинить или терпеть» этого достаточно.
Нужны оба механизма. Автопроверки не отличат формально заполненное, но неверное значение; аудит не масштабируется на весь корпус. Стандартная схема: автопроверки по расписанию, аудит — раз в квартал и после каждого изменения источника.
LLM ускоряет аудит, но не заменяет его. Модель размечает подозрительные записи и предлагает вердикты, человек подтверждает; доля проверок перепроверяется вручную. Полностью автоматическая оценка качества без выборочной людской перепроверки — само-оценка.
Мусор на входе — уверенный мусор на выходе
Механизм отличен от человеческого. Сотрудник спотыкается о дефект: замечает подозрительную запись и идёт уточнять. Модель не спотыкается — она строит наиболее правдоподобное продолжение с учётом дефектных данных. Противоречия увеличивают разброс ответов, пропуски — галлюцинации; дефект не помечается и передаётся дальше — в ответ клиенту, платёж, отчёт.
Цена дефекта не в метрике, а в передаче. Пять процентов ошибок в справочнике при ручном использовании — редкое недоразумение; в ИИ-системе это каждый двадцатый ответ, произнесённый уверенно и без ссылки на сомнение. Пороги качества для ИИ-контура задаются жёстче, чем для человеческого.
Почему цена видна не на демо, а в бою
Демо живёт на чистой выборке. Типовые документы, аккуратные записи, подготовленные вопросы — то, что отобрали для показа. Хвост распределения — сканы, опечатки, устаревшие записи, редкие сочетания — на демонстрацию не попадает.
Бой живёт на хвосте. Именно нетиповые записи формируют обращения в поддержку и потерю доверия: пользователи прощают системе отказ, но не уверенную неправду. Поэтому качество данных оценивается на случайной выборке из реального потока; оценка на «удобных» данных смещена кратно.
Граница с диагностикой до внедрения. Есть ли под задачу подходящие данные и в каком они состоянии на старте — тема статьи «Готовность данных»; здесь — свойства и проверки в ходе проекта и эксплуатации. Качество — не состояние, а процесс: без регламента проверок деградация неизбежна, со временем это проявляется как дрейф данных.
Где уместно и когда нужно
Инвестиции оправданы при трёх условиях. Массовый процесс — тысячи записей или документов в месяц, где дефект умножается на объём; дообучение модели — обучающая выборка тиражирует свои дефекты в веса; RAG — корпус знаний напрямую становится текстом ответов.
Очередность работ определяется задачей, а не списком свойств. Для извлечения полей критичны полнота и машиночитаемость; для ответов клиентам — актуальность; для учётных сценариев — согласованность. Чинят сначала то свойство, которое ломает конкретный сценарий: «повысить качество данных вообще» не решается.
Типичные ошибки
- Задача без декомпозиции. «Повысить качество данных» без указания свойства и проверки не решается: у каждого свойства своя метрика, свой метод и свой владелец.
- Чистка один раз перед пилотом. К эксплуатации качество возвращается к исходному за месяцы — источники продолжают генерировать дефекты, а проверки отключаются вместе с проектной командой.
- Только автопроверки. Формат верный, содержание неверное: город в поле страны, действующая форма с устаревшим смыслом — семантические дефекты видит только аудит.
- Аудит по удобной выборке. Первые сто записей или последняя выгрузка смещены относительно корпуса; нужна случайная, при заметной неоднородности — стратифицированная выборка.
- Измерение без порога. «Полнота 92%» — хорошо или плохо, зависит от цены пропуска в конкретном процессе; порог задаётся от цены ошибки, а не от круглого числа.
- Отчётность вместо свойств. Дашборд «индекса качества» без привязки к проверкам создаёт видимость контроля; число, за которым не стоит проверка, не управляет ничем.
Частые вопросы
С чего начинать чистку данных?
Со свойства, которое ломает целевой сценарий, и с замера его текущего уровня на случайной выборке. Порядок «полнота — актуальность — согласованность» универсален только на бумаге; на практике стартуют с самого дорогого дефекта.
Сколько стоит привести данные в порядок?
Обычно сопоставимо с бюджетом на модели и разработку, на запущенных процессах с многолетней историей — больше. Точная оценка — пробной чисткой репрезентативного среза: скорость правки сотни записей экстраполируется на корпус с поправкой на неоднородность.
Как часто перепроверять качество?
Автопроверки — непрерывно или по расписанию; выборочный аудит — раз в квартал, при смене источника и перед расширением сценариев. После подключения новой системы-источника внеплановый аудит обязателен.
Что важнее — полнота или актуальность?
Определяется задачей: учёт и отчётность ломаются от неполноты и несогласованности, ответы клиентам — от неактуальности. Гнаться за всеми свойствами одновременно дороже, чем последовательно, — приоритет задаётся сценарием.
Можно ли доверить проверку качества самой модели?
Как первичному фильтру — да: разметка подозрительных записей, поиск дублей и выбросов ускоряет аудит в разы. Как итоговой инстанции — нет: без выборочной ручной перепроверки оценка замыкается сама на себя.
Чем качество данных отличается от готовности данных?
Готовность — диагностика до внедрения: есть ли под задачу подходящие данные, объёмы и права. Качество — свойства и проверки найденных данных в проекте и эксплуатации: полнота, актуальность, согласованность, машиночитаемость, владелец.
Что почитать по теме
- Готовность данных — диагностика до внедрения.
- Дрейф данных — как качество уходит незаметно.
- Подготовка базы знаний — применение тех же правил к корпусу для RAG.
- Мониторинг ИИ-систем — где всплывают дефекты данных.
- Готовность данных к внедрению ИИ — практическая проверка перед стартом.