Por qué eliminamos el 70% de la base corporativa sin escribir una sola línea de código: anatomía de ingeniería del RAG empresarial

• Proporción de problemas en los datos: el 70–80% de todos los fallos de RAG corporativo (30% versiones antiguas, 20% duplicados, 15% OCR defectuoso)
• Caso real de depuración de base: la reducción de 12.000 a 3.800 documentos disparó la precisión de búsqueda de forma multiplicativa
• Ganancia del Tool-based RAG: hasta +70% en la calidad de respuesta al pasar de un pre-query ciego a function calling
• Parámetros de fragmentación (chunking) de normativas: Parent-Child (fragmento de búsqueda child de 200–300 tokens, bloque contextual parent de 1500–2000)

Desarrollando asistentes de IA y bases de conocimiento de proyectos en AlpinaGPT (hoy la plataforma cuenta con más de 8.000 usuarios activos y más de 40 clientes corporativos), he analizado decenas de implementaciones externas de RAG. Casi siempre se repite el mismo escenario: los ingenieros montan un prototipo vistoso en una semana, defienden el presupuesto, y un mes después del despliegue en producción el sistema empieza a citar con total seguridad órdenes internas canceladas hace tres años e inventa cláusulas de contratos que no existen.

Los clientes intentan arreglarlo cambiando el LLM o recurriendo al GraphRAG, que está de moda. Pero mi experiencia muestra una proporción contundente: el 80% de las tareas corporativas se resuelven perfectamente con un RAG clásico avanzado con metadatos, sin necesidad de un GraphRAG sobrecomplicado, y el 70–80% de todos los fallos residen en la ingeniería de datos, no en los pesos de la red neuronal.

¿Por qué el RAG corporativo genera alucinaciones y encuentra

normativas obsoletas?

Entre la carpeta con los documentos corporativos y la respuesta correcta del modelo hay cuatro cuellos de botella sistémicos:

1. Corpus de entrada contaminado (Data Engineering): cuando un cliente nos entrega 10.000 archivos corporativos, el 30% resultan ser versiones obsoletas sin fecha, el 20% son duplicados casi idénticos y el 15% son escaneos PDF defectuosos con basura tras el OCR y encabezados/pies de página.

En una implementación, de 12.000 documentos entregados y marcados como «vigentes», tras la auditoría quedaron exactamente 3.800.

Simplemente eliminamos tres cuartas partes de ese cementerio de archivos (presentaciones de 2020 y borradores), y la calidad de las respuestas se multiplicó sin tocar una sola línea de código. La regla de verificación clave de la primera semana: comprobar qué porcentaje de archivos tiene una fecha de modificación superior a un año. 2.

Fallos de la búsqueda vectorial en ruso: el modelo estándar `text-embedding-3-large` de OpenAI a menudo flaquea con la terminología sectorial rusa. Según nuestras mediciones, en normativas en cirílico funcionan notablemente mejor `multilingual-e5-large` y `jina-embeddings-v3`. Además, la búsqueda vectorial pura se pierde con consultas del tipo «apartado 4.

2.1 de la orden n.º 47»: aquí es obligatorio un esquema híbrido de `vector + búsqueda léxica BM25` con reranking posterior.

3. Degradación silenciosa sin monitorización: la base se actualiza y, dos meses después, la precisión cae. Además del trío básico de métricas de RAGAS (`Faithfulness`, `Answer Relevancy`, `Context Recall`), en la versión v0.

2 apareció una métrica crítica para las empresas: `Noise Sensitivity`, que mide la resistencia de la respuesta frente a un contexto contaminado. Y el indicador temprano más económico de que el RAG se está rompiendo en producción es la gráfica semanal de la longitud media de respuesta en tokens: en cuanto el modelo deja de encontrar el dato exacto, empieza a «rellenar con paja» e inflar los párrafos, de 2 a 3 semanas antes de las primeras quejas de los usuarios. 4.

Límite estructural: el RAG trabaja con instantáneas estáticas y no sustituye a una base transaccional (CRUD) para controlar existencias de almacén o precios en tiempo real.

¿Cómo se diseña correctamente la fragmentación de chunks para

normativas, código y FAQ?

Meter un PDF de 80 páginas en un solo vector, o fragmentar documentos sin conservar metadatos (fuente, fecha, sección, autor), es una forma garantizada de arruinar la búsqueda. No existe un tamaño de chunk único: ajustamos la estrategia según la física de cada documento:

• Contratos legales y normativas internas: estrategia `Parent-Child`. La búsqueda se realiza sobre un fragmento hijo estrecho de 200–300 tokens (máxima precisión en el acierto), y en el prompt del modelo se inserta un bloque padre amplio de 1500–2000 tokens, para no perder condiciones ni cláusulas.
• Documentación técnica y descripciones de API: ventana fija `Fixed-size` de 500 tokens con superposición (`overlap`) de 100 tokens, para no cortar una idea por la mitad.
• Código fuente de repositorios: fragmentación estrictamente semántica, respetando los límites de funciones y clases.
• Manuales breves y bases de FAQ: método `Sentence window` — se busca por una sola frase y se entrega al modelo una ventana de `±N` frases vecinas.

¿Qué hacer en la práctica: por qué el

Tool-based RAG supera en un 70% a la búsqueda nativa?

En las implementaciones más básicas, la búsqueda está incrustada a la fuerza antes de cada llamada al modelo (Native RAG): el usuario escribe en el chat «Hola, ¿qué tal?» y el sistema arrastra obedientemente de la base vectorial cinco fragmentos aleatorios de los estatutos de la empresa, quemando tokens y confundiendo al modelo.

Nosotros trasladamos la arquitectura a Tool-based RAG: el motor de búsqueda se conecta al modelo como una herramienta externa mediante `function calling`. El agente decide por sí mismo si necesita consultar la base de conocimiento, reformula por su cuenta la pregunta del usuario en una consulta de búsqueda precisa y, si es necesario, realiza de 2 a 3 llamadas dirigidas a distintas colecciones. En nuestros proyectos, solo este cambio aporta hasta un 70% de mejora en la calidad de las respuestas, y los dos días invertidos en escribir un analizador limpio de DOCX/PDF a Markdown estructurado ahorran meses de lucha contra las alucinaciones.

Repasamos en detalle toda la cocina del diseño de RAG sobre pgvector y las herramientas de agentes en nuestros cursos de ingeniería en [Hamidun Academy](https://academy.hamidun.com) y en los análisis de arquitectura de [Vibe Club](https://hamidun.

com/club).