Recuperación padre-hijo y de pequeño a grande

Los sistemas RAG se enfrentan a una tensión: los fragmentos pequeños se recuperan con gran precisión porque cada uno se centra en una idea, pero carecen del contexto circundante que el LLM necesita para generar una respuesta completa. Los fragmentos grandes proporcionan un contexto abundante, pero reducen la precisión de recuperación porque coinciden débilmente con muchas consultas en lugar de hacerlo fuertemente con una sola. La división padre-hijo resuelve este dilema.

En la división padre-hijo, se crean dos capas de fragmentos a partir del mismo documento. Los fragmentos hijo son pequeños (por ejemplo, de 1 a 3 frases) y se transforman en embeddings y se indexan para la recuperación. Los fragmentos padre son secciones más grandes (por ejemplo, párrafos o páginas completos) que se almacenan por separado. Cuando se recupera un hijo, se devuelve su padre al LLM.

El primer paso consiste en dividir el documento en fragmentos padre grandes y, después, dividir cada padre en fragmentos hijo más pequeños. Cada fragmento hijo conserva una referencia —normalmente un campo de metadatos parent_id— que apunta a su padre. Esta correspondencia permite buscar el pasaje padre completo a partir de cualquier hijo recuperado.

Solo los fragmentos hijo se transforman en embeddings y se almacenan en la base de datos vectorial. Los fragmentos padre se almacenan en un almacén de clave-valor independiente (un diccionario en memoria, Redis o una base de datos de documentos). Así, el índice vectorial se mantiene denso y preciso, mientras que el contexto enriquecido permanece fuera de él.

Durante la recuperación, se genera el embedding de la consulta del usuario y se compara con los fragmentos hijo. Se encuentran los fragmentos hijo del top-k y sus referencias parent_id se resuelven buscando en el almacén de padres. A continuación, se inyectan en el prompt del LLM los pasajes padre, no los hijos. El LLM recibe un contexto amplio; la recuperación fue precisa.

LangChain proporciona la clase ParentDocumentRetriever, que implementa este patrón de forma integrada. Debe proporcionar un divisor para los documentos principales, un divisor para los documentos secundarios, un almacén vectorial para las incrustaciones de los documentos secundarios y un almacén de documentos para los documentos principales. La clase configura la jerarquía y gestiona la recuperación de forma transparente.

La recuperación de pequeño a grande es otro nombre para el mismo concepto: se recuperan fragmentos pequeños y precisos, pero después se amplían para incluir el contexto circundante antes de enviarlos al LLM. Algunas implementaciones no amplían el fragmento hasta un documento principal fijo, sino hasta una ventana de oraciones adyacentes, proporcionando al modelo las oraciones anteriores y posteriores al fragmento coincidente para mantener la continuidad contextual.

Es posible que se recuperen varios fragmentos secundarios del mismo documento principal para una consulta. Sin eliminación de duplicados, el mismo pasaje principal aparecería varias veces en el prompt y desperdiciaría tokens. Siempre debe eliminar los duplicados mediante el ID del documento principal antes de ensamblar el contexto. El ejemplo de código de la función de recuperación anterior lo hace con un conjunto seen_parent_ids.

La recuperación principal-secundaria funciona mejor cuando los documentos tienen una estructura jerárquica clara: capítulos con secciones, artículos con párrafos o wikis con subsecciones. Es especialmente eficaz para documentación técnica extensa en la que las preguntas precisas requieren respuestas localizadas, pero esas respuestas solo tienen sentido dentro de un contexto más amplio de la sección.

Una configuración habitual es la siguiente: fragmentos secundarios de 200 a 400 tokens (ideas individuales y concretas) y fragmentos principales de 1000 a 2000 tokens (secciones completas). Si los fragmentos secundarios son demasiado pequeños, se convierten en oraciones individuales que carecen de significado por sí solas. Si los fragmentos principales son demasiado grandes, comienza a reaparecer el problema de dilución del contexto que se intentaba evitar.

En resumen, las estrategias de fragmentación vistas hasta ahora son las siguientes: el tamaño fijo es rápido, pero rompe el contexto; la fragmentación semántica conserva la coherencia temática; y la fragmentación principal-secundaria optimiza tanto la precisión de la recuperación como la riqueza del contexto del LLM. En la mayoría de los sistemas RAG de producción que procesan documentos extensos, la fragmentación principal-secundaria ofrece la mejor calidad de recuperación con una complejidad manejable.

En esta lección ha aprendido que: los fragmentos secundarios permiten una recuperación precisa, mientras que los fragmentos principales proporcionan un contexto enriquecido; ParentDocumentRetriever de LangChain implementa este proceso automáticamente; y la eliminación de duplicados mediante el ID del documento principal evita repetir el contexto. A continuación exploraremos estrategias de fragmentación específicas para documentos de código y documentos HTML.