Arquitectura RAG y práctica en vivo
El corazón técnico del curso: abrimos la caja de RAG pieza por pieza, lo vemos correr en un prototipo real y lo traducimos a un plano de negocio que puedas dibujar y defender.
Arquitectura RAG: componentes y flujo de información
Al terminar esta sesión podrás
- Dibujar y explicar el flujo RAG en dos fases: indexación (offline) y consulta (online), nombrando cada componente.
- Explicar qué es el chunking y por qué el tamaño del fragmento es un trade-off, no un detalle.
- Explicar, con intuición geométrica, qué es un embedding e interpretar la similitud coseno.
- Distinguir búsqueda densa, léxica e híbrida, y decir qué aporta el re-ranking.
- Reconstruir cómo se inyecta el contexto en el prompt y por qué el grounding y la citación reducen la alucinación.
RAG en una frase
RAG significa Retrieval-Augmented Generation (generación aumentada por recuperación). En vez de pedirle al modelo que conteste de memoria, primero recuperamos los fragmentos relevantes de tu propio conocimiento y se los entregamos junto con la pregunta para que redacte apoyándose en ellos. Piénsalo así: RAG es darle a un escritor brillante pero olvidadizo justo la página del manual que necesita, un instante antes de que conteste. No le pedimos que recuerde; le pedimos que lea y redacte.
RAG son dos sistemas pegados: uno que busca (como un buscador sobre tus documentos) y otro que escribe (el LLM). La mayoría de los errores no vienen del que escribe: si recupera basura, redacta basura con confianza.
El flujo completo en dos fases
Hay una separación temporal que conviene interiorizar. Una parte ocurre antes, una sola vez (o cada que cambian los documentos), y otra ocurre en el momento, con cada pregunta.
Indexación (offline)
Preparamos el conocimiento: cargar, limpiar, fragmentar, calcular embeddings e indexar. Sucede sin usuario presente; es lenta y no importa, nadie espera.
Consulta (online)
El usuario pregunta y respondemos en segundos: embedding de la pregunta, recuperación, armado del prompt, generación y citas. Aquí cada milisegundo cuenta.
Se usa el mismo modelo de embeddings en ambas fases (indexar con uno y consultar con otro es medir en metros y luego en pulgadas). Y el vector store es la bisagra: lo llena la Fase A y lo consulta la Fase B; es lo único que persiste entre ambas.
Recorre el diagrama paso a paso. Avanza por cada componente y observa qué entra y qué sale en cada casilla de las dos fases.
El flujo RAG en dos fases
Avanza con los botones o haz clic en cada casilla. Verás qué hace cada componente y a qué fase pertenece.
Chunking: por qué partir el documento
El modelo solo "ve" una cantidad limitada de texto a la vez (su ventana de contexto): un manual de 500 páginas no cabe. Y aunque cupiera, procesarlo entero en cada pregunta sería caro y lento, el modelo se distrae con lo enterrado en mitad de un texto larguísimo, y para buscar por similitud necesitamos piezas de tamaño parejo. Por eso partimos el documento en fragmentos (chunks).
Al cortar en seco, una idea que cae justo en el corte queda mutilada entre dos chunks. La solución es el solapamiento (overlap): que cada fragmento repita las últimas líneas del anterior, para que una frase partida sobreviva entera en al menos uno de los dos trozos.
Chunk chico: encuentro la aguja pero sin el pajar que la explica (recuperación precisa, pero le falta contexto). Chunk grande: traigo todo el pajar y la aguja se pierde dentro (mucho contexto, pero búsqueda imprecisa). El arte está en el medio, y el tamaño se mide, no se decide por fe.
Prueba tú mismo la balanza. Mueve el tamaño del fragmento y el solapamiento, y observa cómo se reparte el mismo texto y qué se gana o se pierde.
Fragmentación y solapamiento
Ajusta el tamaño del chunk y el solapamiento; el texto se re-fragmenta al instante y verás el efecto sobre precisión y contexto.
Embeddings: significado convertido en números
Un embedding es una lista de números (un vector) que representa el significado de un texto. El modelo está entrenado para que textos con significado parecido produzcan vectores parecidos, aunque usen palabras distintas. Por ejemplo, "¿Cómo devuelvo un producto?" y "¿Cuál es el procedimiento para regresar un artículo?" casi no comparten palabras, pero significan lo mismo, así que sus vectores quedan cerca. Eso es lo que la búsqueda por palabras clave no puede hacer y los embeddings sí.
Imagina un mapa donde cada texto es un punto, pero en vez de dos dimensiones son cientos. "Devolución", "reembolso" y "garantía" caen en un barrio; "perro", "gato" y "mascota" en otro. La distancia entre dos puntos mide cuán distintos son sus significados, y buscar el chunk relevante es encontrar los puntos más cercanos al de la pregunta.
Similitud coseno: cómo medimos "cerca"
Para decidir qué tan parecidos son dos vectores no medimos la distancia en línea recta, sino el ángulo entre ellos. La similitud coseno es el coseno de ese ángulo. Nos importa hacia dónde apunta el vector (el tema), no cuán largo es (que depende de la longitud del texto).
En palabras: el producto punto dividido entre el producto de las longitudes. El numerador mide cuánto "van juntos"; el denominador normaliza para que solo importe la dirección. El rango va de −1 a +1: apuntar igual da coseno cercano a 1, perpendiculares da 0, opuestos da −1. Con texto, los valores suelen caer entre 0 y 1.
Experiméntalo. Arrastra los dos vectores y observa cómo cambian el ángulo y el coseno; la recuperación es exactamente esto, repetido contra miles de chunks.
Laboratorio de similitud coseno
Arrastra las puntas de los vectores A y B, o usa los presets. Verás el ángulo, el cálculo y la interpretación del parecido.
Y aquí tienes el mismo cálculo aplicado a una pregunta real contra varios fragmentos: observa cuáles suben al top por tener el coseno más alto.
Recuperación por coseno, fragmento a fragmento
Cada fila es un chunk comparado con la pregunta; la tabla los ordena por su similitud, igual que lo haría el buscador.
Vector stores: dónde viven los vectores
Una base de datos vectorial hace dos cosas: almacena los vectores junto con su texto original y sus metadatos (de qué documento, página y sección vienen, lo que luego permite citar) y busca rápido, dado el vector de una pregunta, los k vecinos más cercanos. Comparar contra cada uno de millones de chunks sería preciso pero lento, así que usan búsqueda aproximada de vecinos (ANN): casi siempre dan con los correctos en una fracción del tiempo, como buscar un restaurante por barrio en vez de recorrer la ciudad calle por calle.
| Vector store | Tipo | Cuándo |
|---|---|---|
| FAISS | Biblioteca local, en memoria | Prototipos; datasets que caben en RAM |
| Chroma | Embebida, fácil de empezar | Prototipos y apps pequeñas |
| Qdrant | Servidor, producción | Escala y filtros por metadatos |
| pgvector | Extensión de PostgreSQL | Si ya tienes Postgres |
Densa, léxica e híbrida
La recuperación es el paso que más decide la calidad. Dos palancas: el top-k (cuántos chunks devuelves) y el umbral de similitud (por debajo de cierto coseno, descartas y el bot dice "no sé"). Y tres formas de buscar:
| Tipo | Entiende sinónimos | Acierta términos exactos | Ejemplo donde gana |
|---|---|---|---|
| Densa (embeddings) | sí | a medias | "regresar un artículo" ≈ "devolver producto" |
| Léxica (BM25) | no | sí | "póliza AX-22", "error E-404" |
| Híbrida | sí | sí | El caso real mixto: la apuesta segura |
La densa entiende lo que quisiste decir; la léxica encuentra lo que escribiste exacto. En servicio al cliente, donde conviven preguntas en lenguaje natural y referencias exactas, necesitas las dos: por eso la híbrida es lo recomendado.
Después de recuperar, un re-ranker mira la pregunta y cada candidato juntos y los reordena por relevancia real, quedándose con los mejores 3 a 5. Es un segundo filtro más fino: añade valor cuando el orden importa, a cambio de más latencia. Como el chunk, el k y la búsqueda, es otra palanca que se mide.
La capa generativa: inyectar el contexto en el prompt
Con los chunks recuperados se arma un prompt de tres partes: un system con las reglas, el contexto (los chunks con su fuente) y la pregunta del usuario. La instrucción clave, probablemente la frase técnica más importante del curso, vive en el system.
"Responde solo con base en el contexto entregado. Si la respuesta no está ahí, di que no la sabes y deriva a un humano. No inventes." Esa sola regla convierte un generador propenso a alucinar en un asistente fundamentado. El "no sé" no es un fracaso: es su mejor respuesta cuando no hay fuente.
Grounding y citación
El grounding (anclaje) es la práctica de que cada afirmación de la respuesta esté respaldada por un fragmento recuperado: la respuesta no sale del modelo, sale del documento que el modelo leyó. Reduce la alucinación por tres vías: le damos el dato correcto delante (no lo reconstruye de memoria), le prohibimos salirse, y la cita lo hace verificable. Como los chunks llevan metadatos, la respuesta puede adjuntar la fuente: "Tienes 30 días para devolver (Política de Devoluciones, §3.2)".
Una respuesta sin fuente es una opinión; con fuente, es una cita auditable. En banca, salud o un reglamento, esa diferencia lo es todo. Esto es lo que mañana (Día 4) aprenderás a medir como groundedness.
El prototipo RAG por dentro
Al terminar esta sesión podrás
- Reconocer en una ejecución real cada paso del flujo RAG de la sesión anterior: indexar, recuperar, generar y citar.
- Interpretar los scores de recuperación (coseno, léxica, híbrida) que muestra el prototipo.
- Explicar por qué una misma pregunta cambia de respuesta al mover una palanca (modo de búsqueda, top-k, umbral).
- Identificar los tres comportamientos clave: respuesta fundamentada con cita, "no sé" con escalación, y rechazo de lo sensible.
Qué es este prototipo (y qué no es)
Es un chatbot RAG mínimo, real y robusto, pensado para aprender, no para producción.
Nada está simulado
Recupera de un corpus de FAQs y genera con un LLM local (Ollama). Los embeddings y la generación corren de verdad.
Corre local
Solo dos dependencias de Python; toda la inteligencia vive en Ollama, sin internet ni API de pago.
El esqueleto desnudo
Es el "RAG honesto y simple": recuperar, meter al prompt y generar. Sin memoria larga ni acciones agénticas.
Cada pieza del prototipo corresponde a un componente de la sesión anterior: la generación es un LLM local (gemma3:4b), los embeddings un modelo de 768 dimensiones (nomic-embed-text), el vector store es una matriz en memoria con el coseno calculado a mano, y la recuperación es híbrida (densa más léxica). El corpus de TiendaSol son 16 documentos que se fragmentan en 115 chunks; el de admisiones ESAN, 9 documentos en 48 chunks.
Qué muestra la recuperación
Cada fragmento recuperado trae tres números y una marca. El coseno (0 a 1) mide el parecido de significado; la léxica (0 a 1) mide la coincidencia de palabras; la híbrida es la mezcla que ordena el resultado. La marca indica si el coseno supera el umbral del "no sé". La fuente correcta suele tener coseno alto y léxica alta, y así la híbrida la sube al primer lugar.
El "no sé" como éxito
Ante "¿Cuál es el saldo de mis puntos ahora mismo?", el bot no inventa un número: explica que ese dato es de la cuenta y deriva. Aquí se ven el umbral y la instrucción "responde solo con base en el contexto". Un saldo inventado sería una alucinación con consecuencias; el "no sé" honesto es groundedness funcionando.
Revisita a continuación varias conversaciones reales grabadas del prototipo. Elige una y recórrela mensaje a mensaje: verás la recuperación con sus scores, la respuesta con su cita, y los casos de "no sé" y de rechazo.
Conversaciones reales del prototipo
Estas transcripciones reproducen conversaciones reales del prototipo para que las revisites con calma: la recuperación, los scores y la respuesta con su fuente, tal como ocurrieron.
Si el prototipo falla al recuperar un sinónimo difícil o cita la fuente "vecina", no es un accidente: es contenido. Cada tropiezo es un ejemplo real para la sesión de evaluación de mañana, donde aprenderás a medir exactamente esto.
Taller: arquitectura conceptual y fallback humano
Al terminar esta sesión podrás
- Traducir la arquitectura RAG técnica a un diagrama conceptual de cajas y flechas que un equipo de negocio pueda dibujar y defender.
- Identificar las cajas obligatorias: fuentes, indexación, recuperación, generación, salida y fallback humano, más guardrails y logging.
- Diseñar los patrones de escalación: cuándo escalar (los cinco disparadores) y cómo escalar (el handoff con contexto).
- Diseñar el manejo de "no sé" cuando la recuperación no trae nada relevante.
Por qué un diagrama conceptual y no el técnico
En la sesión de arquitectura viste el vocabulario de ingeniería: chunking, embeddings, vector store, top-k, re-ranking. Eso es indispensable para quien construye. Pero como profesional de negocio tu tarea es decidir, especificar y supervisar un chatbot, no programarlo. Necesitas un plano que puedas dibujar en una pizarra ante un comité, defender en dos minutos y auditar para señalar los riesgos. Si no puedes dibujar tu chatbot en una servilleta y explicárselo a tu jefe, todavía no lo entiendes.
| Componente técnico | Caja conceptual | Pregunta de negocio |
|---|---|---|
| Documentos, ingesta | Fuentes / Corpus | ¿De dónde sale el conocimiento? |
| Chunking + embeddings + vector store | Indexación | ¿Cómo se organiza para buscarlo? |
| Recuperación + filtro de similitud | Recuperación | ¿Qué fragmentos relevantes encuentro? |
| Prompt + LLM + grounding | Generación | ¿Cómo redacto apoyado en eso? |
| Respuesta con citas | Salida | ¿Qué ve el cliente, con qué fuente? |
| (nuevo) | Fallback humano | ¿Qué hago cuando no debo o no puedo contestar? |
La notación: cajas y flechas
Usa una notación minimalista y consistente. Una caja de proceso es algo que el sistema hace (recuperar, generar, validar); un almacén guarda información (corpus, índice, logs); un rombo de decisión es una bifurcación con condición; una flecha continua es el flujo normal y una punteada es un camino de excepción (escalación, "no sé", error).
Toda flecha de un rombo va etiquetada
Con su condición: "sí / no", "similitud < 0.6", "tema = reembolso".
Todo diagrama tiene un camino a un humano
Al menos un camino punteado que termina en una persona. Sin salida humana, está incompleto.
La generación nunca apunta directo al cliente
Siempre pasa por un guardrail de salida. Es el error más común.
El logging recibe flechas de casi todo
Recuperación, generación, escalación: si no se registra, no se puede auditar.
Los cinco disparadores de escalación
Un chatbot de servicio se juzga tanto por lo que responde como por cuándo tiene la humildad de pasar la llamada. Cinco campanas: no lo sé, no es lo mío, es delicado, está molesto, o me lo pidió.
| # | Disparador | Ejemplo |
|---|---|---|
| 1 | Baja confianza / similitud | El mejor fragmento no supera el umbral |
| 2 | Tema fuera de alcance | "¿Tienen vacantes?" en un bot de devoluciones |
| 3 | Solicitud sensible o de riesgo | "Reembólsame a mi tarjeta", "cancela mi seguro" |
| 4 | Sentimiento negativo | "Esto es un fraude, voy a demandar" |
| 5 | Petición explícita | "Quiero hablar con una persona" |
El handoff: escalar con contexto
Escalar mal es casi tan dañino como no escalar. El error clásico es pasar al cliente a un agente que empieza de cero ("Hola, ¿en qué le puedo ayudar?") y lo obliga a repetir todo, lo que dispara el esfuerzo y enfurece. Un buen handoff transfiere cuatro cosas: la transcripción completa, el motivo de la escalación, el contexto estructurado ya recolectado (número de pedido, intención) y lo que el bot ya intentó. Un buen traspaso es como un buen pase en fútbol: el que recibe ya está mirando al arco, no buscando la pelota.
Tiene cuatro partes: reconocimiento honesto sin tecnicismos ("no tengo esa información"), sin inventar nada, una salida (ofrece el handoff), y registro en logs. Un "no sé" honesto no es un fallo: es el sistema funcionando. Si los "no sé" se acumulan sobre un tema, no necesitas un modelo más grande, necesitas escribir esa página del manual.
Manos a la obra
En equipo, tomarán el sector que eligieron y producirán un lienzo de arquitectura completo: todas las cajas llenas, los dos caminos de excepción dibujados (el "no sé" por baja similitud y la escalación por decisión) y al menos un SLA de fallback anotado. Después intercambiarán su lienzo con otro equipo para una revisión cruzada con rúbrica. Criticar un diagrama ajeno es lo que enseña a ver los huecos del propio.
Abre la hoja del taller y el lienzo de arquitectura → · Consulta la rúbrica de revisión por pares →
Tiempo del taller
Para las dinámicas en equipo: llenado del lienzo, intercambio y revisión cruzada. Elige la duración e inicia.
Ya sabes cómo funciona RAG por dentro, lo viste correr en un prototipo real y lo tradujiste a un plano de negocio con su salida de emergencia. Mañana la única pregunta que importa para un negocio: ¿cómo sabemos si está funcionando bien? Eso se mide, componente por componente.