Mayo 2026 · 10 min de lectura · Fran Olivares, fundador de OlivaresAI
Un almacén de memoria persistente por sí solo no hace nada. El almacén tiene que ser consultado, puntuado y moldeado en un system prompt que encaje en la ventana de contexto del modelo antes de que aterrice el siguiente mensaje del usuario. Ese paso — el ensamblado de contexto — es la diferencia entre «tenemos una base de datos de memoria» y «la IA recuerda». Esta guía es la versión larga acompañante de la referencia técnica en /docs/context-assembly y recorre cada etapa del pipeline, las cifras que Alma usa por defecto y los trade-offs que puedes afinar.
Porque el modelo solo ve lo que hay en el prompt. Un almacén de memoria con diez mil entradas es invisible para el modelo a menos que algo seleccione las treinta correctas para este turno. Si la selección está mal, el modelo pasa por alto el hecho relevante y produce una respuesta genérica. Si la selección es demasiado amplia, el prompt revienta la ventana de contexto o gasta tokens en ruido. El ensamblado es el portero — un paso silencioso que el usuario nunca ve, pero toda la sensación de «la IA recuerda» depende de su calidad.
El ensamblado también golpea un presupuesto de latencia duro. El usuario está esperando; cualquier cosa por encima de ~100 ms empieza a sentirse lenta antes de que se haya streameado un solo token del modelo. Por eso el ensamblado se apoya en búsqueda indexada en lugar de escaneos completos, por eso la puntuación es una suma ponderada (no una llamada LLM) y por eso los presupuestos de token por tier se computan por adelantado en lugar de negociarse dinámicamente.
Búsqueda híbrida en las tres capas de memoria — memorias, episodios, procedimientos — usando señales tanto de keyword como semánticas. La query del usuario se embebe con el mismo modelo que indexó el almacén (bge-m3 1024-dim en la configuración por defecto de Alma) y el embedding corre contra el índice vectorial para sacar entradas semánticamente similares. En paralelo, una búsqueda por keyword golpea el índice relacional para matches de término exacto que a veces la búsqueda semántica se pierde (nombres propios, identificadores de código, términos técnicos raros).
Ambos conjuntos de resultados se fusionan, deduplican y limitan al presupuesto de candidatos (100 por capa por defecto — el máximo que el índice vectorial subyacente soporta por consulta). El pool de candidatos es lo que fluye a la puntuación; nada más allá de esta etapa rescata una entrada que la búsqueda no sacó.
Cinco señales, ponderadas así en la función de puntuación de producción:
Los pesos están afinados deliberadamente: la relevancia domina, pero las señales secundarias importan cuando la relevancia empata (lo que pasa a menudo en almacenes densos de memoria). Los pesos son invariantes inviolables en el código; los cambios requieren un benchmark A/B porque la calidad percibida por el usuario de «¿la IA recordó lo correcto?» depende de esta mezcla exacta.
Cada tier (memorias, episodios, procedimientos, bloques Soul) tiene su propio presupuesto de tokens. Valores por defecto: memorias ~2 K tokens, episodios ~1 K, procedimientos ~500, bloques Soul ~500. Total ~4 K — muy por debajo de la ventana de contexto de cualquier modelo moderno y lo suficientemente pequeño como para mantenerse cache-friendly. Dentro de cada tier, las entradas puntuadas se añaden en orden de ranking hasta alcanzar el presupuesto.
El presupuesto existe por dos razones. Primera, el contexto efectivo del modelo se encoge si lo aprietas más allá de cierta densidad — las cosas relevantes al final de un prompt de 100K tokens son de facto invisibles para el patrón de atención. Segunda, el prompt caching solo funciona si el prefijo cacheado es estable; hinchar el prompt con memorias de baja señal rompe el cache y hace que cada turno pague tokens a precio completo. Los presupuestos ajustados mantienen tanto la calidad como la economía en su sitio.
Un system prompt estructurado con cinco secciones (en este orden): identidad (bloques Soul activos renderizados como XML), preferencias (entradas de memoria de alta importancia marcadas como preferencias), hechos relevantes (memorias mejor puntuadas para esta query), contexto reciente (episodios mejor puntuados), workflows (procedimientos mejor puntuados). La estructura importa: poner la identidad arriba significa que recibe atención completa; poner los workflows al final significa que solo se consultan si el modelo decide que la query es procedimental.
El mensaje del usuario se añade entonces como el siguiente turno. El modelo recibe el prompt ensamblado + el mensaje del usuario y produce una respuesta. Desde la perspectiva del usuario, la IA simplemente respondió. Por debajo, el ensamblado consultó silenciosamente miles de registros de memoria y le mostró al modelo los treinta correctos.
En el despliegue en producción de Alma, la latencia de ensamblado extremo a extremo se sitúa en el rango de 30-80 ms para un usuario típico (unas cuantas centenas de memorias, una docena de episodios). La búsqueda vectorial domina (~20-40 ms), la búsqueda por keyword corre en paralelo (~5-10 ms), la puntuación está en dígitos sencillos de ms y la construcción del prompt es esencialmente gratis. El objetivo de 100 ms se cumple con margen cómodo incluso para usuarios con miles de memorias — el límite de candidatos y los presupuestos de tier mantienen el trabajo acotado a medida que crece el almacén.
Antes de puntuar, una pasada de detección de contradicciones sobre el pool de candidatos marca pares en el rango de similitud 0,75-0,92 que entran en conflicto semánticamente. La entrada más nueva gana por defecto; la más antigua se marca como superada y se retira del conjunto de candidatos para este turno (y globalmente, en la próxima pasada de consolidación). Esto evita que el modelo reciba «dijiste X» junto a «dijiste no-X» e improvise una síntesis que el usuario nunca acordó.
El ciclo de vida completo (deduplicación, supersesión, decaimiento) está documentado en la guía completa de memoria persistente; el ensamblado es solo el sitio donde esas decisiones de ciclo de vida aparecen en el momento de la consulta.
Arquitectónicamente similar (ambos recuperan, ambos rankean, ambos inyectan en el prompt) pero el corpus y el ciclo de vida son distintos. RAG recupera de un corpus externo de documentos redactado una vez y reindexado en lotes; las entradas no suelen evolucionar. El ensamblado de memoria recupera del almacén propio del usuario en crecimiento continuo, con entradas que se contradicen, fusionan y decaen. Los pesos de puntuación también difieren — RAG rankea principalmente por similitud y autoridad del documento; el ensamblado de memoria pondera importancia, recencia y frecuencia porque esas señales importan más cuando el almacén es personal. Ver la comparación más profunda en Memoria persistente vs RAG.
Sí. El endpoint POST /api/v1/context/assemble acepta overrides para los presupuestos por tier, el umbral mínimo de puntuación, el cap de candidatos y los pesos de boost por etiquetas de categoría (para que un agente PM pueda boostear decisions, el agente de un escritor pueda boostear voice rules). La mayoría de equipos se quedan en los valores por defecto — están afinados para ser útiles de serie — pero las palancas existen para verticales especializados.
Empieza en alma.olivares.ai, puebla veinte o treinta memorias sobre un proyecto que te importe y luego inicia un chat. La primera respuesta del modelo en la nueva conversación hará referencia a hechos específicos de tu almacén de memoria — eso es el ensamblado, solo escondido detrás del chat visible para el usuario. Para desarrolladores que integran directamente: la REST API expone el prompt ensamblado en bruto para que puedas inspeccionar exactamente qué se seleccionó para cada query.
Lectura relacionada: Referencia técnica del ensamblado de contexto · Arquitectura de memoria de tres capas · Memoria persistente para IA: guía completa 2026 · Memoria persistente vs RAG · Soul Engine explicado.