24.03.2026
RAG и его применение в аналитике
RAG – самый прикладной инструмент, который появился в результате LLM-бума. Это поиск в любимом "чат"-формате по внутренним данным компании – таблицам в базах данных, документам, изображениям и т.д.
Как использовать RAG в аналитике и перейти от работы с базами данных к чату с дружелюбным ботом, который подробно всё разъяснит? Постараюсь раскрыть в этом материале.
Как использовать RAG в аналитике и перейти от работы с базами данных к чату с дружелюбным ботом, который подробно всё разъяснит? Постараюсь раскрыть в этом материале.
Чтобы ИИ мог ответить на простой вопрос "сколько пользователей было вчера на сайте", то ИИ-модель должна откуда-то узнать эти данные. Никакая LLM не выдумывает ничего из воздуха.
Может показаться, что для решения этой задачи модель нужно специально дообучить на данных клиента и продолжать это регулярно делать. Дообучение моделей действительно используется, но у такого подхода есть минусы. LLM – это вероятностная модель и она может отвечать на одни и те же запросы по-разному. И ошибаться, конечно. Что недопустимо в задачах аналитики. Поэтому, для систем в которых мы ожидаем точные и повторяемые результаты, задачу требуется решать иначе.
И тут на сцену выходит RAG. Это оркестратор процесса работы с данными с элементами LLM. Для пользователя внешне ничего не меняется, а вот "под капотом" процесс меняется кардинально.
В случае отправки запроса напрямую LLM запрос обрабатывается самой моделью внутри себя. А если используется RAG, то технически это выглядит сложнее:
Может показаться, что для решения этой задачи модель нужно специально дообучить на данных клиента и продолжать это регулярно делать. Дообучение моделей действительно используется, но у такого подхода есть минусы. LLM – это вероятностная модель и она может отвечать на одни и те же запросы по-разному. И ошибаться, конечно. Что недопустимо в задачах аналитики. Поэтому, для систем в которых мы ожидаем точные и повторяемые результаты, задачу требуется решать иначе.
И тут на сцену выходит RAG. Это оркестратор процесса работы с данными с элементами LLM. Для пользователя внешне ничего не меняется, а вот "под капотом" процесс меняется кардинально.
В случае отправки запроса напрямую LLM запрос обрабатывается самой моделью внутри себя. А если используется RAG, то технически это выглядит сложнее:
1. Категоризация запроса пользователя – определение того, что он ожидает получить в ответ. Делается либо с помощью LLM, либо вхождением ключевых слов в запрос. И в зависимости от заданной категории запускается требуемый сценарий. Например, поиск в базе, или поиск в документации;
2. Запрос пользователя преобразуется в вектор через эмбеддинг – специализированная LLM, которая говорит на языке векторов – на входе принимает от пользователя текст, а на выходе отдаёт вектор;
3. с этим вектором отдельная функция идёт в векторную базу данных и ищет там наиболее подходящие значения (по косинусному расстоянию) и соответствующий ему текст на человеческом языке;
4. И уже с первоначальным запросом пользователя и найденным текстом RAG идёт в LLM с запросом вида "У пользователя вопрос: ..., и есть вот такие данные: ... . Составь ответ, который поможет пользователю ...".
2. Запрос пользователя преобразуется в вектор через эмбеддинг – специализированная LLM, которая говорит на языке векторов – на входе принимает от пользователя текст, а на выходе отдаёт вектор;
3. с этим вектором отдельная функция идёт в векторную базу данных и ищет там наиболее подходящие значения (по косинусному расстоянию) и соответствующий ему текст на человеческом языке;
4. И уже с первоначальным запросом пользователя и найденным текстом RAG идёт в LLM с запросом вида "У пользователя вопрос: ..., и есть вот такие данные: ... . Составь ответ, который поможет пользователю ...".
На практике полноценный RAG не ограничивается одной цепочкой. Чаще это ветвистое логическое дерево, в котором, по мере обработки запроса, происходит повторная категоризация, перепроверка и нормализация полученных данных, а также подключение дополнительных инструментов и шаблонизаторов ответа.
Например, если мы говорим про задачу анализа данных, то вначале RAG определяет что это за тип запроса: получение конкретных показателей, или это запрос на поиск аномалий, или оценка текущих данных. Для корректного извлечения данных из баз данных существует целый класс решений, которые генерят SQL-скрипты (такие решения называются text2sql). Выполнение полученного SQL-скрипта – это тоже отдельный этап/функция в общем процессе.
На практике проблемы в RAG-системе те же что есть в любой системе аналитики: данные должны быть чистыми, структурированными, понятными. Если таблицы плохо описаны, если метрики считаются по-разному в разных отчётах или если структура данных непонятна — модель начинает ошибаться. Она может выбрать не ту таблицу, перепутать поля или построить некорректный join.
Например, если мы говорим про задачу анализа данных, то вначале RAG определяет что это за тип запроса: получение конкретных показателей, или это запрос на поиск аномалий, или оценка текущих данных. Для корректного извлечения данных из баз данных существует целый класс решений, которые генерят SQL-скрипты (такие решения называются text2sql). Выполнение полученного SQL-скрипта – это тоже отдельный этап/функция в общем процессе.
На практике проблемы в RAG-системе те же что есть в любой системе аналитики: данные должны быть чистыми, структурированными, понятными. Если таблицы плохо описаны, если метрики считаются по-разному в разных отчётах или если структура данных непонятна — модель начинает ошибаться. Она может выбрать не ту таблицу, перепутать поля или построить некорректный join.
RAG может генерировать синтаксически корректный SQL, который при этом делает не то, что ожидал пользователь. Например, система может использовать неправильную таблицу или выбрать поле с похожим названием, в случае если отсутствует документация и описание системы. Без хорошей документации схема базы для модели выглядит почти так же непонятно, как и для любого человека не знакомого с проектом. Названия вроде t_user_activity_log_v2 или event_data_ext мало что говорят о реальном содержании таблицы.
Даже если SQL получился правильным, результат ещё нужно интерпретировать. Чаще пользователю важно не столько текущий показатель, сколько объяснение того, почему он такой и как он поменялся. Поэтому важно заложить в оркестратор порядок обогащения ответа: сравнить полученный результат с этим же показателем неделю и месяц назад, посмотреть динамику в разрезе по устройствам, разбить ответ по источникам привлечения пользователей и т.д.
Даже если SQL получился правильным, результат ещё нужно интерпретировать. Чаще пользователю важно не столько текущий показатель, сколько объяснение того, почему он такой и как он поменялся. Поэтому важно заложить в оркестратор порядок обогащения ответа: сравнить полученный результат с этим же показателем неделю и месяц назад, посмотреть динамику в разрезе по устройствам, разбить ответ по источникам привлечения пользователей и т.д.
Основная сложность таких систем вовсе не в LLM. Гораздо больше времени уходит на подготовку данных: описание таблиц, документацию метрик, примеры корректных SQL-запросов.
Трудностей много, но при успешной реализации такой системы – для конечного пользователя доступ к данным становится ближе. Написать запрос в чат-бот гораздо проще, чем просить данные у аналитика или писать SQL.
Существуют готовые фреймворки, которые позволяют решать задачи типа text2sql. Например, vanna-ai, который позволяет сформировать модель данных по схемам аналитической базы данных и примеров запросов к этой базе данных. Для своих задач я использую собственные наработки, которые в частности подсмотрены в "ванне". Основная задача таких систем в том, чтобы аккуратно собрать контекст о структуре данных и научить систему определять корректный контекст происходящего.
А если хотите реализовать бот, который будет отвечать на основе ваших данных – вы можете мне написать, я вам с этим помогу.
@zmeuwka
Этот же пост в telegram: ссылка
Трудностей много, но при успешной реализации такой системы – для конечного пользователя доступ к данным становится ближе. Написать запрос в чат-бот гораздо проще, чем просить данные у аналитика или писать SQL.
Существуют готовые фреймворки, которые позволяют решать задачи типа text2sql. Например, vanna-ai, который позволяет сформировать модель данных по схемам аналитической базы данных и примеров запросов к этой базе данных. Для своих задач я использую собственные наработки, которые в частности подсмотрены в "ванне". Основная задача таких систем в том, чтобы аккуратно собрать контекст о структуре данных и научить систему определять корректный контекст происходящего.
А если хотите реализовать бот, который будет отвечать на основе ваших данных – вы можете мне написать, я вам с этим помогу.
@zmeuwka
Этот же пост в telegram: ссылка