Deep Research é um workflow de verificação

Deep research fica poderoso quando se comporta menos como um chatbot e mais como um sistema de verificação.

Essa distinção importa. Um chatbot responde à pergunta que está na frente dele. Um sistema de verificação reconstrói a pergunta, mapeia as evidências, questiona as premissas, checa o estado atual e se recusa a tratar um parágrafo bem escrito como prova.

A maior parte da pesquisa com IA ainda parece a primeira versão. Peça a um modelo um panorama de mercado, uma análise competitiva, um resumo técnico ou um memorando estratégico, e normalmente ele vai produzir algo plausível. Vai encontrar as fontes óbvias. Vai resumir com clareza. Vai escrever com confiança. Para trabalhos de baixo risco, talvez isso baste.

Para trabalhos de alto risco, plausibilidade é justamente o modo de falha.

O workflow de Deep Research que uso foi desenhado em torno desse problema. Seu valor não é gerar relatórios mais longos. Não é usar mais agents pela complexidade em si. A alavancagem vem de um loop operacional repetível: descobrir contexto, mapear afirmações, coletar evidências, questionar o rascunho, corrigir o artefato e validar o sistema inteiro antes de dar o trabalho por concluído.

A mudança importante é esta: a saída não é tratada como um memorando estático. É tratada como um grafo de evidências vivo.

A pesquisa comum para cedo demais

Pesquisa com um único agent é rápida, e essa velocidade é útil. Mas ela tem fraquezas previsíveis.

Ela perde o contexto do sistema. Um chat novo não conhece automaticamente a árvore de arquivos, as anotações, os datasets, os critérios de aceite ou o formato do artefato final. Ele parte do prompt visível, não do ambiente operacional completo.

Ela aceita afirmações desatualizadas. Uma fonte que estava correta antes pode estar errada agora. Uma nota de QA pode descrever um problema que já foi resolvido. Um dataset gerado pode preservar um texto antigo depois que o artefato visível mudou.

Ela mistura evidência e interpretação. O modelo pode resumir uma afirmação técnica, uma estimativa de mercado ou um documento-fonte de um jeito que soa certo, mas silenciosamente altera o alcance da afirmação.

Ela para no texto. Mesmo quando identifica um problema, o trabalho muitas vezes termina em comentário: "Esta citação parece desatualizada" ou "Esta seção deveria ser revisada." Isso é útil, mas não é verificação. Verificar significa que o documento, os dados, as citações, as notas e o estado de validação concordam entre si depois da correção.

É por isso que uma pesquisa superficial pode parecer pronta enquanto continua frágil. O documento final se lê bem, mas a cadeia de afirmações por baixo dele nunca foi forçada a sobreviver a uma revisão.

Deep Research é a minha resposta a essa fragilidade.

O workflow

O workflow tem seis fases. Elas são simples, mas a ordem importa.

1. Descoberta de contexto

O primeiro passo não é escrever. É se orientar.

Antes de pesquisar externamente, o workflow busca em arquivos locais, notas, exportações de fontes, datasets e qualquer artefato de QA existente. O objetivo é evitar o problema da amnésia: começar do zero quando o workspace já contém contexto relevante.

Esta fase responde a perguntas como:

Que contexto já existe?
Quais afirmações são centrais para a entrega?
Quais fontes já estão anexadas?
Quais descobertas podem estar desatualizadas?
O que significa "pronto" para este artefato?

Essa última pergunta é fácil de pular. E é justamente onde boa parte da pesquisa com IA falha. Um memorando de pesquisa, um brief técnico, um dashboard e um apêndice não têm os mesmos critérios de aceite. O workflow precisa identificar o formato do artefato antes de conseguir julgar a qualidade do conteúdo.

2. Mapeamento de fontes e afirmações

Em seguida, o workflow mapeia o artefato como um sistema.

Numa leitura comum, você lê o texto. Numa leitura de verificação, você rastreia afirmações até as evidências. Quais afirmações dependem de quais IDs de fonte? Quais gráficos dependem de quais datasets? Qual apêndice repete uma afirmação do resumo executivo? Quais citações visíveis são geradas a partir de uma exportação de fonte?

É aqui que a entrega deixa de ser um documento e vira um grafo:

Afirmações
Fontes
Referências de fontes
Arquivos de dados
Notas
Apêndices
Entradas de fonte
Scripts de validação

Com o grafo visível, o desalinhamento fica mais fácil de pegar. Corrigir uma afirmação no documento principal não basta se a mesma afirmação desatualizada sobrevive num apêndice, num dado JSON, nas notas de fonte ou numa exportação gerada.

3. Pesquisa e verificação em paralelo

Só depois do mapeamento de contexto e de afirmações é que o workflow se ramifica.

Diferentes frentes de pesquisa podem trabalhar em paralelo: uma checando a cobertura das fontes, outra checando afirmações técnicas, outra checando números e premissas, outra checando metadados e o alinhamento das citações. A ideia não é criar teatro em torno de trabalho "multi-agent". A ideia é separar responsabilidades.

Quem reúne as fontes não deveria ser o único crítico da interpretação. O agent que checa IDs de fonte não deveria se distrair com a fluidez da narrativa. A frente que revisa afirmações técnicas deve poder dizer: "O texto está claro, mas a afirmação é forte demais."

O paralelismo importa porque preserva perspectiva. Ele também deixa o trabalho mais rápido, mas velocidade não é o benefício principal. O benefício principal é que cada frente pode manter um padrão mais estreito e aplicá-lo com mais rigor.

4. QA adversarial

A quarta fase é deliberadamente cética.

O workflow procura descobertas desatualizadas, citações fora de lugar, IDs de evidência quebrados, âncoras duplicadas, links internos mortos, incompatibilidades em dados gerados e conclusões exageradas. Ele checa se notas de QA antigas ainda descrevem o artefato atual. Checa se assets com cache-busting estão de fato ausentes ou só parecem ausentes porque o validador está lendo o nome do arquivo de forma literal demais. Checa se a exportação de fonte usa a chave esperada ou um identificador estável diferente.

Isso importa porque artefatos de pesquisa falham de maneiras chatas.

Os erros perigosos nem sempre são grandes alucinações. Muitas vezes são pequenas incompatibilidades:

Uma afirmação numérica aponta para o ID de fonte errado.
Uma afirmação de status cita uma fonte próxima, porém mais fraca.
Um resumo técnico promove um detalhe secundário à afirmação principal.
Uma entrada de fonte tem o tópico certo, mas a referência subjacente errada.
Um arquivo de validação preserva uma descoberta já superada.
Documento e apêndice agora se contradizem porque só um deles foi corrigido.

Esses defeitos são fáceis de deixar passar numa leitura corrida. E são exatamente o que um workflow de verificação deveria pegar.

5. Correção direta

Encontrar um problema não é a linha de chegada.

Quando o workflow confirma um erro, ele corrige o artefato diretamente. Isso pode significar atualizar o texto visível, os dados gerados, os mapeamentos de fonte, as exportações de fonte, as notas ou os resumos de validação. A correção precisa acontecer onde a afirmação vive, não só onde o problema foi notado.

Essa é a maior diferença entre Deep Research e a pesquisa comum assistida por IA. O workflow não se contenta com uma crítica. Ele quer que a entrega se torne mais verdadeira.

O padrão é correção guiada por evidência, não reescrita especulativa. Se uma afirmação não está verificada, o workflow a restringe. Se uma fonte está desatualizada, ele a substitui ou a qualifica. Se uma nuance técnica não pode ser totalmente confirmada, ele preserva a incerteza em vez de transformar uma estimativa em fato.

6. Validação final

A fase final é mecânica e necessária.

Depois das correções, o workflow valida o sistema de novo: as referências de fonte resolvem, o JSON faz parse, os assets locais existem, os links internos funcionam, não há IDs duplicados, as exportações de fonte estão alinhadas e as checagens de formatação passam.

Essa fase não é glamourosa. Mas é onde a confiança se conquista. Um artefato de pesquisa pode ter um texto excelente e ainda assim estar operacionalmente quebrado. Citações quebradas, arquivos gerados desatualizados e estruturas de dados inválidas não são detalhes de apresentação. São evidência de que o artefato não foi de fato trazido de volta a um estado coerente.

Deep Research só termina quando o artefato e sua camada de evidências concordam.

O sistema que construí

O sistema é construído em torno de uma premissa simples: a qualidade da pesquisa depende da integridade do artefato inteiro, não só do texto visível.

O artefato pode ser um brief em markdown, um relatório estruturado, uma página alimentada por dados, um memorando com apêndices ou uma entrega gerada. O formato exato muda. O loop de controle não.

Uma revisão superficial lê o documento de nível mais alto, faz algumas sugestões de redação e para.

O sistema de Deep Research trata a entrega como um conjunto de superfícies conectadas:

Seções narrativas
Mapeamentos de fonte
Arquivos de dados
Notas
Apêndices
Exportações geradas
Artefatos de validação

Cada superfície é checada contra as outras. Se a narrativa diz uma coisa e os dados dizem outra, o sistema sinaliza a incompatibilidade. Se uma citação aponta para a fonte errada, o sistema trata isso como uma falha de afirmação, não como uma questão cosmética. Se a saída gerada preserva um texto desatualizado, o sistema segue a afirmação de volta até a camada da fonte, em vez de só editar o parágrafo.

Essa é a parte que mais me importa. O workflow não separa a escrita da verificação. Ele torna a escrita responsável perante a camada de evidências.

O sistema tem três tarefas:

Manter o grafo de fontes visível.
Manter as afirmações ligadas à evidência certa.
Manter o artefato final internamente consistente depois das correções.

Isso torna o workflow útil além de um único domínio. Ele dá conta de pesquisa de mercado, análise técnica, estratégia de produto, análise competitiva e apoio a decisões internas, porque o problema central é o mesmo: as afirmações se afastam das evidências a menos que o sistema fique puxando-as de volta.

Essa é a diferença entre "eu revisei o documento" e "o artefato agora é mais confiável."

Por que isso acumula

O workflow fica mais valioso com o tempo porque cada rodada deixa para trás um contexto melhor.

Um chat comum produz uma resposta. Um workflow de verificação produz uma resposta mais mapeamentos de fonte, artefatos corrigidos, notas de validação e conhecimento reutilizável sobre onde o artefato era frágil. A rodada seguinte parte do contexto do sistema em vez de começar do zero.

Esse é o efeito cumulativo que me importa. O sistema de pesquisa fica melhor em pegar os tipos específicos de erro que aparecem em pesquisa estruturada. Ele aprende que dados gerados podem se afastar do texto visível. Aprende que arquivos de QA antigos podem estar desatualizados. Aprende que IDs de fonte importam tanto quanto títulos de fonte. Aprende que resumos técnicos precisam de disciplina no alcance das afirmações.

Isso não torna o workflow autônomo no sentido irresponsável. Torna-o mais inspecionável. O humano continua dono do julgamento. O workflow torna a trilha de evidências mais fácil de auditar.

Isso também muda o papel do operador. O trabalho de maior alavancagem não é perguntar "Você consegue pesquisar isso?". É definir o que conta como evidência, quais superfícies precisam concordar, quais riscos merecem revisão adversarial e qual validação tem que passar antes de o resultado ser confiável.

Em outras palavras, o operador não está apenas fazendo prompts. O operador está desenhando o sistema de controle da pesquisa.

O que pode dar errado

Deep Research não é mágica. Ele pode falhar se a disciplina operacional desmoronar.

Ele pode confiar demais nas próprias notas intermediárias. Um checklist de QA é útil, mas pode estar desatualizado. O artefato atual tem que ser checado diretamente.

Ele pode se ajustar demais à estrutura gerada. Um validador pode sinalizar um asset ausente porque não consegue remover as query strings dos caminhos locais. Uma checagem de CSV pode assumir que a chave estável é id quando a exportação na verdade usa evidence_id.

Ele pode exagerar afirmações incertas. Estimativa de mercado, escopo técnico, posicionamento competitivo e interpretação de fontes costumam ter incertezas que deveriam sobreviver no texto final.

Ele pode corrigir só a camada visível. Essa é a falha mais comum. O documento se lê corretamente, mas os dados, as notas ou a exportação de fonte ainda carregam a afirmação antiga.

A mitigação é chata e rígida: mapeie o sistema, verifique contra fontes primárias ou duráveis sempre que possível, corrija cada superfície dependente e valide depois das edições.

O modelo mental reutilizável

A versão mais simples do workflow são quatro verbos:

Mapear. Verificar. Corrigir. Validar.

Mapeie as afirmações e as superfícies onde elas aparecem.

Verifique as afirmações contra o material de origem, não contra a confiança do texto.

Corrija o artefato de verdade, incluindo os dados gerados e as camadas de citação.

Valide que a entrega final é internamente coerente.

É isso que torna Deep Research diferente de um resumo feito por IA. Ele não otimiza para um primeiro rascunho persuasivo. Ele otimiza para uma entrega que aguenta o contato com a própria evidência.

Para operadores técnicos, founders, estrategistas de produto e power users de IA, essa é a parte que vale copiar. Não construa um workflow de pesquisa que apenas escreve mais. Construa um que torne as afirmações responsáveis.

O futuro da pesquisa com IA não é a resposta mais longa. É a resposta cujo grafo de evidências continua de pé depois da revisão.