Как повысить доверие к ответам своего AI-агента?

Маркетолог спрашивает в чате: «Сколько у нас было за вчера лидов?». И через несколько секунд получает готовый и точный ответ. Заметьте, не тикет к аналитикам, не вопросы, а зачем это и попытки отправить в приоритезацию его запрос, а конкретное значение лидов за вчера. Несколько лет назад это казалось фантастикой, но сейчас это можно не только быстро реализовать, но и проконтролировать качество.

Технически это устроено так: витрина в базе данных, MCP-сервер поверх неё, AI-агент, который переводит вопрос на естественном языке в SQL и выполняет его. Если данные все есть, то собрать демо можно за вечер.

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

Агент, который в 9 случаях из 10 отвечает верно, а в десятом врет без единого признака сомнения, хуже, чем отсутствие агента.

Ниже я расскажу, что делать, чтобы десятого случая не было.

Как все устроено

MCP (Model Context Protocol) — протокол, по которому агент получает доступ к внешним инструментам. MCP-сервер для ClickHouse отдаёт агенту список таблиц, их структуру и возможность выполнить SELECT. Агент сам решает, какой запрос написать.

Вот в этом «сам решает» и находится вся сложность. Дальше — четыре вещи, которые превращают её в управляемую.

1. Создаем витрину

Соблазн выглядит так: дать агенту доступ ко всей базе данных и позволить разбираться в ней самому. В лучшем случае, предоставить схему базы данных.. «Модели сейчас неплохо пишут SQL, документация есть, что может пойти не так?»

А пойдёт вот что. Предположим, в схеме сорок таблиц, из них четыре похожи друг на друга названиями, две содержат исторические данные до миграции, в одной поле status кодируется числами, а в другой — строками. Да, есть документация (актуальная ли?), и агент успешно напишет запрос. Но соединять таблицы он начнет на свой лад, и не факт, что при этом не положит базу. Плюс насколько можно верить результату запроса агента, не видя как этот запрос был получен?

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

Плоская, без джойнов

Каждая строка — одно событие или одна агрегированная запись, все нужные атрибуты уже рядом. Соединять таблицы агенту больше не нужно.

Имена колонок читаются человеком

campaign_cost_rub вместо cst, is_qualified_lead вместо flag_2. Имя колонки — это основная подсказка, по которой агент выбирает поле. Аббревиатуры, понятные вашей команде, для него шум.

Комментарии к колонкам — бесплатная семантика

MCP-сервер передаёт агенту структуру объекта вместе с комментариями. Это самый дешёвый способ объяснить смысл поля, не раздувая системный промпт:

Практическая деталь: комментарии к колонкам живут на таблицах. Если витрина — обычное VIEW, семантику придётся передавать иначе. Например, создать отдельную таблицу с описанием колонок витрины.

Метрики посчитаны заранее

Не рассчитывайте, что агент правильно поделит одно на другое. Конверсия, CPL, ROMI, доля — всё, что имеет в компании конкретное определение, должно быть колонкой, а не результатом арифметики агента. Иначе вы получите два разных ROMI в двух разных диалогах, и оба будут «правильными» с точки зрения модели.

Даты — место, где ломается тише всего

«Вчера» — это какие сутки? По серверному UTC или по московскому времени? Неделя начинается с понедельника? Что такое «этот месяц» 1-го числа?

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

toDate(event_time, ’Europe/Moscow’) AS event_date

А в описании инструмента для агента фиксируйте правило: фильтровать период только по event_date. Это одна строка, которая закрывает целый класс расхождений.

Витрина повторяет датасет BI один в один

Самое важное требование во всём проекте, и оно не техническое.

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

Отсюда следует организационное правило: датасет и витрина меняются вместе, одним изменением. Как только они начнут расходиться, система тихо умрёт — не сломается, а просто начнёт врать.

2. Выставляем ограничения

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

Если у витрины несколько потребителей с разными правами доступа — добавляется row policy, чтобы разграничение жило в базе, а не в логике агента:

CREATE ROW POLICY client_isolation ON analytics.mart_marketing USING client_id = currentUser() TO ai_agent;

Кроме того, max_result_rows нужен не только для базы. Агент попытается положить результат в контекст чата. Тем самым запрос с миллионами строк нагрузит базу и съест не мало токенов ИИ.

3. Добавляем прозрачности

Число без происхождения не является ответом. Два механизма, которые стоят почти ничего, но многое дают.

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

Логировать всё: вопрос, сгенерированный SQL, результат, время. system.query_log с фильтром по пользователю ai_agent даёт вторую половину бесплатно:

Побочный эффект окажется не менее ценен, чем основной. Через месяц у вас есть карта того, что людей на самом деле интересует. Я обнаружил, что около четверти вопросов касалась среза, которого не было ни на одном дашборде — его добавили и в витрину, и в BI.

4. Как понять, что агент вообще отвечает правильно?

Это то, что отличает демо от системы, и то, что чаще всего пропускают.

Заведите набор из 20–30 эталонных вопросов с заранее известными правильными ответами. Реальные формулировки реальных пользователей, включая кривые: с опечатками, с жаргоном, без указания периода, с неоднозначным периодом.

Вопрос: Сколько лидов вчера?

Ожидаемо: 143

Вопрос: Конверсия по каналам за прошлую неделю

Ожидаемо: yandex_direct 4.2%, vk_ads 2.8%, seo 6.1%

Вопрос: Сколько мы слили на директ в этом месяце

Ожидаемо: 412 300 ₽ (проверка: понимает «слили» = расход, «директ» = yandex_direct)

Вопрос: А в прошлом?

Ожидаемо: 389 100 ₽ (проверка: удерживает контекст предыдущего вопроса)

Набор тестовых вопросов прогоняется после любого изменения витрины, смены модели и обновления MCP-сервера. Занимает это 15-30 минут, и один раз в квартал спасает от неприятных последствий.

Важный момент: тесты должны включать вопросы, на которые агент не должен отвечать. «Какая LTV у клиентов из Казани?» при отсутствии таких данных в витрине — правильный ответ здесь «этих данных нет», а не правдоподобное число. Проверять поведение на границе знаний не менее важно, чем внутри неё.

Что не стоит спрашивать у агента

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

1. Сложная атрибуция. Многоканальные модели атрибуции трафика, распределение весов между касаниями клиента в воронке — это вопрос методологии, а не одного запроса к базе. Обычно такие задачи решаются аналитиком через построение пайплайна.
2. Когортный анализ, retention, воронки с окнами. Требует многошаговой логики, где ошибка на любом шаге незаметна.
3. Красивые отчёты. Ответ в чате — это ответ на вопрос, а не дашборд. Конечно, сейчас AI может построить и дашборд, но это другая задача, выходящая за рамки чата.

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

Сколько времени уходит на разработку

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

1. Проектирование и сборка витрины, согласование с датасетом BI — основная часть работ (40% времени).
2. Подключение MCP, настройка доступов, лимитов, логирования — заметно меньше (20% времени).
3. Покрытие тестами и отладка — сопоставимо с настройкой (40% времени).

Также не забываем про операционные расходы — оплата токенов ИИ. Каждый вопрос пользователя — это передача ИИ описания структуры витрины, сам вопрос, сгенерированный SQL и результат запроса. Обычно на вопрос уходят центы. Если сравнить со стоимостью часа аналитика и, тем более, инженера, которые раньше раньше обрабатывали эти обращения, то агент заметно дешевле.

Когда это подходит, а когда нет

Подходит, если:

1. данные уже собраны в единой и быстрой базе данных (такой, как ClickHouse) и уже приведены в порядок;
2. есть очередь из «посчитайте мне» у аналитиков;
3. вопросы в основном однотипные и фактологические;
4. есть BI, с которым можно сверяться.

Не подходит, если:

1. данные сырые и разрозненные — агент не заменяет моделирование данных, он его требует;
2. основные вопросы аналитические, а не фактологические;
3. нет ресурса поддерживать согласованность витрины и BI — расхождение появится в первый же месяц.

Подведем итоги

Подключить AI-агента к ClickHouse через MCP — работа на несколько часов. Сделать так, чтобы его ответам можно было верить — это уже проект: работа над витриной, ограничениями, тестами.

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

Об авторе: Рустам Искендеров, эксперт по data-инжинирингу и внедрению AI в бизнес-аналитику.