Log collection method, terminal device, server and storage medium

Abstract

The invention discloses a log collection method, terminal equipment, a server and a storage medium, and belongs to the field of computers. The method is applied to the terminal equipment and comprises the steps of displaying a first interface; the first interface comprises a self-feedback window and is used for providing an interaction entrance for performing multiple rounds of conversations for the user and the server. The user describes a fault or a problem and the like in the self-feedback window, the server generates a question according to the description of the user, multiple rounds of dialogues are achieved until the server generates fault feedback information according to the information of the multiple rounds of dialogues, and the fault feedback information comprises fault information of the first fault. The log collection function is dynamically started according to the fault feedback information sent by the server, a user does not need to select a fault type and manually start the log collection function, and the accuracy of the log data is improved. And under the condition that the first fault is detected, log data are collected and automatically triggered and stored through a log collection function, and then the log data are sent to the server. The method does not depend on user operation, and the timeliness of the log data is improved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a log collection method, terminal equipment, server, and storage medium. Background Art

[0002] With the rapid development of terminal and network technologies, terminal devices are becoming increasingly prevalent in users' lives. However, during the use of terminal devices, some device failures are inevitable. When a terminal device encounters a problem, the user can use the terminal device's self-feedback function to select one or more fault types and temporarily enable logging for these fault types. After the user reproduces the problem, log data for different fault types is collected (i.e., captured), helping to quickly locate the user's problem.

[0003] However, the current classification of fault types is coarse and relies on user selection. If the user selects the wrong fault type, the captured log data will be less accurate. Furthermore, after capturing log data, the timing of storing (i.e., packaging) the log data also depends on user actions. For log data in areas such as communications and performance, where timeliness is a high priority, failure to promptly respond can result in less timely log data. Summary of the Invention

[0004] This application provides a log collection method, terminal device, server, and storage medium to improve the accuracy of log data. The technical solution is as follows:

[0005] In a first aspect, a log collection method is provided, which is applied to a terminal device and includes: displaying a first interface; the first interface includes a self-feedback window, which provides an interactive entry point for a multi-round dialogue between a user and a server. In the self-feedback window, a user can use text or voice to describe a fault or problem encountered. The self-feedback window acts as a bridge, establishing a communication connection between the user and the server. The server includes a robot engine that can generate questions based on the user's description, thereby enabling a multi-round dialogue between the user and the server until the server is able to generate fault feedback information based on the multi-round dialogue information, the fault feedback information including fault information for a first fault. The terminal device automatically activates a log collection function based on the fault feedback information sent by the server; the log collection function is configured to detect an abnormal scenario corresponding to the first fault. The user does not need to select a fault type or manually activate the log collection function. The log collection function is automatically activated through the multi-round dialogue information, so that when an abnormal scenario corresponding to the first fault is detected, log data for the abnormal scenario is collected, thereby improving the accuracy of the log data. Upon detecting the first fault, the terminal device uses the log collection function to promptly collect log data, and automatically triggers the storage (i.e., packaging) of the log data after collection. Send the log data to the server immediately or after a period of time. In this solution, since the log data is stored (i.e., packaged) when the first fault occurs, it does not depend on user operations. Therefore, even if the user does not upload it to the server in time, it will not affect the timeliness of the log data, thereby improving the timeliness of the log data.

[0006] In one possible implementation, a multi-round dialogue process can be implemented as follows: a terminal device detects first user input information in a self-feedback window and sends the first user input information to a server; a question information sent by the server is received and displayed in the self-feedback window; the question information is generated by the server after slot extraction from the first user input information, and the target slot extracted includes at least the fault type; the user responds based on the question information, and the terminal device detects second user input information in the self-feedback window and sends the second user input information to the server, until fault feedback information from the server is received.

[0007] The terminal device provides users with a multi-round interactive entry point. Users can edit and submit multiple questions and responses until they receive fault feedback information generated by the server based on the multi-round dialogue information. The multi-round dialogue information includes at least the first user input information, the second user input information, and the question information. Compared with solutions where users select the fault type themselves, this method better reflects the user's actual intentions, reduces ineffective dialogue, and improves feedback efficiency.

[0008] In one possible implementation, the fault feedback information is related to the target slot. If the target slot includes a fault type, the fault feedback information includes fault information of the first fault. If the target slot includes a fault application and a fault type, the fault feedback information includes fault information of the first fault of the target application. If the target slot includes a fault application, a fault type, and a fault occurrence frequency, the fault feedback information includes fault information of the first fault of the target application and the fault occurrence frequency. The embodiment of the present application does not limit the specific form of the target slot and the fault feedback information, and can be applied to more application scenarios, thereby improving the universality of the solution.

[0009] In one possible implementation, multiple levels of fault types can be set in the terminal device, and multiple second-level fault types are set under each first-level fault type. The first-level fault type is used to distinguish the field to which the first fault belongs, and the second-level fault type is used to distinguish the scenario to which the first fault belongs. Based on the fault feedback information sent by the server, the terminal device selects the first-level fault type corresponding to the field to which the first fault belongs from the multiple first-level fault types; based on the fault feedback information, the terminal device selects the second-level fault type corresponding to the scenario in which the first fault occurs from the multiple second-level fault types under the first-level fault type to which the first fault belongs. Based on the second-level fault type corresponding to the scenario in which the first fault occurs, one or more abnormal scenarios are determined; and the log collection function of each of these abnormal scenarios is enabled to detect the abnormal scenarios.

[0010] In an embodiment of the present application, there may be multiple scenarios that lead to the occurrence of the first fault. By selecting the above-mentioned first-level fault type and second-level fault type, an abnormal scenario under the second-level fault type can be obtained, thereby improving the accuracy and comprehensiveness of the log collection function for enabling abnormal scenarios.

[0011] In one possible implementation, after determining at least one abnormal scenario as described above, the terminal device can also display a second interface, in which a first function control for turning on a log collection function is also provided; in response to user operation on the first function control, the log collection function of the target abnormal scenario is turned on, and the target abnormal scenario is any abnormal scenario among at least one abnormal scenario.

[0012] In an embodiment of the present application, the log collection function that needs to be enabled is displayed in the interface, and the log collection function is enabled with the user's consent to collect log data, thereby improving the security of the log data and protecting user privacy.

[0013] In one possible implementation, the terminal device may detect whether the first fault has occurred in the following manner: detecting a dot event for a preset perception scenario; the preset perception scenario includes a business anomaly scenario and an application-related usage scenario. If a dot event is detected indicating the first fault has occurred, the first fault is reported, and log data is collected using the log collection function.

[0014] The terminal device has pre-set multiple preset perception scenarios, which include business exception scenarios (i.e., fault scenarios), and application-related usage scenarios (e.g., application opening and closing, etc.). The terminal device can insert pre-embedded programs for branches where preset perception scenarios may appear based on its own business logic, and the terminal device's dotting interface pre-applies for permission to obtain dotting events from the pre-embedded program. After the pre-embedded program captures the preset perception scenario, the dotting interface is called to obtain the dotting events captured by the pre-embedded program through the dotting interface. The dotting event includes the identifier of the preset perception scenario, and whether the first fault occurs can be determined based on the identifier of the preset perception scenario. If the first fault occurs, the collection of log data is automatically triggered. The log data is stored (i.e., packaged), and the timing of collecting log data does not depend on user operations, which improves the timeliness of the log data.

[0015] In one possible implementation, after collecting the log data, the terminal device may further display a third interface; the third interface includes a second function control, and the second function control is used to send the log data; in response to a user operation on the second function control, the log data is sent to the server.

[0016] In this example, the terminal device can also provide the user with a confirmation entry (i.e., the second function control in the third interface) to confirm whether to upload log data to the server. The user can upload log data to the server through the above confirmation entry, thereby improving the security of log data and protecting user privacy.

[0017] In one possible implementation, after enabling the log collection function, the log collection function can be disabled in the following two ways: Example 1: Disabling the log collection function after a preset period of time after enabling the log collection function; Example 2: The terminal device displays a fourth interface; the fourth interface includes a third function control for disabling the log collection function, and the log collection function is disabled in response to a user operation on the third function control.

[0018] In the embodiment of the present application, whether the user turns off the log collection function or the terminal device automatically turns off the log collection function, it is possible to avoid long-term log collection, save resources, and protect user privacy.

[0019] In the second aspect, a log collection method is provided, which is applied to a server and includes: generating fault feedback information based on multi-round dialogue information in a self-feedback window of a terminal device; the self-feedback window is used to provide an interactive entry for the user and the server to conduct multi-round dialogues, and the fault feedback information includes fault information of the first fault of the terminal device; the fault feedback information can be used to determine the log collection function that needs to be enabled, without the user having to select the fault type. By enabling the log collection function in a targeted manner, the resource consumption caused by enabling other log collection functions is reduced. Fault feedback information is sent to the terminal device; log data sent by the terminal device is received; the log data is collected by the log collection function when the first fault occurs after the terminal device enables the log collection function according to the fault feedback information. The terminal device automatically enables the log collection function according to the fault feedback information, so that when the abnormal scene corresponding to the first fault is detected, the log data of the abnormal scene is collected, thereby improving the accuracy of the log data.

[0020] In one possible implementation, fault feedback information can be generated in the following manner. First user input information in a self-feedback window sent by a terminal device is received; slot extraction is performed on the first user input information to obtain a slot extraction result. The target slot for slot extraction is related to the scenario corresponding to the problem or fault input by the user. The target slot indicates keywords required to generate fault feedback information. The server can determine the target slot by performing natural language processing on the first user input information. There can be one or more target slots for each scenario. The target slot includes at least the fault type. If the slot extraction result indicates that slot information for all target slots has been extracted, there is no need to ask the user a question; fault feedback information can be generated. If the slot extraction result indicates that slot information for at least some target slots has not been extracted, that is, slot information for all or some of the target slots has not been extracted, user information is required to provide information. A question is generated based on the slot extraction result and sent to the terminal device. The question can be generated based on some of the slots to guide the user to provide information for at least some of the slots. Continue to receive the second user input information in the self-feedback window sent by the terminal device, continue to perform slot extraction on the second user input information, obtain a slot extraction result, generate question information again based on the slot extraction result, and send the question information to the terminal device, implementing a multi-round dialogue between the user and the server until the server extracts slot information for all target slots based on the multi-round dialogue information with the user, generates fault feedback information based on the multi-round dialogue information, and stops asking questions. The second user input information indicates the user's reply information based on the question information, the multi-round dialogue information includes at least the first user input information, the second user input information, and the question information, and the fault feedback information includes fault information of the first fault.

[0021] In this embodiment, the server extracts the slot information for each round of user input. If the slot extraction fails to find the slot information for certain slots, it generates a question to guide the user to provide the slot information for certain slots. This continues until the slot information for all target slots has been extracted based on multiple rounds of conversation information. Compared to solutions where users select the fault type themselves, this precise questioning better reflects the user's actual problem, reduces ineffective conversations, and improves conversation efficiency.

[0022] In one possible implementation, after multiple rounds of conversation, the server can extract all target slots, perform conversation intent recognition on the multiple rounds of conversation information, and identify the conversation intent. The conversation intent can be a fault problem or a knowledge query. If the conversation intent is a fault problem, log collection is required to generate fault feedback information. If the conversation intent is a knowledge query, knowledge recommendation content is generated, pushed to the terminal device, and displayed on the terminal device's user interface. Compared to a unified solution that performs log collection or knowledge recommendation after multiple rounds of conversation, this method accurately identifies the conversation intent, reduces resource waste, and improves conversation processing efficiency.

[0023] In a third aspect, a log collection method is provided, which is applied to a log collection system, the log collection system including a terminal device and a server, the method including: the terminal device displays a first interface; the first interface includes a self-feedback window, the self-feedback window is used to provide an interactive entrance for a user and a server to conduct multiple rounds of dialogue, so that the server generates fault feedback information based on the multiple rounds of dialogue information, and the fault feedback information includes fault information of the first fault; the server sends the fault feedback information to the terminal device; the terminal device starts a log collection function based on the fault feedback information; the log collection function is used to detect abnormal scenarios corresponding to the first fault; when the first fault is detected, log data is collected through the log collection function; the terminal device sends the log data to the server.

[0024] In a possible implementation, the method further includes: the terminal device detects first user input information in the self-feedback window, and sends the first user input information to the server; the server performs slot extraction on the first user input information to obtain a slot extraction result, generates question information based on the slot extraction result, and sends the question information to the terminal device; the terminal device displays the question information in the self-feedback window, detects second user input information in the self-feedback window, and sends the second user input information to the server until the server generates fault feedback information based on multiple rounds of dialogue information; wherein the second user input information indicates the user's reply information based on the question information, and the multiple rounds of dialogue information at least include the first user input information, the second user input information and the question information.

[0025] The third aspect is a description of a log collection system including a server and a terminal device. The technical effects obtained are similar to those obtained by the corresponding technical means in the first and second aspects, and will not be repeated here.

[0026] In a fourth aspect, a terminal device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method described in the first aspect when executed by the processor.

[0027] The technical effect obtained by the fourth aspect is similar to the technical effect obtained by the corresponding technical means in the first aspect, and will not be repeated here.

[0028] In a fifth aspect, a server is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method described in the second aspect when executed by the processor.

[0029] The technical effect obtained in the fifth aspect is similar to the technical effect obtained by the corresponding technical means in the second aspect, and will not be repeated here.

[0030] In a sixth aspect, a computer-readable storage medium is provided, wherein instructions are stored in the computer-readable storage medium. When the computer-readable storage medium is run on a computer, the computer executes the log collection method described in the first or second aspect above.

[0031] In a seventh aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the log collection method described in the first or second aspect above.

[0032] The technical effects obtained in the sixth and seventh aspects are similar to those obtained by the corresponding technical means in the first or second aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 1 is a user interface diagram of a self-feedback operation process provided by an embodiment of the present application;

[0034] Figure 2 This is a user interface diagram of another self-feedback operation process provided by an embodiment of the present application;

[0035] Figure 3 1 is a user interface diagram of another self-feedback operation process provided by an embodiment of the present application;

[0036] Figure 4This is a user interface diagram of another self-feedback operation process provided by an embodiment of the present application;

[0037] Figure 5 This is a schematic diagram of the structure of a terminal device provided in an embodiment of the present application;

[0038] Figure 6 This is a flow chart of interaction between a terminal device and a server provided in an embodiment of the present application;

[0039] Figure 7 1 is a user interface diagram of a self-feedback window provided in an embodiment of the present application;

[0040] Figure 8 This is a schematic diagram of an interaction framework between a device-side intelligent detection application and a cloud-side robot engine provided by an embodiment of the present application;

[0041] Figure 9 This is a schematic diagram of an interaction framework between another device-side intelligent detection application and a cloud-side robot engine provided by an embodiment of the present application;

[0042] Figure 10 This is a schematic diagram of a user interface for enabling a log collection function provided in an embodiment of the present application;

[0043] Figure 11 This is a schematic diagram of another user interface for enabling the log collection function provided in an embodiment of the present application;

[0044] Figure 12 This is a schematic diagram of a user interface for submitting log data provided in an embodiment of the present application;

[0045] Figure 13 This is a schematic diagram of a user interface for exiting the log collection function provided in an embodiment of the present application;

[0046] Figure 14 This is a structural diagram of a log collection system provided by an embodiment of the present application;

[0047] Figure 15 This is a schematic diagram of a log collection process provided by an embodiment of the present application;

[0048] Figure 16 This is a flow chart of a log collection method applied to a terminal device provided in an embodiment of the present application;

[0049] Figure 17 This is a flow chart of a log collection method applied to a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0051] It should be understood that the “multiple” mentioned in this application refers to two or more. In the description of this application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; “and / or” in this article is merely a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of this application, words such as “first” and “second” are used to distinguish between identical or similar items with basically the same functions and effects. Those skilled in the art can understand that words such as “first” and “second” do not limit the quantity and execution order, and words such as “first” and “second” do not necessarily limit them to be different.

[0052] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0053] The terminal devices include, but are not limited to, mobile phones, mobile phones, foldable phones, smart terminals, laptop computers, smart wearable devices, tablet computers, desktop computers, portable computers, PDAs, wireless terminal devices, vehicle-mounted devices, smart home devices, communication devices, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (portable Android devices, PADs), portable multimedia players (PMPs), etc. The embodiments of the present application do not limit the specific types of the terminal devices.

[0054] In related technologies, users can use the self-feedback function in the terminal device to select the fault type and temporarily turn on the log switch. After the user reproduces the problem, the terminal device collects log data of different fault types, and then the user manually uploads the log data. Figures 1-4 The user interface shown illustrates the self-feedback process. The user selects a fault type on the terminal device, which then collects log data based on the fault type and sends it to the server. The server can then determine a solution based on the received log data.

[0055] like Figure 1 As shown, Figure 1 Figure A in the figure shows multiple application icons, such as the "Browser" application, the "Contacts" application, the "My Phone" application, the "Gallery" application, the "Call" application, and the "Message" application. Among them, the self-feedback interface can be entered through the "My Phone" application. The terminal device detects the user operation (such as touch operation, press operation) acting on the "My Phone" application, and in response to the above operation, opens the "My Phone" application. After opening the "My Phone" application, the terminal device displays the following Figure 1 The user interface shown in Figure B in FIG. The user interface includes multiple controls, for example, a control for providing device detection services, a control for providing in-store appointment services, a control for providing charging standard services, a control for providing mail-in repair services, etc. The terminal device detects the user operation acting on the device detection service control. In response to the above operation, the terminal device displays the following Figure 1 The user interface shown in Figure C in the figure. The user interface may first display a pop-up window. The pop-up window displays permission information to prompt the user which permissions the device detection service needs to obtain from the terminal device when using the device detection function, such as location information permission, Bluetooth permission, camera permission, microphone permission, storage permission, address book permission, application list permission, etc. The pop-up window may include a "Cancel" control and an "Agree" control. When a user operation acting on the "Agree" control is detected, the terminal device may determine that the user agrees that the device detection service obtains the above permissions and display the following information: Figure 1 Conversely, when a user operation on the "Cancel" control is detected, the terminal device can determine that the user refuses the device detection service to obtain the above permissions and fall back to the following Figure 1 The user interface shown in Figure B.

[0056] Figure 1The user interface shown in Figure D can be called a detection interface. The detection interface can display multiple modules to be detected, such as system performance, application message reception delay, communication and network, wireless local area network (WLAN), Bluetooth, gravity sensor, light sensor, charging and battery, real-time charging, proximity sensor, vibrator, etc. The detection interface displays a "Detect Now" control. The terminal device can detect user operations on the "Detect Now" control. After detecting such operations, the terminal device can test the functions or services corresponding to the modules to be detected to confirm whether each module has any faults. After completing the test of a module, the terminal device may display a "√" icon in the area corresponding to the module to indicate that the test for that module has been completed and no faults have been found. When the test of all modules has been completed and no faults have been found, the terminal device may display a "√" icon after each module and a "√" icon after "All" to indicate that no faults have been found. When a fault is found, the terminal device may display the fault details under the corresponding module. Faults detected by the "Detect Now" control are known faults.

[0057] Based on the above Figure 1 ,like Figure 2 As shown in Figure A of FIG, the detection interface may further include a "more" control. The terminal device may detect the user operation acting on the "more" control. In response to the above operation, the terminal device may display the following Figure 2 The pop-up window shown in Figure B may include multiple controls, such as diagnostic analysis controls, remote service controls, problem feedback controls, and about controls. If the "Detect Now" control fails to detect a fault, the user can use the problem feedback control to provide fault feedback.

[0058] Upon detecting an action on an autonomous feedback control (i.e., Figure 2 After the user operates the question feedback control in Figure B) in the terminal device, the terminal device can display Figure 2The user interface shown in Figure C in the figure can also be called a feedback interface or a fault type selection interface. Multiple labels can be displayed in the feedback interface, and one label corresponds to a type of fault. For example, the reliability label displayed in the feedback interface is a reliability fault, and the performance label displayed in the feedback interface is a performance fault, etc., and examples are not given here one by one. The user can determine the target label that matches it from the above multiple labels based on the scenario in which the fault is discovered. For example, when a user encounters problems such as game lag and slow startup when playing a game, the user can select the performance label to indicate that the fault encountered by the user is a performance fault. When a user encounters problems such as the game application cannot be started or crashes, the user can select the application label to indicate that the fault encountered by the user is an application fault. Corresponding prompt information can be displayed in each label, such as "problems such as freezing, restarting and upgrading" and "problems such as application and game lag and slow startup" to help users determine the type of fault.

[0059] in, Figure 2 The types of failures shown in Figure C include but are not limited to: reliability failures, performance failures, power consumption failures, communication failures, application failures, short-range failures, and device failures. Reliability failures include problems related to freezes, restarts, and upgrades. Performance failures include problems related to applications, game freezes, slow startups, etc. Power consumption failures include problems related to battery life, heating, and charging. Communication failures include problems related to call failures, inability to access the Internet, weak signals, and text message sending and receiving. Application failures include problems that arise during the use of applications. Short-range failures include problems related to Wi-Fi, Bluetooth, Global Positioning System (GPS), and Near Field Communication (NFC). Device failures include problems related to devices such as cameras, receivers, speakers, and screens.

[0060] Figure 2 The fault type in Figure C depends on the user's selection. After the user selects the fault type (for example, a performance label), the terminal device may display a window. The window displays a prompt message, such as "Enabling the log capture and upload function, and submitting the problem as soon as the problem recurs will help us better analyze the problem", to prompt the user to grant permission to obtain relevant log data. The terminal device then guides the user to enable logging. The terminal device can determine the fault type reported by the user by detecting one or more user operations on the interface, so as to facilitate subsequent log collection of the self-reported fault type.

[0061] After the user selects the fault type and opens the log, the terminal device can display Figure 2The user interface shown in Figure D in the figure may include a "next item" control. When the user selects the "next item" control, it means that the user is granted permission to obtain log data. Figure 2 After detecting the user operation on the "next item" control, the terminal device can display the following Figure 3 The user interface is shown in Figure A of FIG. This interface may include a window that displays the note information to be collected. That is, a dynamic privacy statement pops up based on the log content. The corresponding log is collected only after the user chooses to agree to open the "note information"; otherwise, the log containing this private information will not be collected. The window may include a "Cancel" control and a "Continue" control. If the user selects the "Cancel" control, it means that the user refuses to grant permission to obtain log data; conversely, if the user selects the "Continue" control, it means that the user again agrees to grant permission to obtain log data.

[0062] After detecting the user operation on the "Continue" control, the terminal device can start the log collection function associated with the selected fault type and obtain log data. At the same time, the terminal device can display Figure 3 The user interface shown in Figure B in the figure below may include prompts, such as automatically exiting diagnostic mode after 6 hours. After reproducing the issue, click "Report a Problem" on the "Smart Detection" notification card in the notification bar to submit a fault report. This prompt confirms that log collection has been enabled and provides guidance on how to enable it.

[0063] Figure 3 The user interface shown in FIG. B may also include a window. During the time range of starting log collection, the window may remain displayed in the pull-down notification interface, such as Figure 3 As shown in Figure C. The window may include an "Exit" control and a "Feedback Problem" control. After turning on the log diagnosis mode, the user can operate the terminal device to reproduce the fault so that the terminal device can obtain log data that can reflect the cause of the fault. After completing the fault reproduction, Figure 3 In Figure C, click the notification bar to slide down. Users can use the "Feedback" control to perform the next feedback operation, that is, package the log.

[0064] In response to the user operation of the "Feedback Issue" control, or after the log collection function is turned off due to the expiration of the log collection duration, the terminal device may display the following Figure 3 The user interface shown in Figure D in the figure is also called the information collection interface. The information collection interface can display multiple items, such as problem classification, problem details, the ability to add problem images, audio or video, problem occurrence time, problem occurrence probability, and problem log.

[0065] The "Problem Classification" item can be used to indicate the fault type. The type displayed in the "Problem Classification" item is the fault type previously selected by the user. The "Problem Details" item can be used to obtain descriptive information, such as the scene where the fault occurred, the situation when it occurred, etc. Figure 3 The D picture in the figure is shown as "Using application D freeze". The "Add pictures, audio or video" item can be used to obtain pictures, audio, video and other data describing the relevant situation when the fault occurs. That is, the user can Figure 3 In the information collection interface of Figure D, fill in information such as "Problem Details" and upload videos, pictures, audio, etc. related to the problem. The "Problem Occurrence Time" item can be used to obtain the specific event of the fault. The "Problem Occurrence Probability" item can be used to obtain the frequency of the fault. The collection of data corresponding to the above items is the fault description information, which can be used to further accurately determine the cause of the fault. The log data collected by the terminal device can be attached to the "Problem Log" item. The information collection interface also includes "Save" and "Submit" controls. Users can use the "Submit" control to report the fault to the server and submit the fault description information and log data at the same time. Users can use the "Save" control to store the fault description information and log data locally, and then need to use "Submit" to feedback to the server.

[0066] based on Figure 3 , Figure 3 In Figure D, after the user reports the fault to the server through the "Submit" control, the user interface displays the following Figure 4 The pop-up window shown in Figure A displays a message such as "Thank you for your feedback! We will analyze it as soon as possible and address the issue in subsequent versions. Please stay tuned for updates." The pop-up window also includes an "Got it" control.

[0067] In response to the user operation of the "know" control, the terminal device may display the following Figure 4 The user interface shown in Figure B in the figure is called the status interface. The status interface can display the feedback record of the previously submitted unknown faults, which includes the problem ticket number, creation time, problem details, problem status, number of successful feedbacks, number of failed feedbacks, number of feedbacks in progress, etc. Figure 4 In Figure B, a problem ticket number will be generated after the user submits it successfully.

[0068] In response to user actions on specific feedback records, such as Figure 4 Clicking on the B diagram in the figure can display more details in the specific feedback record, such as Figure 4 As shown in Figure C, there are two feedback records about the problem number "00001". You can view the feedback list and feedback progress. After the feedback records are uploaded, the terminal device can display the following Figure 4 The user interface shown in Figure D, Figure 4 The user interface of the D diagram in Figure 4 In the user interface of Figure B, an "append log" control is added. In response to the user operation of the "append log" control, the terminal device may display the following Figure 4 In the user interface shown in Figure E, the user can continue to supplement the submission information and can capture log data again by turning on the "Append log feedback" switch.

[0069] It should be noted that in the above Figure 2 In the D figure, if the user chooses to enable logging, the diagnostic mode will be enabled. Otherwise, the diagnostic mode will be enabled without logging feedback. Figure 3 Figure D in .

[0070] The self-feedback function and remote log collection function provided by the terminal device support problem feedback in various scenarios. Figures 1-4 The process of collecting log data has been implemented, and the feedback record includes fault description information, product information, log data, and more. In related technologies, if a user encounters a problem, they can temporarily enable logging, reproduce the problem, and provide feedback with a fault description and log data, helping the user locate the issue more quickly. However, due to the high timeliness of log data in areas such as communications and performance, for example, feedback is required within 10 seconds of the problem occurring. If the user fails to respond promptly, the collected log data will be invalid, resulting in a low timeliness of the captured log data. For example, a user may use the self-feedback function to reproduce a problem with Application A. After collecting log data for Application A, a call or message may come in, or the user may switch to Application B for other operations, or remain idle for a period of time. These factors will interrupt the feedback process. If feedback is provided after a period of time and the log data is packaged, the timeliness of the log data will be affected. In other words, for log data that relies heavily on timeliness, such as a single moment of lag, if feedback is provided a long time later, the captured log data will be invalid.

[0071] In addition, the current classification of fault types is relatively coarse and cannot accurately identify the user's detailed problem and application, resulting in vague problem descriptions. Furthermore, the current fault type depends on user selection, and different log types are captured based on the fault type. If the user's selection is incorrect, the captured logs will be invalid, resulting in low accuracy of the captured log data. For example, a chat call issue requires selecting a communication type, but the user selects an application type. Then, the relevant network logs will not be fully captured, resulting in invalid captured logs. Furthermore, communication and performance log data is relatively large, and not much log data is stored. Previously captured log data will be overwritten by later log data, making solutions that rely on user operations for log data feedback less accurate.

[0072] Based on the technical problems mentioned above, this solution provides users and servers with an interactive entrance (i.e., a self-feedback window) for multiple rounds of dialogue, based on the current self-feedback function and remote log collection function. Users can open the self-feedback window by turning on an intelligent detection application with a self-feedback function. The server relies on large model technology to generate fault feedback information when the fault information of the first fault can be determined based on multiple rounds of dialogue information, thereby achieving accurate scene recognition and improving the accuracy of identifying user problems. The log collection function is then automatically turned on based on the fault feedback information to detect the abnormal scene corresponding to the fault information of the first fault.

[0073] Currently, terminal devices have a wide range of defined problem scenarios. Enabling log collection for each scenario can overload the entire device, bloat the log data, and lead to invalid logs. This solution, based on precise scenario identification—specifically, identifying the abnormal scenario corresponding to the primary fault information—can be enabled on demand, reducing terminal load while improving log data accuracy.

[0074] This solution configures the corresponding log collection function based on fault feedback information and dynamically enables log collection. It also automatically detects abnormal scenarios (i.e., the scenarios that led to the first fault). If the first fault is detected, it automatically triggers the collection and storage (i.e., packaging) of log data. This reduces log timeliness issues caused by slow manual user operations.

[0075] This solution does not rely on user operations to collect log data. The log collection function is automatically turned on. When the first fault is detected, the log data is collected and stored. Even if it is interrupted or uploaded late, the log data of this period can be obtained, which improves the timeliness of the log data.

[0076] Before explaining in detail the log collection method provided in the embodiment of the present application, the terminal device involved in the embodiment of the present application is first explained.

[0077] Figure 5 This is a schematic diagram of the structure of a terminal device provided in an embodiment of the present application. Figure 5The terminal device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. Among them, the sensor module 180 can include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0078] It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the terminal device 100. In other embodiments of the present application, the terminal device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0079] The processor 110 may include one or more processing units, for example, an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0080] The controller may be the nerve center and command center of the terminal device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0081] The processor 110 may also include a memory for storing instructions and data.

[0082] In some embodiments, the processor 110 may include one or more interfaces, such as an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0083] It is understood that the interface connection relationship between the modules illustrated in the embodiments of the present application is merely an illustrative illustration and does not constitute a structural limitation on the terminal device 100. In other embodiments of the present application, the terminal device 100 may also adopt a different interface connection method from the above embodiments, or a combination of multiple interface connection methods.

[0084] The wireless communication function of the terminal device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0085] In some embodiments, antenna 1 of terminal device 100 is coupled to mobile communication module 150 , and antenna 2 is coupled to wireless communication module 160 , so that terminal device 100 can communicate with the network and other devices through wireless communication technology.

[0086] The terminal device 100 implements display functions through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

[0087] The terminal device 100 can realize the shooting function through the ISP, camera 193, video codec, GPU, display screen 194 and application processor.

[0088] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0089] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the terminal device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. The program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created by the terminal device 100 during use (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0090] The terminal device 100 can implement audio functions, such as music playback, recording, etc., through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D and the application processor.

[0091] The SIM card interface 195 is used to connect a SIM card. The SIM card can be connected to and disconnected from the terminal device 100 by inserting or removing it from the SIM card interface 195. The terminal device 100 can support one or N SIM card interfaces, where N is an integer greater than one. The SIM card interface 195 can support Nano SIM cards, Micro SIM cards, SIM cards, and the like. Multiple cards can be inserted into the same SIM card interface 195 at the same time. The multiple cards can be of the same or different types. The SIM card interface 195 is also compatible with different types of SIM cards. The SIM card interface 195 is also compatible with external memory cards. The terminal device 100 interacts with the network through the SIM card to implement functions such as calls and data communications. In some embodiments, the terminal device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the terminal device 100 and cannot be separated from the terminal device 100.

[0092] This method can be applied to a log collection system including a terminal device and a server. The terminal device is also called the terminal side, and the terminal device includes an intelligent detection application and a log engine. The intelligent detection application provides the user with an editing entry for inputting faults or problems, and provides the user with a confirmation entry for whether the collected log data needs to be uploaded to the server, thereby realizing privacy and security management. The user can realize multiple rounds of dialogue with the robot engine through the editing entry, and can upload log data to the server through the confirmation entry. The log engine is used to enable the log collection function, the collection of log data, and the uploading of log data according to the detection results of the intelligent detection application. The server is also called the cloud side or cloud server, and the server includes a robot engine and a log server.

[0093] like Figure 6 As shown, Figure 6 This is a flow chart of the interaction between a terminal device and a server provided in an embodiment of the present application.

[0094] S11. The terminal device displays a first interface; the first interface includes a self-feedback window.

[0095] The user opens the intelligent detection application on the terminal device, displaying the first interface. The self-feedback window in the first interface provides an interactive entry point for the user and the server to conduct a multi-round dialogue. The self-feedback window provides an editing entry for the user to enter a fault or question, allowing the user to conduct a multi-round dialogue with the robot engine.

[0096] In the embodiment of the present application, the process of the user entering the first interface is as follows: Figure 7 As shown, Figure 7 Figure A in the figure can be Figure 2 Figure B in the figure. The terminal device displays Figure 7 For the steps before Figure A, please refer to the above Figure 1 as well as Figure 2 The description of Figure A in FIG is omitted here. Figure 7 After the user operates the question feedback control in Figure A, the terminal device can display Figure 7 The user interface shown in Figure B (i.e., the first interface).

[0097] S12: The terminal device detects first user input information in the self-feedback window and sends the first user input information to the server.

[0098] The intelligent detection application of the terminal device detects the first user input information in the self-feedback window and sends the first user input information to the robot engine of the server. Generally, the first user input information is edited by the user. Figure 2The method of selecting the fault type shown in Figure C is closer to the problem encountered by the user and can better reflect the user's intention.

[0099] Users can use text or voice to describe the faults or problems they encounter in the editing entrance of the self-feedback window, such as Figure 7 Figure B shows a phone freeze (corresponding to the first user input). The intelligent detection application sends the first user input to the server. The self-feedback window acts as a bridge, establishing a communication connection between the terminal device and the robot engine. The self-feedback window sends the user's description to the robot engine, and the robot engine sends the question to the self-feedback window.

[0100] S13. The server performs slot extraction on the first user input information to obtain a slot extraction result, and generates question information according to the slot extraction result.

[0101] In the embodiment of the present application, the robot engine in the server may include a large language model and use an artificial intelligence (AI) machine learning algorithm to implement natural language processing (NLP), such as word segmentation, classification, keyword matching, etc. The robot engine performs slot extraction on the first user input information to obtain a slot extraction result, and generates questions based on the slot extraction result. That is, questions are generated based on the user's description, such as Figure 7 As shown in Figure B, we are very sorry for the bad experience we have brought you. I will work with you to resolve it. In which scenario did the lag occur? (Corresponding to the question).

[0102] The robot engine can also further generate multiple candidate scenarios based on the first user input information to prompt and guide the user's next round of responses. In this way, the question information includes not only the above question, but also multiple candidate scenarios. Figure 7 There are multiple candidate scenarios shown in Figure B: game lag, system lag after upgrade, chat application lag, application (APP) lag, video playback lag, photo and video lag, daily operation lag, and other lag scenarios.

[0103] Typically, natural language processing involves a large number of algorithms and databases, requiring a large amount of memory and computing power. Therefore, this part is deployed on the cloud side, and the robot engine extracts slots and generates question information to reduce power consumption on the terminal side and improve conversation efficiency.

[0104] In some embodiments, the server performs slot extraction on the first user input information to obtain a slot extraction result, and the target slot of the slot extraction includes at least the fault type; when the slot extraction result indicates that the slot information of at least part of the target slots has not been extracted, a question information is generated based on the slot extraction result, and the question information is used to instruct the user to provide the slot information of at least part of the slots.

[0105] In an embodiment of the present application, slot extraction is the process of extracting information related to a specified slot from a specified text (i.e., user input information). The target slot for slot extraction is related to the scenario corresponding to the problem or fault input by the user, and the target slot indicates the keywords required to generate fault feedback information. The robot engine can process the first user input information using an NLP algorithm to determine the target slots. Each scenario can have one or more target slots. The target slot includes at least the fault type. If the slot extraction result indicates that the slot information of all the target slots has been extracted, there is no need to ask the user any more questions, and fault feedback information can be generated. If the slot extraction result indicates that the slot information of at least some of the target slots has not been extracted, that is, the slot information of all the target slots has not been extracted, or the slot information of some of the target slots has not been extracted, the user needs to provide the information. Question information is generated based on the slot extraction result. The question information can be generated based on some of the slots to guide the user to provide the slot information of at least some of the slots.

[0106] It should be noted that in one implementation, if after a preset total number of rounds (for example, 5 rounds, 6 rounds, etc.), the slot information of all the target slots is not obtained, that is, the slot information of some of the target slots is obtained. Then, based on the slot information of the currently extracted slots and the user input information, the slot information is supplemented, and fault feedback information is generated to improve the efficiency of the conversation. In another implementation, if the user has not been able to reply to the slot information of some slots within a preset number of times (for example, 2 times, 3 times, etc.), the robot engine can change the question sentence structure, or, based on the slot information of the currently extracted slots and the user input information, supplement the slot information to reduce invalid conversations and improve conversation efficiency.

[0107] In this embodiment, the server's robot engine extracts slot information from each round of user input. If the slot extraction fails to find the slot information for certain slots, it generates questions to guide the user to provide slot information for certain slots, until the slot information for all target slots is extracted based on multiple rounds of conversation information. Compared to solutions where users select the fault type themselves, this precise questioning better reflects the user's actual problem, reduces ineffective conversations, and improves conversation efficiency.

[0108] S14. The server sends a question message to the terminal device.

[0109] S15. The terminal device displays the question information in the self-feedback window.

[0110] The robot engine sends the generated question information to the intelligent detection application, which displays it in the self-feedback window. In some scenarios, the question information includes a question and multiple candidate scenarios. In this case, the intelligent detection application displays the question in the self-feedback window and adds the candidate scenarios. Figure 7 As shown in Figure B, candidate scenarios may include "game freezes", "system freezes after upgrade", "chat application freezes", "application (APP) freezes", "video freezes", "photo and video freezes", "daily operation freezes", "other freeze scenarios", etc. Users can directly select any one or more of the above candidate scenarios. At the same time, the smart detection application provides an editing entry in the self-feedback window, such as Figure 7 "Please enter your question" as shown in Figure B. Users can also ignore the above candidate scenarios and use text or voice to describe the problem or issue encountered in the editing portal again.

[0111] S16. The terminal device detects second user input information in the self-feedback window and sends the second user input information to the server, where the second user input information indicates the user's reply information based on the question information.

[0112] The user responds based on the question information, which can be self-edited or selected from a candidate scenario. The intelligent detection application of the terminal device detects the second user input information in the self-feedback window and sends the second user input information to the robot engine of the server.

[0113] If the robot engine can determine the detection scenario based on the first user input, the question, and the second user input, it generates fault feedback. Otherwise, it continues to perform slot extraction on the second user input to obtain a slot extraction result. Based on the slot extraction result, it generates another question and sends it to the terminal device, thus implementing multiple rounds of dialogue between the user and the server until the robot engine is able to generate fault feedback based on the multiple rounds of dialogue information. At this point, the questioning process stops.

[0114] S17. The server generates fault feedback information based on the multi-round dialogue information; the multi-round dialogue information at least includes the first user input information, the second user input information and the question information, and the fault feedback information includes fault information of the first fault.

[0115] In some embodiments, the server continues to receive the second user input information in the self-feedback window sent by the terminal device until the slot information of all slots in the target slot is extracted based on the multi-round dialogue information with the user, and the fault feedback information is generated based on the multi-round dialogue information.

[0116] In this embodiment of the present application, the server's robot engine continues to extract slots from the second user's input information. If the slot extraction fails to extract the slot information for certain slots, it generates further questions to guide the user to provide slot information for certain slots, until the slot information for all target slots is extracted. In this way, fault feedback information can be generated based on multiple rounds of dialogue information. Compared to solutions where users select the fault type themselves, asking precise questions can better reflect the user's actual problem, reduce ineffective dialogue, and improve dialogue efficiency.

[0117] The multi-round dialogue information includes at least the first user input information, the question information, and the second user input information. If the server can determine the detection scenario based on the multi-round dialogue information, it generates fault feedback information. The fault feedback information may characterize the detection scenario and include fault information of the first fault. The fault information may include an identifier, name, or code indicating the first fault. The fault feedback information may also include the frequency of the fault.

[0118] In some embodiments, the fault feedback information is related to the target slot. The target slot extracted by the slot extraction includes the fault application and the fault type; and the fault feedback information includes fault information of the first fault of the target application.

[0119] If the target slot includes a fault type, the fault feedback information includes fault information for the first fault, for example, the phone is freezing. If the target slot includes a faulty application and a fault type, the fault feedback information includes fault information for the first fault of the target application, for example, Application D is freezing. If the target slot includes a faulty application, a fault type, and a fault frequency, the fault feedback information includes fault information for the first fault of the target application and the fault frequency, for example, Application D is frequently freezing.

[0120] The embodiment of the present application does not limit the specific form of the target slot and fault feedback information, and can be applied to more application scenarios, thereby improving the universality of the solution.

[0121] In some embodiments, during a multi-round dialogue process, dialogue intentions are identified on the multi-round dialogue information to obtain dialogue intentions, where the dialogue intentions are failure problems or knowledge inquiries. When the dialogue intentions are failure problems, fault feedback information is generated.

[0122] In the embodiment of the present application, intent recognition runs through the entire conversation process, and intent recognition may include slot extraction, question information generation, and conversation intent recognition. Among them, slot extraction and question information generation are used to assist in the recognition of conversation intent. During multiple rounds of conversation, through intent recognition, that is, through slot extraction, question information generation, and conversation intent recognition, it can be determined whether the conversation intent is a fault problem. After multiple rounds of conversation, the robot engine can extract all slots in the target slot, perform conversation intent recognition on the multiple rounds of conversation information, and identify the conversation intent. The conversation intent can be a fault problem or a knowledge query. In the case where the conversation intent is a fault problem, it indicates that log collection is required and fault feedback information is generated. In the case where the conversation intent is a knowledge query, knowledge recommendation content is generated, the knowledge recommendation content is pushed to the terminal device, and the knowledge recommendation content is displayed on the user interface of the terminal device, for example, screen care tips, tips for extending the battery life of mobile phones, etc.

[0123] In the embodiments of the present application, the intention of multiple rounds of dialogue can be not only fault or problem feedback, but also knowledge inquiry, which improves the diversity and richness of the content of human-computer dialogue. After multiple rounds of dialogue, the dialogue intention is identified for the multiple rounds of dialogue information. If the dialogue intention is identified as a fault problem, fault feedback information is generated and the subsequent log collection process continues. Compared with the unified solution of performing log collection or knowledge recommendation after multiple rounds of dialogue, the dialogue intention is accurately identified, resource waste is reduced, and the efficiency of dialogue processing is improved.

[0124] S18. The server sends fault feedback information to the terminal device.

[0125] The server's robot engine sends fault feedback information to the intelligent detection application of the terminal device.

[0126] S19. The terminal device determines the log collection function that needs to be enabled based on the fault feedback information.

[0127] The intelligent detection application of the terminal device determines the log collection function that needs to be enabled based on the fault feedback information.

[0128] S20: Send the log collection function that needs to be enabled.

[0129] The intelligent detection application of the terminal device sends the log collection function that needs to be enabled to the log engine.

[0130] S21, start the log collection function; the log collection function is used to detect the abnormal scenario corresponding to the first fault; when the first fault is detected, collect log data through the log collection function;

[0131] In the embodiment of the present application, the terminal device's log engine activates the corresponding log collection function based on the log collection function that needs to be activated. For example, when the generated fault feedback information includes fault information for the first fault, it indicates that the abnormal scenario in which the first fault occurred needs to be detected, and there is no need to detect other scenarios. By enabling the log collection function in a targeted manner, the resource consumption caused by enabling other log collection functions is reduced.

[0132] The log engine starts a corresponding log collection function, detects an abnormal scenario corresponding to the first fault, and collects log data when the first fault occurs.

[0133] For example, based on the above Figure 7 ,like Figure 8 As shown, Figure 8 This is a schematic diagram of the interaction framework between a terminal-side intelligent detection application and a cloud-side robot engine provided by an embodiment of the present application. The intelligent detection application in the terminal device provides the user with an online customer service fault feedback portal, and the user can operate the self-feedback interface in the intelligent detection application. The self-feedback interface operation can be seen in the above Figure 7 The description of the process is omitted here. The intelligent detection application sends the user input information from each round to the server's robot engine. The robot engine includes an intent recognition module, a slot extraction module, an intelligent question-and-answer module, and a task decision module. The robot engine performs intent recognition for each round of conversation. This process is performed throughout the entire conversation process and includes slot extraction, question generation, and conversation intent recognition. Figure 8 It also shows the multi-round dialogue processing process of the cloud-side robot engine. Figure 8Two rounds of dialogue are shown. In the first round, the user enters "Mobile phone lags" (i.e., the first user input) on the self-feedback interface. The robot engine parses the first user input and identifies the problem scenario as a fault, with the phone lags. The first slot extraction (i.e., slot extraction 1) is performed on the first user input, with the target slot including the fault type, faulty application, and probability of occurrence. The slot extraction result is {Fault type: lag scenario needs clarification; Faulty application: needs clarification; Probability of occurrence: needs clarification}. Based on the slot extraction result, a reply (i.e., a question) is generated: "In what scenarios do you experience lags? Does this problem always occur?" This question is sent to the intelligent detection application for the second round of dialogue. In the second round, the user enters "Application D live streaming frequently lags" (i.e., the second user input) on the self-feedback interface. The robot engine parses the second user input and identifies the problem scenario as a fault, with the key information: Application D live streaming frequently lags. The second slot extraction (i.e., slot extraction 2) is performed on the second user input, with the target slot including the fault type, faulty application, and probability of occurrence. The slot extraction result is {fault type: Application D short video - Application D malfunction - Application D freeze; faulty application: Application D; probability of occurrence: frequent}. Based on the slot extraction result, a problem summary (i.e., fault feedback information) can be generated: "Application D live streaming frequently freezes." The occurrence time can be supplemented after log data is collected.

[0134] above Figure 8 In the process, the cloud-side server builds multiple rounds of dialogues based on online customer service to fill slots, and can classify the fault type based on the user input information, so as to further perform business capabilities such as detection solutions, solution recommendations, and log collection. For example, mobile phone freeze scenarios may include: application W freezes, video freezes, network freezes during calls, interface freezes, game freezes, etc. After the user enters "mobile phone freezes", after multiple rounds of dialogues, the freeze scenario can be determined, for example, application D freezes during live broadcast. In this way, it is possible to accurately identify user problems, specific scenarios where problems are encountered, specific applications, and the frequency of problem occurrence, and generate fault feedback information, thereby improving the accuracy of problem feedback.

[0135] above Figure 8In the process, the slot extraction module performs slot extraction on the user input information in each round to obtain the slot extraction result. And when the slot extraction result indicates that the slot information of at least part of the target slots has not been extracted, the intelligent question and answer module generates question information based on the slot extraction result, and sends the question information to the intelligent detection application to realize intelligent question and answer. The intelligent question and answer module can also be understood as a question and answer robot (QA Bot) that generates question information. After multiple rounds of dialogue, dialogue intent recognition is performed. The dialogue intent can be a fault problem or a knowledge query. The task decision module makes a task decision based on the dialogue intent. If the dialogue intent is a fault problem, such as Figure 8 In the example above, fault feedback information is generated, namely, the problem summary: Application D's live broadcast often freezes. This fault feedback information is sent to the intelligent detection application. If the conversation intent is a knowledge query, for example, how to maintain a mobile phone screen, relevant knowledge recommendations are made.

[0136] above Figure 8 Also shown is the log collection process of the intelligent detection application after receiving the fault feedback information. The intelligent detection application collects logs based on the problem feedback, that is, collects log data based on the fault feedback information. The following steps may be included: automatically generate a fault summary, automatically select the fault type, automatically turn on the log switch, and automatically collect log data. Among them, the fault summary may include the fault type, the log collection function that needs to be turned on (i.e., the log switch), and the fault occurrence scenario that needs to be detected. After automatically selecting the fault type and turning on the log switch, log data is automatically collected when the fault occurrence scenario is detected. When the user chooses feedback, the log data and problem description are submitted, that is, the log data is sent to the server.

[0137] above Figure 8 In this process, multi-round conversation management is performed on the cloud side. Slot extraction is performed on each round of user input information to obtain a slot extraction result. If the slot extraction result indicates that slot information for at least some of the target slots has not been extracted, a response (i.e., question information) is generated to complete interactive round management. Conversation intent is identified for multi-round conversation information, and tasks are distributed based on the conversation intent. If the conversation intent is a knowledge query, knowledge recommendation is performed based on the conversation context. If the conversation intent is a fault problem, a problem summary (i.e., fault feedback information) is generated based on the conversation context.

[0138] It should be noted that the log collection method provided in the embodiment of the present application can also be applied to a terminal device, which can generate question information based on user input information, implement multiple rounds of dialogue with the user, and generate fault feedback information after multiple rounds of dialogue. In other words, the terminal device has the functions of slot extraction, intent recognition, intelligent question answering, and task decision-making listed in the server of the embodiment of the present application, and the collected log data can be stored in the terminal device or sent to the server. In other words, the above Figure 8 The robot engine on the cloud side can also be integrated on the end side. In this way, multi-round dialogues can be implemented between the robot engine on the end side and the intelligent detection application on the end side. The robot on the end side manages the multi-round dialogues, recognizes the dialogue intent of the multi-round dialogue information, and distributes tasks based on the dialogue intent.

[0139] In some embodiments, the terminal device enables the log collection function based on the fault feedback information sent by the server, which can be achieved in the following manner: determining, based on the fault feedback information sent by the server, a first-level fault type corresponding to the field to which the first fault belongs from multiple first-level fault types, each first-level fault type including multiple second-level fault types; determining, based on the fault feedback information, a second-level fault type corresponding to the occurrence scenario of the first fault from multiple second-level fault types under the first-level fault type to which the first fault belongs; determining at least one abnormal scenario based on the second-level fault type corresponding to the occurrence scenario of the first fault; the abnormal scenario indicates the scenario that caused the first fault; and enabling the log collection function for each abnormal scenario in the at least one abnormal scenario.

[0140] In this embodiment of the present application, multiple levels of fault types can be configured in the terminal device. Level 1 fault types include, but are not limited to, reliability faults, performance faults, power consumption faults, communication faults, application faults, short-distance faults, and device faults. Multiple level 2 fault types can also be configured for each level 1 fault type, allowing for more refined fault classification.

[0141] Among them, multiple secondary fault types under communication failures include but are not limited to: signal problems or weak signals, failed or dropped calls, voice quality issues or call failures, SMS sending and receiving, inability to access the Internet or slow Internet access, etc. Multiple secondary fault types under reliability failures include but are not limited to: freezes, restarts, upgrades, etc. Multiple secondary fault types under performance failures include but are not limited to: game lag, slow startup, application lag, etc. Multiple secondary fault types under power consumption failures include but are not limited to: battery life, charging, heat generation, etc.

[0142] The first-level fault type is used to distinguish the field to which the first fault belongs, and the second-level fault type is used to distinguish the scenario to which the first fault belongs. The second-level fault type can be used to describe unknown faults in a more detailed manner.

[0143] The fault feedback information includes the fault information of the first fault. The terminal device determines the first-level fault type corresponding to the field to which the first fault belongs from multiple first-level fault types according to the fault feedback information. Among the multiple second-level fault types under the first-level fault type corresponding to the field, the second-level fault type corresponding to the occurrence scenario of the first fault is determined according to the fault feedback information. There may be multiple abnormal scenarios that lead to the occurrence of the first fault, and the abnormal scenarios under the second-level fault types can be pre-registered and set. For example, the abnormal scenarios for application D jamming may include performance abnormalities, network abnormalities, video abnormalities, image display abnormalities, processor abnormalities, memory abnormalities, etc. According to the second-level fault type corresponding to the occurrence scenario of the first fault, one or more abnormal scenarios are determined. The log collection function of each of these abnormal scenarios is turned on to detect the abnormal scenarios, and log data is collected when abnormal scenarios are detected.

[0144] In an embodiment of the present application, there may be multiple scenarios that lead to the occurrence of the first fault. By selecting the above-mentioned first-level fault type and second-level fault type, an abnormal scenario under the second-level fault type can be obtained, thereby improving the accuracy and comprehensiveness of the log collection function for enabling abnormal scenarios.

[0145] For example, Figure 9 As shown, Figure 9 It is a schematic diagram of the interaction framework between another end-side intelligent detection application and the cloud-side robot engine provided by an embodiment of the present application. The cloud-side robot engine identifies the occurrence scenario of the fault based on multi-round dialogue information, that is, it performs intent recognition on the multi-round dialogue information. Intent recognition may include slot extraction, generation of question information and dialogue intent recognition. By filling in task information (that is, slot extraction) and multi-round questions and answers, dialogue intent recognition is performed. When the dialogue intention is that a fault problem occurs, a problem summary (that is, fault feedback information) is generated. The problem summary may include messages such as fault type, fault description, and fault frequency. The problem summary is sent to the end-side terminal device, and the terminal device turns on the corresponding log collection function based on the problem summary.

[0146] Figure 9 The first-level classification in the categorization refers to the first-level fault type, and the second-level classification refers to the second-level fault type. Among them, the second-level fault types of performance faults include, but are not limited to, Application D online video lag issues, Application W lag issues, and game lag issues. The second-level fault types of communication faults include, but are not limited to, intermittent 5G network connection issues, unclear voice calls, and signal issues. For example, for fault feedback information about Application D online video lag, the first-level fault type corresponding to its field is performance fault; the second-level fault type under performance fault is Application D online video lag.

[0147] It should be noted that Figure 9The following examples illustrate the secondary classification of performance and communication failures. It's understood that each of the other primary failure types also has multiple secondary failure types. For example, secondary failure types for power consumption failures might include rapid power loss, while secondary failure types for device failures might include speaker issues, microphone issues, and an unresponsive power button.

[0148] Pre-register the abnormal scenarios for each secondary fault type, establishing a correspondence between the secondary fault type and one or more abnormal scenarios. In practical applications, accurate scenario identification allows you to determine one or more abnormal scenarios based on the secondary fault type corresponding to the primary fault scenario, and enable log collection for these scenarios. This enables on-demand log data collection.

[0149] For example, Figure 9 As shown in the figure, the fault feedback information is Application D's online video lag. The corresponding level 1 fault type is performance fault, and the level 2 fault type is Application D's online video lag. Application D exception scenarios 1, 2, and 3 are registered, and the log collection function for these scenarios is enabled to capture logs related to the Application D exception. Enabling the log collection function and collecting log data can be achieved as follows: item field1 = "Performance", item2 field2 = "Application D lag", switch id = "Log switch 1, 2, 3", and loginfo = "Collect log data 1, 2, 3". Item field1 indicates the fault category, item field2 indicates the fault scenario, switch id indicates the log switch, and loginfo indicates the log record.

[0150] For example, Figure 9 As shown, using the fault feedback information of application W lag as an example, the corresponding first-level fault type is performance fault, and the second-level fault type is application W lag. Application W lag scenarios 4 and 5 are registered, and the log collection function for these scenarios is enabled to capture logs related to application W lag. Enabling the log collection function and collecting log data can be achieved as follows: item field1 = "Performance", item2 field2 = "Application W lag", switchid = "Log switch 4, 5", and loginfo = "Collect log data 2, 3, 4".

[0151] For example, Figure 9As shown in the figure, the fault feedback information about a poor 5G network connection is used as an example. The corresponding first-level fault type is a communication fault, and the second-level fault type is an intermittent 5G network connection. 5G network connection abnormality faults 10, 11, and 12 are registered, and log collection for these abnormal faults is enabled to capture logs for the intermittent 5G network connection. Enabling log collection and collecting log data can be achieved as follows: item field1 = "communication", item2 field2 = "5G disconnection", switch id = "log switch 10, 11, 12", and loginfo = "collect log data 7, 8, 9".

[0152] For example, Figure 9 As shown in the figure, the fault feedback information about poor voice calls is used as an example. The corresponding first-level fault type is a communication fault, and the second-level fault type is unclear voice calls. Register the unclear voice call fault identification function 7 and 8, enable the log collection function for fault identification 7 and 8, and capture call logs. Enabling the log collection function and collecting log data can be achieved as follows: item field1 = "communication", item2 field2 = "unclear voice calls", switch id = "log switch 7, 8", and loginfo = "collect log data 7, 9, 10".

[0153] In the related art, for the feedback on the problem of video freeze when watching online video in application D, such as Figure 2 As shown in Figure D, select the performance category, enable the performance category log collection function, and collect performance category log data. Figure 9 It can be seen that the scenario corresponding to the performance failure can be the problem of online video lag in application D, the problem of lag in application W, or other problems such as lag in games and slow startup. In the related art, the performance log collection function is enabled to collect logs of all performance categories, resulting in low accuracy of log data. Moreover, under normal circumstances, not too much log data is stored. Assuming that only 5 log data are saved, the first one is the lag log under application W, which is the log that needs to be uploaded. After the sixth log data arrives, the first one is deleted. The related art relies on user operation. If the user operation is not timely, the captured log data will not be the desired first log data, which reduces the validity of the log data.

[0154] In view of the above technical problems, this solution is based on precise problem scenarios and enables automatic problem scenario detection on demand to detect abnormal scenarios where the first fault occurs, thereby improving the accuracy of log data. Through the dynamic configuration of information such as the first-level and second-level fault classifications, as well as the log collection function, it is possible to update relevant information on demand, solve the problems of excessive load and too many logs, and collect information on demand to reduce the system load. If a fault is detected (i.e., the first fault occurs), log dumping and packaging are automatically triggered (i.e., log data is automatically collected and packaged). For example, in the case where too much log data will not be stored, this solution will package the first log data in advance to prevent it from being overwritten, solving the problem of log timeliness caused by slow manual operation of users and improving the validity of log data.

[0155] In some embodiments, after determining at least one abnormal scenario based on the secondary fault type corresponding to the occurrence scenario of the first fault, the log collection method also includes the following steps: displaying a second interface; the second interface includes a first function control, and the first function control is used to enable the log collection function of the target abnormal scenario; the target abnormal scenario is any abnormal scenario among at least one abnormal scenario; in response to the user operation of the first function control, the log collection function of the target abnormal scenario is enabled.

[0156] In the embodiment of the present application, after determining at least one abnormal scenario, the terminal device may further display a second interface, such as Figure 10 As shown, Figure 10 This is a user interface diagram of a log collection function provided by an embodiment of the present application. After multiple rounds of dialogue, the intelligent detection application starts the log collection function of each abnormal scenario based on the fault feedback information. Figure 10 The following takes enabling A log, B log, and C log as examples for explanation. Figure 10 The second interface shown displays a prompt: "Thank you for your reply. We have analyzed the abnormal scenarios that need to be detected. Now we need to enable the relevant log collection function. Please click Enable in sequence to collect log data. Alternatively, you can also click Exit to exit this problem feedback" to guide the user to enable the log collection function. Figure 10The second interface shown also includes a first function control, which is a switch for turning on log A, a switch for turning on log B, or a switch for turning on log C. The user can click or touch the switch of log A to turn on the log collection function of log A; the user can click or touch the switch of log B to turn on the log collection function of log B; and the user can click or touch the switch of log C to turn on the log collection function of log C. In this embodiment of the present application, log data collection of the selected log can be automatically started within a preset time period after the first log is selected (clicked or touched). The timer starts from the selection of the first log, leaving the user sufficient time to make a selection. When the selection time (i.e., the preset time period) expires, it indicates that the user has completed the selection and log data collection begins. Figure 10 The second interface shown may also include a "Start" control (not shown in the figure), and the user can click or touch the "Start" control to start collecting log data of the selected log. Figure 10 The second interface shown also includes an "Exit" control, and the user can exit this problem feedback by clicking or touching the "Exit" control.

[0157] The second interface displayed by the terminal device can also be Figure 11 As shown, Figure 11 This is another user interface diagram for enabling the log collection function provided in an embodiment of the present application. Figure 11 The following example uses the A log, B log, and C log enabled as examples. Figure 11 The second interface displayed displays a prompt: "Thank you for your reply. We have analyzed the abnormal scenarios that need to be detected. We now need to enable the relevant log collection function. Please confirm whether you agree to enable it. If you disagree, you can click Exit to exit this problem feedback" to guide the user to agree to enable the log collection function. Figure 11 The second interface also includes an "Agree" control. The user can click or touch the "Agree" control to turn on the switch for log A, the switch for log B, and the switch for log C. Of course, if the user wants to turn off the switch for certain logs, they can click or touch the switch for the log to turn off the collection function for the log, and then click or touch the "Agree" control. Figure 11 The second interface shown also includes an "Exit" control, and the user can exit this problem feedback by clicking or touching the "Exit" control.

[0158] It should be noted that the above is based on Figure 10 and Figure 11 The user interface shown in the example is used as an example for illustrative description. The interface for opening the log collection function in the embodiment of the present application can be in other forms and is not limited to the above Figure 10 and Figure 11In one achievable manner, after determining at least one abnormal scenario, the log collection function for each abnormal scenario can be automatically triggered to improve collection efficiency.

[0159] In an embodiment of the present application, the terminal device displays a second interface, which also includes a first function control for enabling a log collection function. The log collection function to be enabled is displayed in the interface, and with the user's consent, the log collection function is enabled to collect log data, thereby improving the security of the log data and protecting the user's privacy.

[0160] In some embodiments, the terminal device can detect whether the first fault has occurred by detecting a dot event in a preset perception scenario; the preset perception scenario includes a business anomaly scenario and an application-related usage scenario. If a dot event is detected indicating the first fault has occurred, the first fault is indicated, and log data is collected using the log collection function.

[0161] In an embodiment of the present application, the terminal device has pre-set multiple preset perception scenarios, and the preset perception scenarios include business exception scenarios (i.e., fault scenarios), and application-related usage scenarios (for example, application opening and closing, etc.). The terminal device can insert a pre-embedded program for the branch where the preset perception scenario may appear based on its own business logic, and the dotting interface of the terminal device pre-applies for permission to obtain dotting events from the pre-embedded program. After the pre-embedded program captures the preset perception scenario, the dotting interface is called, and the dotting event captured by the pre-embedded program is obtained through the dotting interface. The dotting event includes the identifier of the preset perception scenario, and whether the first fault occurs can be determined based on the identifier of the preset perception scenario. If the first fault occurs, log data is collected through the log collection function.

[0162] It should be noted that "point tracking", also known as tracking, is a term in the field of data collection, which can be fault data or user behavior data collection. It refers to the relevant technologies and implementation processes for capturing, processing and sending specific events.

[0163] Based on the perception of business anomalies (i.e., fault scenarios), it can be applied to non-specific application scenarios, such as slow data Internet speeds and Bluetooth failures to connect to a computer. When a fault scenario occurs, the fault management interface is called to perform fault management. The intelligent detection application can detect the fault scenario and automatically trigger the collection of log data after the fault management is triggered.

[0164] Based on the perception of application-related usage scenarios, it is suitable for identifying specific application scenarios, such as video freezes, game lags and frame drops, overheating, and device failure after the application exits to the background. Scenarios such as application freezes, frame drops, and exiting to the next day can be identified as application switching scenarios. When an application switches, the event tracking interface is called to perform event tracking. The backend can detect the application switching scenario and automatically trigger log data collection after the event tracking is triggered.

[0165] In an embodiment of the present application, the terminal device detects dotting events of a preset perception scenario. When a dotting event is detected indicating the occurrence of a first fault, the first fault is indicated, and the collection of log data is automatically triggered and stored (i.e., packaged). The timing of collecting log data is not dependent on user operations, thereby improving the timeliness of the log data.

[0166] S22. The terminal device sends the log data to the server.

[0167] The logging engine of the terminal device sends the log data to the server.

[0168] In some embodiments, after the terminal device collects log data through the log collection function, the log collection method may include the following steps: the terminal device displays a third interface; the third interface includes a second function control, and the second function control is used to send log data; in response to the user operation of the second function control, the log data is sent to the server.

[0169] In the embodiment of the present application, after the log engine collects the log data, the intelligent detection application can display a third interface, which includes a second function control. The terminal device detects the user operation acting on the second function control and sends the log data to the server. Figure 12 As shown, Figure 12 This is a user interface diagram for submitting log data provided by an embodiment of the present application. After the log data is collected, the log data is stored (ie, packaged) and the user is informed. Figure 12 The third interface shown displays a prompt: "The device has packaged the log data for this problem feedback. You can exit this problem feedback by clicking Exit; or, click View and submit after viewing; or, click Submit to submit the packaged log data" to guide the user to send the log data. Figure 12 The third interface shown includes a second functional control, ie, a “Submit” control; the user can send the log data to the server by clicking or touching the “Submit” control. Figure 12 The second interface shown also includes an "Exit" control, and the user can exit this problem feedback by clicking or touching the "Exit" control. Figure 12The second interface shown also includes a "View" control, and the user can click or touch the "View" control to view the detailed content of the log data. Figure 4 The description in , will not be repeated here.

[0170] In this example, the terminal device can also provide the user with a confirmation entry (i.e., the second function control in the third interface) to confirm whether to upload log data to the server. The user can upload log data to the server through the above confirmation entry, thereby improving the security of log data and protecting user privacy.

[0171] In some embodiments, after the terminal device turns on the log collection function according to the fault feedback information sent by the server, the log collection method also includes: turning off the log collection function after a preset time period after the log collection function is turned on; or, displaying a fourth interface; the fourth interface includes a third function control, and the third function control is used to turn off the log collection function; in response to the user operation of the third function control, turning off the log collection function.

[0172] In an embodiment of the present application, after the log collection function is turned on, in one implementation, an abnormal scenario is reproduced, and after the terminal device sends log data, a fourth interface is displayed, and the fourth interface includes a third function control. The terminal device detects a user operation acting on the third function control and turns off the log collection function. Figure 13 As shown, Figure 13 This is a user interface diagram of a log collection function exit provided by an embodiment of the present application. After sending the log data, the user is informed that Figure 13 The fourth interface shown displays a prompt: "You have completed this problem feedback. You can click Exit to exit this problem feedback and turn off the log collection function" to guide the user to turn off the log collection function. Figure 13 The fourth interface shown includes a third function control, namely, an "Exit" control; the user can close the log collection function and exit this problem feedback by clicking or touching the "Exit" control.

[0173] In another implementation, the terminal device may further set a duration for the log collection function (i.e., a preset time period). After the duration of the log collection function expires, the terminal device may also automatically disable the log collection function. In other words, the expiration of the duration of the log collection function triggers the shutdown of the log collection function, and the terminal device may terminate the fault feedback.

[0174] In another implementation, the terminal device can set a duration for the log collection function (i.e., a preset time period). Before the end of the duration of the log collection function, if the terminal device has already sent log data, a fourth interface can also be displayed, the fourth interface including a third function control. The terminal device detects a user operation acting on the third function control and turns off the log collection function. If the terminal device has not sent log data after the end of the duration of the log collection function, the log collection function is automatically turned off.

[0175] It should be noted that the above Figure 7 as well as Figure 10-13 , is only a schematic diagram of the user interface. The embodiment of the present application does not limit the specific display method and display content of the user interface. As long as the technical solution of log data collection is realized through multiple rounds of dialogue and the log collection function is turned on, it is within the protection scope of the embodiment of the present application.

[0176] In the embodiment of the present application, whether the user turns off the log collection function or the terminal device automatically turns off the log collection function, it is possible to avoid long-term log collection, save resources, and protect user privacy.

[0177] Based on the above Figure 5-Figure 13 ,like Figure 14 As shown, Figure 14 It is a structural diagram of a log collection system provided by an embodiment of the present application. The end-side terminal device may include an intelligent detection application, a log engine, and a business module. The intelligent detection application is an executable application. The intelligent detection application may include modules such as self-feedback interface operation, feedback process control, privacy control, and solution management. The self-feedback interface operation module can be used to detect user operations and receive user input information. The feedback process control module can be used to manage the autonomous feedback process. The feedback process control module can determine the feedback process and then determine the next operation based on the user operations detected by the self-feedback interface operation module and / or the user input information received. The self-feedback interface operation module can update the user interface according to the next operation determined by the feedback process control module, and then obtain new user operations and / or new user input information. The solution management module can be used to receive and store fault feedback information sent by the robot engine. The self-feedback interface operation module can update the user interface according to the fault feedback information stored in the solution management module, as mentioned above Figure 10 or Figure 11At the same time, the solution management module can control the execution log collection process according to the user's operation in the updated user interface. The privacy control module can be used to confirm the permissions required for each intelligent detection operation and record the permissions that the intelligent detection application has obtained. Among them, when it is necessary to obtain authorization from the user, the self-feedback interface operation module can obtain relevant permission information from the privacy control module. The privacy control module can detect the user operation based on the self-feedback interface operation module and determine whether the user authorizes the relevant permissions, as mentioned above Figure 10 or Figure 11 , and the above Figure 12 .

[0178] The log engine may include a log switch module, a log collection module, and a log upload module. The log switch module may be used to control the on / off of the log collection function. The log switch module may determine the on / off of the log collection function based on the on / off instructions sent by the intelligent detection application. Figure 10 or Figure 11 After detecting a user operation on the first functional control, the intelligent detection application can send an activation instruction to the log switch module, thereby controlling the log switch module to activate the log collection function. When the log switch module instructs the log collection function to be activated, the log collection module can collect log data from the relevant software and hardware modules and transfer (i.e., package) the log data. After the collection is completed, the log upload module can package the collected log data and send it to the cloud-side log server.

[0179] Level 1 fault types include but are not limited to the following categories: reliability faults, performance faults, power consumption faults, communication faults, application faults, device faults, etc. The business module can set corresponding sub-business modules for each level 1 fault type to manage the log data of each level 1 fault type. Figure 14 The figure shows the sub-service modules corresponding to the first-level fault types, such as reliability, performance, power consumption, communications, applications, and device modules. For reliability faults, the reliability service module manages log data related to reliability faults. Other services have similar corresponding relationships and are not detailed here.

[0180] It should be noted that each first-level fault type can include multiple second-level fault types, and each sub-service module can also be set up with a second-level sub-service module corresponding to each second-level fault type to manage the log data corresponding to each second-level fault type. This will not be repeated here. For example, taking the communication service module as an example, the communication service module also includes sub-modules such as signal problems or weak signals, call failure or dropped calls, voice quality problems or call failures, SMS sending and receiving, inability to access the Internet or slow Internet access. The sub-modules corresponding to each second-level fault type in other first-level fault types also have a similar inclusion relationship, which will not be repeated here one by one.

[0181] The business module can determine the primary and secondary fault types based on user operations reported by the feedback interface operation module, and then determine at least one abnormal scenario based on the secondary fault type. Before enabling the log collection function, the log switch module can obtain the specific abnormal scenario from the business module and enable the corresponding log collection function based on the abnormal scenario. The log collection module then uses the enabled log collection function to collect log data for the abnormal scenario.

[0182] The log server may include a log storage module and a log analysis module. The log storage module is used to receive log data uploaded by the terminal device's log upload module. The log analysis module performs data analysis based on the log data obtained by the log storage module to obtain analysis results, such as the cause of the fault. Furthermore, the log analysis module synchronizes the analysis results with the robot engine, which can preliminarily determine a solution that matches the cause of the fault.

[0183] above Figure 14 In the example, the robot engine may include an intent recognition module, a slot extraction module, an intelligent question-and-answer module, and a task decision module. The robot engine communicates with the intelligent detection application in real time. The slot extraction module is used to perform slot extraction on the user input information received by the self-feedback interface operation module to obtain the slot extraction result. The intelligent question-and-answer module is used to generate question information based on the slot extraction result, and send the question information to the self-feedback interface operation module for interface display. The intent recognition module is used to perform dialogue intent recognition on multiple rounds of dialogue information to obtain dialogue intent. The dialogue intent can be a fault problem or a knowledge query. The task decision module is used to assign tasks based on the dialogue intent. If the dialogue intent is a fault problem, it indicates that log collection is required. The task decision module generates fault feedback information and sends the fault feedback information to the feedback process control module. If the dialogue intent is a knowledge query, knowledge recommendation content is generated and pushed to the self-feedback interface operation module for interface display.

[0184] Based on the above Figure 5-Figure 14 ,like Figure 15 As shown, Figure 15It is a schematic diagram of a log collection process provided by an embodiment of the present application. Take the example of a user inputting a fault description "Application D is stuck" in the intelligent detection application on the end side, and the robot engine on the end side sends the fault description (i.e., user input information) to the cloud side. The cloud side uses artificial intelligence algorithms (AI) to perform natural language (NLP) processing on the user input information, such as word segmentation, classification, keyword matching, etc., to generate questions based on the fault description and realize multiple rounds of dialogue between the robot engine and the user. After multiple rounds of dialogue, the robot engine can generate fault feedback information, for example, as mentioned above Figure 8 The fault feedback information obtained from slot extraction 2 shown in FIG is {fault type: Application D short video - Application D malfunction - Application D freezes; faulty application: Application D; problem summary: Application D live broadcast often freezes}. The fault feedback information is sent to the intelligent detection application.

[0185] Smart detection applications use scenarios with predefined perception scenarios (i.e., preset perception scenarios). These include business anomaly scenarios (i.e., failure scenarios) and application-related usage scenarios (e.g., application startup and shutdown). Perception based on business anomaly scenarios (i.e., failure scenarios) can be applied to non-specific application scenarios, while perception based on application-related usage scenarios is applicable to scenarios that can identify specific application scenarios.

[0186] The intelligent detection application starts the corresponding log collection function according to the fault feedback information. The intelligent detection application detects the marking events of the preset perception scenario, and starts the automatic log collection when the abnormal scenario corresponding to the fault feedback information is detected. For example, after the fault is marked when a problem occurs in the fault scenario, if the scenario corresponding to the fault marking matches the abnormal scenario, the collection of log data will be automatically triggered. After the event is marked during the application use process, if the scenario corresponding to the event marking matches the abnormal scenario, the collection of log data will be automatically triggered. For example, the user enters application D to reproduce the problem. When the marking event of the preset perception scenario detected is the user exiting application D or the occurrence of the marking event of application D freezing, it means that the perception scenario is met, and the intelligent detection application starts log collection. After the log data is collected, the feedback interface of the log data (i.e., the third interface) is displayed, and the user operation on the third interface is detected, indicating that the user submits the problem feedback, and the log data is sent to the log server of the server, that is, the automatically perceived packaged log data is attached.

[0187] In the embodiment of the present application, the end side includes an intelligent detection application, a log engine and a business module. The intelligent detection application is responsible for: implementing the autonomous feedback operation interface, feedback process management, privacy management, and solution management. The log engine is responsible for turning on the corresponding log switch for the fault feedback information sent by the cloud side, collecting logs according to size and privacy requirements, packaging, and uploading log data on demand. Each business module communicates with the log engine to turn on and off the log according to specific conditions, control the generation of log data size and quantity, and clean up log data. The cloud side includes a robot engine and a log server. The robot engine is responsible for: multi-round dialogue session management, reading and generating summaries of the conversation context, slot extraction, interactive round management, reply generation, and task distribution. The log server is used to store and analyze the log data sent by the log engine. The end side and the cloud side jointly implement multi-round dialogues, automatic activation of the log collection function, and collection of log data. The automatic activation of the log collection function and the collection of log data do not depend on user operations, thereby improving the accuracy and timeliness of the log data.

[0188] It should be noted that the above Figure 14 and Figure 15 In this embodiment, the cloud-side robot engine can be integrated with the terminal side. In this way, the terminal-side robot engine and the terminal-side intelligent detection application can implement multiple rounds of dialogue until the robot engine is able to generate fault feedback information based on the multi-round dialogue information. The collected log data can be sent to the cloud-side log server or stored on the terminal device, which is not limited to this embodiment of the application.

[0189] Based on the above Figure 5-Figure 15 Next, we will explain the log collection process on the client side. Figure 16 As shown, Figure 16 This is a flow chart of a log collection method applied to a terminal device provided in an embodiment of the present application.

[0190] S101. Display a first interface; the first interface includes a self-feedback window, which is used to provide an interactive entrance for the user and the server to conduct multiple rounds of dialogue, so that the server generates fault feedback information based on the multi-round dialogue information, and the fault feedback information includes fault information of the first fault.

[0191] The terminal device displays the first interface, as described above Figure 7As shown in Figure B, the first interface includes a self-feedback window. The self-feedback window acts as a bridge, establishing a communication connection between the terminal device and the server's robot engine. Users can use text or voice to describe the fault or problem they encounter in the editing entry of the self-feedback window. The self-feedback window sends the user's description to the robot engine, which then sends the generated question information to the self-feedback window, completing multiple rounds of dialogue until the robot engine is able to generate fault feedback information based on the multi-round dialogue information. The terminal device receives the fault feedback information sent by the server.

[0192] In some embodiments, a multi-round dialogue process between a terminal device and a server can be implemented in the following manner: the terminal device detects first user input information in a self-feedback window and sends the first user input information to the server; the terminal device receives and displays question information sent by the server in the self-feedback window; the question information is generated by the server after slot extraction of the first user input information, and the target slot of the slot extraction includes at least the fault type; the terminal device detects second user input information in the self-feedback window and sends the second user input information to the server until fault feedback information sent by the server is received; the second user input information indicates the user's reply information based on the question information, and the multi-round dialogue information includes at least the first user input information, the second user input information, and the question information.

[0193] S102: Start a log collection function according to the fault feedback information sent by the server; the log collection function is used to detect abnormal scenarios corresponding to the fault information of the first fault.

[0194] The intelligent detection application of the terminal device determines the log collection function that needs to be enabled based on the fault feedback information sent by the server and sends it to the log engine of the terminal device. The log engine of the terminal device automatically enables the corresponding log collection function based on the log collection function that needs to be enabled. For example, when the generated fault feedback information includes fault information of the first fault, it indicates that the abnormal scenario where the first fault occurs needs to be detected, and there is no need to detect other scenarios. By enabling the log collection function in a targeted manner, the resource consumption caused by enabling other log collection functions is reduced.

[0195] S103: When a first fault is detected, log data is collected through a log collection function.

[0196] The terminal device's log engine activates the corresponding log collection function to detect the abnormal scenario corresponding to the first fault. When the first fault is detected, log dumping and packaging are automatically triggered (i.e., log data is automatically collected and packaged).

[0197] S104: Send the log data to the server.

[0198] The logging engine of the terminal device sends the log data to the server.

[0199] The log collection method for terminal devices provided in the embodiments of the present application, the interaction process between the terminal device and the server, the process of turning on and off the log collection function of the terminal device, and the interface interaction between the terminal device and the user can be specifically referred to above. Figure 5-Figure 15 The description will not be repeated here.

[0200] In an embodiment of the present application, the terminal device automatically turns on the log collection function based on the fault feedback information sent by the server. There is no need for the user to select the fault type, and there is no need for the user to manually turn on the log collection function. The log collection function is automatically turned on through multiple rounds of dialogue information, so that when the abnormal scene corresponding to the first fault is detected, the log data of the abnormal scene is collected, thereby improving the accuracy of the log data. When the terminal device detects the occurrence of the first fault, the log data is collected in a timely manner through the log collection function, and the operation of storing (i.e., packaging) the log data is automatically triggered after the collection. The log data is sent to the server immediately or after a period of time. In this solution, since the log data has been stored (i.e., packaged) when the first fault occurs, it does not depend on the user operation. Therefore, even if the user does not upload it to the server in time, it will not affect the timeliness of the log data, thereby improving the timeliness of the log data.

[0201] Based on the above Figure 5-Figure 15 Next, we will explain the log collection process on the cloud side. Figure 17 As shown, Figure 17 This is a flow chart of a log collection method applied to a server provided in an embodiment of the present application.

[0202] S201. Generate fault feedback information based on multi-round dialogue information in a self-feedback window of a terminal device; the self-feedback window is used to provide a user and a server with an interactive entry for multi-round dialogue, and the fault feedback information includes fault information of a first fault of the terminal device.

[0203] The server sequentially receives user input information in the self-feedback window of the terminal device and generates question information to implement multiple rounds of dialogue. Then, when the fault information of the first fault can be determined based on the multiple rounds of dialogue information, the server stops asking questions and generates fault feedback information.

[0204] In some embodiments, the above S201 can also be implemented in the following manner: receiving first user input information in a self-feedback window sent by a terminal device; performing slot extraction on the first user input information to obtain a slot extraction result, wherein the target slot extracted includes at least the fault type; generating question information based on the slot extraction result when the slot extraction result indicates that the slot information of at least part of the target slots has not been extracted, wherein the question information is used to instruct the user to provide slot information of at least part of the slots; sending the question information to the terminal device; continuing to receive second user input information in the self-feedback window sent by the terminal device until the slot information of all the slots in the target slots is extracted based on multiple rounds of dialogue information with the user, and generating fault feedback information based on the multiple rounds of dialogue information; wherein the second user input information indicates the user's reply information based on the question information, and the multiple rounds of dialogue information at least includes the first user input information, the second user input information, and the question information.

[0205] S202: Send fault feedback information to the terminal device.

[0206] The server sends the generated fault feedback information to the terminal device, so that the terminal device starts a log collection function according to the fault feedback information and collects log data through the log collection function when the first fault occurs.

[0207] S203, receiving log data sent by the terminal device; the log data is collected by the terminal device through the log collection function when the first fault occurs after the log collection function is enabled according to the fault feedback information.

[0208] The server receives the log data sent by the terminal device, stores the log data and further analyzes it.

[0209] The log collection method applied to the server provided in the embodiment of the present application, the interaction process between the server and the terminal device, and the process of the server extracting slots, generating question information, and generating fault feedback information can be specifically referred to above. Figure 5-Figure 15 The description will not be repeated here.

[0210] In an embodiment of the present application, the server generates fault feedback information based on multiple rounds of conversation information in the self-feedback window of the terminal device. The fault feedback information can be used to determine the log collection function that needs to be enabled, without the user having to select the fault type. By enabling the log collection function in a targeted manner, the resource consumption caused by enabling other log collection functions is reduced. Moreover, the terminal device automatically enables the log collection function based on the fault feedback information, so that when the abnormal scene corresponding to the first fault is detected, the log data of the abnormal scene is collected, thereby improving the accuracy of the log data.

[0211] It should be noted that the log collection method provided in the embodiments of this application allows you to test or use the device and experience its business processes to obtain the device's log collection process. If the device collects logs through multiple rounds of dialogue, and the device displays a confirmation interface for enabling the log switch, or displays an interface confirming that the log data has been packaged, then the device has adopted the log collection method provided by this solution.

[0212] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (such as a coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that includes one or more available media integrations. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0213] The above are optional embodiments provided for this application and are not intended to limit this application. Any modifications, equivalent replacements, improvements, etc. made within the technical scope disclosed in this application should be included in the scope of protection of this application.

Claims

1. A log collection method, characterized in that: The method is applied to a terminal device, and the method includes: Displaying a first interface; the first interface includes a self-feedback window, the self-feedback window is used to provide an interactive entrance for the user and the server to conduct multiple rounds of dialogue, so that the server generates fault feedback information based on the multiple rounds of dialogue information, and the fault feedback information includes fault information of the first fault; Enable a log collection function according to the fault feedback information sent by the server; the log collection function is used to detect an abnormal scenario corresponding to the fault information of the first fault; When the first fault is detected, collecting log data through the log collection function; The log data is sent to the server.

2. The method according to claim 1, wherein Before enabling the log collection function according to the fault feedback information sent by the server, the method further includes: detecting first user input information in the self-feedback window, and sending the first user input information to the server; receiving and displaying in the self-feedback window a question message sent by the server; the question message is generated by the server after performing slot extraction on the first user input information, wherein the target slot extracted from the slot extraction includes at least a fault type; Detecting second user input information in the self-feedback window, sending the second user input information to the server until the fault feedback information sent by the server is received; the second user input information indicates the user's reply information based on the question information, and the multi-round dialogue information includes at least the first user input information, the second user input information and the question information.

3. The method according to claim 2, wherein The target slot for the slot extraction includes a fault application and a fault type; and the fault feedback information includes fault information of a first fault of the target application.

4. The method according to any one of claims 1 to 3, wherein The enabling of the log collection function according to the fault feedback information sent by the server includes: Determining, based on the fault feedback information sent by the server, a first-level fault type corresponding to the field to which the first fault belongs from a plurality of first-level fault types, each first-level fault type including a plurality of second-level fault types; determining, according to the fault feedback information, a secondary fault type corresponding to an occurrence scenario of the first fault from a plurality of secondary fault types under the primary fault type to which the first fault belongs; Determining at least one abnormal scenario according to the secondary fault type corresponding to the occurrence scenario of the first fault; the abnormal scenario indicates the scenario that causes the first fault to occur; Enable the log collection function for each abnormal scenario in the at least one abnormal scenario.

5. The method according to claim 4, wherein After determining at least one abnormal scenario based on the secondary fault type corresponding to the occurrence scenario of the first fault, the method further includes: Displaying a second interface; the second interface includes a first function control, the first function control is used to enable the log collection function of the target abnormal scenario; the target abnormal scenario is any abnormal scenario in the at least one abnormal scenario; In response to a user operation on the first function control, a log collection function for the target abnormal scenario is enabled.

6. The method according to any one of claims 1 to 5, wherein: In the case where the first fault is detected, before collecting log data by the log collection function, the method further includes: Detecting the dot events of preset perception scenarios; the preset perception scenarios include business abnormality scenarios and application-related usage scenarios; When the first fault is detected, collecting log data by using the log collection function includes: In a case where it is detected that the dotting event indicates the occurrence of the first fault, the log data is collected by the log collection function.

7. The method according to any one of claims 1 to 6, wherein: After collecting log data through the log collection function, the method further includes: Displaying a third interface; the third interface includes a second function control, and the second function control is used to send the log data; The sending the log data to the server includes: In response to a user operation on the second function control, the log data is sent to the server.

8. The method according to any one of claims 1 to 7, wherein: After enabling the log collection function according to the fault feedback information sent by the server, the method further includes: After a preset period of time after the log collection function is turned on, turning off the log collection function; or, A fourth interface is displayed; the fourth interface includes a third function control, and the third function control is used to turn off the log collection function; in response to a user operation on the third function control, the log collection function is turned off.

9. A log collection method, characterized in that: The method is applied to a server and includes: generating fault feedback information based on multi-round conversation information in a self-feedback window of the terminal device; the self-feedback window is used to provide an interactive entry for the user and the server to conduct multi-round conversations, and the fault feedback information includes fault information of a first fault of the terminal device; Sending the fault feedback information to the terminal device; Receive log data sent by the terminal device; the log data is collected by the terminal device through the log collection function when the first fault occurs after the log collection function is enabled according to the fault feedback information.

10. The method according to claim 9, wherein Generating fault feedback information according to the multi-round dialogue information in the self-feedback window of the terminal device includes: receiving first user input information in the self-feedback window sent by the terminal device; Performing slot extraction on the first user input information to obtain a slot extraction result, wherein the target slot of the slot extraction includes at least a fault type; If the slot extraction result indicates that slot information of at least some of the target slots has not been extracted, generating question information according to the slot extraction result, the question information being used to instruct the user to provide the slot information of at least some of the target slots; Sending the question information to the terminal device; Continue to receive the second user input information in the self-feedback window sent by the terminal device until the slot information of all slots in the target slot is extracted based on the multi-round dialogue information with the user, and generate fault feedback information based on the multi-round dialogue information; wherein, the second user input information indicates the user's reply information based on the question information, the multi-round dialogue information includes at least the first user input information, the second user input information and the question information, and the fault feedback information includes fault information of the first fault.

11. The method according to claim 9 or 10, wherein: Generating fault feedback information according to the multi-round dialogue information in the self-feedback window of the terminal device includes: Performing dialogue intention recognition on the multiple rounds of dialogue information to obtain a dialogue intention, wherein the dialogue intention is a fault problem or a knowledge inquiry; In the case where the dialogue intention is the fault problem, the fault feedback information is generated.

12. A log collection method, characterized in that: The method is applied to a log collection system, which includes a terminal device and a server. The method includes: The terminal device displays a first interface; the first interface includes a self-feedback window, the self-feedback window is used to provide an interactive entry for the user and the server to conduct a multi-round dialogue, so that the server generates fault feedback information based on the multi-round dialogue information, and the fault feedback information includes fault information of the first fault; The server sends the fault feedback information to the terminal device; The terminal device starts a log collection function according to the fault feedback information; the log collection function is used to detect an abnormal scenario corresponding to the first fault; when the first fault is detected, log data is collected through the log collection function; The terminal device sends the log data to the server.

13. The method according to claim 12, wherein: The method further comprises: The terminal device detects first user input information in the self-feedback window, and sends the first user input information to the server; The server performs slot extraction on the first user input information to obtain a slot extraction result, generates question information according to the slot extraction result, and sends the question information to the terminal device; The terminal device displays the question information in the self-feedback window, detects second user input information in the self-feedback window, and sends the second user input information to the server until the server generates the fault feedback information based on the multi-round dialogue information; wherein the second user input information indicates the user's reply information based on the question information, and the multi-round dialogue information includes at least the first user input information, the second user input information and the question information.

14. A terminal device, characterized in that: The terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method according to any one of claims 1 to 8 when executed by the processor.

15. A server, characterized in that: The server includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method according to any one of claims 9 to 11 when executed by the processor.

16. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 1 to 8, or the method according to any one of claims 9 to 11.

17. A computer program product comprising instructions, characterized in that When the method is run on a computer, the computer is enabled to execute the method according to any one of claims 1 to 8, or the method according to any one of claims 9 to 11.

Images