База внутренних наблюдений LLM для мультиархитектурных AI-агентов

Я — Denis Shokhirev, Enterprise AI architect из Эрлангена. В DennisCraft AI Studio я внедряю AI-агентов для B2B-клиентов в DACH-регионе: логистика, финтех, индустриальная автоматизация. За последние 6 месяцев вывел в прод 14 AI-агентов на стеке Claude, Supabase, n8n, Doppler и self-hosted Postgres. Одна из самых болезненных точек — ловить неочевидные сбои и деградации LLM прямо в бою, когда архитектуры и вендоры смешаны.

Зачем нужна внутренняя база наблюдений LLM

Когда собираешь мультиархитектурные пайплайны — Claude миксуется с GPT, RAG на self-hosted Postgres, оркестрация на n8n — обычный логгинг быстро захлебывается. На трех последних внедрениях ловил ситуацию: agent на базе Claude стабильно работал месяц, потом внезапно начал давать токсичные ответы из-за обновления prompt в другой части пайплайна. Типовые логи не помогли: не было истории внутренних шагов модели, только вход-выход.

Введение внутренней базы наблюдений — это паттерн, когда все промежуточные контексты, chain-of-thought, reasoning traces и вспомогательные функции AI-агентов фиксируются в централизованной БД (Postgres, Supabase, TimescaleDB). Это не просто лог — а именно структурированный трекинг reasoning-потока.

Архитектура и паттерны хранения

Какие данные собирать?

• Chain-of-thought промпты (пошаговое рассуждение)
• Вызовы вспомогательных функций (tool use, API calls)
• Внутренние токенизации, embeddings, промежуточные векторы
• Ошибки, аномалии, “hallucination triggers”
• Версии промптов и параметров (temperature, max tokens)

Структура хранения — отдельная таблица под каждый тип наблюдения. Например, для reasoning-trace:

CREATE TABLE llm_reasoning_traces (
    id SERIAL PRIMARY KEY,
    agent_id UUID NOT NULL,
    timestamp TIMESTAMP NOT NULL DEFAULT now(),
    input_text TEXT,
    step_number INT,
    reasoning_step TEXT,
    tool_used TEXT,
    output_fragment TEXT,
    prompt_version VARCHAR(32),
    model_name VARCHAR(32)
);

Supabase отлично подходит для быстрого прототипирования — скрипты на TypeScript или Python легко пушат данные прямо из агента. Для больших нагрузок — self-hosted Postgres + TimescaleDB для хранения длинных временных рядов reasoning-потоков.

Как интегрировать с агентами?

Внедрение сбора внутренних наблюдений требует минимального вмешательства в код агента. В Python (например, при использовании Anthropic SDK или openai) достаточно обернуть вызовы LLM и tool functions в небольшую прослойку, которая пушит шаги в БД:

import psycopg2
def log_reasoning(agent_id, step, text, tool, output, version, model):
    conn = psycopg2.connect("dbname=aiobs user=aiwriter")
    cur = conn.cursor()
    cur.execute(
        "INSERT INTO llm_reasoning_traces (agent_id, step_number, reasoning_step, tool_used, output_fragment, prompt_version, model_name) VALUES (%s,%s,%s,%s,%s,%s,%s)",
        (agent_id, step, text, tool, output, version, model)
    )
    conn.commit()
    cur.close()
    conn.close()

В n8n можно делать то же самое через стандартный Postgres node или HTTP-запрос к Supabase REST API.

Практические сценарии использования

1. Отлов деградаций и странных паттернов

На одном из логистических проектов Claude-агент начал генерировать ответы, нарушающие корпоративный стиль, после смены supplier-модуля. Благодаря reasoning-trace удалось выявить: новый prompt в RAG-части пайплайна приводил к “hallucination”, которую обычный лог не фиксировал.

2. Аудит и пост-мортем инцидентов

Для финтех-клиента под BAFIN аудит требовалось показывать не только вход-выход, но и объяснять — “как агент принял то или иное решение”. Внутренняя база позволила восстановить reasoning по каждому шагу, включая промежуточные вызовы API и версии промптов.

3. Сравнительный анализ LLM/архитектур

Таблица ниже — реальный пример из моего продакшена (анонимизировано):

Такая аналитика невозможна без централизованной базы reasoning-шагов.

Безопасность и приватность

Хранить ли персональные данные?

В regulated рынках (финтех, HR, медицина) категорически не храню сырые данные пользователей. Все reasoning-traces проходят masking (email, phone, account). Для masking использую semgrep/gitleaks и ручные проверки на этапе записи.

Доступ и аудит логов

Доступ к reasoning-базе — только через service-аккаунты, все действия логируются. Для критичных сценариев добавляю audit-trail таблицы с детализацией: кто, когда, что читал/записывал.

FAQ

Обязательно ли интегрировать базу наблюдений на старте?

Нет, но если архитектура мультиагентная или LLM меняется на лету — лучше заложить сбор reasoning-шагов сразу. Потом донастроить проще, чем восстанавливать по кусочным логам.

Можно ли сохранять reasoning в облаке?

Для EU/DE клиентов — только если Supabase или Postgres размещён в EU и без передачи PII. Для критичных данных — только self-hosted Postgres на выделенном сервере.

Как анализировать reasoning-trace?

Реально работает простая агрегация: считать частоту ошибок, длин reasoning-цепочек, аномалии по времени отклика. Для сложного аудита — выгрузка в Jupyter, ручной разбор.

Легко ли мигрировать reasoning-базу между LLM?

Если схема хранения проста (agent_id, step, model), то миграция между Claude, GPT, Llama делается SQL-скриптами без сложных ETL.

Можно ли строить аналитику на reasoning-шаги в реальном времени?

Да. Для этого использую TimescaleDB или Supabase Realtime, плюс дашборды на Metabase или Grafana.

В вашей продовой LLM-системе где чаще всего “ломается” reasoning-поток — на стыке prompt engineering, на уровне вызова tool, или при интеграции с внешними API? Реально интересно. Я делаю бесплатный 30-мин аудит стека для DACH-фаундеров, строящих AI в регулируемых рынках. Напишите в LinkedIn или на @ger_dennis_ai.