Перейти до основного вмісту
Основний•6–10 годин

AI Metric Reconciliation Lab

Перевірте AI-generated SQL і метрики через semantic contract, deterministic controls, authoritative reconciliation та regression cases до того, як цифра потрапить у dashboard або рішення.

metric contractsSQL validationdata reconciliationfailure analysisregression testing

Сценарій

Задача

AI згенерував SQL для ключового KPI, а dashboard показує інше число. Запит виконується без помилок, але це нічого не доводить: відмінність може бути у grain, timezone, join cardinality, filters, late-arriving data або самій business definition. Потрібно побудувати перевірку, яка відділяє syntactic success від semantic correctness і залишає відтворюваний evidence trail.

Покрокове виконання

1. Заморозьте семантику до генерації SQL

Результат: AI отримує explicit metric contract, а не вгадує бізнес-правила з назви колонки.

Завдання

  • →Запишіть grain і unit of analysis
  • →Зафіксуйте numerator/denominator, filters та exclusions
  • →Визначте timezone, period close і freshness rule
  • →Назвіть authoritative table/report та owner

Перевірки

  • ✓Одна й та сама метрика має один versioned contract
  • ✓Невизначені business rules позначені як open question
  • ✓AI не має права самостійно вирішувати policy ambiguity

2. Розглядайте generated SQL як candidate artifact

Результат: Успішний execution більше не маскує логічну помилку.

Завдання

  • →Збережіть prompt/context і exact query
  • →Перевірте schema та referenced fields
  • →Додайте row-count, null і duplicate checks
  • →Перевірте join keys, one-to-many/many-to-many cardinality та accidental fan-out

Перевірки

  • ✓Query success не є acceptance criterion
  • ✓Unknown field або implicit cast дає явний failure
  • ✓Join cardinality перевіряється окремо від totals

3. Виконайте authoritative reconciliation

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

Завдання

  • →Порівняйте KPI з authoritative report/source
  • →Перерахуйте totals альтернативним query/formula
  • →Перевірте edge segments і boundary dates
  • →Встановіть tolerance лише там, де вона має domain justification

Перевірки

  • ✓Mismatch не “округлюється” до PASS
  • ✓Tolerance має owner і rationale
  • ✓Кожна розбіжність локалізована до definition, data, query або source state

4. Перетворіть помилки на regression suite

Результат: Наступна зміна SQL, schema або моделі не повертає вже відому помилку.

Завдання

  • →Змоделюйте wrong join, stale partition, timezone shift, missing filter і duplicate rows
  • →Запишіть expected deterministic signal
  • →Додайте severity та release action
  • →Версіонуйте dataset/query/contract fingerprint

Перевірки

  • ✓Критична reconciliation failure блокує publication
  • ✓Regression case відтворюється без LLM judge
  • ✓Зміна metric contract запускає повторну baseline verification

Критерії приймання

  • Metric contract містить grain, definitions, filters, time semantics, freshness і authoritative source
  • Generated SQL збережений як versioned candidate artifact разом із assumptions
  • Join cardinality, duplicates, nulls, totals і edge segments мають deterministic checks
  • Ключовий KPI незалежно reconciled з authoritative source або має explicit unresolved discrepancy
  • Щонайменше п’ять failure cases перетворені на permanent regression tests

Матеріали перед виконанням

Структуровані відповіді LLM

Як перетворити довільний текст моделі на версіонований контракт даних із валідацією, retry, семантичною перевіркою та безпечним fallback.

Оцінювання LLM-систем у production

Як побудувати evaluation set, автоматичні та людські метрики, regression gates і спостережуваність для промптів, RAG та агентів.

Data governance для AI

Як керувати даними для AI від власника й контракту до lineage, якості, доступу, retention та схвалення датасетів, щоб моделі навчалися й відповідали на перевірених, дозволених і відтворюваних даних.