Предыстория и постановка задачи
После прошлой статьи мне захотелось взять тот же стек — ИИ-агента и пару MCP-серверов — и попробовать собрать через него DQ-шаблон прямо в нашем BI-портале. MCP (Model Context Protocol) здесь выступает протоколом, позволяющим агенту обращаться к внешним инструментам: базе данных и API портала.
DQ — это Data Quality, проверка качества данных. В широком смысле сюда входят шесть измерений: полнота (все ли нужные значения заполнены), корректность (соответствуют ли данные ожидаемому формату), уникальность (нет ли дублей), согласованность (не противоречат ли записи друг другу), актуальность (насколько данные свежие) — и всё то, из чего потом складывается реальное доверие к данным в организации.
Что такое «универсальный шаблон» на практике
Шаблон получился не универсальным в наивном смысле — то есть не в духе «подставь любую таблицу, и система сама разберётся, что проверять». Оказалось, что «универсальным» можно сделать именно каркас: одни и те же этапы выполнения, единая таблица результатов, один набор отчётов, история запусков и каталог правил.
А вот сами правила — не универсальны. Они всегда остаются доменными, то есть зависят от предметной области конкретных данных. Это принципиальное ограничение, которое никакой агент не обходит.
Доменная специфика правил
Чтобы это не звучало абстрактно: в адресном реестре доменные правила — это КЛАДР (Классификатор адресов России), ФИАС (Федеральная информационная адресная система), ГКН (Государственный кадастр недвижимости), кадастровые номера и такие нюансы, как написание буквы «ё» в названиях улиц.
Для реестра контрагентов набор будет совершенно другим: ИНН, КПП, ОГРН — каждый со своими форматными и контрольными требованиями. Для данных о продажах — третий набор. Никакой агент не «угадает» эти правила без явного каталога.
Как работал агент
В качестве тестового датасета я взял открытый Реестр адресов Москвы. Задача агента строилась по следующей цепочке: через postgres-mcp он смотрит схему базы данных, затем выбирает подходящие проверки из каталога правил, запускает SQL-запросы, записывает результаты в таблицу dq_snapshots, а потом через modusbi-mcp собирает отчёты прямо в BI-портале.
Цепочка воспроизводима и логична. Ниже в статье я подробно разбираю, как именно агент шёл по каждому шагу и что получилось на выходе.
Почему агенту нельзя верить на слово
Даже после того, как шаблон был собран и отчёты появились в портале, эксперимент не даёт оснований доверять агенту безоговорочно. В статье я разбираю конкретные точки, где агент ошибается, делает неочевидные допущения или просто не может знать того, что знает предметный эксперт.
Это не значит, что инструмент бесполезен — скорее наоборот. Но это означает, что автоматическая сборка DQ-шаблона требует явного человеческого контроля на ключевых этапах: при формировании каталога правил, при интерпретации результатов и при принятии решений на основе метрик качества.
