trustgraph/docs/tech-specs/graphrag-performance-optimization.ru.md

# Техническое задание по оптимизации производительности GraphRAG

## Обзор

Данное техническое задание описывает комплексные оптимизации производительности алгоритма GraphRAG (Graph Retrieval-Augmented Generation) в системе TrustGraph. Текущая реализация страдает от существенных проблем с производительностью, которые ограничивают масштабируемость и время отклика. Данное задание охватывает четыре основные области оптимизации:

1. **Оптимизация обхода графа**: Устранение неэффективных рекурсивных запросов к базе данных и реализация пакетной обработки графа.
2. **Оптимизация разрешения меток**: Замена последовательной выборки меток параллельными/пакетными операциями.
3. **Улучшение стратегии кэширования**: Реализация интеллектуального кэширования с вытеснением по алгоритму LRU и предварительной загрузкой.
4. **Оптимизация запросов**: Добавление мемоизации результатов и кэширования векторов для повышения скорости отклика.

## Цели

- **Сокращение количества запросов к базе данных**: Достижение снижения общего количества запросов к базе данных на 50-80% за счет пакетной обработки и кэширования.
- **Улучшение времени отклика**: Ускорение построения подграфа в 3-5 раза и ускорение разрешения меток в 2-3 раза.
- **Повышение масштабируемости**: Поддержка более крупных графовых баз знаний с улучшением управления памятью.
- **Сохранение точности**: Сохранение существующей функциональности GraphRAG и качества результатов.
- **Обеспечение параллельности**: Улучшение возможностей параллельной обработки для множества одновременных запросов.
- **Уменьшение занимаемой памяти**: Реализация эффективных структур данных и управления памятью.
- **Добавление наблюдаемости**: Включение метрик производительности и возможностей мониторинга.
- **Обеспечение надежности**: Добавление механизмов обработки ошибок и таймаутов.

## Описание проблемы

Текущая реализация GraphRAG, находящаяся в файле `trustgraph-flow/trustgraph/retrieval/graph_rag/graph_rag.py`, имеет ряд критических проблем с производительностью, которые серьезно влияют на масштабируемость системы:

### Текущие проблемы с производительностью

**1. Неэффективный обход графа (`follow_edges` function, строки 79-127)**
- Выполняет 3 отдельных запроса к базе данных для каждой сущности на каждом уровне глубины.
- Шаблон запроса: запросы на основе субъекта, предиката и объекта для каждой сущности.
- Отсутствие пакетной обработки: Каждый запрос обрабатывает только одну сущность за раз.
- Отсутствие обнаружения циклов: Может повторно посещать одни и те же узлы несколько раз.
- Рекурсивная реализация без мемоизации приводит к экспоненциальной сложности.
- Временная сложность: O(entities × max_path_length × triple_limit³)

**2. Последовательное разрешение меток (`get_labelgraph` function, строки 144-171)**
- Обрабатывает каждый компонент тройки (субъект, предикат, объект) последовательно.
- Каждый вызов `maybe_label` потенциально вызывает запрос к базе данных.
- Отсутствует параллельное выполнение или пакетная обработка запросов меток.
- Приводит до 3 × subgraph_size отдельных запросов к базе данных.

**3. Примитивная стратегия кэширования (`maybe_label` function, строки 62-77)**
- Простой кэш в виде словаря без ограничений размера или TTL.
- Отсутствие политики вытеснения из кэша приводит к неограниченному росту использования памяти.
- Пропуски в кэше вызывают отдельные запросы к базе данных.
- Отсутствует предварительная загрузка или интеллектуальное "прогрев" кэша.

**4. Субоптимальные шаблоны запросов**
- Запросы на поиск сходства векторов сущностей не кэшируются между похожими запросами.
- Отсутствует мемоизация результатов для повторяющихся шаблонов запросов.
- Отсутствует оптимизация запросов для распространенных сценариев доступа.

**5. Критические проблемы с временем жизни объектов (`rag.py:96-102`)**
- **Объект GraphRag пересоздается для каждого запроса**: Новый экземпляр создается для каждого запроса, что приводит к потере всех преимуществ кэширования.
- **Объект Query имеет очень короткое время жизни**: Создается и уничтожается в рамках выполнения одного запроса (строки 201-207).
- **Кэш меток сбрасывается для каждого запроса**: "Прогрев" кэша и накопленные знания теряются между запросами.
- **Накладные расходы на повторное создание клиента**: Клиенты базы данных потенциально переподключаются для каждого запроса.
- **Отсутствует оптимизация между запросами**: Невозможно воспользоваться преимуществами шаблонов запросов или совместного использования результатов.

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

Текущий наихудший сценарий для типичного запроса:
- **Извлечение сущности**: 1 запрос на поиск сходства векторов.
- **Обход графа**: entities × max_path_length × 3 × triple_limit запросов.
- **Разрешение меток**: subgraph_size × 3 отдельных запросов на метки.

Для параметров по умолчанию (50 сущностей, глубина 2, лимит 30 троек, размер подграфа 150):
- **Минимальное количество запросов**: 1 + (50 × 2 × 3 × 30) + (150 × 3) = **9,451 запросов к базе данных**.
- **Время отклика**: 15-30 секунд для графов умеренного размера.
- **Использование памяти**: Неограниченный рост кэша со временем.
- **Эффективность кэша**: 0% - кэш сбрасывается при каждом запросе.
- **Накладные расходы на создание объектов**: Объекты GraphRag + Query создаются/уничтожаются для каждого запроса.

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

- Поддерживать графовые базы знаний предприятия с миллионами сущностей.
- Обеспечивать время отклика менее 1 секунды для типичных запросов.
- Обрабатывать сотни одновременных запросов GraphRAG.
- Эффективно масштабироваться с ростом размера и сложности графа.

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

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

Оптимизация производительности GraphRAG требует следующих технических компонентов:

#### 1. **Архитектурная реорганизация для управления временем жизни объектов**
   - **Сделать GraphRag долгоживущим**: Перенести экземпляр GraphRag на уровень Processor для сохранения данных между запросами.
   - **Сохранить кэши**: Поддерживать кэш меток, кэш векторов и кэш результатов запросов между запросами.
   - **Оптимизировать объект Query**: Рефакторинг Query как легковесного контекста выполнения, а не контейнера данных.
   - **Сохранение подключений**: Поддерживать подключения к базе данных между запросами.

   Модуль: `trustgraph-flow/trustgraph/retrieval/graph_rag/rag.py` (изменен)

#### 2. **Оптимизированный движок обхода графа**
   - Заменить рекурсивный `follow_edges` итеративным поиском в ширину.
   - Реализовать пакетную обработку сущностей на каждом уровне обхода.
   - Добавить обнаружение циклов с отслеживанием посещенных узлов.
   - Включить раннее завершение при достижении лимитов.

   Модуль: `trustgraph-flow/trustgraph/retrieval/graph_rag/optimized_traversal.py`

#### 3. **Параллельная система разрешения меток**
   - Пакетная обработка запросов меток для нескольких сущностей одновременно.
   - Реализация паттернов async/await для параллельного доступа к базе данных.
   - Добавление интеллектуальной предварительной загрузки для распространенных шаблонов меток.
   - Включение стратегий "прогрева" кэша меток.

   Модуль: `trustgraph-flow/trustgraph/retrieval/graph_rag/label_resolver.py`

#### 4. **Консервативный слой кэширования меток**
   - Кэш LRU с коротким TTL только для меток (5 минут) для баланса между производительностью и согласованностью.
   - Мониторинг метрик кэша и коэффициента попадания.
   - **Без кэширования векторов**: Уже кэшируются на уровне запроса, нет пользы для между запросами.
   - **Без кэширования результатов запросов**: Из-за проблем согласованности данных в графе.

   Модуль: `trustgraph-flow/trustgraph/retrieval/graph_rag/cache_manager.py`

#### 5. **Фреймворк оптимизации запросов**
   - Анализ шаблонов запросов и предложения по оптимизации.
   - Координатор пакетных запросов для доступа к базе данных.
   - Пулинг подключений и управление таймаутами запросов.
   - Мониторинг производительности.