Method, apparatus, and computer-readable medium for intent classification of natural language queries in a generative artificial intelligence platform

[0001] This application is a continuation-in-part of U.S. Nonprovisional application Ser. No. 19/016,948, filed Jan. 10, 2025, the disclosure of which is hereby incorporated by reference in its entirety.

[0002] Natural language processing (NLP) systems utilize computational techniques to parse and understand natural language. NLP techniques allow computer systems to extract syntactic and semantic meaning from human language and have a variety of applications. Within NLP, intent classification is the process for identifying a purpose or context relating to a particular natural language query. Effective intent classification is critical for accurately and efficiently processing natural language queries, as the semantic meaning of a particular sequence of natural language strings can vary greatly depending on the intent of the user.

[0003] Effective intent classification is particularly crucial in enterprise data management systems and in other environments where users engage in complex, multi-step reasoning. Traditional systems often rely solely on immediate user inputs to determine intent, which can result in imprecise or contextually irrelevant responses. These systems fail to account for the evolving nature of dialogues or the underlying structure of the data systems with which a user is interfacing.

[0004] In enterprise settings, interactions frequently involve intricate queries that build on previous exchanges and require an understanding of the relationships between various data assets. For example, a user might first inquire about sales datasets and subsequently ask for the lineage of one of the discovered sales datasets. Without considering the conversational history, traditional systems struggle to maintain context and identify intent, leading to misunderstandings and inefficiencies in data analysis and response generation.

[0005] Additionally, the underlying structure of backend data systems, such as architecture, data types, relationships, and attributes-plays a vital role in interpreting user intents accurately. Ignoring this context can lead to misinterpretation of user queries, further complicating data management tasks.

[0006] Accordingly, improvements are needed in systems for intent classification of natural language queries.

[0020] While methods, systems, and computer-readable media are described herein by way of examples and embodiments, those skilled in the art recognize that methods, apparatuses, and computer-readable media for intent classification of natural language queries in a generative artificial intelligence platform are not limited to the embodiments or drawings described. The drawings and description are not intended to be limited to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present disclosure and claims. Any headings used herein are for organizational purposes only and are not meant to limit the scope of the description or the claims. As used herein, the word “can” is used in a permissive sense (i.e., meaning having the potential to) rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.

[0021] Applicant has discovered a method, apparatus, and computer-readable medium (collectively “system”) that uniquely combines conversational history and metadata context to achieve higher accuracy in intent prediction and classification. This dual-context approach leverages a large language model fine-tuned to accept user questions, chat history, and metadata context.

[0022] The present system improves generative artificial intelligence platforms coupled to enterprise data management systems by implementing an intent classification system that leverages historic conversation data, as well as the underlying structure of the relevant sections of the enterprise data catalog (referred to as the “metadata context”) in order to accurate classify the intent of user queries.

[0023] Existing systems for intent classification have many drawbacks. Traditional intent classification systems rely solely on immediate user inputs, neglecting the evolving conversational history and rich metadata context. Unlike prior systems, the present system focuses on intent classification for classifying user intent within a conversational generative AI platform. As explained in greater detail below, the present system interprets user questions based on metadata context, based on relationships between the data assets being queried, as well as the conversation history pertaining to a particular question.

[0024] FIG. 1 illustrates a flowchart for intent classification of natural language queries in a generative artificial intelligence platform according to an exemplary embodiment. Each of the steps shown in FIG. 1 are performed by one or more computing devices of the system.

[0025] At step 101 a natural language query is received from a user in a user interface of a generative artificial intelligence platform, the generative artificial intelligence platform being coupled to an enterprise data catalog and the natural language query comprising a plurality of query terms. The natural language query can be any type of query that has an unstructured format and is not required to conform to any syntax or format rules.

[0026] FIG. 2 illustrates an example of receiving a natural language query according to an exemplary embodiment. User interface 200 can be a frontend interface of a generative artificial intelligence platform that is coupled to an enterprise data catalog and can be configured to receive natural language input from a user. For example, the user interface 200 can be an interface of a large language model (LLM) such as a generative pre-trained transformer (GPT). The LLM or GPT can be configured to interface with a backend enterprise data catalog, which itself can have a structured database format, such as a relational database, a graph database or other type of database.

[0027] As shown in FIG. 2, the interface 200 can correspond to product and/or an enterprise data catalog and allows for a back-and-forth dialog between the user 201 and the LLM/GPT 202. In the example shown in FIG. 2, the user 201 has entered the natural language query 203 “Get overview of SKILLS dataset.”

[0028] Returning to FIG. 1, at step 102 an entity index is queried based at least in part on one or more query terms in the plurality of query terms to identify one or more entities corresponding to the natural language query.

[0029] The entity index is generated based at least in part on an entity graph corresponding to the enterprise data catalog. The entity graph, also referred to as a concept graph or knowledge graph, includes a plurality of nodes and a plurality of edges between the plurality of nodes. The plurality of nodes correspond to a plurality of concepts and the plurality of edges correspond to a plurality of relationships between the plurality of concepts.

[0030] FIG. 3 illustrates the enterprise data catalog, entity graph, and entity index according to an exemplary embodiment. The enterprise data catalog 301 is the backend database storing the enterprise data and can be organized in various ways, as discussed previously. For example, the enterprise data catalog can be a graph database or a relational database.

[0031] The entity graph 302 corresponds to the enterprise data catalog 301 and can be generated based at least in part on the enterprise data catalog. As discussed previously, each node in the entity graph corresponds to a concept, which can be any aspect of the enterprise data catalog. For example, each node can correspond to a data domain in the enterprise data catalog, a particular column in a table of the enterprise data catalog, a classification or attribute in the enterprise data catalog (e.g., business term), a particular data store, or any other conceptual entity in the enterprise data catalog. The entity graph can be pre-built from the enterprise data catalog prior to any query being received from a user.

[0032] The entity graph 302 also includes a plurality of edges between the plurality of nodes in the entity graph. The edges can be directed edges or undirected edges and indicate relationships between the concepts that correspond to the nodes. For example, an edge can connect a first node corresponding to a first table with a second node corresponding to another table, or to a third node corresponding to a column that is part of the first table, or to a fourth node corresponding to data domain that is part of the first table, or to any other node corresponding to any other conceptual entity that is related to the first table.

[0033] The entity index 303 is an index of the entities that are part of the entity graph and can store the entities that that are found in the entity graph, as well as attributes of those entities. For example, the entity graph 302 includes at least entities A-M and the entity index 303 stores data structures corresponding to each of these entities. The entity attributes can include the type of entity (e.g., class/domain, column, other concept), relationships (both the number of relationships and identification of related entities), and other features.

[0034] FIG. 4 illustrates an example of querying an entity index based at least in part on one or more query terms in the plurality of query terms to identify one or more entities corresponding to the natural language query according to an exemplary embodiment. As shown in FIG. 4, a user enters a query into the user interface 401 of the generative AI platform 402. The query terms 405 can then be used to query the entity index 403, which is coupled to the enterprise data catalog 404.

[0035] As shown in FIG. 4, the entity index 403 can return one or more named entities 406 in response to the query terms 405. The named entities can correspond to various types of entities in the entity index, including data domains, data tables, data types, relationships and/or other concepts extracted from the enterprise data catalog.

[0036] Returning to FIG. 1, at step 103 one or more assets in the enterprise data catalog corresponding to the one or more entities are identified. Assets can include, for example, tables, data domains, columns, or other data structures in the enterprise data catalog. Assets corresponding to the one or more entities can be identified in various ways. For example, the entities returned from the entity index can include entity information, such as entity type. The returned entities can be filtered to only include database assets, such as tables, columns, domains, etc. and to disregard other entities such as concepts, relationships, or non-asset concepts.

[0037] Alternatively or additionally, the system can store a list or other data structure of assets in the enterprise data catalog. When the entity index returns one or more entities corresponding to query terms, the returned entities can be used to lookup correspond assets in the asset data structure.

[0038] Additionally, the system can utilize a metadata index (discussed further below) to identify assets corresponding to the one or more entities. For example, the entities corresponding to the query terms can be looked up in the metadata index to identify which entities correspond to enterprise data catalog assets. The metadata index can include information about each entity that is stored in the entity index, include information about the type of entity (e.g., concept, table, domain, etc.). The metadata index can be used to identify which entities correspond to assets (e.g., database structures such as tables or columns) and filter out entities that are conceptual entities.

[0039] Returning to FIG. 1, at step 104 a metadata context corresponding to the one or more assets are identified. The metadata context can include a variety of metadata relating to the one or more identified assets. For example, the metadata context can include related assets and/or related asset types. The metadata context can also include joinable assets (i.e., joinable tables) that can be joined with the identified assets. In the context of databases, assets such as data tables are joinable if there is a primary key to foreign key relationship between a primary key at a first table and a foreign key at a second table. The present system utilizes detailed metadata relationships through detailed attribute and relationship analysis, including related asset types, and joinable tables to refine intent identification, such as distinguishing between data exploration and metadata exploration intents, as discussed further below.

[0040] FIG. 5 illustrates a flowchart for identifying a metadata context corresponding to the one or more assets according to an exemplary embodiment. At step 501 one or more related asset types are identified for each asset in the one or more assets based at least in part on one or more of the entity index or a metadata index generated based at least in part on the enterprise data catalog. The related asset types are those class types in the catalog that can have a relationship with the class type of the asset. For example, if the asset is a skills table, the related asset types can be processes, subdomain, systems, and/or policies.

[0041] At step 502 one or more joinable assets are identified for each asset in the one or more assets based at least in part on a primary key-foreign key relationship between the asset and the other assets in the enterprise data catalog. As discussed previously, the joinable assets can be joinable tables that have a joinable relationship (Primary Key-Foreign Key relationship) in the catalog with the assets.

[0042] FIG. 6 illustrates a system chart illustrating components of the generative AI platform and backend components that are used to identify assets corresponding to query terms, related asset types, joinable assets, and/or other metadata according to an exemplary embodiment. As shown in FIG. 6, the generative AI platform 601 has bi-directional communication with the enterprise data catalog 602, the entity index 603, and the metadata index 604.

[0043] Returning to FIG. 1, at step 105 one or more previous conversations of the user on the generative artificial intelligence platform are retrieved. This step can include identifying previous conversation of the user and also identifying previous conversations that are specifically relevant to the query. Previous conversations can be stored in a backend database of the generative AI platform and can be stored and organized according to user and/or stored according to conversation topics.

[0044] The step of retrieving previous conversations can be performed in different ways. For example, natural language processing of the query can be used to identify one or more topics related to the query and the identified topics can be used to look up and retrieve previous conversations of that user relating to the identified topics. In another example, the user can specify which previous conversations or topics are pertinent to the query. In another example, the conversation history of the current conversation of the user can be retrieved, while disregarding other prior conversations. The frontend interface of the generative AI platform can include interface elements that allow the user to designate conversations so that a user can converse with the generative AI platform regarding different topics in parallel. In this case, the conversation history of the currently selected conversation can be retrieved. In yet another example, the retrieved conversation history can be retrieved based at least in part on a particular time interval. In this case, the conversation history of the user for a predetermined period of time in the past (e.g., 1 day, 5 days, 2 weeks, 1 month, etc.) can be retrieved.

[0045] At step 106 a structured prompt is generated based at least in part on the natural language query, the one or more assets, the metadata context corresponding to the one or more assets, and the one or more previous conversations. The structured prompt can incorporate user questions/queries and previous conversations, along with metadata context including related asset types and joinable assets. The structured prompt is provided as the prompt to a fine-tuned large language model (LLM) and allows for more accurate intent classification of the user query. As will be described further below, this structured prompt is the same prompt that is used during the training process and is configured to provide a more accurate assessment of user intent.

[0046] The structure prompt can include the natural language query, at least a portion of one or more previous conversations, one or more asset identifiers correspond to one or more assets, one or joinable asset identifiers corresponding to the one or more joinable assets for each asset in the one or more assets, and one or more related asset types for each asset in the one or more assets.

[0047] FIG. 7 illustrates a system diagram of the process of generating a structured prompt 706 according to an exemplary embodiment. The generative AI platform 701 receives a user query, in this case “Get overview of SKILLS dataset,” and queries the entity index 702 with one or more query terms to identify entities corresponding to the query. In this case, the identified entities include the SKILLS entity and the MAINTENANCE ENGINEERS entity.

[0048] The generative AI platform can then determine assets in the enterprise data catalog corresponding the identified entities (SKILLS and MAINTENANCE ENGINEERS), as well as metadata context, such as related asset types, joinable assets, and other metadata corresponding to the determined assets. As discussed previously, these determinations can be performed based on the enterprise data catalog, the entity index, and/or a metadata index. For example, the identified entities can be used to lookup corresponding assets, such as tables or columns, in the enterprise catalog. The entity index can then be used to identify joinable assets and the entity graph, entity index, and/or metadata index can be used to identify related asset types. Box 703 illustrates the identified MAINTENANCE ENGINEERS asset (i.e., the maintenance engineers table), along with a unique identifier of the asset, a list of joinable assets (i.e., joinable tables having a primary key-foreign key relationship with the maintenance engineers table), and related asset types. Similarly, box 704 illustrates the identified SKILLS asset (i.e., the skills table), along with a unique identifier of the asset, a list of joinable assets (i.e., joinable tables having a primary key-foreign key relationship with the skills table), and related asset types.

[0049] Additionally, the generative AI platform 701 retrieves one or more conversation histories from a conversation data store 705 based on one or more of user data, a conversation identified, a topic identifier, or the one or more query terms in the user query.

[0050] The conversation history, the user query, and the identified assets and metadata context (e.g., as shown in box 703 and box 704) are then used to generate the structured prompt which is input to a fine-tune large language model to determine an intent classification.

[0051] FIG. 8 illustrates an example of a structured prompt structure/template according to an exemplary embodiment. The structured prompt 800 includes a task section 800A, chat history section 800B, a metadata context section 800C, a user query section 800D, and an answer 800E section.

[0052] As shown in FIG. 8, the prompt can include instructions to summarize the user query by integrating previous questions (if the query is a follow up) and can package the query along with metadata context and conversation history as part of the prompt. Additionally, the prompt can include instructions to provide the intent in a particular form-in this case the JavaScript Object Notation (JSON format).

[0053] FIG. 9 illustrates an example of a structured prompt that is generated based on specific user query according to an exemplary embodiment. The prompt 900 includes the user query 900D (“Get overview of SKILLS dataset”), as well as the user's previous chat history 900B, the determined metadata context 900C, and the answer format 900E. The prompt additionally includes the task description 900A, which is the same as the task shown in FIG. 8 and omitted for clarity.

[0054] Returning to FIG. 1, at step 107 an intent associated with the natural language query is determined by inputting the structured prompt into a fine-tuned large language model, the fine-tuned large language model being trained based at least in part on a plurality training queries on the enterprise data catalog, a plurality of training conversations, and a plurality of training metadata contexts.

[0055] The large language model (LLM) can first be pre-trained on an enterprise knowledge base corresponding to the enterprise, which grounds the LLM to a particular enterprises' data domain and reduces the hallucinations. After that, fine-tuning can be performed specifically for enterprise data management tasks, incorporating conversational history and metadata context that improves accuracy and efficiency. The metadata context used for training can be captured from the enterprise data catalog which helps the model to associate the intent based on the user question and the context which is passed. The large language model can be an instructions-based Mistral model or another type of model. The model is fine-tuned to accept user question, chat history and metadata context as input which is structured as a prompt to the model and the expected output is the classification of the question into one of the intents.

[0056] FIG. 10 illustrates a system chart showing the system for intent classification according to an exemplary embodiment. The various components of the system are described in greater detail below.

[0057] A training database 1003 is used to train the fine-tuned large language model 1002. The training database includes training queries 1003, training conversations 1003B, training metadata contexts 1003C, and training intents 1003D. The training queries, training conversations, and training metadata context are provided to a training prompt generator 1004 which generates LLM training prompts for training the LLM 1002. The training database 1003 and the training prompt generator 1004 both have bidirectional communication with the enterprise backend 1005. The enterprise backend 1005 includes the enterprise data catalog 1005A, the metadata index 1005B, and the entity index 1005C. This bidirectional communication can be used to determine the training metadata contexts 1003C and training prompts. In sum, the training process takes in the following data:

[0058] Training Queries: The system receives training questions from the user or from a training data sets. The training questions are the primary input for intent classification.

[0059] Training Chat History+Training Metadata Context: The system also uses the conversational history and metadata context. This helps in understanding the background and additional context for the training questions.

[0060] Training Intent: The desired intent to which the user question is to be classified.

[0061] Training Prompt Generation: A component is responsible for generating training prompts. It considers the user question, chat history, metadata context, and the determined intent to create comprehensive prompts for training. The generated prompts can be used to train a Mistral model. When a Mistral model is used, the result of this training process is a fine-tuned Mistral model. This model is now optimized to classify intents accurately based on user questions and the provided context.

[0062] As discussed above, the training process uses training intents along with the determined intents from the LLM. The determined intent can then be compared with a corresponding training intent 1003D, which is also provided as input to the LLM in the training phase, and that corresponds to the provided training data and used to adjust and provide feedback to the LLM. In other words, the training data includes the desired intents and the LLM can be trained to produce the desired intent for a particular set of training data.

[0063] After the training phase, when the system is in active operation, the user query 1007, the conversation history 1008, and metadata context 1009 are provided to a prompt generator 1006 to produce a structured prompt 1001, as discussed previously. The user query serves as the primary input for the inference process. The conversation history and metadata context provide additional background information that helps the model in understanding the query more accurately. The prompt generator 1006 generates prompts for inference and takes into account the query, the conversation history, and metadata context.

[0064] The structured prompt 1001 is provided to the fine-tuned LLM 1002 (such as a fine-tuned Mistral model) and the fine-tuned LLM 1002 produces a determined intent 1010 for the query 1007. The determined intent is the systems understanding of the user's question in the context provided. The fine-tuned large language model can be configured to identify an intent from a plurality of potential intents. The plurality of potential intents can include data catalog discovery (a query for discovering data in the data catalog), metadata exploration (a query for metadata attributes and relationships of data in the data catalog), data exploration (a query asked on a customer database which is data related), data transformation (a query to create mappings or data integrations), product help (a query which is product help related), or others (any other queries which do not fall into the previous categories).

[0065] The examples in the table below illustrate the determined intents for a given query, conversation history, and metadata context:

[0066]

		Determined
Query	Conversation History and Metadata Context	Intent
Get overview of	User: show me engineer skills dataset	Metadata
SKILLS dataset	Metadata Context: [	Explore
	{
	“name”: “SKILLS”,
	“id”: “b2a3c4d5-e6f7g8h9-j0k1l2m3”,
	“joinable_tables”: [“ENGINEER_SKILLS”,
	“SKILLS_REQUIRED_TO_FIX”, “STAFF”, “ASSET_PARTS”,
	“ASSETS”, “ENGINEER_VISITS”, “FAULT_LOG”,
	“related_asset_types”: [“processes”, “subdomain”,
	“systems”, “policies”]
	},
	{
	“name”: “MAINTENANCE_ENGINEERS”,
	“id”: “c3a4b5d6-e7f8g9h0-ilj2k3l4”,
	“joinable_tables”: [“ENGINEER_SKILLS”, “SKILLS”,
	“STAFF”, “ASSET_PARTS”, “ASSETS”,
	“ENGINEER_VISITS”, “FAULT_LOG”],
	“related_asset_types”: [“reports”, “systems”, “processes”,
	“subdomain”]
	}
	]
Show me the	User: show me engineer skills dataset	Data Explore
faults reported by	Metadata Context: [
maintenance	{
engineers	“name”: “SKILLS”,
	“id”: “b2a3c4d5-e6f7g8h9-j0k1l2m3”,
	“joinable_tables”: [“ENGINEER_SKILLS”,
	“SKILLS_REQUIRED_TO_FIX”, “STAFF”, “ASSET_PARTS”,
	“ASSETS”, “ENGINEER_VISITS”, “FAULT_LOG”],
	“related_asset_types”: [“processes”, “subdomain”,
	“systems”, “policies”]
	},
	{
	“name”: “MAINTENANCE_ENGINEERS”,
	“id”: “c3a4b5d6-e7f8g9h0-i1j2k3l4”,
	“joinable_tables”: [“ENGINEER_SKILLS”, “SKILLS”,
	“STAFF”, “ASSET_PARTS”, “ASSETS”,
	“ENGINEER_VISITS”, “FAULT_LOG”],
	“related_asset_types”: [“reports”, “systems”, “processes”,
	“subdomain”]
	}
	]
create a pipeline	User: Show me the fault logs recorded by Edmond in the last	Data
to load this to	month using Fault_Log with id	Transform
CustBKP	‘a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6’ and add a new column
	fault_history
	Metadata Context:
	SELECT fl.fault_log_entry_id, fl.fault_description,
	fl.fault_log_entry_datetime FROM Fault_Log AS fl JOIN Staff
	AS s ON fl.recorded_by_staff_id = s.staff_id WHERE
	s.staff_name = ‘Edmond’ AND fl.fault_log_entry_datetime >=
	DATEADD(month, −1, GETDATE( ))
How can I cancel		Product Help
a task that is
currently in
progress in the
C360 platform?
What's the		Others
weather like
today?

[0067] As shown above, certain queries, such as “How can I cancel a task that is currently in progress in the C360 platform?” will result in a determined intent of “Product Help” regardless of conversation history and/or metadata context. Additionally, certain queries, such as “What's the weather like today?” will result in a determined intent of “Others” regardless of conversation history and/or metadata context.

[0068] Once the intent of the query is determined, the generative AI platform can produce a response to the query. FIG. 11 illustrates a flowchart for generating a response to the user query according to an exemplary embodiment.

[0069] At step 1101 a response to the natural language query is generated based at least in part on the determined intent. Generating a response to the natural language query can optionally include the steps shown in 1101A-1101C.

[0070] At step 1101A one or more backend queries are generated based at least in part on the natural language query and the determined intent. The backend queries can be queries configured to interface with the backend database of the enterprise data catalog and/or the metadata index or entity index. For example, if the backend database is a SQL database and the determined intent is a data explore intent, then the query can be used to generate one or more SQL queries (e.g., SELECT queries) to be sent to the backend database. In another example, if the determined intent is a metadata explore intent, then the backend queries can be configured to query the metadata index.

[0071] At step 1101B the one or more backend queries are executed to identify one or more results. The backend queries can be executed on the enterprise data catalog or on other backend structures, such as the metadata index, the entity index, or other data structures or databases storing data relating to the enterprise data catalog.

[0072] At step 1101C the response to the natural language query is generated based at least in part on the identified one or more results. This step can include transforming the one or more results into a natural language response. This step can be performed by text generation component of the generative AI platform, such as a Generative Pre-trained Transformer (GPT) that is configured to generate natural language text in response to inputs. For example, if the results are portions of the enterprise data catalog, then the response to the natural language query can transform those portions into an easily digestible or summarized format for the user within the frontend interface. The response can also transform numerical results or metadata into natural language text that responds to the user query.

[0073] At step 1102 the response in transmitted in the user interface of the generative artificial intelligence platform. The response can be transmitted as part of a frontend GPT interface and/or an be transmitted within current conversation of the user. The response can also be transmitted in other forms, such a linked document or file, or some combination of a textual response within the interface and a file. For example, the response can include text stating “Here is your requested data” and include a link to a spreadsheet file containing the data that was requested by the user.

[0074] FIG. 12 illustrates a system chart for generating a response to the natural language query according to an exemplary embodiment. As shown in FIG. 12, a user inputs a query into the user interface 1201 of a generative AI platform 1202. The user query 1203 is then used to generate structured prompt 1204, as discussed previously. The structured prompt 1204 is input into the fine-tuned LLM 1205 and the fine-tuned LLM determines an intent 1206 for the query. The determined intent 1206 and user query 1203 are then used to generate backend queries 1207. Backend queries are then executed one or more backend systems 1208, such as entity index 1208A, metadata index 1208B, and/or enterprise data catalog 1208C, to produce results 1209. The results 1209 are then provided back to the generative AI platform 1202, which transforms the results into one or more responses.

[0075] One or more of the above-described techniques can be implemented in or involve one or more special-purpose computer systems having computer-readable instructions loaded thereon that enable the computer system to implement the above-described techniques. FIG. 13 illustrates a specialized computing environment 1300 that is used to perform the above-described methods and implement the above-described systems according to an exemplary embodiment.

[0076] With reference to FIG. 13, the computing environment 1300 includes at least one processing unit/controller 1302 and memory 1301. The processing unit 1302 executes computer-executable instructions. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory 1301 can be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. The memory 1301 can store software implementing the above-described techniques and data structures, including enterprise data catalog 1301A, entity graph 1301B, entity index 1301C, metadata index 1301D, user interface 1301E, generative AI platform 1301F, conversation identification software 1301G, fine-tuned LLM 1301H, prompt generation software 1301I, metadata context identification software 1301J, training data and software 1301K, or other software 1301L corresponding to the processes described herein.

[0077] All of the software stored within memory 1301 can be stored as a computer-readable instructions, that when executed by one or more processors 1302, cause the processors to perform the functionality described with respect to FIGS. 1-12.

[0078] Processor(s) 1302 execute computer-executable instructions. In a multi-processing system, multiple processors or multicore processors can be used to execute computer-executable instructions to increase processing power and/or to execute certain software in parallel.

[0079] Specialized computing environment 1300 additionally includes a communication interface 1303, such as a network interface, which is used to communicate with devices, applications, or processes on a computer network or computing system, collect data from devices on a network, such as legacy systems, destination systems, or other network systems, and implement encryption/decryption actions on network communications within the computer network or on data stored in databases of the computer network. The communication interface conveys information such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.

[0080] Specialized computing environment 1300 further includes input and output interfaces 1304 that allow users (such as system administrators) to provide input to the system to set parameters, to edit data stored in memory 1301, or to perform other administrative functions.

[0081] An interconnection mechanism (shown as a solid line in FIG. 13), such as a bus, controller, or network interconnects the components of the specialized computing environment 1300.

[0082] Input and output interfaces 1304 can be coupled to input and output devices. For example, Universal Serial Bus (USB) ports can allow for the connection of a keyboard, mouse, pen, trackball, touch screen, or game controller, a voice input device, a scanning device, a digital camera, remote control, or another device that provides input to the specialized computing environment 1300.

[0083] Specialized computing environment 1300 can additionally utilize a removable or non-removable storage, such as magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, USB drives, or any other medium which can be used to store information and which can be accessed within the specialized computing environment 1300.

[0084] The present system utilizes several novel techniques and features to achieve a number of technical advantages. These techniques and advantages are described in greater detail below.

Analysis of Conversational History

[0085] Contextual Understanding: The system captures and analyzes the evolving dialogue context by maintaining a detailed record of historical user interactions. This allows the system to understand the flow and progression of the conversation, providing a richer context for intent classification.

[0086] Enhanced Intent Prediction: By considering past interactions, the system can predict user intents more accurately. For instance, if a user asks about “sales datasets” in one turn and then requests “the lineage of one of the discovered sales datasets,” the system uses the historical context to interpret the follow-up query correctly.

Integration of Metadata Context

[0087] Leveraging Metadata Relationships: The system integrates metadata context by analyzing relationships and attributes associated with data assets. This includes data types, metadata attributes, joinable tables, and other relevant metadata that inform the intent classification process.

[0088] Refined Intent Determination: By leveraging detailed metadata relationships, the system refines intent determination, ensuring that responses are contextually relevant and accurate. For example, understanding that queries about joinable tables of a sales dataset are data exploration questions, while queries about metadata attributes of the sales dataset are metadata exploration questions, helps the system interpret user intents more precisely.

Dual-Context Approach

[0089] Combining Historical and Metadata Contexts: The system employs a dual-context approach that surpasses traditional methods relying solely on immediate user inputs. By combining conversational history and metadata context, the system achieves more precise intent classification.

[0090] Improved User Experience and Efficiency: This dual-context approach significantly improves user experience by providing accurate and contextually relevant responses. It also enhances operational efficiency in managing enterprise data by reducing misunderstandings and streamlining data interactions.

Advantages

Improved Accuracy Using Context and Chat History

[0091] By integrating both conversational history and metadata context, the system achieves a much higher level of precision in identifying user intent. Traditional systems, which rely only on immediate user inputs, often misinterpret queries due to a lack of contextual awareness. The large language model can accommodate a bigger context and thus can be leveraged to use that as part of the classification thereby improving accuracy.

Dynamic Intent Identification

[0092] The system's ability to analyze historical interactions enables it to adaptively identify user intent even as the conversation evolves. This contrasts with other systems that may lose context over time and fail to accurately interpret changing user intents.

Metadata-Driven Refinement

[0093] Leveraging detailed metadata relationships, such as data types and attributes, allows the system to refine intent identification. For example, queries about joinable tables can be accurately classified as data exploration questions, which is a capability typically missing in traditional systems where it considers only user question alone in determining the intent.

Enhanced User Experience

[0094] The system's sophisticated intent identification leads to more relevant and accurate responses, improving the overall user experience. Users are less likely to encounter misinterpreted queries and can interact with the system more efficiently, which is a clear advantage over less intuitive systems.

Operational Efficiency:

[0095] By accurately identifying user intents, the system reduces the need for repeated clarifications and follow-up questions. This streamlines operations and increases productivity, offering a significant improvement over traditional systems that often require additional user input to clarify intents.

[0096] Having described and illustrated the principles of our invention with reference to the described embodiment, it will be recognized that the described embodiment can be modified in arrangement and detail without departing from such principles. Elements of the described embodiment shown in software can be implemented in hardware and vice versa.

[0097] In view of the many possible embodiments to which the principles of our invention can be applied, we claim as our invention all such embodiments as can come within the scope and spirit of the following claims and equivalents thereto.