Архитектура enterprise AI: четыре решения, которые всё определяют

Зачем enterprise AI нужна архитектурная рамка решений

Enterprise AI — это уже не просто чат с промптом. В продакшене система должна учитывать identity, permissions, свежесть данных, трассировку, latency, cost и быстро меняющийся ландшафт моделей. Поэтому задача здесь архитектурная, а не только “какой model выбрать”.

Команды часто начинают с вопроса “какую LLM использовать?”. Это полезно, но недостаточно. Более правильный вопрос звучит так: “Какую минимально достаточную систему нужно построить под этот бизнес-результат, и какие control points вокруг неё обязательны?” На практике enterprise AI — это комбинация retrieval, generation, orchestration, evaluation и governance.

Самый надёжный способ проектирования — разделить задачу на четыре решения. Тогда становится проще не переусложнять систему и не добавлять agents там, где достаточно RAG или workflow.

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

В корпоративном проекте с документацией заказчика модель четырёх решений отработала так. Первое решение — «нужен ли AI вообще» — заняло неделю, и часть вопросов в итоге ушла на обычный поиск с фильтрами: там, где нужен факт из конкретного документа, полнотекстовый поиск с ACL дешевле и точнее. Второе — «retrieval, generation или оба» — решилось в пользу связки: часть вопросов требовала цитаты на источник, часть — только формулировки факта. Третье — «workflow или автономный агент» — в пользу workflow: бизнес-процесс был описан заранее и требовал детерминизма, а свободного выбора шагов в нём не было. Четвёртое решение — evaluation и governance — оказалось самым дорогим: правила доступа на уровне документа пришлось встроить в retrieval, а не в интерфейс, и это повлияло сразу на качество, стоимость запроса и архитектуру кэша.

Модель четырёх решений

Модель четырёх решений — это практическая рамка для enterprise AI:

1. Нужен ли AI вообще?
2. Нужны retrieval, generation или оба компонента?
3. Нужен workflow или autonomous agent?
4. Какие evaluation и governance нужны для production?

Решение 1: нужен ли AI вообще?

Часть задач лучше решается search, rules, templates или deterministic code. Если результат должен быть точным, повторяемым и аудируемым, классическая система может быть лучшим выбором. AI нужен там, где есть unstructured language, semantic matching, summarization, extraction из шумного текста или natural-language интерфейс.

Хорошая проверка простая: если junior engineer может уверенно реализовать фичу только на rules, не начинайте с LLM.

Решение 2: нужны retrieval, generation или оба компонента?

Если ответ должен опираться на enterprise knowledge, current policy или internal documents, retrieval обычно обязателен. Если задача — в основном преобразование текста или reasoning на стабильном prompt, может хватить generation. Если нужны и enterprise context, и fluent synthesis, выбирайте RAG.

Решение 3: нужен workflow или autonomous agent?

Workflow — это фиксированная последовательность шагов с предсказуемым control flow. Agent сам решает, что делать дальше, исходя из промежуточных результатов. Workflows проще тестировать, защищать и сопровождать. Agents полезны, когда маршрут заранее неизвестен или системе нужно динамически выбирать tools.

В enterprise-среде workflow обычно должен быть первым выбором. Агентов стоит добавлять только тогда, когда workflow становится слишком хрупким или слишком ручным.

Решение 4: какие evaluation и governance нужны?

Если система влияет на клиентов, деньги, regulated processes или sensitive data, нужны измеримые quality gates, monitoring, access control и traceable logs. Production AI без evaluation — это угадывание. Production AI без governance — риск.

Референсная архитектура enterprise AI

Практическая reference architecture обычно включает такие уровни:

• User experience layer: chat, copilot, embedded assistant, API
• Orchestration layer: сбор prompt, routing к tools, workflow engine, agent runner
• Retrieval layer: ingestion документов, chunking, embeddings, vector search, hybrid search, reranking
• Model layer: LLM, embedding models, rerankers, classifiers, safety models
• Data and system layer: enterprise documents, databases, APIs, line-of-business systems
• Governance layer: identity, authorization, policy enforcement, logging, retention, audit trails
• Evaluation layer: offline test sets, online monitoring, human review, regression checks

Краткое описание диаграммы

Diagram brief: показать слои от пользователя до enterprise systems, а governance и evaluation — как cross-cutting controls.

User / App
   |
Orchestration (workflow or agent runner)
   |
+--------------------+
| Retrieval / RAG    |
+--------------------+
   |
Models + Tools + APIs
   |
Enterprise Data + Systems

Cross-cutting: Governance, security, evaluation, observability

Cross-cutting слои не опциональны. Именно они отделяют prototype от platform.

Слой RAG: когда достаточно retrieval

RAG — самый частый enterprise-паттерн, потому что он связывает output модели с enterprise knowledge без необходимости заново fine-tune модель при каждом изменении данных. Цель RAG не в том, чтобы сделать модель “умнее”. Цель — grounded ответ на основе контролируемых и актуальных источников.

Что должен делать production-grade RAG

Обычно RAG-слой включает:

• ingestion источников из документов, knowledge bases, тикетов, wiki и policy
• parsing и normalization
• chunking с сохранением metadata
• generation embeddings
• hybrid retrieval через keyword + vector search
• reranking по релевантности
• citations и grounded answer
• access control filtering до retrieval и до assembly ответа

Ключевые design choices

Chunking: маленькие chunks повышают precision, но слишком мелкие chunks теряют context. Размер chunks должен определяться структурой контента, а не только token count.

Metadata: храните source, version, owner, classification и timestamp. Metadata нужна для фильтрации и аудита.

Hybrid search: один vector search часто пропускает точные термины — product codes, policy IDs, error messages. Для enterprise обычно безопаснее hybrid retrieval.

Reranking: reranker часто заметно улучшает top-k quality, особенно на большом или шумном корпусе.

Citations: если пользователю важен trust, показывайте источник ответа. Если claim нельзя процитировать, относитесь к нему как к lower confidence.

Когда RAG достаточно

RAG часто хватает для:

• Q&A по internal documentation
• policy lookup
• support assistant responses
• knowledge-base search с synthesis
• summarization по retrieved enterprise content

Когда RAG недостаточно

RAG сам по себе не решает задачи, где нужно:

• выполнять multi-step actions во внешних системах
• планировать и повторять tool calls
• разруливать ambiguous business processes
• отслеживать state сразу в нескольких системах
• принимать решения с branching logic и durable progress tracking

Именно здесь в архитектуру добавляются workflows или agents.

Агенты и workflows: когда нужна orchestration

Частая ошибка — считать, что “agent” означает “лучший AI”. На практике agent — это orchestration pattern. Он помогает системе понять, какой tool вызвать, в каком порядке и как восстановиться после частичных сбоев.

Используйте workflows, если:

• процесс известен заранее
• compliance требует предсказуемого исполнения
• нужны детерминированные шаги и понятная ответственность
• use case можно описать как business process

Примеры:

• document intake и classification
• triage customer tickets
• approval routing
• report generation
• knowledge-base publishing

Используйте agents, если:

• путь к ответу заранее неизвестен
• системе нужен dynamic tool selection
• модель должна анализировать несколько источников и адаптироваться
• работа исследовательская, investigative или open-ended

Примеры:

• incident analysis по logs, dashboards и runbooks
• research assistant с web, internal search и database tools
• troubleshooting между системами

Принципы проектирования agent

Держите agents constrained:

• ограничивайте tool access
• задавайте explicit allowed actions
• ставьте max steps и timeouts
• сохраняйте полный trace решений
• по возможности разделяйте planning и execution
• fail closed для sensitive actions

В enterprise-сценариях “полностью автономный” агент почти никогда не должен быть default. Supervised agent с checkpoints обычно лучше, чем свободно действующий agent.

Workflow + agent вместе

Часто лучшая схема — гибрид:

• workflow управляет business process
• agent отвечает только за сложный substep, например tool selection или interpretation документа

Так система остаётся понятной, но при этом получает adaptive reasoning там, где это действительно нужно.

Оценка: докажите качество до продакшена

Evaluation — это не финальный QA-этап. Это часть system design. Если систему нельзя измерить, ей нельзя доверять и её нельзя улучшать.

Что оценивать

Оценку нужно делать на нескольких уровнях:

• Retrieval quality: recall, precision, relevance, grounding coverage
• Answer quality: correctness, completeness, helpfulness, style
• Tool behavior: вызван ли правильный tool, в правильном порядке, с правильными аргументами
• Safety: resistance к prompt injection, data leakage, policy compliance
• Operational quality: latency, cost, failure rate, fallback behavior

Собирайте test sets из реальных задач

Лучший evaluation set строится из реальных user requests, support tickets, policy questions и workflows. Synthetic data может помочь, но не должна быть единственной основой тестирования.

Для каждого кейса желательно хранить:

• input
• expected outcome
• allowed sources
• expected citations or evidence
• failure mode classification

Offline и online evaluation

Offline evaluation запускается до релиза и после изменений. Это основной способ ловить regressions.

Online evaluation отслеживает live behavior. Она помогает заметить drift, неожиданные пользовательские паттерны и изменения модели или провайдера.

Human review всё ещё нужен

Для high-stakes use cases human review остаётся самым сильным сигналом на пограничных кейсах. Ревьюеры должны использовать rubric, а не интуицию.

Практическая rubric может оценивать:

• relevance
• factual accuracy
• source grounding
• policy compliance
• action correctness

Governance: контроль, безопасность, аудит

Governance — это не только текст политики. Это реализация.

Базовые controls governance

• Identity and access control: кто может задавать вопросы и к каким данным можно обращаться
• Data classification: public, internal, confidential, restricted
• Policy enforcement: prompt filters, retrieval filters, tool restrictions
• Audit logging: запросы, retrieved docs, model versions, tool calls, outputs
• Retention rules: что сохраняется, как долго и где
• Review gates: human approval для sensitive actions
• Incident response: rollback, disablement, escalation procedures

Security risks, которые нужно закрыть рано

• prompt injection в retrieved content
• data exfiltration через tool outputs
• слишком широкие permissions у connectors
• hallucination, поданная как факт
• insecure memory или conversation retention

Governance и architecture должны проектироваться вместе

Если architecture даёт модели доступ к системе, она обязана также описывать, чего модель делать не может. Хороший governance уменьшает blast radius и облегчает security review, legal review и procurement review.

Decision matrix: как выбрать подход

Используйте таблицу ниже, чтобы выбрать стартовый pattern.

Use case / constraint	Лучший стартовый pattern	Почему
Точная business logic, низкая неоднозначность	Rules + classical code	Детерминированно и аудируемо
Q&A по internal docs	RAG	Grounding на enterprise knowledge
Summaries по известному тексту	Prompted generation	Просто и быстро
Многошаговый business process	Workflow	Предсказуемый control flow
Investigative tool use	Agent	Dynamic tool selection
Regulated или high-stakes output	Workflow + RAG + human review	Контроль и traceability
Быстро меняющаяся knowledge base	RAG с fresh ingestion	Без частого retraining
External action от имени пользователя	Workflow с approvals	Безопаснее, чем open-ended autonomy

Как пользоваться matrix

Начинайте с самого простого варианта, который закрывает use case. Затем добавляйте capability только если остаётся измеримый gap. Частая ошибка — сначала добавить agent, потом RAG, а потом уже понять, что задача была структурированной.

Чек-лист внедрения

Перед запуском enterprise AI-фичи проверьте:

• определён ли business outcome и success criteria
• решено ли, нужен ли AI вообще
• определена ли потребность в retrieval
• осознанно выбран ли workflow или agent orchestration
• выделены ли sensitive data и rules доступа
• спроектировано ли grounding и citation behavior
• созданы ли offline evaluation sets
• настроены ли logging и observability
• определены ли approval и rollback procedures
• протестированы ли prompt injection и adversarial inputs
• задокументированы ли ownership и operational support

FAQ

1. Всегда ли RAG лучше, чем fine-tuning?

Нет. RAG лучше, когда знания часто меняются или должны быть traceable к источникам. Fine-tuning может помочь со style, formatting или domain behavior, но он не заменяет retrieval актуальных enterprise-данных.

2. Нужны ли agents для enterprise AI?

Нет. Многие кейсы лучше решаются через RAG + workflow или даже просто workflow + один model call. Agents полезны там, где путь неизвестен или требуется динамический tool use.

3. Как уменьшить hallucinations?

Используйте retrieval, ограничивайте prompts, требуйте citations, валидируйте outputs и оценивайте систему на реальных тестах. Для high-stakes сценариев добавляйте human review.

4. Какая самая большая ошибка команд?

Они начинают с выбора модели, а не с системного дизайна. Модель важна, но именно architecture, retrieval, evaluation и governance определяют, выдержит ли решение production.

5. Можно ли одной архитектурой закрыть несколько use cases?

Да. Общая platform может обслуживать несколько assistants, если orchestration, retrieval, policy и evaluation модульные.

6. Нужен ли vector search для каждого случая?

Нет. Иногда лучше работают lexical search, filters или прямые database queries. Hybrid retrieval распространён, но не универсален.

Related Articles

• RAG на .NET: архитектура, которая переживает продакшн
• .NET и Azure для AI-систем: референсная архитектура
• MCP для enterprise: протокол, безопасность и границы
• Agentic-пайплайны в enterprise: паттерны и антипаттерны
• Production RAG: чек-лист из 50 пунктов для продакшна

CTA

Если вы проектируете enterprise AI platform, начните с модели четырёх решений до выбора модели. Самый быстрый путь к надёжной системе — не “больше AI”, а правильная комбинация retrieval, orchestration, evaluation и governance.

Если вы планируете assistant, workflow или RAG platform для реального enterprise-окружения, относитесь к architecture как к продукту: определите control points, задайте evaluation gates и оставьте humans in the loop там, где риск высок.

Если хотите проверить свою систему на реальных данных — напишите нам. Разберём архитектуру и покажем, где именно она ломается: в retrieval, в orchestration, в evaluation или в governance.