Planifique cómo adaptar la aplicación

Uno de los principales cambios entre versiones es que Discovery v2 introduce proyectos. Un proyecto consta de una o más colecciones. La ventaja de utilizar proyectos es que una consulta se puede ejecutar en muchas colecciones al mismo tiempo. Cada colección puede contener documentos que usted cargue o que rastree desde una única fuente de datos, como un sitio web, Microsoft SharePoint, y más.

Aspectos a tener en cuenta al adaptar la aplicación para utilizar proyectos:

• Aunque el concepto de un entorno no existe en v2, los datos se siguen organizando en recopilaciones. En v2, las colecciones se agrupan en proyectos. En la mayoría de los casos, desea migrar una única colección v1 a una única colección v2.

  Si desea mantener la información de entrenamiento de relevancia que se aplica a una colección v1, añada los documentos de colección a una sola colección en el proyecto v2.

• Decida cuántas colecciones desea añadir a cada proyecto v2. Todos los tipos de proyecto, excepto los proyectos de Content Mining, pueden contener hasta 5 colecciones. Elija el tipo de proyecto adecuado para sus datos.

  Para optimizar los resultados de la búsqueda, se aplican automáticamente diferentes enriquecimientos y opciones de configuración a las colecciones que se añaden a distintos tipos de proyecto. Para más información, consulte los temas siguientes:

  • Descripciones de proyecto
  • Valores de proyecto predeterminados
  • Valores de consulta predeterminados

• La API Discovery v2 ha cambiado para tener en cuenta proyectos y colecciones, entre otras mejoras. Algunas llamadas de API han cambiado para dar soporte a acciones a nivel de proyecto en lugar de a nivel de colección, como por ejemplo el envío de una consulta y la ejecución de un entrenamiento de relevancia. Muchos otros métodos de API han cambiado y algunos no están disponibles en v2. Para obtener una comparación detallada de los métodos de API v1 y v2, consulte Comparación de versiones de API.

Selección de un plan de servicios

Elija entre los planes gestionados Plus, Enterprisey Premium u opte por una instalación local adquiriendo el cartucho Discovery para IBM Cloud Pak for Data. Revise las ventajas y los límites de cada tipo de plan antes de elegir uno.

• Para obtener más información sobre los planes, consulte Planes de precios deDiscovery.
• Para obtener más información sobre los límites de artefacto, consulte Limitar detalles.

La tabla siguiente muestra los tipos de plan para despliegues gestionados que generalmente son similares entre v1 y v2.

Para obtener información sobre el almacenamiento actual, los documentos y las colecciones utilizados, pulse el icono Detalles de entorno en la cabecera de la interfaz de usuario del producto.

No puede realizar una actualización in situ desde un plan v1, como Lite o Advanced, a un plan v2. Debe crear un nuevo plan v2 y, a continuación, mover los datos a la nueva instancia de servicio. Al migrar los datos de v1 a v2, es probable que tenga una instancia de v1 y v2 desplegadas al mismo tiempo. Considere la posibilidad de utilizar la prueba gratuita de 30 días que está disponible con la primera instancia del plan Plus durante este tiempo.

Datos cargados

Si ha utilizado la API para cargar documentos en Discovery v1, hay una API similar disponible en v2 para cargar documentos en colecciones. Debe actualizar los flujos de trabajo que utilice para automatizar el proceso para tener en cuenta la nueva organización de proyectos y colecciones.

Si los documentos originales que ha ingerido en Discovery v1 ya no están disponibles, puede utilizar la API de consulta para extraer el texto del documento de Discovery v1. A continuación, puede añadir el texto a una colección en Discovery v2. Para obtener más información, consulte Recuperación de documentos.

Datos rastreados

Si ha rastreado datos de un origen de datos externo en v1, puede continuar rastreando datos del mismo origen de datos externo en v2. Se da soporte a todos los mismos orígenes de datos.

Para utilizar datos de un origen de datos externo, debe volver a crear las colecciones dentro de un proyecto v2 y configurar cómo se rastrea el origen de datos. Para obtener más información, consulte Visión general de orígenes de datos.

El servicio necesita tiempo y recursos para rastrear e ingerir documentos de orígenes de datos externos. Vuelva a crear los conectores de uno en uno. Factorice el tiempo que tarda en volver a rastrear los datos en la planificación del plan de migración.

Recopilaciones de datos precompiladas

Las siguientes recopilaciones de orígenes de datos incorporadas no están disponibles en v2:

Watson Discovery Noticias

Este origen de datos enriquecido previamente no se ofrece en v2. Para obtener más información sobre una forma alternativa de obtener datos de noticias, consulte Utilización de un servicio de noticias con v2.

Kit de COVID-19

Esta colección precompilada se ha diseñado para ayudarle a impulsar un chatbot dinámico que se crea con IBM® watsonx™ Assistant y Discovery para responder a las preguntas de sus clientes sobre COVID-19. En v2, puede crear una solución similar. Cree un tipo de proyecto Búsqueda conversacional con recopilaciones que rastreen sitios web de confianza para obtener respuestas a las preguntas de COVID-19.

Retención de ID de documento

Los ID de documento se asignan a los documentos que añade a una colección v2 cuando los carga desde la interfaz de usuario del producto o los añade utilizando el método de API Añadir un documento.

Es posible que desee conservar los ID de los documentos v1 en v2 si está utilizando procesos que dependen de estos identificadores exclusivos. Por ejemplo, las pruebas de regresión para la aplicación pueden verificar que se devuelven documentos específicos comprobando los ID de documento. El entrenamiento de relevancia utiliza los ID de documento para realizar un seguimiento de los documentos entre ejecuciones de entrenamiento. Estos procesos son más fáciles de adaptar si los ID de documento son los mismos entre las instancias v1 y v2. De lo contrario, los procesos que se utilizan con la instancia de Discovery v1 se deben volver a correlacionar con los ID asignados a los documentos después de que se añadan a la instancia de Discovery v2.

Si ha especificado sus propios ID de documentos al añadir documentos a la instancia de servicio v1, puede conservar los ID utilizando el método Actualizar un documento en lugar del método Añadir un documento. Con el método de actualización, puede asignar un ID de documento al documento a medida que lo añade a la colección v2. Para obtener más información, consulte Actualizar un documento.

Si los datos se almacenan en un archivo JSON, una matriz del documento original genera un ID de documento con un número añadido. Por ejemplo, original_id_n. Para conservar el ID de documento original sin el sufijo de número, elimine la matriz en el archivo JSON. Cambie [ {"name": "value"} ] por {"name": "value"}, por ejemplo.

Si los documentos v1 tienen ID generados por el sistema, puede enviar una consulta de búsqueda vacía para recuperar una lista de los documentos y sus ID. A continuación, puede asignar el mismo ID a cada documento a medida que lo añade a la nueva colección en v2.

Recuperación de documentos

En algunos casos, los documentos originales que se han ingerido en Discovery V1 ya no están disponibles. Puede utilizar la instancia de Discovery v1 para recuperar información del documento. Discovery crea una copia de texto de cada documento que ingiere. La copia es sólo texto, por lo que los documentos en formato HTML, PDF u otros formatos no de texto se convierten a una versión de sólo texto.

Sólo puede recuperar los primeros 10.000 documentos de una colección utilizando este método. Para obtener más información sobre una forma de recuperar más de 10.000 documentos, consulte Recuperación de más de 10.000 documentos de una colección.

Para transferir información de documento de v1 a v2, realice los pasos siguientes:

1. Extraiga los documentos de v1 utilizando la API para enviar una consulta vacía.

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

   La API devuelve los resultados. El campo matching_results especifica el número total de resultados. El objeto de resultados devuelve los documentos coincidentes. Cada documento se devuelve como un objeto JSON independiente. Devuelve un máximo de 10 documentos de forma predeterminada.

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

2. Puede utilizar los parámetros count y offset para revisar los resultados de la consulta y guardar todos los documentos.

   Por ejemplo, para obtener 100 documentos a la vez, puede establecer count en 100 y offset en 0 y enviar la consulta.

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

   A continuación, puede establecer de nuevo el recuento en 100, pero esta vez establezca el desplazamiento en 100 para obtener los siguientes 100 documentos.

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

   Repita este proceso, incrementando el desplazamiento en 100 hasta que recupere todos los documentos.

3. Prepare los documentos exportados que se van a ingerir en v2.

   Cada archivo JSON resultante que obtiene de Discovery v1 contiene datos que se extraen del documento original, como por ejemplo texto, html y otros campos. Si los metadatos personalizados se asociaron con el documento cuando se cargó en v1, también está presente en el archivo JSON. Además, el archivo contiene varios campos generados por el análisis v1. Conserve sólo un subconjunto de estos datos como parte del documento que añada a Discovery v2.

   Las sugerencias siguientes pueden ayudarle a decidir qué campos mantener:

   • Incluya el campo text o cualquier otro campo con contenido textual que desee que pueda enriquecer o buscar en Discovery v2.
   • Incluya los metadatos personalizados que se almacenan en el documento. Estos metadatos suelen ser específicos de la aplicación que utiliza Discovery y se utilizan para filtrar documentos en una búsqueda. Por ejemplo, metadata.customer_id.
   • No incluya enriquecimientos de Discovery v1. Por ejemplo, enriched_text.entities. Discovery v2 genera sus propios enriquecimientos.
   • Excluya los campos generados por Discovery a menos que los utilice la aplicación y que contengan información que sea exclusiva de la versión v1 del documento. En ese caso, cambie el nombre del campo para que no se sustituya cuando se ingiera el documento en Discovery v2. Por ejemplo, extracted_metadata.publicationdate es un campo generado por Discovery cuando se ingiere un documento. Tal vez desee conservar la información de metadata.parent_document_id de v1 para comprender cómo se generaron originalmente los subdocumentos a partir de un único documento de origen.
   • Evite los campos que tienen nombres de campo reservados. Para obtener más información, consulte Cómo se manejan los campos.

4. Ingiera cada documento JSON v1 editado en la instancia de Discovery v2. El ID de documento Discovery v1 se puede mantener en Discovery v2. Para obtener más información sobre cómo conservar el ID de documento, consulte Retención de ID de documento.

Recuperación de más de 10.000 documentos de una colección

Una consulta sólo puede devolver hasta 10.000 documentos. Sin embargo, si desea recuperar más de 10.000 documentos de la colección, necesita una forma de separar los documentos en subgrupos no solapados. Cada subgrupo debe contener menos de 10.000 documentos que una consulta puede devolver. A continuación, puede paginar a través de los resultados para recuperar los documentos.

La paginación de los resultados está restringida al máximo de 10.000 documentos devueltos por la consulta. En concreto, el uso combinado de los parámetros de paginación count y offset no puede superar los 10.000 documentos.

Una forma de separar los documentos en subgrupos no solapados es aprovechar un campo que existe en cada documento y contiene un valor exclusivo. Por ejemplo, el campo SHA-1 contiene un hash del archivo de origen original y se formatea como un valor de serie hexadecimal. Puede utilizar el primer carácter del campo como una forma de dividir la colección en subgrupos. Puesto que SHA-1 contiene un valor hexadecimal, el primer carácter puede tener hasta 16 valores posibles (0-9 o a-f). Si filtra por first_char_of (SHA-1) == 0, es posible que devuelva aproximadamente 1/16 de toda la colección. A continuación, puede realizar un bucle a través de cada uno de los 16 valores posibles para obtener el resto de los documentos. Si no se devuelve un número óptimo de documentos en uno de los subgrupos, puede utilizar los 2 primeros caracteres del campo SHA-1 para dividir la colección en 256 subgrupos en su lugar.

Actualizar cómo maneja la aplicación los resultados de la consulta

Es posible que sea necesario actualizar la forma en que la aplicación muestra los resultados de la consulta debido a las siguientes diferencias entre la sintaxis del documento de resultados de la consulta entre las consultas v1 y v2:

• En el nivel de enriquecimiento de entidad, la información siguiente no está soportada en v2:

  • Desambiguación
  • Emoción
  • Opinión

  El enriquecimiento Parte de voz se aplica automáticamente a los documentos de la mayoría de los tipos de proyecto en v2, pero los campos de índice generados por el enriquecimiento no se muestran en la representación JSON del documento.

  {: caption="

• En lugar de count y relevance en v1, v2 incluye las menciones.

  Cada entrada de la mención corresponde a una aparición de la entidad en el texto del documento. En el ejemplo siguiente, se encuentran siete apariciones. Para cada aparición, se muestran una puntuación de confianza y los desplazamientos del texto de mención. Puede utilizar los desplazamientos para resaltar la mención en el texto del documento cuando el resultado se visualiza en una interfaz de usuario.

  

• La estructura JSON de las respuestas de consulta se reorganiza ligeramente en v2.

• La información de optimización de almacenamiento no se incluye en la respuesta de consulta v2.

• En v2, enriched_text es una matriz en lugar de un objeto.

• En Discovery v2, se utiliza el enriquecimiento Entidades v2. Los nombres de tipo de entidad en v2 se especifican en mayúsculas, en lugar de en mayúsculas. Si utiliza una consulta o agregación que especifica un nombre de entidad, debe cambiar las mayúsculas y minúsculas. Por ejemplo, cambie PERSON por Person.

• Los campos de los archivos JSON que se añaden a una colección se convierten de forma diferente durante la ingestión entre v1 y v2. Si la aplicación manipula estos resultados, es posible que tenga que realizar ajustes.

  Puede especificar los objetos normalizations y conversions en el método Actualizar una colección de la API para mover o fusionar campos JSON.

  Cómo se manejan los campos de origen JSON

  Contenido de campo JSON original	Representación v1	Representación v2	Notas
  "field": null	"field": null	N/D	v1 conserva el valor nulo. v2 omite el campo nulo por completo.
  "field": ""	"field": ""	N/D	v1 conserva el valor de texto vacío. v2 omite totalmente el campo de texto vacío.
  "field": "value2"	"field": "value2"	"field": "value2"	Sin diferencia.
  "field": []	"field": []	N/D	v1 conserva la matriz vacía. v2 omite el campo con la matriz vacía por completo.
  "field": [ "value4" ]	"field": [ "value4" ]	"field": "value4"	v1 conserva la matriz singleton. v2 convierte la matriz singleton sólo en el valor; no se almacena como parte de una matriz.
  "field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	Sin diferencia.
  "field": [ "v6", "v7", "v8" ]	"field": [ "v6", "v7", "v8"]	"field": [ "v6", "v7", "v8"]	Sin diferencia.