Cuando los equipos de tecnología presentan una propuesta de RAG para documentos empresariales, la diapositiva de arquitectura casi siempre tiene el mismo componente al centro: embeddings + similitud de coseno. El argumento es intuitivo: se convierten textos en vectores, se calcula qué tan "cerca" están, y se devuelven los fragmentos más similares a la pregunta del usuario.
El problema no es que el coseno sea incorrecto. El problema es que se convirtió en el punto de partida por defecto cuando debería ser, en el mejor caso, una herramienta entre varias —y en muchos contextos empresariales, no la más importante.
En los artículos anteriores de esta serie abordamos el análisis de preguntas (Vol.1 #6ter) y la detección de anclas estructurales (Vol.1 #7B). Hoy llegamos al ladrillo de recuperación propiamente dicho. Hay seis posiciones que contradicen el reflejo coseno-primero que domina el debate mainstream.
Los modelos de embeddings son extraordinarios para capturar semántica. Pero los documentos empresariales —contratos, especificaciones técnicas, manuales de producto, resoluciones regulatorias— están llenos de términos exactos que el coseno puede suavizar hasta perder.
Un número de contrato, un código arancelario, una cláusula específica ("INCOTERM DAP México"), un identificador de producto: BM25 los encuentra con precisión quirúrgica. El embedding puede devolver fragmentos "semánticamente cercanos" que no mencionan ese término en ningún lugar.
La regla práctica: si la consulta contiene términos de alta especificidad —nombres propios, códigos, fechas, referencias numéricas— el retrieval debe comenzar o ponderarse con fuerza hacia métodos dispersos (sparse retrieval). El coseno no es la herramienta correcta para buscar el número de factura 2024-COL-00847.
Antes de calcular una sola similitud, el sistema debería reducir el espacio de búsqueda usando metadatos estructurales. En un repositorio con miles de documentos, buscar en todo el corpus cada vez es costoso e impreciso.
Si el usuario pregunta sobre el contrato con una distribuidora firmado en 2024, los filtros de empresa, año y tipo de documento deberían dejar el corpus de búsqueda en decenas de fragmentos, no en miles. Lo que el coseno evalúa después es más pequeño y más relevante.
Este paso se omite constantemente en implementaciones RAG genéricas porque requiere que los documentos estén estructurados y etiquetados desde la ingesta. Es trabajo previo. Sin él, la búsqueda vectorial navega un océano cuando debería buscar en un estanque.
El coseno no puede recuperar información que no existe en los fragmentos. Si el documento está mal dividido —chunks demasiado cortos que pierden contexto, demasiado largos que diluyen la señal relevante, o cortados en medio de una tabla o una cláusula— ninguna función de similitud lo rescata.
La granularidad del chunking debe adaptarse al tipo de documento: una póliza de seguro requiere una estrategia diferente a un informe financiero o a un manual técnico de manufactura. El chunking no es un paso de preprocesamiento neutro; es una decisión de arquitectura con impacto directo en la precisión.
Invertir en la estrategia de segmentación tiene mayor retorno que optimizar el modelo de embeddings o la función de distancia. Ese orden de prioridad es el que suele invertirse en los proyectos que no funcionan en producción.
La combinación de búsqueda dispersa (BM25 o similar) y búsqueda densa (coseno sobre embeddings), fusionada mediante técnicas como Reciprocal Rank Fusion (RRF), produce mejores resultados que cualquiera de los dos métodos por separado en prácticamente todos los benchmarks sobre documentos de dominio específico.
El retrieval híbrido no es una complejidad técnica opcional: es la arquitectura base recomendada cuando el corpus tiene vocabulario técnico especializado —que es exactamente el caso en finanzas, logística, legal, manufactura y salud, los dominios donde el RAG empresarial genera valor real.
Implementar retrieval híbrido tiene un costo de infraestructura mayor que el coseno puro, pero la diferencia en precisión justifica esa inversión cuando un resultado equivocado tiene consecuencias operativas reales.
El retrieval de primera etapa —sea coseno, BM25 o híbrido— cumple una función de candidatos. Devuelve los N fragmentos más probables. Pero la selección final de qué pasa al LLM no debería basarse en ese ranking inicial.
Los rerankers de segunda etapa (cross-encoders) evalúan la relevancia de cada fragmento candidato en relación con la consulta con mucha más profundidad que una función de similitud vectorial. El tiempo de cómputo adicional se aplica sobre un conjunto pequeño de candidatos, pero el salto en calidad es consistentemente significativo.
Equipos que despliegan RAG en producción y se preguntan por qué los resultados son irregulares suelen estar omitiendo este paso. El reranker no es un lujo de arquitecturas avanzadas: es el mecanismo de control de calidad del retrieval.
Una consulta bien reformulada —expandida con sinónimos del dominio, descompuesta en sub-preguntas cuando es compleja, enriquecida con el contexto del usuario— mejora los resultados de recuperación más que cambiar de coseno a otro método de similitud.
Si el ladrillo de análisis de preguntas entrega al retrieval una consulta estructurada y enriquecida, incluso un índice BM25 básico puede superar a un sistema de embeddings de última generación alimentado con la pregunta cruda del usuario.
Este es el argumento más contraintuitivo para los equipos de ingeniería: la inversión en el preprocesamiento de la consulta tiene mayor retorno marginal que la inversión en la función de similitud. El ladrillo de retrieval no funciona en aislamiento.
Si su empresa está evaluando o ya desplegando sistemas de inteligencia documental —consulta de contratos, extracción de condiciones comerciales, navegación de manuales técnicos, auditoría de documentos regulatorios— hay una pregunta concreta que hacer a su equipo técnico:
¿Cuál es su estrategia de retrieval más allá del coseno?
Si la respuesta es "usamos embeddings y similitud vectorial", la conversación no ha empezado. El coseno es el punto de entrada, no la arquitectura.
Los sistemas que entregan precisión consistente en producción combinan filtros estructurales, retrieval híbrido, estrategia de chunking adaptada al tipo de documento y reranking antes de pasar al LLM. Cada uno de esos componentes es una decisión de diseño, no una configuración automática que se activa sola.
La diferencia entre un sistema RAG que impresiona en una demo y uno que funciona en operaciones diarias es, en gran medida, la sofisticación de esta capa de recuperación. Y esa sofisticación no viene del modelo de embeddings: viene de las decisiones de arquitectura que lo rodean.
En Xenturia diseñamos sistemas de inteligencia documental con arquitecturas de retrieval adaptadas al corpus y al caso de uso. Si está evaluando cómo llevar esto a producción en su organización, es una conversación que vale la pena tener antes de empezar a construir.
Agenda una consulta gratuita con nuestro equipo y descubre cómo la IA puede transformar tus operaciones.
Agenda una consulta
IA EstratégicaAIEl punto ciego del RAG empresarial no está en el modelo ni en el índice. Está en lo que le pasa a la pregunta del usuario antes de llegar a la búsqueda.
IA EstratégicaAIDel piloto a la operación real hay un abismo técnico y financiero. Lo que todo líder debe entender antes de escalar IA en su empresa.
IA EstratégicaAINo elija entre privacidad y capacidad. Con Gemma 4 local y GPT-5.4 en la nube, su empresa puede tener ambas: un flujo híbrido práctico para operaciones reales.
