Реализация AI-агента с доступом к базе данных в мобильном приложении
Text-to-SQL — старая задача, но с LLM она стала достаточно надёжной для продакшена. Пользователь спрашивает «покажи мои расходы за прошлый месяц по категориям», агент переводит это в SQL-запрос, выполняет, форматирует результат. Без написания отдельного экрана аналитики, без фиксированных фильтров.
Почему Text-to-SQL на мобильном — отдельная задача
Прямой доступ мобильного приложения к продуктовой БД — плохая идея. Даже read-only. Правильная архитектура: мобильный клиент → бэкенд API с агентом → БД. Бэкенд валидирует сгенерированный SQL, ограничивает набор доступных таблиц, контролирует права пользователя.
На клиенте используется либо локальная БД (SQLite через Room на Android, Core Data / GRDB на iOS) для офлайн-данных приложения, либо агент работает на сервере и клиент получает готовые данные.
Как научить модель вашей схеме БД
Модель не знает вашу схему. Нужно передавать её в системном промпте или через инструмент get_schema. Не вываливайте весь DDL на 200 таблиц — берите только релевантные. Для приложения с личными финансами достаточно 5–8 таблиц.
-- Пример схемы для промпта (упрощённая)
CREATE TABLE transactions (
id SERIAL PRIMARY KEY,
user_id INTEGER NOT NULL,
amount DECIMAL(10,2) NOT NULL, -- отрицательное = расход
category VARCHAR(50), -- 'food', 'transport', 'entertainment'
description TEXT,
created_at TIMESTAMP DEFAULT NOW()
);
В системный промпт добавляем: «Ты генерируешь SQL-запросы ТОЛЬКО для SELECT. Никогда не используй INSERT, UPDATE, DELETE, DROP. Все запросы должны содержать WHERE user_id = :user_id.»
Ограничение через промпт — первый слой защиты. Второй слой — валидация на сервере: парсим AST сгенерированного SQL (библиотека sql-parser или pg_query для PostgreSQL), проверяем тип запроса и список таблиц.
Room и агент: локальная БД на Android
Если агент работает с локальными данными приложения через Room:
// Интерфейс инструмента для агента
class DatabaseTool(private val db: AppDatabase) {
suspend fun executeQuery(sql: String): String {
return try {
// Только SELECT через SupportSQLiteDatabase
val cursor = db.openHelper.readableDatabase.query(sql)
cursor.toJsonArray().toString()
} catch (e: Exception) {
"""{"error": "${e.message}"}"""
}
}
}
SupportSQLiteDatabase.query() принимает сырой SQL — удобно для агента. Room DAO здесь не подходит: он требует фиксированных запросов на этапе компиляции.
Важный момент: Room по умолчанию не разрешает raw queries в основном потоке. Всё должно быть внутри suspend fun или withContext(Dispatchers.IO).
Форматирование результата
Агент получил строки из БД — нужно вернуть их пользователю в читаемом виде, а не как JSON-массив. Передаём результат запроса обратно модели с инструкцией отформатировать:
Tool result: [{"category":"food","total":"-15420"},{"category":"transport","total":"-8300"}]
→ Модель форматирует: "За прошлый месяц вы потратили 154.20 BYN на еду и 83.00 BYN на транспорт"
Для числовых данных хорошо работает запрос к модели на создание Markdown-таблицы — её легко отрендерить на мобильном через любой Markdown-парсер (Markwon на Android, AttributedString + кастомный рендер на iOS, flutter_markdown на Flutter).
Безопасность: что обязательно
- Параметризованные подзапросы там, где возможно (даже для SELECT)
- Whitelist таблиц и колонок, к которым разрешён доступ
- Лимит результатов:
LIMIT 1000обязателен в валидаторе - Таймаут на выполнение запроса (PostgreSQL:
SET statement_timeout = '5s') - Логирование всех сгенерированных запросов для аудита
Этапы и сроки
Анализ схемы БД и определение доступных таблиц → разработка системного промпта с описанием схемы → реализация SQL-валидатора на бэкенде → интеграция агентного цикла → форматирование результатов → тестирование на разнообразных пользовательских запросах → мониторинг качества генерации.
Для локальной SQLite/Room с 3–5 таблицами — 2–3 недели. Для серверного агента с PostgreSQL, валидатором и сложной схемой — 4–6 недель.