Em Que Parte De Uma Palavra

Entendendo a análise de posição dentro de palavras em mecanismos de busca

Você já notou que ao pesquisar algo como "em que parte de uma palavra", o Google não apenas procura esses termos isolados, mas analisa onde cada parte da query cai dentro das palavras indexadas? Isso é mais do que simples correspondência de substring. Envolve tokenização, position increments e relevância algorítmica que poucos entendem na prática. Quando um sistema como o Solr ou o ElasticSearch processa uma query, ele decompõe o texto em tokens e registra a posição exata de cada um. Se você buscar por "palavr", o motor pode fazer um prefix match contra tokens que começam com aquela sequência. Mas se buscar "ravra" (os caracteres centrais de "palavra"), o comportamento é completamente diferente — e isso causa confusão constante.

em que parte de uma palavra a query deve aparecer para gerar relevância

A resposta curta é: depende do seu analisador e do tipo de matching configurado. Em analizadores padrão do Lucene, o ngram e o edge_ngram se comportam de formas opostas. O edge_ngram gera tokens a partir do início — então "palavra" vira "p", "pa", "pal", "palav", etc. Já o ngram comum gera todos os substrings de tamanho fixo, como "pal", "alv", "lva", "vra". Isso significa que uma query digitada parcialmente no início da palavra tem matching direto com edge_ngram, mas precisa de análise n-gram para corresponder quando a digitação começa no meio. Aqui vai um exemplo prático que me pegou recentemente: indexamos um campo de códigos de produto com o padrão "BR-2024-X789". Configurei um analyzer com edge_ngram para autocomplete no campo de busca. Funcionava perfeitamente para "BR-" e "BR-2024-", mas quando um usuário digitava "2024" sem o prefixo, o campo retornava zero resultados. O problema era que edge_ngram só gerava tokens a partir do início de cada token separado pelo hífen. A solução foi adicionar um pattern tokenizer que divide por hífen e, em seguida, aplicar edge_ngram separadamente em cada segmento, ou migrar para um filtro ngram com tamanho mínimo de 2.

Como configurar isso na prática

Vou mostrar um cenário real usando ElasticSearch, que é onde a maioria dos problemas aparece. A estrutura básica de um mapeamento com n-gram look assim: Configuração com edge_ngram para autocomplete prefixual:

{
  "settings": {
    "analysis": {
      "analyzer": {
        "autocomplete": {
          "tokenizer": "autocomplete_tokenizer",
          "filter": ["lowercase"]
        }
      },
      "tokenizer": {
        "autocomplete_tokenizer": {
          "type": "edge_ngram",
          "min_gram": 2,
          "max_gram": 20,
          "token_chars": ["letter", "digit"]
        }
      }
    }
  }
}

Com essa configuração, "palavra" seria indexado como "pa", "pal", "pall", "palav", "palavr", "palavra". Uma query "pal" encontra todos esses tokens. Mas "lav" não encontra nada — o que é esperado e muitas vezes causa frustração. Para cobrir ocorrências no meio da palavra, o ngram comum é mais adequado:

{
  "tokenizer": {
    "autocomplete_tokenizer": {
      "type": "ngram",
      "min_gram": 2,
      "max_gram": 20,
      "token_chars": ["letter", "digit"]
    }
  }
}

Agora "palavra" gera "pa", "al", "lav", "avr", "vra", "pal", "alv", "avra", e assim por diante. O custo é que o índice fica significativamente maior — em torno de 3 a 5 vezes o tamanho original do campo textual, dependendo da length média das palavras. O primeiro erro comum é aplicar n-gram tanto na indexação quanto na query. Quando ambos usam o mesmo tokenizer, você perde a possibilidade de usar queries mais enxutas. O ideal é indexar com n-gram e fazer a query com um tokenizer simples que não decompõe ainda mais — caso contrário, "palavra" na query vira "pa", "al", "lav" e o scoring fica distorcido porque cada termo da query compete contra múltiplos tokens do índice. O segundo problema, mais sutil, é o position increment. Em campos multi-token como endereços ou nomes compostos, o Lucene registra a distância entre tokens. Se você tem "São Paulo" e configura o analyzer para preservar posições, uma query por "o Pau" pode não corresponder porque as posições não se alinham. A workaround é usar "position_increment_gap": 0 no mapeamento do campo se você quiser que substrings cruzem limites de token sem penalidade.

Um terceiro ponto: muitos desenvolvedores esquecem que campos com n-gram consomem muito mais memória no field cache. Se você está rodando aggregations ou sorting no mesmo campo que recebeu a análise n-gram, espere degradação de performance. Nesse caso, o correto é manter o campo n-gram separado de campos numéricos ou agregáveis.

Quando isso não funciona

N-gram e edge_ngram não resolvem problemas de morfologia. Se alguém busca "correndo" e seu índice tem apenas "correr", nenhum n-gram vai ajudar — a menos que você adicione um stemmer ou lematizador ao pipeline. Para português, o PortugueseAnalyzer nativo do Lucene já inclui stemmer, mas ele tem limitações reconhecidas: não trata bem variações irregulares como "houve"/"haver" e pode overstemmar palavras como "moderno" para "mod" em vez de "modern". Se o seu objetivo é busca semântica — entender que "correndo" se relaciona com "velocidade" mesmo sem sobreposição de caracteres — n-gram é a ferramenta errada. Você precisaria de embeddings ou BM25 com expansão de query via sinônimos, não de indexação fonética ou de substring.

Resumo pragmático

Para autocomplete no início da palavra, use edge_ngram com min_gram 2 e token_chars restringidos a letras e dígitos. Para matches no meio da palavra, use n-gram comum, mas prepare-se pelo aumento de 3x a 5x no tamanho do índice. Sempre separe campos de busca n-gram de campos que recebem aggregations. E não esqueça de verificar o position_increment_gap se seus tokens podem conter espaços ou hifens. O ganho médio em usabilidade de uma barra de busca com autocomplete bem configurado costuma reduzir o tempo entre entrada e resultado de cerca de 4 segundos para menos de 800ms, segundo medições que fiz em projetos anteriores com bases de 2 milhões de documentos. O custo é indexação mais lenta durante o reindex — planeje janelas de manutenção de 30 a 45 minutos a mais do que o normal, dependendo do throughput do seu cluster.