Как уменьшить сбои и повысить надежность AI-агентов в проде: контрольная панель для 25+ LLM с защитой от галлюцинаций

Я — Денис Шохирев, Enterprise AI architect из Эрлангена, Германия. В DennisCraft AI Studio я внедряю AI-агентов для B2B клиентов DACH региона: логистика, финтех, автоматизация. За последние 6 месяцев я вывел в прод 14 AI-агентов на стеке Claude, Supabase, n8n, Doppler и self-hosted Postgres. Самый частый запрос после запуска — «Почему агент ведёт себя нестабильно? Почему галлюцинации?». Ни одной маркетинговой презентации — только реальный опыт продакшена.

Почему LLM-агенты ломаются в проде: реальные симптомы

При интеграции более 25 LLM моделей сразу в нескольких B2B рабочих потоках появляется стандартный набор проблем:

• LLM возвращает неконсистентные ответы на идентичные запросы
• Частые сбои интеграций: timeouts, неожиданные null-ответы
• Галлюцинации — выдуманные данные, невалидные SQL, опасные рекомендации
• Сбои пайплайнов n8n из-за невалидного output из LLM

В трёх последних релизах у меня стабильно 10–15% флоу ломались из-за некорректных данных от LLM. Это не баги инфраструктуры — это особенность генеративных моделей.

Контрольная панель: архитектура и принципы

1. Централизованный мониторинг через Supabase

Я фиксирую каждый запрос к LLM (prompt, параметры, ответ, статус) в отдельной таблице Postgres через Supabase. Это позволяет строить дашборды по частоте сбоев, времени ответа, проценту галлюцинаций.

import supabase
from datetime import datetime

def log_llm_call(user_id, prompt, response, status):
    data = {
        "user_id": user_id,
        "prompt": prompt,
        "response": response,
        "status": status,
        "created_at": datetime.utcnow()
    }
    supabase.table("llm_logs").insert(data).execute()

Реальный кейс: за первую неделю после запуска одной из fintech-автоматизаций я выявил 7% нестабильных ответов — только по логам удалось быстро локализовать источник проблемы.

2. Детектирование галлюцинаций на лету

LLM может сгенерировать невалидный SQL, несуществующий товар, или опасную команду. Я реализую runtime-проверки на выходе агента:

• SQL-парсинг с помощью sqlparse — ловлю синтаксические ошибки до выполнения запроса
• Семантический анализ — сравниваю output с whitelist допустимых значений
• Sanity-check на числовые и булевые значения

Например, для автоматизированных запросов в базу данных:

import sqlparse

def is_valid_sql(query):
    try:
        parsed = sqlparse.parse(query)
        return len(parsed) > 0
    except Exception:
        return False

def check_output(output):
    if not is_valid_sql(output):
        return False
    # Дополнительные проверки
    return True

3. Многомодельный fallback и а/б тестирование

В схемах с 25+ LLM (Claude, GPT-4, Llama, Mistral и пр.) я использую схему fallback: если основная модель возвращает ошибку, запрос уходит на резервную. Для критичных операций включаю а/б тест — отправляю один и тот же prompt в две разные LLM и сравниваю результат по checksum.

Локальный leaderboard храню в Supabase.

Интеграция с n8n: ловим сбои на ранних этапах

n8n — мой основной workflow-оркестратор. Я интегрирую LLM-агентов через кастомные ноды, которые валидируют output до передачи дальше по пайплайну. Если output не проходит sanity-checks, flow прерывается, отправляется уведомление в Slack и логируется инцидент.

// Пример custom ноды для проверки JSON output
export function validateLLMOutput(output: string): boolean {
  try {
    const data = JSON.parse(output);
    // Whitelist ключей
    if (!data.hasOwnProperty('order_id')) return false;
    return true;
  } catch (e) {
    return false;
  }
}

В одном из кейсов (industrial automation) за месяц удалось минимизировать некорректные транзакции с 12 до 1, просто добавив runtime-валидацию в n8n.

Контроль доступа и трассировка — обязательна в финтехе

Для задач, связанных с обработкой персональных данных (DSGVO), все обращения к LLM проходят через промежуточный слой с audit-трекингом: кто, когда, с каким параметром, какой результат. Для чувствительных данных настраиваю маскирование в логах Supabase.

Трассировка — через уникальный trace_id на каждый запрос, позволяя быстро восстановить цепочку событий в случае инцидента.

FAQ

Зачем столько моделей — нельзя ли ограничиться одной?

В реальных B2B задачах одна LLM не покрывает все юзкейсы: разные языки, форматы, требования по latency. Многомодельный стек даёт гибкость и устойчивость к сбоям.

Как детектировать галлюцинации без ручного ревью?

Я внедряю автоматические sanity-checks, семантические whitelist-валидации и сравнение с эталонными значениями. Ручной аудит — только на edge-кейсах.

Сколько занимает построение такой панели?

Первая MVP версия — 2–3 дня на стеке Supabase + простая валидация. Дальше — итеративное расширение под новые модели и пайплайны.

Можно ли всё это реализовать без Supabase?

Технически — да, на self-hosted Postgres и REST API. Но Supabase даёт простую авторизацию, быстрые дашборды и вебхуки «из коробки».

Как защититься от утечки данных через LLM?

Использую masking в логах, ограничиваю input через pre-валидаторы, записываю audit trail для всех обращений к LLM. Для финтеха — отдельная изолированная среда.

В каком звене вашего LLM-пайплайна чаще всего ловятся сбои — runtime валидация, интеграционные тесты или ручной аудит? Мне действительно интересно.

Я провожу бесплатный 30-минутный аудит AI-стека для основателей DACH, работающих в регулируемых нишах. Пишите в LinkedIn или на @ger_dennis_ai.