Memória semântica pgvector: por que IA de RH precisa lembrar.

Faça este teste com qualquer chatbot de IA genérico: pergunte sobre seu time hoje, depois volte daqui a uma semana e pergunte de novo. A resposta vai vir do zero, sem contexto, sem histórico, sem memória do que você falou antes. Pra produtividade pessoal, tudo bem. Pra gestão de pessoas, isso é inutilizável.

Quando um gestor pergunta à Belle sobre o desenvolvimento de um liderado, a IA precisa lembrar: os comentários da última avaliação 360°, o tema que apareceu na pulse de março, o feedback de redirecionamento que o próprio gestor escreveu em janeiro, o gap de competência que ficou aberto no PDI anterior. Sem isso, a IA vira oráculo aleatório. Com isso, vira ferramenta de gestão.

A Belle usa pgvector + embeddings + RAG pra ter memória de longo prazo das interações de cada colaborador. Quando você pergunta algo, ela busca por similaridade semântica os fragmentos relevantes do histórico e responde com contexto real, não com alucinação.

O que é memória semântica

Memória semântica é a capacidade de armazenar informação de forma que ela possa ser recuperada por significado, não por palavra-chave exata. Se você guarda "a Ana foi excelente na conversa difícil com o cliente Y" e depois pergunta "quem teve boa atuação em situações de pressão?", a busca tradicional não acha. A busca semântica acha porque entende que "excelente em conversa difícil" e "boa atuação em situações de pressão" estão semanticamente próximas.

Tecnicamente, cada pedaço de texto é convertido num vetor numérico de centenas de dimensões (embedding), gerado por modelo de linguagem. Textos semanticamente parecidos resultam em vetores próximos no espaço vetorial. A busca acontece calculando distância (cosseno ou L2) entre vetores.

Por que pgvector

pgvector é uma extensão do PostgreSQL que adiciona tipo de coluna vetorial e operadores de similaridade. A escolha por ele (versus banco vetorial dedicado tipo Pinecone ou Weaviate) foi deliberada:

• Mesma transação: salvar comentário SBI e gerar embedding acontecem na mesma transação SQL. Sem inconsistência entre dois bancos.
• Mesmo backup: a memória vetorial faz parte do backup do PostgreSQL normal. Não precisa de pipeline separado.
• Mesma autorização: a coluna vetorial respeita as mesmas regras de tenant (cada empresa só vê seus dados) que o resto do schema.
• Performance suficiente: pra cargas até dezenas de milhões de embeddings (que é onde 99% das operações de RH estão), pgvector com índice IVFFlat ou HNSW resolve em <100ms.

O que entra na memória da Belle

Cada interação que vira contexto futuro é convertida em embedding e armazenada com metadados:

• Comentários SBI das avaliações 360° (validados pelo Quality Gate)
• Respostas abertas de pulse survey (anonimizadas quando configuradas como anônimas)
• Conversas anteriores entre gestor e Belle sobre cada colaborador
• PDIs anteriores, gaps identificados, ações concluídas e abandonadas
• Resultados de testes comportamentais (DISC, Big Five, Schwartz, HEXACO)
• Sugestões de sucessão e fits calculados em ciclos anteriores

CREATE TABLE belle_memories (
  id BIGSERIAL PRIMARY KEY,
  company_id INT NOT NULL,
  employee_id INT NOT NULL,
  source_type TEXT NOT NULL,
  source_id BIGINT NOT NULL,
  content TEXT NOT NULL,
  embedding VECTOR(1536) NOT NULL,
  occurred_at TIMESTAMP NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX ON belle_memories
  USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);

Como o RAG funciona aqui

RAG (Retrieval-Augmented Generation) é o padrão: antes de gerar resposta, busca contexto relevante e injeta no prompt. No caso da Belle:

1. Gestor faz pergunta: "Como o Pedro evoluiu nos últimos 6 meses em comunicação?"
2. Belle vetoriza a pergunta: embedding do texto da pergunta gerado em ~10ms.
3. Busca por similaridade: SELECT no banco que retorna os 8-12 fragmentos mais próximos semanticamente, filtrados por employee_id=Pedro e janela de 6 meses.
4. Monta o prompt: pergunta original + fragmentos recuperados (com data e fonte) viram contexto pro LLM.
5. Gera resposta ancorada: LLM responde citando os fragmentos. Belle inclui "em janeiro você comentou X" e "na pulse de março apareceu Y", com link clicável pra origem.

Anti-alucinação porque a fonte está exposta

A grande diferença pra um chatbot genérico é que a resposta da Belle nunca é "do nada". Cada afirmação cita o fragmento de origem com data. Se a Belle disser "Pedro melhorou em comunicação nos últimos 3 meses", o gestor consegue clicar e ver exatamente os 4-5 comentários SBI que sustentam a afirmação. Se a inferência estiver errada, a fonte está lá pra contestar. Não tem "a IA disse" sem rastro.

Isso muda profundamente a relação gestor-IA. Vira ferramenta de gestão auditável, não oráculo.

LGPD e direito ao esquecimento

Memória de longo prazo em RH levanta questão LGPD imediata. A Belle é construída com 3 garantias:

• Escopo por tenant: company_id no índice. Embedding de uma empresa nunca é recuperado por outra, nem mesmo por similaridade.
• Anonimização configurável: pulse anônima vira embedding sem employee_id direto, com identificador hash que só serve pra agregação.
• Direito ao esquecimento: pedido de anonimização do colaborador apaga todos os embeddings associados ao employee_id, junto com os campos originais. Não há resíduo recuperável.

O resultado prático

Gestor que usa Belle há 6 meses tem assistente que conhece o time. Não precisa contar contexto toda vez, não precisa procurar comentário antigo, não precisa lembrar de cabeça quem disse o quê em qual pulse. Belle traz à tona o histórico relevante na hora certa, com fonte rastreável. Continuidade real, em vez de chatbot amnésico.

É a diferença entre "uma IA" e "a IA de RH dessa empresa".