Text-Summary Methodology

AvaBot is able to give what a document is about by summarizing it, it is therefore critical that we choose the right text-summarization method to yield reliable results.

In general, we applied extractive summarization instead of risking for abstractive summarization[8] for the reason that current abstractive summarizing algorithm are less stable and of high demand of training, time and computational power, where Google’s open-source abstractive text summarization architecture, Textsum, requires training for over million time-steps to successfully reproduce the reported result[9], compared to which extractive summarization is more reliable, efficient and of the advantages it respects and reflects more honestly the original documents.

Out of the well-established extractive text summarization algorithms, we turned to TextRank Algorithm, which produced better outcomes compared to other methods[10] when tested on MultiLing2015 training corpus[11].

Next→QA system

Introduction

QA system, i.e., question answering system, is the system to retrieve information from a document and then process natural language queries, and thus our solution to AvaBot's document query feature. QA system can be classified by domain. One is close domain QAs, which are super effective in their specific domains, but require expert-constructed knowledge bases and strict limit of the type of questions. The other is Open Domain QA system, it has come out with the fast development of comprehensive theories in computational linguistics, and is the main target area we are focusing on.

Existing Open-source QA system

Haystack is an open-source framework for building end-to-end question answering system. We chose to use it for implementing the QA feature regarding its scalable functionalities, such as extracting text from pdf, docx and txt, indexing a file with different searching engines like Elasticsearch or FAISS, flexible modules to adapted in order to target on specific file content. Haystack encapsulates the Transformer project and makes it work well in industrial use cases. The whole project is open-sourced, allowing for fine tune to suit what we need. The NLP models we used were trained with Stanford Question Answering Data Set(SQuAD)[12], which is flexible in processing texts in different knowledge backgrounds.

Elasticsearch

A "database" is reuqired for the QA system to store files with meta data and provide them to the retriever at query time. Available solutions include Elasticsearch, FAISS and Milvus. We eventually went for Elasticsearch in that ES is particularly good at dense retrieval with the fastest and most accurate sparse retrieval with many tuning options among the three. In addition, ES is a mature project, it has been production-ready and had a big community behind it.

Gunicorn

We decided to separately deploy our QA system on a virtual machine because it depended on some system tools such as docker engine. A virtual machine can provide a more flexible environment configuration compared with Azure Function, with which we built APIs for the other bot features; Also, VM has large memory and multi-core CPU, which could speed up document processing. Among several application servers we could choose to host the QA system, Gunicorn[13] became our final choice as it is much easier to set up with a flask application (btw, we are in favour of unicorn ). The reason is that Gunicorn is using a pre-fork model[14], which keeps blocking the thread when it is waiting for IO. This does not really affect our project as it requires low level of concurrency. We also solved this problem by proxying it with Nginx[15].