Иерархическая Чанкование и Поиск Родитель-Дочерний

1. Обзор концепции и системная проблема

Каждый инженер, который строил RAG-системы, сталкивался с неразрешимым противоречием:

• Пользователь спрашивает: "Какова политика таймаута для соединений Redis?".
• Векторная база находит строку: timeout: 3000.
• Если передать в модель только эту строку (мелкий чанк), модель не знает, к чему она относится: к Redis, PostgreSQL или HTTP-серверу.
• Если нарезать документацию огромными кусками по 1500 слов, семантический вектор становится "кашей", и нужная строка вообще не попадает в топ-5 результатов.

Hierarchical Chunking (Parent-Child Retrieval) решает эту задачу: высокая векторная разрешающая способность для поиска + широкий богатый контекст для генерации.

2. Архитектурная таксономия и ментальная модель

┌─────────────────────────────────────────────────────────────┐
│                 PARENT-CHILD HIERARCHY MAP                  │
├─────────────────────────────────────────────────────────────┤
│ 1. PARENT DOCUMENT (Полный раздел Markdown / Тело функции): │
│    Parent ID: `parent_auth_flow_42` (800 токенов)            │
│    • Полное описание жизненного цикла сессии и обработки ошибок│
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Разделить на мелкие дочерние     │
├─────────────────────────────────────────────────────────────┤
│ 2. CHILD CHUNKS (Индексированные в векторной базе):         │
│    • Child 1 (120 ток): [ Параметры создания куки ]         │
│    • Child 2 (140 ток): [ Ротация токенов и Redis TTL ] ◄─── │ СОВПАДЕНИЕ!
│    • Child 3 (100 ток): [ Обработка ошибок и 401 возвраты ]  │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Разрешить ссылку `parent_id`    │
├─────────────────────────────────────────────────────────────┤
│ 3. ВСТАВЛЕННЫЙ КОНТЕКСТ ДЛЯ МОДЕЛИ:                         │
│    Модель получает ЦЕЛЫЙ РОДИТЕЛЬСКИЙ ДОКУМЕНТ `parent_auth_flow_42│
│    ➔ Ноль фрагментации контекста, кристально ясный ответ!   │
└─────────────────────────────────────────────────────────────┘

3. Практические инженерные сценарии в продакшене

01. Техническая документация API с множеством эндпоинтов

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

02. Анализ судебных контрактов или юридических соглашений

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

4. Подводные камни, типовые ошибки и безопасность

• Дублирование родительских блоков (Parent Deduplication): Если три разных дочерних чанка из одного родительского блока попали в топ-3 результатов, наивный конвейер может трижды вставить один и тот же текст в промпт. Обязательно проводите дедупликацию по parent_id.
• Увеличение потребления токенов: Поскольку модель получает больший текст, средний размер контекста увеличивается. Регулируйте количество возвращаемых уникальных родителей (например, не более 3 родительских блоков на запрос).

5. Стратегический вывод для инженера 2026 года

Иерархический RAG — это самый элегантный способ преодолеть дилему размера чанка без перехода на чрезмерно сложные графовые архитектуры. Разделение пространства векторного индексирования и пространства чтения модели является золотым правилом качественного информационного поиска.