Агентный анализ — это нечто большее, чем текст-в-SQL: уроки от Anthropic

Аналитический мусор — это новый вид мусора от ИИ

Пост компании Anthropic от 3 июня 2026 года о самообслуживающихся аналитических системах открыто говорит о том, что многие команды по обработке данных узнали на собственном опыте: агентные аналитические системы не являются тем же, что и простое направление запросов в базу данных с помощью Claude Code.

Большинство людей знают термин «мусор от ИИ». Аналитический мусор — это его аналог. Благодаря кодирующим агентам теперь любой может подключиться к базе данных и генерировать аналитические отчеты. Это отлично снижает барьеры входа, но с другой стороны почти никто не проверяет полученные цифры. Панели управления поступают в виде файлов .html, страниц Confluence или скриншотов терминала, причем лишь немногие из них были проверены. Причина в ложном чувстве безопасности: поскольку большие языковые модели так хорошо переводят английский на SQL, считается, что ответы обязательно должны быть верными.

Эта уверенность ошибочна. Когда аналитика ограничивается лишь генерацией запросов, проблема рассматривается слишком узко, а вспомогательная инфраструктура остается незамеченной, хотя именно она определяет, поможет ли полученный ответ или навредит. Собственная архитектура Anthropic размещает основы обработки данных, источники достоверной информации, необходимые навыки и механизмы проверки ещё до того, как Claude увидит запрос. В статье перечислены классические практики инженерии данных как обязательные требования, а также приводятся уроки, которые помогут другим командам избежать ошибок.

Эта статья представляет собой материал из раздела Enterprise AI, а не научную работу, но это один из самых ясных описаний практического применения для понимания того, что необходимо для надежного агентского анализа. В статье по порядку рассматриваются основные идеи: почему подход text-to-SQL неверен, откуда берется неоднозначность, что было создано компанией Anthropic, что должно существовать до написания запроса, роль семантического слоя и навыков, почему важны оценка и техническое обслуживание, а также с чего может начать команда.

Почему text-to-SQL привлекает столько внимания

Генерация запросов — это та часть, которую можно продемонстрировать за тридцать секунд. Задайте вопрос на простом английском, посмотрите, как модель формирует запрос, запустит его в хранилище данных и получите число или график. Это выглядит волшебно, особенно для неспециалистов, которые раньше полагались на команду аналитиков или готовые дашборды.

Плавное объяснение и четкое число от Claude или Codex ничего не говорят о том, был ли вопрос ответлен правильно. По словам Anthropic, направление запроса к Claude на определенный объект может создать ложное впечатление точности, и в этом-то и кроется ловушка.

Возьмем ситуацию, когда заинтересованная сторона спрашивает: «Каковы были доходы от активных клиентов в прошлом месяце?» Аналитические нюансы проявляются сразу:

• Что делает клиента активным?
• Какое определение клиента считается официальным?
• Речь идет о валовом или чистом доходе?
• Какое поле с датой применяется?
• Какие возвраты, фильтры против мошенничества или исключения продуктов следует учитывать?

Генерация SQL-запроса из текста возможна только после принятия этих решений. Поэтому надежному аналитическому агенту требуется целая инфраструктура, которая направляет его понимание бизнес-процессов.

Это отражает известную статью Google о скрытом техническом долге в системах машинного обучения, в которой показано, что модель представляет собой крошечную «коробку» внутри гораздо более крупной структуры производственных систем машинного обучения.

На рисунке выше представлен скриншот из этой статьи. Та же схема применима к аналитическим агентам, если маленькую черную коробку заменить на инструмент текст-в-SQL.

Ответы компании Anthropic соответствуют этой концепции, как видно из фразы «Данные — это не программное обеспечение». Работа с аналитикой отличается от разработки программных функций: обычно существует один правильный ответ из одного правильного источника, но нет определенного способа подтвердить его только на основе итогового результата. Кроме того, система может генерировать безупречный SQL, полностью упуская бизнес-смысл.

Anthropic также приводит набор примеров, показывающих различия между этими двумя подходами, которые представлены в таблице ниже.

Anthropic классифицирует возникающие сбои на три категории:

1. Неоднозначность понятий или сущностей. Пользователь говорит «активные пользователи», «доход» или «удержание клиентов», и агент должен выбрать один из нескольких возможных вариантов толкования. Различия между ними часто настолько тонки, что неверный ответ всё равно выглядит профессионально.
2. Устаревание данных. Документация, таблицы и бизнес-правила постоянно меняются. Показатель, который был корректен три недели назад, может ошибочно измениться после смены структуры данных, появления нового правила исключения или перестройки панели управления.
3. Неудача при поиске. В каком-то месте системы существует правильный ответ, но объём данных для поиска слишком велик. Модель упускает нужную таблицу, показатель или документ и с уверенностью опирается на что-то похожее, но неверное.

Сам склад не может решить ни одну из этих проблем. Он хранит данные, а не полное понимание бизнеса, которое распределено между определениями метрик, семантическими моделями, оговорками, правилами команды, ответственными лицами и историей. В примере с доходами написать GROUP BY легко. Однако определить, что означает «активный», сложно: это может быть одна покупка в течение тридцати дней, оплаченное использование без мошенничества в течение периода выставления счета или пороговое значение, характерное только для конкретной области и находящееся в семантическом слое.

Поэтому вопрос о том, может ли Claude писать SQL, вряд ли является интересным, поскольку, вероятно, он делает это лучше, чем большинство людей. Полезный вопрос заключается в том, что пришлось создать компании Anthropic вокруг Claude, чтобы эти проблемы больше не доминировали в результатах работы.

Что создала Anthropic

Ответ заключается в сочетании проверенных инженерных практик и дополнительных компонентов, которые делают возможным использование агентов. По сути это полная система, в которой Claude выступает интерфейсом сверху, а все остальное находится внутри. В статье это деление представлено в четырех частях:

1. Основы данных, то есть канонические наборы данных, модели данных, преобразования, тесты, проверки свежести и метаданные.
2. Источники истины, включающие семантический слой, информацию о происхождении данных, бизнес-контекст и тщательно отобранные справочные материалы, помогающие связать вопрос с определенным значением.
3. Навыки, представляющие собой процедуры конкретной области, которые указывают модели, как действовать, а не просто сообщают о наличии данных.
4. Проверка качества, включая офлайн-оценки, онлайн-проверки, информацию о происхождении данных и циклы технического обслуживания.

Приведённый выше скриншот взят из поста Anthropic. Обратите внимание на место, где появляется SQL: после всех сложных решений. К тому моменту, когда модель наконец формирует запрос, стек уже сузил возможные значения вопроса и определил, какой путь обработки заслуживает доверия.

Такая структура лучше объясняет цифру из заголовка, чем выбор модели. Беглый просмотр заставляет 95-процентный показатель казаться показателем производительности модели, тогда как внимательный анализ показывает, что это показатель производительности всей системы, учитывая, насколько подробно в посте описан механизм, связывающий Claude с другими компонентами, и насколько мало говорится о самом Claude.

Что должно существовать до того, как будет написан любой SQL-запрос

Компания Anthropic ясно указывает, что традиционные методы инженерии данных по-прежнему актуальны: моделирование размерностей, проверка свежести и полноты данных, канонические наборы данных, готовые к использованию, четкие словари данных. Ничего из этого не исчезает только потому, что интерфейс стал более диалоговым. Более того, значимость этих методов растет, поскольку пользователь теперь — агент, действующий на основе вопроса человека. Аналитик иногда может заметить, что с таблицей что-то не так, тогда как агент может гораздо быстрее привести к серьезным последствиям неверное предположение.

Есть некоторая ирония в том, что компания-пионер заявляет миру, что традиционная инженерия данных необходима для агентов. Ни одна из этих практик не является новой — любая книга по хранилищам данных, вышедшая двадцать лет назад, дает такие же рекомендации. Тем не менее их стоит еще раз повторить.

Канонические наборы данных

Небольшой набор строго регулируемых логических моделей, каждая из которых является единственным источником правды, сокращает количество вероятных ответов ещё до начала поиска. Могут потребоваться разные уровни агрегации, но все обобщения должны основываться на этой небольшой базе. То же самое касается аналитических агентов: когда они могут обращаться только к нескольким надёжным наборам данных и знают, как они соотносятся с дополненными измерениями, вероятность выбора неверного источника резко снижается.

Метаданные как продукт первого класса

Метаданные предоставляют агенту рабочее описание таблиц, столбцов, уровня детализации, владельцев и ограничений. Если никто не документирует модель, значение каждого столбца, а также связи или ключи объединения, большие языки модели заполняют все пробелы предположениями.

Сохранение моделей, документации, панелей управления и файлов с навыками вместе

Колокацию можно просто рассматривать как большой монорепозиторий, но Anthropic предлагает более точное определение. Почти весь код, связанный с данными — от моделирования и семантического слоя до документации и стандартных определений панелей управления — находится в одном репозитории, защищаемом проверками CI на целостность между слоями. Любые изменения в моделировании, которые могут нарушить работу панели управления или сделать недействительными задокументированные показатели, фиксируются системой CI, и исправления вносятся в рамках того же pull request.

Это опровергает распространённое мнение о том, что аналитика на основе ИИ снижает значимость инженерии данных. Чем больше вопросов обрабатывается с помощью моделей, тем заметнее становится качество слоя моделирования.

Другие поставщики также показывают это. Существование семантического слоя dbt позволяет записывать определения метрик один раз, после чего они используются всеми инструментами. Microsoft рекомендует подготавливать данные Power BI для Copilot с схемами, готовыми к использованию ИИ, проверенными ответами и четкими инструкциями, чтобы модель могла отвечать на основе достоверного контекста. Snowflake создает Cortex Analyst на основе семантических моделей и проверенных запросов, обеспечивая мониторинг на этапе генерации SQL. Каждый продукт учит одного и того же: заранее подготовленный контекст является частью ответа.

Семантический слой — это карта агента

Семантический слой представляет собой архитектурный мост, преобразующий необработанные, сложные данные в знакомые бизнес-термины, показатели и связи. Он располагается между средствами хранения данных, такими как Snowflake, Databricks или BigQuery, и инструментами для их анализа, такими как Power BI, Tableau или ИИ-агенты. Благодаря наличию такого слоя можно понять, что означает та или иная колонка, какой тип имеет другая колонка, как рассчитывается показатель, а также как функционируют иерархии и связи между таблицами.

На приведённой выше диаграмме показано, где находится этот слой. Anthropic считает его настолько центральным, что их агенты по структуре обязаны сначала обращаться к семантическому слою. Основной принцип заключается в том, что модель исходит из управляемого смысла, а не из неограниченного анализа сырых данных. Anthropic заходит ещё дальше и считает плохой практикой позволять агентам самостоятельно создавать семантический слой. Люди по-прежнему играют ключевую роль в поддержании его качества, и это происходит в одной из ведущих лабораторий мира.

Индустрия постепенно приходит к единому мнению. Инструмент Cortex Analyst от Snowflake использует семантическую модель для связи бизнес-вопросов со структурой базы данных. В Genie от Databricks эксперты определенной области предоставляют наборы данных, инструкции, примеры SQL-запросов и контекст бизнеса. Инструмент dbt объединяет логику расчетов в одном месте, чтобы последующие инструменты не пересоздавали ее заново, а Microsoft помещает проверенные ответы и инструкции ИИ в модель BI. У агента по науке о данных от Google также требовался подобный инструмент — псевдосемантический слой под названием Analyzer — прежде чем его результаты стали эффективными.

Без такой карты агент делает угадывания. С ней модель тратит усилия на логические рассуждения в рамках заданных ограничений, вместо того чтобы создавать их с нуля.

Примеры запросов пополняют этот слой

Компания Anthropic сообщает, что корпус запросов, то есть исторические SQL-запросы из панелей управления, ноутбуков и предыдущих анализов, может оказать положительное воздействие. Работает не метод прямой передачи этого корпуса агенту в необработанном виде. Вместо этого корпус обрабатывается с целью создания структурированных справочных документов по отдельным областям и повторно используемых шаблонов анализа, закодированных в навыках агента. История запросов является сырьем для отбора информации, а не источником истины, который агент читает напрямую.

Существует также практическое последствие для того, кто владеет чем. Поскольку агент аналитики опирается на управляемые определения, люди, которые их поддерживают — обычно инженеры аналитики и владельцы доменов — становятся частью системы контроля качества агента. Спорный показатель перестает быть предметом разногласий на панели управления и превращается в дефект в общем слое, который исправляется в одном месте и замечается всеми потребителями — людьми или моделями. Команды, уже работающие таким образом, найдут переход на агентов менее болезненным, чем команды, у которых логика показателей разбросана по ноутбукам и инструментам BI.

Почему навыки так сильно влияют на точность

Семантический слой объясняет, что означает мир, но не указывает, как в нем действовать. Он не может сказать, какие шаги предпримет хороший аналитик, когда заинтересованная сторона задаст неоднозначный вопрос с двумя возможными источниками данных и известным крайним случаем в определенном регионе.

В системе аналитики Anthropic навыки функционируют как закодированные руководства для аналитиков, а не как документация. Они содержат процедурные знания:

• порядок проверки источников
• то место, где следует использовать семантический слой, и где допускается использование альтернативных методов
• какие уточняющие вопросы следует задать заинтересованным сторонам
• ограничения, действующие в данной области
• способ проверки результата перед тем, как ему доверять
• детали происхождения информации, включаемые в окончательный ответ

Самый сильный результат Anthropic достигается именно благодаря этому. Согласно разделу, посвященному навыкам, в тестах аналитики Claude без использования навыков никогда не достигал уровня выше 21 процента. Благодаря использованию навыков точность в среднем превысила 95 процентов, а в некоторых областях достигла примерно 99 процентов.

Эта цифра влияет на название системы. Если наибольший прирост достигается за счёт процедурного руководства, а не улучшения генерации SQL, то это по сути не продукт типа «текст в SQL». Это продукт для аналитических рабочих процессов с возможностью выполнения запросов.

Также полезно помнить, чем не является такой инструмент. Это не более длинное системное указание, и это не набор примеров запросов, вставленных в систему. Это поддерживаемый объект с версией, условием активации и определённой процедурой, загружаемый тогда, когда это необходимо. Благодаря этому его можно рассмотреть в рамках pull request, протестировать на наборе для оценки, а также легко устареть, когда изменяется основная модель данных.

На изображении ниже показан шаблон инструмента, который использует Anthropic.

Все эти элементы вместе составляют полное определение, а в приложении приводится весь шаблон.

Оценки и техническое обслуживание имеют такое же значение, как и указания

Даже хорошо настроенный агент для анализа со временем теряет эффективность. Как только появляются семантические слои, тщательно отобранные примеры и навыки, следующей проблемой становится дрейф: меняются таблицы, смещаются определения, перестраиваются панели управления, и навыки больше не соответствуют исходной модели. Процедура, которая вчера была правильной, уже завтра превращается в устаревший контекст.

Компания Anthropic приводит яркий пример: точность работы в офлайн-режиме снизилась примерно с 95 процентов до 65 процентов всего за один месяц, прежде чем обслуживание навыков начали рассматривать как инженерную проблему. Эта цифра делает обслуживание неотъемлемым требованием к надежности, а не просто желательной мерой.

В аналитике имеется удобная особенность: оценки могут основываться на истинных значениях, которые должна воспроизводить любая корректная процедура. Как только они определены, все остальные параметры системы можно настроить с учётом этих значений. Команда может протестировать вторую версию навыка с использованием Haiku, Sonnet или Opus на нескольких уровнях сложности, сравнить точность и выбрать вариант, который наилучшим образом сбалансирует затраты и качество — будь то достаточная точность при более низких затратах или максимальная точность любой ценой.

Зрелая система аналитики тестируется определённым способом: с использованием сохранённых примеров, явных утверждений и цикла обратной связи, который переписывает инструкции каждый раз, когда система допускает ошибку. Databricks предлагает похожую концепцию в своей документации Genie, где в продукт включены проверка ответов, эталоны качества, надёжные ресурсы и тщательно отобранные инструкции.

Здесь важность промптов меньше, чем обычно считают. Качество по-прежнему имеет значение, но при слабом семантическом уровне, устаревших примерах, снижающихся навыках и отсутствии оценок ни один «героический» промпт не сможет долго спасти систему. Аналитика агентов эффективна тогда, когда вся система управляется как сопровождаемый продукт, а не когда модель получает прямой доступ и оставляется самостоятельно придумывать решения.

С чего может начать команда по обработке данных

Лучшее место для начала — это самая простая структура, которая может сработать; сложность добавляется постепенно только там, где результаты показывают её целесообразность. Рекомендации Anthropic по созданию эффективных агентов выражают ту же мысль, и последующая статья об аналитике подтверждает её. Вот пять шагов:

1. Выберите одну область, а не весь спектр задач, например качество доходов, операции поддержки, каналы роста или финансовую отчетность. Выберите сферу с четким ответственным и постоянно возникающими вопросами.

Создать единый управляемый источник истины. Запросы могут ожидать, пока в данной области не будут сформированы канонические наборы данных, определены формулы для измерения показателей, назначен ответственный и внедрена базовая система мониторинга актуальности данных.

Сначала разработать семантический уровень, а сырые SQL-запросы оставить в качестве запасного варианта. Когда вопрос может быть четко отнесен к уже сформированной семантике, агент не должен использовать сырые таблицы для обработки запроса.

Составить один простой набор инструкций или шаблона, описывающий, как эффективный аналитик работает в данной области: уточнение вопроса, выбор источников данных, проверка информации, составление отчета и указание источников цифр.

Перед расширением использования собрать небольшой набор тестовых задач. Двадцать–тридцать реальных вопросов с ожидаемыми ответами и известными крайними случаями дают больше знаний, чем сотня внутренних демонстраций.

Следует избегать прямой связи передовой модели с хранилищем данных и называния этого подхода стратегией. Такой способ почти ничего не учит, кроме того, насколько убедительно может звучать неверный ответ.

Технология 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 …]