Агентний аналіз — це більше, ніж текст-у-SQL: уроки від Anthropic
Що каже стаття про самостійний аналіз від Anthropic про семантичні шари, навички, оцінювання та основи даних, і чому сам текст-у-SQL створює хибне враження точності.
Джерела: Anthropic is telling you that Agentic Analytics is not just text-to-SQL
Аналітичний сміття — це новий AI-сміття
Пост від Anthropic від 3 червня 2026 року про самообслуговуючі аналітичні системи публічно формулює те, що багато команд з обробки даних дізнавалися на власному досвіді: агентські аналітичні системи — це не те саме, що просто спрямувати Claude Code на базу даних та поставити йому запитання.
Більшість людей знають термін «AI-сміття». Аналітичне сміття — це його «родич». Завдяки кодувальним агентам тепер будь-хто може під’єднатися до бази даних та створювати аналітичні звіти. Це чудово для зниження бар’єрів входу, але з іншого боку майже ніхто не перевіряє цифри. Панелі керування надходять у вигляді файлів .html, сторінок Confluence чи скріншотів терміналу, і лише деякі з них були перевірені. Причиною є хибне відчуття безпеки. Оскільки ШІ так добре перекладають англійську мову на SQL, вважається, що відповіді мусять бути правильними.
Ця впевненість є хибною. Коли аналітика зводиться лише до генерації запитів, проблема розглядається занадто вузько, а супутня інфраструктура залишається непоміченою, хоча саме вона визначає, чи допомагає чи шкодить певна відповідь. Власний дизайн Anthropic розміщує основи даних, джерела істини, навички та процедури перевірки ще до того, як Claude бачить запит. У цій статті класичні практики інженерії даних наводяться як обов’язкові вимоги, а також наводяться уроки, щоб інші команди могли уникнути помилок.
Ця стаття є матеріалом про Enterprise AI, а не науковою роботою, проте це один із найзрозуміліших описів практичного застосування для пояснення того, що потрібно для надійної агентської аналітики. У ній послідовно розглядаються основні ідеї: чому підхід text-to-SQL є неправильним, звідки береться неоднозначність, що створила компанія Anthropic, що має існувати перед написанням запиту, роль семантичного шару та навичок, чому важливі оцінки та технічне обслуговування, а також з чого може почати команда.
Чому text-to-SQL привертає всю увагу
Генерація запитів — це та частина, яку можна продемонструвати за тридцять секунд. Задайте запит простою англійською мовою, подивіться, як модель створює запит, виконує його щодо бази даних та отримує число чи графік. Це виглядає магічно, особливо для нетехнічних людей, які раніше покладалися на команду з аналітики чи готові панелі керування.
Чітке пояснення та точне число від Claude чи Codex нічого не говорять про те, чи було запитання відповідь правильно. За словами Anthropic, спрямування Claude на певні дані може створити хибне враження точності, і саме в цьому полягає пастка.
Візьмемо ситуацію, коли зацікавлена сторона запитує: «Який був обсяг доходів від активних клієнтів минулого місяця?» Аналітичні нюанси проявляються відразу:
- Що робить клієнта активним?
- Яке визначення клієнта є офіційним?
- Йдеться про валовий чи чистий дохід?
- Яке поле з датами застосовується?
- Які повернення коштів, фільтри проти шахрайства чи виключення продуктів слід застосувати?
Функція перекладу тексту у SQL працює лише після прийняття цих рішень. Тому надійний аналітичний агент потребує всієї інфраструктури, яка керуватиме його розумінням бізнес-процесів.
Це нагадує відому наукову роботу Google про прихований технічний борг у системах машинного навчання, яка показала, що модель — це крихітна коробка всередині набагато більшого механізму практичного застосування машинного навчання.
Малюнок вище — це скріншот з тієї роботи. Та сама схема застосовується до аналітичних агентів, якщо маленьку чорну коробку замінити на інструмент text-to-SQL.
Відповідь Anthropic узгоджується з цим підходом, як видно з речення „Дані — це не програмне забезпечення“. Робота з аналітикою провалюється інакше, ніж функції програмного забезпечення. Зазвичай існує одна правильна відповідь з одного правильного джерела, проте немає детерміністичного способу підтвердити її лише на основі кінцевого результату. Крім того, система може створювати бездоганний SQL-код, повністю не розуміючи його бізнес-значення.
Anthropic також наводить набір прикладів, які протиставляють ці два підходи, як показано у таблиці нижче.
Anthropic класифікує наслідки цих невдач на три категорії:
- Неоднозначність поняття чи елемента. Користувач використовує терміни на кшталт „активні користувачі“, „дохід“ чи „збереження клієнтів“, і агент мусить обрати один із кількох можливих варіантів реалізації. Різниця між ними часто настільки незначна, що неправильна відповідь все одно здається професійною.
- Застарілість даних. Документація, таблиці та бізнес-правила постійно змінюються. Показник, який був коректним три тижні тому, може помилково змінитися після зміни схеми, додавання нового правила виключення чи перебудови панелі керування.
- Невдача у пошуку. Правильна відповідь існує десь у системі, але обсяг даних для пошуку занадто великий. Модель пропускає потрібну таблицю, показник чи документ та з впевненістю спирається на щось схоже, але неправильне.
Сам склад не може вирішити жодної з цих проблем. Він зберігає дані, а не повне розуміння бізнесу, яке розподілене між визначеннями метрик, семантичними моделями, застереженнями, правилами команди, власністю та історією. У прикладі з доходами написати GROUP BY легко. Але визначити, що означає „активний“, складно: це може бути одна покупка протягом тридцяти днів, оплачене користування без шахрайства протягом періоду билінгу чи порогове значення, специфічне для певного домену, яке існує лише на семантичному рівні.
Тож питання про те, чи може Claude писати SQL, майже не є цікавим, адже він, ймовірно, робить це краще, ніж більшість людей. Корисним є питання про те, що саме довелося створити Anthropic навколо Claude, щоб ці проблеми більше не впливали на результати.
Що створив Anthropic
Відповідь — це поєднання перевіреної інженерної практики та додаткових шарів, які роблять можливими дії агентів. Фактично це повна система, де Claude виступає інтерфейсом зверху, а все інше знаходиться під ним. У статті це розділено на чотири частини:
- Основи даних, тобто канонічні набори даних, моделі даних, операції перетворення, тести, перевірки свіжості та метадані.
- Джерела істини, які охоплюють семантичний шар, ланцюжок походження даних, бізнес-контекст та ретельно підібраний довідковий матеріал, що допомагає прив’язати запитання до визначеного значення.
- Навички, що являються процедурами конкретної галузі, які пояснюють моделі, як працювати, а не лише які дані існують.
- Перевірка, що включає офлайн-оцінки, онлайн-перевірки, визначення походження даних та цикли обслуговування.
Вищенаведений скріншот взятий з посту Anthropic. Подивіться, на якому етапі послідовності з’являється SQL: після усіх складних рішень. Коли модель нарешті формулює запит, стек вже звузив значення запитання та визначив, який шлях має бути довіреним.
Ця структура краще пояснює цифру з заголовка, ніж вибір моделі. Швидкий огляд змушує вважати показник 95 відсотків критерієм ефективності моделі, тоді як уважний аналіз показує, що це критерій ефективності системи, адже більша частина посту присвятована інструментам, які використовуються з Claude, а дуже мало — самому Claude.
Що має існувати перед тим, як буде написаний будь-який SQL
Anthropic чітко зазначає, що традиційна інженерія даних все ще застосовується: моделювання розмірностей, перевірки свіжості та повноти даних, канонічні набори даних, готові до використання, чіткі словники даних. Ніщо з цього не зникає лише через те, що інтерфейс став більш діалоговим. Навпаки, ризики зростають, адже споживач тепер — це агент, який діє на основі запитання людини. Аналітик іноді може відчути, що з таблицею щось не так, тоді як агент може значно швидше поширити хибну припущення.
Є певна іронія в тому, що компанія-піонер каже світу, ніби традиційна інженерія даних є необхідною для агентів. Жодна з цих практик не є новою, і будь-яка книга про зберігання даних віком двадцять років дає такі самі поради. Проте їх все одно варто повторити.
Канонічні набори даних
Невеликий набір суворо регульованих логічних моделей, кожна з яких є єдиним джерелом істини, зменшує кількість ймовірних відповідей ще до початку пошуку. Можуть знадобитися різні рівні агрегації, але підсумки завжди мають формуватися на основі цієї невеликої бази. Те саме стосується аналітичних агентів: коли вони можуть отримати доступ лише до кількох надійних наборів даних та знають, як вони відповідають розширеним вимірам, ймовірність вибору неправильного джерела різко знижується.
Метадані як продукт першого класу
Метадані надають агенту опис таблиць, стовпців, рівня деталізації, власників та обмежень. Якщо ніхто не документує модель, значення кожного стовпця, а також ланцюжки зв’язків чи ключі об’єднання, то ШІ заповнює всі прогалини припущеннями.
Зберігання моделей, документації, панелей керування та файлів навичок разом
Колокейшн може означати просто великий монорепозиторій, але Anthropic пропонує більш точне визначення. Майже весь код, пов’язаний із даними — від моделювання та семантичного шару до документації та стандартних визначень панелей керування — знаходиться в одному репозиторії, який захищаються перевірками CI щодо цілісності між різними шарами. Будь-яка зміна в моделюванні, яка може пошкодити панель керування чи зробити недійсним задокументований показник, фіксується системою CI, і виправлення надсилається в межах тієї самої заявки на пул-репрезентатив.
Це спростовує хибну думку про те, що аналітика на основі ШІ робить інженерію даних менш важливою. Чим більше запитань проходить через моделі, тим більш помітною стає якість шару моделювання.
Інші постачальники також це показують. Семантичний шар dbt існує для того, щоб визначення метрик писалися один раз та використовувалися кожним інструментом. Microsoft радить підготовлювати дані Power BI для Copilot за допомогою схем, готових до роботи з ШІ, перевірених відповідей та чітких інструкцій, щоб модель могла відповідати на основі конкретного контексту. Snowflake створює Cortex Analyst на основі семантичних моделей та перевірених запитів, з моніторингом на етапі генерації SQL. Кожен продукт навчає одного й того самого: контекст, підготовлений заздалегідь, є частиною відповіді.
Семантичний шар — це карта агента
Семантичний шар — це архітектурний міст, який перетворює необроблені, складні дані на знайомі бізнес-терміни, показники та взаємозв’язки. Він розташовується між сховищами даних, такими як Snowflake, Databricks чи BigQuery, та інструментами для їх використання, такими як Power BI, Tableau чи AI-агенти. Завдяки йому можна дізнатися, що означає певний стовпець, який тип має інший стовпець, як обчислюється показник, а також як функціонують ієрархії та взаємозв’язки між таблицями.
На зображенні вище показано, де розташований цей шар. Anthropic вважає його настільки ключовим, що їхні агенти за своєю структурою зобов’язані спочатку звертатися до семантичного шару. Основний принцип полягає у тому, що модель починає роботу з уже визначеного значення, а не з безкінечного дослідження сирих таблиць. Anthropic йде ще далі та вважає поганою практикою дозволяти агентам самостійно створювати семантичний шар. Люди залишаються незамінними для підтримки його якості, і це походить з однієї з провідних лабораторій світу.
Індустрія поступово схиляється до однакового підходу. Cortex Analyst від Snowflake використовує семантичну модель для поєднання бізнес-запитів із структурою бази даних. Genie від Databricks залучає експертів у галузі для надання наборів даних, інструкцій, зразків SQL та контексту бізнесу. dbt зберігає логіку метрик у одному місці, щоб інструменти на наступних етапах не перебудовували її заново, а Microsoft переміщує перевірені відповіді та інструкції ШІ до моделі BI. Агенту з науки про дані від Google також була потрібна щось подібне — псевдосемантичний шар під назвою Analyzer — перш ніж його результати стали ефективними.
Без цієї карти агент лише здогадується. З нею модель спрямовує свої зусилля на міркування в межах визначеного світу, а не на створення його з нуля.
Приклади запитів доповнюють цей шар
Anthropic повідомляє, що корпус запитів — тобто історичні SQL-запити з панелей керування, нотаток та попередніх аналізів — може мати позитивний сукупний ефект. Ефективним є не введення цього корпусу у форматі сирої інформації до агента. Натомість корпус перетворюється на структуровані довідкові документи для кожної галузі та повторно використовувані шаблони аналізу, які зберігаються у навичках агента. Історія запитів є сировим матеріалом для обробки, а не джерелом істини, яке агент читає безпосередньо.
Існує також практична наслідок щодо того, хто володіє чим. Оскільки агент аналітики спирається на урегульовані визначення, люди, які їх підтримують — зазвичай інженери аналітики та власники доменів — стають частиною системи контролю якості агента. Суперечлива метрика перестає бути приводом для суперечок щодо панелі керування та стає дефектом у спільному шарі, який виправляється в одному місці та фіксується кожним користувачем, чи то людиною, чи моделлю. Команди, які вже працюють у такий спосіб, вважатимуть перехід на агентів менш болісним, ніж команди, чия логіка метрик розкидана по нотатках та інструментах BI.
Чому навички настільки впливають на точність
Семантичний шар пояснює, що означає світ, але не як у ньому діяти. Він не може сказати, які кроки вживає хороший аналітик, коли зацікавлена сторона ставить неоднозначне запитання, яке має два можливі джерела та відомий крайній випадок у певному регіоні.
У системі аналітики Anthropic навички функціонують як кодовані посібники аналітика, а не як документація. Вони містять процедурні знання:
- порядок перевірки джерел
- момент, коли слід використовувати семантичний шар, та де дозволяється використання альтернативних методів
- які запитання для уточнення потрібно поставити зацікавленій стороні
- обмеження, які діють у цій галузі
- спосіб перевірки результату перед тим, як довіряти йому
- деталі походження інформації, які включаються до кінцевої відповіді
Найкращі результати Anthropic досягають саме завдяки цьому. Згідно з розділом про навички у публікації, Claude без використання навичок ніколи не досягав рівня вище 21 відсотка у їхніх тестах аналітики. З використанням шару навичок точність у сукупності піднялась вище 95 відсотків, а в деяких галузях сягнула приблизно 99 відсотків.
Ця цифра змінює назву системи. Якщо найбільший приріст досягається завдяки процедурному керівництву, а не кращій генерації SQL, тоді це по суті не продукт типу «текст–SQL». Це продукт аналітичного робочого процесу з виконанням запитів усередині нього.
Також корисно пам’ятати, чим не є ця «навичка». Це не подовжений системний запит, і це не набір прикладів запитів, вставлених у текст. Це підтримуваний артефакт із версією, умовою запуску та визначеною процедурою, який завантажується тоді, коли це необхідно. Це дозволяє переглядати його у запиті на зміни, тестувати проти набору для оцінки та легко виводити з ужитку, коли змінюється базова модель даних.
На зображенні нижче показана шаблон «навички», яку використовує Anthropic.
Разом ці артефакти становлять повне визначення, а додаток містить повну версію шаблону.
Оцінки та технічне обслуговування мають таке ж значення, як і запити
Навіть добре налаштований агент аналітики з часом втрачає ефективність. Як тільки з’являються семантичні шари, підібрані приклади та навички, наступною проблемою стає зміна контексту: таблиці змінюються, визначення зміщуються, панелі керування перебудовуються, а навички більше не відповідають початковій моделі. Процедура, яка була правильною вчора, завтра перетворюється на застарілий контекст.
Anthropic наводить яскравий приклад: точність роботи в офлайн-режимі знизилась з приблизно 95 відсотків до 65 відсотків протягом одного місяця, перш ніж підтримка навичок почала розглядатися як інженерна проблема. Ця цифра робить підтримку навичок обов’язковою вимогою до надійності, а не просто додатковою деталлю.
У аналітиці є зручна особливість — оцінки можуть ґрунтуватися на точних числових даних, які має відтворювати будь-яка правильна процедура. Як тільки це визначено, усі інші параметри системи можна налаштовувати відповідно до них. Команда може протестувати другу версію певної навички за допомогою Haiku, Sonnet чи Opus на кількох рівнях складності, порівняти точність та обрати варіант, який найкраще збалансує витрати та якість — чи то достатня точність за нижчою ціною, чи то максимальна точність за будь-яку ціну.
Зріла система аналітики тестується певним чином: зберігаються приклади використання, є чіткі твердження, а також механізм зворотного зв’язку, який переписує інструкції щоразу, коли система робить помилку. Databricks має схожу концепцію у своїй документації Genie, де до продукту включені перевірка відповідей, бази даних для порівнянь, надійні ресурси та ретельно підібрані інструкції.
Тут запити мають менше значення, ніж зазвичай вважають. Якість все ще важлива, але за наявності слабкого семантичного шару, застарілих прикладів, змінюваних навичок та відсутності оцінок жоден „героїчний“ запит не зможе довго врятувати систему. Аналітика агентів ефективна тоді, коли навколишня система функціонує як підтримуваний продукт, а не тоді, коли модель має прямий доступ та залишається наодинці з необхідністю імпровізувати.
З чого може початися команда з обробки даних
Найкраще починати з найпростішої структури, яка може працювати, поступово додаючи складність лише там, де результати покажуть її ефективність. Керівництво Anthropic щодо створення ефективних агентів висуває таку саму ідею, як і його наступна стаття про аналітику. Ось п’ять кроків:
- Виберіть одну галузь, а не всю систему — наприклад, якість доходів, операції підтримки клієнтів, канали зростання чи фінансову звітність. Оберіть сферу з чітким власником та постійними запитаннями.
Однією з речей, яких слід уникати, є підключення передової моделі безпосередньо до сховища даних та називання цього стратегією. Такий підхід майже нічого не навчає, окрім того, наскільки переконливо може звучати неправильна відповідь.
Text-to-SQL займає певне місце в ієрархії методів виконання як один з корисних підходів. Проблема полягає у тому, що це занадто обмежене поняття для опису всієї системи. Ця тема, ймовірно, призведе до розділення команд на дві групи: тих, хто сприймає text-to-SQL як окремий продукт, та тих, хто бачить у ньому лише окремий шар у межах більш загального процесу аналітики. Варто поставити такі запитання: звідки виникають найбільші проблеми (неоднозначність, отримання даних, застарілість чи слабкі процеси), чи вже існують основи, необхідні аналітичному агенту, чи проект виявить приховані проблеми з моделлю даних, та яким є сьогодні рівень навичок — чи це підказки, посібники з виконання завдань, приклади SQL-запитів чи чек-листи для аналітиків.
Додаток: повний шаблон навичок
Повний шаблон навичок від Anthropic наведено нижче.
---
name: [warehouse-skill]
version: [x.y.z]
description: "IF the user asks to query [the company]'s data warehouse for any
[list of business domains] question — THEN invoke this skill. DO NOT invoke
for [adjacent engineering tasks] or questions with no data-warehouse component."
---
# [Warehouse] Skill Instructions
## Description
The single source of truth for safe and effective [warehouse] querying.
Referenced by other skills [listed] for query execution guidance.
Act as a Data Analyst, providing strategic insights and data-driven
recommendations but seek guidance along the way.
**Out-of-scope decisions**: [product areas, etc.] → surface data only,
state "decision is [owning team]'s call", do NOT take a position or author
code fixes.
## Executing queries
Priority:
1. **[Managed connection]** (if available): [query tool] / [schema tool]
2. **[CLI fallback]** (if installed): [default project, fallback project]
3. **Neither** — ask the user to authenticate, then stop
---
# Semantic Layer (REQUIRED first step)
The governed semantic layer is the **mandatory default path** for every data
question — same numbers as [the BI tool], joins/grain/filters baked in. Raw SQL
via the reference docs below is the **fallback**, used only after the
semantic-layer path is shown not to cover the ask.
## Required workflow
1. **Load** — [how to load the semantic layer in each runtime, with fallbacks]
2. **Discover** — search measures/dimensions by keyword; **always check
segments** (the named canonical population filters — hand-rolled WHERE
clauses for these are the dominant wrong-answer mode)
3. **Compile + run** — build the spec → compile to SQL → execute
4. **Fallback** — only if discovery finds no relevant metric or compile fails
→ raw SQL via `references/*.md` (PART 3 below)
> **Don't bail early.** Do NOT fall back to raw SQL on these grounds:
> - "[custom date filtering / cohorts]" → [covered by time-dimension specs]
> - "[needs a join]" → [the metric layer already encapsulates its joins]
> - [3–4 more pre-rebutted excuses agents use to skip the semantic layer]
### Date windows & timezone — decide before you query
- **As-of date vs trailing-N days**: [convention for each]
- **"Last week/month"** → the last *complete* calendar week/month, not trailing-7/30
- **Timezone default**: [TZ]; [exception for certain reporting rollups]
- **Freshness lag**: [some] tables settle late — anchor on MAX(date), not "yesterday"
---
# PART 1: MUST KNOW (Read First for Every Request)
## 🚀 Quick Start Workflow
1. **Check for red flags first**: [restricted/PII requests, gated domains,
high-stakes asks that need extra validation]
2. **Out of scope — escalate, don't guess**: [access requests, pipeline
troubleshooting, stale dashboards, root-cause assertions, product/pricing
recommendations] → redirect to [the owning team], don't answer
3. **Clarify the request**: time period, segment, the business decision it informs
4. **Check for existing dashboards**: [per-domain dashboard catalogs]
5. **Identify the data source**: [navigation map below; prefer governed/aggregated tables]
6. **Execute the analysis**: [required filters + adversarial review]
7. **Deliver insights**: show methodology, differentiate observations from interpretations
## 🏢 Business Context
### Entity Disambiguation (MUST CLARIFY)
- **"[Term A]" can mean**: [entity 1] or [entity 2] — always clarify which
- **"[Term B]" can mean**: [entity 1] → [entity 2] → [entity 3] (one-to-many chain)
- **"Users"**: [which identifier gives accurate counts, and which ones inflate them]
### Business Terminology
- [Current product names vs deprecated aliases that still appear as frozen
values in the data layer — write with the new names, filter with the old]
- [Key internal acronyms]
- **[Headline metric] calculations**: [monthly / default window / leading indicator]
- **Unfamiliar terms — search [internal docs], don't guess**
### Data Integrity Requirements ⚠️
- **NEVER**: make up data/columns; make speculative assertions beyond what data shows
- **ALWAYS**: use safe division; differentiate observations ("data shows X")
from interpretations ("this suggests Y"); flag limitations
---
# PART 2: HOW TO DO (Follow During Execution)
## 🔧 Technical Execution Guide
- [Managed-connection tools and CLI invocation details]
- **PII protection**: for restricted data, return the SQL for the user to run
themselves — do not return results
## 📊 Analysis Best Practices Guide
1. Clarify the ask before querying
2. Show your work (filters, inclusions/exclusions, freshness)
3. Clarify denominators
4. Consider sample bias
5. Connect to business impact
6. **Adversarial SQL review (MANDATORY)** — spawn the [sql-reviewer] sub-agent
for every query before the final answer; blocking findings must be fixed
and re-reviewed; do not self-certify
7. **Report with provenance** — every answer ends with a footer:
> **Source:** [semantic layer | governed table | raw exploration] ·
> **Confidence:** [tier] · **Reviewed:** [reviewer ✓, round N] ·
> **Freshness:** [max date in the data] · **Owner:** [owning team]
---
# PART 3: DATA REFERENCES & RESOURCES
## 📚 Knowledge Base Navigation
### [Domain A] → `references/[domain_a].md`
- **Use for**: [kinds of questions]
- **Key tables**: [...]
- **Dashboards**: `references/[domain_a]_dashboards.json`
### [Domain B] → `references/[domain_b].md`
- **Use for**: [...]
[... one entry per business domain — a few dozen in total ...]
## ⚠️ Troubleshooting Guide
### When Information Is Missing
- [missing tables / access denied / outdated docs / unknown enum values → what to do]
### Field Naming Gotchas
- Use `[field_x_v2]` NOT `[field_x]`
- [Two similarly-named tables report the same metric at different grains — which to use]
- [Which of two plausible sources is canonical for the headline metric]
- [… a dozen more hard-won one-liners …]