20 Conceitos fundamentais de GEO

AI Overview — A caixinha que matou o clique

O recurso que o Google lançou em 2024 e que mudou tudo.

AI Overview (antes chamado de SGE — Search Generative Experience) é o bloco colorido que aparece no topo dos resultados do Google com uma resposta escrita por IA. Ele está presente em 32% das buscas B2B em 2026 e é o principal responsável pela queda do tráfego orgânico.

Por que importa para a sua marca

Quando o Google gera a resposta via IA, ele cita 3 a 5 fontes numericamente. Se sua marca aparece entre essas fontes, você ganha autoridade (mesmo sem clique). Se não aparece, você é esquecido. A diferença entre aparecer ou não depende de: dados estruturados, llms.txt, consistência de entidade e autoridade temática. Depois do Google I/O 2026, AI Overview e AI Mode passaram a operar como uma camada única com mais de 1 bilhão de usuários mensais. Uma análise editorial da virada está em "GEO não morreu, o que morreu foi o ritual técnico", do CEO da Brasil GEO.

🔗 Ver no glossário · ver no capítulo 1 de /entenda/

RAG — Como a IA busca fontes em tempo real

Retrieval-Augmented Generation — o que diferencia ChatGPT com browsing de ChatGPT offline.

RAG (Retrieval-Augmented Generation) é o mecanismo pelo qual um LLM busca informação em fontes externas em tempo real antes de gerar a resposta. Perplexity, ChatGPT com browsing, Google Gemini e Microsoft Copilot usam RAG.

O que isso significa pra você

RAG escolhe fontes na hora, com base em autoridade, frescor e relevância. Se seu site:

• É atualizado com frequência (frescor)
• Tem dados estruturados claros (facilita leitura da máquina)
• Está indexado rapidamente via IndexNow (chega antes)
• Tem llms.txt estruturado (guia de leitura)

…então a chance de você ser escolhido como fonte pela RAG é muito maior. Perplexity, por exemplo, mostra as fontes numericamente — se você aparece, ganha tráfego direto e citação.

🔗 Ver no glossário

Embeddings — Como a IA entende significado

O truque matemático que faz sua marca ser "agrupada" junto de concorrentes.

Embedding é a forma como os LLMs convertem palavras em vetores numéricos. Cada palavra, frase ou documento vira um ponto num espaço com centenas (ou milhares) de dimensões. Palavras parecidas ficam próximas; distintas ficam distantes.

Por que importa

Quando alguém pergunta "melhores CRMs B2B", o LLM calcula os embeddings da pergunta e busca as marcas cujos embeddings são mais próximos. Se você está descrito de forma clara, consistente e específica, seu embedding aponta pra cidade certa.

Schema.org e JSON-LD — O código que fala com a máquina

Invisível para o usuário, obrigatório para a IA.

Schema.org é um vocabulário padronizado para marcar o significado do conteúdo numa página — "isto é uma pessoa", "isto é uma empresa", "isto é um preço". JSON-LD é o formato recomendado para implementá-lo: um bloco <script type="application/ld+json"> invisível ao usuário.

Exemplo prático

Esta página (/conceitos/) tem o JSON-LD abaixo no head. Observe como ele informa à IA que o autor é Alexandre Caramaschi, que o conteúdo ensina 10 tópicos específicos e que faz parte de um recurso de aprendizado.

{
  "@type": "LearningResource",
  "name": "20 Conceitos Fundamentais de GEO",
  "author": { "@id": "https://brasilgeo.ai/#founder" },
  "educationalLevel": "Intermediate",
  "teaches": [
    "AI Overview", "Retrieval-Augmented Generation",
    "Embeddings", "Schema.org e JSON-LD", ...
  ]
}

Tipos essenciais para GEO

• Person — sua biografia canônica (com ORCID, Wikidata, sameAs)
• Organization — sua empresa (com taxID, founder, location)
• Service / Offer — seus produtos e preços
• FAQPage — perguntas e respostas estruturadas
• BreadcrumbList — contexto de navegação
• ScholarlyArticle — papers acadêmicos (com DOI)

🔗 Ver schema.org e JSON-LD no glossário

llms.txt — O novo robots.txt, mas para IA

Um arquivo simples que aumenta muito sua chance de ser citado.

llms.txt é um arquivo de texto servido na raiz do site (/llms.txt) que fornece a LLMs uma visão sumarizada, estruturada e citável da identidade, serviços, ofertas e conteúdos da marca. É especificação aberta, criada em 2024, já adotada pelos principais crawlers de IA. Vale registrar que llms.txt não é sinal oficial do Google, ponto que Alexandre Caramaschi explicou na justificativa de manter o arquivo em "llms.txt não é requisito para o Google, e mesmo assim mantenho o meu", útil para LLMs não-Google como Claude, Perplexity e ChatGPT com browsing.

O que deve ter num llms.txt

• Frontmatter YAML com: title, description, url, language, last_updated, founder, disambiguation
• Seção About: quem você é em 1-2 parágrafos
• Products / Services: o que você oferece, com preço quando possível
• FAQ: respostas prontas para as 5-10 perguntas mais comuns
• Resources: links para llms-full.txt, sitemap, feeds, markdown mirrors
• Cross-references: entidades relacionadas (fundador, empresa-mãe, subsidiárias)

https://brasilgeo.ai/llms.txt
https://brasilgeo.ai/llms-full.txt
https://brasilgeo.ai/markdown-for-agents

🔗 Ver llms.txt no glossário

EEAT — Experiência, Expertise, Autoridade, Confiabilidade

O framework que o Google usa há anos e que IAs também adotaram.

EEAT é a sigla para Experience, Expertise, Authoritativeness, Trustworthiness — o framework de qualidade do Google. Em 2026, IAs generativas usam heurísticas muito parecidas: preferem citar marcas com experiência real, expertise técnica demonstrável, autoridade reconhecida e confiabilidade verificável.

Como comprovar cada dimensão

• Experiência (E): anos de atuação, cases concretos, depoimentos, presença antiga no tema.
• Expertise (E): credenciais (MBA, certificações), publicações próprias (artigos, papers, ebooks).
• Autoridade (A): citações de terceiros, imprensa, academia, Wikidata, peer-reviewed.
• Confiabilidade (T): CNPJ visível, contato verificável, política de privacidade, HTTPS, LGPD.

🔗 Ver EEAT no glossário

Share of Voice Generativo — A métrica do novo mundo

Antes era ranking. Agora é quantas respostas te citam.

Share of Voice (SOV) Generativo mede em quantas respostas de IAs sua marca é citada, entre as perguntas-chave do seu mercado. É o equivalente moderno do "ranking no Google": em vez de contar posições, você conta citações.

Como calcular SOV na prática

• Escolha 10-20 perguntas-chave do seu funil
• Execute cada uma em 4 IAs (manualmente ou via API)
• Conte citações da sua marca vs concorrentes
• Calcule % = citações suas ÷ total de respostas
• Benchmark: qualquer coisa abaixo de 20% é alerta

🔗 Ver share of voice no glossário

Citabilidade — A nova qualidade

A métrica que antecede o SOV.

Citabilidade é o quanto uma marca está "pronta para ser citada" por uma IA. É como uma pré-métrica: antes de medir quantas vezes você aparece (SOV), você avalia se os fundamentos estão no lugar para aparecer.

5 componentes de alta citabilidade

• Entidade clara: Person + Organization Schema.org com @id único
• Bio consistente: mesma descrição em todos os canais
• Autoridade verificável: ORCID, Wikidata, imprensa, papers
• Conteúdo canônico: um lugar-fonte onde sua tese está documentada
• Discoverability técnica: sitemap, llms.txt, IndexNow, markdown mirror

🔗 Ver citabilidade no glossário

Alucinação — Quando a IA inventa sobre você

Um risco que GEO bem feito mitiga.

Alucinação é o termo técnico para quando um LLM gera informação falsa com aparência de verdade. Pode citar sua marca em contexto errado, atribuir produtos que você não tem, ou confundir sua identidade com a de outra empresa homônima.

Tipos de alucinação sobre marcas

• Atribuição errada: diz que você faz algo que você não faz.
• Confusão de identidade: mistura você com concorrente ou homônimo.
• Fatos incorretos: inventa preços, endereços, fundadores.
• Citação inventada: atribui a você frases que você nunca disse.

🔗 Ver alucinação no glossário

B2A — Business-to-Agent

O próximo passo depois de B2B e B2C. Tese pioneira de Alexandre Caramaschi no Brasil.

B2A (Business-to-Agent) descreve o cenário em que agentes autônomos de IA fazem triagem, comparação, recomendação e até compra em nome de usuários humanos. Não é ficção: OpenAI Operators (2025), Perplexity Shopping (2025) e agentes de n8n/LangChain/AutoGPT já operam em produção.

Por que B2A muda tudo

• Agentes não clicam em banners — não têm conversão emocional. Só lógica.
• Agentes comparam especificações técnicas em millisegundos — a diferença é fina.
• Agentes usam APIs e JSON-LD como fontes primárias — marketing visual importa zero.
• Agentes seguem protocolos como MCP (Model Context Protocol) para acessar dados canônicos.

🔗 Ver B2A no glossário · ver contexto no /entenda/

Agentic Commerce: quando seu cliente vira o robô

Comércio sem checkout humano: o agente compra em nome do dono e a marca precisa estar legível pra ele.

Agentic Commerce é a camada de comércio em que agentes autônomos executam pesquisa, comparação, negociação e compra em nome de um usuário humano. Sai de "loja com chatbot" e vira "loja sem cliente humano na sala". Em 2025 e 2026, três produtos já operam nesse modo em produção: OpenAI Operator (lançado 2025-01-23), Perplexity Shopping Hub (2024-11) e Anthropic Computer Use (2024-10-22).

A premissa é simples e brutal: se o agente compra, então o agente é seu novo cliente. E o agente não tem dó de campanha visual, jingle, brand love ou cor de embalagem. Ele tem três perguntas: a oferta é legível em JSON, o preço bate, e a marca tem reputação verificável? Quem responde sim para as três, vende. Quem responde não, é filtrado antes do humano ver.

Há uma diferença crítica entre Agentic Commerce e e-commerce convencional: a unidade de decisão deixa de ser uma sessão de navegação e passa a ser uma sequência de chamadas a APIs e tools. O agente lê um catálogo via MCP, compara via embeddings, valida reputação via fontes citadas pela LLM, fecha via UCP (Unified Commerce Protocol, proposto em discussões IETF 2025) ou ainda via formulários web automatizados. Cada uma dessas etapas pode te eliminar.

A janela competitiva 2026 é estreita. Os primeiros a ter catálogo legível, agent card publicado e política devolvida em JSON ocupam o lugar de fornecedor preferido nas memórias dos agentes que processam essa categoria. Quando o agente "aprende" rota de compra (alimentos no mercado X, papelaria no Y, embalagem no Z), o custo de troca é alto, igual ao custo de troca de banco para humanos. Os primeiros que entram na rota têm vantagem composta. Operação tarde corre risco de ficar fora da memória padrão dos agentes e depender sempre de busca ativa, que custa caro.

O que muda na camada de UX

A UX do checkout, durante 25 anos, foi otimizada para reduzir abandono humano. Agora ela precisa ser otimizada para um agente que não abandona, mas compara em paralelo com mais sete fornecedores. Três coisas mudam de imediato:

• Catálogo legível por máquina: GTIN, MPN, schema Product/Offer completo, disponibilidade em tempo real. Sem isso, o agente desiste antes de chegar no carrinho.
• Política de retorno em JSON: cláusulas em PDF não servem. O agente quer prazo em dias, condição de elegibilidade e link de RMA estruturado.
• Endpoint de cotação: o agente quer pedir orçamento dinâmico via API, não preencher formulário. Se você só tem formulário, perde para o concorrente que tem rota REST.

{
  "@type": "Offer",
  "name": "Tarifa Branca Residencial",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "price": 0.62,
    "priceCurrency": "BRL",
    "unitCode": "KWH"
  },
  "eligibleCustomerType": "Residential",
  "availability": "InStock",
  "warranty": "P12M"
}

Fontes: OpenAI Operator launch (2025-01-23, openai.com), Anthropic Computer Use (2024-10-22, anthropic.com), Perplexity Shopping Hub (2024-11, perplexity.ai). Schema.org Product e Offer (versão 28.0, 2025).

Model Context Protocol (MCP): o USB-C dos agentes

Protocolo aberto que liga LLMs a ferramentas reais. Publicado pela Anthropic em 25 de novembro de 2024.

Model Context Protocol é uma especificação aberta criada pela Anthropic, anunciada em 25 de novembro de 2024 no post oficial "Introducing the Model Context Protocol" e publicada em modelcontextprotocol.io. O objetivo é padronizar como um LLM acessa fontes externas: arquivos, bancos de dados, APIs, sistemas de versão. Antes do MCP, cada integração era um plugin proprietário. Depois do MCP, qualquer cliente compatível conversa com qualquer servidor compatível.

A arquitetura tem três peças. O host é a aplicação que o usuário usa, por exemplo Claude Desktop ou Cursor. O cliente é a camada dentro do host que abre canais para servidores. O servidor é um processo separado que expõe três primitivas: tools (funções invocáveis), resources (recursos lidos por URI) e prompts (templates parametrizáveis). Comunicação default é stdio para servidores locais e SSE ou HTTP streamable para servidores remotos.

A adoção foi rápida e cruzada. OpenAI declarou suporte oficial em março de 2025. Google DeepMind incluiu MCP no Gemini CLI em julho de 2025. Microsoft adicionou MCP ao Copilot Studio. Em janeiro de 2026 existem mais de 800 servidores públicos catalogados, incluindo postgres, filesystem, github, slack, sentry, stripe, supabase, brave-search e dezenas de SaaS. Esse efeito de rede aconteceu mais rápido que o de qualquer outra spec de integração de LLM, e é a primeira evidência forte de que a era das integrações proprietárias acabou.

Por que MCP importa para GEO

Marca que expõe servidor MCP próprio entrega ao agente contexto canônico de primeira pessoa. Em vez do agente depender do que o LLM lembrou do treino (frágil, antigo, possivelmente errado), ele lê dados ao vivo do seu sistema. Isso reduz alucinação sobre sua marca a quase zero e cria fricção competitiva: o concorrente que não tem MCP precisa torcer pra ser citado de memória.

Há uma diferença prática entre publicar servidor MCP e publicar API REST. A API REST exige que o agente saiba a URL, a estrutura, o auth. O servidor MCP se descreve sozinho: cliente pede a lista de tools, recebe schema, sabe usar. É a diferença entre "leia minha documentação" e "leia meu manifesto e use". Para B2A, isso vale ouro. Em 2026, a Brasil GEO mantém servidor MCP read-only em alexandrecaramaschi.com/api/mcp com tools getBusinessInfo, getLocation, listCourses e contactUs justamente para servir de exemplo canônico do padrão.

{
  "name": "getOrderStatus",
  "description": "Retorna status do pedido pelo ID",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderId": { "type": "string" }
    },
    "required": ["orderId"]
  }
}

Fontes: Anthropic Engineering blog "Introducing the Model Context Protocol" (2024-11-25), modelcontextprotocol.io spec (versão 2025-06-18), OpenAI Platform docs "MCP Tools" (2025-03), Google Cloud blog Gemini CLI MCP (2025-07).

Agent-to-Agent (A2A) Protocol: quando agentes negociam entre si

Spec do Google publicada em abril de 2025. Próximo degrau depois do MCP.

Se MCP padroniza como um LLM acessa uma ferramenta, Agent-to-Agent (A2A) padroniza como um agente conversa com outro agente. O Google anunciou o protocolo em 9 de abril de 2025 no Google Cloud Next, com mais de 50 parceiros iniciais incluindo Salesforce, SAP, ServiceNow, MongoDB, Atlassian, Box, Cohere, Deloitte, Accenture e PwC. A spec vive em github.com/google/A2A sob licença Apache 2.0.

A unidade central do A2A é o Agent Card: um JSON publicado em /.well-known/agent.json que descreve capacidades, modalidades suportadas, endpoint, esquema de autenticação e habilidades. Quando o agente A precisa fazer algo fora do escopo dele, ele descobre o agente B lendo o card, abre uma sessão, troca mensagens e tarefas, e fecha. Tudo HTTPS, com JSON-RPC ou eventos SSE.

O card cumpre função análoga ao robots.txt ou ao llms.txt em camada anterior: ele é o ponto de descoberta. A diferença é que o agent card descreve capacidades acionáveis, não permissões de crawl ou bilhete editorial. É a transição de "leia meu conteúdo" para "execute estas habilidades comigo". Em 2026 já há diretórios públicos de agent cards (agentregistry.dev e variantes), num movimento muito parecido ao que aconteceu com APIs públicas no final da década de 2000.

A diferença filosófica em relação ao MCP é que MCP assume hierarquia (host invoca server) enquanto A2A assume pares. Os dois agentes têm autonomia, podem recusar, podem negociar prazo, podem reformular. Isso muda o tipo de transação possível. MCP serve para "consultar Postgres". A2A serve para "negociar contrato com o agente do fornecedor". Os dois protocolos são complementares e quase sempre coabitam: o agente A usa MCP para consultar seu próprio CRM e A2A para falar com o agente B do parceiro.

Por que B2A maduro depende de A2A

No capítulo 10 falamos de Business-to-Agent. O B2A versão alpha funciona com um agente do comprador navegando seu site como humano, lendo HTML, preenchendo formulário, esperando resposta de e-mail. É funcional mas frágil, lento e impreciso. O B2A maduro funciona quando o agente do comprador fala com o agente vendedor da sua marca via A2A. Cotação, prazo, condição comercial, follow-up: tudo via mensagens A2A estruturadas. O ganho de eficiência muda a economia da venda B2B inteira. O risco é claro: quem não tiver agent card publicado fica fora do circuito de descoberta nos próximos 24 meses, do mesmo jeito que quem não tinha site em 2002 saiu do circuito.

{
  "name": "AgenteVendedorAcmeEmbalagens",
  "description": "Agente de pré-vendas de embalagem flexível",
  "url": "https://acme.com.br/a2a",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "quote",
      "name": "Solicitar cotação",
      "description": "Devolve proposta comercial com prazo e preço"
    }
  ]
}

Fontes: Google Cloud Next anúncio A2A (2025-04-09), repositório github.com/google/A2A (Apache 2.0), Salesforce blog "A2A integration" (2025-04), MongoDB partner press release (2025-04-09).

RLHF: como o ChatGPT aprendeu a ser educado

Reinforcement Learning from Human Feedback. O método que transformou GPT-3 em ChatGPT.

RLHF (Reinforcement Learning from Human Feedback) é a técnica que ajusta um modelo de linguagem para responder de acordo com preferências humanas. O paper de referência é Ouyang et al. 2022, "Training language models to follow instructions with human feedback", arXiv:2203.02155, publicado pela OpenAI em março de 2022. É o método que diferencia GPT-3 cru (que completava texto) de InstructGPT e ChatGPT (que seguem instruções e recusam pedidos perigosos).

O processo tem três etapas. Primeiro, fine-tuning supervisionado com pares prompt-resposta escritos por humanos contratados. Segundo, treinamento de um modelo de recompensa a partir de rankings humanos sobre pares de respostas alternativas. Terceiro, otimização do modelo com PPO (Proximal Policy Optimization) ou DPO (Direct Preference Optimization) usando o modelo de recompensa como sinal. O resultado é um modelo que prefere respostas que humanos avaliaram como melhores.

Em 2023 surgiu o RLAIF (Reinforcement Learning from AI Feedback), proposto pela Anthropic no paper "Constitutional AI" de dezembro de 2022 (arXiv:2212.08073), onde o feedback vem de outro LLM seguindo uma constituição de princípios. Em 2024 e 2025 o DPO de Rafailov et al. (NeurIPS 2023, arXiv:2305.18290) substituiu PPO em vários laboratórios por ser mais estável e barato. Em 2025 o GRPO foi popularizado pelo DeepSeek-R1 (paper 2025-01-22, arXiv:2501.12948) para alinhamento com reasoning.

A ramificação metodológica importa porque cada variante muda o gosto do modelo final. PPO clássico tende a produzir modelos verbosos e cautelosos. DPO produz modelos mais concisos por construção matemática. Constitutional AI produz modelos que verbalizam o raciocínio ético quando recusam. Quem treinou seu modelo favorito, com qual método e sobre qual constituição, é uma decisão editorial. Não é neutra. A Anthropic publica sua constituição completa em anthropic.com/constitution, ato raro de transparência no setor.

Trade-off central: alinhamento custa capacidade

O paper de Bai et al. 2022 da Anthropic ("Training a Helpful and Harmless Assistant with RLHF", arXiv:2204.05862) já documentava o alignment tax: o modelo alinhado responde melhor a tarefas instruction-following, mas piora em alguns benchmarks de capacidade pura. O motivo é simples: o modelo aprendeu a recusar, hedge, contextualizar e ser cauteloso. Isso é desejável em maioria dos casos e custoso em outros, por exemplo em raciocínio matemático livre ou criatividade ficcional sem trilho.

Fontes: Ouyang et al. (2022) arXiv:2203.02155, Bai et al. (2022) arXiv:2204.05862, Anthropic Constitutional AI (2022) arXiv:2212.08073, Rafailov et al. DPO (2023) arXiv:2305.18290, DeepSeek-R1 (2025-01-22) arXiv:2501.12948.

Fine-tuning vs RAG: qual usar e quando

A pergunta certa não opõe "qual é melhor" e sim "qual problema você está resolvendo".

Fine-tuning ajusta os pesos do modelo com seus dados. RAG deixa os pesos intactos e busca seus dados em tempo de inferência. As duas técnicas resolvem problemas diferentes, embora a discussão em conferências em 2024 e 2025 tenha levado o público a achar que são alternativas excludentes. Não são. O paper de Ovadia et al. 2024 "Fine-Tuning or Retrieval?" (arXiv:2312.05934) mostrou empiricamente que RAG quase sempre vence em tarefas de conhecimento factual, mas fine-tuning vence em adaptação de estilo, formato e domínio raro.

Use fine-tuning quando o problema é forma e não fato: tom de voz da marca, formato estruturado específico, domínio linguístico raro (jurídico brasileiro, médico veterinário, normas técnicas ABNT), recusa de tópico off-policy, comportamento ferramenta-específico. O modelo precisa aprender o jeito, não os fatos. Custo: treino caro mas inferência barata. Exemplo de uso real: GPT-4o-mini fine-tuned no jeito de redação do New York Times, anunciado em 2024-08.

Use RAG quando o problema é fato e não forma: catálogo de produtos, base de conhecimento de suporte, normas que mudam, base jurisprudencial atualizada, política da empresa. O modelo já sabe escrever bem em português. Ele precisa ler o seu documento certo na hora certa. Custo: inferência cara (cada query lê embeddings + recupera trechos + faz prompt longo) mas zero treino.

Há um terceiro caminho que cresceu em 2024 e 2025: contexto longo com prompt caching. Em vez de fine-tunar ou indexar, você manda o documento inteiro junto da query, mas cacheia o prompt para reutilizar em chamadas subsequentes. Anthropic, OpenAI e Google oferecem cache. O custo cai 70 a 90% no segundo uso em diante. Funciona bem para bases de até 200 mil tokens que mudam pouco e são consultadas muito. Não substitui RAG em bases dinâmicas mas é o primeiro recurso a testar antes de qualquer arquitetura mais cara.

Decision tree prático

• Volume e fato muda toda semana? RAG. Fine-tune fica obsoleto antes de você publicar.
• Você precisa de output em formato JSON com schema travado? Function calling resolve. Se não bastar, fine-tuning de formato.
• Seu domínio é nicho com vocabulário próprio (português jurídico, agronegocio, contabilidade fiscal)? Considere fine-tuning de domínio sobre base RAG.
• Você está num produto B2B SaaS com bases de clientes isoladas? RAG por tenant, fine-tune zero. Cada cliente é um índice separado, modelo é o mesmo.
• Custo de inferência alto demais por query repetida? Prompt caching da Anthropic (Sonnet 4, Opus 4) e do Google (Gemini context cache) cortam 70-90%. Antes de fine-tunar, tente cache.

Fontes: Ovadia et al. (2023, atualizado 2024) "Fine-Tuning or Retrieval?" arXiv:2312.05934, OpenAI Cookbook "When to fine-tune" (2024), Anthropic prompt caching docs (2024-08-14, ampliado 2025), New York Times Connection com OpenAI (2024-08).

Vector Databases na prática 2026: Pinecone, Weaviate, Qdrant, pgvector

Como escolher banco vetorial sem brigar com o financeiro nem com o time de infra.

Banco de vetores armazena embeddings (vetores numéricos de 256 a 4096 dimensões em 2026) e executa busca por similaridade em milissegundos. O mercado consolidou quatro nomes operacionais sérios e duas extensões dentro de Postgres. Cada uma resolve um corte diferente do trade-off entre custo, latência, escala e ergonomia de DevOps.

Pinecone, fundada por Edo Liberty em 2019, é o pioneiro SaaS. Lançou serverless em janeiro de 2024 e em 2026 oferece preço por uso real (storage + read units + write units). Vence em ergonomia: SDK limpo, sem servidor para administrar, métricas no painel. Custo médio: US$ 0,33 por GB-mês de storage + US$ 8,25 por milhão de read units no plano serverless padrão (tabelas de janeiro de 2026). Fraqueza: vendor lock-in, indisponível em ambiente on-prem.

Weaviate, criado por Bob van Luijt na SeMI Technologies em 2019, é open-source GPL com cloud opcional. Tem schema rico (objetos com propriedades, módulos de geração e classificação embutidos) e suporta busca híbrida nativa. Vence em quem quer cluster próprio sem reinventar. Custo: zero se self-hosted (você paga a infra), ou US$ 25/mês na entrada do Weaviate Cloud Services em 2026.

Qdrant, lançado em 2021 pela equipe de Andrey Vasnetsov em Berlim, escrito em Rust, é o mais rápido nos benchmarks ANN-Benchmarks de 2024 e 2025. Suporta filtragem com payload arbitrário e busca esparsa+densa híbrida. Open-source Apache 2.0. Cloud gerenciado tem free tier 1GB e plano dedicado a partir de US$ 25/mês. Vence em performance pura e em quem topa Rust + Docker.

pgvector, extensão Postgres de Andrew Kane lançada em 2021, virou o default no Supabase, Neon, RDS Aurora e Crunchy. A versão 0.8.0 de outubro de 2024 trouxe HNSW e suporte a tipos sparsevec e halfvec, fechando o gap de performance contra os bancos especializados em volumes até dezenas de milhões de vetores. Vence em quem já tem Postgres, quer transação ACID e quer JOIN entre embedding e tabelas relacionais. Custo: o do Postgres que você já paga.

Como decidir em 5 perguntas

• Quantos vetores você terá em 12 meses? Até 10M: pgvector resolve. 10M a 500M: Qdrant ou Weaviate. Acima: Pinecone serverless ou Qdrant cluster.
• Você já roda Postgres? Sim e <50M vetores: pgvector primeiro. Não force outra infra.
• Você precisa de filtros complexos (multi-tenant + RBAC + campo data)? Qdrant payload é o estado-da-arte. Pinecone fez progresso em 2025 mas ainda atrás.
• Você quer self-host on-prem (compliance, LGPD, ANPD CD 04/2023)? Qdrant ou Weaviate. Pinecone está fora.
• Quanto custa errar? Migração entre bancos vetoriais é cara mas factível. Migração de modelo de embedding (text-embedding-3-small da OpenAI para text-embedding-3-large, ou para Cohere embed-v3, ou para BAAI/bge-m3) é onde a dor real está. Padronize o modelo antes do banco.

Cenário: 1M vetores 1536-dim, 100k queries/dia, 90 dias retenção

pgvector Supabase Pro:    US$  25/mês  (incluso no plano)
Qdrant Cloud Free:        US$   0      (até 1GB, suficiente)
Qdrant Cloud Standard:    US$  25/mês  (1 vCPU 2GB)
Weaviate Cloud Standard:  US$  25/mês  (entrada)
Pinecone Serverless:      US$  43/mês  (storage + reads estimado)
Pinecone p2.x1 (legado):  US$ 165/mês  (não use mais)

Fontes: Pinecone Serverless launch (2024-01-16, pinecone.io blog), pgvector 0.8.0 release (2024-10-26, github.com/pgvector/pgvector), Qdrant Cloud pricing 2026, Weaviate Cloud Services pricing 2026, ANN-Benchmarks (ann-benchmarks.com, atualizado 2025).

Hybrid Search: por que keyword puro perde 30% das queries

BM25 e busca vetorial juntos. Implementação prática com Typesense, Elastic ou Postgres.

Hybrid Search combina busca por palavra-chave clássica (BM25, criado por Stephen Robertson em 1994 e ainda padrão ouro em ranking lexical) com busca vetorial densa (embeddings + similaridade cosseno). A intuição é direta: keyword é boa em queries com termos raros e específicos ("erro KEYV-1147 no Kubernetes 1.32"), vetor é bom em queries semânticas e parafraseadas ("o que faço quando o cluster não responde").

A literatura confirma a vantagem da combinação. Bruch et al. publicaram em SIGIR 2024 o paper "Bridging Dense and Sparse Maximum Inner Product Search" (arXiv:2404.17897) mostrando ganho consistente sobre cada técnica isolada em BEIR. A Microsoft publicou em julho de 2024 o blog "Outperforming vector search with hybrid retrieval and reranking" usando Reciprocal Rank Fusion e mostrou ganho de 10 a 20% sobre vetor puro. A Anthropic, no post "Introducing Contextual Retrieval" de setembro de 2024, mediu 49% de redução de falhas de recuperação com BM25 + embedding + reranker frente a embedding sozinho.

O método de fusão mais usado em 2026 é o Reciprocal Rank Fusion (RRF), proposto por Cormack, Clarke e Buettcher em SIGIR 2009. A fórmula é simples: para cada documento, soma-se 1/(k + rank_lexical) + 1/(k + rank_vetorial), com k tipicamente 60. Quem tem rank bom nas duas listas sobe ao topo. RRF está implementado nativamente em OpenSearch 2.11+, Elasticsearch 8.13+, Typesense 26+ e Weaviate 1.21+.

Implementação canônica em 3 motores

• Typesense: criado por Jason Bourne em 2015, open-source GPL-3, é o mais ergonômico para startups. Habilita híbrido com query_by: "title,embedding" e vector_query: "embedding:([...], k:10)". Cluster gerenciado a partir de US$ 19/mês. Implementação leva tarde de trabalho.
• Elasticsearch / OpenSearch: padrão de mercado em log/observability. Em 2024 ganharam pipeline de RRF nativo e suporte a knn_vector com HNSW. Curva de aprendizado maior, mas é o que time de DevOps maduro já conhece.
• Postgres com pgvector + ts_vector: rodando ambas no mesmo banco, fusão via CTE com window function dense_rank() sobre cada lista, soma das recíprocas. Zero servidor extra. Brilha em até 5 milhões de chunks.

WITH lexical AS (
  SELECT id, ts_rank(search_vector, query) AS lex_score,
         row_number() OVER (ORDER BY ts_rank DESC) AS lex_rank
  FROM docs, plainto_tsquery('portugues', $1) query
  WHERE search_vector @@ query LIMIT 50
), semantic AS (
  SELECT id, 1 - (embedding <=> $2) AS sem_score,
         row_number() OVER (ORDER BY embedding <=> $2) AS sem_rank
  FROM docs LIMIT 50
)
SELECT id,
       (1.0 / (60 + COALESCE(lex_rank, 100))) +
       (1.0 / (60 + COALESCE(sem_rank, 100))) AS rrf_score
FROM lexical FULL OUTER JOIN semantic USING (id)
ORDER BY rrf_score DESC LIMIT 10;

Fontes: Robertson e Walker (1994) BM25 paper, Cormack et al. (2009) SIGIR RRF, Bruch et al. (2024) arXiv:2404.17897, Microsoft Tech Community "hybrid retrieval and reranking" (2024-07), Anthropic "Contextual Retrieval" (2024-09-18).

Tool Use e Function Calling: LLM como roteador de funções

O LLM não executa nada. Ele decide qual função chamar, com quais parâmetros, e em que ordem.

Tool use (ou function calling, na nomenclatura OpenAI) é a habilidade do LLM de, dada uma lista de funções disponíveis com schema JSON, decidir qual chamar, com quais argumentos e em qual sequência. A OpenAI introduziu function calling em junho de 2023, a Anthropic lançou tool use em 4 de abril de 2024 (Claude 3 sonnet e opus), o Google adicionou ao Gemini em maio de 2024. Em 2025-2026, é capacidade core de todos os modelos sérios.

A separação de responsabilidades é estrita. O LLM não executa a função. Ele emite uma mensagem estruturada do tipo tool_use dizendo "preciso chamar getWeather com city=Goiania". O cliente (sua aplicação) intercepta, executa a função real (HTTP, banco, sistema), recebe o resultado, devolve ao LLM como mensagem tool_result, e o LLM continua o raciocínio com base no resultado. Isso é fundamental para segurança: tudo que toca dado ou sistema é código auditável seu, não o modelo.

O schema padrão usa JSON Schema. Cada tool tem name, description e input_schema com types, properties e required. Modelos modernos lidam bem com 20 a 50 tools no contexto. Acima disso vale dynamic tool selection: você usa embedding para escolher quais tools mostrar ao modelo em cada turno, técnica que Anthropic recomenda no cookbook "tool use with thousands of tools" (2024).

A descrição (description) de cada tool é o item mais subestimado da implementação. O modelo decide chamar ou não com base nesse texto. Descrição ruim leva o modelo a chamar a tool errada, em momento errado, ou a alucinar argumentos. A boa prática 2026 é descrever três coisas em cada descrição: o que a tool faz, quando o modelo deve usar e exemplos de input típico. Os mesmos princípios de redação técnica boa para humanos valem para LLMs, com diferença de que o LLM lê tudo, não fatiga e respeita o que está escrito.

Modos de invocação

• Auto: modelo decide se chama tool ou responde direto. Padrão na maioria dos casos.
• Any: força chamada de alguma tool, sem dizer qual. Útil quando você sabe que a query exige consulta externa.
• Tool específica: força chamada da tool X. Útil em pipelines determinísticos.
• Paralelo: modelos como GPT-4o e Claude Sonnet 4 emitem várias tool_use num único turno para chamadas independentes. Reduz latência em 2x a 4x.

{
  "name": "getWeather",
  "description": "Retorna previsão atual para a cidade. Use quando o usuário perguntar clima, temperatura, chuva ou condicoes meteorologicas.",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "Nome da cidade. Exemplo: Goiania, Sao Paulo, Rio de Janeiro"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "default": "celsius"
      }
    },
    "required": ["city"]
  }
}

Fontes: OpenAI function calling release (2023-06-13), Anthropic tool use launch (2024-04-04), Anthropic cookbook "Customer support agent" (2024), Google Gemini function calling docs (2024-05).

Multimodal Models: texto, imagem, áudio, vídeo num modelo só

Gemini 2.5, Claude 4, GPT-4o, GPT-5: o que muda no SEO de imagem.

Modelo multimodal é um LLM treinado nativamente em mais de uma modalidade (texto + imagem + áudio + vídeo), em vez de combinar modelos separados via pipeline. O salto começou com GPT-4V (Vision) em setembro de 2023 e ganhou força com Gemini 1.5 (fevereiro 2024), GPT-4o (maio 2024, treinado nativo em áudio), Claude 3.5 Sonnet com visão (junho 2024), e em 2025-2026 Gemini 2.5 Pro, Claude 4.5/4.7 e GPT-5.

A diferença entre modelo multimodal nativo e pipeline multimodal é qualitativa. No pipeline antigo, uma imagem virava texto via OCR ou caption model e o texto entrava no LLM. Informação visual fina (cor de produto, layout de gráfico, expressão facial num vídeo) se perdia na tradução. No modelo nativo, a imagem entra como tokens visuais junto dos tokens textuais, e o modelo aprende relações entre eles. Resultado: ele lê tabela de imagem PDF como tabela, não como "um monte de letras".

Implicação direta para SEO de imagem: as três técnicas tradicionais (alt text descritivo, nome de arquivo semântico, Schema ImageObject) continuam relevantes mas não dão mais conta sozinhas. O modelo multimodal lê a imagem em si, não só os metadados. Sua foto precisa mostrar o produto de forma legível por máquina, com contexto visual claro, contraste, perspectiva, qualidade. A imagem virou um documento.

Esse deslocamento força repensar o padrão de produção visual da empresa. Times de marketing acostumados a foto de produto stock, fundo branco, ângulo único, agora precisam de banco de imagens com múltiplos ângulos, contexto de uso, alta resolução. PDF de catálogo, antes diagramado para humano folhear, vira documento que LLM lê página por página. Vídeo institucional ganha valor de transcrição automática que vira material de RAG. Áudio de webinar deixa de ser asset perdido e vira fonte indexável de Q&A.

O que muda na prática para SEO multimodal

• Alt text continua importando, mas como um dos sinais, não o único. Escreva o que a imagem mostra com precisão funcional, não com keywords stuffadas.
• Resolução virou ranking factor: imagens granuladas perdem em modelos multimodais que precisam ler texto dentro da imagem (etiqueta, número de modelo, gráfico).
• Contexto visual: foto de produto sobre fundo confuso vence menos que foto em contexto de uso. O modelo aprende a associação visual + funcional.
• Schema ImageObject com contentUrl, width, height, caption, license e author. Modelos multimodais que processam SchemaResourceObject ganham contexto que pixels sozinhos não dão.
• Áudio e vídeo agora são indexáveis. Transcrição automática deixou de ser hack: Gemini 2.5 e GPT-4o leem áudio bruto. SchemaPodcastEpisode e VideoObject com transcript ganharam peso.

Fontes: OpenAI GPT-4V system card (2023-09-25), Google Gemini 1.5 paper (2024-02-15) arXiv:2403.05530, OpenAI GPT-4o announcement (2024-05-13), Anthropic Claude 3.5 Sonnet vision (2024-06-20), Schema.org ImageObject (versão 28.0).

Context Window Economy: quando vale mandar o repo inteiro

Janelas de 1M e 2M tokens mudam a equação. Mas não anulam o custo.

Context window é o limite de tokens que um modelo aceita por requisição (input + output). Em 2022, ChatGPT trabalhava com 4k tokens. Em 2024, GPT-4 Turbo subiu para 128k. Em fevereiro de 2024, Google anunciou Gemini 1.5 Pro com 1 milhão de tokens, expandido para 2 milhões em maio de 2024. Em 2025, Anthropic lançou Claude com 200k padrão e 1M em modos beta para uso enterprise. Em 2026, Claude Opus 4.7 1M context é GA, e Gemini 2.5 Pro mantém 2M.

A pergunta tática é direta: com janela tão grande, ainda vale fazer RAG? A resposta honesta é "depende de três variáveis": custo por token, latência aceitável, e qualidade de attention em contexto longo. Cada uma muda o cálculo.

Custo: input em Claude Opus 4.7 1M custa US$ 15 por milhão de tokens (input cache miss) em janeiro 2026. Mandar um repo de 800k tokens custa US$ 12 por chamada antes do output. Se você consulta esse repo 50 vezes por dia, é US$ 600 diários sem cache. Prompt caching da Anthropic corta para US$ 1,50 (cache hit, 90% off) por chamada subsequente. Gemini 2.5 Pro com context caching tem economia equivalente. A conta muda completamente com cache.

Latência: time-to-first-token cresce sublinearmente com tamanho do contexto, mas cresce. 1M tokens significam 8 a 15 segundos para começar a responder em modelos GA de 2026. Em RAG bem feito, busca + geração ficam abaixo de 2 segundos. Para chat interativo, RAG vence. Para análise batch noturna, contexto longo vence porque você não dorme menos por causa de latência.

Qualidade de attention: o paper Liu et al. 2023 "Lost in the Middle" (arXiv:2307.03172) documentou que modelos perdem informação posicionada no meio de contexto longo. Modelos de 2024-2026 melhoraram, mas o efeito persiste em parte. Em testes "needle-in-haystack", Gemini 2.5 e Claude Opus 4.7 acham agulha em 99%+ de profundidade até 500k tokens. Acima disso, recall cai. Confiar em "ele vai lembrar de tudo" é otimismo perigoso.

Heurísticas operacionais 2026

• Repo pequeno (<200k tokens) que muda pouco: cache inteiro, contexto longo, RAG desnecessário.
• Base que muda toda hora (catálogo, ticket, documento corporativo): RAG. Cache de contexto invalida rápido demais.
• Análise one-shot de PDF de 500 páginas: contexto longo. Não vale a engenharia de RAG para uma tarefa única.
• Atendimento ao cliente em produção: RAG. Latência manda, cache híbrido (system prompt cacheado + chunks recuperados) ganha.
• Reasoning sobre código grande (refactor, security review): contexto longo vence. Estrutura cruzada de arquivos importa.

Documento: 600 paginas ~= 240k tokens
Consultas planejadas: 200 perguntas tecnicas

Opcao A: contexto longo com cache (Claude Opus 4.7)
  Cache write (1x):     240k * 18.75 USD/M  =  4.50 USD
  200 queries c/ hit:   240k * 1.50 USD/M * 200 = 72.00 USD
  Total: ~77 USD

Opcao B: RAG (pgvector + Sonnet 4)
  Embedding indice (1x):  240k * 0.10 USD/M  =  0.024 USD
  200 queries (~4k ctx):  4k * 3 USD/M * 200  =  2.40 USD
  Total: ~2.5 USD

Decisao: RAG vence por 30x em custo nessa carga.
Se fossem so 5 perguntas, contexto longo venceria.

Fontes: Google Gemini 1.5 paper (2024-02-15) arXiv:2403.05530, Anthropic prompt caching docs (2024-08-14, expandido 2025), Liu et al. (2023) "Lost in the Middle" arXiv:2307.03172, Anthropic Claude Opus 4.7 1M context release (2026-01), OpenAI Cookbook "Long context strategies" (2025-09).