Техническое задание: Платформа MONAECO MVP

Единое пространство научных знаний для нефтегазовой отрасли и экологии

Версия: 1.1 Дата: 12 марта 2026 Заказчик: RBC MONAECO Исполнитель: Команда разработки AiDevTeam

Содержание

Общие сведения
Цели и задачи
Границы MVP
Архитектура системы
Технологический стек
Компоненты системы
Модель данных
API
Пользовательский интерфейс
Пользовательские сценарии
Предварительные исследования
Команда проекта
Бюджет
Взаимодействие с заказчиком
План спринтов
Тестирование
Развёртывание и инфраструктура
Интеграция с Knowdy (этап 2)
Риски и митигации
Критерии приёмки MVP
Дополнительные возможности
Открытые вопросы для заказчика
Глоссарий

1. Общие сведения

1.1. Наименование системы

MONAECO — платформа единого пространства научных знаний (Ноосфера) для нефтегазовой отрасли и экологии.

1.2. Основание для разработки

Решение руководства клуба RBC MONAECO о создании IT-платформы для интеграции научных, технических и экологических знаний участников клуба.

1.3. Заказчик

RBC MONAECO — международный бизнес-клуб, объединяющий компании нефтегазовой отрасли, экологические организации и научные институты.

1.4. Исполнитель

Команда разработки AiDevTeam (состав — см. раздел 12).

1.5. Техконтакт со стороны заказчика

Дмитрий Дмитриев — автор графовой БД Knowdy, технический визионер проекта.

2. Цели и задачи

2.1. Бизнес-цель

Создать единую платформу, где знания из разрозненных источников (документация компаний, стандарты, научные статьи, отчёты) объединены в семантический граф и доступны участникам на трёх языках.

2.2. Технические задачи

#	Задача	Описание
Т1	Семантический граф знаний	Граф, хранящий концепты, факты и связи из предметных областей нефтегаза и экологии
Т2	Мультиязычный тезаурус	Единый словарь концептов с метками на EN, RU, ZH
Т3	Автоматическая разметка контента	Агенты, извлекающие из документов концепты и факты → загрузка в граф
Т4	Семантический поиск	Поиск по смыслу (не по ключевым словам): запрос → концепты → граф → ответ
Т5	Генерация текста на 3 языках	Факты из графа → человекочитаемый текст на выбранном языке
Т6	Управление достоверностью	Провенанс каждого факта, рейтинги доверия, отображение противоречий
Т7	Визуализация	Графы знаний, карты, инфографика
Т8	Формальные модели процессов	Формальное описание производственных процессов нефтегаза с экологическими метриками в RDF (см. вопрос В5)

3. Границы MVP

3.1. Включено в MVP

Параметр	Значение
Языки интерфейса	EN, RU, ZH
Отрасль	Нефтегазовая + экология
Объём контента	Десятки единиц (документы, стандарты, статьи)
Количество компаний	До 10
Тип приложения	SPA (веб-приложение)
Карты	OpenStreetMap
Пользовательские роли	Читатель, Эксперт, Администратор

3.2. Исключено из MVP

Языки с RTL-письмом (арабский, иврит)
Пользовательский чат / мессенджер
Мобильное приложение (только адаптивная вёрстка)
Монетизация контента / платный доступ
Интеграция с Knowdy (запланирована на этап 2 — см. раздел 18)

3.3. Структура функциональности: ядро и опции

Функциональность MVP разделена на ядро (минимально необходимое для запуска платформы) и опции (расширения, которые заказчик может включить в MVP или отложить). План спринтов (раздел 15) описывает полный вариант (ядро + все опции). Заказчик выбирает набор опций — от этого зависят сроки и бюджет.

Ядро MVP — без этих компонентов платформа не может функционировать

#	Компонент	Описание
Я1	Графовое хранилище	Oxigraph + SPARQL 1.1 endpoint + Named Graphs
Я2	Онтологический фундамент	BFO + CCO + ENVO/ChEBI/QUDT/IOF Core (подмножества) + каркас monaeco:OilGasOntology (30–40 классов)
Я3	Мультиязычный тезаурус	GEMET (импорт) + 200–500 нефтегазовых концептов (SKOS)
Я4	SHACL-валидация	Проверка данных при импорте
Я5	Агент разметки контента	PDF/DOCX → NER (EN + RU) → RDF-триплеты → загрузка в граф
Я6	Базовый поиск	Поиск по концептам тезауруса → SPARQL-шаблоны → результаты
Я7	Базовый NLG	Шаблонный (Jinja2 + pymorphy3), Вариант A
Я8	Базовый провенанс	PROV-O: каждый факт привязан к источнику
Я9	SPA-приложение	Главная, поиск, карточки концептов, профили компаний
Я10	i18n	Интерфейс на EN/RU/ZH
Я11	Аутентификация и роли	JWT + 3 роли (Читатель, Эксперт, Администратор)
Я12	Инфраструктура	Docker Compose, CI/CD, staging-сервер

Оценка ядра: ~14 недель спринтов (~3.5 месяца) + 5 недель исследований.

Опции MVP — расширяют функциональность, выбираются заказчиком

#	Опция	Описание	Трудоёмкость	Зависимости
О1	Расширенный NLG	LLM-grounded генерация с валидацией (Вариант C/D)	~2 нед.	Я7
О2	Семантический поиск NL→SPARQL	Полный пайплайн: NL → разбор → концепты → SPARQL + semantic expansion	~2 нед.	Я6
О3	Агент обнаружения концептов	Выявление новых терминов, кластеризация, очередь для эксперта	~1.5 нед.	Я5
О4	Агент формирования онтологии	Предложение новых классов и свойств на основе данных	~1 нед.	О3
О5	NLP для китайского	spaCy `zh_core_web_trf`, NER на ZH	~1 нед.	Я5
О6	Визуализация графов	D3.js force-directed, интерактивный подграф	~1.5 нед.	Я9
О7	Карта объектов	Leaflet + OpenStreetMap, маркеры, кластеризация	~1 нед.	Я9
О8	Фасетная навигация	Фильтры по отрасли, географии, типу контента, дате, достоверности	~1 нед.	Я6
О9	Обнаружение противоречий	OWL reasoner находит конфликты, UI отображает оба значения	~1 нед.	Я8
О10	Экспертная панель	Очередь кандидатов в концепты, approve/reject, редактирование тезауруса	~1.5 нед.	О3
О11	Экспорт	CSV результатов поиска + PDF-отчёт по компании	~1 нед.	Я6
О12	Администрирование + аудит	Управление пользователями, статистика, журнал действий	~1.5 нед.	Я11
О13	Формальная модель процесса	Цепочка «добыча → переработка → выбросы» в RDF + визуализация	~1.5 нед.	Я2

Полный MVP (ядро + все опции): ~21 неделя спринтов (~5 месяцев) — как описано в плане спринтов.

Примеры конфигураций MVP

Конфигурация	Опции	Спринтов	Недель	Прим. стоимость
Ядро (минимум)	—	7	~14	~8.5M руб
Ядро + поиск + NLG	О1, О2	9	~18	~11M руб
Ядро + визуализация	О6, О7, О8	9	~18	~11M руб
Ядро + экспертные инструменты	О3, О9, О10	9	~18	~11M руб
Полный MVP	О1–О13	10	~21	~15M руб

Примечание: Стоимость приблизительная, зависит от выбранной комбинации опций. Заказчик может выбрать произвольный набор опций с учётом графа зависимостей (ниже). Точный расчёт — после согласования набора.

Граф зависимостей

flowchart LR
    subgraph Core["🟢 ЯДРО"]
        Y1["Я1<br/>Графовое<br/>хранилище"]
        Y2["Я2<br/>Онтологии"]
        Y3["Я3<br/>Тезаурус"]
        Y5["Я5<br/>Агент<br/>разметки"]
        Y6["Я6<br/>Базовый<br/>поиск"]
        Y7["Я7<br/>Базовый<br/>NLG"]
        Y8["Я8<br/>Провенанс"]
        Y9["Я9<br/>SPA"]
        Y11["Я11<br/>Auth"]
    end

    subgraph Options["🔵 ОПЦИИ"]
        O1["О1<br/>Расш. NLG"]
        O2["О2<br/>NL→SPARQL"]
        O3["О3<br/>Обнаруж.<br/>концептов"]
        O4["О4<br/>Формир.<br/>онтологии"]
        O5["О5<br/>NLP ZH"]
        O6["О6<br/>Граф D3"]
        O7["О7<br/>Карта"]
        O8["О8<br/>Фасеты"]
        O9["О9<br/>Противор."]
        O10["О10<br/>Эксп.<br/>панель"]
        O11["О11<br/>Экспорт"]
        O12["О12<br/>Админ"]
        O13["О13<br/>Модель<br/>процесса"]
    end

    Y7 --> O1
    Y6 --> O2
    Y5 --> O3
    O3 --> O4
    Y5 --> O5
    Y9 --> O6
    Y9 --> O7
    Y6 --> O8
    Y8 --> O9
    O3 --> O10
    Y6 --> O11
    Y11 --> O12
    Y2 --> O13

    style Core fill:#e8f5e9,stroke:#2E7D32
    style Options fill:#e3f2fd,stroke:#1565C0

Примечание: Трудоёмкость опций указана в разработческих неделях и предполагает параллельную работу бэкенда и фронтенда. Стоимость будет добавлена после согласования набора опций с заказчиком.

4. Архитектура системы

4.1. Общая схема

graph TB
    subgraph Users["👤 ПОЛЬЗОВАТЕЛИ"]
        Browser["Браузер · SPA"]
    end

    subgraph Frontend["ФРОНТЕНД"]
        Vue["Vue.js 3<br/>SPA · роутинг · i18n"]
        D3["D3.js<br/>графы · инфографика"]
        Maps["OpenStreetMap<br/>карты · геоданные"]
    end

    subgraph Backend["БЭКЕНД · Python FastAPI"]
        Auth["Аутентификация<br/>и авторизация"]
        Router["Маршрутизация<br/>запросов"]
        Cache["Кэширование<br/>Redis"]
    end

    subgraph Services["СЕРВИСЫ"]
        Search["Поисковый<br/>движок"]
        NLG["NLG-модуль"]
        Markup["Агент<br/>разметки"]
        Concepts["Агент<br/>концептов"]
        Prov["Модуль<br/>достоверности<br/>PROV-O"]
    end

    subgraph Storage["ГРАФОВОЕ ХРАНИЛИЩЕ · Oxigraph"]
        direction LR
        subgraph Ontologies["Онтологии"]
            BFO["BFO + CCO"]
            ENVO["ENVO + ChEBI"]
            ISO["ISO 15926 + IOF"]
        end
        subgraph Data["Данные"]
            GEMET["GEMET"]
            Companies["Компании 1..N"]
            ProvG["PROV · провенанс"]
            SSSOM_G["SSSOM · маппинги"]
        end
    end

    Browser -->|HTTPS| Frontend
    Frontend -->|"REST / WebSocket"| Backend
    Backend --> Services
    Services -->|SPARQL 1.1| Storage

    style Users fill:#e8f4f8,stroke:#2196F3
    style Frontend fill:#e8f5e9,stroke:#4CAF50
    style Backend fill:#fff3e0,stroke:#FF9800
    style Services fill:#fce4ec,stroke:#E91E63
    style Storage fill:#f3e5f5,stroke:#9C27B0

WebSocket используется для: (1) отображения прогресса обработки документов в реальном времени (загрузка → парсинг → NER → RDF → валидация), (2) уведомлений экспертной очереди (новые кандидаты в концепты).

4.2. Принципы архитектуры

Стандарты W3C — все данные в RDF/OWL, все запросы через SPARQL
Named Graphs — каждая онтология и каждый источник данных в отдельном именованном графе
Stateless бэкенд — вся бизнес-логика в сервисах, состояние в графе
Контейнеризация — все компоненты в Docker, оркестрация через Docker Compose (MVP) / Kubernetes (production)
Подготовка к интеграции с Knowdy — абстракция хранилища через интерфейс, замена без переписывания

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

5.1. Хранение данных

Компонент	Технология	Версия	Лицензия	Назначение
Графовая БД	Oxigraph	0.4+	MIT	RDF-хранилище + SPARQL 1.1 endpoint
OWL Reasoner	Openllet	2.6+	Apache 2.0	Логический вывод (OWL 2 DL). MVP: через owlready2 (Python). При необходимости масштабирования — отдельный Java-контейнер
Кэш	Redis	7+	BSD-3	Кэширование SPARQL-запросов

5.2. Онтологии и стандарты

Компонент	Стандарт	Назначение
Верхний уровень	BFO (ISO 21838-2)	Фундаментальные категории (объекты, процессы)
Средний уровень	CCO (Common Core Ontologies)	Агенты, артефакты, события, информация
Экология	ENVO + ChEBI + QUDT	Среды, химические вещества, единицы измерения
Нефтегаз	ISO 15926 + IOF Core	Оборудование, производственные процессы
Мультиязычность	GEMET (SKOS) + OntoLex-Lemon	Тезаурус (37 языков) + лексическая привязка
Маппинги	SSSOM	Межонтологические соответствия
Провенанс	W3C PROV-O	Происхождение и жизненный цикл фактов
Валидация	SHACL	Проверка структуры при импорте данных

5.3. Бэкенд

Компонент	Технология	Назначение
API Gateway	Python 3.12 + FastAPI	REST API, маршрутизация, аутентификация
NLP-пайплайн	spaCy + модели для EN/RU/ZH	Извлечение концептов, NER, связей
NLG-движок	Шаблонный NLG (Jinja2 + pymorphy3)	Генерация текста из графа на 3 языках (см. вопрос В3)
Очередь задач	Celery + Redis	Асинхронная обработка документов
Поисковый движок	Python + SPARQL	NL → SPARQL трансляция

5.4. Фронтенд

Компонент	Технология	Назначение
Фреймворк	Vue.js 3 + TypeScript	SPA, компонентная архитектура
Роутинг	Vue Router	Навигация
Состояние	Pinia	Управление состоянием
Визуализация графов	D3.js v7	Интерактивные графы знаний
Карты	Leaflet + OpenStreetMap	Геоданные, локации объектов
UI-библиотека	PrimeVue	Компоненты интерфейса (лучшая i18n-поддержка, легковесность, оптимален для data-heavy UI)
i18n	Vue I18n	Локализация EN/RU/ZH

5.5. Инфраструктура

Компонент	Технология	Назначение
Контейнеризация	Docker + Docker Compose	Локальная разработка и MVP-деплой
CI/CD	GitHub Actions	Автоматические тесты, сборка
Мониторинг	Prometheus + Grafana	Метрики, алерты
Логирование	Loki + Grafana	Централизованные логи

6. Компоненты системы

6.1. Графовое хранилище

Назначение: Хранение всех знаний платформы в виде RDF-графа с поддержкой SPARQL-запросов и OWL-рассуждений.

Функции:

Хранение RDF-триплетов в Named Graphs
SPARQL 1.1 Query и Update
Полнотекстовый поиск по литералам (SPARQL CONTAINS, REGEX)
Поддержка GeoSPARQL (пространственные запросы — критично для карт)
OWL-рассуждения через Openllet (транзитивность, наследование, disjoint)
SHACL-валидация при импорте

Структура Named Graphs:

Graph URI	Содержимое	Обновление
`monaeco:ontology/bfo`	BFO 2020	Редко (стандарт)
`monaeco:ontology/cco`	Common Core Ontologies	Редко
`monaeco:ontology/envo`	Environment Ontology	Раз в квартал
`monaeco:ontology/chebi`	Chemical Entities	Раз в квартал
`monaeco:ontology/iso15926`	ISO 15926 RDL (подмножество)	Редко
`monaeco:ontology/iof`	IOF Core Ontology	Редко
`monaeco:ontology/oilgas`	Наша нефтегазовая онтология	По мере развития
`monaeco:thesaurus/gemet`	GEMET на 3 языках	Раз в год
`monaeco:thesaurus/monaeco`	Наш тезаурус	Постоянно
`monaeco:mappings`	SSSOM маппинги	По мере развития
`monaeco:data/{company_id}`	Данные компании N	При загрузке
`monaeco:provenance`	PROV-O метаданные	При каждой операции

Примерный объём MVP: ~500K — 2M триплетов (онтологии + тезаурус + данные 10 компаний).

graph LR
    subgraph Ontologies["🔷 Онтологии (редко меняются)"]
        BFO["monaeco:ontology/bfo<br/>BFO 2020"]
        CCO["monaeco:ontology/cco<br/>CCO"]
        ENVO["monaeco:ontology/envo<br/>ENVO"]
        ChEBI["monaeco:ontology/chebi<br/>ChEBI"]
        ISO["monaeco:ontology/iso15926<br/>ISO 15926"]
        IOF["monaeco:ontology/iof<br/>IOF Core"]
        OG["monaeco:ontology/oilgas<br/>🛢️ Наша онтология"]
    end

    subgraph Thesauri["🟢 Тезаурусы"]
        GEMET["monaeco:thesaurus/gemet<br/>GEMET · 3 языка"]
        MT["monaeco:thesaurus/monaeco<br/>Наш тезаурус"]
    end

    subgraph CompanyData["🟠 Данные компаний"]
        C1["monaeco:data/company_1"]
        C2["monaeco:data/company_2"]
        CN["monaeco:data/company_N"]
    end

    subgraph Meta["🟣 Метаданные"]
        PROV["monaeco:provenance<br/>PROV-O"]
        SSSOM_G["monaeco:mappings<br/>SSSOM"]
    end

    style Ontologies fill:#e3f2fd,stroke:#1565C0
    style Thesauri fill:#e8f5e9,stroke:#2E7D32
    style CompanyData fill:#fff3e0,stroke:#E65100
    style Meta fill:#f3e5f5,stroke:#9C27B0

6.2. Онтологический слой

Назначение: Формальное описание предметной области — классы, свойства, аксиомы — на основе которого работает вся система.

Архитектура онтологий (снизу вверх):

block-beta
    columns 1

    block:L4["Уровень 4 · Данные компаний"]:1
        D1["Объекты"] D2["Измерения"] D3["Отчёты"]
    end

    space

    block:L3["Уровень 3 · Доменные онтологии (наша задача)"]:1
        OG["monaeco:OilGasOntology<br/>скважины · месторождения<br/>процессы · выбросы"]
        EC["monaeco:EcologyOntology<br/>экосистемы · загрязнители<br/>LCA-метрики"]
    end

    space

    block:L2["Уровень 2 · Стандартные доменные"]:1
        ENVO["ENVO<br/>экология"]
        ISO15926["ISO 15926<br/>оборудование"]
        IOF["IOF Core<br/>процессы"]
        ChEBI["ChEBI<br/>химия"]
        QUDT["QUDT<br/>единицы"]
    end

    space

    block:L1["Уровень 1 · Средний уровень"]:1
        CCO["CCO — Common Core Ontologies<br/>агенты · артефакты · события · информация"]
    end

    space

    block:L0["Уровень 0 · Верхний уровень"]:1
        BFO["BFO — Basic Formal Ontology<br/>40 классов · ISO 21838-2"]
    end

    L4 -- "экземпляры классов" --> L3
    L3 -- "расширяют" --> L2
    L2 -- "расширяют" --> L1
    L1 -- "расширяет" --> L0

    style L4 fill:#e3f2fd,stroke:#1565C0
    style L3 fill:#e8f5e9,stroke:#2E7D32,stroke-width:3px
    style L2 fill:#fff8e1,stroke:#F9A825
    style L1 fill:#fce4ec,stroke:#C62828
    style L0 fill:#f3e5f5,stroke:#6A1B9A

Наша задача — создать уровень 3:

Классы monaeco:OilGasOntology (примеры):

monaeco:Well (скважина) — подкласс iof:MaterialArtifact
monaeco:OilField (месторождение) — подкласс envo:GeologicalFormation
monaeco:DrillingProcess — подкласс iof:PlannedProcess
monaeco:EmissionEvent — подкласс bfo:Process
monaeco:GHGEmission (выбросы Scope 1/2/3) — с привязкой к GRI 11
monaeco:WasteStream (поток отходов) — роли WasteRole / RawMaterialRole (CEON)
monaeco:FlaringProcess (факельное сжигание)
monaeco:ProducedWater (пластовая вода)

Свойства:

monaeco:hasEmissionScope — Scope 1, 2, 3
monaeco:measuredIn → QUDT единица
monaeco:locatedAt → GeoSPARQL координаты
monaeco:operatedBy → компания (prov:Agent)

6.3. Мультиязычный тезаурус

Назначение: Единый словарь концептов, обеспечивающий мультиязычность платформы на уровне понятий (не переводов).

Структура:

monaeco:concept/crude-oil a skos:Concept ;
    skos:prefLabel "Crude oil"@en ;
    skos:prefLabel "Сырая нефть"@ru ;
    skos:prefLabel "原油"@zh ;
    skos:altLabel "Petroleum"@en ;
    skos:altLabel "Нефть"@ru ;
    skos:definition "Naturally occurring liquid petroleum"@en ;
    skos:broader monaeco:concept/hydrocarbon ;
    skos:exactMatch <http://www.eionet.europa.eu/gemet/concept/1698> ;
    ontolex:isEvokedBy monaeco:lexicon/en/crude-oil .

Объём MVP: ~2 000–5 000 концептов (импорт из GEMET + расширение нефтегазовой терминологией).

Источники:

GEMET (базовый импорт, 5 200 концептов, EN/RU уже есть)
SPE Glossary (нефтегаз, EN → перевод на RU/ZH)
IOGP Terminology
Термины из загружаемых документов (обнаружение агентом)

6.4. Агент разметки контента

Назначение: Автоматическое извлечение знаний из входящих документов и загрузка в граф.

Пайплайн:

flowchart TD
    Doc["📄 Документ<br/>PDF / DOCX / HTML / CSV"]
    Extract["1. Извлечение текста<br/><i>Apache Tika · python-docx · BeautifulSoup</i>"]
    Segment["2. Сегментация на микро-топики<br/><i>заголовки · абзацы · таблицы → блоки</i>"]
    NER["3. NER + извлечение сущностей<br/><i>spaCy: организации · локации · вещества</i>"]
    Link["4. Связывание с тезаурусом<br/><i>fuzzy matching + embedding → skos:Concept</i>"]
    Rel["5. Извлечение отношений<br/><i>dependency parsing: X эксплуатирует Y</i>"]
    RDF["6. Формирование RDF-триплетов<br/><i>сущности → классы · связи → свойства</i>"]
    SHACL["7. SHACL-валидация<br/><i>проверка соответствия схеме</i>"]
    Load["8. Загрузка в Named Graph<br/><i>SPARQL UPDATE + PROV-O метаданные</i>"]
    Graph[("🗄️ Oxigraph<br/>Named Graph")]

    Doc --> Extract --> Segment --> NER --> Link --> Rel --> RDF --> SHACL
    SHACL -->|✅ валидация пройдена| Load --> Graph
    SHACL -->|❌ ошибки| Review["👤 Ручная проверка"]
    Review -->|исправлено| RDF

    style Doc fill:#e3f2fd,stroke:#1565C0
    style Graph fill:#f3e5f5,stroke:#9C27B0
    style SHACL fill:#fff8e1,stroke:#F9A825
    style Review fill:#fce4ec,stroke:#C62828

Входные форматы: PDF, DOCX, HTML, CSV/Excel (таблицы).

Языки NLP: EN (spaCy en_core_web_trf), RU (spaCy ru_core_news_lg), ZH (spaCy zh_core_web_trf).

Режимы работы:

Автоматический — полностью автоматическая разметка, результат в статусе «черновик»
С подтверждением — разметка + отправка эксперту на проверку

6.5. Агент обнаружения концептов

Назначение: Выявление новых терминов и понятий, отсутствующих в тезаурусе.

Алгоритм:

При разметке документа NER находит сущности
Сущности сопоставляются с тезаурусом (fuzzy match, порог 0.85)
Несопоставленные сущности → кандидаты в новые концепты
Кластеризация кандидатов (один и тот же термин из разных документов)
Предложение эксперту: термин + контекст + предполагаемый родитель в иерархии
Эксперт подтверждает / редактирует / отклоняет → обновление тезауруса

Интерфейс эксперта: Очередь кандидатов, предложенные метки на 3 языках, место в иерархии SKOS.

6.6. Агент формирования онтологии

Назначение: Помощь в расширении онтологии — предложение новых классов, свойств и аксиом.

Функции:

Анализ частотности паттернов в данных → предложение новых классов
Обнаружение неформализованных связей между сущностями
Предложение owl:disjointWith, domain/range constraints
Валидация консистентности через Openllet reasoner

Режим работы: Только с подтверждением эксперта. Агент предлагает, эксперт решает.

6.7. Поисковый движок

Назначение: Семантический поиск — пользователь задаёт вопрос на естественном языке, система возвращает факты из графа (не ссылки на документы).

Архитектура:

flowchart LR
    Q["🔍 Запрос<br/>на естественном языке"]

    subgraph Pipeline["Обработка запроса"]
        direction TB
        Parse["1. Разбор запроса<br/><i>NLP → сущности · намерение · фильтры</i>"]
        Map["2. Маппинг на тезаурус<br/><i>нефтяные скважины → monaeco:Well</i>"]
        SPARQL["3. Генерация SPARQL<br/><i>шаблоны + подстановка концептов</i>"]
        Exec["4. Выполнение SPARQL<br/><i>Oxigraph → триплеты</i>"]
        Rank["5. Ранжирование<br/><i>PROV-O trust weights</i>"]
        NLG["6. Формирование ответа<br/><i>NLG → текст + визуализация</i>"]
    end

    R["📊 Результат<br/>факты · источники · графики"]

    Q --> Parse --> Map --> SPARQL --> Exec --> Rank --> NLG --> R

    style Q fill:#e3f2fd,stroke:#1565C0
    style R fill:#e8f5e9,stroke:#2E7D32
    style Pipeline fill:#fafafa,stroke:#9E9E9E

Типы запросов:

Фактический: «Какой объём выбросов CO₂ у компании X?» → конкретное число + источник
Сравнительный: «Сравни выбросы компаний X и Y» → таблица + диаграмма
Навигационный: «Покажи все месторождения в регионе Z» → карта + список
Обзорный: «Что известно о технологии CCS?» → структурированный обзор

Фасетная навигация:

По отрасли / компании
По географии (на карте)
По типу контента (стандарт / статья / отчёт)
По концепту онтологии (дерево)
По дате / периоду
По уровню достоверности

6.8. NLG-модуль

Назначение: Генерация текста из фактов графа на трёх языках — детерминированная, с прослеживаемостью каждого утверждения до исходных данных.

Примечание: Стратегия NLG является открытым вопросом для согласования с заказчиком (см. вопрос В3). Ниже описан базовый вариант (шаблонный NLG). Альтернативы и их сравнение — в разделе 22.

Базовый стек MVP (шаблонный NLG):

flowchart TD
    Facts["🗃️ Факты из графа<br/>RDF-триплеты"]
    Plan["1. Макропланирование<br/><i>отбор фактов · порядок изложения</i>"]
    Template["2. Шаблонизация · Jinja2<br/><i>выбор шаблона: фактоид · сравнение · обзор</i>"]

    subgraph Morph["3. Морфологическая реализация"]
        EN["🇬🇧 EN<br/>шаблоны<br/><i>морфология минимальна</i>"]
        RU["🇷🇺 RU<br/>pymorphy3<br/><i>склонение · спряжение</i>"]
        ZH["🇨🇳 ZH<br/>шаблоны<br/><i>изолирующий язык</i>"]
    end

    Polish["4. Стилистическая полировка<br/><i>⚡ опционально: LLM · факты НЕ изменяются</i>"]
    Result["📝 Текст на выбранном языке"]

    Facts --> Plan --> Template --> Morph --> Polish --> Result

    style Facts fill:#f3e5f5,stroke:#9C27B0
    style Morph fill:#e8f5e9,stroke:#4CAF50
    style Polish fill:#fff8e1,stroke:#F9A825,stroke-dasharray: 5 5
    style Result fill:#e3f2fd,stroke:#1565C0

Пример:

Факт в графе:

monaeco:well/W-42 a monaeco:Well ;
    monaeco:operatedBy monaeco:company/gazprom ;
    monaeco:locatedAt monaeco:region/yamalo-nenets ;
    monaeco:annualProduction [
        qudt:numericValue 1.2 ;
        qudt:unit qudt:MegaTON-PER-YR
    ] .

Генерация:

EN: "Well W-42, operated by Gazprom, is located in Yamalo-Nenets region and produces 1.2 megatonnes per year."
RU: "Скважина W-42, эксплуатируемая Газпромом, расположена в Ямало-Ненецком округе и добывает 1,2 мегатонны в год."
ZH: "W-42号井由Gazprom运营，位于亚马尔-涅涅茨地区，年产量120万吨。"

Альтернативные стратегии NLG (выбор зависит от решения заказчика — см. вопрос В3):

Вариант	Подход	Качество текста	Детерминированность	Сложность внедрения
A. Шаблоны + pymorphy3	Jinja2 + морфологический движок	Среднее	100%	Низкая
B. Grammatical Framework	Абстрактная грамматика → линеаризация	Высокое	100%	Высокая (Haskell)
C. LLM-grounded	Факты → LLM → текст + валидация	Отличное	С гарантиями (см. В3)	Средняя
D. Гибрид	Шаблоны для данных + LLM для нарратива	Отличное	Данные — 100%, нарратив — с гарантиями	Средняя

6.9. Модуль достоверности и провенанса

Назначение: Отслеживание происхождения каждого факта, управление доверием, отображение противоречий.

Стандарт: W3C PROV-O.

Модель провенанса:

Примечание: Выбор между RDF-star и Named Graphs для хранения метаданных фактов определяется по результатам исследования И8. Ниже приведён пример на RDF-star как один из кандидатных вариантов.

# Каждый факт связан с источником (вариант RDF-star — кандидатный)
<<monaeco:well/W-42 monaeco:annualProduction "1.2">>
    prov:wasGeneratedBy monaeco:activity/import-2026-03 ;
    prov:wasDerivedFrom monaeco:document/gazprom-report-2025 ;
    monaeco:trustWeight 0.85 ;
    monaeco:evidenceType eco:DirectAssay .

monaeco:activity/import-2026-03 a prov:Activity ;
    prov:wasAssociatedWith monaeco:agent/markup-agent-v1 ;
    prov:startedAtTime "2026-03-15T10:00:00Z"^^xsd:dateTime .

monaeco:document/gazprom-report-2025 a prov:Entity ;
    prov:wasAttributedTo monaeco:company/gazprom ;
    dc:date "2025"^^xsd:gYear .

Управление противоречиями:

flowchart TD
    R["OWL Reasoner<br/>обнаруживает конфликт"]
    F1["Факт A: выбросы = 42 000 т<br/><i>Источник: корп. отчёт · trust 0.80</i>"]
    F2["Факт B: выбросы = 38 500 т<br/><i>Источник: EPA · trust 0.90</i>"]

    R --> F1 & F2
    F1 -->|"помечен как спорный"| UI["👤 Пользователь видит<br/>оба значения + источники"]
    F2 -->|"помечен как спорный"| UI

    UI -->|"профиль: аудитор"| P1["Приоритет:<br/>корп. отчёт"]
    UI -->|"профиль: эколог"| P2["Приоритет:<br/>EPA"]

    style F1 fill:#fff8e1,stroke:#F9A825
    style F2 fill:#e8f5e9,stroke:#4CAF50
    style R fill:#fce4ec,stroke:#C62828

OWL reasoner обнаруживает конфликт (два значения для функционального свойства)
Система помечает оба факта как «спорные»
Пользователь видит оба значения с источниками и весами доверия
Пользовательский профиль доверия может влиять на сортировку (приоритет компании / науки / регулятора)

Рейтинги доверия:

Тип источника	Базовый вес	Пример
Международный стандарт (ISO, GRI)	0.95	GRI 11, ISO 14040
Государственный регулятор	0.90	EPA, Росприроднадзор
Научная статья (peer-reviewed)	0.85	Nature, SPE Journal
Корпоративный отчёт (аудированный)	0.80	Годовой ESG-отчёт
Корпоративный отчёт (неаудированный)	0.65	Пресс-релиз
IoT-данные (верифицированные)	0.90	Датчики OGMP 2.0
Экспертная оценка	0.70	Мнение специалиста

6.10. Фронтенд

Подробное описание — в разделе 9 (Пользовательский интерфейс).

7. Модель данных

7.1. Пространства имён

@prefix monaeco:  <https://monaeco.org/ontology/> .
@prefix monaeco-t: <https://monaeco.org/thesaurus/> .
@prefix monaeco-d: <https://monaeco.org/data/> .
@prefix bfo:      <http://purl.obolibrary.org/obo/BFO_> .
@prefix envo:     <http://purl.obolibrary.org/obo/ENVO_> .
@prefix chebi:    <http://purl.obolibrary.org/obo/CHEBI_> .
@prefix iso15926: <http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003#> .
@prefix iof:      <https://spec.industrialontologies.org/ontology/core/Core/> .
@prefix qudt:     <http://qudt.org/schema/qudt/> .
@prefix skos:     <http://www.w3.org/2004/02/skos/core#> .
@prefix prov:     <http://www.w3.org/ns/prov#> .
@prefix geo:      <http://www.opengis.net/ont/geosparql#> .

7.2. Пример данных компании

# Компания
monaeco-d:company/acme-oil a monaeco:OilGasCompany ;
    rdfs:label "ACME Oil Corp."@en, "АКМЕ Нефть"@ru ;
    monaeco:headquartersLocation monaeco-d:location/houston ;
    monaeco:memberSince "2026"^^xsd:gYear .

# Месторождение
monaeco-d:field/north-star a monaeco:OilField ;
    rdfs:label "North Star Field"@en ;
    monaeco:operatedBy monaeco-d:company/acme-oil ;
    geo:hasGeometry [
        geo:asWKT "POINT(68.5 72.3)"^^geo:wktLiteral
    ] ;
    monaeco:estimatedReserves [
        qudt:numericValue 150.0 ;
        qudt:unit qudt:MegaTonne
    ] .

# Скважина
monaeco-d:well/ns-001 a monaeco:Well ;
    monaeco:partOf monaeco-d:field/north-star ;
    monaeco:wellType monaeco:ProductionWell ;
    monaeco:drilledDate "2023-06-15"^^xsd:date ;
    monaeco:depth [
        qudt:numericValue 3200 ;
        qudt:unit qudt:Metre
    ] .

# Выбросы (привязка к GRI 11)
monaeco-d:emission/ns-2025-scope1 a monaeco:GHGEmission ;
    monaeco:emissionScope monaeco:Scope1 ;
    monaeco:reportingPeriod "2025"^^xsd:gYear ;
    monaeco:emittedBy monaeco-d:field/north-star ;
    monaeco:quantity [
        qudt:numericValue 42000 ;
        qudt:unit qudt:Tonne
    ] ;
    monaeco:ghgType chebi:16183 ;  # CO2
    prov:wasDerivedFrom monaeco-d:document/acme-esg-2025 .

7.3. Версионирование онтологии (MVP)

OWL-файлы хранятся в Git-репозитории (source of truth)
Каждое изменение онтологии = коммит с описанием изменений
При импорте онтологии в Oxigraph: DROP GRAPH <uri> → LOAD обновлённой версии
Данные компаний, загруженные по старой схеме, валидируются SHACL после обновления; невалидные факты помечаются для ре-обработки агентом разметки
Полное semantic versioning и changelog — post-MVP (§21.4)

8. API

8.1. REST API (бэкенд → фронтенд)

Базовый URL: https://api.monaeco.org/v1

Метод	Путь	Описание
Поиск
POST	`/search`	Семантический поиск (NL → результаты)
GET	`/search/facets`	Получить доступные фасеты
Граф знаний
GET	`/concepts/{id}`	Получить концепт с метками на всех языках
GET	`/concepts/{id}/related`	Связанные концепты (граф окрестности)
GET	`/concepts/{id}/facts`	Факты, привязанные к концепту
GET	`/ontology/tree`	Дерево онтологии (для навигации)
Компании
GET	`/companies`	Список компаний-участников
GET	`/companies/{id}`	Профиль компании
GET	`/companies/{id}/emissions`	Данные о выбросах
GET	`/companies/{id}/facilities`	Объекты компании
Документы
POST	`/documents/upload`	Загрузка документа на разметку
GET	`/documents/{id}/status`	Статус разметки
GET	`/documents/{id}/markup`	Результат разметки (извлечённые факты)
NLG
POST	`/nlg/generate`	Генерация текста из набора фактов
Провенанс
GET	`/provenance/{fact_id}`	Происхождение факта
GET	`/contradictions`	Обнаруженные противоречия
Администрирование
GET	`/admin/queue`	Очередь кандидатов в концепты (для эксперта)
POST	`/admin/concepts/approve`	Подтвердить новый концепт
POST	`/admin/concepts/reject`	Отклонить кандидата
Экспорт
GET	`/export/search`	Экспорт результатов поиска (CSV, JSON-LD)
GET	`/export/company/{id}/report`	Генерация PDF-отчёта по компании
Аудит
GET	`/admin/audit-log`	Журнал действий пользователей

8.2. Авторизация API

Аутентификация (MVP): JWT (JSON Web Tokens). Access token — 15 минут, refresh token — 7 дней. OAuth 2.0 (внешние провайдеры) — планируется для production-версии (см. вопрос В7).

Модель ролей:

flowchart LR
    subgraph Roles["Роли"]
        R["👁️ Читатель"]
        E["🔬 Эксперт"]
        A["⚙️ Администратор"]
    end

    subgraph Permissions["Возможности"]
        P1["Поиск · просмотр · экспорт"]
        P2["Загрузка документов<br/>Разметка · тезаурус"]
        P3["Управление пользователями<br/>Аудит"]
    end

    R --> P1
    E --> P1 & P2
    A --> P1 & P2 & P3

    style R fill:#e3f2fd,stroke:#1565C0
    style E fill:#e8f5e9,stroke:#2E7D32
    style A fill:#fff3e0,stroke:#E65100

Матрица доступа по ролям:

Эндпоинт	Читатель	Эксперт	Администратор
`/search`, `/concepts/`, `/companies/`	Да	Да	Да
`/provenance/*`, `/contradictions`	Да	Да	Да
`/nlg/generate`	Да	Да	Да
`/export/*`	Да	Да	Да
`/documents/upload`	Нет	Да	Да
`/documents/{id}/markup`	Нет	Да	Да
`/admin/queue`, `/admin/concepts/*`	Нет	Да	Да
`/admin/audit-log`	Нет	Нет	Да
Управление пользователями	Нет	Нет	Да

Стратегия версионирования: Текущая версия — /v1. При breaking changes — новая версия (/v2) с параллельной поддержкой предыдущей в течение 3 месяцев.

8.3. SPARQL Endpoint (внутренний)

URL: http://oxigraph:7878/query (не экспонируется наружу)

Используется внутренне компонентами бэкенда. Для MVP — без авторизации внутри docker-сети.

8.4. Форматы данных

Запросы: JSON
Ответы: JSON-LD (предпочтительно), JSON
Загрузка документов: multipart/form-data
Внутренний обмен: RDF (Turtle, N-Triples)

9. Пользовательский интерфейс

9.1. Страницы приложения

Страница	Описание
Главная	Поисковая строка + популярные темы + статистика платформы
Результаты поиска	Факты + фасеты + визуализация + переключатель языков
Концепт	Карточка концепта: определение, связанные концепты (граф), факты, источники
Карта	OpenStreetMap с объектами (месторождения, заводы, скважины)
Компания	Профиль: объекты, выбросы, документы, метрики GRI
Граф знаний	D3.js: интерактивная визуализация подграфа
Загрузка документа	Форма загрузки + прогресс разметки + результат
Экспертная панель	Очередь кандидатов в концепты, редактирование тезауруса
Администрирование	Управление пользователями, статистика, журнал аудита
Экспорт	Экспорт результатов поиска (CSV), генерация PDF-отчётов по компаниям

9.2. Ключевые UX-паттерны

Поиск:

Автодополнение с подсказками из тезауруса
Язык запроса = язык интерфейса (автоопределение)
Результат = факты с источниками (не ссылки на документы)
Переключатель языка перегенерирует текст через NLG

Визуализация графа (D3.js):

Узлы = концепты, рёбра = связи
Цвет узла = тип (компания / объект / процесс / вещество)
Клик на узле → раскрытие подграфа
Масштабирование и перетаскивание

Карта (Leaflet + OSM):

Маркеры объектов (скважины, месторождения, заводы)
Кластеризация при отдалении
Попап с основными фактами и ссылкой на карточку

Достоверность:

Каждый факт помечен иконкой источника
При наведении — полная цепочка провенанса
Противоречия выделены визуально (два значения рядом)

9.3. Адаптивность

Desktop (1280+): полная функциональность
Tablet (768–1279): упрощённая навигация
Mobile (< 768): базовый поиск и просмотр (не приоритет для MVP)

10. Пользовательские сценарии

Основной сценарий: семантический поиск

sequenceDiagram
    actor User as 👤 Читатель
    participant UI as Vue.js SPA
    participant API as FastAPI
    participant Search as Поисковый движок
    participant Graph as Oxigraph (SPARQL)
    participant NLG as NLG-модуль

    User->>UI: Вводит: "Выбросы CO₂ компаний в ЯНАО за 2025"
    UI->>API: POST /search {query, lang: "ru"}
    API->>Search: Разбор запроса (NLP)
    Search->>Search: Маппинг → monaeco:GHGEmission + region/yanao + 2025
    Search->>Graph: SPARQL SELECT (шаблон + подстановка)
    Graph-->>Search: Результат: триплеты с фактами
    Search->>Search: Ранжирование по trustWeight
    Search->>NLG: Факты → текст на RU
    NLG-->>API: Сгенерированный текст + провенанс
    API-->>UI: JSON: текст + фасеты + источники
    UI-->>User: Факты с источниками + фасетная навигация

    Note over User,UI: Пользователь переключает язык на ZH
    User->>UI: Переключатель: RU → ZH
    UI->>API: POST /nlg/generate {facts, lang: "zh"}
    API->>NLG: Те же факты → текст на ZH
    NLG-->>API: 中文文本
    API-->>UI: Текст на китайском
    UI-->>User: Те же факты на 中文

Сценарий эксперта: загрузка документа

sequenceDiagram
    actor Expert as 👤 Эксперт
    participant UI as Vue.js SPA
    participant API as FastAPI
    participant Worker as Celery Worker
    participant Graph as Oxigraph

    Expert->>UI: Загружает PDF (GRI-отчёт)
    UI->>API: POST /documents/upload (multipart)
    API->>Worker: Задача в очередь (Celery)
    API-->>UI: 202 Accepted, task_id

    loop WebSocket: прогресс
        Worker-->>UI: Статус: извлечение текста...
        Worker-->>UI: Статус: NER (найдено 45 сущностей)...
        Worker-->>UI: Статус: формирование RDF...
        Worker-->>UI: Статус: SHACL-валидация...
    end

    Worker->>Graph: SPARQL UPDATE (Named Graph)
    Worker-->>UI: ✅ Готово: 127 триплетов, 3 новых кандидата

    Expert->>UI: Открывает экспертную панель
    UI->>API: GET /admin/queue
    API-->>UI: 3 кандидата в концепты
    Expert->>UI: Утверждает 2, отклоняет 1
    UI->>API: POST /admin/concepts/approve
    API->>Graph: Обновление тезауруса

10.1. Читатель

С1. Поиск фактов:

Как Читатель, я хочу задать вопрос на естественном языке («Какие выбросы CO₂ у компаний в ЯНАО за 2025 год?») и получить факты из графа знаний с указанием источников — чтобы подготовить отчёт.

Критерии приёмки:

Запрос на EN/RU/ZH возвращает результаты за ≤ 3 сек (p95)
Каждый факт в результатах содержит ссылку на источник (провенанс)
При отсутствии результатов отображается информативное сообщение, а не пустая страница

С2. Сравнение компаний:

Как Читатель, я хочу сравнить ESG-метрики двух компаний в табличном и графическом виде — чтобы оценить экологическую ответственность.

Критерии приёмки:

Пользователь может выбрать 2 компании для сравнения
Таблица отображает общие метрики (выбросы, проекты, регионы) с указанием единиц измерения
Различия между компаниями визуально выделены

С3. Навигация по карте:

Как Читатель, я хочу увидеть месторождения и объекты на карте, кликнуть на объект и получить сводку фактов — чтобы понять географию деятельности.

Критерии приёмки:

Карта отображает все объекты с координатами из графа (маркеры с кластеризацией)
Клик на объект открывает popup/карточку с названием, оператором и ключевыми фактами
Карта корректно отображается на экранах ≥ 1024px

С4. Переключение языка:

Как Читатель, я хочу переключить язык интерфейса (EN/RU/ZH) и увидеть ту же информацию на другом языке — чтобы подготовить материал для международных партнёров.

Критерии приёмки:

Переключение языка обновляет текст без полной перезагрузки страницы
Интерфейсные элементы (кнопки, навигация) и данные (labels концептов) переводятся
Выбранный язык сохраняется между сессиями (localStorage)

С5. Экспорт данных:

Как Читатель, я хочу экспортировать результаты поиска в CSV или PDF — чтобы использовать данные в своём отчёте.

Критерии приёмки:

CSV содержит все столбцы из таблицы результатов, включая источники
PDF содержит заголовок запроса, дату экспорта и таблицу результатов
Файлы скачиваются через браузер (Content-Disposition: attachment)

10.2. Эксперт

С6. Проверка новых терминов:

Как Эксперт, я хочу просмотреть очередь предложенных агентом новых терминов, увидеть контекст их появления и утвердить / отредактировать / отклонить — чтобы поддерживать качество тезауруса.

Критерии приёмки:

Очередь отображает термин, контекст (предложение из документа) и предложенный класс
Эксперт может утвердить, отредактировать метки (EN/RU/ZH) или отклонить кандидата
Утверждённый термин появляется в тезаурусе (SPARQL-проверка наличия skos:Concept)

С7. Загрузка и разметка документа:

Как Эксперт, я хочу загрузить GRI-отчёт (PDF), отслеживать прогресс автоматической разметки и проверить извлечённые факты — чтобы наполнить граф достоверными данными.

Критерии приёмки:

Загрузка PDF/DOCX через UI (multipart, ≤ 50 MB)
Прогресс отображается в реальном времени (WebSocket): извлечение текста → NER → RDF → валидация
После завершения отображается количество извлечённых триплетов и кандидатов в концепты

С8. Просмотр противоречий:

Как Эксперт, я хочу видеть обнаруженные противоречия (два источника дают разные значения) и оценить достоверность каждого — чтобы помочь системе приоритизировать данные.

Критерии приёмки:

Противоречия обнаруживаются автоматически (OWL reasoner или SPARQL-запрос)
Каждое противоречие показывает оба значения, источники и даты
Эксперт может отметить приоритетный источник

10.3. Администратор

С9. Управление пользователями:

Как Администратор, я хочу назначать роли (Читатель, Эксперт, Администратор) и управлять доступом компаний к данным — чтобы обеспечить безопасность.

Критерии приёмки:

Список пользователей с фильтрацией по роли
Назначение/изменение роли вступает в силу при следующем запросе (JWT refresh)
Администратор не может понизить свою собственную роль (защита от блокировки)

С10. Мониторинг платформы:

Как Администратор, я хочу видеть статистику (количество триплетов, документов, активных пользователей, ошибок обработки) — чтобы контролировать здоровье системы.

Критерии приёмки:

Дашборд показывает: кол-во триплетов, документов, Named Graphs, активных пользователей за 7 дней
Ошибки обработки выделены (красный индикатор при > 0 ошибок за 24 часа)
Данные обновляются без перезагрузки страницы (polling или WebSocket)

С11. Журнал аудита:

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

Критерии приёмки:

Журнал содержит: дату, пользователя, действие, объект (документ/концепт/пользователь)
Фильтрация по типу действия и пользователю
Записи аудита неизменяемы (append-only, нет удаления)

11. Предварительные исследования

Перед началом разработки команда проводит серию исследований для валидации технологических решений, описанных в данном ТЗ. Без этих исследований существует риск столкнуться с непредвиденными ограничениями технологий уже в ходе спринтов. Каждое исследование завершается коротким отчётом с выводами и рекомендациями.

Длительность фазы исследований: 4–5 недель (параллельно друг с другом, с учётом необходимости создания прототипов).

И1. Выбор графового хранилища

Вопрос: Oxigraph или Virtuoso? Или иное решение?

Что исследуем:

Полнота поддержки SPARQL 1.1 (Query, Update, Federated Query)
Поддержка Named Graphs (Quads) — критично для нашей архитектуры
Совместимость с OWL-рассуждателями (Openllet, HermiT) — встроенная или через интеграцию
Производительность: загрузка 1–2M триплетов, типовые SPARQL-запросы (JOIN, OPTIONAL, FILTER, Property Paths, агрегации)
Поддержка RDF-star (для метаданных фактов)
Полнотекстовый поиск по литералам
Поддержка GeoSPARQL (для пространственных запросов и карт)
Горизонтальное масштабирование (на будущее)
Зрелость: количество production-инсталляций, активность сообщества, частота релизов
Требования к ресурсам (RAM, CPU, диск)

Кандидаты: Oxigraph (Rust, MIT), Virtuoso (C, GPL), GraphDB Free (Java), Apache Jena Fuseki (Java)

Результат: Обоснованный выбор с benchmark-данными.

И2. Онтологии верхнего и среднего уровня: BFO + CCO

Вопрос: Как правильно выстроить онтологическую иерархию BFO → CCO → наши доменные онтологии?

Что исследуем:

BFO 2020 (ISO 21838-2): структура 40 классов, ключевые дистинкции (Continuant vs Occurrent, Independent vs Dependent)
CCO: какие модули существуют (Agent, Artifact, Event, Information, Quality, Units), какие нужны нам
Как ENVO расширяет BFO (паттерн импорта, используемые классы BFO)
Как IOF Core расширяет BFO (PlanSpecification, ProcessOccurrence, MaterialArtifact)
Практические примеры: как смоделировать «скважина», «выброс CO₂», «процесс добычи» через BFO + CCO
Совместимость CCO с IOF Core (оба расширяют BFO — нет ли конфликтов?)
Размер и сложность: сколько аксиом, можно ли использовать без reasoner

Результат: Архитектурное решение по структуре онтологий с примерами моделирования ключевых сущностей.

И3. Доменные онтологии нефтегаза и экологии

Вопрос: Какие именно подмножества ENVO, ISO 15926, IOF Core, ChEBI нам нужны? Как их импортировать?

Что исследуем:

ENVO: какие классы релевантны для нефтегаза (загрязнители, экосистемы, среды)? Размер полной vs подмножества. Формат: OBO vs OWL — какой брать?
ISO 15926 RDL: где скачать OWL-версию? Какие классы оборудования нужны (насосы, трубопроводы, сепараторы, факельные установки)? Размер RDL (десятки тысяч классов — нужна фильтрация)
IOF Core: текущий статус и зрелость, доступность OWL-файлов, покрытие нефтегазовых процессов
ChEBI: подмножество для нефтехимии и парниковых газов (CO₂, CH₄, H₂S, NOₓ). Размер полной ChEBI (>195K) — стратегия фильтрации
QUDT: покрытие единиц измерения нефтегаза (баррели, тонны, м³/сут, ppm)
CEON: зрелость и применимость для моделирования circular economy в нефтегазе
O3PO: применимость онтологии offshore petroleum
Конфликты импортов: что происходит при одновременной загрузке ENVO + ISO 15926 + IOF Core?

Результат: Список конкретных OWL-файлов для импорта, стратегия фильтрации, карта зависимостей между онтологиями.

И4. Мультиязычный тезаурус: GEMET + SKOS + OntoLex-Lemon

Вопрос: Как построить мультиязычный тезаурус для нефтегаза на трёх языках?

Что исследуем:

GEMET: качество русских и китайских переводов, покрытие нефтегазовой терминологии, формат экспорта (SKOS RDF)
SPE Glossary (Society of Petroleum Engineers): доступность, лицензия, формат, покрытие
IOGP Terminology: доступность, мультиязычность
OntoLex-Lemon: как связать SKOS-концепты с лексическими формами? Практические примеры для RU (падежи, роды) и ZH (счётные слова)
Стратегия перевода: автоматический (LLM-assisted) → ручная проверка? Или только ручной?
Связь тезауруса с онтологией: skos:Concept vs owl:Class — когда что использовать?
Инструменты редактирования тезауруса: VocBench, Skosmos, iQvoc — что подходит

Результат: Архитектура тезауруса, источники терминов, выбор инструмента редактирования, workflow наполнения.

И5. Сравнительная оценка NLG-подходов

Вопрос: Какой подход к генерации текста на RU, EN, ZH оптимален для нефтегазового домена?

Что исследуем:

Вариант A — Шаблонный NLG (Jinja2 + pymorphy3):

Качество русской морфологии через pymorphy3 (склонение, спряжение, согласование)
Трудоёмкость создания шаблонов для типовых ответов (фактоид, сравнение, обзор, навигация)
Качество китайских шаблонов без морфологического движка

Вариант B — Grammatical Framework (GF):

Resource Grammar Library: качество русской грамматики (падежи, роды, числа). Качество китайской грамматики (счётные слова, порядок слов)
Создание доменных грамматик: абстрактный синтаксис → конкретные грамматики для 3 языков. Трудоёмкость
Кривая обучения: сколько времени нужно, чтобы разработчик мог создавать новые грамматики
Опыт Abstract Wikipedia: как GF используется в production

Вариант C — LLM-grounded generation (с гарантиями):

Качество текста при строгом ограничении контекста (только факты из графа)
Эффективность валидации: каждое утверждение в тексте → обратная привязка к триплету
Риск остаточных галлюцинаций при разных промптах и моделях
Стоимость API-вызовов при объёме запросов MVP

Вариант D — Гибрид (шаблоны для данных + LLM для нарратива):

Разделение: числовые данные / метрики через шаблоны (100% точность), описательный текст через LLM
Сложность поддержки двух систем

Дополнительно:

STTL (Corese): шаблонная генерация прямо из SPARQL — как дополнение к любому варианту
SimpleNLG: есть ли рабочий форк для русского? Для китайского (SimpleNLG-ZH)?
Производительность: время генерации одного текста из 5–10 фактов

Результат: Сравнительная таблица вариантов (качество / трудоёмкость / риски). Прототип лучшего варианта: 3–5 фактов из графа → текст на 3 языках. Рекомендация для заказчика.

И6. NLP для нефтегазового домена

Вопрос: Как извлекать концепты, сущности и связи из нефтегазовых документов на EN, RU, ZH?

Что исследуем:

spaCy: качество NER для нефтегазовых сущностей (скважины, месторождения, оборудование, химические вещества). Нужен ли fine-tuning? Есть ли готовые модели для нефтегаза?
Связывание сущностей (Entity Linking): как сопоставить извлечённый термин «Ямало-Ненецкий АО» с концептом тезауруса? spaCy EntityLinker vs custom fuzzy match
Извлечение отношений (Relation Extraction): dependency parsing для паттернов «компания X эксплуатирует скважину Y», «месторождение Z расположено в регионе W»
Таблицы: извлечение данных из таблиц в PDF/Excel — Camelot, Tabula, pandas
Сегментация микро-топиков: алгоритмы разбиения документа на тематические блоки (TextTiling, TopicTiling, или простая эвристика по заголовкам)
Качество: на каких данных измерять F1? Нужен ли аннотированный тестовый набор?
Китайский NLP: jieba vs spaCy для сегментации, качество NER

Результат: Выбор NLP-стека, оценка качества на тестовых документах, план fine-tuning (если нужен).

И7. SPARQL-шаблоны и семантический поиск

Вопрос: Как транслировать запросы пользователя на естественном языке в SPARQL?

Что исследуем:

Подходы к NL→SPARQL: шаблонные (keyword → SPARQL template) vs семантические (parsing → AST → SPARQL) vs LLM-assisted (NL → SPARQL через Claude/GPT с валидацией)
Типовые запросы нефтегазового домена: какие паттерны SPARQL нужны (простые lookup, JOIN через несколько классов, агрегации, Property Paths, GeoSPARQL)?
Semantic query expansion: если пользователь ищет «загрязнение воды», система должна расширить поиск на подклассы ENVO — как реализовать через OWL inference или SPARQL CONSTRUCT?
Фасетная навигация: как эффективно считать фасеты через SPARQL (COUNT + GROUP BY)? Кэширование?
Производительность: время выполнения типовых запросов на графе 1–2M триплетов
Существующие решения: QAnswer, Frankenstein (SBERT + SPARQL), KGQA frameworks

Результат: Архитектура поискового движка, библиотека из 15–20 SPARQL-шаблонов, стратегия расширения запросов.

И8. Провенанс и управление достоверностью

Вопрос: Как эффективно реализовать PROV-O, RDF-star и пользовательские рейтинги доверия?

Что исследуем:

PROV-O: практические паттерны — как привязать провенанс к каждому факту без «раздувания» графа? Named Graphs vs RDF-star vs Singleton Properties
RDF-star: поддержка в Oxigraph / Virtuoso / других кандидатах. Можно ли хранить <<s p o>> monaeco:trustWeight 0.85 ?
ECO (Evidence and Conclusion Ontology): применимость для классификации типов доказательств
Обнаружение противоречий: как OWL reasoner находит конфликты? Какие аксиомы нужны (owl:FunctionalProperty, owl:disjointWith)?
Пользовательские профили доверия: как реализовать «финансовый аудитор приоритизирует корпоративные отчёты, а эколог — данные датчиков»? Динамическое переписывание SPARQL?
Производительность: overhead от провенанса (в %)

Результат: Выбор механизма хранения метаданных (RDF-star или Named Graphs), паттерны PROV-O, прототип обнаружения противоречий.

И9. Визуализация графов знаний

Вопрос: Как эффективно визуализировать подграфы из сотен-тысяч узлов в браузере?

Что исследуем:

D3.js force-directed: производительность при 100 / 500 / 1000 узлов, интерактивность (zoom, pan, click-expand)
Альтернативы: Cytoscape.js (специализирован на графах), vis.js (более простой), Sigma.js (WebGL, быстрый)
Стратегии фильтрации: показывать только N-hop окрестность, схлопывание кластеров, LOD (level of detail)
Цветовая кодировка: тип узла (компания, объект, процесс, вещество) → цвет + иконка
Leaflet + OpenStreetMap: кластеризация маркеров, heatmap для выбросов, GeoSPARQL → координаты
Взаимодействие карты и графа: клик на карте → подграф этого объекта

Результат: Выбор библиотеки визуализации, демо-прототип с тестовыми данными, стратегия масштабирования.

И10. Формализация ESG-метрик и цифровых двойников

Вопрос: Как формализовать GRI 11, GHG Protocol, LCA и производственные процессы в RDF?

Что исследуем:

GRI 11 (Oil and Gas Sector Standard): какие метрики формализуемы (Scope 1/2/3, flaring, produced water, waste)? Как моделировать в RDF?
GHG Protocol: Scope 1/2/3 — как связать с конкретным оборудованием через IOF Core?
OGMP 2.0: стандарт отчётности по метану — структура данных
Цифровой двойник процесса: IOF Core (PlanSpecification + ProcessOccurrence) + PRODML (productFlowModel) — как смоделировать цепочку «добыча → переработка → отходы» в RDF?
Circular economy (CEON): паттерн WasteRole → RawMaterialRole — реализация в SPARQL
LCA (ISO 14040): можно ли вычислять экологический след через SPARQL Property Paths?
ecoinvent: доступность данных в RDF, возможность интеграции

Результат: RDF-шаблоны для ESG-метрик, прототип цифрового двойника одного процесса, карта стандартов → классы онтологии.

И11. Архитектура GSL ↔ RDF адаптера (подготовка к интеграции с Knowdy)

Вопрос: Насколько сложен маппинг между GSL и RDF/OWL? Какие конструкции транслируемы, какие — нет?

Что исследуем:

Анализ GSL-синтаксиса по knowdy-schemas (~50 файлов): полный список конструкций
Маппинг GSL → RDF/OWL: {!cls} → owl:Class, {is} → rdfs:subClassOf, {str} → owl:DatatypeProperty, {cls-ref} → owl:ObjectProperty, [gloss] → rdfs:label / skos:prefLabel
Что НЕ маппится: {!proc} (процессы в GSL — это не просто классы), [arg] / [effect] (аргументы процессов)
Маппинг RDF/OWL → GSL: обратная трансляция — какие конструкции OWL непредставимы в GSL?
gsl-parser (C): можно ли использовать для парсинга, или писать свой парсер на Python?
Оценка трудоёмкости: сколько спринтов нужно на полноценный bidirectional adapter?

Результат: Матрица совместимости GSL ↔ RDF/OWL, оценка трудоёмкости адаптера, рекомендации для Дмитрия по расширению GSL.

И12. Безопасность и контроль доступа

Вопрос: Как реализовать многоуровневый доступ к знаниям в RDF-хранилище?

Что исследуем:

Graph-level ACL: ограничение доступа на уровне Named Graphs (данные компании A не видны компании B)
Поддержка ACL в Oxigraph / Virtuoso / кандидатах
RBAC: Читатель (только поиск), Эксперт (+ редактирование тезауруса), Администратор (+ загрузка, управление)
JWT (MVP) + OAuth 2.0 (production): аутентификация, интеграция с внешними провайдерами. Провайдеры зависят от целевых рынков (Google/Microsoft для международного, WeChat/DingTalk для китайского — см. вопрос В7)
OWASP Top 10: применимость к SPARQL-endpoint (SPARQL injection?)
Шифрование данных at rest и in transit

Результат: Архитектура безопасности, выбор подхода к ACL, модель ролей.

Сводная таблица исследований

#	Исследование	Приоритет	Зависимости	Ожидаемый результат
И1	Выбор графового хранилища	Критический	—	Benchmark, обоснованный выбор
И2	BFO + CCO: структура онтологий	Критический	—	Архитектурное решение + примеры
И3	Доменные онтологии (ENVO, ISO 15926, IOF)	Критический	И2	Список OWL-файлов, карта зависимостей
И4	Мультиязычный тезаурус	Высокий	—	Архитектура, источники, инструмент
И5	Сравнительная оценка NLG-подходов	Высокий	—	Сравнение вариантов, прототип лучшего
И6	NLP для нефтегаза	Высокий	—	Выбор стека, оценка качества
И7	Семантический поиск (NL → SPARQL)	Средний	И1	Архитектура, шаблоны SPARQL
И8	Провенанс и достоверность	Средний	И1	Выбор механизма, паттерны PROV-O
И9	Визуализация графов	Средний	—	Выбор библиотеки, демо
И10	ESG-метрики и цифровые двойники	Средний	И2, И3	RDF-шаблоны, прототип двойника
И11	GSL ↔ RDF адаптер	Низкий (этап 2)	—	Матрица совместимости, оценка
И12	Безопасность и ACL	Средний	И1	Архитектура безопасности

Параллелизация

Исследования ведутся параллельно:

gantt
    title Фаза исследований (5 недель)
    dateFormat YYYY-MM-DD
    axisFormat %d.%m

    section Волна 1 (нед. 1–2)
    И1 Графовое хранилище         :i1, 2026-04-14, 14d
    И2 BFO + CCO                  :i2, 2026-04-14, 14d
    И4 Тезаурус GEMET + SKOS      :i4, 2026-04-14, 14d
    И5 Сравнение NLG              :i5, 2026-04-14, 14d
    И6 NLP для нефтегаза          :i6, 2026-04-14, 14d
    И9 Визуализация графов        :i9, 2026-04-14, 14d
    И12 Безопасность и ACL        :i12, 2026-04-14, 14d

    section Волна 2 (нед. 3–4)
    И3 Доменные онтологии         :i3, after i2, 14d
    И7 Семантический поиск        :i7, after i1, 14d
    И8 Провенанс PROV-O           :i8, after i1, 14d
    И10 ESG-метрики               :i10, after i2, 14d
    И11 GSL ↔ RDF адаптер         :i11, 2026-04-28, 14d

    section Финализация (нед. 5)
    Синтез результатов            :milestone, 2026-05-12, 7d
    Корректировка ТЗ              :2026-05-12, 7d

Важно: Результаты исследований могут повлиять на технологический стек и план спринтов. Если какое-то решение окажется нежизнеспособным, ТЗ корректируется до начала спринтов.

12. Команда проекта

12.1. Состав

#	Роль	Кол-во	Ключевые компетенции
1	Tech Lead / Архитектор	1	RDF/OWL/SPARQL, Python, проектирование систем
2	Senior Backend Developer	1	Python, FastAPI, NLP-пайплайны, Celery
3	Middle Backend Developer	1	Python, FastAPI, REST API, тесты
4	Senior Frontend Developer	1	Vue.js 3, TypeScript, D3.js, Leaflet
5	Knowledge Engineer	1	OWL, SPARQL, Protege, предметная область (нефтегаз / экология)
6	NLP/ML Engineer	1	spaCy, NER, relation extraction, мультиязычные модели
7	DevOps Engineer	0.5	Docker, CI/CD, мониторинг, Linux
8	QA Engineer	1	pytest, Playwright, SPARQL-тестирование, SHACL
9	Project Manager	1	Agile/Scrum, коммуникация с заказчиком
	Итого	8.5 FTE

12.2. Критичные компетенции

Knowledge Engineer — ключевая и самая редкая роль. Без неё невозможно выстроить онтологическую иерархию (BFO → CCO → домен). Рекомендуется привлекать специалиста с опытом в биоонтологиях (ENVO, ChEBI) или промышленных стандартах (ISO 15926).
NLP Engineer — для мультиязычного NER (EN/RU/ZH) требуется опыт с spaCy и fine-tuning моделей. Китайский NLP требует специфической экспертизы.
Tech Lead — должен совмещать знания Semantic Web (RDF/OWL/SPARQL) и практический опыт построения бэкенд-систем на Python.

12.3. Definition of Done (для спринтов)

Спринт считается завершённым, когда:

Все задачи спринта выполнены или перенесены с обоснованием
Code review пройден (минимум 1 ревьюер)
Unit-тесты написаны и проходят (green CI)
Демо подготовлено и проведено для заказчика
Документация обновлена (API docs, если менялся API)

13. Бюджет

13.1. Фонд оплаты труда

Ставки — минимальные по российскому рынку для in-house разработки (gross, до НДФЛ):

#	Роль	Ставка (руб/мес)	Кол-во	Итого (руб/мес)
1	Tech Lead / Архитектор	250 000	1	250 000
2	Senior Backend Developer	200 000	1	200 000
3	Middle Backend Developer	130 000	1	130 000
4	Senior Frontend Developer	200 000	1	200 000
5	Knowledge Engineer	170 000	1	170 000
6	NLP/ML Engineer	180 000	1	180 000
7	DevOps Engineer (50%)	200 000	0.5	100 000
8	QA Engineer	110 000	1	110 000
9	Project Manager	140 000	1	140 000
	Итого ФОТ (gross)		8.5	1 480 000
	+ Страховые взносы (~30%)			444 000
	Итого ФОТ с отчислениями			1 924 000

13.2. Инфраструктура

Статья	Стоимость (руб/мес)	Примечание
Staging-сервер (Selectel)	12 000	8 vCPU, 32 GB RAM, 200 GB SSD NVMe
S3-хранилище (документы, бэкапы)	1 000	~50 GB
Домен + SSL	500	monaeco.org
Инструменты (GitHub, CI/CD)	5 000	GitHub Team
Итого инфраструктура	18 500

13.3. Итого по проекту

Статья	Месяцев	Итого (руб)
ФОТ с отчислениями	7	13 468 000
Инфраструктура	7	129 500
Непредвиденные расходы (10%)	—	1 360 000
Итого MVP	7 мес	~14 960 000

Примечание: Бюджет рассчитан на 7 месяцев (5 недель исследований + 21 неделя спринтов + 2 недели буфер). При оптимистичном сценарии — 6 месяцев (~12.8M руб).

14. Взаимодействие с заказчиком

14.1. Модель взаимодействия

Активность	Частота	Участники	Формат
Sprint Demo	Каждые 2 недели	PM, Tech Lead, представитель MONAECO	Видеозвонок + демонстрация на staging
Еженедельный sync	1 раз в неделю (30 мин)	PM, представитель MONAECO	Статус, блокеры, решения
Доступ к staging	Постоянный (с Sprint 0)	Все заинтересованные со стороны MONAECO	URL staging-сервера
Канал коммуникации	Постоянный	PM, Tech Lead, техконтакт MONAECO	Telegram-группа
Приёмка результатов исследований	По завершении фазы	Tech Lead, Knowledge Engineer, Д. Дмитриев	Документ + обсуждение
UAT (приёмочное тестирование)	Sprint 9–10	Представители компаний-участников	Тестирование на staging

14.2. Product Owner

Для эффективной работы рекомендуется назначить Product Owner со стороны MONAECO — человека, который:

Приоритизирует задачи бэклога при конфликте приоритетов
Принимает решения по UX и бизнес-логике (не только технические)
Доступен для вопросов команды в рабочее время (ответ в течение 24 часов)

14.3. Управление изменениями

Изменения к ТЗ оформляются через Change Request (CR):

Инициатор (заказчик или команда) описывает изменение
Команда оценивает влияние на сроки и бюджет
Обе стороны согласуют или отклоняют CR
Утверждённые CR включаются в ближайший спринт (или создают новый)

15. План спринтов

Формат: 2-недельные спринты. Общая длительность MVP: 10 спринтов (21 неделя). Спринтам предшествует фаза исследований (4–5 недель). Буфер на непредвиденное — 2 недели.

Sprint 0 — Подготовка (1 неделя)

Цель: Настроить инфраструктуру и окружение разработки.

Задача	Результат
Создать Git-репозиторий, настроить branching strategy	Репо + CONTRIBUTING.md
Docker Compose: Oxigraph + Redis + FastAPI scaffold	`docker-compose up` работает
Инициализировать Vue.js 3 проект (Vite + TypeScript + Pinia)	Пустое SPA запускается
Настроить CI: линтеры, тесты, сборка	GitHub Actions pipeline
Развернуть Oxigraph, проверить SPARQL endpoint	`curl` к SPARQL возвращает ответ

Демо: Работающая инфраструктура, пустой SPARQL endpoint, пустая SPA-оболочка.

Sprint 1 — Онтологический фундамент (2 недели)

Цель: Загрузить базовые онтологии и создать каркас нефтегазовой онтологии.

Задача	Результат
Импорт BFO 2020 в Named Graph	BFO доступен через SPARQL
Импорт CCO (Common Core Ontologies)	CCO доступен
Импорт ENVO (подмножество: среды, загрязнители)	ENVO доступен
Импорт ChEBI (подмножество: нефтехимия, парниковые газы)	ChEBI доступен
Импорт QUDT (единицы измерений для нефтегаза)	QUDT доступен
Импорт IOF Core (подмножество: процессы, артефакты)	IOF доступен
Создать каркас `monaeco:OilGasOntology` (10–15 ключевых классов)	OWL-файл, загружен
Настроить Openllet reasoner, проверить inference	Транзитивность работает

Демо: SPARQL-запрос «покажи все подклассы Process» возвращает классы из BFO + IOF + наши.

Sprint 2 — Тезаурус + базовый UI (2 недели)

Цель: Создать мультиязычный тезаурус, расширить онтологию, запустить каркас фронтенда.

Задача	Результат
Бэкенд: Импорт GEMET (подмножество: экология + энергетика, 3 языка)	SKOS-граф, EN/RU/ZH
Бэкенд: Создать MONAECO-тезаурус: 200+ нефтегазовых концептов	SKOS-граф
Бэкенд: Маппинг MONAECO → GEMET через SSSOM	SSSOM TSV + RDF
Бэкенд: Расширить `monaeco:OilGasOntology` до 30–40 классов	OWL-файл обновлён
Бэкенд: Импорт ISO 15926 RDL (подмножество: оборудование добычи)	ISO 15926 доступен
Бэкенд: Создать SHACL shapes для валидации данных компаний	SHACL-файл
Фронтенд: UI-каркас: роутинг, layout, i18n (EN/RU/ZH)	SPA с навигацией
Фронтенд: Главная страница: поиск + статистика (mock-данные)	Landing page

Демо: SPARQL «метки crude oil на 3 языках» + SPA с переключателем языков и mock-поиском.

Sprint 3 — Агент разметки + UI поиска (2 недели)

Цель: Рабочий пайплайн: документ → извлечение → RDF. Параллельно — UI для поиска и концептов.

Задача	Результат
Бэкенд: Парсинг PDF/DOCX (Apache Tika / python-docx)	Текст извлекается
Бэкенд: Сегментация на микро-топики (заголовки, абзацы, таблицы)	JSON с блоками
Бэкенд: NER для EN и RU (spaCy)	Извлекаются организации, локации, термины
Бэкенд: Связывание сущностей с тезаурусом (fuzzy match)	Matched entities
Бэкенд: Генерация RDF-триплетов из извлечённых фактов	Turtle-файл
Бэкенд: Загрузка в Named Graph + PROV-O метаданные	Данные в Oxigraph
Бэкенд: API: POST `/documents/upload`	Эндпоинт работает
Фронтенд: Страница результатов поиска (mock-данные)	Search results page
Фронтенд: Карточка концепта (mock-данные)	Concept page
Фронтенд: Переключатель языков (перегенерация контента)	Language switcher

Демо: Загрузить PDF → факты в SPARQL. Параллельно — UI поиска с mock-данными.

Sprint 4 — Обнаружение концептов + интеграция UI (2 недели)

Цель: Обнаружение новых терминов, ZH-поддержка. Подключение фронтенда к реальному API.

Задача	Результат
Бэкенд: Агент обнаружения: несопоставленные сущности → кандидаты	Очередь кандидатов
Бэкенд: Кластеризация кандидатов (один термин из разных документов)	Дедупликация
Бэкенд: NLP для китайского (spaCy `zh_core_web_trf`)	ZH NER работает
Бэкенд: Извлечение данных из таблиц (CSV/Excel)	Таблицы → RDF
Бэкенд: Извлечение отношений (dependency parsing)	Связи между сущностями
Бэкенд: SHACL-валидация при импорте	Ошибки отлавливаются
Фронтенд: Подключение к реальному API (поиск, концепты)	End-to-end работает
Фронтенд: Экспертная очередь кандидатов (базовая)	Expert queue
Фронтенд: Аутентификация (JWT) + роли	Login/RBAC

Демо: Загрузить 3 документа → увидеть кандидаты в UI. Поиск через UI → реальные данные.

Sprint 5 — Поисковый движок (2 недели)

Цель: Семантический поиск: вопрос на NL → ответ из графа, фасеты.

Задача	Результат
Бэкенд: NL-парсер запросов (извлечение сущностей и намерения)	Query analysis
Бэкенд: Маппинг на концепты тезауруса	Entities → SKOS concepts
Бэкенд: Библиотека SPARQL-шаблонов (10–15 типовых запросов)	Templates
Бэкенд: Генерация SPARQL из разобранного запроса	Dynamic SPARQL
Бэкенд: Ранжирование результатов по trustWeight	Sorted results
Бэкенд: Фасетная навигация (подсчёт фасетов через SPARQL aggregation)	Facet counts
Бэкенд: API: POST `/search`, GET `/search/facets`	Эндпоинты работают
Фронтенд: Фасетная навигация в UI	Faceted search
Фронтенд: Автодополнение в поиске (из тезауруса)	Autocomplete

Демо: Ввести «Выбросы CO₂ компании ACME в 2025 году» в UI → получить число + источник + фасеты.

Sprint 6 — NLG и провенанс (2 недели)

Цель: Генерация текста на 3 языках, отображение противоречий.

Задача	Результат
Бэкенд: Шаблоны NLG (Jinja2) для типовых ответов	Шаблоны 4 типов запросов
Бэкенд: Морфологическая реализация RU (pymorphy3)	Склонение/спряжение
Бэкенд: Шаблоны EN и ZH	Линеаризация работает
Бэкенд: Макропланирование: выбор фактов → порядок изложения	Planner
Бэкенд: Пайплайн: SPARQL result → шаблон → 3 текста	End-to-end NLG
Бэкенд: Обнаружение противоречий (OWL reasoner inconsistency check)	Conflicts detected
Бэкенд: API провенанса: GET `/provenance/{fact_id}`	Цепочка происхождения
Бэкенд: API: POST `/nlg/generate`	NLG endpoint
Фронтенд: Мультиязычное отображение (переключатель → перегенерация)	Language NLG
Фронтенд: Визуализация провенанса (цепочка источников)	Provenance chain
Фронтенд: Отображение противоречий (два значения рядом)	Contradiction UI

Демо: Запрос в UI → ответ на 3 языках (переключатель) + провенанс + противоречия.

Sprint 7 — Визуализация (2 недели)

Цель: Графы знаний, карты, профили компаний.

Задача	Результат
Визуализация графа знаний (D3.js force-directed)	Interactive graph
Карта объектов (Leaflet + OSM)	Map page
Профиль компании (объекты, выбросы, метрики)	Company page
Взаимодействие карты и графа (клик на карте → подграф)	Linked views

Демо: Интерактивный граф + карта + профиль компании.

Sprint 8 — Экспертная панель + администрирование (2 недели)

Цель: Полноценная экспертная панель, загрузка документов, аудит.

Задача	Результат
Экспертная панель: очередь кандидатов в концепты, approve/reject	Expert panel
Загрузка документа через UI + прогресс + результат	Upload page
Экспорт результатов поиска (CSV) и отчётов по компаниям (PDF)	Export
Административная панель: пользователи, статистика	Admin panel
Журнал аудита действий	Audit log

Демо: Полный цикл эксперта: загрузить документ → проверить разметку → утвердить концепты.

Sprint 9 — Интеграция и данные (2 недели)

Цель: End-to-end сценарии на реальных (или приближённых к реальным) данных.

Задача	Результат
Загрузить 10–20 реальных документов (GRI-отчёты, стандарты)	Наполненный граф
Расширить онтологию по результатам загрузки	50+ классов
Расширить тезаурус по результатам обнаружения концептов	500+ концептов
End-to-end тест: загрузка → разметка → поиск → ответ на 3 языках	Полный цикл
Нагрузочное тестирование (100 параллельных запросов)	Benchmark
Формальная модель: 1 производственный процесс (добыча → переработка → выбросы)	Process graph
Исправление багов, UX-улучшения	Fixes

Демо: Демонстрация полного цикла для MONAECO.

Sprint 10 — Полировка и релиз MVP (2 недели)

Цель: Стабильный MVP, готовый к демонстрации заказчику.

Задача	Результат
UX-ревью и исправления	Polished UI
Документация пользователя (краткое руководство)	User guide
Документация API (OpenAPI / Swagger)	API docs
Документация по развёртыванию	Deployment guide
Security review (OWASP top 10)	Security fixes
Деплой на staging-сервер	Работающий URL
Подготовка демо-презентации	Demo script

Демо: MVP-презентация для руководства MONAECO и первого пула компаний.

Сводная таблица спринтов

Sprint	Длительность	Бэкенд	Фронтенд	Ключевой артефакт
0	1 неделя	Инфраструктура	SPA-каркас	Docker Compose + CI
1	2 недели	Онтологии (BFO, CCO, ENVO, ChEBI, QUDT, IOF Core)	—	Онтологический фундамент + каркас OilGas
2	2 недели	Тезаурус + SHACL	UI-каркас, i18n, главная	SKOS + SPA с навигацией
3	2 недели	Агент разметки	Поиск + концепты (mock)	PDF → RDF пайплайн
4	2 недели	Обнаружение концептов	Интеграция с API, auth	End-to-end поиск
5	2 недели	Поисковый движок	Фасеты, автодополнение	NL → SPARQL → ответ в UI
6	2 недели	NLG + провенанс	Мультиязычность, противоречия	Текст на 3 языках
7	2 недели	—	Визуализация (D3.js, карта)	Граф + карта
8	2 недели	API: approve/reject, экспорт, аудит	Эксп. панель, экспорт, аудит (UI)	Полный набор страниц
9	2 недели	Данные + интеграция	E2E тестирование	10–20 документов
10	2 недели	Безопасность, документация	UX-полировка	Стабильный MVP
Итого спринты	~21 неделя			~5 месяцев
+ Исследования	~5 недель			см. раздел 11
+ Буфер	~2 недели
Общий срок	~28 недель			~7 месяцев

Визуальный план

gantt
    title План разработки MONAECO MVP
    dateFormat YYYY-MM-DD
    axisFormat %b %Y

    section Исследования
    Фаза исследований (И1–И12)       :research, 2026-04-14, 35d

    section Ядро
    Sprint 0 · Инфраструктура        :s0, after research, 7d
    Sprint 1 · Онтологии             :s1, after s0, 14d
    Sprint 2 · Тезаурус + UI-каркас  :s2, after s1, 14d
    Sprint 3 · Агент разметки        :s3, after s2, 14d

    section Ядро + опции
    Sprint 4 · Концепты + интеграция :s4, after s3, 14d
    Sprint 5 · Поисковый движок      :s5, after s4, 14d
    Sprint 6 · NLG + провенанс       :s6, after s5, 14d

    section Опции
    Sprint 7 · Визуализация          :s7, after s6, 14d
    Sprint 8 · Эксп. панель + админ  :s8, after s7, 14d

    section Финализация
    Sprint 9 · Данные + E2E          :s9, after s8, 14d
    Sprint 10 · Полировка + релиз    :s10, after s9, 14d
    Буфер                            :buffer, after s10, 14d
    MVP-презентация                  :milestone, after buffer, 0d

16. Тестирование

16.1. Уровни тестирования

Уровень	Что тестируем	Инструмент
Unit	Функции, компоненты, утилиты	pytest (бэкенд), Vitest (фронтенд)
Integration	API endpoints, SPARQL queries	pytest + httpx, Playwright
E2E	Полные сценарии (загрузка → поиск → ответ)	Playwright
Ontology	Консистентность онтологий	Openllet reasoner
Data Quality	SHACL-валидация загружаемых данных	pyshacl
Performance	Время ответа, параллельные запросы	Locust

16.2. Критерии качества

Метрика	Порог MVP
Покрытие unit-тестами (бэкенд)	≥ 70%
Покрытие unit-тестами (фронтенд)	≥ 60%
Время ответа поиска (p95)	≤ 3 секунды
Время загрузки страницы (LCP)	≤ 2 секунды
Точность NER (F1 на тестовом наборе)	≥ 0.75
Онтология: 0 inconsistencies	Обязательно
SHACL: 0 violations в рабочих данных	Обязательно

17. Развёртывание и инфраструктура

17.1. Окружения

Окружение	Назначение	Инфраструктура
Local	Разработка	Docker Compose на машине разработчика
Staging	Тестирование, демонстрации	VPS / облако (1 сервер)
Production	Боевая эксплуатация	Kubernetes (планируется после MVP)

17.2. Docker Compose (MVP)

services:
  oxigraph:      # Графовая БД + SPARQL endpoint
  redis:         # Кэш + очередь задач
  api:           # FastAPI бэкенд (включая NLG-модуль)
  worker:        # Celery worker (разметка документов)
  frontend:      # Vue.js SPA (nginx)
  prometheus:    # Метрики
  grafana:       # Дашборды
  loki:          # Централизованные логи

graph LR
    User["👤 Пользователь"] -->|":443"| FE

    subgraph Docker["Docker Compose"]
        FE["🌐 frontend<br/><i>nginx · Vue.js</i><br/>:80"]
        API["⚡ api<br/><i>FastAPI</i><br/>:8000"]
        Worker["🔄 worker<br/><i>Celery</i>"]
        OX["🗄️ oxigraph<br/><i>SPARQL</i><br/>:7878"]
        Redis["📦 redis<br/><i>кэш + очередь</i><br/>:6379"]
        Prom["📊 prometheus<br/>:9090"]
        Graf["📈 grafana<br/>:3000"]
        Loki["📝 loki<br/>:3100"]
    end

    FE -->|REST / WS| API
    API --> OX
    API --> Redis
    API --> Worker
    Worker --> OX
    Worker --> Redis
    Prom --> API & OX & Redis
    Graf --> Prom & Loki
    API & Worker -.->|logs| Loki

    style FE fill:#e8f5e9,stroke:#4CAF50
    style API fill:#fff3e0,stroke:#FF9800
    style OX fill:#f3e5f5,stroke:#9C27B0
    style Worker fill:#fff3e0,stroke:#FF9800
    style Redis fill:#fce4ec,stroke:#E91E63

17.3. Провайдер инфраструктуры

Рекомендуемый провайдер: Selectel (дата-центры в Москве и Санкт-Петербурге).

Преимущества	Детали
Российский хостинг	Соответствие ФЗ-152, низкая латентность
Managed Kubernetes	Доступен для post-MVP масштабирования
S3-совместимое хранилище	Для документов и бэкапов
Конкурентные цены	8 vCPU / 32 GB: ~12 000 руб/мес

Альтернативы: Timeweb Cloud (дешевле, ~8 000 руб/мес), Yandex Cloud (дороже, но больше managed-сервисов).

17.4. Требования к серверу (staging)

Ресурс	Минимум	Рекомендуемый
CPU	4 vCPU	8 vCPU
RAM	16 GB	32 GB
Диск	100 GB SSD	200 GB SSD
ОС	Ubuntu 22.04+	Ubuntu 24.04

17.5. Бэкапы

Oxigraph: ежедневный дамп RDF (N-Quads) → S3/аналог
Redis: RDB snapshot каждые 6 часов
Загруженные документы: хранение на S3/аналог

17.6. Процедура отката при ошибках импорта

Сценарий	Действие
Bad document import (corrupt Named Graph)	`DROP GRAPH` по URI компании → повторный импорт из исходного документа
Ontology import breaks inference	Восстановление онтологического графа из Git (OWL-файлы под version control, см. §7.3)
Agent produces malformed RDF	SHACL-валидация отклоняет до загрузки; если прошла — `DROP GRAPH` + re-import
Partial SPARQL UPDATE failure	Oxigraph: транзакции атомарны (all-or-nothing на уровне одного UPDATE)

Принцип: Каждый Named Graph можно DROP + перезагрузить из первоисточника. Онтологии хранятся в Git. Данные компаний — из исходных документов (перезапуск агента разметки).

18. Интеграция с Knowdy (этап 2)

18.1. Предусловия

Интеграция с Knowdy начинается, когда выполнено хотя бы одно из условий:

Knowdy альфа-релиз + рабочий эндпоинт /query
Knowdy добавляет SPARQL-совместимый интерфейс
Опубликована полная спецификация GSL (для написания адаптера)

18.2. Варианты интеграции

flowchart LR
    subgraph MVP["Этап 1 · MVP"]
        App["MONAECO<br/>Бэкенд"]
        GS["GraphStore<br/><i>абстракция</i>"]
        Ox["OxigraphStore<br/><i>RDF / SPARQL</i>"]
        App --> GS --> Ox
    end

    subgraph Integration["Этап 2 · Интеграция"]
        direction TB
        A["Вариант A<br/>SPARQL в Knowdy"]
        B["Вариант B<br/>GSL ↔ RDF адаптер"]
        C["Вариант C<br/>Knowdy = кэш"]
    end

    subgraph Knowdy["Knowdy"]
        K["Knowdy<br/><i>GSL · C11/Go</i>"]
    end

    Ox -.->|"замена"| A
    Ox -.->|"адаптер"| B
    Ox -.->|"синхронизация"| C
    A --> K
    B --> K
    C --> K

    style MVP fill:#e8f5e9,stroke:#2E7D32
    style Integration fill:#fff8e1,stroke:#F9A825
    style Knowdy fill:#f3e5f5,stroke:#9C27B0

Вариант A: SPARQL-совместимость в Knowdy

Дмитрий добавляет SPARQL endpoint в Knowdy
Мы переключаем хранилище: Oxigraph → Knowdy
Минимальные изменения в нашем коде

Вариант B: Адаптерный слой GSL ↔ RDF

Мы пишем bidirectional adapter: RDF/SPARQL → GSL/Knowdy API
Трудоёмкость зависит от полноты спецификации GSL
Оценка: 2–4 спринта дополнительно

Вариант C: Knowdy как кэширующий слой

Oxigraph остаётся основным хранилищем
Knowdy используется для специализированных задач (быстрый поиск, кастомные запросы)
Синхронизация между хранилищами

18.3. Подготовка к интеграции

Уже на этапе MVP мы закладываем возможность замены хранилища:

Абстракция GraphStore с методами query(), update(), import_ontology()
Реализация OxigraphStore (MVP) — позже добавляется KnowdyStore
Все SPARQL-запросы в шаблонах, не хардкодятся

19. Риски и митигации

quadrantChart
    title Risk Map
    x-axis "Low probability" --> "High probability"
    y-axis "Low impact" --> "High impact"

    R1 Data delays: [0.8, 0.5]
    R7 NL-SPARQL complexity: [0.75, 0.5]
    R12 Scope creep: [0.75, 0.5]
    R8 Key person risk: [0.5, 0.8]
    R11 Knowledge Eng: [0.5, 0.8]
    R4 Oxigraph perf: [0.25, 0.85]
    R2 NER quality: [0.5, 0.5]
    R3 NLG quality: [0.5, 0.5]
    R5 Req changes: [0.5, 0.5]
    R10 OWL reasoning: [0.5, 0.5]
    R6 Ontology size: [0.5, 0.3]
    R9 Licenses: [0.5, 0.5]

#	Риск	Вероятность	Влияние	Митигация
R1	Тестовые данные от компаний задерживаются	Высокая	Среднее	Использовать открытые GRI-отчёты и данные OSDU. Запросить данные до начала спринтов
R2	Качество NER недостаточно для нефтегазовых терминов	Средняя	Среднее	Fine-tuning spaCy на нефтегазовом корпусе; fallback на ручную разметку
R3	Качество NLG недостаточно на RU/ZH	Средняя	Среднее	Сравнительная оценка в И5; шаблонный fallback; LLM-полировка
R4	Oxigraph не справляется с объёмом данных	Низкая	Высокое	Переход на Virtuoso (проверенное production-решение)
R5	MONAECO меняет требования к функциональности	Средняя	Среднее	Итеративный подход: демо каждые 2 недели, Change Request процесс
R6	Онтологии ENVO/ISO 15926 слишком велики для импорта целиком	Средняя	Низкое	Импортировать подмножества, релевантные домену
R7	NL→SPARQL трансляция слишком сложна для шаблонного подхода	Высокая	Среднее	Начать с шаблонов; LLM-assisted как запасной вариант (NL→SPARQL через Claude с валидацией)
R8	Key person risk (Дмитрий Дмитриев — единственный техконтакт)	Средняя	Высокое	Документировать все договорённости; не блокировать MVP на Knowdy
R9	Лицензионные ограничения на онтологии или данные	Средняя	Среднее	Проверить лицензии всех импортируемых онтологий до начала разработки
R10	Производительность OWL-рассуждений (Openllet/HermiT через Java)	Средняя	Среднее	Ограничить reasoning до конкретных паттернов; батчевый режим; кэширование результатов
R11	Knowledge Engineer не найден или уходит	Средняя	Высокое	Документировать все онтологические решения; парное владение знаниями с Tech Lead
R12	Scope creep (расширение требований сверх MVP)	Высокая	Среднее	Чёткие границы MVP (раздел 3); Change Request процесс; еженедельный sync

20. Критерии приёмки MVP

20.1. Функциональные

#	Критерий	Метод проверки
A1	Система содержит данные из ≥10 документов	Подсчёт Named Graphs
A2	Поиск на EN/RU/ZH возвращает релевантные результаты	Тестовый набор: 20 запросов × 3 языка. Precision ≥ 0.8 (≥80% результатов релевантны), Recall ≥ 0.6 (≥60% ожидаемых фактов найдены). Оценка двумя экспертами
A3	NLG генерирует текст на 3 языках	Сравнение с эталонными текстами
A4	Каждый факт имеет цепочку провенанса	SPARQL-проверка наличия prov:wasDerivedFrom
A5	Противоречия обнаруживаются и отображаются	Тест: загрузить 2 документа с разными значениями
A6	Фасетная навигация работает (≥ 4 фасета)	UI-тест
A7	Визуализация графа и карта интерактивны	E2E-тест
A8	Загрузка документа через UI: PDF → факты в графе	E2E-тест

20.2. Нефункциональные

#	Критерий	Порог
N1	Время ответа поиска (p95)	≤ 3 секунд
N2	Одновременные пользователи	≥ 20
N3	Время загрузки страницы	≤ 2 секунд
N4	Доступность на staging	≥ 99% (за неделю)
N5	Поддержка 3 языков	EN, RU, ZH

21. Дополнительные возможности

Возможности, не входящие в MVP, но рекомендуемые для следующих этапов:

21.1. RAG (Retrieval-Augmented Generation)

Пользователи часто хотят «поговорить с данными» в свободной форме. RAG-подход:

Вопрос пользователя → извлечение фактов из графа → LLM формирует развёрнутый ответ с цитированием источников
Провенанс работает: каждый факт в ответе со ссылкой на источник
Значительно снижает порог входа для неподготовленных пользователей

21.2. Система уведомлений

Роль	Событие	Канал
Эксперт	Новые кандидаты в концепты	Email + in-app
Администратор	Документ обработан / ошибка обработки	Email + in-app
Компания	Добавлены новые данные по сектору	Email

21.3. Дашборд аналитики платформы

Динамика: количество триплетов, документов, концептов, компаний
Топ-запросы пользователей
Покрытие онтологии (какие классы имеют экземпляры, какие — пусты)
Качество данных: % фактов с провенансом, % с высоким trust weight

21.4. Версионирование онтологии и данных

Semantic versioning для онтологии (monaeco:OilGasOntology v0.1.0)
Changelog изменений
Возможность «откатить» неудачное изменение

21.5. Collaborative editing для тезауруса

Комментарии к предложенным концептам
Голосование (N из M экспертов одобрили → концепт принят)
История изменений с diff

21.6. Сравнительные ESG-отчёты и бенчмаркинг

ESG-рейтинг компаний на основе данных в графе
Сравнительные таблицы и графики
Анонимизированный бенчмарк (компания видит своё место среди «средних»)

21.7. API для внешних интеграций

Программный доступ к данным (публичный API с ключами)
Webhook'и при обновлении данных
Bulk export (SPARQL CONSTRUCT → Turtle/JSON-LD dump)
Linked Data endpoint (dereferenceable URIs)

21.8. Полноценные цифровые двойники (этап 3+)

Эволюция формальных моделей процессов (этап 1) в полноценные digital twins:

Streaming API для непрерывного потока данных с IoT-датчиков
Агрегация временных рядов
Симуляция «что если» (what-if analysis)
Интеграция с SCADA-системами
Требует отдельного проекта и бюджета

21.9. Расширенный offline-режим

Примечание: Базовый экспорт (CSV результатов поиска, PDF-отчёт по компании) включён в MVP (Sprint 8, API /export/*).

Экспорт визуализаций графов и карт в SVG/PNG
Пакетная генерация отчётов по нескольким компаниям
Кэширование данных для работы без интернета (PWA)

22. Открытые вопросы для заказчика

Вопросы, требующие ответа до начала или в ходе разработки. Ответы могут повлиять на архитектуру, сроки и бюджет.

В1. Данные и контент

Вопрос: Есть ли доступ к реальным GRI-отчётам и документации компаний-участников клуба?

Контекст: В Sprint 9 запланирована загрузка 10–20 реальных документов. При этом риск R1 (задержка данных) оценивается как высокий. Если реальные данные недоступны, MVP будет строиться на открытых GRI-отчётах из публичных источников.

Что нужно от заказчика:

Подтверждение доступности хотя бы 5–10 документов к Sprint 3 (для тестирования агента разметки)
Форматы документов (PDF, DOCX, Excel?)
Ограничения конфиденциальности (NDA, анонимизация)

В2. Наполнение тезауруса

Вопрос: Кто создаёт начальные 2 000–5 000 нефтегазовых концептов для тезауруса?

Контекст: GEMET покрывает экологическую терминологию (импорт автоматический). Но нефтегазовые термины (SPE Glossary, IOGP Terminology) требуют ручной работы: создание концептов, перевод на 3 языка, размещение в иерархии SKOS.

Варианты:

A. Команда создаёт базовый набор (~500 концептов), заказчик верифицирует
B. Заказчик предоставляет глоссарий нефтегазовых терминов, команда конвертирует в SKOS
C. Совместная работа: команда импортирует открытые источники + агент обнаруживает новые термины из загруженных документов + эксперт со стороны заказчика верифицирует

В3. Стратегия NLG и роль LLM в генерации текста

Вопрос: Допустимо ли использование LLM для генерации текстовых ответов пользователю при условии гарантий фактологической точности?

Контекст: В текущих требованиях зафиксировано: «LLM — только вспомогательный инструмент, не для основных функций» и «LLM могут помогать с переводом, предобработкой, но не формировать ответы пользователю». Мы понимаем, что корневая причина этого ограничения — риск галлюцинаций (LLM может выдумать факты). Это обоснованное опасение.

Однако существуют проверенные методы минимизации этого риска, которые мы хотим представить. Выбор стратегии NLG существенно влияет на качество текста, сроки и стоимость разработки.

Вариант A: Шаблонный NLG + pymorphy3 (без LLM)

Факты из графа → шаблоны Jinja2 → морфологическая обработка (pymorphy3 для русского) → текст.

Параметр	Оценка
Фактологическая точность	100% — генерируется только из фактов
Качество текста (RU)	Среднее — правильные падежи, но «роботизированный» стиль
Качество текста (ZH)	Среднее — шаблоны без морфологии
Качество текста (EN)	Хорошее — английский морфологически прост
Сложность разработки	Низкая (2–3 недели)
Стоимость эксплуатации	Нулевая (нет API-вызовов)
Гибкость (новые типы ответов)	Низкая — каждый новый тип = новый шаблон

Вариант B: Grammatical Framework (GF)

Факты → абстрактное синтаксическое дерево → линеаризация через GF Resource Grammar Library → текст на 3 языках.

Параметр	Оценка
Фактологическая точность	100% — детерминированная грамматика
Качество текста (RU)	Высокое — полная падежная система
Качество текста (ZH)	Среднее-высокое — базовая грамматика есть
Качество текста (EN)	Высокое
Сложность разработки	Высокая (Haskell runtime, 2–3 месяца на доменную грамматику)
Стоимость эксплуатации	Нулевая
Гибкость	Средняя — новый тип = новая грамматика
Кадровый риск	Высокий — GF-разработчиков почти нет на рынке

Вариант C: LLM-grounded generation (с гарантиями)

Факты из графа → строгий промпт («опиши ТОЛЬКО эти факты, ничего не добавляй») → LLM → текст → автоматическая валидация (каждое утверждение в тексте привязано к исходному триплету).

Параметр	Оценка
Фактологическая точность	~99% с валидацией (см. гарантии ниже)
Качество текста (RU)	Отличное — естественный язык
Качество текста (ZH)	Отличное — нативное качество
Качество текста (EN)	Отличное
Сложность разработки	Средняя (3–4 недели с валидацией)
Стоимость эксплуатации	Средняя (~$0.01–0.05 за запрос)
Гибкость	Высокая — новый тип ответа = новый промпт

Гарантии фактологической точности (Вариант C):

Closed-context generation — LLM получает ТОЛЬКО конкретные факты из графа в структурированном виде. Модель физически не имеет доступа к другой информации.
Выходная валидация — каждое утверждение в сгенерированном тексте автоматически проверяется: существует ли соответствующий триплет в графе? Если нет — утверждение удаляется.
Провенанс — каждое предложение в ответе размечается ссылкой на конкретный триплет-источник.
Confidence scoring — если валидатор оценивает привязку как неуверенную, текст помечается для экспертной проверки.
Аудит — все запросы, промпты и ответы логируются для анализа.
Fallback — если валидация не проходит, система возвращает шаблонный ответ (Вариант A).

Вариант D: Гибрид (рекомендуемый)

Комбинация вариантов A и C:

Числовые данные, метрики, даты → шаблонный NLG (100% точность)
Описательный текст, обзоры → LLM-grounded с валидацией

Параметр	Оценка
Фактологическая точность	~99.5% (данные — 100%, нарратив — с валидацией)
Качество текста	Отличное
Сложность разработки	Средняя (4–5 недель)
Стоимость эксплуатации	Низкая (LLM только для описательного текста)

Наша рекомендация: Вариант D (гибрид). Он сочетает гарантированную точность для критичных данных с высоким качеством текста. Мы готовы реализовать любой вариант по выбору заказчика.

В4. Персональные данные и ФЗ-152

Вопрос: Будут ли в системе храниться персональные данные (ФИО авторов документов, экспертов, пользователей)?

Контекст: Если да — необходимо обеспечить соответствие ФЗ-152 «О персональных данных»:

Хранение данных на территории РФ (Selectel — московский ДЦ)
Политика обработки персональных данных
Согласие на обработку
Право на удаление

Что нужно от заказчика: Перечень персональных данных, которые будут обрабатываться. Наличие юриста для подготовки политики.

В5. Формальные модели процессов и цифровые двойники

Вопрос: Какие ожидания от «цифровых двойников» в MVP?

Контекст: В MVP запланирована статическая формальная модель одного производственного процесса в RDF (цепочка «добыча → переработка → отходы → выбросы» с визуализацией). Это не real-time цифровой двойник с IoT-данными и симуляцией.

Варианты:

A. MVP = статическая модель процесса в RDF + визуализация (текущий план)
B. MVP = статическая модель + подготовка API для будущего подключения IoT
C. Полноценный digital twin с IoT — отдельный проект (этап 3+, см. раздел 21.8)

Что нужно от заказчика: Подтверждение, что вариант A достаточен для MVP, или уточнение ожиданий.

В6. Product Owner

Вопрос: Кто со стороны MONAECO будет выполнять роль Product Owner?

Контекст: Для эффективной agile-разработки необходим человек со стороны заказчика, который приоритизирует задачи, принимает UX-решения и доступен для вопросов команды (см. раздел 14.2).

В7. Целевые рынки и инфраструктура

Вопрос: Каковы приоритеты по географии пользователей? Какие рынки являются целевыми для MVP?

Контекст: Выбор целевого рынка существенно влияет на архитектуру, инфраструктуру и бюджет. Ниже — ключевые различия.

Аспект	Международный / РФ	Китай (материковый)
Хостинг	Selectel (Москва), любой EU/US cloud	Необходим хостинг в КНР или гонконгский CDN (Great Firewall)
Карты	OpenStreetMap + Leaflet	Baidu Maps / Amap (AutoNavi) — стандарт для B2B в КНР. OSM доступен, но с бедными данными по Китаю
Аутентификация	Google, Microsoft OAuth	WeChat OAuth / DingTalk — стандарт для корпоративных пользователей
LLM (если используется)	Claude, GPT-4	Недоступны из КНР. Альтернативы: DeepSeek, Qwen (Alibaba), GLM (Zhipu)
Compliance	ФЗ-152 (РФ), GDPR (EU)	PIPL (Personal Information Protection Law), CSL (Cybersecurity Law)
CDN / доступность	Cloudflare, стандартные	Необходим китайский CDN (Alibaba Cloud CDN, Tencent CDN)
Домен	monaeco.org	Для КНР желателен ICP-лицензированный домен (.cn)

Что нужно от заказчика:

Приоритет рынков: только международный? только Китай? оба одновременно?
Если Китай — планируется ли ICP-лицензия и хостинг на территории КНР?
Какие OAuth-провайдеры нужны для целевых пользователей?
Допустимо ли использование китайских LLM (DeepSeek, Qwen) вместо западных?

Примечание: Если китайский рынок является приоритетным, рекомендуем провести дополнительное исследование (И13: Инфраструктура для китайского рынка) в фазе исследований.

В8. Изоляция данных между компаниями

Вопрос: Должны ли данные компаний быть изолированы друг от друга? Может ли компания A видеть данные компании B?

Контекст: В текущей архитектуре данные каждой компании хранятся в отдельном Named Graph (monaeco:data/{company_id}). Однако контроль доступа на уровне графов пока не реализован — в RBAC-матрице (раздел 8.2) разграничение только по ролям (Читатель / Эксперт / Администратор), но не по принадлежности к компании.

Варианты:

A. Открытые данные — все участники клуба видят данные друг друга (принцип «единого пространства знаний»)
B. Изолированные данные — каждая компания видит только свои данные + общие онтологии и тезаурус
C. Гибрид — компания выбирает, какие данные публиковать в общий доступ, а какие оставить приватными

Влияние на архитектуру:

Вариант A — минимальные изменения
Варианты B/C — необходим Graph-level ACL, SPARQL-запросы фильтруются по правам пользователя, усложнение бэкенда (+2–3 недели)

Что нужно от заказчика: Выбор варианта. Если B или C — это влияет на сроки и бюджет.

В9. Брендинг и дизайн интерфейса

Вопрос: Есть ли у MONAECO брендбук, фирменный стиль или макеты интерфейса?

Контекст: В текущем плане не выделена отдельная активность на UI/UX-дизайн. Если брендбук не предоставлен, фронтенд-разработчик будет принимать дизайн-решения самостоятельно на основе PrimeVue. Это может не совпасть с ожиданиями заказчика.

Что нужно от заказчика:

Брендбук / фирменные цвета / логотип
Референсы (примеры интерфейсов, которые нравятся)
Или подтверждение, что дизайн на усмотрение команды

В10. Ожидаемое количество пользователей

Вопрос: Сколько пользователей ожидается на этапе MVP?

Контекст: Критерий приёмки N2 предполагает ≥20 одновременных пользователей. На staging-сервере (8 vCPU, 32 GB RAM) одновременно работают 7+ Docker-контейнеров, включая графовую БД и OWL reasoner. При значительном количестве пользователей может потребоваться масштабирование инфраструктуры.

Что нужно от заказчика:

Ожидаемое количество зарегистрированных пользователей на MVP
Ожидаемое количество одновременных пользователей в пиковые моменты (например, демо-презентация)

23. Глоссарий

Термин	Определение
BFO	Basic Formal Ontology — верхнеуровневая онтология, ISO 21838-2
CCO	Common Core Ontologies — средний уровень между BFO и доменными онтологиями
ENVO	Environment Ontology — OWL-онтология экологических сред и процессов
ChEBI	Chemical Entities of Biological Interest — онтология химических веществ
GEMET	General Multilingual Environmental Thesaurus — мультиязычный тезаурус экологии
GF	Grammatical Framework — функциональный язык для мультиязычной генерации текста
GRI 11	Global Reporting Initiative Sector Standard for Oil and Gas — стандарт ESG-отчётности
GSL	General Semantics Language — кастомный язык Knowdy для представления графов
IOF	Industrial Ontologies Foundry — OWL-онтология промышленных процессов
ISO 15926	Стандарт интеграции данных жизненного цикла промышленных объектов
Knowdy	Графовая БД на C11/Go, разработка Дмитрия Дмитриева
Named Graph	Именованный граф — механизм RDF для группировки триплетов под единым URI
NER	Named Entity Recognition — извлечение именованных сущностей из текста
NLG	Natural Language Generation — генерация текста из структурированных данных
NLP	Natural Language Processing — обработка естественного языка
OntoLex-Lemon	W3C-стандарт связи онтологических концептов с лексическими формами
Openllet	OWL 2 DL рассуждатель (reasoner) с открытым кодом
Oxigraph	RDF-хранилище на Rust с SPARQL 1.1 endpoint
OWL	Web Ontology Language — язык описания онтологий (W3C)
PROV-O	W3C Provenance Ontology — онтология происхождения данных
QUDT	Quantities, Units, Dimensions and Types — онтология единиц измерения
RDF	Resource Description Framework — модель представления данных в виде триплетов
SHACL	Shapes Constraint Language — W3C-стандарт валидации RDF-данных
SKOS	Simple Knowledge Organization System — W3C-стандарт для тезаурусов
SPARQL	SPARQL Protocol and RDF Query Language — язык запросов к RDF-данным
pymorphy3	Морфологический анализатор/генератор для русского языка (Python)
STTL	SPARQL Template Transformation Language — язык шаблонов для генерации текста из SPARQL (Corese)
SSSOM	Simple Standard for Sharing Ontological Mappings — стандарт межонтологических маппингов
PIPL	Personal Information Protection Law — закон КНР о защите персональных данных (аналог GDPR)
ICP	Internet Content Provider — лицензия, необходимая для размещения веб-сайтов на территории КНР