Разработка AI-агента с доступом к базе данных
Языковая модель отвечает уверенно и гладко — и именно этим опасна. Она не видит актуальных данных компании: остатков, статусов заявок, условий в договорном реестре — и достраивает недостающее правдоподобными числами. Аналитик получает гладкий текст и заново сверяет каждую цифру с учётной системой, тратя на отчёт часы вместо минут.
Причина не в качестве модели, а в том, что её знание застыло на моменте обучения. Ручная вставка свежей выгрузки в запрос работает до первого роста реестра: цифры устаревают к моменту отправки, а объём данных не помещается в контекст. Агент и реальные данные остаются в разных мирах — и отчёт на устаревших числах уходит в работу.
Разработка AI-агента с доступом к базе меняет схему: агент сам запрашивает нужный срез и строит ответ на нём. Интеграция агента с хранилищем идёт отдельным слоем — схема описана как контракт, доступ ограничен ролями и только чтением, а ответ опирается на строки, которые можно перепроверить за минуту. Этот же слой решает, какие таблицы агент видит, а какие остаются закрытыми.
Дальше разбираем, как это закрывается: как описать схему для агента, чем ограничить выборку по строкам и ролям и как убедиться, что в ответе нет выдуманных чисел.
Что меняется в работе с данными после запуска агента
До запуска агента вопрос к данным — это цепочка: найти нужного человека, дождаться окна в его задачах, получить выгрузку в таблицу. Типовой срез уходил заказчику через часы, а то и к следующему дню, и к моменту ответа формулировка вопроса нередко менялась.
Агент подключается к PostgreSQL отдельной ролью только для чтения: он видит схемы, описания таблиц и агрегаты, но не может изменить ни строки. Ответ на типовой вопрос собирается за секунды — инженер задаёт его словами и получает и результат, и запрос, который этот результат посчитал, чтобы цифру можно было проверить, а не принять на веру.
Дальше меняется сама раскладка работы. Доля ручных выгрузок, которые делались ради разовых срезов, сокращается примерно втрое — остаются только те, где нужны данные из внешних систем. Нагрузка на аналитиков смещается с написания однотипных запросов на описание метрик и проверку логики агента, то есть на работу, которую нельзя автоматизировать.
Отдельный эффект — класс ошибок, который уходит вместе с ручным переносом. Копирование между таблицами и отчётами давало расхождения: разные фильтры периода, устаревший срез, потерянные строки при сведении. Когда все считают из одного источника и по одному определению метрики, расхождение между двумя отчётами перестаёт быть нормой.
Простой тоже теряет в цене. Дежурный инженер получает ответ на вопрос «что сломалось и с какого момента» без ожидания аналитика — время реакции сокращается с часов до минут, а разбор инцидента начинается с фактов, а не с догадок.
Способы подключения агента к источникам данных
Режим доступа к данным выбирают не по удобству подключения, а по тому, какой класс отказов допустим в проде. Агент формирует запрос динамически, поэтому профиль нагрузки заранее неизвестен: одна выборка без лимита на рабочей базе держит блокировки и тормозит запись из основного приложения. Отсюда базовое требование — ограничения прямого доступа: отдельная учётная запись только на чтение, лимит времени выполнения, запрет изменения схемы, белый список таблиц и журнал вызовов с текстом запроса и планом.
Четыре режима и чем они платят
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Прямое обращение к рабочей базе | Небольшая нагрузка, внутренний инструмент, лимит строк | Конкурирует с записью приложения, риск блокировок, доступ по исключению |
| Копия для чтения | Важна стабильность основной базы, задержка данных допустима | Отставание от основной базы; тяжёлые запросы всё равно нужно ограничивать |
| Витрина данных | Повторяющиеся сценарии: отчёты, сводки, регулярные агрегаты | Обновляется по расписанию, под новый вопрос витрину надо расширять |
| Промежуточный слой запросов | Нужны права по ролям и единые правила доступа | Слой надо поддерживать; нестандартные вопросы упираются в описанные метрики |
На практике режимы комбинируем: витрина закрывает частые вопросы, промежуточный слой — остальное, прямое чтение остаётся точечно с лимитом строк и времени. Логика агента при смене режима не переписывается — меняется только описание инструментов доступа.
Как мы строим агента: этапы инженерной работы
Агент с доступом к базе — это не «модель плюс запрос», а контур из прав, ограничений и проверок. Поэтому начинаем с данных и доступа, а не с формулировок вопросов: пока не ясно, на каких таблицах строятся ответы и кто вправе их читать, демонстрация остаётся нестабильной.
- Аудит данных. Разбираем состав таблиц, связи, дубликаты, пропуски и поля с чувствительными сведениями. Отмечаем, где источники расходятся и на что можно опираться без оговорок.
- Схема связей. Собираем карту сущностей и ключей, по которым агент соединяет таблицы. Спорные связи закрываем представлениями с заданной логикой — неверное соединение даёт правдоподобный, но ложный ответ.
- Разграничение прав. Агент работает отдельной учётной записью: только чтение и только разрешённые представления. Объём выборки и глубина истории ограничены, поэтому сбой не превращается в выгрузку всей базы.
- Инструменты агента. Для каждого сценария описываем допустимые выборки и поведение при нехватке данных. Агент отвечает по факту или сообщает о пробеле, а не достраивает ответ.
- Тестовый контур. Разворачиваем копию схемы с обезличенным срезом и прогоняем эталонные вопросы. Считаем долю верных ответов и время отклика, правим связи и описания.
- Проверка ответов агента. Сверяем ответы с расчётом аналитика и разбираем расхождения. Отдельно смотрим поведение на пустых выборках и уточняющих вопросах.
- Регламенты сопровождения. Передаём инструкции: что делать при изменении схемы, как добавлять правила и как откатывать изменения.
Что передаём заказчику: схемы, роли, регламенты
Проект с доступом к базе данных заканчивается не только работающим агентом. Мы передаём комплект, по которому ваша команда сможет сопровождать его сама: видеть, какие данные агент читает и куда пишет, кто меняет его поведение и как откатить изменение, если ответы перестали быть корректными.
- Схема потоков данных — путь от вопроса пользователя до строки в базе: какие таблицы и представления агент читает, куда пишет только после подтверждения человеком, где обращается к внешним сервисам.
- Политики доступа — отдельная учётная запись агента с правами только на чтение нужных представлений, перечень запрещённых полей, правила маскирования и журналирования обращений.
- Конфигурации поведения — шаблоны инструкций, ограничения на объём выборки, пороги, после которых агент останавливается и передаёт вопрос оператору.
- Документация агента — описанные роли и сценарии, каталог доступных действий, примеры корректных и ошибочных ответов с разбором причины.
- Регламент сопровождения — кто из вашей команды обновляет инструкции, с какой периодичностью пересматриваются права доступа и по каким событиям запускается проверка.
- Порядок обновления — как новая версия проходит проверку на контрольном наборе вопросов, что считается ухудшением качества и как вернуться к предыдущей версии.
- Разбор сбоев — журнал запросов и ответов, критерии инцидента, шаблон разбора и сроки реакции на обращение вашей команды.
Разбор проекта: агент с доступом к базе данных
Кейс внедрения агента: сервисная служба поставщика оборудования обрабатывала до 60 запросов в день — «сколько отгрузок по договору», «какие позиции на складе в минусе». Ответ собирался руками: сотрудник открывал три системы, писал запрос и сводил выгрузку в таблицу. Среднее время ответа — 40 минут.
| Этап | До | После |
|---|---|---|
| Подготовка ответа | 40 минут вручную | 4 минуты |
| Ручные выгрузки | 12 в неделю | 2 в неделю |
| Вопросы без участия человека | 0 % | 86 % |
| Актуальность данных | раз в сутки | задержка до минуты |
Узкие места на старте
Первым ограничением оказалась не модель, а описание схемы: в PostgreSQL без словаря колонок и связей агент строил запросы к несуществующим полям и выдавал правдоподобный, но неверный ответ. Второе — права: сервисная учётная запись имела лишние разрешения, доступ урезали до представлений с построчной фильтрацией по клиенту. Третье — дрейф структуры после миграций: расхождения ловил регрессионный набор из эталонных вопросов с ожидаемыми выборками, он прогоняется на каждом изменении.
Результат проекта
Время ответа упало с 40 минут до 4, ручные выгрузки сократились в шесть раз, 86 % обращений закрываются без человека. Оставшиеся 14 % — нестандартные выборки — уходят аналитику с готовым черновиком запроса, а не с нуля.
Чем отличается AI-агент от обычной интеграции с базой?
Обычная интеграция отвечает на вопрос, который известен заранее. Отчёт по расписанию берёт один источник и один набор условий — его пишут один раз, он работает предсказуемо и почти не нагружает базу вне окна запуска. Пока формулировки не меняются, жёсткий запрос проще в отладке: результат воспроизводим, а расхождение объясняется конкретной строкой.
Граница проходит там, где меняется сама постановка. Соединить данные из нескольких таблиц, уточнить фильтр по итогам прошлого разбора, добавить новый разрез — отчёт придётся переписывать: правка, проверка, выпуск. Агент отличается тем, что выбирает источник сам: получает описание схемы, назначение таблиц, связи и правила доступа, а дальше решает, к каким данным идти и как их соединить.
На сложных запросах разница видна отчётливее. Вопрос «сколько было заказов по регионам за квартал и как это соотносится с возвратами» агент разложит на два обращения и соберёт ответ целиком, тогда как отчёт закрывал бы только первую половину. Выбор источника при этом ограничен: учётная запись только на чтение, заданный список таблиц и представлений, предел на объём выборки и журнал — какой запрос ушёл, к чему и зачем.
Практический выбор прост. Если вопросы повторяются и известны заранее — жёсткий запрос по расписанию. Если формулировки меняются, а ответ собирается из нескольких таблиц и требует уточнений — агент. Их часто сочетают: агент закрывает разовые и составные вопросы, а регулярный отчёт остаётся стабильным по нагрузке.
Частые технические вопросы и сомнения
Точность цифр и объём прав агента проверяют до внедрения, а не после. Ниже — ответы на сомнения, которые звучат на этапе оценки: они касаются не модели, а того, как агент получает данные из базы и что ему разрешено делать.
Агент может выдать правдоподобную, но неверную цифру?
Числа агент не придумывает: он формирует запрос, агрегат считает сама база, а модель лишь пересказывает результат. Если запрос не прошёл, возвращается явное «данных нет», а не оценка на глаз. К каждому ответу приложен запрос, который инженер воспроизводит вручную.
Что будет, если структура базы изменится?
Между моделью и таблицами лежит описанная схема с явными связями. Переименование или удаление поля ломает маппинг, и агент на старте сообщает о расхождении вместо тихой подстановки чужого значения. Схему правит инженер, а не модель.
Какие права выдаются агенту?
Отдельная учётная запись: только чтение, только нужные представления, лимит на объём выборки и время выполнения. Запись и изменение структуры — вне её прав. На PostgreSQL это настраивается ролями и отдельной схемой с обезличенными представлениями.
Как быть с персональными данными?
Агент видит представления, где персональные поля замаскированы или заменены идентификатором. Доступ разграничен по ролям, обращения пишутся в журнал — видно, какой вопрос привёл к какой выборке.
Можно ли подключить несколько источников сразу?
Да: источники описываются в общем реестре, агент знает схему каждого и сопоставляет записи по ключам. Если один источник недоступен, в ответе указывается, какие данные получены, а какие нет.
Обсудим задачу: что уточнить перед стартом
Прежде чем называть сроки, нам нужны вводные по задаче, а не отдельный аудит: как устроен доступ к данным, какие вопросы агент должен закрывать и что считаем правильным ответом. Этого достаточно, чтобы вернуться с оценкой сроков и планом работ по этапам.
- Источники данных и способ доступа: какие системы, отдельная реплика или рабочая база, права только на чтение, какие таблицы и представления разрешены.
- Перечень вопросов: 15–20 реальных формулировок от сотрудников — видно, какая доля запросов типовая, а какая требует разбора человеком.
- Формат ответа: таблица, выжимка или график; допустимая задержка; когда агент обязан сказать «данных нет», а не догадываться.
- Чувствительные поля: что нельзя показывать ролям, нужно ли маскирование, разграничение доступа и журнал запросов.
- Точки входа: чат, внутренний портал, система заявок — и как в каждой устроена аутентификация.
- Профиль нагрузки: сколько сотрудников и запросов в день, работа в реальном времени или по расписанию.
- Рамки инфраструктуры: закрытый контур или облако, требования службы безопасности, кто отвечает за доступы.
На обсуждении задачи мы раскладываем работу на этапы — подключение к данным, слой проверки запросов, сценарии ответов, проверка на исторических вопросах — и на каждом фиксируем результат, после которого можно продолжать или остановиться. Приложите схему доступа и список вопросов — вернёмся с оценкой сроков и планом старта проекта.
