Patent Application
20250104087
The field generally relates to a digital assistant implemented in a large language model context.
Although a wide variety of functionality is available via automated systems to customer service planners and managers, in practice it is difficult to plan and execute service for customers having issues. For example, a plurality of applications may be involved in a typical end-to-end customer service systems that implements various functions to maintain customer satisfaction. Navigating through such applications requires training due to the technical complexity, and transitioning from one application to another and leads to data errors.
Accordingly, there remains a need for improved customer service automation systems.
Customer service in today's environment typically includes invoking automated processing such as enterprise applications that handle complex, interconnected workflows. For example, if a customer is reporting a malfunctioning piece of equipment, an automated workflow can include creating a service order and then downstream processing of the service order, which can involve other workflows until the piece of equipment is repaired.
The workflows can be implemented as actions that perform operations performed on a database. In practice, there can be a variety of applications that serve as front ends by which the workflows are orchestrated. Unfortunately, a user attempting to interact with such a system faces a steep learning curve to become familiar with the particularities of the different applications. Behind the scenes, in the back end, the applications can send API calls to an enterprise database management system to implement the customer service processing. Thus, the system is complex. Adding in other functionality such as service templates, service quotations, service contracts, and the like, increases the complexity.
To add another layer to the complexity, it is often desired to know key performance indicators (KPIs) such as top orders, how long it takes to repair a machine, how many service calls per month are executed, how many service calls are scheduled for next week, and the like. By monitoring such KPIs, an organization can better provision resources to quickly address issues that arise, leading to less equipment downtime. However, in practice, KPIs involve yet another set of applications and another learning curve. Thus, the barrier to entry for a new user can be quite high.
As described herein, a conversational user interface can be presented by which customer service actions can be performed in the context of a unified end-to-end user interface experience. A comprehensive assistant application employing a large language model and APIs can simplify user interaction by offering a seamless natural (e.g., human) language interface. The technologies allow users to effortlessly engage with various APIs while concealing implementation complexities for a smoother experience.
As described herein, natural language conversational input comprising a directive to perform a customer service action can be received in the conversational user interface and forwarded to a large language model that has been trained to recognize intents in incoming input. General inquiries can be handled by the pre-trained large language model, and the large language model can handle a variety of natural languages.
For input that does include a directive to perform a customer service action (e.g., “create an order . . . ”), the large language model can be trained to recognize intents and whether sufficient parameters have been provided. Context can be maintained as the conversation continues (e.g., the large language model asks for missing parameters). When the large language model has sufficient parameters, it can respond with an action and an API payload (e.g., a so-called “command”). The action and API payload can then be sent as an API call to the database management system, which implements the action.
Multiple applications can be supported so that a single user interface is presented for actions spanning multiple applications, leading to a unified customer experience.
As described herein, a lightweight front end can be constructed to accept commands and forward to the service. The service itself can also be lightweight in that it can leverage the large language model to identify intents and output an API payload. The large language model can also provide impressive, robust responses to general queries in any of a number of natural languages.
Other techniques such as supporting KPI queries can be implemented as described herein. Further, machine learning can be leveraged to identify the best service or the appropriate technician based on skills.
The described technologies thus offer considerable improvements over conventional customer service techniques.
The automated customer service assistant service 120 can process the input 115 and be in communication with the pre-trained large language machine learning model 130 to which the service 120 can send a preprocessed version 125 of the input 115.
As described herein, the large language model 130 can be configured to process natural language conversational input comprising a directive to perform a customer service action. The large language model 130 can respond to the input 125 from the service 120 by providing an appropriate response command 135 that comprises both an action 137 and an API payload 138. The service 120 can receive the command 135 and can then invoke an API call 145 based on the action 137 along with the API payload 138 to the database management system 150 to perform the action on the backend data 155. For example, the service 120 can choose the API call to be sent based on a mapping 123 between actions and API calls.
As described herein, the response from the model 130 may not always be a command; as instructed, the model 130 can provide responses to general questions, key performance indicator queries, and the like.
The database management system 150 can then implement the specified action 137 as implemented by the API call 145 with reference to the backend data 155. The result 160 of the API call is then received by the automated customer service assistant service 120, which then processes the result 160 and sends an appropriate response 170 to the natural language conversational input 115 back to the client 110.
The backend data 155 is thus a stored internal representation of customer service objects tracking progress of the customer service objects (e.g., service orders, service confirmations, service templates, service quotations, service contracts, or the like).
Due to the architecture design, the client 110 can be a simple front end, and the automated customer service assistant service 120 can be a lightweight application constructed in a no-code or low-code development environment as described herein. The automated customer service assistant service 120 can receive input 115 of a simple, natural-language format. However, the service 120 can also support input provided in an API call, so a client 110 can be constructed that sends input 115 to the service 120 in the form of an API call.
Although the automated customer service assistant service 120 can appear to provide a powerful set of customer service functionality, it can indeed be constructed as a lightweight service 120 that leverages the power of the large language model 130, while being independent of the model 130. As shown, the service 120 can also include additional machine learning models 130 besides the large language model 130 for performing a variety of tasks related to customer service as described herein.
Communication between the service 120 and the database management system 150 can be accomplished in a variety of ways as described herein. For security purposes, the API calls 145 can be whitelisted (e.g., only API calls from whitelisted sources are accepted).
The preprocessed input 125 can include additional information (e.g., annotations) to assist or prevent manipulation of the model 130. Confidential information can be removed (e.g., replaced with a proxy label). Other measures can be taken to prevent leakage of internal information.
In practice, the large language model 130 can perform intent identification on the incoming input 115 that is relayed as pre-processed input 125. For example, a limited set of customer service actions can be provided as acceptable output actions for the command 135, and the model 130 can identify whether the natural language input 115 is an instruction to perform one of the specified customer service actions. The model 130 can also be trained to respond with a command 135 comprising the customer service action 137 and a payload 138 appropriate for performing the customer service action. For example, the payload 138 can be in JSON format and contain appropriate data (e.g., parameters from the input 115, default parameters, or the like) to perform the action 137 indicated in the input 115 as described herein.
Example customer service actions comprise a command to create a service order, a command to release a service order, a command to create a service confirmation, or a command to complete a service confirmation. As described herein, customer service actions can comprise an equipment-service action. Other customer service actions are possible as described herein.
As described herein, a wide variety of natural language conversational input 115 can be supported. For example, any general question that is not identified as a recognized action can simply be processed by the large language model 130 for a response (e.g., “what is the time difference between Frankfurt and Bangalore?”), and the large language model will respond appropriately (e.g., “The time difference between Frankfurt and Bangalore is 3 hours and 30 minutes. This means that when it is 12:00 noon in Frankfurt, it is 3:30 pm in Bangalore . . . ”).
Also, if more data is needed to perform an action, the task of getting needed parameters can be delegated by the automated customer service assistant service 120 to the large language model 130. For example, if a parameter is missing, the large language model 130 can respond by asking for it, and the service 120 can simply forward the question to the client 110, who then responds with the parameter, which is then forwarded to the model 130 as subsequent input, and context is maintained between the two inputs as described herein so that the command can then be provided by the large language model based on parameters aggregated across the inputs.
Also, the large language model can perform a wide variety of other language-based tasks, such as handling different natural (human) languages. For example, in response to the explanation above, the prompt “En Français” can result in “Francfort est généralement dans le fuseau horaire de l′heure d′Europe centrale (CET), tandis que Bangalore est dans le fuseau horaire de l′heure normale de l′Inde (IST).” Thus, the client 110 can easily switch natural language as appropriate and give robust responses in the source language. Responses to input can be automatically set to be in the natural language of the input (e.g., responsive to receiving input in a given natural language, the response can be in the same, given natural language).
Any of the systems herein, including the system 100, can comprise at least one hardware processor and at least one memory coupled to the at least one hardware processor.
The system 100 can also comprise one or more non-transitory computer-readable media having stored therein computer-executable instructions that, when executed by the computing system, cause the computing system to perform any of the methods described herein.
In practice, the systems shown herein, such as system 100, can vary in complexity, with additional functionality, more complex components, and the like. For example, the service 120 can include a large number of additional models 122, or different large language models 130 can be used for different tasks. There can be additional functionality including a training environment. Additional components can be included to implement security, redundancy, load balancing, report design, and the like.
The described computing systems can be networked via wired or wireless network connections, including the Internet. Alternatively, systems can be connected through an intranet connection (e.g., in a corporate environment, government environment, or the like).
The system 100 and any of the other systems described herein can be implemented in conjunction with any of the hardware components described herein, such as the computing systems described below (e.g., processing units, memory, and the like). In any of the examples herein, the large language model 130, input 115, command 135, payload 138, and the like can be stored in one or more computer-readable storage media or computer-readable storage devices. The technologies described herein can be generic to the specifics of operating systems or hardware and can be applied in any variety of environments to take advantage of the described features.
In the example, at 220, a large language model is configured to process customer service requests. As described herein, tailoring statements can be input to the large language model; as a result, the large language model can recognize intents (actions) in incoming natural language conversational input comprising a directive to perform a customer service action. Such tailoring statements can be sent before a conversation, as part of conversational input, or the like.
The large language model can identify the action in the natural language conversational input via intent recognition. The model can be trained to respond with an action (e.g., an action label) and API payload (e.g., comprising one or more parameters in JSON format or the like as described herein) to perform the action. As described herein, the large language model can be configured with large language model tailoring statements that instruct the large language model to behave as a customer service assistant and process customer service actions. Such statements can instruct the large language model to act as an intent and parameter identifier based on a list of possible customer service actions. Tailoring statements can instruct the large language model to fill in a missing parameter of the action. The tailoring statements can instruct the large language model to answer service questions when a command cannot be determined from the natural language conversational input. The tailoring statements can instruct the large language model to respond to requests for how to perform an action by showing an example. Gap fillers can be shown in the example instead of actual data. The tailoring statements can instruct the large language model to reject behavior-modifying statements. Other tailoring statements are described herein, including one to provide key performance indicator information about customer service objects such as service orders.
At 230 natural language conversational input comprising a directive to perform a customer service action is received from the client. As described herein, a wide variety of input can be supported. In the example, the input comprises a directive to perform a customer service action and results in an API call; however, some commands may be simple general inquiries, KPI requests, or the like.
At 240, the input is forwarded to the large language model. Preprocessing can be performed before sending to the large language model as described herein. Context can be maintained in a conversational user interface so that additional input is received, allowing the large language model to accumulate sufficient information, such as parameters. Thus, a back-and-forth, conversational style of user interface is supported, and the large language model maintains context for subsequent natural language conversational input. Confidential information can be removed from the natural language conversational input before sending to the large language model.
During the conversation, the large language model can perform intent recognition. Due to the way that the large language model has been configured, at some point during the conversation, when sufficient parameters have been received, the large language model outputs an action and API payload with parameters for performing the action. As described herein, such an API payload can be in JSON format.
At 250, responsive to the input received by the large language model, a customer service action and API payload can be received from the large language model. In examples herein, the action and API payload are provided in the form of a command. The large language model has been configured to respond with a command when it can identify a customer service action in the natural language conversational input. As described herein, the large language model may not be able to identify an action, or parameters may be missing. In such cases, the model can respond with something other than a command (e.g., a response to a general query, a request for one or more missing parameters, or the like).
At 260, the action is implemented by invoking an appropriate API call with the API payload. For example, the automated customer service assistant service can maintain a mapping between actions and API calls. Upon receiving an action from the large language model, the service can invoke the API call to which the action is mapped and pass along the API payload. The customer service action is then implemented in the database management system on the underlying data. Although the customer service action can comprise an equipment-service action, such as scheduling a technician to repair a malfunctioning piece of equipment (e.g., in the case of creating a confirmation) as shown in some examples, the technologies need to be so limited. As described herein, a variety of customer service actions can be supported.
The API call typically results in a response indicating success or failure and a possible message. The indication of success can be replied back to the service along with any message, which can then relay a response back to the client.
It is possible that the action fails. For example, a formatting error, inconsistent command, impossible action, or the like can be sent via the API call. However, in such a situation, the action can simply fail, the message provided back to the service, which then relays an appropriate response to the client or takes corrective action.
The actions performed can span applications. So, if the customer service action is a first customer service action and the API call is a first API call for a first application, subsequent natural language conversation input can comprise a directive to perform a second customer service action and results in a second API call to a second application.
The method 200 and any of the other methods described herein can be performed by computer-executable instructions (e.g., causing a computing system to perform the method) stored in one or more computer-readable media (e.g., storage or other tangible media) or stored in one or more computer-readable storage devices. Such methods can be performed in software, firmware, hardware, or combinations thereof. Such methods can be performed at least in part by a computing system (e.g., one or more computing devices).
The illustrated actions can be described from alternative perspectives while still implementing the technologies. For example, receiving a command can be described as sending a command depending on perspective.
In any of the examples herein, the basic flow can be that the user provides input, then the backend processes the input and gets meaningful data from the input. If an action needs to be performed, the data is formatted according to the API specifications, and the corresponding action is completed by the API call. The response from the API call is processed by the backend, and any private data is removed and formatted data is sent to the frontend.
If a conversation is required, user input is directly handled by a large language model API, which responds to the user directly with a conversation.
If a situation is not handled, an appropriate message is provided to the user.
In any of the examples herein, an automated customer service assistant service can be situated behind a client and orchestrate interaction with a large language model to achieve customer service operations.
As described herein, the service can be constructed as a lightweight service that maps actions to API calls, receives responses, and relies on other components of the system to do complex tasks. For example, a service can be constructed using a low-code or no-code development environment such as the SAP Build system of SAP SE of Walldorf, Germany, The Oracle APEX system of Oracle Corporation, Google AppSheet, or the like. For example, the service can determine whether a response from the large language model is a command. If it is a command, the service can invoke the API call and process any response (e.g., to determine what to send back to the client); if it is not a command, the service can simply forward the response back to the client. Error handling and the like can be implemented.
One of the reasons the automated customer service assistant service can be lightweight is that the service can delegate tasks such as getting needed parameters from the client to the large language model. For example, responsive to determining that a parameter is missing, the large language model can request more data to fill in.
The large language model can also be relied upon to fill in missing data fields with default or other appropriate values.
In any of the examples herein, a large language machine learning model (or simply “large language model”) can be used to achieve implementation of an automated customer service assistant. A large language model can take the form of an artificial intelligence or machine learning model that is designed to understand and generate human language. Such models typically leverage deep learning techniques such as transformer-based architectures to process language with a very large number (e.g., billions) of parameters. Examples include the Generative Pre-trained Transformer (GPT) developed by OpenAI (e.g., ChatGPT), Bidirectional Encoder Representations from Transforms (BERT) by Google, A Robustly Optimized BERT Pretraining Approach developed by Facebook AI, Megatron-LM of NVIDIA, or the like. Pretrained models are available from a variety of sources.
As described herein, the large language model can perform functions such as intent identification, conversion of a text command into a format suitable for an API call, and the like. However, the large language model can also perform further functions, such as answering general questions, filling in missing parameters, asking for missing required parameters, and the like.
Also, the conversational nature of the large language model can be used to preserve context so that identifying information need not be repeatedly entered. Whole conversations can be sent to the large language model to maintain context and to provide an interactive user interface. The large language model is thus capable of conversing, where needed information can be extracted from the user via simulated conversation.
In practice, communication with the large language model can be achieved via an API. Thus, the large language model can be hosted by a different party than the party implementing the automated customer service assistant service.
In any of the examples herein, other machine learning models than the large language model can be included. For example, when deciding what type of service, what replacement part is needed, which technician should be scheduled based on ideal skills and availability, the best supplier for a replacement part, or the like, a machine learning model can make a prediction that is used for performing the service (e.g., dispatching the technician).
For example, a technician can be chosen based on past history of service performed at the customer site. When the user provides a Customer Name or ID, the equipment details can be retrieved accordingly, and the best service technician available based on skills and availability near the customer site can be recommended for the Service Order. If a particular service technician has serviced the customer site earlier, the model can recommend the same technician again. Such a recommendation can accelerate the service process because the technician has been to the site before and knows the past history of equipment to be serviced.
Such machine learning models can be provided as part of a platform to facilitate deployment of the appropriate model with suitable parameters (e.g., the SAP Predictive Analysis Library of SAP SE of Walldorf, Germany, or the like).
In practice, such models can be trained on past data to make future predictions. Input features can include those appropriate for the prediction (e.g., equipment type, location, problem code, or the like).
In some cases, the machine learning model may fail to make an accurate prediction. For example, a machine learning model may predict that a technician should be dispatched, but the technician is, in fact, unavailable at the specified time. In such a case, the API call can return an indication of failure, but the failure can be received by the service, which can either return the error to the client or try another technician, another time, or the like.
In any of the examples herein, the technologies can be applied in a service context. For example, in the field of servicing equipment, where a company sends out a technician to fix a piece of malfunctioning equipment, field service or equipment scenarios can be supported. Such scenarios encompass providing on-site support and maintenance for various type of equipment, addressing issues, repairs, and ensuring optimal functionality. Field service technicians can diagnose problems, perform repairs, and ensure that the equipment operates efficiently.
Although described primarily in a service context, the technologies described herein can also be applied to a number of other fields. Such fields can include software development, Enterprise Resource Planning (ERP) systems (e.g., finance, procurement, sales, manufacturing, supply chain management, and the like), Human Capital Management (e.g., employee management, payroll, talent acquisition, performance management, learning and development, and the like), customer experience (e.g., customer relationship management, marketing, sales, service, commerce, and the like), procurement and supply chain management (e.g., sourcing, procurement, supplier management, contract management, spend analysis, and the like), travel and expense management (e.g., booking, expense reporting, invoice processing, and the like), contingent workforce management and services procurement, experience management solutions, analytics, and industry-specific domains such as retail, utilities, automotive, aerospace and defense, and the like. These are only examples, and many other domains can be supported.
In any of the examples herein, the technologies can operate in an environment where actions relating to service are implemented by a variety of applications. For example, there can be an application related to service planning, one for service execution, an application for skills identification, an application for warehouse management, an application for dealing with external suppliers, and the like.
By contrast, the technologies herein can present a single unified application that provides a unified end-to-end customer service experience. For example, the same conversational user interface can be used across multiple different actions. Also, the conversational user interface can remember context so that subsequent commands can be carried out without having to repeat details about the order, and the like.
In any of the examples herein, the client can take the form of a lightweight frontend that receives user input and forwards it to the automated customer service assistant service. In practice, utterances such as typed input, spoken input, or the like can be accepted and transmitted to the service. Thus, a conversational user interface can be supported. The large language model can maintain context so that subsequent commands can refer back to an earlier point in the conversation. For example, “what are the details of the order?” is implicitly asking about the most recent order, so an order number need not be entered. Similarly, “release the order” can release the current order being discussed.
Such a simple conversational interface by the client can encourage more widespread use of the underlying technologies because the user is comfortable conversing with the service. It also reduces the amount of work in that an order number need not be entered repeatedly. In fact, in some scenarios, the order number may not ever need be entered because it is understood that the order number of the current order is to be used.
In practice, the client can forward received input via an API.
In any of the examples herein, the natural language conversational input provided to the automated customer service assistant service can be any directive, question, inquiry, greeting, or the like. Such input can comprise a directive to perform a customer service action. Other examples of input include a general inquiry, a key performance indicator query, or the like as described herein.
Some natural language conversational input can be processed by the large language model without further information from the database management system; other input is recognized by the large language model as a directive to perform a customer service action. For input recognized as a directive to perform an action, the large language model can be configured to respond with a command (e.g., with the action and API payload). Further, the large language model can determine whether sufficient parameters have been provided. If not, further information can be gathered from the client while maintaining context. After sufficient parameters are received, then the large language model responds with the command.
As described herein, the large language model can be instructed to select the action from a universe of acceptable actions in the output action of the command; the model can then accept a wide variety of different inputs that are detected as being directives to perform customer service actions. For example, “grab the order status” can be transformed into “GetOrder” in the output action of the command. A power of the large language model is that it can perform intent recognition and recognize that actions are specified in a large variety of possible input scenarios, including foreign languages (e.g., “obtenez statut de commande” for GetOrder). Even though different words are used, the main idea or intention is the same: GetOrder. Intent recognition is very effective at finding the action instead of focusing on the exact words being used. Thus, the automated assistant can understand what the user wants, even if they ask in different ways. Thus, a user need not be trained in using an exact phrase chosen by the software developers.
When sufficient parameters have been received, the large language model outputs the command. The automated customer service assistant service can then send an appropriate API call to a database management system to perform the action and include the API payload. The action can then be performed on the backend data and a result provided.
As shown herein, natural language conversational input can take any of a variety of forms, such as the following:
In any of the examples herein, any of a number of customer service actions can be supported. Such actions typically take the form of performing a task on customer service data, querying customer service data, or the like. Actions can be performed on various objects (e.g., customer service objects). Example customer service objects comprise service order, service confirmation, service template, service quotation, service contract, and the like. A special object of general or null can also be supported.
For example, for a service order object, actions can include getting a type, getting the status, getting the start date, getting the description, sending mail, releasing, completing, adding an instruction, enquiring, or the like. A special action of null can be supported.
As described herein, the universe of possible actions can be provided to the large language model as action labels so that it responds with a valid action (e.g., one of the action labels) that can be mapped to an API call.
A wide variety of customer service actions can be supported as described herein, including those comprising an equipment-service action that comprises tasks such as dispatching a technician to the physical location of malfunctioning equipment, determining what replacement part is needed, determining which technician should be scheduled, determining the best supplier for a replacement part, and the like.
In the case of dispatching a technician, appropriate messaging can be supported to implement scheduling an on-site visit to repair equipment. For example, scheduling can comprise sending a message (e.g., email, text, or the like) to the technician about the time and location, an appointment can be placed into the technician's schedule, or the like. Also, messaging to the customer can be implemented so that the customer is aware that the technician is arriving and when. As a result, the technician knows where to go and visits the site at the appropriate time. Scheduling can avoid conflicts and take travel time into account.
Although examples focus on service order actions, customer service actions related to the domains of service quotations, service contracts, service orders, and service confirmations can be supported. In practice, different API calls and applications can be involved for the different domains. However, a single conversational user interface can be presented as described herein by which a user can easily navigate between the domains without switching applications that handle the different domains. Thus, multiple applications can be supported with a single conversational user interface to provide a unified end-to-end customer experience.
In any of the examples herein, the large language model can respond with a command when it has sufficient information (e.g., parameters) to do so. As described herein, the command can take a variety of forms. For example, an action can be implemented via a command triplet (e.g., (object, action, data)) that specifies the action, the object upon which the action is to be performed, and the data (e.g., parameters for doing so).
As described herein, the object can be the service object involved. Action can be the action to be performed on the object (e.g., CRUD operations such as Create, Update, Delete and Read). Data can comprise the relevant details that are used to implement the action. Data can have items (e.g., parameters) that have been pre-defined to ChatGPT Tool and data that is extracted by ChatGPT. An alternative format is (object, action, identifier).
Other command formats include (object, filterfield, data) for KPI commands. The KPI commands can result in analytical queries like Revenue KPIs and Orders due for subsequent weeks as described herein. For example, the object can be a business object, and the filterfield can be by which field to query the API (e.g., DueDate, Revenue, and the like). Data can indicate relevant data such as number of records (e.g., top 10 or the like) and days (for queries such as “due next week”).
As described herein, the command can be implemented by invoking an appropriate API, performing queries, or the like.
In any of the examples herein, an application programming interface can accept API calls to perform various functions. In the case of a customer service assistant, such functions can implement customer service actions as described herein. For example, a create method call with parameters to an API can create a service order according to the supplied parameters.
Examples herein include calls to OData APIs because of widespread adoption of the OData interface; however, any of a variety of API call interfaces can be supported.
As shown herein, an API payload with parameters can be included in the API call. Although JSON examples are shown herein (e.g., {“SoldToParty”: “17100013”, “Item”: “SRV_01”}); other formats can be supported as appropriate. For example, the large language model can be shown examples of the desired format or instructed to provide payloads in a specified format.
Communication of the API call and response between the service and the database management system can be accomplished in a variety of ways (e.g., HTTP, TCP, UDP, Websockets, SAP, JSON-RPC, GRPC, or the like).
For security purposes, whitelisted APIs can be supported. In such a scenario, accepted API calls are restricted to those from whitelisted sources (e.g., IP addresses). API calls from other sources are rejected. Thus, the API is called from a source node having a network address, and the network address is whitelisted for the API.
When the automated customer service application service receives an action, it can map the action to an API call (e.g., a method), and then send the API call with the API payload to achieve the specified action (e.g., which was determined based on the directive in the natural language conversational input).
In any of the examples herein, the technology stack can include any backend language (e.g., ABAP, Node JS, or the like) on the server side; for the front end, a low code, no code platform (e.g., SAP Build Apps or the like), a user interface framework (e.g., SAP UI5), and any frontend technology supporting desktop/mobile/tablet clients can be used.
The backend can act as an interface between the large language model, the API implementation, and the front end. User input is passed to the backend, and the backend gets the action intent and completes the action and responds only with the result to the front end.
Some advantages include abstraction of the APIs (e.g., the user need not know about the internal communication to fetch the result or output for the query), minimal training about the enterprise data is required to use the system, and it does not require a front end. The system can act as a standalone API that can be consumed.
The service assistant 320 can include a ChatGPT prompt analyzer 324 that is trained to handle queries and responses to the queries; the analyzer 324 can analyze incoming input, annotate the input, and forward the input to the large language model 340, which provides a response (e.g., command or otherwise). The service assistant 320 can include machine learning models 326 for performing tasks such as determining an appropriate part, technician, and the like. The models 326 can identify the best service to the customer and also the ideal technician based on requisite skills, and the like.
When the large language model 340 responds with an action and API payload, the service ODATA API 322 can make an API call for the action and provide the API payload as part of the API call to the database management system 330. Service transactional data 332 can be updated accordingly.
Product proposals 334 can also be incorporated as appropriate.
In practice, further detail and alternatives can be implemented.
In any of the examples herein, information to be sent to the large language model can be pre-processed for a variety of reasons. For example, confidential information can be removed before sending to the large language model. For example, named entity recognition (NER) can be performed, and information indicated to be associated with a proper name can be replaced with proxy (e.g., dummy) information. When a response comes back, the original proper name can be substituted back in for the proxy information. Thus, confidential information is shielded from the large language model.
Similarly, responses from API calls can be filtered to remove confidential data.
Thus, to prevent leakage of internal data, an external id mapping can be done.
Incoming natural language input can also be annotated as part of pre-processing. Examples of information added to prompts as annotations include those shown herein such as instructions not to accept behavior modifying statements, and other further statements as described herein to define the behavior of the assistant. Language behavior and security measures can also be included.
The user input is passed to the backend, and the backend does the intent classification and returns useful information to SAP Build Apps. The Build apps responds meaningfully by performing an action.
Such an arrangement can be extensible. The frontend functions can be extended indefinitely. Frontend changes require close to no changes in the backend.
In the example, users 410 access a frontend 420 constructed as a collection of SAP Build Apps that interact with an database management system 430. The frontend 420 also interacts with backend service 440, which can interact with an Azure API 450. Service binding 460 can be used to associate actions with services.
In practice, alternatives can be implemented. For example, the frontend 420 can interact with the backend service 440 in a scenario wherein a prompt analyzer interacts with the large language model 450. After the action is identified by the backend service 440 along with API parameter values in JSON format, it can be fed as input to the Service 430 by the Apps 420. Such an arrangement can execute the API call by adjusting the OData API required format and returns the response to the Apps 420. For executing the service, the communication arrangement can be established. In an S/4HANA cloud scenario, such can be achieved through service binding by maintaining the communication arrangement for a published API.
The automated customer service assistant service 520 forwards the input as preprocessed input 525 to the large language model 530, which responds with a command triplet (object, action, data). The data can be provided in the form of an API payload (parameters for an API call). Thus, the large language model 530 responds with an action (“Create”) and an API payload, and the command 535 is sent back to the automated customer service assistant service 520.
As described herein, the service 520 can then analyze the response 535 to determine whether it indicates an API call or a general response. A general response can simply be sent back to the client as a response. However, if an API is indicated (e.g., an API payload is provided), the service 520 can then send an API call appropriate for the action and include the API payload. The automated customer service assistant service 520 can extract the action and payload from the command 535. The API call responds with a result.
The service 520 can analyze the result to determine whether the action was successful and what response 545 to send back to the client.
Thus, as described herein, the automated customer service assistant service can receive the input, preprocess it, send it to the large language model 530, receive a command 535, extract the action and payload, call the API, receive a response, and then send the response 545 back to the client.
In any of the examples herein, the automated customer service assistant can provide key performance indicators (KPIs). As shown herein, KPIs such as top orders by revenue and the like can be provided in response to queries. Thus, the natural language conversational interface can be further leveraged by extending to KPIs.
Statements can include one or more statements 610 instructing the model 630 to behave as a service assistant; one or more statements 612 instructing the model 630 to recognize one or more intents and one or more parameters; one or more statements 614 instructing the model 630 to fill in a missing field of the command; one or more statements 616 instructing the model 630 to answer service questions if a command is not determined; one or more statements 618 instructing the model 630 to reject behavior-modifying statements (e.g., to stop being an automated customer service assistant); and the like.
As described herein, a large language model can be configured to process natural language conversational input comprising a directive to perform a customer service action. Such configuration can be accomplished by inputting prompts to the large language model in the form of tailoring statements. Examples of tailoring statements to tailor a large language model to serve as a component in an automated customer service assistant are given below. In any of the examples, any of the following tailoring statements can be input to the large language model to implement an automated customer service assistant with the large language model.
The tailoring statements can define objects and actions. As shown herein, when provided input, the large language model can respond with a command in a specified format (e.g., [object, action, data], [object, action, identifier]; [object, FilterField, data], where the data is an API payload to perform an action; or the like). Additionally, the large language model is permitted to respond to general questions.
Tailoring statements can take the form of one-shot learning examples, few-shot learning examples, direct instructions, or the like. Roles (e.g., system, user, assistant) can be used as part of the code.
The following statement instructs the model to behave as a service assistant. The large language model can be instructed to use a particular format for the commands it provides. The large language model can be instructed not to show the response command when mentioning the history. The large language model can be instructed to put the API payload in JSON format. The large language model can be instructed to preserve context (e.g., when forming the data, add id and source values as fields with the values as previously mentioned, to use the source object from the conversation, and the like).
The large language model can be instructed to answer service questions or carry out conversations when a command cannot be determined from the input; to perform only one command per statements; and the like.
The possible values for objects can be provided (e.g., service order, service confirmation, service template, service quotation, service contract, general, null, or the like). The possible values for action can be provided (e.g., get type, get status, get start date, get description, send mail, release, complete, add instruction, enquire, null, or the like).
The large language model can be instructed to ask for an identifier when an object and action are determined, but an identifier is not available.
The large language model can be instructed to remember the context when a command is predicted.
The LLM will indeed perform what it is instructed to do when processing input.
The following statements can implement such features. Although an example of Object, Action,id is shown, Object, Action,Data can be used.
The following statement instructs the model to fill in fields in a create action:
Further statements are as follows:
A sidebar interface 740 can be provided to switch between entering commands, showing a history, showing KPIs, or the like.
In
In
In
In
The service order can be created by entering the customer id (or customer name) along with the service product (the best service can be identified internally through machine learning if no product is entered).
In
In
In
In
In
In
In
In
Service Orders that are due for service by next week can be listed in descending order of Service Order ID (e.g., the most recently created service that is due for service is listed first, followed by the next service order).
The “top 5” orders can be the ones with the maximum revenue generated for the company, which can be calculated from the Net Value on each order. Among the open service orders, the high revenue generating ones are important for a company; therefore, the top 5 ones by revenue can displayed (e.g., $1,000, $4,350, $3,675, $2,500, $1,500) to help the planner prioritize activity or attention.
Prompt training can be performed so that the large language model recognizes commands and outputs the appropriate business context text.
In the example, a service order is created. For example, for create service order 2130, a new service order for customer service can be created, assigned a unique identifier, and associated parameters can be stored with the record in the database. An example scenario for service order creation is when malfunctioning equipment is identified, and production is affected. The ultimate goal is to repair the equipment and resume production. Therefore, time is of the essence. Other scenarios are possible.
At 2140, the service order is released. Upon release, the order is essentially made active. Work can begin on obtaining parts, setting expectations, and the like.
At 2150, a confirmation is created. The confirmation action can include assigning and dispatching a technician to the site of the customer service incident (e.g., to repair a malfunctioning piece of equipment). As described herein, a machine learning model can be trained to predict the best technician for the job.
At 2160, the confirmation is completed. Completion indicates that the equipment is repaired and in working order.
Although not shown, in practice, significant back and forth can take place to accomplish the workflow. Because multiple natural languages are supported, it is possible for the workflow to be started by one user who knows a first language (e.g., English), and the workflow can be completed by another user with another language (e.g., a French-speaking technician who repairs the equipment on site).
As noted above, the different operations can ordinarily be performed with different applications that present different user interfaces (e.g., via different client front ends or the same basic web interface). However, leveraging the conversational user interface and the large language model as described herein can reduce the barriers to entry and make the workflow more accessible to users.
Any of the following can be implemented.
Clause 1. A computer-implemented method comprising:
Clause 2. The method of Clause 1, wherein:
Clause 3. The method of any one of Clauses 1-2, wherein:
Clause 4. The method of any one of Clauses 1-3, wherein:
Clause 5. The method of any one of Clauses 1-4, further comprising:
Clause 6. The method of any one of Clauses 1-5, wherein:
Clause 7. The method of any one of Clauses 1-6, wherein:
Clause 8. The method of any one of Clauses 1-7, wherein:
Clause 9. The method of any one of Clauses 1-8, wherein:
Clause 10. The method of Clause 9, wherein:
Clause 11. The method of any one of Clauses 9-10, wherein:
Clause 12. The method of any one of Clauses 9-11, wherein:
Clause 13. The method of any one of Clauses 9-12, wherein:
Clause 14. The method of Clause 13, wherein:
Clause 15. The method of any one of Clauses 13-14, wherein:
Clause 16. The method of any one of Clauses 13-15, wherein:
Clause 17. A computing system comprising:
Clause 18. The computing system of Clause 17 wherein:
Clause 19. The computing system of any one of Clauses 17-18 wherein:
Clause 20. One or more non-transitory computer-readable media comprising computer-executable instructions that, when executed by a computing system, cause the computing system to perform operations comprising:
Clause 21. One or more non-transitory computer-readable media comprising computer-executable instructions that, when executed by a computing system, cause the computing system to perform the method of any one of Clauses 1-16.
A number of advantages can be achieved via the technologies described herein. For example, because the user is able to interact with the automated customer service assistant in a conversational, natural language interface, it is possible for new users to immediately begin using the system without training or experience. There is thus an increased level of customer usability.
Faster resolution of customer service issues can be expected, both because the software avoids bottlenecks due to being accessible by more users and the software can match the best technician to the service order. Also, miscommunication can be avoided because so many natural languages can be supported.
Security is enhanced because the underlying business processes cannot be derived from the conversational user interface.
Software development errors can be avoided because the large language model can be used to generate the API payload instead of having to manually code such generation.
Finally, an easy-to-use, efficient automated customer service assistant results in overall higher customer satisfaction.
With reference to
A computing system 2200 can have additional features. For example, the computing system 2200 includes storage 2240, one or more input devices 2250, one or more output devices 2260, and one or more communication connections 2270, including input devices, output devices, and communication connections for interacting with a user. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing system 2200. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing system 2200, and coordinates activities of the components of the computing system 2200.
The tangible storage 2240 can be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium which can be used to store information in a non-transitory way and which can be accessed within the computing system 2200. The storage 2240 stores instructions for the software 2280 implementing one or more innovations described herein.
The input device(s) 2250 can be an input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, touch device (e.g., touchpad, display, or the like) or another device that provides input to the computing system 2200. The output device(s) 2260 can be a display, printer, speaker, CD-writer, or another device that provides output from the computing system 2200.
The communication connection(s) 2270 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video input or output, 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 can use an electrical, optical, RF, or other carrier.
The innovations can be described in the context of computer-executable instructions, such as those included in program modules, being executed in a computing system on a target real or virtual processor (e.g., which is ultimately executed on one or more hardware processors). Generally, program modules or components include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules can be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules can be executed within a local or distributed computing system.
For the sake of presentation, the detailed description uses terms like “determine” and “use” to describe computer operations in a computing system. These terms are high-level descriptions for operations performed by a computer and should not be confused with acts performed by a human being. The actual computer operations corresponding to these terms vary depending on implementation.
Any of the computer-readable media herein can be non-transitory (e.g., volatile memory such as DRAM or SRAM, nonvolatile memory such as magnetic storage, optical storage, or the like) and/or tangible. Any of the storing actions described herein can be implemented by storing in one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Any of the things (e.g., data created and used during implementation) described as stored can be stored in one or more computer-readable media (e.g., computer-readable storage media or other tangible media). Computer-readable media can be limited to implementations not consisting of a signal.
Any of the methods described herein can be implemented by computer-executable instructions in (e.g., stored on, encoded on, or the like) one or more computer-readable media (e.g., computer-readable storage media or other tangible media) or one or more computer-readable storage devices (e.g., memory, magnetic storage, optical storage, or the like). Such instructions can cause a computing system to perform the method. The technologies described herein can be implemented in a variety of programming languages.
The cloud computing services 2310 are utilized by various types of computing devices (e.g., client computing devices), such as computing devices 2320, 2322, and 2324. For example, the computing devices (e.g., 2320, 2322, and 2324) can be computers (e.g., desktop or laptop computers), mobile devices (e.g., tablet computers or smart phones), or other types of computing devices. For example, the computing devices (e.g., 2320, 2322, and 2324) can utilize the cloud computing services 2310 to perform computing operations (e.g., data processing, data storage, and the like).
In practice, cloud-based, on-premises-based, or hybrid scenarios can be supported.
Although the operations of some of the disclosed methods are described in a particular, sequential order for convenient presentation, such manner of description encompasses rearrangement, unless a particular ordering is required by specific language set forth herein. For example, operations described sequentially can in some cases be rearranged or performed concurrently.
The technologies from any example can be combined with the technologies described in any one or more of the other examples. In view of the many possible embodiments to which the principles of the disclosed technology can be applied, it should be recognized that the illustrated embodiments are examples of the disclosed technology and should not be taken as a limitation on the scope of the disclosed technology. Rather, the scope of the disclosed technology includes what is covered by the scope and spirit of the following claims.
