Blog

Si has estado construyendo un sistema de Generación Aumentada por Recuperación (RAG), es probable que te hayas topado con un muro invisible. Sigues las guías, configuras tu base de datos vectorial y ajustas el chunking, pero las respuestas siguen siendo decepcionantes: el sistema “alucina”, inventa hechos o ignora justo el contexto relevante. Y lo peor es que muchas veces parece aleatorio: hoy acierta, mañana se descarrila.

La reacción instintiva suele ser girar las mismas perillas técnicas: cambiar el modelo de embeddings, tocar el top-k, probar un reranker. A veces ayuda, sí, pero a menudo no ataca la raíz del problema. En la práctica, los RAG que funcionan de forma fiable no son los que “tienen mejores vectores”, sino los que están mejor diagnosticados, mejor orquestados y mejor alimentados.

Aquí van cuatro lecciones que no suelen aparecer en tutoriales básicos, pero que marcan la diferencia cuando pasas de prototipo a producción.

Lección 1: deja de “arreglar” alucinaciones. Primero, crea un protocolo de diagnóstico.

Cuando un RAG falla, solemos tratar el síntoma (“alucinó”) como si fuera la causa. Y entonces entramos en modo ensayo-error: sube top-k, cambia el tamaño de los chunks, mete un reranker, reescribe el prompt… El resultado: mejoras puntuales, pero sin comprender el porqué.

La idea contra-intuitiva es esta: antes de tocar nada técnico, define un protocolo de diagnóstico. Un checklist simple, repetible, que te obligue a responder preguntas básicas antes de proponer soluciones.

Un buen protocolo suele tener tres pasos:

• Preguntar (ASK): ¿Cuál es exactamente el pipeline? ¿Qué recuperador usas? ¿Cómo haces chunking? ¿Cuál es el modelo de embeddings? ¿Cómo evalúas si recuperó bien?

• Declarar “desconocido” (UNKNOWN): si no hay evidencia suficiente, no se especula. Se marca el punto como “no sabemos” y se mide.

• Proceder (PROCEED): solo con trazas y datos (qué chunks se recuperaron, con qué score, desde qué fuente) se propone un cambio.

Esto transforma la depuración de un ejercicio de intuición a un proceso de ingeniería. Y, de paso, te obliga a instrumentar tu RAG: logs del retrieval, trazabilidad de fuentes, métricas de “recuperación correcta”, etc.

Lección 2: tu RAG es “analfabeto” con datos estructurados. Necesitas una orquesta, no un solista.

El RAG clásico está diseñado para texto no estructurado. Y se rompe cuando le das:

• tablas

• catálogos con códigos (SKUs, referencias)

• datos relacionales (ERP/CRM)

• conocimiento en forma de grafo (relaciones, dependencias, jerarquías)

¿Por qué? Porque los embeddings semánticos no “entienden” la estructura de una tabla como tabla. Si “aplanas” una tabla a texto, destruyes una parte enorme de la señal (encabezados, relaciones fila-columna, unidades, claves).

La solución no suele ser “un embedding mejor”, sino cambiar el enfoque: una arquitectura multi-motor (una orquesta de recuperación), donde cada motor hace lo que mejor sabe:

• Vectores: para similitud semántica en texto libre.

• Keyword/Sparse: imprescindible para términos exactos (códigos, IDs, nombres propios).

• SQL: para filtros, agregaciones y consultas precisas sobre campos estructurados.

• Grafo: para preguntas de relaciones y razonamiento multi-salto.

Cuando mezclas motores y los orquestas bien, tu RAG deja de ser un “buscador semántico con prompt” y se convierte en un sistema que se adapta al tipo de dato y al tipo de pregunta.

Lección 3: la calidad de tu RAG se decide en la ingesta, no en la búsqueda.

Esta es la parte menos glamourosa y más decisiva: cómo parseas e ingestas los documentos.

En producción, el fallo típico no está en el retriever: está en que el documento entró mal. PDFs con columnas, listas rotas, encabezados perdidos, tablas convertidas en sopa de palabras… y luego te preguntas por qué el chunking es mediocre o por qué la recuperación trae fragmentos incoherentes.

La idea clave: si tu parser destruye la estructura, tu RAG recupera basura con mucha confianza.

¿Qué suele funcionar mejor?

• Convertir documentos a una representación que preserve estructura (títulos, secciones, listas, tablas).

• Añadir metadatos útiles por chunk: sección, página, jerarquía, tipo de bloque (tabla/párrafo), etc.

• Hacer chunking semántico (por secciones y límites naturales), no solo por número de tokens.

• Cuando sea posible, aprovechar señales “visuales” del documento: bloques, cajas, orden de lectura.

Invertir en una ingesta de alta fidelidad suele dar más retorno que semanas ajustando top-k o cambiando embeddings.

Lección 4: para control absoluto, rompe la caja negra y convierte la recuperación en un paso “visible”.

El flujo típico (prompt → retrieval → LLM) es cómodo, pero es una caja negra: si responde mal, no sabes si falló la búsqueda, el ranking o la generación. Para dominios donde la precisión es crítica (legal, auditoría, compliance, investigación), esa opacidad es inaceptable.

La propuesta contra-intuitiva: hacer la recuperación explícita y revisable.

Un flujo muy potente es:

1. El usuario lanza la consulta.

2. El sistema muestra una lista amplia de fragmentos recuperados (por ejemplo, top 50), con metadatos y fuente.

3. El usuario (o un analista) selecciona manualmente los fragmentos relevantes, pudiendo refinar búsquedas y añadir contexto “antes/después”.

4. Solo entonces se envía el prompt final + contexto curado al LLM.

Sí, sacrificas automatización. Pero ganas transparencia, determinismo y control. Y, en ciertos entornos, eso vale oro: reduces errores, aumentas confianza y puedes justificar respuestas con trazabilidad real.

Conclusión: más allá de los vectores

Construir un RAG fiable no va de “encontrar el embedding perfecto”. Va de cambiar el marco mental: de modelos y vectores a procesos, arquitectura e higiene del dato.

• Protocolo de diagnóstico antes de optimizar.

• Orquesta multi-motor para datos reales (no solo texto bonito).

• Ingesta como fundación del sistema.

• Recuperación visible cuando la precisión importa.

La pregunta final no es si automatizar más o menos, sino esto: ¿dónde trazas la línea entre un asistente totalmente automático y una herramienta que exige supervisión humana para garantizar fiabilidad?