Pianificare come adattare l'applicazione

Una delle principali modifiche tra le versioni è che Discovery v2 introduce i progetti. Un progetto è costituito da una o più collezioni. Il vantaggio di utilizzare i progetti è che una query può essere eseguita su molte raccolte contemporaneamente. Ogni raccolta può contenere documenti caricati dall'utente o prelevati da una singola fonte di dati, come un sito web, Microsoft SharePoint, e altro ancora.

Elementi da considerare quando si adatta l'applicazione per utilizzare i progetti:

• Sebbene il concetto di un ambiente non esista in v2, i dati sono ancora organizzati in raccolte. In v2, le raccolte sono raggruppate in progetti. Nella maggior parte dei casi, si desidera migrare una singola raccolta v1 in una singola raccolta v2.

  Se vuoi mantenere le informazioni di formazione della pertinenza che vengono applicate a una raccolta v1, aggiungi i documenti della raccolta a una singola raccolta nel tuo progetto v2.

• Decidere il numero di raccolte che si desidera aggiungere a ogni progetto v2. Tutti i tipi di progetto, ad eccezione dei progetti di estrazione contenuto, possono contenere fino a 5 raccolte. Scegli il tipo di progetto giusto per i tuoi dati.

  Per ottimizzare i risultati della ricerca, diversi arricchimenti e opzioni di configurazione vengono applicati automaticamente alle raccolte che vengono aggiunte a diversi tipi di progetto. Per ulteriori informazioni, fare riferimento ai seguenti argomenti:

  • Descrizioni del progetto
  • Impostazioni di progetto predefinite
  • Impostazioni query predefinite

• L'API Discovery v2 è stata modificata per tenere conto di progetti e raccolte, tra gli altri miglioramenti. Alcune chiamate API sono state modificate per supportare azioni a livello di progetto invece che a livello di raccolta, come l'inoltro di una query e l'esecuzione della formazione della pertinenza. Molti altri metodi API sono stati modificati e alcuni non sono disponibili in v2. Per un confronto dettagliato dei metodi API v1 e v2, vedi Confronto delle versioni API.

Selezione di un piano di servizio

Scegli tra i piani gestiti Plus, Enterprisee Premium oppure opta per un'installazione in loco acquistando la cartuccia Discovery per IBM Cloud Pak for Data. Esamina i vantaggi e limiti di ogni tipo di piano prima di sceglierne uno.

• Per ulteriori informazioni sui piani, vedi Piani dei prezzi diDiscovery.
• Per ulteriori informazioni sui limiti delle risorse utente, consultare Dettagli limite.

La seguente tabella mostra i tipi di piano per le distribuzioni gestite che sono generalmente simili tra v1 e v2.

Per ottenere informazioni sull'archivio corrente, sui documenti e le raccolte utilizzati, fare clic sull'icona Dettagli ambiente dall'intestazione interfaccia utente del prodotto.

Non puoi eseguire un aggiornamento sul posto da un piano v1, come Lite o Advanced, a un piano v2. Devi creare un nuovo piano v2 e quindi spostare i dati nella nuova istanza del servizio. Mentre migri i tuoi dati da v1 a v2, probabilmente avrai sia un'istanza v1 che un'istanza v2 distribuite contemporaneamente. Considera di utilizzare la versione di prova gratuita di 30 giorni disponibile con la prima istanza del piano Plus durante questo tempo.

Dati caricati

Se hai utilizzato l'API per caricare documenti in Discovery v1, un'API simile è disponibile in v2 per caricare i documenti nelle raccolte. È necessario aggiornare i flussi di lavoro utilizzati per automatizzare il processo per tenere conto della nuova disposizione di progetti e raccolte.

Se i documenti originali che hai inserito in Discovery v1 non sono più disponibili, puoi utilizzare l'API di query per estrarre il testo del documento da Discovery v1. Puoi quindi aggiungere il testo a una raccolta in Discovery v2. Per ulteriori informazioni, consultare Ripristino dei documenti.

Dati sottoposti a ricerca per indicizzazione

Se è stata eseguita la ricerca per indicizzazione dei dati da un'origine dati esterna in v1, è possibile continuare a eseguire la ricerca per indicizzazione dei dati dalla stessa origine dati esterna in v2. Sono supportate tutte le stesse origini dati.

Per utilizzare i dati da un'origine dati esterna, è necessario ricreare le raccolte all'interno di un progetto v2 e configurare il modo in cui l'origine dati viene sottoposta a ricerca per indicizzazione. Per ulteriori informazioni, consultare Panoramica delle origini dati.

Il servizio richiede tempo e risorse per eseguire la ricerca per indicizzazione e l'inserimento di documenti da origini dati esterne. Ricreare i connettori uno alla volta. Considerare il tempo necessario per eseguire nuovamente la ricerca per indicizzazione dei dati nella pianificazione del piano di migrazione.

Raccolte dati precompilate

Le seguenti raccolte di origini dati integrate non sono disponibili in v2:

Watson Discovery Notizie

Questa origine dati pre - arricchita non è offerta in v2. Per ulteriori informazioni su un modo alternativo per ottenere i dati delle notizie, vedi Utilizzo di un servizio di notizie con v2.

Kit COVID-19

Questa raccolta precompilata è stata progettata per aiutarti ad alimentare un chatbot dinamico creato con IBM® watsonx™ Assistant e Discovery per rispondere alle domande dei tuoi clienti su COVID-19. In v2, puoi creare una soluzione simile. Creare un tipo di progetto Ricerca conversazionale con raccolte che eseguono la ricerca per indicizzazione di siti Web attendibili per le risposte alle domande COVID-19.

Conservazione degli ID documento

Gli ID documento vengono assegnati ai documenti che aggiungi a una raccolta v2 quando li carichi dall'interfaccia utente del prodotto o li aggiungi utilizzando il metodo API Aggiungi un documento.

Potresti voler conservare gli ID dei documenti v1 in v2 se stai utilizzando i processi che dipendono da questi identificativi univoci. Ad esempio, il test di regressione per l'applicazione potrebbe verificare che vengano restituiti documenti specifici controllando gli ID documento. La formazione di rilevanza utilizza gli ID documento per tracciare i documenti tra le esecuzioni di formazione. Questi processi sono più semplici da adattare se gli ID documento sono gli stessi tra le tue istanze v1 e v2. Altrimenti, i processi utilizzati con l'istanza Discovery v1 devono essere riassociati agli ID assegnati ai documenti dopo essere stati aggiunti all'istanza Discovery v2.

Se hai specificato i tuoi propri ID documento quando hai aggiunto i documenti all'istanza del servizio v1, puoi conservare gli ID utilizzando il metodo Aggiorna un documento invece del metodo Aggiungi un documento. Con il metodo di aggiornamento, puoi assegnare un ID documento al documento quando lo aggiungi alla raccolta v2. Per ulteriori informazioni, vedere Aggiornamento di un documento.

Se i tuoi dati sono archiviati in un file JSON, un array nel documento originale genera un ID documento con un numero accodato ad esso. Ad esempio, original_id_n. Per conservare l'ID documento originale senza il suffisso numerico, rimuovere l'array nel file JSON. Modificare [ {"name": "value"} ] in {"name": "value"}, ad esempio.

Se i documenti v1 hanno ID generati dal sistema, è possibile inoltrare una query di ricerca vuota per richiamare un elenco di documenti e dei relativi ID. Puoi quindi assegnare lo stesso ID a ogni documento quando lo aggiungi alla nuova raccolta in v2.

Recupero dei documenti

In alcuni casi, i documenti originali che erano stati inseriti in Discovery V1 non sono più disponibili. Puoi utilizzare l'istanza Discovery v1 per recuperare le informazioni dal documento. Discovery crea una copia di testo di ogni documento che inserisce. La copia è solo testo, quindi tutti i documenti in formato HTML, PDF o altri formati non di testo vengono convertiti in una versione di solo testo.

È possibile recuperare solo i primi 10.000 documenti in una raccolta utilizzando questo metodo. Per ulteriori informazioni su un modo per recuperare più di 10.000 documenti, vedi Ripristino di più di 10.000 documenti da una raccolta.

Per trasferire le informazioni del documento da v1 a v2, completa la seguente procedura:

1. Estrai i documenti da v1 utilizzando l'API per inoltrare una query vuota.

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

   L'API restituisce i risultati. Il campo matching_results specifica il numero totale di risultati. L'oggetto risultati restituisce i documenti corrispondenti. Ogni documento viene restituito come un oggetto JSON separato. Per impostazione predefinita restituisce un massimo di 10 documenti.

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

2. È possibile utilizzare i parametri count e offset per scorrere i risultati dell'interrogazione e salvare tutti i documenti.

   Ad esempio, per ottenere 100 documenti alla volta, puoi impostare count su 100 e offset su 0 e inoltrare la query.

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

   Successivamente, è possibile impostare di nuovo il conteggio su 100, ma questa volta impostare l'offset su 100 per ottenere i successivi 100 documenti.

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

   Ripetere questo processo, incrementando l'offset di 100 fino a quando non si richiamano tutti i documenti.

3. Prepara i documenti esportati da inserire in v2.

   Ogni file JSON risultante che ottieni da Discovery v1 contiene i dati estratti dal documento originale, come testo, html e altri campi. Se i metadati personalizzati sono stati associati al documento quando è stato caricato in v1, sono presenti nel file JSON. Inoltre, il file contiene diversi campi generati dall'analisi v1. Conserva solo un sottoinsieme di questi dati come parte del documento che aggiungi a Discovery v2.

   I seguenti suggerimenti consentono di decidere quali campi conservare:

   • Includi il campo text o qualsiasi altro campo con contenuto testuale che vuoi sia in grado di arricchire o ricercare in Discovery v2.
   • Includere i metadati personalizzati memorizzati nel documento. Questi metatdata sono generalmente specifici per l'applicazione che utilizza Discovery e vengono utilizzati per filtrare i documenti in una ricerca. Ad esempio, metadata.customer_id.
   • Non includere gli arricchimenti da Discovery v1. Ad esempio, enriched_text.entities. Discovery v2 genera i suoi propri arricchimenti.
   • Escludi i campi che vengono generati da Discovery a meno che non vengano utilizzati dalla tua applicazione e non contengano informazioni univoche per la versione v1 del documento. In tal caso, rinomina il campo in modo che non venga sostituito quando il documento viene inserito in Discovery v2. Ad esempio, extracted_metadata.publicationdate è un campo generato da Discovery quando un documento viene inserito. È possibile che si desideri conservare le informazioni metadata.parent_document_id da v1 per comprendere in che modo i documenti secondari sono stati originariamente generati da un singolo documento di origine.
   • Evitare i campi che hanno nomi campo riservati. Per ulteriori informazioni, consultare Modalità di gestione dei campi.

4. Inserisce ogni documento JSON v1 modificato nell'istanza Discovery v2. L'ID documento Discovery v1 può essere conservato in Discovery v2. Per ulteriori informazioni su come conservare l'ID documento, consultare Conservazione degli ID documento.

Recupero di più di 10.000 documenti da una raccolta

Una query può restituire solo fino a 10.000 documenti. Tuttavia, se si desidera recuperare più di 10.000 documenti dalla raccolta, è necessario un modo per separare i documenti in sottogruppi non sovrapposti. Ogni sottogruppo deve contenere meno di 10.000 documenti che possono essere restituiti da una query. Quindi, è possibile impaginare i risultati per richiamare i documenti.

La paginazione per i risultati è limitata al massimo di 10.000 documenti restituiti dalla query. In particolare, l'utilizzo combinato dei parametri di impaginazione count e offset non può superare 10.000 documenti.

Un modo per separare i documenti in sottogruppi non sovrapposti consiste nell'utilizzare un campo che esiste in ogni documento e che contiene un valore univoco. Ad esempio, il campo SHA-1 contiene un hash del file di origine originale ed è formattato come valore stringa esadecimale. È possibile utilizzare il primo carattere del campo come modo per dividere la raccolta in sottogruppi. Poiché SHA-1 contiene un valore esadecimale, il primo carattere può contenere fino a 16 valori possibili (0-9 o a - f). Se si filtra in base a first_char_of (SHA-1) == 0, potrebbe restituire circa 1/16 dell'intera raccolta. È quindi possibile scorrere ciascuno dei 16 valori possibili per ottenere il resto dei documenti. Se non viene restituito un numero ottimale di documenti in uno dei sottogruppi, è possibile utilizzare i primi 2 caratteri del campo SHA-1 per dividere la raccolta in 256 sottogruppi.

Aggiornare il modo in cui l'applicazione gestisce i risultati della query

Il modo in cui l'applicazione mostra i risultati della query potrebbe dover essere aggiornato a causa delle seguenti differenze tra la sintassi del documento dei risultati della query tra le query v1 e v2:

• A livello di arricchimento entità, le seguenti informazioni non sono supportate in v2:

  • Disambiguazione
  • Emozione
  • Parere

  L'arricchimento Part of Speech viene applicato automaticamente ai documenti nella maggior parte dei tipi di progetto in v2, ma i campi di indicizzazione generati dall'arricchimento non vengono visualizzati nella rappresentazione JSON del documento.

  {: caption="

• Invece di count e relevance in v1, v2 include le citazioni.

  Ogni voce nella citazione corrisponde a una ricorrenza dell'entità nel testo del documento. Nel seguente esempio, vengono trovate sette ricorrenze. Per ogni ricorrenza, vengono visualizzati un punteggio di affidabilità e gli offset del testo della citazione. È possibile utilizzare gli offset per evidenziare la citazione nel testo del documento quando il risultato viene visualizzato in un'interfaccia utente.

  

• La struttura JSON delle risposte della query viene leggermente riorganizzata in v2.

• Le informazioni di deduplicazione non sono incluse nella risposta della query v2.

• In v2, enriched_text è un array invece di un oggetto.

• Nell' v2 Discovery, viene utilizzato l'arricchimento v2 delle entità. I nomi dei tipi di entità in v2 sono specificati in maiuscolo / minuscolo, invece di tutte le lettere maiuscole. Se si utilizza una query o un'aggregazione che specifica un nome entità, è necessario modificare le maiuscole / minuscole. Ad esempio, modificare PERSON in Person.

• I campi dei file JSON aggiunti a una raccolta vengono convertiti in modo diverso durante l'inserimento tra v1 e v2. Se l'applicazione manipola questi risultati, potrebbe essere necessario apportare delle modifiche.

  Puoi specificare gli oggetti normalizations e conversions nel metodo Aggiorna una raccolta dell'API per spostare o unire i campi JSON.

  Gestione dei campi di origine JSON

  Contenuto del campo JSON originale	Rappresentazione v1	Rappresentazione v2	Note
  "field": null	"field": null	N/D	v1 conserva il valore null. v2 ignora completamente il campo null.
  "field": ""	"field": ""	N/D	v1 conserva il valore di testo vuoto. v2 ignora completamente il campo di testo vuoto.
  "field": "value2"	"field": "value2"	"field": "value2"	Nessuna differenza.
  "field": []	"field": []	N/D	v1 conserva l'array vuoto. v2 ignora il campo con l'array vuoto.
  "field": [ "value4" ]	"field": [ "value4" ]	"field": "value4"	v1 conserva l'array singleton. v2 converte l'array singleton solo nel valore; non viene memorizzato come parte di un array.
  "field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	"field": [ 1, 2, 3 ]	Nessuna differenza.
  "field": [ "v6", "v7", "v8" ]	"field": [ "v6", "v7", "v8"]	"field": [ "v6", "v7", "v8"]	Nessuna differenza.