Большую языковую модель можно скачать с Hugging Face, развернуть на сервере с GPU и отправить ей первый запрос. Технически LLM уже работает: получает текст на вход и генерирует ответ. Но до готового бизнес-сервиса еще далеко.
Пользователю нужен интерфейс. Приложению — API. Модели нужно передавать контекст и корпоративные данные. Доступ к сервису необходимо ограничивать, действия — контролировать, запросы — логировать, а ошибки — обрабатывать.
Чтобы модель делала что-то полезное для бизнеса, ей потребуется передать контекст, подключить внешние или внутренние системы и описать правила работы с ними.
Все эти компоненты вокруг модели часто называют обвязкой, или harness.
В этой статье разберемся, зачем она нужна, из каких частей может состоять и почему выбор самой LLM — только один из этапов создания ИИ-сервиса.
По данным исследований, из 33 корпоративных ИИ-пилотов до продакшена в среднем доходят только четыре — 88% остаются экспериментом, и модель здесь редко оказывается узким местом. В некоторых исследованиях еще сравнивают так: модель — двигатель, harness — вся машина.
У двигателя самого по себе нет тормозов, руля и ограничителя скорости. Без обвязки, которая решает, кому доверять, что разрешать и когда передать решение человеку, агент может зациклиться на неудачном запросе, забыть про ограничения доступа и допустить несанкционированное вмешательство в логику работы
Разница между LLM и ИИ-сервисом
На вход модель получает последовательность токенов и последовательно генерирует новые токены в ответ. Она не знает, кто отправил запрос, имеет ли пользователь право видеть запрошенные данные, куда сохранить результат и можно ли вообще выполнять предложенное действие.
Даже история диалога не является для модели какой-то встроенной «памятью». Приложение должно сохранить нужные сообщения и при следующем запросе снова передать их модели в контексте.
Поэтому между работающей LLM и готовым сервисом остается довольно большой слой. А вокруг этого контура появляются аутентификация, работа с данными, интеграции, логирование и мониторинг.
Это и есть тот момент, когда эксперимент с моделью начинает превращаться в продукт.
Что входит в harness
Набор компонентов зависит от задачи. Для простого корпоративного чат-бота и автономного агента, который работает с CRM, он будет разным. Но несколько слоев встречаются почти всегда.
Интерфейс или API
Первое, что отличает запущенную модель от сервиса — способ ей пользоваться. Это может быть веб-чат для сотрудников, API для другого приложения, бот в корпоративном мессенджере или сразу несколько интерфейсов.
Например, Open WebUI дает готовый веб-интерфейс для работы с LLM и позволяет подключать модели через OpenAI-совместимые API. Рядом с таким интерфейсом обычно разворачивают Ollama для локального запуска моделей и инструменты для работы с RAG. Если ищете быстрое решение, то например, все это уже собрано в одном преднастроенном образе Open WebUI в ИИ-маркетплейсе Selectel.
То есть вместо схемы:
Получаем:
Разница со схемой, которая была выше, на первый взгляд, небольшая, но именно на этом уровне LLM впервые становится инструментом, которым могут пользоваться не только инженеры.
ИИ‑роутер — доступ к 300+ моделям из одной панели
Подключите OpenAI‑совместимый шлюз по единому API‑ключу. Настраивайте сквозную аналитику, отслеживайте лимиты и квотируйте ресурсы.
Контекст и корпоративные данные
Базовая LLM знает только то, что попало в ее обучение и текущий контекст. Она не знает актуальные регламенты компании, внутреннюю документацию, каталог товаров или содержимое корпоративной базы знаний.
Один из способов подключить такие данные — RAG: перед запросом к модели система находит релевантные документы или их фрагменты и добавляет их в контекст.
Когда пользователь спрашивает: «Как оформить доступ новому сотруднику?», модель получает не только сам вопрос, но и фрагмент актуальной внутренней инструкции. Здесь уже работают несколько компонентов: хранилище документов, поиск, формирование контекста и сама LLM.
Под такие сценарии существуют готовые сборки — например, у Open WebUI есть встроенный RAG, а RAGFlow специализируется именно на этом.
Интеграции и действия
Следующий уровень — когда сервис должен не только сформировать текст, но и выполнить действие. Например,найти клиента в CRM, создать заявку, отправить письмо, получить остатки товара, сформировать отчет, вызвать внутренний API.
LLM в такой архитектуре может определить, что необходимо сделать и с какими параметрами, но само выполнение лучше оставлять программному коду. Так устроен, например, механизм tool calling у современных коммерческих моделей. Модель формирует структурированный запрос к заранее указанному инструменту, приложение выполняет функцию и возвращает результат обратно модели.
OpenAI, например, позволяет задавать схемы инструментов и получать аргументы вызова в структурированном виде. Structured Outputs дополнительно позволяют ограничить ответ заданной JSON Schema.
Для сборки подобных процессов необязательно писать всю логику самостоятельно. Например, low-code инструменты вроде n8n умеют связывать ИИ-компоненты с CRM, ERP, почтой, чатами и другими системами через workflow. На сервере с GPU можно также локально запустить LLM через Ollama, а без GPU — подключить внешнюю модель по API.
Лимиты, стоимость и отказоустойчивость
У harness есть и менее заметная, но не менее важная задача — не дать сервису случайно потратить бюджет или упасть из-за нагрузки. Каждый запрос к LLM стоит денег и занимает время. Агент с доступом к инструментам в теории может звать модель по кругу десятки раз, пока не наберет лимит токенов или не зациклится на неудачном действии.
На практике это закрывают несколькими механизмами. Для начала ограничивают число шагов и токенов на один запрос пользователя или кэшируют повторяющиеся вопросы. Еще можно разводить задачи по моделям — простые запросы уходят в быструю и дешевую модель, сложные передаются более мощной, — а при недоступности основной модели сервис переключается на резервную. Без этого слоя ваши токены или бюджеты могут сгореть раньше ожидаемого.
Валидация: модели нельзя безоговорочно доверять результат
LLM генерирует наиболее подходящее продолжение текста, а не выполняет детерминированную функцию.
Поэтому там, где результат влияет на другую систему, его желательно проверять до выполнения действия. Простейший пример — агент формирует заявку:
{
"priority": "high",
"department": "network",
"description": "..."
}Приложение может проверить, существуют ли такие значения priority и department, есть ли обязательные поля и достаточно ли у пользователя прав на создание заявки. Для критичных действий может потребоваться отдельное подтверждение человеком.
Получается важное разделение ответственности: LLM предлагает действие → программный слой проверяет → система выполняет. Чем больше полномочий получает ИИ-сервис, тем важнее становится эта граница.
Здесь стоит закрыть и обратную сторону. Не доверять нужно не только тому, что модель предлагает сделать, но и тому, что ей передают на вход. Если в контекст попадают чужие документы, письма или результат вызова внешнего API, в них может быть спрятана инструкция вроде «игнорируй предыдущие указания и…». То есть что-то рассчитанное на модель, — это и есть промпт-инъекция, о котором шла речь в начале статьи (когда говорили про входные данные).
Поэтому текст из RAG, тикетов или ответа стороннего сервиса стоит передавать модели как данные, а не как команды. И явно закреплять в промпте, чьи инструкции важнее. Системные — выше пользовательских, пользовательские — выше того, что нашлось в документах или вернул инструмент.
Безопасность тоже находится вокруг модели
Еще одна причина, по которой просто запущенной LLM недостаточно — безопасность. Если сервис работает с корпоративными данными, необходимо как минимум решить:
-
кто имеет доступ к приложению,
-
какие данные доступны конкретному пользователю,
-
куда отправляются запросы,
-
где хранится история,
-
к каким системам может обращаться ИИ,
-
какие действия ему разрешены,
-
какие события нужно сохранять для расследования ошибок.
Особенно важным этот слой становится у ИИ-агентов. Если сервис умеет только отвечать на вопрос, ошибочный ответ неприятен. Если тот же сервис получил доступ к CRM, файловой системе или инфраструктуре, цена ошибки уже другая.
Поэтому права ИИ-сервиса лучше строить по тому же принципу, что и права обычного приложения: выдавать только тот доступ, который необходим конкретному сценарию.
Саму инфраструктуру тоже можно изолировать. Сервер можно разместить в приватной подсети без прямого доступа из интернета или подключить к приватной сети через роутер. Для доступа к серверу можно использовать SSH-ключи.
Если смотреть на пример между моделью и сервисом — можно обратиться к ChatGPT:
-
GPT — семейство моделей;
-
ChatGPT — приложение, через которое пользователь работает с этими моделями.
Вокруг самой модели в продукте появляются интерфейс, управление диалогом и контекстом, работа с файлами, инструменты и интеграции, контроль доступа и множество других компонентов.
Похожая ситуация с Claude: языковая модель является ядром, но готовый продукт добавляет работу с инструментами, файлами и внешними системами.
При разработке собственного ИИ-сервиса происходит примерно то же самое, только набор компонентов определяется конкретной задачей бизнеса.
Выбирая LLM, мы выбираем ядро будущего сервиса, а не весь сервис.
Обвязку необязательно собирать с нуля
В простом прототипе разработчик вполне может самостоятельно поднять инференс-сервер, написать API и небольшой интерфейс. Дальше нужно подключить авторизацию. Потом документы. Затем появляется еще одна модель. Нужна маршрутизация запросов. Потом бизнес просит интеграцию с CRM. Добавляются логи, workflow, права пользователей. В итоге вокруг модели постепенно появляется собственная платформа.
Часть этой работы можно убрать, если начать не с пустой виртуальной машины, а с уже подготовленного образа. В ИИ-маркетплейсе Selectel сейчас доступны преднастроенные виртуальные машины с разными компонентами ИИ-стека: Open WebUI, n8n, RAGFlow, Dify, LiteLLM, MLflow и другими инструментами. Сервис создает облачные серверы из готовых образов, в которых необходимое ПО уже установлено.
Например:
-
Open WebUI — если нужен готовый интерфейс для пользователей, управление доступом и работа с RAG. В образ также входит Ollama для локального запуска моделей на GPU;
-
n8n — если ИИ нужно связать с существующими бизнес-процессами и системами: CRM, почтой, чатами или внутренними API;
-
RAGFlow — если основная задача связана с поиском и ответами по собственной базе документов.
То есть ИИ-маркетплейс не заменяет проектирование ИИ-сервиса. Он сокращает количество инфраструктурных компонентов, которые приходится устанавливать и первоначально настраивать самостоятельно.
Например, если компании нужен внутренний помощник по документации, минимальный стек может состоять из LLM, веб-интерфейса и RAG. Если тот же помощник должен еще создавать заявки или обращаться к CRM, к этому стеку добавится слой интеграций и проверки действий. Чем сложнее бизнес-задача, тем больше функций оказывается не внутри модели, а вокруг нее.
Что в итоге
Скачать модель и запустить ее на GPU сегодня действительно несложно. Но сама по себе LLM остается вычислительным компонентом. Чтобы она стала сервисом, которым можно дать пользоваться сотрудникам или клиентам, вокруг нее почти всегда появляются другие слои: интерфейс, данные, управление доступом, интеграции, проверки, логи и инфраструктура.
Сложность при этом зависит от задачи. Для внутреннего чат-бота иногда достаточно модели и Open WebUI. Для RAG-сервиса понадобится контур работы с документами. Для агента — инструменты, workflow, права и контроль выполняемых действий.
Модель определяет, что система умеет генерировать. Обвязка определяет, можно ли этим безопасно и удобно пользоваться в реальном процессе.
Автор: natlysky
