Simulation interface document determination method based on large model

Abstract

The invention discloses a simulation interface document determination method based on a large model, and relates to the technical field of data processing, the method comprises the following steps: when a simulation platform receives a query text input by a user, generating a query request based on the query text, and sending the query request to a preset large model; performing semantic analysis on the query request based on the large model, and generating a keyword retrieval condition and a semantic retrieval condition according to an analysis result; retrieving a preset knowledge base according to the keyword retrieval condition and the semantic retrieval condition to obtain a semantic retrieval result and a keyword retrieval result; and performing weighted calculation on the semantic retrieval result and the keyword retrieval result to obtain a target query result. Precise matching of query results is guaranteed through keyword retrieval, semantic retrieval covers implicit associated information to improve comprehensiveness of the results, missing detection and false detection are avoided through cooperation of keyword retrieval and semantic retrieval, and query response efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method for determining simulation interface documentation based on a large model. Background Technology

[0002] Currently, the simulation platform has a massive amount of documentation resources, covering various types of content such as interface descriptions, feature details, function operation guides, parameter configuration specifications, and troubleshooting manuals. The total amount of documentation is large, the scope is broad, and the presentation format is scattered. When using a specific interface, users need to manually filter keywords from a massive amount of documentation and jump between multiple documents to find related information. This is not only time-consuming and labor-intensive, but also prone to missing key information due to document fragmentation and information redundancy, affecting the efficiency of interface usage.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method for determining simulation interface documents based on large models, aiming to solve the technical problem of how to improve the query efficiency of interface documents in simulation platforms.

[0005] To address the aforementioned issues, this application provides a method for determining simulation interface documentation based on a large model. This method includes: When the simulation platform receives the query text input by the user, it generates a query request based on the query text and sends the query request to the preset large model; Based on the large model, the query request is semantically parsed, and keyword search conditions and semantic search conditions are generated according to the parsing results; The preset knowledge base is searched based on the keyword search conditions and semantic search conditions to obtain semantic search results and keyword search results; The semantic search results and the keyword search results are weighted and calculated to obtain the target query results.

[0006] In one embodiment, the step of performing semantic parsing on the query request based on the large model and generating keyword search conditions and semantic search conditions based on the parsing results includes: Based on the large model, the query request is parsed to obtain the query text, scene tags, module names, and simulation platform version number; Based on the preset simulation domain intent classification table and the large model, the query text is subjected to intent recognition to obtain core intent words; Obtain the module scope terms corresponding to the module name and the simulation platform version number, as well as the scene limiting terms corresponding to the scene tag; The core intent words, the scenario limiting words, and the module scope words are deduplicated to obtain the keyword search conditions; The query text, scene semantics, and module semantics are concatenated to obtain the complete text, which is then used as the semantic retrieval condition.

[0007] In one embodiment, the step of receiving query text input by a user, generating a query request based on the query text, and sending the query request to a preset large model includes: When a text submission event is detected, the query text input by the user and the scene tag are obtained; Obtain the module identifier of the currently running simulation module, and determine the module name corresponding to the module identifier based on a preset module identifier and name mapping table; A query request is generated based on the query text, the scene tag, the module name, and the simulation platform version number, and the query request is sent to the large model.

[0008] In one embodiment, the step of performing intent recognition on the query text based on a preset simulation domain intent classification table and the large model to obtain core intent words includes: Based on the large model, the query text is segmented into words to obtain a word segmentation list; Traverse the core intents in the simulation domain intent classification table, and determine the intersection of the core intents and the keywords in the word segmentation list as the first candidate intent; The large model is used to identify the intent of the input query text to obtain a second candidate intent; The intersection of the first candidate intent and the second candidate intent is determined as the core intent word.

[0009] In one embodiment, the step of obtaining the module scope terms corresponding to the module name and the simulation platform version number, and the scene limiting terms corresponding to the scene tag, includes: Traverse the preset scene tag and keyword mapping library to determine the scene limiting words corresponding to the scene tags; The module name and version number are matched with module-specific terms in the module core terminology library to determine the module scope terms corresponding to the module name.

[0010] In one embodiment, the step of searching a preset knowledge base based on the keyword search conditions and semantic search conditions to obtain semantic search results and keyword search results includes: Based on the inverted index algorithm and the keyword search conditions, the first set of documents matching the keyword search conditions and the first matching score are determined, and the keyword search results are obtained. Obtain the similarity between the semantic vector corresponding to the semantic retrieval condition and the document vector; The similarity is weighted based on the user's historical interaction rate, and the resulting first document set and second matching score are determined as the semantic retrieval result.

[0011] In one embodiment, after the step of weighting the semantic retrieval results and the keyword retrieval results to obtain the target query results, the simulation interface document determination method based on the large model includes: Based on the interface keywords corresponding to the query text, determine the interface identifier corresponding to the interface keywords; Traverse the preset interface dependency relationship library to determine the list of associated interfaces corresponding to the interface identifier and the adaptation version number; Based on the user identifier and the user query context, obtain the preceding query record corresponding to the user identifier; Based on the preceding query records and the associated interface list, the subsequent recommendation interface is determined.

[0012] In one embodiment, the step of determining the subsequent recommendation interface based on the preceding query records and the associated interface list includes: Iterate through the preceding interfaces in the associated interface list and determine whether the preceding interface exists in the preceding query record; If it exists, the preceding interface and the following interface associated with the current query interface in the traversal association interface list will be determined as the following recommendation interface.

[0013] Furthermore, to achieve the above objectives, this application also proposes a device for determining simulation interface documents based on a large model. The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the method for determining simulation interface documents based on a large model as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the simulation interface document determination method based on a large model as described above.

[0015] This application provides a method for determining simulation interface documents based on a large model. After receiving user query text, the simulation platform generates a query request and sends it to a preset large model. The large model performs semantic parsing on the query request and generates keyword search conditions and semantic search conditions. Through deep semantic understanding, it deconstructs the core intent of the query and constructs a dual search dimension of literal features and semantic associations, providing a structured basis for multi-dimensional accurate retrieval. Based on the dual search conditions, it searches a preset knowledge base to achieve multi-path filtering of target information in the knowledge base. Keyword search ensures the accurate matching of query results, while semantic search covers implicit related information to improve the comprehensiveness of results. The two work together to avoid missed detections and false detections. The target query result is obtained by weighting the two types of search results. Through dynamic weight allocation, the accuracy and comprehensiveness are balanced, and the scattered search results are integrated into a structured and prioritized final output, improving the efficiency of query response. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a first flowchart illustrating the method for determining simulation interface documentation based on a large model in this application. Figure 2 This is a second flowchart illustrating the method for determining simulation interface documentation based on a large model in this application. Figure 3 This is a third flowchart illustrating the method for determining simulation interface documentation based on a large model in this application. Figure 4 This is a schematic diagram of the hardware operating environment involved in the method for determining simulation interface documentation based on a large model in this application embodiment.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] To achieve the above objectives, this application proposes a method for determining simulation interface documents based on a large model. The method includes: when the simulation platform receives query text input by a user, generating a query request based on the query text and sending the query request to a preset large model; performing semantic parsing on the query request based on the large model, and generating keyword search conditions and semantic search conditions based on the parsing results; searching a preset knowledge base based on the keyword search conditions and semantic search conditions to obtain semantic search results and keyword search results; and performing a weighted calculation on the semantic search results and the keyword search results to obtain the target query result.

[0023] Currently, the simulation platform has a massive amount of documentation resources, covering various types of content such as interface descriptions, feature details, function operation guides, parameter configuration specifications, and troubleshooting manuals. The total amount of documentation is large, the scope is broad, and the presentation format is scattered. When using a specific interface, users need to manually filter keywords from a massive amount of documentation and jump between multiple documents to find related information. This is not only time-consuming and labor-intensive, but also prone to missing key information due to document fragmentation and information redundancy, affecting the efficiency of interface usage.

[0024] This application provides a method for determining simulation interface documents based on a large model. After receiving user query text, the simulation platform generates a query request and sends it to a preset large model. The large model performs semantic parsing on the query request and generates keyword search conditions and semantic search conditions. Through deep semantic understanding, it deconstructs the core intent of the query and constructs a dual search dimension of literal features and semantic associations, providing a structured basis for multi-dimensional accurate retrieval. Based on the dual search conditions, it searches a preset knowledge base to achieve multi-path filtering of target information in the knowledge base. Keyword search ensures the accurate matching of query results, while semantic search covers implicit related information to improve the comprehensiveness of results. The two work together to avoid missed detections and false detections. The target query result is obtained by weighting the two types of search results. Through dynamic weight allocation, the accuracy and comprehensiveness are balanced, and the scattered search results are integrated into a structured and prioritized final output, improving the efficiency of query response.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with network communication and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or apparatus capable of performing the above functions. The following description uses a simulation interface document determination method device based on a large model as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, embodiments of this application provide a method for determining simulation interface documentation based on a large model, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the method for determining simulation interface documentation based on a large model in this application.

[0027] In this embodiment, the method for determining the simulation interface document based on a large model includes steps S10 to S40: Step S10: When the simulation platform receives the query text input by the user, it generates a query request based on the query text and sends the query request to the preset large model.

[0028] In this embodiment, the simulation platform tool integrates a large AI model, which is connected to a knowledge base. The knowledge base contains information such as simulation usage interfaces, simulation function support documentation, and simulation feature documentation.

[0029] Users input natural language text into the AI ​​query module input box on the simulation platform, manually selecting query scenario tags such as interface calls and parameter configurations. Through the event listening mechanism of front-end components, such as JavaScript's onkeydown event listening for Enter key presses and onclick event listening for query buttons, the system detects the user's input text string and scenario tags in real time. Simultaneously, it automatically reads the unique identifier of the currently logged-in user from the platform session cache, extracts the identifier of the current operation module from the interface routing parameters and maps it to the module name, and reads the fixed platform version number from the front-end configuration file. This information is then associated with the user's input text to form an initial raw data set. A preset text cleaning algorithm is called to remove leading and trailing spaces, tabs, newlines, and other whitespace characters from the user's input text in the raw data set; it iterates through special characters in the text, removing or replacing invalid characters that do not affect the semantics according to a preset special character filter list; and it unifies the text encoding to UTF-8 to avoid character garbled characters, resulting in cleaned, standardized user text. The system determines whether the cleaned user text is empty or contains only spaces. If so, it triggers a front-end prompt "Please enter your query content" and terminates further processing. It then counts the number of characters in the text. If the count exceeds a preset limit (e.g., 500 characters), it triggers a front-end prompt "Query content is too long, please shorten it" and terminates further processing. Finally, it compares the user text with a sensitive word database using a string matching algorithm, such as the KMP algorithm. If any sensitive word is matched, it triggers a front-end prompt "Query content contains illegal information" and terminates further processing. Finally, it uses a keyword matching algorithm to search whether the user text contains at least one core term from the knowledge base's keyword database. If no match is found, it triggers a front-end prompt "Query is irrelevant to simulation knowledge" and terminates further processing, resulting in a validated effective data set.

[0030] The system uses a JSON formatting tool to generate structured JSON request data according to a pre-defined request structure template. This structured request data is then used as the request body and encapsulated into an HTTP request according to HTTPS requirements. Following token generation rules, the user ID, current timestamp, and platform key are encrypted using an algorithm such as HMAC-SHA256 to generate a unique authentication token for inter-service identity verification. This results in a standardized HTTPS request packet containing an encrypted request header and a JSON request body. An HTTPS request is then initiated through the pre-defined AI module interface address. When the request passes through the platform load balancer, the load balancer selects currently available AI large-scale model service nodes based on a pre-defined round-robin strategy. The request is then forwarded to the AI ​​large-scale model service gateway, which extracts the token from the request header, decrypts and verifies it according to authentication rules, and verifies the validity of the user ID and timestamp. If the verification passes, the request is forwarded to the AI ​​large-scale model processing module. If token verification fails or no service node is available, the gateway returns an error response, triggering a message indicating that the service is temporarily unavailable and to retry later.

[0031] In one feasible implementation, step S10 may include steps S11 to S13: Step S11: When a text submission event is detected, obtain the query text and scene tags input by the user.

[0032] In this embodiment, a dual mechanism of real-time input monitoring and submission triggering is used via front-end scripts, such as JavaScript. This mechanism detects the input event of the input box in real time and records every character change entered by the user. The Enter key and the search button are bound as submission trigger conditions. When the user triggers either condition, the complete text string within the input box is retrieved. The current selection state of the scene tag selector is obtained through a DOM element selector. If the user manually selects a tag, the value of the selected tag is read directly; otherwise, the values ​​of all preset scene tags are read by default.

[0033] Step S12: Obtain the module identifier of the currently running simulation module, and determine the module name corresponding to the module identifier based on the preset module identifier and name mapping table.

[0034] In this embodiment, the module identifier parameter is extracted from the current URL using the API of an end-to-end routing framework (such as Vue Router or React Router). For example, when the URL is "http: / / sim-platform / # / device-simulation / query", the path parameter "device-simulation" is extracted as the module identifier. If there is no explicit module identifier in the URL, the module identifier is read from the DOM element attributes of the current page. The mapping relationship in the front-end configuration file is read, for example: {"device-simulation":"device simulation module","data-modeling":"data modeling module","result-analysis":"result analysis module"}). The extracted module identifier is matched with the key value in the mapping table using a string matching algorithm, and the corresponding value is obtained as the module name. If there is no matching item for the module identifier in the mapping table, it is mapped to a general module by default, and the name of the current operation module is obtained.

[0035] Step S13: Generate a query request based on the query text, the scene tag, the module name, the user identifier, and the simulation platform version number, and send the query request to the large model.

[0036] In this implementation, when obtaining a user identifier, the value corresponding to a preset key name is read from local storage. If the key name is not found in local storage or the value is empty, an AJAX request is made to the platform's "session verification interface" to query the user identifier corresponding to the current request from the backend Redis session storage. The user identifier read is checked to see if it conforms to a preset format and is within its validity period. If the identifier format is invalid or expired, a front-end login status verification failure message is triggered, and subsequent data collection is terminated. If the verification is successful, the identifier is retained as the user's unique identifier.

[0037] The `version.json` file is read via an HTTP request, and the value corresponding to the version number field is extracted. The version number is formatted according to preset rules, removing extra spaces, parentheses, and other characters, and the version number format is standardized as "major version number.minor version number.revision number", such as standardizing "V3.2.1 beta" to "3.2.1". If the configuration file fails to be read or the version number format is invalid, the default is to fill in the "unknown version" identifier.

[0038] Following a pre-defined template for the original data set structure, each source data point is mapped to a fixed field. These mapped fields are then combined into a key-value pair set, such as JavaScript objects or JSON strings. Field associations ensure strong binding between user queries, user identity, operational scenarios, and system versions. The query text serves as the foundation for identifying core user needs. Scenario tags further narrow down the scope of needs. Module names clearly define the functional scenario of the user's current operation to accurately pinpoint fragmented information in the knowledge base and match exclusive interface dependency chains. User identifiers are used to associate personal query history, support personalized AI learning and permission verification, and the simulation platform version number adapts to differences in interface documentation across different versions. These five elements work synergistically to enable the AI ​​model to accurately interpret user intent, narrow down knowledge retrieval, and improve the relevance and accuracy of results, while also ensuring query security, version compatibility, and a personalized experience.

[0039] Step S20: Based on the large model, perform semantic parsing on the query request, and generate keyword retrieval conditions and semantic retrieval conditions according to the parsing results.

[0040] In this embodiment, the large model can be a BERT model or a GPT series model. After being fine-tuned with dedicated data such as interface documents, query logs, and terminology databases of the simulation platform scenario, the large model can accurately identify professional terms in the simulation field; grasp the typical intent of the simulation scenario, and improve the accuracy of intent recognition.

[0041] After receiving a query request, the large model performs preprocessing on the query text, including text cleaning, word segmentation, and core word extraction. Based on the simulation domain's intent classification system, the model's finely tuned text classification capabilities determine the core intent and implicit requirements. Constraint information such as module name, version number, and scene tags are parsed from the query request to obtain the parsing results. The parsed core intent words, scene limiting words, module constraint words, and version adaptation words are merged and deduplicated to form a keyword set covering intent, scene, module, and version. The deduplicated keywords are then combined using Boolean logic to generate keyword search conditions.

[0042] The query text, scene tag semantic description, and module scene description are concatenated into a complete semantic text to ensure that the large model captures the comprehensive context. The complete semantic text is then encoded into a basic semantic vector using a fine-tuned BERT or other large models. User preference keywords are encoded into semantic vectors using the same large model. The basic vectors are then weighted according to historical interaction weights, such as query frequency × 0.6 + click frequency × 0.4, and then L-normalized to ensure that the vector magnitude is 1. The semantic vectors are then converted into a format that can be recognized by the vector database to obtain the semantic retrieval conditions.

[0043] Step S30: Search the preset knowledge base according to the keyword search conditions and semantic search conditions to obtain semantic search results and keyword search results.

[0044] In this embodiment, based on keyword retrieval conditions, an inverted index algorithm (such as Elasticsearch) is used to match keywords in documents and calculate keyword matching degree. The inverted index uses keywords as index terms, recording which documents each keyword appears in and its location information. During retrieval, the set of documents containing these words is located by querying the keywords. When the query term exactly matches a word in a document, it is considered a high-confidence match and assigned the highest weight; when the query term is a substring or synonym of a word in a document, it is considered a medium-confidence match and assigned a medium weight; when the query term does not appear in a document, it is considered a no-match and is directly filtered. The weights of all matching keywords in the document are summed to generate a total matching score, reflecting the direct relevance between the document and the query. The documents are sorted in descending order of the total keyword matching score, with a higher score indicating a stronger direct relevance between the document and the query.

[0045] When using semantic retrieval criteria, a large-scale model is used to convert queries and documents into high-dimensional semantic vectors, capturing word meanings, context, and potential associations. Cosine similarity is used to measure the angle between the query vector and the document vector; the closer the value is to 1, the more semantically similar the two vectors are. The similarity score is mapped to a fixed range, such as [0, 1], to avoid conflicts with the scale of keyword scores.

[0046] Based on user historical behavior, preferences are mined, and similar documents are dynamically weighted. The interaction rate of various document types in the user's historical queries is statistically analyzed. When the interaction rate is greater than or equal to a preset interaction rate threshold, the current document belongs to the user's preferred category, and its semantic score is multiplied by a weighting coefficient to improve its ranking priority. Personalized recommendations prioritize displaying content that the user may be interested in. Documents are sorted in descending order of semantic similarity score; a higher score indicates a stronger semantic relevance to the query, resulting in semantic retrieval results.

[0047] Optionally, the weighting coefficient can be linearly adjusted according to the preference intensity, for example: weight=1+k*preference_score, where k is an adjustment parameter, such as 0.2; and preference_score is the preference score.

[0048] Step S40: The semantic search results and the keyword search results are weighted and calculated to obtain the target query results.

[0049] In this embodiment, document identifiers in the semantic search results and keyword search results are compared to remove duplicate documents, and the keyword scores and semantic scores of identical documents are aligned. A score is calculated for each document using the formula: Target Score = Keyword Matching Score × α + Semantic Similarity Score × β, where α is a preset keyword matching score weight and β is a preset semantic similarity score weight. All documents are sorted in descending order of target score, and the top N documents are taken as the target query results.

[0050] Please refer to Figure 2 Users initiate knowledge query requests to the simulation platform, which then calls the large model module. The large model retrieves the necessary documents, interface descriptions, and other information from the knowledge base, processes them, and directly returns the query results to the user. Simultaneously, it completes the information interaction with the knowledge base, realizing a closed-loop process for users to quickly acquire knowledge through the simulation platform.

[0051] In this embodiment, after receiving the user's query text, the simulation platform generates a query request and sends it to a preset large model. The large model performs semantic parsing on the query request and generates keyword search conditions and semantic search conditions. Through deep semantic understanding, it deconstructs the core intent of the query and constructs a dual search dimension of literal features and semantic associations, providing a structured basis for multi-dimensional accurate retrieval. Based on the dual search conditions, it searches a preset knowledge base to achieve multi-path filtering of target information in the knowledge base. Keyword search ensures the accurate matching of query results, while semantic search covers implicit related information to improve the comprehensiveness of results. The two work together to avoid missed detections and false detections. The target query result is obtained by weighting the two types of search results. Through dynamic weight allocation, the accuracy and comprehensiveness are balanced, and the scattered search results are integrated into a structured and prioritized final output, improving the efficiency of query response.

[0052] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 Step S20 may also include steps S21 to S25: Step S21: Based on the large model, parse the query request to obtain the query text, scene tag, module name, and simulation platform version number.

[0053] Step S22: Based on the preset simulation domain intent classification table and the large model, perform intent recognition on the query text to obtain core intent words.

[0054] In this embodiment, the large model structurally decomposes the user-input query text and extracts key fields. The query text is then input into a fine-tuned domain-specific large model, such as fine-tuning BERT / GPT using simulated domain corpora. Combined with a pre-defined intent classification table, core intent words are output through a classifier or generative task. The recognition results are post-processed, including stop word filtering, synonym normalization, and domain terminology enhancement, ultimately generating a deduplicated set of core intent words for subsequent keyword matching.

[0055] Specifically, step S22 may include steps S221 to S224: Step S221: Perform text segmentation on the query text based on the large model to obtain a segmentation list.

[0056] In this embodiment, the large model cleans the query text, removing semantically irrelevant characters and standardizing parameter representations. A combined strategy of jieba segmentation and domain-specific dictionary supplementation is employed. First, the cleaned text is split using jieba segmentation; for example, "How to call the status query interface of the device simulation module, what parameters are needed?" is split into "call, device simulation module, status query, interface, need, which, parameters". Then, a simulation-specific dictionary is loaded to correct segmentation biases, such as preventing "status query interface" from being split into "status, query, interface", ensuring complete terminology splitting. Finally, an LSTM-based part-of-speech classification model labels the segmentation results with part-of-speech tags, filtering out core words strongly related to simulation knowledge queries, retaining nouns and verbs, and removing meaningless function words to obtain a set of core words for the query text.

[0057] Specifically, when using a combination of jieba segmentation and domain-specific dictionary supplementation for text segmentation, the simulation domain-specific dictionary file is read, and the file format is verified to conform to the standard three columns per row for terms, word frequencies, and parts of speech. If format errors are found, a dictionary format exception log is generated. The word frequencies of all terms in the dictionary are uniformly mapped to the range of 100-1000 to avoid priority imbalance caused by excessive differences in word frequencies. The processed domain-specific dictionary is loaded into the segmentation engine using the `load_userdict()` method of jieba segmentation, covering conflicting words in the jieba built-in general dictionary. For example, "status query" is an independent word in the general dictionary, while "status query interface" is a complete term in the domain dictionary. After loading, it is prioritized for segmentation according to domain terms, resulting in a jieba segmentation engine loaded with the domain-specific dictionary.

[0058] The preprocessed query text is converted to UTF-8 encoding to avoid segmentation failure caused by Chinese character encoding issues. The lcut() method of jieba segmentation is called to perform preliminary segmentation of the text. Based on the built-in general dictionary and the loaded domain dictionary, the text is segmented according to the longest matching priority principle. Among all possible segmentation paths, the segmentation method that can match the longest word is selected first to obtain the vocabulary list after preliminary segmentation. The initial word segmentation results are traversed and fully matched with the terms in the domain-specific dictionary to check for any terms that have been split. For example, if the text is "How to obtain the device authentication token of API-SIM-2025-002?", and the initial word segmentation results in ["API", "-", "SIM", "-", "2025", "-", "002", "of", "device", "authentication", "token"], then the dictionary matching finds that "API-SIM-2025-002" and "device authentication token" are complete terms, indicating a splitting bias. For words identified as having splitting bias, a reverse longest match correction is performed. Continuous word fragments are extracted from the splitting results, compared with the terms in the domain dictionary, and the longest matching complete term is found and merged to obtain the final word segmentation list without bias.

[0059] Step S222: Traverse the core intents in the simulation domain intent classification table, and determine the intersection of the core intents and the keywords in the word segmentation list as the first candidate intent.

[0060] Step S223: The large model is used to perform intent recognition on the input query text to obtain a second candidate intent.

[0061] Step S224: The intersection of the first candidate intent and the second candidate intent is determined as the core intent word.

[0062] In this embodiment, the large model determines the user's intent based on a preset simulation domain intent classification using a text classification algorithm. For example, the simulation domain intent classification includes: interface call process query, parameter configuration query, error code troubleshooting, function usage instructions, etc. Each type of intent corresponds to a unique intent code and a core set of trigger words. For instance, the core trigger word set for interface call process query is: call, call steps, how to use, usage process, call method; the core trigger word set for parameter configuration query is: parameter, required, optional, default value, value range, parameter format, etc.

[0063] Iterate through each core intent in the preset simulation domain intent classification table, and perform an intersection operation between the keywords in the word segmentation results and the core trigger word set of the intent. If the intersection is not empty, it is determined to be a candidate intent.

[0064] If the core trigger words of other intents do not overlap with the core query words, they will not be included in the candidates; if the same word matches multiple intents, the intent with the highest matching degree and the most overlapping words will be retained to obtain the candidate intent set.

[0065] The complete query text is converted into a format recognizable by the model. For example, according to BERT model requirements, a [CLS] prefix and a [SEP] suffix are added, and the text is tokenized into a word index, padded to 128 characters. The formatted input text is then fed into a fine-tuned BERT classification model, which outputs the probability distribution of various intents. An intent confidence threshold is set, and intents with probabilities greater than or equal to the threshold are selected to obtain the set of intents determined by the model. The intersection of the candidate intent set and the model-determined intent set is taken as the target intent. If the intersection is empty, the intent with the highest probability determined by the model and greater than or equal to the intent confidence threshold is taken as the target intent. If a candidate intent exists but the model probability is less than the intent confidence threshold, the word segmentation results and model input are re-verified to ensure there are no formatting errors. The target intent set is converted into a standardized format and associated with the corresponding intent description to obtain a structured list of core intents.

[0066] Optionally, the large model combines intent categories with domain common sense to uncover implicit needs that users haven't explicitly stated. For example, when the intent is determined to be an API call process, the implicit needs are default call prerequisites, sample code, and error code solutions; when the intent includes parameter configuration, the implicit needs are default parameter values, value ranges, and required / optional identifiers, forming a complete intent combination of core intents and implicit needs. For each core intent, using the intent code as the key, the intent-implicit need association rule base is queried to extract the associated implicit needs. If multiple core intents are associated with the same implicit needs, they are directly merged into a basic implicit need set.

[0067] The basic set of implicit requirements is matched with rules in the simulation domain's common sense base to supplement missing key requirements. For example, if the interface call process in the common sense base requires association with pre-dependent interfaces, then implicit requirements for pre-dependent interfaces are added. Implicit requirements irrelevant to the current query scenario are removed to ensure that requirements fit the module and version scenario. Requirements are sorted by the strength of association with the core intent, with higher priority given to requirements directly associated with the core intent and lower priority given to requirements supplemented by common sense, resulting in an optimized complete set of requirements. The structured core intent list is then associated with the complete set of implicit requirements to generate the final intent combination data.

[0068] Step S23: Obtain the module scope words corresponding to the module name and the simulation platform version number, as well as the scene limiting words corresponding to the scene tag.

[0069] In this embodiment, the scene tag and keyword mapping library is read, and the scene tag set is traversed one by one to extract the keywords corresponding to each tag. A deduplication operation is performed on the keyword set after mapping multiple tags to form a scene-specific word set. The scene-specific word set is compared with the obtained target intent, and keywords that match the intent are retained to ensure that scene words match user intent. Figure 1 To avoid redundant restrictions.

[0070] The module's core terminology library is read, and the module name is used as the key to obtain the module's exclusive core terminology set. The module's core terms are then matched with the obtained query text core term set, retaining overlapping and strongly related terms, and removing module terms that are irrelevant to the current query, forming a module-scope term set. The module-scope terms are marked as strong qualifiers. When generating keyword search conditions later, all search results must contain at least one module-scope term to ensure that the search does not cross modules.

[0071] Using the module name and platform version number as a joint index, the version interface difference database is queried to obtain the interface-specific terminology set for that version. This version terminology set is then intersected with the obtained module-wide terminology set, retaining all co-existing terms. Newly added key terms for that version are also included. The terminology differences between this version and previous versions are compared to ensure that the version-adapted terminology set only includes terms supported by the current version, removing outdated terms to obtain the final version-adapted terminology set. Adapted terms are filtered based on the platform version number to ensure that the search results are consistent with the user's current system version, avoiding invalid information due to version incompatibility.

[0072] Step S24: Deduplicate the core intent words, the scene limiting words, and the module scope words to obtain the keyword search conditions.

[0073] In this embodiment, the core word set, scenario-limiting word set, and module-scope word set of the query text are merged and deduplicated to obtain a complete keyword set; keyword search conditions are generated according to preset search condition generation rules.

[0074] Optionally, the search condition generation rules can define module-scope terms and version-adaptation terms as mandatory conditions to ensure that the results belong to the current module and are compatible with the current version. Core keywords of the query text can be defined as mandatory conditions to ensure that the results align with the core intent. Scenario-specific terms can be defined as optional conditions; these supplement the core intent and are not mandatory, but the more matches, the higher the relevance score of the search results. The weight of scenario terms in the overall keyword search score is preset to ensure a positive correlation between the score and scenario fit. Match percentage = number of scenario terms matched in a single result / total number of scenario-specific terms; base score = match percentage × preset weight of scenario terms. Keywords are split according to the source dimension and filled into the logical rules according to the field names required by the search engine to form a complete JSON structure.

[0075] Optionally, the search criteria generation rules can be that all core words of the query text must appear in the search criteria. For example, if a user queries "how to call the user management interface", then "call" and "user management" must be retained. Scenario words and module words are sorted by priority, and a preset number of the most relevant words are selected; if scenario words and module words conflict, module words are retained first.

[0076] Step S25: The query text, scene semantics, and module semantics are concatenated to obtain the complete text, which is then used as the semantic retrieval condition.

[0077] In this embodiment, the query text, scene semantics, and module semantics are concatenated into a complete text to ensure that the comprehensive semantics of user intent, scene constraints, and module scenes can be captured simultaneously during the encoding of the large model, thus avoiding semantic bias caused by a single text.

[0078] Text cleaning is performed on the semantic descriptions of scene labels and module scene descriptions to remove redundant characters and standardize expressions, ensuring clear and unambiguous semantics. The complete semantic text is then concatenated using a fixed format: scene semantic description + module semantic description + colon + cleaned query text. The length of the concatenated text is checked to ensure it does not exceed the maximum input length of the BERT model. If it exceeds the length, it is truncated according to the principle of retaining the query text and scene semantics while simplifying the module semantics to avoid model encoding failure. This yields a complete text integrating multi-dimensional semantics.

[0079] The BERT model's tokenizer is invoked to perform the following operations on the complete semantic text: Add special identifiers: add [CLS] (model classification identifier) ​​at the beginning of the text and [SEP] (sentence separation identifier) ​​at the end; split the text into tokens from the model's vocabulary; convert each token into an integer index corresponding to the vocabulary; adjust the token index sequence length to the model's fixed input length, padding with [PAD] (padding identifier) ​​if insufficient, and truncating if excessive; generate an attention mask with the same length as the token index sequence; feed the formatted input into the fine-tuned BERT model, perform forward propagation, and obtain the hidden layer output corresponding to the [CLS] identifier. This vector integrates the semantic information of the entire text and is the core semantic representation of the text; perform mean subtraction on the [CLS] output vector (subtracting the average of all dimensions of the vector) to reduce the model's encoding bias, obtaining the basic semantic vector; obtain the basic semantic vector and the attention mask.

[0080] For each keyword in the preference keyword weight mapping, a keyword semantic vector is generated. The weights of the preference keywords are then normalized to obtain normalized weights. For each preference keyword, the operation of basic semantic vector + keyword vector × normalized weight × adjustment coefficient is performed, and the influence of all preference keywords is added sequentially. The weighted and adjusted vector is then subjected to L2 normalization to ensure that the vector magnitude is 1, which facilitates subsequent cosine similarity calculation, resulting in a normalized semantic retrieval vector.

[0081] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Furthermore, after step S40, steps S50 to S80 may also be included: Step S50: Based on the interface keywords corresponding to the query text, determine the interface identifier corresponding to the interface keywords.

[0082] Step S60: Traverse the preset interface dependency relationship library to determine the list of associated interfaces corresponding to the interface identifier and the adaptation version number.

[0083] In this embodiment, the basic attributes of each interface document are extracted using the unique identifier of the interface as the key. These basic attributes include: interface name, module, compatible version, and core functions. Based on the business process diagram, the pre-dependent interfaces of each interface are parsed, recording the reasons for the dependency and the core output of the dependent interfaces; the post-recommendation interfaces are parsed, recording the recommended scenarios and parameter associations with the core interfaces; user historical call logs are analyzed to uncover potential dependencies, such as: 80% of users call the login interface before calling the device status query interface, and this is added to the corresponding interface's dependency record after system verification; an index is built by interface identifier-module-version, and all data is organized into a structured dependency relationship library, including: interface identifier, interface name, module, version, pre-dependent list, post-recommendation list, and association constraint rules; the resulting interface dependency relationship library allows for quick location of associated interfaces for any interface through keyword retrieval.

[0084] Extract interface keywords from the query text, such as: device status query interface, version 3.2.1, device simulation module; use interface keywords as search conditions to match associated unique interface identifiers. Use the core interface identifier and the adaptation version number as joint search conditions, call the index of the dependency relationship library to locate the complete dependency record of the interface; extract the list of preceding dependent interfaces and the list of following recommended interfaces from the dependency record; compare with the latest version of the current platform, and remove deprecated or incompatible associated interfaces; sort the preceding interfaces by dependency priority and the following interfaces by scenario matching degree to obtain the list of valid associated interfaces.

[0085] Step S70: Obtain the preceding query record corresponding to the user identifier based on the user identifier and the user query context.

[0086] Step S80: Determine the subsequent recommendation interface based on the preceding query records and the associated interface list.

[0087] A user context storage table is pre-created, with fields defined as: user identifier, query timestamp, query core interface identifier / name, query scenario, list of pushed dependent interfaces, and core output of preceding interfaces. A lightweight Redis database is used for storage, indexed by the user identifier, with a 7-day expiration time to avoid data redundancy. By recording user query history, historical query data of the same user can be linked. Using the user identifier as the search key, preceding query records from the past 7 days are retrieved from the user query context storage. It is determined whether the preceding interface in the associated interface list is in the preceding query records. If so, the simulation business process corresponding to that preceding interface is identified as the target business process. Subsequent interfaces that are simultaneously in the subsequent recommendation list and the target business process are identified as subsequent recommendation interfaces.

[0088] In one feasible implementation, step S80 may include: traversing the preceding interfaces in the associated interface list, determining whether the preceding interface exists in the preceding query record; if it exists, then determining the preceding interface and the following interface associated with the current query interface in the traversed associated interface list as the following recommended interface.

[0089] In this implementation, the user ID is used as the query key to extract all interface IDs that the user has queried in the previous query records. Each preceding interface ID in the associated interface list is traversed to determine whether it exists in the previous query records. If it exists, the corresponding business process ID is marked as a candidate business process ID. If it does not exist, the corresponding business process ID is excluded. If there are multiple candidate business process IDs, they are sorted by historical query timestamp, and the business process ID corresponding to the most recently queried preceding interface is selected as the target business process ID. If none of the preceding interfaces are in the user's previous query records, no matching business process is output, and the subsequent steps are terminated.

[0090] This application provides a device for determining simulation interface documents based on a large model, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute the simulation interface document determination method based on a large model as described in Embodiment 1 above.

[0091] The following is for reference. Figure 4 The diagram illustrates a structural schematic of a device suitable for implementing the large-model-based simulation interface document determination method according to embodiments of this application. The device for the large-model-based simulation interface document determination method in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, personal digital assistants (PDAs), tablet computers (PADs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 4 The simulation interface documentation determination method for large-model-based devices shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0092] like Figure 4As shown, the simulation interface document determination method device based on a large model may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that performs various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the simulation interface document determination method device based on a large model. The processing unit 1001, the read-only memory 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the large-model-based simulation interface documentation determination method device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a large-model-based simulation interface documentation determination method device with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0093] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0094] The simulation interface document determination method and device based on a large model provided in this application, employing the simulation interface document determination method based on a large model in the above embodiments, can solve the technical problem of how to improve the query efficiency of interface documents in a simulation platform. Compared with the prior art, the beneficial effects of the simulation interface document determination method and device based on a large model provided in this application are the same as those of the simulation interface document determination method based on a large model provided in the above embodiments, and other technical features in this simulation interface document determination method and device based on a large model are the same as those disclosed in the previous embodiment, and will not be repeated here.

[0095] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0096] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0097] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the simulation interface document determination method based on a large model in the above embodiments.

[0098] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0099] The aforementioned computer-readable storage medium may be included in the simulation interface document determination method device based on a large model; or it may exist independently and not assembled into the simulation interface document determination method device based on a large model. The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the simulation interface document determination method device based on a large model, the simulation interface document determination method device based on a large model performs the following: when the simulation platform receives query text input by a user, it generates a query request based on the query text and sends the query request to a preset large model; it performs semantic parsing on the query request based on the large model and generates keyword search conditions and semantic search conditions based on the parsing results; it searches a preset knowledge base based on the keyword search conditions and semantic search conditions to obtain semantic search results and keyword search results; and it performs a weighted calculation on the semantic search results and the keyword search results to obtain the target query result.

[0100] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the client computer, partially on the client computer, as a standalone software package, partially on the client computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the client computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0101] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0102] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0103] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described method for determining simulation interface documents based on large models. This addresses the technical problem of improving the efficiency of interface document retrieval in simulation platforms. Compared to existing technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the simulation interface document determination method based on large models provided in the above embodiments, and will not be elaborated upon here.

[0104] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for determining simulation interface documentation based on a large model, characterized in that, The method for determining the simulation interface documentation based on the large model includes: When the simulation platform receives the query text input by the user, it generates a query request based on the query text and sends the query request to the preset large model; Based on the large model, the query request is semantically parsed, and keyword search conditions and semantic search conditions are generated according to the parsing results; The preset knowledge base is searched based on the keyword search conditions and semantic search conditions to obtain semantic search results and keyword search results; The semantic search results and the keyword search results are weighted and calculated to obtain the target query results.

2. The method for determining simulation interface documentation based on a large model as described in claim 1, characterized in that, The steps of performing semantic parsing on the query request based on the large model and generating keyword search conditions and semantic search conditions based on the parsing results include: Based on the large model, the query request is parsed to obtain the query text, scene tags, module names, and simulation platform version number; Based on the preset simulation domain intent classification table and the large model, the query text is subjected to intent recognition to obtain core intent words; Obtain the module scope terms corresponding to the module name and the simulation platform version number, as well as the scene limiting terms corresponding to the scene tag; The core intent words, the scenario limiting words, and the module scope words are deduplicated to obtain the keyword search conditions; The query text, scene semantics, and module semantics are concatenated to obtain the complete text, which is then used as the semantic retrieval condition.

3. The method for determining simulation interface documentation based on a large model as described in claim 2, characterized in that, The step of performing intent recognition on the query text based on the preset simulation domain intent classification table and the large model to obtain core intent words includes: Based on the large model, the query text is segmented into words to obtain a word segmentation list; Traverse the core intents in the simulation domain intent classification table, and determine the intersection of the core intents and the keywords in the word segmentation list as the first candidate intent; The large model is used to identify the intent of the input query text to obtain a second candidate intent; The intersection of the first candidate intent and the second candidate intent is determined as the core intent word.

4. The method for determining simulation interface documentation based on a large model as described in claim 2, characterized in that, The steps of obtaining the module range terms corresponding to the module name and the simulation platform version number, and the scene limiting terms corresponding to the scene tag include: Traverse the preset scene tag and keyword mapping library to determine the scene limiting words corresponding to the scene tags; The module name and version number are matched with module-specific terms in the module core terminology library to determine the module scope terms corresponding to the module name.

5. The method for determining simulation interface documentation based on a large model as described in claim 2, characterized in that, The steps of receiving query text input by the user, generating a query request based on the query text, and sending the query request to a preset large model include: When a text submission event is detected, the query text input by the user and the scene tag are obtained; Obtain the module identifier of the currently running simulation module, and determine the module name corresponding to the module identifier based on a preset module identifier and name mapping table; A query request is generated based on the query text, the scene tag, the module name, and the simulation platform version number, and the query request is sent to the large model.

6. The method for determining simulation interface documentation based on a large model as described in claim 1, characterized in that, The step of searching the preset knowledge base based on the keyword search conditions and semantic search conditions to obtain semantic search results and keyword search results includes: Based on the inverted index algorithm and the keyword search conditions, the first set of documents matching the keyword search conditions and the first matching score are determined, and the keyword search results are obtained. Obtain the similarity between the semantic vector corresponding to the semantic retrieval condition and the document vector; The similarity is weighted based on the user's historical interaction rate, and the resulting first document set and second matching score are determined as the semantic retrieval result.

7. The method for determining simulation interface documentation based on a large model as described in claim 1, characterized in that, After the step of weighting the semantic retrieval results and the keyword retrieval results to obtain the target query results, the method for determining the simulation interface document based on the large model includes: Based on the interface keywords corresponding to the query text, determine the interface identifier corresponding to the interface keywords; Traverse the preset interface dependency relationship library to determine the list of associated interfaces corresponding to the interface identifier and the adaptation version number; Based on the user identifier and the user query context, obtain the preceding query record corresponding to the user identifier; Based on the preceding query records and the associated interface list, the subsequent recommendation interface is determined.

8. The method for determining simulation interface documentation based on a large model as described in claim 7, characterized in that, The step of determining the subsequent recommendation interface based on the preceding query records and the associated interface list includes: Iterate through the preceding interfaces in the associated interface list and determine whether the preceding interface exists in the preceding query record; If it exists, the preceding interface and the following interface associated with the current query interface in the traversal association interface list will be determined as the following recommendation interface.

9. A simulation interface documentation determination device based on a large model, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the method for determining simulation interface documentation based on a large model as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the simulation interface document determination method based on a large model as described in any one of claims 1 to 8.

Images