Difference between revisions of "Vol-3194/paper9"
Jump to navigation
Jump to search
(modified through wikirestore by wf) |
(edited by wikiedit) |
||
Line 8: | Line 8: | ||
|authors=Federico Maria Scafoglieri,Alessandra Monaco,Giulia Neccia,Domenico Lembo,Alessandra Limosani,Francesca Medda | |authors=Federico Maria Scafoglieri,Alessandra Monaco,Giulia Neccia,Domenico Lembo,Alessandra Limosani,Francesca Medda | ||
|dblpUrl=https://dblp.org/rec/conf/sebd/ScafoglieriMNLL22 | |dblpUrl=https://dblp.org/rec/conf/sebd/ScafoglieriMNLL22 | ||
+ | |wikidataid=Q117345107 | ||
}} | }} | ||
==Automatic Information Extraction from Investment Product Documents== | ==Automatic Information Extraction from Investment Product Documents== |
Latest revision as of 18:00, 30 March 2023
Paper
Paper | |
---|---|
edit | |
description | |
id | Vol-3194/paper9 |
wikidataid | Q117345107→Q117345107 |
title | Automatic Information Extraction from Investment Product Documents |
pdfUrl | https://ceur-ws.org/Vol-3194/paper9.pdf |
dblpUrl | https://dblp.org/rec/conf/sebd/ScafoglieriMNLL22 |
volume | Vol-3194→Vol-3194 |
session | → |
Automatic Information Extraction from Investment Product Documents
Automatic Information Extraction from Investment Product Documents Federico Maria Scafoglieri1 , Alessandra Monaco1 , Giulia Neccia1 , Domenico Lembo1 , Alessandra Limosani2 and Francesca Medda2,3 1 Sapienza Universitá di Roma, Piazzale Aldo Moro, 5, 00185 Roma RM 2 Commissione nazionale per le societá e la Borsa, Via Giovanni Battista Martini, 3, 00198 Roma RM 3 University College London, Gower Street, London, United Kingdom Abstract In this paper we report on the activities carried out within a collaboration between Consob and Sapienza University. The developed project focus on Information Extraction from documents describing financial investment products. We discuss how we automate this task, via both rule-based and machine learning- based methods, and describe the performances of our approach. Keywords Information Extraction, Financial documents, Financial Market Vigilance, Table Extraction 1. Introduction In Italy, Consob (Commissione Nazionale per le Società e la Borsa) is the supervisory and regula- tory authority of the financial market. Among the several functions, Consob has the role of monitoring and supervising any financial instruments that are issued, with the ultimate aim of detecting and enforcing against illicit conduct. The specific project we will discuss in the following, besides Consob, involves researchers from Sapienza University of Rome. To support Consob in its supervision activities, and in particular in the task of verifying the correctness and completeness of the information it collects about financial investment products, within this collaboration a solution for the automatic extraction of structured information from free text documents has been developed. Through such solution, relevant data contained in the documents are not to be manually identified and extracted, but can be collected through an automated process which makes them available in a machine processable format. To this aim, two approaches to Information Extraction (IE) have been adopted: rule-based and machine learning (ML)-based. In the following we describe them, explain why both are useful for our goals, and report on first the results we obtained in the project. SEBD 2022: The 30th Italian Symposium on Advanced Database Systems, June 19-22, 2022, Tirrenia (PI), Italy $ scafoglieri@diag.uniroma1.it (F. M. Scafoglieri); monaco.1706205@studenti.uniroma1.it (A. Monaco); neccia.1847033@studenti.uniroma1.it (G. Neccia); lembo@diag.uniroma1.it (D. Lembo); i.tiddi@vu.nl (A. Limosani); f.medda@ucl.ac.uk (F. Medda) © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) �Figure 1: Portion of a KID by CreditSuisse. 2. The use case In the EU, the creators of financial products (a.k.a. financial manufacturers) are obliged by law to make information related to so-called PRIIPs (Packaged Retail Investment and Insurance- based Investments Products) publicly available. The NCAs (National Competent Authorities) have supervisory duties on such products, so that they can be safely placed on the respective national markets. The legislation requires information about PRIIPs to be communicated to NCAs through documents called KIDs (Key Information Documents). In the practice, this means that features to be checked are cast into text reports, typically formatted as pdf files (cf. Figure 1, containing a KID for the Italian market), and extracting structured data from them (to bootstrap control activities), is actually in charge to the authority (In Italy, Consob). Due to the massive amount of documents to be analyzed (e.g., more than 1 million KIDs received by in 2020), this process cannot be carried out manually, but still it is only partially automated to date. 3. The approach The KIDs present key information about financial products through free text or tables. We decided to extract relevant data contained in the free text part of the documents through a rule-based mechanism [1, 2]. This choice lies in the fact that the KIDs follow a quite rigid template imposed by the European authority, a characteristic that makes domain experts able to express quite precise patterns for the identification of wanted data, and AI experts to encode them into extraction rules. This approach has also the great advantage to provide the final user with a precisely explainable IE mechanism, a characteristic which is particularly critical in the context we operate. However, rule-based mechanisms do not lend themselves well to the extraction of data contained in tables, which are particularly difficult to identify, depending also on the way in which the table is originally formatted [3]. For this reason we decided to resort to an approach �based on learning systems that treat a pdf file as if it were an image and aim to identify the set of pixels that are tables, together with the corresponding cells. Afterwards, the textual characters contained inside the detected cells can be recognized through OCR methods. In the following we discuss in more detail the two approaches, highlighting their complete pipelines and showing the results obtained. 3.1. Rule-based IE We defined around 100 rules to extract 16 data fields, like product name, manufacturer, in- vestment risk, from the free text contained in a KID. Below we briefly comment on the data preparation and the annotation modules that are part of our rule-based IE pipeline. A third module is in charge of exporting the extracted fields in CSV format. Data Preparation. This module transforms the PDF into plain text and clean it from errors. We performed it by means of PDFBox1 , an Apache state-of-the-art and highly customizable library for PDF documents. Annotation. The annotation task is carried out through CoreNLP2 , a popular open-source JAVA toolkit for natural language processing developed at Stanford University. For our development we relied on the CoreNLP-it module [4], specifically developed for the Italian language, We exploited fundamental services offered by CoreNLP, such as tokenization, lemmatization, POS tagging, and in particular made use of the TokensRegex component [5], which extends traditional regular expressions on strings by working on tokens instead of characters and defining pattern matching via a stage-based application. These extensions of regular expressions allow for writing extraction rules, i.e., rule-based extractors matching on additional token-level features, such as part-of-speech annotations, named entity tags, and custom annotations. As an example, consider the following TokensRegex extraction rule useful for extracting International Securities Identification Numbers (ISINs) from KIDs: $StartISIN = ( /ISIN/ /:/|/Codice/ /del/ /Prodotto|prodotto/ /:/| ... ) $EndISIN = ( /*/ ...) $code = "/([A-Za-z][A-Za-z][0-9]{10})/" { ruleType: "tokens", pattern: ( ($StartISIN) (?$CodeISIN [{word:$code} & {SECTION:"SECTION_PRODUCT"}]+?) ($EndISIN)), action: ( Annotate($CodeISIN, ISIN, "ISIN")) } The ISIN is an alphanumeric sequence of 12 characters identifying a PRIIP. This sequence begins with two characters followed by ten numbers. In the rule above, the ISIN format is compiled into the regular expression assigned to the variable $code. $StartISIN and $EndISIN represent the set of sequences of tokens (separated from each other through the symbol |) preceding and following the ISIN code, respectively. ruleType specifies that our 1 https://pdfbox.apache.org 2 https://stanfordnlp.github.io/CoreNLP/ �Figure 2: Pipeline for table extraction rule works on "tokens", whereas pattern contains the pattern to be matched over the text. Through the pattern above the rule looks for a matching of the regular expression $code over all the tokens in the product section (i.e., annotated with SECTION_PRODUCT), and such that $code is preceded by the tokens in $StartISN and followed by the ones in $EndISIN. Finally action describes what annotation to apply. In our example, we annotate the token identified by the group $CodeISIN with the annotation ISIN. By applying this rule over the KID in Figure 1 we annotate CH0524993752 with ISIN. 3.2. Machine Learning-based IE We used ML techniques to extract data from the following tables: • Performance scenarios: it provides data about potential risks and yield. We are inter- ested in extracting the potential refund and the average yield per year in all the possible scenarios: stress, unfavorable, moderate, favorable, each at fixed time periods (initial, intermediate, recommended holding). • Costs over time: it shows the cost trend. We want to extract data about total costs and reduction in yield (RIY) in percentage at the same time periods considered for the performance scenarios. • Composition of costs: it describes the components of costs. We aim to extract the RIY for various cost categories: una tantum input and una tantum output costs, recurrent wallet transactions, other recurrent costs, performance and overperformance fees. We modeled the problem as a Computer Vision task, converting each page of the KID into a set of images. In such a setting, the Extraction involves (1) a Table Detection task, aiming at detecting bordered or borderless/semi-bordered tables, (2) a Table Structure Recognition task, able to identify the cells belonging to the detected table, and (3) a Text Extraction task, to get the textual information contained inside each cell. We propose an automatic, learning-based approach, exploiting the power of Deep Learning and Convolutional Neural Networks (CNN) for image processing. In particular, for subtasks 1-2 we use CascadeTabNet [6], a recent implementation of a CNN model which was trained by the authors on the detection of border/borderless tables and cells first on general tables (e.g. word, latex documents), then on ICDAR-193 . For subtask 3 instead, we use Tesseract [7], a popular 3 ICDAR-19 is a dataset containing table data, that was released for a Table Detection and Recognition competition at ICDAR in 2019 �Optical Character Recognition (OCR) engine. The pipeline we realized is shown in Figure 2. The main module are: • Page Identification Module, which identifies the pages of the document containing the tables we want to extract. Such tables are indeed contained in specific sections of the document, which we can recognize through a simple lookup of certain keywords, like ‘performance scenarios’, ‘costs over time’, ‘composition of costs’. • Table Detection and Table Structure Recognition Module, which uses the pre-trained CascadeTabNet model to identify the masks (i.e. bounding boxes) of borderless/bordered tables and cells. The masks are returned if and only if their level of confidence is higher than the input threshold, that we experimentally tuned to 0.6. Cells are then assigned to the correspondent table depending on their positions. • Table Identification and Row Extraction Module, that applies the OCR to each cell bounding box. Based on the text extracted by the OCR, we are able to understand if the considered table is the one of interest. In a single page in fact, many different tables can be present. We use the top coordinate value of the cell masks to organize them into rows. • Row Processing and Cleaning Module, which produces the final output of the extrac- tion. In particular, from an inspection of the rows created in the previous step, and on the basis on their attended structure that we know from the regulation, we are able to assign the extracted information to the correspondent information field. A final Cleaning step, deals with missing punctuations, extra space removal, OCR error correction and, numerical formats standardization. The effectiveness of the results often depends on the table template: there are few tables that the algorithm fails to recognize at all, or for which some cells are not detected (mostly the table headers). Table/cell detection is indeed a challenging task, due to different reasons. Firstly, the heterogeneity of table templates adopted by the PRIIPs authors makes the task harder for the neural network; templates are slightly different from the ones in ICDAR-19, because they are modern, often semi-bordered or borderless, semi-coloured, with multi-line cells. The same table type may present different number of rows or columns, just because the specific kind of PRIIP requires it, or because of a different arrangement of the information in the table (for instance, a single cell contains both a cost and a RIY). Moreover, we noticed issues in identifying multi-line cells: few times true multi-line cells are detected as two distinct cells or, on the contrary, distinct cells that appear one under the other, probably very close, are detected as a single multi-line cell. We addressed this last case in the Rows Cleaning Module: using our knowledge of the table structures, knowing which field types appear one under the other, we split the wrongly multi-line cells and assign the data to the proper field. Regarding cell masks, we noticed also that, in few cases, the detected bounding box was quite inaccurate, cropping the text and consequently causing troubles in OCR. In order to avoid it, we consider an enlargement factor such that we run the OCR on a slightly larger area. 4. First results Table 1 provides some information regarding the two datasets on which we tested our approach. Dataset-1 was created specifically as a test scenario. It is representative of document hetero- �geneity and includes KIDs from the years 2018-2020. Dataset-2 was selected randomly from a sample of KIDs from the first half of 2021. Table 1 Dataset Info Dataset Total KIDs Size Manufacturers DATASET-1 1240 250MB 36 DATASET-2 7736 3GB 52 Table 2 reports an average of precision and recall over all information extracted through the rule-based approach. The performances we got testify that the effort put in designing the rules definitely pays off, since we reach very high level of precision and recall, as required in the considered application scenario. Table 2 Results for the rule-based approach Dataset Precision Recall F-Measure DATASET-1 98% 96% 97% DATASET-2 98% 94% 96% Table 3 instead shows the number of tables extracted through our ML-based approach for each table type, before the Fine-Tuning phase that we will describe in the next section. We obtained the worst recall for the Costs Evolution table. This is probably due to the fact that the extraction of this table mostly relies on just two header cells in the Table Identification step, therefore, if the model fails for any reason in detecting just those two cell masks, the table is not extracted even though the numerical cell masks are often correctly detected. This issue is less critical for the other table types, since more cells can be used for Table Identification. Table 3 Results of the Extractor for the different table types. Dataset DATASET-1 DATASET-2 Performance Extracted 1218 6435 scenarios Missing 22 1301 Costs Extracted 752 3925 over time Missing 488 3811 Composition Extracted 1153 6886 of costs Missing 87 850 5. Fine-Tuning to improve Information Extraction from tables As said, to extract information from tables, we started from a model that was trained on the detection of generic tables. Since the tables in KIDs documents may present complex layouts, we fine-tuned the model using custom data, in order to improve its effectiveness. Below we describe the Fine-Tuning process we adopted. �Table 4 Comparing results of the Original and Fine-Tuned Extractor for the different table types. Model Gap Original Fine-Tuned (%) Performance Extracted 1218 1237 +1.5% scenarios Missing 22 3 Costs Extracted 752 1223 +62,63% over time Missing 488 17 Composition Extracted 1153 1167 + 1.2% of costs Missing 87 73 Labeling Data with Label Studio. The first step involves creating a suitable dataset for training purposes. Here, ’suitable’ means ’labeled’: for each image of the dataset we have to annotate the coordinates (bounding boxes) of the tables and the cells it contains. To this aim we have used Label Studio4 , an open-source flexible data annotation tool, that can be adapted to different labeling tasks (image classification, object detection, event recognition, etc.) and data type (images, audio, text, time-series, etc.), allowing different users to collaborate on the annotation process, that is well known to be highly time consuming and to require a lot of manual effort. For our object detection annotation task we customized labels in ‘bordered’, ‘borderless’ and ‘cell’ and we drew the bounding boxes of each label using the mouse. The tool automatically generates the bounding boxes coordinates and allows to export the annotations in different formats. We exported annotations in Pascal VOC (Visual Object Classes) XML, that creates a different xml file for each image, containing <object> elements providing annotation information, in particular the label and the coordinates of the bounding box. Training the Model. The extracted Pascal VOC data are then converted into COCO (Common Objects in COntexts) format, typically required by object detection models. We trained the model using MMDetection, an open source object detection toolbox, loading the pre-trained weights of CascadeTabNet model and training for 10 epochs using our annotated data. 239 images (KID pages converted to png files) were used for the training, trying to maximize the variance of the KIDs authors and therefore, the templates. Each image page may contain more than a single table. In total, our training dataset contained 10844 objects, respectively 71 bor- dered tables, 373 borderless tables and 10400 cells. Results on table extraction after Fine-Tuning. The fine-tuned model has been tested on Dataset-15 , showing a great improvement in extracting data from ‘Costs over time’ tables. Whereas the first model (non-fine-tuned) was not able to extract 488 tables (~40% of the total tables), the fine-tuned model misses just 17 tables. The gap between the two extractions is im- pressive, which testifies that Fine-Tuning has been particularly effective. A slight improvement has been observed in the other table types, too. In Table 4 we give the results of the extractions of tables by comparing the first model with the fine-tuned model, whereas in Table 5 we report the average precision, recall and f1-scores 4 https://labelstud.io/ 5 We also tested our results on Dataset-2, but our evaluation, due to dataset size, was done on a sample basis with results similar to that reported for Dataset-1. �on all the fields extracted from the 3 table types for Dataset-1. Table 5 Results of Fine-Tuning. Dataset Precision Recall F-Measure DATASET-1 ~99% ~79% ~88% 6. Conclusion We are currently working to complete IE from KIDs, by attacking some of their portions that have not been so far involved in the extraction process. The next project steps concern with post- extraction data analysis, aimed to identify anomalous documents, correct errors and missing mandatory data, discover interesting correlations among data. We are also investigating how to link collected data to a domain ontology, to exploit reasoning services and enhance the entire data acquisition process according to the Ontology-based data access and integration [8, 9, 10] References [1] J. Doleschal, B. Kimelfeld, W. Martens, Database principles and challenges in text analysis, SIGMOD Record 50 (2021) 6–17. [2] D. Lembo, F. M. Scafoglieri, Ontology-based document spanning systems for information extraction, Int. J. of Semantic Computing 14 (2020) 3–26. [3] E. Oro, M. Ruffolo, PDF-TREX: an approach for recognizing and extracting tables from PDF documents, in: Proc. of ICDAR, IEEE Computer Society, 2009, pp. 906–910. [4] A. P. Aprosio, G. Moretti, Italy goes to stanford: a collection of corenlp modules for italian, Comp. Res. Rep. (CoRR) abs/1609.06204 (2016). URL: http://arxiv.org/abs/1609.06204. [5] A. X. Chang, C. D. Manning, Tokensregex: Defining cascaded regular expressions over tokens, Stanford University Computer Science Technical Reports. CSTR 2 (2014) 2014. [6] D. Prasad, A. Gadpal, K. Kapadni, M. Visave, K. Sultanpure, Cascadetabnet: An approach for end to end table detection and structure recognition from image-based documents, Comp. Res. Rep. (CoRR) abs/2004.12629 (2020). URL: https://arxiv.org/abs/2004.12629. [7] R. Smith, An overview of the tesseract OCR engine, in: Proc. of ICDAR, volume 2, 2007, pp. 629–633. doi:10.1109/ICDAR.2007.4376991. [8] D. Calvanese, G. D. Giacomo, D. Lembo, M. Lenzerini, R. Rosati, Ontology-based data access and integration, in: L. Liu, M. T. Özsu (Eds.), Encyclopedia of Database Systems, Second Edition, Springer, 2018. [9] F. M. Scafoglieri, D. Lembo, A. Limosani, F. Medda, M. Lenzerini, Boosting information extraction through semantic technologies: The kids use case at consob, volume 2980 of CEUR, ceur-ws.org, 2021. [10] D. Lembo, Y. Li, L. Popa, K. Qian, F. Scafoglieri, Ontology mediated information extraction with MASTRO SYSTEM-T, volume 2721 of CEUR, ceur-ws.org, 2020, pp. 256–261. �