Quali sono le novità in termini di risoluzione entità in MindMeld?

Introduzione

La risoluzione entità ER (Entity Resolution) è il processo di disambiguazione di un’entità. Viene realizzata associando un riferimento di testo al nome del mondo reale più appropriato in una knowledge base (KW) di ricerca. Ad esempio, risolvendo ‘madrid fc‘ in ‘Real Madrid Club de Fútbol‘, dove la prima è una delle parafrasi della seconda. Spesso si fa riferimento alla risoluzione entità anche con altri nomi, come corrispondenza entità, collegamento entità, collegamento record o deduplicazione record. La risoluzione entità è disponibile come parte della Pipeline NLP di MindMeld e viene utilizzata per eliminare l’ambiguità da eventuali entità identificate nell’input dell’utente, eseguendo l’associazione in base a una knowledge base (KB) precompilata. Controlla la documentazione ufficiale per scoprire come creare una KB per la risoluzione entità e utilizzarla durante la creazione di un’app MindMeld. Fino a poco tempo fa, MindMeld offriva due opzioni di risoluzione entità: una basata sul motore di ricerca e analisi di testo completo Elasticsearch e l’altra basata su un semplice algoritmo di corrispondenza esatta come opzione di fallback. Con l’aumentare della diversità nelle applicazioni di MindMeld, queste opzioni potrebbero non essere sempre utilizzabili. Per offrire supporto esteso, MindMeld ora fornisce due opzioni aggiuntive per la risoluzione entità: una basata su TF-IDF e l’altra basata sulle rappresentazioni di modello neurale precedentemente sottoposto a training (BERT, GloVe, fastText, eccetera). In particolare, queste nuove opzioni non presentano alcuna dipendenza da Elasticsearch (e dai relativi servizi). Prima di esaminare più nel dettaglio queste nuove opzioni, riassumiamo rapidamente come è strutturata una knowledge base di entità in MindMeld. Di seguito un esempio di progetto di ordinazione di prodotti alimentari con la knowledge base creata per la disambiguazione dei nomi di prodotti alimentari:   Come osservato, il campo ‘cname’ (nome canonico) insieme al campo ‘whitelist’ esemplificano alcuni usi comuni per ogni prodotto alimentare insieme al campo ‘id’ che si riferisce a un record univoco, ufficialmente riconosciuto nella knowledge base. Questi tre campi principalmente costituiscono un oggetto entità nella KB. Il testo nel campo ‘cname’ viene solitamente utilizzato in risposte conversazionali e quello nel campo ‘whitelist’, insieme al nome canonico, serve da alias durante il processo di disambiguazione. Spesso, i risultati migliori si ottengono da un resolver entità quando il campo ‘whitelist’ è compilato completamente (ossia, comprende usi alternativi, errori di ortografia, forme abbreviate, eccetera). Questo tipo di lavoro può diventare un processo noioso in alcune applicazioni, ma è inevitabile quando si tratta di entità in un dominio altamente specializzato.

Ulteriori informazioni sugli ultimi resolver

In resolver diversi dalla corrispondenza esatta, il primo passo è ottenere una rappresentazione di vettori per il testo di input per cui occorre la disambiguazione e per tutte le voci della KB (cname e whitelist) che fungono da alias per la disambiguazione. Quindi, utilizzando una qualche forma di corrispondenza di similarità di vettori (similarità di coseno), vengono assegnati un punteggio e una classificazione agli alias. Nelle scelte di risoluzione entità aggiunte di recente, il resolver basato su TF-IDF gestisce una vasta gamma di funzionalità n-gram (ossia, funzioni di testo a livello di superficie) prima di calcolare la similarità di coseno sui vettori sparsi. D’altra parte, un resolver basato su embedder precedentemente sottoposto a training esegue le associazioni utilizzando la similarità di coseno su rappresentazioni di vettori dense di testo. Sfruttare embedder precedentemente sottoposti a training per la risoluzione entità offre alcuni vantaggi rispetto ad altri approcci. Ad esempio, offrono comprensione semantica di testo senza dover compilare approfonditamente le whitelist (ossia, ‘prestazioni sotto aspettative’ è equivalente a ‘prestazioni scadenti’) e forniscono una transizione facile alla corrispondenza di entità multilingue (ossia, si deduce che ‘tercio’ in spagnolo è uguale a ‘terzo’ in italiano). Tuttavia, le discrepanze tra precedentemente sottoposto a training e inferenza, come differenze di lunghezza di testi di input, penalizzano gli embedder precedentemente sottoposti a training. Inoltre, i tempi di inferenza dei modelli di embedder possono essere maggiori rispetto a quelli delle altre due opzioni di resolver, a causa dei calcoli di vettori densi sottostanti. Tuttavia, quando perfezionati in modo appropriato, i modelli di embedder possono superare altre opzioni di resolver basate principalmente su funzioni di testo a livello superficiale. Nell’analisi seguente, i resolver basati su embedder precedentemente sottoposti a training vengono confrontati con Elasticsearch e resolver di entità TF-IDF. I set di dati gestiti per questo confronto coinvolgono sia la corrispondenza di testo a livello superficiale che la corrispondenza semantica.

Prestazioni di resolver diversi

Dopo aver eseguito diversi esperimenti con vari set di dati gestiti internamente, sono state calcolate le seguenti prestazioni in media di resolver di entità diversi per corrispondenza di entità di testo breve. Punteggio Top-1 riportato come misura di precisione di seguito:   Le varianti BERT precedentemente sottoposte a training sono disponibili nei trasformatori di frase Hugging Face e il grafico presenta i punteggi solo delle prime 5 varianti più performanti. Modelli di incorporamento parole precedentemente sottoposti a training, come fastText, generalmente hanno prestazioni più scarse dei modelli di embedder BERT o resolver basati su TF-IDF. Tali prestazioni scadenti possono essere attribuite al cambio di dominio o alla mancanza di perfezionamento. Un’ulteriore analisi che utilizza diverse configurazioni della variante BERT più performante (‘distilbert-base-nli-stsb-mean-tokens’) restituisce i seguenti risultati:   I risultati dimostrano che punteggi di similarità alternativi come BERTScore non sono competitivi. Inoltre, l’uso della similarità di coseno durante la concatenazione di layer diversi del modello BERT porta un miglioramento delle prestazioni corrispondenti alle prestazioni di Elasticsearch. Ciò è intuibile perché layer diversi di BERT possono acquisire informazioni complementari. Anche dopo aver quantizzato la variante BERT per un minore impatto sulla memoria e meno complessità di tempo, le prestazioni peggiorano solo del 2-3%. Inoltre, quando valutato su dati casuali contenenti errori di ortografia nell’input, il resolver basato su TF-IDF mostra prestazioni superiori ad altri. Ciò può essere dovuto al diverso set di n-gram acquisito da questo resolver. Per questo esperimento, i testi whitelist vengono riutilizzati come istanze di test e vengono indotti in questi testi errori di ortografia. Di conseguenza, con 0% di parole non significative, si osserva una precisione del 100% poiché tutte le entità di test sono presenti anche nelle whitelist.   Infine, il seguente grafico illustra le differenze di complessità di tempo di inferenza tra i diversi resolver :   (Da sinistra a destra: BERT più accurato, TF-IDF, Elasticsearch) Tempo di inferenza per entità quando misurato tra knowledge base di diverse dimensioni. L’asse X mostra la dimensione della knowledge base, mentre l’asse Y mostra il tempo per entità in millisecondi. Giallo è il tempo di inferenza per codificare il testo di input e verde è il tempo di inferenza per il calcolo di similarità. Le complessità di tempo di TF-IDF e Elasticsearch sono abbastanza comparabili, mentre la migliore variante BERT, sebbene quantizzata, è 20 volte più lenta. Questa migliora fino a 10 volte più lenta se si concatenano i 4 primi layer, ma con una conseguente perdita di precisione.

Selezione e configurazione di un resolver entità

Le configurazioni di resolver entità MindMeld prendono in considerazione una vasta gamma di parametri configurabili in base al resolver in uso. Il seguente frammento, quando fornito in ‘config.py’ di un’app utilizza un modello BERT precedentemente sottoposto a training scelto da Hugging Face: ENTITY_RESOLVER_CONFIG = {     ‘model_type’: ‘resolver’,     ‘model_settings’: {         ‘resolver_type’: ‘sbert_cosine_similarity’,         ‘pretrained_name_or_abspath’: ‘distilbert-base-nli-stsb-mean-tokens’,         …     } } Puoi utilizzare altri modelli di embedder modificando il parametro ‘embedder_type’: ENTITY_RESOLVER_CONFIG = {     ‘model_type’: ‘resolver’,     ‘model_settings’: {         ‘resolver_type’: ‘embedder_cosine_similarity’,         ‘embedder_type’: ‘glove’,        …     } } Puoi anche specificare config run-time come ‘batch_size’ quando utilizzi un modello di embedder, insieme a configurazioni specifiche del modello di embedder. Per caricare un resolver basato su TF-IDF, puoi effettuare quanto segue: ENTITY_RESOLVER_CONFIG = {     ‘model_type’: ‘resolver’,     ‘model_settings’: {         ‘resolver_type’: ‘tfidf_cosine_similarity’,         …     } } Per ogni oggetto entità nella KB, incorporamenti speciali, che sono il pool medio/max di tutti gli incorporamenti di alias, vengono anche calcolati e utilizzati per la risoluzione se configurati. Tali incorporamenti speciali spesso migliorano la precisione dei resolver con solo un aumento marginale dei costi computazionali. Per dettagli completi e tutte le scelte configurabili, vedi la sezione ‘Configurazioni’ nella documentazione ufficiale.

Conclusioni e lavoro futuro

In generale, il resolver basato su Elasticsearch è consigliato a meno che uno scenario speciale necessiti di non utilizzarlo. Come riserva, usa resolver basati su modelli di embedder quando esiste un requisito di maggiore corrispondenza semantica o un resolver basato su TF-IDF se non esiste questo requisito. Il modulo ER in MindMeld non fornisce ancora API per confrontare i resolver e identificare quello che funziona meglio per la tua applicazione. Rimani sintonizzato mentre pianifichiamo le attività necessarie per aggiungere tale supporto insieme ai modi per perfezionare resolver basati su modelli di embedder.   Iscriviti a Webex Visita la nostra home page o contattaci direttamente per assistenza. Fai clic qui per ulteriori informazioni sulle offerte di Webex e per eseguire l’iscrizione a un account gratuito