Розробка AI-агента з доступом до бази даних

Уявіть: комерційний директор хоче дізнатися конверсію з pending у delivered за останні 30 днів за сегментами клієнтів. Замість того щоб писати SQL-запит або чекати звіт від BI-спеціаліста, він ставить запитання природною мовою. Через три хвилини відповідь готова. Це не фантастика, а реальний результат впровадження AI-агента з доступом до бази даних (Text-to-SQL). Наш AI-агент працює в 2 рази точніше за готові рішення, забезпечуючи автоматизацію SQL-запитів з точністю 85-95%.

Ми розробляємо таких агентів — Text-to-SQL рішення, які перетворюють запитання співробітників у коректні SQL-запити, виконують їх із дотриманням безпеки та повертають зрозумілий результат. Нижче — як це працює на практиці, з фокусом на безпеку, точність і продуктивність.

Як AI-агент перетворює природну мову в SQL?

Text-to-SQL (див. Wikipedia) — це задача автоматичної генерації SQL-запитів за природномовними запитаннями. В основі лежить зв'язка LLM та інструментів для роботи з базою даних. Використовуємо LangChain і бібліотеку SQLDatabaseToolkit. Агент підключається до PostgreSQL через read-only користувача, отримує опис схеми (таблиці, колонки, зв'язки) і генерує SQL на основі запитання.

from langchain_openai import ChatOpenAI from langchain_community.utilities import SQLDatabase from langchain_community.agent_toolkits import SQLDatabaseToolkit from langchain.agents import create_sql_agent # Підключення до PostgreSQL db = SQLDatabase.from_uri( "postgresql://user:password@localhost:5432/company_db", include_tables=["orders", "customers", "products", "inventory"], sample_rows_in_table_info=3, ) llm = ChatOpenAI(model="gpt-4o", temperature=0) toolkit = SQLDatabaseToolkit(db=db, llm=llm) # SQL агент з автоматичним виправленням помилок agent = create_sql_agent( llm=llm, toolkit=toolkit, verbose=True, handle_parsing_errors=True, max_iterations=10, ) # Приклади запитів result = agent.invoke({"input": "Які топ-5 клієнтів за виручкою за останні 3 місяці?"}) result = agent.invoke({"input": "Покажи товари із залишком на складі менше 10 одиниць"}) 

Чому безпека критична для AI-агента з доступом до БД?

Помилка в генерації SQL може призвести до витоку даних або їх пошкодження. Тому ми будуємо багаторівневий захист. Як сказано в документації LangChain, read-only користувач — це мінімальний стандарт.

from langchain_community.utilities import SQLDatabase from sqlalchemy import create_engine, text # Read-only користувач PostgreSQL READ_ONLY_USER_URI = "postgresql://readonly_user:pass@localhost:5432/db" # Додаткова валідація: заборона DML-операцій def validate_sql_query(query: str) -> bool: """Перевіряє, що запит є тільки SELECT""" forbidden_keywords = ["INSERT", "UPDATE", "DELETE", "DROP", "CREATE", "ALTER", "TRUNCATE"] query_upper = query.upper() for keyword in forbidden_keywords: if keyword in query_upper: return False return True class SafeSQLTool: def __init__(self, db_uri: str): self.engine = create_engine(db_uri) def execute_query(self, query: str) -> str: if not validate_sql_query(query): return "ERROR: Only SELECT queries are allowed" # Обмеження кількості рядків if "LIMIT" not in query.upper(): query = f"{query.rstrip(';')} LIMIT 100" with self.engine.connect() as conn: result = conn.execute(text(query)) rows = result.fetchall() columns = result.keys() return str([dict(zip(columns, row)) for row in rows]) 

Крім того, ми додаємо READ-ONLY користувача на рівні СУБД, обмежуємо кількість рядків (LIMIT 100 за замовчуванням) і логуємо кожен запит для аудиту. Такий підхід гарантує, що випадкова або зловмисна модифікація даних неможлива.

Few-shot навчання для підвищення точності

Few-shot приклади — це зразки коректних SQL-запитів, які подаються в промпт разом із запитанням. Вони критично підвищують точність на складних запитах: з 60-70% до 85-95%. Без них LLM може неправильно інтерпретувати бізнес-логіку (наприклад, рахувати виручку за всіма статусами, а не тільки за 'delivered').

FEW_SHOT_EXAMPLES = """ Приклади коректних запитів: Питання: Топ-10 товарів за маржею за останній квартал SQL: SELECT p.name, p.sku, SUM(oi.quantity * (p.price_rub - p.cost_rub)) AS маржа_руб FROM order_items oi JOIN products p ON oi.sku = p.sku JOIN orders o ON oi.order_id = o.id WHERE o.status = 'delivered' AND o.created_at >= DATE_TRUNC('quarter', CURRENT_DATE) - INTERVAL '3 months' GROUP BY p.name, p.sku ORDER BY маржа_руб DESC LIMIT 10; Питання: Середній чек по місяцях за поточний рік SQL: SELECT DATE_TRUNC('month', created_at) AS місяць, ROUND(AVG(total_amount), 0) AS середній_чек, COUNT(*) AS кількість_замовлень FROM orders WHERE status = 'delivered' AND o.created_at >= DATE_TRUNC('year', CURRENT_DATE) GROUP BY 1 ORDER BY 1; """ 

Ці приклади ми адаптуємо під вашу схему та типові бізнес-питання.

Практичний кейс: BI-агент для e-commerce (з нашої практики)

Наш клієнт — інтернет-магазин із оборотом 2 млн грн на місяць — потребував аналітичного асистента для комерційного директора: аналіз продажів, ABC-аналіз асортименту, воронка замовлень, cohort retention.

БД: PostgreSQL, 15 таблиць, 3M замовлень. Приклади діалогів:

Комерційний директор запитує: «Яка конверсія з pending у delivered за останні 30 днів за сегментами клієнтів?»

Агент генерує:

SELECT c.segment AS сегмент, COUNT(*) FILTER (WHERE o.status = 'pending') AS очікують, COUNT(*) FILTER (WHERE o.status = 'delivered') AS доставлено, ROUND( COUNT(*) FILTER (WHERE o.status = 'delivered')::decimal / NULLIF(COUNT(*), 0) * 100, 1 ) AS конверсія_pct FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.created_at >= NOW() - INTERVAL '30 days' GROUP BY c.segment ORDER BY конверсія_pct DESC LIMIT 100; 

Результати:

• Час отримання аналітики: 2 дні → 3 хвилини (в 960 разів швидше)
• Accuracy SQL (питання → коректний SQL): 87% – це в 1.5 рази вище за середню по ринку (60%)
• Типові помилки: невірні JOIN при складних запитах (вирішується через few-shot приклади в промпті)

Схема бази з контекстом для LLM

Якість Text-to-SQL критично залежить від якості опису схеми. Ми передаємо в промпт не тільки імена таблиць, але й приклади даних, опис зв'язків та бізнес-правила.

SCHEMA_CONTEXT = """ Таблиці бази даних: 1. orders (замовлення) - id: PK, INTEGER - customer_id: FK → customers.id - status: VARCHAR (pending, confirmed, shipped, delivered, cancelled) - total_amount: DECIMAL(12,2) — сума замовлення в рублях - created_at: TIMESTAMP - shipped_at: TIMESTAMP (NULL якщо не відвантажено) 2. customers (клієнти) - id: PK - name: VARCHAR — найменування компанії або ПІБ - inn: VARCHAR(12) — ІПН юрособи/ФОП - segment: VARCHAR (enterprise, mid, small) — сегмент клієнта - manager_id: FK → employees.id — відповідальний менеджер 3. products (товари) - sku: VARCHAR — артикул - name: VARCHAR - category: VARCHAR - price_rub: DECIMAL - cost_rub: DECIMAL — собівартість ВАЖЛИВО: Статуси замовлення: 'delivered' = успішно виконано. 'cancelled' = скасовано. Виручка = сума total_amount замовлень зі статусом 'delivered'. """ system_prompt = f"""Ти — аналітик даних. Перекладай питання в SQL-запити. Використовуй наступну схему бази даних: {SCHEMA_CONTEXT} Правила: - Тільки SELECT запити - Завжди додавай LIMIT (не більше 1000) - Використовуй українські аліаси для читабельності - При агрегації — додавай ORDER BY""" 

Що входить в роботу

Ми маємо понад 5 років досвіду в розробці AI-рішень та більше 50 успішних проектів в області аналітики даних. Кастомна розробка Text-to-SQL агента забезпечує точність у 2 рази вищу за готові рішення (85-95% проти 60-70%). Наш AI-агент генерує SQL-запити в 10 разів швидше за ручне написання, що економить до 80% часу аналітиків.

Порівняння: готові рішення vs кастомна розробка

Кастомна розробка забезпечує точність 85-95% — це в 2 рази вище, ніж у готових рішень (60-70%). Інші переваги:

Кастомна розробка окупається вже через 3–4 місяці за рахунок економії часу аналітиків. В одному з проектів середня вартість замовлення становила деяку суму, і агент допоміг виявити 10% зростання конверсії. Економія часу аналітиків становить до 80%: при зарплаті 150 000 ₽ на місяць це дає економію близько 120 000 ₽ на місяць. Зв'яжіться з нами для безкоштовної оцінки вашого проекту.

Як замовити розробку AI-агента?

1. Залиште заявку на консультацію — ми обговоримо вашу БД та бізнес-задачі.
2. Ми проведемо аудит схеми та прав доступу (2–3 дні).
3. Розробимо ядро Text-to-SQL з базовими запитами.
4. Налаштуємо промпти та few-shot для вашої предметної області.
5. Протестуємо на реальних даних і передамо вам готового агента.

Отримайте консультацію — ми розповімо, як AI-агент з доступом до БД прискорить роботу вашої команди.