A user behavior data processing method and device

Abstract

This specification provides a user behavior data processing method and apparatus. The method includes: acquiring first behavior data, wherein the first behavior data corresponds to a first service; processing the first behavior data based on a first mapping relationship corresponding to the first service to obtain field information of the first behavior data corresponding to each specified element, wherein the first mapping relationship is generated by a first large language model based on a second behavior dataset generated in the first service, and the first mapping relationship includes a mapping relationship between multiple specified elements and multiple first fields, wherein the multiple specified elements are event elements predefined for all services to describe user behavior, so as to reduce the cost of user behavior data processing and improve processing efficiency.

Description

Technical Field

[0001] This specification relates to the field of data processing technology, and in particular to a method and apparatus for processing user behavior data. Background Technology

[0002] Currently, various internet platforms have moved from the stage of "data collection" to the stage of "data semantic understanding". User behavior data (embedded data) is the core data source, and its value no longer depends solely on the "quantity", but on the "interpretability" and "consumability" of the data.

[0003] In a multi-business module (or business domain) data tracking (user behavior data collection) system, the data tracking structures of different business modules exhibit inconsistencies in field naming and structure (i.e., different field names and / or field structures between user behavior data collected from different business modules). For example, business module 1 uses "event" to name the event type (also known as action type) field and "timestamp" to name the time field, while business module 2 uses "event_type" to name the event type field and "event_time" to name the time field. This issue causes inconvenience for downstream task models in understanding and consuming user behavior data. For instance, downstream task model engineers need to spend a significant amount of time manually writing field mapping rules for user behavior data from different business modules (e.g., uniformly mapping the naming of event type fields to "event_type" or "event" or other names, and uniformly mapping the naming of time fields to "event_time" or "timestamp" or other names, etc.) to align (or standardize) the user behavior data across multiple business modules, facilitating downstream task models' understanding and consumption of user behavior data.

[0004] However, the manual coding of field mapping rules in the above process leads to high costs and low efficiency in data processing. Therefore, there is an urgent need for an improved user behavior data processing method to handle dynamic field offsets, reduce data processing costs, and improve data processing efficiency. Summary of the Invention

[0005] This specification provides one or more embodiments of a user behavior data processing method and apparatus to reduce data processing costs and improve data processing efficiency.

[0006] According to the first aspect, a user behavior data processing method is provided, comprising: acquiring first behavior data, wherein the first behavior data corresponds to a first business;

[0007] Based on the first mapping relationship corresponding to the first business, the first behavior data is processed to obtain the field information of the first behavior data corresponding to each specified element. The first mapping relationship is generated by the first large language model based on the second behavior dataset generated in the first business. The first mapping relationship includes the mapping relationship between multiple specified elements and multiple first fields. The multiple specified elements are event elements predefined for all businesses to describe user behavior.

[0008] According to a second aspect, a user behavior data processing device is provided, comprising: a first acquisition module configured to acquire first behavior data, wherein the first behavior data corresponds to a first service;

[0009] The first processing module is configured to process the first behavior data based on the first mapping relationship corresponding to the first business, and obtain the field information of the first behavior data corresponding to each specified element. The first mapping relationship is generated by a first large language model based on the second behavior dataset generated in the first business. The first mapping relationship includes the mapping relationship between multiple specified elements and multiple first fields. The multiple specified elements are event elements predefined for all businesses to describe user behavior.

[0010] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0011] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method described in the first aspect.

[0012] According to the method and apparatus provided in the embodiments of this specification, first behavior data is obtained, wherein the first behavior data corresponds to a first service; based on the first mapping relationship corresponding to the first service, the first behavior data is processed to obtain field information of the first behavior data corresponding to each specified element, wherein the first mapping relationship is generated by a first large language model based on the second behavior dataset generated in the first service, and the first mapping relationship includes the mapping relationship between multiple specified elements and multiple first fields, wherein the multiple specified elements are event elements predefined for all services to describe user behavior.

[0013] In the above process, leveraging the semantic understanding and reasoning capabilities of a large language model, a first mapping relationship corresponding to the first business is pre-generated on the second behavior dataset generated by the first business. This first mapping relationship includes the relationships between multiple specified elements and multiple first fields learned from the second behavior dataset. Subsequently, this first mapping relationship is used to process the first behavior data corresponding to the first business, thereby obtaining the field information corresponding to each specified element in the first behavior data. Since these specified elements are predefined event elements used to describe user behavior for all businesses, the above process can effectively align fields between multiple businesses, that is, uniformly map the fields of each business to the corresponding specified elements. These elements together constitute the event structure required to describe user behavior. Accordingly, based on the field information corresponding to each specified element in the first behavior data, the user behavior reflected by the first behavior data can be clearly represented, achieving the unification of cross-business field semantics and the semantics represented by user behavior data. The above process, by constructing the mapping relationship corresponding to the business through a large language model, can achieve flexible construction of field mapping rules, and covers a richer range of field mapping relationships. It can better cope with the occurrence of dynamic field offsets and helps to reduce the processing cost of user behavior data and improve data processing efficiency. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0015] Figure 1 This is a schematic diagram illustrating the implementation framework of one embodiment disclosed in this specification;

[0016] Figure 2 This is a schematic flowchart of a user behavior data processing method provided in an embodiment.

[0017] Figure 3 This is another flowchart illustrating the user behavior data processing method provided in this embodiment;

[0018] Figure 4 This is a schematic block diagram of a user behavior data processing device provided in an embodiment. Detailed Implementation

[0019] In this specification, the Large Language Model (LLM) may also be referred to simply as the Large Model. A Large Language Model is a natural language processing model based on deep learning techniques, typically with billions to hundreds of billions or even more parameters, possessing powerful language understanding and generation capabilities. Large Language Models can employ the Transformer architecture or its variants (such as GPT, BERT, etc.), which utilizes an attention mechanism to globally model sequential data, efficiently handling long-distance dependencies and thus performing exceptionally well in natural language tasks. Large Language Models learn the statistical features and semantic relationships of language through pre-training on large-scale corpora, giving them excellent generalization capabilities. The core capabilities of Large Language Models include, but are not limited to: understanding contextual semantics, generating coherent and grammatically correct text, performing logical reasoning, and handling multi-task scenarios. Its usage typically includes two modes: direct inference and fine-tuning. In direct inference mode, the user guides the Large Language Model to generate specific outputs by designing prompts. Cue words can be task descriptions or instructions in text form, used to stimulate the semantic understanding and generation capabilities of large language models. In fine-tuning mode, large language models are further trained on small-scale datasets in specific domains to optimize their performance on specific tasks. The powerful generalization ability and flexibility of large language models make them an important tool in the field of artificial intelligence, providing efficient and accurate solutions for automated text generation and understanding.

[0020] In some embodiments, large language models can also understand and generate data from other modalities (such as visual and audio data). In this case, large language models can also be called multimodal large language models (MLLMs). MLLMs provide a richer and more natural interactive experience by integrating multiple types of input and output, such as text, images, and sound. The core advantage of MLLMs lies in their ability to process and understand information from different modalities and fuse this information to complete complex tasks. For example, MLLMs can analyze an image and generate descriptive text, or generate a corresponding image based on a text description. This cross-modal understanding and generation capability makes MLLMs widely applicable across multiple fields.

[0021] It should be noted that the key technologies of large language models can be found in the detailed description in the paper "A Survey of Large Language Models" (paper number: arXiv:2303.18223v16, published on March 11, 2025), and will not be repeated here.

[0022] It is understood that before or during the use of the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner in accordance with relevant laws and regulations, and user authorization will be obtained.

[0023] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.

[0024] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0025] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0026] The technical solutions of the embodiments of this specification will now be described in detail with reference to the accompanying drawings.

[0027] The inventors propose a user behavior data processing method to automatically align and standardize user behavior data from multiple services (also known as business platforms or business modules), achieve the unification of field semantics across services and the semantics represented by user behavior data, and reduce the processing cost and improve data processing efficiency. Figure 1 This diagram illustrates an implementation scenario according to an embodiment disclosed in this specification. In this scenario, a user behavior data processing system manages multiple services, and electronic devices can acquire user behavior data generated by the multiple services managed by the system. These different services include those providing users with different functional services, such as, but not limited to, payment services, e-commerce services, live streaming services, and job recommendation services.

[0028] It is understandable that user behavior data from different business units (and even user behavior data from different periods within the same business unit) may have different field names and / or field structures (e.g., the number of fields, field types, and / or nesting structures). To facilitate downstream task models' understanding and consumption of user behavior data, it is necessary to standardize (or align) the user behavior data to unify the semantic representation of user behavior data across business units, thereby facilitating its subsequent use.

[0029] When executing the user behavior data processing flow for the first time, the electronic device can perform the following steps 02-010:

[0030] In step 02, the electronic device can acquire user behavior datasets S generated by multiple different services.

[0031] The user behavior dataset S generated by each different business can include several behavioral data generated by any user interacting with the corresponding business's service interface. For example, if the corresponding business is e-commerce, the behavioral data generated by the user's interaction with the business may include, but is not limited to: behavioral data indicating entry into the e-commerce business, behavioral data indicating browsing, clicking, or placing orders for products recommended by the e-commerce business, behavioral data indicating navigation between interfaces provided by the e-commerce business, and behavioral data indicating product searches on the search interface provided by the e-commerce business, etc. Electronic devices can obtain the above behavioral data through event tracking technology. The above behavioral data is in JSON format.

[0032] For example, a single piece of behavioral data may include multiple fields, such as but not limited to: user identifier field, time field (including fields indicating the time when the user behavior occurred, fields specifying the time when the behavioral data was uploaded, etc.), event type (also known as action type) field, fields indicating the page, business scenario, etc. where the user behavior occurred, fields indicating the object on which the user behavior was acted, channel field (indicating the way to enter the corresponding business), and redundant fields involved in the behavioral data (such as predefined nested fields, debugging fields, corresponding business-specific attribute fields, etc.). These redundant fields are not strongly associated with the user behavior.

[0033] Then, in step 04, the electronic device performs hierarchical sampling from the user behavior dataset S1 generated by the first service for each service (taking any first service as an example) to obtain the sampled behavior dataset C (for example, the subsequent second behavior dataset can also be called the sampled behavior dataset).

[0034] Understandably, user behavior data generated by various business operations is often unevenly distributed. For example, high-frequency events (such as page views and clicks) constitute the majority of the data, while data samples of key long-tail events (such as refunds and complaints) are scarce. To ensure the accuracy of subsequent user behavior data processing, it is necessary to perform stratified sampling of the user behavior data generated by the business operations. This ensures that the sampled behavior dataset contains both sufficient data corresponding to high-frequency events and representative data corresponding to long-tail events. Additionally, it can also cover behavior data with various complex nested structures.

[0035] The aforementioned stratified sampling may include the following steps 041-043:

[0036] In step 041, based on the field information of the specified fields (such as field names and / or field values), several behavioral data in the user behavior dataset S1 corresponding to the first service are statistically analyzed to determine the number of behavioral data corresponding to each field information of each specified field.

[0037] For example, if the specified fields include an event type field, the electronic device can count the number of user behavior data corresponding to each value of the event type field (e.g., actions such as clicks, payments, browsing, refunds, risk control, and complaints). (For example, the number of user behavior data triggering a click, the number of user behavior data triggering a payment, the number of user behavior data triggering a browsing, etc.). Alternatively, if the specified fields include all fields related to user behavior data, the electronic device can count the number of user behavior data corresponding to each different value (or each different field name) of each field.

[0038] It is understood that the above is merely an exemplary explanation of the type of the specified field, which can be any field contained in the user behavior data. This specification does not limit the type of the specified field.

[0039] Then, in step 042, based on the number of user behavior data corresponding to each field information of each specified field, several behavior data in the user behavior dataset S1 are divided into high-frequency behavior data and long-tail behavior data. For example, based on the number of user behavior data corresponding to each field information of each specified field, the field information (e.g., the field value) of each specified field is sorted. Taking descending order as an example, the user behavior data corresponding to the first preset number of field information in the sorted sequence is determined as high-frequency behavior data, and the user behavior data corresponding to the other field information in the sorted sequence is determined as long-tail behavior data.

[0040] Then, in step 043, a first proportion of behavioral data is sampled from the high-frequency behavioral data and added to the sampled behavioral dataset C1; a second proportion of behavioral data is sampled from the long-tail behavioral data and added to the sampled behavioral dataset C1. The proportion of high-frequency behavioral data in the sampled behavioral dataset C1 is greater than the proportion of long-tail behavioral data. The difference between the two proportions can exceed a specified difference (e.g., 60%).

[0041] In some other possible examples, considering the differences in the nested structure between user behavior data, in order to ensure accurate processing of user behavior data, the aforementioned hierarchical sampling may also include step 044: In step 044, from several behavior data in the user behavior dataset S1 corresponding to the first business, several behavior data with a nesting level exceeding a first level threshold and / or a field number exceeding a first number threshold are identified as complex attribute-type behavior data. The first level threshold and the first number threshold can be set according to business requirements.

[0042] Step 044 can be executed before step 041. Accordingly, step 041 can be specifically implemented as follows: based on the field information (e.g., field values) of a specified field, statistical analysis is performed on several behavioral data points in the user behavior dataset S1 corresponding to the first business that are not identified as complex attribute-type behavioral data, to determine the number of user behavior data points corresponding to each field information of each specified field. Furthermore, step 042 is implemented as follows: a third proportion of behavioral data points are sampled from the complex attribute-type behavioral data and included in the sampled behavioral dataset C1. Accordingly, at this time, the sampled behavioral dataset C1 can include high-frequency behavioral data with a first proportion, long-tail behavioral data with a second proportion, and complex attribute-type behavioral data with a third proportion, wherein the first proportion is greater than the second proportion and greater than the third proportion. In some examples, the second proportion may be greater than the third proportion.

[0043] In some possible examples, the aforementioned first, second, and third ratios can be determined based on the number of behavioral data points in the sampled behavior dataset C1 to be obtained. The number of behavioral data points in the sampled behavior dataset C1 can be set based on the number of behavioral data points in the aforementioned acquired user behavior dataset S1 and / or the required parameters.

[0044] The aforementioned stratified sampling operation enables the sampled behavior dataset C1 to cover behavioral data with more diverse semantic patterns, field structures, and field names using a smaller number of behavioral data samples, thus improving the coverage of various types of behavioral data. The sampled behavior dataset C1 contains a reasonable proportion of long-tail behavioral data and complex attribute-type behavioral data, ensuring that the subsequent business-related mapping relationships (or scripts) generated from it are more adaptable to diverse data forms, better able to identify the same semantics behind different field names, and establish the ability to handle missing fields and structural variations. This makes the business-related mapping relationships (or scripts) not only applicable to the "most" conventional scenarios but also robustly cover the "few but critical" complex situations, forming the cornerstone of building a highly generalized and highly available data system.

[0045] In addition, the hierarchical sampling operation enables the sampled behavior dataset C1 to cover the entire scenario with a small number of behavior data samples, which can reduce the inference cost of subsequent large language models to a certain extent. It ensures that the generated business-related mapping relationships (and scripts) are fully exposed to various business scenarios, which can significantly improve the robustness and stability of the business-related mapping relationships (or scripts) in online execution, and provide high-quality behavior data input for downstream task models.

[0046] Subsequently, in step 06, the electronic device uses the first large language model to summarize and extract the mapping relationship between multiple fields and multiple specified elements based on several behavioral data in the sampled behavior dataset C1, and generates the mapping relationship corresponding to the first business. Among them, the multiple specified elements are event elements predefined for all businesses to describe user behavior.

[0047] In some examples, multiple specified elements may include elements required by the event model, such as time elements, scene elements, action elements, and object elements, to characterize user behavior corresponding to user behavior data, such as indicating that a user performed an action on an object (object element) at a certain time (time element) in a certain scene (scene element). Multiple specified elements may also include user identification elements and channel elements, etc.

[0048] The mapping relationship corresponding to the first business function can include: a mapping relationship between multiple specified elements and the field names of multiple fields. The field information can include at least the field name and value. The field information can also include the semantic information represented by the field name and value.

[0049] In some possible examples, the designated storage space corresponding to the electronic device may pre-store a first prompt template, which is used to instruct the first language model to process the input behavioral dataset, identify each field from it, and construct a mapping relationship between the fields and specified features. This includes the specific mapping relationship between field names and specified features and data processing strategies (i.e., field extraction rules). The data processing strategies may include, but are not limited to, at least one of the following: value rules, field semantic merging, candidate field list, conflict resolution strategy, missing completion strategy, and conditional branching logic.

[0050] For example, the first prompt template can be represented as follows:

[0051] "You are a senior user behavior data architect and data governance expert with many years of experience. You are skilled at extracting key fields from messy, multi-source user behavior data (including high-frequency behavior data - simple data, long-tail behavior data - medium data, and complex attribute behavior data - complex data), building standardized event models, and developing detailed data processing strategies."

[0052] Task Description:

[0053] Please analyze the behavior dataset I input and perform the following tasks:

[0054] 1. Field identification: All original fields in the behavior dataset.

[0055] 2. Feature Mapping: Maps fields to specified features, such as time features, event type (or action type) features, scene features, and object features.

[0056] 3. Strategy Formulation: For each specified element, formulate detailed data processing strategies, including value retrieval rules, semantic merging of fields, candidate field list, conflict resolution strategy, missing data completion strategy, and conditional branching logic.

[0057] Input: [Behavior Dataset] (where behavior data is added).

[0058] Please strictly follow the following logic for analysis and output the final result in "JSON format (or other machine-readable intermediate representation format (such as schema or pseudocode configuration))" (the result should be concise, clear, and complete):

[0059] 1. Field identification and preliminary classification;

[0060] List all the original fields found and briefly explain their hypothetical meaning.

[0061] 2. Core Element Mapping Strategy:

[0062] For each specified element (time, action, scene, object), you need to define a strategy object containing the following properties:

[0063] “target_element”: Specifies the name of the element (e.g., Time / Event / Scene / Object).

[0064] "semantic_merge_rules": [Field synonym merging] Lists which original fields are semantically equivalent to the specified feature (e.g., "ts", "event_time", "log_date" are all merged into time features).

[0065] "candidate_fields": [Candidate Field List] Lists the field names that have been merged into the specified feature. The order of the field names can be based on their priority. Higher priority fields are selected first. Priority is determined by the percentage of the occurrences of the corresponding field name in the behavioral dataset relative to the total occurrences of all field names in the candidate field list in the behavioral dataset; a higher percentage indicates higher priority.

[0066] "extraction_rule": [Value rule] Describes the number of times the field names of each candidate field merged into the specified feature appear in the behavior dataset, and / or the ratio of the number of times each candidate field name appears in the behavior dataset to the total number of times all field names in the candidate field list appear in the behavior dataset. It can also describe how values ​​are extracted from the fields (e.g., "direct value extraction", "parsing keys from JSON strings", "converting timestamps to a specified format such as ISO8601", "enumerated value mapping"), etc.

[0067] "conflict_resolution": [Conflict resolution strategy] When multiple fields are merged into a specified feature, the selection is based on the priority of the fields or other selection rules (e.g., prioritizing fields whose values ​​exist).

[0068] "imputation_strategy": [Missing Fill Strategy] When all fields merged into a specified feature are missing, a specified placeholder strategy is used, such as "fallback field method", "default value fill", "context inference", or "mark as unknown". - Specific logic: Describe the fallback chain in detail (e.g., if `page_url` is missing, try to retrieve `referrer`; if still missing, fill in "Unknown_Page").

[0069] "conditional_branches": [Conditional branching strategy] Checks whether the extraction logic of a specified element's field changes under certain conditions. (For example: if "Event_type" is 'purchase', then "object_id" must be extracted from "order_details", otherwise it should be extracted from "item_id"; another example: if the time field is a Unix timestamp, it should follow parsing path A; if it is an ISO8601 string, it should follow parsing path B; if the format is completely messed up, it should follow path C (fill in the default value)).

[0070] Specific sample example: (Add here: multiple sample behavior data generated by the sample business, and the corresponding mapping relationship (e.g., JSON format) obtained based on these multiple sample behavior data. This mapping relationship includes the mapping relationship between each specified element and each field (a list of candidate fields corresponding to each specified element), value selection rules, conflict resolution strategies, missing data completion strategies, and conditional branching strategies.)

[0071] Output requirements:

[0072] "Accuracy": Inferences must be based on the provided behavioral data; do not fabricate fields that do not exist.

[0073] "Output Format": The output must be in a valid JSON format (also indicating an intermediate representation format readable by other machines) to facilitate subsequent parsing by the program.

[0074] It is understood that the above is merely an exemplary illustration of the first prompt template and does not constitute a limitation on the first prompt template. For example, the aforementioned first prompt template may also include content indicating the reasoning and parsing of nested paths of complex nested behavioral data based on complex attribute-type behavioral data, so as to achieve accurate extraction of specified elements in the complex nested behavioral data.

[0075] After the electronic device acquires the sampled behavior dataset C1, it adds several behavior data points to the specified addition positions of the aforementioned first prompt template to obtain the first prompt text. The first prompt text is then input into the first large language model, so that the first large language model processes several behavior data points based on the instructions in the first prompt text. Based on its own knowledge, semantic understanding, and reasoning capabilities, the model summarizes and extracts the mapping relationships between multiple fields and multiple specified elements from the several behavior data points, generating the mapping relationship corresponding to the first business.

[0076] In some possible examples, the mapping relationship corresponding to the first business function may include: a list of candidate fields corresponding to each specified element. This list of candidate fields for a single specified element can represent the mapping relationship between the specified element and the field names of one or more fields. The field names of one or more first fields included in this candidate field list are fields with the same semantic meaning (e.g., all representing event type semantics, all representing time semantics, etc.), achieving semantic merging. As mentioned earlier, the mapping relationship corresponding to the first business function may also include: the value rules for each specified element, missing element completion strategies, conflict resolution strategies, and conditional branching strategies, etc.

[0077] Understandably, missing fields are common in user behavior data generated by business operations. In the aforementioned business-related mapping relationships, the joint candidate field list, conflict resolution strategy, and missing field completion strategy ensure the success rate of extracting key fields (fields corresponding to specified elements), providing a foundation for guaranteeing the integrity of the input (i.e., standardized behavior) to the downstream task model. The aforementioned conditional branching strategy provides a foundation for the accurate parsing and processing of user behavior data involving different event types, channels, and / or business scenarios.

[0078] Similarly, the mapping relationships for each business are obtained through the above method. This process constructs field mapping relationships for user behavior data across different businesses using a large language model, eliminating the need for manually constructing field mapping rules for user behavior data across different businesses. This enables flexible construction of field mapping rules to better handle dynamic field offsets.

[0079] After obtaining the mapping relationship corresponding to each service, in step 08, the mapping relationship corresponding to each service can be stored in the specified storage space.

[0080] Subsequently, in step 010, the electronic device can process the user behavior data in the user behavior dataset S generated by each service (taking any first service as an example) based on the mapping relationship corresponding to each service, thereby achieving standardization of the user behavior data. Specifically, step 010 includes: step 0101, the electronic device can obtain the first behavior data from the user behavior dataset S1 generated by any service (taking the first service as an example) (or other behavior data in the user behavior dataset S1 besides the aforementioned sampled dataset); step 0102, based on the mapping relationship corresponding to the first service, the first behavior data is processed to obtain the field information of the first behavior data corresponding to each specified element. This process is repeated to obtain the field information of each user behavior data corresponding to each specified element, thereby achieving standardization of the user behavior data.

[0081] In some possible examples, after generating the mapping relationships for each business function, it is possible to further generate corresponding executable lightweight scripts based on these mapping relationships. Accordingly, such as... Figure 1 As shown, after step 06 and before step 08, step 07 may also be included. In step 07, the script corresponding to the first service is generated through the second language model using the mapping relationship corresponding to the first service. The script corresponding to the first service includes the mapping relationship corresponding to the first service.

[0082] This second major language model can be the same as or different from the aforementioned first major language model. Both can be major language models with any architecture in related technologies, such as major language models based on the Transformer architecture.

[0083] In some possible examples, the designated storage space corresponding to the electronic device may pre-store a second prompt template, which is used to instruct the second major language model to convert the mapping relationship corresponding to each business into an executable script in a specified language (such as JEXL (Java Expression Language), Python or Pandas).

[0084] For example, the second prompt template can be represented as follows:

[0085] "You are a senior expert proficient in data engineering, ETL (Extract, Transform, Load) architecture, and specific languages ​​(such as JEXL (Java Expression Language), Python, or Pandas). Your core task is to transform the input 'mapping relationships corresponding to various business functions' into a high-performance, zero-error, deterministic executable script in a specified language."

[0086] This executable script will be deployed in a high-concurrency environment to parse user behavior data in real time.

[0087] Input to the executable script: [behavioral data] (inconsistent field names, varying nesting depths, and key fields (such as fields corresponding to specified features) may be missing).

[0088] The executable script outputs: a result object containing field information corresponding to each specified element (standardized event element mapping), and a natural language narrative string obtained based on the field information corresponding to each specified element and a predefined narrative text template.

[0089] Task Description:

[0090] Input content: (The mapping relationship corresponding to the business, i.e., the output of the first major language model mentioned above)

[0091] Based on the mapping relationship corresponding to the input business logic, please generate a complete executable script in a specified language (such as JEXL), including the following parts:

[0092] For each specified element (such as Time, Event, Scene, Object), generate a corresponding assignment expression in a specified language (such as JEXL). The strategy outlined in the business mapping must be strictly followed.

[0093] "Candidate Fields Priority": Implements "cascading check" logic. That is: check field A; if it's not empty, select A; otherwise, check field B; if it's not empty, select B; otherwise, check field C, and so on. Hint: You can use nested ternary operators or custom logic to simulate the `coalesce` function.

[0094] "Conflict Resolution": If a field with a specific priority is specified in the configuration, ensure that the field is at the beginning of the decision chain.

[0095] "Extraction Rules": Time Conversion: If timestamp format conversion is involved, write out the corresponding logical placeholders (e.g., `utils.toIso8601(record.get('ts'))`).

[0096] "Conditional Branches": Implement `if-then-else` logic. For example: "If the source is iOS, then treat 'tap' as 'click'".

[0097] "Imputation / Fallback": If all candidate fields are empty, the **default value** defined in the configuration (such as "unknown" or "unknown") must be returned.

[0098] Output format definition: Structured track: Each specified element (which can be listed) and its corresponding field information (e.g., JSON format); Semantic track: Based on the extracted field information corresponding to each specified element, fill in the following template to generate a natural language sentence: `"User {user} at {time} in {scene} performed the {Event} operation on {object}."`

[0099] Code style: Single or multi-line clear structure: JEXL is usually stored as a single-line expression, but if the logic is complex, use line breaks and comments to make it readable (assuming the runtime environment supports multi-line JEXL).

[0100] Null safety: All field accesses must handle the "null" case to prevent throwing a `NullPointerException`.

[0101] ...

[0102] # Execution Please generate a complete script in the specified language based on the provided "{input content}".

[0103] The above is merely an exemplary illustration of the second prompt template and does not constitute a limitation on the second prompt template.

[0104] After the electronic device obtains the mapping relationship corresponding to each service, it can add the mapping relationship corresponding to each service to the specified position of the second prompt template in sequence to obtain the second text prompt. Then, the second text prompt is input into the second language model so that the second language model processes the second text prompt. Based on the task description instruction of the second text prompt and the mapping relationship corresponding to the service, the corresponding script is generated.

[0105] The following is an example of a JEXL script corresponding to a payment transaction:

[0106] / * JEXL script: Standardization and semantic representation of user behavior logs in payment services * /

[0107] *Scenario: Five key elements are extracted to address the unique characteristics of the payment process (order placement, payment, refund, etc.).

[0108] *Features: Includes strict null safety checks, multi-level priority fallback, business default value filling, and complex conditional branch mapping.

[0109] /

[0110] 1. Basic utility function definitions (simulated runtime environment)

[0111] Safe value retrieval: Prevents exceptions from being thrown when record[key] is null or the key does not exist.

[0112] def getVal(key) {return (record.containsKey(key) && record[key] !=null) ? record[key] : null;}

[0113] / / Default value filling aid: If the value is null, return the default value; otherwise, return the original value.

[0114] def fillDefault(val, defaultVal) { return (val != null) ? val:defaultVal;}

[0115] / / ==========================================

[0116] 2. Core Element Extraction Logic

[0117] / / --- [Time element] ---

[0118] / / Business background: Payment requires high time accuracy.

[0119] / / Strategy: Priority chain (pay_timestamp_ms > order_create_time > server_log_time)

[0120] Var rawTime = getVal('pay_timestamp_ms') != null ? getVal('pay_timestamp_ms') :

[0121] (getVal('order_create_time') != null ? getVal('order_create_time') :

[0122] (getVal('server_log_time') != null ? getVal('server_log_time') :null));

[0123] / / Conditional branching: type conversion and fallback

[0124] / / If it is a number (millisecond stamp) -> convert to ISO8601; If it is a string -> attempt to parse; If it is completely empty -> use the current system time and mark an exception.

[0125] var std_time = (rawTime != null) ? (typeof rawTime == 'number' ?utils.toIso8601(rawTime) : rawTime) : utils.now();

[0126] / / --- [Action Element] ---

[0127] / / Business background: Payment status varies (success, failure, processing, refund).

[0128] / / Strategy: Priority chain (pay_status > action_type > event_name)

[0129] var rawAction = getVal('pay_status') != null ? getVal('pay_status') :

[0130] (getVal('action_type') != null ? getVal('action_type') :

[0131] (getVal('event_name') != null ? getVal('event_name') : null));

[0132] / / Conditional branch: Semantic normalization specific to payment transactions

[0133] / / Rule: Unify 'success', 'paid', and '200' to PAY_SUCCESS;

[0134] 'fail', 'error', and 'cancelled' are all unified as PAY_FAIL

[0135] var lowerAction = (rawAction == null) ? "" :

[0136] rawAction.toString().toLowerCase();

[0137] var std_action = (rawAction == null) ? 'UNKNOWN_STATUS' : (['success', 'paid', 'succeeded', '200'].contains(lowerAction)) ? 'PAY_SUCCESS': (['fail', 'failed', 'error', 'cancelled', 'refunded', '400', '500'].contains(lowerAction)) ? 'PAY_FAIL' : (['processing', 'pending', 'wait_pay'].contains(lowerAction)) ? 'PAY_PENDING' : rawAction.toUpperCase();

[0138] / / --- [Scene Elements] ---

[0139] / / Business background: Differentiate between the cashier, order details page, and H5 redirect page.

[0140] / / Strategy: Priority chain (page_code > page_url > screen_name)

[0141] var rawScene = getVal('page_code') != null ? getVal('page_code') :(getVal('page_url') != null ? getVal('page_url') : (getVal('screen_name') !=null ? getVal('screen_name') : null));

[0142] / / Conditional branch: mapping URL / Code to business scenario

[0143] var std_scene = (rawScene == null) ? 'UNKNOWN_SCENE' : (typeofrawScene == 'string' && (rawScene.contains('cashier') ||

[0144] rawScene.contains('pay_page'))) ? 'Cashier_Counter' : (typeofrawScene == 'string' && (rawScene.contains('order_detail') ||

[0145] rawScene.contains('order_confirm'))) ? 'Order_Detail_Page' : (typeofrawScene == 'string' && rawScene.contains('result')) ? 'Pay_Result_Page' :rawScene;

[0146] / / --- [Object element] ---

[0147] / / Business background: The core object of payment is the order number (OrderID) or transaction number (TransactionID).

[0148] / / Strategy: Priority chain (order_id > transaction_id > bill_no)

[0149] var rawObject = getVal('order_id') != null ? getVal('order_id') :(getVal('transaction_id') != null ? getVal('transaction_id') : (getVal('bill_no') != null ? getVal('bill_no') : null));

[0150] / / Default value filling: Missing objects are a serious problem in payment transactions, marked as a special placeholder. var std_object = fillDefault(rawObject, 'MISSING_ORDER_ID');

[0151] / / --- [Channel Element] ---

[0152] / / Business background: Differentiate between specific payment channels such as Alipay and UnionPay.

[0153] / / Strategy: Priority chain (pay_channel > channel_code > platform)

[0154] var rawChannel = getVal('pay_channel') != null ? getVal('pay_channel') : (getVal('channel_code') != null ? getVal('channel_code') :(getVal('platform') != null ? getVal('platform') : null));

[0155] / / Conditional branch: Standardized mapping of payment channels

[0156] var lowerChan = (rawChannel == null) ? "" :

[0157] rawChannel.toString().toLowerCase();

[0158] var std_channel = (rawChannel == null) ? 'DIRECT_PAY' : (['alipay', 'ali', 'zhifubao'].contains(lowerChan)) ? 'Alipay' : (['wechat', 'wx', 'tenpay'].contains(lowerChan)) ? 'UnionPay' : (['appstore'].contains(lowerChan)) ? contains(lowerChan)) ? 'Bank_Card' : rawChannel;

[0159] / / ==========================================

[0160] / / 3. Construct the output results

[0161] / / ==========================================

[0162] / / A. Structured Track - Used for database storage or downstream computation

[0163] var structuredTrack = { "time": std_time, "action": std_action, "scene": std_scene, "object": std_object, "channel": std_channel, "audit_meta": { "time_source": (getVal('pay_timestamp_ms') != null) ? 'ms_tick' : 'fallback', "action_raw": rawAction, "is_critical_missing": (rawObject ==null) / / Marks whether the critical order number is missing}};

[0164] / / B. Semantic Text Template / / Format: "Perform {action} on {object} at {time} in {scene}, via {channel}"

[0165] / / Purpose: Used for alarm detection, operational report summaries, or large model context input.

[0166] var semanticText = "at " + std_time + " at " + std_scene + " to " + std_object + ", performing " + std_action + ", in " + std_channel;

[0167] / / Place the result into the output context (assuming output is a predefined Map object)

[0168] output.put("structured_track", structuredTrack);

[0169] output.put("semantic_description", semanticText);

[0170] return output;

[0171] The above is merely an illustrative example of the script corresponding to the payment business and does not constitute a limitation on the specific content of the script.

[0172] The above process automatically compiles the mapping relationships corresponding to each business function output by the first large language model into lightweight executable scripts (such as JEXL expressions) through the second large language model. This solidifies the "one-time semantic understanding" of the large language model into a set of "permanent rules" scripts that can be executed frequently and deterministically in the online environment. This preserves the semantic depth of behavioral data while reducing calls to the large language model, ensuring the determinism and stability of the behavioral data processing results.

[0173] This process is repeated to obtain the scripts corresponding to each business function. Accordingly, step 08 includes storing the scripts corresponding to each business function in a designated storage space.

[0174] Understandably, this designated storage space supports versioning, review, gray-scale deployment, and rollback of scripts corresponding to each business, making the online execution of each script controllable and traceable.

[0175] Subsequently, after obtaining the scripts corresponding to each business (or the script corresponding to the first business), step 0102 specifically includes: retrieving the first script corresponding to the first business from the specified storage space; processing the first line of data using the first script to obtain, based on the first mapping relationship, the field information of the first line of data corresponding to each specified element (and narrative text describing the user behavior corresponding to the first line of data in natural language). Figure 1 As shown, the first script is run through the script engine to process the first row of data, thereby obtaining the field information of the first row of data corresponding to each specified element (and the narrative text describing the user behavior corresponding to the first row of data in natural language) based on the first mapping relationship.

[0176] Similarly, based on the above method, by calling the script corresponding to the relevant business, the behavioral data corresponding to the relevant business (i.e., the behavioral data generated in the relevant business) is processed to obtain the field information of each behavioral data corresponding to each specified element (as well as narrative text describing the user behavior corresponding to the behavioral data in natural language). This achieves automatic alignment and standardization of behavioral data.

[0177] In some other possible examples, when the user behavior data processing flow is not executed for the first time, the electronic device can directly obtain the mapping relationship (or script) corresponding to the corresponding business from the specified storage space, and directly process the behavior data corresponding to the corresponding business based on the obtained mapping relationship (or script) corresponding to the corresponding business, so as to obtain the field information and narrative text of the corresponding behavior data corresponding to each specified element.

[0178] Subsequently, the structured output, which corresponds to the field information of each specified element in the aforementioned behavioral data, can be used for feature / vector services, such as training recommendation models based on user behavior and training user intent prediction models based on user behavior. In some possible examples, the structured output of the aforementioned behavioral data can be directly used as the model input, or the structured output of the aforementioned behavioral data can be encoded, and the encoded result can be used as the model input.

[0179] The narrative text of the aforementioned behavioral data can be used to train a large language model for a specified task, which may include, but is not limited to, semantic understanding, retrieval enhancement, and semantic reasoning tasks.

[0180] In the above process, leveraging the semantic understanding and reasoning capabilities of a large language model, a first mapping relationship corresponding to the first business is pre-generated on the second behavior dataset generated by the first business. This first mapping relationship includes the relationships between multiple specified elements and multiple first fields learned from the second behavior dataset. Subsequently, this first mapping relationship is used to process the first behavior data corresponding to the first business, thereby obtaining the field information corresponding to each specified element in the first behavior data. Since these specified elements are predefined event elements used to describe user behavior for all businesses, the above process can effectively align fields between multiple businesses, that is, uniformly map the fields of each business to the corresponding specified elements. These elements together constitute the event structure required to describe user behavior. Accordingly, based on the field information corresponding to each specified element in the first behavior data, the user behavior reflected by the first behavior data can be clearly represented, achieving the unification of cross-business field semantics and the semantics represented by user behavior data. The above process, by constructing the mapping relationship corresponding to the business through a large language model, can achieve flexible construction of field mapping rules, and covers a richer range of field mapping relationships. It can better cope with the occurrence of dynamic field offsets and helps to reduce the processing cost of user behavior data and improve data processing efficiency.

[0181] Furthermore, the above process does not directly process all user behavior data. Instead, it generates scripts containing mapping relationships based on a stratified sampling sample set (i.e., sampled behavior data). This enables a data processing architecture where one inference generates a defined rule (i.e., the script), and the defined rule is executed multiple times. This forms a "stratified sampling + large language model semantic alignment" mechanism, which can cover log structures (user behavior data) with multiple services, versions, and semantic forms with a small number of samples, solving the problem that traditional rule engines cannot handle field drift and naming inconsistencies. Subsequently, the scripts corresponding to each service are used to process each user behavior data separately. These scripts clearly define specific execution logic, improving the accuracy of user behavior data processing results and further enhancing data processing efficiency while reducing the inference cost of the large language model.

[0182] The user behavior data processing method provided in this specification will be described in detail below with reference to specific embodiments.

[0183] Figure 2 A flowchart illustrating a reinforcement learning training method for a large language model according to one embodiment of this specification is shown. This method is executed via an electronic device, which can be any device, equipment, platform, device cluster, etc., with computing and processing capabilities. In the process of user behavior data processing, such as... Figure 2 As shown, the method includes the following steps S210-S220:

[0184] In step S210, the first line of data is obtained, wherein the first line of data corresponds to the first service.

[0185] In some possible examples, the first row of data is in JSON format.

[0186] In some possible examples, the first behavioral data may be user behavior data generated by an electronic device for a first service within a certain period. For example, the first behavioral data may include multiple fields, which may include, but are not limited to: fields indicating event type (i.e., action type), fields indicating time, fields indicating user identification, fields indicating scenario, and fields indicating the target of the user behavior, etc.

[0187] It is understood that the above are merely exemplary examples of the fields contained in behavioral data and do not constitute a limitation on the specific types (or dimensions) of the fields contained in behavioral data. Behavioral data may also include other types of fields, such as fields indicating channels, fields indicating the attribute information of the object targeted by the action, fields indicating whether the event type was successful, and other types of fields that are strongly related to the event type (such as nested structure fields set for a specified event type).

[0188] A channel can refer to the way a user enters the service interface of a corresponding business. For example, a user enters the service interface of a corresponding business through a shared link of a specified associated communication application. Correspondingly, the value of the field indicating the channel in the behavioral data generated by the user during the interaction with the corresponding business is: the shared link of the specified associated communication application. Another example is that a user enters the service interface of a corresponding business through the homepage entry provided by the corresponding host application (i.e., the host application on which the program of the corresponding business depends) (or the entry point of the search results page provided by the corresponding host application). Correspondingly, the value of the field indicating the channel in the behavioral data generated by the user during the interaction with the corresponding business is: the homepage entry point of the host application (or the entry point of the search results page provided by the corresponding host application), and so on.

[0189] After obtaining the first behavior data, in step S220, based on the first mapping relationship corresponding to the first business, the first behavior data is processed to obtain the field information of the first behavior data corresponding to each specified element. The first mapping relationship is generated by the first large language model based on the second behavior dataset generated in the first business. The first mapping relationship includes the mapping relationship between multiple specified elements and multiple first fields. The multiple specified elements are event elements predefined for all businesses to describe user behavior.

[0190] In some possible examples, the second behavior dataset belongs to the field behavior dataset collected from the first business during the first cycle. The second behavior dataset includes high-frequency behavior data with a first proportion, long-tail behavior data with a second proportion, and complex attribute behavior data with a third proportion, wherein the first proportion is greater than the second proportion and greater than the third proportion, and the complex attribute behavior data is field behavior data with a nesting level exceeding a first level threshold and / or a field number exceeding a first number threshold. The sampling process for the second behavior dataset can be referred to the sampling process for the aforementioned sampling behavior dataset, and will not be repeated here.

[0191] In some possible examples, these multiple specified elements include: time element, scene element, action element, and object element. In still other possible examples, these multiple specified elements may also include channel element, user identifier element, etc.

[0192] For example, the time element may correspond to, but is not limited to, fields in behavioral data that indicate time, such as, but not limited to, fields in behavioral data that indicate the time when a user's behavior (action) occurs, fields that indicate the time when behavioral data is reported, etc.

[0193] Scenario elements may correspond to, but are not limited to: fields in behavioral data that indicate the page ID (or page name) where the user behavior occurs, fields that indicate the URL (Uniform Resource Locator) of the page where the user behavior occurs, and fields that indicate the business scenario in which the user behavior occurs (such as specific business context, functional module, or operational activity).

[0194] Action elements (also known as event type elements) can correspond to, but are not limited to, fields in behavioral data that indicate the event type. The values ​​of these event type fields can include, but are not limited to, actions (user behaviors) such as clicking, submitting, paying, and adding to favorites.

[0195] The object element can correspond to, but is not limited to, the field in the behavioral data that indicates the object (i.e. the object on which the user's behavior is applied). The value of the field of the indicating object can include, but is not limited to, the applied object such as product, order, activity, content, and functional module.

[0196] The first mapping relationship may include mapping relationships between multiple specified features and field names of multiple first fields. The field information of the first field may include at least the field name and value of the first field. The field information of the first field may also include semantic information represented by the field name and value of the first field.

[0197] In some possible examples, the first mapping relationship may include: a list of candidate fields corresponding to each specified feature. This list of candidate fields for a single specified feature represents the mapping relationship between that specified feature and the field names of one or more first fields. The field names of one or more first fields included in this candidate field list are semantically related, achieving semantic merging. This first mapping relationship may also include: field extraction rules such as value selection rules for each specified feature, missing data completion strategies, conflict resolution strategies, and conditional branching strategies. These are all inferred and summarized by the first language model based on the behavioral data in the second behavioral dataset.

[0198] Accordingly, in step S220, the electronic device processes the first row of data based on the first mapping relationship corresponding to the first service. For each specified element, based on the field extraction rules corresponding to the specified element defined by the first mapping relationship, the field information of the corresponding first field is extracted from the first row of data, thereby obtaining the field information of the first row of data corresponding to each specified element. That is, the structured field information of the first row of data corresponding to each specified element is obtained, for example, represented as: time element: xx time; action element: xx action; scenario element: xx page or business scenario (e.g., product order scenario); object element: xx object (e.g., xx product).

[0199] In some possible examples, the aforementioned multiple specified elements include a first specified element, and the first mapping relationship indicates that the first specified element corresponds to multiple first fields (i.e., its corresponding candidate field list includes multiple first fields), and different first fields have different priorities;

[0200] Step S220 may include the following step 11: In step 11, based on the priority of each of the multiple first fields corresponding to the first specified feature, the following steps 111-112 are executed in descending order of priority:

[0201] In step 111, if a first field with the current priority is detected in the first row of data, the field information of the first field with the current priority is extracted to obtain the field information corresponding to the first specified feature.

[0202] The priorities of the multiple first fields corresponding to the first specified element are derived by the first large language model based on the second row dataset. The larger the proportion of the first field corresponding to the first specified element in the second row dataset, the higher its priority; that is, the field information of that first field is retrieved more preferentially. For example, the first fields corresponding to the first specified element in the second row dataset include fields A, B, and C. Field A appears more frequently than field B in the second row dataset, and field B appears more frequently than field C. In other words, the proportion of field A corresponding to the first specified element in the second row dataset is greater than the proportion of field B corresponding to the first specified element, and the proportion of field B corresponding to the first specified element is greater than the proportion of field C corresponding to the first specified element. Accordingly, field A has a higher priority than field B, and field B has a higher priority than field C.

[0203] In step 111, the electronic device first sets the highest priority as the current priority (as mentioned above, field A), and checks whether the first row of data contains the first field of the current priority. If the first row of data contains the first field of the current priority (including the field name and the corresponding value), the field information of the first field of the current priority is extracted to obtain the field information corresponding to the first specified element. If the first row of data does not contain the first field of the current priority (i.e., the first field of the current priority is missing, or the value of the first field of the current priority is missing), the subsequent step 112 is executed.

[0204] Accordingly, in step 112, if it is detected that the first field of the current priority does not exist in the first row of data, then it is checked whether the first row of data has a first field of the next priority of the current priority. If a first field of the next priority exists, the field information of the first field of the current priority is extracted to obtain the field information corresponding to the first specified element. In this step, if it is detected that the first field of the current priority does not exist in the first row of data, then it is checked whether the first row of data has a first field of the next priority of the current priority (such as field B mentioned above). If a first field of the next priority exists, the field information of the first field of the current priority is extracted to obtain the field information corresponding to the first specified element; if the first field of the next priority does not exist (i.e., the first field of the next priority is missing, or the value of the first field of the next priority is missing), then it is checked whether the first row of data has a first field of the next priority of the next priority (such as field C mentioned above). This process continues until the field information corresponding to the first specified element is obtained, or until it is detected that all first fields corresponding to the first specified element are missing, at which point the detection stops.

[0205] In the example above, by setting priorities, conflicts in field extraction corresponding to specified elements during behavioral data processing can be avoided to some extent, ensuring the smooth execution of the processing flow and the accurate acquisition of behavioral data processing results.

[0206] In some possible examples, the aforementioned first mapping relationship also includes a missing completion strategy (i.e., for specified elements with missing fields, a specified placeholder strategy is used to place them), to ensure the formal integrity of the processed, standardized behavioral data, providing a basis for the accurate use of downstream task models and preventing errors and crashes when downstream task models use the processed, standardized behavioral data. Accordingly, step S220 may include the following step 21:

[0207] For any second specified element among multiple specified elements, if it is determined that all first fields corresponding to the second specified element in the first row of data are missing, then placeholders are placed based on a specified placeholder strategy to obtain the field information of the first row of data corresponding to the second specified element. The specified placeholder strategy includes at least one of the following: a placeholder strategy that uses a preset value for placeholders, or a placeholder strategy that uses a backtracking field method.

[0208] In this example, for any second specified element among multiple specified elements, the electronic device determines the field information of the first field corresponding to the second specified element from the first row of data based on the first mapping relationship. If it is determined that all first fields corresponding to the second specified element in the first row of data are missing, then a placeholder is performed based on the specified placeholder strategy to obtain the field information of the first row of data corresponding to the second specified element.

[0209] In some possible examples, the placeholder strategy is specified as a placeholder strategy that uses a preset value, wherein the preset value includes, for example, "unknown" or "Unknown", indicating that the field information in the first row of data corresponding to the second specified element is not obtained, is unknown, or is a value preset in advance for the properties of the second specified element.

[0210] In some possible examples, where there are multiple first fields corresponding to the second specified element, the designated placeholder strategy can be a placeholder strategy using a fallback field approach. Accordingly, the electronic device can determine whether a first field corresponding to the second specified element exists in the first row of data according to the order of the multiple first fields corresponding to the second specified element. If the first field is missing, it determines whether a later field exists in the first row of data. If the later field exists, it extracts the field information of that later field. This designated placeholder strategy ensures the structural integrity of the event model constructed by the specified element, providing a foundation for the safe use of subsequent downstream task models.

[0211] In the above process, leveraging the semantic understanding and reasoning capabilities of a large language model, a first mapping relationship corresponding to the first business is pre-generated on the second behavior dataset generated by the first business. This first mapping relationship includes the relationships between multiple specified elements and multiple first fields learned from the second behavior dataset. Subsequently, the first behavior data corresponding to the first business is processed using this first mapping relationship to obtain the field information corresponding to each specified element in the first behavior data. Since these specified elements are predefined event elements used to describe user behavior for all businesses, the above process can effectively align fields across multiple businesses, that is, uniformly map the fields of each business to the corresponding specified elements. These elements together constitute the event structure required to describe user behavior. Accordingly, based on the field information corresponding to each specified element in the first behavior data, the user behavior reflected by the first behavior data can be clearly represented, achieving the unification of field semantics across businesses and the semantics represented by user behavior data. The above process not only helps reduce the processing cost of user behavior data but also significantly improves data processing efficiency.

[0212] The user behavior data processed in the above way can be used to align user profiles across different business units. Subsequently, downstream task models (such as recommendation models and risk control models) trained using user behavior data generated in a particular business unit can be better migrated across different business units (platforms).

[0213] In some other possible examples, during the processing of user behavior data, such as Figure 3 As shown, the method includes the following steps S310-S330:

[0214] In step S310, a first line of data is obtained, wherein the first line of data corresponds to the first service. The implementation principle of step S310 is similar to that of step S210 described above, and its implementation process can be found in the implementation process of step S210 described above, and will not be repeated here.

[0215] In step S320, the first script corresponding to the first service is obtained, wherein the first script includes a first mapping relationship; the first mapping relationship is generated by the first large language model based on the second behavior dataset generated in the first service, and the first mapping relationship includes the mapping relationship between multiple specified elements and multiple first fields, wherein the multiple specified elements are event elements predefined for all services to describe user behavior.

[0216] The first script is generated using the first mapping relationship and the second major language model.

[0217] In some possible examples, the first script corresponding to the first service may be pre-generated and stored in the aforementioned designated storage space. In this step, the electronic device can retrieve the first script corresponding to the first service from the designated storage space.

[0218] In some possible examples, the first script corresponding to the first business is generated through the following steps 31-32: In step 31, based on the second behavior dataset, the first mapping relationship is determined through the first large language model.

[0219] In step 32, the first script is generated using the first mapping relationship and the second language model.

[0220] The implementation principle of step 31 is similar to that of step 06, and its implementation process can be found in the implementation process of step 06. The implementation principle of step 32 is similar to that of step 07, and its implementation process can be found in the implementation process of step 07, which will not be repeated here.

[0221] In some possible examples, a designated storage space stores multiple different versions of the script corresponding to the first service. In some cases, the electronic device can retrieve the latest version of the script corresponding to the first service from the designated storage space and use it as the first script. In still other cases, the electronic device can also retrieve the corresponding version of the script from the designated storage space based on user settings (which specify the version of the script to be retrieved) and use it as the first script corresponding to the first service.

[0222] In some possible examples, the first behavior data is obtained from the current behavior dataset collected in the current period (i.e., the latest period); step S320 may include the following steps: if the data situation of the current behavior dataset has not changed relative to the data situation of the second behavior dataset, then the first script corresponding to the first service is obtained. In this example, the electronic device first summarizes the data situation in the current behavior dataset, such as the field distribution, and determines whether the data situation of the current behavior dataset has changed relative to the data situation of the second behavior dataset. If the data situation of the current behavior dataset has not changed relative to the data situation of the second behavior dataset, then it is determined that the first script generated based on the second behavior dataset is suitable for processing the behavior data in the current behavior dataset, and accordingly, the first script corresponding to the first service is obtained.

[0223] In some possible examples, the data situation of the aforementioned current behavior dataset has not changed relative to the data situation of the second behavior dataset, which may include: the changes in the fields in the current behavior dataset relative to the fields in the second behavior dataset have not exceeded a first change threshold.

[0224] In some specific examples, it is possible to check the field distribution in the current behavior dataset and / or the changes in the nesting paths of fields in the behavior data. Specifically, if the field distribution in the current behavior dataset indicates that, relative to the field distribution in the second behavior dataset, the field missing rate exceeds a specified missing threshold, the rate of newly added fields (names) or the rate of missing fields exceeds a specified field change threshold; or the nesting paths of fields have changed, then it is necessary to re-sampling the current behavior dataset in a stratified manner, and using the new sampled behavior dataset obtained from the stratified sampling, combine the first and second language models to generate a new version of the script.

[0225] After gray-scale verification confirms the consistency of the output (processed behavioral data) of the new version of the script and the old version (the verified script stored in the specified storage space), the new version of the script is deemed compliant. Subsequently, the new version of the script will be directly used as the first script for the first business function to process the behavioral data in the current behavioral dataset.

[0226] In the above cases, the first change threshold includes the specified missing threshold and the specified field change threshold as described above.

[0227] In some possible examples, the first script can be a JEXL script or another equivalent expression language format in the related art.

[0228] After obtaining the first script, in step S330, the first script is used to process the first row of data to obtain the field information corresponding to each specified element in the first row of data based on the first mapping relationship. In this step, the first script can be run through a script engine to parse the first row of data and obtain the field information corresponding to each specified element in the first row of data based on the first mapping relationship.

[0229] In some possible examples, the first script may also include field extraction logic based on the first mapping relationship; in step S330, the following step 41 may be included: in step 41, the field extraction logic in the first script is run through the script engine to extract field information corresponding to the specified element from the first row data based on the first mapping relationship for each specified element.

[0230] For example, if the first script is a JEXL script, the script engine can be a JEXL script engine. This is a high-performance expression engine that executes processing logic generated by a Large Language Model (LLM).

[0231] The field extraction logic may include: the extraction logic compiled based on field extraction rules such as value rules, missing completion strategies, conflict resolution strategies, and conditional branching strategies for each specified element; the script engine runs the field extraction logic in the first script to extract the field information corresponding to the specified element from the first row of data according to the corresponding field extraction rules.

[0232] The above method enables the standardization of any behavioral data to obtain standardized results. The standardized behavioral data focuses on key fields that can clearly and easily represent user behavior (i.e., fields corresponding to each specified element), thus achieving the trimming and compression of fields in the behavioral data that are irrelevant to representing user behavior.

[0233] In some other possible examples, during the processing of user behavior data, such as Figure 3 As shown, the first script further includes: a narrative text template; the method may also include the following step S340:

[0234] In step S340, based on the narrative text template and the field information of the first row data corresponding to each specified element, a narrative text corresponding to the first row data is generated, wherein the narrative text is used to describe the user behavior corresponding to the first row data in natural language.

[0235] In this step, the first script defines a narrative text template for describing user behavior corresponding to behavioral data in natural language. This narrative text template includes locations for adding field information corresponding to each specified element. The electronic device runs the first script through a script engine. Based on a first mapping relationship, it extracts the field information corresponding to each specified element from the first behavioral data. Then, it adds the extracted field information to the corresponding locations in the narrative text template to generate the narrative text corresponding to the first behavioral data.

[0236] For example, the narrative text template can be represented as follows: "At {time (the location where the field information corresponding to the time element is added)}, at {scene (the location where the field information corresponding to the scene element is added)}, {action (the location where the field information corresponding to the object element is added)} is performed on {object (the location where the field information corresponding to the object element is added)}, in the manner of {channel (the location where the field information corresponding to the channel element is added)}."

[0237] The above process transforms the semantic understanding capabilities of the large language model into deterministic execution capabilities, i.e., generating corresponding executable scripts. Then, using these scripts, which have a predetermined method for processing data, the corresponding behavioral data is processed, achieving "one-time reasoning (generating a script containing mapping relationships), multiple executions (executing the script multiple times to process behavioral data)." A compiled architecture is used to extract and align event elements from the large language model, thereby generating executable scripts. These executable scripts are then used to perform batch deterministic behavioral data processing (standardization). The large language model is only used to generate / update scripts; there is no need to call the large language model multiple times when processing behavioral data. This preserves the semantic depth of the behavioral data while significantly reducing the cost of calling the online large language model, thus controlling cost and stability.

[0238] Furthermore, the above process constructs a "dual-track output architecture," namely, a structured track (i.e., the field information corresponding to each specified element in the structured behavioral data) and a semantic track (i.e., the narrative text corresponding to the behavioral data). The stable feature structure in the structured track ensures the rigor of the data, providing a solid foundation for the user behavior data processing system. Using this type of structured track (data) to train downstream task models (such as recommendation / prediction models requiring strong controllability and interpretability) can improve model stability to a certain extent. The semantic track has stronger semantic meaning, releasing the fluidity of the data and endowing it with narrative capabilities. It can be used for training downstream large-scale models / retrieval enhancement / semantic classification enhancement models, improving the model's generalization ability across business semantic transfer, and to some extent solving the problem that "features in the structured track lack sufficient semantics, while the semantic text is semantically uncontrollable."

[0239] The "dual-track output architecture" enables the generation of processing results, each destined for a different consumer terminal, through a single high-quality processing flow. This architecture not only enhances the system's generalization capabilities but also significantly reduces the marginal cost of data consumption.

[0240] Furthermore, the above process incorporates an automatic detection mechanism for changes in the behavior dataset (data drift), which then determines whether to add corresponding scripts based on the detection results. This forms a closed-loop detection mechanism: "large language model generates scripts -- deterministic execution -- dual-track output -- automatic evolution." This architecture enables the user behavior data processing system to be adaptive, maintaining semantic stability even under rapid business iterations. It also better enables dynamic updates to new field mapping rules based on time, better addressing dynamic field offsets and meeting the semantic requirements of large-scale production-level behavioral data.

[0241] The foregoing description describes specific embodiments of this specification; other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than those shown in the embodiments, and the desired result may still be achieved. Furthermore, the processes depicted in the drawings do not necessarily need to follow the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0242] Corresponding to the above method embodiments, this specification provides a user behavior data processing device 400, the schematic block diagram of which is shown below. Figure 4 As shown, it includes:

[0243] The first acquisition module 410 is configured to acquire first line data, wherein the first line data corresponds to the first service.

[0244] The first processing module 420 is configured to process the first behavior data based on the first mapping relationship corresponding to the first business, and obtain the field information of the first behavior data corresponding to each specified element. The first mapping relationship is generated by a first large language model based on the second behavior dataset generated in the first business. The first mapping relationship includes the mapping relationship between multiple specified elements and multiple first fields. The multiple specified elements are event elements predefined for all businesses to describe user behavior.

[0245] In some possible examples, the first row of data is in JSON format.

[0246] In some possible examples, this also includes:

[0247] The second acquisition module (not shown in the figure) is configured to acquire the first script corresponding to the first service, wherein the first script includes the first mapping relationship;

[0248] The first processing module 420 is specifically configured to process the first behavioral data using the first script, so as to obtain the field information of the first behavioral data corresponding to each specified element based on the first mapping relationship.

[0249] In some possible examples, the first script may also include field extraction logic based on the first mapping relationship;

[0250] The first processing module 420 is specifically configured to run the field extraction logic in the first script through a script engine, so as to extract the field information corresponding to the specified element from the first behavior data based on the first mapping relationship for each specified element.

[0251] In some possible examples, the first script may also include: a narrative text template;

[0252] The first processing module 420 is further configured to generate narrative text corresponding to the first behavior data based on the narrative text template and the field information of the first behavior data corresponding to each specified element, wherein the narrative text is used to describe the user behavior corresponding to the first behavior data in natural language.

[0253] In some possible examples, this also includes:

[0254] The determination module (not shown in the figure) is configured to determine the first mapping relationship based on the second behavior dataset and through the first large language model before obtaining the first script corresponding to the first service;

[0255] The generation module (not shown in the figure) is configured to generate the first script using the first mapping relationship through the second major language model.

[0256] In some possible examples, the multiple specified elements include: time elements, scene elements, action elements, and object elements.

[0257] In some possible examples, the second behavior dataset belongs to the field behavior dataset collected from the first service during the first period:

[0258] The second behavior dataset includes high-frequency behavior data with a first proportion, long-tail behavior data with a second proportion, and complex attribute behavior data with a third proportion in the field behavior dataset. The first proportion is greater than the second proportion and greater than the third proportion. The complex attribute behavior data is field behavior data with a nesting level exceeding a first level threshold and / or a field number exceeding a first number threshold.

[0259] In some possible examples, the plurality of specified elements includes a first specified element, and the first mapping relationship indicates that the first specified element corresponds to a plurality of first fields;

[0260] The first processing module 420 is specifically configured to perform the following steps based on the priority of each of the multiple first fields corresponding to the first specified feature, in descending order of priority:

[0261] If a first field with current priority is detected in the first behavior data, the field information of the first field with current priority is extracted to obtain the field information corresponding to the first specified element;

[0262] If the first field of the current priority is not detected in the first behavior data, then it is detected whether the first field of the next priority of the current priority exists in the first behavior data. If the first field of the next priority exists, the field information of the first field of the current priority is extracted to obtain the field information corresponding to the first specified element.

[0263] In some possible examples, the first processing module 420 is specifically configured to, for any second specified element among the plurality of specified elements, if it is determined that all first fields in the first behavioral data corresponding to the second specified element are missing, then place the fields based on a specified placeholder strategy to obtain the field information of the first behavioral data corresponding to the second specified element. The specified placeholder strategy includes at least one of the following: a placeholder strategy using a preset value placeholder, or a placeholder strategy using a backtracking field method.

[0264] In some possible examples, the first behavioral data is obtained from the current behavioral dataset collected in the current period;

[0265] The first acquisition module 410 is configured to acquire the first script corresponding to the first service if the data situation of the current behavior dataset has not changed relative to the data situation of the second behavior dataset.

[0266] In some possible examples, the data situation of the current behavior dataset has not changed relative to the data situation of the second behavior dataset, including: the changes in the fields in the current behavior dataset relative to the fields in the second behavior dataset have not exceeded a first change threshold.

[0267] The above-described apparatus embodiments correspond to the method embodiments, and detailed descriptions can be found in the description of the method embodiments section, which will not be repeated here. The apparatus embodiments are derived based on the corresponding method embodiments and have the same technical effects as the corresponding method embodiments; detailed descriptions can be found in the corresponding method embodiments.

[0268] This specification also provides a computer-readable storage medium storing a computer program thereon, which, when executed in a computer, causes the computer to perform the user behavior data processing method provided in this specification.

[0269] This specification also provides a computing device, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements the user behavior data processing method provided in this specification.

[0270] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for storage media and computing devices are basically similar to the method embodiments, so they are described more simply; relevant parts can be referred to the descriptions of the method embodiments.

[0271] Those skilled in the art will recognize that the functions described in the embodiments of the present invention in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0272] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, or improvements made based on the technical solutions of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for processing user behavior data, comprising: Obtain first behavior data, wherein the first behavior data corresponds to the first service; Based on the first mapping relationship corresponding to the first business, the first behavior data is processed to obtain the field information of the first behavior data corresponding to each specified element. The first mapping relationship is generated by the first large language model based on the second behavior dataset generated in the first business. The first mapping relationship includes the mapping relationship between multiple specified elements and multiple first fields. The multiple specified elements are event elements predefined for all businesses to describe user behavior.

2. The method as described in claim 1, wherein, The first row of data is in JSON format.

3. The method of claim 1, further comprising: Obtain the first script corresponding to the first service, wherein the first script includes the first mapping relationship; The field information corresponding to each specified element obtained from the first row data includes: The first script is used to process the first behavioral data to obtain field information corresponding to each specified element based on the first mapping relationship.

4. The method of claim 3, wherein, The first script also includes field extraction logic based on the first mapping relationship; The step of processing the first behavioral data using the first script to obtain field information corresponding to each specified element of the first behavioral data based on the first mapping relationship includes: The script engine runs the field extraction logic in the first script to extract field information corresponding to each specified element from the first behavioral data based on the first mapping relationship.

5. The method of claim 3, wherein, The first script also includes: a narrative text template; Also includes: Based on the narrative text template and the field information of the first behavior data corresponding to each specified element, a narrative text corresponding to the first behavior data is generated, wherein the narrative text is used to describe the user behavior corresponding to the first behavior data in natural language.

6. The method of claim 3, further comprising, before obtaining the first script corresponding to the first service: Based on the second behavior dataset, the first mapping relationship is determined using the first large language model; Using the first mapping relationship, the first script is generated through the second major language model.

7. The method of claim 1, wherein, The specified elements include: time elements, scene elements, action elements, and object elements.

8. The method of claim 1, wherein, The second behavior dataset belongs to the field behavior dataset collected from the first service during the first period: The second behavior dataset includes high-frequency behavior data with a first proportion, long-tail behavior data with a second proportion, and complex attribute behavior data with a third proportion in the field behavior dataset. The first proportion is greater than the second proportion and greater than the third proportion. The complex attribute behavior data is field behavior data with a nesting level exceeding a first level threshold and / or a field number exceeding a first number threshold.

9. The method of claim 1, wherein, The plurality of specified elements includes a first specified element, and the first mapping relationship indicates that the first specified element corresponds to a plurality of first fields; The field information corresponding to each specified element obtained from the first row data includes: Based on the priority of each of the multiple first fields corresponding to the first specified feature, the following steps are performed in descending order of priority: If a first field with current priority is detected in the first behavior data, the field information of the first field with current priority is extracted to obtain the field information corresponding to the first specified element; If the first field of the current priority is not detected in the first behavior data, then it is detected whether the first field of the next priority of the current priority exists in the first behavior data. If the first field of the next priority exists, the field information of the first field of the current priority is extracted to obtain the field information corresponding to the first specified element.

10. The method of claim 1, wherein, The field information corresponding to each specified element obtained from the first row data includes: For any second specified element among the plurality of specified elements, if it is determined that all first fields in the first row data corresponding to the second specified element are missing, then a placeholder is placed based on a specified placeholder strategy to obtain the field information of the first row data corresponding to the second specified element. The specified placeholder strategy includes at least one of the following: a placeholder strategy that uses a preset value for placeholder, or a placeholder strategy that uses a backtracking field method.

11. The method of claim 3, wherein, The first behavioral data is obtained from the current behavioral dataset collected in the current period; The step of obtaining the first script corresponding to the first service includes: If the data condition of the current behavior dataset has not changed relative to the data condition of the second behavior dataset, then the first script corresponding to the first service is obtained.

12. The method of claim 11, wherein, The data condition of the current behavior dataset has not changed relative to the data condition of the second behavior dataset, including: The changes in the fields in the current behavior dataset relative to the fields in the second behavior dataset did not exceed the first change threshold.

13. A user behavior data processing apparatus, comprising: The first acquisition module is configured to acquire first line data, wherein the first line data corresponds to the first service. The first processing module is configured to process the first behavior data based on the first mapping relationship corresponding to the first business, and obtain the field information of the first behavior data corresponding to each specified element. The first mapping relationship is generated by a first large language model based on the second behavior dataset generated in the first business. The first mapping relationship includes the mapping relationship between multiple specified elements and multiple first fields. The multiple specified elements are event elements predefined for all businesses to describe user behavior.

14. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-12.

Images