Los 7 errores que matan la precisión de tu RAG
29 may 2026
Los 7 errores que matan la precisión de tu RAG
Tu chatbot responde con confianza, pero entrega información incorrecta. El cliente se frustra. Tú te rascas la cabeza. Probablemente no es un problema del modelo de lenguaje, sino de cómo está alimentándose de información. Un estudio reciente de CMARIX revela que el 54% de las implementaciones de RAG fallan en precisión, y la mayoría de esos fracasos vienen de decisiones técnicas simples que nadie suele cuestionar en la arquitectura inicial. Aquí están los siete errores más comunes que sabotean tu sistema.
Error 1: Chunks demasiado grandes o demasiado pequeños
El chunking es donde todo comienza. Parece trivial, pero es donde muchos pierden la partida.
Si fragmentas documentos en pedazos mayores a 1500 tokens, estás obligando al modelo a procesar demasiado ruido. Imagina que tu KB tiene una sección sobre políticas de devolución, pero el chunk incluye también historiales de envíos, términos legales y opciones de contacto. El embedding no sabe qué priorizar, y la búsqueda vectorial devuelve resultados imprecisos.
Al revés, chunks más pequeños que 200 tokens pierden contexto crítico. Una pregunta sobre "cómo cambiar mi suscripción" necesita saber si el usuario está en un plan anual o mensual, o si ya realizó cambios antes. Fragmentos microscópicos no conectan esa información.
La solución: mantente entre 400 y 1200 tokens por chunk, con solapamiento (overlap) del 20%. Prueba en tu dominio específico. Un chunk de 800 tokens para docs técnicos puede ser perfecto; para FAQs podría ser demasiado.
Error 2: Embeddings elegidos sin criterio
No todos los embeddings son iguales. Usarlos sin estrategia es como comprar cualquier cable USB sin revisar si es compatible.
Si tu caso es un FAQ simple, Voyage-3-Lite (512 dimensiones) funciona bien: menos tokens procesados, latencia baja. Pero si tienes documentación técnica complicada o bases de conocimiento con relaciones semánticas densas, necesitas Voyage-3 (1024 dimensiones) para capturar esa complejidad. El modelo más grande tiene 49 puntos de referencia adicionales para entender matices.
También importa el entrenamiento del modelo: algunos embeddings están optimizados para e-commerce, otros para soporte legal. Un embedding entrenado en textos generales puede no captar la terminología específica de tu industria. Si trabajas en fintech, probablemente necesites embeddings más especializados.
El error aquí es usar embeddings sin probar primero. Toma una muestra de 50 queries de tus usuarios reales y mide el recall con diferentes opciones. Te sorprenderá la diferencia.
Error 3: Similarity threshold arbitrario
El threshold de similitud es tu control de calidad. Tocarlo sin cuidado sabotea todo.
Fijar un threshold bajo (<0.3) abre las compuertas al ruido: responderas preguntas sobre mascotas cuando el usuario pregunta sobre máquinas. Establecerlo alto (>0.5) es paranoia. El modelo se queda sin contexto valioso y dice "no sé" cuando claramente debería tener una respuesta.
La realidad es que no hay un número mágico. Depende de tu embedding model, tu dominio y tu tolerancia al riesgo. Un banco no puede permitirse falsos positivos. Un chatbot de e-commerce sí puede ser más permisivo.
Calibra empíricamente: toma queries reales, ordena los resultados por similitud y grafica dónde comienzan a aparecer respuestas no relevantes. Ese es tu threshold.
Error 4: K (cantidad de documentos recuperados) mal configurado
K es simple pero letal si lo ignoras.
K muy bajo (K=2) te deja fuera hallazgos relevantes alternativos. La pregunta sobre "integración de pago" podría tener 5 documentos válidos, pero K=2 te trae solo los dos primeros y posiblemente la respuesta es mejor con el tercero.
K muy alto (K=20) confunde al modelo: tiene contexto contradictorio, documentos marginalmente relevantes y ruido. El LLM gasta tokens en procesar información irrelevante en lugar de ir directo a lo que necesita.
Según research en benchmarking de RAG, K entre 5 y 10 es el rango óptimo para la mayoría de casos. Por supuesto, mide en tu propia base de datos. Empieza con K=5, prueba precisión y recall, y ajusta desde ahí.
Error 5: No filtrar por tenant en arquitecturas multi-tenant
Este no es un error técnico, es un riesgo de seguridad que parece invisible hasta que explota.
Si ejecutas un chatbot SaaS para múltiples clientes y no filtras documentos por business_id antes de embedear, estás creando puentes entre tenants. El cliente A podría recibir respuestas basadas en la KB del cliente B. Datos sensibles, números, políticas internas: todo mezclado.
El fix es obligatorio: implementa filtrado de metadatos en la etapa de recuperación, antes de calcular similitud. Cada búsqueda debe tener un WHERE implícito que aisle el tenant.
Error 6: Ignorar el ranking final (re-ranking)
La mayoría de implementaciones usan similitud de coseno y se detienen.
Eso es desperdiciar potencial. Después de recuperar tus K documentos, puedes aplicar un re-ranking más sofisticado: un modelo cross-encoder que entienda la relevancia bidireccional entre query y documento, no solo similitud vectorial.
La mejora no es cosmética. Implementar API verification para validar respuestas mejora la precisión un 19%. Agregar self-consistency checking aporta otro 65% de mejora adicional.
Error 7: No monitorear degradación continua
Tu RAG no es estático. Conforme crece tu KB, cambian los usuarios y tus embeddings envejecen.
Sin monitoreo, no sabrás cuándo la precisión se derrumba hasta que los clientes se quejen. Establece alertas: si más del 15% de queries devuelven similarity < 0.4, investigá. Si el feedback de usuarios sobre "respuesta irrelevante" sube, re-entrena embeddings o ajusta chunks.
El resumen es acción, no teoría
Estos siete errores tienen algo en común: no son culpa del modelo de lenguaje. Son decisiones de arquitectura que necesitan ajuste empírico. Toma un viernes, haz un audit de tu sistema actual contra estos puntos, y prueba cambios pequeños. Los resultados hablan solos.