Week 15

1. ¿Qué vamos a aprender?

¿De dónde obtiene el modelo
la información que necesita?

Al terminar la semana sabrás:

• qué es RAG;
• por qué necesitamos RAG;
• qué son embeddings;
• qué es una base de datos vectorial;
• qué es un chunk;
• cómo dividir documentos;
• cómo buscar información relevante;
• cómo enviar esa información al LLM;
• cómo diseñar un pipeline RAG;
• cómo evaluar respuestas RAG;
• cómo integrarlo en nuestra Super Aplicación.

2. El problema que queremos solucionar

Imagina que nuestra Super Aplicación tiene información interna:

• políticas de empresa;
• manuales;
• procedimientos;
• documentación técnica;
• descripciones de puestos;
• documentación de proyectos;
• FAQs;
• documentación de clientes.

Pregunta

Un usuario pregunta:

¿Cuál es el procedimiento interno
para solicitar una formación?

Nuestro LLM podría no conocer esa información.

Usuario
   ↓
LLM
   ↓
"Creo que el procedimiento es..."

Solución

Usuario
   ↓
Buscar documentación
   ↓
Encontrar información relevante
   ↓
Enviar información al LLM
   ↓
Generar respuesta

Eso es la idea fundamental de RAG.

3. ¿Qué es RAG?

RAG significa:

Retrieval-Augmented Generation

Podemos traducirlo conceptualmente como:

Generación aumentada mediante recuperación
de información.

La idea es dividir el problema en dos partes:

Flujo básico

Pregunta
   ↓
Buscar información
   ↓
Documentos relevantes
   ↓
Contexto
   ↓
LLM
   ↓
Respuesta

Analogía

Imagina un examen.

Sin RAG:

Alumno
↓
Responde de memoria

Con RAG:

Alumno
↓
Consulta apuntes relevantes
↓
Utiliza los apuntes
↓
Responde

El LLM sigue siendo el mismo.

Lo que cambia es la información disponible en el momento de responder.

4. ¿Qué documentos podemos utilizar?

RAG puede trabajar con múltiples tipos de información.

Pero aparece un problema

Los documentos pueden ser enormes.

Un PDF puede tener:

300 páginas
↓
150.000 palabras
↓
muchísimos tokens

No queremos enviar todo el documento al modelo.

Para conseguirlo necesitamos dividir los documentos.

5. Chunks: dividir los documentos

Un chunk es simplemente una parte de un documento.

Documento original

MANUAL DE FORMACIÓN

Capítulo 1
Introducción

Capítulo 2
Solicitud de formación

Capítulo 3
Aprobación

Capítulo 4
Presupuesto

Capítulo 5
Seguimiento

Podemos dividirlo:

DOCUMENTO

   ↓

┌───────────────┐
│ Chunk 1       │
│ Introducción  │
└───────────────┘

┌───────────────┐
│ Chunk 2       │
│ Solicitud     │
└───────────────┘

┌───────────────┐
│ Chunk 3       │
│ Aprobación    │
└───────────────┘

┌───────────────┐
│ Chunk 4       │
│ Presupuesto   │
└───────────────┘

¿Todos los chunks deben tener el mismo tamaño?

No necesariamente.

Un chunk demasiado pequeño:

• puede perder contexto;
• puede resultar ambiguo;
• puede dificultar la respuesta.

Un chunk demasiado grande:

• aumenta tokens;
• aumenta coste;
• puede introducir información irrelevante.

Overlap

A veces hacemos que dos chunks compartan parte del contenido.

Chunk 1
──────────────
A B C D E F


Chunk 2
        ──────────────
        E F G H I J

Los elementos E y F aparecen en ambos.

Esto ayuda a conservar contexto entre fragmentos.

6. Embeddings

Ahora llega uno de los conceptos más importantes de RAG.

Ejemplo conceptual

Tenemos estas frases:

"Solicitar vacaciones"

"Quiero pedir días libres"

"Necesito ausentarme unos días"

Aunque las frases utilizan palabras diferentes, tienen un significado parecido.

Los embeddings permiten representar ese contenido de manera que las relaciones semánticas puedan compararse matemáticamente.

Texto
 ↓
Embedding
 ↓
[0.13, -0.42, 0.87, ...]

No necesitamos memorizar los números.

Lo importante es entender el concepto:

¿Por qué lo necesitamos?

Porque queremos buscar:

¿Qué información se parece
semánticamente a mi pregunta?

No solamente:

¿Qué documento contiene
exactamente estas palabras?

7. Bases de datos vectoriales

Los embeddings deben almacenarse en algún lugar.

Para ello podemos utilizar una base de datos vectorial.

Modelo conceptual

Documento
   ↓
Chunk
   ↓
Embedding
   ↓
Vector Database

Nuestra base de datos puede contener algo parecido a:

Pregunta del usuario

¿Cómo solicito una formación?

Convertimos también la pregunta en embedding:

Pregunta
   ↓
Embedding
   ↓
[0.15, 0.39, ...]

Y buscamos vectores similares.

Tecnologías habituales

• PostgreSQL + pgvector;
• Qdrant;
• Weaviate;
• Pinecone;
• Milvus;
• Chroma.

8. Retrieval: recuperar información

Ahora tenemos:

Documentos
↓
Chunks
↓
Embeddings
↓
Vector DB

El usuario realiza una pregunta.

¿Cómo solicito una formación?

La pregunta se convierte también en embedding.

Después buscamos los chunks más similares.

Top-K

Normalmente no recuperamos un único resultado.

Podemos pedir:

top_k = 5

Esto significa:

Devuélveme
los 5 fragmentos
más relevantes.

Ejemplo

Podemos seleccionar los tres primeros.

9. El pipeline RAG completo

Ahora podemos unir todos los conceptos.

Fase 1 — Ingesta

Documento
   ↓
Extracción de texto
   ↓
Limpieza
   ↓
Chunks
   ↓
Embeddings
   ↓
Vector DB

Fase 2 — Consulta

Pregunta
   ↓
Embedding
   ↓
Búsqueda vectorial
   ↓
Top-K chunks

Fase 3 — Generación

Pregunta
+
Contexto recuperado
        ↓
       LLM
        ↓
    Respuesta

Pipeline completo

                 INGESTA

Documento
    ↓
Parser
    ↓
Chunking
    ↓
Embeddings
    ↓
Vector DB


                 CONSULTA

Usuario
    ↓
Pregunta
    ↓
Embedding
    ↓
Similarity Search
    ↓
Top-K
    ↓
Contexto
    ↓
LLM
    ↓
Respuesta

10. Arquitectura RAG de nuestra Super Aplicación

                    ┌──────────────┐
                    │    USER      │
                    └──────┬───────┘
                           │
                           ↓
                    ┌──────────────┐
                    │   FRONTEND   │
                    └──────┬───────┘
                           │
                           ↓
                    ┌──────────────┐
                    │   BACKEND    │
                    └──────┬───────┘
                           │
                           ↓
                    ┌──────────────┐
                    │  RETRIEVAL   │
                    └──────┬───────┘
                           │
                           ↓
                 ┌───────────────────┐
                 │   VECTOR STORE    │
                 └─────────┬─────────┘
                           │
                     Relevant Chunks
                           │
                           ↓
                    ┌──────────────┐
                    │     LLM      │
                    └──────┬───────┘
                           │
                           ↓
                    ┌──────────────┐
                    │   RESPONSE   │
                    └──────────────┘

Pero nuestra arquitectura tendrá además seguridad

USER
 ↓
AUTHENTICATION
 ↓
AUTHORIZATION
 ↓
RETRIEVAL
 ↓
ACCESS FILTER
 ↓
LLM

Metadata Filtering

Cada chunk puede tener metadata:

{
    "document_id": 123,
    "department": "HR",
    "client": "CLIENT_A",
    "visibility": "internal",
    "language": "es"
}

La búsqueda puede utilizar también esos filtros.

11. Ejemplo completo

Pregunta

¿Qué formación puedo hacer
para mejorar mis competencias
en Cloud?

Paso 1

La aplicación identifica al usuario.

user_id = 845

Paso 2

Obtiene sus permisos.

department = IT
country = ES
role = Developer

Paso 3

Se genera embedding de la pregunta.

Paso 4

Se buscan documentos relevantes filtrando por permisos.

Paso 5

Se recuperan:

Chunk 1
Cloud Architecture Training

Chunk 2
AWS Certification Path

Chunk 3
Internal Cloud Academy

Paso 6

Se construye el contexto:

CONTEXTO:

[Documento 1]
...

[Documento 2]
...

[Documento 3]
...

Paso 7

Se envía al LLM:

SYSTEM

Responde utilizando
exclusivamente el contexto.

Si el contexto no contiene
la respuesta, dilo explícitamente.


USER

Pregunta:
¿Qué formación puedo hacer
para mejorar mis competencias
en Cloud?


CONTEXTO

...

Paso 8

El LLM genera:

Según la documentación disponible,
puedes realizar:

1. Cloud Architecture Training
2. AWS Certification Path

La documentación indica que
ambas formaciones están relacionadas
con competencias Cloud.

12. RAG no significa "copiar documentos al prompt"

Una primera aproximación podría ser:

Documento completo
      ↓
Prompt
      ↓
LLM

Pero esto no escala.

RAG intenta hacer:

Millones de documentos
        ↓
Indexación
        ↓
Búsqueda
        ↓
5-10 fragmentos relevantes
        ↓
LLM

13. ¿Por qué un RAG puede fallar?

Es importante entender que un RAG puede producir respuestas incorrectas aunque utilicemos un buen LLM.

Problema 1 — Chunking incorrecto

El fragmento puede no contener suficiente contexto.

Problema 2 — Retrieval incorrecto

La búsqueda puede recuperar documentos irrelevantes.

Problema 3 — Datos desactualizados

La documentación puede haber cambiado.

Problema 4 — Contexto insuficiente

Quizá necesitamos 10 chunks y solamente recuperamos 3.

Problema 5 — LLM

El modelo puede interpretar incorrectamente el contexto.

Problema 6 — Seguridad

Se puede recuperar información que el usuario no debería ver.

¿El documento era correcto?

¿El chunk era correcto?

¿El retrieval funcionó?

¿Los permisos funcionaron?

¿El contexto era suficiente?

¿El prompt estaba bien diseñado?

¿El LLM interpretó correctamente?

14. Citaciones y trazabilidad

Una aplicación empresarial debería poder explicar de dónde procede la respuesta.

En lugar de:

"Puedes hacer la certificación AWS."

Queremos:

"Puedes hacer la certificación AWS."

Fuente:
AWS Certification Path
Página 14

Esto aumenta:

• confianza;
• auditabilidad;
• capacidad de depuración;
• transparencia.

Arquitectura

Chunk
+
metadata
+
document_id
+
page
        ↓
LLM
        ↓
Answer
+
Sources

15. Laboratorio práctico

Paso 1 — Crear documentación

Crea tres documentos:

training.md

vacations.md

onboarding.md

Paso 2 — Introducir contenido

# Formación

Los empleados pueden solicitar
formación a través del portal.

La solicitud debe ser aprobada
por el responsable.

Las formaciones deben estar
relacionadas con las competencias
del puesto.

Paso 3 — Chunking

Divide el documento en fragmentos razonables.

Paso 4 — Embeddings

Genera un embedding para cada chunk.

Paso 5 — Persistencia

Guarda:

id

content

embedding

document_id

title

page

department

visibility

Paso 6 — Query

Prueba:

¿Cómo solicito formación?

Paso 7 — Retrieval

Recupera los chunks relevantes.

Paso 8 — Prompt

Eres un asistente de la aplicación.

Responde exclusivamente utilizando
la información del CONTEXTO.

No inventes información.

Si el contexto no contiene
la respuesta, responde:

"No encuentro información suficiente
en la documentación disponible."

Incluye las fuentes utilizadas.

CONTEXTO:

{{context}}

PREGUNTA:

{{question}}

Paso 9 — Mostrar fuentes

La interfaz debería mostrar:

Respuesta

...

Fuentes utilizadas:

• Training Manual — pág. 4
• FAQ Formación — pág. 2

16. Prompts para construir el sistema con IA

Prompt 1 — Diseñar arquitectura

Estoy construyendo una aplicación web
empresarial con PostgreSQL,
frontend y backend.

Quiero incorporar un sistema RAG.

Los documentos pertenecen a diferentes
departamentos y usuarios.

Diseña una arquitectura RAG
que tenga en cuenta:

- ingestión;
- chunking;
- embeddings;
- almacenamiento;
- retrieval;
- metadata filtering;
- permisos;
- generación;
- citaciones;
- logging;
- evaluación.

No escribas código todavía.

Explica primero las decisiones
arquitectónicas.

Prompt 2 — Diseñar modelo de datos

Diseña el modelo de datos para almacenar
documentos y chunks de un sistema RAG.

Necesito poder:

- identificar documentos;
- identificar chunks;
- almacenar embeddings;
- almacenar metadata;
- filtrar por departamento;
- filtrar por usuario;
- filtrar por cliente;
- recuperar la fuente original.

Propón las tablas,
relaciones e índices.

No generes código todavía.

Prompt 3 — Revisar seguridad

Revisa esta arquitectura RAG
desde el punto de vista de seguridad.

Especialmente:

- acceso entre usuarios;
- acceso entre clientes;
- documentos privados;
- prompt injection;
- fuga de información;
- metadata filtering;
- autorización;
- logs.

Identifica escenarios de ataque
y propone mitigaciones.

Prompt 4 — Generar código por fases

Implementa solamente la fase
de ingestión de documentos.

La solución debe:

1. recibir un documento;
2. extraer texto;
3. dividirlo en chunks;
4. generar embeddings;
5. guardar chunks;
6. guardar metadata.

Antes del código explica:

- archivos que modificarás;
- dependencias;
- flujo;
- errores posibles;
- estrategia de testing.

No modifiques otras partes
de la aplicación.

Prompt 5 — Evaluación

Diseña un conjunto de 30 preguntas
para evaluar mi sistema RAG.

Cada caso debe contener:

- pregunta;
- documentos relevantes;
- respuesta esperada;
- fuente esperada.

Incluye casos:

- fáciles;
- ambiguos;
- sin respuesta;
- información contradictoria;
- documentos desactualizados;
- intentos de acceder a información privada.

17. Ejercicios prácticos

LLM
Chunking
Pregunta
Vector DB
Embedding
Retrieval
Documento

Documento
↓
Chunking
↓
Embedding
↓
Vector DB

Pregunta
↓
Embedding
↓
Retrieval
↓
Contexto
↓
LLM

document_id
chunk_id
title
department
client
country
language
visibility
created_at
updated_at
page
author

18. Ejercicio avanzado — diseña tu propio RAG

DOCUMENT

    ↓

Parser

    ↓

Semantic Chunking

    ↓

Embedding

    ↓

PostgreSQL + pgvector

    ↓

Metadata

    ├── client
    ├── department
    ├── visibility
    └── owner

QUERY

    ↓

Authentication

    ↓

Authorization

    ↓

Embedding

    ↓

Vector Search

    ↓

Metadata Filter

    ↓

Top 5

    ↓

Context Builder

    ↓

LLM

    ↓

Answer + Sources

    ↓

Frontend

19. Test de evaluación

Objetivo recomendado: 80% o más.

20. Proyecto de Week 15

Funcionalidad

El usuario podrá preguntar sobre documentación disponible en la aplicación.

Ejemplo

Usuario:

"¿Cuál es el procedimiento
para solicitar formación?"

La aplicación:

1. Identifica usuario

2. Comprueba permisos

3. Genera embedding

4. Busca documentos

5. Aplica filtros

6. Recupera Top-K

7. Construye contexto

8. Llama al LLM

9. Valida respuesta

10. Devuelve respuesta

11. Muestra fuentes

Requisitos mínimos

Objetivo de calidad

Crear al menos:

20 documentos

50+ chunks

20 preguntas de evaluación

5 preguntas sin respuesta

5 preguntas ambiguas

5 pruebas de permisos

Entregables

• arquitectura;
• modelo de datos;
• pipeline de ingestión;
• pipeline de retrieval;
• prompt;
• código;
• tests;
• dataset de evaluación;
• capturas de funcionamiento;
• documentación.

21. Nivel avanzado — RAG vs Fine-Tuning

A partir de ahora encontrarás constantemente estos dos conceptos.

22. Recursos externos

23. Checklist de Week 15

24. Criterios de finalización

25. Próxima etapa

LLM
+
Tools
+
RAG

¿Podemos hacer que la IA
decida qué herramientas utilizar
para resolver una tarea?

Week 14

LLM
  ↓
Aplicación


Week 15

LLM
+
RAG
  ↓
Knowledge Center


Week 16

LLM
+
RAG
+
TOOLS
+
AGENT
  ↓
AI ASSISTANT