Blog

Moje prywatne publiczne notatki.

Eksperymenty NLP w PLGrid

Wstęp

W ramach prac magisterskich, a także inżynierskich związanych z przetwarzaniem języka naturalnego (NLP), studenci często potrzebują dostępu do komputerów wyposażonych w kart GPU. Jedną z możliwości jest uruchomienie tych eksperymentów w środowiskach chmurowych, np. Google Colab lub Amazon Sagemaker. Niemniej wykorzystanie tych narzędzi, w szczególności darmowej wersji Colab-a, wiąże się z szeregiem ograniczeń.

• Prometheus: 32 karty V100,
• Ares: 72 karty V100,
• Athena (jeszcze niedostępna): 384 karty A100.

PLGrid

Rejestracja

Wykorzystanie tych komputerów wymaga jednak uzyskania dostępu oraz właściwej konfiguracji środowiska uruchomieniowego. Proces rozpoczynamy od rejestracji swojego konta w PLGrid . W ramach procesu rejestracyjnego musimy wskazać swojego opiekuna naukowego, który umożliwi nam dostęp do infrastruktury PLGrid. Po rejestracji oczekujemy na potwierdzenie, że opiekun zaakceptował nasze zgłoszenie.

Dostęp do wybranego superkomputera

Następnym krokiem w procedurze jest uzyskanie dostęp do wybranego superkomputera. Krok ten wymaga, abyśmy mieli dostęp do grantu na obliczenia na tym superkomputerze. Występowanie o grant zazwyczaj odbywa się za pośrednictwem opiekuna. Zwykle opiekunowie mają już granty, do których mogą dołączyć kolejne osoby.

O dostęp do wybranego superkomputera aplikujemy w zakładce “usługi”: szukamy w niej nazwy np. Dostęp do klastra Ares w ośrodku Cyfronet:

Dodanie dostępu nie odbywa się jednak w tym miejscu – konieczne jest kliknięcie zielonego guzika “Zarządzaj usługami”. Jego kliknięcie powoduje przejście do innej aplikacji powiązanej z systemem PLGrid.

Uwaga: w systemie zarządzania usługami występuje błąd, związany z niepoprawnym działaniem usługi OpenID. W przypadku jego występowania (komunikat “Błąd serwera”) należy skontaktować się ze wsparciem po stronie PLGrid (odnośnik Helpdesk w menu górnym na głównej stronie portalu).

Praca na serwerze

Maszyny dostępowe i obliczeniowe

Po uzyskaniu dostępu do wybranego serwera (Prometheus, Ares, Athena), można się na niego zalogować za pomocą SSH, np. do serwera Ares można się połączyć wpisując:

$ ssh <mojlogin>@ares.cyfronet.pl

Oczywiście <mojlogin> zamieniamy na nasz login w systemie PLGrid.

Po zalogowaniu się na serwer musimy uświadomić sobie, że jesteśmy zalogowanie na maszynie dostępowej. Będzie się to objawiało następującym komunikatem w linii poleceń

$ <mojlogin>@login01:~/

Czyli maszyna, na której się znajdujemy nazywa się np. login01.

Uwaga: na maszynach dostępowych nigdy nie uruchamiamy żadnych zadań, angażujących zasoby obliczeniowe! Dotyczy to również zadań typu instalowanie bibliotek Pythona, czy kompilacja kodu. Tego rodzaju działania należy wykonywać wyłącznie na węzłach obliczeniowych.

Zabezpieczenie sesji pracy

Czynności wykonywane na maszynie dostępowej oraz na węzłach obliczeniowych warto zabezpieczyć przed przypadkowym zerwaniem dostępu do internetu. W tym celu można wykorzystać narzędzie screen lub tmux

Tutaj przedstawimy tylko najważniejsze polecenia tmux-a:

• tmux – uruchomienie sesji tmux-a. Wylogowanie, bądź zerwanie połączenia internetowego nie przerywa sesji tmux-a,
• tmux a – połączenie się do wcześniej utworzonej sesji tmux-a.

• ctrl+b d – opuszczenie sesji tmux-a, bez jej kończenia (umożliwia rozłączenie się z serwerem),
• ctrl+b c – utworzenie nowej zakładki/ekranu,
• ctrl+b n/p – przełączenie się do następnej/poprzedniej zakładki.

Ten zbiór poleceń stanowi pewne minimum, które pozwala na efektywną pracę ze zdalną sesją obliczeniową. W internecie można znaleźć szereg dalszych informacji, które pozwalają na wykonywanie bardziej zaawansowanych czynności (np. przeglądanie wyników wcześniej wykonanych poleceń).

Uruchamianie zadań

Zadania na superkomputerze są uruchamiane z wykorzystaniem systemu kolejkowego. Najważniejsze polecenia to:

• srun – praca na węźle w trybie interaktywnym
• sbatch – praca na wężle w trybie batchowym

Zazwyczaj na etapie prototypowania lepiej pracować w trybie interaktywnym. Mamy wtedy możliwość pracy tak, jakbyśmy robili to na zwykłym komputerze wyposażonym w Linuksa, z tą różnicą, że mamy dostęp do karty GPU i bardzo dużych zasobów dyskowych.

Jeśli jednak potrzebujemy uruchomić wiele eksperymentów, a wiemy już że nasze skrypty działają poprawie, możemy wykorzystać w tym celu drugie polecenie.

Przykładowe uruchomienie sesji wygląda następująco:

$ srun -A plgnlp-gpu -p plgrid-gpu-v100 --gres=gpu:1 -N 1 -n 1 --ntasks-per-node=1 --mem=32GB -t 24:00:00 --pty /bin/bash -l

gdzie:

• -A – nazwa grantu, określana przez opiekuna,
• -p – nazwa kolejki, dostęp do kart V100 na Aresie wymaga podania kolejki jw.,
• --gres=gpu:1 – zarezerwowanie dostępu do specjalnych zasobów, w tym wypadku jednej karty GPU,
• -N – liczba węzłów, na których uruchamiane jest zadanie,
• -n – liczba rdzeni (dla całego zadania), które zostaną udostępnione,
• --ntasks-per-node – liczba rdzeni na pojedynczym węźle (w zasadzie może być pominięte),
• --mem – ilość pamięci RAM dla każdego węzła obliczeniowego,
• -t – maksymalny czas uruchomienia zadania (24h są maksymalną wartością dla tej kolejki),
• --pty – powłoka, która zostanie uruchomiona po połączeniu się z węzłem.

Uruchomienie polecenia nie zawsze powoduje natychmiastowe uzyskanie dostępu do węzła. Jeśli czekamy długo, możemy spróbować zmniejszyć jeden lub wiele parametrów. Zwykle uruchamianie na jednym węźle, z jedną kartą GPU jest jednak dość szybko realizowane. Jeśli jednak czekamy długo, możemy wpisać:

$ squeue

Spowoduje ono wyświetlenie wszystkich uruchomionych zadań w ramach grantów, do których mamy dostęp.

Zasoby dyskowe

Superkomputery wyposażone są w klastry dyskowe o bardzo dużej pojemności (liczonej w petabajtach). Dlatego realizując eksperymenty nie musimy za bardzo przejmować się tą kwestią. Trzeba jednak wiedzieć, że przetrzeń dyskowa w naszym katalogu domowym jest niewielka – np. 10GB.

Dane eksperymentalne muszą być przechowywane na SCRATCHu, czyli dysku wyposażonym w szybkie połączenia z węzłami. W ramach grantu obliczeniowego mamy na nim limit 1000GB. W teorii SCRATCH jest czyszczony co 30 dni, ale realnie zdaża się to bardzo rzadko. Dlatego spokojnie możemy przechowywać na nim dane.

Katalog SCRATCH dostępny jest w zmiennej $SCRATCH, ale warto zrobić sobie dowiązanie symboliczne do tego katalogu, w swoim katalogu domowym. Istotnie upraszcza to pracę. Kod źródłowy (jako najcennieszy zasób), warto jednak trzymać w katalogu domowym oraz w repozytorium, np. Gicie. Żeby ułatwić sobie dostęp do scratcha z poziomu katalogu z kodem, możemy zrobić sobie również dowiązanie symboliczne z katalogu np. output do odpowiadającego mu katalogu na SCRATCHu.

Uruchamianie modułów

Standardowo po uzyskaniu dostępu do węzła obliczeniowego mamy dostęp do niewielkiej liczby modułów softwareowych, takich jak kompilator czy interpreter języka. Dlatego zazwyczaj, w celu uzyskania powtarzalności eksperymentów, ładujemy programistyczne “moduły”, które dają nam dostęp do narzędzi w ściśle określonych wersjach.

Dla eksperymentów NLP na Aresie polecane jest załadowanie dwóch modułów:

$ module load python/3.8.6-gcccore-10.2.0
$ module load cuda/11.6.0

Poza tym warto zrobić sobie środowisko virtualenv, aby móc instalować własne biblioteki pythonowe. Pamiętemy zatem żeby po każdym zalogowaniu na węzeł aktywować to środowisko, np.:

$ source ~/scratch/python-3.8.6/bin/activate

Po wprowadzeniu tych poleceń możemy już uruchamiać swoje programy napisane w Pythonie, z dokładnie określonym zestawem bibliotek.

Powodzenia!

Classification of legal rights

The PhD thesis Engineering Law-Compliant Requirements: the Nomos Framework by Alberto Siena contains a very interesting classification of the legal rights. In my previous post, reviewing the article describing the application of SRL methods to the extraction of definitions and norms from laws, I have briefly mentioned that there are four types of norms: obligation, right, permission and power. Yet the description was not very elaborate. So I consulted the source of this classification, which is the PhD of Alberto Siena. I haven’t read the full thesis yet, but it is a very interesting and very clear description of a proposed formalism used to model the legal rights.

• claim – duty,
• privilege – noclaim,
• power – liability,
• immunity – disablity.

Each pair of rights describes the same deontic situation from the perspective of opposite actors bound by the right. If A has a claim against B, then B has a duty against A. So it is not necessary to describe them separately.

Claim – duty

This is the case of two actors, when one (B) has an obligation (duty) to do something for (A). So A has a claim against B – meaning that he expects, and the law supports that expectation, that B would fulfil the claim. E.g. A is a patient and B is a doctor. According to the Polish law, the doctor has to inform the patient about the outcomes of the medical examination of his body. So the doctor has a duty to inform, while the patient has a claim to be informed. The support given by law is usually carried out by sanction, by not fulfilling the claim. Yet these sanctions are not part of the relationship.

Privilege – noclaim

This is the opposite of the previous relation, in the sense, that the noclaim party of the relationship is not supported by law, to fulfil an expectation from that party. But in general there might be no such expectation from the party. The relationship is more concerned with the privilege party – it has a right (in the normal sense) to do something, but the counterparty can not force the party to do so. E.g. if A is a land owner and B is some local authority, responsible for the territory, the land is a part of, if the local law allows that, A can build a house on his/her piece of land. Yet, the local authority cannot force the owner to do so. Thus, the owner has a privilege and the authority has noclaim against the owner.

As we see in that example, the noclaim party is less connected with the privileged party, than in the previous relationship, since there might be many subjects who might be interested in A using theirs privilege (or not using, which is covered by the same relationship): neighbors, family, etc. In most of the cases it is useless to name these subjects as the noclaim party to a particular privilege, so this seems to be a degraded element of the relationship.

Power – liability

This relationship is a reflection of the claim – duty relationship, but it has a different action associated with it. In the previous case, the action was concerned with its own outcome (e.g. patient being informed), in that case the action is concerned with its legal outcome. So the power allows A to change the legal situation of B, while B has a liability against A, who can change their legal situation. E.g. if A is a jury and B is a suspect, the jury may judge, that the suspect is guilty. This action will change the legal position of the suspect, making them a convicted person.

Immunity – disability

In that case, the relationship is a reflection of the noclaim – privilege relationship, but applied to the legal outcomes of actions. It is impossible for the disabled party to change the legal situation of the immune subject. E.g. if A is a prosecutor and B is a judge, in normal circumstances A cannot prosecute B. If B were not a judge, the prosecutor would have the power to do that. Once again, we see that this relationship is the opposite of the previous one.

Summary

This classification of the legal rights seems very clear to me. The symmetry of the relationships provides simple structure to the rights.

Review of "Populating legal ontologies using semantic role labeling"

The article entitled Populating legal ontologies using semantic role labeling published on LREC 2020 and later in JAIL discusses the application of Semantic Role Labeling approach for extracting structured (or semi-structured) information form provisions, EU directives in particular.

The article starts with the brief discussion of different approaches to ontology population and describes the SRL formalism. Then there are the following system described: European Legal Taxonomy Syllabus, Eunomos and Legal-URN.

The first system, ELTS, is a lightweight ontology used to compare and align legal terminology in several European countries. The system concentrated only on the concepts (i.e. rules were not concerned).

The second system (Eunomos) has two extensions. The first extension is concerned with linking the legislation with the contents of the ontology, by keeping links to the provisions, by structuring the provisions in XML format and by maintaining the cross-references. The second extension is concerned with the inclusion of rules in the ontology.

The third system (Legal-URN) has yet a different goal. It is based on business process modeling and extends the notation with deontic elements. It is devised as an extension to be applied in companies for providing legislation-based compliance for business process. This extension is based on Hohfeldian model of legal norms.

Then the article jumps to the description of the methodology applied for the extraction of definitions and norms from the EU legislation. The approach is based on a two or three-step procedure (depending on the type of extraction: 2 for definitions, 3 for norms): the text is normalized and it is parsed to the SRL formalism, the elements of the parsed sentence are mapped to a legal structure (e.g. Head -> means (VBS) is used to detect the elements of a definition) and mapped to the final representation (in the case of norms). The paper discusses in detail only the first and the second step. There are no examples of rules for converting the second representation to the final one.

• regular definitions (e.g. x means y),
• include/exclude definitions (e.g. x including y and z),
• ostensive definitions (by example, e.g. x such as y),
• referential definitions (e.g. x defined in article y).

• obligation (e.g. x has to do y),
• right (e.g. x shall be entitled to y),
• permission (e.g. x is permitted to do y),
• power (e.g. x may require y).

The distinction between the different types of norms is not part of the article. The examples in that section justify my statement that the extracted data is semi-structured. The example concerned with a certificate, allows the system extracts it as an active role in the rule. This is strange, since I would expect a certificate to be extracted as the active role, the pronoun refers to. This is a serious limitation of the approach.

• legal effect (e.g. an event x leads to an event y “automatically”),
• scope (e.g. x can do y if/despite x is z),
• exception (e.g. x can do y if z or x can do y, x cannot do y if z),
• hierarchy of norms (e.g. rules concerning x are subject to regulations in y),
• rationale (e.g. the purpose of x is y).

The article is concluded with the evaluation of the approach. What is important: the number of converted (annotated) rules is pretty small. There are 224 sentences taken from Directive 95/46/EC and 267 sentences (the number is not reported directly in the article) from the Directive 98/5/EC. The first directive was used to create the norms, so the results are overly optimistic. Yet, it shows the limitation of the method, since it is impeded by the performance of the SRL parser. Depending on the type of argument, the results (lenient F1) range between 34 and 100%. Yet there are only three types of arguments with support > 10. Obligation has 76%, Power has 85% (77% for strict evaluation) and Legal effect has 34%.

The second directive (“the test set”) has much lower figures. Yet it is not described how the evaluation was performed – whether the directive was annotated first and the results were checked against the gold standard or the results were evaluated afterwards (in which case the results are invalid). Nevertheless, the values are in the range 0-100% (there’s no aggregate result). The support is not reported, so it is impossible to filter the type of the argument by support. The macro-average lenient F1 is 53.3%.

Personal opinion: the article is important, since it identifies the different types of definitions and norms that appear in the legislation. The approach is lightweight, in the sense that the norms are not re-structured into fully formal representation, the arguments might be long pieces of text, which has to be further interpreted. Yet, as a result, sometimes the results are meaningless, like in the case of the pronoun, being the argument of a rule. The performance of the system is low, that it cannot be utilized in an automatic procedure. Even for manual curation, it would produce numerous false positives and false negatives. The system does not try to combine the outputs of the extraction in more meaningful representation, i.e. a concept that is extracted is not used as bias or restriction for an argument in the rules. For me, it is not known how the results should be further utilized in search, QA or legal modeling. I think that methods base on question answering based on DNNs would be able to achieve better results (that’s quite obvious), but they would be able to be applied without much annotation, since a general purpose QA dataset would be enough to achieve similar or even better results.

Schemat opisu eksperymentów ML

Prowadząc badania naukowe w dziedzinie NLP, czy ML, pojawia się problem, polegający na tym, że po jakimś czasie nie do końca wiemy, jak dokładnie przeprowadziliśmy dany eksperyment. Karol Lasocki, który obecnie pracuje dla Amazonu, wspomniał o fiszce, wykorzystywanej do dokumentowania eksperymentów. Ten pomysł bardzo mi się spodobał. Poniżej prezentuję schemat fiszki, który wypracowałem w ramach eksperymentów prowadzonych między innymi w konkursie PolEval.

Kod eksperymentu

Np. qa-1 – kod eksperymentu to również nazwa katalogu z danymi eksperymentu. Dzięki temu można bardzo łatwo zidentyfikować, gdzie znajdują się wyniki eksperymentu, jego dane oraz użyty model.

Cel eksperymentu

Po co przeprowadzamy ten eksperyment. Najlepiej, żeby eksperyment dotyczył jednej hipotezy, którą chcemy zweryfikować.

Wnioski z eksperymentu

Krótkie (2-3 zdania) podsumowanie eksperymentu. Powinno odpowiadać, na pytanie postawione w hipotezie eksperymentu.

Użyty model

Jaka była architektura sieci neuronowej. Jeśli używamy modeli pretrenowanych, to jaki dokładnie był to model – optymalnie, żeby był to identyfikator z repozytorium Huggingface Models.

Użyte dane wejściowe

Jakie dane wejściowe zostały wykorzystane do treningu, a jakie do testowania. Jeśli są to dane ogólnie dostępne, to oczywiście identyfikator z HF. Jeśli są to dane autorskie, to dobrze, żeby było odniesienie do ich lokalizacji lub jednoznaczny identyfikator.

Użyte parametry

W dobrych skryptach MLowych parametry wypisywane są na początku eksperymentu. Warto wykorzystać te dane i je tutaj zamieścić.

Kod źródłowy

Wskazanie repozytorium, z którego korzystamy w eksperymencie. Opcjonalne może to być link do konkretnego commita.

Skrypt treningu

Jest to jedna z najważniejszych pozycji w schemacie. Zamieszczenie dokładnego wywołania skryptu trenującego umożliwia łatwe powtórzenie eksperymentu. Ma to szczególne znaczenie w przypadku skryptów, które posiadają szereg parametrów. Pomaga też ustalić np. że zbiór danych treningowych, który był wykorzystywany w danym eksperymencie, jest identyczny jak zbiór danych w innym eksperymencie.

Skrypt predykcji

Skrypt wykorzystany do wykonania predykcji na danych testowych. Analogicznie jak skrypt powyżej, pozwala ustalić wszystkie istotne parametry wykorzystane do predykcji.

Wyniki eksperymentu

Szczegółowa tabelka z wynikami eksperymentu, dla poszczególnych checkpointów. Najlepiej raportować tutaj wyniki ze zbioru ewaluacyjnego oraz ewentualnie ze zbioru testowego.

Model wynikowy

Lokalizacja modelu wynikowego, jeśli miałby się znajdować gdzieś indziej, niż w katalogu dedykowanym dla eksperymentu.

Napotkane problemy

Jakie problemy pojawiły się przy treningu modelu. Jak je rozwiązano.

Uzupełnienie braków wniosku o rejestrację spółki w eKRS

Jeśli sąd wezwie Cię do uzupełnienia braków przy rejestracji spółki przez portal eKRS, to uzupełnia się je na innej stronie, konkretnie prs-ekrs.

Skrypt dla Jupytera na Prometeuszu

Ten wpis dotyczy konfiguracji Jupytera tak, żeby działał na Prometeuszu. Przy okazji środowisko jest tak skonfigurowane, że można używać GPU.

Jako alternatywę polecam użycie biblioteki idact

Ważne jest aby przed instalacją virutalneva załadować odpowiedni moduł Python, np.

unset PYTHONPATH
module load plgrid/tools/python/3.6.5

Następnie instalujemy virtualenva na Prometeuszu. Najprościej zrobić to zgodnie z instrukcją z dokumentacji Virtualnevna

Zakładamy, że virtualenv jest w katalogu ~/python3_6. Aktywujemy go wywołaniem:

source ~/python3_6/bin/activate

Instalujemy wszystkie potrzebne nam biblioteki, w szczególności Jupytera:

pip install jupyter-notebook

Generujemy również klucz, który pozwoli nam na logowanie się na Prometeusza z Prometeusza, bez podawania hasła.

Następnie tworzymy plik o nazwie jupyter.sh o następującej treści

unset PYTHONPATH
module load plgrid/apps/cuda/9.0
module load plgrid/libs/lapack/3.8.0
module load plgrid/libs/hdf5/1.10.1
module load plgrid/libs/openblas/0.2.19
module load plgrid/libs/atlas/3.10.3
module load plgrid/tools/gcc/8.1.0
module load plgrid/tools/python/3.6.5
module load plgrid/tools/java8/1.8.0_60
export XDG_RUNTIME_DIR=~/xdg
export PORT=${1:-9000}
echo $PORT
source ~/python3_6/bin/activate
~/python3_6/bin/jupyter-notebook --no-browser --port=${PORT} notebooks &
sleep 10
ssh -N -R ${PORT}:localhost:${PORT} login01

Po uzyskaniu dostępu do węzła obliczeniowego plik ten pozwoli nam na pracę na Jupyterze na komputerze lokalnym, pod warunkiem, że zalogujemy się przekierowując port 9000

ssh pro -L 9000:localhost:9000

Usuwanie autora z PDFa

Na podstawie:

https://askubuntu.com/questions/27381/how-to-edit-pdf-metadata-from-command-line

1. Instalujemy exiftools:

$ sudo apt-get install exiftool

2. Wywołujemy komendę:

$ exiftool -Author="" plik.pdf

Szczególnie przydatne dla wszystkich osób, które prowadzą proces redakcyjny, z założeniem, że dane autora nie powinny przedostać się do recenzentów (blind review).

Instalacja IRuby

Aby zainstalować IRubiego oraz Ruby on Rails w najnowszych wersjach należy wykonać następujące polecenia (testowane na Ubuntu w wersji serwerowej 16.10):

$ sudo apt-get install zlib1g-dev libssl-dev libxml2-dev libsqlite3-dev libev-dev
$ sudo apt-get install ruby curl git-core libyaml-dev libgcrypt11-dev libgmp-dev
$ sudo apt-get install libgdbm-dev libncurses5-dev automake libtool bison libffi-dev libreadline6-dev
$ sudo apt-get install python3-dev libzmq3-dev python-dev python-pip
$ sudo pip install 'ipython[notebook]' markupsafe zmq certifi jsonschema  jupyter_console
$ curl https://rvm.io/mpapis.asc | gpg --import -
$ curl -L get.rvm.io | bash -s stable
$ source ~/.rvm/scripts/rvm
$ rvm install 2.4.1
$ rvm use 2.4.1 --default
$ gem install iruby rails

Weryfikacja poprawności instalacji może być przeprowadzona poprzez wywołanie polecenia:

$ iruby notebook

Uwaga!

Jeśli w trakcie instalacji IRubiego pojawi się komunikat:

autogen.sh: error: could not find libtool.

Należy wykonać następujące polecenie:

$ sudo ln -s /usr/bin/libtoolize /usr/bin/libtool

A następnie ponownie wywołać polecenie

$ gem install iruby rails

Popieram Piotra Waglowskiego

Tyle w temacie nadchodzących wyborów parlamentarnych.

Closed beta of entity linking service

Recently I have deployed an entity linking service. It can be found at klon.wzks.uj.edu.pl/asterion. So far this is a closed beta – in future I am going to provide a commercial linking service. If you are interested in testing this service, don’t hesitate to contact me.

The means of operation of the service are simple – you provide a text on input, via HTTP POST and you will receive a JSON response with names of Wikipedia articles, together with text offsets and confidence values for the proposed links. As with any machine learning algorithm the output is not perfect, so don’t expect “true artificial intelligence” ;-) Still, the output might be pretty valuable, e.g. for indexing.

The API might be tested as follows (Warsaw is the capital of Poland):

curl -X POST -d 'text=Warszawa jest stolicą Polski.' http://klon.wzks.uj.edu.pl/asterion/annotator/annotate.json -u 'login:password' -basic

{"concepts": 
  [
    {"id":6605,"name":"Warszawa","confidence":0.21689995068611942,"start":0,"end":7},
    {"id":5664,"name":"Stolica Polski","confidence":0.21689995068611942,"start":14,"end":27}
  ]
}

So far only Polish is supported, but English will be provided soon.