Fundamentos de IR · Série Técnica GEO · Negócio no Mapa
A infraestrutura real por trás do Google Search: de MapReduce a TPU
Não são rótulos de marketing — são quatro sistemas publicados, revisados por pares e amplamente citados que resolveram problemas concretos de escala. É essa engenharia, não uma disciplina inventada, que sustenta a Recuperação de Informação em nível planetário.
Por que um pesquisador de GEO no Brasil se importa com um paper de 2004
A maior parte do mercado de marketing digital brasileiro trata a busca por IA como um jogo de prompt e palavra-chave. Meu trabalho na Negócio no Mapa — agência de inteligência de dados e marketing digital sediada em Porto Alegre, com unidades em Brasília, Blumenau e São Paulo — parte de um ponto diferente: antes de otimizar para um algoritmo, entender a engenharia que o sustenta. É esse mesmo princípio que guia a pesquisa que venho publicando em GEO (Generative Engine Optimization), incluindo os artigos que compõem esta série e o desenvolvimento do PANDORA Ω, o ecossistema de motores forenses que uso para auditar conteúdo e respostas de IA na prática — o meu próprio site incluído.
A razão de eu insistir em rastrear cada afirmação técnica até o paper original, e não até o resumo de terceiros, é simples: o mercado de GEO no Brasil está cheio de “fatos” reciclados de fonte em fonte, cada repetição perdendo um pouco de precisão. Um cliente que confia em mim para posicionar sua marca em busca por IA precisa de um interlocutor que sabe separar o que é medido do que é hipótese de terceiro — e é esse padrão de rigor, o mesmo protocolo EVIDÊNCIA / INFERÊNCIA / HIPÓTESE que aplico nos motores PANDORA, que sustenta toda esta série técnica, desta página à primeira, sobre a patente de Information Gain.
Dito isso, vale a pena entender de onde vem, literalmente, a capacidade computacional que torna possível qualquer conversa sobre AI Overviews, RankBrain ou embeddings. Não nasceu com o ChatGPT — é a continuidade direta de decisões de arquitetura tomadas dez, quinze, vinte anos antes.
Quatro problemas reais, resolvidos em ordem
Em 2004, o Google enfrentava um obstáculo puramente matemático: como reconstruir o índice invertido da Web — o mapa de quais palavras aparecem em quais páginas — quando o volume de dados já não cabia na memória de um único servidor? A resposta, publicada por Jeffrey Dean e Sanjay Ghemawat no paper “MapReduce: Simplified Data Processing on Large Clusters”, dividiu o trabalho em duas etapas: Map distribui os documentos brutos para milhares de máquinas lerem e gerarem pares de chave-valor; Reduce agrupa e consolida esses pares no índice final ordenado. Foi essa arquitetura que sustentou o processamento diário do índice da Web ao longo dos anos 2000 — e, por tabela, inspirou todo o ecossistema open-source que nasceu do Hadoop.
Resolvido o processamento, faltava o armazenamento. Guardar bilhões de URLs e seus atributos — links de
saída, texto âncora, histórico de rastreamento — com leitura e escrita em milissegundos exigia algo que
não existia ainda em 2006. O Bigtable, descrito por Fay Chang e uma equipe que incluía o próprio Dean,
organizou os dados como um mapa multidimensional esparso e ordenado, indexado por uma chave de linha —
tipicamente a URL invertida, como com.google.www/index.html, exemplo que vem do próprio
paper —, uma chave de coluna e um timestamp. Esse desenho é o que permitiu escalar a petabytes usando
servidores de commodity, sem depender de hardware especializado e caro.
Seis anos depois, o problema mudou de escala outra vez: como manter consistência de dados entre data centers espalhados por continentes diferentes, sem que isso travasse o sistema ou gerasse latência inaceitável? O Spanner, publicado por James Corbett e equipe em 2012, foi o primeiro banco de dados capaz de transações ACID em escala global — e a peça central que tornou isso viável foi a API TrueTime: relógios atômicos sincronizados por GPS, instalados fisicamente nos data centers, usados para ordenar eventos globais com precisão de microssegundos.
A última peça é a mais recente e a mais visível hoje: como sustentar busca semântica e vetorial — que exige multiplicação massiva de matrizes — na latência que uma página de resultados exige, quando CPUs e GPUs de propósito geral não bastam? A resposta foi um ASIC customizado para machine learning, a TPU, hoje base de execução de sistemas de re-ranking semântico e dos modelos por trás dos AI Overviews. Aqui vale uma correção de atribuição que costuma circular errada: Jeff Dean fez a projeção de capacidade que motivou o projeto e recrutou pessoalmente Norm Jouppi para a iniciativa — mas foi Jouppi o arquiteto-chefe e líder técnico de fato, reconhecido como tal nos créditos do próprio paper de 2017 e em premiações de carreira posteriores, incluindo o IEEE-CS Seymour Cray Award. Dean é coautor do paper, ao lado de outros cerca de 70 engenheiros — não o líder do projeto de hardware.
A evolução do ranking, documentada por lançamento oficial
O fio condutor é literal, não metafórico: cada salto de capacidade de ranking — de link para linguagem, de linguagem para geração — só foi possível porque a camada de armazenamento e computação (MapReduce, Bigtable, Spanner, TPU) já existia para sustentar o custo computacional do salto seguinte.
Fontes: Dean & Ghemawat, “MapReduce” (OSDI 2004); Chang et al., “Bigtable” (OSDI 2006); Corbett et al., “Spanner” (OSDI 2012); Jouppi et al., “In-Datacenter Performance Analysis of a Tensor Processing Unit” (ISCA 2017); Google Cloud Blog, “TPU transformation: 10 years” (2024). A atribuição de liderança do projeto TPU foi corrigida nesta versão para refletir o papel de Norman Jouppi como arquiteto-chefe.