Мы долго пытались сделать так, чтобы языковая модель могла отвечать по нашим рабочим данным, и в итоге прошли путь от примитивных выгрузок в Excel до связки на открытой модели, MCP-протокола и

Мы долго пытались сделать так, чтобы языковая модель могла отвечать по нашим рабочим данным, и в итоге прошли путь от примитивных выгрузок в Excel до связки на открытой модели, MCP-протокола и OLAP-кубов. Делюсь тем, что не сработало, что подошло и на каком стеке мы остановились.

Отправная точка знакома каждому, кто пробовал обсуждать с ИИ цифры: чтобы задать один вопрос по данным, нужно вручную выгрузить Excel, приложить файл в чат и заново объяснить модели, что лежит в столбцах, за какой период срез и как считается метрика. Следующий вопрос — и весь цикл повторяется. Задача была разорвать этот круг: дать модели постоянный инструмент подключения к данным, чтобы она сама читала схему кубов, измерения, меры и периоды и отвечала точными числами, а не правдоподобным текстом.

Отсюда три требования, которые определили весь выбор инструментов:

— прямой доступ: модель сама ходит в таблицы и сама читает схему, без ручных выгрузок и пересказа;

— точность: в ответе допустимы только числа, реально полученные из данных, поэтому нужен инструмент, который считает, а не угадывает;

— приватность: данные не уходят за периметр компании, значит облачные API с чужими дата-центрами отпадают.

Первым делом нужно было решить, на чём будет работать сама модель. Требование приватности исключило облачные чат-модели, поэтому выбрали открытую модель с весами, которые скачиваются один раз и дальше живут внутри инфраструктуры. Бонусом стало отсутствие платы за токены на этапе эксперимента, когда число запросов заранее не ограничено.

Для запуска взяли Ollama. Она не требует отдельной инженерной подготовки, поднимает модель одной командой и сразу отдаёт наружу OpenAI-совместимый HTTP API. Это удобно: такой API «из коробки» понимают и AnythingLLM, и LibreChat, и любой другой клиент под формат OpenAI. На Linux и macOS установка — одной командой, на Windows есть обычный установщик. Модель скачивается через `ollama pull`, дальше её можно проверить запросом к `http://localhost:11434/v1/`. Из доступных моделей остановились на Gemma: открытые веса, есть версии разного размера под разное железо, включая облегчённые для машин без выделенной видеокарты. Для первой проверки взяли самую лёгкую — `gemma4:e4b`.

Но модель, которая просто генерирует текст, — ещё не решение. Нужен был способ подключить её к живым данным в OLAP-кубах.

Сразу отмели классический RAG: нарезать данные на эмбеддинги и подсовывать модель «похожие по смыслу» куски не подходит для точных цифр. «Похожий по смыслу» фрагмент — это не то же самое, что точное число за конкретный период по конкретной таблице. Поэтому выбрали MCP — Model Context Protocol. Он даёт модели набор инструментов, которые она может вызывать сама и получать точный результат, а не похожий фрагмент из индекса.

Источником данных выступил XLTable — наш семантический слой OLAP и XMLA-совместимый сервер, которым мы пользуемся поверх ClickHouse. Аналитики работают не с сырыми таблицами, а с готовыми кубами. У XLTable есть MCP-сервер, то есть готовый мост между моделью и кубами. Дописывать ничего не пришлось. Он даёт модели набор инструментов:

— `list_databases()` — список баз, если их несколько;

— `list_cubes(database)` — список OLAP-кубов;

— `describe_cube(database, cube)` — схема куба: измерения, уровни иерархии, меры;

— `query_cube(database, context)` — агрегирующий запрос с группировкой, агрегацией и фильтрами.

Если источник данных не XLTable, принцип переносится: MCP-сервер — это процесс, который отдаёт модели набор вызываемых функций. Можно написать минимальный аналог на Python, пометив функции декоратором `@mcp.tool()`. Точный синтаксис зависит от версии SDK, но роли те же: разведка схемы и запрос данных.

Модель есть, доступ к данным через MCP есть. Оставался интерфейс, чтобы попробовать всё это в чате, не тратя время на написание своего фронтенда. Для первой проверки взяли AnythingLLM — простое десктопное приложение с чатом. Установка в несколько кликов, Ollama подключается как источник модели указанием адреса локального эндпоинта, а MCP-сервер добавляется в настройках: путь к процессу — и инструменты XLTable уже видны модели. Настройка заняла пару шагов: поставить AnythingLLM, указать Ollama с адресом `http://localhost:11434` и модель, затем в разделе Managed Skills / MCP добавить свой сервер. Дальше можно открыть чат и задать вопрос — модель сама вызывает инструмент MCP и отвечает, опираясь на результат.

Связка заработала, и это подтвердило жизнеспособность архитектуры «открытая модель + MCP-сервер над кубами». Но сразу стали видны ограничения AnythingLLM. Главное — концептуальное: это всё-таки чат над источниками, а нам нужен агент. Не собеседник, который иногда дёргает инструмент, а исполнитель, который сам строит цепочку вызовов: уточнить схему куба, запросить данные, посчитать, собрать дашборд и выдать готовый результат. Конкретно не хватало гибкости системного промпта, контроля над порядком вызова инструментов и обработкой ошибок, возможности генерировать визуальные артефакты прямо в ответе и удобной работы с несколькими эндпоинтами моделей одновременно. Всё это упиралось в исходные требования к точности, поэтому продолжать на AnythingLLM смысла не было.

Как только прототип подтвердил работоспособность, локальный запуск на одной личной машине стал узким местом. Модель занимала ресурсы, была недоступна команде, а эндпоинт не гарантированно находился на месте, когда он нужен. Поэтому Ollama переехала на отдельный сервер с постоянным адресом. Локальную «песочницу» оставили для быстрых экспериментов.

На сервере стояла виртуальная машина с GPU — Intel Ice Lake с NVIDIA Tesla T4, достаточная для одной модели. Там же запустили две версии модели — лёгкую `e4b` и более тяжёлую `12b`, и прогнали одинаковый тест с флагом `-verbose`, чтобы увидеть время загрузки и скорость генерации. Сравнение подтвердило: 12b увереннее держит протокол и точнее вызывает инструменты. Лёгкую версию с сервера убрали через `ollama rm`, а дальше настраивали сервер под 12b.

Под задачу работы с данными завели отдельную донастроенную версию модели — `gemma4-12b-xltable`. В её конфигурации через Modelfile зафиксировали расширенный контекст, низкую температуру и ограниченные top_p/top_k, чтобы модель меньше «фантазировала» по стилю генерации. Точность закладывали не только в текст системного промпта, но и в параметры инференса. Практически это делается файлом Modelfile с параметрами вроде `num_ctx`, который подбирается среди 16384, 24576 и 32768 в зависимости от памяти сервера. Затем командой `ollama create` собирается именованная модель, и именно это имя указывается в клиентах.

В итоге мы остановились на связке: открытая модель Gemma4, запущенная через Ollama на отдельном сервере с GPU, MCP-сервер XLTable как мост к OLAP-кубам и интерфейс, который уже строится не как чат, а как агент с возможностью выстраивать цепочки вызовов и возвращать готовые результаты. Теперь вместо выгрузки Excel и пересказа структуры данных можно просто спросить — и модель сама сходит в куб, уточнит схему, запросит нужные агрегаты и вернёт точное число.

А вы уже пробовали давать своей модели доступ к данным через MCP? Или до сих пор каждый раз выгружаете Excel и объясняете заново, что лежит в столбцах?

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: