Cómo funciona realmente una memoria de IA persistente

Los pesos de un modelo están congelados. Hablarle no le enseña nada, y cerrar la pestaña no le hace olvidar: nunca hubo un sitio al que ese recuerdo pudiera ir. Lo que usted vive como un asistente que se acuerda de usted es un arreglo mucho más prosaico: se guardó texto en algún sitio y, antes de que el modelo respondiera, un programa fue a buscar los fragmentos relevantes y los pegó delante.

Ese es todo el truco. Pero la calidad de una memoria de IA es casi por completo la calidad del paso de recuperación, y ahí es donde los productos de esta categoría difieren enormemente mientras se describen de forma idéntica.

La ventana de contexto no es memoria

Las dos se confunden constantemente, así que: la ventana de contexto es la mesa de trabajo del modelo. Todo lo que puede tener en cuenta ahora mismo, en este turno. Es amplia en los modelos actuales, y se borra por completo entre conversaciones.

La memoria es un almacén que sobrevive a la conversación. La relación entre ambas es que la memoria *alimenta* la ventana, selectivamente.

Y tiene que ser selectiva, porque la alternativa ingenua falla tanto en coste como en precisión. Si tuviera un año de notas y las volcara todas en cada turno, pagaría esos tokens en cada mensaje, y el modelo lo haría peor, no mejor: un detalle relevante enterrado en cien páginas de detalles irrelevantes se diluye. La recuperación existe porque menos, bien elegido, gana a más.

Almacenar: la parte que parece trivial y no lo es

Se toman dos decisiones en el momento de escribir, y las dos le persiguen después.

Qué guardar. Guardar transcripciones enteras es barato y casi inútil: acaba buscando en un pajar que construyó usted mismo. Guardar hechos destilados es mucho más recuperable, pero exige un juicio sobre qué importaba, y toda extracción automática descartará a veces justo aquello que le importaba. La mayoría de los productos se sitúan en algún punto de ese eje, y dónde se sitúan predice mejor cómo se sienten a los seis meses que cualquier lista de funciones.

Cómo trocearlo. El texto entra en forma de fragmentos, y el fragmento es la unidad que se recupera. Demasiado grande, y un acierto arrastra tres temas sin relación. Demasiado pequeño, y la frase vuelve sin el contexto que la hacía significativa. No hay una respuesta correcta, solo una ajustada.

Encontrar: los embeddings y su punto ciego

Un segundo modelo —un modelo de embedding, no ese con el que usted conversa— convierte cada fragmento en un vector de unos cientos a unos miles de números. Los textos de significado parecido aterrizan cerca unos de otros. Su pregunta recibe el mismo tratamiento, y la búsqueda se vuelve geometría: devolver los fragmentos más cercanos.

Hecho de forma exhaustiva eso es lento, así que los sistemas reales usan un índice aproximado: HNSW es el habitual, un grafo navegable que alcanza una buena respuesta sin visitar todos los puntos. Cambia un poco de exhaustividad por órdenes de magnitud de velocidad, y en pgvector es un índice de una línea.

Aquí está el punto ciego que nadie menciona en el argumentario. La búsqueda semántica es *solo* semántica. Pida un número de factura exacto, un apellido, una versión de una biblioteca, un nombre de variable —los casos en los que conoce la cadena precisa— y la similitud vectorial le tenderá encantada cinco cosas que *hablan* de ese tema y no la que contiene la cadena.

Por eso un índice de palabras clave, BM25 o la búsqueda de texto completo de una base de datos, no es el enfoque antiguo que los vectores vinieron a sustituir. Es la mitad en la que los vectores son malos.

Búsqueda híbrida y reranking

Un pipeline de recuperación serio ejecuta las dos búsquedas y las fusiona. La fusión estándar es la reciprocal rank fusion: cada resultado se puntúa por su *rango* en cada lista en lugar de por una puntuación bruta, lo que esquiva el hecho de que una distancia coseno y una puntuación BM25 no se miden en la misma unidad y no se pueden sumar.

Llega después el paso que produce la mayor parte de la calidad perceptible, y que muchos productos se saltan porque cuesta cómputo. La fusión le da unos treinta candidatos. Un reranker cross-encoder lee la pregunta y cada candidato *juntos*, y puntúa hasta qué punto ese responde a esta. Es mucho más preciso que comparar dos vectores fabricados de forma independiente, y demasiado lento para pasarlo sobre todo el almacén, que es justo por lo que se ejecuta el último, sobre una lista corta.

Una advertencia si trabaja en más de un idioma. Las dos etapas dependen de modelos, y muchos modelos de embedding y de reranking están pensados primero para el inglés. Un pipeline que puntúa bien en inglés puede degradarse en silencio en francés o en alemán, y usted lo vivirá como «se ha olvidado», no como «el reranker se entrenó con la distribución equivocada». Si no trabaja en inglés, compruebe que los modelos son realmente multilingües: multilingual-e5 es una de esas familias.

Cuando pasamos nuestro propio pipeline de la búsqueda vectorial simple a la fusión híbrida más un cross-encoder multilingüe, el mean reciprocal rank sobre nuestro conjunto de evaluación mejoró un 139%. Tómelo por lo que es: nuestra medición, sobre nuestros datos, con nuestro troceado. Dice que el paso merece la pena; no es una cifra que pueda esperar reproducir en otro corpus.

Las cuatro formas en que esto falla

1. Nunca se almacenó. El fallo más frecuente, y con diferencia. Nada en la cadena de recuperación puede encontrar un hecho que nunca se escribió, y la extracción automática deja cosas fuera.
2. Sin umbral. Si el sistema siempre devuelve sus cinco mejores resultados, cuando no existe nada relevante devuelve cinco cosas irrelevantes, y el modelo, que es complaciente, las teje en la respuesta. Un suelo de similitud que no devuelve nada es una funcionalidad, y su ausencia explica por qué algunos asistentes recuerdan mal con aplomo.
3. Contradicciones caducadas. Usted se mudó de ciudad; el hecho antiguo y el nuevo están los dos en el almacén, los dos recuperables. Sin ponderación por recencia ni sustitución explícita, el modelo puede elegir cualquiera de los dos.
4. El problema de la aguja. Los identificadores exactos, en un sistema solo vectorial. Véase más arriba.

Qué preguntar a un producto de memoria

Cinco preguntas, y todas tienen una respuesta factual que un proveedor le da o esquiva:

• ¿Búsqueda por palabras clave además de vectorial, o solo vectorial?
• ¿Hay una etapa de reranking, y con qué modelo?
• ¿Hay un umbral de relevancia por debajo del cual no devuelve nada?
• ¿Los modelos de embedding y de reranking son multilingües, y están evaluados en mi idioma?
• ¿Puedo ver, editar y borrar un recuerdo concreto, o el almacén es opaco para mí?

La última no va de calidad de recuperación, pero es la que le importará primero, la primera vez que se recuerde algo equivocado sobre usted.

Pryzm ejecuta fusión híbrida con un reranker cross-encoder multilingüe y un umbral de relevancia, sobre PostgreSQL con índices HNSW, y cada recuerdo es visible y borrable individualmente. Cómo se comparan las alternativas está en nuestra comparativa.