Parent Documents

Resumen

Parent document retrieval (recuperación por documentos padre) es una estrategia que separa el tamaño del chunk que se indexa del tamaño del chunk que se entrega al LLM. Fragmentos pequeños (child chunks) se indexan para búsqueda precisa. Cuando uno es relevante, se devuelve su contenedor más grande (parent chunk) como contexto para la generación.

Esto resuelve una tensión fundamental en RAG: fragmentos pequeños mejoran la precisión de recuperación (encuentran exactamente la información relevante), pero fragmentos grandes proporcionan el contexto necesario para respuestas coherentes.

Alcance y supuestos

Este paquete cubre parent document retrieval: la relación child/parent, estrategias de ratio y solapamiento, y trade-offs entre precisión de recuperación y coherencia de contexto.

No cubre estrategias básicas de chunking, selección de modelos de embedding, ni implementación interna de bases vectoriales. Asume que entiendes chunking, embeddings, retrieval y conceptos básicos de RAG.

Modelo mental

Piensa en un libro con marcadores. Pones marcadores en párrafos específicos (child chunks) para encontrar rápido lo que buscas. Pero cuando encuentras un marcador relevante, no arrancas solo ese párrafo — sacas el capítulo entero (parent chunk) para tener el contexto completo.

El marcador es preciso; el capítulo es informativo. Necesitas ambos.

Uso práctico

Usa parent document retrieval cuando:

• ✅ Necesitas chunks pequeños (100-300 tokens) para buena precisión de búsqueda.
• ✅ Pero esos chunks pequeños no tienen suficiente contexto por sí solos para responder bien.
• ✅ Tus documentos tienen estructura jerárquica natural (secciones, capítulos, párrafos).
• ❌ Tus chunks ya tienen suficiente contexto (500+ tokens con buena coherencia).
• ❌ La latencia extra de mapear child → parent es un problema para tu caso.

Ejemplo trabajado: child/parent retrieval para documentación técnica

Documentación técnica donde cada sección tiene sub-secciones que individualmente son muy específicas:

interface ParentChunk {
  id: string;
  text: string;       // el bloque grande (ej: sección completa)
  children: ChildChunk[];
}

interface ChildChunk {
  id: string;
  text: string;       // fragmento pequeño indexado
  parentId: string;
}

async function parentDocumentRetrieval(query: string): Promise<string[]> {
  // Indexar: chunks pequeños para búsqueda
  const queryEmbedding = await embedder.embed(query);

  // Buscar en child chunks (más precisos)
  const relevantChildren = await vectorSearch(queryEmbedding, {
    topK: 5,
    index: "child_chunks",  // índice separado de chunks pequeños
  });

  // Mapear a parents y deduplicar
  const parentIds = [...new Set(relevantChildren.map(c => c.parentId))];

  // Recuperar parents completos como contexto
  const parentChunks = parentIds.map(id => parentStore.get(id));

  // Opcional: limitar tokens totales para no exceder contexto del LLM
  return truncateToTokenLimit(parentChunks, 4000);
}

La magia está en que el child chunk de 150 tokens puede apuntar con precisión a un concepto, pero el LLM recibe el parent de 500-1000 tokens con el contexto completo que necesita para responder bien.

Evidencia

• LlamaIndex, Parent Document Retriever documenta la implementación del patrón donde chunks pequeños se usan para recuperación y chunks grandes para síntesis.
• LlamaIndex documentation, Chunking Strategies cubre las estrategias de chunking que complementan el parent document retrieval.