Su analista de IA necesita un cerebro, no un vector store

Pregunte a una analista nueva qué la frena de verdad en sus primeros meses y no dirá SQL - dirá convenciones. Qué índice de referencia aplica a qué mandato, y los dos mandatos donde la respuesta obvia es la equivocada. Por qué las comparaciones anteriores a 2024 tienen que usar las tablas _hist, porque la migración de ese año cambió cómo se claven las posiciones. El hecho de que el proveedor ESG usa SEDOL y el almacén usa ISIN, y que catorce nombres desaparecen en silencio de cualquier join que olvide la tabla puente.

Nada de esto está escrito en ningún sitio útil. Vive en las cabezas de las dos personas más veteranas de la mesa, en historiales de chat que nadie puede buscar, y en los márgenes de presentaciones ya sustituidas dos veces. Es el conocimiento que hace correcto un análisis - y cuando un agente de IA empieza a analizar, la pregunta de si posee ese conocimiento deja de ser un extra y se convierte en la diferencia entre una respuesta y un incidente.

La respuesta por defecto del sector es la generación aumentada por recuperación: incrustar los documentos, buscar por similitud, meter los fragmentos más cercanos en el contexto. Nosotros construimos otra cosa, y este artículo es el argumento. La versión corta: el conocimiento institucional es estructural, y la búsqueda por similitud es ciega a la estructura.

Por qué la búsqueda por similitud pierde el conocimiento estructurado

Aquí hay una forma real de conocimiento del mundo de nuestros escenarios de demostración - el join canónico para precios as-of y la salvedad que lo hace correcto:

1SELECT h.*, p.close2FROM holdings h3ASOF JOIN prices p4ON p.isin = h.isin AND p.ts <= h.ts5-- never p.ts = h.ts: look-ahead bias.6-- promoted to house standard after the Q1 incident.

El SQL es la mitad fácil. La mitad que soporta el peso es todo lo que lleva adjunto: este patrón aplica a backtests y a cualquier análisis que una precios con posiciones; lo validó el jefe de la mesa tras un incidente; restringe una clase concreta de consultas; y el <= no es una elección de estilo sino todo el punto. Ahora el caso de fallo: una memoria de embeddings, preguntada por unir precios, recupera encantada el SQL - se parece mucho a la pregunta - e igual de encantada omite la salvedad, porque vive en otro fragmento con otro embedding y nada estructural dice estas dos piezas son inseparables. El agente escribe un join de aspecto impecable con = en vez de <=, el backtest mira al futuro sin ruido, y el error es invisible precisamente porque todo lo recuperado era "relevante".

La similitud le dice qué suena relacionado. No puede decirle qué aplica, qué viene adjunto o qué fue sustituido - porque eso son aristas, no distancias.

Un grafo de conocimiento, no una pila de documentos

La memoria de DataQube es un grafo. Definiciones, consultas de ejemplo, salvedades, decisiones y habilidades son nodos tipados, enlazados a los espacios de trabajo donde rigen, a las fuentes de datos que describen y a las herramientas que restringen. Las aristas también son tipadas - aplica-a, matiza, derivado-de, sustituye - y un mismo par de nodos puede llevar varias a la vez: la salvedad del look-ahead es a la vez sobre la fuente de precios y una restricción del patrón de join - exactamente por eso ningún recuerdo del patrón puede llegar sin ella.

La recuperación es entonces un recorrido del grafo, no una búsqueda del vecino más cercano. Cuando un agente empieza a trabajar en un espacio, trae el vecindario: las definiciones con ese alcance, las salvedades adjuntas a cada fuente y herramienta que está a punto de tocar, las habilidades promovidas desde trabajo validado anterior. La salvedad de precios no se recupera porque se parezca a la pregunta - se recupera porque está adjunta a la cosa que se usa. El parecido es opcional; la adjunción no.

Conocimiento que sabe cuándo se equivoca

Almacenar nunca fue lo difícil. Lo difícil - y, diríamos, el producto de verdad - es la invalidación. El conocimiento institucional caduca sin calendario: una definición cambia tras un incidente, una fuente se reclava, una convención la tumba un comité que no avisó a nadie.

Así ocurre en DataQube, con el incidente en que se basa nuestro escenario de demostración. Un problema con el snapshot de precios obliga a la mesa a cambiar su definición de retorno activo. En el momento en que la nueva definición queda validada, la antigua queda sustituida: deja de recuperarse al instante, en todas partes, sin caché que caducar. Pero no se borra - permanece en el grafo, enlazada a su reemplazo, sellada con el momento en que dejó de ser cierta. Esa última propiedad es la que hace el sistema auditable y no meramente actual: cuando alguien revisa un análisis de antes del cambio, el registro muestra que se produjo bajo la definición vigente entonces - la diferencia entre "el análisis estaba mal" y "la definición cambió después", una distinción que a los auditores les importa mucho.

La puerta de entrada importa tanto como la de salida. Los candidatos extraídos de conversaciones - "el agente notó que la mesa siempre excluye las clases semilla" - entran en cuarentena: visibles, atribuibles y nunca recuperados hasta que una persona los valida. Nada de lo que el agente infirió puede convertirse en silencio en algo en lo que el agente se apoya. La validación misma es un evento en el registro: quién aprobó esta pieza de conocimiento, cuándo, de qué conversación salió. Los estándares de la casa llevan su cadena completa.

La alternativa rechazada es la que suena más atractiva: dejar que el sistema aprenda continuamente y confiar en que el buen conocimiento desplaza al malo. En un producto de consumo es una apuesta razonable. En uno regulado significa que las creencias de su agente son una entrada no auditada y automodificable de cada número que produce - y la primera vez que una inferencia errónea contamine un trimestre de respuestas, no podrá decir ni cuándo llegó ni qué tocó.

Cómo se ve la recuperación en una ejecución real

Aquí está el ciclo completo en el producto - conocimiento validado llegando antes de que corra la primera consulta, y un candidato nuevo saliendo a cuarentena al final:

Repetir ejecución

A partir de conversaciones reales con clientes — todos los datos son ficticios.

Fíjese en la forma de lo recuperado: no documentos que se parecen a la pregunta, sino las definiciones de este espacio y las salvedades adjuntas a las fuentes que esta ejecución está a punto de usar. Y fíjese en lo que sale: un candidato, claramente marcado como pendiente de validación, lejos de futuras recuperaciones hasta que alguien con autoridad lo apruebe.

La prueba de una sola pregunta

Si está evaluando memoria de agentes, pregunte esto al proveedor: cuando cambia una definición, muéstreme qué pasa con la antigua - y muéstreme qué sirve su sistema para un análisis fechado antes del cambio. Un almacén de similitud no tiene buena respuesta; los fragmentos viejos y nuevos coexisten, y la recuperación elige por parecido y heurísticas de recencia. Un grafo con semántica de sustitución responde con precisión: la definición nueva en todas partes desde el momento de la validación, la antigua conservada con su ventana de validez para quien audite el pasado.

Un sistema de memoria sin semántica de sustitución no acumula conocimiento. Acumula pasivos - fluidos, seguros de sí mismos y cada vez más equivocados. Cómo encaja el módulo de memoria en el resto de la plataforma está en la página de producto, y si quiere ver el flujo de cuarentena en vivo, reserve una demo y enséñele al agente algo falso - y vea cómo no llega a importar.