ИИ не гарантирует качество данных — его гарантирует контур: ИИ предлагает, детерминированные проверки решают, человек принимает риск
Вопрос (кратко):
Департамент аналитики ggsel хочет снять операционную нагрузку с аналитиков: ИИ-модели должны собирать витрины в ClickHouse и, возможно, делать дашборды в DataLens. Но есть огромные вопросы к качеству и проверке данных — не про дубли и пробелы, а глубже: ИИ — блэкбокс, который не может гарантировать качества. Что делать, есть ли решения и кейсы?
Отчёт опирается на 8 отобранных механизмов и публичных production-кейсов (LinkedIn, Spotify, Uber, Vanguard, референсная архитектура AWS, golden-set evaluation Snowflake, data diff в CI, guardrails DataLens→ClickHouse) и каталог из 24 контролей и исследований; это практическая выборка, не полный каталог рынка. Часть цифр — заявления самих компаний. Источники проверены 29.09.2026.
Целевой безопасный конвейер: от вопроса до read-only DataLens
Наведите на этап, чтобы увидеть его содержание. Красным — обязательные пути отказа: abstain, fail gate, reject, rollback. У высокорисковых финансовых и executive-метрик всегда есть владелец и human sign-off; агент обязан уметь отказаться и запросить уточнение.
Синтаксически корректный SQL ≠ правильный ответ: у LinkedIn 96% компиляции и 99% валидных таблиц/колонок, но лишь 53% ответов эксперты признали верными; самая частая ошибка — неверный фильтр, 24% —
arxiv.orgКонтекст — самое дорогое: у Spotify кураторы приняли лишь 12,5% автосгенерированных пар «вопрос—SQL», 87,5% были шумом; после доменных кластеров с владельцами — 2 100+ сотрудников и 13 000+ диалогов —
engineering.atspotify.comНедетерминизм не исчезает: у Uber ~5% run-to-run изменения метрик, хотя ~78% пользователей экономят время, а типовой запрос ускорился с ~10 до ~3 минут —
uber.comBI-слой можно ограничить детерминированно: подключение DataLens к ClickHouse по умолчанию read-only (readonly=2), raw SQL выключен, экспорт можно запретить —
yandex.cloud
Матрица: что реально работает и где остаётся риск
| Паттерн / кейс | Механизм | Результат | Остаточный риск | Источник |
|---|
План на 90 дней
Дни 0–30 — фундамент
- Один низко/среднерисковый домен, 2–3 типовые витрины
- Контракты: grain, формулы метрик, join rules, владельцы
- 50–100 golden questions + edge cases и негативные тесты
- Зафиксировать текущие SLA и трудозатраты аналитиков
Дни 31–60 — фабрика PR
- AI создаёт PR: SQL, YAML-тесты, документация, черновик DataLens
- CI строит данные в sandbox ClickHouse
- Unit/data/contract tests, data diff, reconciliation с эталоном
- Аналитик ревьюит расхождения, не переписывает всё заново
Дни 61–90 — публикация
- Shadow run, canary, атомарная публикация
- Мониторинг: freshness, volume, distributions, metric drift, lineage
- Автоматический rollback по инциденту
- Расширять scope только после прохождения quality gates
Критерии go/no-go пилота
- Acceptance rate AI-PR без существенной переделки
- Analyst minutes per accepted artifact
- Доля golden set с совпавшим результатом, а не просто исполнимым SQL
- Semantic defect escape rate; инциденты и rollback rate
- False-pass / false-alarm тестов; freshness/SLA; cost и p95 runtime
- Abstention/clarification rate; доля артефактов с владельцем, lineage, контрактом и тестами
- Решение о rollout — по качеству и escape rate, не по числу сгенерированных SQL
Чего не давать агенту в первой версии
- Production DDL/DML — только Git-ветка и sandbox
- Самостоятельное изменение формул метрик
- Создание неописанных joins вне разрешённых join-paths
- Прямую публикацию executive-дашбордов: финансовые, регуляторные и executive-метрики всегда требуют владельца и human sign-off
Рекомендуемый стек контролей — внедрять поэтапно, не покупать всё сразу
Метод: 8 отобранных механизмов и production-кейсов (основной сравнительный набор) плюс каталог из 24 контролей, систем и исследований; веб-источники проверены 29.09.2026. Цифры кейсов (53%, 24%, 12,5%, ~5%, ~78%, 2 100+ пользователей и т.п.) взяты из публикаций самих компаний и статей и являются vendor/author-reported, не независимо верифицированной гарантией. Для места длинные формулировки механизмов сокращены; полный каталог из 24 контролей свернут в 8 строк рекомендуемого стека.