Как ИИ-агенты упрощают работу с аналитикой: разбор реальных кейсов с митапа «ИИшная»

Митап «ИИшная», организованный ЮMoney, показал: ИИ-агенты уже решают прикладные задачи аналитики, снижая порог входа в работу с данными и экономя часы ручного труда. Три ключевых кейса - SQL-агенты на LangGraph, автоматическая оценка качества LLM через Langfuse и LLM-as-a-Judge, а также локальные базы знаний в Markdown для RAG - дают четкий ответ на вопрос, как перейти от экспериментов к надежным инструментам. В этом разборе мы возьмем каждое решение и объясним его логику без технического жаргона, чтобы вы могли оценить применимость в своей работе.

Главный вывод встречи: агентный подход - когда программа не просто выдает ответ, а проходит несколько этапов проверки - резко сокращает число ошибок. Простые Text-to-SQL решения часто генерируют неверные запросы, потому что не знают структуру базы данных или сленг компании. Агент на LangGraph действует иначе: он уточняет вопрос, пишет SQL, выполняет его и, если видит ошибку или пустой результат, переписывает запрос. Этот цикл делает взаимодействие с данными предсказуемым.

Параллельно на митапе подняли вопрос контроля качества: как понять, что языковая модель не ошибается, если вручную проверять каждый ответ невозможно. Решение - связка Langfuse и метода LLM-as-a-Judge, где одна модель оценивает ответы другой по заданным критериям. Третий блок - организация базы знаний в обычных Markdown-файлах для RAG-сценариев. Это простой и безопасный способ дать ИИ доступ к актуальным документам компании без облачных хранилищ и сложных внедрений. Все инструменты из кейсов - опенсорсные или имеют бесплатные версии, начать можно с малого.

Что такое ИИ-агенты в аналитике и почему о них говорят

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

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

На митапе «ИИшная» показали живые примеры таких агентов. Организатор - ЮMoney - собрал практиков, которые уже внедряют агентные решения в аналитические пайплайны. Никаких абстрактных прогнозов: только работающие связки LangGraph для SQL-запросов, Langfuse для оценки качества и Markdown для баз знаний. Это те инструменты, которые можно взять и применить, а не просто обсудить.

SQL-агенты на LangGraph: как перестать бояться неправильных запросов

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

Почему простые Text-to-SQL решения часто подводят

Прямой перевод текста в SQL без промежуточных проверок дает сбои по нескольким причинам. Языковая модель не видит актуальную схему базы данных - она может предположить существование таблицы, которой нет, или перепутать названия полей. Бизнес-термины вроде «активный клиент» или «чистая прибыль» модель интерпретирует буквально, без учета внутренних правил расчета. Если запрос возвращает пустой результат или ошибку, простой Text-to-SQL не способен это обнаружить и исправить - он просто выдает сгенерированный код. Отсюда и возникает ощущение, что «ИИ генерирует ерунду, нельзя доверять». Проблема не в модели, а в отсутствии цикла обратной связи.

Как устроен SQL-агент: четыре шага к точному ответу

Агент на LangGraph работает как опытный аналитик, который не хватается сразу за написание кода, а сначала разбирается в задаче. Процесс состоит из четырех этапов.

Шаг первый - уточнение. Получив запрос «продажи за прошлый месяц», агент переспрашивает: какой именно месяц считать прошлым, по какой таблице смотреть, включать ли возвраты. Это критически важно, потому что пользователь часто формулирует вопрос неполно, а модель без уточнения додумает детали и ошибется.

Шаг второй - генерация SQL. Имея уточненный контекст и доступ к схеме базы данных, агент пишет запрос. Здесь LangGraph позволяет встроить проверку синтаксиса до выполнения.

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

Шаг четвертый - автокоррекция. Агент анализирует ошибку и переписывает запрос с ее учетом. Например, если ошибка в названии таблицы, он ищет похожие названия в схеме. Если результат пуст, проверяет условия фильтрации. Этот цикл повторяется до получения корректного ответа или до исчерпания лимита попыток. Такой подход снижает долю неудачных запросов по сравнению с одношаговыми Text-to-SQL решениями - точные цифры зависят от сложности базы данных и качества промптов, но сам принцип многоэтапной проверки делает результат предсказуемым.

Автоматическая оценка качества ИИ: Langfuse и LLM-as-a-Judge

Когда вы внедряете языковую модель в аналитический процесс, возникает вопрос: как понять, что ответы становятся лучше, а не хуже? Ручная проверка каждого результата отнимает часы и не масштабируется. На «ИИшной» показали практическую связку: платформа Langfuse собирает метрики, а метод LLM-as-a-Judge автоматически выставляет оценки по заданным критериям.

Зачем нужна автоматическая оценка LLM

Без системы оценки вы работаете вслепую. Изменили промпт - стало лучше или хуже? Обновили модель - как это повлияло на точность ответов? Добавили новые документы в базу знаний - не появились ли противоречия? Langfuse решает эти вопросы, собирая логи каждого взаимодействия: запрос пользователя, ответ агента, время выполнения, токены и ошибки. На основе этих данных можно строить дашборды и отслеживать аномалии. Это не просто мониторинг, а основа для итеративного улучшения агента.

LLM-as-a-Judge: как это работает на практике

Метод LLM-as-a-Judge устроен так: отдельная языковая модель получает на вход вопрос пользователя, ответ основного агента и инструкцию с критериями оценки - точность, полнота, безопасность, соответствие формату. Она выставляет оценку по шкале и объясняет ее текстом. Это не идеальный судья - модель тоже может ошибаться, - но для отлова явных проблем метод работает надежно. Если агент сгенерировал SQL, который возвращает не те данные, LLM-as-a-Judge сравнивает вопрос пользователя с результатом и сигнализирует о расхождении. На практике это экономит часы ручной проверки и позволяет быстро находить слабые места в логике агента. Langfuse интегрирует такие оценки в общую систему мониторинга, так что вы видите не только факт ошибки, но и ее причину.

Локальная база знаний в Markdown для RAG: порядок в данных без облаков

RAG - Retrieval-Augmented Generation - это подход, при котором языковая модель перед ответом ищет релевантную информацию в ваших документах, а не полагается только на память. Это решает проблему устаревших знаний и снижает вероятность галлюцинаций. В аналитике RAG позволяет агенту опираться на описания метрик, бизнес-правила и примеры отчетов, а не додумывать их.

Что такое RAG и почему это важно для аналитики

Представьте: вы спрашиваете агента «посчитай отток клиентов за квартал». Без RAG модель додумает формулу оттока сама - и почти наверняка ошибется, потому что в каждой компании отток считают по-своему. С RAG агент сначала находит в базе знаний документ «Методика расчета оттока», видит формулу и только потом генерирует SQL или отчет. Результат соответствует внутренним стандартам, а не усредненному представлению модели. Это критически важно для любых задач, где есть корпоративная специфика: от финансовой отчетности до продуктовой аналитики.

Markdown как основа базы знаний: простота и контроль

На митапе показали подход, который не требует дорогих корпоративных решений: база знаний в обычных Markdown-файлах. Markdown - это текстовый формат с простой разметкой, который читается человеком без специальных редакторов и легко индексируется для ИИ. Файлы можно хранить локально или в приватном репозитории, что закрывает вопросы безопасности данных - никакие документы не уходят во внешние облака.

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

Кому и когда пригодятся такие ИИ-агенты

Описанные кейсы закрывают конкретные сценарии, с которыми сталкиваются разные роли в команде. Аналитик, который тратит часы на написание однотипных SQL-запросов, может делегировать их агенту на LangGraph и сосредоточиться на интерпретации результатов. Команда, которая хочет дать доступ к данным нетехническим сотрудникам - маркетологам, продакт-менеджерам, руководителям - получает инструмент, где не нужно знать SQL: достаточно задать вопрос на естественном языке, а агент сам уточнит детали и вернет готовую выгрузку. Разработчик, внедряющий LLM в продукт, получает связку Langfuse и LLM-as-a-Judge для автоматического контроля качества ответов без ручной модерации каждого кейса.

Все показанные инструменты доступны для старта без бюджета. LangGraph и Langfuse - опенсорсные проекты с бесплатными версиями. Markdown-файлы не требуют вообще никаких затрат, кроме времени на описание базы знаний. Начать можно с одного сценария: например, сделать агента для пяти самых частых аналитических запросов в компании и подключить его к Langfuse для мониторинга. Результат будет виден сразу - по сокращению времени на рутинные задачи и снижению числа ошибок в отчетах.

Отдельно стоит отметить тренд на создание ИИ-агентов без программирования. Платформа «Когнитрон» от Росатома позволяет обучать модели и создавать ИИ-помощников через интерфейс на естественном языке - это снижает порог входа для специалистов без IT-подготовки. Похожий подход к автоматизации рутины разбирается в статье про создание «цифровых коллег», где на примере Cursor и Alibaba Cloud показаны реальные барьеры внедрения: безопасность, передача знаний и контроль качества. Эти материалы дополняют картину и помогают понять, как агенты встраиваются в рабочие процессы за пределами аналитики.

Что дальше: как следить за развитием ИИ-агентов в аналитике

Тема агентов развивается быстро: появляются новые фреймворки, методы оценки и подходы к организации данных. Митапы вроде «ИИшная» - хороший источник практических знаний, где показывают работающие решения, а не слайды с прогнозами. Если вы хотите оставаться в курсе без информационного шума, в проекте «Среда AI» мы разбираем такие кейсы простым языком: как бизнес теряет доверие к AI-агентам из-за неполных данных, как Google Antigravity 2.0 делает агентов доступными прямо на рабочем столе и как ИИ меняет профессиональный контент в 2026 году. Подписывайтесь на обновления - дальше будет только интереснее.