Como construir uma camada de contexto e um cérebro corporativo com LLMs

Como construir uma camada de contexto e um “cérebro corporativo” com LLMs

Toda empresa que adota LLMs chega à mesma ideia: “e se o modelo soubesse tudo o que nós sabemos?” Os esquemas do data warehouse, as páginas do Notion, as threads do Slack onde as decisões realmente acontecem. A versão demo é um projeto de fim de semana — chunk, embed, cosine similarity, prompt. Mas ela quebra silenciosamente em produção. Este artigo mostra o que realmente é necessário para construir uma camada de contexto que funciona em escala.

Não é só um banco vetorial

Uma camada de contexto é um sistema que continuamente mapeia fontes de dados heterogêneas em itens de contexto normalizados, indexa-os de múltiplas formas especializadas, compõe o subconjunto certo dentro de um orçamento de tokens no momento da consulta, e aprende com curadoria e uso — tudo com isolamento por inquilino (multi-tenancy), permissões, atualização e custo como restrições de primeira classe.

O autor Tomer Mesika detalha seis partes essenciais de um sistema de produção real:

1. Mapeamento contínuo

A ingestão não é um job em lote — é um loop de reconciliação que nunca termina. Tabelas são removidas, canais arquivados, permissões revogadas. Um “cérebro” uma semana desatualizado é pior que inútil. Use datamaps declarativos (hierarquias tipadas) em vez de scripts por fonte — uma vez que a hierarquia é descrita como dados, um único motor de mineração serve warehouses SQL, wikis e trackers sem ramificação por vendor.

2. Indexação múltipla

Não existe um único índice que sirva um cérebro corporativo. Você precisa de: verdade relacional (Postgres por inquilino), índice de palavras-chave (BM25 para busca lexical — “dim_customers_v3” não é encontrado por similaridade semântica), índice vetorial (coleções separadas para descrições e código SQL), e um grafo de conhecimento para relações estruturais.

3. Recuperação como orquestração

“Recuperar top-k e colar” não sobrevive a contexto heterogêneo. Uma pergunta sobre receita pode precisar de um esquema de warehouse, um exemplo SQL validado, uma página wiki definindo “receita” e uma thread sobre um problema de dados conhecido — cada um em um índice diferente. A solução é um motor de composição com grafo dinâmico de estratégias executadas em paralelo.

4. Ensino e aprendizado

O conhecimento mais valioso nunca foi escrito onde um conector pode alcançar. Usuários precisam adicionar notas (“esta tabela conta duplicado antes de 2024”), arquivos e consultas salvas — itens de contexto com a mesma identidade, ACL e ciclo de vida dos itens minerados, e que sobrepõem metadados minerados em caso de conflito.

5. Responder é agir

Uma pergunta merece uma resposta, não uma lista de leitura. O agente executa SQL contra o warehouse, chama APIs, busca dashboards. Credenciais de execução devem ser separadas das de mineração, e qualquer escrita precisa de aprovação humana com checkpoint durável.

6. Gateway de LLM

Provedores falham. Você precisa de um gateway com fallback entre modelos, cache de respostas idênticas, e orçamento de tokens por camada. Modelos pequenos para filtragem, grandes apenas quando necessário.