trustgraph/docs/tech-specs/ontorag.ru.md

---
layout: default
title: "OntoRAG: Техническая спецификация системы извлечения знаний на основе онтологий."
parent: "Russian (Beta)"
---

# OntoRAG: Техническая спецификация системы извлечения знаний на основе онтологий.

> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.

## Обзор

OntoRAG – это система извлечения знаний и запросов, основанная на онтологиях, которая обеспечивает строгую семантическую согласованность как при извлечении триплетов знаний из неструктурированного текста, так и при запросах к полученному графу знаний. Подобно GraphRAG, но с формальными ограничениями онтологий, OntoRAG гарантирует, что все извлеченные триплеты соответствуют предопределенным онтологическим структурам, и предоставляет возможности семантически-осведомленных запросов.

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

**Название сервиса**: `kg-extract-ontology`

## Цели

**Извлечение, соответствующее онтологии**: Обеспечить строгое соответствие всех извлеченных триплетов загруженным онтологиям.
**Динамический выбор контекста**: Использовать эмбеддинги для выбора соответствующих подмножеств онтологий для каждого фрагмента.
**Семантическая согласованность**: Поддерживать иерархии классов, области/диапазоны свойств и ограничения.
**Эффективная обработка**: Использовать векторные хранилища в памяти для быстрого сопоставления элементов онтологии.
**Масштабируемая архитектура**: Поддержка нескольких одновременных онтологий с разными доменами.

## Предыстория

Текущие сервисы извлечения знаний (`kg-extract-definitions`, `kg-extract-relationships`) работают без формальных ограничений, что может приводить к несовместимым или противоречивым триплетам. OntoRAG решает эту проблему следующим образом:

1. Загрузка формальных онтологий, определяющих допустимые классы и свойства.
2. Использование эмбеддингов для сопоставления текстового содержимого с соответствующими элементами онтологии.
3. Ограничение извлечения только производством триплетов, соответствующих онтологии.
4. Обеспечение семантической проверки извлеченных знаний.

Этот подход сочетает гибкость нейронного извлечения с строгостью формального представления знаний.

## Технический дизайн

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

Система OntoRAG состоит из следующих компонентов:

```
┌─────────────────┐
│  Configuration  │
│    Service      │
└────────┬────────┘
         │ Ontologies
         ▼
┌─────────────────┐      ┌──────────────┐
│ kg-extract-     │────▶│  Embedding   │
│   ontology      │      │   Service    │
└────────┬────────┘      └──────────────┘
         │                      │
         ▼                      ▼
┌─────────────────┐      ┌──────────────┐
│   In-Memory     │◀────│   Ontology   │
│  Vector Store   │      │   Embedder   │
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐      ┌──────────────┐
│    Sentence     │────▶│   Chunker    │
│    Splitter     │      │   Service    │
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐      ┌──────────────┐
│    Ontology     │────▶│   Vector     │
│    Selector     │      │   Search     │
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐      ┌──────────────┐
│    Prompt       │────▶│   Prompt     │
│   Constructor   │      │   Service    │
└────────┬────────┘      └──────────────┘
         │
         ▼
┌─────────────────┐
│  Triple Output  │
└─────────────────┘
```

### Детали компонента

#### 1. Загрузчик онтологий

**Назначение**: Извлекает и анализирует конфигурации онтологий из сервиса конфигураций, используя обновления, основанные на событиях.

**Реализация**:
Загрузчик онтологий использует очередь ConfigPush от TrustGraph для получения обновлений конфигураций онтологий, основанных на событиях. Когда элемент конфигурации типа "онтология" добавляется или изменяется, загрузчик получает обновление через очередь config-update и анализирует структуру JSON, содержащую метаданные, классы, объектные свойства и свойства типов данных. Эти проанализированные онтологии хранятся в памяти в виде структурированных объектов, которые могут быть эффективно доступны во время процесса извлечения.

**Основные операции**:
Подписаться на очередь config-update для конфигураций типа онтология
Анализировать структуры JSON онтологий в объекты OntologyClass и OntologyProperty
Проверять структуру и согласованность онтологии
Кэшировать проанализированные онтологии в памяти для быстрого доступа
Обрабатывать потоки данных с использованием векторных хранилищ, специфичных для каждого потока

**Местоположение реализации**: `trustgraph-flow/trustgraph/extract/kg/ontology/ontology_loader.py`

#### 2. Встраиватель онтологий

**Назначение**: Создает векторные представления для всех элементов онтологии, чтобы обеспечить сопоставление семантической схожести.

**Реализация**:
Встраиватель онтологий обрабатывает каждый элемент в загруженных онтологиях (классы, объектные свойства и свойства типов данных) и генерирует векторные представления с использованием сервиса EmbeddingsClientSpec. Для каждого элемента он объединяет идентификатор элемента, метки и описание (комментарий), чтобы создать текстовое представление. Этот текст затем преобразуется в векторное представление высокой размерности, которое отражает его семантическое значение. Эти представления хранятся в векторном хранилище FAISS, специфичном для каждого потока, вместе с метаданными об элементе, источнике онтологии и полном определении. Встраиватель автоматически определяет размерность представления из первого ответа на запрос.

**Основные операции**:
Создавать текстовые представления из идентификаторов элементов, меток и комментариев
Генерировать представления с помощью EmbeddingsClientSpec (используя asyncio.gather для пакетной обработки)
Хранить представления с исчерпывающими метаданными в векторном хранилище FAISS
Индексировать по онтологии, типу элемента и идентификатору элемента для эффективного поиска
Автоматически определять размерность представления для инициализации векторного хранилища
Использовать модели встраивания, специфичные для каждого потока, с независимыми векторными хранилищами

**Местоположение реализации**: `trustgraph-flow/trustgraph/extract/kg/ontology/ontology_embedder.py`

#### 3. Обработчик текста (Разделитель предложений)

**Назначение**: Разбивает текстовые фрагменты на более мелкие сегменты для точного сопоставления с онтологиями.

**Реализация**:
Обработчик текста использует NLTK для токенизации предложений и разметки частей речи, чтобы разделить входящие текстовые фрагменты на предложения. Он обрабатывает совместимость версий NLTK, пытаясь загрузить `punkt_tab` и `averaged_perceptron_tagger_eng`, с возможностью использования более старых версий, если это необходимо. Каждый текстовый фрагмент разбивается на отдельные предложения, которые могут быть независимо сопоставлены с элементами онтологии.

**Основные операции**:
Разделять текст на предложения с помощью токенизации предложений NLTK
Обрабатывать совместимость версий NLTK (punkt_tab vs punkt)
Создавать объекты TextSegment с текстом и информацией о позиции
Поддерживать как полные предложения, так и отдельные фрагменты

**Местоположение реализации**: `trustgraph-flow/trustgraph/extract/kg/ontology/text_processor.py`

#### 4. Выборщик онтологий

**Назначение**: Определяет наиболее релевантный поднабор элементов онтологии для текущего текстового фрагмента.

**Реализация**:
Выборщик онтологий выполняет семантическое сопоставление между текстовыми сегментами и элементами онтологии с использованием векторного поиска по схожести FAISS. Для каждого предложения из текстового фрагмента генерируется представление, и выполняется поиск в векторном хранилище наиболее похожих элементов онтологии с использованием косинусной схожести с настраиваемым порогом (по умолчанию 0,3). После сбора всех релевантных элементов выполняется комплексное разрешение зависимостей: если выбран класс, включаются его родительские классы; если выбрано свойство, добавляются классы, являющиеся доменом и диапазоном этого свойства. Кроме того, для каждого выбранного класса автоматически включаются **все свойства, которые ссылаются на этот класс** в качестве домена или диапазона. Это обеспечивает доступ к всем релевантным свойствам отношений.

**Основные операции**:
Генерация векторных представлений для каждого текстового сегмента (предложений)
Выполнение поиска ближайших соседей в векторном хранилище FAISS (top_k=10, threshold=0.3)
Применение порогового значения для фильтрации слабых соответствий
Разрешение зависимостей (родительские классы, домены, диапазоны)
**Автоматическое включение всех свойств, связанных с выбранными классами** (сопоставление домена/диапазона)
Построение согласованного подмножества онтологии со всеми необходимыми связями
Удаление дублирующихся элементов, появляющихся несколько раз

**Местоположение реализации**: `trustgraph-flow/trustgraph/extract/kg/ontology/ontology_selector.py`

#### 5. Создание запросов

**Назначение**: Создает структурированные запросы, которые направляют LLM (большую языковую модель) на извлечение только троек, соответствующих онтологии.

**Реализация**:
Сервис извлечения использует шаблон Jinja2, загруженный из `ontology-prompt.md`, который форматирует подмножество онтологии и текст для извлечения LLM. Шаблон динамически перебирает классы, объектные свойства и свойства типов данных, используя синтаксис Jinja2, представляя каждый из них с их описаниями, доменами, диапазонами и иерархическими связями. Запрос включает строгие правила использования только предоставленных элементов онтологии и запрашивает вывод в формате JSON для последовательного разбора.

**Основные операции**:
Использование шаблона Jinja2 с циклами по элементам онтологии
Форматирование классов с отношениями родительских классов (subclass_of) и комментариями
Форматирование свойств с ограничениями домена/диапазона и комментариями
Включение явных правил извлечения и требований к формату вывода
Вызов сервиса запросов с идентификатором шаблона "extract-with-ontologies"

**Местоположение шаблона**: `ontology-prompt.md`
**Местоположение реализации**: `trustgraph-flow/trustgraph/extract/kg/ontology/extract.py` (метод build_extraction_variables)

#### 6. Основной сервис извлечения

**Назначение**: Координирует все компоненты для выполнения сквозного извлечения троек на основе онтологии.

**Реализация**:
Основной сервис извлечения (KgExtractOntology) является уровнем оркестровки, который управляет полным рабочим процессом извлечения. Он использует шаблон TrustGraph's FlowProcessor с инициализацией компонентов для каждого потока. Когда поступает обновление конфигурации онтологии, он инициализирует или обновляет компоненты, специфичные для потока (загрузчик онтологии, эмбеддер, обработчик текста, селектор). Когда для обработки поступает текстовый фрагмент, он координирует конвейер: разделение текста на сегменты, поиск соответствующих элементов онтологии с помощью векторного поиска, построение ограниченного запроса, вызов сервиса запросов, разбор и проверка ответа, генерация троек определения онтологии и вывод как контентных троек, так и контекстов сущностей.

**Конвейер извлечения**:
1. Получение текстового фрагмента через очередь chunks-input
2. Инициализация компонентов потока, если это необходимо (при первом фрагменте или обновлении конфигурации)
3. Разделение текста на предложения с использованием NLTK
4. Поиск в векторном хранилище FAISS для поиска соответствующих концепций онтологии
5. Построение подмножества онтологии с автоматическим включением свойств
6. Создание переменных шаблона Jinja2
7. Вызов сервиса запросов с шаблоном extract-with-ontologies
8. Разбор ответа JSON в структурированные тройки
9. Проверка троек и расширение URI до полных URI онтологии
10. Генерация троек определения онтологии (классы и свойства с метками/комментариями/доменами/диапазонами)
11. Построение контекстов сущностей из всех троек
12. Вывод в очереди троек и entity-contexts

**Основные характеристики**:
Векторные хранилища на поток, поддерживающие различные модели эмбеддинга
Обновления онтологии, управляемые событиями, через очередь config-update
Автоматическое расширение URI с использованием URI онтологии
Элементы онтологии добавляются в графовое представление знаний со всеми метаданными
Контексты сущностей включают как контентные, так и элементы онтологии

**Местоположение реализации**: `trustgraph-flow/trustgraph/extract/kg/ontology/extract.py`

### Конфигурация

Сервис использует стандартный подход к конфигурации TrustGraph с аргументами командной строки:

```bash
kg-extract-ontology \
  --id kg-extract-ontology \
  --pulsar-host localhost:6650 \
  --input-queue chunks \
  --config-input-queue config-update \
  --output-queue triples \
  --entity-contexts-output-queue entity-contexts
```

**Основные параметры конфигурации**:
`similarity_threshold`: 0.3 (по умолчанию, настраивается в коде)
`top_k`: 10 (количество элементов онтологии для извлечения на сегмент)
`vector_store`: Per-flow FAISS IndexFlatIP с автоматически определенными измерениями
`text_processor`: NLTK с токенизацией предложений punkt_tab
`prompt_template`: "extract-with-ontologies" (шаблон Jinja2)

**Конфигурация онтологии**:
Онтологии загружаются динамически через очередь config-update с типом "ontology".

### Поток данных

1. **Фаза инициализации** (для каждого потока):
   Получение конфигурации онтологии через очередь config-update
   Разбор JSON онтологии в объекты OntologyClass и OntologyProperty
   Генерация векторных представлений для всех элементов онтологии с использованием EmbeddingsClientSpec
   Сохранение векторных представлений во временном хранилище FAISS для каждого потока
   Автоматическое определение размерности векторных представлений из первого ответа

2. **Фаза извлечения** (для каждого фрагмента):
   Получение фрагмента из очереди chunks-input
   Разбиение фрагмента на предложения с использованием NLTK
   Вычисление векторных представлений для каждого предложения
   Поиск в векторном хранилище FAISS наиболее релевантных элементов онтологии
   Создание подмножества онтологии с автоматическим включением свойств
   Формирование переменных шаблона Jinja2 с текстом и онтологией
   Вызов сервиса запросов с шаблоном extract-with-ontologies
   Разбор ответа в формате JSON и проверка корректности троек
   Расширение URI с использованием URI онтологии
   Генерация троек определения онтологии
   Создание контекстов сущностей из всех троек
   Отправка в очереди triples и entity-contexts

### Временное векторное хранилище

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

**Реализация: FAISS**

Система использует **FAISS (Facebook AI Similarity Search)** с IndexFlatIP для поиска по точному косинусному сходству. Основные характеристики:

**IndexFlatIP**: Точный поиск по косинусному сходству с использованием внутреннего произведения
**Автоматическое определение**: Размерность определяется из первого ответа на векторное представление
**Хранилища для каждого потока**: Каждый поток имеет независимое векторное хранилище для разных моделей векторных представлений
**Нормализация**: Все векторы нормализуются перед индексацией
**Пакетные операции**: Эффективное добавление пакетами для начальной загрузки онтологии

**Местоположение реализации**: `trustgraph-flow/trustgraph/extract/kg/ontology/vector_store.py`

### Алгоритм выбора подмножества онтологии

**Назначение**: Динамически выбирает минимальную релевантную часть онтологии для каждого текстового фрагмента.

**Подробные шаги алгоритма**:

1. **Сегментация текста**:
   Разбиение входного фрагмента на предложения с использованием NLP для определения границ предложений
   Извлечение именных групп, глагольных групп и именованных сущностей из каждого предложения
   Создание иерархической структуры сегментов с сохранением контекста

2. **Генерация векторных представлений**:
   Генерация векторных представлений для каждого текстового сегмента (предложений и фраз)
   Использование той же модели векторных представлений, что и для элементов онтологии
   Кэширование векторных представлений для повторяющихся сегментов для повышения производительности

3. **Поиск по сходству**:
   Для каждого векторного представления текстового сегмента выполняется поиск в векторном хранилище
   Извлекаются k (например, 10) наиболее похожих элементов онтологии
   Применяется порог сходства (например, 0.7) для фильтрации слабых совпадений
   Результаты агрегируются по всем сегментам, отслеживается частота совпадений

4. **Разрешение зависимостей**:
   Для каждого выбранного класса рекурсивно включаются все родительские классы до корневого
   Для каждого выбранного свойства включаются классы, являющиеся доменом и диапазоном
   Для обратных свойств обеспечивается включение обоих направлений
   Добавляются эквивалентные классы, если они существуют в онтологии

5. **Создание подмножества**:
   Удаление дубликатов элементов при сохранении взаимосвязей
   Организация в классы, объектные свойства и свойства типов данных
   Обеспечение сохранения всех ограничений и взаимосвязей
   Создание мини-онтологии, которая является самодостаточной и полной

**Пример**:
Данный текст: "The brown dog chased the white cat up the tree."
Сегменты: ["brown dog", "white cat", "tree", "chased"]
Соответствующие элементы: [dog (class), cat (class), animal (parent), chases (property)]
Зависимости: [animal (parent of dog and cat), lifeform (parent of animal)]
Окончательное подмножество: Полная мини-онтология с иерархией животных и отношением "chases"

### Проверка троек

**Назначение**: Обеспечивает строгое соответствие всех извлеченных троек ограничениям онтологии.

**Алгоритм проверки**:

1. **Валидация классов**:
   Проверьте, являются ли субъекты экземплярами классов, определенных в подмножестве онтологии.
   Для свойств объектов убедитесь, что объекты также являются допустимыми экземплярами классов.
   Проверьте имена классов по отношению к словарю классов онтологии.
   Обрабатывайте иерархии классов: экземпляры подклассов считаются допустимыми для ограничений родительского класса.

2. **Валидация свойств**:
   Убедитесь, что предикаты соответствуют свойствам в подмножестве онтологии.
   Различайте свойства объектов (от сущности к сущности) и свойства данных (от сущности к литералу).
   Проверьте, соответствуют ли имена свойств точно (с учетом пространства имен, если оно присутствует).

3. **Проверка домена/диапазона**:
   Для каждого свойства, используемого в качестве предиката, извлеките его домен и диапазон.
   Убедитесь, что тип субъекта соответствует или наследуется от домена свойства.
   Убедитесь, что тип объекта соответствует или наследуется от диапазона свойства.
   Для свойств данных убедитесь, что объект является литералом правильного типа XSD.

4. **Валидация кардинальности**:
   Отслеживайте количество использования свойств для каждого субъекта.
   Проверьте минимальную кардинальность: убедитесь, что обязательные свойства присутствуют.
   Проверьте максимальную кардинальность: убедитесь, что свойство не используется слишком много раз.
   Для функциональных свойств убедитесь, что присутствует не более одного значения для каждого субъекта.

5. **Валидация данных**:
   Разбирайте литеральные значения в соответствии с их объявленными типами XSD.
   Проверяйте, являются ли целые числа допустимыми числами, правильно ли отформатированы даты и т.д.
   Проверяйте шаблоны строк, если определены ограничения regex.
   Убедитесь, что URI имеют правильную структуру для типов xsd:anyURI.

**Пример валидации**:
Тройка: ("Buddy", "has-owner", "John")
Проверьте, что "Buddy" имеет тип класса, который может иметь свойство "has-owner".
Проверьте, существует ли "has-owner" в онтологии.
Убедитесь, что ограничение домена: субъект должен быть типа "Pet" или подкласса.
Убедитесь, что ограничение диапазона: объект должен быть типа "Person" или подкласса.
Если допустимо, добавьте в вывод; если недопустимо, зарегистрируйте нарушение и пропустите.

## Вопросы производительности

### Стратегии оптимизации

1. **Кэширование вложений**: Кэшируйте вложения для часто используемых текстовых фрагментов.
2. **Пакетная обработка**: Обрабатывайте несколько фрагментов параллельно.
3. **Индексирование векторного хранилища**: Используйте алгоритмы приблизительного поиска ближайших соседей для больших онтологий.
4. **Оптимизация запросов**: Минимизируйте размер запроса, включая только необходимые элементы онтологии.
5. **Кэширование результатов**: Кэшируйте результаты извлечения для идентичных фрагментов.

### Масштабируемость

**Горизонтальное масштабирование**: Несколько экземпляров экстрактора с общим кэшем онтологии.
**Разделение онтологии**: Разделите большие онтологии по доменам.
**Потоковая обработка**: Обрабатывайте фрагменты по мере их поступления, без пакетной обработки.
**Управление памятью**: Периодическая очистка неиспользуемых вложений.

## Обработка ошибок

### Сценарии сбоев

1. **Отсутствующие онтологии**: Переход к извлечению без ограничений.
2. **Сбой службы вложений**: Используйте кэшированные вложения или пропустите семантическое сопоставление.
3. **Тайм-аут службы запросов**: Повторите попытку с экспоненциальной задержкой.
4. **Недопустимый формат тройки**: Зарегистрируйте и пропустите неформатированные тройки.
5. **Несоответствия в онтологии**: Сообщите о конфликтах и используйте наиболее конкретные допустимые элементы.

### Мониторинг

Ключевые метрики для отслеживания:

Время загрузки онтологии и использование памяти.
Задержка генерации вложений.
Производительность векторного поиска.
Время отклика службы запросов.
Точность извлечения тройки.
Уровень соответствия онтологии.

## Путь миграции

### Из существующих экстракторов

1. **Параллельная работа**: Работайте параллельно с существующими экстракторами изначально.
2. **Постепенное развертывание**: Начните с определенных типов документов.
3. **Сравнение качества**: Сравните качество вывода с существующими экстракторами.
4. **Полная миграция**: Замените существующие экстракторы после проверки качества.

### Разработка онтологии

1. **Начальная версия из существующих**: Сгенерируйте начальные онтологии из существующих знаний.
2. **Итеративная доработка**: Дорабатывайте на основе шаблонов извлечения.
3. **Экспертная оценка**: Проверьте с экспертами в предметной области.
4. **Непрерывное улучшение**: Обновляйте на основе обратной связи об извлечении.

## Сервис запросов, чувствительный к онтологии

### Обзор

Сервис запросов, чувствительный к онтологии, предоставляет несколько путей запросов для поддержки различных бэкенд-хранилищ графов. Он использует знания онтологии для точного, семантически-осведомленного ответа на вопросы как в Cassandra (через SPARQL), так и в графовых хранилищах (Neo4j, Memgraph, FalkorDB) (через Cypher).

**Компоненты сервиса**:
`onto-query-sparql`: Преобразует естественный язык в SPARQL для Cassandra.
`sparql-cassandra`: Слой запросов SPARQL для Cassandra с использованием rdflib.
`onto-query-cypher`: Преобразует естественный язык в Cypher для графовых баз данных.
`cypher-executor`: Выполнение запросов Cypher для Neo4j/Memgraph/FalkorDB.

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

```
                    ┌─────────────────┐
                    │   User Query    │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐      ┌──────────────┐
                    │   Question      │────▶│   Sentence   │
                    │   Analyser      │      │   Splitter   │
                    └────────┬────────┘      └──────────────┘
                             │
                             ▼
                    ┌─────────────────┐      ┌──────────────┐
                    │   Ontology      │────▶│   Vector     │
                    │   Matcher       │      │    Store     │
                    └────────┬────────┘      └──────────────┘
                             │
                             ▼
                    ┌─────────────────┐
                    │ Backend Router  │
                    └────────┬────────┘
                             │
                 ┌───────────┴───────────┐
                 │                       │
                 ▼                       ▼
    ┌─────────────────┐          ┌─────────────────┐
    │ onto-query-     │          │ onto-query-     │
    │    sparql       │          │    cypher       │
    └────────┬────────┘          └────────┬────────┘
             │                            │
             ▼                            ▼
    ┌─────────────────┐          ┌─────────────────┐
    │   SPARQL        │          │   Cypher        │
    │  Generator      │          │  Generator      │
    └────────┬────────┘          └────────┬────────┘
             │                            │
             ▼                            ▼
    ┌─────────────────┐          ┌─────────────────┐
    │ sparql-         │          │ cypher-         │
    │ cassandra       │          │ executor        │
    └────────┬────────┘          └────────┬────────┘
             │                            │
             ▼                            ▼
    ┌─────────────────┐          ┌─────────────────┐
    │   Cassandra     │          │ Neo4j/Memgraph/ │
    │                 │          │   FalkorDB      │
    └────────┬────────┘          └────────┬────────┘
             │                            │
             └────────────┬───────────────┘
                          │
                          ▼
                 ┌─────────────────┐      ┌──────────────┐
                 │   Answer        │────▶│   Prompt     │
                 │  Generator      │      │   Service    │
                 └────────┬────────┘      └──────────────┘
                          │
                          ▼
                 ┌─────────────────┐
                 │  Final Answer   │
                 └─────────────────┘
```

### Конвейер обработки запросов

#### 1. Анализатор вопросов

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

**Описание алгоритма**:
Анализатор вопросов принимает входящий вопрос на естественном языке и разбивает его на значимые сегменты, используя тот же подход к разделению предложений, что и конвейер извлечения. Он определяет ключевые сущности, отношения и ограничения, упомянутые в вопросе. Каждый сегмент анализируется для определения типа вопроса (фактический, агрегирующий, сравнительный и т. д.) и ожидаемого формата ответа. Это разделение помогает определить, какие части онтологии наиболее релевантны для ответа на вопрос.

**Основные операции**:
Разделение вопроса на предложения и фразы
Определение типа и намерения вопроса
Извлечение упомянутых сущностей и отношений
Обнаружение ограничений и фильтров в вопросе
Определение ожидаемого формата ответа

#### 2. Сопоставитель онтологий для запросов

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

**Описание алгоритма**:
Подобно компоненту Ontology Selector конвейера извлечения, но оптимизирован для ответов на вопросы. Сопоставитель генерирует представления для сегментов вопроса и ищет в векторном хранилище соответствующие элементы онтологии. Однако он фокусируется на поиске концепций, которые будут полезны для построения запросов, а не для извлечения. Он расширяет выбор, включая связанные свойства, которые могут быть пройдены во время исследования графа, даже если они не упоминаются явно в вопросе. Например, если задан вопрос о "сотрудниках", он может включить такие свойства, как "работает в", "управляет" и "отчитывается", которые могут быть релевантны для поиска информации о сотрудниках.

**Стратегия сопоставления**:
Генерация представлений для сегментов вопроса
Поиск непосредственно упомянутых концепций онтологии
Включение свойств, соединяющих упомянутые классы
Добавление обратных и связанных свойств для обхода
Включение родительских/дочерних классов для иерархических запросов
Создание подмножества онтологии, ориентированного на запросы

#### 3. Маршрутизатор бэкэнда

**Назначение**: Маршрутизирует запросы к соответствующему бэкэнду в зависимости от конфигурации.

**Описание алгоритма**:
Маршрутизатор бэкэнда анализирует системную конфигурацию, чтобы определить, какой бэкэнд графа активен (на базе Cassandra или Cypher). Он направляет вопрос и подмножество онтологии к соответствующему сервису генерации запросов. Маршрутизатор также может поддерживать балансировку нагрузки между несколькими бэкэндами или механизмы отката, если основной бэкэнд недоступен.

**Логика маршрутизации**:
Проверка настроенного типа бэкэнда из системных настроек
Маршрутизация к `onto-query-sparql` для бэкэндов Cassandra
Маршрутизация к `onto-query-cypher` для Neo4j/Memgraph/FalkorDB
Поддержка конфигураций с несколькими бэкэндами с распределением запросов
Обработка сценариев отката и балансировки нагрузки

#### 4. Генерация SPARQL-запросов (`onto-query-sparql`)

**Назначение**: Преобразует вопросы на естественном языке в SPARQL-запросы для выполнения в Cassandra.

**Описание алгоритма**:
Генератор SPARQL-запросов принимает вопрос и подмножество онтологии и создает SPARQL-запрос, оптимизированный для выполнения в бэкэнде Cassandra. Он использует сервис подсказок со специальной для SPARQL-шаблоном, который включает семантику RDF/OWL. Генератор понимает шаблоны SPARQL, такие как пути свойств, необязательные предложения и фильтры, которые могут эффективно преобразовываться в операции Cassandra.

**Шаблон подсказки для генерации SPARQL**:
```
Generate a SPARQL query for the following question using the provided ontology.

ONTOLOGY CLASSES:
{classes}

ONTOLOGY PROPERTIES:
{properties}

RULES:
- Use proper RDF/OWL semantics
- Include relevant prefixes
- Use property paths for hierarchical queries
- Add FILTER clauses for constraints
- Optimise for Cassandra backend

QUESTION: {question}

SPARQL QUERY:
```

#### 5. Генерация запросов Cypher (`onto-query-cypher`)

**Назначение**: Преобразует вопросы, сформулированные на естественном языке, в запросы Cypher для графовых баз данных.

**Описание алгоритма**:
Генератор запросов Cypher создает нативные запросы Cypher, оптимизированные для Neo4j, Memgraph и FalkorDB. Он сопоставляет классы онтологии с метками узлов, а свойства - с отношениями, используя синтаксис сопоставления шаблонов Cypher. Генератор включает в себя оптимизации, специфичные для Cypher, такие как указания направления отношений, использование индексов и указания для планирования запросов.

**Шаблон запроса Cypher**:
```
Generate a Cypher query for the following question using the provided ontology.

NODE LABELS (from classes):
{classes}

RELATIONSHIP TYPES (from properties):
{properties}

RULES:
- Use MATCH patterns for graph traversal
- Include WHERE clauses for filters
- Use aggregation functions when needed
- Optimise for graph database performance
- Consider index hints for large datasets

QUESTION: {question}

CYPHER QUERY:
```

#### 6. Движок запросов SPARQL-Cassandra (`sparql-cassandra`)

**Назначение**: Выполняет запросы SPARQL к базе данных Cassandra с использованием библиотеки Python rdflib.

**Описание алгоритма**:
Движок SPARQL-Cassandra реализует обработчик SPARQL с использованием библиотеки rdflib на Python и пользовательского хранилища для Cassandra. Он преобразует графы запросов SPARQL в соответствующие запросы CQL для Cassandra, обрабатывая соединения, фильтры и агрегации. Движок поддерживает отображение RDF в Cassandra, которое сохраняет семантическую структуру, оптимизируя при этом для модели хранения колоночных семей Cassandra.

**Особенности реализации**:
Реализация интерфейса хранилища rdflib для Cassandra
Поддержка запросов SPARQL 1.1 с распространенными шаблонами
Эффективный перевод шаблонов триплетов в CQL
Поддержка путей свойств и иерархических запросов
Потоковая передача результатов для больших наборов данных
Объединение подключений и кэширование запросов

**Пример перевода**:
```sparql
SELECT ?animal WHERE {
  ?animal rdf:type :Animal .
  ?animal :hasOwner "John" .
}
```
Переводит в оптимизированные запросы Cassandra, использующие индексы и ключи разделения.

#### 7. Исполнитель запросов Cypher (`cypher-executor`)

**Назначение**: Выполняет запросы Cypher к базам данных Neo4j, Memgraph и FalkorDB.

**Описание алгоритма**:
Исполнитель запросов Cypher предоставляет унифицированный интерфейс для выполнения запросов Cypher в различных графовых базах данных. Он обрабатывает специфичные для базы данных протоколы подключения, подсказки для оптимизации запросов и нормализацию формата результатов. Исполнитель включает логику повторных попыток, пулинг соединений и управление транзакциями, соответствующие для каждого типа базы данных.

**Поддержка нескольких баз данных**:
**Neo4j**: Протокол Bolt, функции транзакций, подсказки для индексов
**Memgraph**: Собственный протокол, потоковая передача результатов, аналитические запросы
**FalkorDB**: Адаптация протокола Redis, оптимизации в памяти

**Функции выполнения**:
Управление подключениями, независимое от базы данных
Проверка запросов и синтаксический анализ
Применение ограничений по времени ожидания и ресурсам
Пагинация и потоковая передача результатов
Мониторинг производительности для каждого типа базы данных
Автоматическое переключение при отказе между экземплярами базы данных

#### 8. Генератор ответов

**Назначение**: Синтезирует ответ на естественном языке на основе результатов запроса.

**Описание алгоритма**:
Генератор ответов принимает структурированные результаты запроса и исходный вопрос, а затем использует сервис подсказок для генерации всестороннего ответа. В отличие от простых ответов, основанных на шаблонах, он использует LLM для интерпретации данных графа в контексте вопроса, обрабатывая сложные взаимосвязи, агрегации и выводы. Генератор может объяснить свою логику, ссылаясь на структуру онтологии и конкретные тройки, извлеченные из графа.

**Процесс генерации ответов**:
Форматирование результатов запроса в структурированный контекст
Включение соответствующих определений онтологии для ясности
Создание подсказки с вопросом и результатами
Генерация ответа на естественном языке с помощью LLM
Проверка ответа на соответствие намерению запроса
Добавление ссылок на конкретные сущности графа, если это необходимо

### Интеграция с существующими сервисами

#### Взаимодействие с GraphRAG

**Дополняющие**: onto-query обеспечивает семантическую точность, а GraphRAG обеспечивает широкое покрытие
**Общая инфраструктура**: Оба используют одну и ту же базу знаний и сервисы подсказок
**Маршрутизация запросов**: Система может маршрутизировать запросы к наиболее подходящему сервису в зависимости от типа вопроса
**Гибридный режим**: Можно комбинировать оба подхода для получения всесторонних ответов

#### Взаимодействие с OntoRAG Extraction

**Общие онтологии**: Использует одни и те же конфигурации онтологии, загруженные kg-extract-ontology
**Общий векторный магазин**: Повторно использует встроенные представления из сервиса извлечения
**Согласованная семантика**: Запросы выполняются над графами, созданными с использованием одних и тех же онтологических ограничений

### Примеры запросов

#### Пример 1: Простой запрос сущности
**Вопрос**: "Какие животные являются млекопитающими?"
**Соответствие онтологии**: [животное, млекопитающее, subClassOf]
**Сгенерированный запрос**:
```cypher
MATCH (a:animal)-[:subClassOf*]->(m:mammal)
RETURN a.name
```

#### Пример 2: Запрос взаимосвязей
**Вопрос**: "Какие документы были написаны Джоном Смитом?"
**Соответствие онтологии**: [документ, человек, автор]
**Сгенерированный запрос**:
```cypher
MATCH (d:document)-[:has-author]->(p:person {name: "John Smith"})
RETURN d.title, d.date
```

#### Пример 3: Запрос агрегации
**Вопрос**: "Сколько ног у кошек?"
**Соответствие онтологии**: [кошка, количество_ног (свойство типа данных)]
**Сгенерированный запрос**:
```cypher
MATCH (c:cat)
RETURN c.name, c.number_of_legs
```

### Конфигурация

```yaml
onto-query:
  embedding_model: "text-embedding-3-small"
  vector_store:
    shared_with_extractor: true  # Reuse kg-extract-ontology's store
  query_builder:
    model: "gpt-4"
    temperature: 0.1
    max_query_length: 1000
  graph_executor:
    timeout: 30000  # ms
    max_results: 1000
  answer_generator:
    model: "gpt-4"
    temperature: 0.3
    max_tokens: 500
```

### Оптимизация производительности

#### Оптимизация запросов

**Обрезка онтологии**: Включайте только необходимые элементы онтологии в запросы.
**Кэширование запросов**: Кэшируйте часто задаваемые вопросы и соответствующие запросы.
**Кэширование результатов**: Сохраняйте результаты для идентичных запросов в течение определенного периода времени.
**Пакетная обработка**: Обрабатывайте несколько связанных вопросов в рамках одного обхода графа.

#### Соображения масштабируемости

**Распределенное выполнение**: Параллелизуйте подзапросы по разделам графа.
**Инкрементные результаты**: Потоково передавайте результаты для больших наборов данных.
**Балансировка нагрузки**: Распределяйте нагрузку запросов между несколькими экземплярами сервиса.
**Пул ресурсов**: Управляйте пулами соединений к базам данных графов.

### Обработка ошибок

#### Сценарии сбоев

1. **Неправильная генерация запроса**: Переключайтесь на GraphRAG или простой поиск по ключевым словам.
2. **Несоответствие онтологии**: Расширьте поиск до более широкого подмножества онтологии.
3. **Тайм-аут запроса**: Упростите запрос или увеличьте время ожидания.
4. **Отсутствие результатов**: Предложите переформулировать запрос или связанные вопросы.
5. **Сбой сервиса LLM**: Используйте кэшированные запросы или ответы на основе шаблонов.

### Метрики мониторинга

Распределение сложности вопросов.
Размеры разделов онтологии.
Успешность генерации запросов.
Время выполнения запросов к графу.
Оценки качества ответов.
Коэффициенты попадания в кэш.
Частота ошибок по типам.

## Будущие улучшения

1. **Обучение онтологии**: Автоматически расширяйте онтологии на основе шаблонов извлечения.
2. **Оценка достоверности**: Присваивайте оценки достоверности извлеченным тройкам.
3. **Генерация объяснений**: Предоставляйте обоснование для извлечения троек.
4. **Активное обучение**: Запрашивайте подтверждение человеком для неопределенных извлечений.

## Соображения безопасности

1. **Предотвращение внедрения вредоносного кода**: Очищайте текст фрагментов перед построением запроса.
2. **Ограничения ресурсов**: Ограничивайте использование памяти для векторного хранилища.
3. **Ограничение скорости**: Ограничивайте количество запросов на извлечение от каждого клиента.
4. **Журналирование аудита**: Отслеживайте все запросы и результаты извлечения.

## Стратегия тестирования

### Модульное тестирование

Загрузчик онтологии с различными форматами.
Генерация и хранение векторов.
Алгоритмы разбиения предложений.
Расчеты векторного сходства.
Разбор и проверка троек.

### Интеграционное тестирование

Комплексная цепочка извлечения.
Интеграция с сервисом конфигурации.
Взаимодействие с сервисом запросов.
Обработка одновременных извлечений.

### Тестирование производительности

Обработка больших онтологий (1000+ классов).
Обработка больших объемов фрагментов.
Использование памяти под нагрузкой.
Тесты на задержку.

## План поставки

### Обзор

Система OntoRAG будет поставляться в четыре основные фазы, каждая из которых будет предоставлять постепенную ценность, одновременно создавая полную систему. План сосредоточен на создании основных возможностей извлечения, а затем добавлении функциональности запросов, а также оптимизации и расширенных функций.

### Фаза 1: Основа и основное извлечение

**Цель**: Создать базовый конвейер извлечения на основе онтологии с простым векторным сопоставлением.

#### Шаг 1.1: Основа управления онтологией
Реализовать загрузчик конфигурации онтологии (`OntologyLoader`).
Разбирать и проверять структуры JSON онтологии.
Создать хранилище онтологии в памяти и шаблоны доступа.
Реализовать механизм обновления онтологии.

**Критерии успеха**:
Успешная загрузка и разбор конфигураций онтологии.
Проверка структуры и согласованности онтологии.
Обработка нескольких одновременных онтологий.

#### Шаг 1.2: Реализация векторного хранилища
Реализовать простое векторное хранилище на основе NumPy в качестве первоначального прототипа.
Добавить реализацию векторного хранилища FAISS.
Создать абстракцию интерфейса векторного хранилища.
Реализовать поиск по сходству с настраиваемыми порогами.

**Критерии успеха**:
Эффективное хранение и извлечение эмбеддингов.
Выполнение поиска по схожести с задержкой менее 100 мс.
Поддержка бэкендов NumPy и FAISS.

#### Шаг 1.3: Конвейер эмбеддингов онтологии
Интеграция с сервисом эмбеддингов.
Реализация компонента `OntologyEmbedder`.
Генерация эмбеддингов для всех элементов онтологии.
Хранение эмбеддингов с метаданными в векторном хранилище.

**Критерии успеха**:
Генерация эмбеддингов для классов и свойств.
Хранение эмбеддингов с правильными метаданными.
Перегенерация эмбеддингов при обновлениях онтологии.

#### Шаг 1.4: Компоненты обработки текста
Реализация разбиения на предложения с использованием NLTK/spaCy.
Извлечение фраз и именованных сущностей.
Создание иерархии текстовых сегментов.
Генерация эмбеддингов для текстовых сегментов.

**Критерии успеха**:
Точное разбиение текста на предложения.
Извлечение значимых фраз.
Сохранение контекстных связей.

#### Шаг 1.5: Алгоритм выбора онтологии
Реализация сопоставления по схожести между текстом и онтологией.
Создание механизма разрешения зависимостей для элементов онтологии.
Создание минимальных когерентных подмножеств онтологии.
Оптимизация производительности генерации подмножеств.

**Критерии успеха**:
Выбор релевантных элементов онтологии с точностью >80%.
Включение всех необходимых зависимостей.
Генерация подмножеств менее чем за 500 мс.

#### Шаг 1.6: Базовый сервис извлечения
Реализация построения запросов для извлечения.
Интеграция с сервисом запросов.
Разбор и проверка ответов в формате триплетов.
Создание конечной точки сервиса `kg-extract-ontology`.

**Критерии успеха**:
Извлечение триплетов, соответствующих онтологии.
Проверка всех триплетов на соответствие онтологии.
Обработка ошибок извлечения.

### Фаза 2: Реализация системы запросов

**Цель**: Добавление возможностей запросов, учитывающих онтологию, с поддержкой нескольких бэкендов.

#### Шаг 2.1: Базовые компоненты системы запросов
Реализация анализатора вопросов.
Создание сопоставителя онтологии для запросов.
Адаптация векторного поиска для контекста запроса.
Создание компонента маршрутизации бэкендов.

**Критерии успеха**:
Анализ вопросов на семантические компоненты.
Сопоставление вопросов с релевантными элементами онтологии.
Маршрутизация запросов к соответствующему бэкенду.

#### Шаг 2.2: Реализация пути SPARQL
Реализация сервиса `onto-query-sparql`.
Создание генератора SPARQL-запросов с использованием LLM.
Разработка шаблонов запросов для генерации SPARQL.
Проверка синтаксиса сгенерированных SPARQL-запросов.

**Критерии успеха**:
Генерация корректных SPARQL-запросов.
Использование соответствующих шаблонов SPARQL.
Поддержка сложных типов запросов.

#### Шаг 2.3: Движок SPARQL-Cassandra
Реализация интерфейса хранилища rdflib для Cassandra.
Создание переводчика CQL-запросов.
Оптимизация сопоставления триплетов.
Обработка форматирования результатов SPARQL.

**Критерии успеха**:
Выполнение SPARQL-запросов на Cassandra.
Поддержка распространенных шаблонов SPARQL.
Возврат результатов в стандартном формате.

#### Шаг 2.4: Реализация пути Cypher
Реализация сервиса `onto-query-cypher`.
Создание генератора Cypher-запросов с использованием LLM.
Разработка шаблонов запросов для генерации Cypher.
Проверка синтаксиса сгенерированных Cypher-запросов.

**Критерии успеха**:
Генерация корректных Cypher-запросов.
Использование соответствующих шаблонов графов.
Поддержка Neo4j, Memgraph, FalkorDB.

#### Шаг 2.5: Исполнитель Cypher
Реализовать многобазовый исполнитель запросов Cypher.
Поддержка протокола Bolt (Neo4j/Memgraph).
Поддержка протокола Redis (FalkorDB).
Обработка нормализации результатов.

**Критерии успеха**:
Выполнение запросов Cypher на всех целевых базах данных.
Обработка специфических для базы данных различий.
Эффективное управление пулами соединений.

#### Шаг 2.6: Генерация ответов
Реализовать компонент генерации ответов.
Создать подсказки для синтеза ответов.
Форматировать результаты запросов для использования LLM.
Генерировать ответы на естественном языке.

**Критерии успеха**:
Генерировать точные ответы на основе результатов запросов.
Сохранять контекст из исходного вопроса.
Предоставлять четкие и лаконичные ответы.

### Фаза 3: Оптимизация и надежность

**Цель**: Оптимизировать производительность, добавить кэширование, улучшить обработку ошибок и повысить надежность.

#### Шаг 3.1: Оптимизация производительности
Реализовать кэширование эмбеддингов.
Добавить кэширование результатов запросов.
Оптимизировать векторный поиск с использованием индексов FAISS IVF.
Реализовать пакетную обработку для эмбеддингов.

**Критерии успеха**:
Уменьшить среднюю задержку запроса на 50%.
Поддерживать в 10 раз больше одновременных запросов.
Поддерживать время отклика менее 1 секунды.

#### Шаг 3.2: Продвинутая обработка ошибок
Реализовать комплексное восстановление после ошибок.
Добавить механизмы отката между путями запросов.
Создать логику повторных попыток с экспоненциальной задержкой.
Улучшить ведение журналов ошибок и диагностику.

**Критерии успеха**:
Грациозно обрабатывать все сценарии сбоев.
Автоматическое переключение на резервные системы.
Подробное сообщение об ошибках для отладки.

#### Шаг 3.3: Мониторинг и наблюдаемость
Добавить сбор показателей производительности.
Реализовать трассировку запросов.
Создать конечные точки проверки состояния.
Добавить мониторинг использования ресурсов.

**Критерии успеха**:
Отслеживать все ключевые показатели производительности.
Быстро выявлять узкие места.
Мониторить состояние системы в режиме реального времени.

#### Шаг 3.4: Управление конфигурацией
Реализовать динамические обновления конфигурации.
Добавить проверку конфигурации.
Создать шаблоны конфигурации.
Поддержка настроек, специфичных для среды.

**Критерии успеха**:
Обновлять конфигурацию без перезапуска.
Проверять все изменения конфигурации.
Поддерживать несколько сред развертывания.

### Фаза 4: Продвинутые функции

**Цель**: Добавить сложные возможности для производственного развертывания и расширенной функциональности.

#### Шаг 4.1: Поддержка нескольких онтологий
Реализовать логику выбора онтологии.
Поддержка межонтологических запросов.
Обработка версий онтологий.
Создать возможности объединения онтологий.

**Критерии успеха**:
Выполнять запросы между несколькими онтологиями.
Обрабатывать конфликты онтологий.
Поддерживать эволюцию онтологий.

#### Шаг 4.2: Интеллектуальная маршрутизация запросов
Реализовать маршрутизацию на основе производительности
Добавить анализ сложности запросов
Создать адаптивные алгоритмы маршрутизации
Поддержка A/B-тестирования для путей

**Критерии успеха**:
Оптимизировать маршрутизацию запросов
Учиться на основе производительности запросов
Улучшать маршрутизацию со временем

#### Шаг 4.3: Расширенные функции извлечения
Добавить оценку достоверности для троек
Реализовать генерацию объяснений
Создать механизмы обратной связи для улучшения
Поддержка инкрементного обучения

**Критерии успеха**:
Предоставлять оценки достоверности
Объяснять решения по извлечению
Постоянно повышать точность

#### Шаг 4.4: Подготовка к производству
Добавить ограничение скорости
Реализовать аутентификацию/авторизацию
Создать автоматизацию развертывания
Добавить резервное копирование и восстановление

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

### Этапы выполнения

1. **Этап 1** (Конец Фазы 1): Базовая работа системы извлечения, основанной на онтологии.
2. **Этап 2** (Конец Фазы 2): Полная система запросов с путями SPARQL и Cypher.
3. **Этап 3** (Конец Фазы 3): Оптимизированная, надежная система, готовая к тестированию.
4. **Этап 4** (Конец Фазы 4): Система, готовая к производству, с расширенными функциями.

### Смягчение рисков

#### Технические риски
**Масштабируемость векторного хранилища**: Начать с NumPy, постепенно перейти на FAISS.
**Точность генерации запросов**: Реализовать механизмы проверки и резервирования.
**Совместимость с бэкендом**: Тщательно тестировать с каждым типом базы данных.
**Узкие места производительности**: Профилировать и оптимизировать итеративно.

#### Операционные риски
**Качество онтологии**: Реализовать проверку и контроль согласованности.
**Зависимости от сервисов**: Добавить предохранители и механизмы резервирования.
**Ограничения ресурсов**: Отслеживать и устанавливать соответствующие лимиты.
**Согласованность данных**: Реализовать правильную обработку транзакций.

### Показатели успеха

#### Показатели успеха Фазы 1
Точность извлечения: >90% соответствия онтологии
Скорость обработки: <1 секунды на фрагмент
Время загрузки онтологии: <10 секунд
Задержка векторного поиска: <100 мс

#### Показатели успеха Фазы 2
Успешность выполнения запросов: >95%
Задержка запросов: <2 секунды (от начала до конца)
Совместимость с бэкендом: 100% для целевых баз данных
Точность ответов: >85% на основе доступных данных

#### Показатели успеха Фазы 3
Время безотказной работы системы: >99.9%
Скорость восстановления после ошибок: >95%
Процент попаданий в кэш: >60%
Количество одновременных пользователей: >100

#### Показатели успеха Фазы 4
Поддержка запросов к нескольким онтологиям: Полная поддержка
Оптимизация маршрутизации: Снижение задержки на 30%
Точность оценки достоверности: >90%
Развертывание в производственной среде: Обновления без простоев

## Ссылки

[OWL 2 Web Ontology Language](https://www.w3.org/TR/owl2-overview/)
[GraphRAG Architecture](https://github.com/microsoft/graphrag)
[Sentence Transformers](https://www.sbert.net/)
[FAISS Vector Search](https://github.com/facebookresearch/faiss)
[spaCy NLP Library](https://spacy.io/)
[rdflib Documentation](https://rdflib.readthedocs.io/)
[Neo4j Bolt Protocol](https://neo4j.com/docs/bolt/current/)