Las raíces arquitectónicas de las alucinaciones

Cuando un LLM inventa un punto de datos, una entidad o una política corporativa que no existe realmente, casi siempre es porque el pipeline de recuperación que alimentaba la entrada era inexacto, obsoleto o incompleto. Existe un término concreto para referirse al espacio que media entre un sistema que ofrece respuestas básicas y un sistema cuyas respuestas permiten actuar con confianza en el entorno de producción: la brecha de confianza.

Un agente que base su razonamiento en el snapshot de clientes de ayer, o un modelo de incrustación que se haya sustituido sin volver a procesar los registros subyacentes, supone un grave riesgo operativo. No produce una respuesta visiblemente incorrecta; produce una alucinación con alta confianza. Una alucinación en una sola demostración de sandbox es una curiosidad, pero el mismo error aplicado a miles de interacciones en vivo por minuto es un incidente.

Introducción a la integridad contextual

La precisión es una propiedad arquitectónica fundamental que mejor se define como la integridad contextual: la disciplina de mantener los datos operativos en vivo, las incrustaciones vectoriales, los índices de búsqueda y el estado de los agentes de forma automática y coherente en lugar de conciliarlos manualmente después de los hechos.

Cuando esas cuatro variables se encuentran en el mismo registro servido por la misma ruta de query, no hay ningún paso de sincronización en el que pueda producirse una pérdida de precisión. La recuperación que recibe un agente se basa de forma segura en la verdad operativa del mismo milisegundo exacto en que se emitió.

Los modelos de Voyage AI lideran el Retrieval Incrustación Benchmark (RTEB), superando a modelos comparables de Gemini, Cohere y OpenAI en las tarea RAG de empresas que ejecutan realmente los agente.

MongoDB ha entregado los bloques de construcción necesarios para cerrar la brecha de confianza de forma nativa dentro de la capa de datos:

• Interoperabilidad de la serie Voyage 4: Una familia de modelos de espacio de incrustación compartidos (voyage-4-large, voyage-4, voyage-4-lite, voyage-4-nano) que producen incrustaciones totalmente compatibles. El buque insignia voyage-4-large es el primer modelo de incrustación de producción compilado sobre una arquitectura de mezcla de expertos (MoE), que ofrece una precisión de estado del arte con un costo de servicio aproximadamente un 40 % inferior al de los modelos densos comparables. Así, se evita tener que volver a procesar toda la colección de datos al modificar los perfiles de costo o de latencia.
• Recuperación asimétrica: una primicia del sector, ya que los documento se incrustan una vez con voyage-4-large para obtener la máxima precisión de referencia, mientras que las query continuas se incrustan mediante voyage-4-lite para mantener bajos los costo de latencia y tokens.

Gana habilidad: Voyage AI con MongoDB

Explora la solución

El recorrido de los desarrolladores: Reglas básicas de filtro

Para los equipos de ingeniería que buscan superar la charla conceptual, la implementación práctica requiere examinar la lógica de filtro real bajo carga. Un ejemplo clave es la búsqueda vectorial filtrada.

MongoDB gestiona esto aplicando primero un filtro por atributos (como el ID de usuario) y, a continuación, ejecutando la búsqueda vectorial. Por el contrario, los planificadores relacionales alternativos a menudo ejecutan primero la búsqueda vectorial e intentan aplicar los filtros después. Cuando los motores relacionales buscan primero, los resultados muy relevantes con frecuencia quedan fuera del conjunto de evaluación de candidatos antes de que puedan calificarse. Esta pequeña variación arquitectónica tiene consecuencias enormes en la precisión a escala de producción de empresas.

Ver: Builder's Journey: crear aplicaciones de IA con MongoDB

LG U+ maneja 3,5 millones de consultas mensuales

Los argumentos de la arquitectura conceptual alcanzan un techo operativo muy claro cuando una empresa ejecuta un centro de llamadas que recibe 3 millones y medio de llamadas de clientes en vivo al mes. El gigante coreano de telecomunicaciones LG U+ se propuso desarrollar Agent Assist: una herramienta interna inteligente que ofrece a 4.000 agentes humanos transcripción en tiempo real, categorización automatizada de consultas y resúmenes contextuales durante consultas en vivo.

Su base de datos relacional heredada simplemente no podía gestionar simultáneamente incrustaciones vectoriales, datos transaccionales y pruebas de queries en tiempo real dentro de la misma ruta de la aplicación. Al migrar los registros operativos principales de Postgres y consolidarlos en MongoDB Atlas, el equipo eliminó por completo la capa de sincronización propensa a la latencia entre sistemas dispares. $vectorSearch ejecuta algoritmos de similitud semántica de forma nativa sobre las mismas colecciones de datos que los agentes humanos consultan para los historiales de transacciones.

El servicio se lanzó apenas cuatro meses después de que comenzara el desarrollo, manteniendo una latencia de query inferior a un segundo incluso durante los picos matutinos. El tiempo de procesamiento por llamada se redujo un 7 % y la eficiencia de los recursos mejoró un 30 %. El sistema, que se desplegó para 1200 agentes en un principio, ahora gestiona más de un millón de consultas por semana y está escalando hacia 2300 agentes.

Lista de verificación de producción antes del envío

Lo que demuestra LG U+ es la lista de verificación absoluta que una capa de datos debe entregar antes de que se pueda confiar en un agente de producción:

1. Índices en la misma ubicación: El índice de búsqueda de IA y los datos operativos en tiempo real deben residir exactamente en el mismo clúster de bases de datos, de modo que los agentes nunca recuperen información de una versión de la verdad mientras actúan basándose en otra.
2. Latencia inferior a un segundo: Las consultas semánticas deben ejecutarse en menos de un segundo bajo cargas intensas, o la respuesta del agente llega demasiado tarde para ser útil desde el punto de vista operativo.
3. Infraestructura de escalado automático: La plataforma debe escalar automáticamente para absorber los picos de demanda matutinos sin que los ingenieros tengan que reaprovisionar los nodos manualmente.
4. Flexibilidad del esquema: El modelo de datos subyacente debe adaptarse dinámicamente a las distintas formas que pueden adoptar las conversaciones, sin obligar a realizar migraciones rígidas del esquema cada vez que la empresa realice una iteración.