IA local (RAG): quando compensa#

O RAG local é a busca semântica rodando nesta máquina, na CPU, sem GPU e sem chamada externa. Ele é o que permite encontrar o trecho certo da base sem gastar token — e é também o que pode deixar o servidor lento, se as duas decisões abaixo forem tomadas no escuro.

Antes de começar#

O RAG local não cabe no servidor mínimo. Com 2 núcleos e 4 GB, o motor de embeddings não entra junto com o resto. O ponto em que ele funciona sem apertar é o servidor recomendado: 4 núcleos e 8 GB. Veja Requisitos de instalação.

As duas decisões que esta tela expõe#

Antes, as duas eram tomadas sem ninguém ver.

1. Qual modelo de embedding. Era uma variável de ambiente, com um padrão treinado em inglês rodando sobre uma base escrita em português — o que degrada a busca sem gerar erro nenhum. Na tela, o catálogo é explícito, com o tamanho em disco e a memória necessária de cada opção: a escolha é feita vendo o preço, e não descoberta quando o servidor começa a travar.

2. Quanta CPU a busca pode usar. O motor de inferência toma todos os núcleos por padrão. No mesmo servidor rodam o Asterisk e o MongoDB — e um lote de embeddings usando a máquina inteira aparece do outro lado como áudio picotado numa ligação. Esse é o sintoma clássico, e ele não parece um problema de IA.

Como fazer#

1. Vá em Configurações → Inteligência artificial, aba do RAG local.
2. Veja o catálogo de modelos. Cada um mostra o tamanho em disco, a memória necessária e o idioma para o qual foi treinado.
3. Escolha um modelo treinado para português, ou multilíngue. Modelo em inglês sobre base em português piora a busca sem avisar.
4. Baixe o modelo. A tela mostra o progresso.
5. Limite quantos núcleos a busca pode usar. Deixe folga para o resto do servidor.
6. Indexe a base e teste com perguntas reais.

Trocar de modelo obriga a reindexar#

Vetores de modelos diferentes não são comparáveis. Trocar o modelo sem reindexar a base produz busca que retorna resultados sem sentido — e, de novo, sem erro na tela.

Reindexação pesada durante o horário de pico compete com o atendimento. Faça-a fora do horário, ou no servidor folgado.

Quando o RAG local compensa#

Compensa quando o volume de perguntas repetidas é alto, quando a base é grande e estável, e quando o servidor tem folga. O ganho é direto: cada pergunta respondida localmente é uma pergunta que não vira token.

Não compensa quando o servidor é o mínimo, quando o volume é baixo (a economia não paga a memória ocupada), ou quando a base ainda está sendo escrita e muda todo dia — cada mudança pede reindexação.

A memória que a tela mostra é medida, não estimada#

O valor de memória exibido no painel do RAG é a diferença de consumo do processo antes e depois de carregar o motor, nesta máquina. Não é número de catálogo.

Se algo der errado#

Ligações com áudio picotado depois de ligar o RAG. É a CPU. Reduza o número de núcleos que a busca pode usar.

A busca devolve resultados que não têm relação com a pergunta. Confira se o modelo foi trocado sem reindexar, e se ele foi treinado para português.

O servidor começou a reciclar processos. Falta de memória. Confira o modelo escolhido: os maiores pedem bem mais, e num servidor virtual a memória pode ter sido retomada pelo hipervisor — veja Requisitos de instalação.

O download do modelo não termina. Confira o espaço em disco e o acesso à rede a partir do servidor.

A busca ficou lenta depois de a base crescer. É esperado até certo ponto. Se ficou inviável, o caminho é um modelo mais eficiente ou mais CPU — não desligar a indexação.