Агенты ломаются не на демо, а на orchestration: что production-команды берут из Haystack, чтобы контролировать routing, memory и retrieval

Я Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany, и в DennisCraft AI Studio я собираю production AI-системы на Claude, Supabase, n8n, Doppler и self-hosted Postgres для DACH B2B. В демо агент почти всегда выглядит убедительно, а в проде он чаще всего разваливается не на reasoning, а в orchestration: не туда ушел routing, память притянула устаревший факт, retrieval вернул 12 почти одинаковых кусков и система начала спорить сама с собой.

Именно поэтому production-команды смотрят на Haystack не как на “еще один фреймворк для чат-бота”, а как на способ собирать управляемые пайплайны вокруг retrieval, routing и memory. Если у вас агент должен жить в regulated market, проходить аудит и вести себя предсказуемо под нагрузкой, orchestration становится важнее красивого demo trace.

Почему сбой начинается между компонентами, а не внутри модели

Модель может быть сильной, prompt может быть аккуратным, но production-поведение определяется не только LLM. Обычно ломаются 3 участка:

• routing: какой инструмент, индекс или workflow выбрать для конкретного запроса;
• memory: какие факты тащить вперед и когда их забывать;
• retrieval: что именно попадает в контекст и по каким правилам ранжируется.

В документации Anthropic по tool use и structured outputs акцент простой: модель должна получать ясные границы по инструментам и форматам, иначе ошибки накапливаются каскадом. Это не теория. На последних production-системах, которые я запускал для B2B-процессов, больше половины нестабильных ответов были вызваны не “плохим reasoning”, а тем, что система неправильно выбрала источник данных или смешала свежий state со старым.

Что production-команды реально берут из Haystack

1. Явные пайплайны вместо скрытой магии

Главная практическая ценность Haystack — возможность описать pipeline как набор явных узлов: retriever, router, ranker, prompt builder, generator, validator. Это важно для аудита и отладки. Когда ответ плохой, вам нужен не “agent thought summary”, а конкретный ответ на вопрос: какой узел отработал неверно.

2. Routing как отдельный слой управления

В демо routing часто прячут внутри prompt: “реши, какой инструмент использовать”. В проде этого мало. Нужны правила, fallback и ограничения. Например:

• если запрос содержит идентификатор договора, сначала идет lookup в Postgres;
• если найден свежий structured record, retrieval по документам не запускается;
• если confidence у retriever ниже порога, агент не отвечает, а запрашивает уточнение.

Такой подход снижает риск ложной уверенности. OWASP в LLM Top 10 2025 прямо выделяет prompt injection и excessive agency как отдельные классы рисков: https://genai.owasp.org/llm-top-10/ . Если orchestration не ограничивает маршрут выполнения, модель слишком легко уводится в сторону.

3. Memory как политика, а не как “бесконечный чат”

У production-agent memory — это не просто история переписки. Обычно это 3 разных слоя:

• session memory: что происходит прямо сейчас;
• task memory: промежуточные факты по текущему кейсу;
• system memory: проверенные данные из БД или knowledge base.

Haystack полезен тем, что позволяет не смешивать эти слои в одну кашу. Если memory не разделена, агент начинает цитировать устаревшие решения, старые статусы заявок или черновые выводы как будто это истина.

Retrieval в проде: меньше “шире контекст”, больше контроля

Самая частая ошибка — считать, что проблема решается увеличением числа документов в контексте. На практике retrieval должен быть уже, строже и измеримее. OpenAI Cookbook в примерах по RAG постоянно показывает одну и ту же мысль: качество retrieval зависит от chunking, reranking и фильтрации метаданных, а не только от embeddings. Это легко проверить на своем корпусе.

Я обычно советую production-командам сначала зафиксировать 3 метрики:

• retrieval precision по ручной выборке;
• доля ответов с fallback;
• число маршрутов, в которых агент обращается к нецелевому источнику.

Без этого обсуждение orchestration быстро превращается в вкусовщину.

Как это выглядит в рабочем стеке с Postgres, Supabase и n8n

Даже если вы не строите все вокруг Haystack, сам паттерн orchestration можно реализовать в знакомом стеке. Ниже упрощенный пример Python-роутера: сначала structured lookup в Postgres, затем retrieval, затем fallback.

import os
import psycopg
from anthropic import Anthropic

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

def fetch_ticket(ticket_id: str):
    with psycopg.connect(os.environ["DATABASE_URL"]) as conn:
        with conn.cursor() as cur:
            cur.execute(
                "select status, summary from tickets where id = %s",
                (ticket_id,)
            )
            return cur.fetchone()

def answer(query: str, ticket_id: str | None = None):
    if ticket_id:
        row = fetch_ticket(ticket_id)
        if row:
            status, summary = row
            return f"Ticket {ticket_id}: {status}. {summary}"
    return client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=300,
        messages=[{"role": "user", "content": query}],
    ).content[0].text

Для n8n полезно выносить routing-решения в отдельный шаг, а не прятать их внутри одного giant prompt:

steps:
  - name: classify_request
    type: llm
  - name: lookup_postgres
    type: postgres
    run_if: "{{ $json.route == 'structured_lookup' }}"
  - name: query_kb
    type: http
    run_if: "{{ $json.route == 'retrieval' }}"
  - name: human_review
    type: manual
    run_if: "{{ $json.confidence < 0.75 }}"

Здесь важен не синтаксис, а дисциплина: маршрут, порог уверенности и ручная эскалация должны быть видимыми. Именно это потом спасает систему на аудите или разборе инцидента.

Что особенно важно для regulated European markets

В regulated среде orchestration — это уже вопрос не только качества ответа, но и контроля риска. Если агент работает с клиентскими документами, договорными статусами, платежной логикой или внутренними SOP, вам нужно доказуемо объяснять, почему был выбран именно этот источник данных и почему этот факт попал в ответ.

Поэтому production-команды часто берут из Haystack не “agent framework”, а дисциплину pipeline-first:

• явные узлы обработки;
• логирование маршрута;
• отделение verified data от generated text;
• контролируемые fallback-сценарии.

Когда команда этого не делает, агент выглядит нормально до первого спорного кейса. После этого выясняется, что никто не может воспроизвести, откуда взялся ответ и почему retrieval выбрал именно этот документ.

FAQ

Haystack нужен только для RAG?

Нет. На практике его ценность в том, что он заставляет проектировать пайплайн как управляемую систему. RAG — только один из сценариев.

Можно ли обойтись без Haystack и сделать то же самое на своем стеке?

Да. Я часто собираю orchestration на Anthropic SDK, Postgres, Supabase и n8n. Но даже тогда полезно мыслить категориями router, retriever, validator и memory policy.

Что чаще ломает production-agent: память или retrieval?

Обычно их связка. Retrieval приносит спорный контекст, а memory закрепляет его как якобы проверенный факт на следующих шагах.

Нужно ли давать модели право самой выбирать инструменты?

Иногда да, но в узких пределах. В чувствительных процессах лучше оставлять модели ограниченный выбор внутри правил, а не полный контроль над маршрутом.

С чего начать аудит orchestration?

С карты маршрутов и логов по каждому узлу. Если вы не видите, где система выбрала источник данных, вы не контролируете агент, даже если у вас красивые ответы в интерфейсе.

В каком месте вашего LLM pipeline сегодня возникает больше всего production-сбоев — routing, memory policy, retrieval quality или отсутствие fallback на human review? Мне правда интересно сравнить это с тем, что я вижу на проектах в DACH.
I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.