Când un chatbot răspunde dintr-un contract de 120 de pagini, dintr-un manual tehnic sau dintr-o arhivă de politici interne, problema nu este doar „să găsească un fragment relevant”. Problema reală este să nu piardă contextul din jurul acelui fragment. Aici intră în scenă chunking-ul ierarhic, o tehnică folosită în aplicațiile RAG, adică Retrieval-Augmented Generation, pentru a combina căutarea precisă cu răspunsuri mai bine ancorate în documentul original.
De ce chunking-ul simplu nu mai ajunge
Într-un sistem RAG clasic, documentele mari sunt împărțite în bucăți mai mici, numite chunks. Acestea sunt transformate în embeddings și sunt căutate într-o bază vectorială. Microsoft explică în documentația Azure AI Search că împărțirea documentelor ajută atât la respectarea limitelor de tokeni ale modelelor de embeddings și chat, cât și la evitarea pierderii de date prin trunchiere.
Dar chunking-ul are un compromis dificil. Dacă fragmentele sunt prea mari, embedding-ul poate deveni mai puțin precis: bucata conține prea multe idei amestecate. Dacă fragmentele sunt prea mici, sistemul poate găsi propoziția corectă, dar pierde secțiunea, definițiile sau excepțiile care o explică. Pentru documente juridice, politici de securitate, specificații tehnice sau baze de cunoștințe interne, acest lucru poate duce la răspunsuri incomplete.
Ce înseamnă parent-child retrieval
Parent-child retrieval rezolvă parțial acest conflict prin două niveluri de text. „Child chunks” sunt fragmente mici, folosite pentru căutare precisă. „Parent chunks” sunt secțiuni mai mari, folosite pentru context atunci când sistemul construiește răspunsul.
LangChain descrie ParentDocumentRetriever exact în această logică: întâi sunt recuperate fragmente mici, apoi sistemul caută ID-ul documentului părinte și returnează documentul sau secțiunea mai mare din care provin acele fragmente. Cu alte cuvinte, copilul ajută la găsire, părintele ajută la înțelegere.
Un exemplu simplu: într-un manual intern, un child chunk poate conține propoziția „backupul critic se verifică lunar”. Dacă sistemul trimite la model doar această propoziție, răspunsul poate rata excepțiile. Parent chunk-ul poate include întreaga secțiune despre backup: cine verifică, ce sisteme intră în procedură, unde se păstrează rapoartele și ce se întâmplă dacă testul eșuează.
Cum se construiește o structură ierarhică
O implementare practică începe de la structura documentului. Pentru documente cu titluri clare, părinții pot fi capitole, secțiuni sau subsecțiuni. Pentru documente fără structură bună, se pot folosi fragmente mai mari, cu suprapunere controlată.
LlamaIndex documentează o abordare similară prin HierarchicalNodeParser și AutoMergingRetriever. Parserul creează o ierarhie de noduri „coarse-to-fine”, de la bucăți mari la bucăți mici. În exemplul din documentație, nodurile frunză sunt indexate în vector store, iar nodurile mai mari sunt păstrate în docstore. La interogare, AutoMergingRetriever poate combina fragmente mici care trimit către același părinte, pentru a oferi un context mai coerent.
Pentru o echipă care construiește un asistent AI peste documente mari, o schemă de pornire ar putea fi: document complet, capitol, secțiune, paragraf. Căutarea se face pe paragrafe sau fragmente scurte, dar răspunsul primește secțiunea relevantă, nu doar linia găsită.
Pași defensivi pentru o implementare mai bună
Primul pas este curățarea documentelor: titluri, tabele, note de subsol și metadate trebuie păstrate cât mai corect. Dacă parserul rupe greșit un tabel sau amestecă pagini diferite, retrieval-ul va moșteni problema.
Al doilea pas este atașarea de metadate utile: sursă, dată, versiune, număr de pagină, titlu de secțiune și ID-ul părintelui. Acestea nu sunt detalii decorative. Ele ajută la audit, la citarea surselor și la eliminarea documentelor vechi.
Al treilea pas este testarea cu întrebări reale. Nu ajunge să verifici dacă sistemul returnează ceva. Trebuie verificat dacă răspunsul citează secțiunea corectă, dacă nu amestecă două documente și dacă refuză elegant când informația nu există.
Limite și riscuri
Chunking-ul ierarhic nu face modelul infailibil. Dacă documentele sunt greșite, învechite sau contradictorii, sistemul poate returna tot context greșit. De asemenea, parent chunks prea mari pot readuce problema costului, latenței și a informației inutile. Pinecone subliniază că nu există o mărime universală potrivită pentru toate aplicațiile; strategia depinde de date, model, tipul de interogări și modul în care rezultatele sunt folosite.
În practică, parent-child retrieval este cel mai util când precizia și contextul trebuie păstrate împreună: proceduri interne, documentație tehnică, contracte, politici de securitate, manuale de produs sau arhive de suport. Nu este o rețetă magică, dar este una dintre cele mai solide metode pentru a reduce răspunsurile scoase din context în aplicațiile AI bazate pe documente mari.
