Customer Support Platform

Increase customer support efficiency by using preformed answers and optionally modifying it before replying to customers.

Goal

Build an API as demo to investors, about 3 weeks away. Basically a customer hands over their customer support chat logs, we provide back query-responses through API. The (reiterated) version of the problem is: retrieve relevant responses (from previously seen responses) based on customer question.

• Treat customer question as a query.
• Retrieve a reasonable response.
• The meat of the problem lies in creating a good mapping from query to a response.

Due to the timely nature of building a demo in short time, I look to using pre-existing tools rather than develop an entire process from scratch. Obviously it’s hard to publish any papers on using existent techiques, but our goal constraint involves more engineering than research.

Pre-existing tools approach

Apache Lucene

Apache Lucene, arguably the most advanced, high-performance, and fully featured search engine library in existence today—both open source and proprietary. But since it is a library only, it would be difficult to get started – you’d need to build around the library. This is the search engine library used behind Wikipedia, Guardian, Stack Overflow, Github, Akamai, Netflix, LinkedIn.

• Lucene has pluggable relevance ranking models (NLP information extraction and sentiment analysis) are built in, including the the Vector Space Model and Okapi BM25.
• The power of Lucene is text searching/analyzing. It’s very fast because all data in every field is indexed by default. Text searching focused applications should definitely use Lucene.

There are two predominant platforms built on top of Lucene. Apache Solr, and Elasticsearch. These two are built and designed for full text search on top of Lucene. Both are open source.

ElasticSearch is friendlier to teams which are used to REST APIs, JSON etc and don’t have a Java background, so we’ll run with that.

Elasticsearch

Elasticsearch is also written in Java and uses Lucene internally but makes full-text search easy by hiding the complexities of Lucene behind a simple, coherent, RESTful API.

• Also pluggable ranking models! This is important to try different approaches to getting good customer results. The modularity of this means we can build one pipeline, and improve our response by using different ranking models.
• Can be plugged with our own custom ranking functions. For instance, we might care about
  • Information decay, where more recent responses snippet at the top.
  • Ranking based on uses and non-uses of a response snippet.
• Customer’s questions treated as query input, and support agent’s responses treated as snippets to look up.
• References
  • General intro Learn | Docs.
  • Theory Behind Relevance Scoring

Searching

• Relevance: Elasticsearch’s main advantage over a traditional database is full-text search. Search results are sorted by their relevance score. The concept of relevance is completely foreign to traditional databases, in which a record either matches or it doesn’t. See Full Text Searching.
• Phrase Search: Sometimes we want to match exact sequences of words, phrases. Use the match_phrase query in Phrase Search.
• Highlighting: Although not super important, we can highlight the snippet that matched our search. Highlighting.

Ranking Models

Using a good ranking model is the meat of the problem. Famous ranking models:

• TF-IDF What is TF-IDF? The 10 minute guide Wikipedia TF-IDF
• BM25 is regarded slightly better in our case than TF-IDF.
  • Quote from Similarity in Elasticsearch: There is a reason why TF-IDF is as widespread as it is. It is conceptually easy to understand and implement while also performing pretty well. That said, there are other, strong candidates. Typically, they offer more tuning flexibility. In this article we have delved into one of them, BM25. In general, it is known to perform just as good or even better than TF-IDF, especially on collections with short documents.
• Consider taking Coursera on NLP, learn more about ranking models.

These two above are considered statistical analysis. In recent years, fundamental break-throughs were archieved using machine learning, specifically with neural architectures, in several subfields of AI – computer vision, speech recognition, machine translation. Consequently, more advanced ranking models could be derived from approaches in neural networks.

Training Data

Evaluating any prediction or recommendation engine relies on having a good set of data. The Ubuntu Dialogue Corpus is one such dialogue dataset.

Ubuntu Dialogue Corpus

The Ubuntu Dialogue Corpus, introduced by this paper, contains almost 1 million multi-turn dialogues, with a total of over 7 million utterances and 100 million words. Along with introduction of the dialogue corpus, the paper also discusses learning architectures suitable for analyzing this dataset.

Specifically, the following architectures are benchmarked for performance:

• Term Frequency-Inverse Document Frequency (TF-IDF, which is what is used by the Elasticsearch/Lucene engine)
• Recurrent Neural Network (RNN)
• Long Short-Term Memory (LSTM) architecture

Performance evaluation is based on the task of best response selection, without human labels. The agent is asked to select the k most likely responses, and it is correct if the true response is among the k candidates. The family of metrics used in language tasks is called Recall@k. For example, k = 1 is denoted as R@1.

The observed result is that the LSTM outperforms both RNN and TF-IDF on all evaluation metrics.

Daerli Chinese Conversation Log

A confidential corpus of support dialogues are to be used in our testing, as customers involved are Chinese companies.