Как ЮMoney учит ИИ отвечать на вопросы к базе данных и проверять собственные ошибки

Проект вырос из внутреннего хакатона. Как объясняет старший аналитик данных ЮMoney Артём, сотрудники постоянно обращаются к аналитикам с вопросами, на которые готовые отчёты не отвечают. Запросы копятся в очереди, хотя многие из них довольно типовые. Новый сервис позволяет получить ответ без ожидания: достаточно написать вопрос, например, сколько электронных кошельков открыли в мае 2025 года. Затем можно уточнить: «А в декабре? И покажи по неделям». Система сохранит смысл предыдущего вопроса, изменит период и построит новую выборку.

Для управления процессом команда выбрала LangGraph — инструмент, который позволяет выстроить работу ИИ в виде последовательности контролируемых шагов. Сначала сервис определяет предметную область, затем выбирает таблицы, составляет SQL, проверяет его и выполняет. Если что-то пошло не так, он может вернуться на предыдущий шаг или попросить уточнение. Вместо передачи модели всей переписки система хранит последний успешно обработанный вопрос и периодически обновляет краткое содержание диалога. Это помогает не перегружать модель лишними подробностями.

Один из уроков разработки связан с определением темы вопроса. Поначалу команда решила экономить время: если пользователь почти повторяет предыдущий запрос, можно не определять предметную область заново. Но оказалось, что за небольшим изменением формулировки иногда скрывается совершенно другой вопрос. Теперь тема проверяется каждый раз. Сначала работают обычные правила по ключевым словам, затем при необходимости подключается языковая модель. Если результаты противоречат друг другу, сервис просит пользователя уточнить запрос, а не выбирает ответ наугад.

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

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

Перед выполнением SQL дополнительно проверяют на опасные операции, способные изменить или удалить данные. Затем MS SQL Server в режиме SET NOEXEC ON проверяет синтаксис и существование таблиц и полей без выполнения запроса. Если найдена ошибка, модель получает её описание и может исправить SQL. По умолчанию предусмотрено до трёх попыток. Когда нужных данных нет, сервис должен прямо сообщить об этом, а не придумывать число.

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

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

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

Следующий шаг — сократить ручную подготовку новых предметных областей. Сейчас для каждой приходится отдельно описывать таблицы, правила и примеры. В будущем разработчики хотят использовать каталог данных и историю задач в Jira, чтобы система могла находить похожие аналитические запросы. Рассматривается и более сложный сценарий: агент самостоятельно ищет дополнительные данные или пишет Python-код для расчёта отклонений и прогнозов по готовой выгрузке. Но внедрять новые возможности команда намерена только при наличии проверяемого улучшения качества: сама по себе большая самостоятельность ИИ ещё не означает, что он стал полезнее. Подобный подход к развитию ИИ-агентов через измерение качества уже описывался в другом техническом кейсе.