Memoria por cliente

Recuperar respuestas de tus documentos. La memoria es la otra mitad: lo que el agente sabe sobre este cliente en particular, preservado a través de sesiones, canales y meses.

La memoria se deriva, no se registra

Almacenar transcritos completos y buscarlos de vuelta es el enfoque obvio y uno deficiente. Los transcritos están llenos de relleno, el mismo hecho aparece en veinte redacciones diferentes, y la recuperación empeora a medida que la relación se alarga —exactamente al revés de lo deseable.

En su lugar, después de un turno, la plataforma solicita a un modelo que extraiga entradas normalizadas de lo que el cliente dijo, de dos tipos:

• Hechos — declaraciones duraderas sobre el cliente. "Gestiona una flota de cuatro vehículos." "La renovación es en mayo." "Prefiere WhatsApp."
• Temas — asuntos recurrentes a los que la relación vuelve constantemente, cada uno con un nombre de tema.

Cada entrada lleva una puntuación de importancia, para que una observación casual y una restricción estricta no se traten como iguales cuando el espacio es limitado.

Solo la mitad del cliente de la conversación

La extracción lee lo que el cliente dijo. Las propias respuestas del agente no son elegibles para convertirse en hechos sobre el cliente, y esto importa más de lo que parece.

Un agente que especule una vez —una frase sobre lo que probablemente fabrica la empresa de este cliente, ofrecida como una suposición en una respuesta— de otro modo tendría esa especulación extraída como un hecho duradero y leída de vuelta como una premisa en cada turno subsiguiente. A partir de entonces, ya no es una suposición; es algo que el agente sabe. El cliente ve la consecuencia sin haber visto nunca la causa: respuestas que siguen siendo sobre el negocio equivocado, sin nada en pantalla que explique por qué.

Hay dos defensas, porque la primera es una solicitud y la segunda es una verificación. La extracción solo se muestra la mitad del cliente. Luego, antes de que se escriba nada, el software verifica que la redacción del "hecho" tenga alguna base en lo que el cliente realmente dijo —una verificación que se ejecuta fuera del modelo, en cada entrada, cada turno.

La deduplicación es todo el juego

Un cliente menciona lo mismo a lo largo de cinco conversaciones. Sin deduplicación, acumulas cinco memorias casi idénticas, estas desplazan a todo lo demás en el momento de la recuperación, y el agente empieza a repetirse.

Antes de que se escriba una entrada, la plataforma busca una en la que debería fusionarse en su lugar:

• Temas coinciden por nombre de tema —exacto, porque un tema ya es una etiqueta normalizada.
• Hechos coinciden por proximidad vectorial: la memoria existente más cercana del mismo tipo, aceptada como duplicada solo si su distancia coseno está dentro de un umbral configurado.

En caso de coincidencia, la fila existente se actualiza en lugar de duplicarse —el contenido y la incrustación se actualizan, y la importancia se eleva al mayor de los dos valores, para que un hecho que resulta importar más más tarde se promueva en lugar de almacenarse dos veces con diferentes pesos. La entrada también se vuelve a señalar a la sesión más reciente y al mensaje que la desencadenó, para que su antigüedad refleje la relación en curso.

Incrustación por lotes

Un solo turno a menudo produce varias entradas. Incrustarlas una a una significa varias rondas secuenciales de ida y vuelta al punto de conexión de incrustación —y dado que ese punto de conexión se ejecuta con una concurrencia de uno, esa secuencia bloquea las incrustaciones de consulta de otros usuarios detrás de ella.

Por lo tanto, las entradas de un turno se incrustan como un único lote y los vectores se pasan a la ruta de escritura. Medido en un turno de tres entradas: 117 ms secuenciales frente a 46 ms por lotes —una diferencia de 2,4× en una ruta que se sitúa entre el cliente y su respuesta.

Recuperación

Al inicio de un turno, las memorias se recuperan para ese cliente por similitud vectorial, bajo su propio umbral de distancia —más estricto que el utilizado para la recuperación de documentos, porque un pasaje de documento marginalmente relacionado es simplemente poco útil, mientras que un "hecho" marginalmente relacionado sobre alguien es activamente incorrecto.

Las memorias recuperadas se unen al prompt junto con cualquier fragmento de documento recuperado. El agente responde desde tus documentos, dirigido a una persona que ya conoce.

Olvido

Todo lo anterior se acumula. Las entradas se fusionan, la importancia aumenta, nada sale —lo cual es el correcto por defecto para la memoria y el incorrecto para una memoria que es incorrecta.

Una memoria incorrecta es casi invisible desde el lado del cliente. Ellos no pueden ver la base de datos, por lo que no pueden ver que un hecho erróneo está en ella; lo que ven es un agente que sigue dando algo por sentado. La única persona en la conversación que puede identificar la entrada errónea es la que está siendo mal recordada, y la única forma en que pueden hacerlo es diciendo que no.

Por lo tanto, decir que no funciona. "No fabricamos eso." "Esa no es mi empresa." "Olvídate lo que sabes sobre X." El agente compara eso con lo almacenado y elimina las entradas que encuentra, en cualquier idioma, sin que nadie abra una página de configuración.

Juzgar si una frase niega algo recordado es genuinamente un problema de lenguaje —"no hacemos eso" puede ser una corrección o simplemente una declaración sobre el negocio—, por lo que un modelo toma esa decisión. Lo que el modelo no tiene permitido decidir es cuánto daño se le permite hacer, y esos límites están en el código:

• Como máximo un puñado de entradas por solicitud, para que una mala interpretación se mantenga acotada.
• Solo entradas lo suficientemente cercanas para coincidir realmente. Una búsqueda por similitud siempre devuelve sus resultados más cercanos, incluso en una cuenta que no contiene nada relevante; sin un límite de distancia, "olvida lo que sabes sobre X" en una cuenta no relacionada eliminaría lo que haya ocurrido por estar en primer lugar.
• Lo que se eliminó se vuelve a leer al cliente. Eliminar en silencio es tan malo como recordar incorrectamente, y esta vez la única persona que puede decir si fue correcto ya está en la conversación.

La eliminación es permanente: no hay un archivo que contenga una copia de algo que el cliente pidió ser olvidado, lo cual es la única lectura de esa solicitud que tiene sentido.

Acotación y encriptación

Las memorias están acotadas al espacio del usuario final, aplicadas a nivel de base de datos como cualquier otro registro propiedad del inquilino, y almacenadas encriptadas por espacio. El historial de un cliente no puede aparecer en la conversación de otro, y el texto almacenado no es legible solo desde la base de datos.

Por qué esto es difícil de añadir como complemento posterior

La memoria por cliente cambia la forma del modelo de datos: una identidad por usuario final, un espacio para acotarla, encriptación claveada a ese alcance, y un paso de derivación en el bucle de turno. Los sistemas que comienzan como un único asistente compartido tienden a terminar con un campo de CRM en algún lugar y llamarlo memoria —lo cual es por qué la diferencia se muestra en la conversación en lugar de en la lista de funciones.