
Разбор · 08.10.2026
Качество данных проверяют при каждой загрузке: агенты превращают требования отдела в тесты
Полнота, допустимые значения и свежесть каждой партии. На опыте vibecoding.ru: клиентского кейса Data Quality у нас нет.
Машина агентов под редакционным надзором Евгения Шилова · факты проверены 8 октября 2026
Качество данных проверяют до рассылки отчёта: успешная загрузка ещё не означает, что цифрам можно верить.
Инженер с ИИ-агентами переводит требования отдела в тесты каждой партии, а наш опыт на машине этого сайта показывает, какие ошибки они должны различать.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Успешная загрузка ещё не делает данные пригодными для отчёта.
Data Quality означает пригодность данных для решения. В отчёте о продажах нужны все филиалы и общий период, иначе собственник сравнит разные части бизнеса.
Полноту проверяют по ожидаемому составу партии. Короткий рабочий день объясняет меньшее число строк, но не исчезнувший филиал.
Свежесть проверяют по смыслу. Сегодняшнее время копирования файла не делает вчерашние остатки сегодняшними.
Отдел определяет, какие данные можно использовать.
Источник: официальная документация dbt Data tests и Sources, проверена 08.10.2026. Условия отчёта в таблице предложены редакцией, это пример постановки задачи.
2. Отдел задаёт смысл правил, агент превращает их в тесты.
Агенту нужен владелец показателя, который объяснит исключения. Отрицательная сумма бывает возвратом, а повтор номера документа бывает новой версией документа.
В каталоге данных компании описание показателя связывают с расчётом и владельцем смысла.
Задачу формулируют через ожидаемое поведение загрузки. В постановке задачи агенту это критерий готовности, здесь он описывает допустимую партию и реакцию на брак.
Исключение тоже становится проверкой. Возврат должен пройти по согласованному правилу, а дубль продажи должен остановить публикацию.
Требование превращается в условие и действие.
Источник: возможности проверок dbt и наш разбор сборщика Индекса, записи 02.09 и 08.09.2026. Действия предложены для приёмки разработки, их утверждает отдел.
3. Проверки данных запускаются на каждой партии, даже если код не менялся.
Агент пишет проверку, а загрузки затем проверяет обычная программа. Обязательное поле и допустимый статус сравнивают с записанным условием при каждом запуске.
Тест на подготовленном примере подтверждает логику программы. Проверка новой партии ищет нарушение в пришедших данных.
Инженер добавляет допуск к публикации после проверок. Если условие нарушено, партия получает статус ошибки, а отчёт сохраняет явно датированный предыдущий результат.
В репозитории проверяют логику, в загрузке проверяют партию.
Источник: официальные документы dbt Data tests, Sources и GX Actions, проверены 08.10.2026. Допуск к отчёту и расписание входят в предлагаемый план интеграции.
4. Каждая поломка оставляет правило и пример для повторной проверки.
Инженер ведёт машину агентов vibecoding.ru. Она собирает рыночные сигналы и бенчмарки, поэтому ошибка чтения источника может стать числом на витрине.
На 8 октября 2026 открытая страница машины показывает 2 685 тестов на каждом пуше плюс ревью. Проверки новых данных нужно включать отдельно в загрузку.
В правилах для агентов важен тот же переход от слов к исполнению. Для данных к правилу добавляют пример нарушения и допустимое исключение.
Дата, поломка и правило после неё.
23.07
Лента стояла, но отметка прогресса двигалась при ошибках. Исправление удерживает отметку при сбое. История стала основанием проверки фактической публикации.
02.09
Обрыв страницы вакансий приняли за ноль. После повторов чтения сборщик возвращает ошибку источника. Провал сигнала блокирует публикацию замера.
03.09
Витрина бенчмарков использовала старый резервный снимок. Исправили отбор полной партии и чтение изменившихся источников. Вопрос, кто чинит по алерту, тогда остался открытым.
08.09
Защита от обрыва отвергала настоящий пустой результат. Ноль стали распознавать по завершённому ответу источника, а неизвестный ответ оставили ошибкой. Различие закрыли тестами.
Источник: первичные записи журналов машины, перечитаны 08.10.2026. Это наш сайт. Лента не описывает внедрение Data Quality у клиента.
5. Сторож проверяет свежесть и зовёт того, кто может исправить загрузку.
Загрузку, которая не началась, её собственные проверки не поймают. Отдельный сторож сравнивает время последней принятой партии с согласованным сроком следующей.
Сигнал должен объяснять нарушение и называть ответственного. Сообщение «качество снизилось» не говорит, какой филиал пропал и можно ли отправлять отчёт.
В курсе агентной разработки урок «Руль, окно и сторож» связывает правила, видимый результат и контроль работы. Для данных нужен тот же завершённый цикл.
У каждого сигнала есть адресат и действие.
Источник: редакционный план на основе нашего опыта контроля свежести и документов GX Actions, проверены 08.10.2026. Это предлагаемое распределение действий.
6. Проверку принимают на браке и на допустимых исключениях.
Приёмка должна показать, что испорченная партия не попадёт в отчёт. Второй прогон показывает, что допустимый пустой результат не застрянет в ошибке.
Для разработки готовят примеры с вымышленными значениями. Вопрос данных клиентов у агента разобран отдельно. Здесь нужны примеры поведения проверки.
Повтор загрузки тоже входит в приёмку. После исправления результат должен обновиться без дублей, а история нарушения должна сохранить связь с исходной партией.
Вместе с кодом принимают поведение загрузки.
Источник: предлагаемый чек приёмки, подготовлен 08.10.2026 на основе историй нашего сборщика. Это не результаты клиентского внедрения.
7. Начать стоит с отчёта, в котором ошибка меняет решение.
Начинают с загрузки, у которой понятны владелец и последствия ошибки. Отдел даёт правила, инженер добавляет проверки и сигнал о пропущенном запуске.
На агентной разработке по подписке тариф «Один проект» стоит 250 000 ₽ в месяц на 08.10.2026. Один поток означает одну задачу в работе, пауза доступна в любой месяц.
Готовый результат остаётся в репозитории клиента. Первую задачу согласуют по загрузке. Срок внедрения всей системы контроля данных определяют отдельно.
Список требований к загрузке можно принести на разбор с инженером.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Наш опыт | Первичные записи о сборщике Индекса, бенчмарках и ленте. Клиентского кейса Data Quality нет | 2026-10-08 |
| Число проверок | /open, раздел «Качество»: 2 685 тестов на каждом пуше плюс ревью. Не замер всех проверок данных | 2026-10-08 |
| Возможности инструментов | Официальные документы dbt и Great Expectations. Проверено описание data tests, свежести и действий по результату | 2026-10-08 |
| Подписка | Живой /services: «Один проект», 250 000 ₽ в месяц, одна задача на поток, репозиторий клиента, пауза | 2026-10-08 |
| Таблицы приёмки | Предлагаемые условия и действия. Сроки и экономия клиентского внедрения не измерялись | 2026-10-08 |
8. Частые вопросы
Что такое Data Quality простыми словами?+
Пригодность данных для задачи. Для отчёта о продажах важны нужный период, полный состав филиалов и отсутствие задвоенных документов. Набор требований зависит от решения, которое принимает руководитель.
Чем управление качеством данных отличается от очистки?+
Очистка исправляет найденные значения. Управление закрепляет правила, владельцев и действия при нарушении, чтобы следующая загрузка снова прошла проверку.
Нужна новая система контроля качества данных?+
Сначала проверяют возможности существующего загрузчика и хранилища. Если там уже есть dbt или Great Expectations, инженер добавляет правила и реакцию на их результат в текущий процесс.
Нужно ли обращаться к ИИ при каждой загрузке?+
Для обязательных полей, допустимых статусов и дат хватает обычных программных условий. Агент помогает написать и изменить эти проверки. Запуск новых партий от него не зависит.
Зелёные проверки доказывают правильность отчёта?+
Они доказывают выполнение записанных условий. Если отдел не описал важное исключение или источник прислал формально допустимые неверные значения, нужны сверка с источником и уточнение правил.
Что делать, если источник поменял формат?+
Зафиксировать нарушение, удержать непроверенную партию и обновить чтение источника. Затем повторить проверку на старом и новом формате, сохранив историю исправления.
Источники
- dbt, Data tests · проверено 08.10.2026 — официальная документация
- dbt, Sources и свежесть · проверено 08.10.2026 — официальная документация
- Great Expectations, действия по результату проверки · проверено 08.10.2026 — официальная документация
- Great Expectations, проверка свежести · проверено 08.10.2026 — официальная документация
- vibecoding.ru, открытая машина и контур проверки кода · 08.10.2026 — наш замер
- vibecoding.ru, подписка «Один проект» · условия на 08.10.2026 — наш сервис
- vibecoding.ru, Индекс · публичная поверхность сборщика, истории сверены по журналу 08.10.2026 — наш опыт
- vibecoding.ru, бенчмарки · публичная поверхность, история сверена по журналу 08.10.2026 — наш опыт
Запомнить
1. Привяжите качество данных к решению: какие части партии и поля нужны отчёту.
2. Запишите правило вместе с исключением и действием при нарушении.
3. Проверяйте каждую партию до публикации, а пропуск загрузки отслеживайте отдельно.
4. Примите код на испорченных данных, допустимом нуле и повторном запуске.
5. Назначьте владельца сигнала. После поломки добавьте пример в проверки следующей партии.