Indici di ricerca in Azure AI Search

In Azure AI Search, un indice di ricerca è il contenuto ricercabile, disponibile per il motore di ricerca per l'indicizzazione, la ricerca full-text, la ricerca vettoriale, la ricerca ibrida e le query filtrate. Un indice viene definito da uno schema e salvato nel servizio di ricerca, con l'importazione dei dati seguente come secondo passaggio. Questo contenuto esiste all'interno del servizio di ricerca, oltre agli archivi dati primari, necessari per i tempi di risposta in millisecondi previsti nelle applicazioni di ricerca moderne. Ad eccezione degli scenari di indicizzazione basati sull'indicizzatore, il servizio di ricerca non si connette mai, né esegue query sui dati di origine.

Se si vuole creare e gestire un indice di ricerca, questo articolo consente di comprendere i punti seguenti:

• Contenuto (documenti e schema)
• Struttura dei dati fisici
• Operazioni di base

Si preferisce passare subito alla parte pratica? Vedere Creare un indice di ricerca.

Schema di un indice di ricerca

In Azure AI Search, gli indici contengono documenti di ricerca. A livello concettuale, un documento è un singola unità di dati ricercabili nell'indice. Ad esempio, un rivenditore potrebbe avere un documento per ogni prodotto, un'università potrebbe avere un documento per ogni classe, un sito di viaggio potrebbe avere un documento per ogni hotel e destinazione e così via. Applicando questi concetti ai più familiari elementi di database equivalenti, un indice di ricerca equivale a una tabella e i documenti equivalgono in linea di massima alle righe di una tabella.

La struttura di un documento è determinata dallo schema dell'indice, come illustrato nell'esempio seguente. La raccolta "campi" in genere costituisce la maggior parte di un indice, in cui ogni campo è denominato, assegnato a un tipo di dati e attribuito con comportamenti consentiti che determinano la modalità di utilizzo.

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

Gli altri elementi vengono compressi per brevità, ma i collegamenti seguenti forniscono dettagli:

• gli strumenti suggerimenti supportano query di completamento automatico.
• scoringProfiles vengono usati per l'ottimizzazione della pertinenza.
• gli analizzatori vengono usati per elaborare le stringhe in token in base alle regole linguistiche o ad altre caratteristiche supportate dall'analizzatore.
• corsOptions, o scripting remoto tra origini (CORS), vengono usate per le app che generano richieste da domini diversi.
• encryptionKey configura la doppia crittografia del contenuto sensibile nell'indice.
• semantico configura la riclassificazione semantica nella ricerca full-text e ibrida.
• vectorSearch configura i campi vettoriali e le query.

Definizioni dei campi

Un documento di ricerca viene definito dalla raccolta "campi" nel corpo della richiesta Crea indice. Sono necessari campi per l'identificazione dei documenti (chiavi), l'archiviazione di testo ricercabile e campi per il supporto di filtri, facet e ordinamento. Potrebbero essere necessari anche campi per i dati che un utente non vede mai. Ad esempio, è possibile che si vogliano campi per margini di profitto o promozioni di marketing che è possibile usare in un profilo di punteggio per potenziare il punteggio di ricerca.

Se i dati in ingresso sono gerarchici, è possibile rappresentarli all'interno di un indice come tipo complesso, usato per le strutture nidificate. Il set di dati di esempio predefinito, Hotel, illustra i tipi complessi usando un indirizzo (contiene più sottocampi), che ha una relazione uno-a-uno con ogni hotel, e una raccolta complessa di camere in cui più camere sono associate a ogni hotel.

Attributi campo

Gli attributi del campo determinano le modalità in cui un campo viene usato, ad esempio se viene usato nella ricerca full-text, nella navigazione con facet, nelle operazioni di ordinamento e così via.

I campi della stringa spesso sono contrassegnati come "ricercabile" e "recuperabile". I campi usati per limitare i risultati della ricerca includono "classificabile", "filtrabile" e "con facet".

Sebbene sia possibile aggiungere nuovi campi in qualsiasi momento, le definizioni del campo esistente vengono bloccate per la durata dell'indice. Per questo motivo, gli sviluppatori usano in genere il portale di Azure per creare indici semplici, testare idee o usare le pagine portale di Azure per cercare un'impostazione. L'iterazione frequente su una progettazione degli indici è più efficiente se si segue un approccio basato sul codice in modo che sia possibile ricompilare l'indice con facilità.

Struttura fisica e dimensioni

In Azure AI Search la struttura fisica di un indice è in gran parte un'implementazione interna. È possibile accedere allo schema, eseguire query sul contenuto, monitorarne le dimensioni e gestire la capacità, ma i cluster stessi (indici invertiti, indici vettoriali, partizioni e altri file e cartelle) vengono gestiti internamente da Microsoft.

È possibile monitorare le dimensioni dell'indice nella pagina Indici di gestione > della ricerca nella portale di Azure oppure inviando una richiesta GET INDEX al servizio di ricerca. È anche possibile inviare una richiesta Statistiche del servizio e controllare il valore delle dimensioni di archiviazione.

Le dimensioni di un indice sono determinate da:

• Quantità e composizione dei documenti
• Attributi nei singoli campi
• Configurazione dell'indice (in particolare, se si includono strumenti suggerimenti)

La composizione e la quantità dei documenti sono determinate da ciò che si sceglie di importare. Tenere presente che un indice di ricerca deve contenere solo contenuto ricercabile. Se i dati di origine includono campi binari, omettere tali campi, a meno che non si usi l'arricchimento tramite intelligenza artificiale per violare e analizzare il contenuto per creare informazioni ricercabili nel testo.

Gli attributi dei campi determinano i comportamenti. Per supportare questi comportamenti, il processo di indicizzazione crea le strutture di dati necessarie. Ad esempio, per un campo di tipo Edm.String, "ricercabile" richiama la ricerca full-text, che analizza gli indici invertiti per il termine con token. Al contrario, un attributo "filtrabile" o "ordinabile" supporta l'iterazione su stringhe non modificate. L'esempio nella sezione successiva mostra le variazioni delle dimensioni dell'indice in base agli attributi selezionati.

Gli strumenti suggerimenti sono costrutti che supportano query di completamento automatico. Di conseguenza, quando si include uno strumento suggerimenti, il processo di indicizzazione crea le strutture di dati necessarie per le corrispondenze di caratteri verbatim. Gli strumenti suggerimenti vengono implementati a livello di campo, quindi scegliere solo i campi per i quali il completamento automatico sia accettabile.

Esempio che illustra le ricadute sull'archiviazione di attributi e strumenti suggerimenti

Lo screenshot seguente illustra i modelli di archiviazione dell'indice derivanti da diverse combinazioni di attributi. L'indice si basa sull'indice di esempio immobiliare, che è possibile creare facilmente usando la procedura guidata Importa dati e i dati di esempio predefiniti. Anche se non vengono visualizzati gli schemi dell'indice, è possibile dedurre gli attributi in base al nome dell'indice. Ad esempio, l'indice realestate-searchable ha soltanto l'attributo "ricercabile" selezionato, l'indice realestate-retrievableha soltanto l'attributo "recuperabile" selezionato e così via.

Sebbene queste varianti di indice siano per certi versi artificiali, è possibile farvi riferimento per una considerazione generale sul modo in cui gli attributi influiscono sull'archiviazione:

• "recuperabile" non ha alcun effetto sulle dimensioni dell'indice.
• "filtrabile", "ordinabile" e "con facet" utilizzano più spazio di archiviazione.
• Lo strumento suggerimenti ha un potenziale elevato per aumentare le dimensioni dell'indice, ma non tanto quanto indica lo screenshot (tutti i campi che potrebbero essere noti allo strumento suggerimenti sono stati selezionati, scenario non probabile nella maggior parte degli indici).

Inoltre, nella tabella precedente non è riflesso l'effetto degli analizzatori. Se si usa il tokenizer edgeNgram per archiviare sequenze verbatim di caratteri (a, ab, abc, abcd), l'indice è maggiore rispetto a quando si usa l'analizzatore standard.

Operazioni di base e interazione

Ora che si ha un'idea migliore di ciò che è un indice, questa sezione presenta le operazioni di runtime dell'indice, inclusa la connessione e la protezione di un singolo indice.

Isolamento dell'indice

In Azure AI Search si usa un indice alla volta e tutte le operazioni correlate all'indice hanno come destinazione un singolo indice. Non esiste il concetto di indici correlati, né l'aggiunta di indici indipendenti per l'indicizzazione o l'esecuzione di query.

Disponibilità continua

Un indice è immediatamente disponibile per le query non appena viene indicizzato il primo documento, ma non sarà completamente operativo fino a quando non vengono indicizzati tutti i documenti. Internamente, un indice di ricerca viene distribuito tra le partizioni ed eseguito nelle repliche. L'indice fisico viene gestito internamente. L'indice logico viene gestito dall'utente.

Un indice è disponibile continuamente, senza possibilità di sospenderlo o portarlo offline. Poiché è progettato per l'operazione continua, gli aggiornamenti al relativo contenuto o le aggiunte all'indice stesso vengono eseguiti in tempo reale. Di conseguenza, le query potrebbero restituire temporaneamente risultati incompleti se una richiesta coincide con un aggiornamento del documento.

Si noti che la continuità delle query esiste per le operazioni sui documenti (aggiornamento o eliminazione) e per le modifiche che non influiscono sulla struttura e sull'integrità esistenti dell'indice corrente, ad esempio l'aggiunta di nuovi campi. Se è necessario apportare aggiornamenti strutturali (modificando i campi esistenti), questi vengono in genere gestiti usando un flusso di lavoro drop-and-rebuild in un ambiente di sviluppo o creando una nuova versione dell'indice nel servizio di produzione.

Per evitare una ricompilazione dell'indice, alcuni clienti che apportano piccole modifiche scelgono di "versionare" un campo creandone uno nuovo che coesiste insieme a una versione precedente. Nel corso del tempo, questo comporta contenuti orfani sotto forma di campi obsoleti o definizioni di analizzatori personalizzati obsoleti, in particolare in un indice di produzione costoso da replicare. È possibile risolvere questi problemi sugli aggiornamenti pianificati dell'indice come parte della gestione del ciclo di vita dell'indice.

Connessione e sicurezza degli endpoint

Tutti gli indici e le richieste di query hanno come destinazione un indice. Gli endpoint sono in genere uno dei seguenti:

Come connettersi ad Azure AI Search

1. Iniziare con il portale di Azure. I sottoscrittori di Azure o la persona che ha creato il servizio di ricerca possono gestire il servizio di ricerca nel portale di Azure. Una sottoscrizione di Azure richiede autorizzazioni di Collaboratore o superiori per creare o eliminare servizi. Questo livello di autorizzazione è sufficiente per gestire completamente un servizio di ricerca nel portale di Azure.

2. Provare altri client per l'accesso a livello di codice. Per i primi passaggi, è consigliabile seguire le guide introduttive:

   • Avvio rapido: REST
   • Avvio rapido: SDK di Azure
   • Guida introduttiva: RAG (con Visual Studio Code e un notebook jupyter)

Passaggi successivi

È possibile ottenere un'esperienza pratica nella creazione di un indice usando un esempio o una procedura dettagliata qualsiasi fra quasi tutti quelli disponibili per Azure AI Search. Per iniziare, è possibile scegliere una delle guide introduttive dal sommario.

Tuttavia, è necessario anche acquisire familiarità con le metodologie per il caricamento di un indice con i dati. Le strategie di definizione dell'indice e di importazione dei dati vengono definite in parallelo. Gli articoli seguenti forniscono altre informazioni sulla creazione e sul caricamento di un indice.

• Creare un indice di ricerca
• Crea un archivio vettoriale
• Creare un alias di indice
• Panoramica dell'importazione dei dati
• Caricare un indice