Архитектура агентного ИИ: Как подключить языковую модель к корпоративным данным без утечек

# Как мы искали способ подключить ИИ к своим данным

Интеграция искусственного интеллекта в рабочие процессы часто сталкивается с парадоксом: чем сложнее задача, тем выше требования к точности данных и приватности. Мы искали способ подключить языковую модель к внутренним данным, чтобы она могла отвечать на вопросы фактами, а не домыслами. Этот поиск привел нас к отказу от облачных API в пользу локальных решений, выбору открытой архитектуры на базе Ollama и внедрению протокола MCP для взаимодействия с аналитическими кубами.

От RAG к MCP: почему контекста недостаточно

Классический подход к подключению данных к ИИ — это RAG (Retrieval-Augmented Generation). Модель получает в контекст фрагменты данных, похожие по смыслу на вопрос пользователя. Однако для финансовой отчетности или аналитики такой подход имеет критический недостаток: он возвращает текст, а не точные числа.

Например, если спросить: «Каковы продажи по магазину X за июль?», RAG может просто найти текст в документе, где упоминается эта цифра. Но если данные изменились в базе, а документ не обновлен, ИИ скажет правду, основанную на устаревшей информации. Кроме того, RAG не умеет выполнять агрегации.

Мы выбрали протокол MCP (Model Context Protocol). В отличие от RAG, MCP предоставляет модели не просто текст, а набор инструментов (function calling). Модель видит доступные методы, например query_cube(database, cube), и сама вызывает их с нужными параметрами. Это позволяет ей работать как аналитик: сначала запросить схему (измерения и меры), затем выполнить точный расчет и вернуть результат. Мы использовали MCP-сервер для нашего продукта XLTable, который дает доступ к готовым OLAP-кубам.

*Примечание редактора:* Важно разделять заявления компании и технические факты. В данном случае компания заявляет, что их продукт XLTable идеально подходит под протокол MCP. Фактически же, любой MCP-сервер, реализующий стандартные интерфейсы list_cubes и query_cube, будет работать с любым клиентом на базе MCP, независимо от того, называет ли он себя XLTable или чем-то иным.

Выбор стека: Gemma 4 и Ollama в локальном контуре

Требование приватности исключает облачные API. Данные не должны покидать периметр компании, ни в виде выгрузок, ни в виде промптов. Мы остановились на локальном запуске открытой модели.

Инструментом для управления локальными инстансами стала Ollama. Она позволяет запустить модель одной командой и предоставляет OpenAI-совместимый HTTP API. Это упрощает подключение любых клиентов.

В качестве модели мы выбрали Gemma 4. Среди открытых вариантов она предлагает баланс между качеством и потреблением ресурсов. Для экспериментов использовалась версия gemma4:e4b (4 миллиарда параметров), а в финальной архитектуре на сервере развернута версия с 12 миллиардами параметров.

Для локального развертывания используются следующие команды (на Linux/macOS):

```bash # Установка Ollama curl -fsSL https://ollama.com/install.sh | sh

# Скачивание модели ollama pull gemma4:e4b

# Проверка доступности API curl http://localhost:11434/v1/models ```

Переход к агентной архитектуре

Первый прототип на базе десктопного приложения AnythingLLM подтвердил работоспособность связки: модель могла видеть инструменты MCP и вызывать их. Однако AnythingLLM позиционировался как чат-интерфейс, где ИИ — собеседник. Нам требовался агент.

Агент отличается тем, что он строит цепочку действий самостоятельно: запрашивает схему куба, фильтрует данные, считает метрики и формирует ответ строго по протоколу. Для этого требовалась платформа, поддерживающая жесткие системные промпты и контроль над порядком вызовов инструментов. Локальная установка Ollama на отдельном сервере с GPU (в нашем случае NVIDIA Tesla T4) стала следующим шагом. Это позволило распределить нагрузку, сделав модель доступной для команды, а не только для владельца ноутбука.

Настройка серверной инфраструктуры

Перенос модели на сервер потребовал тонкой настройки Ollama для обеспечения стабильности и безопасности.

Кастомная конфигурация модели

Чтобы снизить «галлюцинации» (вероятность выдуманных фактов), мы создали кастомную модель gemma4-12b-xltable с фиксированными параметрами генерации: расширенным контекстом (num_ctx) и ограниченным пространством поиска (top_p, top_k). Это зашифровывается в файл Modelfile, который компилируется командой ollama create.

Система управления ресурсами

Серверная модель требует больших ресурсов. Чтобы избежать простоя и повторных загрузок весов (что занимает значительное время для крупных моделей), мы настроили окружение через переменные systemd:

* OLLAMA_HOST=127.0.0.1:11434 — ограничивает доступ только локальной сети (безопасность). * OLLAMA_KEEP_ALIVE=-1 — удерживает модель в памяти навсегда после загрузки. * OLLAMA_LOAD_TIMEOUT=10m — увеличивает время ожидания загрузки.

Для автоматической загрузки модели сразу после запуска сервера создан отдельный сервис ollama-warmup.service, который выполняет пустой запрос для «прогрева» весов.

Реверс-прокси как щит

Несмотря на настройки Ollama, публичный доступ к эндпоинту был заблокирован. Доступ возможен только через nginx, работающий как реверс-прокси. Он проверяет заголовок Authorization и передает запрос на внутренний порт Ollama только при наличии валидного API-ключа. Это дополнительный уровень защиты данных.

Итоговая архитектура

Мы построили систему, где: 1. Данные хранятся в OLAP-кубах (XLTable). 2. Логика взаимодействия реализована через MCP-сервер, предоставляющий инструменты для чтения данных. 3. Инференс выполняется локальной моделью Gemma 4 на управляемом сервере. 4. Безопасность обеспечена изоляцией сети, ключами аутентификации и отсутствием передачи данных во внешние облака.

Этот стек позволяет реализовать сценарии, где ИИ не просто генерирует текст, а проводит реальные расчеты, опираясь на актуальные корпоративные данные, что критически важно для бизнес-аналитики.

*Технические детали реализации, включая примеры кода MCP-сервера на Python и конфигурационные файлы, доступны в полной версии статьи на Хабр.*