AI Operational Intelligence Prototype — SRS-сборка¶

Эта страница собирает разделы для спецификации требований к ПО: от контекста и проблемы до безопасности, качества и эксплуатации.

Содержание¶

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

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

Статус¶

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

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

Контекст¶

Enterprise AI уже может помогать с синтезом, но свободный LLM-чат поверх корпоративных данных — слабая и небезопасная модель для управленческой аналитики.

В управленческих вопросах важны не только текстовые ответы, но и проверяемость:

на каких данных основан вывод;
какой расчёт был выполнен;
какие документы были использованы;
какие ограничения есть у анализа;
что является фактом, а что — гипотезой;
почему выбран именно этот диагностический путь.

Прототип проверяет, как сделать LLM-based управленческую аналитику контролируемой, трассируемой и пригодной для enterprise-обсуждения.

Проблема¶

Обычная управленческая аналитика часто требует ручной сборки картины из разных источников:

BI-дашбордов;
SQL-выгрузок;
task trackers;
ITSM;
PMO-отчётов;
документов;
протоколов встреч;
экспертных комментариев.

LLM может ускорить синтез, но свободный чат над корпоративными данными создаёт риски:

галлюцинации;
неверный выбор источника;
отсутствие воспроизводимого расчёта;
отсутствие возможности провести аудит вывода;
смешение фактов и интерпретаций;
опасный доступ модели к данным.

Прототип проверял более узкую идею: LLM не должна «отвечать из памяти» и не должна получать прямой доступ к бизнес-данным. Она должна работать внутри контролируемого execution loop: выбрать допустимый tool path, вызвать backend tools, получить структурированный результат, сохранить базовый execution trace и сформировать evidence-backed answer.

Целевое продуктовое направление по-прежнему — прототип системы поддержки принятия решений с проверяемыми доказательствами. Это направление не было доставлено как законченный продукт в рамках данной работы.

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

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

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

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

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

Роль¶

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;
ревью результата;
позиционирование проекта.

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

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

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

Сущность	Роль
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. Эта работа не выполнялась.