ИИ-аналитик на 350 ГБ и честном слове

Давеча разговаривал с CTO одной компании. Оборот - около 5 млрд рублей в год, данных - примерно 350 ГБ, источников три: Redis, BigQuery и MS SQL. Масштаб вполне осязаемый, не пет-проект на ноутбуке.

CTO продвигает внутри простую идею: BI и аналитика в привычном виде компании больше не нужны. Он сам навайбкодит ИИ-аналитика, который подключится к данным и будет отвечать на любые вопросы бизнеса. Заодно компания сэкономит миллионы долларов на аналитиках и привычной BI-инфраструктуре. 🤦 Последняя часть, судя по всему, особенно хорошо продаётся CEO.

Есть только несколько деталей. В компании нет:

▫️ документации к дашбордам
▫️ доменной базы знаний
▫️ каталога данных и lineage
▫️ семантического или core-слоя
▫️ даже страницы в Confluence, где зафиксированы определения метрик, владельцы данных и правила работы с ними

То есть агенту скорее всего дадут какой-то контекст и предложат самостоятельно понять, из какой таблицы брать revenue, какую дату считать датой продажи, как учитывать возвраты, НДС, отмены и задвоения, а затем уверенно отдать цифру бизнесу. Желательно сразу правильную.

Написать SQL по схеме таблиц модель действительно может. Проблема начинается там, где заканчивается схема и начинается смысл. Если два менеджера по-разному понимают revenue или install, а договорённость нигде не записана, агенту нечего «понять». Он выберет одну из правд, аккуратно посчитает её и очень убедительно объяснит результат.

Я сейчас участвую в разработке похожего инструмента в бигтехе. У нас уже есть существенная часть перечисленного фундамента, а недостающие элементы строятся: документация, каталог, lineage, доменные знания, владельцы, правила доступа, проверенные расчёты. И даже в такой среде по ощущениям мы пока не приблизились к заветному чату, который надёжно отвечает на любой вопрос про данные.

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

По моим прикидкам сложность такого проекта слабо связана с объёмом данных. 350 ГБ могут быть сложнее 35 ТБ, если в этих гигабайтах никто не договорился о терминах. После условного порога в две базы, два дашборда и двух аналитиков появляются разные источники истины, локальные трактовки и исторические исключения. «Два аналитика» я, конечно, занизил, но направление мысли именно такое.

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

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

Возможно, здесь и прячется ответ, почему инициативу про отказ от BI двигает именно CTO 😂 Технически собрать интерфейс к LLM несложно. Основная работа лежит в скучной области договорённостей, ответственности и качества данных, которую особенно приятно объявить лишними расходами.

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