Explore o novo chatbot do Developer Center! O MongoDB AI chatbot pode ser acessado na parte superior da sua navegação para responder a todas as suas perguntas sobre o MongoDB .

Learn why MongoDB was selected as a leader in the 2024 Gartner® Magic Quadrant™
Desenvolvedor do MongoDB
Central de desenvolvedor do MongoDBchevron-right
Produtoschevron-right
Atlaschevron-right

Análise de consultas, parte 2: ajustando o sistema

Erik Hatcher10 min read • Published Jan 17, 2024 • Updated Jan 17, 2024
AtlasPesquisa
Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Artigo
star-empty
star-empty
star-empty
star-empty
star-empty
Na Parte 1: Conheça suas consultas, demonstramos a importância de monitorar e ajustar seu sistema de pesquisa e o efeito dramático que isso pode ter em seus negócios. Nesta segunda parte, vamos nos aprofundar nas técnicas técnicas disponíveis para ajustar e ajustar com base na análise do resultado da sua consulta.
A Análise de Query está disponível em pré-visualização pública para todos os clusters do MongoDB Atlas em um M10 ou superior executando o MongoDB v5.0 ou superior para visualizar as informações analíticas dos termos de pesquisa monitorados na UI do Atlas. O Atlas Search não rastreia termos de pesquisa nem exibe análises para queries em clusters de nível gratuito e compartilhado.
Atlas Search Query Analytics concentra-se inteiramente na frequência e no número de resultados retornados de cada chamada $search. Há também uma série de métricas de pesquisa disponíveis para monitoramento operacional, incluindo CPU, memória, tamanho do índice e outros pontos de dados úteis.

Ações perspicazes

Existem algumas grandes categorias de ações que podem ser tomadas com base nos insights da análise de consultas de pesquisa, que não são mutuamente exclusivas e geralmente funcionam em sinergia umas com as outras.

Experiência do utilizador

Vamos começar com a experiência do usuário em si, desde a caixa de pesquisa até a apresentação dos resultados. Você está acompanhando uma consulta de resultados zero: o que o usuário experimentou quando isso ocorreu? Você está mostrando apenas algo como "Sorry, nothing found. Try again! "? Considere mostrar documentos com os quais o usuário se envolveu anteriormente, fornecer links ou pesquisar automaticamente por consultas mais flexíveis, talvez removendo alguns dos termos de consulta do usuário e perguntando: "Did you mean this?" Enquanto o usuário estava digitando a consulta, você está fornecendo sugestão automática/digitação antecipada para que os erros de digitação sejam corrigidos na consulta de pesquisa completa?
Para consultas que retornam resultados, há informações suficientes fornecidas na interface do usuário para permitir que o usuário refine os resultados?
Considere estas melhorias:
  • Adicione sugestões enquanto o usuário digita, o que pode ser facilitado aproveitando ngrams por meio do operadorde preenchimento automático ou construindo uma collection e índice de preenchimento automático especializado para essa finalidade.
  • Adicionar navegaçãofacetada, permitindo ao usuário detalhar categorias específicas e restringir os resultados mostrados.
  • Forneça queriesmoreLikeThis para ampliar os resultados.

Construção de consultas

A forma como as queries são construídas é metade do segredo para obter ótimos resultados de pesquisa. (A outra metade é como seu conteúdo é indexado.) Os termos de pesquisa inseridos pelo usuário são a chave para o rastreamento do Query Analytics, mas nostrás da solicitação de pesquisa completa há muito mais.
Sua interface de usuário fornece os termos de pesquisa recebidos e prováveis parâmetros adicionais. Cabe à camada de aplicativos construir o pipeline de agregação que usa $search a partir desses parâmetros.
Aqui estão algumas técnicas de query que podem influenciar a qualidade dos resultados da pesquisa:
  • Incorpore sinônimos, talvez de uma forma ponderada pela relevância, em que as cláusulas sem sinônimos sejam mais valorizadas do que as cláusulas com sinônimos adicionados.
  • Aproveite as cláusulascompound.should para permitir que os cálculos de relevância subjacentes façam sua milagrosidade. A distribuição de termos de query em vários campos - com aumentos de pontuação independentes representando a importância, ou peso, de cada campo - permite que os melhores documentos subam nos resultados, mas ainda fornece que todos os documentos correspondentes sejam retornados. Por exemplo, uma query de "the matrix " na collection de filmes se beneficiaria do aumento de title mais de plot.
  • Use a query de múltiplas análises. Aproveite um campo que está sendo analisado de várias maneiras. Aumente o peso das correspondências exatas e diminua o peso das correspondências menos exatas e mais imprecisas. Consulte a seção "Index configuration " abaixo.

Configuração do índice

A configuração do índice é a outra metade dos excelentes resultados de pesquisa e depende de como os índices de pesquisa subjacentes são criados a partir de seus documentos. Aqui estão algumas técnicas de configuração de índice a serem consideradas:
  • Multi-análise: Configure seus principais campos de conteúdo para serem analisados/tokenizados de várias maneiras, variando de exato ( tipo token ) a quase exato ( tokenem letras minúsculas, diacríticos normalizados), tokenizado padrão (espaços em branco e caracteres especiais ignorados), análise específica do idioma e até mesmo difuso.
  • Considerações sobre o idioma: se você souber o idioma do conteúdo, use-o a seu favor usando o analisador de idioma apropriado. Considere fazer isso de uma forma de análise múltipla para que, no momento da consulta, você possa incorporar considerações específicas da linguagem nos cálculos de relevância.
Vamos destacar alguns ajustes específicos comuns do Atlas Search a serem considerados.

Adicionando sinônimos

Por que “Jacky Chan” não correspondeu a nenhum dos vários filmes que deveriam corresponder? Em primeiro lugar, o nome dele está escrito “Jackie Chan,, então o usuário cometeu um erro de ortografia e não temos a correspondência exata do nome com erros ortográficos. ( É aqui que $match sempre falhará e uma opção de pesquisa mais difusa é necessária.) Ocorre que nosso aplicativo estava fazendo phrase queries. Soltamos isso adicionando algumas cláusulascompound.shouldadicionais usando um operadortextdifusa e também adicionamos uma equivalência de sinônimos "jacky "/"jackie " para garantir. Ao fazer essas alterações, ao longo do tempo, vamos ver que o número de ocorrências para "Jacky Chan'' in the “Tracked Queries with No Results " diminuirá.
O text operador fornece expansão de sinônimos em tempo de consulta. Os sinônimos podem ser bidirecionais ou unidirecionais. Os sinônimos bidirecionais são chamados equivalent de nos mapeamentos de sinônimos da Atlas Search — por exemplo, "car," "automobile," e " " — portanto,vehicle uma consulta contendo qualquer um desses termos também corresponderia a documentos contendo qualquer um dos outros termos. Essas palavras são "equivalent" porque todas podem ser usadas de forma intercambiável. Sinônimos unidirecionais são explicit mapeamentosanimal doganimal—cat digamosanimal catdog,dog" " -> " " e " " -> "dog." — de modo que uma consulta para " " corresponderá a documentos com " " ou " ", mas uma consulta para " " será apenas para isso: " "

Aprimorando a construção de consultas

Usar um único operador, como text, em um caminho curinga, facilita a localização (“recall” na linguagem de recuperação de informações), mas não ajuda narelevância quando os documentos mais coincidentes aparecem no topo dos resultados. Uma forma eficaz de melhorar a relevância é adicionar várias cláusulas ampliadas para dar mais peso a alguns camposdo que outros.
Geralmente, é uma boa ideia incluir um operadortextem umcompound.should para permitir que sinônimos entrem em jogo (o operadorphraseatualmente não dá suporte à expansão de sinônimos) junto com cláusulasphraseadicionais que correspondam com mais precisão ao que o usuário digitou. Adicione fuzzy ao operadortextpara corresponder, apesar de pequenos erros de digitação/variações de palavras.
Você pode observar que o Search Tester atualmente usa um * caminho curinga para combinar todos os campos analisados textualmente; considere os campos que realmente fazem mais sentido serem pesquisados e se aumentos separados devem ser atribuídos a eles para ajustar a relevância. Usar um * curinga não lhe dará a melhor relevância, pois cada campo tem o mesmo peso de reforço. Isso pode fazer com que resultados objetivamente ruins obtenham maior relevância do que deveriam. Além disso, o desempenho de um curinga é afetado pela quantidade de campos que você tem em toda a coleção, o que pode aumentar à medida que você adiciona documentos .
Como exemplo, vamos supor que a nossa caixa de pesquisa potencialize a pesquisa de filmes. Esta é a aparência de uma primeira passagem com base na relevância para uma consulta de "purple rain," gerada a partir do nosso aplicativo, primeiro em prosa: Considere as correspondências do termo da consulta (OR'd) nos campostitle, cast e plot, aumentando as correspondências nesses campos nessa ordem, e vamos aumentar até 11 quando a consulta corresponder a uma frase (os termos da consulta em ordem sequencial) de qualquer um desses campos.
Agora, na sintaxe $search do Atlas, o operador de query principal se torna um compound de um grupo de shoulds com diferentes impulsos:
1"compound": {
2 "should": [
3 {
4 "text": {
5 "query": "purple rain",
6 "path": "title",
7 "score": {
8 "boost": {
9 "value": 3.0
10 }
11 }
12 }
13 },
14 {
15 "text": {
16 "query": "purple rain",
17 "path": "cast",
18 "score": {
19 "boost": {
20 "value": 2.0
21 }
22 }
23 }
24 },
25 {
26 "text": {
27 "query": "purple rain",
28 "path": "plot",
29 "score": {
30 "boost": {
31 "value": 1.0
32 }
33 }
34 }
35 },
36 {
37 "phrase": {
38 "query": "purple rain",
39 "path": [
40 "title",
41 "phrase",
42 "cast"
43 ],
44 "score": {
45 "boost": {
46 "value": 11.0
47 }
48 }
49 }
50 }
51 ]
52}
Observe a duplicação da query do usuário em vários lugares desse estágio $search. Isso merece um pouco de codificação de sua parte, parametrizando valores, fornecendo ajustes fáceis e completos no arquivo de configuração para esses valores de aumento, nomes de campos e assim por diante, para facilitar a criação dessas cláusulas de consulta mais ricas em seu ambiente.
Esse tipo de espalhar uma consulta em campos impulsionados de forma independente é a primeira chave para desbloquear uma melhor relevância em suas pesquisas. A próxima chave é consultar com diferentes análises, permitindo que vários níveis de exatidão para a imprecisão tenham aumentos independentes e, novamente, eles podem ser espalhados por caminhos de campos com pesos diferentes.
A próxima seção detalha a criação de vários analisadores para campos; imagine conectá-los aos pathsde outro grupo de cláusulasshould! Sim, você pode se deixar levar por essa técnica, embora deva começar de forma simples. Muitas vezes, impulsionar os campos de forma independente e apropriada para o seu domínio é tudo o que se precisa para obter uma boa capacidade de localização e relevância.

Configuração da análise de campo

A forma como seus dados são indexados determina se e como eles podem ser combinados com consultas e, portanto, afeta os resultados que seus usuários experimentam. Ajustar a configuração do índice de campo pode alterar uma solicitação de pesquisa de não encontrar documentos para uma correspondência conforme o esperado (ou vice-versa!). Sua configuração de índice é sempre um trabalho em andamento, e o Query Analytics pode ajudar a acompanhar esse progresso. Ele evoluirá à medida que suas necessidades de consulta mudarem.
Se você configurou seu índice inteiramente com mapeamentos dinâmicos, começou bem! Você poderá consultar seus campos de maneiras específicas do tipo de dados — numericamente, por intervalos de datas, filtragem e correspondência, até mesmo regexing em valores de string. O mais interessante é a capacidade de consulta do texto analisado. Os valores de campo de string são analisados. Por padrão, nas configurações de mapeamento dinâmico, cada campo de string é analisado usando o analisadorlucene.standard. Este analisador faz um trabalho geralmente decente de dividir strings de texto completo em termos pesquisáveis (ou seja, o "words" do texto). Esse analisador não faz nenhum tratamento específico do idioma. Assim, por exemplo, as palavras "find," "finding," e "finds" são todas indexadas como termos únicos com análise padrão/padrão, mas seriam indexadas como o mesmo termo radical ao usar lucene.english.

O que está em uma palavra?

Aplicando algum conhecimento específico de domínio e dados, podemos ajustar como os termos são indexados e, portanto, quão facilmente encontrados e relevantes eles são para os documentos. Sabemos que nosso filme plot está em inglês, podemos mudar o analisador para lucene.english, abrindo a capacidade de localização de filmes com queries que se aproximam das palavras em inglês no plotreal.O Atlas Search tem mais 40 analisadores específicos de idiomas disponíveis.

Multi-análise

A Análise de Query indicará queries com baixo desempenho, mas cabe a você fazer ajustes. Para enfatizar um ponto importante que está sendo reiterado aqui de várias maneiras, a forma como seu conteúdo é indexado afeta como ele pode ser consultado, e a combinação de como o conteúdo é indexado e como é consultado controla a ordem em que os resultados são retornados (também denominado relevância). Uma técnica realmente útil disponível com o Atlas Search é chamada deMultianalisador, habilitando cada campo a ser indexado usando qualquer número de configurações de analisadores. Cada uma dessas configurações é indexada independentemente (seu próprio índice invertido, dicionário de termos e tudo mais).
Por exemplo, poderíamos indexar o campo de título para fins de preenchimento automático e também poderíamos indexá-lo como texto em inglês e, em seguida, foneticamente. Também podemos usar nosso analisador personalizado definido (veja abaixo) para o termo shingling, bem como nosso analisador de todo o índice, padronizado para lucene.standard se não for especificado.
1"title": [
2 {
3 "foldDiacritics": false,
4 "maxGrams": 7,
5 "minGrams": 3,
6 "tokenization": "nGram",
7 "type": "autocomplete"
8 },
9 {
10 "multi": {
11 "english": {
12 "analyzer": "lucene.english",
13 "type": "string"
14 },
15 "phonetic": {
16 "analyzer": "custom.phonetic",
17 "type": "string"
18 },
19 "shingles": {
20 "analyzer": "custom.shingles",
21 "type": "string"
22 }
23 },
24 "type": "string"
25}
Como são indexados de forma independente, também podem ser consultados de forma independente. Com essa configuração, os títulos podem ser consultados foneticamente ("kat in the hat "), usando derivação com reconhecimento de inglês ("find nemo "), ou com shingles (de modo que as queries "the purple rain " possam criar a frase "purple rain " queries).
Explore os analisadoresintegrados disponíveis e experimente a multiindexação e a query. Às vezes, um pouco de análise personalizada pode realmente resolver o problema, portanto, tenha em mente essa técnica para uma maneira eficaz de melhorar a capacidade de localização e a relevância. Aqui estão nossas definições de analisadorcustom.shingles e custom.phonetic, mas por favor, não copie isso implicitamente. Certifique-se de testar e entender esses ajustes no que se refere aos seus dados e tipos de queries:
1"analyzers": [
2 {
3 "charFilters": [],
4 "name": "standard.shingles",
5 "tokenFilters": [
6 {
7 "type": "lowercase"
8 },
9 {
10 "maxShingleSize": 3,
11 "minShingleSize": 2,
12 "type": "shingle"
13 }
14 ],
15 "tokenizer": {
16 "type": "standard"
17 }
18 },
19 {
20 "name": "phonetic",
21 "tokenFilters": [
22 {
23 "originalTokens": "include",
24 "type": "daitchMokotoffSoundex"
25 }
26 ],
27 "tokenizer": {
28 "type": "standard"
29 }
30 }
31]
A query, naturalmente, ainda fará query do índice invertido configurado como padrão para um campo, a menos que o caminho especifique um "multi ".
Um exemplo simples de consultar especificamente o multicustom.phonetic, conforme o definimos aqui, tem a seguinte aparência:
1$search: {
2 "text": {
3 "query": "kat in the hat",
4 "path": { "value": "title", "multi": "custom.phonetic" }
5 }
6}
Agora, visualize a combinação dessa análise “multi” com cláusulascompound.shouldaprimoradas de várias maneiras para obter controles de encontrabilidade e relevância refinados que sejam tão sutis quanto seu domínio vale a pena.
Dica de especialista em ajuste de relevância: use algumas cláusulas, uma por campo multianalisado de forma independente, para aumentar do mais exato (melhor! ) para o menos exato, até a correspondência difusa conforme necessário.
Todos esses vários truques - desde análise de linguagem, palavras de derivação e um parâmetro difuso para corresponder palavras próximas, mas não muito corretas, e transmitir termos de consulta em vários campos - são ferramentas úteis.

Acompanhamento de queries de pesquisa do Atlas

Como você faz para incorporar o Atlas Search Query Analytics em seu aplicativo? É um processo bastante direto de adicionar uma pequena seção "tracking " ao seu estágio $search.
As consultas que contêm a estruturatracking.searchTerms são rastreadas (ressalva para a camada de cluster qualificada):
1{
2 $search: {
3 "tracking": {
4 "searchTerms": "<query to track>"
5 }
6 }
7}
Em Java, as SearchOptions de rastreamento são construídas assim:
1SearchOptions opts = SearchOptions.searchOptions()
2 .option("scoreDetails", BsonBoolean.TRUE)
3 .option("tracking", new Document("searchTerms", query_string));
Se você tiver uma caixa de pesquisa simples e essa for a única entrada fornecida para uma consulta de pesquisa, essa string será a melhor opção para o valor searchTerms. Em alguns casos, a consulta a ser rastreada é mais complicada ou merece mais contexto. Ao fazer o dever de casa para este artigo, encontramos um de nossos primeiros usuários do recurso Query Analytics que estava usando códigos de rastreamento para o valorsearchTerms, correspondente a outra collection que contém o contexto completo da consulta, como uma lista de IP que estão sendo usados para detecção de intrusão na rede.
A simples adição dessas informações de rastreamento abre a porta para uma maior compreensão das consultas que ocorrem em seu sistema de pesquisa.

Conclusão

Os ajustes específicos que funcionam melhor para seus desafios de consulta específicos são onde a arte desse ofício entra em ação. Há muitas maneiras de melhorar os resultados de uma query específica. Mostramos várias técnicas a serem consideradas aqui. Principais conclusões:
  • A pesquisa é o gateway usado para gerar receita, pesquisar e envolver os usuários.
  • Saiba o que seus usuários estão enfrentando e use esse insight para iterar melhorias.
  • A correspondência de resultados de classificação com imprecisão e relevância é uma arte e uma ciência, e há muitas opções.
O Atlas Search Query Analytics é uma boa primeira etapa no processo de gerenciamento de query de pesquisa virtuose.
Quer continuar a conversa? Acesse os Fóruns da Comunidade de Desenvolvedores do MongoDB!

Ícone do FacebookÍcone do Twitterícone do linkedin
Avalie esse Artigo
star-empty
star-empty
star-empty
star-empty
star-empty
{Parte de uma série
Análise de query de pesquisa do Atlas
Mais nesta série
  • Análise de queries – Parte 1: conheça suas queries
Relacionado
Início rápido

Construindo pipelines RAG com haystack e MongoDB Atlas


Sep 18, 2024 | 4 min read
exemplo de código

Trends Analyser


Sep 11, 2024 | 1 min read
Artigo

Como pausar e retomar clusters do Atlas de maneira fácil


Sep 11, 2024 | 5 min read
Tutorial

Influencie a classificação dos resultados de pesquisa com pontuações de funções no Atlas Search


Feb 03, 2023 | 5 min read
Sumário
  • Ações perspicazes