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

Представьте: коммерческий директор хочет узнать конверсию из pending в delivered за последние 30 дней по сегментам клиентов. Вместо того чтобы писать SQL-запрос или ждать отчёт от BI-специалиста, он задаёт вопрос на естественном языке. Через три минуты ответ готов. Это не фантастика, а реальный результат внедрения AI-агента с доступом к базе данных (Text-to-SQL).

Мы разрабатываем таких агентов — 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 (из нашей практики)

Задача: аналитический ассистент для коммерческого директора — анализ продаж, 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 минуты
• Accuracy SQL (вопросы → корректный SQL): 87%
• Типичные ошибки: неверные 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""" 

Что входит в работу

Сравнение: готовые решения 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-агент с доступом к БД ускорит работу вашей команды.