Recuperación y fragmentación de documentos para consultas eficaces

Curso de LangChain para Manejo y Recuperación de Documentos

Contenido del curso

Manejo de documentos

Indexación de vectores

Recuperación de documentos

Re-ranking semántico

RAG

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0010:27

Recuperación y fragmentación de documentos para consultas eficaces

Curso de LangChain para Manejo y Recuperación de Documentos

Clase 7 de 17

Clase 7 / 17

Recursos

Cuando tus datos ya están limpios y listos, el siguiente paso crítico es recuperar los documentos más relevantes para responder las preguntas de tus usuarios. Aquí es donde entran en juego los retrievers o recuperadores, y uno de los más poderosos es el Parent Retriever, una estrategia que combina lo mejor de los fragmentos pequeños y los documentos grandes.

¿Por qué existe una dicotomía entre documentos pequeños y grandes?

Al fragmentar documentos, te enfrentas a una decisión importante [1:06]:

Documentos pequeños: preservan la semántica y la precisión de oraciones y párrafos.
Documentos largos: preservan el contexto general del texto.

Si optas por documentos cada vez más grandes, los embeddings comienzan a perder precisión. Pero si solo usas fragmentos diminutos, pierdes el contexto necesario para que tu modelo de lenguaje genere respuestas completas. Ninguna de las dos opciones es perfecta por sí sola.

¿Cómo funciona el Parent Retriever?

El Parent Document Retriever resuelve esta dicotomía con una estrategia de dos niveles [1:56]:

Primero, tomas tu conjunto de documentos y los divides en fragmentos grandes llamados documentos padres (por ejemplo, capítulos de un libro).
Después, cada documento padre se fragmenta en documentos hijos, que son porciones más pequeñas y semánticamente precisas.
Cuando un usuario hace una query, el sistema busca coincidencias contra los documentos hijos, aprovechando su precisión semántica.
Una vez identificados los hijos relevantes, el sistema recupera el documento padre completo al que pertenecen.

De esta forma obtienes dos ventajas simultáneas: los fragmentos pequeños hacen match preciso con la consulta del usuario, y los documentos grandes aportan el contexto necesario para que el modelo de lenguaje responda de manera profunda y completa.

¿Dónde se almacenan padres e hijos?

Los documentos hijos, convertidos en vectores, se guardan en tu vector store (en este caso se usa Chroma) [3:18]. Los documentos padre se almacenan en un doc store o in-memory store, que podría ser una base de datos como Redis o simplemente la memoria del sistema para fines de prototipado.

¿Cómo se implementa un Parent Retriever con código?

Para construir este recuperador necesitas importar varios componentes [3:55]:

ParentDocumentRetriever: orquesta la relación entre padres e hijos.
InMemoryStore: almacena los documentos completos sin corte.
RecursiveCharacterTextSplitter: fragmenta los documentos en hijos.
Language: permite especificar el tipo de contenido (por ejemplo, Markdown).
Una vector store como Chroma para guardar los embeddings de los fragmentos pequeños.

El proceso de configuración sigue estos pasos:

Cargar los documentos usando un loader de LangChain. En el ejemplo se obtienen 964 documentos [4:48].
Definir un child splitter con RecursiveCharacterTextSplitter usando from_language para especificar que el contenido es Markdown. Se configura un chunkSize de 100 tokens y un chunkOverlap de 10 [5:15].
Crear la vector store con Chroma, asignándole una colección llamada full documents.
Crear el store en memoria con InMemoryStore para guardar los documentos completos.
Construir el retriever pasando la vector store, el doc store y el child splitter como parámetros [6:25].
Agregar los documentos llamando a retriever.add_documents().

¿Qué diferencia hay entre buscar en la vector store y usar el Parent Retriever?

Una vez configurado, puedes verificar que los 964 documentos completos están almacenados usando store.yield_keys() [7:28]. Al hacer una consulta como "MultiQuery Retriever will be able to overcome some of the limitations of...", la diferencia es clara [8:10]:

La búsqueda directa en la vector store devuelve cuatro fragmentos pequeños.
El Parent Retriever devuelve solo tres documentos únicos, porque detecta que dos de esos fragmentos pequeños pertenecen al mismo documento padre.

En lugar de entregar fragmentos repetitivos del mismo origen, el retriever trae el contexto completo una sola vez. Esto significa que tu modelo de lenguaje recibe información más rica y sin redundancias, lo que produce respuestas más profundas y coherentes [9:06].

La clave está en entender que varios fragmentos pequeños pueden pertenecer a un mismo documento grande. Al recuperar el padre en lugar de múltiples hijos redundantes, potencias la capacidad de tu modelo para dar respuestas completas. ¿Ya has probado esta estrategia con tus propios datos? Comparte tu experiencia en los comentarios.

Eber Laurente Lliuyacc

Hace 3 años

2. Retriever

Una vez que hemos logrado :

Extraer la data de manera efectiva
Limpiar de manera impecable

Ahora podemos trabajar en consultarlos, ubicar los mejores documentos par responder preguntas, documentos que tengan mayor relación con su query o petición.

2.1 Parent retriever

En la fragmentación de documentos nos encontraremos con una dicotomía: utilizar documentos cortos o documentos largos
- Documentos largos:
  - Ventaja: Ayudan a preservar el contexto general del texto
  - Desventaja: Mientras más grande, van perdiendo precisión en los embeddings
- Documentos cortos:
  - Ventaja: Ayudan a preservar la semántica y precisión de oraciones y párrafos. Los embedding reflejan un significado más exacto y específico.
  - Desventaja: Pierden el contexto general de texto
Entonces, ¿cuál es la mejor estrategia: Uso de ParentDocumentRetrieverEl flujo completo: los queries ubican a los Children Documents por la similitud de las chunks, también se ubican a los Parent documents, y ambos son insertados en el LLM. Con lo cual logramos precisión semántica por los Children y un mayor contexto con los Parent documents
1. Parent_splitter: Los documentos originales son cortados en secciones grandes. Por ejemplo, libros se cortan en capítulos. El resultados de la primera división (secciones grandes, capítulos) se denominan Parents
2. Child_splitter: Cada Parents es nuevamente divido en secciones más pequeñas, las que denominaremos Childrens
3. Los queries apuntan directamente a los Childrens
4. Para responder a las queries, nos traemos al Parent correspondiente al Children
5. Los Children se almacenan en el vector store, mientras que los Parent son almacenados en memory store o un doc store en una base de datos Redis

Manejo de documentos

Extracción y Fragmentación de Texto para IA

Extracción de Texto Contextual en HTML: Técnicas y Aplicaciones

Extracción de Texto en PDFs con Doku Gami

Fragmentación de Texto con Contexto en Documentos de Programación

Indexación de vectores

Indexación de Vectores para Optimizar Bases de Datos

Indexación Incremental y Limpieza de Vectores Duplicados

Recuperación de documentos

Recuperación y fragmentación de documentos para consultas eficaces

Fragmentación de Documentos para Modelos de Lenguaje

Etiquetado y Filtrado de Documentos con Modelos de Lenguaje

Filtrado Inteligente de Documentos con Metadatos y Modelos de Lenguaje

Implementación de MultiQuery Retrievers con LangChain y Pydantic

Combinación de Retrievers para Búsqueda de Documentos Relevantes

Re-ranking semántico

Integración de Reranking Semántico en Buscadores por Palabras Clave

Ranking por Relevancia Marginal Máxima en Documentos

Reordenamiento de Documentos en Recuperación Mejorada de Información

RAG

Implementación de Sistemas RAG para Mejora de Chatbots

Creación de Aplicación con Streamlit para Procesamiento de Documentos

Recuperación y fragmentación de documentos para consultas eficaces

Progreso del curso

Manejo de documentos

Indexación de vectores

Recuperación de documentos

Re-ranking semántico

RAG

Recursos

Recursos