Named Entity Recognition: Difference between revisions

From FDHwiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 30: Line 30:
== Bibliography ==
== Bibliography ==
<references />
<references />
== Quantitive analysis of the performances ==
Through the Python script we produced it is possible to generate at least six different kinds of pulses for each detected named entity. Considering that the database contains approximately 2300 books and 600 journal issues, it would be interesting to compute a lower bound for the number of produced pulses. In order to do this, some assumptions concerning the average number of named entity detected in a single document must be formulated. By examining the log of the script, which registers the number of named entity associated to each document, we were led to consider that 1000 named entity per document is a good estimate of the average performance. A second assumption must be done with regard to the number of articles contained in a journal issue. By browsing the database, it was concluded that 10 is an acceptable value.
Under these assumption, the number of pulses produced by parsing the whole database is
(2300 books*1000 named entities/book + 600 journal issue * 10articles/journal issue*1000 named entities / articles) * 6 pulses/named entity  50 Million == pulses.
The question now is how large a database must be in order to contain all these pulses. Please note that pulses are not the only elements stored in the output database, there’s also metadata information on documents, among which the most notable is the number of pulses produced from a certain document. The size of this metadata however is negligible compared to the contribution of pulses and won’t be considered in the estimate. In order to compute the final size of the output, a proportion with the current dimension of the database will be done. As of now the database contains around 400’000 pulses and its size is in the order of 220MB. Therefore, a database of 50 millions of pulses should be 125 times larger, which means a size of 27.5 GB. Considering that the input database is 80 GB in size, it can be argued that pulses represent an interesting way of condensing critical parts of information.
Lastly, an estimation of the needed time to process the whole database will be computed. The bottlenecks in the processing of the input database are two: the limited number of requests which can be sent to Dandelion daily and the writing of pulses into the output database. With these limitations, it was still possible to process 100 books in 16 hours. Under the assumption that processing a book takes as long as processing a journal issue, the total time to process the 2900 documents in the input database would be 464 hours, or 20 days.

Revision as of 16:38, 15 December 2017

Discussion of the State of the Art

Named Entity Recognizers relied for a long time on algorithms based on statistical models such as the Hidden Markov Model (HMM) [1] [2] and the Conditional Random Fields (CRFs) [3] [4]. For instance, the widely used Stanford Named Entity Recognizer [5] uses CRFs.

In recent years however the advancement in both GPU technology and deep learning techniques triggered the advent of architectures making use of Long Short-Term Memory Neural Networks (LSTMNNs) [6]. LSTMNNs are often used in conjunction with CRFs and allow to obtain a performance equivalent to the aforementioned methods [7] [8] without the need of performing complex feature engineering [7][9] [10]. LSTMNNs provide a model which has become a fundamental component for major companies like Google which prefer them over precedent approaches [11].

It is worth nothing that a recent paper [12] introduces the possibility to use Iterated Dilated Convolutional Neural Networks (ID-CNNs) in place of LSTMNNs to drastically improve computation time through full exploitation of the GPU's parallelizable architecture while keeping the same level of accuracy, which suggests ID-CNNs could be the next step in improving NER.

As far as the current state of the NER reasearch, matters of great concern include training data scarcity and inter-domain generalization [13]. In order to be efficient on a language domain, current NER systems need large labeled datasets related to that domain [14]. This training data isn’t available for all language domains, which leads to the impossibility of applying NER efficiently to them. Furthermore, if a language domain doesn’t follow strict language conventions and allows for a wide use of the language, then the model will fail to generalize due to excessive heterogeneity in the data. Examples of such domains are Sport and Finance. This is the reason for which one of the big challenges is “adapt[ing] models learned on domains where large amounts of annotated training data are available to domains with scarce annotated data” [13].

Bibliography

  1. ↑ Dan Klein, Joseph Smarr, Huy Nguyen, and Christopher D. Manning. 2003. Named entity recognition with character-level models. In Proceedings of the seventh conference on Natural language learning at HLT-NAACL 2003 - Volume 4 (CONLL '03), Vol. 4. Association for Computational Linguistics, Stroudsburg, PA, USA, 180-183.
  2. ↑ Dan Shen, Jie Zhang, Guodong Zhou, Jian Su, and Chew-Lim Tan. 2003. Effective adaptation of a Hidden Markov Model-based named entity recognizer for biomedical domain. In Proceedings of the ACL 2003 workshop on Natural language processing in biomedicine - Volume 13 (BioMed '03), Vol. 13. Association for Computational Linguistics, Stroudsburg, PA, USA, 49-56.
  3. ↑ Andrew McCallum and Wei Li. 2003. Early results for named entity recognition with conditional random fields, feature induction and web-enhanced lexicons. In Proceedings of the seventh conference on Natural language learning at HLT-NAACL 2003 - Volume 4 (CONLL '03), Vol. 4. Association for Computational Linguistics, Stroudsburg, PA, USA, 188-191.
  4. ↑ Burr Settles. 2004. Biomedical named entity recognition using conditional random fields and rich feature sets. In Proceedings of the International Joint Workshop on Natural Language Processing in Biomedicine and its Applications (JNLPBA '04), Nigel Collier, Patrick Ruch, and Adeline Nazarenko (Eds.). Association for Computational Linguistics, Stroudsburg, PA, USA, 104-107.
  5. ↑ https://nlp.stanford.edu/software/CRF-NER.html
  6. ↑ James Hammerton. 2003. Named entity recognition with long short-term memory. In Proceedings of the seventh conference on Natural language learning at HLT-NAACL 2003 - Volume 4 (CONLL '03), Vol. 4. Association for Computational Linguistics, Stroudsburg, PA, USA, 172-175.
  7. ↑ 7.0 7.1 Guillaume Lample, Miguel Ballesteros, Sandeep Subramanian, Kazuya Kawakami, Chris Dyer. 2016. Neural Architectures for Named Entity Recognition.
  8. ↑ Zhiheng Huang, Wei Xu, Kai Yu. 2015. Bidirectional {LSTM-CRF} Models for Sequence Tagging.
  9. ↑ Chen Lyu, Bo Chen, Yafeng Ren, Donghong Ji. 2017.Long short-term memory RNN for biomedical named entity recognition.
  10. ↑ Jason P. C. Chiu, Eric Nichols. 2015. Named Entity Recognition with Bidirectional LSTM-CNNs.
  11. ↑ Hasim Sak, Andrew Senior, Francoise Beaufays. 2014. Long Short-Term Memory Recurrent Neural Network Architectures for Large Scale Acoustic Modeling
  12. ↑ Emma Strubell, Patrick Verga, David Belanger, Andrew McCallum. 2017. Fast and Accurate Sequence Labeling with Iterated Dilated Convolutions.
  13. ↑ 13.0 13.1 Vivek Kulkarni, Yashar Mehdad, Troy Chevalier.2016. Domain Adaptation for Named Entity Recognition in Online Media with Word Embeddings.
  14. ↑ Isabelle Augenstein, Leon Derczynski, Kalina Bontcheva. 2017. Generalisation in Named Entity Recognition: {A} Quantitative Analysis.

Quantitive analysis of the performances

Through the Python script we produced it is possible to generate at least six different kinds of pulses for each detected named entity. Considering that the database contains approximately 2300 books and 600 journal issues, it would be interesting to compute a lower bound for the number of produced pulses. In order to do this, some assumptions concerning the average number of named entity detected in a single document must be formulated. By examining the log of the script, which registers the number of named entity associated to each document, we were led to consider that 1000 named entity per document is a good estimate of the average performance. A second assumption must be done with regard to the number of articles contained in a journal issue. By browsing the database, it was concluded that 10 is an acceptable value. Under these assumption, the number of pulses produced by parsing the whole database is 

(2300 books*1000 named entities/book + 600 journal issue * 10articles/journal issue*1000 named entities / articles) * 6 pulses/named entity  50 Million == pulses.

The question now is how large a database must be in order to contain all these pulses. Please note that pulses are not the only elements stored in the output database, there’s also metadata information on documents, among which the most notable is the number of pulses produced from a certain document. The size of this metadata however is negligible compared to the contribution of pulses and won’t be considered in the estimate. In order to compute the final size of the output, a proportion with the current dimension of the database will be done. As of now the database contains around 400’000 pulses and its size is in the order of 220MB. Therefore, a database of 50 millions of pulses should be 125 times larger, which means a size of 27.5 GB. Considering that the input database is 80 GB in size, it can be argued that pulses represent an interesting way of condensing critical parts of information.

Lastly, an estimation of the needed time to process the whole database will be computed. The bottlenecks in the processing of the input database are two: the limited number of requests which can be sent to Dandelion daily and the writing of pulses into the output database. With these limitations, it was still possible to process 100 books in 16 hours. Under the assumption that processing a book takes as long as processing a journal issue, the total time to process the 2900 documents in the input database would be 464 hours, or 20 days.

Retrieved from "http://fdh.epfl.ch/index.php?title=Named_Entity_Recognition&oldid=1041"