Разработка AI Data Analyst — цифровой аналитик данных Text-to-SQL

Почему AI Data Analyst ошибается в цифрах и ломает доверие

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

Второй тип — пустая выборка. Ошибки генерации запросов в условиях отбора (несовпадение типа даты, лишний фильтр по статусу, регистр в строковом сравнении) дают ноль строк, а интерфейс показывает аккуратный нуль или пустой график. Отличить «данных нет» от «данные не нашлись» по ответу невозможно, и именно здесь доверие к цифрам ломается тише всего.

Скрытые дубли появляются на соединениях: если к сделкам подтянуть строки оплат или контактов, каждая сделка размножается, и выручка растёт без единого изменения в источнике. Рядом — потерянное сопоставление справочников: «ООО Ромашка» и «Ромашка ООО» остаются разными клиентами, часть категорий выпадает из среза, а итоги по группам перестают сходиться между собой.

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

Эффект внедрения: сроки ответов и достоверность цифр

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

Что мы фиксируем на приёмке. Время от вопроса до готовой цифры по типовым показателям падает с часов до секунд, а повторный запрос уже не требует участия инженера. Доля вопросов, закрытых без аналитика, обычно выходит на 60–80%: остальное — тяжёлые расчёты, новые источники и спорные определения метрик, которые осознанно остаются за командой данных. Ручные выгрузки по регулярным срезам уходят в самообслуживание, и нагрузка на аналитиков смещается с «достать цифру» на «описать и уточнить метрику».

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

Варианты реализации и их технические ограничения

Выбор схемы определяется не моделью, а тем, где лежат данные и кому их видно. Цифровой аналитик переводит вопрос на язык запросов, и от способа развёртывания зависит, куда этот запрос уйдёт. Одно дело — отвечать по открытому набору метрик, другое — обращаться к рабочему хранилищу с персональными данными.

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

Порядок работ: от аудита источников до передачи

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

1. Аудит данных. Инвентаризируем источники, собираем профиль таблиц: доля пустых значений, дубликаты записей, расхождения в справочниках, часовые пояса в датах. На выходе — перечень полей, пригодных для аналитики, и отдельный список того, что требует чистки на стороне владельца системы.
2. Проектирование решения. Фиксируем сущности и связи, строим семантический слой: метрики, измерения, синонимы бизнес-терминов. Отдельно согласуем спорные показатели — как считать выручку с возвратами, что такое активный клиент, за какой период берём сравнение.
3. Настройка прав доступа. Разграничиваем роли и видимость строк, включаем журналирование каждого запроса: кто спросил, что получил. Руководитель филиала видит свои данные и не видит чужие — без ручных выгрузок и переписок.
4. Сборка и настройка. Подключаем источники, переводим вопросы на естественном языке в запросы к базе, добиваемся устойчивости к разным формулировкам одного и того же вопроса. Частые обращения кэшируем, тяжёлые считаем по расписанию.
5. Приёмка на контрольных вопросах. Готовим набор из нескольких десятков реальных вопросов с эталонными ответами и сверяем результат построчно. Если расхождение — смотрим, в семантике ошибка или в данных, и правим до подписания.
6. Передача и обучение. Отдаём документацию по семантическому слою, инструкции для пользователей, разбор типовых ошибок и регламент: что делаем при изменении структуры источника. Обучаем рабочую группу и сопровождаем первые недели самостоятельной работы.

Что остаётся у вас: конфигурации, схемы, регламенты

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

• Описание модели данных — подключённые источники, используемые таблицы и связи, места, где поля трактуются неоднозначно, и принятые по ним решения.
• Словарь показателей — каждое бизнес-понятие привязано к формуле, источнику и фильтрам; расхождение в трактовке между отделами видно на этапе настройки, а не в готовом отчёте.
• Политики доступа — роли, разграничение на уровне строк и колонок, маскирование персональных данных, журнал обращений: видно, кто и какой вопрос задавал.
• Передача конфигурации — файлы подключений, параметры обработки запросов, расписание обновления словаря, версионирование настроек в вашем репозитории.
• Схема развёртывания — где работает сервис, как связан с хранилищем, какие точки отказа и как выполняется откат на предыдущую версию.
• Набор проверочных вопросов — эталонные пары «вопрос → верный ответ», по которым проверяется корректность после любой правки модели.
• Инструкции для пользователей — как формулировать вопрос, какие уточнения система запросит, что делать, если ответ выглядит сомнительным.
• Регламент обновления — кто правит словарь при изменении схемы источника, как изменения тестируются и кто подтверждает выпуск.

Кейс: как подняли долю верных ответов с 62% до 94%

Разбираем проект в розничной сети: данные лежали в ClickHouse и нескольких реляционных базах, а вопросы к ним шли через очередь из четырёх аналитиков. Ответ на типовой вопрос «сколько отгрузили в регионе за квартал» занимал до трёх дней — уточнение постановки, поиск витрины, написание запроса, сверка цифры с владельцем данных. На сотню запросов в месяц около двадцати возвращалось на доработку.

Точкой отсчёта стал золотой набор: около 600 вопросов к базе с эталонными запросами и разметкой по витринам. На нём система давала 62% верных ответов, а остальное делили неверные соединения таблиц, потерянные фильтры по периоду и подмена метрики близкой по названию. Время подготовки цифры — от формулировки вопроса до подтверждённого числа — считали отдельной метрикой.

Что изменили

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

Что стало

Доля верных ответов выросла с 62% до 94% на том же наборе; остаток — вопросы вне домена, их система честно отклоняет. Среднее время подготовки цифры сократилось с двух-трёх дней до нескольких минут вместе с проверкой источника. Ручные выгрузки упали с сорока с лишним до единиц в месяц, а класс ошибок сопоставления данных ушёл: ключи клиентов и возвраты нормализуются до построения запроса, поэтому двойной учёт и неверное соединение по неканоническому ключу больше не воспроизводятся.

Чем AI-аналитик отличается от регулярной отчётности?

Регулярная отчётность отвечает на вопрос, сформулированный заранее: метрики описаны, формулы согласованы, расчёт идёт по расписанию и даёт одно и то же число на один и тот же период. Её сила — в повторяемости: расхождение между отчётами видно сразу, а результат не зависит от того, кто смотрит: и отчёт, и фильтры, и порядок срезов заданы заранее.

Цифровой аналитик работает иначе — собирает запрос к данным под конкретный разовый вопрос: как вели себя заказы сегмента после смены тарифа, сколько клиентов вернулось за две недели. Такого отчёта никто не проектировал, но ответ строится не на пустом месте, а на семантическом слое: описаниях таблиц, связях, словаре метрик и правилах фильтрации.

Разница не в источнике данных — оба подхода читают одни и те же витрины. Разница в моменте, когда вопрос становится точным: в отчётности — при проектировании, у аналитика — в момент запроса. Отсюда стабильность в одном случае и скорость на нестандартных срезах в другом.

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

Ориентир простой: цифровой аналитик надёжен там, где данные описаны в словаре метрик. За пределами описанных сущностей он не догадывается, а сообщает, чего не хватает, — такой вопрос уходит инженеру.

Сомнения по качеству данных, доступам и нагрузке

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

У сотрудников разные права, не все видят нужные таблицы

Аналитик работает под учётной записью пользователя, а не под служебной. Данные, к которым у человека нет доступа, физически не попадут в ответ, даже если он сформулирует вопрос иначе. Права разводим по ролям и колонкам на стороне хранилища — одна точка настройки вместо копий.

Не вырастет ли нагрузка на хранилище

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

Схема изменится после внедрения — всё сломается

Изменения схемы неизбежны. Слой описаний живёт отдельно от хранилища: переименование колонки или новая таблица правятся в нём, а не в коде. Держим набор эталонных вопросов и ответов — после каждой миграции прогоняем его и до пользователей видим, что перестало отвечать корректно.

Обсудим задачу: что подготовить к разговору

Чтобы оценка была предметной, а не «плюс-минус порядок», нам достаточно нескольких вводных. Они же становятся основой критериев приёмки: по ним потом проверяем, что цифровой аналитик отвечает на реальные вопросы сотрудников, а не на демонстрационные.

• Постановка задачи — какие решения принимают по данным и что мешает сейчас: долгие выгрузки, очередь к аналитику, отчёты, собранные вручную.
• Перечень источников — базы, хранилища, таблицы и представления, словарь метрик; что считается «истиной», если цифры в отчётах расходятся.
• Образцы вопросов — 20–50 формулировок так, как их реально задают сотрудники, с ожидаемыми ответами хотя бы для части.
• Правила доступа — под какой учётной записью работает аналитик, какие таблицы и колонки ему закрыты, как маскируются персональные данные.
• Границы допустимого — только чтение, лимит строк в ответе, поведение при неоднозначном запросе: уточнить у пользователя или отказать.
• Критерии приёмки — доля вопросов из набора, на которые ответ верен, как сверяем числовое совпадение и что считаем ошибкой.
• Эксплуатация — где разворачиваем, кто владелец, как обновляются описания таблиц при изменении схемы.

Пришлите то, что уже есть: перечень источников и десяток живых вопросов. Вернёмся с оценкой, планом этапов и набором проверок под ваши данные.