Information processing device, information processing method, and information processing program

Abstract

An information processing device according to the present invention generates a first prompt sentence that requests a trained model to create feedback to a user incorporating the content of the user's answer to a question, inputs the first prompt sentence into the trained model, and outputs, to the user, the output generated by the trained model in response to the first prompt sentence. The information processing device further generates a second prompt sentence that requests the trained model to create, on the basis of the answer content, a report to the user's supervisor reporting the state of the user, inputs the second prompt sentence into the trained model, and outputs, to the supervisor, the output generated by the trained model in response to the second prompt sentence. The first prompt sentence and the second prompt sentence each include a feedback policy for the answer content, derived from the same common metrics based on the result of an analysis of the answer content (Fig. 11).

Description

Information processing apparatus, information processing method, and information processing program

[0001] The present invention relates to a technique for providing feedback according to user input content.

[0002] Maintaining and improving employees' motivation for work and engagement with the company is important because it affects individual employees' performance and, in turn, the productivity of the entire company. Therefore, in order to grasp subjective evaluations of employees such as "satisfaction" and "mental health" and appropriately address problems, surveys may be conducted on employees.

[0003] However, it is difficult for the survey implementer to consider and execute a prompt and effective response to the survey results. If the consideration and execution of the response do not go well, employees may not obtain the benefits and effects of answering the survey and may feel a sense of being forced. As a result, there are problems such as the survey itself becoming routine and employees answering subsequent surveys out of inertia, or the "satisfaction" and "mental health" actually decreasing due to stress and distrust towards the survey.

[0004] In response to such problems, there is a technique of identifying important survey items and supporting the formulation of measures by outputting scores and correlation coefficients for each survey item based on the survey results. (Patent Document 1)

[0005] Japanese Unexamined Patent Application Publication No. 2023-051718

[0006] The reason why it is difficult to consider and execute a prompt and effective response is the difficulty of achieving both the "speed" and "quality" of the response. Although conventional technologies such as Patent Document 1 can obtain judgment materials from the perspective of measure formulation, they do not solve the above-mentioned compatibility problem regarding the consideration and execution of specific measure contents.

[0007] First, regarding the "speed" issue, there is the aspect that it takes time for employees to respond after submitting a survey. Generally, aggregating and analyzing response data and deciding on the appropriate response requires significant effort from the survey provider. In particular, to obtain detailed information that cannot be grasped through multiple-choice questions alone, it is necessary to include open-ended questions, but aggregating and analyzing natural language data requires even more effort. It is also conceivable to automatically aggregate response results based on some threshold or rule, identify employees who require priority attention, and notify them with alerts. However, while some employees may receive immediate assistance, there will be variations in the response speed for each respondent, meaning that respondents who are not prioritized will not receive any benefit or effectiveness. Ideally, it is crucial for the sustainable success of the survey that all respondents receive prompt assistance and experience the benefits and effectiveness.

[0008] Next, regarding the "quality" challenge, one aspect that can be cited is the difficulty in considering and implementing effective responses. Generally, based on the survey results, companies often consider overall measures that are expected to be effective for as many employees as possible. However, factors and problems such as "satisfaction" and "mental health" often differ from employee to employee, and therefore, in order to maximize effectiveness, it would be ideal to consider individualized responses tailored to each employee. However, considering the aforementioned "speed," individualized responses take time in both consideration and implementation, so in reality, companies tend to stick to overall measures or standardized measures, and it is difficult to say that effective responses are being achieved for everyone. Furthermore, even when individualized responses are implemented, efficiency can be improved by assigning a person in charge of individualized responses (e.g., a supervisor) to each employee, but if there are individual differences in the ability of those in charge to execute, the resulting effects that each employee receives are likely to differ as well.

[0009] Because of the difficulty in balancing "speed" and "quality," employees who complete surveys often don't receive prompt and effective responses, leading them to feel like they're being forced to do it. Ideally, all employees should receive early, individualized support, while the survey administrators can reduce the burden of individual support and minimize individual differences. This is crucial for the sustained success of the survey.

[0010] This invention has been made in view of the above-mentioned problems, and addresses them by generating individualized feedback based on the responses and providing it to employees and staff. Specifically, employees can receive personalized feedback immediately after responding, and staff can receive a report with suggestions on how to respond to employees individually, thereby creating opportunities for rapid individualized support for all employees and supporting staff in data aggregation, analysis, and response planning. The aim is to achieve a swift and effective response.

[0011] The information processing device according to the present invention inputs a first prompt to a trained model, requesting the trained model to create feedback for the user by incorporating the user's answers to a question. The information processing device further inputs a second prompt to the trained model, requesting the trained model to create a report to the user's supervisor reporting the user's status. The first and second prompts include a feedback policy for the answers derived from the same common indicator based on the analysis results of the answers.

[0012] According to the information processing device of the present invention, by generating and providing individualized feedback based on the user's responses, all respondents can receive individualized support early on and feel that they are gaining benefits from participating in the survey. At the same time, by reducing the burden and individual differences in individualized support for the survey implementer, it becomes possible to support the sustained success of the survey. Issues, configurations, and effects other than those described above will be clarified by the following description of embodiments.

[0013] This is an explanatory diagram showing an overview of the system according to Embodiment 1. This is a block diagram showing example configurations of the client (CL), application server (AS), management server (MS), and LLM server (LS). This is an example of a screen operated by the administrator (AD) displayed on the client's display (CLOD). This is an example of a screen operated by the administrator (AD) displayed on the client's display (CLOD). This shows the flow of the user's (US) survey responses. This shows the flow of feedback generation. The sequence diagram explains the flow of providing a report to the leader (LD) in one instance of the report creation (MSCR) process that the management server (MS) periodically executes by schedule management (MSMB). This is an example of an application screen displayed on the client (CL) when the user (US) inputs survey responses (CLIA) and confirms feedback (CLCF). This is an example of a task instruction statement containing generation instructions to the Large-Scale Language Model (LLM) used when generating feedback for the user (US). This is an example of input data and output data, which are the generated results, sent together with the task instruction statement. This is an example of an application screen displayed to the client (CL) when the leader (LD) performs report confirmation (CLCR). This is an example of a task instruction document containing generation instructions to the Large-Scale Language Model (LLM) used when generating feedback for the leader (LD). This is an example of input data and output data, which are the generated results, sent together with the task instruction document. This is an example of a screen in which comment input (AS36) and response report (AS37) have been added to the report confirmation screen (AS30) in Figure 10 of Embodiment 1. This is an example of an application screen displayed to the client (CL) when the user (US) checks the logs of previous answers and feedback content. This is an example of a task instruction document containing generation instructions to the Large-Scale Language Model (LLM) used when generating feedback for the leader (LD) in Embodiment 2. This is an example of input data and output data, which are the generated results, sent together with the task instruction document. This is a schematic diagram showing the components of the user task instruction document (TPU20) in Embodiment 3.This is an example of an application screen displayed on the client (CL) in Embodiment 3.

[0014] One embodiment of the present invention is a pulse survey type system that conducts surveys periodically, characterized in that a large-scale language model (LLM) generates feedback based on employee response data. It should be noted that the system is not limited to pulse surveys; for example, a survey conducted once a year is also possible.

[0015] The following definitions are used to describe the present invention. "Input data" refers to text data obtained by converting survey response data, etc., into a predetermined format. "Output data" refers to text data generated and output by a Large-Scale Language Model (LLM). "Instruction text" refers to all or part of the text data input to the Large-Scale Language Model (LLM), and when it is specifically referred to as "task instruction text," it refers to text data that describes the detailed specifications for generating the "output data" for the "input data."

[0016] <Embodiment 1> <Figure 1: System Overview> Figure 1 is an explanatory diagram showing an overview of the system according to Embodiment 1 of the present invention. This system generates and provides feedback text to the user (the respondent) and their support staff (the leader) based on the user's answers to a survey. The leader is ultimately provided with a report combining the feedback text and other information.

[0017] In Embodiment 1 of the present invention, the feedback provision system includes a management server (MS) and an application server (AS). However, these servers may be configured by a common computer, or either or both may be configured by multiple computers. Furthermore, the feedback provision system may also include an LLM server (LS) and a client (CL). The application server (AS), management server (MS), LLM server (LS), and client (CL) are connected by a network (NW).

[0018] The User (US) is the person who answers the survey, operates the Client (CL), and communicates with the Application Server (AS). The Leader (LD) is the person who supports the User (US), operates the Client (CL), and communicates with the Application Server (AS) and the Management Server (MS). The Administrator (AD) is the person who sets up the survey, operates the Client (CL), and communicates with the Application Server (AS) and the Management Server (MS). The Administrator (AD) may also directly operate the Application Server (AS) and the Management Server (MS). The Leader (LD) and Administrator (AD) roles may be held by the same person.

[0019] <Figure 2: System Configuration Diagram> Figure 2 is a block diagram showing example configurations of the client (CL), application server (AS), management server (MS), and LLM server (LS) according to Embodiment 1 of the present invention. Each of these has a transmitting and receiving unit and can connect to each other via a network (NW). The clients (CL) operated by the user (US), the leader (LD) (the supervisor of the user US), and the administrator (AD) are not distinguished in Figure 2.

[0020] Although shown separately for illustrative purposes, each of the processes illustrated works in conjunction with the others. Furthermore, each function in the diagram is realized through the collaboration of hardware and software. As is clear from the diagram, each of these components has a control unit, a memory unit, and a transceiver unit. The control unit consists of a central processing unit (CPU), which is the processing unit of a typical computer, the memory unit consists of a memory device such as a semiconductor memory device or a magnetic memory device, and the transceiver unit consists of a network interface such as wired or wireless. In addition, each component is equipped with a clock or other necessary features as needed.

[0021] A client (CL) is a device such as a personal computer, smartphone, or tablet. A client (CL) has an input / output unit (CLIO), a control unit (CLCO), and a transceiver unit (CLSR).

[0022] The input / output section (CLIO) includes a keyboard (CLIK) for text input, a display (CLOD) for outputting images and text, and can also be connected to other input / output devices, such as a mouse (not shown), a touch panel (not shown), or a microphone (not shown) for voice input, via external terminals (not shown).

[0023] The control unit (CLCO) performs input / output control (CLCC) and screen display (CLDD).

[0024] The Input / Output Control Unit (CLCC) receives text and operation instructions from the Input / Output Unit (CLIO). It also receives screen rendering commands from other servers (e.g., ASDD or MSDD) and renders them using the Screen Display Unit (CLDD) in a size and format appropriate for the display (CLOD), outputting them to the display (CLOD) via the Input / Output Control Unit (CLCC).

[0025] The application server (AS) comprises a memory unit (ASME), a control unit (ASCO), and a transmission / reception unit (ASSR). It plays a role in exchanging information between humans and the system, for example, by receiving survey responses from users (US) and providing feedback through a screen like the one shown in Figure 7. Figure 7 will be explained later.

[0026] The memory unit (ASME) includes a clock (ASCK) and is responsible for storing information necessary for the application.

[0027] The control unit (ASCO) receives requests from the client (CL) and performs tasks such as user authentication (ASUC), requesting FB creation (ASRF), and screen rendering (ASDD).

[0028] The transmitting / receiving unit (ASSR) transmits and receives data with the management server (MS), client (CL), etc., via the network (NW), and performs communication control for this purpose.

[0029] The management server (MS) acts as an intermediary between the application server (AS) and the LLM server (LS), and is responsible for managing the survey execution schedule and instructions related to feedback generation based on the survey settings registered by the administrator (AD).

[0030] The management server (MS) comprises a storage unit (MSME), a control unit (MSCO), and a transceiver unit (MSSR).

[0031] The memory unit (MSME) stores user information (MSUS), survey setting information (MSTS), question setting information (MSSTQ), survey reservation information (MSRS), report reservation information (MSRR), user response information (MSTA), user feedback information (MSTU), reader feedback information (MSTL), standardized user instructions (MSPU), standardized reader instructions (MSPL), instruction information (MSTP), and the clock (MSCK).

[0032] User information (ASUS) is a table stored in the database that manages information about users authorized to use the application (not shown in the diagram). It stores encrypted user IDs, names, email addresses, and login passwords. It also stores information about each user's roles and groups. Details about roles and groups will be described later in Figure 3.

[0033] Similarly, survey setting information (MSTS), question setting information (MSTQ), survey reservation information (MSRS), report reservation information (MSRR), user response information (MSTA), user feedback information (MSTU), leader feedback information (MSTL), and instruction information (MSTP) are also tables stored in the database (not shown). The data stored in each will be described later in the explanation of the related diagrams.

[0034] User Standard Instructions (MSPU) and Leader Standard Instructions (MSPL) are template text data containing only the instructions that are commonly used regardless of the question content, among the task instructions that instruct the Large-Scale Language Model (LLM) to generate feedback. By embedding question information, as shown in the example screen in Figure 4, into these standard instructions, the user task instructions (TPU10) and leader task instructions (TPL10) shown in Figures 8 and 11, respectively, are completed. Further details will be explained later in the description of Figure 4.

[0035] The Control Unit (MSCO) performs tasks such as data exchange with the Application Server (AS), data exchange with the LLM Server (LS), and rendering of survey setting screens for the Administrator (AD). The Control Unit (MSCO) includes the following functional units for performing these processes: data storage (MSSD), screen rendering (MSDD), schedule management (MSMB), task instruction creation (MSCP), response request distribution (MSDR), report creation (MSCR), user input preprocessing (MSIU), reader input preprocessing (MSIL), instruction construction (MSBP), and instruction transmission (MSSP). Details of each function will be described later in the management screens of Figures 3-4 and the sequence diagrams of Figures 5-6.

[0036] The transmitting / receiving unit (MSSR) transmits and receives data between application servers (AS), clients (CL), LLM servers (LS), etc., via the network (NW), and controls the communication for this purpose.

[0037] An LLM server (LS) is a server that includes a Large-Scale Language Model (LLM) and consists of a transceiver unit (LSSR) for receiving input and output from external terminals, a storage unit (LSME) for storing the Large-Scale Language Model (LLM), and a control unit (LSCO) for controlling input / output and computation.

[0038] The control unit (LSCO) includes receiving instructions from the management server (MS) to the large-scale language model (LLM) via instruction reception (LSRP), controlling the generation process (LSGA) performed in the large-scale language model (LLM), and transmitting the generated output data to the management server (MS) via transmission (LSSA).

[0039] The Large-Scale Language Model (LLM) within the Memory Unit (LSME) is a pre-trained model that has been machine-learned using a large amount of natural language data. The Large-Scale Language Model (LLM) is a type of artificial intelligence that pre-trains on vast amounts of text data and uses it to perform natural language processing tasks such as text classification, generation, text summarization, and question answering, ultimately generating text. By using the Large-Scale Language Model (LLM), it is possible to process lengthy texts in a short amount of time and convert them into shorter forms (numbers or summaries) that explain the writer's situation.

[0040] Regarding large-scale language models (LLMs), any known model may be used; for example, a so-called generative AI for natural language processing that supports natural language input and output can be used. Specific examples include, but are not limited to, ChatGPT, GPT3, and GPT4. Since the methods of using these are well known to those skilled in the art, they will not be described in detail in the embodiments of this invention.

[0041] <Figures 3-4: Management Screen> Figures 3-4 are examples of screens operated by the administrator (AD) that are displayed on the client's display (CLOD) in an embodiment of the present invention. The administrator (AD) connects to the management server (MS) from the client (CL), launches the application, and operates the screen. At startup, authentication may be performed to determine whether the administrator (AD) has viewing and operation privileges.

[0042] The survey settings screen (MS10) in Figure 3 is an example of a screen for configuring various settings related to conducting a survey. The survey settings screen (MS10) may also include, for example, distribution settings (MS11), user settings (MS12), and question settings (MS13).

[0043] The distribution setting (MS11) is an item for setting the execution schedule of regular surveys and the schedule for providing reports. It may include a title (MS11_1) that serves as the name of the survey, a period (MS11_2) for setting the overall start and end dates, the distribution frequency (MS11_3) of the regular survey, the response deadline (MS11_4) for each regular survey, the distribution time (MS11_5) of each regular survey, and the report frequency (MS11_6) provided to the reader (LD).

[0044] In the example of FIG. 3, the distribution frequency (MS11_3) indicates that a request for response is distributed (MSDR) to the user (US) every Friday, but the administrator (AD) may be able to set it flexibly. For the repetition period, units such as "daily", "weekly", "monthly", "yearly", etc. can be selected, and by combining with a numerical value, settings such as every other week or once a month can be enabled. Also, when "weekly" is selected, additional day-of-the-week selection buttons (multiple selection available) may be displayed as in the example of FIG. 3 so that the preferred day of the week can be specified. On the other hand, when "monthly" is selected, a UI for specifying the execution timing such as "9th day" or "second Monday" may be displayed.

[0045] The number of times of conducting the regular survey is automatically determined by the combination of the period (MS11_2) and the distribution frequency (MS11_3). Instead of setting the end date, the number of distributions may be directly specified.

[0046] The response deadline (MS11_4) is an item for specifying the valid time for responses to each regular survey. After the elapse of this time since the survey is distributed, the user (US) cannot respond to that round of the survey. Instead of being specified by the administrator (AD), it may be automatically determined, for example, until the date and time of the next survey distribution is used as the response deadline.

[0047] The report frequency (MS11_6) is an item for setting the timing at which the reader (LD) receives reports. In the example of FIG. 3, it indicates that the reader receives reports every time the periodic survey is conducted twice. It can be set flexibly, for example, set to "every time" if the reader (LD) wants to timely grasp the status of the user (US). Also, instead of the frequency standard of the periodic survey, the frequency can be set based on other criteria, such as receiving a report with the previous month as the aggregation period on the 1st of each month.

[0048] The user settings (MS12) is an item for registering information of the user (US) and the reader (LD). When the administrator (AD) inputs information (MS12_1) such as name, email address, role, etc., that person is registered as a system user. The role is a label for identifying whether that person is a user (US) who answers the survey or a reader (LD) who receives reports. In the example of FIG. 3, the user (US) is managed with the label "user" and the reader (LD) is managed with the label "reader". If you want to newly add, edit, or delete a user (US) or a reader (LD), you may press the edit button (MS12_2) to perform the operation.

[0049] A group of users (US) and readers (LD) can be defined as a group (MS12_3), and multiple groups can be managed. The group can be used to define the relationship between the user (US) and the reader (LD). For example, the support person for the users (US) belonging to Group 1 is limited to only the readers (LD) belonging to Group 1, and readers (LD) of other groups (for example, Group 2) are not allowed to view the response content of the users (US) in Group 1 and the reports based on it. By doing so, it becomes possible to flexibly define line relationships such as superiors and subordinates within the organization. Note that a user (US) and a reader (LD) may each belong to multiple groups. Also, there may be multiple users (US) and readers (LD) in each group. Indirectly, it is also possible to reflect the complex multi-layered structure of the organization.

[0050] Question settings (MS13) define the survey questions and answer methods. By pressing the question editing button (MS13_1), you can edit the questions on the question editing screen (MS20) shown in Figure 4, for example. Once all settings are complete, pressing the confirmation screen button (MS14) will take you to the settings confirmation screen (not shown), and if there are no problems, the settings information will be sent to the management server (MS). Distribution settings (MS11) are saved as data (MSSD) in Survey Settings Information (MSTS), user settings (MS12) in User Information (MSUS), and Question Settings (MS13) in Question Settings Information (MSTQ). Survey Settings Information (MSTS), User Information (MSUS), and Question Settings Information (MSTQ) are managed by assigning IDs to each record as needed, and by adding foreign key fields to establish relationships between them.

[0051] The question editing screen (MS20) in Figure 4 is an example of an operation screen for creating, editing, and saving survey questions. If the administrator (AD) wants to reuse questions from a survey conducted in the past, they can, for example, select the title of the past survey (MS21_1) and press the load button (MS21_2) to copy and display past data for subsequent input items. The question editing screen (MS20) may also include the purpose of the survey (MS22) and the detailed settings for the survey questions (MS23).

[0052] The Survey Question Details Settings (MS23) is an example of a UI for setting the content of each question. By pressing the Add Question button (MS24), this UI is added, and the content of each question can be set. It may also include UIs for rearranging the order of questions, copying questions, and deleting questions. The setting items for a question may include the question text (MS23_1), answer type (MS23_2), and required settings (MS23_3). The question text (MS23_1) can be set freely by the administrator (AD) by accepting text input, or it may accept a dropdown selection to choose from pre-set questions. The answer type (MS23_2) is an item that sets whether the question is a multiple-choice answer or a written answer. In the case of a multiple-choice answer, in the example in Figure 4, if you select the answer type "Single Selection" or "Multiple Selections Allowed" from the dropdown, additional answer options (MS23_4) will be displayed. Each option accepts text input, and the number of options can be freely changed. The required setting (MS23_3) allows you to specify whether the user (US) is required to answer the question.

[0053] Finally, the survey objective (MS22) and question intent (MS23_5), which are characteristic setting items in Embodiment 1 of the present invention, will be explained. The survey objective (MS22) is a text input box in which the administrator (AD) enters an explanatory text about the overall aim and expectations of conducting this survey. Similarly, the question intent (MS23_5) is a text input box in which the administrator (AD) enters an explanatory text about supplementary explanations, aims, and expectations for each question. Both the survey objective (MS22) and the question intent (MS23_5) are items for describing additional information that cannot be fully reflected by the content described in the question text (MS23_1) and answer choices (MS23_4), and are used as part of the task instruction text used for feedback generation (see Figures 8 and 11 for details). In Embodiment 1 of the present invention, feedback is generated based on the survey responses. However, in order for the feedback to be effective and beneficial to the user (US) and leader (LD), it is necessary to accurately understand the intent and purpose of the survey itself and generate the feedback considering that it is based on the responses to that survey. For this reason, it is usually necessary for the administrator (AD), who is the question designer for the survey, to customize and create task instructions in accordance with the intent of the question design. However, creating task instructions every time a new question is designed is a heavy burden for the administrator (AD). Therefore, in the present invention, task instructions (standard user instructions (MSPU) and standard leader instructions (MSPL)) that serve as templates including basic instructions for feedback generation are prepared, and by embedding the question settings (MS13) set on the screen in Figure 4 into these templates, task instructions that match the intent of the question design are automatically created. By embedding the survey objective (MS22) and question intent (MS23_5) together, the aim and background of the question design, which cannot be expressed in the question text alone, can be added to the task instruction text, making it possible to support the generation of useful feedback that matches the intentions of the administrator (AD). In addition, it becomes possible to generate general feedback regardless of the question design created by the administrator (AD).

[0054] Once all settings are complete, press the Complete button (MS25) to finish setting up the questions and return to the survey settings screen (MS10) shown in Figure 3.

[0055] The information set by the administrator (AD) in the screens shown in Figures 3 and 4 has been explained above. Based on the set information, the survey is designed and registered in the system. After registration, the management server (MS) performs task instruction creation (MSCP) and schedule management (MSMB). Task instruction creation (MSCP), as mentioned above, is the process of embedding question setting (MS13) information into the user standard instruction (MSPU) and the leader standard instruction (MSPL), and returns user task instruction (TPU10) and leader task instruction (TPL10) as output results, as exemplified in Figures 8 and 11. The output results are saved as data (MSSD) in instruction information (MSTP) and managed in association with the IDs of survey setting information (MSTS) and question setting information (MSTQ).

[0056] Schedule Management (MSMB) schedules the distribution of response requests to users (US) (MSDR) and the creation of reports to leaders (LD) (MSCR) based on the information in the distribution settings (MS11). Based on the information in the distribution settings (MS11), Schedule Management (MSMB) determines the number of periodic surveys to be conducted, the number of each survey, the distribution date and time, and the response deadline date and time, and saves each survey as an individual record with an ID in the Survey Reservation Information (MSRS) (MSSD). Similarly, it determines the number of reports to be provided, the number of each survey, and the creation date and time, and saves each report as an individual record with an ID in the Report Reservation Information (MSRR) (MSSD). In addition to the aforementioned ID, number of surveys, and various dates and times, Survey Reservation Information (MSRS) and Report Reservation Information (MSRR) shall hold an external key for linking with Survey Settings Information (MSTS). Furthermore, the Report Reservation Information (MSRR) shall also maintain an additional foreign key to link with the Survey Reservation Information (MSRS) in order to identify the session number of the periodic survey that each report will aggregate. Subsequently, the Schedule Management (MSMB) will refer to the clock (MSCK) and, when the date and time recorded in the Survey Reservation Information (MSRS) and Report Reservation Information (MSRR) arrives, it will execute the processes of sending out request for responses (MSDR) and creating reports (MSCR), respectively.

[0057] <Figures 5-6: Sequence Diagrams> Figures 5-6 are sequence diagrams showing an example of the processing steps performed in Embodiment 1. Of these, Figure 5 represents the process of receiving survey responses from the user (US) and generating feedback therefrom, and Figure 6 represents the process of creating a report for the leader (LD).

[0058] Let's explain the sequence diagram in Figure 5. The sequence diagram in Figure 5 illustrates the flow of user (US) survey responses (Figure 5A) and feedback generation (Figure 5B) in a single distribution of a Request for Response (MSDR) that is periodically executed by the Management Server (MS) through Schedule Management (MSMB). For illustrative purposes, it is shown as a process for one user (US), but if there are multiple targets, it will be executed for multiple users (US).

[0059] Let's start with Figure 5A. The management server (MS) is activated by a timer (MSST) when the delivery date and time recorded in the survey reservation information (MSRS) arrives, and begins processing the response request distribution (MSDR). The response request distribution (MSDR) issues a URL (with an expiration date) for responding to the periodic survey for that periodic survey, extracts the email addresses of the users (US) who are eligible to receive the periodic survey for that periodic survey from the user information (MSUS), and notifies the users (US) of the URL. The means of notification at this time can be anything, such as email, chat, or SMS.

[0060] The user (US) operates the client (CL) and launches the application (CLSA) by accessing the URL sent to them, and then sends a user authentication (ASUC) request to the application server (AS).

[0061] When the application server (AS) receives a request, it sends a request to the management server (MS) to verify that the email address and password match those registered in the user information (MSUS) stored on the management server (MS). Once it has confirmed that the user is indeed the registered user (US), the management server (MS) retrieves the necessary information, such as question information, from a designated table in the storage unit (MSME) and sends a response to the application server (AS). Based on the received information, the application server (AS) renders a screen (MSDD) as exemplified at the top of Figure 7 and displays it on the client (CL).

[0062] Furthermore, to reduce the burden on users (US), the user authentication (ASUC) step may be omitted. In that case, the request for response distribution (MSDR) may issue a URL for each recipient and notify each recipient's email address, and verify that only the owner of the email address can access it, thereby serving as identity verification.

[0063] The user (US) enters their answers to the survey (CLIA) on a response screen as illustrated in the upper part of Figure 7, and submits the response data. When the application server (AS) receives the response data, it sends a waiting message (ASMW), and the client (CL) displays the waiting message (CLMW) until feedback is received. If the waiting time is not expected to be long, (ASMW) and (CLMW) may be omitted.

[0064] Next, Figure 5B will be explained. While the application server (AS) has the client (CL) on standby (CLMW), it executes an FB creation request (ASRF) and sends a request to the management server (MS). When the request is made, the user (US) information, the response data, and the response date and time (measured by the clock (ASCK)) are sent together. When the management server (MS) receives the request, it executes user input preprocessing (MSIU). User input preprocessing (MSIU) is the process of converting the received response data into a predetermined format, creating user input data (IDU10) as shown in Figure 9, for example. Then, the instruction statement construction (MSBP) extracts the user task instruction statement (TPU10) (see Figure 8 for details) linked to the ID of the survey setting from the instruction statement information (MSTP), and combines it with the user input data (IDU10) mentioned above to complete the final instruction statement for requesting feedback generation from the LLM server (LS). This instruction document incorporates an individual response policy that determines the direction of the feedback content. Furthermore, as will be described later in Figure 6, the same individual response policy is also incorporated into the feedback instruction document generated for the user's (US) leader (LD). This ensures that the direction of the feedback content received by both the user (US) and the leader (LD) is consistent (see Figures 8, 9, 11, and 12 for details on the individual response policy). Finally, the constructed instruction document is sent to the LLM server (LS) (MSSP). Upon receiving the instruction document (LSRP), the LLM server (LS) inputs it into the Large-Scale Language Model (LLM) and executes the generation process (LSGA). Based on the content of the instruction document, the Large-Scale Language Model (LLM) generates user output data (ODU10), for example, as shown in Figure 9. Once the generation process (LSGA) is complete, the user output data (ODU10) is sent to the management server (MS) (LSSA). Upon receiving a response, the management server (MS) saves the response data to the user response information (MSTA), and saves the user input data (IDU10) and user output data (ODU10) to the user FB information (MSTU) (MSSD).

[0065] User Response Information (MSTA) is a table that stores the response history of each user (US), recording ID, user ID, ID of the survey reservation for the current session, identification information for each question (question ID, question number, question text, etc.), the content of the answer to that question, the date and time of the answer, etc. User Feedback Information (MSTU) is a table that stores the feedback history generated for each user's (US) responses, recording ID, input data, output data, etc. In addition, User Feedback Information (MSTU) holds corresponding IDs for User Response Information (MSTA) and Instruction Information (MSTP), and is linked to the response data and task instructions used to generate the feedback.

[0066] The management server (MS) sends the output data to the application server (AS) as a response to the feedback request (ASRF). The application server (AS) extracts the necessary data from various tables and performs screen rendering (ASDD), displaying it on the client (CL) screen (CLDD). The client (CL) finishes waiting (CLMW), and a screen like the one shown at the bottom of Figure 7 is displayed, and the user (US) checks the feedback based on their responses (CLCF).

[0067] Let's explain the sequence diagram in Figure 6. The sequence diagram in Figure 6 illustrates the flow of report provision to the Reader (LD) during a single report creation process, which is performed periodically by the Management Server (MS) through Schedule Management (MSMB).

[0068] The management server (MS) is activated by a timer (MSST) when the delivery date and time recorded in the report reservation information (MSRR) arrives, and then executes the report creation (MSCR) process. In report creation (MSCR), if there are multiple targets for which reports are to be created, a loop process is performed for each target and the process is repeated. First, the target selection (MSCR1) lists all the targets for creation in the report reservation for that round and selects one of them as the target for creation. In Embodiment 1, a report is provided to the leader (LD) of the group to which a user (US) belongs, based on the response data of a certain user (US). Therefore, there are as many targets for creation as there are pairs of users (US) and leaders (LD) belonging to the same group. For example, the target selection (MSCR1) may extract the target group from the user information (MSUS) and select one pair of users (US) and leaders (LD) as the target for creation.

[0069] Next, the Reader Input Preprocessing (MSIL) is executed for the selected target. Reader Input Preprocessing (MSIL) is a process that extracts the data necessary for report creation from user response information (MSTA) and user FB information (MSTU) and converts it into a predetermined format, creating input data such as that shown in Figure 12. Then, the Instruction Statement Construction (MSBP) extracts the reader task instruction statement (TPL10) (see Figure 11 for details) linked to the survey setting ID from the instruction statement information (MSTP), and combines it with the input data to complete the final instruction statement for requesting feedback generation from the LLM server (LS). Note that this instruction statement incorporates the same individual response policy used to generate feedback for the user (US) in question, as mentioned earlier in Figure 5B (see Figure 12 for details). Finally, the constructed instruction statement is sent to the LLM server (LS) (MSSP).

[0070] When the LLM server (LS) receives an instruction (LSRP), it inputs it into the Large-Scale Language Model (LLM) and executes the generation process (LSGA). Based on the content of the instruction, the Large-Scale Language Model (LLM) generates output data, such as that shown in Figure 12. Once the generation process (LSGA) is complete, it sends the output data to the management server (MS) (LSSA).

[0071] When the management server (MS) receives a response, it saves the reader input data (IDL10) and reader output data (ODL10) to the reader FB information (MSTL) using data saving (MSSD). Here, the reader FB information (MSTL) is a table that stores the feedback history generated for the reader (LD), recording IDs, input data, output data, etc., and also holding the IDs of the corresponding report reservation information (MSRR) and instruction information (MSTP). After saving the data, if there are still items to be created, the process is repeated (MSCR2) and returned to the selection of items to be created (MSCR1). If there are no items to be created, the report creation (MSCR) process is terminated (MSCR3).

[0072] The leader (LD) can launch the application (CLSA) at any time and send a user authentication (ASUC) request to the application server (AS). Alternatively, the leader (LD) may be prompted to launch the application (CLSA) by receiving a notification to their email address after the report generation (MSCR) is complete. If authentication is successful, the management server (MS) sends the output data to the application server (AS), and the application server (AS) extracts the necessary data from various tables, performs screen rendering (ASDD), and displays it on the client (CL) screen (CLDD). The client (CL) will see a screen like the one shown in Figure 10, for example, and the leader (LD) will check the report (CLCR) regarding the user (US) for whom they are the support person.

[0073] As explained in Figures 5 and 6, employees (Users) can receive feedback immediately after completing the survey. The Large-Scale Language Model (LLM) generates feedback in natural, non-standardized language that is tailored to each employee's response, ensuring that all respondents receive personalized support from the system. Similarly, leaders (LDs) also receive reports offering guidance and advice based on the responses, enabling them to provide prompt support to users.

[0074] <Figure 7: User Application Screen> Figure 7 is an example of an application screen displayed to the client (CL) when the user (US) enters their survey responses (CLIA) and checks the feedback (CLCF). For illustrative purposes, Figure 7 is divided into upper and lower sections. When the user enters their responses on the upper screen, the process described in the sequence diagram of Figure 5B is executed, and the user transitions to the lower screen where the feedback is displayed.

[0075] The survey response screen (AS10) may include, for example, survey information (AS11), a response input screen (AS12), and a response submission button (AS13). The survey information (AS11) may display, for example, the title (MS11_1) set in the survey management screen (MS10) in Figure 3, the survey number indicating which periodic survey it is, and the date the response request was sent or the response deadline. The response input screen (AS12) displays the question text and answer choices set in the question editing screen (MS20) in Figure 4, as well as a UI for entering the answer. When the response submission button (AS13) is pressed with answers entered for all required questions, the response data is sent to the application server (AS).

[0076] The feedback confirmation screen (AS20) may include, for example, target information (AS21), feedback display screen (AS22), and history display (AS23). Target information (AS21) may display information such as the name of the respondent user (US) and the date and time of the response. The feedback display screen (AS22) displays the feedback text generated by the Large-Scale Language Model (LLM) based on the response content submitted earlier. If necessary, a UI may be included for the user (US) to evaluate the quality of the feedback text or request regeneration. Additionally, a screen may be provided to check the history of the user's past responses and the feedback texts therein, and a UI for displaying the history (AS23) may be included.

[0077] <Figures 8-9: User Task Instructions and Input / Output> Figures 8-9 show examples of task instructions (Figure 8) that contain generation instructions to a Large-Scale Language Model (LLM) used when generating feedback for the user (US), and input data and output data (Figure 9) that are sent together with the task instructions.

[0078] The user task instruction text (TPU10) in Figure 8 will now be explained. As previously mentioned in the explanations of Figures 2 and 4, the user task instruction text (TPU10) is text data created by embedding question information into the user standard instruction text (MSPU) and stored in the instruction text information (MSTP). The user task instruction text (TPU10) may also include basic instructions (TPU11), preliminary information (TPU12), analysis instructions (TPU13), feedback creation instructions (TPU14), and output format (TPU15).

[0079] The basic instructions (TPU11) should state that feedback should be created for the user (US). Other basic information regarding the overall outline and structure of the instructions may also be included.

[0080] The preliminary information (TPU12) may include information about the input data format as shown in Figure 9, as well as information about the survey. In the example in Figure 8, the question information entered on the question editing screen (MS20) in Figure 4 is embedded in the task instruction text in a predetermined format. In particular, by embedding information such as "purpose of implementation" and "intention of the question," it becomes possible to accurately input the background and aim of the administrator's (AD) question design as information into the Large-Scale Language Model (LLM), which is expected to improve the usefulness of feedback and the versatility of question design.

[0081] Next, we will describe the analysis instruction (TPU 13), which is a characteristic configuration in Embodiment 1 of the present invention. While the aforementioned prior information (TPU 12) inputs supplementary information regarding the administrator's (AD) question design into the large-scale language model (LLM), the analysis instruction (TPU 13) is characterized by causing the large-scale language model (LLM) itself to generate supplementary information regarding the user's (US) responses and utilizing it for feedback generation. The analysis instruction (TPU 13) includes, for example, the steps of calculating specific common indicators based on the responses to understand the user's (US) state, and determining an individual response policy for the user (US) based on the understood state. Calculation of common indicators refers to converting the user's (US) responses into common indicators that are not dependent on the question design. Determining an individual response policy refers to determining the core policy of what kind of response should be taken for the respondent based on the responses, using the common indicators.

[0082] There are two reasons for incorporating the structure of this analysis instruction (TPU13) when creating feedback. Firstly, since the Large-Scale Language Model (LLM) has a probabilistic output, if feedback is generated directly based on prior information (TPU12), not only minor wording but also the direction of the content itself may become probabilistic. In particular, if the administrator (AD) can freely design the questions, the output is likely to be unstable. Therefore, to ensure that the basic direction does not deviate regardless of the question, the response data is converted into a common index and a core policy is instructed, thereby improving the stability of the output and its versatility for questions. Secondly, in Embodiment 1, the user (US) receives feedback directly from the system and also receives support from the leader (LD), so they receive individualized support from both directions. In this case, for the individualized support to be more effective, it is desirable that the direction of the individualized support from both parties is aligned. Therefore, by utilizing the individual response policy determined in the analysis instruction (TPU13) when creating reports for the leader (LD), the direction of feedback to the user (US) and the report to the leader (LD) are aligned, improving the consistency of individual responses. This will be explained further in the descriptions of Figures 11 and 12.

[0083] In the example in Figure 8, the degree of emotional positivity is used as a common indicator, and instructions are given to evaluate it along with the reasons based on the response content. Regardless of the question, the user's (US) emotional state is judged comprehensively based on the response content to determine whether it is positive or negative, and the individual response strategy is switched accordingly. If the emotional state is negative, the strategy is to prioritize "mental care," and if it is positive, the strategy is to prioritize "advice." The common indicator and individual response strategy are not limited to the example in Figure 8. For example, motivation could be defined as the common indicator, and if it is high, the strategy could be "praise," and if it is low, "motivation," etc. Various changes are possible. Furthermore, the calculation of the common indicator and the determination of the individual response strategy can be performed using a rule-based method, for example, without using a large-scale language model (LLM). In that case, the individual response strategy determined by the rule-based method can be added to the input data in Figure 9, for example, and instructions to use it can be added to the user task instruction (TPU10). Also, the common indicator can be a quantitative indicator as well as a qualitative indicator. Furthermore, any number of individual response strategies can be prepared. Furthermore, individual response policies can be embedded not only directly in the user task instruction document (TPU10), but also from an external file, or from content entered by the administrator (AD). Individual response policies themselves may also be generated using large-scale language models (LLMs) or rule-based methods.

[0084] Finally, the feedback creation instruction (TPU14) and output format (TPU15) will be explained. The feedback creation instruction (TPU14) may instruct the creation of feedback based on the individual response policy determined in the analysis instruction (TPU13). The output format (TPU15) may instruct the output of the content generated by the analysis instruction (TPU13) and the feedback creation instruction (TPU14) in a predetermined format. In the example in Figure 8, the format is JSON, but it is not limited to this.

[0085] The user input data (IDU10) and user output data (ODU10) in Figure 9 will be explained below. The user input data (IDU10) is the user's (US) response data converted into a predetermined format. In the example in Figure 9, the user input data (IDU10) holds the response date and the content of the response to each question as JSON format text data. Note that the format does not have to be JSON format. The user output data (ODU10) is the output result generated by the Large-Scale Language Model (LLM). It holds the generation results of the analysis instruction (TPU13) and the feedback creation instruction (TPU14) according to the output format (TPU15) described in the user task instruction (TPU10) in Figure 8. Note that in the example screen in Figure 7, only the generation result of the feedback creation instruction (TPU14) is displayed to the user (US), but the generation result of the analysis instruction (TPU13) may also be displayed.

[0086] As explained in Figures 8 and 9, the task instructions and input data provide effective and useful feedback to the user (US). This allows for the generation of universally stable output data regardless of the question design.

[0087] <Figure 10: Application screen for the leader> Figure 10 is an example of an application screen displayed to the client (CL) when the leader (LD) performs report review (CLCR). The leader (LD) selects any one user (US) for whom they are the designated support person and displays this screen.

[0088] The report confirmation screen (AS30) may include, for example, report information (AS31), response content (AS32), common indicators (AS33), system response history (AS34), and feedback (AS35).

[0089] The report information (AS31) may include, for example, the name of the leader (LD), the name of the target user (US), and the aggregation period. The aggregation period may be, for example, from the date of the first distribution of the periodic survey (the two most recent surveys in the example of Figure 10) to the date of the final response deadline. In addition, more information may be presented to the leader (LD) as needed.

[0090] The response content (AS32) may display the response data of the target users (US) during the aggregation period as is, or it may be displayed in a visualized form such as a graph.

[0091] The common indicator (AS33) may display the value of the common indicator generated by the analysis instruction (TPU13) in Figure 8. In the example in Figure 10, the emotional positivity for each periodic survey is visualized to show changes over time. By combining this with data from previous aggregation periods, it may be possible to check long-term changes in the target users (US). Leaders (LDs) will be able to grasp additional information from the common indicator, not just the responses, and can use this as a reference when supporting the target users (US).

[0092] The system response history (AS34) may display the evaluation reasons for the common indicators generated by the analysis instruction (TPU13) in Figure 8, and the individual response policies decided based on them. Additionally, it may display the feedback text provided to the target user (US). The system response history (AS34) serves to show the leader (LD) what individual responses the system has taken with the target user (US) so far, and the leader (LD) can refer to the responses that the system has already taken.

[0093] The feedback (AS35) displays feedback text for the reader (LD) generated by the Large-Scale Language Model (LLM). The reader task instruction text (TPL10) shown in Figure 11 and the reader input data (IDL10) shown in Figure 12 are used to generate the feedback.

[0094] As described above, a Leader (LD) can receive a report like the one shown in Figure 10 for each user (US) to whom they are registered as a support representative. The report contains the information described above, and the Leader (LD) can use this information to provide individual support to the user (US).

[0095] <Figures 11-12: Task Instructions and Input / Output for Reader> Figures 11-12 show an example of a task instruction (Figure 11) containing instructions for generating a large-scale language model (LLM), used in Embodiment 1 to generate feedback for the reader (LD), and input data and output data (Figure 12) which are the generation results transmitted together with the task instruction.

[0096] The leader task instruction statement (TPL10) shown in Figure 11 will be explained. The leader task instruction statement (TPL10) is text data stored in the instruction information (MSTP) and is created by embedding question information into the leader standard instruction statement (MSPL). The leader task instruction statement (TPL10) may also include basic instructions (TPL11), preliminary information (TPL12), feedback creation instructions (TPL13), and output format (TPL14).

[0097] The basic instructions (TPL11) should state that feedback should be prepared for the leader (LD). Other basic information regarding the overall outline and structure of the instructions may also be included.

[0098] The preliminary information (TPL12) may include information regarding the input data format as shown in Figure 12, and information regarding the survey. Similar to the user task instruction statement (TPU10) in Figure 8, the question information is embedded in a predetermined format.

[0099] The feedback creation instruction (TPL13) may include instructions to organize the user's (US) status based on the responses and communicate it to the leader (LD), as well as instructions to make suggestions and advice regarding individualized responses to the user (US). When making suggestions and advice regarding individualized responses, instructions should be added to ensure that they are in line with the individualized response policy decided when generating the feedback to the user (US). The individualized response policy may be added as information to the input data, for example, as shown in Figure 12. By having the user (US) and the leader (LD) receive feedback based on the same policy, consistency is created in the individualized responses that both the system and the leader (LD) implement for the user (US), making them more effective. The feedback generated according to the feedback creation instruction (TPL13) is finally output according to the output format (TPL14).

[0100] The reader input data (IDL10) and reader output data (ODL10) shown in Figure 12 will be explained. The reader input data (IDL10) is the user (US) response data that is the target of the report aggregation, converted into a predetermined format. Basically, it has the same structure as the user input data (IDU10) in Figure 9, but there are some differences. First, there may be multiple response data to be aggregated, and for example, as in the example in Figure 12, the history of each response may be kept in list format, including the user's (US) response date and the content of the response to each question. Second, individual response policies (IDL11) are added, and the individual response policies determined from the user (US) response data that is the target of the report aggregation are extracted from, for example, user FB information (MSTU) and added to the reader input data (IDL10). If there are multiple response data to be aggregated, for example, only the latest individual response policy may be added as in Figure 12, or the individual response policy that was most frequently adopted during the aggregation period may be added as a representative. Additionally, supplementary information such as common indicators, other than individual response policies, may be added. Finally, a large-scale language model (LLM) generates output results such as reader output data (ODL10).

[0101] As described above, the task instructions and input data explained in Figures 11 and 12 provide effective and useful reports to the Leader (LD). From the report, the Leader (LD) can obtain information about the User's (US) current situation and proposed individual responses, thereby reducing the burden and individual differences in considering individual responses. Furthermore, from the User's (US) perspective, they can receive individual responses based on a consistent policy from both the system and the Leader (LD), and synergistic effects can be expected.

[0102] <Embodiment 1: Summary> The management server (MS) (information processing device) according to Embodiment 1 is configured such that the control unit (MSCO) manages the execution schedule for distributing response requests and reports based on the survey settings, receives responses from users (US), and acquires feedback from large-scale language models (LLM), and transmits it to the users (US) and readers (LD) in a predetermined format. As a result, users (US) can receive personalized feedback based on their responses immediately after submitting them, and readers (LD) can also receive reports that include advice and suggestions on how to respond individually, thereby enabling the rapid creation of opportunities for individual responses and supporting aggregation, analysis, and response planning.

[0103] The management server (MS) according to Embodiment 1 includes a storage unit (MSME) that stores standardized instruction statements (standardized instruction statements for users (MSPU), standardized instruction statements for leaders (MSPL)) that include instructions for generating feedback for users (US) and leaders (LD), respectively. The control unit (MSCO) embeds detailed question design information entered by the administrator (AD) into each standardized instruction statement and creates task instruction statements (task instruction statements for users (TPU10), task instruction statements for leaders (TPL10)) specifically for that question design. The task instruction statements contain instructions to generate feedback for both users (US) and leaders (LD) based on the same policy. This makes it possible to generate feedback that accurately reflects the design intent of the question and to unify the direction of feedback for both users (US) and leaders (LD), thereby realizing more effective individualized responses.

[0104] <Embodiment 2> Embodiment 2 of the present invention adds additional components to further support the sustained success of the survey in Embodiment 1. In Embodiment 1, the leader (LD) receives the report and is provided with advice and guidance on individualized responses. Embodiment 2 further provides support for the implementation and effectiveness verification of those individualized responses. Embodiment 2 will be described below, but the parts common to Embodiment 1 will be omitted from the explanation.

[0105] In Embodiment 2, in addition to the system configuration of the management server (MS) in Embodiment 1, the memory unit (MSME) also includes reader execution information (MSTE) (not shown). Furthermore, the instruction content in the reader standard instruction statement (MSPL) of the memory unit (MSME) and the processing content in the reader input preprocessing (MSIL) of the control unit (MSCO) are modified from Embodiment 1. Details will be described later in the descriptions of the relevant drawings.

[0106] Figure 13 is an example screen in Embodiment 1, where comment input (AS36) and response report (AS37) have been added to the report confirmation screen (AS30) of Figure 10. The comment input (AS36) is a text input box for the leader (LD) to enter comments for the target user (US) after confirming the contents of the report. By entering a comment here and pressing the submit button, the comment content is directly displayed to the user (US) on a screen such as Figure 14. The response report (AS37) is a text input box for the leader (LD) to enter a report on the individual actions actually taken for the target user (US). The information entered here is used as part of the input data in Figure 16, for example.

[0107] Information entered in comment input (AS36) and response report (AS37) is stored in the Leader Execution Information (MSTE). The Leader Execution Information (MSTE) includes, for example, the leader's ID, the target user's ID, the report ID, the text of the comment input, the text of the response report, the date and time of the comment input, and the date and time of the response report.

[0108] Figure 14 shows an example of an application screen displayed to the client (CL) when the user (US) checks the log of past responses and feedback. This screen may be accessed by pressing, for example, the history display (AS23) button in Figure 7. When the client (CL) sends a screen display request, the management server (MS) extracts the necessary data from various related tables, and the screen is displayed when the client (CL) receives it as a response.

[0109] The response log screen (AS40) may include, for example, a response / feedback history (AS41) and a leader comment (AS42). The response / feedback history (AS41) may display the user's (US) past responses and the feedback received therein. The leader comment (AS42) displays the comment entered by the leader (LD) in the comment input (AS36) in Figure 13. If necessary, the leader's name and the date and time of comment input may also be displayed. If the leader (LD) has not entered a comment, a waiting message such as "Waiting for comment" may be displayed.

[0110] As explained in Figures 13 and 14, the leader (LD) can review the report and immediately send comments, enabling them to quickly provide initial support to the target users (US). Users (US) will be more likely to realize the benefits and effects of answering the survey when they receive comments from the leader (LD).

[0111] Figures 15 and 16 show examples of a task instruction statement (Figure 15) containing generation instructions to a large-scale language model (LLM) used to generate feedback to a reader (LD) in Embodiment 2, and input data and output data (Figure 16) which are the generation results transmitted together with the task instruction statement.

[0112] The leader task instruction statement (TPL20) in Figure 15 will now be explained. The leader task instruction statement (TPL20) in Figure 15 was created by modifying the instruction content of the leader standard instruction statement (MSPL) in Embodiment 1 and embedding question information. The leader task instruction statement (TPL20) may include basic instructions (TPL21), preliminary information (TPL22), feedback creation instructions (TPL23), and output format (TPL24). Of these, all except the basic instructions (TPL21) have been modified from Embodiment 1, and will be explained below.

[0113] The preliminary information (TPL22) may include information regarding the format of the input data and information regarding the survey, similar to Embodiment 1. Regarding the input data, there are changes from Embodiment 1 as shown in Figure 16, so the information regarding the format of the input data has been modified to match the format of the reader input data (IDL20) in Figure 16. The changes to the input data will be described later in Figure 16.

[0114] The feedback creation instruction (TPL23), similar to Embodiment 1, may include instructions for organizing the content of the target user's (US) responses and for proposing individualized responses. In addition, Embodiment 2 adds instructions for verifying the effectiveness of the individualized responses previously performed by the leader. The individualized responses previously performed by the leader (LD) refer to, for example, the information entered in the response report (AS37) on the screen in Figure 13, which is also added to the leader's input data (IDL20) in Figure 16. The instructions for effectiveness verification may include, for example, instructions to compare the content of the target user's (US) responses from the previous period with the content of their responses from the current period, and to infer how the individualized responses previously performed by the leader (LD) influenced whether or not there was a change.

[0115] In the feedback creation instruction (TPL23), the suggestion instruction is written after the effectiveness evaluation instruction. By writing in this order, the Large-Scale Language Model (LLM) generates text in the order of presenting the effectiveness evaluation followed by the suggestion. Therefore, support suggestions based on the effectiveness evaluation can be obtained from the Large-Scale Language Model (LLM).

[0116] The output format (TPL24) can be either a format in which the text generated according to the instructions in the feedback creation instruction (TPL23) is divided into smaller parts, or a format in which it is all combined into one. In the example in Figure 15, the instructions specify that the text generated by the instructions for organizing the response content, verifying the effectiveness, and proposing individual responses should be output separately.

[0117] The reader data (IDL20) and reader output data (IDL20) shown in Figure 16 will be explained. In the reader input data (IDL20) shown in Figure 16, the difference from Embodiment 1 is that the period (IDL21) and correspondence report (IDL22) have been added. The reader input preprocessing (MSIL) extracts information related to the above period (IDL21) and correspondence report (IDL22) from the relevant tables and creates the reader input data (IDL20).

[0118] In Embodiment 1, the input data only included response data for the aggregation period of the report in question. However, in Embodiment 2, in addition to the response data for the aggregation period of the previous report, the input data for the aggregation period of the previous report is also included. Therefore, by adding date information for the previous and current periods, as in Period (IDL 21), it is possible to distinguish between response data from different aggregation periods. Note that the format may differ from Period (IDL 21) as long as it can be distinguished. Next, as a change from Embodiment 1, there is a correspondence report (AS 37) on the report confirmation screen (AS 30) in Figure 13, so the information entered by the reader (LD) during the previous report confirmation is added to the input data as a correspondence report (IDL 22). Finally, the Large-Scale Language Model (LLM) generates an output result like the reader input data (IDL 20).

[0119] With the addition of the time period (IDL21) and response report (IDL22), the input data now includes the target user's (US) previous response, the individual actions taken by the leader (LD) in the previous session, and the target user's (US) current response. The Large-Scale Language Model (LLM) uses this information according to the task instructions to generate the feedback text for this report.

[0120] As explained in Figures 13, 15, and 16, the leader (LD) receives the report, reviews the advice and suggestions regarding individual support, and then implements individual support for the target user (US), such as conducting one-on-one meetings or providing work support. After implementation, the LD inputs the details of the individual support implemented on the screen shown in Figure 13 and reports it to the system. In the next report, the LD can gain insights through feedback about the impact of the previously implemented individual support on the target user (US). This makes it easy for the leader (LD) to run the effectiveness verification cycle from collecting survey responses to implementing and evaluating individual support.

[0121] <Embodiment 2: Summary> In Embodiment 2, the management server (MS) has a control unit (MSCO) that receives comment inputs and response reports from the leader (LD) and stores them in the leader execution information (MSTE) of the storage unit (MSME). The control unit (MSCO) sends the information received in the comment input directly to the user (US), and the information received in the response report is added to the input data and sent to the large-scale language model (LLM), thereby generating feedback that describes the evaluation of the individual responses performed by the leader (LD). This enables the leader (LD) to continuously improve individual responses and supports the sustained success of the survey.

[0122] <Embodiment 3> Embodiment 3 of the present invention adds further diversity and depth to the content of the feedback in Embodiment 1, and develops it through an interactive process. This improvement makes it possible to generate better feedback and produce beneficial effects for the user (US). Embodiment 3 will be described below, but the parts that are common with Embodiment 1 will be omitted from the explanation.

[0123] In Embodiment 3, in addition to the system configuration of the management server (MS) in Embodiment 1, the control unit (MSCO) also includes an interaction control (MSCI) (not shown). The interaction control (MSCI) is a function for controlling the interactive responses between the user (US) and the system.

[0124] Similar to Embodiment 1, after the user (US) completes the survey, feedback generated by the LLM server (LS) is displayed on the client (CL) screen for the user to review. The user (US) can further input additional information by operating the client (CL), and the entered information is sent to the management server (MS) (see Figure 18 for an example of the information input screen). Interaction control (MSCI) is responsible for managing the information exchange between the client (CL) and the LLM server (LS), and manages a series of dialogue processes, including sending the information received from the client (CL) along with task instructions to the LLM server (LS), and sending the information generated by the LLM server (LS) back to the client (CL).

[0125] In Embodiment 3, the structure of the task instruction statement that directs the generation of feedback is modified in order to make the content of the feedback even more useful. Specifically, the system that provides the feedback is given a specific character, and the structure is modified so that feedback is generated for the user's (US) answers based on that character setting. Furthermore, as a feature, the structure is modified so that the feedback content is refined through repeated discussions between characters with multiple different settings, each exchanging their opinions on the answers.

[0126] Figure 17 is a schematic diagram showing the components of a user task instruction statement (TPU 20) in Embodiment 3. The user task instruction statement (TPU 20) may include basic instructions (TPU 21), preliminary information (TPU 22), analysis instructions (TPU 23), feedback creation instructions (TPU 24), and output format (TPU 25). The components other than the feedback creation instructions (TPU 24) may be the same as those in Embodiment 1, and their explanation is omitted here.

[0127] The feedback creation instruction (TPU24) includes a character generation instruction (TPU24_1) and a character discussion instruction (TPU24_3), and may also include a character selection instruction (TPU24_2) and a user confirmation instruction (TPU24_4).

[0128] The character generation instruction (TPU24_1) includes instructions for generating characters with distinctive tendencies regarding their feedback stance and direction. For example, various patterns are possible, such as characters that primarily provide harsh reprimands or characters that primarily provide support and empathy, but these are not the only examples. The instruction also specifies that multiple types of characters must be generated, and in particular, that each character has a completely different feedback stance and direction. This is because it is expected that interaction will occur when characters with different characteristics engage in discussions, resulting in high-quality feedback that combines creativity based on a broad perspective with objectivity based on diverse values.

[0129] The character generation instruction (TPU24_1) includes two types of instructions: a step to define the number of character types and a step to define the characteristics of each character.

[0130] In the step of defining the number of character types, for example, there may be instructions for a human to directly define the number of types. Alternatively, it may be dynamically determined based on user (US) input or other survey information (question content, number of times conducted, etc.).

[0131] In the step of defining the characteristics of each character, for example, setting items for defining characteristics may be prepared, and distinctive characters may be generated by determining the setting values ​​for each item. Specific examples of setting items include, but are not limited to, name, age, gender, occupation, role, expertise, personality traits, values, beliefs, catchphrases, tone of voice, emotional expression, presence or absence of humor, etc. If a human directly defines the setting values ​​for each item, it is necessary to define different settings for each character so that the characteristics of each character are different from those of the others. Alternatively, a large-scale language model (LLM) may be used to generate the setting values ​​for each item instead of a human. In that case as well, it may be possible to instruct the model to generate setting values ​​that are different from those of each character so that characters with different characteristics are generated.

[0132] On the other hand, a Large-Scale Language Model (LLM) can be instructed to generate characters from scratch without providing any settings to define their characteristics. For example, it could analyze user (US) input to categorize topics, and if that topic falls under the category of "career concerns," it could be instructed to generate a character with matching expertise, such as a "career counselor." Alternatively, it could perform sentiment analysis on user (US) input, and if it detects "anxiety," it could be instructed to generate a character with an optimal speaking tone, such as a "calm and reassuring senior colleague." Furthermore, it could be instructed to generate characters entirely improvisationally based on the input.

[0133] The character selection instruction (TPU24_2) includes instructions for selecting characters to participate in the discussion from among the characters generated by the aforementioned character generation instruction (TPU24_1). This instruction includes two types of instructions: a step to determine the range of selectable characters and a step to determine the selection method.

[0134] The step of determining the selectable range includes instructions for determining a specific numerical range for the number of selectable character types. In this invention, since it is meaningful for multiple characters to interact with each other, the number of selectable character types must be two or more. The upper limit of the number of types may be directly defined by a human, or it may be dynamically determined based on user (US) input or other survey information (question content, number of times conducted, etc.).

[0135] The step of determining the selection method includes instructions for deciding how to select a character. For example, the system may be instructed to select a character based on selection criteria directly defined by a human, or it may be instructed to dynamically select a character based on user (US) input. If selection criteria are provided, the simplest method is to select a character randomly, within the upper and lower limits determined in the step of determining the selectable range. If the selection is based on user (US) input, there are two possible patterns: the system makes the selection, or the user (US) selects the character through interactive responses. In the former case, the system may be instructed to select a character with the expertise or personality traits that best match the user's (US) input. In the latter case, as shown in the example screen in Figure 18A, the system may display a list of selectable characters on the client (CL) screen operated by the user (US), and the user (US) may be instructed to select a character by inputting information on which character's feedback they wish to receive. By allowing users (US) to freely select their characters, it becomes possible to reflect their preferences and wishes in the stance and direction of feedback.

[0136] The character discussion instruction (TPU24_3) includes three types of instructions: a step defining how the discussion will proceed among the multiple characters selected by the aforementioned character selection instruction (TPU24_2), a step defining the termination conditions, and a step summarizing the conclusions.

[0137] The first step in defining the discussion process involves defining how each character will develop the discussion. For example, you could specify the direction and agenda of the discussion, or you could specify the order in which to speak and the rules for speaking. As a concrete example of the direction and agenda of the discussion, you could specify instructions that define the perspective and flow of the discussion, such as "First, we will extract the user's problems, then discuss solutions and action guidelines, and finally discuss a concrete action plan." As a concrete example of the order in which to speak and the rules for speaking, you could specify arrangements such as "Characters who have a positive opinion on the user's response will speak first," or "At least one character will always express a critical opinion on the user's response."

[0138] Next, in the step of defining the discussion termination conditions, you define the criteria for determining when to end the discussion. For example, you may specify the number of discussion repetitions or the number of characters as termination conditions. For example, you may specify "end the discussion after three rounds" or "end the discussion after a total of 1000 characters have been discussed." Also, if the discussion is repeated multiple times, you may specify, for example, to display an intermediate conclusion each time the discussion ends. Furthermore, termination conditions may be set quantitatively, such as the number of tokens or the number of times each character has spoken, or qualitatively, such as whether a conclusion consistent with the purpose of the discussion has been reached.

[0139] The character discussion instructions (TPU24_3) include instructions for the step of summarizing the conclusions of the discussion in order to create final feedback. Instructions may also be given on how to summarize the conclusions, such as word count or style (bullet points, etc.).

[0140] Finally, the User Confirmation Instruction (TPU24_4) includes a confirmation step to confirm with the user (US) after the discussion has concluded. This instruction may also include asking the user (US) for feedback, such as further development of the discussion or changes to the characters.

[0141] Figures 18A and 18B show examples of application screens displayed to the client (CL) in Embodiment 3. This screen is a feedback confirmation screen (AS30) displayed to the user (US), and here we will mainly explain the changes from Embodiment 1. For illustrative purposes, the first half is shown as a character selection section (Figure 18A), and the second half as a discussion and feedback provision section (Figure 18B). Also, the output example in Figure 18 shows the output results actually generated by the Large-Scale Language Model (LLM).

[0142] The feedback confirmation screen (AS30) is newly equipped with a text input box (AS39). By providing a UI that allows the user (US) to input information, interactive responses from the user (US) to the information provided by the system are made possible. Alternatively, the feedback confirmation screen (AS30) may be equipped with buttons or checkboxes with predefined response content instead of the text input box (AS39).

[0143] The explanation will begin with Figure 18A. Figure 18A shows an example of the display of information generated by the character generation instruction (TPU24_1) and character selection instruction (TPU24_2) of the user task instruction statement (TPU20) in Figure 17, and an example of the user's (US) response to it.

[0144] The character display (AS31) shows a list of characters generated by the character generation instruction (TPU24_1). In the example in Figure 18A, information on five characters with different characteristics is displayed, including a character identification number, name, occupation or expertise, personality traits, and descriptions of their way of thinking and values. In addition to this information, information defined as setting items in the character generation instruction (TPU24_1), such as age, gender, beliefs, catchphrases, tone of voice, emotional expression, and presence or absence of humor, may also be displayed. Alternatively, if the character definition is based on user (US) input, there may be a description explaining the relationship between the input and the character definition, as well as the basis for setting the character definition. Furthermore, supplementary information that allows the user to more concretely imagine the character's personality may be displayed, such as icon images for each character.

[0145] The character selection input (AS32) illustrates how a user (US) can select a character using a text input box (AS39). In the example in Figure 18A, a character is selected by entering its identification number as text. However, the selection method is not limited to this example; the character can also be selected by entering other identifying information, such as its name. Alternatively, a button or checkbox could be provided instead of a text input box (AS39) for selecting a character. The information entered by the user (US) is sent to the management server (MS), and then a discussion between characters, as shown in Figure 18B, is displayed on the client (CL).

[0146] In the example in Figure 18A, the user (US) selects the character themselves, but if the system automatically selects the character, the character selection input (AS32) is unnecessary. In that case, the screen may be displayed from the discussion display (AS33) shown in Figure 18B.

[0147] Figure 18B shows an example of the display of information generated by the character discussion instruction (TPU24_3) and user confirmation instruction (TPU24_4) from the user task instruction (TPU20) in Figure 17, and an example of the user's (US) response to it. The discussion display (AS33) displays the content of the discussion between the characters selected by the user (US). Following the procedure of the character discussion instruction (TPU24_3), the characters exchange opinions on the user's (US) response, and the discussion content is generated in such a way that it is repeated until the discussion termination condition is met. In the example in Figure 18B, information such as the name, expertise, and personality traits of each character is displayed, followed by the opinions generated based on that character setting, which are displayed as the character's statements. Although omitted for illustrative purposes, after each character has made a statement in the first discussion, a second discussion begins, and the discussion is repeated and displayed until the termination condition is met. If a termination condition other than the number of discussion repetitions is set, such as the number of characters, then relevant information such as the number of characters may be displayed together. Once the discussion is finished, the final feedback is displayed in the conclusion display (AS34). After the conclusion display (AS34), the user confirmation display (AS35) is displayed according to the user confirmation instruction (TPU24_4). The user (US) responds to the system's questions using a text input box (AS39), for example, by entering a request (AS36). The information entered by the user (US) is sent to the management server (MS), and the large-scale language model (LLM) generates new information according to the user's (US) request, and then that information is displayed on the client (CL) screen.

[0148] Embodiment 3 can be implemented using various display methods, not limited to the display example shown in Figure 18. For example, the full text may be displayed only after generation by the Large-Scale Language Model (LLM) is complete, or information may be streamed in real time during the generation process. The display order of the discussion display (AS33) and the conclusion display (AS34) may be reversed, or the user (US) may be able to switch between displaying or hiding either the discussion display (AS33) or the conclusion display (AS34). Furthermore, the content of each character's statements may be converted into media such as audio, images, or video and output as multimedia along with the text.

[0149] As described above, Embodiment 3 has the characteristic of giving the feedback provider a distinctive stance and direction, generating multiple entities with different characteristics, and refining the feedback by having these entities repeatedly discuss based on the user's input. The user can receive feedback with different ways of thinking and values, and can even experience the process of these diverse ways of thinking and values ​​fusing together to arrive at a single conclusion. This is expected to increase the user's satisfaction with the feedback and deepen their understanding of their own answers from multiple perspectives. Furthermore, the interactive process with the system makes it possible to reflect the user's own will in the feedback generation process, thereby enabling discussions to develop in line with the stance and direction desired by the user, and providing more useful feedback to the user.

[0150] In Embodiment 3, modifications were made to the feedback generation for the user (US), but similar modifications may also be made to the feedback generation for the leader (LD) as well as the user (US).

[0151] Furthermore, Embodiment 3 is not limited to the use case of generating feedback for survey responses, but can be broadly applied to the basic use case of large-scale language models, such as generating answers to questions and consultations entered by users. Large-scale language models basically determine the next token with the highest probability based on a vast amount of training data during the process of generating text. Therefore, the answers generated to questions and consultations tend to be somewhat average. By defining character settings and other elements in the instruction text and instructing the model to generate distinctive answers that deviate from the average answer, users are more likely to gain unexpected perspectives and new insights. However, on the other hand, simply giving users biased answers that only look at things from one perspective leaves the challenge that the answers will not be essentially useful to the questions and consultations. Therefore, the method of Embodiment 3, which presents diverse ways of thinking that look at things from various perspectives, fuses these ways of thinking, and derives essentially meaningful ways of thinking, is useful. By having characters discuss things as in Embodiment 3 and providing the user with both the discussion process and the final conclusion, it is possible to provide essentially useful answers based on multifaceted perspectives. Embodiment 3 can be applied to all use cases that require such essentially useful answers.

[0152] <Embodiment 3: Summary> The management server (MS) according to Embodiment 3 is equipped with an interaction control (MSCI) in the control unit (MSCO) for managing interactive responses between the user (US) and the system. User (US) input information is sent to the LLM server (LS) along with a user task instruction document (TPU20) containing character generation instructions and character discussion instructions. The Large-Scale Language Model (LLM) generates characters with multiple different characteristics and discussions between characters based on the user's (US) input information, and the generation results are sent to the user (US). This allows the user (US) to confirm the conclusions derived based on diverse perspectives and the discussion content that led to those conclusions, and to receive useful feedback. As a result, the effects and benefits that the user (US) can obtain from survey responses can be further improved.

[0153] <Regarding Variations of the Invention> The present invention is not limited to the embodiments described above, and includes various variations. For example, the embodiments described above are described in detail to make the present invention easier to understand, and are not necessarily limited to those having all the described configurations. Furthermore, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. In addition, it is possible to add, delete, or replace parts of the configuration of each embodiment with other configurations.

[0154] In the embodiments described above, ChatGPT and others were given as examples of systems employing LLM, but other language models may also be used. For example, any language model that learns the probability of how natural the arrangement of words that make up a sentence is as natural language, and is configured to output an answer to a natural language question when a natural language question is input, would suffice.

[0155] Each of the configurations, functions, processing units, processing means, etc. in the above embodiments may be implemented in hardware, in whole or in part, for example, by designing them as integrated circuits. Alternatively, each of the above configurations, functions, etc. may be implemented in software by a processor interpreting and executing a program that implements each function. Information such as programs, tables, and files that implement each function can be stored in storage devices such as non-volatile semiconductor memory, hard disk drives, SSDs (Solid State Drives), or computer-readable non-temporary data storage media such as IC cards, SD cards, and DVDs. For example, a control unit (MSCO) can be configured by hardware such as a circuit device that implements its function, or it can be configured by a computing device such as a CPU (Central Processing Unit) executing software (information processing program) that implements its function.

[0156] The control lines and information lines in the above embodiments are those deemed necessary for illustrative purposes and do not necessarily represent all control lines and information lines in the actual product. In practice, it can be assumed that almost all components are interconnected.

[0157] AD Administrator AS Application Server ASCO Control Unit ASME Memory Unit CL Client LS LLM Server LD Reader MS Management Server MSCO Control Unit MSME Memory Unit NW Network US User

Claims

1. An information processing device comprising a memory for storing a program and a processor for executing the program, wherein the processor receives the user's answer to a question, generates a first prompt sentence by incorporating the answer into a pre-configured sentence requesting a trained model to create feedback for the user, inputs the first prompt sentence to the trained model, outputs the output from the trained model based on the first prompt sentence to the user, generates a second prompt sentence by incorporating the answer into a pre-configured sentence requesting the trained model to create a report for the user's supervisor based on the answer, inputs the second prompt sentence to the trained model, outputs the output from the trained model based on the second prompt sentence to the supervisor, and the first prompt sentence and the second prompt sentence include a feedback policy for the answer derived from the same common index based on the analysis results of the answer.

2. The information processing apparatus according to claim 1, wherein the first prompt sentence includes a sentence that notifies the trained model of the purpose of conducting a user survey consisting of one or more of the questions, and the processor inputs the first prompt sentence including the purpose to the trained model, thereby requesting the trained model to create the feedback that reflects the intentions of the designer of the user survey.

3. The information processing apparatus according to claim 1, wherein the first prompt statement includes a statement that notifies the trained model of the designer's intent for each of the questions, and the processor requests the trained model to create the feedback that reflects the designer's intent by inputting the first prompt statement containing the designer's intent for each of the questions to the trained model.

4. The information processing apparatus according to claim 1, wherein the first prompt statement includes a statement requesting the trained model to calculate the common index, the first prompt statement further includes a statement requesting the trained model to create the feedback to the user based on the calculated common index, and the processor obtains the feedback created by the trained model based on the common index from the trained model by inputting the first prompt statement requesting the trained model to create the feedback based on the common index to the trained model.

5. The information processing apparatus according to claim 1, wherein the first prompt statement includes a statement requesting the trained model to convert the response content into the common index, and the processor inputs the first prompt statement requesting the trained model to convert the response content into the common index to the trained model, thereby obtaining the feedback created by the trained model based on the common index calculated from the response content from the trained model.

6. The information processing apparatus according to claim 1, wherein the second prompt sentence includes a sentence representing the feedback policy created by the trained model based on the common indicators, and the processor outputs to the supervisor the report created by the trained model based on the same policy as the feedback output to the user by inputting the second prompt sentence including the policy to the trained model.

7. The information processing apparatus according to claim 1, characterized in that the processor receives a document describing the actions taken by the supervisor on the user based on the report, the second prompt document includes a document describing the actions and a document requesting the trained model to verify the effects of the actions based on the changes in the response content, the processor inputs the second prompt document requesting the trained model to verify the effects of the actions to the trained model, thereby obtaining from the trained model the result of the trained model's estimation of the impact the actions had on the user, and the processor presents the result of the trained model's estimation of the effects of the actions to the supervisor.

8. The information processing apparatus according to claim 1, wherein the second prompt statement includes a statement in which the supervisor requests the trained model to suggest support that the supervisor should provide to the user based on the response content, the processor receives the support suggestion from the trained model by inputting the second prompt statement requesting the support suggestion to the trained model, and the processor presents the support suggestion received from the trained model to the supervisor.

9. The information processing apparatus according to claim 7, characterized in that the second prompt statement includes a statement in which the supervisor requests the trained model to suggest support that the supervisor should provide to the user based on the response content, the processor receives the support suggestion from the trained model by inputting the second prompt statement requesting the support suggestion to the trained model, and the second prompt statement contains a statement requesting the verification of the effect of the action, followed by a statement requesting the support suggestion.

10. The information processing apparatus according to claim 1, wherein the first prompt sentence includes a sentence requesting the trained model to generate a virtual character that provides the feedback, the processor receives the feedback in the form of an utterance by the virtual character by inputting the first prompt sentence requesting the virtual character to generate to the trained model, and the processor outputs the feedback to the user in the form of an utterance by the virtual character.

11. The information processing apparatus according to claim 10, wherein the first prompt statement includes a statement requesting the trained model to create at least a first character and a second character having different characteristics from each other as virtual characters, the first prompt statement further includes a statement requesting the trained model to conduct a virtual discussion between the virtual characters to provide the feedback, the processor receives the progress of the virtual discussion from the trained model by inputting the first prompt statement requesting the trained model to conduct the virtual discussion, and the processor presents the progress of the virtual discussion received from the trained model to the user.

12. The information processing apparatus according to claim 11, wherein the first prompt statement includes a statement defining a method for conducting the virtual discussion, and the processor receives the progress of the virtual discussion as it has progressed according to the method by inputting the first prompt statement including the method to the trained model.

13. The information processing apparatus according to claim 11, wherein the first prompt statement includes a statement defining a termination condition for the virtual discussion, and the processor receives from the trained model the progress of the virtual discussion that terminates in accordance with the termination condition by inputting the first prompt statement including the termination condition to the trained model.

14. The information processing apparatus according to claim 10, wherein the first prompt sentence includes characteristic instructions that instruct the trained model on the characteristics of the virtual character, and the processor receives the feedback in the form of utterances by the virtual character that reflect the characteristic instructions by inputting the first prompt sentence including the characteristic instructions to the trained model.

15. The information processing apparatus according to claim 10, wherein the first prompt sentence includes a sentence requesting the trained model to generate the virtual character having appropriate characteristics suitable for providing advice on the response, and the processor receives the feedback from the trained model in the form of an utterance by the virtual character having characteristics suitable for providing advice by inputting the first prompt sentence including the appropriate characteristics to the trained model.

16. The information processing apparatus according to claim 1, characterized in that the trained model is configured to output an answer to a question in natural language when a question in natural language is input, by learning the probability of how natural the arrangement of words constituting a sentence is as natural language, and the processor receives the answer output as natural language by the trained model after it receives the first prompt sentence or the second prompt sentence in natural language from the trained model.

17. An information processing method comprising: receiving the user's answer to a question; generating a first prompt sentence by incorporating the answer into a pre-configured sentence requesting a trained model to create feedback for the user, and inputting the first prompt sentence into the trained model; outputting the output from the trained model based on the first prompt sentence to the user; generating a second prompt sentence by incorporating the answer into a pre-configured sentence requesting the trained model to create a report to the user's supervisor based on the answer, and inputting the second prompt sentence into the trained model; and outputting the output from the trained model based on the second prompt sentence to the supervisor, wherein the first prompt sentence and the second prompt sentence include a feedback policy for the answer derived from the same common indicator based on the analysis results of the answer.

18. An information processing program characterized in that it causes a computer to perform the following steps: receiving the user's answer to a question; generating a first prompt sentence by incorporating the answer into a pre-configured sentence requesting a trained model to create feedback for the user, and inputting the first prompt sentence into the trained model; outputting the output from the trained model based on the first prompt sentence to the user; generating a second prompt sentence by incorporating the answer into a pre-configured sentence requesting the trained model to create a report for the user's supervisor based on the answer, and inputting the second prompt sentence into the trained model; and outputting the output from the trained model based on the second prompt sentence to the supervisor, wherein the first prompt sentence and the second prompt sentence include a feedback policy for the answer derived from the same common indicator based on the analysis results of the answer.

19. An information processing device comprising a memory for storing a program and a processor for executing the program, wherein the processor receives output from the trained model in the form of utterances by the virtual characters by inputting a prompt statement to the trained model that includes a statement requesting the trained model to generate virtual characters; the processor presents the output from the trained model to the user in the form of utterances by the virtual characters; the prompt statement includes a statement requesting the trained model to create at least a first character and a second character having different characteristics as virtual characters; the prompt statement further includes a statement requesting the trained model to conduct a virtual discussion between the virtual characters; the processor receives the progress of the virtual discussion from the trained model by inputting the prompt statement requesting the trained model to conduct the virtual discussion; and the processor presents the progress of the virtual discussion received from the trained model to the user.

Images