Ollama и локальный helpdesk-ассистент: от одной команды до рабочего прототипа

Когда мы в августе разворачивали Llama 2 на A10G, то потратили добрый день на сборку wheel-пакетов, борьбу с версиями CUDA и перенос весов через бастион. Всё это работало, но порог входа оставался высоким - не каждая команда готова к такому DevOps-упражнению перед тем, как вообще понять, нужно им это или нет.

Ollama появилась тихо - один бинарник, ollama run llama2, и модель отвечает через тридцать секунд. Без virtualenv, без pip install accelerate, без разбора транзитивных зависимостей в изолированной сети. Понятно, что это не волшебство - веса всё равно скачиваются, рантайм всё равно есть. Но разница в ощущениях между «собери стек из пяти компонентов» и «одна команда» - вполне реальная, особенно если задача стоит сначала показать прототип бизнесу, а потом уже думать о production.

У нас как раз оказался такой случай.

Задача: helpdesk по инфраструктуре

Один из клиентов пришёл с запросом: есть команда поддержки из нескольких человек, есть корпоративная wiki с описанием инфраструктуры, и есть набор типовых вопросов, которые приходят в helpdesk каждую неделю. «Как сбросить пароль в AD», «какой адрес у DNS-сервера в сегменте X», «как подключиться к VPN из-за рубежа» - всё это есть в документах, но люди всё равно пишут в чат.

Идея: поставить LLM-ассистент, который отвечает на такие вопросы, не отправляя содержимое запросов и документов в облако. Данные чувствительности не запредельной, но компания принципиально не хочет, чтобы вопросы про внутреннюю инфраструктуру уходили к третьей стороне. Требование понятное.

RAG для полноценного охвата документов - это отдельная история, и мы её пока оставили на следующий этап. Первый шаг - просто запустить модель локально и посмотреть, как она отвечает на вопросы без дополнительного контекста. Что модель знает сама по себе - уже полезно для части вопросов.

Как запустили

Машина у клиента - физический сервер с одной NVIDIA RTX 4090 24 GB, Rocky Linux 9. Не DMZ, не закрытый сегмент - обычный сервер в корпоративной сети. Именно поэтому Ollama здесь органична: она рассчитана на быстрый старт, а не на параноидально изолированный контур.

Установка:

curl -fsSL https://ollama.ai/install.sh | sh
ollama run llama2

Веса 13B в формате GGUF Ollama тянет сама при первом запуске - около 8 GB. На корпоративном канале это несколько минут. Дальше модель отвечает локально, никакого трафика наружу в процессе инференса.

Ollama выставляет REST API на localhost:11434 с эндпоинтом /api/generate - достаточно, чтобы прикрутить простой веб-интерфейс или бот. Мы взяли open-webui - тоже Docker-контейнер одной командой, даёт приличный чат-интерфейс поверх Ollama API. Клиентам показывать сразу.

Что получилось на реальных вопросах

Протестировали на двух десятках типовых вопросов из их helpdesk-очереди. Вопросы делятся на три категории:

• Общие технические - «как проверить сертификат SSL через openssl», «что такое MX-запись», «почему DHCP не выдаёт адрес». Здесь Llama 2 справляется хорошо - это общие знания, в весах есть.
• Инфраструктурно-специфичные - «какой у нас адрес корпоративного DNS», «как называется сервер резервного копирования». Здесь без RAG модель просто не знает - и говорит об этом, что честно.
• Процедурные - «как завести заявку на доступ к системе X», «кто согласовывает командировки». Частично работает, если процедура типовая и модель знает примерный паттерн.

Итог: примерно треть вопросов из реальной очереди модель закрывает сама. Не идеально, но уже что-то - особенно учитывая, что это нулевой этап без единого корпоративного документа в контексте.

Русский язык у Llama 2 всё ещё слабоват. Понимает хорошо, отвечает терпимо, но периодически уходит в английский на середине ответа. Для техподдержки это раздражает пользователей сильнее, чем неточный ответ.

Сравнение с ручным стеком

В августе мы строили всё вручную: llama.cpp, llama-cpp-python, свой HTTP-эндпоинт. Это давало больше контроля - можно подкрутить параметры инференса, выбрать конкретную версию GGUF, настроить тонкости. Но на старте всё это - лишние часы.

Ollama жертвует этим контролем в пользу простоты. Параметры модели настраиваются через Modelfile, но интерфейс менее гибкий, чем прямая работа с llama.cpp. Для прототипа и для команды без глубокой экспертизы в ML - нормальный трейдофф. Для production с требованиями к изолированной сети - надо смотреть внимательнее, потому что механизм обновления моделей в Ollama пока завязан на их реестр.

Куда дальше

Прототип показали клиенту - реакция положительная. Следующий шаг, который уже обсуждаем, это RAG поверх корпоративной wiki: загнать документы в векторную БД, при запросе доставать релевантные фрагменты и передавать в контекст модели. Это должно закрыть ту самую «инфраструктурно-специфичную» треть вопросов, где модель сейчас расписывается в незнании.

Пока что у нас есть рабочий прототип локального ассистента, который поднимается за полчаса, не отправляет данные наружу и отвечает на треть реальных запросов helpdesk без дополнительной настройки. Для нулевой итерации - вполне.