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

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

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