Перейти к основному содержимому
Основной•6–10 часов

Лаборатория сверки AI-метрик

Проверяйте сгенерированные ИИ SQL и метрики через семантический контракт, детерминированные контроли, сверку с авторитетным источником и регрессионные кейсы до попадания числа в дашборд или решение.

контракты метриквалидация SQLсверка данныханализ сбоеврегрессионное тестирование

Сценарий

Задача

ИИ сгенерировал SQL для ключевого KPI, а дашборд показывает другое число. Запрос выполняется без ошибок, но это ничего не доказывает: причина может быть в grain, часовом поясе, кардинальности join, фильтрах, поздних данных или самой бизнес-дефиниции. Постройте проверку, которая отделяет синтаксический успех от семантической корректности и оставляет воспроизводимый след доказательств.

Пошаговое выполнение

1. Зафиксируйте семантику до генерации SQL

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

Задачи

  • →Зафиксируйте grain и единицу анализа
  • →Закрепите числитель, знаменатель, фильтры и исключения
  • →Определите часовой пояс, закрытие периода и freshness rule
  • →Укажите авторитетную таблицу или отчёт и owner

Проверки

  • ✓У метрики один версионируемый контракт
  • ✓Неопределённые бизнес-правила отмечены как открытые вопросы
  • ✓ИИ не вправе самостоятельно разрешать policy ambiguity

2. Считайте сгенерированный SQL candidate artifact

Результат: Успешное выполнение больше не маскирует логическую ошибку.

Задачи

  • →Сохраните prompt, контекст и точный query
  • →Проверьте schema и используемые поля
  • →Добавьте проверки row count, null и дубликатов
  • →Проверьте join keys и fan-out one-to-many или many-to-many

Проверки

  • ✓Query success не является acceptance criterion
  • ✓Неизвестное поле или implicit cast даёт явный failure
  • ✓Кардинальность join проверяется отдельно от totals

3. Выполните сверку с авторитетным источником

Результат: Ключевое число воспроизводится независимым способом, а расхождения объясняются.

Задачи

  • →Сравните KPI с авторитетным отчётом или источником
  • →Пересчитайте totals независимым query или формулой
  • →Проверьте крайние сегменты и граничные даты
  • →Используйте tolerance только при обосновании предметной областью

Проверки

  • ✓Mismatch не округляется до PASS
  • ✓У tolerance есть owner и rationale
  • ✓Каждое расхождение локализовано до definition, data, query или source state

4. Превратите ошибки в regression suite

Результат: Следующее изменение SQL, schema или модели не возвращает уже известную ошибку.

Задачи

  • →Смоделируйте wrong join, stale partition, сдвиг часового пояса, пропущенный фильтр и дубликаты
  • →Запишите ожидаемый детерминированный сигнал
  • →Назначьте severity и release action
  • →Версионируйте fingerprint dataset, query и contract

Проверки

  • ✓Критическая ошибка сверки блокирует publication
  • ✓Regression case воспроизводится без LLM judge
  • ✓Изменение контракта метрики запускает повторную baseline verification

Критерии приёмки

  • Контракт метрики содержит grain, определения, фильтры, временную семантику, freshness и авторитетный источник
  • Сгенерированный SQL сохранён как versioned candidate artifact вместе с assumptions
  • Кардинальность join, дубликаты, null, totals и крайние сегменты имеют детерминированные проверки
  • Ключевой KPI независимо сверен с авторитетным источником или имеет явное нерешённое расхождение
  • Минимум пять failure cases превращены в постоянные regression tests