Hierarchical Chunking & Parent-Child Retrieval(Ієрархічний RAG та пошук 'Батьківський документ — Дочірній чанк')

1. Огляд концепції та системна проблема

Кожен інженер, який будував RAG-системи, стикався з нерозв'язним протиріччям:

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

Hierarchical Chunking (Parent-Child Retrieval) розв'язує цей вузол: висока векторна роздільна здатність для пошуку + широкий багатий контекст для генерації.

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

┌─────────────────────────────────────────────────────────────┐
│                 PARENT-CHILD HIERARCHY MAP                  │
├─────────────────────────────────────────────────────────────┤
│ 1. PARENT DOCUMENT (Full Markdown Section / Function Body): │
│    Parent ID: `parent_auth_flow_42` (800 tokens)            │
│    • Повний опис життєвого циклу сесії та обробки помилок   │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Split into granular children     │
├─────────────────────────────────────────────────────────────┤
│ 2. CHILD CHUNKS (Indexed in Vector Database):               │
│    • Child 1 (120 tok): [ Cookie creation parameters ]      │
│    • Child 2 (140 tok): [ Token rotation & Redis TTL ] ◄─── │ MATCH!
│    • Child 3 (100 tok): [ Error handling & 401 returns ]    │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Resolve `parent_id` link         │
├─────────────────────────────────────────────────────────────┤
│ 3. INJECTED CONTEXT FOR MODEL:                              │
│    Model receives ENTIRE PARENT DOCUMENT `parent_auth_flow_42│
│    ➔ Zero context fragmentation, crystal clear answer!      │
└─────────────────────────────────────────────────────────────┘

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

01. Технічна документація API з багатьма ендпоінтами

Батьківський чанк охоплює весь ендпоінт: опис, аргументи, коди відповідей та приклад коду. Дочірні чанки містять окремо опис кожного параметра. Користувач питає про один рідкісний параметр, але модель отримує весь контекст ендпоінту і пише правильний інтеграційний запит.

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

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

4. Підводні камені, типові помилки та безпека

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

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

Ієрархічний RAG — це найелегантніший спосіб подолати дилему розміру чанка без переходу на надскладні графові архітектури. Розділення простору векторного індексування та простору читання моделі є золотим правилом якісного інформаційного пошуку.