RAG es la aspirina de la IA generativa: todo el mundo la receta, casi nadie entiende cómo funciona realmente, y cuando falla, el paciente sufre alucinaciones. Si has asistido a cualquier conferencia de tecnología en los últimos 18 meses, habrás escuchado la misma promesa repetida como un mantra: “Conecta tu LLM a tus documentos con RAG y tendrás un chatbot que responde con la verdad de tu empresa”. Es una promesa seductora. También es, en la mayoría de las implementaciones que he visto, una mentira piadosa.

Lo sé porque he recorrido ambos caminos. Construí un sistema RAG funcional en producción —el Ops Engineering Copilot con Algolia Agent Studio, indexando los más de 70 posts de este blog— y también construí un sistema que rechaza RAG deliberadamente —el radar agéntico de obsolescencia, que usa Tool Calling puro para consultar bases de datos industriales con precisión matemática—. La experiencia de operar ambos sistemas en producción me ha dejado una conclusión incómoda: RAG no es malo; lo que es malo es cómo lo implementamos.

Este artículo es el catálogo de los 7 errores que destruyen la precisión de un sistema RAG, las soluciones que funcionan, y la pregunta que nadie quiere hacerse: ¿realmente necesitas RAG, o necesitas otra cosa?

Antipatrón 1: Chunking a Ciegas

El primer paso de cualquier pipeline RAG es trocear tus documentos en fragmentos (chunks) que se almacenarán como vectores. Y aquí es donde la mayoría de los tutoriales cometen el primer pecado mortal: trocear por longitud fija (por ejemplo, 500 tokens por chunk con 50 tokens de overlap).

El problema es brutal: un párrafo que explica un concepto técnico complejo queda cortado por la mitad. La primera mitad acaba en un chunk, la segunda en otro. Cuando el usuario hace una pregunta, el retriever encuentra la primera mitad (que contiene las palabras clave), pero le falta el contexto de la segunda. El LLM, fiel a su naturaleza, rellena lo que falta con una invención plausible. Alucinación servida.

La solución: Chunking semántico. Trocear por unidades lógicas de significado: secciones delimitadas por headers, párrafos completos, o bloques funcionales del documento. En el Ops Copilot, cuando indexamos los posts de Datalaria con Algolia, cada record corresponde a una sección completa del artículo (delimitada por ### en Markdown), no a un bloque arbitrario de N tokens. El resultado: cada chunk es autosuficiente y contiene un pensamiento completo.

Antipatrón 2: Embeddings Genéricos para Dominios Especializados

Los embeddings pre-entrenados (como text-embedding-3-small de OpenAI o los de Vertex AI) están entrenados con texto general de internet. Funcionan razonablemente bien para preguntas genéricas. Pero cuando tu dominio es altamente especializado —ingeniería industrial, normativa europea, nomenclatura de componentes electrónicos—, la distancia semántica entre términos clave puede ser completamente incorrecta en el espacio vectorial.

Un ejemplo real: en el contexto de la gestión de obsolescencia, los términos “EOL” (End of Life), “NRND” (Not Recommended for New Designs) y “PDN” (Product Discontinuation Notice) están semánticamente muy próximos para un ingeniero de supply chain. Pero para un embedding genérico, “End of Life” podría estar más cerca de un artículo sobre cuidados paliativos que de un aviso de discontinuación de un chip.

La solución: Evalúa los embeddings con tu propio dataset antes de comprometerte. Construye un pequeño benchmark de 50-100 pares pregunta-respuesta de tu dominio y mide la tasa de acierto del retriever (hit rate). Si los embeddings genéricos no superan el 80% de acierto en tu benchmark, considera fine-tuning o embeddings especializados para tu sector. Y si tu dominio es altamente estructurado (códigos, nomenclaturas, tablas), probablemente no necesitas embeddings en absoluto: necesitas Tool Calling.

Antipatrón 3: Olvidar el Reranking

El retriever vectorial te devuelve los k documentos más “cercanos” en el espacio de embeddings. Pero cercanía vectorial no es sinónimo de relevancia. Un documento puede contener las mismas palabras clave que la pregunta del usuario y, sin embargo, responder a una pregunta completamente diferente.

He visto este antipatrón causar estragos en sistemas de soporte técnico: el usuario pregunta "¿Cómo configuro el timeout del agente CrewAI?", el retriever devuelve un chunk sobre timeouts de GitHub Actions (mismo vocabulario, contexto diferente), y el LLM genera una respuesta técnicamente correcta para el chunk equivocado.

La solución: Añadir una capa de reranking entre el retriever y el LLM. Un reranker (como Cohere Rerank o un cross-encoder local) recibe la pregunta original y los k candidatos del retriever, y los reordena por relevancia semántica real, no por simple proximidad vectorial. En la práctica, un reranker bien configurado puede mejorar la precisión del retrieval entre un 15% y un 30%, una mejora que se traduce directamente en menos alucinaciones.

Antipatrón 4: Contexto Insuficiente en el Prompt

El error más extendido y más fácil de cometer: inyectar 2-3 chunks en el prompt del LLM y esperar un milagro. Los modelos modernos como Gemini 2.5 o Claude manejan ventanas de contexto de cientos de miles de tokens. Alimentarlos con 500 tokens de contexto recuperado es como darle a un motor de Fórmula 1 el combustible de un mechero.

La solución: Experimenta agresivamente con el tamaño de la ventana de contexto inyectada. Aumenta de top-3 a top-10 o top-15 chunks y mide el impacto en la calidad de la respuesta. Incluye metadatos enriquecidos en cada chunk: título del documento fuente, fecha de creación, autor, sección. Estos metadatos le dan al LLM un marco referencial para evaluar la relevancia y la actualidad de la información. En el Ops Copilot, cada record de Algolia incluye no solo el texto del post, sino también el título, la categoría, los tags y la fecha de publicación.

Antipatrón 5: Alucinación por Retrieval Parcial

Este es el antipatrón más peligroso porque es silencioso. El retriever encuentra un chunk parcialmente relevante. El LLM detecta que la información está incompleta. En lugar de detenerse y confesar su ignorancia, completa la respuesta con información fabricada que suena perfectamente plausible. El usuario no tiene forma de distinguir qué parte de la respuesta proviene del retrieval y qué parte es una alucinación.

En aplicaciones industriales, esto puede ser catastrófico. Imagina un sistema RAG conectado a tu documentación de mantenimiento que, ante una pregunta sobre el par de apriete de un tornillo crítico, devuelve un valor inventado porque el chunk correcto no fue recuperado. El resultado puede ser un fallo mecánico en producción.

La solución: Doble barrera. Primera: instruye al LLM en el system prompt para que responda “No tengo información suficiente en la documentación proporcionada para responder a esta pregunta” cuando el contexto recuperado sea insuficiente o ambiguo. Incluye ejemplos en el prompt (few-shot) de respuestas correctas que reconocen limitaciones. Segunda: implementa una validación posterior de la respuesta. Evalúa programáticamente si la respuesta contiene afirmaciones que no están respaldadas por los chunks inyectados (frameworks como RAGAS automatizan esta verificación con métricas como faithfulness y answer relevancy).

Antipatrón 6: No Medir la Calidad

El sexto antipatrón es cultural, no técnico: lanzar un sistema RAG a producción sin métricas de evaluación. Preguntar “¿funciona?” a cinco compañeros de equipo no es una metodología de evaluación; es una anécdota. Sin métricas cuantitativas, no puedes saber si un cambio en el chunking mejoró o empeoró la precisión, si un nuevo embedding model es superior al anterior, o si el reranker que acabas de añadir justifica su coste de latencia.

La solución: Implementar un framework de evaluación automatizado antes de lanzar a producción. Las herramientas más maduras son:

  • RAGAS (Retrieval Augmented Generation Assessment): Mide faithfulness (la respuesta está fundamentada en el contexto), answer relevancy (la respuesta es relevante a la pregunta), y context precision (los chunks recuperados son relevantes).
  • DeepEval: Framework open-source que permite definir test suites con métricas como hallucination score, bias, y toxicity.

El punto clave es tratar la evaluación de RAG como tratas los tests unitarios de tu código: si no tiene tests, no va a producción. Cada iteración del pipeline (cambio de embedding, ajuste de chunk size, nuevo reranker) debe pasar por la suite de evaluación antes de desplegarse. Es la misma filosofía de CI/CD que aplicamos en el Autopilot Parte 5 con GitHub Actions, pero aplicada a la calidad del retrieval.

Antipatrón 7: Usar RAG Cuando Necesitas Tool Calling

Este es el antipatrón que más me costó aceptar, porque implicaba cuestionar una decisión arquitectónica propia. Cuando construimos el radar agéntico de obsolescencia, la primera tentación fue usar RAG: indexar toda la documentación de componentes, las hojas de datos y los históricos de precios en un vector store, y dejar que el LLM buscara la información relevante ante cada alerta de End of Life.

El resultado fue desastroso. Los LLMs son, como escribí en aquel artículo, calculadoras mediocres. Cuando el radar necesitaba calcular el impacto financiero de una obsolescencia (cruzar el grafo BOM, multiplicar cantidades por precios, sumar costes de rediseño), RAG devolvía aproximaciones narrativas donde necesitábamos cifras exactas. La precisión financiera era inaceptable para un informe ejecutivo.

La solución fue separar radicalmente el “cerebro” semántico del “músculo” matemático: el LLM (Gemini 2.5 + CrewAI) se encarga de la comprensión del lenguaje natural (extraer el Part Number de un email de proveedor, entender el contexto de una alerta), y las herramientas Python (@tool de CrewAI) se encargan de las operaciones de precisión (consultas SQL a Supabase, cálculos de P&L, cruce de grafos relacionales). El resultado: reportes ejecutivos generados en 4 segundos con 0% de alucinación en los datos numéricos.

RAG vs Tool Calling: cuándo usar cada uno

La regla que he destilado es sencilla:

Necesitas… Usa… Por qué
Respuestas sobre conocimiento no estructurado (manuales, posts, documentación narrativa) RAG El retrieval semántico es superior para buscar en texto libre
Respuestas con datos estructurados y precisión numérica (SQL, APIs, cálculos financieros) Tool Calling Las herramientas ejecutan código determinista, sin alucinaciones
Ambos (interpretar un email + calcular impacto financiero) Arquitectura híbrida El LLM orquesta; las herramientas ejecutan

Y si te preguntas cómo estandarizar esas conexiones entre el LLM y las herramientas para no quedar atado a un proveedor, eso es exactamente lo que abordamos en el artículo sobre MCP (Model Context Protocol).

Conclusión: RAG No Está Roto; Tu Implementación Sí

Si hay un mensaje que quiero que te lleves de este artículo es este: RAG es una arquitectura legítima y poderosa cuando se implementa con rigor ingenieril. El problema no es el patrón; el problema es que la industria lo ha popularizado como una solución mágica plug-and-play, cuando en realidad es un pipeline complejo que requiere chunking inteligente, embeddings evaluados, reranking, contexto generoso, defensas contra alucinaciones, métricas de calidad, y la humildad de reconocer cuándo Tool Calling es la herramienta correcta.

La Regla del 10x que propuse en el artículo sobre la Economía Oculta de la IA aplica perfectamente aquí: si RAG no te da un resultado 10 veces mejor que una búsqueda SQL directa o una llamada a una API, probablemente estás usando la herramienta equivocada para el problema equivocado.

Y en la era del EU AI Act, donde la trazabilidad (Artículo 12) y la precisión son obligaciones legales para sistemas de alto riesgo, implementar un RAG que alucina no es solo un error técnico: es un riesgo regulatorio.

Fuentes de Interés: