Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
TL;DR: Quando o dado não é copiado para dentro do modelo nem usado em treinamento, a integração precisa buscar a informação no momento da pergunta. Isso muda requisitos de latência, exige política explícita de cache e obriga a tratar dado volátil de forma diferente de dado estável. Em compensação, elimina a sincronização paralela que sempre acaba desatualizada.
Incorporar. Treinar ou ajustar o modelo com dado da empresa. O conhecimento fica nos pesos, e a atualização exige novo treinamento.
Recuperar. Buscar a informação a cada consulta e entregá-la como contexto. O conhecimento fica na fonte, e a atualização é imediata.
Para dado corporativo que muda, a segunda forma é a que sustenta resposta correta. Saldo, status de pedido, chamado aberto e posição de estoque mudam em horas.
Orçamento de latência. A consulta agora inclui recuperação antes da inferência. Vale declarar uma meta por tipo de pergunta e medir cada etapa separadamente.
Política de cache por tipo de dado. Política interna e documentação mudam pouco e admitem cache longo. Saldo e status não admitem. A invalidação precisa ser explícita, e não herdada de um padrão único.
Tratamento de dado volátil. Para informação que precisa estar atualizada no segundo, a camada consulta a fonte diretamente em vez de usar índice, aceitando latência maior em troca de exatidão.
Disponibilidade das fontes. Se o ERP cair, a aplicação precisa informar a indisponibilidade em vez de responder com o que sobrou do índice.
O desenho baseado em cópia cria um segundo lugar onde o dado mora, com pipeline, janela de atualização e monitoramento próprios. Esse segundo lugar tende a divergir da origem em algum momento, e a divergência aparece em resposta errada sem aviso.
Recuperar na origem elimina essa classe inteira de problema. O que permanece é o índice de busca para conteúdo textual, que também precisa de estratégia de atualização, com escopo bem menor do que uma réplica completa.
| Aspecto | Cópia para o modelo | Recuperação na consulta |
|---|---|---|
| Atualidade | Congelada no treino | Estado atual |
| Permissão por pessoa | Difícil de aplicar | Aplicável na recuperação |
| Custo de atualização | Novo treinamento | Nenhum |
| Exposição do dado | Dentro dos pesos | Trecho na consulta |
| Latência | Menor | Maior, com etapa de busca |
Uma varejista tentou o caminho de ajuste fino com o catálogo de produtos e as regras de promoção, buscando respostas rápidas para o time de loja.
O modelo ajustado respondia bem sobre o catálogo do mês do treinamento. Promoções mudavam toda semana, e em 20 dias as respostas já divergiam do sistema. Cada atualização exigia novo ciclo de treinamento e validação.
A reformulação manteve o modelo base e passou a recuperar catálogo e regra vigente no momento da pergunta, com cache de cinco minutos para catálogo e consulta direta para preço e estoque. O tempo de resposta subiu em torno de 400 milissegundos, e a divergência com o sistema desapareceu.
A decisão de cache fica mais simples quando cada fonte recebe uma faixa de volatilidade declarada no momento da modelagem:
| Faixa | Exemplos | Estratégia |
|---|---|---|
| Segundos | Saldo, estoque, status de pedido | Consulta direta à fonte, sem cache |
| Minutos | Fila de atendimento, posição de entrega | Cache curto com invalidação por evento |
| Dias | Cadastro, catálogo, condição comercial | Cache com invalidação por mudança |
| Meses | Política interna, manual, contrato assinado | Indexação com controle de versão |
| Imutável | Histórico fechado de períodos anteriores | Materialização completa |
Sem essa classificação, o time acaba adotando um TTL único que é curto demais para conteúdo estável e longo demais para dado crítico, insatisfatório nas duas pontas.
O critério é a taxa de mudança do dado, e não a frequência da pergunta.
Recuperar na origem cria uma dependência operacional que precisa de comportamento definido. Três opções, em ordem de preferência:
Informar a indisponibilidade. A resposta declara que determinada fonte não respondeu e o que ficou de fora.
Responder com cache marcado. Usar o último valor conhecido, com a data explícita na resposta.
Recusar a consulta. Para perguntas críticas em que responder com dado parcial é pior que não responder.
O que nunca deve acontecer é a via silenciosa, em que a aplicação responde com o que conseguiu sem sinalizar a ausência.
Quando o dado não é usado para treino, três cláusulas precisam estar escritas: ausência de uso do conteúdo enviado para treinamento, prazo de retenção do conteúdo com preferência por retenção zero, e região de processamento.
Vale confirmar o que vale para o plano contratado, porque a política pública de um provedor pode diferir do que se aplica a cada tipo de conta. Essa verificação costuma ser pedida por segurança e é rápida de obter por escrito.
Um Company Brain trabalha assim por desenho: o dado permanece na origem e é recuperado no momento da pergunta, sem cópia para dentro do modelo.
Não. Continua útil para formato, tom e comportamento em tarefas repetitivas. O que ele não resolve é conhecimento factual que muda.
Em consulta interativa, costuma ficar entre algumas centenas de milissegundos e poucos segundos, dependendo da fonte. Recorte bem feito compensa parte disso, porque reduz o tempo de inferência.
Pode ser materializado e indexado sem preocupação, com atualização apenas na entrada de novos períodos.
Fale com um especialista da Strattum sobre latência, cache e volatilidade de dado na sua arquitetura de IA.