Planete como adaptar sua aplicação

Uma das principais mudanças entre as versões é que Discovery v2 introduz projetos. Um projeto consiste em uma ou mais coleções. A vantagem de usar projetos é que uma consulta pode correr contra muitas coleções ao mesmo tempo. Cada coleção pode conter documentos que você carrega ou que rastreia a partir de uma única fonte de dados, como um site, o Microsoft SharePoint, e outros.

Coisas a considerar quando você adapta seu aplicativo para usar projetos:

• Embora o conceito de um ambiente não exista em v2, os dados ainda são organizados em coleções. Em v2, as coleções são agrupadas em projetos. Na maioria dos casos, você deseja migrar uma única coleção v1 para uma única coleção v2.

  Se você deseja manter informações de treinamento de relevância que são aplicadas a uma coleção v1, inclua os documentos de coleta em uma única coleção em seu projeto v2.

• Decida quantas coleções você deseja adicionar a cada projeto v2. Todos os tipos de projeto, exceto projetos de Mineração de Conteúdo, podem conter até 5 coleções. Escolha o tipo certo de projeto para os seus dados.

  Para otimizar resultados de pesquisa, diferentes enriquecimentos e opções de configuração são aplicados automaticamente em coleções que são adicionadas a diferentes tipos de projeto. Para obter mais informações, consulte os tópicos a seguir:

  • descrições do projeto
  • Configurações do projeto padrão
  • Configurações de consulta padrão

• A API Discovery v2 mudou para dar conta de projetos e coleções, entre outros aprimoramentos. Algumas chamadas de API alteradas para suportar ações no nível do projeto em vez do nível de coleta, como enviar uma consulta e executar treinamento de relevância. Muitos outros métodos de API mudaram e alguns não estão disponíveis em v2. Para uma comparação detalhada dos métodos de API v1 e v2, consulte comparação de versão da API.

Como escolher um plano de serviço

Escolha entre os planos gerenciados Plus, Enterprisee Premium ou opte por uma instalação no local ao comprar o Discovery Cartucho para IBM Cloud Pak for Data. Revise os benefícios e os limites de cada tipo de plano antes de escolher um.

• Para obter mais informações sobre os planos, consulte Discovery planos de precificação.
• Para obter mais informações sobre limites de artefatos, consulte Limit details.

A tabela a seguir mostra tipos de plano para implementações gerenciadas que geralmente são semelhantes entre v1 e v2.

Para obter informações sobre o armazenamento atual, documentos e coleções usadas, clique no ícone Detalhes do ambiente a partir do cabeçalho da interface do usuário do produto.

Não é possível fazer um upgrade in-place a partir de um plano v1, como Lite ou Advanced, para um plano v2. Você deve criar um novo plano v2 e, em seguida, mover seus dados para a nova instância de serviço. Enquanto você migra seus dados de v1 para v2, você provavelmente terá ambos uma instância v1 e v2 implementada ao mesmo tempo. Considere usar a avaliação sem encargos de 30 dias que está disponível com sua primeira instância do plano Plus durante esse tempo

Dados transferidos por upload

Se você usou a API para fazer upload de documentos em Discovery v1, uma API similar está disponível em v2 para fazer upload de documentos em coleções. Deve-se atualizar quaisquer fluxos de trabalho usados para automatizar o processo para considerar a nova organização de projetos e coleções.

Se os documentos originais que você ingeriu em Discovery v1 não estiverem mais disponíveis, você poderá usar a API de consulta para extrair o texto do documento a partir de Discovery v1. Você pode então adicionar o texto em uma coleção em Discovery v2. Para obter mais informações, consulte Recuperar documentos.

Dados do crawled

Se você rastejou dados de uma fonte de dados externa em v1, você pode continuar engatinhar dados da mesma fonte de dados externos em v2. Todas as mesmas fontes de dados são suportadas.

Para usar dados de uma fonte de dados externa, você deve recriar as coleções dentro de um projeto v2, e configurar como a fonte de dados está engatinada. Para obter mais informações, consulte Visão Geral de fontes de dados.

O serviço precisa de tempo e recursos para engatinhar e ingerir documentos a partir de fontes de dados externas. Recriar os conectores um de cada vez. Fatore o tempo que leva para refazer o crawl dos dados em seu plano de migração.

Coleções de dados pré-construídos

As coleções de fonte de dados embutidas a seguir não estão disponíveis em v2:

Watson Discovery Notícias

Esta fonte de dados pré-enriquecida não é oferecida em v2. Para obter mais informações sobre uma maneira alternativa de obter dados de notícias, consulte Usando um serviço de notícias com v2.

COVID-19 kit

Esta coleção pré-construída foi projetada para ajudá-lo a alimentar um chatbot dinâmico que é construído com IBM® watsonx™ Assistant e Discovery para responder às perguntas dos seus clientes sobre COVID-19. Em v2, é possível construir uma solução semelhante. Crie um tipo de projeto Busca Conversacional com coleções que engatinam websites confiáveis para respostas a perguntas do COVID-19.

Retendo IDs de documentos

IDs de documentos são atribuídos aos documentos que você adicionar a uma coleção v2 quando você faz o upload deles a partir da interface do usuário do produto ou adicioná-los usando o método de API Adicionar um documento.

Você pode desejar reter os IDs de seus documentos v1 em v2 se você estiver usando processos que dependem desses identificadores únicos. Por exemplo, o teste de regressão para o aplicativo pode verificar se documentos específicos são retornados verificando os IDs do documento. O treinamento de relevância utiliza os IDs de documentos para rastrear documentos entre execuções de treinamento. Esses processos são mais fáceis de se adaptar se os IDs de documentos forem os mesmos entre suas instâncias v1 e v2. Caso contrário, os processos que são usados com a instância Discovery v1 devem ser remapeados para os IDs que são atribuídos aos documentos após serem adicionados à instância Discovery v2.

Se você especificou seus próprios IDs de documentos quando adicionou documentos para a instância de serviço v1, você pode reter os IDs usando o método Update um documento em vez do método Adicionar um documento. Com o método de atualização, é possível atribuir um ID de documento ao documento ao adicioná-lo à coleção v2. Para obter mais informações, consulte Atualizar um documento.

Se os seus dados são armazenados em um arquivo JSON, uma matriz no documento original gera um ID de documento com um número anexado a ele. Por exemplo, original_id_n. Para reter o ID do documento original sem o sufixo de número, remova a matriz no arquivo JSON. Alterar [ {"name": "value"} ] para {"name": "value"}, por exemplo.

Se os seus documentos v1 tiverem IDs gerados pelo sistema, você pode enviar uma consulta de pesquisa vazia vazia para recuperar uma lista dos documentos e seus IDs. Em seguida, é possível atribuir o mesmo ID a cada documento ao adicioná-lo à sua nova coleção em v2.

Recuperação de documentos

Em alguns casos, os documentos originais que foram ingeridos em Discovery V1 não estão mais disponíveis. Você pode usar a instância Discovery v1 para recuperar informações do documento. Discovery cria uma cópia de texto de cada documento que ele ingere. A cópia é texto apenas, portanto, quaisquer documentos em HTML, PDF ou outros formatos não texto são convertidos em uma versão textual.

Você pode recuperar apenas os primeiros 10.000 documentos em uma coleção usando este método. Para obter mais informações sobre uma maneira de recuperar mais de 10.000 documentos, consulte Recuperando mais de 10.000 documentos de uma coleta.

Para transferir informações de documentos do v1 para v2, complete as seguintes etapas:

1. Extraia os documentos do v1 usando a API para enviar uma consulta vazia.

   Por exemplo, GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=.

   A API retorna os resultados.. O campo matching_results especifica o número total de resultados.. O objeto de resultados retorna os documentos correspondentes. Cada documento é retornado como um objeto JSON separado. Ele retorna um máximo de 10 documentos por padrão.

   {
     "matching_results": 34,
     "session_token": "nnn",
     "results": [
       {"{result objects}":"{maximum of 10 by default}"}
     ]
   }
   

2. Você pode usar os parâmetros count e offset para página através dos resultados da consulta e salvar todos os documentos.

   Por exemplo, para obter 100 documentos por vez, você pode configurar o count para 100 e offset para 0 e enviar a consulta.

   GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=&count=100&offset=0
   

   Em seguida, você pode novamente definir a contagem para 100, mas desta vez definiu o deslocamento para 100 minutos para obter os próximos 100 documentos.

   GET {url}/v1/environments/{environment_id}/collections/{collection_id}/query?q=&count=100&offset=100`
   

   Repita esse processo, incrementando o deslocamento em 100 até recuperar todos os documentos.

3. Prepare os documentos exportados para serem ingeridos em v2.

   Cada arquivo JSON resultante que você obtiver de Discovery v1 contém dados que são extraídos do documento original, como texto, html e outros campos. Se metadados personalizados foram associados ao documento quando ele foi carregado para v1, ele também está presente no arquivo JSON. Além disso, o arquivo contém vários campos que foram gerados pela análise v1. Retenha apenas um subconjunto desses dados como parte do documento que você adicionar em Discovery v2.

   As dicas a seguir podem ajudá-lo a decidir quais campos manter:

   • Inclua o campo text ou qualquer outro campo com conteúdo textual que você deseja que possa enriquecer ou procurar no Discovery v2.
   • Inclua qualquer metadado personalizado que esteja armazenado no documento. Esses metatdata geralmente são específicos para o aplicativo que usa Discovery e são usados para filtrar documentos em uma procura. Por exemplo, metadata.customer_id.
   • Não inclua enriquecimentos a partir de Discovery v1. Por exemplo, enriched_text.entities. Discovery v2 gera seus próprios enriquecimentos.
   • Excluir campos que são gerados pelo Discovery, a menos que eles sejam usados por seu aplicativo e contenham informações que sejam exclusivas para a versão v1 do documento. Nesse caso, renomear o campo para que ele não seja substituído quando o documento for ingerido em Discovery v2. Por exemplo, extracted_metadata.publicationdate é um campo que é gerado por Discovery quando um documento é ingerido. Talvez você queira reter as informações metadata.parent_document_id do v1 para entender como os subdocumentos foram originalmente gerados a partir de um único documento de origem.
   • Evite campos que tenham nomes de campo reservados. Para obter mais informações, consulte Como os campos são tratados.

4. Ingest cada um documento editado v1 JSON na instância Discovery v2. O ID do documento Discovery v1 pode ser mantido em Discovery v2. Para obter mais informações sobre como reter o ID do documento, consulte IDs de documentos de retenção.

Recuperando mais de 10.000 documentos de uma coleção

Uma consulta só pode retornar até 10.000 documentos No entanto, se você desejar recuperar mais de 10.000 documentos de sua coleta, precisará de uma maneira de separar os documentos em subgrupos sem sobreposição. Cada subgrupo deve conter menos de 10.000 documentos que podem ser retornados por uma consulta.. Em seguida, é possível paginar os resultados para recuperar os documentos.

A paginação para os resultados é restrita ao máximo de 10.000 documentos retornados pela consulta. Especificamente, o uso combinado dos parâmetros de paginação count e offset não pode exceder 10.000 documentos..

Uma maneira de separar os documentos em subgrupos não sobrepostos é utilizar um campo que existe em cada documento e contém um valor exclusivo. Por exemplo, o campo SHA-1 contém um hash do arquivo de origem original e é formatado como um valor de sequência hexadecimal. É possível usar o primeiro caractere do campo como uma maneira de dividir a coleta em subgrupos Como SHA-1 contém um valor hexadecimal, o primeiro caractere pode ter até 16 valores possíveis (0-9 ou a-f). Se você filtrar pelo first_char_of (SHA-1) == 0, poderá retornar aproximadamente 1/16 da coleção inteira. Em seguida, é possível efetuar loop em cada um dos 16 valores possíveis para obter o restante dos documentos. Se o número ideal de documentos não for retornado em um dos subgrupos, será possível usar os primeiros 2 caracteres no campo SHA-1 para dividir a coleta em 256 subgrupos.

Atualize como seu aplicativo manipula resultados de consulta

A forma como o seu aplicativo mostra resultados de consulta pode precisar ser atualizado devido às seguintes diferenças entre a sintaxe de documento de resultados da consulta entre as consultas v1 e v2:

• No nível de enriquecimento da entidade, as informações a seguir não são suportadas em v2:

  • Desambiguação
  • Emoção
  • Impressão

  O enriquecimento Parte do Discurso é aplicado automaticamente em documentos na maioria dos tipos de projeto em v2, mas os campos de índice que são gerados pelo enriquecimento não são exibidos na representação JSON do documento.

  

  na estrutura de dados de entidades*

• Em vez do count e relevance em v1, v2 inclui as menções.

  Cada entrada na menção corresponde a uma ocorrência da entidade no texto do documento. No exemplo a seguir, sete ocorrências são encontradas. Para cada ocorrência, são exibidas uma pontuação de confiança e os deslocamentos do texto de menção. Você pode utilizar os deslocamentos para destacar a menção no texto do documento quando o resultado for exibido em uma interface com o usuário.

  

• A estrutura JSON das respostas de consulta é rearranjada ligeiramente em v2.

• As informações de deduplicação não estão incluídas na resposta de consulta v2.

• Em v2, enriched_text é uma matriz em vez de um objeto.

• Em Discovery v2, as Entidades v2 de enriquecimento são usadas. Nomes de tipos de entidade em v2 são especificados em headline case, em vez de todas as letras maiúsculas. Se você usar uma consulta ou agregação que especifica um nome de entidade, você deve alterar a capitalização. Por exemplo, altere PERSON para Person.

• Os campos de arquivos JSON que são adicionados a uma coleção são convertidos de forma diferente durante a ingestão entre v1 e v2. Se o seu aplicativo manipula esses resultados, você pode precisar fazer ajustes.

  É possível especificar os objetos normalizations e conversions no método Atualizar uma coleção da API para mover ou mesclar campos JSON.

  Como os campos de origem JSON são tratados

  Conteúdo do campo JSON original	v1 representação	v2 representação	Notas
  "field": null	"field": null	N/D	v1 mantém o valor nulo. v2 esquiava totalmente o campo nulo.
  "field": ""	"field": ""	N/D	v1 mantém o valor do texto vazio. v2 pula o campo de texto vazio por completo.
  "field": "value2"	"field": "value2"	"field": "value2"	Nenhuma diferença.
  "field": []	"field": []	N/D	v1 mantém a matriz vazia. v2 esquiava o campo com a matriz vazia por completo.
  "field": [ "value4" ]	"field": [ "value4" ]	"field": "value4"	v1 mantém a matriz singleton. v2 converte a matriz singleton no valor apenas; ela não é armazenada como parte de uma matriz.
  "field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	Nenhuma diferença.
  "field": [ "v6", "v7", "v8" ]	"field": [ "v6", "v7", "v8"]	"field": [ "v6", "v7", "v8"]	Nenhuma diferença.