Где это стоит компании времени и решений

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

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

Дефицит аналитиков относительно объёма вопросов. В компании может быть один аналитик на весь поток запросов от нескольких отделов - продажи, склад, финансы. Приоритизация неизбежна, и часть вопросов просто не доходит до очереди.

От дашбордов к вопросу на естественном языке

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

Как работает анализ базы данных на естественном языке

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

Как это устроено по шагам:

  • Пользователь задаёт вопрос на естественном языке - «сколько клиентов сделали повторный заказ за последние три месяца» - без знания структуры базы и без SQL.
  • Система понимает структуру данных - таблицы, связи между ними, названия полей - и переводит вопрос в корректный SQL-запрос к конкретной базе.
  • Запрос выполняется, и результат возвращается в понятном виде - таблица или график, а не сырой вывод из базы.
  • Система может пойти дальше простого ответа на вопрос - заметить аномалию в данных (например, резкий провал по одному сегменту клиентов), предложить смежный разрез, который стоит проверить, или обратить внимание на тренд, который не был явно запрошен, но заметен в данных.

Ключевое отличие от обычного BI-дашборда: дашборд отвечает на заранее заданные вопросы (те, под которые его настроили), а система с естественным языком отвечает на новый вопрос сразу, без предварительной настройки отчёта под него.

Что реально может, а что нет

Здесь стоит быть честным о том, где проходит граница возможностей - потому что ожидания вокруг «ИИ, который сам во всём разберётся» часто завышены.

Может:

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

Не может или может плохо:

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

Ограничения подхода

  • Точность text-to-SQL зависит от сложности схемы базы: чем больше таблиц и нестандартных связей, тем выше риск, что система построит запрос неточно. Сложные многотабличные запросы стоит проверять, особенно на старте.
  • Доступ ИИ к базе данных - это вопрос безопасности, который нужно решать отдельно: какие таблицы доступны, есть ли в них персональные данные, как разграничены права доступа между пользователями.
  • Система эффективна для структурированных данных (таблицы, понятная схема). Для неструктурированных данных - сканы, произвольные текстовые поля - нужны другие инструменты.
  • Это направление требует пилотной проверки на реальной базе конкретной компании, прежде чем говорить о промышленном использовании - общих гарантий точности здесь быть не может, слишком многое зависит от состояния конкретной базы.

С чего начинать, если тема актуальна

Три вопроса, которые стоит задать себе до того, как обсуждать такое решение с подрядчиком:

  1. Насколько структурирована ваша база данных - единая схема или несколько разрозненных систем с разной логикой?
  2. Сколько сейчас в среднем ждёт бизнес-пользователь ответа на аналитический вопрос от аналитика или разработчика?
  3. Есть ли в компании уже накопленная документация по структуре базы (описание таблиц, связей), или это знание есть только в голове у конкретного разработчика?

Если ответ на последний вопрос «только в голове у одного человека» - это стоит решить в первую очередь, независимо от того, будет ли в компании ИИ-аналитик: это риск сам по себе.

Частые вопросы

Нужно ли знать SQL, чтобы пользоваться такой системой?

Нет - в этом весь смысл: вопрос задаётся обычными словами, SQL-запрос система строит сама.

Какие данные может анализировать ИИ таким способом?

Структурированные данные с понятной схемой - таблицы CRM, ERP, учётных систем. Неструктурированные данные (сканы, произвольный текст) требуют других инструментов.

Безопасно ли давать ИИ доступ к базе данных компании?

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

Похожие материалы