# Архитектура enterprise AI: четыре решения, которые всё определяют Практическое руководство по архитектуре корпоративных AI-систем: RAG против дообучения, агенты против workflows, оценка качества и governance. > For the index of this section of the site, see [llms.txt](https://anetlab.com/llms.txt) 18 октября 2026 г.11 мин чтения # Архитектура enterprise AI: четыре решения, которые всё определяют Практическое руководство по архитектуре корпоративных AI-систем: RAG против дообучения, агенты против workflows, оценка качества и governance. [Виктор Бузин](https://anetlab.com/about.md) · Founder & Principal Engineer, AnetLab 16+ лет в enterprise-разработке: .NET, AI/LLM-системы, RAG, MCP. Автор материала и практик в студии. ## Зачем 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: архитектура, которая переживает продакшн](https://anetlab.com/blog/rag-na-dotnet.md) * [.NET и Azure для AI-систем: референсная архитектура](https://anetlab.com/blog/dotnet-azure-ai-architecture.md) * [MCP для enterprise: протокол, безопасность и границы](https://anetlab.com/blog/mcp-for-enterprise.md) * [Agentic-пайплайны в enterprise: паттерны и антипаттерны](https://anetlab.com/blog/agentic-workflows-enterprise.md) * [Production RAG: чек-лист из 50 пунктов для продакшна](https://anetlab.com/blog/production-rag-checklist.md) ## CTA Если вы проектируете enterprise AI platform, начните с модели четырёх решений до выбора модели. Самый быстрый путь к надёжной системе — не “больше AI”, а правильная комбинация retrieval, orchestration, evaluation и governance. Если вы планируете assistant, workflow или RAG platform для реального enterprise-окружения, относитесь к architecture как к продукту: определите control points, задайте evaluation gates и оставьте humans in the loop там, где риск высок. Если хотите проверить свою систему на реальных данных — [напишите нам](https://anetlab.com/contact.md). Разберём архитектуру и покажем, где именно она ломается: в retrieval, в orchestration, в evaluation или в governance. Читайте также 20 октября 2026 г.AI/LLM ### [Оценка качества RAG на .NET: Recall@5, MRR и гейт релиза](https://anetlab.com/blog/rag-evaluation-dotnet.md) Как измерять качество RAG на .NET: Golden Set из 50–100 вопросов, расчёт Recall@5 и MRR, измерение faithfulness и eval-как-гейт-релиза в CI. [Читать разбор](https://anetlab.com/blog/rag-evaluation-dotnet.md) [.NET](https://anetlab.com/blog?tag=.NET)[RAG](https://anetlab.com/blog?tag=RAG.md)[Оценка качества](https://anetlab.com/blog?tag=%D0%9E%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%20%D0%BA%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%B0.md) 19 октября 2026 г.AI/LLM ### [Agentic-пайплайны в enterprise: паттерны и антипаттерны](https://anetlab.com/blog/agentic-workflows-enterprise.md) Когда агенты в корпоративных процессах оправданы, а когда хватит детерминированного workflow: архитектура, типовые провалы и чек-лист внедрения. [Читать разбор](https://anetlab.com/blog/agentic-workflows-enterprise.md) [Агенты](https://anetlab.com/blog?tag=%D0%90%D0%B3%D0%B5%D0%BD%D1%82%D1%8B.md)[Архитектура](https://anetlab.com/blog?tag=%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0.md)