Como funciona realmente uma memória de IA persistente

Os pesos de um modelo estão congelados. Falar com ele não lhe ensina nada, e fechar o separador não o faz esquecer — nunca houve sítio nenhum para onde essa memória pudesse ir. Aquilo que vive como um assistente que se lembra de si é um arranjo muito mais prosaico: foi guardado texto algures e, antes de o modelo responder, um programa foi encontrar as partes pertinentes e colou-as à frente dele.

É esse o truque todo. Mas a qualidade de uma memória de IA é quase inteiramente a qualidade da etapa de recuperação, e é aí que os produtos desta categoria diferem enormemente enquanto se descrevem de forma idêntica.

A janela de contexto não é memória

Confundem-se as duas constantemente, portanto: a janela de contexto é a secretária de trabalho do modelo. Tudo o que ele pode ter em conta agora, neste turno. É grande nos modelos atuais, e é integralmente apagada entre conversas.

A memória é um armazenamento que sobrevive à conversa. A relação entre ambas é que a memória *alimenta* a janela — seletivamente.

E tem de ser seletiva, porque a alternativa ingénua falha tanto no custo como na exatidão. Se tivesse um ano de notas e as despejasse todas em cada turno, pagaria esses tokens em cada mensagem, e o modelo faria pior, não melhor: um detalhe pertinente enterrado em cem páginas de detalhes irrelevantes dilui-se. A recuperação existe porque menos, bem escolhido, vale mais do que mais.

Guardar: a parte que parece trivial e não é

Tomam-se duas decisões no momento da escrita, e ambas o perseguem depois.

O que guardar. Guardar transcrições inteiras é barato e quase inútil — acaba a procurar num palheiro que construiu a si próprio. Guardar factos destilados é muito mais recuperável, mas exige um juízo sobre o que importava, e qualquer extração automática há de descartar por vezes precisamente aquilo que lhe interessava. A maioria dos produtos situa-se algures neste eixo, e a posição que ocupam prevê melhor a sensação ao fim de seis meses do que qualquer lista de funcionalidades.

Como o cortar. O texto entra sob a forma de fragmentos, e o fragmento é a unidade que será recuperada. Demasiado grande, e um resultado arrasta consigo três temas sem relação. Demasiado pequeno, e a frase volta sem o contexto que a tornava significativa. Não há resposta certa, apenas uma resposta afinada.

Encontrar: os embeddings e o seu ângulo morto

Um segundo modelo — um modelo de embedding, não aquele com que conversa — transforma cada fragmento num vetor de algumas centenas a alguns milhares de números. Os textos de sentido próximo aterram perto uns dos outros. A sua pergunta recebe o mesmo tratamento, e a procura passa a ser geometria: devolver os fragmentos mais próximos.

Feito de forma exaustiva isso é lento, por isso os sistemas reais usam um índice aproximado — HNSW é o mais comum, um grafo navegável que chega a uma boa resposta sem visitar todos os pontos. Troca um pouco de cobertura por ordens de grandeza de velocidade, e em pgvector é um índice de uma linha.

Eis o ângulo morto que ninguém menciona no argumentário. A pesquisa semântica é *apenas* semântica. Peça um número de fatura exato, um apelido, uma versão de biblioteca, um nome de variável — os casos em que conhece a cadeia precisa — e a similaridade vetorial entregar-lhe-á de bom grado cinco coisas que *falam* desse tema e não aquela que contém a cadeia.

É por isso que um índice por palavras-chave, BM25 ou a pesquisa de texto integral de uma base de dados, não é a abordagem antiga que os vetores vieram substituir. É a metade em que os vetores são maus.

Pesquisa híbrida e reranking

Um pipeline de recuperação sério corre as duas pesquisas e funde-as. A fusão padrão é a reciprocal rank fusion: cada resultado é pontuado pelo seu *rank* em cada lista e não por uma pontuação bruta, o que contorna o facto de uma distância de cosseno e uma pontuação BM25 não serem medidas na mesma unidade e não se poderem somar.

Segue-se a etapa que produz a maior parte da qualidade visível, e que muitos produtos saltam porque custa computação. A fusão dá-lhe uns trinta candidatos. Um reranker cross-encoder lê a pergunta e cada candidato *em conjunto*, e pontua até que ponto aquele responde a esta. É muito mais exato do que comparar dois vetores fabricados independentemente, e demasiado lento para correr sobre todo o acervo — que é exatamente por isso que corre em último, sobre uma lista curta.

Um aviso se trabalha em mais do que uma língua. Ambas as etapas dependem de modelos, e muitos modelos de embedding e de reranking são pensados primeiro para o inglês. Um pipeline com boas pontuações em inglês pode degradar-se silenciosamente em francês ou alemão, e vai viver isso como «esqueceu-se», e não como «o reranker foi treinado na distribuição errada». Se não trabalha em inglês, verifique que os modelos são genuinamente multilingues — multilingual-e5 é uma dessas famílias.

Quando passámos o nosso próprio pipeline da pesquisa vetorial simples para a fusão híbrida mais um cross-encoder multilingue, o mean reciprocal rank no nosso conjunto de avaliação melhorou 139%. Tome esse número pelo que é: a nossa medição, nos nossos dados, com a nossa fragmentação. Diz que a etapa vale a pena; não é um número que possa esperar reproduzir noutro corpus.

As quatro formas como isto falha

1. Nunca chegou a ser guardado. A falha mais frequente, e de longe. Nada na cadeia de recuperação consegue encontrar um facto que nunca foi escrito, e a extração automática deixa passar coisas.
2. Sem limiar. Se o sistema devolve sempre os seus cinco melhores resultados, então quando nada de pertinente existe devolve cinco coisas fora do tema — e o modelo, complacente, integra-as. Um piso de similaridade que não devolve nada é uma funcionalidade, e a sua ausência explica por que razão alguns assistentes se lembram mal com toda a confiança.
3. Contradições desatualizadas. Mudou de cidade; o facto antigo e o novo estão ambos no acervo, ambos recuperáveis. Sem ponderação por recência nem substituição explícita, o modelo pode escolher qualquer um dos dois.
4. O problema da agulha. Identificadores exatos, num sistema puramente vetorial. Ver acima.

O que perguntar a um produto de memória

Cinco perguntas, e cada uma tem uma resposta factual que um fornecedor lhe dá ou esquiva:

• Pesquisa por palavras-chave além da vetorial, ou apenas vetorial?
• Existe uma etapa de reranking, e com que modelo?
• Existe um limiar de pertinência abaixo do qual não devolve nada?
• Os modelos de embedding e de reranking são multilingues, e avaliados na minha língua?
• Posso ver, editar e apagar uma memória individual — ou o acervo é opaco para mim?

A última não é sobre qualidade de recuperação, mas é aquela que lhe vai importar primeiro, na primeira vez que algo errado for retido a seu respeito.

O Pryzm corre fusão híbrida com um reranker cross-encoder multilingue e um limiar de pertinência, em PostgreSQL com índices HNSW, e cada memória é individualmente visível e apagável. A comparação com as alternativas está no nosso quadro.