A busca vetorial recupera conteúdo por significado, não por palavra exata, comparando vetores numéricos. Segundo a OpenAI Platform (2024), o modelo text-embedding-3-small gera vetores de 1.536 dimensões. Cada consulta custa frações de centavo, mas exige um banco de vetores. Monte em cinco passos e meça antes de migrar.

A busca vetorial no WordPress transforma cada post em um vetor numérico e responde à consulta pelo conteúdo mais próximo em significado, não pela coincidência de palavras. Isso resolve o ponto cego da busca nativa, que falha quando o leitor digita um sinônimo ou uma pergunta em vez do termo cravado no texto. Aqui você vai montar a estrutura completa em cinco passos, entender quando o ganho justifica o custo de API e ver onde a abordagem quebra em produção. O percurso vale para quem já trabalha com conteúdos de IA e WordPress da FULL e quer recuperação semântica real, sem prometer mágica.

Primeiros passos: Visão geral da busca vetorial

A busca vetorial no WordPress depende de três peças que conversam entre si: um modelo de embeddings, um banco de vetores e uma camada de consulta. O modelo converte cada texto em uma lista de 1.536 números, e a consulta busca os mais próximos por distância de cosseno.

O banco guarda esses vetores com índice para responder rápido, e a tabela abaixo posiciona as três peças antes de você escolher o stack.

Entender essa divisão é o que separa um protótipo que funciona de um que cai sob tráfego, e dá para montar tudo sem licença paga para medir o ganho antes de comprometer orçamento. Para o vocabulário formal, vale revisar o conceito de embeddings antes de codar.

Por que a busca vetorial supera a busca nativa do WordPress

A busca nativa do WordPress roda um LIKE %termo% no MySQL e só encontra resultados que contêm a palavra exata digitada, ignorando sinônimos, plural e intenção. A busca vetorial resolve isso porque compara significado: a pergunta “como deixar o site rápido” recupera o artigo sobre cache mesmo sem a palavra “rápido” no texto.

O ganho aparece em sites de conteúdo denso, onde a mesma ideia é descrita com palavras diferentes em dezenas de posts. Nos tickets de suporte da FULL, a queixa de “busca interna que não acha nada” é recorrente em blogs grandes, e quase sempre a causa é a limitação do LIKE. A busca vetorial muda o critério de coincidência de string para proximidade semântica, o que se conecta diretamente com a intenção de busca do leitor que digita. Vale lembrar que a busca vetorial não substitui o filtro por categoria ou por data: ela melhora o ranqueamento por relevância de texto, e é nesse recorte que o ganho aparece de forma consistente em blogs com muito histórico.

Passo a passo: Montar a busca vetorial em 5 etapas

Montar a busca vetorial exige cinco etapas em ordem: escolher o modelo, criar o banco de vetores, gerar os embeddings em fila, expor o endpoint de consulta e medir contra a busca nativa. Em uma base de 5 mil posts, o ciclo completo costuma levar de dois a quatro dias, e o gargalo quase sempre é a geração inicial dos vetores.

Escolha o modelo de embeddings

Comece pelo text-embedding-3-small da OpenAI: 1.536 dimensões, custo na casa de centavos por milhão de tokens e qualidade suficiente para conteúdo em português. Modelos maiores, como o text-embedding-3-large de 3.072 dimensões, dobram o custo de armazenamento sem ganho proporcional em busca de blog. Valide gerando o vetor de um post e conferindo se ele retorna uma lista de 1.536 números.

Crie o banco de vetores

Suba o pgvector como extensão do PostgreSQL e crie uma coluna vector(1536) na tabela de índice. O pgvector aceita índice HNSW, que troca um pouco de precisão por consultas abaixo de 50 ms. Valide rodando um CREATE INDEX HNSW e medindo o tempo de uma consulta de teste com EXPLAIN ANALYZE.

Gere os embeddings em fila

Nunca gere todos os vetores de uma vez: acima de 50 mil posts isso estoura o rate limit da API. Use o Action Scheduler em lotes de 100 posts e grave o vetor no postmeta para não reprocessar conteúdo que não mudou. Valide conferindo que a fila esvazia sem erro 429 da API.

Exponha o endpoint de consulta

Registre uma rota na WP REST API que receba a pergunta, gere o embedding dela e devolva os IDs mais próximos por cosseno. A doc oficial da WP REST API (developer.WordPress.org) traz o passo de register_rest_route. Valide chamando o endpoint com uma pergunta e conferindo a ordem dos resultados.

Meça contra a busca nativa

Antes de trocar a busca do site, rode 20 consultas reais nas duas e compare a relevância dos cinco primeiros resultados. Se a busca vetorial não ganhar em pelo menos metade dos casos, o problema está nos embeddings ou no conteúdo, não no método. Valide registrando os resultados em uma planilha antes de migrar.

Quando a busca vetorial não compensa no WordPress

A busca vetorial nem sempre paga o próprio custo: em sites pequenos, com menos de 200 posts e termos bem cravados, o LIKE nativo já entrega resultado aceitável e a API vira despesa sem retorno. O custo real não é só por consulta; é a reindexação constante e a infra do banco de vetores.

A gente vê no suporte da FULL que boa parte dos sites que pedem busca “inteligente” na verdade tem problema de conteúdo mal estruturado, e nesse caso nenhum vetor resolve. O critério honesto é volume e diversidade léxica: muitos posts dizendo a mesma coisa com palavras diferentes justificam o vetor; um catálogo enxuto, não. Medir a taxa de busca sem resultado no Google Search Console ajuda a decidir com dado, não com intuição. Antes de investir, rode esse diagnóstico por um mês e veja quantas buscas internas terminam sem clique: esse número, e não a moda do momento, é o que justifica o custo recorrente de um banco de vetores.

Sincronizar o vetor com a edição de conteúdo

Manter o vetor sincronizado com o conteúdo é o ponto que mais quebra em produção: um post editado sem reindexação serve um vetor desatualizado e devolve resultado errado sem avisar ninguém. A correção é amarrar a regeneração ao hook save_post, com uma guarda de hash do conteúdo no postmeta.

Sem essa guarda, cada salvamento de rascunho dispara uma chamada de API paga à toa, já que o save_post roda em todo update. Em bases ativas, agendar a reindexação via Action Scheduler em vez de rodar no próprio hook evita travar a tela do editor. Esse cuidado de ciclo de vida é o mesmo rigor que se aplica a Core Web Vitals no WordPress: o ganho técnico só vale se for sustentável no dia a dia. Outra guarda útil é versionar o nome do modelo no postmeta: quando você troca o text-embedding-3-small por outro modelo, os vetores antigos ficam incompatíveis, e marcar a versão evita comparar embeddings gerados por modelos diferentes.

Stack e custo: Quanto custa rodar busca vetorial

Rodar busca vetorial cobra em dois lugares: a geração de embeddings, uma vez por post mais as edições, e a infra do banco de vetores. Para um site de 5 mil posts, gerar os vetores iniciais com o text-embedding-3-small custa poucos dólares no total, já que o preço é por token e posts de blog são curtos.

O peso recorrente é o banco: pgvector roda na sua própria infra sem licença, enquanto Pinecone e Weaviate cobram por volume gerenciado. A escolha entre eles é de posicionamento, não de “melhor”: pgvector compete por custo zero de infra e proximidade do dado; Pinecone compete por escala gerenciada; Weaviate compete por busca híbrida nativa. Para priorizar o conteúdo a indexar primeiro, o Semrush para análise de SEO aponta as páginas com mais demanda. Some o custo de API ao custo de infra e compare com o ganho de retenção: se a busca melhor não segura o leitor por mais tempo, o investimento não se paga.

Ative a busca vetorial com o stack que a FULL já entrega

Montar busca vetorial é trabalho de integração, mas o substrato é um WordPress bem servido de plugins premium, e é aí que o bundle da FULL muda a conta. O plano PRO da FULL custa R$849,90 por mês para dez sites, o que dá R$85 por site com 17 plugins premium inclusos, entre eles o Rank Math PRO e o WP Rocket que sustentam a camada de SEO e performance ao redor da busca. A gente vê no suporte da FULL que quem tenta licenciar cada plugin avulso para um projeto de IA gasta mais só nas licenças do que no R$85 por site do bundle. Conheça os planos em FULL.services/planos e libere o stack antes de investir no banco de vetores. Para o lado de visibilidade em motores generativos, vale gerar e publicar seu arquivo com a ferramenta de llms.txt e revisar como a IA generativa no WordPress consome esse conteúdo.

• Se o site tem menos de 200 posts → mantenha a busca nativa do WordPress e invista o orçamento em conteúdo.
• Se você controla a infra e quer custo zero de licença → use pgvector no PostgreSQL com índice HNSW.
• Se a base passa de 100 mil vetores e cresce rápido → evite gerenciar o índice na mão, escolha Pinecone ou Weaviate.
• Se o conteúdo muda toda hora → amarre a reindexação ao save_post com guarda de hash, senão o vetor desatualiza.

Perguntas frequentes sobre busca vetorial no WordPress

Próximos passos para implementar a busca vetorial

A busca vetorial no WordPress deixou de ser experimento de laboratório e virou uma camada viável para sites de conteúdo denso, desde que você meça o ganho antes de migrar e mantenha o vetor sincronizado com a edição. Comece pequeno: indexe os 200 posts de maior tráfego, exponha o endpoint na WP REST API e compare com a busca nativa em consultas reais. O custo de API é baixo; o custo escondido está na reindexação e na infra do banco de vetores. Se a relevância subir nos seus testes, escale a fila e o índice com calma. Para continuar aprendendo, o FULL Academy reúne os tutoriais, guias e reviews de WordPress em um só lugar, e o guia de tráfego orgânico com Rank Math mostra como transformar a busca melhor em retenção.

Legenda: o fluxo mostra como a pergunta vira vetor e retorna os posts mais próximos por cosseno, o que comprova a recuperação por significado.