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