Учёные предложили архитектуру ИИ-аналитики, которая отвечает раньше вопроса

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

Предложенное решение строится на двух связанных архитектурных идеях. Первая, подключаемый модуль «навыка предметной экспертизы» (domain-expert skill): самодостаточная папка без собственной базы данных, в которую входят манифест, текстовые вставки-«фасеты» под разные этапы конвейера, привязанные к ключевым словам справочные материалы, шаблоны отчётов и, опционально, вычислительный код. Нужный навык подбирается автоматически под пару «клиент + набор данных» через детерминированное сопоставление со схемой данных и встраивается сквозным элементом во все этапы агентного конвейера, от исследования схемы до движков формирования отчётов; если подходящего навыка нет, модуль просто ничего не делает (строгий no-op). Поскольку каждый навык, это независимая папка, которую система выбирает детерминированно, каталог навыков открыт для расширения: авторы называют это «расширяемым маркетплейсом отраслевых экспертов».

Вторая идея, офлайн-контур «компиляции знаний» о данных. Специальный агент обращается напрямую к parquet-файлам набора данных через DuckDB, не создавая нагрузки на боевую (production) систему, и по каждой таблице прогоняет процесс схождения к результату под контролем отдельного агента-критика с механизмом самовосстановления при сбоях; связи между таблицами (join) проверяются сверкой пересечения значений. Итог, устойчивое, накопленное знание о схеме данных, на основе которого система формирует постоянно обновляемые экспертные отчёты: каждая опубликованная в них цифра повторно проверяется путём повторного выполнения SQL-запроса, который эту цифру подтверждает. Тот же контур генерирует предлагаемые пользователю вопросы, повторяющие структуру (повестку) отчётов.

Вместе это замыкает проактивный цикл: отчёт показывает цифры, цифры подсказывают вопросы, а клик по вопросу запускает уже проверенное углублённое исследование, и всё это происходит ещё до того, как пользователь вообще открыл поле для ввода запроса. Авторы приводят формальную модель архитектуры и иллюстративные данные по одному клиенту (single-tenant), но прямо оговаривают: пользовательских исследований или сравнения с эталонными тестами (бенчмарками) в статье нет, заявленный вклад работы это сама архитектура и обоснование её надёжности, а не измеренная эффективность.

Ключевые факты

Проблема: диалоговые аналитические системы требуют от пользователя готового вопроса, а неспециалист перед незнакомой схемой данных видит только пустое поле запроса.
Коммерческие «проактивные» инструменты ограничены поиском аномалий поверх заранее размеченных метрик, а академические рекомендатели вопросов зависят от истории запросов, которой у нового набора данных нет.
Первая идея архитектуры, подключаемый «навык предметной экспертизы»: самодостаточная папка (манифест, подсказки, справочники, шаблоны отчётов, опциональный код), которая подбирается автоматически под пару «клиент + данные» и при отсутствии подходящего навыка просто ничего не делает.
Вторая идея, офлайн-агент, который через DuckDB напрямую читает parquet-файлы без нагрузки на боевую систему, сверяет таблицы под контролем агента-критика и строит отчёты, где каждая цифра перепроверяется повторным SQL-запросом, плюс генерирует подсказанные вопросы.
Авторы прямо указывают: статья даёт архитектуру и формальную модель с иллюстративными данными по одному клиенту, но не содержит ни пользовательских исследований, ни сравнения с эталонными тестами.

Почему это важно

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

Кому это важно

Материал адресован тем, кто строит корпоративные аналитические ИИ-продукты и агентные конвейеры для работы с данными: разработчикам платформ бизнес-аналитики, командам, внедряющим ИИ-агентов поверх корпоративных баз данных, и архитекторам, которые проектируют системы для клиентов без штата дата-аналитиков, то есть для конечных пользователей, которые сами не умеют формулировать SQL-подобные вопросы.

Как это применить

Статья описывает не готовый продукт, а архитектурный паттерн из двух частей, который можно перенимать по отдельности. «Навык предметной экспертизы», это независимая папка с манифестом, текстовыми вставками для разных этапов конвейера, справочниками и шаблонами отчётов, подключаемая автоматически по схеме данных клиента и безопасно отключаемая (no-op), если подходящего навыка нет, авторы описывают её как основу «маркетплейса» отраслевых экспертиз. Офлайн-контур поверх DuckDB и parquet-файлов, с проверкой связей между таблицами и повторным выполнением SQL для подтверждения каждой цифры в отчёте, рецепт того, как получать проверяемые метрики без нагрузки на боевую базу данных.

Можно ли доверять

Источник, сама статья с arXiv, доверия к пересказу достаточно, но у самой работы есть чёткие ограничения, которые авторы не скрывают: это архитектурная статья с формальной моделью и иллюстративными данными по одному клиенту (single-tenant), без пользовательских исследований и без сравнения с эталонными тестами (бенчмарками). Иными словами, заявлена и обоснована конструкция системы, а не измеренный эффект от её внедрения, это стоит учитывать, читая любые выводы о её эффективности.

Риски и подводные камни

В тексте не названы ни авторы и их организация, ни клиент или отрасль, для которых система разворачивалась, ни конкретная модель, лежащая в основе агентного конвейера, ни дата публикации, это затрудняет независимую проверку заявлений. Заявленная «детерминированность» подбора навыка по схеме данных может плохо переноситься на данные с нестандартной или «грязной» структурой, а единственный описанный случай использования (single-tenant) не говорит о том, как архитектура ведёт себя на разнородном множестве клиентов.