System and method for generating automated response to user request in natural language

Abstract

FIELD: information technology.SUBSTANCE: method for generating an automated response to a user query in natural language, implemented by a system for generating an automated response to a user query in natural language, includes the following stages: from the user's terminal equipment, the user query in natural language is transmitted to the server; on the server, the user query is sent to the Request Processing Unit, from where it is forwarded to the Legitimacy Verification Unit; in the Legitimacy Verification Unit, the user query is compared with the pre-established requirements for the user query; if the Legitimacy Verification Unit detects a discrepancy between the user query received from the Request Processing Unit, the Legitimacy Verification Unit sends a message to the user's terminal equipment about the impossibility of providing a response to the user query; if compliance with the requirements established in the Legitimacy Verification Unit is detected, the user query is sent from the Legitimacy Verification Unit to the Request Processing Unit; after returning from the Legitimacy Verification Unit to the Request Processing Unit, the user query is sent to the Scenario Selection Unit and the user query is sent from the Scenario Selection Unit to the selected Scenario.EFFECT: increasing the accuracy of the automated response to the user's request, as well as reducing the response time.20 cl, 1 dwg

Description

[0001] FIELD OF TECHNOLOGY

[0002] The present invention relates to the field of information technology in general, and in particular to systems and methods that can provide automated responses to user queries in natural language in real time.

[0003] STATE OF THE ART

[0004] Currently, businesses face a pressing need to quickly obtain high-quality answers to questions across various fields in order to expedite the process of solving business problems. This problem is being addressed by the emergence of systems that provide automated responses to user questions. Many systems use neural networks to solve this problem. However, existing systems of this kind lack a built-in self-checking feature to adjust responses to queries in the event of an error, which would allow for continuous improvement and refinement based on user queries. Furthermore, retraining neural networks in such cases requires significant resources and training data and does not meet the goal of continuous automated improvement, as it is performed ad hoc based on user requests.In addition, existing automated response systems suffer from a lack of processing of the request at the stage of moving to the database in order to correctly access the database to obtain a high-quality response.

[0005] Thus, the prior art discloses a solution called "Artificial Intelligence-Based Network Assistant" (RU201814532 3A, class G06F15 / 00, published on 07 / 09 / 2020), which identifies a problem affecting network performance in one or more areas with low performance, analyzes performance data using a trainable machine learning model to identify a predicted root cause of a problem affecting network performance based on one or more symptoms associated with the problem, wherein the trainable machine learning model uses multiple types of machine learning algorithms to analyze performance data, wherein the performance data contains real-time data or non-real-time data for a specific time interval, provides a predicted root cause for presentation through a user interface, based on the performance data of one or more network components,user device performance data, social media data, alarm data, troubleshooting request data, or key performance indicator data are used to recommend a series of actions using a trained machine learning model to resolve the issue based on the predicted root cause.

[0006] The prior art also includes the invention “System for answering questions from different fields of knowledge in real time” (RU2 747 425, cl. G06F 16 / 23 (2019.01), G06F 16 / 90 (2019.01), G06N 5 / 04 (2006.01), published 24.11.2020), in which the system for automated question answering comprises a semantic space formed from a corpus of questions and answers, a user interface configured to receive a question, a processor comprising a question decomposition engine configured to decompose the question into a knowledge area, a keyword, and a focus word, a question similarity generator configured to identify one or more questions in the semantic space using the decomposed question, an answer extraction and ranking engine configured to extract from the semantic space one or more answers associated with one or more identified questions, identifying one or more extracted answers as the best answer, and an answer refinement engine. The automated question-answering system receives a user's question and extracts one or more knowledge areas, focus words, and / or keywords.The system compares the decomposed question across the entire semantic space and identifies stored questions that are highly similar to the question posed. The system then extracts the answers to these questions that are most similar to the question posed and ranks these answers based on their similarity or overlap with the extracted focus words and knowledge domains. The best answer is identified and presented to the user.

[0007] The closest analogue of the present invention is the invention known from the prior art as "A method for searching for methods for resolving technical contradictions and a system based on a trainable neural network for its implementation" (RU2707917, class G06N 5 / 02 (2006.01), published on 02.12.2019), which includes a method for searching for methods for resolving technical contradictions, including an analysis of known information on technical contradictions from various fields of technology, methods for solving inventive problems using logical analysis and issuing recommendations in response to a user request, which is characterized by the fact that a user request is entered into the system in the interface language, the interface language with the user request is recognized and translated into a request code, then an algorithm is created for generating a request code, priorities are formed for training the neural network, after which further training of the neural network is carried out according to the parameters corresponding to the request code,and search for methods of resolving technical contradictions using a retrained neural network using the principles of morphological analysis and fuzzy logic, for which purpose a group of basic technical and / or social and / or economic characteristics is identified in the product or object corresponding to the query code, while the neural network forms stable relationships between the characteristics of the item corresponding to the query code and its technical and / or social and / or economic characteristics, then the neural network establishes relationships between the item under study and its mention in patent databases and each set of relationships is formed in its own information space, after which, using the morphological design method, a set of matrices is formed, each of which is formed by ordered searches through an exhaustive and final list of technical and / or social and / or economic characteristics of the item,taken into account when applying technical solutions by establishing the type of relationship between them, after which, based on the recorded relationships, a ranking system is created, which is the basis for generating a detailed response to the request, after which the response code is generated, translated into the interface language and the response is given to the user of the system.

[0008] The main shortcomings of prior art solutions are as follows. In the technical solutions studied in the prior art, automated responses to queries are provided by selecting (searching through) pre-defined data already in the system, which is then enriched with only some additional information from various sources. However, the problem of analyzing the correctness of responses to automated user queries remains unresolved; i.e., self-checking and, therefore, response correction are not performed. The closest analogue already includes additional training of the neural network based on parameters corresponding to the query code, and searches for methods to resolve technical contradictions using the additionally trained neural network. However, this technical solution, despite performing a search based on newly created parameters, still lacks the ability for the system to self-correct and, therefore, continuously improve and develop itself automatically.Moreover, the solution described in the analog requires significantly more resources and training data for further training of the neural network compared to the solution presented in this description, as well as more time for adjustments. Furthermore, existing technical solutions for creating user question-answering systems are insufficiently effective in automatically preparing user queries for direct transmission to a database or other storage where information for the response will be selected, which subsequently impacts the quality of the response. The technical solution disclosed in this description addresses the technical issues raised here.

[0009] DISCLOSURE OF THE INVENTION

[0010] The technical problem that the present invention is aimed at solving is the creation of a system and method for an automated response to a user request in natural language, which allows the system to be continuously refined and self-corrected in automatic mode, firstly, in the process of working on the user request and DSL request, bringing them to a language understandable to the system, and secondly, by analyzing and correcting errors in the presentation of the response to the user request.

[0011] The technical results achieved during the implementation of the present invention are:

[0012] - obtaining information through semantic processing of natural language text;

[0013] -improving the accuracy of automated response to user request;

[0014] -speeding up the delivery of an accurate answer to the user’s request;

[0015] -speed up the process of changing system settings to provide the correct automated response to the user's request;

[0016] - enhancing system data protection;

[0017] - increasing the performance of the hardware and software complex due to the absence of the need for resource-intensive additional training of the neural network in the hardware and software complex when receiving feedback from the user's terminal equipment, which saves the amount of RAM.

[0018] The purpose of the invention is to create a system and method for automated response to a user request in natural language with the ability to self-correct and automatically refine the user request and DSL request, as well as the system itself.

[0019] The system for generating an automated response to a user request is a hardware and software complex and includes:

[0020] - at least one user terminal equipment connected to at least one server;

[0021] - at least one server configured to connect to the user's terminal equipment for the purpose of receiving, transmitting and processing user requests in natural language on the server, with the possibility of having on the server at least one Request Processing Unit, at least one Legitimacy Check Unit, at least one Scenario Selection Unit, with the possibility of installing on the server at least one machine-readable medium with at least one computer program installed thereon - the Scenario, with the possibility of having on the server at least one Hint Unit, Example Unit, Vector Storage, at least one Request Generation Unit, at least one Request Correction Unit, at least one Database, at least one Response Generation Unit, at least one Feedback Unit;

[0022] - A request processing unit installed on the server and configured to receive a user request in natural language from the user's terminal equipment, forward the user request to the Legitimacy Verification Unit, receive back the user request from the Legitimacy Verification Unit, and forward the user request to the Scenario Selection Unit;

[0023] - Legitimacy Check Unit installed on the server and configured with the ability to add to the Legitimacy Check Unit requirements for a user request in natural language and for a DSL request in the form of a set of legitimacy check rules, which can include both text signatures and conditions for determining membership in a class of legitimacy or illegitimacy using a machine learning model executed (machine learning models) with the ability to classify a user request as legitimate or illegitimate, with the ability (Legitimacy Check Unit) to save the specified requirements in the Database, with the ability to call the specified requirements from the Database to the Legitimacy Check Unit, with the ability to receive a user request from the Request Processing Unit, with the ability to check the user request for compliance with the requirements for a user request in natural language,sending a user request to the Request Processing Unit in the event of a positive check, sending a response about the impossibility of processing the user request to the user's terminal equipment in the event of a request not meeting the request requirements, with the ability (Legitimacy Verification Unit) to receive a DSL request from the Request Correction Unit, with the ability to check the DSL request for compliance with the DSL request requirements, returning the DSL request to the Request Correction Unit in the event of a positive check, sending a response about the impossibility of processing the DSL request to the user's terminal device in the event of a request not meeting the request requirements established in the Legitimacy Verification Unit;

[0024] - A Scenario Selection Block that operates on the basis of a neural network implemented (the neural network) with the ability to learn to classify user requests based on examples of user requests, as well as with the ability to further classify user requests by determining the structure of the request and determine requests to a particular Scenario, with the ability (the Scenario Selection Block) to assign to a user request an identifier (for example, any number, a set of information) of a specific Scenario, which the Scenario Selection Block received from a new Scenario when it accessed the Scenario Selection Block, installed (the Scenario Selection Block) in the Request Processing Block and configured to receive from the Request Processing Block a user request, with the ability (the Scenario Selection Block) to select a Scenario, assign a Scenario identifier to a user request, direct the user request to the selected Scenario,with the ability to receive a message from the new Scenario about the presence of a new Scenario on the Machine-readable medium and with the ability to receive from the new Scenario the Scenario identifier and examples of user requests, on which the Scenario Selection Unit, operating on the basis of a neural network, is further trained to accept requests for this Scenario, with the ability (the Scenario Selection Unit) to further train itself to automatically select a new Scenario after receiving examples of user requests and an identifier from the new Scenario;

[0025] - A machine-readable storage medium, configured with the ability to load a computer program – a Script – onto the machine-readable medium, with the ability to add new Scripts to the machine-readable medium;

[0026] - at least one Scenario, which is a computer program, designed with the ability to create in the source code of the Scenario a Scenario identifier, with the ability to interact with user queries in natural language related to this Scenario, for the purpose of forming this Scenario, a Database Table schema, a set of dictionaries of the Hint Block, each of which relates to a certain Scenario, a set of user queries and DSL queries of the Example Block, formed in groups for each Scenario, with the ability to transmit user queries to the Scenario Selection Block, on which the Scenario Selection Block is further trained to accept queries to this Scenario, executed (Scenario) with the ability, upon receiving a request from the Scenario Selection Block, to send a user query in natural language to the Hint Block to certain dictionaries related to this Scenario, and to receive from the Hint Block a corrected user query,send a request to the Example Block for specific examples related to the given Scenario and receive relevant examples from the Example Block; after receiving the adjusted user query in natural language and relevant examples, send the user query to the DSL Query Generation Block together with the Database Record Table schema, with the ability (Scenario) to send messages from the new Scenario to the Scenario Selection Block about the creation of a new Scenario and with the ability to send examples of user queries to the Scenario Selection Block for its further training; with the ability (Scenario) to receive from the Feedback Block a user response from the terminal equipment about the discrepancy between the user's response and the user query and the "user query - DSL query" pair; in this case, send the original user query in natural language to the Hint Block and receive from the Hint Block the adjusted user query,send the original user query to the Example Block and receive relevant examples from the Example Block, send the corrected user query, relevant examples, the Database Record Table schema, and the natural language user query - DSL query pair about which a mismatch message was sent to the DSL Query Generation Block so that when generating a new DSL query, the DSL Query Generation Block sees the previous "incorrect" DSL query and takes it into account when generating a new DSL query;

[0027] - A suggestion block installed on the server and configured to install words in the suggestion block in the form of a set of dictionaries, each of which relates to a specific Scenario and consists of a pair of "designation variant - unified value", where the designation variant is a word or phrase that can be used by the user in a query in its natural form (for example: "flash drive", "flash drive"), and the unified value is a standard term corresponding to records in the Database Table, with the ability (the suggestion block) to replace words in the user query with pre-set unified words in the suggestion block that correspond in semantic meaning to the words in the user query, and return the adjusted user query to the Scenario.The system uses the appropriate dictionary to check the user's query: if a match is found for the "designation variant", the "unified value" is substituted into the query.

[0028] - An example block installed on the server and representing a set of pairs of "user query in natural language and DSL query" (hereinafter may be called "example, examples"), implemented (Example Block) with the ability to receive a user query from the Scenario, extract a semantic vector from it, send the semantic vector of the user query to the Vector Storage to search for the closest semantic vector of another user query in terms of proximity (for example, by cosine proximity), and, when the closest semantic vector of another user query is found in the Vector Storage, call the relevant and previously saved pair of "user query, close in proximity to the original user query - DSL query, corresponding to the closest in proximity user query",return (Example Block) the original user query with relevant examples to the Scenario if relevant examples are available; with the ability (Example Block) to receive from the Feedback Block a user message from the terminal device about the correspondence of the system-generated DSL query to the actual user query in natural language and the "user query - DSL query" pair, extract the semantic vector from the user query and send it to the Vector Storage for saving, and save a new pair (example) "user query in natural language - DSL query". Examples of previous queries demonstrate the desired format and style of DSL query generation; these examples serve as a guide for the system when interpreting a new query and help improve the accuracy and consistency of the output;

[0029] - Vector storage – a vector database containing pre-computed semantic vector representations of user queries, designed to store semantic vectors of user queries;

[0030] - DSL query generation unit, configured to receive from the Script the schema of the Database Record Table, the identifier of the Script of the original corrected user query corresponding to the user query, relevant examples from the Examples Unit (if any), with the ability (Generation Unit) to direct the specified data to the LLM Model, which operates through vLLM and is able to interpret the data and generate a correct DSL query, with the ability to receive from the LLM Model the generated DSL query and direct it to the Query Correction Unit;

[0031] -LLM Model – an artificial intelligence program trained to work with text, installed on the server;

[0032] - DSL Query Correction Unit configured to receive from the DSL Query Generation Unit the schema of the Database Record Table, the Scenario identifier corresponding to the user query, the original user query and the generated DSL query to the Database, with the ability (DSL Query Correction Unit) to correct the generated DSL query to the Database in order to replace human-readable values ​​in the DSL query with the corresponding values ​​from the rows and columns of the Table in the Database (for example, using the Levenshtein method), send the corrected DSL query to the Legitimacy Check Unit, in case of a positive check, receive the DSL query from the Legitimacy Check Unit, with the ability (DSL Query Correction Unit) to send the DSL query to the Database and receive from the Database an excerpt from the Table of Rows and Columns of the Database related to the DSL query and containing the rows and Database columns that are relevant to the DSL query,generated on the basis of the DSL request received by the Database from the DSL request correction unit, with the ability (DSL request correction unit) to send an excerpt from the Database Record Table, the original user request and the DSL request to the Response Generation unit;

[0033] - A database, which is software designed to store in the Database requirements for user queries in natural language and DSL queries, and to establish in the Database a Table of rows and columns with records;

[0034] - A response generation unit configured to receive from the Request Correction Unit an excerpt from the Database Record Table related to the user request and containing the rows and columns of the Database, the Scenario identifier corresponding to the user request, the user request and the DSL request, with the ability (Response Generation Unit) to send this excerpt from the Database, the user request and the DSL request to the LLM Model operating through vLLM and capable of interpreting the data of the excerpt from the Database and the DSL request, to generate on their basis a response in natural language to the user request in natural language, with the ability to send to the terminal equipment the generated response in natural language to the user request and the “user request – DSL request” pair;

[0035] - A feedback unit configured to receive from the user's terminal equipment a "user request - DSL request" pair, a Scenario identifier corresponding to the user request, a message about whether the system's response in natural language corresponds to the user's original user request, with the ability, in the event of confirmation from the terminal equipment of the response's correspondence to the original user request, to transmit to the Examples Unit a message about storing in the Examples Unit the "user request - generated DSL request corresponding to the user request" pair and to transmit the said pair to the Examples Unit, with the ability (Feedback Unit), in the event of receiving from the terminal equipment a message about the response's non-compliance with the original user request, to transmit to the Scenario previously selected for preparing the response to the user request, the "user request - generated DSL request" pairs,for which a mismatch message was sent" to generate a new DSL query. Thus, the Feedback Block provides dynamic replenishment and correction of examples, which allows the system to improve the quality of the response and the accuracy of query matching in the future.

[0036] In a particular embodiment, a machine-readable storage medium, configured with the ability to load a computer program - Script - onto the machine-readable medium, is installed on the server.

[0037] In a particular embodiment, a machine-readable storage medium, configured with the ability to load a computer program - Script - onto the machine-readable medium, is installed on the user's terminal equipment.

[0038] In a particular implementation, the Vector Storage is installed on a server outside the Example Block.

[0039] In a particular implementation, Vector Storage is installed on the server in the Example Block.

[0040] In a specific implementation, the DSL Request Generation Block is installed on the server.

[0041] In a particular implementation variant, the User DSL Request Generation Unit is installed on the user's terminal equipment.

[0042] In a particular implementation, the Database is installed on the server that receives a request from the terminal device.

[0043] In a particular implementation, the Database is installed on an external server relative to the server receiving the request from the terminal device.

[0044] In a particular implementation option, a separate Database is installed in the system to store the Record Table and a separate Database is installed to store the requirements for the user request and the DSL request.

[0045] In a particular embodiment, the interaction of the Scenario with user queries in natural language related to this Scenario, with the purpose of forming this Scenario, the schema of the Database Record Table, the set of dictionaries for the Hint Block, the set of user queries and DSL queries for the Example Block, the set of user queries for the Scenario Selection Block, on which the Scenario Selection Block is further trained to accept queries for this Scenario, is understood as recording the above data in the source code of the Scenario.

[0046] In a particular embodiment, the interaction of the Scenario with user queries in natural language related to this Scenario, with the purpose of forming this Scenario, the schema of the Database Record Table, the set of dictionaries for the Hint Block, the set of user queries and DSL queries for the Example Block, the set of user queries for the Scenario Selection Block, on which the Scenario Selection Block is further trained to accept queries for this Scenario, is understood as accessing the Database, where the above data is stored.

[0047] In a particular embodiment, the interaction of the Scenario with user queries in natural language related to this Scenario, with the purpose of forming this Scenario, the schema of the Database Record Table, the set of dictionaries for the Hint Block, the set of user queries and DSL queries for the Example Block, the set of user queries for the Scenario Selection Block, on which the Scenario Selection Block is further trained to accept queries for this Scenario, is understood as accessing a separate file installed on the server on which the above-mentioned data is stored.

[0048] In a particular embodiment, the "user request - DSL request" pair is stored on the Example Block's storage device.

[0049] In a particular implementation, the user query – DSL query pair is stored in Vector Storage.

[0050] In a particular embodiment, the Feedback Block is configured to send a “user request-DSL request” pair to the Example Block for storing it as an example if feedback from the user’s terminal equipment has not been received within a time set in the system.

[0051] In a particular embodiment, the Request Processing Unit is configured to, upon receiving a user request from the terminal equipment, send a request to the Request Processing Unit with a request to provide feedback from this terminal equipment on the last request from this terminal equipment, with the ability (Request Processing Unit) to refuse to process the user request from this user terminal equipment until a message is received from the Feedback Unit in the Request Processing Unit to provide feedback on the last user request from this terminal equipment.

[0052] In a particular embodiment, the Request Processing Unit is configured to provide, upon request of the Request Processing Unit, information on the provision of feedback from the given terminal equipment on the latest user request from the given terminal equipment.

[0053] The technical result “Increasing the accuracy of an automated response to a user’s request”, “Obtaining information through semantic processing of text in natural language” is achieved due to the following essential features of the system:

[0054] - the presence of a Legitimacy Check Block in the system, in which the user request and DSL request are checked for compliance with the system requirements, thereby providing the user with only system-verified responses, which increases the accuracy of the automated response to the user's request;

[0055] - the presence of a Scenario Selection Block in the system, thanks to which a user request in natural language is determined for a specific Scenario with dictionaries corresponding to this Scenario in the Hint Block and groups of examples corresponding to this Scenario in the Example Block, which helps to increase the accuracy of the formation of an automated response by immediately assigning the user request to a specific group (due to assignment to a specific Scenario);

[0056] - the presence of different Scenarios in the system, which include user requests, which helps to increase the accuracy of generating a response to a user request due to the Scenario working with already defined dictionaries in the Hint Block and examples in the Example Block;

[0057] - The presence of a hint block in the system, in which spellings and common designations are replaced with standardized system terms. This allows the user to obtain the correct result even when the query formulation does not directly match the system's internal notations;

[0058] - the presence of an Example Block in the system, which contains relevant examples of queries already in the system that are similar in meaning to the original query. This allows the Generation Block to subsequently generate a more precise DSL query based on previous similar DSL queries, and therefore provide a more precise response;

[0059] - the presence of a DSL query correction block, in which the DSL query is modified to match the Database Record Table schema, which increases the accuracy of providing a response to the user's query due to correct access to the Database;

[0060] - the presence of a Feedback Block, which receives user feedback and, firstly, stores in the Example Block only those "user query - DSL query" pairs that match the user query, and secondly, returns the pair for DSL query refinement. These actions improve the accuracy of responses to the current user query and future user queries.

[0061] The technical result of “Accelerating the delivery of an accurate response to a user’s request” is achieved through the following essential features of the system:

[0062] - the presence of a Legitimacy Check Block in the system, in which the user request and DSL request are checked for compliance with the system requirements, thereby immediately cutting off inappropriate requests and speeding up the system;

[0063] - the presence of a Scenario Selection Block in the system, thanks to which a user request in natural language is determined by the Request Processing Block for a specific Scenario with dictionaries corresponding to this Scenario in the Hint Block and groups of examples corresponding to this Scenario in the Example Block, which speeds up the process of generating an automated response by immediately assigning the user request to a specific group (specific Scenario);

[0064] - the presence of different Scenarios in the system that access different dictionaries in the Hint Block, and different examples in the Example Block, which speeds up the process of generating a response to a user request due to the absence of the need for a longer search in the general array of information;

[0065] - the presence of a Hint Block in the system, in which spellings and common designations are replaced with standardized terms in the system. This speeds up the response process, as it makes it easier for the Database Record Table to recognize and identify the request;

[0066] - The presence of an Example Block in the system, which contains relevant examples of queries already in the system that are similar in meaning to the original query. This allows the system to respond to the user's query more quickly, based on previous query examples;

[0067] - the presence of a Query Correction Block, in which the DSL query is modified to fit the structure of the Database Record Table, which speeds up the process of preparing an extract from the Database Record Table and, accordingly, speeds up the process of providing a response to the user's query.

[0068] The technical result of “Increasing the protection of system data” is achieved through the following essential features of the system:

[0069] - the presence of a Legitimacy Check Block in the system, which prevents the execution of a DSL request that does not meet the system requirements and thereby helps maintain the integrity of the Database Record Table.

[0070] The technical results of "Accelerating the process of changing system settings to provide an automated response to a user request" and "Increasing the performance of the hardware and software system due to the absence of the need to additionally enter new data into the hardware and software system, which saves the amount of RAM" are achieved through the following essential features of the system:

[0071] - the presence of a Feedback Block, which receives feedback from the user and, firstly, saves in the Example Block only those "user request - DSL request" pairs that match the user request, and secondly, returns the pair for revision. These actions accelerate the process of changing system settings and correcting errors by receiving feedback from the user's terminal equipment, saving and reprocessing the response, which eliminates the need for more resource-intensive and time-consuming additional training of the LLM Model. The system flexibly accepts confirmation of the correctness of its response, which it will use in the future, or quickly modifies the response logic to similar requests, allowing for seamless self-correction.

[0072] - presence of an Example Block, which stores only “user request – DSL request” pairs that have already passed a positive check from the user’s terminal equipment.

[0073] The method for generating an automated response to a user query in natural language is implemented by means of the System for generating an automated response to a user query in natural language and includes the following steps:

[0074] - from the user's terminal equipment, the user's request in natural language is transmitted to the server;

[0075] - on the server, the user request is sent to the Request Processing Block, from where it is sent to the Legitimacy Verification Block;

[0076] - In the Legitimacy Check Block, the user request is compared with the pre-set user request requirements;

[0077] - if the Legitimacy Verification Unit detects that the user request received from the Request Processing Unit does not comply with the established requirements for the user request, the Legitimacy Verification Unit sends a message to the user's terminal equipment about the impossibility of providing a response to the user request;

[0078] - if the Legitimacy Verification Block detects that the requirements set in the Legitimacy Verification Block are met, the user request is sent from the Legitimacy Verification Block to the Request Processing Block;

[0079] - after returning from the Legitimacy Check Block to the Request Processing Block, the user request is sent to the Scenario Selection Block;

[0080] - in the Scenario selection block, the structure of the user request is determined and assigned to a specific Scenario, assigning the user request the identifier of this Scenario;

[0081] - direct the user request from the Scenario Selection Block to the selected Scenario;

[0082] - from the Scenario, the user request is sent to the Hint Block, where the words in the user request are replaced with standard words pre-set in the Hint Block;

[0083] - the user request corrected in the Hint Block is returned to the Scenario;

[0084] - send the user request from the Scenario to the Example Block, where the semantic vector is removed from the user request and sent to the Vector Storage;

[0085] - in the Vector Storage, based on proximity (for example, cosine proximity) to the semantic vectors of user queries located in the Vector Storage, the closest semantic vector is searched for;

[0086] - if the closest semantic vector is found in the Vector Storage, a pair of “the user query found by the semantic vector and the corresponding DSL query” is found in the Example Block;

[0087] - the “user request – DSL request” pair found in the Example Block is sent to the Script together with the original user request, or only the original user request is sent to the Script if the “user request – DSL request” pair was not found in the Example Block;

[0088] - from the Scenario, the user query corrected in the Hint Block is sent to the DSL Query Generation Block together with the Database Record Table schema and the Scenario identifier corresponding to the user query, and relevant examples;

[0089] - from the DSL Query Generation Block, the corrected original user query in natural language, the Scenario identifier corresponding to the user query, the Database record schema and relevant examples are sent to the LLM Model;

[0090] - The LLM model interprets the data of the adjusted original user natural language query, the schema of the Database records and the relevant examples, and generates a DSL query;

[0091] - the generated DSL request is sent from the LLM Model to the DSL Request Generation Block;

[0092] - from the DSL Request Generation Block, the Scenario ID corresponding to the user request, the DSL request and the original user request are sent to the DSL Request Correction Block;

[0093] - in the DSL Query Correction Block, human-readable values ​​in the DSL query are replaced with the corresponding values ​​from the rows and columns in the Database Table;

[0094] - the corrected DSL request from the Correction Block is sent to the Legitimacy Check Block to check for compliance with the system requirements for the DSL request;

[0095] - if the Legitimacy Check Block detects a discrepancy with the system requirements for the DSL request, a message is sent to the user's terminal equipment about the impossibility of providing a response to the user's request;

[0096] - if the Legitimacy Check Block detects that the DSL request meets the system requirements, the DSL request is returned to the DSL Request Correction Block;

[0097] - after the DSL request is received by the DSL request correction unit, the DSL request correction unit sends the DSL request to the Database;

[0098] - The Database receives the DSL request, generates an excerpt from the Database Record Table in accordance with the DSL request, and sends the excerpt to the DSL Request Correction Block;

[0099] - The DSL Request Adjustment Block passes the original user request, the scenario ID corresponding to the user request, the DSL request, and an excerpt from the Database Record Table to the Response Generation Block;

[0100] - The Response Generation Block passes the original user request, DSL request and excerpt from the Database Record Table to the LLM Model;

[0101] - The LLM model interprets the data from the original user query, DSL query and excerpt from the Database Record Table, generates a natural language response and forwards it to the Response Generation Block;

[0102] - The response generation unit receives the generated response in natural language to the user request and transmits it to the user's terminal equipment together with the original user request, the Scenario identifier corresponding to the user request, the DSL request and a message to the user about the need to provide information about whether the response matches the user request or not (hereinafter referred to as the feedback message);

[0103] - after receiving a response in natural language, a Scenario identifier corresponding to the user request, the original user request, a DSL request and a feedback message from the user terminal equipment, the information on whether the response matches the user request or not, as well as the “user request – DSL request” pair, is sent to the Feedback Block;

[0104] - if the Feedback Block receives from the user's terminal equipment a message about the response matching the user's request together with the original user's request and the DSL request, the Feedback Block sends to the Example Block the "user request - DSL request" pair and a message about saving the "user request - DSL request" pair for further use for future requests as examples;

[0105] - when the Example Block receives a message about saving the “user query – DSL query” pair, the “user query – DSL query” pair is saved, and the semantic vector is removed from the user query and saved in the Vector Storage;

[0106] - if the Feedback Unit receives from the user's terminal equipment a message about a discrepancy between the response and the user request, together with the original user request and the DSL request, the Scenario identifier corresponding to the user request, the Feedback Unit transmits to the corresponding Scenario that initially received the user request, the original user request, and the incorrectly generated DSL request in order to begin the process of forming a new response to the user request.

[0107] The technical result “Increasing the accuracy of an automated response to a user’s request”, “Obtaining information through semantic processing of text in natural language” is achieved due to the following essential features of the method:

[0108] - forwarding the user request and DSL request to the Legitimacy Check Block, where the user request and DSL request are checked for compliance with the system requirements, thereby providing the user with only system-verified responses, which increases the accuracy of the automated response to the user's request;

[0109] - directing the user request to the Scenario Selection Block, due to which the user request in natural language is assigned to a specific Scenario with the dictionaries corresponding to this Scenario in the Hint Block and the groups of examples corresponding to this Scenario in the Example Block, which helps to increase the accuracy of generating an automated response by immediately assigning the user request to a specific group (due to assignment to a specific Scenario);

[0110] - directing the user request to specific Scenarios to which the user requests belong, which helps to increase the accuracy of generating a response to the user request due to the Scenario working with already defined dictionaries in the Hint Block and examples in the Example Block;

[0111] - directs the user's query to the Suggestion Block, where spellings and common designations are replaced with standardized system terms. This allows the user to obtain the correct result even when the query formulation does not directly match the system's internal notations;

[0112] - directs the user's query to the Example Block, which contains relevant examples of queries already in the system that are similar in meaning to the original query. This allows the Generation Block to subsequently generate a more precise DSL query based on previous similar DSL queries, and therefore provide a more precise response;

[0113] - directing the DSL request to the Request Correction Block, in which the DSL request is modified to match the Database Record Table schema, which increases the accuracy of providing a response to the user's request due to correct access to the Database;

[0114] - receiving feedback from the user from the Feedback Block about whether the response matches the user request, and sending the “user request – DSL request” pair either to the Example Block to be saved for future requests or to the Scenario to generate a new response, which increases the accuracy of the response to the current user request and user requests in the future.

[0115] The technical result of “Accelerating the delivery of an accurate response to a user’s request to the user” is achieved through the following essential features of the method:

[0116] - directing the user request and DSL request to the Legitimacy Check Block, where the user request is checked for compliance with the system requirements, thereby immediately cutting off inappropriate requests and speeding up the system;

[0117] - directing a user request to the Scenario Selection Block, due to which the user request in natural language is determined by the Request Processing Block for a specific Scenario with the dictionaries corresponding to this Scenario in the Hint Block and the groups of examples corresponding to this Scenario in the Example Block, which speeds up the process of generating an automated response by immediately assigning the user request to a specific group (specific Scenario);

[0118] - directing user queries to specific Scenarios that access different dictionaries in the Hint Block, and different examples in the Example Block, which speeds up the process of generating a response to a user query by eliminating the need for a longer search in the general array of information;

[0119] - directs the user's query to the Suggestion Block, where spellings and common designations are replaced with standardized terms in the system. This speeds up the response process, as it makes it easier for the Database Record Table to recognize and identify the query;

[0120] - directs the user's query to the Examples Block, which contains relevant examples of queries already in the system that are similar in meaning to the original query. This allows the system to respond to the user's query more quickly, based on previous query examples;

[0121] - directing the DSL request to the DSL Request Correction Block, in which the DSL request is modified to fit the structure of the Database Record Table, which speeds up the process of preparing an extract from the Database Record Table and, accordingly, speeds up the process of providing a response to the user request.

[0122] The technical result “Increasing the protection of system data” is achieved by the following essential feature of the method:

[0123] - directing the DSL request to the Legitimacy Check Block, which prevents the execution of a DSL request that does not meet the system requirements and thereby helps maintain the integrity of the Database Record Table.

[0124] DESCRIPTION OF DRAWINGS

[0125] The invention will be further described in accordance with the accompanying drawing, which is provided to clarify the essence of the invention and in no way limits the scope of the invention. The following drawing is attached to the application:

[0126] Fig. 1 shows the diagram of the System.

[0127] EXAMPLES OF IMPLEMENTING THE INVENTION

[0128] This invention is in demand in any industry where information system repositories contain large amounts of data that require systematization and classification when accessing it. This invention solves one of the most pressing problems of any business: quickly obtaining a logically structured, human-like, and data-driven answer to a specific question. This technology will be especially in demand in the field of information security, where security officers need to receive quick and high-quality answers to questions about information circulating within the system. The example below demonstrates the feasibility of implementing the invention in the work of an information security officer within a company.

[0129] SYSTEM IMPLEMENTATION EXAMPLE #1

[0130] This example uses the terminal equipment (100) Lenovo ThinkPad T14 Gen 4:

[0131] • Processor: Intel Core i7-1355U (10-core, up to 5.0 GHz)

[0132] • RAM: 16GB DDR5, 5200MHz

[0133] • Storage: 512GB SSD NVMe PCIe Gen4

[0134] • Graphics: Integrated Intel Iris Xe Graphics

[0135] • Display: 14" IPS, 1920×1200, 300 nits, anti-glare

[0136] • Network: Wi-Fi 6E, Bluetooth 5.2, Gigabit Ethernet (via docking station)

[0137] • OS: Windows 11 Pro / Ubuntu 22.04 LTS

[0138] • Security: TPM 2.0, Fingerprint Scanner, Camera Latch (ThinkShutter)

[0139] • Ports:

[0140] • 2× USB-C (including Thunderbolt 4)

[0141] • 2× USB-A 3.2

[0142] • HDMI 2.1

[0143] • Audio combo

[0144] • microSD

[0145] The system uses a server station based on NVIDIA Tesla T4 as a server (101):

[0146] • Processor: AMD Ryzen Threadripper PRO 5995WX (64 cores, 2.7–4.5 GHz)

[0147] • RAM: 512GB DDR4 ECC Registered

[0148] • Graphics: 1× NVIDIA GeForce RTX 4090 (24 GB GDDR6X, CUDA, Tensor, RT cores)

[0149] • Storage devices:

[0150] • 1×2TB NVMe SSD (system drive)

[0151] • 2×4TB NVMe SSD (for data / models)

[0152] • Network: 2× 10Gb Ethernet

[0153] • OS: Ubuntu 22.04 LTS, NVIDIA CUDA Toolkit, PyTorch, Docker, NVIDIA Container Toolkit installed

[0154] The server (101) has a Request Processing Unit (102) installed, which in this example is software created on the basis of the FastAPI framework.

[0155] The server (101) has a Legitimacy Checker (103) installed, which in this example is a software built on a Python script.

[0156] In the Legitimacy Check Block (103), the following requirements are set for the user's natural language request for this example:

[0157] - a natural language query should not contain stop words like "politics, insult, news", or system-level commands like "delete, remove, add".

[0158] In this example, one of the types of DSL queries will be generated in the system – an SQL query.

[0159] The Legitimacy Check Block (103) for this example sets the following requirements for the SQL query:

[0160] - only data selection queries (SELECT) are allowed, while queries containing DELETE, UPDATE, INSERT, DROP, ALTER and similar modifying operators are blocked;

[0161] - the structure of the SQL query must have the following components: FROM, WHERE if filtering is required;

[0162] - the structure of the SQL query must not contain calls to external procedures EXEC, xp_cmdshell.

[0163] Excerpt from the source code of the software that represents the Legitimacy Check Block (103) in this example:

[0164]

[0165]

[0166] The Scenario Selection Unit (104) is installed on the server (101), powered by the LaBSE (Language-Agnostic BERT Sentence Embedding) neural network. This model is pre-trained: during its initial development, training was conducted on large multilingual text arrays, which allowed the formation of universal linguistic representations and ensured the comparison of sentence meanings in different languages. In this example, this pre-trained model was further trained on the task of classifying user queries into two Scenarios (106). The model was further trained as follows: a labeled training set was formed, including text user queries for one of four Scenarios (106):

[0167] • Analytics;

[0168] • Search documentation.

[0169] An example of a labeled training sample:

[0170] Request Scenario Who did Sergey Ivanov communicate with most often by email? Analytics How does a relationship graph work? Search documentation

[0171] Fine-tuning was used on top of LaBSE embeddings for further training, adding a classification head (linear layer) and the CrossEntropyLoss loss function. Training was performed in Python 3.10 using the Transformers library from HuggingFace. Model validation was performed on the holdout subset, achieving a macro-F1 score greater than 0.92.

[0172] In the Scenario Selection Block (104), set the identifier for each Scenario (106). The identifiers were previously sent to the Scenario Selection Block (104) from the Scenario (106) along with the user requests. In this example, the Scenario (106) identifiers are the numbers: 0, 1:

[0173] - Analytics 0;

[0174] - Search documentation 1.

[0175] The machine-readable medium (105) in this example is a 128GB SanDisk Ultra Flair USB flash drive with a FAT32 file system, onto which the Scenarios (106) are loaded.

[0176] In this example, Scenario (106) is implemented using a Python script. Two scenarios are used:

[0177] - Analytics 0;

[0178] - Search documentation 1.

[0179] Hint Block (107) is a software program created using Python script.

[0180] The following dictionaries are used in this example:

[0181] “flash drive”: “USB device”,

[0182] "flash drive": "USB device",

[0183] «email»: «mail»,

[0184] "communicates by mail": "mail",

[0185] "called": "call",

[0186] "talked on the phone": "call".

[0187]

[0188] The example block (108) presents software created based on a Python script.

[0189] In this example, the following pairs of “user natural language query - SQL query” (examples) are stored in the Example Block (108):

[0190] Index Text query SQL query 0 Who does Maxim Ivanov write to by email most often? SELECT addressees, COUNT(id) AS num_count FROM events WHERE subject = 'Ivanov Maxim' AND type_communicate = 'mail' GROUP BY addressees; 1 Who communicated the most by email on January 25th? SELECT subject, COUNT(id) AS num_count FROM events WHERE type_communicate = 'mail' AND DATE(event_date) = '2023-01-25' GROUP BY subject ORDER BY num_count DESC LIMIT 1;

[0191] In this example, the FAISS library is used as Vector Storage (109). In this example, each user query is converted into a semantic vector in Vector Storage (109) using the multilingual-e5-large model. The resulting vectors are stored in Vector Storage (109).

[0192] The following semantic vectors of the text (user) queries above are stored in the Vector Storage (109) for this example:

[0193] Index Semantic vector 0 [-0.1177, -0.5101, -0.2313, ..., -0.5063, -1.3049, -0.5016] 1 [ 0.2184, -0.0092, -0.4151, ..., -0.3355, -0.9334, -0.1946]

[0194] To evaluate the closeness of semantic vectors in this example, the cosine similarity metric is used.

[0195] The cosine similarity formula for two vectors A and B is:

[0196]

[0197] where - the scalar product of vectors, and - their Euclidean norms.

[0198] This metric is used because it allows texts to be compared not by word count or length, but by the similarity of semantic features extracted by the model in a vector representation. Even if two queries differ in wording or length (for example, "who copied to a flash drive" and "which user most often wrote data to a USB device"), their vector representations will be similar, and cosine similarity will indicate a high degree of correspondence. Thus, the chosen metric provides a more accurate determination of the semantic similarity of texts compared to simple distances dependent on query length.

[0199]

[0200] In the Result of processing the user query "Who most often corresponded by email with Ivanov Maxim?", the closest example was found in the Example Block:

[0201] Who does Maxim Ivanov email most often? and the corresponding SQL query:

[0202] SELECT addressees, COUNT(id) AS num_count

[0203] FROM events

[0204] WHERE subject = 'Ivanov Maxim'

[0205] AND type_communicate = 'mail_category'

[0206] GROUP BY addressees;

[0207] The following is used as the memory device of the Example Block (108) in this example:

[0208] - Postgresql relational database (for storing pairs of “natural query – SQL query”),

[0209] - FAISS / Qdrant vector database (for storing semantic vectors of user queries).

[0210] The SQL query generation block (110) is a software implemented based on the Python programming language.

[0211] Model LLM (115) - Qwen3-8B.

[0212] The SQL Query Correction Block (111) is a Python-based program. For this example, the Correction Block dictionary excerpt for matching values ​​from the Database Table (112) schema is:

[0213] "mail": "email_category";

[0214] "call": "call_category";

[0215] "social networks": "social_category".

[0216] In this example, the value “mail” will be replaced with “email_category”

[0217] Generated SQL query:

[0218] SELECT subject, COUNT(id) AS num_count

[0219] FROM events

[0220] WHERE type_communicate = 'mail'

[0221] GROUP BY subject;

[0222] SQL query after adjustment:

[0223] SELECT subject, COUNT(id) AS num_count

[0224] FROM events

[0225] WHERE type_communicate = 'email_category'

[0226] GROUP BY subject;

[0227]

[0228] The database (112) in this example is a ClickHouse column-oriented DBMS containing a user interaction events table, the structure of which includes the following fields:

[0229] • id — unique event identifier;

[0230] • subject — event initiator (user);

[0231] • type_communicate — communication type (e.g. mail, messenger, etc.);

[0232] • addressees — message recipient;

[0233] • company_name — the name of the organization with which the event is associated;

[0234] • theme — the subject of the message or interaction;

[0235] • date — date and / or timestamp of the event.

[0236] In this example, the Database Table (112) is:

[0237] ID subject type_communicate addressees company_name theme date 1 Ivanov Maxim mail_category Petrov A.V. Yodo Quarterly Analytics Report 2024-12-20 2 Ivanov Maxim social_category Smirnova E.V. Acme Corp Meeting reminder 2025-01-10 3 Petrov A.V. mail_category Ivanov Maxim Yodo Answer on the calculation method 2025-01-11 4 Smirnova E.V. call_category Ivanov Maxim Yodo Commentary on the report 2025-01-12 6 Ivanov Maxim mail_category Petrov A.V. Yodo Final presentation 2025-01-19

[0238] Database Schema (112):

[0239]

[0240] The Response Generation Block (113) is a Python-based program. In this example, the Response Generation Block uses prompt engineering to generate responses. Prompt engineering is an approach to formulating and optimizing queries for artificial intelligence, i.e., a technique for creating and refining input queries to improve the accuracy, completeness, and relevance of the model's responses.

[0241] The feedback block (103) in this example is software (Python script). An example of the software source code:

[0242]

[0243] EXAMPLE OF IMPLEMENTATION OF METHOD #2

[0244] In this example, the user with the account SidorovS sends the following request from his terminal equipment (100) to the server (101) “Who does Maxim Ivanov communicate with by email?”

[0245] On the server (101), the user SidorovS's request "Who does Maxim Ivanov communicate with via email" is sent to the Request Processing Block (102).

[0246] From the Request Processing Block (102), the request is sent to the Legitimacy Verification Block (103). Legitimacy Verification Block (103) verifies that the request does not contain the stop words "politics, insults, news" or system-level commands "delete, remove, add" set in Legitimacy Verification Block (103). According to the parameters of Legitimacy Verification Block (103), the request "Who does Maxim Ivanov communicate with via email" passes the legitimacy check and is returned to Request Processing Block (102).

[0247] From the Request Processing Block (102), the request is sent to the Scenario Selection Block (104). In the Scenario Selection Block (104), the request "Who does Maxim Ivanov communicate with via email" is assigned the Scenario ID "0," which corresponds to Scenario (106) "Analytics."

[0248] From the Scenario Selection Block (104), the request is sent to the Scenario (106) “Analytics” on the machine-readable medium (105).

[0249] From Scenario (106) "Analytics," the query is sent to the Suggestion Block (107). The Suggestion Block (107) returns the adjusted query to Scenario (106):

[0250] "Who does Maxim Ivanov communicate with via email?", i.e. email has been replaced with "mail".

[0251] From Scenario (106), the user query is sent to the Example Block (108). In the Example Block, the user query question is translated into a semantic vector and, using cosine similarity (top_n=1, a configurable parameter), this vector is compared with vectors in the Vector Storage (109). One example (the closest semantic vector) is found from the Example Block that is most similar in meaning to the user's original query:

[0252] ("Who does Maxim Ivanov write to by email most often?",

[0253] "SELECT addressees, COUNT(id) AS num_count"

[0254] "FROM events WHERE subject = 'Ivanov Maxim'"

[0255] "AND type_communicate = 'mail_category' "

[0256] "GROUP BY addressees;")

[0257] From the Example Block (108), return to the Scenario (106) the user query together with the example “user query – SQL query” in the form:

[0258] "Who does Maxim Ivanov write to by email most often?" ->"SELECT addressees, COUNT(id) AS num_count FROM events WHERE subject = 'Maxim Ivanov' AND type_communicate = 'mail_category' GROUP BY addressees.

[0259] From Scenario (106), the user query, along with the example from the Example Block (108), the Scenario ID "0", and the Database Record Schema (112), are sent to the SQL Query Generation Block (110). From the SQL Query Generation Block (110), the original user query, relevant examples, and the Database Table Schema (112) are sent to the LLM Model (115), where a new SQL query is generated.

[0260] LLM Instructions:

[0261]

[0262] Based on the above data, the LLM Model generates the following SQL query: 'SELECT addressees, COUNT(id) AS num_count from events WHERE subject = “Ivanov Maxim” AND type_communication = 'mail' GROUP BY addressees, count;' and passes it to the SQL Query Generation Block (110).

[0263] From the SQL Query Generation Block (110), the SQL query with the user query and the Scenario ID corresponding to the user query is sent to the SQL Query Correction Block (111). In the SQL Query Correction Block (111), the SQL query is corrected as follows:

[0264] 'SELECT addressees, COUNT(id) AS num_count from events WHERE subject = “Ivanov Maxim” AND type_communication = 'email_category' GROUP BY addressees, count;'

[0265] Explanation: The correction block replaced “mail” with “email_category” from the values ​​of the Database Table (112).

[0266] From the SQL Query Correction Block (111), the SQL query is sent to the Legitimacy Check Block (103), where it is checked for the types of permitted operations. The SQL query structure contains the FROM and WHERE operators. FROM specifies the table or set of tables in the Database (112) from which data is retrieved, while WHERE specifies the filtering conditions for rows to be selected from the specified Table. The query structure does not contain calls to external EXEC or xp_cmdshell procedures, or invalid subqueries or nested operations.

[0267] From the Legitimacy Check Block (103), the SQL query is returned to the SQL Query Correction Block (111).

[0268] From the SQL Query Correction Block, the query is sent to the Database (112).

[0269] The following excerpt from the Database Table (112) with the original SQL query is sent from the Database (112) to the SQL Query Correction Block (111):

[0270] 'SELECT addressees, COUNT(id) AS num_count from events WHERE subject = “Ivanov Maxim” AND type_communication = 'email_category' GROUP BY addressees, count;'

[0271] addressees num_count Petrov A.V. 1

[0272] The user query, the scenario identifier corresponding to the user query, the SQL query, and the excerpt from the Database Record Table (112) are sent from the SQL Query Correction Block (111) to the Response Generation Block (113)

[0273] In the Response Generation Block (113), translate the response table into natural language:

[0274] "Maxim Ivanov communicated by email with Petrov A.V. 1 time" and is transmitted together with the pair "user query–SQL query" to the user's terminal equipment.

[0275] The response to the user request from the Response Generation Block (113) requests feedback from the user by clicking “Like” or “Dislike” on the user’s terminal equipment interface, which corresponds to confirming or denying whether the submitted response matches the user request.

[0276] A message was sent from the user's terminal equipment (100) to the Feedback Block (113) by clicking "Like" in the interface, confirming that the user's request matches the provided response, along with the "user request - SQL query" pair. After the Feedback Block (113) receives this message from the user's terminal equipment (100), the Feedback Block (113) sends a message to the Example Block (108) to save the user's request and the generated SQL query in the Example Block (108). This pair is saved in the Example Block (108):

[0277] Index Text query SQL query 2 Who does Maxim Ivanov write to by email most often? SELECT addressees, COUNT(id) AS num_count FROM events WHERE subject = 'Ivanov Maxim' AND type_communicate = 'mail' GROUP BY addressees;

[0278] In FAISS vector database:

[0279] Index Semantic vector 2 [-0.1177, -0.5101, -0.2313, ..., -0.5063, -1.3049, -0.5016]

[0280] EXAMPLE OF IMPLEMENTATION OF METHOD #3

[0281] In this example, the user SidorovS's request "Who communicated more by email from the first to the nineteenth of January 2025" is transmitted from the terminal equipment of the user (100) SidorovS to the server (101).

[0282] On the server (101), the user SidorovS's request "Who communicated more by email from the first to the nineteenth of January 2025" is received by the Request Processing Block (102).

[0283] The request is sent from the Request Processing Block (102) to the Legitimacy Verification Block (103). The request does not contain the stop words specified in the Legitimacy Verification Blocks. According to the parameters of the Legitimacy Verification Block (103), the request "Who communicated more by email from January 1st to January 19th, 2025" passes the legitimacy check and is returned to the Request Processing Block (102).

[0284] From the Request Processing Block (102), the request is sent to the Scenario Selection Block (104). In the Scenario Selection Block (104), the request "Who communicated more by email from January 1st to January 19th, 2025" is assigned the identifier "0," which corresponds to the "Analytics" scenario.

[0285] From the Scenario Selection Block (104), the request is sent to the Scenario (106) “Analytics”.

[0286] From Scenario (106) "Analytics," the query is sent to the Suggestion Block (107). The Suggestion Block (107) returns the adjusted query to Scenario (106):

[0287] Who communicated more by email from the first to the nineteenth of January 2025, i.e. email has been replaced by mail.

[0288] From the Suggestion Block (107), the query is sent to the Example Block (108). In the Example Block (108), the question is converted from the query into a semantic vector, and using cosine similarity (top_n=1, configurable parameter), one example is selected that is most similar in meaning to the user's query:

[0289] "Who communicated the most by email on January 25th?"

[0290] SELECT subject, COUNT(id) AS num_count FROM events

[0291] WHERE type_communicate = 'mail_category'

[0292] AND DATE(event_date) = '2023-01-25'

[0293] GROUP BY subject ORDER BY num_count DESC LIMIT 1;

[0294] From the Example Block (108), the user request is returned to the Scenario (106) together with an example in the form:

[0295] "Who communicated by email the most on January 25th?" -> "SELECT subject, COUNT(id) AS num_count FROM events WHERE type_communicate = 'mail_category' AND DATE(event_date) = '2023-01-25' GROUP BY subject ORDER BY num_count DESC LIMIT 1.

[0296] From the Scenario (106), the Scenario identifier corresponding to the user query, the user query together with the example and the Database Record Table schema (112) are sent to the SQL Query Generation Block (110), from which they are sent to the LLM Model (115).

[0297] LLM Instructions:

[0298]

[0299] The LLM model generates a SQL query: 'SELECT subject, COUNT(id) AS num_count from events WHEREDATE(event_date) >= '2025-01-01' AND DATE(event_date) <= '2025-01-19' AND type_communication = 'mail' GROUP BY subject, count;' and sends it to the SQL Query Generation Block (110).

[0300] From the SQL Query Generation Block (110), the SQL query together with the user query, the Scenario ID corresponding to the user query, are sent to the SQL Query Correction Block (111), where the SQL query is corrected:

[0301] 'SELECT subject, COUNT(id) AS num_count from events WHEREDATE(event_date) >= '2025-01-01' AND DATE(event_date) <= '2025-01-19'AND type_communication = 'email_category' GROUP BY subject, count;'

[0302] Adjustment explanation: The adjustment block replaced “mail” with “email_category”.

[0303] From the SQL Query Correction Block (111), the query is sent to the Legitimacy Check Block (103), where a check for the type of allowed operations is performed. The query structure contains the FROM and WHERE operators. FROM specifies from which table or set of database tables the data is retrieved, WHERE sets the filtering conditions for the rows to be selected from the specified Database Record Table (112). The query structure does not contain calls to external procedures EXEC, xp_cmdshell, or invalid subqueries or nested operations. The SQL query is returned to the SQL Query Correction Block. From the SQL Query Correction Block (111), the SQL query is sent to the Database (112). From the Database (112), an excerpt from the Database Record Table (112) is returned to the SQL Query Correction Block (111):

[0304] addressees num_count Ivanov Maxim 2 Petrov A.V. 1 Smirnova E.V. 1

[0305] This excerpt from the Database Record Table (112) is sent together with the Scenario ID corresponding to the user request, the user request, and the SQL query to the Response Generation Block (113).

[0306] The Response Generation Block (113) sends an excerpt from the Database Record Table (112), the Scenario ID corresponding to the user request, the user request, and the SQL query to the LLM Model (115), where a natural language response is generated for the user. The response, along with the "user request - SQL query" pair, is sent to the user's terminal equipment (100). In this example, the response to the user is sent in the following format:

[0307] “From January 1 to January 19, 2025, Maxim Ivanov communicated by mail (2 times), A.V. Petrov (1 time), and E.V. Smirnova (1 time).”

[0308] The response to the user request from the Response Generation Unit (113) requests feedback from the user by clicking “Like” or “Dislike” on the user’s terminal equipment interface, which corresponds to confirming or denying whether the submitted response matches the user request.

[0309] In this example, a message was sent from the user's terminal equipment (100) to the Feedback Block (113) by placing a "Dislike" in the interface about the confirmation of the discrepancy between the user's request and the provided response, the Scenario ID corresponding to the user's request, and the "user request - SQL query" pair.

[0310] In this example, the user clicked "Dislike" because the SQL Query Generation Block made a mistake in the date: the user requested until January 19th (< 19, strict condition), and the system returned January 19th inclusive (<=19).

[0311] The Feedback Block sends the "user query - SQL query" pair and the Scenario ID corresponding to the user query to the corresponding Scenario. From Scenario (106) "0," the query is sent to the Hint Block (107). The Hint Block (107) returns the adjusted query to Scenario (106):

[0312] Who communicated more by mail from the first to the nineteenth of January 2025.

[0313] From the Suggestion Block (107), the query is sent to the Example Block (108). In the Example Block (108), the query question is converted into a semantic vector, and using cosine similarity (top_n=1, a configurable parameter), the 1 example that is most similar in meaning to the user's query is selected:

[0314] "Who communicated the most by email on January 25th?"

[0315] SELECT subject, COUNT(id) AS num_count FROM events

[0316] WHERE type_communicate = 'mail_category'

[0317] AND DATE(event_date) = '2023-01-25'

[0318] GROUP BY subject ORDER BY num_count DESC LIMIT 1;

[0319] From the Example Block (108), the user request is returned to the Scenario (106) together with an example in the form:

[0320] "Who communicated by email the most on January 25th?" -> "SELECT subject, COUNT(id) AS num_count FROM events WHERE type_communicate = 'mail_category' AND DATE(event_date) = '2023-01-25' GROUP BY subject ORDER BY num_count DESC LIMIT 1.

[0321] From the Scenario (106), the user query together with the example, the Database Record Table schema (112), the Scenario identifier corresponding to the user query, and the already received incorrect SQL query are sent to the SQL Query Generation Block (110), from which they are sent to the LLM Model (115).

[0322] LLM Instructions:

[0323]

[0324] The LLM model generates a SQL query: 'SELECT subject, COUNT(id) AS num_count from events WHEREDATE(event_date) >= '2025-01-01' AND DATE(event_date) < '2025-01-19' AND type_communication = 'mail' GROUP BY subject, count;' and sends it to the SQL Query Generation Block (110).

[0325] From the SQL Query Generation Block (110), the SQL query together with the user query, the Scenario identifier corresponding to the user query, is sent to the SQL Query Correction Block (111), where the SQL query is corrected:

[0326] 'SELECT subject, COUNT(id) AS num_count from events WHEREDATE(event_date) >= '2025-01-01' AND DATE(event_date) < '2025-01-19'AND type_communication = 'email_category' GROUP BY subject, count;'

[0327] Correction explanation: The correction block replaced “mail” with “email_category”

[0328] From the SQL Query Correction Block (111), the query is sent to the Legitimacy Check Block (103), where a check for the type of allowed operations is performed. The query structure contains the FROM and WHERE operators. FROM specifies from which table or set of database tables the data is retrieved, WHERE sets the filtering conditions for the rows to be selected from the specified Database Record Table (112). The query structure does not contain calls to external procedures EXEC, xp_cmdshell, or invalid subqueries or nested operations. The SQL query is returned to the SQL Query Correction Block. From the SQL Query Correction Block (111), the SQL query is sent to the Database (112). From the Database (112), an excerpt from the Database Record Table (112) is returned to the SQL Query Correction Block (111):

[0329] addressees num_count Ivanov Maxim 1 Petrov A.V. 1 Smirnova E.V. 1

[0330] This excerpt from the Database Record Table (112) is sent together with the user request, the Scenario ID corresponding to the user request, and the SQL query to the Response Generation Block (113).

[0331] The Response Generation Block (113) sends an excerpt from the Database Record Table (112), the user query, the Scenario ID corresponding to the user query, and the SQL query to the LLM Model (115), where a natural language response is generated for the user. The response, along with the "user query - SQL query" pair, is sent to the user's terminal equipment (100). In this example, the response to the user is sent in the following format:

[0332] “From January 1 to January 19, 2025, Maxim Ivanov (1 time), A.V. Petrov (1 time), and E.V. Smirnova (1 time) communicated by mail.”

[0333] The response to the user request from the Response Generation Block (113) requests feedback from the user by clicking “Like” or “Dislike” on the user’s terminal equipment interface, which corresponds to confirming or denying whether the submitted response matches the user request.

[0334] In this example, a message was sent from the user's terminal equipment (100) to the Feedback Block (113) by clicking "Like" in the interface to confirm that the user's request matches the provided response, as well as a "user request - SQL query" pair.

[0335] After the Feedback Block (113) receives this message from the user's terminal equipment (100), the Feedback Block (113) sends a message to the Example Block (108) about saving the user query and the generated SQL query in the Example Block (108). In the Example Block (108), this pair is saved:

[0336] Index Text query SQL query 2 Who communicated more by email from January 1st to January 19th, 2025? 'SELECT subject, COUNT(id) AS num_count from events WHERE DATE(event_date) >= '2025-01-01' AND DATE(event_date) < '2025-01-19' AND type_communication = 'email_category' GROUP BY subject, count;'

[0337] In FAISS vector database:

[0338] Index Semantic vector 2 [-0.2439, -0.6782, -0.1054, ..., -0.4127, -1.1936, -0.3871]

[0339] Thus, the above describes examples of the implementation of the System and the method for generating an automated response to a user request in natural language.

[0340] The above shows that the claimed invention is feasible, applicable and ensures the achievement of the technical result.

Claims

1. A system for generating an automated response to a user request in natural language, which is a hardware and software complex and includes: - at least one user terminal equipment connected to at least one server; - at least one server configured to connect to the user's terminal equipment for the purpose of receiving, transmitting and processing user requests in natural language on the server, with the possibility of having on the server at least one Request Processing Unit, at least one Legitimacy Check Unit, at least one Scenario Selection Unit, with the possibility of installing on the server at least one Machine-readable medium with at least one computer program installed thereon - the Scenario, with the possibility of having on the server at least one Hint Unit, at least one Example Unit, at least one Vector Storage, at least one DSL Request Generation Unit, at least one DSL Request Correction Unit, at least one Database, at least one Response Generation Unit, at least one Feedback Unit, at least one LLM Model; - at least one Request Processing Unit installed on the server and configured to receive a user request in natural language from the user's terminal equipment, forward the user request to the Legitimacy Verification Unit, receive back the user request from the Legitimacy Verification Unit, and forward the user request to the Scenario Selection Unit; - at least one Legitimacy Verification Unit installed on the server and configured to add to the Legitimacy Verification Unit requirements for a user request in natural language and for a DSL request in the form of a set of legitimacy verification rules, with the ability to save said requirements in the Database, with the ability to call said requirements from the Database to the Legitimacy Verification Unit, with the ability to receive a user request from the Request Processing Unit, with the ability to check the user request for compliance with the requirements for a user request in natural language, forwarding the user request to the Request Processing Unit in the event of a positive check, forwarding a response about the impossibility of processing the user request to the user's terminal equipment in the event of a request not complying with the requirements for the request, with the ability to receive a DSL request from the Request Correction Unit,with the ability to check the DSL request for compliance with the DSL request requirements, return the DSL request to the Request Correction Unit in the event of a positive check, and send a response about the impossibility of processing the DSL request to the user's terminal device in the event of a request not complying with the request requirements established in the Legitimacy Verification Unit; - at least one Scenario Selection Block, operating on the basis of a neural network, implemented by a neural network with the ability to learn to classify user requests based on examples of user requests, as well as with the ability to further classify user requests by determining the structure of the request and determine requests to a particular Scenario, with the ability to assign to the user request an identifier of a specific Scenario, which the Scenario Selection Block receives from a new Scenario when it accesses the Scenario Selection Block, installed in the Request Processing Block and configured with the ability to receive from the Request Processing Block a user request, with the ability to select a Scenario, assign a Scenario identifier to the user request, and direct the user request to the selected Scenario,with the ability to receive a message from the new Scenario about the presence of a new Scenario on the Machine-readable medium and with the ability to receive from the new Scenario the Scenario identifier and examples of user queries, on which the Scenario Selection Block, operating on the basis of a neural network, is further trained to accept queries for this Scenario, with the ability to further train itself to automatically select a new Scenario after receiving examples of user queries and an identifier from the new Scenario; - at least one machine-readable information carrier, configured with the ability to load a computer program – a Script – onto the machine-readable carrier, with the ability to add new Scripts to the machine-readable carrier; - at least one Scenario, which is a computer program, designed with the ability to create in the source code of the Scenario a Scenario identifier, with the ability to interact with user queries in natural language related to this Scenario, the schema of the Database Table, a set of dictionaries of the Hint Block, each of which relates to a certain Scenario, a set of user queries and DSL queries of the Example Block, formed in groups for each Scenario, with the ability to transmit user queries to the Scenario Selection Block, on which the Scenario Selection Block is further trained to accept queries to this Scenario, designed with the ability, upon receiving a request from the Scenario Selection Block, to send a user query in natural language to the Hint Block to certain dictionaries related to this Scenario, and to receive from the Hint Block a corrected user query,send a request to the Example Block for specific examples related to the given Scenario and receive relevant examples from the Example Block; upon receiving the adjusted user query in natural language and relevant examples, send the user query to the DSL Query Generation Block together with the Database Record Table schema and the Scenario identifier, with the ability to send messages from the new Scenario to the Scenario Selection Block about the creation of a new Scenario and with the ability to send examples of user queries to the Scenario Selection Block for its further training; with the ability to receive from the Feedback Block a user response from the terminal equipment about the discrepancy between the user's response and the user query and the "user query - DSL query" pair; in this case, send the original user query in natural language to the Hint Block and receive from the Hint Block the adjusted user query,send the original user query to the Example Block and receive relevant examples from the Example Block, send the adjusted user query, the relevant examples, the schema of the Database Record Table and the natural language user query - DSL query pair about which the mismatch was reported, and the Scenario identifier to the DSL Query Generation Block; - at least one Suggestion Block installed on the server and configured to install words in the Suggestion Block in the form of a set of dictionaries, each of which relates to a specific Scenario and consists of a pair of "designation variant - unified value", where the designation variant is a word or phrase that can be used by the user in a query in its natural form, and the unified value is a standard term corresponding to records in the Database Table, with the ability to replace words in the user query with pre-installed unified words in the Suggestion Block that correspond in semantic meaning to the words in the user query, and return the adjusted user query to the Scenario; - at least one Example Block installed on the server and representing a set of pairs "user query in natural language and DSL query", configured with the ability to install a Vector Storage in the Example Block, with the ability to receive a user query from the Scenario, extract a semantic vector from it, send the semantic vector of the user query to the Vector Storage to search for the closest semantic vector of another user query, when the closest semantic vector of another user query is found in the Vector Storage, call the relevant and previously saved pair "user query, close in proximity to the original user query - DSL query, corresponding to the close in proximity user query", return the original user query with relevant examples to the Scenario in the case of the presence of relevant examples;with the ability to receive from the Feedback Block a user message from the terminal device about the correspondence of the DSL request generated by the system to the actual user request in natural language and the pair “user request – DSL request”, to extract the semantic vector from the user request and send it to the Vector Storage for saving, to save a new pair “user request in natural language – DSL request”; - at least one Vector storage - a vector database containing pre-computed semantic vector representations of user queries, configured to store semantic vectors of user queries; - at least one DSL Query Generation Unit configured to receive from the Script the schema of the Database Record Table, the identifier of the Script of the original corrected user query corresponding to the user query, relevant examples from the Example Unit, if any, and the user query corrected in the Hint Unit, with the ability to send said data to the LLM Model operating through vLLM and capable of interpreting the data and generating a correct DSL query, with the ability to receive from the LLM Model the generated DSL query and send it to the DSL Query Correction Unit; - at least one LLM Model – an artificial intelligence program trained to work with text, installed on the server; - at least one DSL Query Correction Unit configured to receive from the DSL Query Generation Unit the schema of the Database Record Table, the Scenario identifier corresponding to the user query, the user query and the generated DSL query to the Database, with the ability to correct the generated DSL query to the Database in order to replace human-readable values ​​in the DSL query with the corresponding values ​​from the rows and columns of the Table in the Database, send the corrected DSL query to the Legitimacy Verification Unit, in the event of a positive check, receive the DSL query from the Legitimacy Verification Unit, with the ability to send the DSL query to the Database and receive from the Database an excerpt from the Table of Rows and Columns of the Database related to the DSL query and containing the rows and columns of the Database related in meaning to the DSL query, formed on the basis of the DSL query received by the Database from the Correction Unit DSL request,with the ability to direct an excerpt from the Database Record Table, the original user query, the DSL query, and the Script identifier to the Response Generation Block; - at least one Database, which is software designed with the ability to store in the Database requirements for user queries in natural language and DSL queries, with the ability to establish in the Database a Table of rows and columns with records, with the ability, upon receipt from the DSL query correction unit, to generate an extract from the Table of rows and columns of the Database and send it to the DSL query correction unit; - at least one Response Generation Unit configured to receive from the DSL Query Correction Unit an excerpt from the Database Record Table related to the user query and containing the rows and columns of the Database, to receive the Scenario identifier corresponding to the user query, the user query and the DSL query, with the ability to send this excerpt from the Database, the user query and the DSL query to the LLM Model operating through vLLM and capable of interpreting the data of the excerpt from the Database and the DSL query and generating on their basis a response in natural language to the user query in natural language, to receive from the LLM Model a response in natural language and to send to the terminal equipment the generated response in natural language to the user query, the “user query – DSL query” pair and the Scenario identifier; - at least one Feedback Unit configured to receive from the user's terminal equipment a "user request - DSL request" pair, a Scenario identifier corresponding to the user request, a message about the compliance or non-compliance of the system's response in natural language with the user's original user request, with the ability, in the event of confirmation from the terminal equipment of the compliance of the response with the original user request, to transmit to the Examples Unit a message about storing in the Examples Unit the "user request - generated DSL request corresponding to the user request" pair and to transmit the said pair to the Examples Unit, with the ability, in the event of receiving from the terminal equipment a message about the non-compliance of the response with the original user request, to transmit to the Scenario, previously selected for preparing the response to the user request, the "user request - generated DSL request" pairs,about which a non-compliance message was sent" to generate a new DSL request.

2. The system of claim 1, wherein the machine-readable medium is installed on a server.

3. The system according to claim 1, wherein the machine-readable medium is installed on the user’s terminal equipment.

4. The system of paragraph 1, wherein the Vector storage is installed on a server outside the Example Block.

5. The system of paragraph 1, wherein the Vector storage is installed on the server in the Example Block.

6. The system according to paragraph 1, in which the DSL request generation unit is installed on the server.

7. The system according to paragraph 1, in which the User DSL Request Generation Unit is installed on the user’s terminal equipment.

8. The system according to paragraph 1, in which the Database is installed on a server to which a request is received from a terminal device.

9. The system according to paragraph 1, in which the Database is installed on an external server relative to the server to which the request is received from the terminal device.

10. The system of paragraph 1, in which a separate Database is installed for storing the Table of row and column records and a separate Database for storing the requirements for the user request and for the DSL request.

11. The system of claim 1, wherein the row and column record tables and the user query and DSL query requirements are stored in a single Database.

12. The system according to paragraph 1, in which the interaction of the Scenario with user queries in natural language related to the given Scenario, the schema of the Database Table of Records, the set of dictionaries for the Hint Block, the set of user queries and DSL queries for the Example Block, the set of user queries for the Scenario Selection Block is understood as the recording of the above data in the source code of the Scenario.

13. The system according to paragraph 1, in which the interaction of the Scenario with user queries in natural language related to the given Scenario, the schema of the Database Table of Records, the set of dictionaries for the Hint Block, the set of user queries and DSL queries for the Example Block, the set of user queries for the Scenario Selection Block is understood as an access to the Database, where the above-mentioned data is stored.

14. The system according to paragraph 1, in which the interaction of the Scenario with user queries in natural language related to the given Scenario, the schema of the Database Table of Records, the set of dictionaries for the Hint Block, the set of user queries and DSL queries for the Example Block, the set of user queries for the Scenario Selection Block is understood as access to a separate file installed on the server on which the above-mentioned data is stored.

15. The system of claim 1, wherein the “user request – DSL request” pair is stored on the storage device of the Example Block.

16. The system of claim 1, wherein the “user query – DSL query” pair is stored in a Vector Storage.

17. The system according to claim 1, in which the Feedback Unit is configured to send a “user request – DSL request” pair to the Example Unit for storing it as an example if feedback from the user’s terminal equipment has not been received within a time set in the system.

18. The system according to claim 1, in which the Request Processing Unit is configured to, upon receiving a user request from the terminal equipment, send a request to the Feedback Unit with a request to provide feedback from this terminal equipment on the last request from this terminal equipment, with the ability to refuse to process the user request from this user terminal equipment until a message is received from the Feedback Unit in the Request Processing Unit to provide feedback on the last user request from this terminal equipment.

19. The system according to claim 1, in which the Request Processing Unit is configured to provide, upon request of the Request Processing Unit, information on the provision of feedback from the given terminal equipment on the latest user request from the given terminal equipment.

20. A method for generating an automated response to a user request in natural language, implemented by a System for generating an automated response to a user request in natural language and including the following steps: - from the user’s terminal equipment, the user’s request in natural language is transmitted to the server; - on the server, the user request is sent to the Request Processing Unit, from where it is sent to the Legitimacy Verification Unit; - in the Legitimacy Check Block, the user request is compared with pre-established requirements for the user request; - if the Legitimacy Verification Unit detects that the user request received from the Request Processing Unit does not comply with the established requirements for the user request, the Legitimacy Verification Unit sends a message to the user’s terminal equipment about the impossibility of providing a response to the user request; - if the Legitimacy Verification Block detects that the requirements established in the Legitimacy Verification Block are met, the user request is sent from the Legitimacy Verification Block to the Request Processing Block; - after returning from the Legitimacy Check Block to the Request Processing Block, the user request is sent to the Scenario Selection Block; - in the Scenario Selection Block, the structure of the user request is determined and assigned to a specific Scenario, with the user request being assigned the identifier of this Scenario; - direct the user request from the Scenario Selection Block to the selected Scenario; - from the Scenario, the user request is sent to the Hint Block, where the words in the user request are replaced with standard words pre-set in the Hint Block; - the user request corrected in the Hint Block is returned to the Scenario; - send the user request from the Scenario to the Example Block, where the semantic vector is removed from the user request and sent to the Vector Storage; - in the Vector Storage, based on proximity to the semantic vectors of user queries located in the Vector Storage, the closest semantic vector is searched for; - if the closest semantic vector is found in the Vector Storage, a pair of “the user query found by the semantic vector and the corresponding DSL query” is found in the Example Block; - the “user request – DSL request” pair found in the Example Block is sent to the Scenario together with the original user request, or only the original user request is sent to the Scenario if the “user request – DSL request” pair was not found in the Example Block; - from the Scenario, the user query corrected in the Hint Block is sent to the DSL Query Generation Block together with the Database Record Table schema, the Scenario identifier corresponding to the user query, and relevant examples; - from the DSL Query Generation Block, the corrected original user query in natural language, the Scenario identifier corresponding to the user query, the Database Record Table schema and relevant examples are sent to the LLM Model; - The LLM model interprets the data from the corrected original user query in natural language, the Database Table schema and relevant examples and generates a DSL query; - the generated DSL request is sent from the LLM Model to the DSL Request Generation Block; - from the DSL Request Generation Block, the Scenario identifier corresponding to the user request, the DSL request and the original user request are sent to the DSL Request Correction Block; - in the DSL Query Correction Block, human-readable values ​​in the DSL query are replaced with the corresponding values ​​from the rows and columns in the Database Table; - the corrected DSL request from the Correction Block is sent to the Legitimacy Check Block in order to check for compliance with the system requirements for the DSL request; - if the Legitimacy Verification Block detects a discrepancy with the system requirements for a DSL request, a message is sent to the user's terminal equipment about the impossibility of providing a response to the user's request; - if the Legitimacy Check Block detects compliance with the system requirements for the DSL request, the DSL request is returned to the DSL Request Correction Block; - after the DSL request is received by the DSL request correction unit from the Legitimacy Unit, the DSL request is sent to the Database; - The database receives a DSL request, generates an extract from the Database Record Table in accordance with the DSL request, and sends the extract to the DSL Request Correction Block; - The DSL Request Correction Block transmits to the Response Generation Block the original user request, the Scenario identifier corresponding to the user request, the DSL request and an excerpt from the Database Record Table; - The response generation block transfers to the LLM Model the original user request, the DSL request and an excerpt from the Database Record Table; - The LLM model interprets data from the original user request, DSL request and excerpt from the Database Record Table, generates a response in natural language and sends it to the Response Generation Block; - The response generation unit receives the generated response in natural language to the user request and transmits it to the user's terminal equipment together with the original user request and the corresponding DSL request, the Scenario identifier corresponding to the user request, a message for the user about the need to provide information about the compliance or non-compliance of the response with the user request (hereinafter referred to as the "feedback message"); - after receiving a response in natural language, a Scenario identifier corresponding to the user request, the original user request, the corresponding DSL request and a feedback message at the user’s terminal equipment, information on the compliance or non-compliance of the response with the user request, as well as the “user request – DSL request” pair, is sent from the user’s terminal equipment to the Feedback Unit; - if the Feedback Block receives from the user's terminal equipment a message about the response matching the user's request together with the original user request and the DSL request, the Feedback Block sends to the Example Block the "user request - DSL request" pair and a message about saving the "user request - DSL request" pair for further use for future requests as examples; - when a message about saving the “user query – DSL query” pair is received by the Example Block, the “user query – DSL query” pair is saved, and the semantic vector is removed from the user query and saved in the Vector Storage; - if the Feedback Unit receives from the user's terminal equipment a message about a discrepancy between the response and the user request, together with the original user request and the DSL request, the Scenario identifier corresponding to the user request, the Feedback Unit transmits to the corresponding Scenario that initially received the user request, the original user request, the incorrectly generated DSL request in order to begin the process of forming a new response to the user request.

Images