RAG para base de conocimiento: qué sobrevive a producción

Toda empresa que experimenta con IA generativa llega rápido a la misma idea: conectar el modelo a la base de conocimiento interna. La técnica tiene nombre, RAG, y la arquitectura básica es simple. Lo que no es simple es hacerla sobrevivir a datos reales, permisos reales y usuarios reales.

El problema casi nunca es el modelo

RAG se formalizó en 2020 combinando dos memorias: la paramétrica, que está en los pesos del modelo, y la no paramétrica, que es un índice recuperable al momento de la pregunta. La promesa es buena: actualizas el índice sin reentrenar nada.

Cuando un RAG corporativo responde mal, la causa casi siempre está en la recuperación, no en la generación. Si el fragmento correcto no llegó al contexto, ningún modelo salva la respuesta. Por eso la primera métrica a instrumentar no es la calidad de la respuesta, es si el documento correcto entró en el top-k.

El chunking es decisión de producto, no de infraestructura

Dividir documentos en fragmentos parece un detalle técnico y es donde la mayoría de los proyectos pierde calidad. Un fragmento demasiado grande arrastra ruido; demasiado pequeño corta la frase que le daba sentido al número.

El agravante en la empresa es que un fragmento aislado suele perder su referente. "La tasa pasa a ser de 2,5%" no dice de qué producto, desde cuándo, ni bajo qué contrato. Recuperado solo, se vuelve una respuesta equivocada con cara de correcta.

La mitigación que funciona es enriquecer cada fragmento con el contexto de su documento de origen antes de generar el embedding. Experimentos publicados por Anthropic muestran que esa contextualización reduce de forma relevante la tasa de fallo en la recuperación, y mejora aún más combinada con búsqueda léxica y reranking.

Más contexto no es la solución que parece

La reacción natural ante una mala respuesta es subir el top-k y empujar más texto al modelo. Hay un límite claro para eso.

El estudio Lost in the Middle mostró que el desempeño del modelo depende de dónde está la información relevante dentro del contexto. El acierto es mayor cuando aparece al principio o al final, y cae visiblemente cuando queda en el medio. La curva tiene forma de U.

La consecuencia práctica es directa: llenar la ventana de contexto puede empeorar la respuesta incluso cuando el fragmento correcto está ahí dentro. Ordenar bien unos pocos fragmentos correctos vale más que enviar muchos.

Búsqueda híbrida y reranking

La búsqueda vectorial sola falla en dos casos comunes en la empresa: códigos de producto y términos exactos de contrato. El embedding captura similitud semántica, no igualdad literal, así que "error 4021" y "error 4012" quedan peligrosamente cerca.

La combinación que lo resuelve es híbrida: búsqueda densa para el significado, búsqueda léxica para el término exacto, y un reranker encima para ordenar el conjunto final. Es más infraestructura, y es la diferencia entre demo y producción.

Medir sin depender de una clave de respuestas manual

Evaluar RAG parece exigir una respuesta escrita a mano para cada pregunta, lo que no escala. Frameworks como RAGAS existen para bajar ese costo, descomponiendo la evaluación en dimensiones medibles por separado, entre ellas si la respuesta está realmente apoyada en los fragmentos recuperados y si esos fragmentos eran relevantes para la pregunta.

Separar esas dos dimensiones es lo que da diagnóstico. Una respuesta infiel con buen contexto es problema de generación. Un contexto irrelevante es problema de recuperación, y ningún ajuste de prompt lo arregla.

Qué se rompe específicamente en la empresa

Tres cosas, ninguna sobre el modelo:

• Permisos. El índice no puede devolver a alguien un fragmento de un documento que esa persona no podría abrir. El filtro de permisos tiene que ocurrir en la recuperación, no después, sobre la respuesta.
• Frescura. Un documento revocado que sigue en el índice genera una respuesta confiada y equivocada. La reindexación tiene que ser parte del ciclo de vida del documento.
• Procedencia. Una respuesta sin enlace a su fuente no es auditable y no gana la confianza de legal ni de compliance.

Qué significa esto para tu equipo

Empieza por un conjunto de documentos pequeño y bien delimitado, con dueño claro. Instrumenta recuperación y generación por separado desde el primer día. Arma un conjunto de treinta a cincuenta preguntas reales, recogidas con las personas que lo van a usar, y úsalo como regla de regresión ante cada cambio de chunking, embedding o prompt.

Y resuelve los permisos en la arquitectura antes de mostrar la demo a la dirección. Encajar control de acceso en un índice ya construido es uno de los refactores más caros de este tipo de proyecto.