AI Operational Intelligence Prototype — архитектурное ревью¶

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

Содержание¶

Краткое описание
Цели, требования и ограничения
Модель системы
Архитектура и интеграции
Безопасность, качество и эксплуатация
Решения, компромиссы и риски

Краткое описание¶

Статус¶

Technical PoC / рабочий прототип, июнь 2026

Роль¶

System Designer, AI-assisted Prototype Engineer

Стек¶

Тип: Enterprise AI / прототип управляемого LLM-контура / прототип аналитики на проверяемых данных

Python, FastAPI, LangGraph, Open WebUI, PostgreSQL, Qdrant, MinIO, Redis, Docker Compose

Ценность проекта¶

Технический прототип управляемого LLM-контура для аналитики на проверяемых данных. Прототип проверяет подход к построению управленческой AI-аналитики: модель не отвечает свободно из памяти и не получает прямой доступ к данным. Она работает внутри backend-mediated tool environment на подготовленных синтетических сценариях.

Прототип проверял архитектурную идею на single-turn аналитических запросах. Это не production-платформа, не законченный продукт поддержки принятия решений и не полноценный multi-turn conversational agent.

Что было реализовано¶

chat-like интерфейс на базе Open WebUI;
экспериментальный LangGraph-based execution flow;
backend tools для обращения к подготовленным синтетическим данным;
начальный tool registry / концепт описания доступных инструментов;
синтетические финансовые и кросс-функциональные управленческие сценарии;
single-turn аналитические запросы;
паттерн evidence-backed responses;
базовая трассировка выполнения / run details;
архитектурная документация и направление развития.

Ограничения текущего прототипа¶

Главное ограничение: каждое новое сообщение в Open WebUI фактически обрабатывалось как новый независимый запрос, а не как продолжение текущей аналитической сессии.

Что демонстрирует¶

понимание рисков enterprise AI;
controlled LLM execution вместо свободного чата;
разделение chat UI и execution layer;
tool-mediated analytics;
evidence-backed response design;
execution trace как механизм доверия и отладки;
способность быстро собрать working prototype;
способность честно документировать ограничения.

Цели, требования и ограничения¶

Цели и нецели¶

Основные цели проекта¶

Проверить, может ли LLM работать с подготовленными корпоративными цифровыми следами через контролируемые backend tools, а не через прямой доступ к данным.
Построить воспроизводимый лабораторный стенд с синтетическими enterprise-данными.
Реализовать экспериментальный вертикальный срез: пользовательский запрос → управляемый execution flow → выбор tool → вызов backend tool → структурированный результат → evidence-backed answer → execution trace.
Показать подход к управленческой диагностике, где выводы опираются на факты, документы, расчёты и явно указанные ограничения анализа.
Зафиксировать архитектурное направление для будущего продукта: backend control plane, Tool Gateway, Tool Registry, playbook-based сценарии, semantic layer, audit trail.

Чем этот PoC не является¶

Не является настоящим MVP.
Не является production-ready enterprise-платформой.
Не является полноценным multi-turn conversational agent.
Не является автономным «ИИ-директором».
Не является заменой BI.
Не является полноценным process mining продуктом.
Не содержит production authentication and authorization.
Не содержит подключения к реальным корпоративным источникам данных.
Не содержит полноценный playbook engine.
Не содержит evaluation pipeline для проверки качества ответов.
Не содержит production deployment model.
Не содержит полноценную observability и audit model.

Что было реализовано¶

chat-like интерфейс на базе Open WebUI;
экспериментальный LangGraph-based execution flow;
backend tools для обращения к подготовленным синтетическим данным;
начальный tool registry / концепт описания доступных инструментов;
синтетические финансовые и кросс-функциональные управленческие сценарии;
single-turn аналитические запросы;
паттерн evidence-backed responses;
базовая трассировка выполнения / run details;
архитектурная документация и направление развития.

Прототип также исследовал концепт playbook-routing: вопрос мог направляться в ограниченный диагностический путь с ограниченным набором tools. Это прототипный концепт playbooks, а не полноценный playbook engine.

Что не было реализовано¶

полноценное multi-turn состояние сессии;
продолжение аналитического сценария после уточняющего вопроса;
корректную обработку ответа пользователя на уточнение системы;
durable conversation memory;
persisted analytical run context;
production authentication and authorization;
подключение к реальным корпоративным источникам данных;
полноценный playbook engine;
evaluation pipeline для проверки качества ответов;
production deployment model;
полноценную observability и audit model.

Ограничения текущего прототипа¶

Главное ограничение: каждое новое сообщение в Open WebUI фактически обрабатывалось как новый независимый запрос, а не как продолжение текущей аналитической сессии.

Даже когда прототип задавал уточняющий вопрос вроде «какой сценарий вы имели в виду?», следующий ответ пользователя обрабатывался как новый независимый запрос, а не как продолжение предыдущего run.

Ограничение зафиксировано явно. Прототип проверял архитектурную идею single-turn controlled execution; он не доставил conversational analytics product.

Бизнес-требования¶

Пункты ниже описывают намерение PoC. Их не следует читать как утверждение, что каждое требование было полностью реализовано.

BR-001. Проверяемая управленческая аналитика Прототип должен исследовать управленческий вопрос и возвращать вывод, опирающийся на расчёты, документы, ответы инструментов и явно указанные ограничения анализа.
BR-002. Снижение трудозатрат на первый проход анализа Прототип должен сокращать время первичной проверки гипотезы за счёт маршрутизации запроса, вызова инструментов, сбора доказательств и формирования структурированного ответа.
BR-003. Прозрачность вместо «магического ИИ» Пользователь должен видеть не только итоговый текст, но и основание вывода: выбранный диагностический путь, вызванные инструменты, параметры, результаты, источники и ограничения.
BR-004. Безопасная работа с данными LLM не должна получать прямой доступ к базам данных, документам или произвольным SQL-запросам.
BR-005. Доменные диагностические пути Анализ должен быть оформлен как набор ограниченных диагностических путей, а не как свободный чат со всем каталогом инструментов.
BR-006. Демонстрация без клиентских данных PoC должен демонстрировать подход на синтетическом enterprise-датасете.
BR-007. Направление расширяемости Новые домены анализа должны добавляться через tools, описания инструментов и диагностические пути, а не через один общий промпт.
BR-008. Будущие enterprise-ограничения Архитектурные решения должны оставлять место для последующих audit, RBAC/ACL, контролируемых интеграций, private deployment и переносимости workflow. В PoC это не реализовано.

Функциональные требования¶

FR-001. Chat-like интерфейс для аналитического вопроса Пользователь должен иметь возможность задать управленческий вопрос в свободной форме через chat-like интерфейс.
FR-002. Выбор диагностического пути Прототип должен определять домен вопроса и выбирать ограниченный диагностический путь либо задавать уточнение. Уточнение исследовалось, но ответ пользователя не обрабатывался как продолжение того же run.
FR-003. Ограничение инструментов диагностическим путём Выбранный путь должен ограничивать набор доступных инструментов, чтобы LLM не работала со всем каталогом сразу.
FR-004. Доступ к данным только через tool-server LLM должна получать данные через контролируемые backend tools.
FR-005. Структурированный ответ инструментов Tool-server должен возвращать структурированный JSON с результатом, метаданными, статусом и технической информацией, достаточной для лога запуска.
FR-006. Расчёт финансовых метрик Финансовые метрики должны рассчитываться по структурированным данным из БД, а не генерироваться LLM.
FR-007. RAG как направление document evidence Документы должны использоваться как дополнительный источник доказательств через контур MinIO/Qdrant/RAG.
FR-008. Структурированный аналитический ответ Итоговый ответ должен включать факты, интерпретацию, гипотезы, ограничения анализа и рекомендуемые действия, где это возможно.
FR-009. Прозрачность запуска Прототип должен раскрывать выбранный диагностический путь, запуски инструментов, входы, выходы и базовые run details.
FR-010. Ответ на языке вопроса пользователя Прототип должен формировать ответ на том же языке, на котором задан вопрос.
FR-012. Уточняющий вопрос Если вопрос неполный, слишком широкий или не содержит критичных параметров, прототип может уточнить недостающую информацию. Это не было рабочим multi-turn циклом: следующее сообщение обрабатывалось как новый запрос.
FR-013. Воспроизводимый импорт синтетических данных Лабораторный стенд должен поднимать demo-состояние из репозитория: PostgreSQL seed, MinIO объекты, Qdrant-артефакты, манифесты и скрипты.
FR-014. Несколько связанных синтетических доменов Демо-датасет должен содержать связанные домены: finance, sales, products, documents, delivery, ITSM, PMO, meetings и tasks.

Правила и ограничения¶

CON-001. Проверяемость выводов Каждый существенный вывод должен иметь связь с ответом инструмента, документом, расчётом или явно указанным лимитом.
CON-002. Контролируемый доступ к данным LLM не должна получать прямой доступ к PostgreSQL, Qdrant, MinIO, файловой системе или произвольному SQL.
CON-003. Трассируемость выполнения Запуск должен на базовом уровне сохранять выбранный диагностический путь, вызовы инструментов, параметры, результаты и финальный ответ.
CON-004. Только синтетические данные в PoC В PoC используются синтетические данные. Реальные корпоративные данные клиентов не подключаются.
CON-005. Ограниченный масштаб PoC PoC рассчитан на демонстрационные сценарии и архитектурную проверку, а не на промышленную нагрузку, массовых пользователей или SLA.
CON-006. Ограничение использования LLM Использование локальной LLM является целевым для будущего продукта, но для PoC допустимо использование внешней LLM. Система должна оставаться адаптируемой к смене модели.

Допущения¶

Прототип работает на синтетическом датасете, а не на боевых данных клиента.
Часть cross-domain сценариев демонстрационная и требует стабилизации.
RAG-контур показывает направление document evidence, но не является зрелым ingestion/lifecycle решением.
Tool Registry и связанные factory-идеи находятся в ранней стадии: часть реализована, часть описана архитектурно.
UI является временным chat-like harness, а не целевым executive cockpit.
Прототип не доказывает production-готовность. Он доказывает, что controlled LLM analytics loop можно собрать и продемонстрировать на синтетических данных.

Модель системы¶

Доменная модель¶

Основные участники:¶

Сущность	Роль
Executive User	Задаёт аналитический вопрос и получает ответ прототипа
Domain Owner	Предполагаемый проверяющий выводы по домену: finance, delivery, PMO, ITSM
Platform Admin	Роль целевой системы для источников, доступов, диагностических путей и инструментов; в PoC не реализована
Diagnostic path / концепт playbook	Ограничивает диагностический процесс, доступные инструменты и доменную рамку
Tool	Контролируемая операция над данными: метрика, RAG, агрегированный результат
Diagnostic Run	Один запуск анализа с run details, выбранным путём, историей вызовов инструментов и финальным ответом
Evidence Item	Факт, расчёт, документальный чанк или ограничение, связанное с выводом
Claim	Утверждение в ответе, которое должно ссылаться на доказательство

Diagnostic run в этом прототипе — это single-turn аналитический запрос. Модель не описывает durable multi-turn conversation.

Синтетический датасет¶

В PoC используется синтетический датасет fashion-v1, концептуально расширенный в сторону FashionCo Group / fashionco-enterprise.

Домен компании:

Премиум одежда / малое-среднее производство;
B2B / B2B2C через дистрибьюторов, бутики, шоурумы и партнеров маркетплейсов;
период данных: 2024-2025;
бизнес-домены связаны в едином enterprise-контуре.

Основные домены данных:

Домен	Содержание
`core`	customers, products, sales orders, order items
`crm`	companies, contacts, deals, activities, tasks
`finance`	invoices, payments, accounts receivable, COGS
`production`	production orders, operations, materials, supplier deliveries
`documents`	document objects, invoice files, metadata
`rag`	RAG documents and chunks
`delivery`	epics, tasks, transitions, rework, cycle time
`itsm`	incidents, SLA, affected services, business impact
`pmo`	roadmap items, milestones, slippage, status reports
`meetings`	decisions, action items, decision-to-action gaps
`goals`	KPI, objectives, ownership, conflicts — target/extension
`semantic`	metric definitions, business entities, calculation rules
`system`	dataset version, runtime metadata
`eval`	scenario truth, expected claims, forbidden claims — not exposed to normal tools

Модель данных¶

Упрощённая ERD-логика:

flowchart LR
    SalesOrder[core.sales_orders] --> SalesItem[core.sales_order_items]
    SalesOrder --> Invoice[finance.invoices]
    SalesOrder --> Payment[finance.payments]
    SalesOrder --> Deal[crm.deals]
    Deal --> Roadmap[pmo.roadmap_items]
    Roadmap --> Epic[delivery.epics]
    Epic --> Task[delivery.tasks]
    Task --> Transition[delivery.task_transitions]
    Roadmap --> Incident[itsm.incidents]
    Roadmap --> Decision[meetings.decisions]
    Decision --> Action[meetings.action_items]
    Document[documents.document_objects] --> Chunk[rag.rag_chunks]
    Chunk --> Roadmap
    Chunk --> Incident
    Chunk --> Decision

API-контракты¶

Agent endpoint¶

POST /agent/check-hypothesis
Content-Type: application/json

Пример запроса:

{
  "question": "Почему в марте 2025 просела валовая маржа?",
  "hypothesis": "Падение маржи связано со скидками",
  "context": {
    "period": "2025-03",
    "domain": "finance"
  }
}

Пример ответа:

{
  "selected_playbook": "financial_operations",
  "verdict": "partially_supported",
  "final_answer": "...",
  "evidence": [
    {
      "type": "metric",
      "tool_id": "metric_gross_margin",
      "period": "2025-03",
      "summary": "gross margin decreased compared with baseline"
    }
  ],
  "tool_calls": [
    {
      "tool_id": "metric_gross_margin",
      "args": { "period": "2025-03" },
      "status": "ok"
    }
  ],
  "limitations": [
    "Analysis is based on synthetic dataset only"
  ]
}

Поле selected_playbook отражает прототипный концепт playbook-routing, а не полноценный playbook engine.

Tool-server health¶

GET /health

Назначение: проверка доступности tool-server.

Gross margin tool¶

POST /tools/metric/gross-margin
Content-Type: application/json

Поддерживаемые формы запроса:

{ "period": "2025-03" }

{ "start_date": "2025-02-01", "end_date": "2025-03-31", "group_by": ["month"] }

Логика расчёта:

revenue = SUM(core.sales_orders.net_amount_rub)
cogs = SUM(core.sales_orders.cogs_amount_rub)
gross_margin = revenue - cogs
gross_margin_rate = gross_margin / revenue

RAG search tool¶

POST /tools/rag-search
Content-Type: application/json

Пример запроса:

{
  "query": "решение по Definition of Ready для промо-функции",
  "filters": {
    "domain": "delivery",
    "source_type": "meeting_minutes",
    "period": "2025-Q1"
  }
}

Ожидаемый ответ:

{
  "status": "ok",
  "results": [
    {
      "document_id": "DOC-PMO-2025-03-12",
      "chunk_id": "CHUNK-001",
      "title": "PMO weekly meeting notes",
      "score": 0.82,
      "object_key": "executive-demo-docs/pmo/2025-03-12.md",
      "snippet": "..."
    }
  ]
}

Архитектура и интеграции¶

Архитектурная идея¶

Архитектура описывает flow прототипа, а не завершённую продуктовую архитектуру.

Пользовательский запрос
→ управляемый execution flow
→ выбор tool
→ вызов backend tool
→ структурированный результат
→ evidence-backed answer
→ execution trace

LLM должна действовать внутри контролируемой backend-mediated tool environment, а не как свободный чат-бот с прямым произвольным доступом к данным.

OpenWebUI
  → экспериментальный LangGraph / FastAPI flow
  → выбор tool / прототипный playbook routing
  → концепт Tool Registry
  → tool-server / Tool Gateway
  → PostgreSQL / Qdrant / MinIO
  → структурированный результат
  → evidence-backed answer
  → execution trace

Это single-request цикл прототипа. Второе сообщение пользователя в Open WebUI не обрабатывалось как продолжение той же аналитической сессии.

Context diagram¶

flowchart TB
    User[Пользователь]
    Prototype[AI Operational Intelligence Prototype]
    Synth[(Синтетические enterprise-данные)]
    Docs[Синтетические документы]
    LLM[OpenAI-compatible LLM]

    User --> Prototype
    Prototype --> Synth
    Prototype --> Docs
    Prototype --> LLM

Диаграмма показывает лабораторный стенд. Реальные коннекторы к ERP, ITSM, PMO или документным системам не реализованы.

Паттерн Tool Gateway¶

Весь доступ к данным идёт через контролируемые HTTP tools с явными input contracts, валидацией, структурированным выводом и metadata.

Прототипный концепт playbooks¶

Прототип исследовал маршрутизацию вопросов в доменные диагностические пути вместо раскрытия LLM всего каталога инструментов сразу.

Каждый домен предполагал ограниченный набор allowed tools, диагностических шагов, ограничений и ожидаемых evidence. Это экспериментальный концепт routing, а не полноценный playbook engine.

Tool Registry¶

Реализован и развивался начальный концепт Tool Registry / описания инструментов как машиночитаемый каталог доступных tools, схем, доменов и ограничений.

Один diagnostic run¶

sequenceDiagram
    autonumber
    participant U as User
    participant UI as OpenWebUI
    participant AG as experimental flow
    participant LLM as LLM
    participant TG as tool-server
    participant PG as PostgreSQL
    participant QD as Qdrant
    participant MN as MinIO

    U->>UI: Аналитический вопрос
    UI->>AG: POST /agent/check-hypothesis
    AG->>LLM: plan next diagnostic step
    LLM-->>AG: selected tool
    AG->>TG: controlled tool call
    TG->>PG: execute named query
    PG-->>TG: metric result
    TG-->>AG: structured result
    AG->>LLM: evaluate evidence
    LLM-->>AG: optional document evidence
    AG->>TG: rag_search
    TG->>QD: vector search with filters
    QD-->>TG: chunks + scores
    TG->>MN: resolve object refs
    MN-->>TG: source metadata
    TG-->>AG: document evidence
    AG->>LLM: synthesize answer with limitations
    AG-->>UI: final answer + run details
    UI-->>U: evidence-backed answer + execution trace

Sequence описывает один запрос. Он не описывает durable conversational loop.

Интеграционные принципы¶

LLM не исполняет SQL.
LLM не читает документы напрямую.
LLM не должна получать полный неограниченный список tools.
Backend / tool-server валидирует входные параметры.
Tools возвращают structured JSON, metadata, warnings и status.
Evidence связывается с tool call, документом, period/entity и claim, где это возможно.
Debug visibility доступна через run details и не должна раскрывать приватные chain-of-thought рассуждения.

Evidence-first answers¶

Итоговые ответы должны опираться на tool outputs, document evidence, расчёты или явно указанные ограничения.

Run trace как слой доверия¶

Каждый diagnostic run на базовом уровне сохраняет выбранный диагностический путь, tool calls, параметры, outputs и run details для отладки и обсуждения.

Подход к evidence и прозрачности¶

Прототип исследовал паттерн evidence и прозрачности: выбранный диагностический путь, tool calls, параметры, результаты инструментов, timeline выполнения, run details и JSON-level debug visibility.

Безопасность, качество и эксплуатация¶

Модель безопасности и доступа¶

Реализовано в PoC¶

Используются только synthetic data.
LLM не получает прямой доступ к PostgreSQL, Qdrant и MinIO.
Доступ к данным идёт через controlled HTTP tools.
Tools имеют явные input contracts.
Финансовые расчёты выполняются named queries / backend logic, а не произвольным SQL от LLM.
В run details видны выбранный диагностический путь, tool calls, inputs и outputs.

Целевая production-модель — не реализована¶

SSO / IdP integration.
RBAC / ABAC.
Tenant isolation.
ACL-aware RAG retrieval.
Tool permissions by diagnostic path, user role and domain.
Read-only mode по умолчанию.
Approval gates для write-действий.
Full audit log: run_id, user_id, tool_id, params hash, result hash, source refs.
Secrets management.
On-prem/private deployment option.

Controlled LLM execution¶

LLM может планировать следующий шаг, но доступ к данным делегирован контролируемым backend tools — не свободному чату над корпоративными данными.

Модель контролируемого доступа к инструментам¶

LLM никогда не обращается к PostgreSQL, Qdrant или MinIO напрямую.

Нефункциональные требования¶

PoC не оценивался и не доказывался против production NFR. Значимые лабораторные ограничения:

демонстрируемый single-request flow;
трассируемость вызовов инструментов;
отсутствие прямого доступа модели к хранилищам данных;
воспроизводимый стенд на Docker Compose;
только синтетические данные.

Режимы отказа¶

Failure mode	Проявление	Комментарий
Неверный routing диагностического пути	Операционный вопрос мог уйти в finance path	Уточнение исследовалось, но ответ пользователя не продолжал ту же сессию
Unsupported question	Вопрос вне покрытия dataset/tools	Явное limitation предпочтительнее выдуманного ответа
Duplicate tool calls	Agent вызывает один и тот же tool с теми же параметрами	Fingerprint `tool_id + canonical_json(args)`, run-local cache
Stub/empty tool response	Tool не вернул данные или вернул заглушку	Status handling, warning, insufficient evidence verdict
Missing RAG evidence	Документальный слой не находит подтверждения	Явное limitation: document evidence not found
Hallucinated conclusion	LLM формулирует вывод без evidence	Evidence-first prompt; evaluation pipeline не реализован
Incomplete cross-domain linkage	Метрики есть, но связь finance ↔ delivery ↔ ITSM не доказана	Нужен более сильный semantic layer; не полностью стабилизировано
External LLM unavailable	API недоступен или лимитирован	Retry/backoff и local-model option — будущая работа
Context overflow	Tool manifest/evidence слишком велики	Context budget, summarization, retrieval filters — ранняя стадия
Data leakage risk	Модель видит лишние данные	Tool-level permissions и no direct data access; production ACL нет

Оценка масштаба и стоимости¶

Текущий PoC рассчитан на демонстрационный режим:

1-3 одновременных пользователя;
единицы diagnostic runs во время демо;
synthetic dataset за период 2024-2025;
десятки/сотни тысяч строк максимум в рамках lab-данных;
один run обычно должен укладываться в 1-10 tool calls;
стоимость определяется LLM API calls и инфраструктурой Docker/VPS/local machine;
production sizing не выполнялся.

Для production потребуются отдельные оценки объёма источников, размера document corpus, частоты ingestion, числа пользователей, RPS, SLA, стоимости LLM routing и требований к private deployment. Эта работа не выполнялась.

Решения, компромиссы и риски¶

Ключевые решения¶

Backend как control plane¶

Backend должен определять доступные tools, permissions, правила валидации, границы исполнения, аудируемость и структуру ответа. LLM не является системой доступа к данным.

Это было прототипировано как лабораторный control plane. Production authentication, authorization и audit не реализованы.

Лабораторный runtime отделён от целевой архитектуры¶

LangGraph и Open WebUI использовались как быстрые лабораторные инструменты для экспериментального execution flow. Целевая продуктовая архитектура предполагала бы backend-native control plane, отдельный UI, Tool Gateway, semantic layer, report service и audit trail.

LangGraph был полезен для single-request tool loop. Он не использовался как durable conversation memory.

Open WebUI как временный интерфейс¶

Open WebUI настроен как временный chat-like интерфейс для демонстрации PoC, а не как целевой executive UI.

Главное ограничение: каждое новое сообщение в Open WebUI фактически обрабатывалось как новый независимый запрос, а не как продолжение текущей аналитической сессии. Даже уточняющий вопрос вроде «какой сценарий вы имели в виду?» не давал рабочего продолжения, когда пользователь отвечал.

См. также Architecture Decision Records.

Прототипный концепт playbooks вместо свободного набора tools¶

Прототип не раскрывал LLM все tools сразу. Диагностический путь должен был задавать доменную рамку и allowed tools. Это осталось прототипным концептом, а не полноценным playbook engine.

Synthetic data вместо реальных корпоративных коннекторов¶

PoC использует синтетический enterprise dataset, чтобы демонстрировать cross-domain диагностику без боевых клиентских данных.

RAG как document evidence, а не замена SQL¶

Структурированные метрики считаются в PostgreSQL/tools. RAG используется для документов, решений, отчётов, протоколов и контекста.

Компромиссы¶

1. Интерфейс¶

Контекст¶

Для PoC нужно быстро показать основной пользовательский сценарий: задать аналитический вопрос, запустить контролируемый tool flow и получить evidence-backed answer.

Принятое решение¶

Open WebUI как временный интерфейс для демонстрации PoC.

Отклонённая альтернатива¶

Разработка собственного UI с нуля на старте потребовала бы отдельного фронтенд-цикла: UX, авторизация, модель доступа, история переписки. Это увеличило бы сроки и отвлекло бы от проверки главной архитектурной гипотезы.

Обоснование¶

Open WebUI позволяет быстро получить рабочий chat-like интерфейс без затрат на frontend-разработку.
Для PoC важнее проверить контролируемую аналитику средствами LLM, чем финальный пользовательский интерфейс.
Open WebUI достаточно для демонстрации базового single-turn сценария: принять вопрос, передать его на обработку, получить ответ.

Компромиссы¶

Open WebUI не дал этому прототипу durable session state.
Детали запуска нужно генерировать на стороне backend и открывать по ссылке.
Open WebUI не показывает целевой исполнительский UX.
Есть риск, что PoC воспринимают как «ещё один чат с LLM».

2. Стек для обвязки и бизнес-логики (harness)¶

Контекст¶

Один запрос требовал планирования, вызова инструментов, оценки достаточности evidence, возможных дополнительных вызовов и финализации ответа.

Принятое решение¶

LangGraph + FastAPI как экспериментальный лабораторный runtime.

Отклонённая альтернатива¶

Java Spring Boot backend — преждевременно.
n8n — недостаточно гибок для ветвлений и динамического формирования контекста.
Dify — оверинжениринг для PoC, тяжеловесная платформа.

Обоснование¶

LangGraph быстро даёт рабочую модель экспериментального процесса: планировщик → запуск инструмента → оценка достаточности → финализация.
FastAPI-обёртка позволяет быстро предоставить конечную точку для Open WebUI и smoke-тестов.
Состояние внутри одного запроса не равно multi-turn состоянию разговора.

Компромиссы¶

LangGraph не должен становиться финальным production-ядром.
Логику workflow позже пришлось бы переносить в продуктовый backend.
Per-request graph state — это не durable conversation memory.

3. Синтетический датасет вместо реальных клиентских интеграций¶

Контекст¶

Для демонстрации подхода нужны связные данные из нескольких доменов: finance, sales, delivery, ITSM, PMO, meetings, documents. Реальные корпоративные данные получить сложно: они чувствительные, грязные, неполные и требуют согласований.

Принятое решение¶

Использовать синтетический корпоративный датасет с заранее заложенными кросс-доменными сценариями и контролируемыми аномалиями.

Отклонённая альтернатива¶

Подключать реальные клиентские системы: ERP, CRM, Jira/YouTrack, ITSM, SharePoint, Confluence, Email, Calendar, DMS.

Обоснование¶

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

Компромиссы¶

PoC не проверяет поведение на грязных, неполных и противоречивых реальных данных.
Не проверены реальные интеграционные проблемы: ACL, версионирование документов, свежесть источников, нестабильные API.
Для пилота потребуется отдельный этап изучения корпоративных систем.

4. Доступ к источникам данных¶

Контекст¶

Ключевой архитектурный принцип PoC: LLM не получает прямой доступ к данным. Все обращения к PostgreSQL, Qdrant и MinIO должны идти через оркестратор и сервер инструментов.

Принятое решение¶

Легковесный FastAPI tool-server

Отклонённая альтернатива¶

Прямой доступ к источникам из обвязки — противоречит ключевой архитектурной концепции.
Tool Gateway продуктового уровня на Java — преждевременно.

Обоснование¶

FastAPI позволяет быстро реализовать контролируемые инструменты.
Каждый tool имеет явный contract: input, validation, output, metadata.
Слой достаточен, чтобы проверить гипотезу: LLM выбирает действие, backend исполняет, результат возвращается как evidence.

Компромиссы¶

Реализация не является зрелой моделью Tool Gateway.
Нет полноценного RBAC/ACL.
Нет approval gates и квот на использование источников.

5. Работа с LLM API¶

Контекст¶

PoC требовал usable reasoning и быстрой итерации. Локальная модель потребовала бы железа и serving-работы раньше, чем проверка архитектуры.

Принятое решение¶

Внешний OpenAI-compatible LLM API

Отклонённая альтернатива¶

Локальная модель через vLLM, Ollama или llama.cpp — нет доступного железа на этапе PoC.

Обоснование¶

Внешний API быстрее подключить.
OpenAI-совместимый интерфейс сохраняет возможность позже заменить провайдера.
PoC не работает с реальными клиентскими данными, поэтому риск внешнего API ниже.

Компромиссы¶

Зависимость от внешнего API, стоимости, задержки и доступности.
Для enterprise-клиентов внешняя LLM может быть неприемлема.
Для реальных корпоративных данных нужна отдельная политика периметра.

ADR опубликованы частично в целях демонстрации.

Основные риски¶

Scope explosion — идея легко расползается в finance, process mining, goal-setting, personal assistant, meeting transcription и daily reports. Нужен жёсткий вертикальный срез.
Недостаток цифровых следов — реальные компании могут не иметь нужных данных, или доступ будет политически закрыт.
Неполная проверяемость — без связи с результатами вызова инструментов ответ может выглядеть убедительно и оставаться слабо проверяемым.
Состояние разговора — без multi-turn session handling уточняющие вопросы не становятся настоящим аналитическим диалогом.
Корпоративная безопасность — production-версия потребует отдельной работы по RBAC, ACL, аудиту, секретам, развёртыванию и сопровождению.