¿Qué es un motor de contexto?
Un motor de contexto es una capa de runtime que reúne la información más relevante, actual y permitida para una persona o agente, la conecta con entidades y eventos, y transforma interacciones nuevas en contexto durable.
Los sistemas de registro definen qué es autoritativo. Las bases de conocimiento guardan documentos. Un motor de contexto decide qué piezas importan para este cliente, tarea, momento, canal y acción.
Es más que búsqueda vectorial o historial de chat. Incluye identidad, registros estructurados, relaciones, recencia, estado, permisos, provenance, memoria y resultados previos.
¿Por qué es importante?
Un motor de contexto no puede inferir un modelo confiable desde una pila de documentos. Primero necesita ground truth y ontología: Objetos, Record Types, tipos de campo, relaciones, IDs y owners.
Con ese mapa conecta un número de WhatsApp, un thread de Gmail u Outlook, un registro CRM, un evento de producto, una métrica del warehouse y una feature del data lake con el mismo cliente sin borrar diferencias de autoridad.
Relaciones como Person trabaja en Company o Ticket trata sobre Product crean caminos de retrieval más precisos que la similitud semántica sola.
Cómo funciona
Primero mapeá ontología y ground truth. Definí Objetos, Record Types, campos, relaciones, identity keys, sources autoritativos y qué es verificado, sincronizado, inferido o calculado.
Después conectá streaming y batch. WhatsApp, Gmail y Outlook aportan conversaciones; CRM y APIs aportan registros; ETL, warehouses y data lakes aportan historia y señales con lineage.
En runtime, el motor parte de actor, tarea, cliente y permisos. Recorre relaciones, consulta registros, recupera evidencia, pondera recencia y source, y arma contexto acotado. Los outcomes vuelven al objeto y owner correctos.
Ejemplo técnico
Un cliente contacta soporte por un dispositivo que sigue fallando. El motor conecta el WhatsApp con cuenta, serial, pedido, ticket, telemetría y la llamada de ayer.
Muestra el paso fallido, garantía, issue conocido y política de reemplazo, no todos los documentos del producto. El agente evita repetir troubleshooting y ofrece la acción permitida.
La elección, el pedido de reemplazo y la resolución se vuelven contexto nuevo. El sistema de órdenes sigue siendo autoritativo para el envío.
Notas de implementación
Usá retrieval ontology-aware con filtros estructurados, grafos, búsqueda lexical y semántica, ventanas de eventos y reglas. No uses embeddings para decidir identidad u ownership.
Propagá Objeto, Record Type, tipo de campo, relación, source ID, event time, permisos, provenance, confianza y expiración. Aplicá acceso antes de ranking.
Evaluá identity resolution, relaciones, selección de source, recall de contexto crítico, staleness, leakage, contradicciones y write-back correcto.


