На проекте LLM редко остаётся «чатом в браузере»: заказчик ожидает ответы по внутренним регламентам, трассируемость выводов и контроль данных. Архитектура использования LLM определяет, откуда модель берёт контекст, как проверяется ответ и кто несёт ответственность за решение. Статья отвечает на вопрос: какие паттерны развёртывания LLM в корпоративном контуре выбирать и какие требования закладывать в спецификацию, чтобы решение было защищаемым (defensible), а не экспериментальным.

1. Суть темы

Корпоративный контур LLM — это совокупность решений о размещении модели (облако, on-prem, гибрид), источниках данных, политиках доступа и цепочке от запроса аналитика до утверждённого артефакта. Для системного аналитика архитектура — не «техническая деталь DevOps», а граница системы: что входит в решение, какие интеграции обязательны, какие НФТ (нефункциональные требования) и риски нужно явно зафиксировать.

Доминирующий паттерн для аналитических сценариев — RAG (Retrieval-Augmented Generation, генерация с дополненной выборкой): при каждом запросе система ищет релевантные документы в корпоративной базе знаний и передаёт их модели как контекст перед генерацией ответа. Зрелые решения эволюционируют от прототипа «векторный поиск + LLM» к Defensible RAG — рабочей рамке статьи для RAG-сценариев с управляемой ответственностью, где выводы влияют на аудит, оценку рисков поставщиков и трактовку политик. Это не отраслевой стандарт, а consolidated practice: набор архитектурных контролей, которые аналитик фиксирует в ADR для high-stakes сценариев.

Governed decision infrastructure (управляемая инфраструктура принятия решений) — более широкий образ для любого LLM-контура, где зафиксированы границы доверия, аудит и эскалация к человеку. Термин применяется, когда хотя бы одно из условий выполняется:

  • вывод влияет на решение с юридическими, финансовыми или репутационными последствиями;
  • требуется audit trail «запрос → контекст → ответ → ревьюер»;
  • класс данных или регуляторика требуют disclosure и HITL (human-in-the-loop).

Defensible RAG — частный случай для сценариев с retrieval: ответ обязан быть привязан к источникам, воспроизводим и проверяем до выхода в production. Сценарии без retrieval — direct inference, tool-use, multi-agent без индекса — попадают под governed infrastructure, если выполняются критерии выше, но не требуют citation policy и Central Vector Registry; для них достаточно LLM gateway, validation gate, logging и эскалации — детали non-RAG decision paths — в 11.06 Этические и правовые аспекты.

Граница темы: здесь — архитектурные паттерны и слои корпоративного LLM-решения; критерии выбора и запреты, не сквозные истории внедрения (они — в 11.07 Практические кейсы применения LLM в анализе). Формулировка промптов — в 11.03 Промпт-инжиниринг для аналитика; подключение к Jira, Confluence, function calling и MCP — в 11.05 Интеграция LLM с инструментами аналитика; выбор конкретной модели — в 11.08 Выбор и настройка моделей для корпоративного использования.

Базовые паттерны развёртывания

ПаттернСутьКогда уместен на проекте
Прямой вызов LLM (direct inference)Запрос → модель → ответ без внешних данныхЧерновики по общим знаниям, переформулировка, шаблонные задачи без корпоративного контекста
RAGПоиск по базе знаний + генерация с опорой на найденные фрагментыQ&A по регламентам, поиск по спецификациям, аналитика на основе внутренних документов
Fine-tuning / адаптацияДообучение модели на корпоративных текстахДоменная терминология и стиль — дополнение, не замена RAG
Tool-use / function callingМодель вызывает внешние API, БД, калькуляторы по контрактуАктуальные данные из систем, не попавшие в индекс; см. 11.05 Интеграция LLM с инструментами аналитика
Агентная оркестрация (multi-agent orchestration)Несколько специализированных агентов: поиск, валидация, синтезМногошаговая аналитика с независимыми SLA компонентов
Локальный инференс (local inference)Модель на инфраструктуре заказчикаСтрогие требования к локализации данных; расчёт ROI — в 11.08 Выбор и настройка моделей для корпоративного использования

На практике зрелые корпоративные решения комбинируют паттерны: RAG для актуального контекста, промпт-шаблоны (11.03 Промпт-инжиниринг для аналитика) вместо fine-tuning там, где достаточно стиля, tool-use для live-данных, агенты — только при обоснованной сложности.

Fine-tuning vs RAG + промпт: дообучение оправдано, когда стиль и терминология не укладываются в system prompt и few-shot приемлемом объёме, есть стабильный labeled corpus и бюджет на retrain при drift модели. Если задача — «единый формат user story» — начните с RAG + шаблонов промптов; fine-tuning добавляйте только после пилота, когда измеримый выигрыш перекрывает стоимость поддержки версии модели.

Multi-agent vs один pipeline: достаточно одного pipeline + validation gate, если запрос линейный (retrieval → generation → citation), SLA укладывается в один hop латентности, а проверка — rule-based или один LLM-call. Multi-agent оправдан при параллельных ветках retrieval, разных SLA компонентов, обязательной изоляции validation от generation или при contractual boundaries между командами-владельцами агентов (03.01.03 Декомпозиция системы на подсистемы и модули).

Когда LLM не в scope

Не каждый сценарий выигрывает от LLM. Закладывайте human-only или отказ от автоматизации в ADR, если:

Это не анти-ИИ позиция, а инструмент для 02.01.04 Определение границ решения (Scope Modelling).

Эволюция зрелости: прототип vs корпоративный контур

Таблица ниже — целевая архитектура, которую аналитик фиксирует в ADR для high-stakes сценариев. Конкретные пороги метрик и регуляторные обязательства проектируются под контекст; функции MAP и MEASURE NIST AI RMF — отправная точка для governance и evaluation gates, не норма ISO.

СлойТипичный прототипЦелевой корпоративный контурРиск при игнорировании
Retrieval (выборка)Только векторное сходствоГибрид: вектор + keyword + GraphRAG при relational-запросах«Слепые зоны» связей между сущностями
АрхитектураОдин pipelinePipeline + validation gate; multi-agent — по обоснованиюНепроверенные выводы
Оценка качестваРучное тестированиеEvaluation gates до prod; детали — 11.09 Мониторинг и оценка качества LLM-решенийГаллюцинации в production
GovernanceВедомственные siloCentral Vector Registry; LLM gatewayShadow RAG — неконтролируемое размножение
Безопасность retrievalОбщий индексACL на уровне chunk до generation; integrity checks при ingestionУтечка и poisoned index
ЛогированиеМинимальные tracesЛоги retrieval + generation + reasoningНевозможность audit trail
ПрозрачностьОпциональноDisclosure logic при влиянии на решение — см. 11.06 Этические и правовые аспекты, 08.06 Юридические и регуляторные требования РФ (PCI-DSS)Регуляторное и репутационное exposure

Диаграмма ниже — типичные усиления для RAG и decision-support, а не обязательные следствия выбора паттерна. Direct LLM для informational draft не требует Defensible RAG или Central Vector Registry; audit logging включается по классу сценария и регуляторике.

flowchart TB
    subgraph patterns [Паттерны корпоративного контура]
        D[Direct LLM]
        R[RAG]
        F[Fine-tuning]
        T[Tool-use]
        A[Multi-agent]
        L[Local inference]
    end
    subgraph maturity [Типичные усиления для RAG / decision-support]
        DR[Defensible RAG]
        CV[Central Vector Registry]
        AL[Audit Logging]
        ACL[Retrieval ACL]
        GW[LLM Gateway]
    end
    R -.->|часто| DR
    R -.->|часто| CV
    R -.->|часто| ACL
    T -.->|decision-support| DR
    A -.->|decision-support| DR
    A -.->|decision-support| AL
    L -.->|confidential data| ACL
    D -.->|по классу сценария| AL
    patterns -.->|enterprise| GW

2. Ключевые понятия

Enterprise RAG

Enterprise RAG — архитектурный паттерн, объединяющий information retrieval (поиск релевантных данных) и text generation (генерацию ответа на естественном языке). Ключевое отличие от «просто чата с GPT»: retrieval выполняется на каждый запрос — система ищет в базе знаний и подставляет найденное в контекстное окно модели. Технические детали embedding, chunking и context window — в 11.02 Теоретические основы обработки естественного языка; здесь достаточно цепочки: запрос → retrieval (с ACL-фильтрацией) → сборка контекста → generation с citations → validation gate → audit log.

Defensible RAG

Defensible RAG (защищаемый RAG) — рабочая рамка статьи, при которой RAG — не эксперимент, а инфраструктура с управляемой ответственностью. Требования:

Для аналитика defensible RAG означает: в спецификации явно описаны источники истины, критерии приёмки ответа и human-in-the-loop там, где решение имеет правовые или финансовые последствия.

Residual risk в SRS: RAG снижает, но не обнуляет галлюцинации. В acceptance criteria фиксируйте не «0% ошибок», а измеримые пороги на golden set (faithfulness, citation coverage) + обязательный human review для decision-support. Конкретные метрики и мониторинг — 11.09 Мониторинг и оценка качества LLM-решений; в SRS достаточно ссылки на evaluation gate и класс сценария.

Validation Gate — минимальная спецификация для SRS

Validation gate — компонент между generation и выдачей ответа пользователю. Без явной спецификации gate остаётся декоративным. Минимум для inclusion в SRS/FRD:

ЭлементЧто зафиксировать
Проверки (inputs)Citation coverage (каждое утверждение decision-support привязано к chunk); policy rules (запрещённые темы, PII-паттерны); confidence threshold модели; согласованность retrieved chunks (нет конфликтующих фактов без пометки)
АрбитрRule engine — для детерминированных правил; второй LLM-call — только с явным обоснованием и golden set; человек — для automated decision и fail escalation
При failBlock — ответ не показывается (decision-support); Degrade — ответ с пометкой «не подтверждён» + только citations (informational); Escalate — очередь human review с сохранением контекста

Связь с приёмкой: validation gate на prod дополняет статическую приёмку до release — golden set и evaluation gates описываются как 02.04.02 Критерии приёмки (Acceptance Criteria) и 08.03 Тестирование требований (статическое тестирование); мониторинг после выхода — 11.09 Мониторинг и оценка качества LLM-решений.

LLM Gateway

LLM gateway (policy enforcement point) — единая точка входа для корпоративных LLM-вызовов: маршрутизация моделей, единые политики логирования, квоты и cost cap, блокировка shadow silos. В ADR фиксируйте: все prod-сценарии проходят через gateway; прямой доступ к vendor API — исключение с обоснованием. Gateway не заменяет validation gate, но обеспечивает единый perimeter для direct inference, RAG и tool-use.

Shadow Vector Silos и Central Vector Registry

Shadow Vector Silos — децентрализованные RAG-реализации, когда подразделения поднимают собственные векторные базы с разными политиками retrieval, версионирования и контроля доступа. Симптом на проекте: три «корпоративных ассистента» с пересекающимися, но несогласованными индексами Confluence и SharePoint.

Central Vector Registry (центральный реестр векторных баз) — governance-компонент, а не просто каталог URL. Минимальный состав для Context Diagram:

Элемент реестраЧто фиксирует аналитик
Corpus metadataНазвание набора, владелец, класс данных, scope индексации
Index versionВерсия индекса; версионируемый идентификатор конфигурации индексации (поставщик платформы) — не ML-спека, а ссылка для воспроизводимости и audit
ACL policyКакие роли видят какие chunks; связь с корпоративным IAM
LineageИсточник документа → chunk ID → версия в CMS/Git
SLA re-indexRTO/RPO актуальности; триггеры обновления как требование к архитектуре (каналы интеграции — 11.05 Интеграция LLM с инструментами аналитика)

Аналитик при обнаружении silo эскалирует к реестру, а не документирует очередной локальный pipeline как «официальный».

Безопасность retrieval-слоя

В корпоративном контуре ACL применяется до generation: пользователь не должен получить chunk из раздела Confluence, к которому у него нет прав в исходной системе. Архитектурно это означает:

«Запрет PD в промпт» для direct LLM — necessary, но insufficient: retrieval-слой может системно обойти RBAC, если индекс собран без учёта ACL источника.

Integrity и adversarial retrieval

RBAC на chunk не закрывает целостность индекса. Архитектурные риски:

  • Poisoned documents — вредоносный контент в corpus меняет ответы без обхода ACL;
  • Prompt injection через индекс — инструкции внутри документа («игнорируй политику…») попадают в контекст generation;
  • Конфликтующие chunks — устаревший и актуальный регламент в одном ответе без явной пометки.

Контроли для SRS: source allowlist (только утверждённые репозитории); ingestion validation (сканирование, нормализация, отсечение исполняемых вложений); опционально content signing или checksum lineage; validation gate с проверкой конфликтов retrieved sources. Для PD и regulated-сценариев — связка с 08.06 Юридические и регуляторные требования РФ (PCI-DSS) и локальными нормами (152-ФЗ и отраслевые акты — в 11.06 Этические и правовые аспекты).

Классификация данных и допустимые паттерны

Компактная таблица для ADR по периметру данных:

Класс данных / сценарийДопустимый паттернЗапреты и контроли
Public / обобщённые знанияDirect LLMPD, внутренние коды в промпте
Internal, informational draftDirect LLM или RAG в периметреPD в облако без DPA; human review
Internal, decision-supportEnterprise RAG + Defensible RAGЗапрет: vector-only при relational-запросах; ответ без citation
Confidential / PDOn-prem или private cloud RAG (11.08 Выбор и настройка моделей для корпоративного использования)Direct LLM в публичном API; общий индекс без ACL
Regulated automated decisionDefensible RAG + HITL + disclosureАвтоответ без audit trail и escalation; локальные нормы — 11.06 Этические и правовые аспекты, 08.06 Юридические и регуляторные требования РФ (PCI-DSS)

Hybrid Retrieval и GraphRAG

Классическая схема «User Query → Vector Search → LLM → Answer» недостаточна для корпоративной аналитики в четырёх измерениях:

  1. Cross-document aggregation — векторный поиск находит семантически близкие chunk'и, но не синтезирует информацию, распределённую по множеству документов.
  2. Entity relationship reasoning — сходство текста ≠ логическая связь сущностей (один поставщик в разных аудитах).
  3. Time-based comparison — без temporal awareness нельзя сравнить профиль риска между циклами аудита.
  4. Compliance traceability — без логов retrieval и reasoning path нельзя восстановить базу для AI-influenced conclusion.

GraphRAG дополняет векторный поиск графом сущностей и связей. Hybrid retrieval — комбинация векторного, keyword/BM25 и графового поиска.

Входные артефакты аналитика для GraphRAG-слоя: модель сущностей из 03.03.01 ER-диаграммы (сущность-связь), правила entity resolution (один vendor = один node), temporal fields в 10.01.14 Шаблон глоссария и словаря данных, явные relationship queries в требованиях.

Пример «слепой зоны» vector-only RAG — запрос: «Какие пять поставщиков накопили наибольший compliance risk за последние три цикла аудита?» Система найдёт документы со словами «vendor», «risk», «compliance», но не сопоставит одного поставщика между версиями отчётов. Корректный ответ требует hybrid retrieval с графом и temporal awareness.

Multi-agent orchestration

Multi-agent orchestration — разделение pipeline на специализированных агентов: планировщик, retrieval, generation, validation, synthesis. Каждый агент — компонент с входами, выходами и SLA; между агентами — контракты по 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) и интерфейсы между слоями — 03.01.04 Интерфейсы и интеграционные взаимодействия.

НФТ латентности: multi-step agents добавляют p95 времени ответа (каждый hop — сеть + inference). Закладывайте в 10.01.12 Шаблон нефункциональных требований (NFR) явный budget: например, p95 ≤ 15 с для decision-support vs ≤ 3 с для informational Q&A.

flowchart LR
    Q[User Query] --> ACL[ACL Filter]
    ACL --> HR[Hybrid Retrieval]
    HR --> |Vector| VD[(Vector DB)]
    HR --> |Graph| GD[(Knowledge Graph)]
    HR --> CTX[Context Assembly]
    CTX --> LLM[LLM Generation]
    LLM --> VG[Validation Gate]
    VG --> R[Response + Citations]
    VD --> CVR[Central Vector Registry]
    GD --> CVR
    LLM --> AL[Structured Audit Log]
    VG --> AL
    HR --> AL

3. Как применяется в работе аналитика

Архитектурные решения по LLM попадают в ваши артефакты так же, как решения по интеграции или хранению данных: через контекст, требования, ADR и матрицу рисков.

Выбор паттерна под тип задачи

Ниже — матрица «паттерн ↔ артефакт» с критериями и запретами. Сквозные истории внедрения и пошаговые walkthrough — в 11.07 Практические кейсы применения LLM в анализе, чтобы не дублировать содержание при наполнении той статьи.

Задача аналитикаРекомендуемый паттернЧто зафиксировать в спецификации
Черновик user story из общих практикDirect LLM + 11.03 Промпт-инжиниринг для аналитикаКласс данных; запрет PD; human review
Q&A по Confluence, регламентам, SRSEnterprise RAGCorpus owner, ACL, re-index trigger, citation policy
Единый стиль требованийRAG + промпт-шаблоны; fine-tuning — по критериям вышеВерсия промпта (07.05 Системы контроля версий (Git) для документации); при fine-tuning — drift monitoring
Актуальные метрики из BI/APIRAG + tool-useКонтракты вызова; RBAC на tool layer — 11.05 Интеграция LLM с инструментами аналитика
Агрегация рисков по сущностям во времениHybrid RAG + GraphRAGER-модель графа, entity resolution, temporal fields
Сквозной «запрос → проверка → отчёт»Pipeline + validation gate; multi-agent — если SLA/изоляция требуютEvaluation gates, escalation path, p95 latency

Критерий выбора: если ошибка ответа влияет на audit conclusion, vendor scoring или customer-facing advisory — direct LLM и vector-only RAG недостаточны; нужны hybrid retrieval, ACL, logging и disclosure logic.

Что описать в Context Diagram и ADR

При добавлении LLM-компонента используйте 10.01.13 Шаблон архитектурного решения (ADR) и 03.01.02 Моделирование контекста системы (Context Diagram):

  1. Граница доверия — какие решения может предлагать ИИ, какие только готовит черновик (02.04.01 Верификация и валидация (V&V)).
  2. LLM gateway — единая точка входа, маршрутизация моделей, квоты, единое логирование.
  3. Источники retrieval — репозитории, владелец corpus, sign-off на индексируемый набор (02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence), 02.04.03 Управление качеством требований).
  4. Поток данных и perimeter — что покидает контур; облачный API vs on-prem (11.08 Выбор и настройка моделей для корпоративного использования, 03.05.05 Безопасность API).
  5. ACL retrieval и integrity — фильтрация chunks по ролям до generation; source allowlist, ingestion validation (08.07 Основы кибербезопасности для системного аналитика).
  6. Validation gate — проверки, арбитр, поведение при fail (см. таблицу выше).
  7. НФТ — латентность, RTO/RPO индекса, cost cap — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 10.01.12 Шаблон нефункциональных требований (NFR).
  8. Трассируемость — chunk ID, версия документа, timestamp retrieval — 10.01.15 Шаблон матрицы трассировки.
  9. Версионирование конфигурации — промпты, retrieval config — в Git рядом со спецификациями (07.05 Системы контроля версий (Git) для документации).
  10. Регуляторика — disclosure, liability, PD — 11.06 Этические и правовые аспекты, 08.06 Юридические и регуляторные требования РФ (PCI-DSS).

Нефункциональные требования к RAG-слою

Минимальный чеклист для inclusion в SRS/FRD:

Участие в governance и оценке рисков

Три категории exposure для 08.05 Управление рисками на этапе анализа:

КатегорияПример рискаАрхитектурный контроль
FinancialНеконтролируемый token burnROI-модель, квоты, cost cap, LLM gateway
LegalРешение без раскрытия участия ИИDisclosure logic, audit log
ReputationalОшибочный audit conclusionDefensible RAG, hybrid retrieval, human review

На проекте защита строится на локальном golden set и audit trail, а не на чужой статистике: каждый вывод с участием LLM должен иметь цепочку «запрос → retrieved docs / tool calls → generation → validation → ревьюер».

Практический протокол на проекте

  1. Классифицируйте сценарий и данные — informational draft vs decision-support vs automated decision; заполните таблицу «класс → паттерн → запреты» в ADR.
  2. Проверьте shadow silo — есть ли векторные базы у смежных команд; инициируйте central registry и LLM gateway до нового pipeline.
  3. Сформулируйте relationship queries — если стейкхолдеры спрашивают про связи сущностей и динамику во времени, закладывайте GraphRAG, а не только embedding search.
  4. Согласуйте evaluation до разработки — acceptance criteria с порогами на golden set, не post-factum.
  5. Опишите validation gate — проверки, арбитр, block / degrade / escalate по классу сценария.
  6. Определите fallback и degradation — что видит пользователь при сбое retrieval или LLM.
  7. Зафиксируйте re-index triggers — RTO/RPO; детали каналов — с платформенной командой и 11.05 Интеграция LLM с инструментами аналитика.

4. Типовые ошибки и ограничения

Архитектурные ошибки

ОшибкаПроявлениеКак избежать
Vector-only RAG для relational analyticsНеверные топ-N поставщиковHybrid + GraphRAG; entity resolution из 03.03.01 ER-диаграммы (сущность-связь)
Shadow Vector SilosТри разных ответа на один вопросCentral Vector Registry, единые ACL, LLM gateway
RAG без ACLChunk из закрытого раздела в ответеФильтрация по ролям до generation
RAG без integrity checksОтвет по poisoned или устаревшему chunkSource allowlist, ingestion validation, conflict detection в validation gate
RAG без audit logНельзя ответить «на чём основан вывод»Structured logging retrieval + generation + reasoning
Validation gate без спецификации«Есть проверка» без критериев failТаблица проверок / арбитр / block-degrade-escalate в SRS
Multi-agent «ради моды»Latency × N, сложность без выигрышаОдин pipeline + validation gate по умолчанию
Fine-tuning вместо промптовRetrain при каждом изменении шаблонаRAG + 11.03 Промпт-инжиниринг для аналитика до обоснованного fine-tune
Облачный API без ROI-анализаБюджет ×10 при росте adoptionLocal inference при стабильном volume — 11.08 Выбор и настройка моделей для корпоративного использования

Ограничения, которые нельзя «пропромптить»

  • Галлюцинации остаются при любом grounding — RAG снижает частоту, но не обнуляет; 02.04.01 Верификация и валидация (V&V) обязательна для decision-support.
  • Chunking теряет связи на границах фрагментов — graph-связи и overlap частично компенсируют.
  • Stale index — ответ «по регламенту v3», когда уже v5; без re-index triggers архитектура вводит в заблуждение.
  • Parametric memory vs retrieval — модель может дополнить context из pre-training; grounding policy должна это ограничивать.
  • Garbage in — RAG по некачественному Confluence без владельца corpus даёт grounded, но неверный ответ.
  • Adversarial corpus — ACL не защищает от злонамеренного или некачественного контента в разрешённом источнике.

Антипаттерны в формулировке требований

  • «Внедрить ChatGPT для всех» без классификации данных — shadow usage вместо architecture.
  • «RAG по всему Confluence» без sign-off на corpus — garbage in, grounded garbage out.
  • «Defensible RAG по умолчанию» без классификации сценария — over-engineering для черновиков user story.
  • «Validation gate = второй промпт» без критериев fail и escalation path.
  • Передача accountability на vendor без ADR и acceptance criteria.

Defensible RAG не отменяет роль аналитика: архитектура задаёт rails, но смысл требований, границы scope и финальное ревью остаются за человеком — как при любой 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая).

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • NIST AI Risk Management Framework (AI RMF 1.0) — функции MAP (контекст, риски, политики) и MEASURE (метрики, evaluation) применимы к validation gates и governance LLM-контура — https://www.nist.gov/itl/ai-risk-management-framework

Статьи и спецификации

Дополнительно для ориентира по рынку