Вы запустили бота для техподдержки. Через месяц счёт за API от OpenAI вырос в три раза, а клиенты жалуются на странные ответы. Менеджеры не могут объяснить, почему бот вчера работал нормально, а сегодня галлюцинирует. Знакомо?
Проблема в том, что языковые модели (LLM - большие языковые модели, которые генерируют текст) ведут себя не как обычные программы. Они недетерминированы: один и тот же запрос может дать разные ответы. Провайдеры (OpenAI, Anthropic) обновляют модели без предупреждения - и ваша система ломается. А стоимость одного запроса превратилась в метрику, которую генеральный директор смотрит наравне с выручкой.
Старые подходы к управлению моделями (MLOps - операционная работа с классическими моделями машинного обучения) не работают. MLflow, DVC, Kubeflow не отвечают на простые вопросы: почему ответ изменился, сколько денег съедает конкретная фича, когда сломался формат ответа.
LLMOps - это набор инструментов и процессов, которые делают работу с языковыми моделями в боевой среде предсказуемой и управляемой. Три кита: трассировка вызовов (запись каждого запроса к модели), автоматическая оценка качества и контроль стоимости. В этой статье разберём, как внедрить их в малом бизнесе без программиста за 2-8 часов.
Зачем предпринимателю понимать разницу MLOps и LLMOps
Это не академический вопрос. Если ваша команда (или вы сами) применяет старые подходы к AI-ботам, бюджеты будут расти бесконтрольно. Никто не сможет ответить, почему конкретный клиент получил плохой ответ. А переход с одной модели на другую превратится в проект на квартал вместо двух недель.
Разберём на примере стройфирмы. У вас есть бот, который отвечает на вопросы клиентов по прайсу и срокам. Вы используете одну модель (скажем, GPT-4o). Вдруг OpenAI обновляет её - и бот начинает путать цены. Без LLMOps вы узнаете об этом через неделю по жалобам. С LLMOps - через 30 секунд, и сразу откатываете промпт.
Главная разница в одной фразе. Классические модели машинного обучения детерминированы (одинаковый вход - одинаковый выход). Языковые модели - нет. Это меняет всю операционную работу: версионирование, оценку качества, мониторинг, бюджетирование.
Таблица различий: где старый подход не работает
Классический MLOps строился вокруг детерминированных моделей. Те же входные данные дают тот же выход. Версия модели - это идентификатор сохранённых весов. Качество считают на фиксированном тестовом наборе.
Всё это перестаёт работать с языковыми моделями.
| Что сравниваем | MLOps | LLMOps |
|---|---|---|
| Что версионируем | Веса модели | Промпт + модель + температура |
| Предсказуемость | Полная | Нет (при температуре больше нуля) |
| Главная цифра по деньгам | Стоимость обучения на видеокартах | Цена за миллион входных и выходных токенов |
| Как мерим качество | Точность на тестовом наборе | AI-судья, проверка фактов, ручной просмотр |
| Скорость работы | Время одного запуска модели | Время до первого слова + поток текста |
| Где живут данные | Хранилище признаков | База документов и векторных представлений |
| Что выкатываем | Контейнер с весами | Адрес API (программный интерфейс для вызова модели) и шаблон промпта |
Главный сюрприз - молчаливые обновления провайдера. OpenAI, Anthropic и Google регулярно меняют модели под теми же именами. Версия GPT-4o от марта и от ноября - это разные модели. У них разные сценарии отказа, разная стоимость и разный стиль ответов.
Свежий пример. В мае 2025 команда OpenAI обновила версию gpt-4o-2024-11-20. Поведение модели по структурированным ответам изменилось. Без сохранённых исторических трасс невозможно понять, когда именно сломался бот. Невозможно даже померить, насколько просел процент корректных ответов в формате JSON.
Для бизнеса это означает одно: без LLMOps вы летите вслепую. Каждый месяц платите за API, но не знаете, работает ли система так, как надо.
Почему промпт - самый изменчивый артефакт
В классическом машинном обучении изменение модели - тяжёлая операция. Переобучение, проверка качества, выкатка. Это дни и недели работы команды.
Изменение промпта (текстовой инструкции для модели) - операция на 30 секунд. Поэтому промпты меняются часто. Без проверки. Без документации последствий. Без понимания, что именно сломается.
Проблема глубже, чем кажется. Изменение промпта не всегда заметно глазу. Добавили одну фразу в системный промпт - и тон голоса бота поехал. Добавили инструкцию по форматированию - сломали парсер, который ждал JSON. Поменяли порядок примеров в few-shot (несколько примеров правильных ответов в самом промпте) - точность упала на 5-8 процентных пунктов.
Пример из жизни. В одном A/B-тесте (методе сравнения двух вариантов на живом трафике) на боте техподдержки сделали простую правку. Заменили фразу «Ты помогаешь пользователям решать технические проблемы» на «Ты эксперт по техподдержке продукта X». Это снизило долю отказов модели отвечать с 12% до 3% на тех же запросах. Без замены модели. Без правки кода. Только промпт.
Для предпринимателя это означает: вы можете улучшить качество бота, просто поменяв текст инструкции. Но без системы версионирования вы не узнаете, какая версия работала лучше, и не сможете откатиться, если что-то пошло не так.
Langfuse Prompt Management решает эту задачу. Каждая версия промпта получает осмысленную метку (боевая среда, staging, experiment-v2). Все трассы автоматически привязываются к версии промпта, которая была активна в момент вызова. Откат на предыдущую версию - одна команда в терминале или один щелчок в интерфейсе.
Следующий код достаёт нужную версию промпта из реестра. Можно взять конкретный номер версии или последнюю боевую. Этот код понадобится вашему менеджеру или фрилансеру, который настраивает бота.
from langfuse import Langfuse
lf = Langfuse()
# Получаем конкретную версию промпта
prompt = lf.get_prompt("support-bot", version=42)
# Или последнюю боевую версию
prompt = lf.get_prompt("support-bot", label="боевая среда")
compiled = prompt.compile(user_name="Алексей", product="X")
Три столпа LLMOps
Прежде чем погружаться в инструменты, важно зафиксировать терминологию. На этих трёх китах держится вся дисциплина.
Трассировка (tracing). Запись каждого вызова языковой модели с полным контекстом. Что попало на вход, какие параметры стояли, что вышло на выходе, сколько миллисекунд это заняло, сколько токенов потратили, сколько денег ушло. Одна трасса охватывает всю цепочку - от входящего HTTP-запроса до финального ответа. Включая промежуточные шаги агента и поиск по базе документов.
Для бизнеса это значит: вы всегда можете посмотреть, почему бот ответил именно так. Если клиент жалуется, вы открываете трассу и видите, что пошло не так.
Оценка качества (evaluation, eval). Автоматическая проверка ответов. Включает три семьи методов. Сравнение с эталоном (метрики типа ROUGE и BERTScore показывают, насколько ответ похож на правильный). Оценка без эталона через AI-судью (faithfulness - верность фактам, answer relevancy - релевантность ответа, hallucination rate - доля выдуманных фактов). Автотесты, которые гоняются при каждом коммите. Главная цель - быстро понимать, стало хуже или лучше после правки.
Контроль стоимости. Наблюдение и управление расходами на трёх уровнях. Запрос, сессия пользователя, целая фича. Сюда же входит маршрутизация между моделями по сложности задачи (простой вопрос - дешёвая модель, сложный - дорогая). Кеширование промптов. Семантическое кеширование (когда похожие по смыслу запросы возвращают один сохранённый ответ). Пакетная обработка.
Разница между неоптимизированным и оптимизированным стеком - 60-80% экономии при том же качестве. Это не теория, это типичная цифра по живым проектам 2025-2026 годов. Для малого бизнеса это десятки тысяч рублей в месяц.
Минимальный рабочий стек 2026
Для малого бизнеса не нужны большие платформы и отдельные команды. Достаточно трёх инструментов, которые работают вместе. Все они бесплатны на старте.
Langfuse - трассировка и реестр промптов. Можно поставить на свой сервер через Docker Compose или Kubernetes Helm Chart. Бесплатная открытая версия закрывает 95% потребностей средней команды. Облачный вариант - 49 долларов в месяц за миллион трасс. Для старта хватит бесплатного плана.
Следующий код подключает Langfuse к вызову модели Claude. Декоратор @observe() автоматически записывает всю информацию о запросе. Этот код может настроить ваш менеджер или фрилансер за час.
import anthropic
from langfuse.decorators import observe
@observe()
def generate_answer(question: str) -> str:
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[{"role": "user", "content": question}]
)
return response.content[0].text
DeepEval - набор инструментов для оценки качества с поддержкой автотестов. Умеет работать с G-Eval (универсальным судьёй по произвольным критериям), детектором галлюцинаций, метриками для RAG (поиск с генерацией - когда модель ищет ответ в ваших документах). Обычный pip-пакет, запускается локально или с удалённой моделью-судьёй.
Следующий код создаёт тест на отсутствие галлюцинаций. Если модель выдумала факт, которого нет в контексте, тест упадёт. Это страховка от того, что бот начнёт обещать клиентам то, чего нет.
from deepeval import evaluate
from deepeval.metrics import HallucinationMetric
from deepeval.test_case import LLMTestCase
test_case = LLMTestCase(
input="Сколько стоит GPT-4o?",
actual_output=response,
context=["GPT-4o стоит 5 долларов за миллион входных токенов"]
)
metric = HallucinationMetric(threshold=0.3)
evaluate([test_case], [metric])
LiteLLM - единая точка входа ко всем провайдерам моделей. Один адрес, стандартный API в стиле OpenAI, встроенный учёт стоимости и маршрутизация между провайдерами. Позволяет переключаться между моделями без изменения кода.
Следующая команда запускает LiteLLM как локальный прокси. Он маршрутизирует запросы между GPT-4o и Claude по принципу наименьшей загрузки и учитывает расход бюджета через Redis. Это даёт экономию до 50% за счёт использования дешёвых моделей для простых запросов.
litellm --model gpt-4o --model claude-sonnet-4-5 \
--routing least-busy --budget-manager redis://localhost
Реестр промптов: версионирование и откат
Реестр промптов в Langfuse работает как git для текстов. Каждая версия хранится с метаданными. Кто автор. Когда создана. Какие эксперименты на ней запускали. Какие метки повешены. Боевой промпт помечается меткой боевая среда. Все остальные - staging или experiment-N.
Для бизнеса это не косметика. Это страховка от потери денег и репутации. Когда плохой промпт уже в живом трафике, скорость отката - вопрос выживания, а не удобства.
Разберём на примере турагентства. У вас бот отвечает на вопросы по турам. Вы обновили промпт, чтобы он был более дружелюбным, но бот начал выдумывать скидки. Клиенты уже оформляют бронирования по несуществующим ценам. С реестром промптов вы откатываетесь за 30 секунд. Без него - ищете старую версию в коде, правите, выкатываете через CI (систему сборки) - 20 минут. За это время убытки могут составить десятки тысяч рублей.
Процесс работы с новой версией промпта:
- Инженер создаёт новую версию в интерфейсе Langfuse или через API
- Автоматически запускается оценка качества на золотом наборе данных в CI
- Если оценка прошла, версия получает метку
staging - После A/B-теста или ручного просмотра - продвижение в
боевая среда - При деградации - откат одной командой
Следующая команда откатывает боевой промпт support-bot на 41-ю версию. Это делает менеджер за 10 секунд.
langfuse prompts rollback --name support-bot --version 41
Среднее время отката в Langfuse - 30 секунд. Для сравнения, откат кода через стандартный конвейер CI/CD занимает 15-20 минут. Когда плохой промпт уже льёт деньги в трубу, разница между 30 секундами и 20 минутами - это десятки тысяч рублей сэкономленного бюджета и сохранённое доверие клиентов.
Метрики LLMOps для панели
Минимальный набор цифр, который нужен с первого дня. Не сто метрик, не «всё что можно». Шесть штук, которые реально показывают здоровье системы.
- TTFT p50/p95 (time to first token, время до первого слова). Сколько пользователь ждёт, пока появится начало ответа. Цель: 95-й процентиль меньше 2 секунд для интерактивных приложений. Процентиль - это пороговая цифра, ниже которой укладывается такая-то доля запросов. Например, p95 = 2 секунды означает, что 95% запросов обрабатываются быстрее 2 секунд.
- Tokens per request (токенов на запрос). Средний объём входа плюс выхода. Аномальный рост - значит проблема с промптом или с данными.
- Cost per session (стоимость одной сессии). Сколько денег съедает один пользователь за один диалог. Целевая цифра зависит от модели монетизации.
- Hallucination rate (доля галлюцинаций). Процент ответов с фактическими ошибками по оценке AI-судьи. Цель для боевого RAG - меньше 5%.
- Refusal rate (доля отказов). Процент запросов, на которые модель отказалась отвечать. Рост этой цифры - значит что-то изменилось в промпте или провайдер обновил модель.
- Error rate (доля ошибок). Серверные ошибки (HTTP 5xx) плюс таймауты. Цель: меньше 0.5%.
Langfuse строит панели по этим цифрам из коробки. Для оповещений можно подцепить Grafana через экспортёр Prometheus или использовать встроенные веб-крючки Langfuse.
SLA (service-level agreement, договор об уровне сервиса) и SLO (service-level objective, целевой показатель уровня сервиса) - это формальные обещания о здоровье системы. SLO - внутренняя цель команды. SLA - юридическое обязательство перед клиентом. Эти метрики - основа для обоих.
Кто владеет LLMOps в команде
Самая частая ошибка - назначить LLMOps задачей инженера машинного обучения по аналогии с MLOps. Разработка с языковыми моделями устроена иначе. Большую часть изменений делают продуктовые разработчики через правку промптов. А не команда машинного обучения через дообучение.
Это меняет логику владения процессом. Бизнес-следствие простое. Если повесить LLMOps только на ML-команду, продуктовые команды будут править промпты в обход системы. А значит, никакого контроля качества не будет.
Для малого бизнеса это ещё проще. У вас нет ML-команды. Всё делает один человек - вы или ваш менеджер. Поэтому LLMOps должен быть встроен в инструменты, которые вы используете, и не требовать специальных знаний.
Рабочая модель для команды до 20 человек выглядит так. Инфраструктуру LLMOps поддерживает один инженер-платформист (или фрилансер). Настраивает Langfuse, LiteLLM, конвейеры CI. Пороги оценки и политику работы с промптами определяют продуктовые инженеры вместе с продакт-менеджером.
Отдельная ставка «LLMOps-инженер» оправдывается, когда система начинает обрабатывать 50+ запросов в секунду. Или когда речь идёт о мультиагентных системах с десятком инструментов и сложными цепочками. Для малого бизнеса это избыточно.
Дорожная карта внедрения
Не нужно строить идеальную систему сразу. Это типичная ловушка для перфекционистов: пока команда проектирует «правильную архитектуру», конкуренты уже катят первую версию. Правильная стратегия - короткие итерации, каждая из которых сама по себе даёт ценность.
Итерация 1, логи. Подключить SDK Langfuse, записывать все вызовы языковой модели с токенами и стоимостью. Время: 1 день. Результат: вы видите, сколько тратите на каждую фичу.
Итерация 2, реестр промптов. Вынести жёстко зашитые в код промпты в Langfuse. Добавить версионирование. Время: 2-3 дня. Результат: можете откатить плохой промпт за 30 секунд.
Итерация 3, базовая оценка качества. Написать 20-50 эталонных примеров (golden dataset). Запустить DeepEval в системе сборки. Поставить пороги по доле галлюцинаций и релевантности ответа. Время: 1 неделя. Результат: автоматическая проверка качества при каждом изменении.
Итерация 4, контроль стоимости. Настроить маршрутизатор LiteLLM. Добавить кеширование промптов для длинных системных инструкций. Ожидаемая экономия: 30-50%. Время: 3-5 дней.
Итерация 5, A/B-тесты. Добавить экспериментальные веса в Langfuse. Настроить канареечную выкатку (постепенный перевод небольшой доли трафика на новую версию) на 5% трафика. Время: 3-5 дней. Результат: вы тестируете изменения на малом трафике перед полным запуском.
Каждая итерация независима. Если бюджет закончится после третьей - у команды уже есть логи, реестр промптов и базовая оценка качества. Это намного лучше нуля.
Типичные ошибки
Откладывать трассировку до первых проблем. Восстановить историю задним числом невозможно. Когда сломается продакт - данных для отладки не будет.
Хранить промпты в коде. Любая правка тогда превращается в выкатку через CI. Это медленно, дорого и убивает скорость экспериментов.
Использовать только классические метрики (точность, F1, ROUGE). Они не ловят галлюцинации и не показывают, что ответ стилистически плох.
Не считать стоимость на уровне фичи. Без этого невозможно принять решение, какую фичу масштабировать, а какую закрыть.
Назначать LLMOps только ML-команде. Продуктовые разработчики будут править промпты в обход - и контроля не будет.
Частые вопросы
Если у нас уже есть MLflow, нужен ли отдельный стек LLMOps?
MLflow хорошо версионирует модели и артефакты. Но он не умеет трассировать цепочки вызовов с промежуточными шагами. Не считает стоимость по провайдерам. Не хранит реестр промптов с метками. Можно использовать MLflow для отслеживания экспериментов по дообучению. А Langfuse - для боевой трассировки. Это не конкуренты, а дополнения.
Как убедить технического директора, что LLMOps нужен до выпуска первой версии?
Один аргумент работает лучше всего. Без трассировки с первого дня нет исторических данных для отладки первых проблем в продакте. Восстановить историю трасс задним числом невозможно. Подключение Langfuse занимает 1 день. На своём сервере это стоит 0 рублей.
Langfuse или LangSmith для самохостинга?
Langfuse - полностью открытый код. Docker Compose поднимается за 20 минут. Данные не покидают ваш контур. LangSmith - облачный, глубже интегрирован с LangChain и LangGraph. Но данные идут на серверы LangChain Inc. Для компаний с требованиями к расположению данных - однозначно Langfuse.
С чего начать, если бюджет на инфраструктуру минимален?
Langfuse на том же сервере, где живёт приложение. Docker Compose, 2 ядра процессора, 4 ГБ оперативной памяти. LiteLLM как прокси добавляет меньше 5 миллисекунд накладных расходов. DeepEval запускается локально или через GitHub Actions. Итого - 0 рублей на инфраструктуру при самостоятельном хостинге.
Как LLMOps меняется при переходе к мультиагентной системе?
Когда агентов несколько, трасса превращается в дерево. Родительский отрезок включает вложенные вызовы инструментов, под-агентов и промежуточные обращения к модели. Langfuse поддерживает иерархические трассы из коробки. Главное изменение - оценка качества перестаёт быть просто «оцени ответ». Теперь она включает «оцени правильность использования инструментов» и «оцени финальный план агента».
Что делать завтра
Не стройте идеальную систему. Начните с первой итерации: подключите Langfuse и начните записывать логи. Это займёт один день. Через неделю вы увидите, сколько на самом деле тратите на AI, и сможете принимать решения на основе данных.
Следующий шаг - систематическая оценка качества. Но для этого нужно сначала внедрить базовую трассировку.
Готовый шаблон промпта для старта: возьмите свой текущий промпт, поместите его в Langfuse с меткой боевая среда. Создайте вторую версию с небольшим изменением (например, добавьте «отвечай кратко») и повесьте метку staging. Запустите A/B-тест на 5% трафика. Через день сравните метрики - и выберите лучшую версию.
AI Компас (t.me/kosmoslab_ai) - канал для предпринимателей в РФ и СНГ, которые применяют AI в своём бизнесе без программиста. Разбираем инструменты и схемы - без курсов и теории.