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

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

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

Проверить, может ли 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 можно собрать и продемонстрировать на синтетических данных.