Jeff Dean, do Google, explica como melhorar a engenharia de contexto em sistemas de IA

Executivo do Google descreve como recuperação de dados, ferramentas, memória e agentes podem tornar sistemas de IA mais capazes do que a escolha isolada de um modelo

Diego IvoDiego Ivo5 min
Compartilhar:

Jeff Dean, cientista-chefe do Google DeepMind e Google Research, afirmou que a escolha de um modelo representa apenas uma parte da construção de sistemas de inteligência artificial. Em entrevista ao Y Combinator, ele concentrou a explicação nos componentes que fornecem informações e ações ao modelo.

A conversa abordou engenharia de contexto, recuperação de dados, memória, uso de ferramentas e coordenação de agentes. Segundo Dean, esses elementos permitem apresentar ao modelo informações diretamente relacionadas ao problema, em vez de depender somente do conhecimento incorporado durante o treinamento.

O executivo também descreveu um processo de melhoria baseado na observação de falhas. Diretrizes, habilidades e ferramentas podem ser ajustadas quando o sistema não resolve uma tarefa, criando um ciclo de avaliação que não exige alterar diretamente os parâmetros do modelo.

Modelo representa uma parte do sistema completo

Diana Hu, sócia do Y Combinator, perguntou se o avanço da IA estava deixando de depender apenas de modelos maiores e passando a incluir tudo o que opera ao redor deles. A pergunta citou recuperação, ferramentas, memória e agentes como componentes desse conjunto.

Dean concordou com essa formulação e disse que o objetivo é construir um sistema geral capaz de resolver problemas. O modelo precisa reconhecer ferramentas disponíveis, recuperar informações relevantes e utilizar um histórico de dados obtidos em tarefas anteriores quando esse material contribuir para a execução atual.

A declaração desloca a comparação do modelo isolado para a configuração completa. Na entrevista, Dean não apresentou uma classificação de modelos nem afirmou que todos produzem resultados equivalentes. A explicação tratou das condições necessárias para que um sistema execute uma classe específica de problemas.

Contexto direto torna informações mais claras para o modelo

Dean comparou o contexto fornecido durante uma tarefa aos dados usados no treinamento. O treinamento reúne trilhões de tokens em parâmetros, enquanto o contexto apresenta uma seleção menor de informações diretamente visíveis e relacionadas ao caso que está sendo processado naquele momento.

Segundo o executivo, essa diferença torna o material contextual mais claro para o modelo. O sistema pode identificar documentos, instruções e resultados anteriores sem precisar recuperar implicitamente toda a informação a partir dos parâmetros formados durante o treinamento.

O contexto, portanto, não se limita ao texto de uma instrução. A descrição inclui documentos recuperados, memória de trabalhos anteriores, resultados produzidos por ferramentas e informações adicionadas por outros agentes ao longo da execução.

Ferramentas ampliam as ações disponíveis durante a tarefa

A entrevista também separou conhecimento e capacidade de ação. Um modelo pode reconhecer uma tarefa, mas ainda precisa de ferramentas adequadas para consultar dados, executar etapas e verificar resultados fora da própria geração de texto.

Dean citou a necessidade de entender quais ferramentas estão disponíveis e quais ajudam em cada fase do problema. Essa seleção antecede chamadas específicas e permite que o sistema escolha recursos diferentes conforme a informação necessária ou o tipo de operação exigida.

O processo depende de instruções sobre uso, limites e retorno de cada ferramenta. Sem essa descrição, a disponibilidade técnica de uma integração não informa ao modelo quando ela deve ser acionada nem como interpretar o resultado recebido.

Problemas complexos são divididos em sequências de operações

Para tarefas maiores, Dean descreveu a decomposição do problema em uma sequência de chamadas de ferramentas. O sistema identifica etapas, executa operações, incorpora os resultados ao contexto e decide qual ação deve ocorrer em seguida.

A entrevista incluiu ainda a possibilidade de testar abordagens diferentes e comparar quais funcionam. Essa etapa exige critérios de avaliação, porque a geração de várias alternativas não determina sozinha qual delas atendeu às condições estabelecidas para o trabalho.

A coordenação pode envolver um agente ou vários agentes com responsabilidades distintas. Dean classificou a organização desses sistemas complexos como uma área de importância crescente, especialmente quando tarefas combinam recuperação, execução e avaliação.

Falhas indicam quais informações e habilidades estão ausentes

Na parte prática da entrevista, Hu perguntou como os profissionais podem melhorar em engenharia de contexto. Dean recomendou usar modelos, estruturas de execução e ferramentas para resolver problemas reais e observar os pontos em que o conjunto falha.

As falhas permitem identificar se o sistema recebeu informação insuficiente, escolheu uma ferramenta inadequada ou não tinha instruções para uma operação. A correção ocorre sobre a configuração disponível ao usuário, sem depender de acesso ao treinamento ou aos parâmetros internos do modelo.

Dean afirmou que diretrizes melhores e habilidades específicas podem fazer o modelo resolver uma classe de problemas com mais consistência. Nesse uso, uma habilidade registra como empregar determinada ferramenta e quais procedimentos devem ser seguidos durante a execução.

Avaliação orienta melhorias no sistema

O ciclo descrito combina execução, observação e ajuste. Depois de identificar uma falha, a equipe altera informações, diretrizes ou ferramentas e repete a tarefa para verificar se o novo arranjo produz o resultado esperado.

Essa lógica aproxima a engenharia de contexto da orquestração, porque diferentes fontes e ações precisam ser coordenadas ao redor de um objetivo. O modelo continua relevante, mas passa a operar dentro de um sistema com critérios e recursos definidos.

A avaliação também evita atribuir toda falha à capacidade geral do modelo. O erro pode resultar de contexto incompleto, recuperação inadequada, ferramenta indisponível ou instrução ambígua, fatores que podem ser inspecionados separadamente.

Acesso depende de modelos e interfaces disponíveis

Hu observou que a engenharia de contexto pode ser praticada sem os recursos necessários para treinar um modelo. O trabalho pode começar por uma interface de programação de aplicações, pela recuperação própria de informações e por ferramentas conectadas ao sistema.

A entrevistadora citou uma API do Gemini como exemplo de acesso. A menção não anunciou nova disponibilidade nem restringiu a abordagem ao produto do Google. Outros modelos com suporte a contexto e ferramentas podem compor configurações semelhantes.

Conforme a entrevista completa de Jeff Dean, a melhoria ocorre ao observar o sistema em funcionamento e ajustar os componentes que fornecem informação e capacidade de ação. A recomendação se refere ao processo de construção, não a uma garantia de desempenho.

Cadastre-se gratuitamente para ver o conteúdo

Preencha o formulário para acessar o conteúdo completo.

Grátis. Sem spam. Cancele a qualquer momento.

Diego Ivo

Escrito por Diego Ivo

Diego é CEO da Conversion, agência Líder em SEO e especializada em Search. Possui mais de uma década de experiência no mercado digital e é um dos principais experts no Brasil em SEO.

Comentários

Deixe um comentário

Receba o melhor conteúdo de SEO & Marketing em seu e-mail.

Assine nossa newsletter e fique informado sobre tudo o que acontece no mercado