Executando verificação de segurança...
10

O Problema da Memória em LLMs (IA)

Faz um tempo que venho estudando o uso de LLMs, agentes, frameworks, MCPs (Model Context Protocol) e tudo o que acompanha o ecossistema de IA como ferramenta de negócio. No entanto, algo que me chama a atenção é a questão da memória.

Pelo que entendi, a memória em sistemas atuais é muito mais uma questão de decidir quais dados passar para o "cérebro" da IA raciocinar do que o armazenamento de informações em si. Ou seja: memória em LLMs, hoje, nada mais é do que gerenciamento de contexto.

A Limitação da Proximidade Matemática

A forma como os dados são coletados de um banco vetorial parece, às vezes, como tentar ensinar alguém usando apenas um dicionário de termos isolados. Em vez de entender o contexto real do que aconteceu (como um ser humano) ou se basear em bilhões de parâmetros (como o treinamento base do LLM), as memórias atuais baseiam-se na proximidade matemática (vetorial).

Se eu perguntar "Qual é o meu nome?", o sistema buscará contextos similares a "meu nome". Se no banco de dados existir a informação sobre o meu cachorro, o RAG pode acabar entregando isso ao LLM, pois a distância vetorial entre "Meu nome é Wesley" e "O nome do meu cachorro é Bob" é curta. Isso resulta em desperdício de janela de contexto e possíveis alucinações.

O ser humano não "decide" ativamente cada bit do que armazenar; nós guardamos o que é relevante e criamos associações. Já a IA "lembra" apenas enquanto houver espaço no contexto; depois disso, ela simplesmente esquece.

O Custo da Inteligência na Memória

Projetos como o MemGPT tentam resolver isso usando um LLM para decidir o que deve ou não ser persistido e para realizar a busca. Parece uma solução viável, mas quando transportamos isso para uma aplicação de voz ou um humanoide, o fluxo se torna complexo e lento:

  1. Usuário fala -> Capturado por um STT (Speech to Text).
  2. LLM avalia se precisa de memória de longo prazo.
  3. MemGPT (ou outro LLM) realiza a busca das informações.
  4. LLM Principal gera a resposta integrando esses dados.
  5. TTS (Text to Speech) transforma a resposta em fala.
  6. MemGPT usa um LLM novamente para verificar se aquela interação deve ser salva.

Será que essa é realmente a melhor forma de estruturar a memória?

Frameworks como LangChain, Agno e a própria Google oferecem soluções de memória semântica. Outros papers e projetos sugerem o uso de Grafos de Conhecimento (GraphRAG) como memória, permitindo associações mais ricas, mas essa abordagem ainda não se popularizou totalmente devido à sua complexidade.

Estamos realmente criando "memória" ou apenas sistemas de busca cada vez mais complexos para compensar a falta dela?

Carregando publicação patrocinada...
4

Vetores medem similaridade semântica, mas não relevância lógica ou hierarquia de fatos. Isso é a falácia da proximidade vetorial (RAG tradicional).

É por isso que o mercado está se movendo para o Hybrid Search (Busca Vetorial + Busca por Palavras-chave/BM25) e, mais recentemente, para o Reranking. O Reranker é um modelo menor que analisa os 10-20 resultados da busca vetorial e os reordena por relevância real antes de enviar ao LLM.

Eu já fiz bons experimento com GNN (Graphic Neural Network) com muito bons resultados, mas muito ajuste manual, difícil de chegar em solução generica.

2

bom dia, sr

o sr acha que uma bem escrita heurística já seria o suficiente para aproveitar o potencial dos dados na busca?
oq acha da capacidade de RegEx? uma LLM sozinha poderia chamar a execução de um grep e encontrar uma info em um ou mais corpos de texto.
e oq vc acha de nós treinarmos uma LLM? assim, ela já compacta as infos na forma de pesos, mesmo

1

Voce tocou em 3 pontos diferentes da engenharia de dados: a eficiência bruta (Heurísticas/RegEx), a inteligência de busca (LLM como ferramenta) e a natureza do aprendizado(Finetuning).

Quanto a heurística (regras de negócio, filtros de metadados, priorização por data ou relevância categórica) ela é, muitas vezes, superior ao RAG puro.
Se você sabe que o usuário sempre busca por "contratos ativos", uma heurística que filtre o banco de dados antes da busca vetorial elimina 90% do ruído. Elas falham na "cauda longa" da linguagem humana. Onde o usuário usa sinônimos ou conceitos abstratos, a heurística quebra. Ela não substituem a busca semântica, mas pode ser a primeira camada (Pre-filtering O erro de muitos projetos é jogar tudo para o vetor sem aplicar o conhecimento de negócio que já possuem.

Usar uma LLM para gerar e executar grep ou RegEx é uma forma subestimada de precisão cirúrgica. O RegEx é determinístico. Se você precisa encontrar um padrão (um CPF, um código de produto, uma data específica), o RegEx é 100% eficaz, enquanto o LLM sozinho pode alucinar o formato. Imagina um agente de IA que, ao receber uma pergunta, decide: "Para responder isso, preciso de um padrão específico, vou rodar um script de busca no diretório X". Isso é o que chamamos de Tool Use (ou Function Calling). A RegEx não entende intenção. Se você buscar "problemas técnicos" via RegEx, perderá mensagens que dizem "o sistema está instável", a menos que preveja todas as variações.

A RegEx é uma ferramenta de extração, não de compreensão. Funciona maravilhosamente bem como uma "ferramenta" que o Agente decide usar quando a busca semântica é vaga demais.
E ai vem a questão de treinar (ou fazer Finetuning) de uma LLM para ela "decorar" os dados parece a solução definitiva, mas tem armadilhas perigosas:Lenta e cara, precisão média (tende a misturar fatos e alucinar), privacidade difícil (o dado está "fundido" no modelo).

Você já tentou implementar algum tipo de Fine-tuning para testar.

1

sim, sr.

porém, nenhum deles é bala de prata, mesmo. cada um tem um propósito.

oq eu falei aqui ou q o sr falou já é o famoso CRUD básico, literal. adicionar boa coleta de dados, curadoria, ferramentas que economizem recursos, utilitários já consagrados, tudo isso é oq diferencia um CRUD de facul de um sistema melhorzinho.

porém, o segredo está em voltar à matemática, estatística, e estudar.

1
TécnicaÉ... (parte boa)Mas tem... (parte ruim)
RAGPreciso e atualizávelLatente e ruidoso
MemGPTPersistente e econômicoComplexo e lento
GraphRAGRico em relacionamentosCaro e mantível
Fine-TuningCustomizado e eficienteOverfitting e catastrófico
MIRASAdaptável em tempo realComputacional e complexo
ReasoningBankEvolutivo e reutilizávelDependente de histórico