TL;DR: Um engenheiro do Google desenvolveu um sistema Deep Research que supera o RAG tradicional, automatizando consultas técnicas complexas através de um processo de três etapas que extrai questões, realiza pesquisas em paralelo e agrega os resultados em respostas coerentes.

Takeaways:

• O Deep Research supera as limitações do RAG tradicional, permitindo processar consultas complexas e multifacetadas que envolvem múltiplas fontes de dados.
• A arquitetura do sistema consiste em três etapas principais: entendimento da solicitação, pesquisa paralela em múltiplas fontes e agregação dos resultados.
• O sistema utiliza prompts específicos com temperatura ajustada do LLM e schemas tipados para manter a qualidade e rastreabilidade das informações.
• Combina busca vetorial no Firestore com a API Programmable Search Engine do Google para obter documentação atualizada sem reconstruir a base de conhecimento.
• O futuro do trabalho de conhecimento aponta para a automação de tarefas complexas através de sistemas Deep Research personalizados para contextos específicos.

Automatizando o Trabalho de um Engenheiro do Google: Como Construir um Sistema de Pesquisa Profunda Personalizado

Você já se perguntou como os profissionais de tecnologia de alto nível estão lidando com o crescente volume de informações e demandas técnicas? Imagine poder automatizar as partes mais demoradas do seu trabalho, como pesquisar e responder a questões técnicas complexas. É exatamente isso que um engenheiro do Google conseguiu fazer, e neste artigo, vou mostrar como você também pode implementar essa solução revolucionária.

O Que é Deep Research e Por Que Ele é Importante?

O Deep Research representa uma evolução significativa do RAG (Retrieval-Augmented Generation), sendo um padrão de design de aplicação GenAI versátil para resolver tarefas complexas que o RAG padrão simplesmente não consegue lidar. Quando falamos de consultas não específicas e multifacetadas, o RAG tradicional se mostra insuficiente.

“As consultas dos usuários são geralmente complexas e não específicas demais para o RAG lidar com elas”, como destacado por especialistas da área.

Por que isso importa? Três razões principais:

• O Deep Research é essencial para lidar com a complexidade crescente das demandas de informação atuais
• Implementações customizadas podem automatizar tarefas específicas de conhecimento que antes consumiam horas de trabalho
• Entender e personalizar o Deep Research é fundamental para engenheiros de IA e líderes na área que desejam se manter competitivos

De acordo com projeções recentes, o RAG tradicional se tornará obsoleto até 2025, principalmente devido à sua incapacidade de processar consultas complexas que envolvem múltiplas fontes de dados. A realidade é que o número e tipo de fontes de dados se tornaram tão complexos que uma abordagem padronizada como o RAG simplesmente não é mais suficiente.

Arquitetura Conceitual do Deep Research

O padrão Deep Research segue uma estrutura de três etapas principais que trabalham em conjunto para fornecer respostas abrangentes e precisas:

1. Entendimento e decomposição da solicitação do usuário – Esta fase inicial foca em compreender profundamente o que o usuário realmente precisa
2. Execução de um pipeline de pesquisa e recuperação paralela – Aqui, o sistema coleta informações de diversas fontes simultaneamente para maior eficiência
3. Agregação dos resultados da pesquisa – Na etapa final, todas as informações coletadas são combinadas para fornecer uma resposta completa e coerente

Essa arquitetura foi projetada especificamente para lidar com a complexidade e variedade de fontes de dados que encontramos no mundo real. Um dos aspectos mais críticos é a agregação eficaz dos resultados, que transforma dados brutos em informações úteis e acionáveis.

Quebrando a Solicitação do Usuário

Quando trabalhamos com Deep Research, o primeiro desafio é extrair as questões técnicas relevantes. No caso de um engenheiro do Google, isso envolve analisar transcrições de reuniões com clientes para identificar as perguntas que precisam ser respondidas.

Para fazer isso de forma eficiente, utilizamos prompts de texto simples como:

"Você é um assistente de IA ajudando a extrair questões técnicas do cliente de uma conversa entre um Engenheiro de Cliente do Google Cloud (CE) e um cliente."

Alguns pontos importantes nesta etapa:

• Cada questão extraída deve ser formatada como uma string simples e concisa
• O sistema deve ser flexível para se adaptar a diferentes tamanhos e formatos de transcrição
• A extração deve priorizar clareza e objetividade, sem adicionar complexidade desnecessária

Para garantir precisão, a temperatura do LLM (Large Language Model) deve ser mantida baixa. Além disso, ferramentas como dotprompt facilitam a definição de prompts com configuração, entrada e esquema de saída bem estruturados.

Pesquisa Paralela de Tarefas

Após a extração das questões, inicia-se a fase de pesquisa, cuja complexidade varia conforme o tamanho e tipo de base de conhecimento necessária. No exemplo do engenheiro do Google, duas fontes principais são utilizadas:

1. Firestore – Contendo chunks da documentação GCP (Google Cloud Platform)
2. API Programmable Search Engine do Google – Permitindo acesso a documentação atualizada sem reconstruir a base de conhecimento

A estrutura de resposta para cada tarefa de pesquisa é rigorosamente tipada:

const TaskResearchResponse = ai.defineSchema('TaskResearchResponse', z.object({
  answer: z.string(),
  caveats: z.array(z.string()),
  docReferences: z.array(z.object({
    title: z.string(),
    url: z.string(),
    relevantContent: z.string().optional(),
  }))
});

Esta estrutura tipada é crucial para manter o controle de quais documentos resultaram em quais insights, permitindo rastrear a origem das informações e fornecer referências precisas ao usuário final.

Recuperação de Documentos

A recuperação eficiente de documentos é o coração do sistema Deep Research. No Genkit, isso é feito através de plugins pré-construídos ou funções customizadas. No nosso exemplo, são definidos dois retrievers especializados:

1. Retriever do Firestore Vector Search – Utiliza uma ação server-side para buscar documentos similares através de busca vetorial
2. Retriever customizado de busca – Chama a API Programmable Search Engine e obtém o conteúdo das URLs resultantes

Um detalhe importante: a API Search Engine fornece apenas as URLs dos resultados, sendo necessário um passo adicional para buscar e processar o conteúdo dessas páginas. Além disso, é essencial aplicar uma limpeza básica ao conteúdo HTML bruto antes de transformá-lo em Genkit Documents para processamento posterior.

Sumarização das Respostas

Com os documentos relevantes recuperados, o próximo passo é resumir as respostas para cada questão de pesquisa. Isso é feito utilizando o Gemini 2.5, que preenche o esquema de resposta à questão de pesquisa.

O prompt de sumarização deve garantir que:

• A resposta responda claramente à questão técnica
• Sejam incluídos passos específicos ou configurações relevantes
• Quaisquer ressalvas importantes ou melhores práticas sejam destacadas

Para manter a precisão das respostas, a temperatura do modelo é mantida baixa. Além disso, referências a seções específicas da documentação são incluídas quando relevante, proporcionando ao usuário final a possibilidade de aprofundar seu conhecimento sobre o tema.

Agregação dos Resultados da Pesquisa

A etapa final do processo consiste em agregar os relatórios de pesquisa em um formato útil para os usuários. No caso do engenheiro do Google, isso significa formular um rascunho de e-mail conciso com respostas e recursos de documentação.

O prompt de agregação é especialmente detalhado:

"Gere um e-mail profissional de acompanhamento para o cliente com base nos resultados da pesquisa técnica."

Alguns aspectos importantes desta etapa:

• Uma abordagem de prompting multi-shot (com múltiplos exemplos) é usada para ajustar o estilo de escrita
• O e-mail começa com uma referência à reunião e um breve resumo
• Cada questão técnica é abordada de forma concisa e com links para a documentação relevante

Nesta fase, a temperatura do modelo é configurada mais alta para permitir flexibilidade no estilo de escrita, mas mantendo a concisão e o nível de detalhe alinhados com o exemplo fornecido no prompt.

Conclusão: O Futuro do Trabalho de Conhecimento

O Deep Research representa uma evolução significativa em relação ao RAG tradicional, com potencial para acelerar ou automatizar completamente tarefas intensivas em conhecimento. A eficácia prática de qualquer sistema Deep Research depende de três fatores principais:

1. A relevância das bases de conhecimento acessadas
2. A qualidade da recuperação e processamento das informações
3. A customização do relatório final para atender às necessidades específicas dos usuários

Em um futuro próximo, veremos muitas tarefas de trabalhadores do conhecimento sendo automatizadas usando aplicações Deep Research. O diferencial estará na capacidade de customizar esses sistemas para casos de uso específicos e adaptar o formato de saída às necessidades particulares de cada contexto.

Você já pensou em quais tarefas do seu trabalho poderiam ser automatizadas com um sistema Deep Research personalizado? Compartilhe nos comentários suas ideias e experiências com automação de tarefas baseadas em conhecimento.

Fonte: Jakob Pörschmann. “I’m Automating My Job as a Google Engineer with a Custom-Built Deep Research System – Here’s How to Build It”. Disponível em: Medium.