Objetivos de aprendizaje
- Entender las piezas reales de un sistema RAG.
- Distinguir una demo bonita de un sistema usable en una pyme.
- Definir criterios de calidad antes de indexar documentos.
En cristiano: RAG. Es una forma de responder con tus documentos. Primero busca fragmentos relevantes, luego se los pasa al modelo y finalmente genera una respuesta basada en ese contexto.
La tubería completa
Documentos -> ingesta y limpieza -> chunking -> embeddings -> base vectorial -> recuperación -> reranking -> generación con citas -> evaluación y logs
Idea clave. La calidad del RAG se decide antes de preguntar. Si tus documentos entran sucios, troceados sin criterio y sin metadatos, el modelo solo maquillará el desorden.
Preguntas de diseño
- ¿Qué documentos puede consultar cada usuario?
- ¿Cada respuesta necesita cita exacta?
- ¿Qué pasa si no encuentra evidencia?
- ¿Cómo se actualizan documentos antiguos?
- ¿Qué entradas podrían contener instrucciones maliciosas?
Cuidado. “Responde siempre” es una mala regla para RAG. Un sistema fiable debe poder decir: “no tengo evidencia suficiente en los documentos”.
Comprueba que funciona. Antes de construir, escribe tres preguntas que tu RAG debe responder y tres que debe rechazar. Ese pequeño test evitará muchas falsas demos.
Guardar y reabrir el proyecto.
Un RAG bueno tiene cuatro compromisos: recupera bien, cita bien, limita permisos y deja evidencia. Si falta uno, no está listo para datos sensibles.
Siguiente misión recomendada
Si has guardado la evidencia de esta lección, continúa con «Ingesta, limpieza y chunking». Si no, repite la comprobación antes de avanzar.