Quiz: Evaluación de Conceptos Fundamentales

Concepto clave

El Retrieval Augmented Generation (RAG) es una arquitectura que combina recuperación de información con generación de texto. En lugar de depender únicamente de los parámetros aprendidos durante el entrenamiento (como hace un LLM tradicional), un sistema RAG primero recupera documentos relevantes de una base de conocimiento externa y luego usa esa información como contexto para generar respuestas.

Imagina que eres un abogado preparando un caso. No intentas memorizar todos los códigos legales (como haría un LLM puro). En su lugar, primero buscas en tu biblioteca de leyes (la base de datos vectorial) los estatutos relevantes, luego usas esos documentos específicos para redactar tu argumento (la generación). Esto produce respuestas más precisas, actualizables y con menor "alucinación".

Cómo funciona en la práctica

Un flujo típico de RAG con bases de datos vectoriales tiene estos pasos:

1. Indexación: Los documentos fuente (PDFs, páginas web, etc.) se dividen en fragmentos (chunks). Cada fragmento se convierte en un vector de embedding usando un modelo como sentence-transformers.
2. Almacenamiento: Estos vectores, junto con el texto original y metadatos, se insertan en una base de datos vectorial como Chroma, Pinecone o pgvector.
3. Consulta: Cuando un usuario hace una pregunta, esta se convierte en un vector de consulta usando el mismo modelo de embedding.
4. Recuperación: La base de datos vectorial encuentra los fragmentos más similares (usando similitud coseno o distancia euclidiana) y los devuelve.
5. Aumentación y generación: Los fragmentos recuperados se inyectan como contexto en un prompt para un LLM (como GPT-4 o Llama), que genera la respuesta final.

Caso de estudio

Una empresa de seguros quiere un chatbot que responda preguntas sobre pólizas usando su manual interno de 500 páginas. Implementan un sistema RAG:

• Usan Chroma para prototipar rápidamente, almacenando embeddings de fragmentos de 200 tokens.
• Para producción, migran a pgvector en su PostgreSQL existente, aprovechando ACID y consultas SQL.
• La consulta "¿Cubre mi póliza daños por inundación en el primer piso?" se convierte en vector, recupera 3 fragmentos relevantes del manual, y el LLM genera: "Sí, la cobertura básica incluye inundaciones en plantas bajas, según sección 4.2, con un deducible del 5%".

Un sistema RAG bien implementado puede reducir errores factuales en un 40-60% comparado con un LLM sin contexto, según estudios recientes.

Errores comunes

• Chunking inapropiado: Fragmentos demasiado grandes pierden precisión; demasiado pequeños pierden contexto. Solución: Experimentar con tamaños (ej. 256-512 tokens) y solapamiento (overlap).
• Embeddings inconsistentes: Usar diferentes modelos para indexar y consultar. Solución: Siempre usar el mismo modelo y versión.
• Falta de filtrado por metadatos: Recuperar fragmentos irrelevantes porque no se filtran por fecha, departamento, etc. Solución: Usar metadatos en la consulta vectorial.
• Prompt engineering débil: No instruir al LLM para que use solo el contexto proporcionado. Solución: Incluir en el prompt: "Responde basándote únicamente en los siguientes documentos...".

Checklist de dominio

1. Puedo explicar la diferencia entre RAG y fine-tuning de un LLM.
2. Sé cómo elegir entre Chroma (simplicidad), Pinecone (escalabilidad cloud) y pgvector (integración SQL).
3. Puedo diseñar un esquema de chunking y embeddings para un conjunto de documentos.
4. Entiendo cómo la similitud coseno afecta la recuperación de fragmentos.
5. Sé depurar un sistema RAG cuando devuelve respuestas incorrectas.
6. Puedo optimizar costos balanceando calidad de embeddings vs. latencia.
7. Conozco las limitaciones de RAG (ej., no maneja razonamiento complejo entre fragmentos).

Diseño de un sistema RAG para documentación técnica

Vas a diseñar la arquitectura de un sistema RAG para la documentación de una API de 300 páginas. Sigue estos pasos:

1. Define el chunking: Decide el tamaño de fragmento (en tokens) y si usarás solapamiento. Justifica tu elección basándote en la naturaleza técnica de la documentación.
2. Selecciona la base de datos vectorial: Elige entre Chroma, Pinecone o pgvector para este caso. Considera que el equipo ya usa PostgreSQL en AWS. Explica tu decisión.
3. Diseña el flujo de consulta: Describe los pasos desde que un usuario pregunta "¿Cómo autenticar con OAuth2?" hasta la respuesta generada. Incluye cómo manejarías metadatos (ej., versión de la API).
4. Propón una métrica de evaluación: Define una métrica simple para medir la precisión del sistema (ej., porcentaje de respuestas correctas en un set de prueba).

• Piensa en cómo la estructura de la documentación (encabezados, código) afecta el chunking.
• Considera los costos de infraestructura y las habilidades del equipo.
• Recuerda que el LLM necesita contexto claro para generar respuestas precisas.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.