Cuando la similitud no es relevante: construyendo RAG empresarial más allá de la búsqueda vectorial.

La búsqueda vectorial es excepcionalmente buena para mostrar texto que se asemeja a una pregunta. Sin embargo, la similitud y la utilidad son cosas distintas, y es en la brecha entre ellas donde el RAG empresarial tiende a fallar.

Un documento recuperado puede compartir el vocabulario del usuario y, aun así, estar desactualizado, fuera de alcance, incompleto o irrelevante para la situación empresarial actual. Mientras tanto, el documento que realmente resolvería la pregunta podría estar redactado de manera diferente y obtener una puntuación más baja. El problema suele no radicar en el modelo de embedding ni en la base de datos vectorial, sino en la creencia de que la similitud semántica equivale a una definición completa de relevancia, lo cual no es cierto.

En una empresa, la relevancia depende de mucho más que de la redacción. La recencia, la autoridad, la geografía, el tipo de documento, los permisos del usuario, el estado del flujo de trabajo, los vínculos contractuales y las conexiones entre entidades empresariales también influyen. Un sistema fiable debe sopesar todos esos factores juntos y no considerar la proximidad en el espacio vectorial como el veredicto final.

Cómo la búsqueda vectorial se convirtió en la opción por defecto

La búsqueda por palabras clave se basa en gran medida en términos exactos. Quien busque “política de salida de empleados” podría pasar por alto un archivo titulado “Procedimiento de cese de empleados”, ya que no comparten ninguna palabra.

La búsqueda vectorial fue la solución a esa debilidad. Los documentos se convierten en embeddings, representaciones numéricas de su significado, y la pregunta del usuario se transforma en un vector del mismo tipo. El sistema luego devuelve los fragmentos cuyos vectores están más cerca de los del consulta. Se puede encontrar material conceptualmente relacionado incluso cuando la pregunta y el texto original utilizan palabras diferentes.

Eso hace que la recuperación vectorial sea adecuada para diversas tareas: manejar preguntas en lenguaje natural, encontrar sinónimos y paráfrasis, buscar documentos no estructurados, soportar consultas conversacionales o multilingües, y reducir una gran colección a una lista corta de candidatos.

Esas ventajas situaron a las bases de datos vectoriales en el centro de los primeros diseños de RAG, y el flujo estándar parecía ordenado. Los documentos se dividían en fragmentos, cada fragmento recibía una representación vectorial y estas se almacenaban. Al momento de hacer una consulta, se representaba vectorialmente la pregunta, se recuperaban los fragmentos más cercanos y se los pasaba a un modelo de lenguaje, el cual escribía la respuesta.

Las demostraciones y las pequeñas bases de conocimiento funcionan bien con este enfoque. Sin embargo, en entornos empresariales comienza a surgir estrés.

La similitud es una de las señales entre varias

Imagínese a un gerente de compras escribiendo: “¿Qué condiciones de pago son aplicables según nuestro acuerdo actual con Northstar Components?”

Un sistema basado únicamente en vectores podría incluir un contrato actual con un proveedor, un contrato vencido con el mismo proveedor, una plantilla con las condiciones de pago estándar, un correo electrónico sobre un cambio propuesto, una política de adquisiciones que menciona los pagos a proveedores, y un contrato para alguna otra subsidiaria de Northstar.

Cada uno de estos elementos está semánticamente relacionado con la pregunta, pero quizás solo uno o dos son relevantes desde el punto de vista operativo. Elegir correctamente implica responder a preguntas adicionales: ¿A qué entidad legal se refiere “nuestro”? ¿Qué empresa de Northstar está involucrada? ¿El acuerdo sigue en vigor y las enmiendas han modificado los términos originales? ¿Qué jurisdicción lo rige? ¿Este usuario tiene permiso para verlo? ¿Existe una versión firmada y cuál fuente tiene más autoridad?

Un embedding no tiene una comprensión inherente de tales restricciones. Mide la cercanía en un espacio semántico aprendido. No puede determinar qué documento es legalmente vinculante o operativamente válido.

Así es como una alta puntuación de similitud genera una falsa confianza. El sistema obtiene texto plausible, el modelo de lenguaje lo convierte en una respuesta pulida, y la prosa fluida oculta el error en la recuperación.

Siete maneras en que la similitud pura falla

Varios patrones de fallo recurrentes hacen que la recuperación basada únicamente en vectores sea arriesgada.

Material desactualizado. Los documentos antiguos a menudo se parecen a los actuales. Una póliza vencida puede ser similar a su sustituta, salvo por un único umbral, fecha o regla de aprobación. Debido a la gran similitud en la redacción, ambas obtienen una alta calificación. Sin controles de versión y fecha de vigencia, el sistema puede terminar proporcionando orientaciones obsoletas, lo cual es especialmente peligroso en trabajos regulados, donde un pequeño cambio en la póliza puede alterar el cumplimiento, la elaboración de informes o la forma en que se trata a los clientes.

Ceguera ante la autoridad. Una nota de lluvia de ideas, un correo interno y una política aprobada pueden tratar el mismo tema, y la versión informal puede tener prioridad simplemente porque su redacción se parece a la pregunta. El conocimiento empresarial no es una democracia. En general, un contrato firmado debe prevalecer sobre un borrador, un procedimiento aprobado sobre las actas de una reunión, y una solicitud regulatoria validada sobre las notas de un analista. La relevancia requiere una jerarquía de pruebas.

Relaciones separadas por la división en fragmentos. Para mejorar la precisión y adaptarse a las ventanas de contexto, los sistemas RAG dividen los documentos en partes pequeñas, lo que puede separar los hechos de las relaciones que les dan significado. Un fragmento puede definir una obligación de pago, otro puede indicar el nombre del proveedor, y un tercero puede contener una enmienda que anula la cláusula original. Cada fragmento es incompleto por sí solo, y obtener el pasaje más similar no garantiza que se reconstruya la imagen completa.

Problemas con identificadores exactos. Las representaciones embedding están optimizadas para el significado y a menudo representan mal las cadenas literales. Los números de pieza, números de cuenta, referencias a cláusulas, códigos de medicamentos, identificadores de equipos y números de versión son víctimas habituales. Una búsqueda de “Modelo AX-1047” no debería devolver “AX-1041” solo porque las descripciones asociadas se parecen entre sí. La recuperación de información en entornos empresariales suele requerir precisión literal junto con la semántica.

Restricciones negativas. Con frecuencia la gente pregunta por lo que está ausente: qué clientes aún no han completado la verificación, qué dispositivos quedan fuera del acuerdo de mantenimiento actual, qué facturas siguen sin pagar después de 60 días, qué sitios de prueba no han presentado la documentación requerida. Estas preguntas se basan en la ausencia, exclusión o comparación entre registros. La búsqueda por similitud obtiene texto relacionado con el concepto, pero no puede determinar con fiabilidad qué es lo que falta.

Falta de concepto de estado del negocio. Un objeto empresarial pasa por estados como borrador, enviado, aprobado, suspendido, vencido y archivado. Dos documentos sobre el mismo objeto pueden ser prácticamente idénticos aunque se encuentren en estados diferentes, y el estado actual puede determinar si un documento es relevante o no.

La autorización por sí sola no es suficiente. El documento más semánticamente relevante podría ser aquel al que al usuario no se le permite acceder. El control de acceso no puede limitarse a una simple instrucción en un comando. El contenido restringido debe eliminarse antes de que llegue al contexto del modelo, ya que de lo contrario el sistema corre el riesgo de divulgar detalles sensibles directamente o permitir que el modelo los infiera de forma indirecta.

La relevancia tiene muchas dimensiones

En los sistemas RAG empresariales, la relevancia se entiende mejor como una combinación de indicadores: similitud semántica, relevancia por palabras clave o coincidencia exacta, autoridad de la fuente, validez temporal, alineación con las reglas empresariales, elegibilidad para acceder y relevancia basada en relaciones o grafos. Una fórmula de clasificación podría sumar todos estos indicadores, asignando a cada uno su propio peso.

Los pesos dependen del caso de uso. Un asistente de investigación interno podría darle un peso elevado a la similitud semántica. Una herramienta de respuesta a preguntas basada en contratos podría dar más importancia a las fechas de vigencia y a la autoridad de la fuente. Una plataforma de investigación podría verse dominada por las relaciones entre personas, eventos, ubicaciones y activos.

Nada de esto implica que toda organización necesite un modelo matemático complejo de clasificación. Significa que la relevancia debe definirse de manera deliberada y no heredarse del puntaje predeterminado de una base de datos vectorial.

Así es una arquitectura de recuperación más sólida

Un RAG fiable suele pasar por varias etapas de recuperación y validación.

1. Comprender la consulta

Antes de realizar la búsqueda, el sistema determina qué se está solicitando. Eso puede significar extraer la intención y cualquier entidad nombrada, rangos de tiempo, tipos de documentos, jurisdicciones, identificadores de clientes o productos, unidades de negocio y el nivel de autoridad requerido, y luego decidir si la pregunta necesita una búsqueda, cálculo, comparación o recorrido por un grafo.

Tomemos como ejemplo “¿Qué cambió en nuestra política de retención de datos en Europa este año?”. Esto no debería tratarse como una búsqueda semántica genérica. Implica una región, una categoría de documento, un intervalo de tiempo y una comparación de versiones. La comprensión de consultas convierte una oración informal en un plan estructurado de recuperación de información.

2. Filtrado de metadatos

Los metadatos reducen el espacio de búsqueda antes o durante su recuperación. Los campos que resultan útiles incluyen la región, el propietario, la unidad de negocio, las fechas en que un documento entra en vigor y vence, su estado de aprobación y versión, el tipo de documento, la clasificación de datos, la familia de productos, los IDs de clientes o proveedores y los atributos utilizados para el control de acceso.

La aplicación de filtros impide que los candidatos claramente inelegibles compitan con los elegibles. También convierte la calidad de los metadatos en un componente de la calidad de RAG: cuando los documentos se ingieren sin fechas fiables, propietarios, estado de versión o etiquetas de acceso, la recuperación sigue siendo frágil, independientemente del modelo de incrustación utilizado.

3. Recuperación híbrida

La recuperación híbrida combina la búsqueda semántica con la búsqueda léxica. Los vectores se ocupan del significado y las paráfrasis, mientras que los métodos léxicos como BM25 se enfocan en la terminología exacta, los identificadores y los términos poco comunes. Un sistema híbrido puede comprender que “procedimiento de finalización” está relacionado con “política de cese de empleo” y, aun así, insistir en una coincidencia exacta para “HR-OPS-204.”

Los resultados pueden fusionarse mediante la fusión de rangos recíprocos o una función de puntuación específica para el dominio. Para muchas empresas, esta es una de las actualizaciones más prácticas para un proceso basado únicamente en vectores.

4. Recuperación de datos estructurados

Los fragmentos de documentos no son la fuente adecuada para algunas preguntas. Cualquier información relacionada con conteos, totales, umbrales, estados o comparaciones suele encajar mejor con consultas SQL, índices de búsqueda, APIs, almacenes de datos, bases de conocimiento, sistemas de datos maestros o motores de reglas.

Si alguien pregunta “¿Cuántas reclamaciones abiertas superaron los 500.000 rupias este trimestre?”, lo adecuado es consultar la fuente estructurada que almacena los registros de reclamaciones. El texto narrativo que solo aborda las reclamaciones no puede proporcionar un conteo. Un diseño maduro dirige cada pregunta al mecanismo más adecuado para ella.

5. Gráficos de conocimiento y recuperación basada en relaciones

Algunas preguntas se refieren fundamentalmente a relaciones. Un gráfico de conocimiento puede modelar clientes, proveedores, productos, contratos, ubicaciones, incidentes y regulaciones, junto con los vínculos entre ellos.

Supongamos que un analista de riesgos quiere saber qué proveedores activos se conectan con entidades sancionadas a través de la estructura de propiedad beneficiaria. Es poco probable que un solo párrafo contenga las pruebas necesarias. Para responder a esta pregunta hay que seguir los enlaces presentes en los registros de los proveedores, los datos de propiedad corporativa, los resultados de las verificaciones y el estado de los contratos. La recuperación de grafos permite localizar la red de entidades involucradas, y la búsqueda vectorial puede luego obtener pasajes de apoyo sobre esas entidades y los enlaces que se hayan descubierto.

Esta combinación se conoce comúnmente como GraphRAG, aunque las implementaciones varían. Su valor no radica en que los grafos sean más avanzados que los vectores, sino en que los grafos conservan las relaciones explícitas, mientras que los embeddings las reducen a una proximidad estadística.

6. Reclasificación

La recuperación en la primera pasada debe priorizar la capacidad de recordación: se debe recopilar un conjunto amplio de candidatos posiblemente relevantes. Luego, un clasificador secundario los evalúa con más cuidado en relación con la consulta completa. Los codificadores cruzados, los modelos de clasificación especializados o los evaluadores basados en LLM pueden determinar si un pasaje realmente responde a la pregunta.

Las señales que se pueden utilizar incluyen el grado de directitud con el que el pasaje responde, la alineación de entidades, la autoridad, la actualidad, la completitud, la especificidad, las contradicciones y las reglas empresariales. El objetivo es distinguir entre los pasajes que están “sobre el tema” y aquellos que son “útiles para esta pregunta”.

7. Montaje del contexto

Entregar los cinco fragmentos principales a un LLM no constituye una estrategia de contexto. Es posible que sea necesario agrupar las pruebas por documento, ordenarlas cronológicamente, ampliarlas con secciones vecinas, incluir enlaces a definiciones o tablas, eliminar duplicados, fusionarlas con enmiendas, compararlas entre versiones, añadir etiquetas para la fuente y la autoridad, y realizar una compresión que no descarte las excepciones.

El objetivo es preservar la estructura necesaria para el razonamiento. En el caso de una cláusula contractual, eso significa incluir sus definiciones, excepciones y el historial de enmiendas. Un procedimiento clínico podría requerir las advertencias relacionadas con él. Un resultado financiero podría necesitar su período de informe y su base contable.

8. Validación de pruebas

Antes de escribir una respuesta final, el sistema debe verificar si la evidencia es suficiente. ¿Las fuentes respaldan directamente la respuesta y están actualizadas? ¿Existen discrepancias entre fuentes autorizadas? ¿Falta algún documento necesario? ¿La respuesta se basa en una inferencia no sustentada? ¿Puede el usuario acceder realmente a cada pasaje citado?

Cuando la evidencia es insuficiente, la respuesta más segura podría ser indicarlo, solicitar aclaraciones o elevar el asunto. El RAG empresarial debe estar diseñado para abstenerse de responder, y no solo para hacerlo.

Las reglas empresariales tienen un peso real

Una buena parte de los errores de recuperación nunca se resolverán con embeddings mejores, ya que la relevancia está definida por la organización. Reglas representativas: utilizar la política aprobada más reciente, a menos que aplique una regional; aplicar las enmiendas contractuales en el orden en que se ejecutaron; dar prioridad a los estados financieros auditados sobre las estimaciones de la dirección; excluir los documentos regulatorios en borrador; identificar al cliente por su entidad legal, no por su nombre comercial; y devolver solo los registros pertenecientes al territorio al que el usuario puede acceder.

Estos aspectos deben incluirse en el código de recuperación, clasificación u orquestación. Esperar que un LLM los deduzca del contexto es poco fiable y no deja nada sujeto a auditoría. Aquí, el RAG empresarial se convierte en un esfuerzo de ingeniería de sistemas en lugar de una cuestión de elegir un modelo.

Evaluación más allá de la precisión de la respuesta

Un sistema puede dar una respuesta correcta por la razón equivocada, utilizando pruebas débiles y apoyándose en el conocimiento previo del modelo. También puede parecer preciso en las pruebas pero fallar una vez que cambian los documentos. Por lo tanto, la evaluación debe examinar cada capa del proceso.

Recuperación. Verificar si se han encontrado las pruebas necesarias: recall@k, precision@k, media del rango recíproco y ganancia acumulativa descontada normalizada, además de la frecuencia con la que se encuentran identificadores exactos y la frecuencia con la que los resultados son actualizados y fiables.

Contexto. Verificar si el material reunido es utilizable: completitud de las pruebas, redundancia, tasa de contradicciones, relevancia contextual, preservación de las tablas y las relaciones entre secciones, y consistencia de versiones.

Generación. Verifique la respuesta final: fidelidad a las pruebas, corrección de las citaciones, completitud, frecuencia de afirmaciones sin sustento, abstención adecuada, y cumplimiento de permisos y políticas.

Resultados empresariales. Haga un seguimiento del valor operativo: horas ahorradas, frecuencia con la que los casos se escalan, cantidad de esfuerzo de revisión restante, gravedad de los errores, rapidez con la que se resuelven los problemas, si los usuarios confían en la herramienta, incidentes de cumplimiento y grado de adopción de los flujos de trabajo. Un mejor rendimiento en la recuperación semántica sirve de poco si siguen apareciendo contratos vencidos o registros inaccesibles.

Errores que cometen los equipos al pasar de la búsqueda vectorial

Las organizaciones suelen darse cuenta de las limitaciones del RAG basado únicamente en vectores y luego añaden complejidad sin un modelo claro de relevancia.

Un error es adoptar todas las técnicas al mismo tiempo. Un grafo de conocimiento, un reordenador y un flujo de trabajo basado en agentes no solucionarán la falta de metadatos ni una mala gobernanza de documentos.

Otro error es convertir al LLM en el árbitro universal. Los modelos son útiles para interpretar consultas y clasificar pruebas, pero las reglas que deben ser exactas, como los controles de acceso, las fechas y los IDs de entidades, suelen deber permanecer como código determinista.

Un tercer error es ajustar todo únicamente para preguntas de referencia. Los usuarios reales formulan consultas vagas, parciales y dependientes del contexto, por lo que los datos de prueba necesitan casos límite reales, documentos obsoletos, fuentes contradictorias y límites de permisos.

Finalmente, algunos equipos consideran la recuperación de información como una compra de infraestructura. Elegir una base de datos vectorial es solo una de las decisiones que hay que tomar, ya que la relevancia también depende de cómo se ingieren y estructuran los documentos, de los metadatos adjuntos, de cómo se resuelven las identidades, y de cómo se gestionan el ranking, la orquestación y la gobernanza.

Un camino práctico hacia adelante

No es necesario reemplazar la plataforma RAG existente para mejorar la relevancia. Puede evolucionar paso a paso.

Comience con las preguntas que no dieron resultado y clasifique cada error de recuperación. ¿Faltaba la evidencia adecuada, estaba clasificada con un ranking demasiado bajo, fue filtrada incorrectamente, dividida en varios fragmentos, o fue superada por una fuente obsoleta?

A continuación, defina qué significa la relevancia para el flujo de trabajo específico decidiendo qué fuentes tienen autoridad, qué campos de metadatos son relevantes y qué reglas empresariales rigen la validez.

Luego, añada el mecanismo más simple que se adapte a cada fallo. Los identificadores exactos requieren una búsqueda léxica. Las fechas, regiones y tipos de documentos necesitan filtros de metadatos. Un juicio deficiente entre la consulta y el documento exige un reordenador. Los fragmentos que carecen de contexto requieren la recuperación de secciones vecinas. Las preguntas analíticas pertenecen a bases de datos estructuradas. Las respuestas que dependen de relaciones entre entidades necesitan un recorrido por grafos. Las permisos deben verificarse de manera determinista antes de la recuperación, y las pruebas incompletas deben activar reglas de abstención.

Finalmente, cree un conjunto de evaluación a partir de preguntas reales de usuarios y fallos reales, y pruebe la recuperación y la generación por separado para que las mejoras en un nivel no oculten problemas en otro.

Evidencia adecuada sobre texto similar

La búsqueda vectorial sigue siendo valiosa y es excelente para localizar pasajes sobre temas similares. Lo que no puede hacer por sí sola es decidir qué pasaje es actual, fiable, permitido, completo o aplicable a una situación empresarial concreta.

Se necesita una arquitectura de relevancia más amplia que combine la recuperación semántica con la búsqueda de coincidencias exactas, metadatos, reglas empresariales, fuentes estructuradas, relaciones en grafos, reclasificación y una verificación de las pruebas.

La próxima ola de sistemas RAG no será ganada por la búsqueda de más texto similar. Los ganadores serán aquellos que proporcionen las pruebas correctas para el usuario adecuado, en el contexto correcto y en el momento oportuno.