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;
способность честно документировать ограничения.

Обзор¶

Обзор прототипа¶

AI Operational Intelligence Prototype — технический прототип управляемого LLM-контура для аналитики на проверяемых данных.

Исходное рабочее название — AI Operational Intelligence Platform / Executive Decision Intelligence. Оно описывало целевое продуктовое направление, а не зрелость реализованного результата.

Прототип проверяет подход к построению управленческой AI-аналитики. Пользователь задаёт аналитический вопрос в chat-like интерфейсе; backend запускает контролируемый execution flow по подготовленным синтетическим данным. LLM должна работать внутри backend-mediated tool environment, а не как свободный чат-бот с произвольным доступом к данным.

Это не production-платформа и не законченный multi-turn продукт поддержки принятия решений. Это экспериментальный прототип enterprise AI-архитектуры, который проверял ограниченную идею управляемого выполнения.

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

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

Технологический стек¶

Слой	Решение в PoC	Назначение
Chat-like UI	Open WebUI	Временный интерфейс для демонстрации
Execution flow	FastAPI + LangGraph	Экспериментальный single-request диагностический flow
Tool execution	FastAPI tool-server	Контролируемые backend tools, валидация, структурированный вывод
Структурированные данные	PostgreSQL	Синтетические finance, delivery, ITSM, PMO, meetings данные
Документное хранилище	MinIO + Qdrant	Направление document evidence для RAG
Runtime/cache	Redis	Поддержка лабораторного runtime
LLM	OpenAI-совместимое API	Планирование и синтез; не источник истины
Infra	Docker Compose	Воспроизводимый лабораторный стенд

Исследованные архитектурные паттерны: Tool Gateway, концепт Tool Registry, прототип playbook-routing, направление RAG, run trace, evidence trail.

Подход к разработке: AI-assisted prototyping, генерация синтетических данных, scenario-driven проверка PoC.

Роль и обязанности¶

Роль¶

System Designer, AI-assisted Prototype Engineer.

Это работа по архитектуре прототипа: перевод enterprise AI-идеи в ограниченный лабораторный стенд, а не ownership production-архитектуры.

Зона ответственности¶

перевод продуктовой идеи в архитектурную модель прототипа;
формулировка концепта контролируемого цикла работы с LLM;
выбор временного стека для лаборатории PoC;
проектирование синтетического датасета;
проектирование прототипного playbook / diagnostic-path подхода;
проектирование модели контролируемого доступа к инструментам (см. Безопасность и модель доступа);
реализация и развитие начального концепта Tool Registry (см. Архитектура);
подготовка синтетических enterprise demo-данных (см. Доменная модель);
развитие подхода evidence и прозрачности (см. Интеграционные принципы);
настройка Open WebUI как временного chat-like интерфейса (см. Компромиссы);
фиксация ограничений, включая отсутствие рабочего multi-turn цикла сессии;
описание будущего направления к отчётам, карточкам сигналов, evidence view и backend-native orchestration. Эти пункты не были реализованы.

Выполненные работы¶

спроектировал архитектуру прототипа: chat-like harness, экспериментальный execution flow, концепт маршрутизации диагностических путей, слой инструментов, слой синтетических данных, направление document evidence и execution trace;
построил лабораторный FastAPI + LangGraph runtime для экспериментальных single-request диагностических flow;
зафиксировал принцип: LLM не обращается напрямую к PostgreSQL, Qdrant или MinIO;
реализовал / заложил контролируемый запуск инструментов через FastAPI tool-server;
подготовил синтетический датасет для fashion/retail/manufacturing-компании;
расширил датасет в сторону кросс-доменной диагностики: finance, delivery, ITSM, PMO, meetings, documents;
зафиксировал целевое направление, не выдавая его за уже доставленный scope.

Применение ИИ¶

Проект разрабатывался с использованием AI-assisted prototyping.

LLM использовались для ускорения:

генерации черновиков кода;
подготовки synthetic data;
подготовки промптов и логики процессов;
анализа вариантов архитектуры;
подготовки документации;
генерации черновиков тестовых сценариев.

Ключевые решения оставались под ручным контролем:

архитектурные границы;
модель доступа к данным;
выбор лабораторного и целевого runtime;
требования к проверяемости;
структура синтетического датасета;
смысл диагностических путей;
ограничения PoC;
ревью результата;
позиционирование проекта.

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

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

Архитектура описывает 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.

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

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

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, аудиту, секретам, развёртыванию и сопровождению.

Дорожная карта и демонстрация¶

Дорожная карта¶

Фаза	Цель	Exit criteria
v0.1 Lab PoC	Показать controlled LLM execution	Запрос → диагностический путь → вызовы tools → ответ + run details. ПРОТОТИПИРОВАНО
v0.2 Стабилизированный запуск	Стабилизировать один финансовый и один операционный сценарий	Демо проходит без ручной подмены результата. ПРОТОТИПИРОВАНО
v0.3 Документальный доказательный слой	Усилить evidence через RAG	Ответ может ссылаться на документы/чанки. ПРОТОТИПИРОВАНО как направление
v0.4 Tool Registry v0.1	Увести захардкоженные инструменты в сторону registry	Инструменты описаны через манифест; отдельный tool-server. ПРОТОТИПИРОВАНО как начальный концепт
v0.5 Исполнительный отчет	Перейти от chat answer к report artifact	Executive brief + signal cards + evidence appendix. НЕ РЕАЛИЗОВАНО
v0.6 Cross-domain scenario	Показать цепочку finance → delivery → ITSM → PMO	Прототип может исследовать заложенную кросс-доменную причину. ИССЛЕДОВАНО, НЕ ПОЛНОСТЬЮ СТАБИЛИЗИРОВАНО
v1 Настоящий MVP	См. ниже	Не достигнуто

Следующий шаг к MVP¶

Чтобы стать настоящим MVP, прототипу потребовались бы:

multi-turn session state;
корректная обработка уточняющих вопросов;
продолжение того же аналитического run;
persisted run/session context;
более формальная schema для tool registry;
evaluation harness;
read-only connectors к реалистичным enterprise data sources;
authentication and authorization model;
audit and observability layer;
demo-сценарии с measurable expected outcomes.

Текущая работа — technical PoC / рабочий прототип. Это ещё не настоящий MVP.

Demo-сценарии¶

Сценарии ниже — это single-turn аналитические запросы на синтетических данных. Они показывают intended flow, а не законченный conversational product.

Сценарий 1. Финансовая диагностика¶

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

Почему в марте 2025 просела валовая маржа?

Ожидаемый flow прототипа: направить вопрос в финансовый диагностический путь, вызвать metric tools для gross margin, revenue, discounts, COGS и product mix, затем сформировать структурированное резюме с evidence и ограничениями.

Сценарий 2. Операционная диагностика¶

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

Почему time-to-market нестабилен, хотя локальные KPI команд выглядят нормально?

Ожидаемый flow прототипа: направить вопрос в операционный диагностический путь и посмотреть delivery, PMO, ITSM, решения встреч и связанные evidence на кросс-функциональные узкие места, которые плохо видны в изолированных KPI-дашбордах.

Сценарий 3. Кросс-доменная диагностика¶

Целевой вопрос:

Почему во втором квартале просела маржа online-канала, если продажи и локальные KPI digital-команд выглядели нормально?

Целевая диагностическая цепочка:

маржа ↓
-> скидочное давление ↑
-> задержка промо-сегментации
-> rework в delivery
-> инциденты stock availability integration
-> PMO status green illusion
-> решение по DoR не стало action item
-> управленческий вывод с evidence trail

Статус: целевой demo-flow; исследован, но требует стабилизации cross-domain linkage и качества evidence.

Скриншоты и демо¶

«Что ты умеешь?»¶

UI_1 — Прототипный каталог диагностических путей и tools

Финансовый диагностический путь: гипотеза о падении валовой маржи¶

UI_2 — Диагностика финансовых показателей: гипотеза падения маржи

UI_3 — Диагностика финансовых показателей: отчёт об использовании

UI_4 — Диагностика финансовых показателей: вызванные инструменты и run details

Операционный диагностический путь: аномалии KPI¶

UI_5 — Диагностика операционных аномалий на стыке delivery, ITSM, PMO и документов

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

Проект показывает способность взять неоднозначную enterprise AI-идею и превратить её в ограниченный, демонстрируемый прототип.

Он демонстрирует:

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

Главная ценность — не «использование LLM». Главная ценность — проектирование системы, где AI-рассуждение ограничено архитектурой, evidence, контрактами инструментов и аудируемостью, и явное описание того, что прототип реализовал, а чего не реализовал.