Maio de 2026 · 10 min de leitura · Fran Olivares, fundador da OlivaresAI
Um armazenamento de memória persistente por si só não faz nada. O armazenamento tem que ser consultado, pontuado e moldado num system prompt que caiba na janela de contexto do modelo antes da próxima mensagem do usuário chegar. Essa etapa — montagem de contexto — é a diferença entre "temos um banco de memória" e "a IA lembra". Este guia é o companheiro long-form da referência técnica em /docs/context-assembly e percorre cada estágio do pipeline, os números que Alma usa por padrão e os trade-offs que você pode ajustar.
Porque o modelo só vê o que está no prompt. Um armazenamento de memória com dez mil entradas é invisível ao modelo a menos que algo selecione as trinta certas para este turno. Se a seleção está errada, o modelo perde o fato relevante e produz uma resposta genérica. Se a seleção é ampla demais, o prompt estoura a janela de contexto ou desperdiça tokens com ruído. A montagem é a guardiã — uma etapa silenciosa que o usuário nunca vê, mas todo o sentimento de "a IA lembra" depende da qualidade dela.
A montagem também precisa atender um orçamento de latência rígido. O usuário está esperando; qualquer coisa acima de ~100 ms começa a parecer lenta antes de um único token do modelo ter streamado. É por isso que a montagem se apoia em busca indexada em vez de scans completos, por que a pontuação é uma soma ponderada (não uma chamada de LLM) e por que os orçamentos de tokens por tier são calculados na frente em vez de negociados dinamicamente.
Busca híbrida nas três camadas de memória — memories, episodes, procedures — usando sinais de palavra-chave e semânticos. A consulta do usuário é embeddinglada com o mesmo modelo que indexou o armazenamento (bge-m3 1024-dim na configuração padrão da Alma), e o embedding roda contra o índice vetorial para trazer entradas semanticamente similares. Em paralelo, uma busca por palavra-chave bate no índice relacional para matches de termo exato que a busca semântica às vezes perde (nomes próprios, identificadores de código, termos técnicos raros).
Os dois conjuntos de resultados são mesclados, deduplicados e limitados ao orçamento de candidatos (padrão 100 por camada — o máximo que o índice vetorial subjacente suporta por consulta). O pool de candidatos é o que flui para a pontuação; nada além desse estágio resgata uma entrada que a busca não trouxe.
Cinco sinais, ponderados como segue na função de pontuação de produção:
Os pesos são tunados de propósito: a relevância domina, mas os sinais secundários importam quando a relevância empata (o que acontece com frequência em armazenamentos de memória densos). Os pesos são invariantes invioláveis no codebase — mudanças exigem um benchmark A/B porque a qualidade percebida pelo usuário de "a IA lembrou da coisa certa" depende dessa mistura exata.
Cada tier (memories, episodes, procedures, blocos Soul) tem seu próprio orçamento de tokens. Padrões: memories ~2 K tokens, episodes ~1 K, procedures ~500, blocos Soul ~500. Total ~4 K — bem abaixo da janela de contexto de qualquer modelo moderno, e pequeno o suficiente para se manter cache-friendly. Dentro de cada tier, entradas pontuadas são adicionadas em ordem de ranking até o orçamento ser atingido.
O orçamento existe por duas razões. Primeiro, o contexto efetivo do modelo encolhe se você o encher além de uma certa densidade — coisas relevantes no fundo de um prompt de 100K tokens são de fato invisíveis ao padrão de atenção. Segundo, o prompt caching só funciona se o prefixo cacheado for estável; inchar o prompt com memories de baixo sinal busta o cache e faz cada turno pagar tokens a preço cheio. Orçamentos apertados mantêm qualidade e economia em ordem.
Um system prompt estruturado com cinco seções (nesta ordem): identidade (blocos Soul ativos renderizados como XML), preferências (entradas de memory de alta importância marcadas como preferências), fatos relevantes (memories top-pontuadas para esta consulta), contexto recente (episodes top-pontuados), fluxos (procedures top-pontuadas). A estrutura importa: colocar identidade no topo significa que recebe atenção total; colocar fluxos no fundo significa que só são consultados se o modelo decidir que a consulta é procedural.
A mensagem do usuário é então acrescida como o próximo turno. O modelo recebe o prompt montado + mensagem do usuário e produz uma resposta. Da perspectiva do usuário, a IA simplesmente respondeu. Por baixo, a montagem silenciosamente consultou milhares de registros de memória e mostrou ao modelo os trinta certos.
No deployment de produção da Alma, a latência end-to-end da montagem fica na faixa de 30-80 ms para um usuário típico (algumas centenas de memories, uma dúzia de episodes). A busca vetorial domina (~20-40 ms), a busca por palavra-chave roda em paralelo (~5-10 ms), a pontuação é de um dígito de ms e a construção do prompt é essencialmente gratuita. O alvo de 100 ms é atingido com folga confortável mesmo para usuários com milhares de memories — o cap de candidatos e os orçamentos por tier mantêm o trabalho limitado conforme o armazenamento cresce.
Pré-pontuação, uma passada de detecção de contradição no pool de candidatos sinaliza pares na faixa de similaridade 0.75-0.92 que conflitam semanticamente. A entrada mais nova vence por padrão; a mais velha é marcada como superseded e removida do conjunto de candidatos para este turno (e globalmente, na próxima passada de consolidação). Isso impede que o modelo receba "você disse X" ao lado de "você disse não-X" e improvise uma síntese que o usuário nunca concordou.
O ciclo de vida completo (deduplicação, supersessão, decaimento) está documentado em o guia completo de memória persistente; a montagem é só onde essas decisões do ciclo de vida aparecem no momento da consulta.
Arquiteturalmente similar (ambos recuperam, ambos rankeiam, ambos injetam no prompt) mas o corpus e o ciclo de vida são diferentes. RAG recupera de um corpus de documentos externo escrito uma vez e reindexado em um cronograma; as entradas normalmente não evoluem. A montagem de memória recupera do armazenamento próprio do usuário em crescimento contínuo, com entradas que contradizem, mesclam e decaem. Os pesos de pontuação também diferem — RAG rankeia principalmente por similaridade e autoridade do documento; a montagem de memória pondera importância, recência e frequência porque esses sinais importam mais quando o armazenamento é pessoal. Veja a comparação mais profunda em Memória persistente vs RAG.
Sim. O endpoint POST /api/v1/context/assemble aceita overrides para os orçamentos por tier, o limiar mínimo de score, o cap de candidatos e os pesos de boost para tags de categoria (para que um agente PM possa boostar decisões, um agente para escritor possa boostar regras de voz). A maioria dos times fica nos padrões — eles foram tunados para serem úteis fora da caixa — mas as alavancas existem para verticais especializadas.
Comece em alma.olivares.ai, popule vinte ou trinta memories sobre um projeto que você se importe, depois inicie um chat. A primeira resposta do modelo na nova conversa vai referenciar fatos específicos do seu armazenamento de memória — isso é a montagem, só escondida atrás do chat voltado ao usuário. Para desenvolvedores integrando diretamente: a REST API expõe o prompt montado bruto para que você possa inspecionar exatamente o que foi selecionado para cada consulta.
Leitura relacionada: Referência técnica de montagem de contexto · Arquitetura de memória em três camadas · Memória persistente para IA: guia completo 2026 · Memória persistente vs RAG · Soul Engine explicado.