Без ML-команды: кто эксплуатирует LLM-систему для тикетов поддержки и документов на ваших серверах после запуска

LLM-системе, которая сортирует тикеты поддержки и читает документы на ваших собственных серверах, и после запуска нужен тот, кто будет её эксплуатировать. LLM — это большая языковая модель (large language model), AI того же типа, что стоит за ChatGPT. У компании без команды машинного обучения (ML) три варианта. Подрядчик, который построил систему, может и дальше эксплуатировать её по договору поддержки. Либо после передачи системы её может взять на себя ваш ИТ-отдел или разделить работу с подрядчиком. При любом варианте кто-то должен по графику проверять качество ответов и утверждать каждое изменение модели до того, как оно пойдёт в работу.

Из чего состоит эксплуатация LLM-системы после запуска?

После запуска эксплуатация LLM-системы сводится к таким регулярным задачам:

• Серверы, часто с GPU (чипами, на которых работают языковые модели), и обновления софта, который запускает модель
• Используемая версия модели и решение о том, когда её менять
• Регулярная оценка ответов на фиксированной выборке ваших собственных тикетов и документов
• Очередь ручной проверки, то есть то, что софт передаёт человеку, и сотрудники, которые её разбирают
• Изменения на вашей стороне, например новая форма, категория тикетов или бизнес-правило
• Логи, в которых записано, что делала система, и права доступа к тикетам и документам
• Сбои ночью и человек, которому в этом случае звонят

vLLM — одна из open-source программ для запуска моделей на собственных серверах. На её странице безопасности на GitHub (по состоянию на 20 октября 2026 года) есть бюллетень от 6 октября 2026 года об ошибке, исправленной в версии 0.31.0. Заголовок бюллетеня гласит: «Слишком большой min_tokens в одном запросе подвешивает движок vLLM, а /health остаётся зелёным». В этом заголовке min_tokens — параметр запроса, который задаёт минимальную длину ответа.

Инструмент мониторинга обращается к адресу вроде /health, чтобы убедиться, что сервер жив. В случае, который описан в бюллетене vLLM, сервер выглядит исправным, хотя уже перестал отвечать на запросы. Мониторинг LLM-системы должен отправлять настоящие тестовые запросы и проверять, что ответы приходят.

Чем наша собственная система отличается от хелпдеска со встроенным AI?

Если хелпдеск продаётся как программное обеспечение как услуга (SaaS), то есть арендуется через интернет, сервис эксплуатирует вендор, а модель работает на серверах вендора или компаний, с которыми он сотрудничает. Ваши тикеты уходят к вендору и к этим компаниям. Выбор между таким инструментом и собственной системой разбирается в статье о том, купить ПО для AI-обработки документов или заказать LLM-пайплайн.

Вендор хелпдеска Zendesk пишет на своей странице о генеративном AI (по состоянию на тот же день), что «Zendesk интегрирует LLM в Сервисы двумя способами». Первый использует модели, размещённые на платформах, «таких как AWS Bedrock, Microsoft Azure, Groq или Fireworks AI», и в этом случае, по словам Zendesk, «провайдер LLM никогда не получает доступа к вашим Данным сервиса». Второй использует модели, «размещённые непосредственно провайдером модели», например OpenAI и Google Gemini. Для них, как пишет Zendesk, текст, отправленный модели, и её ответы «не сохраняются ни в каком механизме логирования».

Intercom, ещё один вендор хелпдеска, публикует список субобработчиков, то есть компаний, которые обрабатывают данные по его поручению. В этом списке, действующем с 25 июня 2026 года (по состоянию на тот же день), для «обработки с помощью AI» среди прочих названы OpenAI, Anthropic, Google и Microsoft. На странице сказано, что списки «могут время от времени обновляться Intercom».

Может ли подрядчик, который построил нашу LLM-систему, и дальше её эксплуатировать?

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

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

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

У нашего ИТ-отдела нет опыта в ML. Может ли он принять систему?

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

Для передачи ИТ-отделу нужны runbook'и — пошаговые инструкции для ежедневных задач и для каждого известного сбоя, например переполнения очереди ручной проверки. Нужны также тестовая выборка ваших тикетов и документов с правильными ответами и скрипт, который оценивает систему по этой выборке. Код и файлы модели должны храниться в хранилище, которое контролирует ваша компания.

Тестовая среда, то есть копия системы, где изменения пробуют до того, как они коснутся реальных тикетов, должна появиться ещё до запуска. В ней же можно проводить обучение: ваша команда выполняет рутинные задачи на копии, а инженеры подрядчика проверяют работу.

У изменений промптов и правил должен быть владелец. Промпт — это текст, который говорит модели, что делать. Когда меняется форма или появляется новая категория тикетов, кто-то должен обновить промпт или правила и заново прогнать оценку на тестовой выборке. Решите, где будет этот человек: в ИТ-отделе, у подрядчика или в команде, которая отвечает за процесс, например в поддержке.

Как может работать разделение обязанностей между нашим ИТ-отделом и подрядчиком?

При разделении за вашим ИТ-отделом остаются серверы и доступ, а подрядчика привлекают для изменений модели и проблем с качеством.

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

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

Почему качество ответов иногда падает после запуска?

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

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

Как собрать тестовую выборку, объясняют статьи о застрявшем AI-пилоте и о вопросах операционного директора к подрядчику. Какой бы вариант вы ни выбрали, в договоре должно быть указано, кто проводит повторную оценку и кто видит результаты.

Кто решает, когда менять модель?

Если на ваших собственных серверах работает модель с открытыми весами, ваша компания сама решает, когда переходить на другую версию. Модель с открытыми весами — это модель, файлы которой разработчик публикует, чтобы любой мог скачать и запускать её по условиям лицензии. Лицензия при этом продолжает действовать, а новая версия может выйти под другой лицензией.

Один из примеров — модели Gemma от Google. Страница Gemma 3 на сайте моделей Hugging Face (по состоянию на тот же день) ссылается на Условия использования Gemma (Gemma Terms of Use), которые включают Политику запрещённого использования (Prohibited Use Policy). В блоге Google об открытом ПО 2 апреля 2026 года говорилось: «Модели Gemma 4 — первые в Gemmaverse, выпущенные под одобренной OSI лицензией Apache 2.0». Поэтому переход с Gemma 3 на Gemma 4 меняет лицензию, которую читают ваши юристы: вместо собственных условий Google действует Apache 2.0, лицензия с открытым исходным кодом.

Система на ваших собственных серверах всё равно может обращаться к модели через API провайдера, то есть подключаться через интернет к серверам другой компании. Такую модель выводят из эксплуатации по графику этой компании. На странице Anthropic о выводе моделей из эксплуатации (по состоянию на тот же день) сказано: «Запросы к моделям после даты вывода из эксплуатации будут завершаться ошибкой». Anthropic пишет, что предупреждает клиентов с активными развёртываниями «как минимум за 60 дней до вывода из эксплуатации публично выпущенных моделей». На странице также уточняется, что эти даты относятся к собственным платформам Anthropic, а Amazon Bedrock и Google Cloud «устанавливают собственные графики вывода из эксплуатации».

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

Может ли тикет поддержки обмануть систему?

Prompt injection (инъекция промпта) — это атака, при которой текст, отправленный системе, содержит инструкции, адресованные модели. Тикеты поддержки приходят извне, поэтому система, которая их читает, остаётся уязвимой всё время, пока работает. OWASP Top 10 for LLM Applications 2025, список рисков от проекта по безопасности OWASP (по состоянию на тот же день), ставит prompt injection на первое место. Один из примеров звучит так: «Злоумышленник внедряет промпт в чат-бот службы поддержки, приказывая ему игнорировать прежние указания, запрашивать данные из закрытых хранилищ и отправлять письма, что приводит к несанкционированному доступу и повышению привилегий».

Правила проектирования против prompt injection, например не давать системе больше доступа, чем нужно для её задачи, приведены в статье о застрявшем пилоте. OWASP называет и меру, которую нужно повторять, пока система работает: «Регулярно проводите тестирование на проникновение и имитацию взломов, рассматривая модель как недоверенного пользователя». При тестировании на проникновение тестировщики с вашего разрешения намеренно пытаются взломать систему.

Тесты на проникновение должны стоять в графике эксплуатационных задач, а в договоре должно быть сказано, какая сторона их заказывает и устраняет найденное. В логах может храниться полный текст тикетов, поэтому решите, кто может их читать и сколько они хранятся.

Сколько эксплуатация системы будет стоить в месяц и что спросить до подписания договора?

Ежемесячные расходы на собственных серверах начинаются с самих серверов и их GPU, купленных или арендованных, и с рабочего времени сотрудников на очередь ручной проверки. К ним добавляется договор поддержки, если за подрядчиком остаётся какая-то роль, а также повторное тестирование после каждого изменения. Цифр здесь нет, потому что каждая из них зависит от ваших объёмов и конфигурации.

Структура расходов зависит от выбранного варианта. Если систему эксплуатирует подрядчик, значительная часть расходов приходится на договор поддержки. После передачи системы большая их часть — это время ваших собственных сотрудников, включая обучение.

Задайте одни и те же вопросы каждой компании, которая предлагает построить и эксплуатировать систему:

• Какие эксплуатационные задачи вы возьмёте на себя после запуска, а какие будет выполнять наш ИТ-отдел?
• Как часто вы будете оценивать систему на нашей тестовой выборке?
• Кто платит за повторное тестирование, когда используемую нами версию модели выводят из эксплуатации?
• Что получит наш ИТ-отдел при передаче и как вы проверите, что он может эксплуатировать систему самостоятельно?

Условия лицензий у разных моделей разные, а правила защиты данных различаются по странам. Эта статья — не юридическая консультация, поэтому проверьте применимые к вам условия у юриста.

Где здесь место amBrain?

Единственный проект с языковой моделью, который amBrain описывает публично, таков: «Мы вывели интеграцию LLM в прод внутри FinTech-периметра клиента: извлечение и нормализация неструктурированных уведомлений брокеров и торговых площадок — о корпоративных действиях, изменениях по инструментам и марже — в структурированные записи, которые потребляет торговая система».

Эта статья — не кейс, и работа для клиентов в ней не описывается. В процитированной строке не сказано, кто эксплуатирует ту систему сегодня, где работает её модель и какие из описанных в этой статье шагов в неё входили. Тикеты поддержки, документы и варианты эксплуатации в этой статье — общие примеры, они не взяты ни из того проекта, ни из любой другой работы amBrain.

Вендоры, разработчики моделей и программные проекты, названные здесь, — примеры по опубликованным страницам, и статья не утверждает, что между amBrain и кем-либо из них есть какие-либо отношения. Цен, сроков и условий amBrain статья не приводит.

amBrain делает софт с 2019 года. Компания работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». Если amBrain в вашем шорт-листе, задайте ему те же вопросы, что и любой другой компании.