Maio 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 de ser consultado, pontuado e moldado num system prompt que caiba na janela de contexto do modelo antes da próxima mensagem do utilizador chegar. Esse passo — montagem de contexto — é a diferença entre "temos uma base de dados de memória" e "a IA recorda". Este guia é o companheiro alargado da referência técnica em /docs/context-assembly e percorre cada fase do pipeline, os números que a Alma usa por defeito, e os compromissos que 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 os trinta certos para este turno. Se a seleção estiver errada, o modelo perde o facto relevante e produz uma resposta genérica. Se a seleção for demasiado ampla, o prompt ultrapassa a janela de contexto ou desperdiça tokens em ruído. A montagem é o porteiro — um passo silencioso que o utilizador nunca vê, mas a sensação inteira de "a IA recorda" assenta na sua qualidade.
A montagem também tem um orçamento de latência apertado. O utilizador está à espera; qualquer coisa acima de ~100 ms começa a parecer lenta antes de um único token de modelo ter sido transmitido. É por isto que a montagem se apoia em pesquisa indexada em vez de scans completos, porque é que a pontuação é uma soma ponderada (não uma chamada LLM), e porque é que os orçamentos de tokens por nível são calculados à partida em vez de negociados dinamicamente.
Pesquisa híbrida nas três camadas de memória — memórias, episódios, procedimentos — usando sinais de palavra-chave e semânticos. A consulta do utilizador é embebida com o mesmo modelo que indexou o armazenamento (bge-m3 1024-dim na configuração defeito da Alma), e o embedding corre contra o índice vetorial para fazer emergir entradas semanticamente semelhantes. Em paralelo, uma pesquisa por palavra-chave atinge o índice relacional para correspondências exatas de termos que a pesquisa semântica por vezes falha (nomes próprios, identificadores de código, termos técnicos raros).
Ambos os conjuntos de resultados são fundidos, deduplicados, e limitados ao orçamento de candidatos (defeito 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 após esta fase resgata uma entrada que a pesquisa não fez emergir.
Cinco sinais, ponderados como se segue na função de pontuação de produção:
Os pesos são deliberadamente afinados: a relevância domina, mas os sinais secundários importam quando a relevância empata (o que acontece frequentemente em armazenamentos densos de memória). Os pesos são invariantes invioláveis no código — alterações requerem um benchmark A/B porque a qualidade sentida pelo utilizador de "a IA recordou a coisa certa" depende desta mistura exata.
Cada nível (memórias, episódios, procedimentos, blocos Soul) tem o seu próprio orçamento de tokens. Defeitos: memórias ~2 K tokens, episódios ~1 K, procedimentos ~500, blocos Soul ~500. Total ~4 K — bem abaixo da janela de contexto de qualquer modelo moderno, e suficientemente pequeno para se manter cache-friendly. Dentro de cada nível, as entradas pontuadas são adicionadas por 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 o sobrecarregar para além de uma certa densidade — coisas relevantes no fundo de um prompt de 100K tokens são de facto invisíveis para o padrão de atenção. Segundo, o prompt caching só funciona se o prefixo cacheado for estável; inchar o prompt com memórias de baixo sinal rebenta o cache e faz cada turno pagar tokens a preço cheio. Orçamentos apertados mantêm qualidade e economia em linha.
Um system prompt estruturado com cinco secções (nesta ordem): identidade (blocos Soul ativos renderizados como XML), preferências (entradas de memória de alta importância marcadas como preferências), factos relevantes (memórias mais bem pontuadas para esta consulta), contexto recente (episódios mais bem pontuados), fluxos de trabalho (procedimentos mais bem pontuados). A estrutura importa: colocar identidade no topo significa que recebe atenção completa; colocar fluxos de trabalho no fundo significa que são consultados apenas se o modelo decidir que a consulta é procedimental.
A mensagem do utilizador é então anexada como turno seguinte. O modelo recebe o prompt montado + mensagem do utilizador e produz uma resposta. Da perspetiva do utilizador, a IA simplesmente respondeu. Por baixo, a montagem consultou silenciosamente milhares de registos de memória e mostrou ao modelo os trinta certos.
No deployment de produção da Alma, a latência de montagem ponta-a-ponta situa-se no intervalo 30-80 ms para um utilizador típico (algumas centenas de memórias, uma dúzia de episódios). A pesquisa vetorial domina (~20-40 ms), a pesquisa por palavra-chave corre em paralelo (~5-10 ms), a pontuação é de ms de um dígito, e a construção do prompt é essencialmente gratuita. O alvo de 100 ms é cumprido com margem confortável mesmo para utilizadores com milhares de memórias — o limite de candidatos e os orçamentos de nível mantêm o trabalho limitado à medida que o armazenamento cresce.
Pré-pontuação, uma passagem de deteção de contradições sobre o pool de candidatos marca pares no intervalo de semelhança 0,75-0,92 que conflituam semanticamente. A entrada mais nova ganha por defeito; a mais antiga é marcada como substituída e removida do conjunto de candidatos para este turno (e globalmente, na próxima passagem de consolidação). Isto previne que o modelo receba "disseste X" junto com "disseste não-X" e improvise uma síntese com a qual o utilizador nunca concordou.
O ciclo de vida completo (deduplicação, substituição, decaimento) está documentado no guia completo de memória persistente; a montagem é apenas onde essas decisões de ciclo de vida aparecem no momento da consulta.
Arquiteturalmente semelhante (ambos recuperam, ambos ordenam, ambos injetam no prompt) mas o corpus e o ciclo de vida são diferentes. O RAG recupera de um corpus externo de documentos autorado uma vez e reindexado num horário; as entradas geralmente não evoluem. A montagem de memória recupera do armazenamento próprio do utilizador em crescimento contínuo, com entradas que se contradizem, se fundem e decaem. Os pesos de pontuação também diferem — o RAG ordena maioritariamente por semelhança e autoridade de documento; a montagem de memória pondera importância, recência e frequência porque esses sinais importam mais quando o armazenamento é pessoal. Ver 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 nível, o limiar mínimo de pontuação, o limite de candidatos e os pesos de boost para tags de categoria (para que um agente de PM possa fazer boost a decisões, um agente de escritor possa fazer boost a regras de voz). A maioria das equipas fica nos defeitos — foram afinados para serem úteis out-of-the-box — mas as alavancas existem para verticais especializadas.
Comece em alma.olivares.ai, popule vinte ou trinta memórias sobre um projeto que lhe interessa, depois inicie um chat. A primeira resposta do modelo na nova conversa fará referência a factos específicos do seu armazenamento de memória — essa é a montagem, apenas escondida atrás do chat visível ao utilizador. Para programadores que integram diretamente: a REST API expõe o prompt montado em bruto para que 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.