Привет, Хабр! Меня зовут Александр Овсов, я RnD-разработчик в компании Just AI. Занимаюсь прототипированием новых фич продукта Jay Knowledge Hub и исследованиями новых возможностей LLM. Jay Knowledge Hub — это умная платформа для поиска по неразмеченным корпоративным данным, созданная на базе RAG и AI-агентов.

Одним из типичных юзкейсов для наших пользователей является аналитика сложных данных хранящихся в CSV-таблицах (финансовые отчеты, продуктовая аналитика и т.д.). Работать с такими данными при помощи классических методов RAG сложно из-за структуры этих данных. Чтобы решить эту проблему, мы решили использовать агентский подход — набирающий популярность метод, который позволяет LLM выполнять сложные задачи, например, отправлять SQL-запросы к таблицам. О реализации такого подхода на примере CSV таблиц я сейчас и расскажу.

Архитектура агента

Для создания LLM-агента, отвечающего на вопросы по нескольким CSV-таблицам при помощи SQL-запросов, была выбрана мультиагентная архитектура. В ней задействованы два агента:

1. Первый агент — определяет, к какой таблице относится вопрос пользователя.

2. Второй агент — выполняет SQL-запрос к таблице, выбранной первым агентом.

Первый агент: определение таблицы по вопросу

Для определения таблицы, к которой относится вопрос, необходимо создать эффективное саммари CSV-таблицы. Требования к такому саммари:

Эмбеддинги, созданные на основе саммари, должны отражать содержание таблицы;
Саммари должно быть понятным для LLM, чтобы агент точно понимал соответствие таблицы вопросу.

Алгоритм формирования саммари таблицы

Изначально результирующая таблица формируется из случайно выбранных строк исходной таблицы.
Затем алгоритм итеративно улучшает эту таблицу: на каждом шаге случайным образом одна из строк заменяется другой случайно выбранной строкой исходной таблицы.
После каждой замены алгоритм проверяет, увеличилась ли вариативность значений в столбцах.
Если вариативность выросла или осталась прежней, замена сохраняется; если уменьшилась — замена отменяется.
Этот процесс повторяется фиксированное число раз (число строк исходной таблицы/10). В результате с высокой вероятность получается репрезентативное саммари.
Например, если таблица содержит способы оплаты (карта, ваучер, банковский перевод), алгоритм гарантирует, что в итоговом саммари будет представлено максимально возможное разнообразие этих значений.

Функционирование первого агента

Агент имеет следующий системный промпт:

> You are a chatbot tasked with answering user questions based on one of several tables.
> 
> Use find_table to find most relevant to user question tables. You can paginate through results. Check no more then first 2 pages.
> 
> If the question does not match any table - respond with `<no answer>`
> 
> Use the query_table function to retrieve the final answer. Keep in "question" param as much information as possible.
> 
> If the query_table function does not return an answer - respond with `<no answer>`
> 
> Ensure your answer is in the same language as the question.

У агента есть две функции:

- find_table(query, page_num) — ищет таблицу по эмбеддингам саммари;

- query_table(table_name, question) — делает SQL-запрос для получения конкретного ответа.

Агент сначала вызывает функцию find_table, которая возвращает страницу релевантных таблиц (пять таблиц на странице, максимум две страницы). Затем агент по саммари таблиц решает, подходит ли найденная таблица для ответа на вопрос. Если подходящая таблица найдена, он вызывает функцию query_table. Если таблица не найдена за две страницы поиска, агент отвечает, что ответа нет.

Обработка уточняющих вопросов (поддержка истории сообщений)

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

> Keep in "question" param as much information as possible.

Исправление ошибок в запросах пользователя

Интересным свойством агента является автоматическое исправление ошибок в запросах пользователя при вызове функции query_table. Например, если пользователь неверно указывает регистр букв (имя студента или название должности), агент самостоятельно учитывает правильное написание на основе саммари таблицы и корректирует запрос при вызове функции. Это повышает общую точность и надежность ответов.

Второй агент: выполнение SQL-запросов к таблице

Второй агент реализует функции для непосредственной работы с таблицами через SQL-запросы. Этот агент также использует ранее созданное саммари таблицы, чтобы сначала создать саму таблицу в базе данных SQLite3, а затем ответить на вопрос пользователя.

Системный промпт этого агента:

> You are a chatbot tasked with answering user questions based on a table by executing SQL queries. The underlying SQL engine is SQLite3. Follow this sequence:
> 
> Analyze the table structure: Review the provided table sample to understand its structure and content.
> 
> Create the SQL table: Use the function create_sql_table to create table. You should create table with all columns. Use the table name {table_name}. This function will also insert all rows. DO NOT do it yourself. Just provide CREATE TABLE statement
> 
> If you think the table was not created correctly before, recreate it to ensure accuracy.
> 
> Answer user questions: Use query_sql_table to execute SQL queries and answer the user’s questions based on the data.
> 
> The table contains {columns} columns and {rows} rows.
> 
> Table sample (random rows for information only - not for insertion): {table_sample}
> 
> {table_status_warning}

Таким образом агент может выполнять два действия:

Создавать таблицу через функцию create_sql_table(create_command) (только оператор CREATE TABLE, вставку данных выполняет сама функция);
Выполнять SQL-запросы к таблице (query_sql_table(query)).

Обработка ошибок при создании и запросах к таблице

Если в процессе создания SQL-таблицы или выполнения запросов возникают ошибки (например, неправильно определён тип данных столбца или несоответствие формата), агент получает подробную информацию об ошибке. На основании этого агент способен:

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

Такое поведение делает процесс более устойчивым к ошибкам и обеспечивает точность и корректность итоговых ответов.

Кэширование таблиц для ускорения работы

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

Вместо заключения

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

Анализируем сложные данные в CSV-таблицах: как мы усовершенствовали RAG с помощью агентского подхода