Чтобы составить чек-лист проверки данных с ИИ, передайте модели подтверждённую схему, реестр бизнес-правил, назначение набора данных, этап обработки и цену ошибки. Попросите оформить явные проверки структуры, типов, диапазонов, обязательных значений, уникальности, ссылочной целостности (referential integrity), допустимых значений, межполевой логики, своевременности, полноты и сверки. Затем испытайте каждое правило синтетическими проходящими и непроходящими примерами. Чек-лист становится рабочим, только когда у каждой проверки есть владелец, серьёзность, политика блокировки, путь к доказательствам и маршрут обработки сбоя.

Границы безопасного ввода и утверждения описаны в руководстве по ИИ. Если исходные данные уже ошибочны и их нужно исправить, используйте отдельный процесс очистки таблицы: валидация определяет и обнаруживает сбои, но не исправляет их молча.

Ключевые выводы

Определите набор данных, назначение, этап, владельца, потребителей и цену ошибки.

Используйте авторитетную схему и бизнес-правила; не выводите правила из названий столбцов.

Дайте каждому контролю стабильный Check ID и детерминированный метод проверки.

Охватите уровни строки, таблицы, связи, партии и агрегатов.

Разделяйте блокирующие сбои, предупреждения и информационные наблюдения.

Проверяйте сам чек-лист синтетическими положительными, отрицательными и граничными случаями.

Направляйте сбои ответственным людям; ИИ не утверждает исключения и не выпускает данные.

Что делает проверку исполнимой?

Размытый чек-лист говорит «проверить даты», «удалить дубли» или «убедиться, что итоги выглядят правильно». Исполнимый чек-лист называет точное поле или связь, допустимое условие, способ его проверки, область записей, сохраняемое доказательство и действие при непрохождении.

Валидность — не то же самое, что истинность. Корректная дата может описывать не то событие, а сошедшийся итог — содержать неверно классифицированные строки. Чек-лист обнаруживает заданные нарушения и выявляет нерешённые смысловые вопросы, но не гарантирует, что каждое значение точно отражает реальность.

Держите валидацию отдельно от очистки и утверждения. Обнаружение даёт доказательства. Исправление идёт по разрешённому прослеживаемому процессу. Выпуск — решение человека или управляемой системы на основе заданной политики.

Шаг 1. Определите назначение и этап

Начните с контракта данных. Запишите, что представляет набор, кто его создаёт и использует, какое решение или процесс он поддерживает, на каком этапе жизненного цикла выполняется проверка и что может случиться, если дефект пройдёт.

Государственная система качества данных Великобритании рассматривает качество как пригодность для цели и описывает управление качеством на всём жизненном цикле данных.［1］ Правило, важное при загрузке, может отличаться от правила перед отчётностью, обучением модели, миграцией или публикацией.

Поле контракта	Что записать
ID и версия набора	Стабильное имя и версия схемы
Назначение	Поддерживаемые решение, услуга, отчёт, миграция или анализ
Этап	Загрузка, преобразование, хранение, экспорт или выпуск
Производитель и потребитель	Системы и ответственные команды
Единица и гранулярность	Что представляет одна строка
Обновление	Ожидаемая частота, время отсечения и задержка
Чувствительность	Класс данных и ограничения доступа
Цена ошибки	Последствия для клиентов, финансов, права, безопасности или операций
Владелец и утверждающий	Люди, отвечающие за правила и политику выпуска

Если набор служит нескольким целям, задокументируйте отдельные профили правил. Поле, необязательное для разведочного анализа, может быть обязательным для выставления счетов.

Шаг 2. Соберите авторитетные правила

Не просите ИИ придумать чек-лист по файлу-образцу. Соберите описание схемы, словарь данных, контракт исходной системы, бизнес-политику, справочные таблицы, спецификацию преобразований, требования потребителей и известную историю инцидентов. Запишите владельца и версию каждого источника.

Если определений нет или они противоречат друг другу, создайте задачу для владельца данных. Пишите unknown rule, а не угадывайте по имени поля или наблюдаемому распределению. Существующие данные показывают, что происходило, но не доказывают, что разрешено.

Если надёжного словаря нет, сначала используйте процесс составления словаря данных. Если правило реализуется на SQL, процесс проверки SQL поможет оценить синтаксис и риски запроса, а выполнение остаётся контролируемым и только для чтения.

Шаг 3. Стандартизируйте записи, из которых состоит чек-лист проверки данных с ИИ

Дайте каждой проверке стабильный Check ID. Храните определение в проверяемом формате — например, в версионируемой таблице или файле конфигурации.

Поле контроля	Обязательное содержание
Check ID	Стабильный идентификатор, например `VAL-023`
Источник правила	Версионированная схема, политика или решение владельца
Область	Набор, таблица, строки, поля и исключения
Правило	Точное условие прохождения
Метод проверки	Запрос, утверждение, парсер или процедура сверки
Ожидаемый результат	Логическое значение, количество, допуск или утверждённый набор
Серьёзность	Критическая, высокая, средняя, низкая или информационная
Применение	Блокировка (blocking), предупреждение, карантин или наблюдение
Владелец	Человек, отвечающий за правило
Путь к доказательствам	Где хранятся версия входа и результат
Маршрут сбоя (failure route)	Очередь, команда, срок реакции и эскалация
Исключение	Утверждённая область, причина, срок действия и утверждающий
Триггер пересмотра	Изменение схемы, политики, инцидент или изменение у потребителя

Разделяйте серьёзность и применение. При миграции серьёзный дефект можно временно лишь наблюдать по утверждённому исключению, а незначительное на вид нарушение формата может блокировать машинный интерфейс. Решает владелец политики; модель только предлагает варианты.

Шаг 4. Проверьте структуру и типы

Структурные проверки подтверждают, что ожидаемые объекты существуют и разбираются. Проверьте тип файла, кодировку, разделитель, названия заголовков, наличие таблиц и столбцов, порядок полей (если он задан контрактом), форму записи и версию схемы. Отклоняйте неожиданные лишние поля, если они создают риск утечки или несовместимости.

Проверки типов должны проверять реальный контракт, а не только то, может ли программа преобразовать значение. Решите, является ли "0012" идентификатором или числом, отличается ли пустая строка от null, как работает десятичная точность, в каком часовом поясе метка времени и допускают ли логические значения только одно определённое представление.

Фиксируйте преобразования типов явно. Молчаливое преобразование может убрать ведущие нули или прочитать метку времени в неверном поясе. Успешного разбора недостаточно: сравните результат с ожидаемым смысловым типом.

Шаг 5. Добавьте проверки полей данных

Проверки полей обычно включают:

Обязательность: значение должно присутствовать для заданного типа строки.
Диапазон: число или дата попадает в утверждённый диапазон с включёнными или исключёнными границами.
Длина и формат: идентификатор, код или текст соответствует шаблону из контракта.
Допустимые значения: значение есть в версионированном справочном наборе.
Уникальность: значение или составной ключ встречается в заданной области только один раз.
Точность: валюта, измерение или процент сохраняют допустимую разрядность.
Условная обязательность: поле обязательно только при определённом состоянии другого поля.

Включайте граничные случаи. Если допустимый возраст — от 18 до 120, проверьте 17, 18, 120, 121, null, текст и дробное число. Если метка времени не должна быть позже отсечения партии, проверьте равенство границе и переходы часового пояса.

Не позволяйте ИИ выводить допустимые диапазоны из текущих минимума и максимума. Исторические значения могут содержать ошибки и не охватывать допустимые крайние значения. Используйте авторитетное правило или спросите владельца.

Шаг 6. Проверьте ключи и связи

Уникальность и ссылочная целостность действуют между строками или таблицами. Определите потенциальные, первичные и составные ключи, связи «родитель–потомок», кардинальность и поведение при удалении. Ищите дубли бизнес-ключей, записи-потомки без родителя, неожиданные соединения «многие ко многим» и родителей с невозможными состояниями потомков.

Документация PostgreSQL различает ограничения check, not-null, unique, primary key и foreign key и объясняет, что внешние ключи поддерживают ссылочную целостность между связанными таблицами.［3］ Ограничения базы данных ценны, но чек-листу могут понадобиться проверки до загрузки, связи между системами, временные правила или условия, которые нельзя безопасно выразить простым ограничением.

Для каждой связи укажите снимок и нормализацию ключей. Отдельно показывайте количество совпавших, несовпавших, совпавших многократно и исключённых записей.

Если основная задача — сравнить два набора и разобрать несовпадающие записи, используйте отдельный процесс сверки таблиц. Чек-лист может ссылаться на его результат, не вбирая в себя весь процесс сверки.

Шаг 7. Добавьте межполевую и временную логику

Межполевые правила выражают бизнес-смысл. Примеры: end_date >= start_date, сумма возврата не превышает списанную сумму, формат почтового индекса соответствует стране, закрытая запись требует причины закрытия. Запишите каждое как явный предикат с определённым поведением для null.

Временные проверки должны различать время события, загрузки, обновления и отсечения партии. Проверяйте слишком поздно поступившие события, метки времени в будущем, невозможные последовательности, пересекающиеся периоды действия, пробелы в обязательных интервалах и устаревшие справочные данные.

Избегайте правил, закрепляющих предвзятость или неутверждённые косвенные признаки. Корреляция в старых данных — не бизнес-ограничение. Если предлагаемое правило влияет на право на услугу, доступ, цены, занятость или другой значимый результат, требуйте соответствующей контексту предметной, правовой проверки, проверки конфиденциальности и справедливости.

Шаг 8. Измерьте полноту и своевременность

Полнота — это больше, чем заполненные поля. Определите ожидаемое число записей, ожидаемые разделы, обязательные сущности, периоды охвата и обязательные связи. Сравнивайте полученные записи с авторитетным контрольным итогом, если он есть.

Проверки своевременности должны задавать ожидаемое время поступления, допустимое опоздание, часовой пояс, праздники, окна повторных попыток и признак полной партии. Отличайте опоздание от отсутствия: партия может прийти вовремя, но содержать лишь часть ожидаемой совокупности.

Словарь W3C Data Quality Vocabulary позволяет описывать измерения качества, метрики, аннотации и связанное с наборами данных происхождение.［2］ Принимать этот словарь не обязательно, чтобы следовать принципу: храните, что измерено, какой метрикой, для какой версии набора, когда и кем или каким процессом.

Шаг 9. Сверьте агрегаты и инварианты

Добавьте проверки между уровнями: значения строк должны сводиться к итогам групп, итоги групп — совпадать с контрольными итогами партии, а начальный остаток плюс движения — равняться конечному, если предметная область задаёт такой инвариант. Укажите округление, конвертацию валют, допуск и исключённые статусы.

Правило сверки никогда не должно звучать как «итоги должны быть близки». Задайте абсолютный и относительный допуски, их основание и то, блокирует правило или предупреждает. Показывайте и разницу, и её составляющие, чтобы рецензент мог разобраться.

По возможности используйте независимые контрольные итоги. Два результата одного ошибочного преобразования могут совпасть, поэтому записывайте общие зависимости.

Шаг 10. Спроектируйте обработку сбоев

Каждому непройденному контролю нужен маршрут сбоя. Решите, блокировать ли партию, отправить ли затронутые записи в карантин, предупредить потребителей, продолжить по утверждённому исключению или остановить последующий процесс. Назовите владельца, срок реакции, требуемые доказательства и путь эскалации.

Поле сбоя	Обязательное содержание
ID запуска и Check ID	Конкретный запуск проверки и правило
Версия набора	Снимок входа и ревизия конвейера
Число сбоев	Затронутые строки и их доля
Примеры	Минимальные примеры с ограниченным доступом
Серьёзность и применение	Политика, применённая к этому сбою
Владелец	Человек или команда, отвечающие за разбор
Сдерживание	Блокировка, карантин, предупреждение или изоляция
Решение	Исправление, коррекция источника, принятое исключение или изменение правила
Утверждение	Уполномоченный рецензент и метка времени
Доказательство повторного запуска	Результат после исправления или исключения

Исключения должны быть узкими, ограниченными по времени и проверяемыми. Записывайте, кто их утвердил, почему, какие записи они охватывают и когда истекают. Никогда не просите модель отменить непройденный контроль.

Шаг 11. Испытайте синтетическими случаями

Для каждого правила создайте как минимум один проходящий случай, один непроходящий и нужные граничные случаи. Синтетические записи не должны содержать реальных персональных или производственных данных. Дайте им стабильные ID и ожидаемые результаты.

Примеры: дубль составного ключа, запись-потомок без родителя, дата окончания раньше даты начала, null, обязательный только для одного типа записи, значение ровно на максимуме, позднее, но допустимое событие и партия вне допуска. Убедитесь, что каждый случай нарушает только целевую проверку; иначе тестовый набор может не изолировать правило.

Модель может предлагать случаи по таблице правил, но покрытие и ожидаемые результаты проверяют рецензенты. Профиль NIST для генеративного ИИ описывает конфабуляцию и другие риски, требующие управляемой проверки.［4］ Сгенерированный тест, который лишь выглядит правдоподобно, не доказывает корректность контроля.

Шаг 12. Проведите пилот и версионируйте

Запустите чек-лист в непроизводственной среде на синтетических тестовых наборах и утверждённом историческом снимке. Сравните результаты с известными инцидентами и ручной проверкой. Неожиданные прохождения расследуйте так же серьёзно, как неожиданные сбои.

Версионируйте контракт набора, источники правил, чек-лист, реализацию, тестовые наборы и политику применения. Проводите повторную проверку после изменений схемы, политики, источника, потребителя, преобразований или рисков.

Не включайте блокировку в рабочей среде только потому, что черновик от ИИ выглядит полным. Владельцы данных утверждают смысл, инженеры проверяют реализацию и эксплуатационное поведение, владельцы безопасности и конфиденциальности — обработку чувствительных данных, а орган, отвечающий за выпуск, решает о применении.

Краткий контракт для промпта

Поручите модели использовать только предоставленные схему, источники правил и назначение набора данных; выдавать по одной строке на проверку с Check ID, точным предикатом, областью, поведением для null, методом проверки, ожидаемым результатом, вариантом серьёзности, вариантом применения, владельцем, доказательством, маршрутом сбоя (failure route) и синтетическими случаями; помечать противоречивые или отсутствующие правила как owner decision required; не выводите ограничения из распределения в выборке и не утверждайте исключения, исправления или выпуск данных.

Итоговая проверка

Назначение набора, гранулярность, этап жизненного цикла, потребители, чувствительность и цена ошибки задокументированы.
Каждое правило ссылается на авторитетный источник и владельца.
Охвачены проверки структуры, типов, полей, уникальности, ссылочной целостности, межполевой логики, времени, полноты, своевременности и агрегатов.
У каждой проверки есть детерминированная логика, поведение для null, ожидаемый результат и путь к доказательствам.
Серьёзность отделена от политики блокировки, предупреждения, карантина или наблюдения.
Синтетические проходящие, непроходящие и граничные случаи дают ожидаемые результаты.
Определены маршруты сбоев, владельцы, эскалация, исключения, сроки их действия и доказательства повторного запуска.
Применение в рабочей среде утверждается через обычный процесс выпуска организации.
Версии и триггеры пересмотра связывают схему, правила, реализацию и тестовые наборы.

Часто задаваемые вопросы (FAQ)

Чем валидация отличается от очистки?

Валидация определяет, выполняются ли заданные условия, и сохраняет доказательства. Очистка изменяет данные. Исправление должно быть разрешённым, воспроизводимым и отделённым от результата проверки.

Может ли ИИ вывести правила из примера?

Он может предложить вопросы, но наблюдаемые закономерности — не авторитетные правила. Подтверждайте каждое ограничение схемой, политикой, требованиями потребителей или у владельца данных.

Какие проверки должны блокировать конвейер?

Это решает утверждённая политика применения исходя из назначения и цены ошибки. Держите серьёзность отдельно от блокирующего поведения и документируйте исключения.

Достаточно ли ограничений базы данных?

Нет. Это сильные меры контроля для поддерживаемых инвариантов, но проверки жизненного цикла, между системами, своевременности, агрегатов и до загрузки могут требовать дополнительной валидации.

Как проверять значения null?

Определите для каждого поля и типа записи, различаются ли null, пустое значение, ноль, «неизвестно» и «неприменимо». Проверьте каждый допустимый и запрещённый случай.

Что такое хорошая проверка referential integrity?

Используйте точные нормализованные ключи родителя и потомка из одних и тех же определённых снимков, затем отдельно покажите совпавшие, записи без родителя, совпавшие многократно и исключённые записи.

Можно ли использовать производственные строки как тестовые данные?

Предпочитайте синтетические наборы. Если для пилота нужен утверждённый исторический снимок, минимизируйте его, защитите доступ и соблюдайте правила хранения и удаления.

Когда пересматривать чек-лист?

При изменении схемы, политики, источника, преобразований, потребителя, истории инцидентов или цены ошибки, а также с установленной периодичностью.

Кто утверждает исключение?

Назначенный владелец политики или данных после необходимой предметной проверки, проверки конфиденциальности, безопасности, правовой проверки или проверки выпуска. Исключение должно иметь ограниченную область, обоснование и срок действия.

Источники

UK Government — The Government Data Quality Framework — https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework
W3C — Data on the Web Best Practices: Data Quality Vocabulary — https://www.w3.org/TR/vocab-dqv/
PostgreSQL — Constraints — https://www.postgresql.org/docs/current/ddl-constraints.html
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 4 сентября 2026 г.

Как составить чек-лист проверки данных с ИИ