Как настроить observability для LLM-агентов: трассировка, мониторинг затрат и анализ производительности с Langfuse

Черный ящик, который съедает ваш бюджет

Вы запускаете AI-агента в продакшен. Первые дни все работает идеально. Клиенты довольны. Потом приходит счет от OpenAI. 15 000 долларов за месяц. Вы смотрите на цифры, потом на код, потом снова на цифры. Где эти деньги? Что именно агент делал? Почему вчерашний запрос стоил $0.12, а сегодняшний — $2.47?

Это не гипотетическая ситуация. Это реальность 2026 года, где GPT-4.5 Turbo стоит $0.03 за 1K входных токенов и $0.06 за выходные, а Claude 3.7 Sonnet — $0.008 и $0.024 соответственно. Каждый вызов агента — это лотерея. Он может сделать 3 шага и закончить. А может уйти в рекурсивную спираль из 47 вызовов LLM, 12 обращений к базе данных и 5 HTTP-запросов к внешним API.

Observability — это не про «работает/не работает»

Observability для AI-агентов — это возможность ответить на три вопроса:

1. Что именно происходило внутри агента в каждый момент времени?
2. Почему агент принял именно такое решение (а не другое)?
3. Сколько стоило каждое решение и насколько оно было эффективным?

Если вы не можете ответить на эти вопросы, вы не управляете агентом. Вы просто наблюдаете, как он тратит ваши деньги.

Вот типичная картина без observability:

• Агент обрабатывает запрос пользователя «Найди мне рейсы в Нью-Йорк»
• В логах: «INFO: Agent started», «INFO: Calling LLM», «INFO: Agent completed»
• В метриках: latency 4.2s, успешных запросов 100%
• На деле: агент сделал 8 вызовов LLM, 3 из которых были избыточными, использовал GPT-4.5 вместо GPT-4o-mini, потратил 12 000 токенов на промпты, которые можно было сократить в 3 раза

Вы видите проблему? Логи говорят «все ок». Метрики говорят «все ок». А бюджет плачет.

Langfuse: не просто трейсер, а полноценная observability-платформа

Langfuse в 2026 году — это не тот инструмент, который был в 2024. Это полноценная платформа для observability AI-систем. Она умеет:

Самое главное — Langfuse понимает контекст. Он знает, что вызов LLM — это не просто HTTP-запрос. Это промпт, контекст, модель, параметры генерации, токены, стоимость. И все это связывается в единую картину.

1 Установка и базовая интеграция

Начнем с самого простого — установим Langfuse и подключим его к нашему агенту. В 2026 году есть два варианта: облачный (Langfuse Cloud) и self-hosted. Для продакшена я рекомендую self-hosted — так вы контролируете свои данные.

# Self-hosted вариант с Docker
curl -fsSL https://langfuse.com/install.sh | bash

# Или через docker-compose
wget https://raw.githubusercontent.com/langfuse/langfuse/main/docker-compose.yml
docker-compose up -d

Для Python-агентов (использующих LangChain, LlamaIndex, RLM-Toolkit или любой другой фреймворк) интеграция занимает 5 минут:

from langfuse import Langfuse
from langfuse.callback import CallbackHandler

# Инициализация
langfuse = Langfuse(
    secret_key="your-secret-key",
    public_key="your-public-key",
    host="http://localhost:3000"  # или ваш облачный URL
)

# Создаем callback handler
handler = CallbackHandler(
    secret_key="your-secret-key",
    public_key="your-public-key",
    host="http://localhost:3000"
)

# Интегрируем с вашим агентом
# Для LangChain:
from langchain.agents import initialize_agent
from langchain.llms import OpenAI

llm = OpenAI(temperature=0)
agent = initialize_agent(
    tools,
    llm,
    agent="zero-shot-react-description",
    callbacks=[handler]  # Вот и вся магия
)

2 Настройка трассировки для сложных агентов

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

from langfuse.decorators import observe
from langfuse import Langfuse

langfuse = Langfuse()

class ResearchAgent:
    def __init__(self):
        self.web_search = WebSearchTool()
        self.analyzer = AnalysisSubAgent()
    
    @observe()  # Декоратор автоматически создает span
    async def research_topic(self, topic: str):
        # Этот вызов будет зафиксирован в трейсе
        search_results = await self.web_search.search(topic)
        
        # Параллельные вызовы суб-агентов
        analysis_tasks = [
            self.analyzer.analyze(result) 
            for result in search_results[:3]
        ]
        analyses = await asyncio.gather(*analysis_tasks)
        
        # Итоговый вызов LLM
        final_report = await self.generate_report(analyses)
        
        # Добавляем кастомные метрики
        langfuse.score(
            name="research_quality",
            value=0.85,
            comment="Automated eval score"
        )
        
        return final_report
    
    @observe()
    async def generate_report(self, analyses):
        # Этот метод тоже будет в трейсе
        # как child span родительского research_topic
        ...

Что дает этот подход?

• Полное дерево выполнения: видно, какие суб-агенты вызывались, в каком порядке
• Время выполнения каждого шага: сразу видно, где bottleneck
• Контекст: промпты, ответы, промежуточные результаты
• Связь между шагами: понимаем, как решение суб-агента A повлияло на агента B

Это именно то, о чем я писал в статье «Трейсы вместо кода». Код — это только инструкция. Трейс — это реальное поведение.

3 Мониторинг затрат: от абстрактных цифр к конкретным действиям

Самое болезненное место. Вы получаете счет от OpenAI/Anthropic/AWS Bedrock и не понимаете, на что ушли деньги. Langfuse решает это радикально просто: он считает стоимость КАЖДОГО вызова LLM в реальном времени.

Как это работает:

# Langfuse автоматически определяет модель и провайдера
# и применяет актуальные цены на 22.01.2026

# Пример трейса с затратами:
# - Вызов 1: GPT-4.5 Turbo, 1250 input tokens, 450 output tokens
#   Стоимость: (1250 * $0.03 / 1000) + (450 * $0.06 / 1000) = $0.0375 + $0.027 = $0.0645
#
# - Вызов 2: Claude 3.7 Sonnet, 800 input, 1200 output
#   Стоимость: (800 * $0.008 / 1000) + (1200 * $0.024 / 1000) = $0.0064 + $0.0288 = $0.0352
#
# Итого за трейс: $0.0997

Но просто видеть цифры — мало. Нужно понимать, КТО и НА ЧТО тратит.

Вот какие дашборды нужно настроить в первую очередь:

1. Стоимость по пользователям: кто ваши самые дорогие юзеры? Может, один power-user съедает 40% бюджета?
2. Стоимость по типам запросов: какие операции самые дорогие? Research? Анализ документов? Код-генерация?
3. Эффективность промптов: какие промпты приводят к избыточным вызовам LLM?
4. Сравнение моделей: где GPT-4.5 избыточен и можно использовать GPT-4o-mini?

4 Анализ производительности: не только latency

«Агент работает медленно» — это не диагноз. Это симптом. Настоящие вопросы:

• Что именно медленно? LLM-вызовы? Инструменты? Внешние API?
• Зависит ли скорость от контекста? Большие документы замедляют все?
• Есть ли race conditions или блокировки в параллельных вызовах?

Langfuse показывает распределение времени в трейсе:

{
  "trace_id": "abc-123",
  "total_duration": 4.2,
  "breakdown": {
    "llm_calls": 3.1,
    "tool_executions": 0.8,
    "sub_agents": 0.3,
    "overhead": 0.1
  },
  "slowest_span": {
    "name": "document_analysis_llm",
    "duration": 1.8,
    "model": "GPT-4.5 Turbo",
    "tokens": 4200
  }
}

Сразу видно: проблема в document_analysis_llm. 1.8 секунды — это много. Дальше анализ:

• Может, контекст слишком большой? (4200 токенов — многовато)
• Может, нужно использовать модель с большим контекстным окном, но более быструю?
• Или разбивать документ на части и анализировать параллельно?

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

Типичные ошибки и как их избежать

За 2 года работы с Langfuse я насмотрелся на все. Вот топ-5 ошибок, которые делают все:

Продвинутые сценарии: когда базового observability недостаточно

Ваш агент работает в продакшене 6 месяцев. Вы настроили трассировку, мониторинг затрат, алерты. Что дальше? Дальше начинается настоящая магия.

Корреляция трейсов с бизнес-метриками

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

Пример: агент-консультант по инвестициям. Технически все ок: latency 2s, успешность 99.8%. Но бизнес-метрики показывают: только 15% пользователей совершают сделку после консультации.

Анализируем трейсы:

# Ищем паттерны в неуспешных трейсах
failed_conversions = langfuse.fetch_traces(
    filters={
        "tags": ["investment_agent"],
        "user_id": users_who_didnt_convert,
        "limit": 100
    }
)

# Анализируем промпты и ответы
for trace in failed_conversions:
    # Обнаруживаем: агент слишком часто говорит
    # «я не могу дать финансовые рекомендации»
    # Пользователи разочаровываются и уходят
    
    # Решение: дообучить агента давать более конкретные ответы
    # в рамках регуляторных ограничений

A/B тестирование промптов и моделей

У вас есть два варианта промпта для суб-агента-анализатора. Какой лучше? Раньше — гадали. Теперь — тестируем и смотрим метрики.

# Запускаем A/B тест
prompt_variant_a = "Analyze the document and extract key points..."
prompt_variant_b = "Review the document, identify main themes..."

# Langfuse автоматически тегирует трейсы по вариантам
# Потом сравниваем:
# - Стоимость (токены)
# - Время выполнения
# - Качество ответов (через scores)
# - Дальнейшие действия пользователя

То же самое с моделями: GPT-4.5 vs Claude 3.7 vs Llama 4 405B. Какая дает лучший результат за меньшие деньги?

Прогнозирование затрат и масштабирование

Собираетесь запустить новую фичу? Хотите знать, сколько она будет стоить при 1000 пользователей в день? Langfuse дает данные для прогнозирования.

Берем:

• Среднюю стоимость одного трейса для похожих операций
• Распределение по сложности (простые/средние/сложные запросы)
• Паттерны использования (пиковые часы, сезонность)

Строим модель: «При 1000 пользователей в день, с распределением 70% простых, 25% средних, 5% сложных запросов, месячная стоимость будет $X±15%».

Интеграция с другими инструментами

Langfuse — не остров. Он должен работать в вашем стеке.

• Datadog/Sentry: отправляйте алерты из Langfuse при аномальной стоимости или latency
• Slack/Teams: уведомления о дорогих трейсах или падении качества
• Data warehouses: экспорт трейсов в Snowflake/BigQuery для глубокого анализа
• CI/CD: автоматическая оценка качества после каждого деплоя

Пример интеграции с Datadog:

# При обнаружении аномально дорогого трейса
if trace_cost > 5.0:  # $5 за трейс — это много
    send_to_datadog({
        "title": "Expensive LLM trace detected",
        "text": f"Trace {trace_id} cost ${trace_cost:.2f}",
        "tags": ["llm", "cost", "alert"],
        "priority": "high"
    })

Что будет дальше? Прогноз на 2027

Observability для AI-агентов — еще молодая область. Но тренды уже видны:

1. Автоматическая оптимизация: система не только покажет проблему, но и предложит фикс. «Ваш промпт можно сократить на 40% без потери качества»
2. Предиктивный мониторинг: «Через 2 часа у вас закончатся квоты на GPT-4.5 при текущем темпе»
3. Семантический поиск по трейсам: «Найди все случаи, когда агент неправильно интерпретировал юридические термины»
4. Интеграция с безопасностью: детектирование prompt injection, утечек данных, несанкционированных действий

Уже сегодня инструменты вроде NeMo Agent Toolkit и TraceML двигаются в этом направлении.

Мой совет: начните с малого. Поставьте Langfuse сегодня. Настройте базовую трассировку. Посмотрите, сколько на самом деле стоит ваш агент. Потом добавляйте мониторинг затрат. Потом — анализ производительности. Через месяц у вас будет полная картина. А через два — вы будете управлять агентом, а не он вами.

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