В CRM заказ отмечен как оплаченный, в учётной системе платёж ещё не проведён, а в выгрузке для аналитики сохранено вчерашнее состояние. Все три записи могут точно отражать свои системы. Но помощник, которому поручили ответить «можно ли отгружать заказ», получит противоречивый вход.
Начинать подготовку данных стоит с конкретного решения и правил интерпретации. Для этого полезен контракт качества: соглашение о составе данных, их происхождении, актуальности и действиях при нарушении условий.
Качество определяется задачей
В публикации «Качество данных в Big Data» рассматриваются характеристики качества данных. Для прикладного проекта эти характеристики нужно перевести в проверяемые условия. Поле может быть приемлемым для месячного отчёта и непригодным для решения, которое принимается сейчас.
В контракте запишите, какое событие отражает каждое значимое значение. «Дата оплаты» может означать создание поручения, поступление денег или проведение операции в учётной системе. Название столбца этого различия не объясняет.
Определите источник, уполномоченный подтверждать конкретный факт. Это не обязательно одна система на все случаи. Склад подтверждает физическое наличие, финансовая система — проведённый платёж, договорный реестр — действующие условия. Помощник должен сохранять эти границы.
Контракт на примере проверки заказа
Ниже — вымышленный пример. Пороговые значения иллюстрируют устройство договора между командами и не являются универсальными нормативами.
| Объект проверки | Условие | Реакция при нарушении |
|---|---|---|
| Идентификатор заказа | Непустой и однозначно связывает записи | Не объединять записи предположительно; отправить на разбор |
| Валюта и сумма | Валюта задана; сумма разобрана без округления до целых | Заблокировать денежное сравнение |
| Статус платежа | Значение взято из согласованного источника и словаря | Показать, что статус не подтверждён |
| Актуальность остатков | Обновление не старше согласованного для операции интервала | Запросить свежие сведения или передать решение сотруднику |
| Необязательный комментарий | Отсутствие допускается | Продолжить обработку без додумывания содержания |
| Версия схемы | Версия поддерживается обработчиком | Остановить загрузку нового формата до проверки совместимости |
Для критических реквизитов доля ошибок по всему массиву малоинформативна: один неверно связанный заказ может привести к неправильному действию. Поэтому обязательность условия задают на уровне операции, а агрегированную статистику используют для наблюдения за потоком.
Хранить факт и его происхождение вместе
Результат загрузки должен позволять ответить, из какого источника получено значение, когда оно относилось к реальности и когда попало в систему. Для выгрузки полезно сохранять идентификатор набора или контрольную сумму, версию преобразования и время среза.
Не заменяйте исходное значение нормализованным без следа. Если строка «1 250,50» преобразована в число, нужно иметь возможность проверить правила преобразования. Если код сопоставлен со справочником, зафиксируйте версию справочника.
W3C Data Quality Vocabulary описывает способы представления измерений качества и связанных метаданных. Даже без внедрения этого словаря полезно придерживаться его базового различения: характеристика качества, способ её измерения и результат измерения — разные объекты.
Для конкретного показателя запишите числитель, знаменатель и исключения. «Полнота 99%» непонятна, пока неизвестно, какие поля и записи проверялись. Сто пропусков в необязательном комментарии и сто отсутствующих идентификаторов заказа создают разные последствия.
Не прятать неудобные записи
Повреждённые, конфликтующие и неподдерживаемые входы направляют в отдельную очередь. У записи сохраняют причину, владельца разбора и связь с первоначальным запросом. Отбрасывание строки без уведомления может превратить техническую ошибку в потерянную бизнес-операцию.
В отчёте показывайте и качество принятого потока, и долю отклонённых входов. Иначе улучшение метрики можно получить простым исключением сложных случаев.
Пропущенное значение нельзя безусловно заменять нулём. Ноль может означать реальное отсутствие долга, количества или температуры по выбранной шкале. Для неизвестного значения нужен собственный статус, а для допустимого заполнения — явно согласованное правило.
Как менять контракт без остановки потребителей
Владельцы источника и потребителя договариваются о совместимости до изменения схемы. Новое необязательное поле обычно требует другого объёма работ, чем изменение смысла уже существующего статуса. Второй случай особенно опасен: формат остаётся прежним, а решение меняется.
Проверьте новую версию на сохранённых примерах и на свежих входах. Сравните различия по операциям, определите момент переключения и возможность возврата. Для воспроизведения старого результата потребуется старый набор данных и соответствующая ему логика.
Контракт должен иметь владельца с обеих сторон. Автоматическая проверка сообщает о нарушении, но не может самостоятельно решить спор о том, какая система отражает действующее бизнес-правило.
Что можно поручить модели
Модель может помогать разбирать свободный текст, предлагать соответствие полей и объяснять найденные расхождения. Для принятия критичных значений нужны проверяемые правила и источник подтверждения. Согласованность ответа сама по себе не подтверждает качество входных данных.
Для базы знаний вопросы версий и переключения дополнительно раскрыты в статье об обновлении RAG без поломки активной версии. Контракт качества нужен раньше: он определяет, какие данные вообще допустимо включать в новую версию.