Applied artificial intelligence technology for using natural language processing to train a natural language generation system with respect to numeric style features

Abstract

Disclosed herein is computer technology that applies natural language processing (NLP) techniques to training data to generate information used to train a natural language generation (NLG) system to produce output that stylistically resembles the training data. In this fashion, the NLG system can be readily trained with training data supplied by a user so that the NLG system is adapted to produce output that stylistically resembles such training data. In an example, an NLP system detects a plurality of linguistic features in the training data. These detected linguistic features are then aggregated into a specification data structure that is arranged for training the NLG system to produce natural language output that stylistically resembles the training data. Parameters in the specification data structure can be linked to objects in an ontology used by the NLG system to facilitate the training of the NLG system based on the detected linguistic features.

Description

INTRODUCTION

There is an ever-growing need in the art for improved natural language generation (NLG) technology. However, one of the challenges for developing a robust NLG system as a platform that is to be used by many different users is that each user may have different stylistic preferences regarding how content should be presented in NLG output. For example, Company A and Company B may both use the same underlying NLG technology to produce performance reports about its salespeople, but each may have different stylistic preferences for such reports. However, configuring the NLG system to differentiate its stylistic output for different users is a challenging task technologically.

As a technical advance in the art, the inventors disclose the use of natural language processing (NLP) techniques that are applied to training data to generate information used to train an NLG system to produce output that stylistically resembles the training data. In other words, the NLP techniques discussed herein permit an NLG system to be trained via automated learning techniques in a manner that will satisfy a user who wants the NLG system to “write like me”.

NLG is a subfield of artificial intelligence (AI) concerned with technology that produces language as output on the basis of some input information or structure (e.g., where the input constitutes data about a situation to be analyzed and expressed in natural language).

NLP is a subfield of AI concerned with technology that interprets natural language inputs, and natural language understanding (NLU) is a subfield of NLP concerned with technology that draws conclusions on the basis of some input information or structure.

A computer system that trains an NLG system to flexibly produce style-specific natural language outputs needs to combine these difficult areas of NLG and NLP/NLU so that the system not only understands the deeper meanings and styles that underlie the training data but also is able to translate these stylistic understandings and meanings into a configuration that is usable by the NLG system. The inventors disclose herein a number of technical advances with respect to the use of NLP technology to train an NLG system.

For example, the inventors disclose an NLP system that is able to detect a plurality of linguistic features in the training data, wherein the training data comprises a plurality of words arranged in a natural language. These detected linguistic features are then aggregated into a specification data structure that is arranged for training an NLG system to produce natural language output that stylistically resembles the training data. This specification data structure can comprise a machine-readable representation of the detected linguistic features. Parameters in the specification data structure can be linked to objects in an ontology used by the NLG system to facilitate the training of the NLG system based on the detected linguistic features.

The detected linguistic features can include numeric styles in the training data as well as date and number textual expressions in the training data. Examples of such linguistic features include decimal precision features, decimal separator features, digit grouping delimiter features, currency symbol features, day expressions features, month expression features, currency expressions features, and numeric expressions features.

The detected linguistic features can also include ontological vocabulary derived from the training data. Such ontological vocabulary can be used to train the NLG system to use expressions for ontological objects known by the NLG system that match up with how those ontological objects are expressed in the training data.

In a particularly powerful example embodiment discussed herein, the detected linguistic features can include concept expression templates that model how a concept is expressed in the training data. Examples of concepts that can be modeled in this fashion from the training data include change concepts, compare concepts, driver concepts, and rank concepts. In an example embodiment, to detect and extract such concept expression templates from the training data, the training data can be scanned for the presence of one or more anchor words, where each anchor word is associated with a concept understood by the system. If an anchor word is present in the training data, the system can then process the training data to extract an expression template that models how the concept associated with the present anchor word is discussed in the training data. NLP parsing can be applied to the training data and linkages to NLG ontologies can be employed to facilitate this concept expression template extraction.

Further still, the inventors disclose how user interfaces can be employed that permit a user to selectively control which of the detected linguistic features will be used to train the NLG system. Such user interfaces can also permit users to create concept expression templates “on the fly” in response to text inputs from the user (e.g., where a user types in a sentence from which a concept expression template is to be extracted).

Through these and other features, example embodiments of the invention provide significant technical advances in the NLP and NLG arts by harnessing computer technology to improve how natural language training data is processed to train an NLG system for producing natural language outputs in a manner that stylistically resembles the training data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 discloses an example AI computer system in accordance with an example embodiment.

FIG. 2 discloses an example process flow for NLP-based training of an NLG system.

FIG. 3 shows an example process flow for extracting linguistic features from training data and aggregating the extracted linguistic features into a specification data structure.

FIG. 4A discloses an example process flow for entity identification in support of NLP in accordance with an example embodiment.

FIG. 4B discloses an example prefix tree that can be used for identifying entities in training data.

FIG. 5 shows an example process flow for detecting and extracting concept expression templates from training data.

FIGS. 6A-6D show examples of parse tree structures at various stages of the FIG. 5 process flow.

FIG. 6E shows an example process flow for transforming and/or tagging tokens in a parse tree with NLG-compatible labels.

FIG. 7 shows another example schematic for end-to-end detection and extraction of concept expression templates from training data.

FIGS. 8A-8I show examples of parse tree structures and other text examples at various stages of the FIG. 7 process.

FIGS. 9A-9J show examples of different portions of a specification data structure that can be produced by the NLP training system.

FIGS. 10A-10G show various example of user interfaces for controlling and operating the training system.

FIG. 10H shows an example narrative produced by the trained NLG system.

FIGS. 11A and 11B show example specification data structures that illustrate how user inputs via user interfaces can modify a base specification data structure.

FIGS. 12A and 12B show example commands for an HTTP API with respect to an example embodiment.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

FIG. 1 shows an example computer system 100 in accordance with an example embodiment. The computer system 100 may comprise a training data gateway 102 that links an artificial intelligence (AI) platform 104 with one or more sources of input training data such as document(s) 120, text input 122, and/or speech input 124. The training data gateway 102 then provides such information to an NLP-based training system 106 as training data 126. As an example, the training data gateway 102 can receive an upload of one or more documents 120, where the document(s) 120 serve as training data 126. The training data gateway 102 can also receive user input in the form of text 122 (such as text input through a graphical user interface) wherein the text 122 serves as training data 126. The training data gateway 102 can also receive user input in the form of speech 124, where speech recognition is performed by the gateway 102 to convert the speech into training data 126. For example, software such as the Transcribe application available from Amazon could be employed to transcribe speech data into text data for processing. The document(s) 120, text input 122, and/or speech input 124 can take the form of unstructured data arranged as a plurality of words in a natural language format. The NLP-based training system 106 applies NLP to the training data to determine linguistic styles that are present in the training data and uses the determined linguistic styles to generate configuration data 128 that is used to train the NLG system 108 to produce natural language output that stylistically resembles the training data 126.

To aid the NLP-based training system 106 and the NLG system 108 in their operations, the NLP-based training system 106 and the NLG system 108 can access supporting data 110. This supporting data 110 can include the ontological and project data that serves as a knowledge base for the AI platform 104.

The computer system 100 comprises one or more processors and associated memories that cooperate together to implement the operations discussed herein. The computer system 100 may also include a data source that serves as a repository of data for analysis by the AI platform 104 when processing inputs and generating outputs. These components can interconnect with each other in any of a variety of manners (e.g., via a bus, via a network, etc.). For example, the computer system 100 can take the form of a distributed computing architecture where one or more processors implement the NLP tasks described herein (see NLP-based training system 106), one or more processors implement the NLG tasks described herein (see NLG system 108). Furthermore, different processors can be used for NLP and NLG tasks, or alternatively some or all of these processors may implement both NLP and NLG tasks. It should also be understood that the computer system 100 may include additional or different components if desired by a practitioner. The one or more processors may comprise general-purpose processors (e.g., a single-core or multi-core microprocessor), special-purpose processors (e.g., an application-specific integrated circuit or digital-signal processor), programmable-logic devices (e.g., a field programmable gate array), etc. or any combination thereof that are suitable for carrying out the operations described herein. The associated memories may comprise one or more non-transitory computer-readable storage mediums, such as volatile storage mediums (e.g., random access memory, registers, and/or cache) and/or non-volatile storage mediums (e.g., read-only memory, a hard-disk drive, a solid-state drive, flash memory, and/or an optical-storage device). The memory may also be integrated in whole or in part with other components of the system 100. Further, the memory may be local to the processor(s), although it should be understood that the memory (or portions of the memory) could be remote from the processor(s), in which case the processor(s) may access such remote memory through a network interface. The memory may store software programs or instructions that are executed by the processor(s) during operation of the system 100. Such software programs can take the form of a plurality of instructions configured for execution by processor(s). The memory may also store project or session data generated and used by the system 100. The data source can be any source of data, such as one or more databases, file systems, computer networks, etc. which may be part of the memory accessed by the processor(s).

The NLP-based training system 106 can be designed to work end-to-end without any human supervision, although it should be understood that a practitioner may choose to provide a user interface that allows users to review and update the determined linguistic features before they are applied to the NLG system 108.

FIG. 2 depicts an example process flow for execution by one or more processors that implement the NLP-based training system 106. At step 200, a processor ingests the training data 126. For example, as noted, the training data 126 can take the form of a corpus of documents that are represented by files. The documents can be ingested, converted into raw text strings, and saved for use by the training system 106 (for example, in a relational database as one document per row). The same process can be followed for text inputs and speech inputs, albeit the volume of data will likely be lower in such instances. Also, if desired, multiple files can be ingested at step 200 using techniques such as multi-part, form-encoded HTTP POST.

At step 202, a processor extracts linguistic features from the ingested training data using a variety of pattern matchers and rule-based NLP heuristics, examples of which are discussed below. Using these techniques, specific linguistic features can be detected in and extracted from each document, and each document can be converted into a data structure (e.g., a JSON data structure) that contains linguistic feature metadata.

At step 204, a processor aggregates the extracted linguistic features produced from the documents at step 202 by iterating over the document-specific data structures. This can include deriving totals, percentages, grouping, and sorting, which operates to produce a specification data structure (e.g., a JSON specification data structure, which is a machine-readable description of the linguistic features extracted from the ingested training data 126.

At step 206, a user interface (e.g., a browser-based graphical user interface (GUI)) can process the specification data structure and present a user with the linguistic features discovered by steps 202 and 204. Through the user interface, the user can elect to discard any of the discovered linguistic features. In example embodiments, the user can also enter custom sentences into the user interface to add additional ontological vocabulary to the system and/or add concept expressions to the specification. However, as noted above, such user interaction can be omitted if desired by a practitioner.

At step 208, a processor configures the NLG system 108 based on the specification data structure to thereby train the NLG system 108 to produce language that stylistically resembles the training data 126. In an example embodiment, a platform-specific applicator can take the JSON specification data structure (and any user preferences) as inputs and update the appropriate configuration within the NLG system 108.

The NLG system 108 can then use the specification data structure to update its configuration information to control how it produces natural language output. In an example embodiment, the NLG system 108 can produce NLG output about a data set based on defined configurations such as parameterized communication goal statements. An example of NLG technology that can be used as the NLG system 108 is the QUILL™ narrative generation platform from Narrative Science Inc. of Chicago, Ill. Aspects of this technology are described in the following patents and patent applications: U.S. Pat. Nos. 8,374,848, 8,355,903, 8,630,844, 8,688,434, 8,775,161, 8,843,363, 8,886,520, 8,892,417, 9,208,147, 9,251,134, 9,396,168, 9,576,009, 9,697,178, 9,697,197, 9,697,492, 9,720,884, 9,720,899, and 9,977,773, 9,990,337, and 10,185,477; and US patent application Ser. No. 15/253,385 (entitled “Applied Artificial Intelligence Technology for Using Narrative Analytics to Automatically Generate Narratives from Visualization Data, filed Aug. 31, 2016), 62/382,063 (entitled “Applied Artificial Intelligence Technology for Interactively Using Narrative Analytics to Focus and Control Visualizations of Data”, filed Aug. 31, 2016), Ser. No. 15/666,151 (entitled “Applied Artificial Intelligence Technology for Interactively Using Narrative Analytics to Focus and Control Visualizations of Data”, filed Aug. 1, 2017), Ser. No. 15/666,168 (entitled “Applied Artificial Intelligence Technology for Evaluating Drivers of Data Presented in Visualizations”, filed Aug. 1, 2017), Ser. No. 15/666,192 (entitled “Applied Artificial Intelligence Technology for Selective Control over Narrative Generation from Visualizations of Data”, filed Aug. 1, 2017), 62/458,460 (entitled “Interactive and Conversational Data Exploration”, filed Feb. 13, 2017), Ser. No. 15/895,800 (entitled “Interactive and Conversational Data Exploration”, filed Feb. 13, 2018), 62/460,349 (entitled “Applied Artificial Intelligence Technology for Performing Natural Language Generation (NLG) Using Composable Communication Goals and Ontologies to Generate Narrative Stories”, filed Feb. 17, 2017), Ser. No. 15/897,331 (entitled “Applied Artificial Intelligence Technology for Performing Natural Language Generation (NLG) Using Composable Communication Goals and Ontologies to Generate Narrative Stories”, filed Feb. 15, 2018), Ser. No. 15/897,350 (entitled “Applied Artificial Intelligence Technology for Determining and Mapping Data Requirements for Narrative Stories to Support Natural Language Generation (NLG) Using Composable Communication Goals”, filed Feb. 15, 2018), Ser. No. 15/897,359 (entitled “Applied Artificial Intelligence Technology for Story Outline Formation Using Composable Communication Goals to Support Natural Language Generation (NLG)”, filed Feb. 15, 2018), Ser. No. 15/897,364 (entitled “Applied Artificial Intelligence Technology for Runtime Computation of Story Outlines to Support Natural Language Generation (NLG)”, filed Feb. 15, 2018), Ser. No. 15/897,373 (entitled “Applied Artificial Intelligence Technology for Ontology Building to Support Natural Language Generation (NLG) Using Composable Communication Goals”, filed Feb. 15, 2018), Ser. No. 15/897,381 (entitled “Applied Artificial Intelligence Technology for Interactive Story Editing to Support Natural Language Generation (NLG)”, filed Feb. 15, 2018), 62/539,832 (entitled “Applied Artificial Intelligence Technology for Narrative Generation Based on Analysis Communication Goals”, filed Aug. 1, 2017), Ser. No. 16/047,800 (entitled “Applied Artificial Intelligence Technology for Narrative Generation Based on Analysis Communication Goals”, filed Jul. 27, 2018), Ser. No. 16/047,837 (entitled “Applied Artificial Intelligence Technology for Narrative Generation Based on a Conditional Outcome Framework”, filed Jul. 27, 2018), 62/585,809 (entitled “Applied Artificial Intelligence Technology for Narrative Generation Based on Smart Attributes and Explanation Communication Goals”, filed Nov. 14, 2017), Ser. No. 16/183,230 (entitled “Applied Artificial Intelligence Technology for Narrative Generation Based on Smart Attributes”, filed Nov. 7, 2018), Ser. No. 16/183,270 (entitled “Applied Artificial Intelligence Technology for Narrative Generation Based on Explanation Communication Goals”, filed Nov. 7, 2018), 62/632,017 (entitled “Applied Artificial Intelligence Technology for Conversational Inferencing and Interactive Natural Language Generation”, filed Feb. 19, 2018), Ser. No. 16/277,000 (entitled “Applied Artificial Intelligence Technology for Conversational Inferencing”, filed Feb. 15, 2019), Ser. No. 16/277,003 (entitled “Applied Artificial Intelligence Technology for Conversational Inferencing and Interactive Natural Language Generation”, filed Feb. 15, 2019), Ser. No. 16/277,004 (entitled “Applied Artificial Intelligence Technology for Contextualizing Words to a Knowledge Base Using Natural Language Processing”, filed Feb. 15, 2019), Ser. No. 16/277,006 (entitled “Applied Artificial Intelligence Technology for Conversational Inferencing Using Named Entity Reduction”, filed Feb. 15, 2019), and Ser. No. 16/277,008 (entitled “Applied Artificial Intelligence Technology for Building a Knowledge Base Using Natural Language Processing”, filed Feb. 15, 2019); the entire disclosures of each of which are incorporated herein by reference. As explained in the above-referenced and incorporated Ser. No. 16/183,230 patent application, the NLG system 108 can employ a conditional outcome framework to determine the ideas that should be expressed in the narrative that is produced in response to the parameterized communication goal statement. Once the ideas have been generated by the conditional outcome framework of the NLG system 108, the NLG system can then form these ideas into a narrative using the techniques described in the above-referenced and incorporated Ser. No. 16/183,230 patent application to generate the natural language output. Through the training techniques discussed herein, this natural language output will stylistically resemble the training data by including one or more expressions that are derived from the linguistic features detected in and extracted from the training data.

I. Linguistic Features

FIG. 3 depicts an example architecture for implementing systems 202 and 204 within the training system 106. A variety of different pattern matchers can be employed to detect and extract linguistic features from the training data 126. These pattern matchers can be implemented in software code within the training system 106. In an example embodiment, the pattern matchers can employ regular expression (RegEx) pattern matching where regular expressions are used to define the patterns sought via the matching process. In example embodiments, the training system 106 can include numeric style pattern matchers 300, date and number pattern matchers 310, ontological vocabulary pattern matchers 320, and concept expressions pattern matchers 330. Examples of each of these will be discussed below. The linguistic features detected and extracted via the pattern matchers can then be aggregated into a specification data structure 370.

I(A). Numeric Styles

The numeric styles class of linguistic features is concerned with how numeric values are rendered in text. Numeric style pattern matchers 300 can detect and extract different aspects of numeric style expressed by numbers within the training data. The pattern matchers within 300 (examples of which are discussed below) can use regular expressions to define the generalized patterns sought within the training data 126 so that specific instances of the patterns can be recognized. Each pattern matcher can be run against the full text of each document within the training data 126, and the constituents of each match can be captured for aggregation into the specification data structure 370.

One or more decision precision pattern matchers 302 can be configured to determine the number of digits contained in the fractional part of a number written in decimal form. For example, the number “5.5” exhibits a single digit of decimal precision, while the number “5.539” exhibits 3 digits of decimal precision. Regular expressions can be employed to detect numbers written in decimal form, and then associated logic can be used to count how many digits are to the right of the decimal.

One or more decimal separator pattern matchers 304 can be configured to determine the character that is used by a number string to separate the integer part of the number from the fractional part of the number. For example, often times a period “.” is used to denote the decimal in a number, but sometimes other characters are used, such as a comma “,”. Regular expressions can be employed to detect numbers written in decimal form, and then associated logic can be used to determine the character being used to separate the integer and fractional portions. For example, the decimal separator pattern matcher 304 can return a period as the decimal separator if the input number is “305.59”, and it can return a comma as the decimal separator if the input number is “305,59”.

One or more digit grouping delimiter pattern matchers 306 can be configured to determine the character that is used by a number string to divide groups of integers in large integers that represent values over 1000. For example, often times a comma “,” is used to separate rightmost groupings of 3 digits in an integer, but sometimes other characters are used, such as a period “.” or white space. Regular expressions can be employed to detect the presence of large integers that represent values over 1000, and then associated logic can be used to determine the character being used to separate the integer portions in groups of 3 digits starting from the rightmost integer digit. For example, the digit grouping delimiter pattern matcher 306 can return a comma as the digit grouping delimiter if the input number is “30,000”; it can return a period as the digit grouping delimiter if the input number is “30.000”; and it can return white space as the digit grouping delimiter if the input number is “30 000”. Disambiguation techniques can be applied to distinguish between numbers that may be ambiguous as to whether they are large integers or small integers with a fractional component following a decimal. As an example, if the decimal separator character is unknown, then the number “5,536” could be interpreted as five thousand five hundred thirty six (if the decimal separator is a period) or it could be interpreted as five point five three six (if the decimal separator is a comma). Possible disambiguation options can include resolving decimal separation and digit grouping hierarchically (e.g., excluding a character found to be a decimal separator from consideration as a digit grouping delimiter), or flagging ambiguous cases for resolution via user input, etc.

One or more currency symbol pattern matchers 308 can be configured to determine the character that is used as a currency symbol within a string that expresses a currency value. Regular expressions can be employed to detect the currency values, and then associated logic can return the character used as the currency symbol (e.g., $, ¥, €, etc.).

I(B). Date and Number Expressions

The date and numbers class of linguistic features is concerned with the form of how numbers are dates are expressed in text. Date and number pattern matchers 310 can detect and extract different aspects of the formats for dates and numbers within the training data. The pattern matchers within 310 (examples of which are discussed below) can use regular expressions to define the generalized patterns sought within the training data 126 so that specific instances of the patterns can be recognized. Each pattern matcher can be run against the full text of each document within the training data 126, and the constituents of each match can be captured for aggregation into the specification data structure 370.

One or more day expressions pattern matchers 312 can be configured to determine the textual form in which days of the year are expressed (e.g., “Monday, Jan. 13, 2018”, “01/13/2018”, “13/01/2018”, “Jan. 13, 2018”, etc.). Regular expressions can be employed to detect which of a set of possible day expression patterns are present within the training data.

One or more month expressions pattern matchers 314 can be configured to determine the textual form in which months of the year are expressed (e.g., “January 2018”, “Jan. 2018”, “01/2018”, etc.). Regular expressions can be employed to detect which of a set of possible month expression patterns are present within the training data.

One or more currency expressions pattern matchers 316 can be configured to determine the textual form in which currency values are expressed (e.g., “$20”, “20 USD”, “20 US Dollars”, etc.). Regular expressions can be employed to detect which of a set of possible currency expression patterns are present within the training data.

One or more numeric expressions pattern matchers 318 can be configured to determine the textual form in which integer and decimal values are expressed (e.g., “Three Thousand Eighteen”, “3018”, etc.). Regular expressions can be employed to detect which of a set of possible numeric expression patterns are present within the training data.

I(C). Ontological Vocabulary

The ontological vocabulary class of linguistic features is concerned with the words used to represent ontological entities and relationships within the training data. Different information domains might refer to the same notional entity using different lexicons (e.g., Company A might refer to sales personnel as “salespeople” while Company B might refer to sales personnel as “sales associates”). The ontological vocabulary pattern matchers 320 can use data accessible to the underlying NLG system (e.g., supporting data 110) to automatically detect ontologically-significant words, particularly nouns and verbs. For example, the ontological vocabulary pattern matchers 320 can leverage an ontology used by the NLG system 108, which can contain a rich ontology that may include human-readable labels and linguistic expression forms that span one or more domains. Other data sources that can be tapped can include data sources that contain named instances of ontological entities, as well as name attribute values related to known entities. Although specific named instances may not have any relevance to vocabulary features and NLG expressions, they can help disambiguate relationship and/or attribute words. Such data sources can be used to build a text search index that maps specific words back to their corresponding ontological entities, where the text search index is for use by the ontological vocabulary pattern matchers 320. The system can build the index by traversing all nodes in the ontology as well as all fields in the underlying data sources via a data access layer for the training system 106.

As an example, consider the following ontology:

Entity: salesperson

Expressions: salesperson, account executive

Entity: sale

Expressions: sale, transaction, auction

Relationship: sells

Participating Entities: salesperson, sale

Expressions: sells, achieves, earns

As well as the following dataset, in tabular form:

	salesperson	sales	region	year
	Aaron Young	50000	East	2018
	Daisy Bailey	51000	West	2018

Once the data above is loaded into the system, the ontological vocabulary pattern matchers 320 can extract vocabulary features and infer preferences from any of the following examples of unstructured text:“In 2018, the top account executive was Tom Reynolds, with a total of 56,000”.

Identified: “account executive”

Result: Express salesperson entities as “account executive”

“In 2018, Aaron Young achieved 50,000 transactions”

Identified: “Aaron Young”, “achieved”, “transactions”

Result: Express relationship of sales+salespeople as “achieve”

FIG. 4A discloses an example process flow for performing ontological vocabulary pattern matching. As used herein, the term “named entity” refers to any ontological or data atom that the NLP system 106 recognizes in training data. As such, it should be understood that the term named entity refers to more than just the entities that are described as part of an ontology 410 within the supporting data 110. Examples of different types of named entities can include entity types (e.g., salesperson), entity instances (e.g., John, who is an instance of a salesperson), attributes (e.g., sales, which are an attribute of a salesperson), attribute values, timeframes, relationship types, relationships, qualifiers, outcomes, entity bindings, and predicate bindings.

At step 400 of FIG. 4A, the system builds a tree structure that can be used for recognizing named entities in the training data (e.g., the sentences of a training document or other training input), for example a prefix tree. This tree can pull information from the knowledge base such as the sources shown in FIG. 4A, which may include an ontology 410, project data 412, linguistic/deictic context 414, and general knowledge 416.

The ontology 410 can be the ontology for a data set addressed by the message, an example of such an ontology is described in the above-referenced and incorporated Ser. No. 16/183,230 patent application.

The project data 412 represents the data set that serves as a project-specific knowledge base. For example, the project data 412 can be the sales data for the salespeople of a company. Thus, the project data 412 may include a number of entity instances and attribute values for the entity types and attributes of the ontology 410.

The deictic context 414 can be a data structure that maps referring terms such as pronouns and demonstratives in the training data to specific named entities in the supporting data 110. This linguistic/deictic context can help the system know how to map referring terms such as pronouns that are mentioned in the training data to specific entities that are mentioned in the training data. An example of technology that can be used to build such a linguistic/deictic context is described in (1) U.S. patent application 62/612,820, filed Jan. 2, 2018, and entitled “Context Saliency-Based Deictic Parser for Natural Language Generation and Natural Language Processing”, (2) U.S. patent application Ser. No. 16/233,746, filed Dec. 27, 2018, and entitled “Context Saliency-Based Deictic Parser for Natural Language Generation”, and (3) U.S. patent application Ser. No. 16/233,776, filed Dec. 27, 2018, and entitled “Context Saliency-Based Deictic Parser for Natural Language Processing”, the entire disclosures of each of which are incorporated herein by reference.

The general knowledge 416 can be a data structure that identifies the words that people commonly use to describe data and timeframes (e.g., “highest”, etc.).

Step 400 can operate to read through these data sources and extract each unique instance of a named entity that is found to be present in the data sources, and build the prefix tree that allows the system to later recognize these named entities in the words of the training data and then map those named entities to elements in the ontology 410, project data 412, deictic context 414, and/or general knowledge that are understood by the system. Also, if desired by a practitioner, it should be understood that step 400 can be performed as a pre-processing step that happens before any training data is received by the NLP training system 106.

FIG. 4B shows a simple example of a prefix tree that can be built as a result of step 400. It should be understood that for many projects, the prefix tree would be much larger. In this example, it can be seen that the name “Aaron Young” was found in the knowledge base of data sources as an entity instance, the word “generate” was found in the knowledge base of data sources as an attribute of sales value, the pronoun “he” was found to be contextually relevant to the entity instance of Aaron Young, and so on for other named entities as shown by FIG. 4B. Given that the ontology 410 may include a variety of different expressions for ontological elements (as described in the above-referenced and incorporated Ser. No. 16/183,230 patent application), it should be understood that the prefix tree can be highly robust at recognizing the meaning of a large number of words within the context of a training data set. For example, expressions such as “sales”, “sells”, “deals”, “moves”, “transactions”, etc. can be linked to an attribute such as the sales of a salesperson to allow the system to recognize a wide variety of words in training data that relates to sales data. In general, it can be expected that (1) nouns will often map to entity types, entity instances, characterizations, attributes, and qualifiers, (2) verbs will often map to attributes and relationships, (3) adjectives will often map to qualifiers and characterizations, and (4) prepositions will often map to relationships; however this need not always be the case and will depend on the nature of the data sources accessed by step 400.

Then, step 402 maps words in the training data to named entities in the prefix tree. Thus, if the word “Aaron” appears in the training data, this can be recognized and mapped via the prefix tree to the entity instance of Aaron Young, and if the word “generate” appears in the training data, this can be recognized and mapped via the prefix tree to the attribute of sales value.

I(D). Concept Expressions

The concept expressions class of linguistic features is concerned with the sequence of words or phrases used in the training data to express NLG concepts. Concept expressions pattern matchers 330 can be used to infer the high level concepts that are expressed in the training data, and they thus represent a particularly powerful and innovative aspect that can be employed in example embodiments of training system 106. Examples of concepts that can be detected by pattern matchers 330 include:

• • Change: An example of a sentence that expresses a change concept is “Imports of steel fell sharply in 2018, down 43% from the previous year.”
  • Compare: An example of a sentence that expresses a compare concept is “Imports of steel were lower in 2018 than the previous year.”
  • Driver: An example of a sentence that expresses a driver concept is “New tariffs contributed to the decrease in steel imports.”
  • Rank: An example of a sentence that expresses a rank concept is “The top 3 steel exporters by volume are China, Russia, and India.”The concept expressions pattern matchers 330 can use metadata derived from NLP tools and a series of rule-based heuristics to identify candidates for concept expressions, ultimately producing an annotated template that can be structurally compatible with the NLG system 108.

The system can be configured to assume that all concept expressions contain an anchor word, a single or compound word that is globally unique to a particular concept. The system can then use occurrences of these anchor words to identify candidate phrases for template extraction. Examples of specific anchor words for several concepts are listed below.

For example, one or more change concept pattern matchers 332 can be configured to detect the presence of any of the following anchor words in a training sentence. Upon detection of one of these anchor words, the subject training sentence can be categorized as a candidate for a change expression and get passed to template extraction logic 350 (discussed below).

Examples of anchor words for a change concept can include:

• • increase
  • reduction
  • decrease
  • decline
  • rise
  • fall
  • raise
  • lower
  • lift
  • drop
  • grow
  • shrink
  • gain
  • lose
  • up
  • down
  • improve
  • worsen
  • slump
  • upturn
  • downturn
  • gains
  • losses

As another example, one or more compare concept pattern matchers 334 can be configured to detect the presence of any of the following anchor words in a training sentence. Upon detection of one of these anchor words, the subject training sentence can be categorized as a candidate for a compare expression and get passed to template extraction logic 350 (discussed below). Examples of anchor words for a compare concept can include:

• • more
  • less
  • fewer
  • greater
  • lesser
  • higher
  • lower
  • superior
  • inferior
  • exceed

As another example, one or more driver concept pattern matchers 336 can be configured to detect the presence of any of the following anchor words in a training sentence. Upon detection of one of these anchor words, the subject training sentence can be categorized as a candidate for a driver expression and get passed to template extraction logic 350 (discussed below). Examples of anchor words for a driver concept can include:

• • drive
  • detract
  • contribute
  • aid
  • counteract
  • help
  • hurt
  • impact

As another example, one or more rank concept pattern matchers 338 can be configured to detect the presence of any of the following anchor words in a training sentence. Upon detection of one of these anchor words, the subject training sentence can be categorized as a candidate for a rank expression and get passed to template extraction logic 350 (discussed below). Examples of anchor words for a rank concept can include:

• • best
  • worst
  • top
  • bottom
  • top most
  • bottom most
  • top ranked
  • bottom ranked
  • largest
  • smallestHowever, it should be understood that more, fewer, and/or different anchor words can be used for detecting these concept candidates. For example, a thesaurus could be used to find appropriate synonyms for each of these anchor words to further expand the pools of “change”, “compare”, “driver”, and “rank” anchor words.

Furthermore, while the examples discussed herein describe “change”, “compare”, “driver”, and “rank” concepts, it should be understood that a practitioner may choose to detect other concepts that could be present within training data. For example, any of “peaks and troughs” concepts, “volatility” concepts, “correlation” concepts, “prediction” concepts, “distribution” concepts, and others can also be detected using the techniques described herein. Following below are some additional examples of concepts that can be expressed in sentences and for which concept expression templates could be extracted using the techniques described herein:

• • “Actual versus Benchmark” Concept: “The best period was Oct. when Total Likes outperformed Fan Acquisition Target Goal by 7.537.”
  • “Compound Annual Growth Rate” (CAGR) Concept: “If that growth rate were to continue, Sale Volume is forecast to be $7.34 billion by 2022.”
  • “Clusters” Concept: “When organized into groups of similar Stadiums and Capacity values, one distinct group stands out. There were 28 entities that had values of Stadiums between three and 17 and Capacity between zero and 165,910.”
  • “Concentration” Concept: “Crime Count is relatively concentrated with 60% of the total represented by 35 of the 161 entities (22%).”
  • “Correlation” Concept: “Profit and revenue had a strong positive correlation, suggesting that as one (profit) increases, so does the other (revenue), or vice versa.”
  • “Current versus Previous” Concept: “Compared to the previous year, the average across all months decreased from $92.7 million to $84.2 million.”
  • “Cyclicity” Concept: “Sale Volume experienced cyclicality, repeating each cycle about every 8.2 years.”
  • “Distribution” Concept: “The distribution is negatively skewed as the average of 4.2 million is greater than the median of 4.2 million.”
  • “Intersection” Concept: “Total Quantity was lower than Total Revenue for the first 6% of the series, but at 02/2010 Total Quantity increased above Total Revenue and remained higher for the last 94% of the series.”
  • “Min Max” Concept: “Values ranged from 54% (Easy System Chat) to 118% (Phone).”
  • “Outliers” Concept: “PASSAT and JETTA were exceptions with very high Miles Per Gallon values.”
  • “Percentage of Whole” Concept: “Over the course of the series, Honduras accounted for 15% of top keyword totals, election accounted for 9.92%, and president accounted for 8.74%.”
  • “Peak/Trough” Concept: “Total Sales had a significant dip between Feb-2013 ($7,125) and May-2013 ($7,417), falling to $5,430 in Mar-2013.”
  • “Segments” Concept: “Total Contacts Completed fluctuated over the course of the series with 60% of data points moving in an opposite direction from the previous point.”
  • “Streak” Concept: “The largest net growth was from August 2017 to December 2017, when Variable (Line) increased by 36 percentage points.”

Further still, while a single anchor word is used to assign a candidate concept classification to training sentences in the example embodiment discussed above, it should be understood that a practitioner could also use an anchor word in combination with additional metadata (such as part of speech tagging) or a combination of anchor words to infer concepts from training sentences. For example, a practitioner may conclude that the word “fewer” could be indicative of both a “change” concept and a “compare” concept, and additional words and/or rules could be used to further resolve which classification should be applied to the subject training sentence. As another example, the detection of a rank concept when the word “top” is present in the training data can be made dependent on whether “top” is being used in the subject sentence as an adjective (in which case the rank candidacy can get triggered) or as a noun (in which case the rank candidacy may not get triggered).

Once candidate phrases have been identified via the anchor word detection, the candidate phrases are then parsed and evaluated by template extraction logic 350 before producing a concept expression template. The template creation process can employ a sequence of rule-based heuristics, examples of which are discussed below. For example, FIG. 5 discloses an example process flow for template extraction. For purposes of elaboration, this FIG. 5 process flow will be discussed in the context of the following unstructured text that expresses a change concept:

• • “The United States division experienced a large drop in sales in June 2017 compared to the previous year, which prompted this meeting.”With this example, the change concept pattern matcher 332 will detect the anchor word “drop” in the training sentence, and the template extraction logic 350 will attempt to extract a change expression template from this training sentence.

At step 500, a processor performs constituency parsing and dependency parsing on the training sentence to create a parse tree structure. Additional details for example embodiments of constituency parsing and dependency parsing are discussed below. FIG. 6A shows an example parse tree structure that can be generated at step 500 from the example sentence above. In this example, the parse tree structure corresponds to the constituency parse tree.

At step 502, a processor identifies entities in the parse tree structure based on data sources such as an ontology. This step can be performed using named entity recognition (NER) techniques, and an example of an NER technique that can be performed on the parse tree structure of FIG. 6A is discussed above with respect to FIG. 4A. However, the NER of step 502 need not draw from the ontology 410 used by NLG system 108; instead the ontology used by the NER of step 502 can use existing ontologies that are available in combination with parsing tools that can be used at step 500. Entities that can be identified at step 502 (even if ontology 410 is not used) can include organizations, person names, dates, currencies, etc. With respect to the leaf nodes of the parse tree structure example of FIG. 6A, step 502 can recognize the following entities:

• • United States
  • June 2017
  • previous year

At step 504, a processor prunes clauses in the parse tree structure by removing clauses or phrases from the parse tree structure that do not contain relevant identified entities. For the parse tree structure of FIG. 6A, step 504 will operate to remove the right-most subordinate clause (SBAR) (“which prompted this meeting”) because this clause does not contain any entities identified at step 502. FIG. 6B shows the example parse tree structure after the pruning of step 504 has been performed.

At step 506, a processor collapses branches of the pruned parse tree structure based on relationships with identified entities. For example, step 506 can discard sibling tree nodes of any branches with known entities or attributes. With reference to the pruned parse tree structure of FIG. 6B, step 506 can operate to discard the siblings of “United States”, “June 2017”, and “the previous year” within the tree structure. FIG. 6C shows the parse tree structure after step 506 has been performed to make these removals.

At step 508, a processor parameterizes the collapsed parse tree structure to yield an NLG-compatible concept expression template. The NLG-compatible concept expression template can include semantically-significant variable slots. With respect to the running example, the following transformations can occur as part of step 508:

• • “United States” (GPE)→“ENTITY_0” (NN)—by virtue of recognition of the words “United States” as an entity.
  • “a large drop”→ANCHOR_0—by virtue of recognition of the word “drop” as an anchor word
  • “Sales” (ATTR)→ATTR_0 (NN)—by virtue of recognition of the word “sales” as being an attribute in ontology 410
  • “June 2017” (DATE)→DATE_0 (NN)—by virtue of recognition of this string as referring to a date
  • “the previous year” (DATE)→DATE_1 (NN)—by virtue of recognition of this string as referring to a dateFIG. 6D shows the parameterized parse tree structure that can be produced by step 508. Also, the parameterization step 508 can include concept-specific rules. For example, the parameterization of a change concept can look for numeric values and then separately parameterize “from” and “to” values in a change expression. FIG. 6E shows an example process flow for transforming and/or tagging tokens in a parse tree with NLG-compatible labels.

FIG. 7 shows an end-to-end process flow for extracting concept expression templates from training data for another example embodiment. This process flow can include the following:

• • 1. Tokenizing a document into sentences
  • 2. For each sentence:
    • a. Pre-processing with a suite of NLP techniques (dependency and constituency parsing, named entity recognition)
    • b. Leveraging a user's′ data and the NLG system's ontology to identify and flag known resources (entities, attributes)
  • 3. For each pre-processed sentence:
    • a. Passing the sentence through a separate pattern matcher for each concept supported by the NLG system
    • b. For each template extractor triggered by its associated pattern matcher, applying a set of heuristics to extract the relevant subtree from the parsed sentence and parameterize the sentence into a form compatible with the NLG system.Through this process, a raw sentence like “The United States saw a $5000 increase in sales in the cycle ending in February.” can be converted to a parameterized template of the form “$ENTITY_0 see $BY-VALUE_0 ANCHOR_0 in $ATTR_0 in $DATE_0” that can be used by the NLG system 108 to generate new sentences of a similar form. The following sections will now describe details about various aspects of the FIG. 7 embodiment.

Sentence Pre-Processing

Given an input document, the training system can first use a sentence tokenizer to split the document into sentences that are then passed on for further processing. An example of a sentence that can produced by the tokenizer is:

• • “The United States saw a $5000 increase in sales in the cycle ending in February.”

Each sentence is then passed through two NLP tools—one for constituency parsing and one for dependency parsing. An example of a tool that can be used for constituency parsing is Stanford's CoreNLP. CoreNLP can be used to generate a constituency tree for the sentence. An example of a tool that can be used for dependency parsing is Explosion AI's Spacy. Spacy can be used to generate a dependency parse and part-of-speech tags, and it can also perform named entity recognition (NER). This NER is an NLP practice that uses static dictionaries and heuristics (e.g. capitalization) to recognize and flag person names (“Aaron Young”), geopolitical entities (“United States”), dates (“February”), etc. FIG. 8A shows a basic constituency tree produced as a result of sentence pre-processing. While CoreNLP and Spacy are used for the constituency parsing and dependency parsing in an example embodiment, it should be understood that other tools can be used for these parsing operations. For example, Microsoft Azure's linguistics API may be used for constituency parsing, and tools such as CoreNLP and Google's cloud NLP tools can be used for dependency parsing if desired by a practitioner.

The system can perform both a dependency and constituency parse because they serve unique roles in the template extraction process. The dependency parse is useful for determining the linguistic roles and relationships of different tokens in the sentence (e.g. determining the preposition associated with a given numeric value, or which verb has a recognized attribute as its object). The constituency tree, on the other hand, is important for building a tree structure compatible with the NLG system 108.

The system next applies a known resource extraction process such as the one described in connection with FIG. 4A. The known resource extraction process flags tokens that are recognized as corresponding to known entities or attributes of entities. These known entities and attributes come from two sources:

• • a. The NLG system's ontology—as noted above, the ontology utilized by the NLG system can have a library of known entities, attributes, and relationships, and the extraction logic can scan sentences for any instances of tokens matching these known ontological entities. For example, “sales” is recognized concept in our ontology, so is tagged as an attribute.
  • b. User data—if a user has uploaded data or has linked the system to a database, the extraction logic can also recognize string data values in a sentence as entities or attributes. For example, if a user has a data representing product names, the known resource extractor would recognize (and thus be able to parameterize downstream) that “Gizmotron 5000” is an entity in the sentence “The best selling product was the Gizmotron 5000”, even though that term does not appear in the NLG system ontology, nor could be recognized by a standard NER.

The NLP results, extracted known resources, and raw sentence string for each sentence are set as a metadata on a node object that is passed to the template pattern matchers for further processing.

Pattern Matching to Identify Sentences Expressing a Concept

For all concepts expressible by the NLG system (e.g., “change”, “comparison”, “rank”, etc.), the training system can implement a separate pattern matcher used to identify sentences expressing that concept, as noted above in connection with FIG. 3. As previously discussed, the pattern matchers can be implemented using “anchor words”, and the system can maintain a dictionary of anchor words, stored as tuples of (positive, negative) pairs, along with part of speech. For example, a subset of anchor words for the “change” concept can include:

• • (‘increase’, Noun), (‘decrease’, Noun),
  • (‘increase’, Verb), (‘decrease’, Verb),
  • (‘grow’, Verb), (‘shrink’, Verb),
  • (‘gains’, ‘Noun’), (‘losses’, ‘Noun’),While tuples can be used in an example embodiment, it should be understood that other combinations could be employed to store representations of the anchor words. For example, the anchor word representations can be expanded to be triples where an additional item captures “change” relations (e.g., more, less, equal).

The “rank” concept includes “top”, “bottommost”, and “best”; the “compare” concept includes “more”, “less”; etc.

The training system thus implements a pattern matcher for each supported concept that scans the processed sentences, and is triggered any time it recognizes an anchor word/part-of-speech pair associated with the concept. Each processed sentence is passed through pattern matchers, and for each that is triggered the training system initiates the template extraction process.

Template Extraction

When the pattern matcher for a given concept is triggered, the training system attempts to templatize the triggering sentence. This involves the following steps:

1. Token Generation and Substitution

As mentioned above, each sentence is processed with both CoreNLP (for the constituency tree) and Spacy (for NER, dependencies, etc.). The first step of template extraction is to integrate the constituency tree with the Spacy token objects, replacing the leaves of the CoreNLP constituency tree with Spacy tokens and their associated metadata. For any recognized named entities (e.g. “United States” and “February” in this example), we collapse all words making up the named entity into a single leaf in the tree. FIG. 8B shows an example parse tree after this step (where “United States” and “February” are underlined to illustrate their status as recognized named entities.

2. Subtree Extraction

The next step is to extract from the complete parse tree the subtree expressing the identified concept. The default approach for this this is to move up the tree from the anchor word to the complete clause containing the anchor word. In the example of FIG. 8C, where “increased” is the anchor word, the system moves up the tree to the independent clause “whose sales increased by $7000 this quarter”, and the rest of the sentence is discarded (see FIG. 8C). This amounts to selecting the underlined portion of the parse tree shown by FIG. 8D:

This logic can be overridden for particular template extractors as appropriate. For example, the “rank” concept extractor can be designed to move up the tree to the topmost containing noun phrase (see the underlined portion in the example of FIG. 8E).

3. Clause Pruning

The training system then eliminates any clauses from the sentence that do not contain an anchor word or any known resources. In the example of FIG. 8F, this means dropping the clause “who was recently promoted” because it does mention a known resource or the anchor word (“more”). This amounts to dropping the crossed out elements in the example parse tree of FIG. 8G.

4. Known Resource/Entity Branch Collapsing

The next step is to collapse any branches containing known entity or attribute tokens (this includes both known resources extracted from the ontology or user data, or other entities recognized by NER during the initial Spacy pre-processing of the sentence). To accomplish this, the system moves up the tree from each recognized token to the highest containing noun phrase (NP) that that does not also contain an anchor word or another recognized token. For example, the initial NP (“The United States”) is collapsed to a single NP containing only the token for “United States”. The system does not collapse the NP containing “sales” beyond the bolded subtree in the example below, because the next highest NP (“a $5000 increase in sales in February”) contains an anchor word (“increase) as well as another entity (“February”). If instead the sentence had referenced “average weekly sales”, then that NP would have been collapsed to a single token NP including only “sales”. FIG. 8H shows the example parse tree after the collapsing operation is performed.

5. Parameterization

The final step is to parameterize the sentence into an abstracted form usable by the NLG system. For the template extractors, this involves replacing tokens for attributes, entities, and dates with enumerated variables (ENTITY_0, ENTITY_1, etc.). A second pass handles parameterization of concept-specific elements (in the example for “change” below, the system parameterizes the “BY-VALUE”, and could do the same for the “TO” and “FROM” values if present). The system can also parameterize the anchor word, which allows for use of the template in NLG systems with synonyms for the anchor word (e.g. “ . . . saw a dip in sales . . . ”) or its opposite (“ . . . saw a decrease in sales . . . ”). FIG. 8I shows an example parameterization of the running parse tree example. This template can then be passed directly to the NLG system, which maps the variables in the template to runtime NLG objects to generate new sentences.

Notes on Template Validation

To ensure that generated templates are syntactically and semantically valid, the system can apply multiple passes of validation throughout the parsing and templatization process. If any of these fail, the system can raise an error when processing a sentence.

• • 1. Constituency and dependency parsing is not a 100% accurate process (often due to sentence ambiguity, e.g., for the sentence “Enraged cow injures farmer with ax”, who has the ax?), so a first validation check ensures that the dependency parse and constituency parse agree with respect to part-of-speech tags.
  • 2. Each template extractor implements a custom parameter validation pass, which can ensure the set of parameterized sentence elements is valid for a given concept. For example, the “compare” concept can be designed so that it is required to contain either two entities or two attributes.
  • 3. A final validation pass performs a syntactic validity check (e.g. does the sentence contain a proper subject and object) and an NLG compatibility check (ensuring that the final tree structure is consistent with the format expected by out NLG system.II. Specification Data Structures

As noted above, the result of the extraction and aggregation phases is a specification data structure (such as a JSON specification), which is a machine-readable, declarative description of the linguistic features that the training system discovered. Each top-level key in the specification data structure can be a specific linguistic feature, whose value is a list of feature instances, grouped by their generalized form and sorted by frequency. Each list item contains a “count” value to indicate the number of times that generalized form was encountered. Examples of each feature's data structure in an example JSON specification are discussed below.

For example, FIG. 9A shows a portion of a JSON specification for the decimal precision linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included relevant numeric values for the decimal precision feature, and the precision field identifies the value for the corresponding decimal precision. The FIG. 9A example also lists the relevant sentences in the training data for the decimal precision feature.

As another example, FIG. 9B shows a portion of a JSON specification for the decimal separator linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included relevant numeric values for the decimal separator feature, and the separator field identifies the character used as the decimal separator for the subject count. The FIG. 9B example also lists the relevant sentences in the training data for the decimal separator feature.

As another example, FIG. 9C shows a portion of a JSON specification for the digit grouping delimiter linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included relevant numeric values for the digit grouping delimiter feature, and the separator field identifies the character used as the digit grouping delimiter for the subject count. The FIG. 9C example also lists the relevant sentences in the training data for the digit grouping delimiter feature.

As another example, FIG. 9D shows a portion of a JSON specification for the currency symbol linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included relevant currency values for the currency symbol feature, and the symbol field identifies the character used as the currency symbol for the subject count. The FIG. 9D example also lists the relevant sentences in the training data for the currency symbol feature.

As yet another example, FIG. 9E shows a portion of a JSON specification for the day expression linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included relevant day expressions. Each feature instance contains the generalized format string used by programming languages to convert a date into a string (see “format_str” and “strftime” in FIG. 9E). The FIG. 9E example also lists the relevant sentences in the training data for the day expression feature.

As yet another example, FIG. 9F shows a portion of a JSON specification for the month expression linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included relevant month expressions. Each feature instance contains the generalized format string used by programming languages to convert a month into a string (see “format_str” and “strftime” in FIG. 9F). The FIG. 9F example also lists the relevant sentences in the training data for the month expression feature.

As yet another example, FIG. 9G shows a portion of a JSON specification for the currency expression linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included relevant currency expressions. Each feature instance contains several Boolean flags which describe various properties of the subject expression. The aggregation of these Boolean values can then be used to define the specific currency expression that was detected in the training data. The FIG. 9G example also lists the relevant sentences in the training data for the currency expression feature.

As yet another example, FIG. 9H shows a portion of a JSON specification for the numeric expression linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included relevant numeric expressions. Each feature instance contains several Boolean flags which describe various properties of the subject expression (see the “format” portions of FIG. 9H). The aggregation of these Boolean values can then be used to define the specific numeric expression that was detected in the training data. The FIG. 9H example also lists the relevant sentences in the training data for the numeric expression feature.

As still another example, FIG. 9I shows a portion of a JSON specification for the ontological vocabulary linguistic feature discussed above. The count field identifies a count of the sentences in the training data that included a relevant ontological element as identified by the “expression” field, and different counts can be included for each ontological element found in the training data. Each feature instance contains a type (“object_type”), an ID reference (“object_ID”) and an object label (“object_label”) for its corresponding ontological node in the NLG system 108. The FIG. 9I example also lists the relevant sentences in the training data for subject ontological element.

As still another example, FIG. 9J shows a portion of a JSON specification for the concept expression feature discussed above. The count field identifies a count of the sentences in the training data that included a relevant concept as identified by the “concept” field, and different counts can be included for each concept found in the training data. Each concept instance can contain a representation (such as an ASCII representation) of the template data structure as well as the values corresponding to the template's parameters. Further still, each concept instance can identify the phrases and anchor words that were found to be matches to a concept within the training data. The FIG. 9J example also lists the relevant sentences in the training data for subject concept expression.

Furthermore, it should be understood that if multiple different instances of a detected linguistic feature are detected in the training data, the JSON specification can include a separate entry for each instance. The system can then choose which instance should be used for training the NLG system based on heuristics (e.g., choosing the most common instance to train) or based on user input (e.g., presenting the instances to a user as selectable options and then training the NLG system based on the user-selected instance). For example, with reference to FIG. 9A, if multiple decimal precisions were found in the training data, the JSON specification can separately identify each instance along with the count for those instances. Thus, if there were also 6 numbers in the training data where the decimal precision was 3 digits, there could be another entry in the JSON specification corresponding to this instance. The training process could then apply the most common instance (e.g., the decimal precision of 3 digits in this example) based on automated heuristics or rely on user input to decide which instance should be used for training.

III. User Interfaces

As noted above with reference to step 206, user interfaces can be provided to help a user control and review aspects of the training process. For example, a browser application can provide a user with interfaces for creating a document corpus, extracting features, and applying configuration changes to the NLG system 108.

FIG. 10A shows an example GUI for document upload to provide the training system 106 with training data. This GUI can also specify a data scenario in response to user input, wherein the specified data scenario can be a domain-specific data set such as project data used by the NLG system 108. Such a data scenario may include an ontology and project data used by the training system and the NLG system as a knowledge base. This data scenario can also define the configuration that is to be modified based on the specification data structure extracted by the training system (and possibly modified via the user interfaces).

FIG. 10B shows an example GUI that allows a user to view and select concept expression templates that were detected within the training data. Each detected concept expression template can be separately listed in the GUI, and the listing can be accompanied by information that identifies the concept type (e.g., “change” in the example of FIG. 10B) as well as an example of one of the sentences in the training data from which the concept expression template was extracted. Further still, the GUI can show the prevalence of each concept expression template within the training data (which, for the example of FIG. 10B, was 30% for the first listed template and 7% for the second listed template). Each listing in the example of FIG. 10B serves as a model for describing change that can be used by the NLG system 108, and each listing can be selectable via a checkbox or the like to control whether that concept expression template is to be added to the NLG system 108 as a configuration and preferred over default expressions. The “More sentences” link can be selected if the user wants to review additional training sentences from which the subject concept expression template was extracted. The “Show template parse tree” link can be selected to show the corresponding parse tree for the subject concept expression template (see FIG. 10C).

The GUI of FIG. 10B can also summarize the different concept expression templates that were extracted from the training data. For example, the GUI of FIG. 10B shows that 10 concept expression templates were found in the training data, of which 4 were change expressions, 1 one a compare expression, 2 were driver expressions, etc.

In a particularly powerful aspect of an example embodiment, the GUI of FIG. 10B can be used to create custom templates in response to user input (see, e.g. the “+Custom Template” button). Upon selection of this button, the GUI can include a text entry field through which the user can enter a sentence. The training system can then process this sentence to extract a concept expression template from it. The extracted concept expression template can then be presented to the user via the GUI of FIG. 10B. This feature allows for users to create concept expression templates for use by the NLG system “on the fly”. FIG. 10G discussed below further elaborates on customized template creation.

FIG. 10D shows an example GUI that allows a user to view and select the ontological vocabulary that was detected within the training data. Each detected item of ontological vocabulary can be separately listed in the GUI, and the listing can be accompanied by information that identifies the ontological object type (e.g., entity, type, attribute, etc.) as well as an example of one of the sentences in the training data from which the item of ontological vocabulary was extracted. Further still, the GUI can show the prevalence of each item of ontological vocabulary within the training data (which, for the example of FIG. 10B, was 41% for “region” and 17% for “income”). Each listing in the example of FIG. 10B can be selectable via a checkbox or the like to control whether that item of vocabulary is to be added to the NLG system 108 as a configuration and preferred over default expressions. Thus, if “region” is selected via the GUI of FIG. 10D, the word “region” can be included as the preferred expression for the subject ontological element in the ontology used by the NLG system 108. The “More sentences” link can be selected if the user wants to review additional training sentences from which the subject item of ontological vocabulary was extracted (see FIG. 10E).

The GUI of FIG. 10D can also summarize the ontological vocabulary extracted from the training data. For example, the GUI of FIG. 10D shows that 8 vocabulary words were found in the training data, of which 3 were entity words, 4 were attribute words, and 1 was a relationship word.

FIG. 10F shows an example GUI that allows a user to view and select the numeric styles, dates, and number patterns that were detected within the training data via pattern matches 300 and 310. Each category of style item can be separately listed in the GUI, and the listing can include a drop down menu that identifies the specific pattern instances of each style identified within the training data. The user can then select which of these detected instances should be used with the configuration data. For example, the drop down menu can be accessed, and the desired instance can be selected via the drop down menu to control whether that pattern instance is to be added to the NLG system 108 as a configuration and preferred over default expression patterns.

The GUI of FIG. 10F can also summarize the different styles extracted from the training data. For example, the GUI of FIG. 10F shows that 6 total styles were found in the training data, of which 2 were decimal format styles, 2 were date format styles, and 2 were currency format styles.

FIG. 10G shows an example GUI for creating a custom concept template. Through this GUI, a user can teach the training system a new concept template based on natural language text input by the user. The concept section of the GUI can include a dropdown menu that lists the available concepts for the training system. The user can select which of these concepts is to be used for the custom concept template. The sample text section of the GUI can include a data entry field through which the user types a sentence in a natural language, where this sentence expresses the subject concept in a format that the user wants to add to the system. The anchor word section of the GUI can be a drop down menu that is populated with all of the words of the entered sentence. The user can then select from this word list which of the words is to be used as the anchor word for the subject concept. The anchor word direction section of the GUI allows the user to specify a frame of reference for directionality with respect to the subject anchor word. This can be specified via a user selection of an option of possible directions presented via a drop down menu or the like. Thus, for the change concept anchor word of “hindered”, the user input in the direction section can flag that the word “hindered” corresponds to a downward direction in the data. The opposite anchor word section can include a data entry field through which the user can enter the opposite/antonym of the subject anchor word. This opposite anchor word can also be added as an anchor word for the subject concept (in association with the opposite direction relative to the subject direction entered for the subject anchor word). The training system can then use the subject sentence data entered by the user to extract an appropriate concept expression template that can be presented to the user via the GUI of FIG. 10B.

FIG. 10H shows a sample narrative generated by NLG system 108 that has been adjusted based on the configurations applied by the training system 106. The left side of FIG. 10H shows a marked-up version of the narrative produced by the trained NLG and the right side of FIG. 10H shows a clean version of the narrative produced by the trained NLG. The marked-up version shows specific edits made to the narrative as a result of the training configuration e.g., where “July” and “April” were replaced by the stylistic variants “Jul.” and “Apr.” respectively, where the term “salespeople” was replaced by the stylistic variant “account executive”, etc.).

A parallel specification data structure can be created to capture the user decisions entered via the user interfaces around enabling/disabling the application of various extracted linguistic features from the training data. The parallel data structure which can be a parallel JSON specification can contain lists whose indexes match the original JSON specification's indexes, and each list item can be a JSON object with an “enabled” key. FIG. 11A shows an example JSON specification portion for ontological vocabulary. If the user uses the GUIs to enable the second word (“yield”), but not the first word (“income”), the parallel data structure of FIG. 11B will be produced to reflect these modifications entered via the user interface. The data structure of FIG. 11B can then be sent to an applicator alongside the original JSON specification of FIG. 11A for use programmatically during the configuration manipulation of the NLG system 108.

Also, the system 100 can expose an HTTP API that allows programmatic access to perform corpus creation, JSON specification retrieval, and platform application. This API can be used by the browser application. The endpoints and associated payloads can be described via cURL commands as reflected by FIGS. 12A and 12B. FIG. 12A shows commands for generating a specification from multiple files, where the specification is saved to a JSON file. FIG. 12B shows commands for using a specification in a JSON file to change the configuration for an NLG project.

IV. NLG Configuration/Instrumentation

The final phase of NLG training can employ a platform-specific applicator that takes the specification data structure (plus any user modifications as reflected in a parallel data structure) as an input and then updates the configuration for the NLG system 108 accordingly.

Each applicator can be responsible for defining the necessary business logic to manipulate the platform-specific configuration. It can also be responsible for initializing the necessary database/service/library connections to the platform in order to enact configuration changes. The applicator can then update the styling options for a narrative in the NLG system to reflect the extracted linguistic features for things such as date formats, number formats, etc. With respect to concept expression templates, the applicator can add them to the ontology 410 including as new expressions in the ontology 410 as appropriate (e.g., adding them as expressions to entity types, derived entity types, and/or relationships in the ontology 410 as may be appropriate). In another example embodiment, the concept expression templates can be loaded into or otherwise made available to the NLG AI (e.g., the NLG 530 shown in FIG. 5 of the above-referenced and incorporated Ser. No. 16/183,230 patent application).

An applicator iterates through feature instances for each top-level key in the JSON specification. Before applying changes, it checks the corresponding list in the user settings structure. If the user settings object in the corresponding list index position has an “enabled” key with a false value, the applicator will skip the current feature instance altogether and move on.

In an example, an applicator can process two items of input: (1) the JSON specification, and (2) an identifier for the project to be updated. The applicator then connects to the NLG system's configuration database using a configuration client library provided by the NLG system. This library can use the provided project ID to ensure that the appropriate project-specific configuration subset is accessible.

For each node in the list of vocabulary and concept features in the JSON specification, the applicator can perform the following:

• • 1. Use the node's identifier fields to retrieve the appropriate configuration object.
    • a. For vocabulary, the lookup will use the “object_type” and “object_id” fields.
    • b. For concepts, the lookup will use the “concept” field.
  • 2. Update the “parse_tree” field on configuration object with the contents of the node's “parse_tree” field.
  • 3. Save the updated configuration object back to configuration store.Thereafter, the next time a story is produced by the NLG system, it will load the updated configuration and express ontological entities and concepts using the updated expression forms.

While the invention has been described above in relation to its example embodiments, various modifications may be made thereto that still fall within the invention's scope. Such modifications to the invention will be recognizable upon review of the teachings herein.

Claims

1. A natural language processing method comprising: performing natural language processing (NLP) on training data to detect a plurality of linguistic features in the training data, wherein the training data comprises a plurality of words arranged in a natural language, and wherein the detected linguistic features include a numeric style feature;generating a specification data structure based on the detected linguistic features, the specification data structure arranged for training a natural language generation (NLG) system to produce natural language output that stylistically resembles the training data;training the NLG system based on the specification data structure to thereby configure the NLG system to produce natural language output that stylistically resembles the training data; andthe trained NLG system processing a data set to generate a natural language output that expresses an idea derived from the processed data set, wherein the generated natural language output includes numeric data that is expressed in accordance with the numeric style feature; andwherein the performing, generating, training, and processing steps are performed by a processor.

2. The method of claim 1 wherein the specification data structure comprises a machine-readable representation of the detected linguistic features.

3. The method of claim 1 wherein the performing step comprises the processor performing pattern matching on the training data to detect the numeric style feature.

4. The method of claim 3 wherein the pattern matching comprises regular expression pattern matching.

5. The method of claim 1 wherein the numeric style feature comprises a decimal precision feature.

6. The method of claim 1 wherein the numeric style feature comprises a decimal separator feature.

7. The method of claim 1 wherein the numeric style feature comprises a digit grouping delimiter feature.

8. The method of claim 1 wherein the numeric style feature comprises a currency symbol feature.

9. The method of claim 1 further comprising: modifying the specification data structure to selectively choose in response to user input which of the detected linguistic features are to be used for training the NLG system, wherein the processor performs the modifying step.

10. The method of claim 9 further comprising: providing a user interface for presentation to a user, the user interface configured to summarize the detected linguistic features; andreceiving user input through the user interface, wherein the received user input includes commands that identify which of the detected linguistic features are to be used to train the NLG system, wherein the processor performs the receiving step.

11. The method of claim 1 further comprising: receiving the training data as text sentence input from a user.

12. The method of claim 1 further comprising: receiving the training data as a pre-existing document.

13. The method of claim 1 further comprising: receiving the training data as speech input from a user.

14. The method of claim 1 wherein the training data comprises a corpus of documents.

15. The method of claim 1 wherein the training data comprises a plurality of sentences, the method further comprising performing the NLP on each of a plurality of the sentences to detect a plurality of linguistic features in the sentences.

16. The method of claim 1 wherein the processor comprises a plurality of processors.

17. The method of claim 16 wherein different processors perform the performing and generating steps.

18. The method of claim 1 wherein the same processor performs the performing and generating steps.

19. An apparatus for natural language processing, the apparatus comprising: a processor configured to (1) perform natural language processing (NLP) on training data to detect a plurality of linguistic features in the training data, wherein the training data comprises a plurality of words arranged in a natural language, and wherein the detected linguistic features include a numeric style feature, (2) generate a specification data structure based on the detected linguistic features, the specification data structure arranged for training a natural language generation (NLG) system to produce natural language output that stylistically resembles the training data, and (3) train the NLG system based on the specification data structure to thereby configure the NLG system to produce natural language output that stylistically resembles the training data; andthe trained NLG system, wherein the trained NLG system is configured to process a data set to generate a natural language output that expresses an idea derived from the processed data set, wherein the generated natural language output includes numeric data that is expressed in accordance with the numeric style feature.

20. The apparatus of claim 19 wherein the specification data structure comprises a machine-readable representation of the detected linguistic features.

21. The apparatus of claim 19 wherein the processor is further configured to perform pattern matching on the training data to detect the numeric style feature.

22. The apparatus of claim 21 wherein the pattern matching comprises regular expression pattern matching.

23. The apparatus of claim 19 wherein the numeric style feature comprises a decimal precision feature.

24. The apparatus of claim 19 wherein the numeric style feature comprises a decimal separator feature.

25. The apparatus of claim 19 wherein the numeric style feature comprises a digit grouping delimiter feature.

26. The apparatus of claim 19 wherein the numeric style feature comprises a currency symbol feature.

27. The apparatus of claim 19 wherein the processor is further configured to modify the specification data structure to selectively choose in response to user input which of the detected linguistic features are to be used for training the NLG system.

28. The apparatus of claim 27 wherein the processor is further configured to: provide a user interface for presentation to a user, the user interface configured to summarize the detected linguistic features; andreceive user input through the user interface, wherein the received user input includes commands that identify which of the detected linguistic features are to be used to train the NLG system.

29. The apparatus of claim 19 wherein the processor is further configured to receive the training data as text sentence input from a user.

30. The apparatus of claim 19 wherein the processor is further configured to receive the training data as a pre-existing document.

31. The apparatus of claim 19 wherein the processor is further configured to receive the training data as speech input from a user.

32. The apparatus of claim 19 wherein the training data comprises a corpus of documents.

33. The apparatus of claim 19 wherein the training data comprises a plurality of sentences, and wherein the processor is further configured to perform the NLP on each of a plurality of the sentences to detect a plurality of linguistic features in the sentences.

34. The apparatus of claim 19 wherein the processor comprises a plurality of processors.

35. The apparatus of claim 19 wherein the processor is included as part of the NLG system.

36. The apparatus of claim 19 wherein the processor is part of an NLP system, and wherein the NLG system includes a different processor.

37. A computer program product for natural language processing, the computer program product comprising: a plurality of processor-executable instructions that are resident on a non-transitory computer readable storage medium, wherein the instructions are configured, upon execution by a processor, to cause the processor to (1) perform natural language processing (NLP) on training data to detect a plurality of linguistic features in the training data, wherein the training data comprises a plurality of words arranged in a natural language, and wherein the detected linguistic features include a numeric style feature, (2) generate a specification data structure based on the detected linguistic features, the specification data structure arranged for training a natural language generation (NLG) system to produce natural language output that stylistically resembles the training data, and (3) train the NLG system based on the specification data structure to thereby configure the NLG system to produce natural language output that stylistically resembles the training data, wherein the trained NLG system is configured to process a data set to generate a natural language output that expresses an idea derived from the processed data set, wherein the generated natural language output includes numeric data that is expressed in accordance with the numeric style feature.