Search

US-12625896-B1 - Chatbot access to ERP data using large language model with intermediate query representation

US12625896B1US 12625896 B1US12625896 B1US 12625896B1US-12625896-B1

Abstract

In an example embodiment, a design-time environment and a run-time environment. The design-time environment helps developers create and maintain configuration and other information that can be formed into chatbot runtime capabilities more easily. Developers can define what data can be accessed and how the data is to be filtered or displayed. The run-time environment is where the interaction with the user happens. When a user inputs a query, the system translates the query into a structured format that the enterprise resource planning (ERP) system can understand. This involves several steps, including identifying a capability that matches the query, generating a prompt for a large language model (using the capability), receiving an intermediate query representation, converting the intermediate query representation into a query, executing the query, and then processing the results to present them to the user.

Inventors

  • Christoph Meyer
  • Martin Zuber
  • Xiang Yu
  • Manuel Zeise
  • Isil Pekel
  • Zahra Zamansani
  • Leslie Zanon
  • Tanguy Lucci
  • Hassan El Hajj
  • Nikolay Grechanov

Assignees

  • SAP SE

Dates

Publication Date
20260512
Application Date
20250310

Claims (20)

  1. 1 . A system comprising: at least one hardware processor; a non-transitory computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations comprising: receiving a natural language request via a chatbot user interface; matching the natural language request to a first scenario of a plurality of scenarios managed by a chatbot runtime, the first scenario generated based on a query configuration and defining three functions for accessing data in an Enterprise Resource Planning (ERP) system, the query configuration specifying a target query language for the ERP system; and executing a first function of the three functions, causing a query runtime to: generate a first prompt using the natural language request and the first scenario, the first prompt comprising a description of an intermediate query representation tailored to a scope of the target query language specified by the first scenario; send the first prompt to a Large Language Model (LLM); receive the intermediate query representation in a language not run by the ERP system; and deterministically convert the intermediate query representation into a query, in the target query language corresponding to the ERP system; executing a second function of the three functions, causing the query runtime to run the query on the ERP system to retrieve ERP data; and executing a third function of the three functions, causing the query runtime to render the ERP data in the chatbot user interface.
  2. 2 . The system of claim 1 , wherein the first scenario additionally defines a first user interface configuration, and wherein the executing of the third function further comprises altering display parameters of the chatbot user interface based on the first user interface configuration.
  3. 3 . The system of claim 1 , wherein the first prompt further comprises one or more hints provided by a designer of the first scenario, the one or more hints comprising at least one definition, not available in a data model of the first scenario, of one or more terms.
  4. 4 . The system of claim 1 , wherein the first prompt further comprises an application context.
  5. 5 . The system of claim 1 , wherein the first prompt further comprises past elements of a conversation in the chatbot user interface.
  6. 6 . The system of claim 1 , wherein the intermediate query representation comprises filter predicates, aggregation predicates, and filter structure, the filter structure defining whether filter presentation is a complex nested structure.
  7. 7 . The system of claim 6 , wherein the converting comprises storing the filter structure as an abstract syntax tree, translating each atomic condition in the abstract syntax tree to an atomic condition in the language, and converting the abstract syntax tree into a Boolean expression.
  8. 8 . A method comprising: receiving a natural language request via a chatbot user interface; matching the natural language request to a first scenario of a plurality of scenarios managed by a chatbot runtime, the first scenario generated based on a query configuration and defining three functions for accessing data in an Enterprise Resource Planning (ERP) system, the query configuration specifying a target query language for the ERP system; and executing a first function of the three functions, causing a query runtime to: generate a first prompt using the natural language request and the first scenario, the first prompt comprising a description of an intermediate query representation tailored to a scope of the target query language specified by the first scenario; send the first prompt to a Large Language Model (LLM); receive the intermediate query representation in a language not run by the ERP system; and deterministically convert the intermediate query representation into a query, in the target query language corresponding to the ERP system; executing a second function of the three functions, causing the query runtime to run the query on the ERP system to retrieve ERP data; and executing a third function of the three functions, causing the query runtime to render the ERP data in the chatbot user interface.
  9. 9 . The method of claim 8 , wherein the first scenario additionally defines a first user interface configuration, and wherein the executing of the third function further comprises altering display parameters of the chatbot user interface based on the first user interface configuration.
  10. 10 . The method of claim 8 , wherein the first prompt further comprises one or more hints provided by a designer of the first scenario, the one or more hints comprising at least one definition, not available in a data model of the first scenario, of one or more terms.
  11. 11 . The method of claim 8 , wherein the first prompt further comprises an application context.
  12. 12 . The method of claim 8 , wherein the first prompt further comprises past elements of a conversation in the chatbot user interface.
  13. 13 . The method of claim 8 , wherein the intermediate query representation comprises filter predicates, aggregation predicates, and filter structure, the filter structure defining whether filter presentation is a complex nested structure.
  14. 14 . The method of claim 13 , wherein the converting comprises storing the filter structure as an abstract syntax tree, translating each atomic condition in the abstract syntax tree to an atomic condition in the language, and converting the abstract syntax tree into a Boolean expression.
  15. 15 . A non-transitory machine-readable medium storing instructions which, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving a natural language request via a chatbot user interface; matching the natural language request to a first scenario of a plurality of scenarios managed by a chatbot runtime, the first scenario generated based on a query configuration and defining three functions for accessing data in an Enterprise Resource Planning (ERP) system, the query configuration specifying a target query language for the ERP system; and executing a first function of the three functions, causing a query runtime to: generate a first prompt using the natural language request and the first scenario, the first prompt comprising a description of an intermediate query representation tailored to a scope of the target query language specified by the first scenario; send the first prompt to a Large Language Model (LLM); receive the intermediate query representation in a language not run by the ERP system; and deterministically convert the intermediate query representation into a query, in the target query language corresponding to the ERP system; executing a second function of the three functions, causing the query runtime to run the query on the ERP system to retrieve ERP data; and executing a third function of the three functions, causing the query runtime to render the ERP data in the chatbot user interface.
  16. 16 . The non-transitory machine-readable medium of claim 15 , wherein the first scenario additionally defines a first user interface configuration, and wherein the executing of the third function further comprises altering display parameters of the chatbot user interface based on the first user interface configuration.
  17. 17 . The non-transitory machine-readable medium of claim 15 , wherein the first prompt further comprises one or more hints provided by a designer of the first scenario, the one or more hints comprising at least one definition, not available in a data model of the first scenario, of one or more terms.
  18. 18 . The non-transitory machine-readable medium of claim 15 , wherein the first prompt further comprises an application context.
  19. 19 . The non-transitory machine-readable medium of claim 15 , wherein the first prompt further comprises past elements of a conversation in the chatbot user interface.
  20. 20 . The non-transitory machine-readable medium of claim 15 , wherein the intermediate query representation comprises filter predicates, aggregation predicates, and filter structure, the filter structure defining whether filter presentation is a complex nested structure.

Description

TECHNICAL FIELD Embodiments pertain to artificial intelligence and, in some examples, to natural language processing systems for interacting with enterprise resource planning (ERP) data. BACKGROUND In a computer system, software servers are often used to manage applications that interact with one or more software clients over a computer network, such as the Internet. An OData server is a type of web server that implements the Open Data Protocol (OData) to enable the creation and consumption of RESTful Application Program Interfaces (APIs) for data sources. OData is a protocol for creating and consuming data APIs that are consistent with RESTful principles and expose data as resources that can be accessed using standard HyperText Transfer Protocol (HTTP) methods like GET, POST, PUT, PATCH and DELETE. An OData server allows developers to expose data from various sources such as databases, file systems, or web services as OData feeds, which can be consumed by client applications. The OData server maps the HTTP requests to the corresponding data operations and returns the data in a standardized format, typically JavaScript Object Notation (JSON) or Extensible Markup Language (XML). OData servers are used in various contexts, such as enterprise data integration, business intelligence, and mobile application development. They enable the creation of scalable and flexible APIs that can be consumed by a wide range of clients, including web and mobile applications, desktop software, and other backend systems. BRIEF DESCRIPTION OF THE DRAWINGS The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements. FIG. 1 is a block diagram illustrating a system for converting a natural language query into an ERP query, in accordance with an example embodiment. FIG. 2 is a diagram illustrating an example of LLM-provided test cases, in accordance with an example embodiment. FIG. 3 is a screen capture illustrating an example of user interface configuration aspects that can be specified by the developer. FIG. 4 illustrates a comprehensive test without any filter condition, in accordance with an example embodiment. FIG. 5 is a diagram illustrating a screen capture of a user interface in which a developer can select the properties and navigation properties that are later accessible to the user. FIG. 6 is a screen capture illustrating an example of the rendered user interface, in accordance with an example embodiment. FIG. 7 is a flow diagram illustrating a method of accessing an ERP system in a chatbot using an LLM, in accordance with an example embodiment. FIG. 8 is a block diagram illustrating a software architecture, in accordance with an example embodiment. FIG. 9 illustrates a diagrammatic representation of a machine in the form of a computer system within which a set of instructions may be executed for causing the machine to perform any one or more of the methodologies discussed herein. DETAILED DESCRIPTION The description that follows discusses illustrative systems, methods, techniques, instruction sequences, and computing machine program products. In the following description, for purposes of explanation, numerous specific details are set forth to provide an understanding of various example embodiments of the present subject matter. It will be evident, however, to those skilled in the art, that various example embodiments of the present subject matter may be practiced without these specific details. Enterprise resource planning (ERP) systems are designed to manage and integrate various business processes through a centralized application. These systems facilitate the flow of information across different departments, such as finance, human resources, and supply chain management, by providing a unified platform for data management and reporting. A common challenge in ERP systems is the complexity of data retrieval and interaction. Users often need to access and manipulate large volumes of data stored in diverse formats and structures. This requires the use of structured query languages and a deep understanding of the underlying data models, which can be cumbersome and time-consuming. The described examples focus on a technology called NL2Query, which is designed to improve chatbots to allow people to interact with complex data systems, specifically in the context of ERP systems. This technology allows users to communicate with these systems using natural language, like the way one would talk to a person, and then translates that input into a structured query that the system can understand and process. The “Joule chatbot” is a digital assistant developed by SAP SE of Walldorf, Germany, to assist users in interacting with their ERP systems in a more user-friendly manner. Consider the Joule chatbot as a smart helper that users can communicate with, either by typing or speaking, to obtain information or perform tasks within