Cercare indici in Ricerca di intelligenza artificiale di Azure
In Ricerca di intelligenza artificiale di Azure 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, a parte gli 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 o 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
Preferisce essere subito pratico? Vedere Creare invece un indice di ricerca.
Schema di un indice di ricerca
In Ricerca di intelligenza artificiale di Azure 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'organizzazione di notizie potrebbe avere un documento per ogni articolo, un sito di viaggio potrebbe avere un documento per ogni hotel e destinazione e così via. Mapping di questi concetti agli equivalenti di database più familiari: un indice di ricerca equivale a una tabella e i documenti sono approssimativamente equivalenti alle righe di una tabella.
La struttura di un documento è determinata dallo schema dell'indice, come illustrato nell'esempio seguente. La raccolta "fields" è in genere la parte più grande di un indice, in cui ogni campo è denominato, ha assegnato 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:
- i suggerimenti supportano query type-ahead, ad esempio il 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), viene usato per le app che generano richieste da domini diversi.
- encryptionKey configura la doppia crittografia del contenuto sensibile nell'indice.
- semantica configura il reranking semantico nella ricerca full-text e ibrida.
- vectorSearch configura i campi vettoriali e le query.
Definizioni dei campi
Un documento di ricerca viene definito dall'insieme "fields" nel corpo della richiesta Create Index. Sono necessari campi per l'identificazione dei documenti (chiavi), l'archiviazione di testo ricercabile e i 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 aumentare il punteggio di ricerca.
Se i dati in ingresso sono gerarchici, è possibile rappresentarli all'interno di un indice come tipo complesso, usati per le strutture nidificate. Il set di dati di esempio predefinito, Hotels, illustra i tipi complessi che usano un indirizzo (contiene più sottocampi) che hanno una relazione uno-a-uno con ogni hotel e una raccolta complessa Rooms, in cui più camere sono associate a ogni hotel.
Attributi campo
Gli attributi di campo determinano la modalità di utilizzo di un campo, ad esempio se viene usato nella ricerca full-text, nella navigazione in base a facet, nelle operazioni di ordinamento e così via.
I campi stringa vengono spesso contrassegnati come "ricercabili" e "recuperabili". I campi usati per restringere i risultati della ricerca includono "ordinabile", "filtrabile" e "facetable".
| Attributo | Descrizione |
|---|---|
| "ricercabile" | Ricercabile full-text o vettoriale. I campi di testo sono soggetti all'analisi lessicale, ad esempio l'interruzione delle parole durante l'indicizzazione. Se si imposta un campo ricercabile su un valore come "sunny day", internamente viene suddiviso nei singoli token "sunny" e "day". Per informazioni vedere Funzionamento della ricerca full-text. |
| "filtrabile" | A cui si fa riferimento nelle query $filter. I campi filtrabili di tipo Edm.String o Collection(Edm.String) non vengono sottoposti a word breaking, quindi i confronti sono solo per corrispondenze esatte. Ad esempio, se si imposta tale campo f su "sunny day", $filter=f eq 'sunny' non trova corrispondenze, ma $filter=f eq 'sunny day' lo farà. |
| "ordinabile" | Per impostazione predefinita il sistema ordina i risultati in base al punteggio, ma è possibile configurare l'ordine in base ai campi nei documenti. I campi di tipo Collection(Edm.String) non possono essere "ordinabili". |
| "facetable" | In genere usato in una presentazione dei risultati della ricerca che include un numero di passaggi per categoria, ad esempio, gli hotel in una specifica città. Questa opzione non può essere usata con i campi di tipo Edm.GeographyPoint. I campi di tipo Edm.String filtrabili, ordinabili o "facetable" possono essere al massimo di 32 kilobyte. Per altri dettagli, vedere Create Index (REST API)(Creare un indice: API REST). |
| "chiave" | Identificatore univoco per i documenti all'interno dell'indice. È necessario scegliere un singolo campo come campo chiave e questo deve essere di tipo Edm.String. |
| "recuperabile" | Specifica se il campo può essere restituito nel risultato di una ricerca. Ciò è utile quando si vuole usare un campo (ad esempio il margine di profitto) come filtro, ordinamento o meccanismo di assegnazione dei punteggi, ma non si vuole che il campo sia visibile all'utente finale. L'attributo deve essere true for key . |
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 in genere usano il portale per la creazione di indici semplici, idee di test o usano le pagine del portale 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à.
Nota
Le API usate per compilare un indice hanno comportamenti predefiniti diversi. Per le API REST, la maggior parte degli attributi è abilitata per impostazione predefinita(ad esempio, "ricercabile" e "recuperabile" per i campi stringa) e spesso è necessario impostarli solo se si desidera disattivarli. Per .NET SDK, l'opposto è vero. In qualsiasi proprietà non impostata in modo esplicito, l'impostazione predefinita consiste nel disabilitare il comportamento di ricerca corrispondente, a meno che non venga abilitato in modo specifico.
Struttura fisica e dimensioni
In Ricerca di intelligenza artificiale di Azure la struttura fisica di un indice è in gran parte un'implementazione interna. È possibile accedere al relativo schema, eseguire query sul relativo contenuto, monitorarne le dimensioni e gestire la capacità, ma i cluster stessi (indici, partizioni e altri file e cartelle) vengono gestiti internamente da Microsoft.
È possibile monitorare le dimensioni dell'indice nella scheda Indici del 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 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 creare 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.
I suggerimenti sono costrutti che supportano query di completamento automatico o di tipo type-ahead. Di conseguenza, quando si include un suggerimento, il processo di indicizzazione crea le strutture di dati necessarie per le corrispondenze di caratteri verbatim. I suggerimenti vengono implementati a livello di campo, quindi scegliere solo i campi che sono ragionevoli per il tipo-ahead.
Esempio che illustra le implicazioni di archiviazione di attributi e 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 gli schemi di indice non vengono visualizzati, è possibile dedurre gli attributi in base al nome dell'indice. Ad esempio, l'indice realestate-searchable ha l'attributo "ricercabile" selezionato e nient'altro, l'indice recuperabile realestate ha l'attributo "recuperabile " selezionato e nient'altro e così via.
Sebbene queste varianti di indice siano in qualche modo artificiali, è possibile farvi riferimento per confronti generali sul modo in cui gli attributi influiscono sull'archiviazione:
- "recuperabile" non ha alcun effetto sulle dimensioni dell'indice.
- "filtrabile", "ordinabile", "facetable" utilizzano più spazio di archiviazione.
- il suggerimento ha un potenziale elevato per aumentare le dimensioni dell'indice, ma non tanto quanto lo screenshot indica (tutti i campi che potrebbero essere resi consapevoli del suggerimento sono stati selezionati, che non è uno scenario probabile nella maggior parte degli indici).
Inoltre, non riflessa nella tabella precedente è l'effetto degli analizzatori. Se si usa il tokenizer edgeNgram per archiviare sequenze verbatim di caratteri (a, ab, abc, abcd), l'indice è maggiore di se 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.
Nota
Quando si gestisce un indice, tenere presente che non è disponibile alcun portale o supporto API per lo spostamento o la copia di un indice. I clienti in genere puntano la soluzione di distribuzione dell'applicazione in un servizio di ricerca diverso (se si usa lo stesso nome di indice) o modificano il nome per creare una copia nel servizio di ricerca corrente e quindi compilarla.
Isolamento dell'indice
In Ricerca di intelligenza artificiale di Azure si usa un indice alla volta, in cui tutte le operazioni correlate all'indice hanno come destinazione un singolo indice. Non esiste alcun concetto di indici correlati o di join 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 sospendere o portare offline. Poiché è progettato per l'operazione continua, gli aggiornamenti al relativo contenuto o 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 "versione" 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
Tutte le richieste di indicizzazione e query sono destinate a un indice. Gli endpoint sono in genere uno dei seguenti:
| Endpoint | Connessione e controllo di accesso |
|---|---|
<your-service>.search.windows.net/indexes |
È destinata all'insieme degli indici. Utilizzato durante la creazione, l'elenco o l'eliminazione di un indice. Amministrazione diritti sono necessari per queste operazioni, disponibili tramite l'amministratore Chiavi API o ruolo Collaboratore ricerca. |
<your-service>.search.windows.net/indexes/<your-index>/docs |
È destinata all'insieme documents di un singolo indice. Utilizzato durante l'esecuzione di query su un indice o un aggiornamento dati. Per le query, i diritti di lettura sono sufficienti e disponibili tramite chiavi API di query o un ruolo lettore dati. Per l'aggiornamento dei dati, sono necessari i diritti di amministratore. |
Come connettersi a Ricerca intelligenza artificiale di Azure
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 versione successiva per creare o eliminare servizi. Questo livello di autorizzazione è sufficiente per gestire completamente un servizio di ricerca nel portale di Azure.
Provare altri client per l'accesso a livello di codice. Per i primi passaggi, è consigliabile seguire le guide introduttive:
Passaggi successivi
È possibile ottenere un'esperienza pratica nella creazione di un indice usando quasi qualsiasi esempio o procedura dettagliata per Ricerca di intelligenza artificiale di Azure. Per iniziare, è possibile scegliere una delle guide introduttive dal sommario.
Ma è anche necessario 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 il caricamento di un indice.