flowchart LR
A[Consulta] --> B[Retriever]
D[Resources externos] --> B
B --> C[Fragmentos relevantes]
C --> E[Context]
A --> E
E --> F[Modelo]
F --> G[Respuesta]
RAG
Cómo funciona Retrieval-Augmented Generation: recuperar información externa pertinente, incorporarla al contexto y generar una respuesta apoyada en evidencia.
En la página anterior resolvimos una parte del problema.
Tenemos muchos documentos.
Sabemos buscar.
Podemos seleccionar fragmentos.
Podemos incorporarlos al contexto.
Ahora conectaremos esa recuperación con la generación de un modelo.
El patrón resultante suele llamarse RAG.
RAG significa Retrieval-Augmented Generation: generación aumentada mediante recuperación.
La intuición puede expresarse sin vocabulario técnico:
antes de responder, el sistema busca información pertinente y se la proporciona al modelo para que genere utilizando ese contexto.
Idea central
RAG no es “meter más texto”.
Es construir contexto específico para la consulta mediante recuperación de información externa antes de generar la respuesta.
Chip Huyen formula precisamente esta separación: una tarea requiere instrucciones sobre cómo realizarla y también información relevante para resolver la consulta concreta. Berryman y Ziegler describen RAG como un patrón en el que la aplicación recupera contenido relevante y lo incorpora al prompt o contexto.
Qué problema resuelve
Imaginemos que preguntamos:
¿Cuál es el estándar contractual vigente sobre responsabilidad?
La respuesta correcta puede depender de un documento interno aprobado ayer.
Ese documento no estaba en los datos de entrenamiento del modelo, puede ser confidencial, puede cambiar y puede estar dentro de un repositorio empresarial.
Sin un mecanismo adicional, el modelo no dispone necesariamente de él.
Podríamos copiar manualmente la política dentro del prompt.
Eso funciona para un documento pequeño.
Pero si tenemos:
100.000 resourcesnecesitamos seleccionar.
RAG intenta resolver:
¿cómo proporcionar al modelo sólo la información externa relevante para esta consulta antes de pedirle que genere?
La arquitectura mínima
Podemos representar:
En una arquitectura muy simplificada existen dos funciones principales:
Retriever → recupera información.
Generator → genera utilizando esa información.
No necesitamos que ambos componentes sean del mismo proveedor ni que hayan sido entrenados juntos.
Dos momentos: preparar y consultar
Una explicación demasiado simple puede hacer pensar que RAG empieza cuando el usuario formula una pregunta.
En muchos sistemas existe trabajo previo.
Preparación
Los resources pueden necesitar:
ingesta
→ extracción de contenido
→ limpieza
→ fragmentación
→ metadatos
→ indexaciónEsta etapa prepara la información para recuperación posterior.
Si un documento nunca fue incorporado, no podrá recuperarse.
Si quedó mal clasificado, la búsqueda puede fallar.
Si una versión derogada está marcada como vigente, el modelo puede recibir una fuente equivocada.
Consulta
Después, durante la tarea:
pregunta
→ búsqueda
→ recuperación
→ contexto
→ generaciónSeparar ambos momentos permite localizar errores.
Consulta
La consulta expresa la necesidad de información.
Puede ser idéntica a la pregunta del usuario.
O puede ser reformulada.
Ejemplo:
Usuario:
¿Y qué ocurrió con ACME?
Si el contexto previo hablaba de precedentes de caps de responsabilidad, la consulta aislada es ambigua.
Podría reformularse:
precedente ACME sobre cap de limitación de responsabilidadChip Huyen denomina este tipo de operación query rewriting.
La función es sencilla:
hacer que la consulta de recuperación contenga suficiente información para buscar bien.
Búsqueda
El retriever busca candidatos.
Puede utilizar términos, embeddings, búsqueda híbrida, filtros o combinaciones.
Embeddings: una intuición mínima
Un embedding es una representación numérica que permite comparar contenidos según relaciones semánticas.
No necesitamos estudiar aquí la matemática.
La intuición es:
texto
↓
representación numérica
↓
comparación de proximidadEso puede ayudar a encontrar:
“tope agregado de responsabilidad”cuando la consulta dice:
“cap contractual”Pero embeddings no equivalen a RAG.
Son una posible técnica de recuperación.
RAG ≠ base vectorial
Una base vectorial puede ser útil para recuperación semántica.
RAG describe el patrón más amplio:
recuperar información pertinente + generar utilizando esa información.
Puede apoyarse en búsqueda léxica, semántica, híbrida u otras estrategias.
Recuperación
La búsqueda produce candidatos.
La recuperación selecciona qué resultados pasarán al contexto.
Supongamos que aparecen:
Estándar v4 — vigente
Estándar v3 — derogado
Contrato ACME — excepción
Presentación interna — borradorLa similitud textual no basta.
Podemos considerar relevancia, vigencia, tipo de documento, ámbito, autoridad y fecha.
El retriever necesita ser compatible con la gobernanza del knowledge.
Fragmentación
Los documentos grandes suelen dividirse en unidades recuperables.
Chip Huyen destaca que la estrategia de chunking puede afectar significativamente el desempeño del retrieval.
Fragmento demasiado grande
Puede introducir ruido, reglas irrelevantes, más costo y más tokens.
Fragmento demasiado pequeño
Puede perder definiciones, excepciones, contexto y referencias cruzadas.
En Derecho este problema es particularmente visible.
Regla:
cap = 12 mesespuede encontrarse en una cláusula.
La excepción:
fraude y confidencialidad fuera del cappuede aparecer en la siguiente.
Si los fragmentos se separan mal, la recuperación puede entregar una regla incompleta.
Overlap y límites
Algunas estrategias utilizan solapamiento entre fragmentos para evitar cortar información en bordes.
No necesitamos fijar una cantidad universal.
La enseñanza de Huyen es precisamente que no existe un tamaño óptimo para todos los casos.
La configuración debe evaluarse respecto de corpus, documentos, consultas, modelo y tarea.
Para un handbook jurídico, lo importante es comprender que chunking es una decisión de diseño con consecuencias sustantivas.
Contexto
Los fragmentos recuperados deben ensamblarse con la tarea.
Podemos imaginar:
[SKILL]
Cómo evaluar responsabilidad.
[PREGUNTA]
¿Cumple la cláusula el estándar?
[CONTRATO]
Cap = 3 meses.
[ESTÁNDAR RECUPERADO]
Cap mínimo = 12 meses.
[PRECEDENTE]
ACME = 6 meses.
[ESTATUS]
ACME fue excepción.La respuesta se generará a partir de ese paquete.
El contexto es selectivo
Huyen describe RAG como una forma de construir contexto específico para cada consulta.
Eso es clave.
No utilizamos siempre la misma información.
Para responsabilidad recuperamos unas fuentes.
Para protección de datos, otras.
Para continuidad, otras.
La selección depende de la tarea.
Respuesta
El generator recibe:
instrucciones
+
consulta
+
información recuperaday produce una respuesta.
Por ejemplo:
La cláusula propone un cap de 3 meses.
El estándar vigente recuperado establece 12 meses.
Existe, por tanto, una desviación.
El precedente ACME no modifica el estándar porque consta
como excepción aprobada.La generación está “aumentada” por retrieval.
Respuesta con evidencia
La arquitectura debería, cuando la tarea lo requiera, conservar vínculos hacia la evidencia.
Por ejemplo:
| Afirmación | Fuente |
|---|---|
| Cap propuesto = 3 meses | contrato, §14.2 |
| Estándar = 12 meses | estándar v4, §8.4 |
| ACME = excepción | acta ACME, §4 |
Esto hace posible verificar.
Pero una cita no garantiza que la inferencia sea correcta.
RAG y la ventana de contexto
Podría pensarse:
“Si los modelos admiten contextos cada vez más largos, RAG dejará de ser necesario.”
Huyen plantea una objeción importante a esa idea.
Incluso si la ventana crece, los datos disponibles pueden crecer más, procesar más contexto cuesta, más contexto puede añadir latencia y el modelo puede utilizar mal información irrelevante.
RAG no existe solamente porque el contexto sea pequeño.
También existe porque queremos seleccionar.
RAG y relevancia
Berryman y Ziegler advierten que fragmentos irrelevantes pueden perjudicar la generación.
El modelo puede asumir que si un texto fue incluido debe importar.
Por eso una recuperación defectuosa puede producir respuestas defectuosas aunque el generator sea excelente.
Podemos expresarlo:
buen modelo
+
mal contexto
=
mal sistemaQué RAG no garantiza
Esta es quizá la parte más importante.
No garantiza que la fuente correcta exista en el corpus
Si el anexo decisivo nunca fue incorporado, no puede recuperarse.
No garantiza exhaustividad
El retriever puede omitir material relevante.
Encontrar tres precedentes no prueba que no existan otros.
No garantiza vigencia
Puede recuperarse una versión antigua.
No garantiza aplicabilidad
Una política vigente puede pertenecer a otra unidad o categoría.
No garantiza que el fragmento conserve contexto suficiente
Puede faltar una excepción.
No garantiza que el modelo interprete correctamente
Una fuente correcta puede ser leída incorrectamente.
No garantiza que la cita respalde la afirmación
Una referencia real puede ser utilizada para una conclusión que el texto no demuestra.
No garantiza veracidad
RAG puede reducir ciertos errores al aportar información relevante.
No transforma automáticamente la generación en verdad.
No reemplaza selección jurídica de fuentes
Un algoritmo de relevancia no determina por sí solo autoridad jurídica.
No reemplaza revisión profesional
En tareas de alto impacto, el output puede seguir necesitando verificación y decisión humana.
RAG mejora acceso, no elimina juicio
Pregunte siempre:
- ¿la fuente existía?
- ¿fue recuperada?
- ¿era vigente?
- ¿era aplicable?
- ¿el fragmento era suficiente?
- ¿la afirmación está respaldada?
- ¿la evaluación jurídica es correcta?
RAG responde principalmente a la segunda pregunta.
RAG ≠ memoria
Otra confusión frecuente es llamar “memoria” a cualquier información recuperada.
En este handbook:
RAG responde:
¿qué información externa debemos traer al contexto para esta ejecución?
Memoria se ocupará más adelante de persistencia de estado o información entre interacciones.
Pueden conectarse.
No son sinónimos.
RAG ≠ fine-tuning
También conviene proteger otra frontera.
RAG introduce información durante la ejecución.
Fine-tuning modifica parámetros del modelo mediante entrenamiento adicional.
Ambos pueden especializar un sistema.
Lo hacen de manera diferente.
Para información cambiante y con necesidad de procedencia, la recuperación posee ventajas evidentes: podemos actualizar el resource sin reentrenar el modelo.
Evaluar un sistema RAG
No basta probar si “la respuesta suena bien”.
Podemos separar dos familias de preguntas.
Evaluación del retrieval
¿recuperó la fuente correcta?
¿omitió algo relevante?
¿introdujo ruido?
¿respetó filtros?Evaluación de la generación
¿utilizó correctamente la evidencia?
¿distinguió fuente e inferencia?
¿citó bien?
¿exageró la conclusión?Esta separación es coherente con la lógica modular de toda la sección.
Riesgos de conocimiento en trabajo jurídico
Los materiales del curso sintetizan cinco riesgos especialmente útiles:
| Riesgo | Manifestación | Control |
|---|---|---|
| Desactualización | recupera estándar antiguo | versión y vigencia |
| Fuente débil | trata precedente informal como criterio | jerarquía de fuentes |
| Fragmentación | omite anexo o excepción | chunking y cobertura |
| Confusión | mezcla políticas de ámbitos distintos | filtros y metadatos |
| Falsa seguridad | responde sin evidencia suficiente | umbral de abstención |
La tabla muestra algo importante:
RAG es una arquitectura de acceso a información, no una arquitectura completa de confianza.
El caso conductor
Para la cláusula de responsabilidad:
Consulta
estándar vigente cap SaaS críticoBúsqueda
Encuentra política, precedentes y matriz.
Recuperación
Selecciona:
Estándar v4 §8.4
Matriz §3.2
ACME §15
Acta ACME §4Fragmentación
Conserva la regla junto con sus excepciones.
Contexto
Incorpora esos fragmentos con la cláusula nueva y la skill.
Respuesta
Compara tres meses con doce y distingue ACME como excepción.
Ahora poseemos todas las piezas para estudiar el caso completo.
Qué debes recordar
RAG significa:
Retrieval
+
Augmented
+
GenerationEl sistema recupera información externa relevante y la incorpora al contexto antes de generar.
La arquitectura mínima contiene:
consulta
→ búsqueda
→ recuperación
→ fragmentos
→ contexto
→ generaciónEmbeddings, bases vectoriales, búsqueda híbrida, reranking y query rewriting son técnicas o componentes posibles.
No son la definición de RAG.
La calidad depende especialmente de la recuperación.
Y RAG no garantiza exhaustividad, vigencia, aplicabilidad, correcta interpretación ni verdad.
El problema que todavía queda abierto
Hemos estudiado las piezas separadamente.
Ahora podemos reconstruir el proceso completo:
skill
+
estándar interno
+
precedentes
+
retrieval
+
contexto
+
respuesta con evidenciaLa siguiente página aplica toda la sección a una cláusula contractual concreta.