Урок 5: Гибридные архитектуры — router, PII redaction, каскад, judge pattern

Чему вы научитесь

• Отличать пять гибридных паттернов, которые реально уменьшают стоимость и риск AI-системы
• Понимать, когда ставить локальный router, а когда сразу строить каскад из нескольких моделей
• Проектировать PII redaction pipeline так, чтобы он помогал по 152-ФЗ, а не создавал ложное чувство безопасности
• Выбирать место для LangGraph, LiteLLM и Microsoft Presidio в промышленной архитектуре, а не «прикручивать модный фреймворк»
• Видеть, где гибридная схема ломается: по качеству, по latency, по регуляторике или по операционной сложности

Главная ошибка в AI-проекте на производстве — выбирать одну «лучшую» модель и пытаться натянуть на неё все сценарии. Так не работает. В реальной эксплуатации архитектура почти всегда гибридная: часть запросов надо отбросить, часть обезличить, часть закрыть локально, а дорогую модель включать только там, где её интеллект действительно окупается. Именно это отличает пилот «для совета директоров» от системы, которая выдерживает бюджет, SLA и комплаенс.

Если в запросах есть персональные данные, связку redaction и внешний AI-контур надо оценивать вместе с уроком p.3/01 «Персональные данные в AI-проекте — как не попасть на 500 млн». Если объект относится к значимым КИИ, внешний иностранный cloud может быть закрыт вообще — это уже тема урока p.3/02 про КИИ и урока p.3/05 про санкционный контур.

Пять паттернов, которые надо знать наизусть

1. Router pattern — сначала решаем, что это за запрос

Router pattern — это входной диспетчер. Он не отвечает пользователю по существу, а определяет класс задачи: «можно закрыть локально», «нужен внешний reasoning», «надо сначала обезличить», «запрос вообще запрещён политикой». В промышленном AI это часто важнее выбора модели, потому что один и тот же чат получает и безобидный вопрос по регламенту, и письмо клиента с телефоном, и просьбу «сделай служебную записку», и кусок аварийного лога.

flowchart TD
    A[Входящий запрос] --> B{Класс запроса}
    B -->|Поиск по базе знаний| C[Локальный RAG]
    B -->|ПД или коммерческая тайна| D[Redaction / запрет]
    B -->|Сложный reasoning| E[Топовая модель]
    B -->|Типовой шаблон| F[Дешёвая локальная модель]
    D --> G{Можно обезличить?}
    G -->|Да| E
    G -->|Нет| H[Остановить запрос и показать policy]

Практический смысл router-паттерна двойной.

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

Для этого удобно использовать LiteLLM: он работает как единый LLM-gateway, умеет router, fallback и проксирование разных провайдеров через единый OpenAI-совместимый интерфейс (docs.litellm.ai). Если нужен управляемый многошаговый граф с checkpoint, human-in-the-loop и явными переходами между узлами, полезен LangGraph, который как раз позиционируется как фреймворк для long-running stateful agents с durable execution и human-in-the-loop (GitHub README; docs.langchain.com/oss/python/langgraph).

Рабочее правило такое: router должен быть тупее основной модели, но жёстче в политике. Ему не нужен блестящий reasoning. Ему нужна предсказуемость.

2. PII Redaction Pipeline — сначала убрать идентификаторы, потом спрашивать модель

Это самый важный паттерн для всех, кто работает с письмами клиентов, HR-документами, сервис-деском, претензиями, аудиорасшифровками и CRM. Его смысл прост: до выхода во внешний сервис локальный слой удаляет или заменяет персональные данные и иные чувствительные признаки.

Важно: redaction не отменяет закон. Он уменьшает риск и помогает сделать передачу минимально необходимой, но сам по себе не отменяет требований 152-ФЗ. Подробная правовая рамка уже разобрана в уроке p.3/01 «Персональные данные в AI-проекте — как не попасть на 500 млн».

flowchart LR
    A[CRM / почта / Service Desk] --> B[Локальный redaction layer]
    B --> C{ПД найдены?}
    C -->|Нет| D[Внешняя модель]
    C -->|Да| E[Маскирование / псевдонимизация]
    E --> D
    D --> F[Ответ модели]
    F --> G[Локальная подстановка контекста при необходимости]

Для redaction обычно используют Microsoft Presidio. Это open-source SDK для поиска и де-идентификации PII в тексте, изображениях и structured data; у него есть analyzer, anonymizer, image redactor и structured-модуль (microsoft.github.io/presidio; GitHub). Для промышленного сценария этого мало «из коробки». Нужно дополнять Presidio внутренними словарями: табельные номера, номера договоров, коды контрагентов, номера партий, внутренние названия цехов и проектов.

Здесь важно не перепутать три режима:

• маскирование — заменили «Иванов Иван» на [PERSON_1];
• псевдонимизация — сохранили карту подстановки локально, чтобы потом восстановить контекст;
• обезличивание в строгом смысле — сделали так, чтобы повторная идентификация стала практически невозможной.

Для внешнего LLM чаще всего нужен второй вариант: псевдонимизация внутри локального контура. Тогда внешняя модель видит структуру кейса, но не видит реальное лицо.

3. LLM cascade — дешёвая модель идёт первой, дорогая подключается по правилу

Каскад — это не просто «две модели подряд». Это дисциплина эскалации. Сначала работает дешёвая или локальная модель. Если уверенность низкая, формат не сошёлся, ответ пустой или задача явно сложнее порога, запрос уходит на более сильный слой.

flowchart TD
    A[Запрос] --> B[Модель 1: дешёвая / локальная]
    B --> C{Confidence и формат ок?}
    C -->|Да| D[Отдать ответ]
    C -->|Нет| E[Модель 2: сильная]
    E --> F[Отдать ответ]

Каскад особенно полезен в четырёх промышленных сценариях:

• массовая классификация обращений;
• суммаризация планёрок и сменных журналов;
• черновики ответов поставщикам и подрядчикам;
• помощник по внутренним регламентам, где 70–80% вопросов типовые, а редкий хвост действительно требует топовой модели — оценка доли типовых запросов зависит от корпуса и требует проверки на ваших логах.

Хороший каскад строится не на «ощущении, что ответ неплохой», а на явных критериях:

• модель вернула JSON по схеме или не вернула;
• ответ содержит обязательные поля или нет;
• retrieval нашёл достаточное число релевантных фрагментов или нет;
• confidence-классификатор выше порога или нет;
• запрос помечен как юридически чувствительный и сразу уходит в усиленный контур.

Практически это часто выглядит так: локальная Qwen или T-Pro закрывает базовый слой, а сложные кейсы уходят в более сильный API. Для быстрого сравнения качества и стоимости по обезличенным примерам удобно гонять такие каскады через arckep.ru: это даёт рублёвую картину по нескольким моделям без VPN. Но в production политика маршрутизации должна жить у вас, а не в внешнем интерфейсе для тестов.

4. Judge pattern — одна модель пишет, вторая принимает или отклоняет

Judge pattern часто путают с каскадом, но задача другая. В каскаде сильная модель отвечает вместо слабой. В judge-схеме одна модель генерирует, а другая проверяет: соответствует ли ответ источникам, формату, политике и бизнес-правилам.

flowchart LR
    A[Запрос] --> B[Generator model]
    B --> C[Черновой ответ]
    C --> D[Judge model]
    D --> E{Прошёл проверку?}
    E -->|Да| F[Пользователю]
    E -->|Нет| G[Перегенерация / эскалация человеку]

Где это особенно полезно:

• черновики служебных писем и ответов на претензии;
• извлечение реквизитов из документов с последующей проверкой полноты;
• ответы по нормативке, где надо проверить, что модель не выдумала пункт регламента;
• суммаризация HSE-инцидентов, где пропуск факта опаснее, чем слегка более дорогой inference.

Judge pattern полезен, когда вам нужно качество топового ответа, но нет желания отправлять всю массу запросов в топовую модель как генератор. Генерацию можно делать средней моделью, а сильную использовать как «контролёра ОТК». Именно в промышленных процессах эта логика понятна управленцу: генератор — как производственная линия, judge — как выходной контроль.

Технически judge лучше всего работает там, где есть проверяемый контракт:

• structured output;
• эталонный набор правил;
• retrieval-контекст;
• возможность отправить ответ на ручную валидацию.

Если ответа «правильный / неправильный» не существует и задача творческая, judge быстро превращается в дорогое вкусовое жюри.

5. Edge + cloud split — локально всё чувствительное и realtime, в облако только верхний слой

Этот паттерн особенно естественен для производства. На линии, возле камеры, PLC, датчика или edge-шлюза нужен быстрый и предсказуемый контур. В облако уходит не сырой поток, а агрегат: описание дефекта, статистика смены, инцидент, сводка за день, обезличённый журнал.

flowchart LR
    A[Камеры / датчики / PLC] --> B[Edge inference локально]
    B --> C[События и агрегаты]
    C --> D{Данные чувствительные?}
    D -->|Да| E[Оставить on-prem]
    D -->|Нет| F[Cloud analytics / LLM]
    F --> G[Отчёт / сводка / ассистент]

Классический пример — CV-контроль качества. Детекция дефекта идёт локально на edge-узле, потому что линии не нужен интернет для решения «брак / не брак». А вот сменный отчёт, аналитика повторяемости дефектов или объяснение на естественном языке можно строить поверх агрегированных данных в отдельном облачном или корпоративном контуре.

Этот же подход работает для IIoT и техподдержки: локальный слой собирает и фильтрует телеметрию, а облако помогает с summarization, knowledge search и сравнением с историческими инцидентами. Для значимых объектов КИИ внешний cloud может быть закрыт полностью — тогда split остаётся, но верхний слой тоже переносится в private VPC или on-prem, как разбиралось в уроке p.3/02 про КИИ.

Как внедрять гибридную архитектуру без хаоса

1. Разделите запросы по классам. Сначала не модели, а типы задач: поиск, суммаризация, draft, юридически чувствительные кейсы, realtime-сигналы, CV, работа с ПД.

2. Определите стоп-лист. Какие запросы нельзя отправлять наружу вообще: ПД без redaction, коммерческая тайна, КИИ-контур, инженерные параметры, которые запрещены политикой.

3. Поставьте router перед всеми моделями. Не дайте приложению обращаться к провайдерам напрямую. У маршрутизации должен быть единый шлюз.

4. Вынесите redaction в отдельный сервис. Он должен жить до LLM-вызова, а не после. Иначе вы уже совершили внешнюю передачу данных.

5. Задайте правила эскалации в каскаде. Формат, confidence, policy-tag, retrieval score, human review — это должны быть явные поля, а не интуиция команды.

6. Отделите генерацию от контроля качества. Judge pattern нужен там, где ошибка дорогая, а не в каждом чат-ответе подряд.

7. Для edge-сценариев сначала спроектируйте локальную автономность. Если интернет пропал, линия, камера или шлюз не должны остановиться из-за отсутствия внешней LLM.

8. Логируйте маршруты, а не только ответы. Через месяц вас будут спрашивать не «что ответила модель», а «почему этот запрос пошёл в этот контур и на каком основании».

Где паттерн ломается

Итоги

• Гибридная архитектура в промышленности нужна не ради красоты, а ради трёх вещей: стоимость, управляемость, комплаенс.
• Router pattern — это главный входной контроль. Он определяет, какая модель и какой контур вообще имеют право работать с запросом.
• PII redaction pipeline полезен только как часть общего режима обработки данных; сам по себе он не отменяет требования 152-ФЗ.
• Каскад и judge pattern решают разные задачи: первый экономит на эскалации, второй повышает качество через контроль.
• Edge + cloud split — естественный паттерн для завода: локально держим realtime и чувствительные данные, наверх отправляем только нужный слой.
• Плохая гибридная архитектура дороже простой. Хорошая — жёстко задаёт правила маршрута, эскалации и журналирования.