Мы планируем поэтапное внедрение, об этом немного есть в разделе - Дорожная карта: эволюционное внедрение AIDA.
Сейчас у нас готова инфраструктура, готов агентский фреймворк. Начнем с мониторинга и планирования ресурсов, это относительно просто (по сравнению с другими задачами). Параллельно команда прорабатывает подходы к разработке c dbt, пока как MVP. Основная проблема, с которой сталкиваются все (и мы не исключение) - на этапе MVP все работает, а при тиражировании решения возникают проблемы. Но предупрежден - значит вооружен, дорогу осилит идущий!
Позвольте, я переформулирую его, чтобы подчеркнуть важный нюанс: «Если я поставлю ваш фреймворк на свою БД, в которой тысячи таблиц, он сразу заработает?»
Ответ - нет, не заработает. И это подводит нас к сути вопроса об окупаемости.
Теперь попробую ответить на вопрос в исходной постановке.
В этой статье описан универсальный агентский фреймворк, способный решать разные задачи. Text-to-sql - одна из таких задач. Разработка такого фреймворка задача, возможно, не самая тривиальная, но разовая. Добавить в него пайплайн для решения задачи text-to-sql с точки зрения трудозатрат, по сравнению со стоимостью разработки самого фреймворка, o(n).
При этом пайплайн, как бы хорошо он ни был реализован, ничего не стоит, если нет хорошего описания метаданных БД, с которой он работает (таблицы, атрибуты, ключи, связи, описание атрибутов). Но и этого не достаточно. Помимо самого описания БД нужно еще и бизнесовое описание атрибутов и их отношений с другими объектами (семантический слой или его аналог в любом виде). А еще нужны примеры реальных запросов, решающих конкретную задачу. Это описание для DWH/Lakehouse (а мы планируем использовать его с нашей аналитической платформой) получить гораздо сложнее и дороже, чем реализовать агентский фреймворк с пайплайном text-to-sql.
То есть стоимость всей системы состоит из двух частей:
• "Движок": Это сама технология, которая умеет думать, понимать вопросы и формировать ответы. Ее разработка - это разовая и относительно небольшая часть затрат в общем масштабе.
• "База знаний" (данные и метаданные): Это "топливо" для движка. Сюда входит детальное описание всех наших данных, бизнес-правил, связей, а также примеры реальных запросов. Именно в это мы инвестируем уже много лет, и это наш самый ценный актив. Без этой базы знаний любой, даже самый умный "движок", будет бесполезен.
Таким образом, мы не просто создаем "еще одну IT-систему" или отдаем дань моде (хайпу). Можно рассматривать это как инвестицию, которая позволит увеличить отдачу от уже вложенных за несколько лет средств в создание нашей платформы данных. Мы идем в сторону демократизации доступа к данным (в эту сторону мы начали идти за долго до того, как это словосочетание стало популярным), позволяя любому сотруднику (при наличии у него доступов), а не только аналитику, знающему, как работает наша платформа, получать ответы на свои вопросы.
В долгосрочной перспективе это не просто дешевле, а создает совершенно новое качество работы с данными, которое невозможно получить, просто нанимая новых людей.
Мы планируем поэтапное внедрение, об этом немного есть в разделе - Дорожная карта: эволюционное внедрение AIDA.
Сейчас у нас готова инфраструктура, готов агентский фреймворк. Начнем с мониторинга и планирования ресурсов, это относительно просто (по сравнению с другими задачами). Параллельно команда прорабатывает подходы к разработке c dbt, пока как MVP. Основная проблема, с которой сталкиваются все (и мы не исключение) - на этапе MVP все работает, а при тиражировании решения возникают проблемы. Но предупрежден - значит вооружен, дорогу осилит идущий!
Пока нет. Но мы подумаем в этом направлении.
Хороший и очень правильный вопрос.
Позвольте, я переформулирую его, чтобы подчеркнуть важный нюанс: «Если я поставлю ваш фреймворк на свою БД, в которой тысячи таблиц, он сразу заработает?»
Ответ - нет, не заработает. И это подводит нас к сути вопроса об окупаемости.
Теперь попробую ответить на вопрос в исходной постановке.
В этой статье описан универсальный агентский фреймворк, способный решать разные задачи. Text-to-sql - одна из таких задач. Разработка такого фреймворка задача, возможно, не самая тривиальная, но разовая. Добавить в него пайплайн для решения задачи text-to-sql с точки зрения трудозатрат, по сравнению со стоимостью разработки самого фреймворка, o(n).
При этом пайплайн, как бы хорошо он ни был реализован, ничего не стоит, если нет хорошего описания метаданных БД, с которой он работает (таблицы, атрибуты, ключи, связи, описание атрибутов). Но и этого не достаточно. Помимо самого описания БД нужно еще и бизнесовое описание атрибутов и их отношений с другими объектами (семантический слой или его аналог в любом виде). А еще нужны примеры реальных запросов, решающих конкретную задачу. Это описание для DWH/Lakehouse (а мы планируем использовать его с нашей аналитической платформой) получить гораздо сложнее и дороже, чем реализовать агентский фреймворк с пайплайном text-to-sql.
То есть стоимость всей системы состоит из двух частей:
• "Движок": Это сама технология, которая умеет думать, понимать вопросы и формировать ответы. Ее разработка - это разовая и относительно небольшая часть затрат в общем масштабе.
• "База знаний" (данные и метаданные): Это "топливо" для движка. Сюда входит детальное описание всех наших данных, бизнес-правил, связей, а также примеры реальных запросов. Именно в это мы инвестируем уже много лет, и это наш самый ценный актив. Без этой базы знаний любой, даже самый умный "движок", будет бесполезен.
Таким образом, мы не просто создаем "еще одну IT-систему" или отдаем дань моде (хайпу). Можно рассматривать это как инвестицию, которая позволит увеличить отдачу от уже вложенных за несколько лет средств в создание нашей платформы данных. Мы идем в сторону демократизации доступа к данным (в эту сторону мы начали идти за долго до того, как это словосочетание стало популярным), позволяя любому сотруднику (при наличии у него доступов), а не только аналитику, знающему, как работает наша платформа, получать ответы на свои вопросы.
В долгосрочной перспективе это не просто дешевле, а создает совершенно новое качество работы с данными, которое невозможно получить, просто нанимая новых людей.