Retrieval-Augmented Generation se ha convertido en la arquitectura por defecto para sistemas de búsqueda y conocimiento empresarial. El concepto es elegante: en lugar de esperar que el modelo sepa la respuesta, recuperas documentos relevantes y dejas que el modelo sintetice una respuesta de fuentes reales. En la práctica, la brecha entre una demo que funciona y un sistema de producción confiable es donde la mayoría de los proyectos fallan.
Después de construir sistemas RAG en múltiples industrias y tipos de documentos, vemos los mismos cinco problemas repetidamente. Ninguno de ellos es sobre el modelo de lenguaje.
1. El problema del chunking
Cuando divides documentos en piezas para embedding y recuperación, cada elección crea compromisos. Los chunks de tamaño fijo (dividir cada 500 tokens) son fáciles de implementar pero terribles para documentos estructurados—dividirán un procedimiento por la mitad, separarán una regla de sus excepciones y cortarán tablas en fragmentos sin sentido.
El daño se muestra en tiempo de consulta. Un usuario pregunta “¿cuál es la política de devolución para pedidos internacionales?” y el recuperador devuelve un chunk que contiene la política de devolución doméstica (porque mencionó “política de devolución”) mientras que las excepciones internacionales viven en el siguiente chunk que no fue recuperado.
Qué hacer en su lugar: Ajusta tu estrategia de chunking a la estructura de tu documento. Para documentos de políticas, divide en límites de sección. Para manuales técnicos, mantén los procedimientos como unidades atómicas. Para contenido conversacional como emails o tickets, divide por mensaje o hilo. Prueba la calidad de recuperación con consultas representativas antes de comprometerte con una estrategia, y espera iterar. No hay un enfoque universal de chunking que funcione para todos los tipos de contenido.
2. El problema del índice obsoleto
Tus documentos cambian. Las políticas se actualizan. Los productos se modifican. Los procedimientos se revisan. Pero si tu índice de embeddings no refleja esos cambios prontamente, tu sistema de búsqueda está devolviendo con confianza información desactualizada—que en muchos casos es peor que no devolver nada.
Hemos visto organizaciones construir impresionantes sistemas RAG, lanzarlos, y luego darse cuenta tres meses después de que el índice no se ha actualizado desde el día de lanzamiento porque nadie construyó el pipeline de actualización. La carga inicial fue un trabajo batch que alguien ejecutó manualmente, y las actualizaciones incrementales estaban “planificadas para la fase dos.”
Qué hacer en su lugar: Construye el pipeline de actualización antes de construir la interfaz de búsqueda. Trata la frescura del índice como un requisito central, no como una característica de seguimiento. Implementa detección de cambios en tus fuentes de documentos, reprocesamiento incremental para documentos modificados, y monitoreo que te alerte cuando el índice se quede atrás. Define una ventana de obsolescencia aceptable (¿horas? ¿días?) basada en tu contenido y imponla.
3. La brecha de relevancia
La búsqueda de similitud vectorial encuentra documentos que están semánticamente relacionados con la consulta. Eso no siempre es lo mismo que encontrar documentos que responden la consulta. Una pregunta sobre “procedimientos de terminación de empleados” coincidirá con documentos sobre incorporación (ambos discuten el ciclo de vida laboral), revisiones de desempeño (menciona terminación como resultado), y la política de terminación real. La similitud semántica sola no puede distinguir de manera confiable lo más relevante de lo meramente relacionado.
Este problema empeora con colecciones grandes de documentos. Cuando tienes miles de documentos, incluso un modelo de embedding bien ajustado devolverá resultados donde varios son tópicamente adyacentes pero no realmente útiles para la pregunta específica.
Qué hacer en su lugar: No confíes solo en la búsqueda vectorial. La recuperación híbrida—combinando búsqueda semántica con coincidencia de palabras clave y filtrado de metadatos—supera consistentemente a la búsqueda vectorial pura en entornos empresariales. Si un usuario pregunta sobre “política MA-2024-031,” la coincidencia de palabras clave la encuentra instantáneamente mientras que la búsqueda vectorial podría clasificarla debajo de documentos semánticamente similares pero incorrectos. Agrega filtros de metadatos (tipo de documento, departamento, rango de fechas) para reducir resultados antes de clasificar. Y construye un conjunto de evaluación de recuperación—una colección de consultas con documentos relevantes conocidos—para que puedas medir y optimizar la relevancia sistemáticamente.
4. La trampa de la ventana de contexto
Los modelos de lenguaje modernos tienen ventanas de contexto grandes—100K tokens o más. Es tentador resolver problemas de recuperación metiendo más documentos en el contexto: “si no estamos seguros de qué documento es relevante, incluye todos y deja que el modelo lo resuelva.”
Este enfoque degrada la calidad de respuesta de maneras sutiles. La investigación muestra consistentemente que los modelos se desempeñan peor con información en el medio de contextos largos comparado con el principio y el final. Más contexto también significa más oportunidades para que el modelo se distraiga con información tangencialmente relacionada. Y prácticamente, más tokens significa mayor latencia y costo.
Qué hacer en su lugar: Trata la recuperación como un problema de precisión, no de recall. Es mejor darle al modelo tres pasajes altamente relevantes que treinta algo relevantes. Invierte en calidad de recuperación—mejor chunking, mejor clasificación, mejor filtrado—en lugar de compensar la recuperación pobre con contexto de fuerza bruta. Si regularmente estás llenando la ventana de contexto porque no puedes encontrar confiablemente los documentos correctos, ese es un problema de recuperación a resolver, no una ventana de contexto a llenar.
5. La brecha de evaluación
Este podría ser el problema más dañino porque habilita todos los demás. Sin evaluación sistemática, no sabes qué tan bien está funcionando tu sistema RAG. Confías en retroalimentación anecdótica (“parece bastante bueno”), quejas ocasionales de usuarios, y sensaciones.
El problema es que los fallos de RAG son a menudo silenciosos. El sistema devuelve una respuesta confiada y bien escrita que casualmente proviene de un documento desactualizado, o que es técnicamente precisa pero no aborda lo que el usuario realmente necesitaba. Los usuarios que obtienen respuestas incorrectas pueden no reportarlas—pueden ni siquiera darse cuenta de que la respuesta estaba mal hasta que causa un problema posterior.
Qué hacer en su lugar: Construye evaluación en el sistema desde el día uno. Esto significa:
- Evaluación de recuperación. Para un conjunto de consultas de prueba, ¿se están recuperando los documentos correctos? Mide precisión y recall en tu profundidad de recuperación típica (top 3, top 5, lo que sea que pases al modelo).
- Evaluación de respuesta. Para consultas con respuestas conocidas, ¿produce el sistema respuestas correctas y bien fundamentadas? Esto requiere cierta revisión humana, pero puedes construir un proceso de muestreo escalable.
- Monitoreo de frescura. ¿Los documentos que se están devolviendo son actuales? Rastrea la edad de documentos recuperados en relación con la última versión disponible.
- Ciclos de retroalimentación de usuarios. Facilita a los usuarios marcar respuestas malas. Rastrea estas señales y úsalas para identificar problemas sistemáticos.
Ejecuta esta suite de evaluación regularmente—no solo en el lanzamiento, sino semanalmente o después de cualquier cambio de pipeline. Las regresiones de calidad suceden gradualmente y son fáciles de perder sin medición.
El hilo común
Los cinco de estos problemas comparten una causa raíz: tratar RAG como un problema de modelo cuando en realidad es un problema de ingeniería de datos. El modelo es la parte fácil. Las partes difíciles son procesamiento de documentos, chunking, indexación, frescura, calidad de recuperación y evaluación—todas preocupaciones de pipeline de datos.
Las organizaciones que tienen éxito con RAG empresarial son las que invierten en estas capacidades fundamentales en lugar de perseguir la última actualización de modelo. Un pipeline de recuperación bien construido con un modelo suficientemente bueno superará a un modelo de última generación sentado encima de un pipeline pobre, cada vez.
Si estás planeando una implementación RAG o luchando con una que no está cumpliendo expectativas, comienza con estas cinco áreas. Las soluciones rara vez son glamorosas, pero son donde viven las mejoras reales de calidad.
