Как вы переносите агента из прототипа в production (MLOps)?

Краткий тезис

Перенос AI-агента из прототипа в production требует внедрения практик MLOps: версионирования промптов, автоматизированного тестирования, контейнеризации, CI/CD, мониторинга производительности и безопасности. Главное отличие POC от production — это надёжность (агент не может «зависнуть» или выдать опасный ответ), наблюдаемость (метрики latency, токенов, ошибок) и итеративность (возможность быстро обновлять промпты и инструменты без простоя). Без этих практик агент останется хрупкой игрушкой.

1. Терминология: агент, MLOps, production vs prototype

• Агент (AI Agent) — программная сущность, которая принимает решения, используя LLM + набор инструментов (API, базы данных, вызовы кода). В прототипе агент часто однопоточный, без сохранения состояния, работает «из коробки» на локальном ноутбуке.
• MLOps (Machine Learning Operations) — набор практик для автоматизации, мониторинга и управления ML-системами в production, адаптированный для агентов (управление промптами, тестирование, деплой).
• Production — среда, где агент обслуживает реальных пользователей, обрабатывает тысячи запросов, должен отвечать SLA (Service Level Agreement), иметь fallback на случай сбоя, логирование, аудит.

Прототип и production различаются уровнем инженерной зрелости: в POC можно игнорировать отказоустойчивость, мониторинг и безопасность — в production это критично.

2. Версионирование промптов (Prompt versioning)

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

Инструменты

• Git — хранить тексты промптов в репозитории (например, prompts/<agent_name>/<version>.yaml).
• LangSmith / Weights & Biases — специализированные платформы для отслеживания версий промптов, тестовых прогонов и метрик.

Пример структуры в Git

prompts/
  customer_support_agent/
    v1.0.yaml      # "You are a helpful assistant..."
    v1.1.yaml      # изменён instruction на "You are a polite assistant..."
    v2.0.yaml      # добавлены примеры (few-shot)

Важно вместе с версией промпта фиксируется версия используемой модели (gpt-4‑0125, claude‑3‑sonnet и т.д.), так как одна и та же строка может работать по-разному на разных моделях.

3. Автоматизированное тестирование агента

Тесты делятся на три уровня:

Пример unit-теста на обработку инструмента (вымышленный код):

# test_agent_tools.py
def test_get_weather_correct_city():
    agent = CustomerSupportAgent()
    result = agent.call_tool("get_weather", city="Moscow")
    assert result["status"] == "success"
    assert "температура" in result["answer"]

Нагрузочное тестирование — отдельно: проверяем, сколько одновременных запросов выдерживает агент под нагрузкой (используем locust, k6).

4. Контейнеризация и FastAPI wrapper

Прототип агента обычно запускается скриптом python agent.py — для production это неприемлемо. Нужно обернуть агента в веб-сервер (обычно через FastAPI) и упаковать в Docker контейнер.

Структура FastAPI-обёртки

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class QueryRequest(BaseModel):
    user_id: str
    message: str

class QueryResponse(BaseModel):
    agent_response: str
    tokens_used: int
    latency_ms: float

agent = CustomerSupportAgent()  # предварительно инициализированный

@app.post("/agent/query", response_model=QueryResponse)
async def query(request: QueryRequest):
    import time
    start = time.time()
    response = agent.run(request.message)
    latency = (time.time() - start) * 1000
    return QueryResponse(
        agent_response=response.text,
        tokens_used=response.tokens,
        latency_ms=latency
    )

Dockerfile

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Почему FastAPI — асинхронность, автоматическая документация (Swagger), поддержка Pydantic для валидации запросов.

5. CI/CD пайплайн (Continuous Integration / Continuous Deployment)

CI/CD гарантирует, что каждое изменение (промпта, кода, инструмента) проходит тесты и автоматически попадает в production.

Типовой пайплайн (GitLab CI / GitHub Actions):

1. Commit → триггер pipeline.
2. Stage «lint & test»: линтеры (flake8, black), unit и интеграционные тесты.
3. Stage «evaluation»: запуск benchmark датасета, сравнение метрик (например, accuracy ответов) с предыдущей версией. Если метрики упали — пайплайн останавливается.
4. Stage «build»: сборка Docker образа с тегом версии (например, agent:v1.1).
5. Stage «deploy»: rolling update в Kubernetes (или замена контейнера на сервере).
6. Stage «smoke test»: быстрый health‑check после деплоя (1‑2 запроса к endpoint).

Важно если изменился только промпт (а не код), пайплайн всё равно должен запускаться — для этого версии промптов тоже коммитятся в репозиторий.

6. Мониторинг в production

Агент в production требует постоянного наблюдения. Ключевые метрики:

Настройка алертов если latency > 5 сек в течение 5 минут → уведомление в Slack/Telegram.

7. Shadow‑режим (теневое развёртывание)

Shadow режим — это запуск новой версии агента параллельно с текущей production-версией, без реального влияния на пользователя. Ответы shadow-агента логируются, но не показываются пользователю. Затем сравниваются метрики (качество, latency, стоимость) и принимается решение о замене.

Схема работы

1. Пользователь шлёт запрос.
2. Production‑агент обрабатывает его и отправляет ответ пользователю.
3. Запрос дублируется shadow‑агенту.
4. Shadow‑агент возвращает свой ответ (не пользователю, а в лог).
5. Аналитик или автоматизированный скрипт сравнивает два ответа по метрикам (ROUGE, BLEU, LLM‑evaluation).

Когда использовать перед крупными изменениями (новый промпт, другая модель, новый инструмент) — позволяет снизить риск регресса.

8. Безопасность и ролевая модель

В production агент может выполнять опасные действия (вызов API, запись в БД). Необходимо:

• Санкционирование вызовов инструментов: агент не должен вызывать удаление данных без подтверждения.
• Ратирование (rate limiting): один пользователь не может послать 1000 запросов в минуту.
• Аудит действий: все вызовы инструментов логируются с user_id и timestamp для расследования инцидентов.
• Prompt injection protection: на уровне входных данных и LLM (фильтры, валидация).

Пет-проект для закрепления

Задача Развернуть агента для ответа на вопросы по документации проекта на базе GPT‑4o (или opensource‑модели) с полным MLOps‑циклом.

Инструменты и шаги

1. Создать простого агента с одним инструментом (search_docs) на Python + LangChain.
2. Добавить версионирование промптов в Git (файлы prompts/agent/v1.yaml).
3. Написать unit‑тест на инструмент (pytest) и интеграционный тест на агента (запрос-ответ).
4. Обернуть агента в FastAPI (endpoint /query).
5. Упаковать в Docker.
6. Настроить CI/CD (например, GitHub Actions) с шагами: lint, test, build, deploy на минимальный VPS.
7. Добавить мониторинг (Prometheus + Grafana), метрики: latency, tokens, success rate.
8. Реализовать shadow‑режим: агент‑клон запускается в отдельном контейнере, его ответы пишутся в log‑файл.
9. Настроить алерт в Telegram при падении success rate ниже 95%.
10. Провести нагрузочное тестирование с k6 (100 одновременных запросов) и убедиться, что latency не превышает 2 сек.

Ожидаемый результат Готовый репозиторий с кодом, Dockerfile, GitHub Actions, конфигами Prometheus и скриптами для shadow‑тестирования. Агент отвечает на вопросы из документации, мониторинг показывает дашборд с метриками, shadow‑режим позволяет проверить новую версию без риска.

Связь с другими вопросами

Навигация

• Предыдущий: 57
• Следующий: 59
• Индекс: 00. Индекс разборов