Contributo open-source ai pacchetti NLP

Un progetto open source può essere definito come un codice sorgente reso disponibile al pubblico per la visualizzazione, l'utilizzo, la modifica e la distribuzione con una licenza permissiva. Importanti progetti open source sono il risultato del contributo di persone con non solo capacità di programmazione, ma anche documentazione, pulizia del codice e altre abilità.

Qualsiasi correzione di errori di battitura, aggiunta di un avviso su un possibile avviso del compilatore, correzione di un bug o persino aggiunta di documentazione dettagliata a un progetto, può essere considerata un contributo open source.

Com'è lo scenario Open Source nella PNL?

Sono disponibili più guide sui contributi open source (OSC) e su come iniziare con la tua prima richiesta pull. Data la grande quantità di dati testuali disponibili su Internet, l'elaborazione del linguaggio naturale è fiorita ampiamente negli ultimi anni. Diversi pacchetti soddisfano le esigenze di vari flussi di lavoro basati sulla PNL. TensorFlow , ad esempio, ha Keras-NLP come modulo di flusso di lavoro olistico NLP. Pytorch e TorchText insieme formano TorchNLP per tutta la messa a punto basata su trasformatore utilizzando PyTorch.

Dato che ho un avido interesse per l'elaborazione del linguaggio naturale e la linguistica computazionale, volevo che il mio primo contributo open source fosse sullo stesso argomento. Nel dicembre 2022, sono stato accettato nella seconda coorte del Kaggle BIPOC Mentorship Program e ho iniziato a lavorare sul pacchetto NLP-Profiler di Mani Sarkar per apportare miglioramenti e aggiungere funzionalità. Vorrei ringraziarlo per il suo costante supporto, incoraggiamento e tutoraggio durante tutto il programma.

Cos'è il Profiler PNL?

NLP Profiler è un programma/libreria che profila i dati di testo, estrae i dati specifici della PNL innati nei corpora e produce dettagli statistici sui dati di testo. Possiamo pensarlo come pandas.describe()ma su dati di testo. Produce un dataframe describe() su cui è possibile eseguire la funzione per ottenere statistiche descrittive.

Possiamo installare NLP-Profiler usando pip/pip3 sui notebook Kaggle e Colab. Per lavorarci localmente, può essere compilato dal sorgente . Iniziamo da:

Una volta che abbiamo il pacchetto nel nostro ambiente, possiamo usarlo per ottenere approfondimenti sui dati testuali. Supponendo di avere un dataframe con dati testuali nella colonna 'text', possiamo sviluppare il dataframe riepilogativo, nel modo seguente:

Il "profiled_text_dataframe" è dotato di varie funzionalità come il conteggio delle frasi, il conteggio dei caratteri, la soggettività del sentimento, il punteggio di qualità dell'ortografia, il controllo della facilità di lettura, ecc .

Questo dataframe può ora essere utilizzato per scopi statistici e matematici per sviluppare pipeline linguistiche computazionali. Quindi, il pacchetto beneficia del riepilogo dei dati di testo, matematicamente.

Come ho contribuito al pacchetto?

Contribuire a qualsiasi pacchetto richiede un'analisi meticolosa delle varie dipendenze e funzionalità. L'NLP-Profiler dipende da più linguaggi e pacchetti di analisi semantica che sono volatili ma anche molto comunemente usati. Questi includono TextBlob , Spacy , ecc. L'allentamento della dipendenza da tali pacchetti non solo riduce il tempo di risposta del pacchetto, ma ne aumenta anche la stabilità. Inoltre, se non fissiamo le dipendenze, finiamo per riscontrare risultati o comportamenti imprevisti che portano a errori CI. Man mano che i pacchetti continuano a evolversi e nel repository dei pacchetti si verificano più contributi, mantenere un registro delle modifiche e testare il flusso end-to-end del pacchetto ogni volta che viene apportata una modifica è piuttosto una necessità.

Ho iniziato leggendo la documentazione e come è implementata nei notebook Jupyter (Colab/Kaggle). Il pacchetto inizialmente soffriva di conflitti di dipendenza con gli ambienti Colab e Kaggle. Questo è stato facilmente risolto modificando la sequenza in cui i pacchetti sono stati pip installati nei notebook e disinstallando il pacchetto "digitazione" prima di installare lo stesso.

Uno sguardo dettagliato ai problemi aperti e alle richieste pull consente di avere una migliore comprensione delle aree del pacchetto che richiedono riparazioni o sono aperte a contributi. Puoi scegliere uno dei numeri aperti o cercare sezioni nel pacchetto che richiedono miglioramenti e iniziare a collaborare con gli sviluppatori.

Ho esaminato i problemi e le diverse funzionalità e ho trovato alcuni margini di miglioramento. La funzione di controllo grammaticale , testata su set di dati testuali di grandi dimensioni, ha impiegato molto tempo a rispondere. Dipendeva dal pacchetto language-tool-python che non considerava la punteggiatura e aveva un tempo di risposta elevato. Ho sostituito il pacchetto con Gingerit : uno strumento di correzione grammaticale basato sul contesto di frasi complete. Durante il test sui notebook Jupyter, il tempo di risposta del profiler, complessivamente, è stato ridotto di 8 secondi .

Inoltre, anche il calcolo della funzione di controllo ortografico ha impiegato molto tempo per rispondere, anche per set di dati di piccole dimensioni. Era basato sulla formula:

La formula può essere sostituita con algoritmi fuzzy per adattarsi a tutti i tipi di calcoli di penalità per errori di ortografia. Ad esempio, "I ma bda persno" produce un punteggio ortografico dell'85 % con la formula. Tuttavia, con algoritmi fuzzy, produce un punteggio del 73% , che è in migliore parità con la percezione umana. Inoltre, il requisito dell'utilizzo di TextBlob per la tokenizzazione può anche essere allentato utilizzando il pacchetto SymSpell , che afferma di essere molto più veloce di qualsiasi altro correttore ortografico disponibile.

Queste modifiche, prima di essere incorporate, devono essere documentate nelle pull request, effettuate per ciascuna di esse. Alcune linee guida devono essere seguite obbligatoriamente per chiunque crei una richiesta pull. Queste linee guida aiutano a mantenere la stabilità del ramo principale del repository e informano il collaboratore dei possibili conflitti che potrebbero derivare dalle modifiche apportate.

Il test sulla macchina locale, prima di creare una richiesta pull, è molto necessario. Il repository ha alcuni test " lenti " e " fumosi " che devono essere eseguiti sul repository modificato, dalla tua parte, prima di effettuare una richiesta pull.

Inoltre, il repository dispone del plug-in Sourcery AI , che controlla le modifiche apportate e fornisce un rapporto dettagliato se le modifiche si aggiungono alla qualità del repository e, in caso contrario, dove sono necessari miglioramenti. GitHub Action esegue diversi altri controlli come CodeQL , End-to-End flow e pre-commit . Questi garantiscono l'unione senza conflitti delle richieste pull.

Cosa fare e cosa non fare

Ci sono alcune linee guida da rispettare. Questi sono interamente basati sulla mia esperienza, finora.

1. Leggi i file markdown che contengono i dettagli dei contributi e delle modifiche apportate finora. Questi sono necessari per avere un'idea preliminare del flusso di lavoro.
2. Consenti alle azioni Github sul tuo repository fork di eseguire azioni del flusso di lavoro end-to-end per ogni ramo, per garantire che la build sia stabile.
3. Il test in un ambiente locale con diversi casi di test è obbligatorio per garantire che le modifiche funzionino come previsto.
4. Per un collaboratore dilettante come me, è essenziale essere scrupolosi con il pacchetto prima di apportare modifiche sostanziali.
5. La risoluzione delle dipendenze o la creazione dell'ambiente locale per i test può essere impegnativa. Si può passare all'alternativa Github1s , che consente un editor online VSCode per repository.

Ambito futuro

Il file del correttore ortografico necessita di ulteriori correzioni a causa del fallimento di alcuni test di accettazione e prestazioni. Questo deve essere risolto e, quindi, è menzionato nelle questioni aperte del repository. Alcune funzioni granulari come ' Repeated_letters_count ', ' Repeated_digits_count' , ' Repeated_spaces_count ', ' Repeated_whitespaces_count ', ' Repeated_punctuations_count ', ' english_characters_count ' e ' non_english_characters_count ' devono essere corrette in quanto tendono a non essere prodotte quando viene richiamato il profiler.

Data l'esperienza che acquisisco lavorando su questo pacchetto, aspiro a contribuire a Keras-NLP in modi simili e aggiungere al mondo della linguistica, nel mio modo umile.

Riferimenti

1. Problemi aperti di PNL-Profiler
2. Creare un ambiente locale
3. Taccuino Kaggle PNL-Profiler
4. Test di compilazione in Github
5. Pull-Request su cui ho lavorato: 1. Correttore ortografico 2. Correttore grammaticale
6. Ulteriori lavorazioni: 1. Bug da correggere 2. Rendere compatibile il pacchetto python3.9
7. Ulteriori aggiornamenti sul pacchetto.
8. Sostenitori del pacchetto .
9. Guida al contributo.
10. Pacchetti aggiuntivi a cui contribuire .
11. Editor di frammenti di codice