Graph-enhanced semantic retrieval augmented generation for cross domain data in enterprise systems

Abstract

Aspects of the disclosure include a machine learning architecture for leveraging graph-enhanced semantic retrieval augmented generation (RAG) for cross domain data in enterprise systems. A method includes processing a natural language query using a large language model to generate a query intent and a query schema, generating text embeddings representing the query intent, and generating node embeddings representing the query schema. A semantic similarity search and a structural similarity search are performed to identify two sets of nodes and edges, which are aggregated. A connected subgraph is built from the aggregated set of nodes and edges and an optimal path through the connected subgraph is identified based on a learned cost function. A retrieval augmented generation executable is generated based on the at least one optimal path and executed against a database to retrieve contextual data. The contextual data is leveraged to respond to the query.

Description

202419796GRAPH-ENHANCED SEMANTIC RETRIEVAL AUGMENTED GENERATION FOR CROSS DOMAIN DATA IN ENTERPRISE SYSTEMSINTRODUCTION

[0001] The subject disclosure relates to machine learning, networks, pattern recognition, and data discovery, and specifically to a machine learning architecture which leverages graph-enhanced semantic retrieval augmented generation (RAG) for cross domain data in enterprise systems.A BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The specifics of the exclusive rights described herein are particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other features and advantages of the embodiments of the present disclosure are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

[0003] FIG. 1 illustrates a block diagram of a processing system in accordance with an embodiment;

[0004] FIG. 2 depicts an example graph-enhanced semantic retrieval augmented generation (RAG) system in accordance with one or more embodiments;

[0005] FIG. 3 depicts a block diagram of a multilayer perceptron (MLP)-type model implementation in accordance with one or more embodiments;

[0006] FIG. 4 depicts a block diagram of a transformer-type model implementation in accordance with one or more embodiments;

[0007] FIG. 5 A depicts a first portion of a flowchart of a method in accordance with one or more embodiments; and

[0008] FIG. 5B depicts a second portion of the flowchart of the method of FIG. 5A in accordance with one or more embodiments.202419796

[0009] The diagrams depicted herein are illustrative. There can be many variations to the diagram or the operations described therein without departing from the spirit of this disclosure. For instance, the actions can be performed in a differing order or actions can be added, deleted or modified.

[0010] In the accompanying figures and following detailed description of the described embodiments of this disclosure, the various elements illustrated in the figures are provided with two or three-digit reference numbers. With minor exceptions, the leftmost digit(s) of each reference number corresponds to the figure in which its element is first illustrated.DETAILED DESCRIPTIONOVERVIEW

[0011] Enterprise systems today integrate vast amounts of structured and unstructured data across multiple domains. As organizations grow and diversify, their operations generate and rely on data from a wide array of sources, including databases, document repositories, transactional systems, communication platforms, and external feeds. This data may encompass everything from product specifications, engineering drawings, and supply chain records to customer communications, regulatory documents, and market intelligence. The diversity and volume of this information present significant challenges for data management, accessibility, and utilization.

[0012] Efficient data retrieval and management is essential in such environments because business processes increasingly depend on timely, accurate access to relevant information. For example, product lifecycle management (PLM) systems must aggregate and analyze data from design, manufacturing, quality assurance, and support domains to enable informed decision-making and rapid response to market demands. Similarly, enterprise resource planning (ERP) and customer relationship management (CRM) platforms require seamless integration of data from disparate sources to optimize operations, improve customer service, and maintain compliance. Without effective data retrieval and management, organizations202419796 face bottlenecks in analytics, reporting, and operational workflows. Users may struggle to locate the information they need, leading to delays, errors, and missed opportunities.

[0013] Organizations increasingly rely on natural language interfaces to query sprawling enterprise data ecosystems, often seeking to translate open-ended prompts into precise database queries. One goal of such systems is to empower domain experts and end users to access relevant information without needing detailed knowledge of the underlying schemas, API endpoints, or query languages. A streamlined pipeline that can interpret high-level intent, identify related entities and relationships, and retrieve targeted context for generation tasks can significantly accelerate analytics, reporting, and operational workflows. Unfortunately, the complexity and diversity of enterprise data — often distributed across multiple applications, formats, and schemas — complicates the process, as conventional search and query mechanisms may be unable to bridge semantic gaps or navigate intricate relationships between diverse entities.

[0014] Advances in machine learning, pattern recognition, and contextual language understanding have fostered new techniques for retrieving and synthesizing relevant information from disparate and complex data sources. In particular, large language models (LLMs) are re-defining how users interact with vast amounts of data. By leveraging natural language processing capabilities, LLMs can interpret user queries expressed in everyday language, automatically translate them into structured database queries, and generate accurate, context-aware responses — thereby bridging the gap between human intent and complex enterprise data systems. However, conventional LLMs can suffer from so-called hallucinations — scenarios in which an LLM might generate output that can be factually incorrect. This can result from a variety of complications, some universal, such as ambiguous or poorly defined queries and limitations in a model’s ability to generalize beyond its training corpus, and some specific to enterprise contexts, such as conflicting and / or contradictory industry-specific terminology and vocabulary, differences in user roles, and the variety of domain-specific data types and data models involved, which might include202419796 structured, semi-structured, and unstructured data that spans multiple overlapping domains.

[0015] Retrieval-augmented generation approaches can be combined with large language models to ground their generated outputs in factual context. RAG techniques enable an LLM to access and incorporate relevant information from internal databases, document repositories, and knowledge graphs, ensuring that responses are both accurate and tailored to the specific business context. For example, in an enterprise setting, when a user submits a query, a RAG-supported system can first search internal enterprise databases and document repositories to identify content that is semantically related to the query. This retrieved context can then be provided to the LLM, which uses it to inform and constrain its response generation.

[0016] Today, conventional retrieval mechanisms in RAG-supported LLM pipelines exhibit several limitations, particularly when deployed in enterprise environments. Most existing systems rely heavily on textual (semantic) similarity and learned language understanding to identify and retrieve relevant information in response to user queries. Typically, these solutions use semantic similarity-based algorithms to match user queries with documents, records, or database entries, and then employ RAG to fetch the associated data. The underlying LLM subsequently generates responses based on this retrieved context.

[0017] While this approach can improve the factual grounding of LLM outputs, it often fails to account for the complex structural relationships and metadata inherent in enterprise data ecosystems. For example, enterprise knowledge bases frequently contain interconnected entities, hierarchical relationships, and rich metadata that define how different pieces of information relate to one another. Conventional RAG systems, which focus primarily on matching text, may overlook these connections, resulting in incomplete or suboptimal retrieval of context.

[0018] This limitation is particularly pronounced in environments where data is distributed across multiple domains, applications, and customized schemas. In such202419796 cases, the semantic similarity approach may retrieve large volumes of loosely related information, leading to overloaded contextual inputs for the LLM and increased risk of confusion or hallucination. Additionally, these systems may struggle to navigate intricate relationships between entities, such as dependencies between product components, user roles, or regulatory requirements, which are critical for accurate and actionable responses. As a result, users may receive answers that are technically correct but lack the necessary specificity, context, or actionable insight required for enterprise decision-making.

[0019] The present invention overcomes the limitations of conventional RAGbased LLM solutions by introducing a novel graph-enhanced semantic retrieval augmented generation (RAG) system. This system is specifically designed to address the challenges of data complexity, scale, and heterogeneity in enterprise environments, such as product lifecycle management, knowledge management, and business intelligence platforms. At the core of the graph-enhanced semantic retrieval augmented generation (RAG) system is a two-prong pipeline, as illustrated in FIG. 2, which processes user prompts (queries) in parallel through two distinct but complementary pathways to capture and leverage both the textual and structural features of a query. FIG. 2 is discussed in greater detail below.

[0020] The two-prong pipeline begins with an analysis phase. During this step, an input natural language query is processed using a large language model to identify or generate a query intent and a query schema for the query. In this context, query intent is defined as the set of domain logical entities, including their properties and relationships, that are extracted from the query, while query schema is defined as the subset of an overall schema of an underlying graph database corresponding to the query intent. For example, the query “What is the part number of the connectors used in the ECU harness that supports CAN protocol signals?” can be processed to generate the query intent: [connectors in the ECU harness supporting CAN protocol signals] and the query schema: [the portion of the graph database representing connector entities, their part numbers, and their relationships to ECU harnesses and supported protocols]. The query intent and query schema are then processed along two legs of the two-prong pipeline.202419796

[0021] In the first leg, the meaning and context of a query are leveraged to generate semantically grounded text embeddings. In some embodiments, text embeddings are compared against a collection of semantic embeddings for an entire (complete) schema to identify a first set of nodes and edges that are semantically similar to the user’s intent. In some embodiments, text embeddings are used to represent the description of the node(s) in a numeric form for similarity analysis. In the second leg, node embeddings are generated to encode the structure of the query schema. The node embeddings are compared against a collection of structural embeddings for the complete schema to identify a second set of nodes and edges that are structurally similar to the query, taking into account the available underlying graph topology, entity types, and domain-specific schema information. In some embodiments, a node embedding generator operates on the structural aspects of the input data, generating node embeddings that reflect the relationships, connectivity, and metadata associated with entities in an underlying enterprise knowledge graph. Advantageously, the collection of semantic embeddings and the collection of structural embeddings can be generated offline, prior to receiving the user query. This enables rapid, efficient similarity searches during query processing, as the system can quickly compare incoming queries against precomputed embeddings without incurring significant computational overhead or latency.

[0022] An intermediary set of nodes and edges can be built from the first set of nodes and edges and the second set of nodes and edges. In some embodiments, the intermediary set of nodes and edges is constructed using learned heuristics. For example, in some embodiments, the first and second sets of nodes are aggregated based on one or more set operations, such as the union of the nodes or the intersection of the nodes, or a combination thereof, to create one set of nodes that are both structurally and semantically similar to the nodes and relationships identified in the query schema. The heuristics are discussed in greater detail below. A graph is defined from the intermediary set of nodes and edges. The graph is pruned using one or more pruning strategies, and an optimization pass is performed on the pruned graph to identify probable path(s) through the graph based on a learned cost function. In some embodiments, the learned cost function is based on a minimization of202419796 differences in semantic and structural similarity scores between the query schema received during an online phase and the complete schema generated ahead of time during an offline phase.

[0023] In short, by evaluating both semantic and structural similarity in parallel, the graph-enhanced semantic RAG system is able to generate two candidate sets of nodes and edges — one based on textual relevance and the other on graph-based relationships. These sets can then be aggregated, for example through intersection or union operations, to produce a focused subgraph that is highly relevant to the user’s query. This targeted retrieval strategy dramatically reduces the search space, ensuring that only the most pertinent entities and relationships are provided as context to the downstream LLM. Notably, a graph-enhanced approach constructed as described herein enables richer semantic and relational understanding of user queries, allowing the underlying system to deliver more precise, context-aware, and actionable responses. Compute efficiency and latency is also improved, as the two-leg node generation scheme and subsequent pruning steps allow the system to reduce the RAG search space, natively avoiding the computational overhead associated with an exhaustive search when generating responses to user queries.DETAILED EMBODIMENT

[0024] FIG. 1 illustrates an example of a processing system 100 that can be used to implement the computer-based components of the graph-enhanced semantic RAG system described herein. The processing system 100 includes an exemplary computing device (“computer”) 102 configured for performing various aspects of the operations described herein in accordance with aspects of the invention. In addition to computer 102, exemplary processing system 100 includes network 114, which connects computer 102 to additional systems (not depicted) and can include one or more wide area networks (WANs) and / or local area networks (LANs) such as the Internet, intranet(s), and / or wireless communication network(s). Computer 102 and the additional system are in communication via network 114, e.g., to communicate data between them.202419796

[0025] Exemplary computer 102 includes one or more processor core(s) 104, main memory (“memory”) 110, and input / output component(s) 112, which are in communication via bus 103. Processor cores 104 include cache memory (“cache”) 106 and controls 108. Cache 106 can include multiple cache levels (not depicted) that are on or off-chip from processor 104. Memory 110 can include various data stored therein, e.g., instructions, software, routines, etc., which, e.g., can be transferred to / from cache 106 by controls 108 for execution by processor 104. Input / output component s) 112 can include one or more components that facilitate local and / or remote input / output operations to / from computer 102, such as a display, keyboard, modem, network adapter, etc. (not depicted).

[0026] A cloud computing system 120 is in wired or wireless electronic communication with the processing system 100. The cloud computing system 120 can supplement, support, or replace some or all of the functionality (in any combination) of the processing system 100. Additionally, some or all of the functionality of the processing system 100 can be implemented as a node of the cloud computing system 120.

[0027] FIG. 2 depicts an example graph-enhanced semantic retrieval augmented generation (RAG) system 200 in accordance with one or more embodiments. As shown in FIG. 2, the graph-enhanced semantic RAG system 200 includes a large language model 202 configured to receive and process user queries 204 and to generate, for each given query, a corresponding response 206. More specifically, in some embodiments, large language model 202 is configured to serve as the primary interface between users and an underlying enterprise data system. In some embodiments, query 204 is a user query expressed in natural language and response 206 is a natural language reply to the query 204. In some embodiments, the response 206 is generated, at least in part, according to both a semantic and structural understanding of the query 204, as described in further detail herein.

[0028] The graph-enhanced semantic RAG system 200 leverages the large language model 202 to interpret a user’s intent expressed in the query 204, to translate open-ended or domain-specific questions identified in the query 204 into actionable202419796 tasks, and to facilitate the retrieval and synthesis of relevant information from complex, multi-domain data sources. The architecture of the large language model 202 is not meant to be particularly limited. At its core, a large language model consists of an encoder and a decoder. The encoder takes in a sequence of input tokens, such as words or characters, and produces a sequence of hidden representations for each token that capture the contextual information of the input sequence. The decoder then uses these hidden representations, along with a sequence of target tokens, to generate a sequence of output tokens.

[0029] The most popular and widely used types of large language models are recurrent neural networks (RNNs) and transformers. RNNs are neural networks that process sequences of inputs one by one, and use a hidden state to remember previous inputs. RNNs are particularly well-suited for tasks that involve sequential data, such as text, audio, and time-series data. In a transformer, on the other hand, the encoder and decoder are composed of multiple layers of multi-headed self-attention and feedforward neural networks. The core of the transformer model is the self-attention mechanism, which allows the model to focus on different parts of an input sequence at different timesteps, without the need for recurrent connections that process the sequence one by one. Transformers leverage self-attention to compute representations of input sequences in a parallel and context-aware manner and are well-suited to tasks that require capturing long-range dependencies between words in a sentence, such as in language modeling and machine translation.

[0030] Large language models are typically trained on large amounts of text data, often containing hundreds of millions if not billions of words. To handle the large amount of data, the training process is often highly parallelized. The training process can take several days or even weeks, depending on the size of the model and the amount of training data involved. Large language models can be trained using backpropagation and gradient descent, with the objective of minimizing a loss function such as cross-entropy loss.

[0031] In some embodiments, the large language model 202 is trained to serve as an intelligent mediator, transforming user queries 204 into precise, data-driven202419796 responses 206 that empower users to access and utilize enterprise information efficiently, without requiring specialized knowledge of underlying schemas or query languages. To accomplish this, the large language model 202 is trained to leverage a two-prong graph-enhanced semantic RAG pipeline to identify the most relevant subset of an underlying enterprise knowledge base graph by evaluating both semantic and structural similarities between the query 204 and the knowledge graph. The semantic and structural analysis, and the identification of the graph subset, is covered in greater detail below. Advantageously, the relevant graph subset, a collection of nodes n and edges e, can be used to guide the large language model 202 in constructing a RAG executable 208 — a specialized retrieval and generation routine — which can be leveraged against one or more databases 210 to retrieve information that is both semantically and structurally relevant to the query 204.

[0032] For example, when a user submits the query 204, “What is the part number of the connectors used in the ECU harness that supports CAN protocol signals?”, the large language model 202 first analyzes the query to extract key entities and relationships, such as “connectors,” “ECU harness,” and “CAN protocol signals.” Using the two-prong pipeline, the model identifies the relevant nodes and edges in the knowledge graph and determines the subset of schema necessary to answer the query. The RAG executable 208 is then dynamically constructed to retrieve information from the database 210 that matches both the semantic meaning and the structural context of the query. Continuing from the prior example, the RAG executable 208 can take the form of a Cypher query (for a graph database) or a SQL query (for a relational database) that is specifically designed to retrieve connector part numbers associated with ECU harnesses supporting CAN protocol signals. An example, merely illustrative, of a Cypher query generated by the RAG executable 208 might be:MATCH (connector:Connector)-[:USED_IN]->(harness:ECU_Harness)- [:SUPPORTS]->(protocol:Protocol) WHERE protocol. name = "CAN" RETURN connector.part number, connector.manufacturer, connector, compatibility notes202419796

[0033] In any case, this process ensures that only the most pertinent data — such as connector part numbers, associated harnesses, and supported protocols that are specific to ECU harnesses that support CAN protocol signals — is retrieved and provided as context for response generation. The large language model 202 then synthesizes this information to produce a response 206 that is accurate, contextually grounded, and tailored to the specific business environment. For instance, the response 206 may include the exact part number(s) of connectors, manufacturer details, and compatibility notes, enabling the user to make informed decisions without needing to navigate complex database schemas or query languages.

[0034] Turning now to the two-prong graph-enhanced semantic RAG pipeline itself, in some embodiments, the graph-enhanced semantic RAG system 200 and / or large language model 202 is / are configured to analyze the query 204 and to generate, in response, a query intent and a query schema (collectively, the “intent and schema 212”). In some embodiments, the large language model 202 may be fine-tuned on domain-specific semantics, such as those found in product lifecycle management (PLM), to improve the accuracy and relevance of intent and schema extraction.

[0035] In some embodiments, when a user submits a query 204, the large language model 202 first parses the natural language input to identify key logical entities, their properties, and relationships. For example, given the query “What is the part number of the connectors used in the ECU harness that supports CAN protocol signals?”, the model recognizes entities such as “connectors,” “ECU harness,” and “CAN protocol signals.” The model then determines the relationships between these entities, such as connectors being used in a specific harness and that the harness must support a particular protocol. The model uses this analysis to generate the query intent, which encapsulates the user’s informational goal — in this case, finding connector part numbers associated with a specific harness and protocol. Simultaneously, the model identifies the query schema, which is the subset of the overall enterprise graph database schema that is relevant to the query intent. For the example above, the query schema might include the connector entity type, its part number attribute, the ECU harness entity, and the protocol entity, along with the relationships that link them.202419796

[0036] The intent and schema 212 are passed, sequentially or in parallel, to a text embedding generator 214 and a node embedding generator 216. The text embedding generator 214 transforms the textual descriptions and semantic content of the identified entities, relationships, and attributes of the query 204 into highdimensional numerical representations known as text embeddings, enabling efficient comparison and similarity analysis against precomputed embeddings from an enterprise knowledge graph. For example, if the intent and schema 212 includes entities such as “connectors,” “ECU harness,” and “CAN protocol signals,” the text embedding generator 214 will encode the descriptions and relevant properties of these entities into vector representations. The output of the text embedding generator 214 is a set of text embeddings 218 that serve as the basis for downstream semantic similarity searches.

[0037] In contrast, the node embedding generator 216 encodes the structure of the query schema — derived from the user’s intent — into high-dimensional node embeddings 220 that represent not only the attributes of individual entities but also their connections and positions within the broader graph topology. In short, node embeddings 220 are numerical vectors that encode both the intrinsic features of each node and the structural context provided by their neighbors and relationships. These embeddings capture information such as the degree of connectivity, the types of relationships involved, and the proximity of nodes within the graph. In some embodiments, the inputs to the node embedding generator 216 consist of the subset of the graph schema relevant to the query 204, including the involved or associated entities, their properties, and the relationships among them. For example, if the intent and schema 212 involves “connectors,” “ECU harness,” and “CAN protocol signals,” the node embedding generator 216 receives the graph segment that includes connector nodes, ECU harness nodes, protocol nodes, and the edges that define how these entities are related (e.g., connectors used in a harness, harnesses supporting specific protocols).

[0038] In some embodiments, the node embedding generator 216 utilizes graph neural network techniques such as node2vec or GraphSAGE to process the intent and schema 212 to produce the node embeddings 220, although other202419796 techniques are possible and within the contemplated scope of this disclosure. The node embeddings 220 serve as the basis for downstream structural similarity searches.

[0039] More specifically, the text embedding 218 can be passed to a text similarity search 222, while the node embeddings 220 can be passed to a structural similarity search 224. The purpose of the text similarity search 222 is to identify nodes n and edges e within a predetermined enterprise knowledge graph G (referred to herein as the “complete schema”) that are semantically similar to the user’s query 204. This is accomplished by comparing the text embeddings 218 against a precomputed set of semantic embeddings for the complete schema (referred to herein as the “complete schema semantic embeddings 226”). Advantageously, similarity between embeddings can be determined using known distance measures, such as, for example, Euclidean distance, cosine similarity, dot product similarity, etc.

[0040] For instance, the Euclidean distance is the straight-line distance between two embedding vectors in a shared high-dimensional space, providing a quantitative measure of their similarity. Additionally, or alternatively, cosine similarity can be used to assess the angle between two vectors, which is particularly useful for determining how closely the semantic meaning of two entities aligns, regardless of their magnitude. Other measures, such as Manhattan distance (which sums the absolute differences across each dimension) or dot product similarity, may also be employed depending on the specific requirements of the enterprise data and the nature of the embeddings. For example, when comparing the embedding for “ECU harness” in a user query to the embeddings of all harness-related nodes in the schema, the text similarity search 222 might use cosine similarity to rank the most relevant matches, and / or might use Euclidean distance to filter out nodes that are semantically distant from the query intent. These distance metrics enable the text similarity search 222 to efficiently and accurately identify the nodes n and edges e that are most semantically relevant to the user’s informational needs.

[0041] Similarly, the structural similarity search 224 identifies a set of nodes n and edges e within the complete schema that are structurally (rather than semantically) similar to the user’s query 204. This is accomplished by comparing the202419796 node embeddings 220 — generated from the query’s relevant graph segment as previously described — against a precomputed set of structural embeddings for the complete schema (referred to herein as the “complete schema structural embeddings 228). Advantageously, similarity between embeddings can be measured using the same types of distance metrics commonly used for semantic embeddings. For example, Euclidean distance can be used to quantify the straight-line distance between two node embedding vectors, indicating how closely the structural features of the query match those in the schema. Cosine similarity is also effective, as it measures the angle between vectors and can reveal how similar the connectivity patterns or neighborhood structures are, regardless of the absolute values of the features. Other metrics, such as Manhattan distance or dot product similarity, may be applied depending on the specific characteristics of the graph data and the embedding technique used. For instance, if the query 204 involves finding connectors that are used in ECU harnesses supporting CAN protocol signals, the structural similarity search 224 might compare the node embedding 220 for a “connector” in the query 204 against all connector node embeddings in the schema, ranking those with similar connectivity patterns — such as similar types of relationships to harness and protocol nodes — higher. This approach ensures that the graph-enhanced semantic RAG system 200 to retrieve nodes n and edges e that not only match the semantic meaning of the query 204, but also its structural context within the enterprise knowledge graph.

[0042] The result of the preceding steps is two sets of nodes n and edges e in the underlying enterprise knowledge graph that are semantically and structurally similar, respectively, to the query schema. The nodes n and edges e generated via the text similarity search 222 and the nodes n and edges e generated via the structural similarity search 224 are passed to a set operation 230 for aggregation. In some embodiments, the two sets of nodes n and edges e from the previous steps are aggregated based on set operations such as unions and / or intersections to create a single set of aggregated nodes n and edges e that are both structurally and semantically similar to the nodes and relationships identified in the query schema.

[0043] For example, applying an intersection operation will yield a set containing only those nodes and edges that are present in both the semantically202419796 similar set and the structurally similar set. This ensures that the final aggregated set includes entities and relationships that are highly relevant to the query in both textual meaning and graph structure, providing a focused and precise context for downstream processing. In addition, or alternatively, a union operation can be used to combine all nodes and edges from both sets, resulting in a broader context that includes any entity or relationship identified as relevant by either semantic or structural similarity. This approach may be useful when it is important to maximize coverage and ensure that no potentially relevant information is omitted. In practice, the choice between union, intersection, or a combination thereof can be determined based on the specific requirements of the query or the domain. For instance, some embodiments may use intersection to prioritize precision, while others may use union to prioritize recall.

[0044] In some embodiments, the choice between union, intersection, or a combination thereof is a hyperparameter that is learned while training the graph- enhanced semantic RAG system 200 and / or any subcomponent thereof. This learning process typically involves evaluating the performance of different aggregation strategies — such as pure union, pure intersection, or weighted combinations — on a labeled training dataset containing representative queries and their desired outputs. For example, during training, the graph-enhanced semantic RAG system 200 and / or set operation 230 can experiment with various values for the union-intersection hyperparameter, measuring how well each setting enables the retrieval of relevant nodes and edges that lead to accurate, contextually appropriate responses. The system may use optimization techniques such as grid search, random search, or gradientbased methods to adjust the hyperparameter and identify the configuration that minimizes a loss function (e.g., prediction error, relevance score, or user engagement metric). In this manner, the system learns over time which aggregation strategy yields the best results for different types of queries or domains, allowing the system to select the learned-optimal union-intersection hyperparameter during inference phases.

[0045] Alternatively, or additionally, hybrid approaches may be employed, such as weighting nodes and edges based on their presence in both sets or applying domain-specific heuristics to further refine the aggregated set. This flexibility allows202419796 the set operation 230 to tailor the aggregation strategy to the needs of the enterprise environment and the nature of the user’s query.

[0046] In some embodiments, the aggregated set of nodes n and edges e are passed to a graph builder 232. The graph builder 232 builds, from the aggregated set of nodes n and edges e, a connected subgraph 233. The connected subgraph 233 is passed to a pruning module 234.

[0047] The pruning module 234 applies one or more graph traversal algorithms, connectivity checks, and domain-specific rules to ensure that the resulting subgraph is not only connected but also contextually appropriate for the query 204. This may involve stitching together disconnected nodes, pruning extraneous edges, and / or enforcing constraints such as path length, node type connectivity conditions, and relationship directionality onto the nodes n and edges e. For instance, the pruning module 234 might prune all nodes n from the graph representing connectors that are not directly linked to ECU harness nodes, thereby ensuring that only connectors directly relevant to the query 204 remain in the resulting pruned subgraph 235. In some embodiments, the subgraph can be further pruned using one or more predetermined connected components algorithms or other data driven techniques, such as the application of one or more domain specific rules. While not meant to be particularly limited, domain-specific pruning rules might constrained the type of connections or size of the paths in the subgraph, whether a given path is valid in the subgraph, etc.

[0048] In some embodiments, the pruned subgraph 235 is passed to a path identifier 236. In some embodiments, path identifier 236 identifies a path 238 through or across the pruned subgraph 235 based on one or more predetermined cost functions according to the semantic and structural similarity scores previously identified. For example, a cost function can specify how much to penalize the nodes and edges along a given path. In some embodiments, the paths with the lowest score, or highest score, will be pruned, depending on the implementation. In some embodiments, an optimal path is selected according to the chosen loss function(s). For example, a cost function can penalize a path by assigning higher costs to nodes202419796 and edges that are less semantically or structurally similar to the intent and schema 212, or that introduce undesirable characteristics such as excessive length, weak connectivity, or irrelevant relationships (each according to any predetermined thresholds, which themselves can be learned hyperparameters).

[0049] For example, a cost function might increase the penalty for each node or edge that deviates from a highest semantic or structural similarity score, such as including a connector node that is only loosely related to the specified ECU harness or protocol. Similarly, the loss function could penalize paths that traverse one or more intermediate nodes, or that include edges with low confidence or relevance scores. In some cases, the cost function may also account for domain-specific constraints, such as requiring certain types of relationships or limiting the number of hops between adjacent nodes / entities.

[0050] In some embodiments, path identifier 236 generates the path 238 at least in part by summing the various costs (penalties) of the various candidate paths through the pruned subgraph 235 and ranking the paths according to their relative scores (costs). In this manner, the path(s) with a lowest score can be generated (or the set of paths having scores / costs below any predetermined threshold).

[0051] The path 238, once identified by the path identifier 236, represents the optimal sequence of nodes and edges within the pruned subgraph 235 that directly addresses the user’s query intent and schema. The path 238 can be returned to the large language model 202. In some embodiments, the path 238 is leveraged to generate the RAG executable 208 previously discussed.

[0052] In practice, the path 238 provides a precise blueprint for constructing a targeted database query or retrieval routine that is relevant to the query 204. For example, the large language model 202 can use the entities and relationships defined along the path 238 to dynamically generate a Cypher or SQL query that traverses the relevant nodes and edges in the enterprise knowledge graph or database 210. This ensures that the RAG executable 208 is specifically tailored to extract only the information that is most pertinent to the user’s request, such as connector part202419796 numbers associated with ECU harnesses supporting CAN protocol signals. By grounding the RAG executable 208 in the structure and context provided by the path 238, the graph-enhanced semantic RAG system 200 avoids unnecessary data retrieval and reduces the risk of including irrelevant or extraneous information. This focused approach enables the large language model 202 to deliver highly accurate, context- aware responses, while also improving computational efficiency and response latency in enterprise environments.

[0053] FIG. 3 depicts a block diagram of a multilayer perceptron (MLP)-type implementation for use with the graph-enhanced semantic RAG system 200 or any other component or subcomponent described herein, in accordance with one or more embodiments. MLP 300 is a type of feedforward artificial neural network that consists of multiple layers of interconnected nodes 302. The depth, width, dimensionality, etc., of the MLP 300 need not be particularly limited, and the construction shown in FIG. 3 is merely illustrative. More specifically, the number of layers, the number of nodes, and inter-layer connectivity are hyperparameters that can be explored and turned while training the MLP 300 and / or the underlying model.

[0054] In some embodiments, the MLP 300 includes one or more nodes 302 (neurons) arranged in each of the fully connected layers 304. Nodes 302 in adjacent fully connected layers 304 are connected by weighted edges 310, where the weight of a respective edge represents the strength of the connection between the respective nodes 302. These weights are adjusted during a training phase. In some embodiments, each node 302 in the MLP 300 performs a weighted sum of its inputs, adds a bias term, and then, optionally, applies a non-linear activation function to produce an output. The nonlinear activation function, such as a rectified linear unit (ReLU), sigmoid, or tanh function, can be applied to the outputs of each node 302 to introduce nonlinearity to the resulting output scores.

[0055] Turning now to FIG. 4, in some embodiments, the graph-enhanced semantic RAG system 200 or any other component or subcomponent described herein can be implemented in whole or in part using a transformer architecture, such as those relied upon in some large language models (LLMs). In some embodiments,202419796 transformer 400 includes an encoder 406 trained to generate embeddings (e.g., text / semantic embeddings, node / structural embeddings, etc.). While not meant to be particularly limited, the transformer 400 and / or encoder 406 can include a neural network machine learning architecture that is capable of processing large amounts of text data and generating high-quality natural language responses. In practice, large language models have been used for a wide range of natural language processing (NLP) tasks, including, for example, machine translation, text generation, sentiment analysis, and question answering (i.e., query-and-response). Large language models have also been adapted for other domains, such as computer vision, speech recognition, and software development.

[0056] As shown in FIG. 4, the transformer 400 begins with an input 402. The input 402 denotes an input provided by a user (or upstream system) and can be represented as a sequence of tokens, individual words or sub-words, from which input embeddings 404 can be generated. The input embeddings 404 represent the tokens within the input 402 as numbers, which can be processed using encoder 406. In some embodiments, a positional encoding 408 can be generated to encode the position of each token in input 402 as a set of numbers. These numbers can be fed into the encoder 406 with the input embeddings 404, allowing the transformer-based architecture to more effectively understand the order of words in a sentence and to thereby generate grammatically correct and semantically meaningful outputs.

[0057] The encoder 406 processes the input embeddings 404 and the positional encoding 408 and generates, for the input 402, an encoded representation 410 that captures the meaning and context of the input 402. To accomplish this, encoder 406 applies a series of self-attention transformer layers (or simply, “transformer layers”), which are a series of hidden states that represent the input 402 at different levels of abstraction. The encoder 406 can include any number of these transformer layers, as desired. In some embodiments, the encoded representation 410 is provided to a decoder 412.

[0058] The decoder 412 similarly includes a number of transformer layers, as desired, except that the decoder 412 processes an output 414. In many202419796 implementations, the output 414 is a right-shifted copy of the input 402, meaning that the decoder 412 can only use the previous words for next-token prediction. In some embodiments, output embeddings 416 can be generated from the output 414 to represent the tokens in the output 414 as numbers, in a similar manner as described with respect to the encoder 406. A positional encoding 418 can be added to the output embeddings 416 to encode the position of each token in output 414 as a set of numbers. The decoder 412 can be trained by minimizing a loss function (also known as an objective function, which quantifies a difference between a predicted output and a known true value) using, for example, gradient descent.

[0059] Once trained, the transformer 400 can be used during an inference phase to generate an output 420, which can be thought of as a next-token probability (that is, how likely is the next token in the sequence to be x, or y, etc.). In some configurations, the transformer-based architecture includes a linear layer and softmax layer (omitted for clarity) to transform a raw output from the decoder 412 into the output 414. For example, after the decoder 412 produces a raw output (e.g., output embeddings), the linear layer can map the output embeddings to a higher-dimensional space, thereby transforming the output embeddings into a same original input space as the input 402. The softmax function can be used to generate a probability distribution for each output token in the vocabulary.

[0060] In the current implementation, the input 402 can include a query 204 (refer to FIG. 2) and output 420 and / or encoded representation 410 can include a response 206 (refer, again, to FIG. 2). In other words, transformer 400 can be trained to generate, responsive to receiving input 402 including a query 204, an output 420 (or encoded representation 410 in encoder implementations) including a response 206. In other words, the transformer 400 can be configured to return, responsive to receiving a query 204, a response 206.

[0061] Referring now to FIGS. 5 A and 5B, a flowchart 500 for leveraging graph-enhanced semantic retrieval augmented generation (RAG) for cross domain data in enterprise systems is generally shown according to an embodiment. The flowchart 500 is described with reference to FIGS. 1 to 4 and may include additional202419796 steps not depicted in FIGS. 5 A and 5B. Although depicted in a particular order, the blocks depicted in FIGS. 5A and 5B can be, in some embodiments, rearranged, subdivided, and / or combined. FIG. 5A shows a first portion of the flowchart 500, while FIG. 5B shows a second portion of the flowchart 500. FIGS. 5A and 5B are discussed together for convenience.

[0062] At block 502, the method includes processing a natural language query using a large language model to generate a query intent and a query schema. In some embodiments, the query intent includes domain logical entities and relationships extracted from the natural language query. In some embodiments, the query schema includes a subset of a complete schema of an enterprise knowledge graph corresponding to the query intent.

[0063] At block 504, the method includes generating text embeddings representing the query intent.

[0064] At block 506, the method includes generating node embeddings representing the query schema.

[0065] At block 508, the method includes performing a semantic similarity search by comparing the text embeddings with a set of semantic embeddings of a complete schema of an enterprise knowledge graph corresponding to the query intent to identify a first set of nodes and edges in the enterprise knowledge graph. In some embodiments, the set of semantic embeddings of the complete schema of the enterprise knowledge graph are precomputed during an offline phase, prior to receiving the natural language query.

[0066] At block 510, the method includes performing a structural similarity search by comparing the node embeddings with a set of structural embeddings of the complete schema to identify a second set of nodes and edges in the enterprise knowledge graph. In some embodiments, the set of structural embeddings of the complete schema of the enterprise knowledge graph are precomputed during an offline phase, prior to receiving the natural language query.202419796

[0067] At block 512, the method includes aggregating the first set of nodes and edges with the second set of nodes and edges. In some embodiments, aggregating the first set of nodes and edges with the second set of nodes and edges includes using at least one of a union operation or an intersection operation to produce an aggregated set of nodes and edges.

[0068] At block 514, the method includes building a connected subgraph from the aggregated set of nodes and edges.

[0069] At block 516, the method includes identifying at least one optimal path through the connected subgraph based on a learned cost function that assigns penalties to nodes and edges according to semantic similarity scores and structural similarity scores.

[0070] At block 518, the method includes generating a retrieval augmented generation executable based on the at least one optimal path.

[0071] At block 520, the method includes executing the retrieval augmented generation executable against a database to retrieve contextual data.

[0072] At block 522, the method includes providing, by the large language model and responsive to receiving the natural language query, a response comprising the contextual data.

[0073] In some embodiments, the method includes pruning the connected subgraph using at least one of a graph traversal algorithm and a domain-specific pruning rule to obtain the pruned subgraph.

[0074] While the disclosure has been described with reference to various embodiments, it will be understood by those skilled in the art that changes may be made and equivalents may be substituted for elements thereof without departing from its scope. The various tasks and process steps described herein can be incorporated into a more comprehensive procedure or process having additional steps or functionality not described in detail herein. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the disclosure202419796 without departing from the essential scope thereof. Therefore, it is intended that the present disclosure not be limited to the particular embodiments disclosed, but will include all embodiments falling within the scope thereof.

[0075] Unless defined otherwise, technical and scientific terms used herein have the same meaning as is commonly understood by one of skill in the art to which this disclosure belongs.

[0076] Various embodiments of the present disclosure are described herein with reference to the related drawings. The drawings depicted herein are illustrative. There can be many variations to the diagrams and / or the steps (or operations) described therein without departing from the spirit of the disclosure. For instance, the actions can be performed in a differing order or actions can be added, deleted or modified. All of these variations are considered a part of the present disclosure.

[0077] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, element components, and / or groups thereof. The term “or” means “and / or” unless clearly indicated otherwise by context.

[0078] The terms “received from”, “receiving from”, “passed to”, “passing to”, etc. describe a communication path between two elements and does not imply a direct connection between the elements with no intervening elements / connections therebetween unless specified. A respective communication path can be a direct or indirect communication path.

[0079] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any202419796 structure, material, or act for performing the function in combination with other claimed elements as specifically claimed.

[0080] For the sake of brevity, conventional techniques related to making and using aspects of the present disclosure may or may not be described in detail herein. In particular, various aspects of computing systems and specific computer programs to implement the various technical features described herein are well known. Accordingly, in the interest of brevity, many conventional implementation details are only mentioned briefly herein or are omitted entirely without providing the well- known system and / or process details.

[0081] Embodiments of the present disclosure may be implemented as or as part of a system, a method, and / or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0082] Various embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0083] These computer readable program instructions may be provided to a processor of a special purpose computer to produce a machine, such that the instructions, which execute via the processor of the special purpose computer, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having202419796 instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0084] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0085] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0086] The descriptions of the various embodiments described herein have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the form(s) disclosed. The embodiments were chosen and described in order to best explain the principles of the disclosure. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was202419796 chosen to best explain the principles of the various embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments described herein.

Claims

202419796CLAIMSWhat is claimed is:

1. A method for graph-enhanced semantic retrieval augmented generation of enterprise data responsive to a natural language query, the method comprising: processing a natural language query using a large language model to generate a query intent and a query schema; generating text embeddings representing the query intent; generating node embeddings representing the query schema; performing a semantic similarity search by comparing the text embeddings with a set of semantic embeddings of a complete schema of an enterprise knowledge graph corresponding to the query intent to identify a first set of nodes and edges in the enterprise knowledge graph; performing a structural similarity search by comparing the node embeddings with a set of structural embeddings of the complete schema to identify a second set of nodes and edges in the enterprise knowledge graph; aggregating the first set of nodes and edges with the second set of nodes and edges; building a connected subgraph from the aggregated set of nodes and edges; identifying at least one optimal path through the connected subgraph based on a learned cost function that assigns penalties to nodes and edges according to semantic similarity scores and structural similarity scores; generating a retrieval augmented generation executable based on the at least one optimal path; executing the retrieval augmented generation executable against a database to retrieve contextual data; and202419796 providing, by the large language model and responsive to receiving the natural language query, a response comprising the contextual data.

2. The method of claim 1, wherein the query intent comprises domain logical entities and relationships extracted from the natural language query.

3. The method of claim 2, wherein the query schema comprises a subset of a complete schema of an enterprise knowledge graph corresponding to the query intent.

4. The method of claim 1, wherein the set of semantic embeddings of the complete schema of the enterprise knowledge graph are precomputed during an offline phase, prior to receiving the natural language query.

5. The method of claim 4, wherein the set of structural embeddings of the complete schema of the enterprise knowledge graph are precomputed during an offline phase, prior to receiving the natural language query.

6. The method of claim 1, wherein aggregating the first set of nodes and edges with the second set of nodes and edges comprises using at least one of a union operation or an intersection operation to produce an aggregated set of nodes and edges.

7. The method of claim 1, further comprising pruning the connected subgraph using at least one of a graph traversal algorithm and a domain-specific pruning rule to obtain the pruned subgraph.

8. A system comprising a memory, computer readable instructions, and one or more circuitry for executing the computer readable instructions, the computer readable instructions controlling the one or more circuitry to perform operations comprising: processing a natural language query using a large language model to generate a query intent and a query schema; generating text embeddings representing the query intent;202419796 generating node embeddings representing the query schema; performing a semantic similarity search by comparing the text embeddings with a set of semantic embeddings of a complete schema of an enterprise knowledge graph corresponding to the query intent to identify a first set of nodes and edges in the enterprise knowledge graph; performing a structural similarity search by comparing the node embeddings with a set of structural embeddings of the complete schema to identify a second set of nodes and edges in the enterprise knowledge graph; aggregating the first set of nodes and edges with the second set of nodes and edges; building a connected subgraph from the aggregated set of nodes and edges; identifying at least one optimal path through the connected subgraph based on a learned cost function that assigns penalties to nodes and edges according to semantic similarity scores and structural similarity scores; generating a retrieval augmented generation executable based on the at least one optimal path; executing the retrieval augmented generation executable against a database to retrieve contextual data; and providing, by the large language model and responsive to receiving the natural language query, a response comprising the contextual data.

9. The system of claim 8, wherein the query intent comprises domain logical entities and relationships extracted from the natural language query.

10. The system of claim 9, wherein the query schema comprises a subset of a complete schema of an enterprise knowledge graph corresponding to the query intent.20241979611. The system of claim 8, wherein the set of semantic embeddings of the complete schema of the enterprise knowledge graph are precomputed during an offline phase, prior to receiving the natural language query.

12. The system of claim 11, wherein the set of structural embeddings of the complete schema of the enterprise knowledge graph are precomputed during an offline phase, prior to receiving the natural language query.

13. The system of claim 8, wherein aggregating the first set of nodes and edges with the second set of nodes and edges comprises using at least one of a union operation or an intersection operation to produce an aggregated set of nodes and edges.

14. The system of claim 8, further comprising pruning the connected subgraph using at least one of a graph traversal algorithm and a domain-specific pruning rule to obtain the pruned subgraph.

15. A computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by one or more circuitry to cause the one or more circuitry to perform operations comprising: processing a natural language query using a large language model to generate a query intent and a query schema; generating text embeddings representing the query intent; generating node embeddings representing the query schema; performing a semantic similarity search by comparing the text embeddings with a set of semantic embeddings of a complete schema of an enterprise knowledge graph corresponding to the query intent to identify a first set of nodes and edges in the enterprise knowledge graph;202419796 performing a structural similarity search by comparing the node embeddings with a set of structural embeddings of the complete schema to identify a second set of nodes and edges in the enterprise knowledge graph; aggregating the first set of nodes and edges with the second set of nodes and edges; building a connected subgraph from the aggregated set of nodes and edges; identifying at least one optimal path through the connected subgraph based on a learned cost function that assigns penalties to nodes and edges according to semantic similarity scores and structural similarity scores; generating a retrieval augmented generation executable based on the at least one optimal path; executing the retrieval augmented generation executable against a database to retrieve contextual data; and providing, by the large language model and responsive to receiving the natural language query, a response comprising the contextual data.

16. The computer program product of claim 15, wherein the query intent comprises domain logical entities and relationships extracted from the natural language query.

17. The computer program product of claim 16, wherein the query schema comprises a subset of a complete schema of an enterprise knowledge graph corresponding to the query intent.

18. The computer program product of claim 15, wherein the set of semantic embeddings of the complete schema of the enterprise knowledge graph are precomputed during an offline phase, prior to receiving the natural language query.20241979619. The computer program product of claim 18, wherein the set of structural embeddings of the complete schema of the enterprise knowledge graph are precomputed during an offline phase, prior to receiving the natural language query.

20. The computer program product of claim 15, wherein aggregating the first set of nodes and edges with the second set of nodes and edges comprises using at least one of a union operation or an intersection operation to produce an aggregated set of nodes and edges.

Images