Pesquisa Cognitiva Perguntas Frequentes

Azure Cognitive Search é um serviço no Azure que fornece um motor de pesquisa dedicado e armazenamento persistente do seu conteúdo pesmável para cenários completos de pesquisa de texto. Inclui também IA opcional e integrada utilizada durante a indexação para extrair mais texto e estrutura do conteúdo bruto.

O fluxo de trabalho primário é criar, carregar e consultar um índice. Embora possa utilizar o portal para a maioria das tarefas, a Pesquisa Cognitiva destina-se a ser usada programáticamente, manuseando pedidos a partir do código do cliente. O suporte programático é fornecido através de APIs REST e bibliotecas de clientes em .NET, Python, Java e JavaScript SDKs para Azure.

A Azure Search foi renomeada para Azure Cognitive Search em outubro de 2019 para refletir o uso expandido (ainda opcional) de competências cognitivas e processamento de IA em operações de serviço.

O analisador padrão usado para tokenização é lucene padrão e é agnóstico da linguagem. Caso contrário, o suporte linguístico é expresso através de analisadores linguísticos que aplicam regras linguísticas ao conteúdo de entrada (indexação) e saída (consultas). Algumas características, tais como pesquisa semântica e soletradora, estão limitadas a um subconjunto de línguas.

O código do cliente deve ligar para as bibliotecas do cliente ou PARA ASP para se ligar a um índice de pesquisa, formular consultas e lidar com respostas. Também pode escrever código que constrói e atualiza um índice, ou executa indexadores programáticamente ou por script.

Nem sempre. A API REST é sempre a primeira a implementar novas funcionalidades nas versões API de pré-visualização, e as versões geralmente disponíveis suportam todas as operações programáticas. As bibliotecas de clientes em Azure SDKs irão captar novas funcionalidades ao longo do tempo, mas são lançadas na sua própria agenda.

Embora as APIs REST sejam as primeiras a sair com funcionalidades mais recentes, os SDKs Azure fornecem mais suporte de codificação, e são recomendados sobre REST, a menos que uma funcionalidade necessária não esteja disponível.

Não pode parar um serviço de pesquisa. Em Azure Cognitive Search, os recursos de computação são atribuídos quando o serviço é criado. Não é possível libertar e recuperar esses recursos a pedido.

O nível de serviço, o nome e a região são fixados para o tempo de vida do serviço.

Desde que siga a lista de verificação antes de mover recursos e certifique-se de que cada passo está concluído, não deve haver tempo de inatividade.

Refere-se à ingestão, análise e armazenamento de conteúdo textual e fichas que povoam um índice de pesquisa. A indexação cria índices invertidos e outras estruturas de dados físicos que suportam a recuperação de informação.

Não há apoio nativo para a gestão de índices. Os índices de pesquisa são considerados estruturas de dados a jusante, aceitando conteúdos de outras fontes de dados que recolhem dados operacionais. Como tal, não há suporte incorporado para apoiar e restaurar índices porque a expectativa é que você reconstruiria um índice a partir de dados de origem se o apagasse, ou quisesse movê-lo.

No entanto, se quiser mover um índice entre os serviços de pesquisa, pode experimentar o código de amostra de recuperação de índices-backup neste Azure Cognitive Search repo de amostra .NET.

Não, se apagar um índice de Azure Cognitive Search ou serviço, não pode ser recuperado. Quando elimina um serviço de pesquisa, todos os índices do serviço são apagados permanentemente.

Se estiver a utilizar o indexante de pesquisa para SQL do Azure Base de Dados, não existem restrições à utilização de réplicas primárias ou secundárias como fonte de dados ao construir um índice de raiz. No entanto, refrescar um índice com atualizações incrementais (com base em registos alterados) requer a réplica primária. Este requisito provém de Base de Dados SQL, que garante o rastreio de alterações apenas nas réplicas primárias. Se tentar usar réplicas secundárias para uma carga de trabalho de atualização de índices, não há garantia de que obtenha todos os dados.

As consultas executam um único índice de pesquisa que está hospedado no seu serviço de pesquisa. Não é possível juntar vários índices para pesquisar conteúdo em dois ou mais índices, mas pode consultar índices de mesmo nome em vários serviços de pesquisa.

O caso mais comum é não saber que cada tipo de consulta suporta diferentes comportamentos de pesquisa e níveis de análises linguísticas. A pesquisa completa de texto, que é a carga de trabalho predominante, inclui uma fase de análise de linguagem que decompõe os termos das formas de raiz. Este aspeto da análise de consulta lança uma rede mais ampla sobre possíveis partidas, porque o termo tokenized corresponde a um maior número de variantes.

As consultas wildcard, fuzzy e regex, no entanto, não são analisadas como consultas regulares de termo ou frases e podem levar a má recordação se a consulta não corresponder à forma analisada da palavra no índice de pesquisa. Para obter mais informações sobre a análise e análise de consultas, consulte a arquitetura de consulta.

A maioria das consultas de pesquisa wildcard, como prefixo, fuzzy e regex, são reescritas internamente com termos correspondentes no índice de pesquisa. Este processamento extra aumenta a latência. Além disso, consultas de pesquisa amplas, como a* por exemplo, que são suscetíveis de ser reescritas com muitos termos podem ser lentas. Para pesquisas de wildcard performantes, considere definir um analisador personalizado.

Não, uma consulta é sempre traçada para um único índice.

As pontuações de pesquisa são geradas para consultas completas de pesquisa de texto, com base nas propriedades estatísticas dos termos correspondentes, e ordenadas de alto a baixo no conjunto de resultados. Os tipos de consulta que não são pesquisa completa de texto (wildcard, prefixo, regex) não são classificados por uma pontuação de relevância. Este comportamento é propositado. Uma pontuação constante permite que os jogos encontrados através da expansão de consulta sejam incluídos nos resultados, sem afetar o ranking.

Por exemplo, suponha que uma entrada de "tour*" numa pesquisa wildcard produz fósforos em "tours", "tourettes" e "tourmaline". Dada a natureza destes resultados, não há como inferir quais termos são mais valiosos que outros. Por esta razão, as frequências de termo são ignoradas quando a pontuação resulta em consultas de tipos wildcard, prefixo e regex. Os resultados da pesquisa com base numa entrada parcial recebem uma pontuação constante para evitar distorções em relação a jogos potencialmente inesperados.

A Cognitive Search não armazena dados de clientes fora da região em que o serviço é implantado.

Sim, se usar as competências incorporadas com base nos Serviços Cognitivos, o indexante envia pedidos aos Serviços Cognitivos sobre a rede interna. Se adicionar uma habilidade personalizada, o indexante enviará conteúdo para o URI fornecido na habilidade personalizada.

Não exatamente. Normalmente, os utilizadores autorizados a executar a sua aplicação também estão autorizados a ver todos os resultados da pesquisa. A Pesquisa Cognitiva não tem suporte incorporado para permissões de nível de linha ou de documento, mas pode implementar filtros de segurança como uma solução alternativa.

A autorização baseada em funções para operações de planos de dados sobre conteúdos está agora em visualização pública.

Pode utilizar o portal do Azure num serviço de pesquisa protegido por rede se criar uma exceção de rede que permita o acesso ao cliente e ao portal. Para obter mais informações, consulte a ligação através de uma firewall IP ou conecte-se através de um ponto final privado.

Passos seguintes

Se a sua pergunta não for respondida aqui, pode consultar as seguintes fontes para mais perguntas e respostas.

Stack Overflow: Azure Cognitive Search
Como funciona a pesquisa em texto completo no Azure Cognitive Search
O que é o Azure Cognitive Search?