1. Modelo mental
RAG no significa “subir PDFs a una IA”. Es un pipeline que decide qué documentos entran, cómo se trocean, cómo se indexan, qué fragmentos se recuperan y cómo se obliga al modelo a responder con evidencia.
La calidad final es multiplicativa: un modelo excelente no puede citar un fragmento que nunca fue recuperado. Por eso conviene separar métricas de ingestión, retrieval y generación.
En documentos privados aparece además una dimensión crítica: permisos. Recuperar el fragmento correcto para la persona equivocada sigue siendo un fallo grave.
2. Conceptos que debes dominar
Extracción y normalización de contenido, metadatos, estructura y permisos.
Unidad que se indexa y recupera. Su tamaño debe reflejar estructura y preguntas.
Representación vectorial que permite comparar similitud semántica.
Recuperación léxica útil para términos exactos, códigos y nombres.
Combina señales semánticas y léxicas para mejorar cobertura.
Reordena candidatos con un modelo más caro o preciso.
Número de fragmentos enviados a la siguiente etapa; demasiado bajo omite, demasiado alto contamina.
Vínculo entre respuesta y fragmento/documento original.
Reglas de acceso que deben aplicarse antes o durante retrieval.
Pruebas separadas para recuperación, grounding y utilidad de respuesta.
3. Workflow paso a paso
Inventaría documentos
Tipos, formatos, tamaño, propietarios y sensibilidad.
Conoces volumen y permisos.
Define preguntas
Recoge consultas reales, no sólo documentos.
Puedes diseñar chunking contra necesidades.
Extrae estructura
Conserva títulos, páginas, tablas y metadatos.
No conviertes todo en texto plano sin contexto.
Trocea
Prueba tamaños y overlap; usa límites semánticos cuando convenga.
Cada chunk tiene origen recuperable.
Indexa
Elige vector, léxico o híbrido y guarda filtros.
Puedes filtrar por permisos/metadatos.
Recupera y rerankea
Genera candidatos y mide recall antes de tocar el prompt.
La evidencia correcta aparece en top-k.
Genera con contrato
Limita respuesta a contexto y exige citas.
El modelo sabe abstenerse.
Evalúa y opera
Mide retrieval, respuesta, latencia, coste y freshness.
Puedes detectar regresiones y documentos caducados.
4. Ejemplo completo
Caso:manuales técnicos internos. 18.000 páginas, versiones por producto y acceso por equipo.
Se extraen encabezados, número de página, versión, producto y ACL. Se prueban chunks de 400, 800 y 1.200 tokens con overlap 10–15%. La búsqueda combina BM25 y embeddings porque hay códigos exactos de piezas. El reranker selecciona 6 fragmentos. La respuesta debe citar manual, versión y página.
El eval incluye preguntas cuya respuesta está en una tabla, preguntas ambiguas y preguntas sin respuesta. El objetivo no es “responder siempre”: una abstención correcta es mejor que una instrucción técnica inventada.
5. Matriz de decisión
| Decisión | Qué mirar | Señal buena | Señal de riesgo |
|---|---|---|---|
| Chunk pequeño | Consultas puntuales | Alta precisión | Pierde contexto |
| Chunk grande | Contexto narrativo | Menos fragmentación | Dilución y coste |
| Vector | Semántica | Recupera paráfrasis | Falla códigos exactos |
| BM25 | Términos exactos | Nombres/códigos | Falla semántica |
| Híbrido + rerank | Corpus complejo | Cobertura + precisión | Más latencia/coste |
6. Fallos y límites
Una guía útil también debe decir cuándo detenerse. Estos son los fallos que más cambian la calidad del resultado:
- Indexar documentos sin versión ni fecha.
- No aplicar ACL en retrieval.
- Optimizar prompt antes de medir recall.
- Usar chunk fijo ignorando tablas y estructura.
- Introducir demasiados chunks y saturar contexto.
- Citar documentos sin verificar que el fragmento soporta la frase.
- No tener casos “sin respuesta”.
- No borrar/reindexar contenido revocado.
7. Cómo medirlo
No midas sólo si “parece bueno”. Define una señal observable antes de escalar.
| Métrica | Qué mide | Cómo observarla | Umbral/alerta |
|---|---|---|---|
| Recall@k | Evidencia recuperada | Golden queries | Bajo por slice |
| MRR/nDCG | Orden relevante | Ranking | Evidencia llega tarde |
| Groundedness | Respuesta soportada | Claims vs chunks | Claim sin soporte |
| Citation accuracy | Cita correcta | Documento/página | Cita decorativa |
| Abstention | No inventa cuando falta | Casos sin respuesta | Responde sin evidencia |
| Latency/cost | Operación | p95 + coste | Reranking excesivo |
8. Checklist de producción
9. Ejercicios para convertir lectura en habilidad
- Toma cinco documentos y crea 20 preguntas reales antes de elegir chunk size.
- Compara vector vs BM25 en nombres propios y paráfrasis.
- Mide recall@5 antes de cambiar el modelo generativo.
- Añade una ACL y verifica que un usuario no recupere contenido ajeno.
- Diseña una respuesta de abstención que sea útil y accionable.
10. Qué estudiar después
No intentes memorizar toda la IA. Encadena la siguiente pieza cuando resuelva una duda que ya has encontrado en la práctica.
Apéndice A · Preguntas que deberías poder responder
- ¿Qué parte del problema es determinista y cuál necesita juicio probabilístico?
- ¿Qué dato o ejemplo cambiaría tu decisión actual?
- ¿Cómo distinguirás una mejora real de una respuesta simplemente más convincente?
- ¿Qué ocurre cuando faltan datos, la herramienta falla o la respuesta es incierta?
- ¿Qué parte del proceso debe seguir bajo responsabilidad humana?
- ¿Qué coste operativo aparece después del primer prototipo?
- ¿Qué revisarías dentro de 30, 90 y 180 días para evitar que el sistema envejezca?
Si no puedes responder todavía a varias de estas preguntas, no significa que el proyecto esté mal: significa que has encontrado exactamente los huecos que la siguiente iteración debe cerrar. Ese es uno de los usos más valiosos de una guía técnica: convertir incertidumbre difusa en decisiones explícitas.
Apéndice B · Cuatro escenarios para practicar la decisión
Pregunta:Consultas puntuales.Señal favorable:Alta precisión.Alerta:Pierde contexto.
Pregunta:Contexto narrativo.Señal favorable:Menos fragmentación.Alerta:Dilución y coste.
Pregunta:Semántica.Señal favorable:Recupera paráfrasis.Alerta:Falla códigos exactos.
Pregunta:Términos exactos.Señal favorable:Nombres/códigos.Alerta:Falla semántica.
No memorices la tabla como si fuera una regla universal. Cambia volumen, riesgo, disponibilidad, privacidad o coste y vuelve a recorrer la decisión. Un sistema robusto documenta qué variables sostienen la elección y cuáles podrían invalidarla.
Apéndice C · Cuaderno de campo para tu propio caso
Copia estas preguntas en un documento y complétalas con un caso real. El objetivo es que el conocimiento deje de estar en la página y pase a tu proceso.
- Problema¿Qué trabajo concreto intentas mejorar y para quién?
- Baseline¿Cómo se hace hoy, cuánto tarda y qué errores aparecen?
- Datos¿Qué entra, de dónde viene, quién puede verlo y qué no debería salir del entorno?
- Salida¿Qué formato y criterios convierten el resultado en usable?
- Prueba¿Qué 20–50 casos representarían el trabajo real?
- Riesgo¿Cuál es el fallo más costoso y cómo se detecta?
- Operación¿Quién observa, corrige, actualiza y puede detener el sistema?
- Revisión¿Qué evento o fecha obligará a reevaluar esta decisión?
Guarda también dos ejemplos que funcionaron y dos que fallaron. Con el tiempo, esos ejemplos se convierten en un pequeño dataset de evaluación mucho más útil que cualquier memoria informal de “esto parecía ir bien”.
Apéndice D · De prototipo a producción
Una demo responde a la pregunta “¿puede funcionar?”. Producción responde a otras: “¿funciona de forma repetible?”, “¿qué pasa cuando falla?”, “¿quién lo mantiene?”, “¿cómo sabemos que sigue siendo bueno dentro de tres meses?” y “¿podemos revertirlo?”. El salto entre ambas fases suele ser mayor que el salto entre dos modelos.
Antes de escalar, separa cuatro planos.Calidad:casos y métricas.Operación:latencia, cuotas, errores y costes.Gobernanza:permisos, datos, revisión y responsables.Cambio:versiones, fuentes y fechas de reevaluación. Si uno de estos planos no tiene dueño, el riesgo aparecerá precisamente cuando el uso crezca.
- Define un SLO de calidad y uno operativo.
- Registra versión de modelo, prompt, fuentes y configuración.
- Mantén una muestra estable para detectar regresiones.
- Añade un fallback para proveedor, herramienta o dato ausente.
- Decide qué errores se reintentan y cuáles se escalan.
- Presupuesta revisión humana, no sólo tokens.
- Evita permisos permanentes que sólo necesitabas para una prueba.
- Programa una revisión tras cambios de modelo, precio, política o dataset.
Finalmente, observa el sistema con tráfico real. Una mejora offline puede empeorar experiencia, coste o tasa de escalado. Las métricas de esta guía son el comienzo; adáptalas al impacto de tu caso y conserva siempre ejemplos concretos detrás de cada porcentaje.
RAG de producción: retrieval antes que generación
RAG no es “subir PDFs a un chatbot”. Es un pipeline de recuperación. Antes de pensar en el modelo generativo debes decidir cómo se limpian los documentos, cómo se dividen, qué metadata se conserva y cómo se recuperan fragmentos. Si el retrieval no encuentra la evidencia correcta, un modelo excelente sólo redactará mejor sobre contexto incorrecto.
El chunking es una decisión semántica y operativa. Fragmentos demasiado pequeños pierden contexto; demasiado grandes diluyen señales y consumen ventana. Overlap puede conservar continuidad pero aumenta almacenamiento y repetición. El tamaño óptimo depende de estructura, longitud de respuesta y tipo de consulta, por eso debe evaluarse con preguntas reales.
Combina señales cuando sea útil. La búsqueda vectorial captura similitud semántica; palabras clave conservan exactitud para códigos, nombres o términos raros; filtros de metadata limitan el universo; un reranker puede ordenar candidatos. RAG maduro suele ser un sistema de recuperación híbrido, no una única consulta a un vector store.
La respuesta debe conservar provenance. Guarda qué chunks llegaron al modelo y qué documento/página los originó. Evalúa retrieval por separado de generación: recall@k o hit rate para encontrar evidencia, y groundedness/correctness para la respuesta. Si sólo mides la respuesta final no sabrás si el fallo estuvo en búsqueda o en síntesis.
Añade una política de abstención. Cuando no haya evidencia suficiente, la respuesta correcta puede ser “no encontrado en los documentos”. Un sistema que siempre produce una respuesta puede parecer útil en demo y ser peligroso en producción.
Una escala de madurez para rag de producción: retrieval antes que generación
Resuelve un caso real de principio a fin. Conserva entrada, salida y correcciones. Aquí buscas descubrir fallos, no automatizar.
La entrada y la salida ya tienen contrato, existen ejemplos límite y puedes medir calidad, tiempo y coste con el mismo criterio.
Hay observabilidad, permisos, fallback, responsable, revisión de cambios y un mecanismo para detectar regresiones antes de afectar al usuario.
La transición entre niveles debe estar motivada por evidencia. No pases a integración o autonomía sólo porque una demo salió bien. Pasa cuando hayas repetido la tarea con casos representativos, sepas dónde falla y el ahorro neto siga siendo positivo después de incluir revisión y operación.
Para los primeros 30 días, reúne ejemplos y construye el baseline. Entre 30 y 60 días, estabiliza el contrato de entrada/salida y convierte los fallos recurrentes en tests, checklist o reglas. Entre 60 y 90 días, si el volumen lo justifica, añade automatización, monitorización y revisión de costes. Si una etapa no supera sus propios criterios, mantén el sistema en la etapa anterior.
Documenta también las condiciones de salida: qué cambio de proveedor, política, precio, modelo, volumen o riesgo obligaría a reevaluar el diseño. Una arquitectura madura no pretende ser definitiva; hace explícito cuándo deja de ser válida.
Antes de considerar el trabajo terminado, realiza una revisión adversarial: busca deliberadamente entradas ambiguas, datos faltantes, instrucciones contradictorias, límites de cuota y resultados que parezcan correctos pero no puedan verificarse. El objetivo no es demostrar que el sistema funciona, sino descubrir bajo qué condiciones deja de funcionar y comprobar que esos fallos tienen una respuesta segura. Registra cada hallazgo y conviértelo en una prueba futura.
- Guarda al menos 20 casos reales, incluidos fallos.
- Define un criterio de aprobación que otra persona pueda aplicar.
- Separa métricas de calidad, coste y operación.
- Establece quién puede detener o revertir el sistema.
- Programa una fecha de revisión aunque nada parezca haber cambiado.
Documentación que sostiene y actualiza esta guía
Las capacidades y políticas cambian. Usa estas referencias para comprobar los puntos que dependan de un proveedor o de una versión concreta.