A user portrait label dynamic processing method based on multi-agent cooperation

Abstract

This invention relates to the field of electronic digital data processing technology and discloses a method for dynamic processing of user profile tags based on multi-agent collaboration. The method establishes a profile processing session, registers the profile object number, data reception time range, and configuration version; receives behavior records, text records, fact records, and device status records, and forms candidate tag records by different tag processing agents; generates a candidate set according to the profile object number, tag bit number, and applicable time range; reads historical valid tag versions, mutually exclusive tag bits, dependent tag bits, and abnormal time period records and registers conflict states; forms tag version records based on conflict states, source trust level, event timeliness, historical valid tag versions, and tag dependencies; performs write switching in the order of tag wide table, profile index, real-time cache, and call record index, and restores the valid tag version corresponding to the rollback target in case of an anomaly.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, specifically to a method for dynamic processing of user profile tags based on multi-agent collaboration. Background Technology

[0002] User profile tags are typically formed from registration information, behavior logs, content interactions, transaction records, device status, and third-party data processing. They are used to describe a user's basic attributes, behavioral preferences, activity level, consumption intentions, risk status, and scenario characteristics. Existing profiling platforms mostly use offline tasks, rule engines, wide tag tables, model prediction, and timed incremental updates to generate tags, and provide the results to downstream systems such as recommendation, search, content distribution, and risk control through profile indexes and caching interfaces.

[0003] In actual operation, the same user will continuously generate new behavioral events at different business entry points, on different terminal devices, and at different time periods. The user profile platform needs to supplement, update, downgrade, or invalidate existing tags accordingly. Existing solutions typically match preset rules based on the current behavioral event or call the model to generate new tag values ​​and then write the tag values ​​into the corresponding tag positions. Some solutions reduce full recalculation and improve tag update efficiency by using incremental updates, differential updates, time decay, or field-level overwriting methods.

[0004] However, the above methods typically focus more on the generation and writing of label values, lacking a unified judgment on whether candidate labels should be effective. Especially after introducing multi-agent collaborative processing, the behavior analysis agent, semantic extraction agent, rule verification agent, conflict judgment agent, and label writing agent may generate candidate labels based on different data ranges, processing cycles, and confidence levels, easily leading to different label results around the same user and the same label position. For example, if historical valid labels show that a user has been in a highly active state for a long time, but low-frequency access records occur in a short period of time due to device abnormalities, network interruptions, or temporary scene changes, if the system only overwrites the old labels according to the latest events, the stable profile will be rewritten by short-term abnormal and frequent changes; if only historical labels are retained, the real changes will not be reflected in a timely manner.

[0005] Furthermore, user profile tags typically exist simultaneously in the tag wide table, profile index, real-time cache, and downstream call records. When a candidate tag has been written to the tag wide table, but the profile index has not yet been synchronized and the real-time cache still retains the old tag, the downstream system may read different versions of the profile results. If it is subsequently discovered that the tag source is unreliable, conflicts with other tags, or is triggered by a short-term anomaly, the existing solution also lacks a processing chain that can locate the original evidence, identify the effective version, and revert to the previous effective tag state.

[0006] Therefore, existing methods for dynamically processing user profile tags still have problems in scenarios where multiple heterogeneous behavioral events are continuously written and multiple agents generate candidate tags in parallel. These problems include difficulty in unifying the arbitration of candidate tags for the same user and the same tag position, difficulty in keeping the effective version of the tag consistent, the ease with which short-term anomalies can trigger frequent tag flipping, the possibility that expired tags may continue to be called by downstream applications, and the difficulty in tracing and rolling back the tag update process. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a method for dynamically processing user profile tags based on multi-agent collaboration, thus solving the aforementioned problems.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a method for dynamic processing of user profile tags based on multi-agent collaboration, comprising: S1. Establish a portrait processing session, register the portrait object number, data reception time range, tag dictionary version, tag bit configuration version, evidence source configuration version, tag dependency configuration version, and write to the hierarchical list; S2. Receive behavior records, text records, fact records and device status records according to the portrait object number, and form candidate tag records with source record number, event time, source trust level, applicable time range and candidate status by different tag processing agents; S3. Generate a candidate set using the portrait object number, tag number, and applicable time range as the merge key. Read historical valid tag versions, mutually exclusive tag bits, dependent tag bits, and abnormal time period records, and register the conflict status of the candidate set. S4. Based on the conflict status, source trust level, event timeliness, historical valid tag versions, and tag dependencies, determine the version status, replacement relationship, writing level, and rollback target of the tag version record to form the tag version record; S5. Switch the tag version in the order of tag wide table, profile index, real-time cache and call record index, and restore the valid tag version corresponding to the rollback target if any of the following states occur: missing write level, evidence withdrawal, conflict state not resolved, change of historical valid tag version, and invalidation of applicable time range.

[0009] Furthermore, establishing a profile processing session includes: Read the batch number, data reception start time, data reception end time, access system number, and batch verification mark from the data batch registration table; Write data whose event reception time reaches the data reception start time but is earlier than the data reception end time into the current profile processing session; Write data whose event reception time has reached the data reception deadline into the next profile processing session; Data whose event occurred earlier than the start time of data reception for the current portrait processing session, and whose event reception time falls within the current portrait processing session, are registered as late records.

[0010] Furthermore, the registration portrait object number includes: If a platform user ID exists in the source record, the platform user ID will be registered as the profile object ID; When the platform user ID is missing but the login account ID exists, read the binding record in the identity relationship table where the binding start time is no later than the event occurrence time, the unbinding time is not registered, and the binding source status is valid, and register the bound platform user ID as the profile object ID; When the platform user ID is missing but the login account ID exists, read the binding record in the identity relationship table whose binding start time is no later than the event occurrence time, whose unbinding time is later than the event occurrence time, and whose binding source status is valid, and register the bound platform user ID as the profile object ID; When both the platform user ID and login account ID are missing, a temporary profile object ID is generated in a fixed order of device ID, session ID, source system ID, and first event time. When a temporary profile object is subsequently matched with a valid platform user ID, its candidate tag records are transferred to the corresponding profile object ID and re-merged.

[0011] Furthermore, the registered configuration versions include: Read the tag bit number, tag value name, tag value level, and tag value scope from the tag dictionary version; Read the tag type, value range, single-value attribute, multi-value attribute, stability period, expiration condition, and allowed source from the tag configuration version; Read the source trust level, required fields, late arrival allowance, deduplication field and field completion deadline from the evidence source configuration version; Read the upstream tag bit, downstream tag bit, mutual exclusion relationship, dependency missing handling method and dependency conflict handling method in the tag dependency configuration version.

[0012] Furthermore, the formation of candidate label records includes: The behavior records, text records, fact records, and device status records are deduplicated according to the deduplication field of the version registration based on the evidence source configuration. When the deduplication fields are completely identical, retain the source record that first entered the portrait processing session; When the deduplication fields are identical but the field contents differ, a source conflict pending verification record is registered. Candidate tag records are formed when the source record meets the tag bit number, source record type, trigger field, field value range, and minimum source trust level in the tag formation rule table.

[0013] Furthermore, candidate label records are generated in the following way: Candidate tag numbers are formed in a fixed order of portrait processing session number, portrait object number, tag number, source record number, and candidate serial number; Write the candidate label value, candidate label level, source record type, event time, source trust level, applicable time range, candidate status, and agent number into the candidate label record; The time frame for events is determined based on the type of source record. For behavioral records, the time of event occurrence is used; for text records, the time of text generation is used; for fact records, the time of record effectiveness is used; and for device status records, the time of abnormal start and end and the time of abnormal impact are used, and these are not used as the formal starting point for the applicable time range of candidate tags.

[0014] Furthermore, the registration candidate status includes: When the required fields are complete, the event time is complete, the source trust level reaches the minimum source trust level registered in the tag formation rule table, and the candidate tag value exists in the tag dictionary version and is not restricted by abnormal time periods, it is registered as a mergeable state. When the event time is missing, it is registered as a time pending verification status; When a source record lacks a required field for the label formation rule table, it is registered as a field pending completion. When the event time corresponding to the candidate tag falls within the abnormal period covered by the device status record, an abnormal impact flag is added to the candidate tag record, and the candidate tag record is brought into S3 for abnormal impact conflict registration. When the review conclusion field of the manual review record is registered as rejected, it is registered as a manual rejection status.

[0015] Furthermore, generating the candidate set includes: Read candidate tag records whose candidate status is mergeable, as well as candidate tag records with anomaly impact flags and whose required fields, event time, source trust level, and tag dictionary version meet the merging conditions; Merge keys are formed in a fixed order based on the portrait object number, tag number, and applicable time range; Write candidate label records with completely consistent applicable time ranges into the same candidate set; When the applicable time ranges overlap and the start and end times are inconsistent, the time segmentation granularity of the version registration is configured according to the tag bit and the time segmentation is divided into a unified time period, and a candidate set is generated according to the segmented applicable time range. Candidate set numbers are formed based on the portrait processing session number, portrait object number, tag number, applicable time range start point, applicable time range end point, and set serial number.

[0016] Furthermore, the conflict states of the registered candidate set include: When there are two or more different candidate label values ​​in the candidate set corresponding to a single-value label, register a single-value conflict state. When the number of candidate tag values ​​corresponding to a multi-value tag bit exceeds the capacity limit registered in the tag bit configuration version, a multi-value capacity conflict status is registered. When the candidate tag value and the valid tag version of the mutual exclusion tag bit satisfy the mutual exclusion relationship registered in the tag dependency configuration version, register the mutual exclusion conflict state; If no valid tag version exists in the upstream tag position, register the dependency missing status; When the candidate tag event time falls within an abnormal period covered by the device status record, register the abnormal impact conflict status. When the source credibility level is lower than the lowest effective level registered in the label configuration version, and the candidate label value and the historical effective label value have an inverse relationship in the label value direction relationship table, a weak evidence conflict state is registered.

[0017] Furthermore, performing a tag version write switch includes: When the tag version record is in a pending state and the hierarchical registration is complete, the tag version will be written to the pending area of ​​the tag wide table. After the tag wide table is written to the area to be activated, write the same tag version number to the image index to be switched area; When the same image object number, the same tag position number, the same applicable time range, and the same tag version number are registered in both the tag wide table waiting to take effect area and the image index waiting to switch area, the real-time cache read pointer will be switched to the new tag version; After the real-time cache switch is completed, the tag version number, callable time, applicable time range, and version status are written into the call record index; If any of the following states occur, such as missing write level, evidence withdrawal, unresolved conflict, changes in historical valid tag version, or invalidation of applicable time range, and the rollback target is valid, the valid tag version corresponding to the rollback target is restored in the order of real-time cache, profile index, tag wide table, and call record index. If the rollback target is empty or invalid, the corresponding profile object number and tag bit number are registered as a state of no valid version pending verification.

[0018] Compared with existing technologies, this invention provides a method for dynamic processing of user profile tags based on multi-agent collaboration, which has the following beneficial effects: 1. This invention establishes a user profile processing session, uniformly registering the profile object number, data reception time range, tag dictionary version, tag configuration version, evidence source configuration version, tag dependency configuration version, and writing level list. Different tag processing agents generate candidate tag records with source record number, event time, source credibility level, applicable time range, and candidate status. Then, a candidate set is generated using the profile object number, tag number, and applicable time range. Combining historical valid tag versions, mutually exclusive tag bits, dependent tag bits, and abnormal time period records to register conflict states, this invention ensures that candidate tags from different behavior records, text records, fact records, and device status records for the same user and the same tag bit are no longer directly overwritten. Instead, they first undergo candidate merging, conflict identification, version status determination, replacement relationship determination, writing level determination, and rollback target registration before entering the writing switch. This reduces frequent tag flipping caused by short-term anomalies, weak evidence sources, and mutually exclusive tags, avoids the mutual overwriting of current behavior tags, historical stable tags, and scenario inference tags, and improves version consistency, traceability, and recoverability in the dynamic processing of user profile tags.

[0019] 2. This invention performs tag version write switching in the order of tag wide table, portrait index, real-time cache, and call record index. It registers the same portrait object number, tag bit number, applicable time range, and tag version number in both the tag wide table's pending activation area and the portrait index's pending switching area before switching the real-time cache read pointer. This prevents tag versions from existing in a concurrent call state across multiple write levels. When a write level is abnormal, evidence is withdrawn, or a conflict state is not resolved, the valid tag version corresponding to the rollback target is restored in the order of real-time cache, portrait index, tag wide table, and call record index. This prevents expired tags, withdrawn evidence tags, and tags that have not completed consistency verification from continuing to be read downstream, improving data consistency in the multi-level portrait tag storage and retrieval process. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the process of a dynamic processing method for user profile tags based on multi-agent collaboration according to the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] Example: Figure 1A method for dynamic processing of user profile tags based on multi-agent collaboration is presented, including: S1. Establish a profile processing session, register the profile object number, data reception time range, tag dictionary version, tag configuration version, evidence source configuration version, tag dependency configuration version, and write it to the hierarchical list. The specific implementation is as follows: First, read the data batch registration table to be processed. The data batch registration table should at least record the batch number, batch source, data reception start time, data reception end time, access system number, batch generation time, batch status, and batch verification flag.

[0023] The data reception start time, data reception end time, event occurrence time, and event reception time all adopt the unified time zone registered by the portrait processing platform; the data reception time range of the current portrait processing session adopts the boundary caliber of including the start time and excluding the end time, that is, data whose event reception time reaches the data reception start time and is earlier than the data reception end time enters the current portrait processing session.

[0024] Data whose event reception time is earlier than the data reception start time will not enter the current profile processing session. Data whose event reception time reaches the data reception deadline will enter the next profile processing session to avoid data at the same boundary time being processed repeatedly.

[0025] The portrait processing session uses the data reception start time and data reception end time as the time boundary for this processing. Data whose event occurrence time falls before the current portrait processing session, but whose event reception time falls within the current portrait processing session, is registered as a late record. The late record must at least record the original event occurrence time, event reception time, source system number, source record number, late reason field, and late processing status.

[0026] Late arrival status is categorized into three levels: eligible to enter the current session, pending late arrival review, and transferred to the next session. The event occurrence time of the late arrival record is still used to determine the applicable time range of subsequent candidate tags, while the event reception time is only used to determine which profile processing session it enters. Data with missing event occurrence time and only event reception time is recorded as a pending time review record and is not processed as a late arrival record; after the event occurrence time is supplemented later, the late arrival status is re-registered based on the supplemented event occurrence time.

[0027] The portrait processing session number is formed by concatenating the processing date, batch number, tag configuration version number, and serial number in a fixed order. The concatenation order remains consistent within the same portrait processing platform and does not change with the candidate tag formation result, conflict status, or writing result.

[0028] If a completed portrait processing session already exists for the same batch number, the same tag configuration version number, and the same data reception time range, the new session request is registered as a duplicate batch status, and no candidate tag record is generated again; if an existing portrait processing session is in a failed or aborted state, the new session request is registered as a restarted batch status, and the processed range in the failed or aborted record is referenced, with the incomplete range re-entering processing; if an existing portrait processing session is in a processing state, the new session request is registered as a duplicate processing state, and only the request record is retained.

[0029] The platform user ID is prioritized when assigning a profile object number. When a platform user ID exists in behavior records, text records, fact records, and device status records, it is directly used as the profile object number. When a platform user ID is missing but a login account ID exists, the binding record between the login account ID and the platform user ID in the identity relationship table is read. If the binding start time is no later than the event occurrence time, the unbinding time is null or later than the event occurrence time, and the binding source status is valid, the bound platform user ID is used as the profile object number. When the same login account ID corresponds to multiple valid binding records at the same event occurrence time, the corresponding data is registered as an identity conflict pending verification record, and no formal profile object number is generated. When both the platform user ID and the login account ID are missing, and only the device ID and session ID exist, a temporary profile object number is generated in a fixed order: device ID, session ID, source system ID, and first event time. The temporary profile object status is then registered in the profile processing session.

[0030] The rules for forming the temporary profile object status are as follows: when data corresponding to the same device number, the same session number, the same source system number, and the same initial event time has not yet been matched with a valid platform user number, it is registered as a temporary profile object. The temporary profile object status is maintained until a valid binding record appears in the identity relationship table, the data corresponding to the temporary profile object reaches the temporary retention deadline, and the manual review record confirms that it is independently retained as a pending review object.

[0031] When registering valid platform user IDs in the identity relationship table, candidate tag records that have been formed but not yet effective under the temporary profile object ID will be converted into candidate tag records under the official profile object ID, and the temporary object will be retained and merged into the record. If a candidate set already exists under the temporary profile object, the candidate set will not be effective directly, and will be merged again according to the official profile object ID. If no valid platform user ID is matched by the expiration of the temporary retention deadline, the temporary profile object will be registered as a pending object, and its candidate tags will only be allowed to enter the candidate record area and will not enter the official tag version writing process.

[0032] For records with unbinding times in the identity relationship table, data after the unbinding time will no longer be included in the portrait object number before unbinding. Tag versions that were already in effect before the unbinding time will retain their historical records under the original portrait object number; records generated after the unbinding time will form portrait object numbers according to the new binding relationship.

[0033] If the unbinding record is subsequently withdrawn, the data after the withdrawal time will re-enter the identity relationship pending verification state and will not be directly written back to the original portrait object number to avoid frequent migration of portrait tags caused by repeated changes in identity relationship.

[0034] The image processing session also registers the tag dictionary version, tag bit configuration version, evidence source configuration version, tag dependency configuration version, and writes to the hierarchical list.

[0035] The tag dictionary version is used to limit the allowed tag bit numbers, tag value names, tag value levels, and tag value applicable scope in the current profile processing session; the tag bit configuration version is used to limit the tag type, value range, single-value attributes, multi-value attributes, stability period, failure conditions, allowed sources, and call boundaries for each tag bit; the evidence source configuration version is used to limit the source trust level, required fields, late arrival allowance, deduplication fields, and field completion deadline for behavior records, text records, fact records, and device status records; the tag dependency configuration version is used to limit upstream tag bits, downstream tag bits, dependencies, mutual exclusion relationships, dependency missing handling methods, and dependency conflict handling methods; the write hierarchy list is used to limit the order in which tag versions are subsequently written to the tag wide table, profile index, real-time cache, and call record index.

[0036] The tag dictionary version, tag configuration version, evidence source configuration version, and tag dependency configuration version all have a version number, version effective time, version expiration time, and version status. The profile processing session can only reference configuration versions whose version status is "effective" and whose data reception start time falls between the version effective time and the version expiration time.

[0037] In this embodiment, the allowed late arrival time, field completion deadline, temporary retention deadline, tag stability period, tag validity period, time segmentation granularity, capacity limit, minimum source trust level, minimum effectiveness level, candidate tag retention period, and write recovery period are not generated temporarily by the tag processing agent, but rather originate from the configuration version pre-registered by the portrait processing platform. The configuration version is formed based on historical data reception delays, source system reissue cycles, tag call timeliness requirements, cache synchronization cycles, downstream interface consistency requirements, and manual review cycles, and is registered before the version takes effect. The portrait processing session only references the effective configuration version corresponding to its data reception start time, and does not use the above parameters as fixed values ​​for all portrait processing platforms. When the configuration version is updated, existing portrait processing sessions continue to reference the original configuration version, while newly established portrait processing sessions reference the updated and effective configuration version.

[0038] If any configuration version is not in an active state, the profile processing session is registered as a configuration pending state and will not proceed to candidate tag generation. The configuration pending state will remain until the missing configuration version is registered as active; after the missing configuration version is completed, the profile processing session will reread the same data batch registration table and generate candidate tag records with the completed configuration version; if the data batch before the completion has been withdrawn, the profile processing session will be registered as a configuration pending termination state.

[0039] If no processable data is available within the data reception time range, the profile processing session is registered as an empty batch. Only the session number, data reception time range, configuration version, and reason for the empty batch are retained; no candidate tag records are generated. The empty batch status does not participate in candidate set merging, conflict status registration, or tag version writing and switching. If a subsequent source system reissues a late record within the same data reception time range, the reissued record enters a new profile processing session according to the late record rules, without modifying the already registered empty batch status.

[0040] Once the profile processing session is established, the criteria for profile object numbering, data reception time boundaries, late arrival record criteria, tag configuration criteria, evidence source criteria, tag dependency criteria, and write level criteria within the session are all fixed. Subsequent candidate tag formation, candidate set merging, conflict status registration, tag version record generation, and write switching all reference the same profile processing session number. If subsequent steps discover anomalies in configuration version, identity relationship, or time boundaries, the original profile processing session is not directly modified. Instead, an abnormal session record is registered, and the session enters the corresponding pending verification state. After the pending verification state is lifted, a new profile processing session is established, or the unaffected data range from the original profile processing session continues to be referenced.

[0041] This ensures that the same batch of data uses consistent data boundaries and configuration standards throughout the candidate label generation, conflict arbitration, version governance, and write switching processes, avoiding mismatches in label processing results due to inconsistent version standards at different steps.

[0042] S2. Receive behavior records, text records, fact records, and device status records according to the profile object number. Different tag processing agents then generate candidate tag records with source record number, event time, source trust level, applicable time range, and candidate status. Specifically, the implementation is as follows: A tag processing agent is a processing unit that performs candidate tag formation, field verification, status registration, and record output according to the corresponding source record type and tag formation rule table, and does not use the model training result as the sole criterion for judgment.

[0043] Different label processing agents include at least behavioral evidence agents, text evidence agents, factual evidence agents, and device status evidence agents. The behavioral evidence agent reads behavioral records and forms candidate label records based on behavioral type, business entry number, business object category, and a label formation rule table. The text evidence agent reads text records and forms candidate label records based on text source, text generation time, extracted fields, and a label formation rule table. The factual evidence agent reads factual records and forms candidate label records based on record effective time, status confirmation fields, and a label formation rule table. The device status evidence agent reads device status records and forms abnormal period records, abnormal impact states, and abnormal restriction conditions. The candidate label records output by each label processing agent are registered according to the profile processing session number, profile object number, label bit number, source record number, and candidate serial number, and in subsequent steps, a candidate set is generated according to the profile object number, label bit number, and applicable time range.

[0044] After the profile processing session is established, the fixed profile object number, data reception time range, tag dictionary version, tag bit configuration version, evidence source configuration version, and tag dependency configuration version in the profile processing session are read first. Then, the behavior records, text records, fact records, and device status records that fall within the current data reception time range are read according to the profile object number.

[0045] During data retrieval, deduplication is first performed on the source records. The deduplication fields are read from the evidence source configuration version. For behavior records, the deduplication fields are source system number, source record number, profile object number, event occurrence time, behavior type, and business object number. For text records, the deduplication fields are text source, text record number, profile object number, and text generation time. For fact records, the deduplication fields are source system number, source record number, profile object number, record effective time, and status confirmation field. For device status records, the deduplication fields are exception type, exception start time, exception end time, affected source system, and affected behavior type. Records with completely identical deduplication fields are only retained from the first entry into the profile processing session; subsequent duplicate records are registered as duplicate source records. Records with identical deduplication fields but different field content are registered as source conflict pending verification records and are not directly generated as candidate tag records.

[0046] The definition of behavior records includes user access, clicks, searches, favorites, stays, add-to-cart, purchases, inquiries, exits, and service calls generated in the business entry point. Each behavior record must have at least the source system number, source record number, profile object number, event occurrence time, event reception time, business entry point number, behavior type, business object number, and session number.

[0047] When the behavioral evidence agent reads behavioral records, it first checks whether the source record number, event occurrence time, behavior type, business object number, and profile object number are complete according to the evidence source configuration version. If the above fields are complete and the event reception time falls within the data reception time range of the current profile processing session, it continues to read tags to form a rule table.

[0048] The tag formation rule table must at least register the tag bit number, source record type, allowed source system, trigger field, field value range, business object category, candidate tag value, candidate tag level, minimum source trust level, and abnormal restriction conditions. When the behavior type, business entry number, and business object category in the behavior record simultaneously satisfy the corresponding record in the tag formation rule table, a candidate tag value is formed based on the tag dictionary version.

[0049] If the behavior type is not in the allowed source list of the corresponding tag configuration version, the behavior record is registered as a source mismatch and will not form a candidate tag record; if the business object category is not registered by the tag dictionary version, the behavior record is registered as a dictionary mismatch; if the behavior record is missing a business object number but the tag formation rule table requires the business object number to be a required field, the behavior record is registered as a field to be supplemented.

[0050] The definition of text records includes user search terms, customer service conversations, comments and feedback, and questionnaire texts that have been anonymized and can be used for tagging. Each text record must have at least the following information: text source, text record number, profile object number, text generation time, text topic category, negative expression status, manual confirmation status, and anonymization status.

[0051] When the text evidence agent reads a text record, it first checks the anonymization status. If the anonymization status is incomplete, the text record is registered as pending anonymization and no candidate label record is generated. If the anonymization status is complete, it then reads the text topic category and the text topic mapping relationship in the label dictionary version.

[0052] When a text topic category exists in the tag dictionary version and the text source is a source allowed by the tag configuration version, a corresponding text candidate tag record is formed. The negative expression status is formed based on the negative flag field already registered in the text record. The negative flag field comes from the text preprocessing results and the manual review results. When the negative flag field exists, the text record is only allowed to form candidate tags for attention, consultation, and exclusion, and will not form candidate tags for purchase intention confirmation, preference confirmation, and status confirmation.

[0053] The manual confirmation status is formed based on the manual review record. The manual review record shall at least register the review object, review label position, text record number before review, review conclusion, review time and reviewer role. When the manual confirmation status is confirmed, the source credibility level of the text candidate label shall be registered according to the credibility level of the source of manual review in the evidence source configuration version. When the manual confirmation status is rejected, the text record enters the manual rejection status and no candidate label record is formed.

[0054] The scope of fact records includes registration information, real-name authentication information, transaction completion records, order cancellation records, refund records, membership level records, manual review records, and third-party authorization information. Each fact record must have at least the source record number, record effective time, record expiration time, source system number, status confirmation field, and source signature status.

[0055] When the fact-verifying agent reads a fact record, it first checks the record's effective time, status confirmation field, and source signature status. If the record's effective time is missing, the fact record is registered as "fact time pending completion"; if the status confirmation field is missing, the fact record is registered as "fact status pending completion"; if the source signature status is "failed," the fact record is registered as "source signature abnormal status," and no candidate label record is generated.

[0056] When transaction completion records, order cancellation records, and refund records exist simultaneously, the final status is read in the order of their effective times. If the effective time of the refund record is later than that of the transaction completion record, no high-consumption intention candidate label is generated, but a transaction status pending verification candidate label is generated. If the effective time of the order cancellation record is later than that of the add-to-cart record and the inquiry record, no purchase completion candidate label is generated, but only a transaction incomplete candidate label is generated.

[0057] When a manual review record contains the review object, review label, previous label version, review conclusion, and review time, it is used as a candidate label record as a highly reliable source. When a manual review record lacks a previous label version, it is registered as a review object pending review and does not directly overwrite the existing label version.

[0058] The scope of device status records includes client abnormal exit, network interruption, repeated reconnection, device switching, changes in access environment, and resending status from the source system. Each device status record must have at least the abnormal type, abnormal start time, abnormal end time, affected source system, and affected behavior type.

[0059] Device status records do not directly form user profile tag values, but are used to create abnormal impact markers for behavior records and text records. The judgment of abnormal time periods is based on the boundary between the abnormal start time and the abnormal end time; when the event occurrence time of a behavior record falls between the abnormal start time and the abnormal end time, and the source system number and behavior type of the behavior record fall into the affected source system and affected behavior type respectively, the corresponding candidate tag record of the behavior record is registered with an abnormal impact marker, and the source record number, abnormal type, abnormal start time, abnormal end time, affected source system, and affected behavior type are retained.

[0060] If the end time of the anomaly is missing, the anomaly period will continue until the anomaly resolution record is registered in the same source system. Before the anomaly resolution record arrives, the affected candidate tag records can enter S3 to form a candidate set, but the anomaly impact conflict status is registered in S3. Before the anomaly resolution conditions and stable observation range are met, they cannot enter the pending processing path.

[0061] If the abnormal record is subsequently withdrawn by the source system, the candidate tag record that has been registered for the abnormal impact status will enter the abnormal withdrawal pending verification status, waiting to reread the corresponding behavior record and text record.

[0062] Candidate tag records are uniformly formed according to a fixed order: profile processing session number, profile object number, tag bit number, source record number, and candidate serial number. Each candidate tag record must at least register the candidate tag number, profile processing session number, profile object number, tag bit number, candidate tag value, candidate tag level, source record number, source record type, event time, event reception time, source trust level, applicable time range, candidate status, agent number, and complete field flag.

[0063] The source credibility level is not temporarily assigned by different label processing agents, but is read from the evidence source configuration version. Once a record from the same source is manually verified, its source credibility level is registered according to the manually verified source. Once a record from the same source is manually rejected, its source credibility level is no longer used for candidate label formation. The definition of event time is determined based on the source record type: behavioral records use the event occurrence time, text records use the text generation time, factual records use the record effective time, and device status records are only used as the time of anomaly impact and not as the formal starting point for the applicable time range of candidate labels.

[0064] The applicable time range is determined by the event time, the tag stability period, the tag validity period, and the fact record effective time. For static fact tags, the applicable start time is the fact record effective time, and the applicable end time is the fact record expiration time; if the fact record expiration time is null, the applicable end time is registered as triggered by subsequent fact changes. For behavioral statistics tags, the applicable start time is the data reception deadline of the profile processing session, and the applicable end time is the expiration time of the behavioral tag validity period registered in the tag configuration version.

[0065] The applicable start time for preference inference tags is the end time of the profile processing session after the tag stability period is met, and the applicable end time is the expiration time of the preference tag registered in the tag configuration version. The applicable start time for temporary scenario tags is the session start time, and the applicable end time is the session end time; if the session end time is missing, the applicable end time is registered as a session pending end. If the event time is missing, the applicable time range is registered as pending supplementation, and the candidate tag record remains in a pending verification state and does not participate in the merging of the formal candidate set.

[0066] Candidate states include mergeable, time pending verification, field pending completion, fact pending verification, desensitization pending processing, dictionary mismatch, source conflict pending verification, manual rejection, and invalid archive. Abnormal impacts are not registered as candidate states, but only as additional markers for candidate label records, used for subsequent S3 abnormal impact conflict registration.

[0067] The conditions for the formation of a mergeable state are that the required fields are complete, the event time is complete, the source trust level reaches the lowest source trust level in the tag formation rule table, and the candidate tag value exists in the tag dictionary version. When the event time of the source record corresponding to the candidate tag falls into the abnormal period covered by the device status record, an abnormal impact mark is added to the candidate tag record, and the abnormal impact conflict is registered in S3.

[0068] The conditions for the formation of the time pending verification status are that the event occurrence time, text generation time, or effective time of fact record are missing; the time pending verification status is maintained until the corresponding time field is filled in. After the field is filled in, the applicable time range is re-formed and it enters the mergeable state. If the field is not filled in by the deadline, it enters the invalid archive.

[0069] The condition for a field to be supplemented is that the source record is missing a required field registered in the tag formation rule table; the field to be supplemented status is maintained until the required field is supplemented. After the field is supplemented, the source trust level and tag dictionary version are rechecked. If they are still not satisfied, the record is entered into an invalid archive.

[0070] The condition for forming an anomaly impact marker is that the event time of the source record corresponding to the candidate tag falls within the abnormal period covered by the device status record; candidate tag records with anomaly impact markers can enter S3 to form a candidate set, and S3 registers the anomaly impact conflict status. The anomaly impact marker is maintained until the anomaly resolution record arrives and the corresponding candidate tag is re-verified; if the anomaly is not resolved and the candidate tag exceeds the candidate retention period, the candidate tag record is entered into the invalid archive.

[0071] The conditions for the formation of the "fact pending verification" status are that the fact record contains transaction cancellation, refund, missing status confirmation field, pending source signature, and missing manual review object; the "fact pending verification" status is maintained until the final status confirmation field is completed, the source signature is approved, and the manual review record arrives, after which it enters the mergeable or invalid archive.

[0072] The "dictionary not matched" status occurs when the candidate tag value, text topic category, or business object category is not registered in the current tag dictionary version. When subsequent tag dictionary versions add the corresponding mapping, the candidate tag records are reprocessed according to the new tag dictionary version; otherwise, they are archived as invalid. The "source conflict pending verification" status occurs when the same deduplication field corresponds to multiple inconsistent source records. This status persists until the source system's correction record or manual review record arrives. The "manual rejection" status is formed by the rejection conclusion of the manual review record. Records in this status directly enter the invalid archive and are no longer included in the current profile processing session merging.

[0073] Through the above processing, the candidate tag records generated in S2 have fixed candidate tag numbers, clear source records, clear event timeframes, clear source credibility levels, clear applicable time ranges, clear candidate statuses, additional markers for abnormal impacts, and corresponding deregulation conditions. All candidate tag records entering the mergeable state use the same tag dictionary version, tag bit configuration version, and evidence source configuration version from the same profiling session. Subsequently, S3 can generate candidate sets according to the same profiling object, the same tag bit, and the same applicable time range, and continue to read abnormal impacts, source credibility levels, facts pending verification, and field completeness status to register conflict states.

[0074] S3. Generate a candidate set using the image object number, tag number, and applicable time range as the merge key. Read historical valid tag versions, mutually exclusive tag bits, dependent tag bits, and abnormal time period records, and register the conflict status of the candidate set. The specific implementation is as follows: After candidate tag records meet the merging check criteria, the following information is first read from each candidate tag record: profile processing session number, profile object number, tag bit number, candidate tag number, candidate tag value, source trust level, event time, applicable time range, and candidate status. The candidate set receives candidate tag records with a merging status, as well as candidate tag records with anomaly impact markers whose required fields, event time, source trust level, and tag dictionary version meet the merging criteria. Candidate tag records with statuses such as time pending verification, field pending completion, fact pending verification, dictionary mismatch, source conflict pending verification, and invalid archive are not included in the current candidate set.

[0075] The portrait object number, tag number, and applicable time range are arranged in a fixed order to form a merge key. The portrait object number is used to limit the candidate set to belong to only the same portrait object, the tag number is used to limit the candidate set to process only the candidate tags under the same tag, and the applicable time range is used to limit the effective time boundary corresponding to the candidate tag.

[0076] Candidate tag records with completely identical applicable time ranges are included in the same candidate set. When the applicable time ranges overlap but the start and end times are different, the time segmentation granularity in the tag configuration version is read, the overlapping range is split into a unified time period, and then the candidate tag records are respectively assigned to the candidate sets under the corresponding unified time period.

[0077] The granularity of time segmentation is configured by the tag version registration. Static fact tags are segmented according to the effective and expiration times of fact records. Behavioral statistics tags are segmented according to the data reception time range of the profile processing session. Preference inference tags are segmented according to the session range corresponding to the tag's stable period. Scenario-specific tags are segmented according to the session start and end times. The segmented candidate tag records retain their original applicable time ranges while also registering the segmented applicable time ranges. Subsequent candidate sets will be assigned to and use the segmented applicable time ranges. Candidate tag records with missing applicable time ranges will remain in a time-pending status and will not generate candidate set numbers.

[0078] The candidate set number is formed in a fixed order: image processing session number, image object number, tag number, start point of the applicable time range after segmentation, end point of the applicable time range after segmentation, and set serial number. After the candidate set is generated, the following are recorded: candidate set number, image processing session number, image object number, tag number, applicable time range, candidate tag number list, candidate tag value list, source record number list, source trust level list, forming agent number list, and candidate set status.

[0079] The candidate set is initially registered as a pending conflict identification state. If the candidate label number list is empty, the candidate set is not generated; if there are duplicate candidate labels formed by the same source record number in the candidate label number list, only the candidate label number formed the first time is retained, and the remaining candidate label numbers are registered as duplicate candidates for archiving.

[0080] After the candidate set is generated, the historical tag version records corresponding to the same portrait object and the same tag position are read. The selection rules for historical valid tag versions are: the tag version status is valid, it has not been canceled, it has not been rolled back, it has not expired, it has not been affected by evidence withdrawal, and its applicable time range overlaps with the applicable time range of the current candidate set, or it was most recently effective before the start of the applicable time range of the current candidate set.

[0081] If multiple historical valid tag versions exist that meet the criteria, the version whose applicable time range overlaps with the current candidate set will be selected first; if multiple versions still exist, the version with the latest effective time will be selected; if the effective times are the same, the version with the later tag version number will be selected.

[0082] If no valid historical tag version meets the conditions, the candidate set is registered as having no historical version and enters the initial validity verification. The initial validity verification means that no replacement comparison with the historical valid tag value is performed; only the tag dictionary value range, mutual exclusion relationship, dependency relationship, source trust level, and abnormal period are verified.

[0083] Then, the list of single-value attributes, multi-value attributes, capacity limits, and mutually exclusive tags in the tag configuration version is read. A single-value attribute means that only one valid tag value is allowed for the same profile object, the same tag, and the same applicable time range; a multi-value attribute means that multiple tag values ​​are allowed to coexist within the same applicable time range. When the candidate set corresponds to a single-value tag, and there are more than two different candidate tag values ​​in the candidate tag value list, a single-value conflict status is registered.

[0084] When a candidate set corresponds to a multi-valued label, and the number of different candidate label values ​​exceeds the capacity limit registered for the label configuration version, a multi-value capacity conflict status is registered. The mutually exclusive label list registers the mutually exclusive label number, mutually exclusive label value, mutually exclusive effective scope, and mutually exclusive release conditions. When a candidate label value in the candidate set satisfies a mutually exclusive relationship with the valid label version of other labels for the same profile object within the same applicable time frame, a mutually exclusive conflict status is registered. The mutually exclusive conflict status record includes the candidate label number, mutually exclusive label number, mutually exclusive label version number, and mutually exclusive relationship number involved.

[0085] Then, the dependency tag bits in the tag dependency configuration version are read. The tag dependency configuration version records at least the current tag bit number, the upstream tag bit number, the dependency type, the valid scope of the dependency, the dependency missing handling method, and the dependency conflict handling method. If the current candidate tag depends on the upstream tag bit, and the upstream tag bit does not have a valid tag version, the dependency missing status is recorded.

[0086] If a valid label version exists in the upstream label position, but this version is in a state of observation pending verification, pending rollback, expired, or affected by evidence withdrawal, the registration dependency is unstable. The directional relationship between the upstream label value and the current candidate label value is defined by the label value directional relationship table in the label dictionary version; the label value directional relationship table registers positive, negative, and neutral relationships within the same label system.

[0087] When an upstream label value and a current candidate label value are registered as having an inverse relationship in the label value direction relationship table, a dependency conflict state is registered. If an inverse relationship is not registered in the label value direction relationship table, it is not processed as an inverse relationship to avoid incorrect registration of conflict states due to differences in human interpretation.

[0088] Then read the device status record and the source anomaly record. The anomaly period is defined by the start time of the anomaly but not by the end time; if the end time of the anomaly is missing, the arrival time of the anomaly resolution record is used as the temporary end boundary. If the event time of the candidate tag record falls within the anomaly period, and the source system number and behavior type belong to the affected source system and affected behavior type in the anomaly record, respectively, register the anomaly impact conflict status.

[0089] If an anomaly record has been cleared but the stable observation range registered in the tag configuration version has not yet been reached, the anomaly impact conflict state continues. The stable observation range is registered in the tag configuration version and can use one of the following fixed criteria: the number of profile processing sessions, the natural time length, and the number of consecutive mergeable candidates. The current profile processing session can only use the fixed criteria already registered in the tag configuration version and will not be temporarily changed during processing. When the anomaly impact conflict state is cleared, it is necessary to simultaneously satisfy the following conditions: the anomaly clearing record has arrived, and no similar anomaly impact record has reappeared within the stable observation range.

[0090] For candidate sets whose source credibility level is lower than the lowest effective level in the label configuration version, and whose candidate label values ​​are registered as having an inverse relationship with the label values ​​of historical effective label versions in the label value direction relationship table, a weak evidence conflict state is registered. If the source credibility level reaches the lowest effective level but the evidence record lacks required fields, a weak evidence conflict state is not registered; instead, the field is kept in the pending state and the process is returned to S2.

[0091] For a candidate set whose candidate label value is the same as the label value of the historical valid label version, the replacement conflict state is not registered, but the evidence supplement state is registered. The evidence supplement state records the new candidate label number, the new source record number and the historical valid label version number, which are subsequently used in S4 to supplement the evidence record of the historical valid label version.

[0092] A candidate set can have multiple conflict states simultaneously. Conflict states are written into the conflict state list in the following order: single-value conflict, multi-value capacity conflict, mutual exclusion conflict, missing dependency, unstable dependency, dependency conflict, anomaly impact conflict, weak evidence conflict, and evidence supplementation state. Each conflict state is recorded with the conflict state number, the basis for its formation, the candidate tag number involved, the historical version number involved, the mutual exclusion tag number involved, the dependency tag number involved, the anomaly record number involved, the registration time, the maintenance conditions, and the release conditions.

[0093] The single-value conflict state is maintained until only one candidate label value is retained in the candidate set that can enter the pending path; the multi-value capacity conflict state is maintained until the number of candidate label values ​​does not exceed the capacity limit; the mutual exclusion conflict state is maintained until the mutual exclusion label version becomes invalid, is rolled back, is canceled, or the candidate label enters the isolation path; the dependency missing state is maintained until the upstream label bit forms a valid label version; the dependency unstable state is maintained until the upstream label bit is restored to a valid state; the dependency conflict state is maintained until the upstream label version is updated, the current candidate label expires, or the manual review record confirms the processing path; the anomaly impact conflict state is maintained until the anomaly resolution record arrives and meets the stable observation range; the weak evidence conflict state is maintained until high-credibility evidence is supplemented, continuous stable candidate records meet the stability conditions in the label bit configuration version, or the candidate label expires; the evidence supplementation state is lifted after the evidence supplementation registration is completed in S4.

[0094] If subsequent events occur such as upstream tag completion, abnormal removal, candidate tag expiration, arrival of manual review records, version rollback of mutually exclusive tags, or withdrawal of source evidence, the conflict status will not be directly deleted. Instead, a removal record or change record will be added to the conflict status list. The removal record must at least register the reason for removal, the record number on which the removal was based, the time of removal, and the processing status after removal.

[0095] The conflict formation, maintenance, and resolution processes of the candidate set are all kept under the same candidate set number. At the end of S3, the candidate set has historical valid label versions, label value direction relationships, mutual exclusion relationships, dependency relationships, anomaly impact relationships, source trust level relationships, and conflict status lists that can be read by S4. When S4 forms the label version record based on this, it does not need to re-determine the basic boundary and conflict source of the candidate set.

[0096] S4. Based on the conflict status, source trust level, event timeliness, historical valid tag versions, and tag dependencies, determine the version status, replacement relationship, write level, and rollback target of the tag version record to form the tag version record. The specific implementation is as follows: After S3 completes the registration of conflict states of the candidate set, it first reads the candidate set number, the portrait processing session number, the portrait object number, the tag bit number, the candidate tag value list, the candidate tag number list, the source trust level list, the event time list, the applicable time range, the conflict state list, the historical valid tag version, the tag dictionary version, the tag bit configuration version, the evidence source configuration version, and the tag dependency configuration version.

[0097] Before the candidate set enters S4, the candidate set status should be "conflict identification completed"; if the candidate set status is still "conflict identification pending", "time pending verification", "field pending supplementation", or "source conflict pending verification", no tag version record will be formed.

[0098] The event duration is determined based on the event time, event reception time, applicable time range, tag validity period, field completion deadline, and late arrival allowance time in the evidence source configuration version of the candidate tag record. The event duration includes at least the following states: duration valid, late arrival available, candidate tag expired, completion deadline expired, and duration not met. Among them, candidate tag expired indicates that the candidate tag has exceeded the tag validity period, candidate tag retention period, or applicable deadline; completion deadline expired indicates that the required fields, event time, or source trust level field have not been completed after the field completion deadline has expired; duration not met indicates other duration blocking states that do not belong to duration valid, late arrival available, or cannot be classified as candidate tag expired or completion deadline expired.

[0099] If the event time falls within the processing range allowed by the current profile processing session and does not exceed the tag validity period registered in the tag configuration version, the event validity period is registered as valid. If the event occurrence time is earlier than the current profile processing session and the event reception time falls within the current profile processing session, and does not exceed the late arrival allowance, the event validity period is registered as late arrival available. If the event occurrence time exceeds the tag validity period, candidate tag retention period, or applicable deadline, the event validity period is registered as candidate tag expired. If the event time is missing, a required field is missing, or the source trust level field is missing, and the field is not filled in by the field completion deadline, the event validity period is registered as completion deadline expired. If the late arrival time exceeds the late arrival allowance but does not fall under candidate tag expiration or completion deadline expired, the event validity period is registered as validity period not met.

[0100] Candidate tag records whose event timeliness is expired, whose rewrite deadline has expired, or whose timeliness is not met shall not be formed into tag versions awaiting activation. Among them, candidate tag records whose candidate tags have expired shall enter the invalid archive processing path, and candidate tag records whose rewrite deadline has expired shall enter the invalid archive processing path. In other cases where the timeliness is not met, if there is a source that can be supplemented for the event time and the deadline for supplementing the fields has not expired, the time pending verification processing path shall be returned. Except for the above situations, the records shall enter the invalid archive processing path.

[0101] The processing path is formed according to the priority order of the blocking status list, event validity status, and conflict status list. If the blocking status list contains a withdrawn source record, a tag value that is not within the allowed range of the tag dictionary version, or a manually rejected status, or if the event validity status is that the candidate tag has expired, the rewrite deadline has expired, or the validity period has not been met, the invalid archive processing path will be prioritized.

[0102] When single-value conflicts, mutual exclusion conflicts, and dependency conflicts exist in the conflict state list, the system enters the conflict isolation handling path. When missing dependencies and unstable dependencies exist in the conflict state list, the system enters the dependency completion handling path. When an exception affects a conflict state in the conflict state list, the system enters the exception delay handling path.

[0103] If weak evidence of conflict exists in the conflict status list, and the candidate label value and the label value in the historical valid label version are registered as having an inverse relationship in the label value direction relationship table, the system enters the observation and verification processing path. If the conflict status list does not have the above-mentioned blocking status, the candidate label value is within the allowed value range of the label dictionary version, the source trust level reaches the minimum effective level registered in the label bit configuration version, and the event validity period is valid or late available, the system enters the pending effectiveness processing path.

[0104] The version status of the tag version record is formed based on the processing path. If it enters the pending-to-be-effective processing path, the version status is registered as pending-to-be-effective; if it enters the observation-pending-to-be-reviewed processing path, the version status is registered as observation-pending-to-be-reviewed; if it enters the conflict isolation processing path, the version status is registered as conflict isolation; if it enters the dependency completion processing path, the version status is registered as dependency completion; if it enters the exception delay processing path, the version status is registered as exception delay; if it enters the invalid archive processing path, the version status is registered as invalid archive.

[0105] The replacement relationship is formed based on the same portrait object number, the same tag number, and historical valid tag versions with overlapping time periods. When the applicable time range of the candidate tag version completely covers the applicable time range of the historical valid tag version, the replacement relationship is registered as full-segment replacement; when the applicable time range of the candidate tag version only covers a part of the time period in the historical valid tag version, the replacement relationship is registered as segmented replacement, and a retained segment and a replacement segment are formed according to the time segmentation granularity of the tag configuration version registration; when the candidate tag version is only used to supplement the applicable time range not covered by the historical valid tag version, the replacement relationship is registered as new supplement; when the candidate tag version cannot replace the historical valid tag version due to conflict status, abnormal influence status, or weak evidence status, the replacement relationship is registered as no replacement.

[0106] The write hierarchy is formed based on the write hierarchy list. The write hierarchy of a tag version to be effective must at least register the tag wide table, profile index, real-time cache, and call record index; tag versions under observation, pending core testing, conflict isolation, dependency completion, abnormal delay, and invalid archive status are not registered as formal write hierarchies, but only the corresponding record areas in the candidate record area, isolated record area, pending core testing record area, and archive record area are registered.

[0107] The rollback target is formed based on the same profile object number, the same tag bit number, and the most recent valid tag version within the same applicable time range. The most recent valid tag version is the tag version that has completed the write switch of the tag wide table, profile index, real-time cache, and call record index, has a valid version status, and has not been hit by evidence withdrawal records, conflict unresolved records, canceled version records, or invalid records. In non-first-time effective scenarios, if there is no most recent valid tag version, the rollback target is registered as empty, and the tag version record is registered as having no valid version pending verification; in the state of having no valid version pending verification, the S5 formal write switch is not initiated. In the first-time effective scenario, if there is no rollback target, it is handled according to the rules for no rollback target in the first-time effective scenario.

[0108] When the candidate set meets multiple processing path conditions, a unique processing path is determined in the order of invalid archive, conflict isolation, dependency completion, exception delay, observation pending verification, and pending activation, and the unused processing path and corresponding reason are registered in the tag version record.

[0109] The pending-effectiveness processing path is used when the candidate set has passed the conflict status verification. Upon entering the pending-effectiveness processing path, a pending-effectiveness tag version record is created, and the version status is registered as pending effectiveness, awaiting subsequent write switching by S5. The observation pending-verification processing path is used when candidate tag evidence is insufficient but still needs to be retained for observation.

[0110] When entering the observation and processing path, an observation tag version record is created, and the version status is registered as "observation pending verification." The observation tag version does not replace the historical valid tag version and does not enter the real-time cache formal reading level. The conflict isolation processing path is used when there are unresolved conflicts in the candidate set.

[0111] When entering the conflict isolation processing path, a conflict isolation version record is created, and the version status is registered as conflict isolation. The candidate tag record remains in the candidate state until single-value conflicts, mutual exclusion conflicts, and dependency conflicts are resolved. The dependency completion processing path is used when upstream tag bits are missing or upstream tag versions are unstable.

[0112] When entering the dependency completion processing path, a dependency completion version record is created, registering the dependency tag number, dependency version requirements, dependency completion deadline, and re-verification conditions after completion. The exception delay processing path is used for situations where candidate tags are affected by device anomalies, source anomalies, or reissue anomalies.

[0113] When entering the abnormal delay processing path, an abnormal delay version record is created, registering the abnormal record number, abnormal resolution conditions, stable observation range, and trigger conditions for re-entering the candidate set. The invalid archive processing path is used when candidate tags lack the basis for subsequent processing. When entering the invalid archive processing path, an invalid archive record is created, registering the reason for invalidity, the candidate tag numbers involved, and the archive time; no writable tag version is created.

[0114] Tag version numbers are generated in a fixed order: portrait processing session number, portrait object number, tag bit number, candidate set number, and version serial number. A tag version record must at least register the tag version number, portrait processing session number, portrait object number, tag bit number, candidate set number, candidate tag value, candidate tag level, list of source candidate tag numbers, list of evidence record numbers, list of source trust levels, event validity status, conflict status list, processing path, historical valid tag version numbers, replacement relationship, applicable start time, applicable end time, write level, version status, rollback target, and version generation time.

[0115] The source candidate label number list comes from the S3 candidate set, the evidence record number list comes from the source record number in the candidate label record and its corresponding evidence record, and the conflict state list remains consistent with the S3 registration content and does not regenerate new conflict state names in S4.

[0116] Replacement relationships are formed based on the tag type, historical valid tag version, and processing path. For single-value tags, if a historical valid tag version exists and the current processing path is pending activation, the replacement relationship is registered as replacing the historical valid tag version. For single-value tags, if no historical valid tag version exists and the current processing path is pending activation, the replacement relationship is registered as initial activation. For multi-value tags, if the candidate tag value and the current valid tag value are not mutually exclusive and the capacity limit is not exceeded, the replacement relationship is registered as appending a valid tag value. For multi-value tags, if the same candidate tag value already has a valid version, the replacement relationship is registered as supplementary evidence, without creating a duplicate valid version. Under the observation pending verification, conflict isolation, dependency completion, and abnormal delay processing paths, the replacement relationship is registered as not replacing the historical version. Replacement relationships are not registered under invalid archive processing paths.

[0117] The applicable start time is determined according to the tag type and event validity period. For static fact tags, the applicable start time is the effective time of the fact record; for behavioral statistics tags, the applicable start time is the data reception deadline of the profile processing session; for preference inference tags, the applicable start time is the deadline of the profile processing session that meets the stability period requirements in the tag configuration version; for scenario-based temporary tags, the applicable start time is the session start time; and for risk warning tags, the applicable start time is the effective time of the risk event.

[0118] When an event's validity period is "lately available," the applicable start time still uses the tag rule corresponding to the original event time, and is not replaced by the event reception time. The applicable expiration time is formed according to the expiration conditions in the tag configuration version; if a factual record expiration time exists, it is registered according to the factual record expiration time; if controlled by validity period, it is registered according to the tag's validity period expiration time; if controlled by dependency release conditions, the dependency release condition number is registered; the temporary tag for the scenario uses the session end time as the applicable expiration time; if the session end time is missing, it is registered as a session pending end state and does not enter the formal write switch.

[0119] The write hierarchy is read from the write hierarchy list in the profile processing session and limited according to the processing path. The write hierarchy for versions with tags to be activated is the tag wide table, profile index, real-time cache, and call record index; the write hierarchy for versions with observed tags is the tag wide table observation area and the call record index observation area, and they do not enter the profile index's formal queryable area or the real-time cache's formal read area; conflict isolation versions, dependency completion versions, and abnormal delayed versions are only written to the candidate record area and version governance record area, and do not enter the formal call hierarchy; invalid archive records are only written to the archive record area.

[0120] If any of the formal levels in the label wide table, profile index, real-time cache, and call record index are missing from the write level list, the label version to be effective will be registered as a write level pending status and will not enter the S5 write switch.

[0121] The rollback target is selected from historical tag versions of the same profile object and the same tag position. The rollback target must meet the following conditions simultaneously: the version status is valid, consistency verification of the tag wide table, profile index, real-time cache and call record index has been completed, it has not been canceled, rolled back, expired, is not in the observation pending verification state, is not in the writing state, is not in the configuration termination state, is not affected by evidence withdrawal, and the applicable time range can cover the recovery scope after the current candidate tag version is canceled.

[0122] If multiple versions meet the criteria, the version with the latest effective time will be selected; if the effective times are the same, the version with the later tag version number will be selected. If there is no rollback target that meets the criteria for the current tag, the tag version record will be registered as "no valid version pending approval", the rollback target field will be registered as "empty value pending approval", and this tag version will not be allowed to enter the formal write switch.

[0123] If there is no rollback target in the first effective scenario, and the candidate set is not in a conflict state and the source trust level reaches the minimum effective level, it can be registered as the first effective without rollback target. This state is only allowed to enter the first write and does not allow the restoration of historical versions when canceled later. After cancellation, the tag enters the state of no valid version pending verification.

[0124] Each processing path has maintenance and release conditions. The processing path awaiting effect will remain in effect until the S5 write pre-verification passes and the write switch is initiated. If evidence withdrawal, new conflict status, or changes in the version of historical valid tags are found before the write, the pending effect will be terminated and the path will return to S3 to re-register the conflict status.

[0125] The pending processing path is maintained until supplementary high-credibility evidence is provided, continuous and stable candidate records meet the stability conditions in the label configuration version, candidate labels expire, or records are manually reviewed. When supplementary high-credibility evidence and stability conditions are met, the pending effectiveness judgment is re-entered. When a candidate expires, it enters invalid archiving.

[0126] The conflict isolation process remains in place until single-value conflicts, mutual exclusion conflicts, and dependency conflicts are resolved. After resolution, it returns to S3 to update the conflict status list, and then enters S4 to redetermine the processing path. The dependency completion process remains in place until the upstream label bit forms a valid tagged version or the completion deadline expires. When the upstream label bit forms a valid tagged version, it returns to S3 to re-register the dependency status. When the completion deadline expires, it enters the invalid archive.

[0127] The abnormal delay handling path continues until the abnormal resolution record arrives and meets the stable observation range; after meeting the range, it returns to S3 to re-register the abnormal impact status, and enters invalid archiving when the candidate tag exceeds the retention period. The invalid archiving handling path is a terminated path and will not enter S5 write switch.

[0128] The tag version record generated by S4 connects the candidate set, conflict status, source trust level, event timeliness, historical valid tag versions, tag dependencies, replacement relationships, write level, and rollback target into the same version chain. When S5 performs tag version write switching, it directly reads the version status, write level, and rollback target from the tag version record, without temporarily judging whether the candidate tag should replace the historical version, thus ensuring that the processing approach for candidate tags remains consistent from conflict arbitration to write switching.

[0129] S5. Switch tag versions in the order of tag wide table, profile index, real-time cache, and call record index. If any of the following states occur—missing write level, evidence withdrawal, unresolved conflict, changes to historically valid tag versions, or invalid applicable time range—and the rollback target is valid, restore the valid tag version corresponding to the rollback target. Specifically, this is implemented as follows: First, read the tag version record generated by S4. The tag version record has at least the tag version number, the portrait processing session number, the portrait object number, the tag bit number, the tag value, the version status, the writing level, the replacement relationship, the applicable start time, the applicable end time, the candidate set number, the evidence record number list, the historical valid tag version number, and the rollback target.

[0130] When the version status is "Pending Activation," and the write level simultaneously registers the tag wide table, profile index, real-time cache, and call record index, and the rollback target registered in the tag version record meets the S4 validity conditions, the replacement write switching process begins. If the tag version record is registered as being activated for the first time without a rollback target, the initial write process begins when there are no conflicts in the candidate set and the source trust level reaches the minimum activation level. The initial write process does not perform historical version recovery. When the version status is "Observation Pending Core," "Conflict Isolation," "Dependency Completion," "Abnormal Delay," "Invalid Archive," "Write Pre-Blocking," "Pending Rollback," or "No Valid Version Pending Core," the formal write switching process does not begin.

[0131] Before the write switch begins, a pre-write check is performed. The pre-write check reads the tag version number, candidate set number, conflict status list, evidence record number list, historical valid tag version number, and rollback target.

[0132] The tag version number was not registered as a canceled version, and all single-value conflicts, mutual exclusion conflicts, dependency conflicts, anomaly impact conflicts, and weak evidence conflicts in the candidate set have resolution records. The evidence in the evidence record number list has not been withdrawn. In the replacement write switching process, when the historical valid tag version is still the current valid version of the same tag position for the same profile object and the rollback target is still in a valid state, the pre-write verification passes. In the first write process, when the tag version record is registered as the first effective version without a rollback target, and the candidate set has no conflict state and the source trust level reaches the minimum effective level, the pre-write verification passes.

[0133] If any verification item is not met, the tag version record is registered as a pre-write blocking state, and the blocking reason, blocking basis record number, and blocking time are recorded in the blocking record. The blocking reasons may include evidence withdrawal, unresolved conflict, changes in historical versions, failure of the rollback target, missing write level, and failure of the applicable time range. The pre-write blocking state is maintained until the blocking reason is resolved. After the blocking reason is resolved, the process returns to S4 to re-form the processing path. If the blocking reason cannot be resolved and the candidate tag exceeds the retention period, it will be entered into invalid archive.

[0134] When any of the following conditions occur: missing write level, evidence withdrawal, unresolved conflict, change of historical valid tag version, invalid rollback target, or invalid applicable time range, the system will first stop writing the current tag version to the formal call level and generate a rollback trigger record. The rollback trigger record shall at least register the tag version number, profile object number, tag bit number, applicable time range, trigger status, trigger basis record number, trigger time, and processing device identifier.

[0135] Missing write level means that the tag version record does not simultaneously register the tag wide table, portrait index, real-time cache, and call record index, or any level in the write level list does not return a writeable status; evidence withdrawal means that the source record in the evidence record number list is withdrawn by the source system, the manual review record is revoked, or the source signature verification fails; conflict status not resolved means that there are still no resolution records for single-value conflicts, mutual exclusion conflicts, dependency conflicts, abnormal impact conflicts, and weak evidence conflicts in the candidate set; changes in historical valid tag versions mean that after S4 generates the tag version record, the current valid tag version number of the same portrait object number, the same tag bit number, and the same applicable time range is different from the historical valid tag version number registered in the tag version record; rollback target invalid means that the tag version corresponding to the rollback target has been registered as a canceled version, invalid version, or evidence withdrawal version; applicable time range invalid means that the current processing time has exceeded the applicable deadline in the tag version record, and the deadline for rewriting the tag bit configuration version registration has expired.

[0136] During rollback execution, the system first restores the real-time cache read pointer to the valid tag version corresponding to the rollback target. After the real-time cache is restored, the index record corresponding to the current tag version number in the profile index waiting-to-be-switched area is registered as canceled. After the profile index is canceled, the record corresponding to the current tag version in the tag wide table waiting-to-be-effective area is registered as canceled and awaiting cleanup. Finally, a rollback completion record is written to the call record index. The rollback completion record must at least register the rolled-back tag version number, the rollback target tag version number, the rollback reason, the rollback completion time, the callable time after restoration, and the current version status.

[0137] If the rollback target is empty or expires before the rollback is executed, the system will not write the current tag version into the formal call level, but will register the corresponding profile object number and tag bit number as a pending status with no valid version. In the pending status with no valid version, downstream calls will only continue to read the most recent valid tag version that was registered with the call record index before the rollback. This most recent valid tag version should be a valid version of the same profile object, the same tag bit, and its applicable time range should still cover the current call time. If there is no most recent valid tag version that meets the above conditions, the downstream call will return a status indicating that the tag bit has no valid tag, and record the reason for the missing call. It will not replace the valid tag version with the currently pending tag version, the canceled tag version, or the tag version that has not completed consistency verification.

[0138] The rolled-back tag version is registered as a cancelled version. Cancelled versions retain the candidate set number, evidence record number list, conflict status list, pre-write verification record, rollback trigger record, and rollback completion record, but cannot be used as the basis for subsequent historical valid tag versions, rollback targets, mutual exclusion relationship judgments, or downstream calls.

[0139] After the pre-write validation passes, the tag version record is registered as being in a "writing in progress" state. This state indicates that the new tag version has entered the multi-level writing process, but the unified switchover has not yet been completed. While in this state, downstream calls still read the valid tag version from before the switchover and do not read the new tag version.

[0140] The write-in-progress state is maintained until the tag wide table, profile index, real-time cache, and call record index complete their corresponding registration and pass consistency verification; if any write level encounters an exception, the write-in-progress state is changed to the write-exception state, and undo, retry, or rollback is performed according to the exception level.

[0141] When writing to the wide tag table, the new tag version is first written to the tag wide table's pending-approval area. The tag wide table's pending-approval area must at least register the tag version number, image object number, tag position number, tag value, applicable start time, applicable end time, replacement relationship, historical valid tag version number, rollback target, and writing batch.

[0142] After the tag wide table's pending-effectiveness area is written, the new tag version does not immediately become a valid tag version; instead, a wide table pending-switch record is generated. This pending-switch record remains in this state until the portrait index's pending-switch area is written. If the tag wide table's pending-effectiveness area write fails, the tag version record is registered as having a wide table write failure status. The portrait index, real-time cache, and call record index do not execute new version writing; the real-time cache continues to point to the valid tag version corresponding to the rollback target, and the tag version record returns a write exception status.

[0143] When writing the portrait index, the records to be switched in the wide table are read, and the version number of the same tag is written to the portrait index's switching area. The portrait index's switching area must at least register the portrait object number, tag bit number, tag value, tag version number, applicable time range, and switching status. After the portrait index's switching area is written, the new tag version is not yet available for querying; the real-time cache continues to read the valid tag version before the switch.

[0144] If the portrait index fails to write to the area to be switched, the tag version record is registered as an index write failure state, the new tag version in the tag wide table's area to be effective is registered as a write to be revoked, the real-time cache continues to point to the valid tag version corresponding to the rollback target, and the portrait index continues to retain the queryable state of the rollback target version.

[0145] The unified switch is triggered when there are records with the same portrait object, the same tag position, the same applicable time range, and the same tag version number in both the tag wide table waiting to take effect area and the portrait index waiting to be switched area.

[0146] During the unified switch, the wide tag table moves the new tag version from the waiting area to the effective area and registers the replaced historical effective tag version as the replaced historical version; the profile index moves the new tag version from the waiting area to the queryable area and moves the historical effective tag version from the current queryable area to the historical query area; the real-time cache switches the read pointer from the historical effective tag version to the new tag version.

[0147] The real-time cache read pointer must at least register the portrait object number, tag bit number, current tag version number, previous valid tag version number, switch time, and switch status. Before the real-time cache switch is complete, downstream calls will still return the historical valid tag version. If the real-time cache switch fails, the tag version record is registered as a cache pending synchronization state. The tag wide table and portrait index maintain the switched record of the new tag version, but the call record index is registered as a cache pending synchronization state, and this tag version is not used as subsequent stable evidence.

[0148] Call record index registration is performed after the real-time cache switch is complete. The call record index must register at least the profile object number, tag bit number, tag version number, callable time, applicable time range, version status, and call boundaries. After successful call record index registration, the tag version record changes from a writing state to a valid state.

[0149] When a call to the record index registration fails, the tag wide table, the profile index, and the real-time cache maintain the state of the new tag version, and a call record supplementary registration record is generated. The call record supplementary registration record must at least record the tag version number, the reason for supplementary registration, the start time of supplementary registration, the supplementary registration status, and the supplementary registration completion time.

[0150] Before the supplementary registration is completed, the new tag version can be returned for real-time caching, but it cannot be used as evidence for subsequent tag stability assessment; after the supplementary registration is completed, the tag version record is supplementarily registered as evidence of stability.

[0151] After the write operation is complete, a consistency check is performed. The consistency check reads the tag version number from the valid area of ​​the tag wide table, the queryable area of ​​the profile index, the real-time cache read pointer, and the call record index. If the profile object number, tag bit number, applicable time range, and tag version number in these four write levels are all consistent, the tag version record is registered as valid.

[0152] When the effective area of ​​the tag wide table and the queryable area of ​​the portrait index are the same, but the real-time cache read pointer still points to a historical version, register a cache pending synchronization status; when the effective area of ​​the tag wide table and the queryable area of ​​the portrait index are inconsistent, register an index inconsistency status; when the real-time cache has already pointed to the new tag version, but the call record index has not been registered, register a call record pending supplement status. All of the above statuses retain the status formation time, the write level involved, and the recovery processing records.

[0153] When a write-level exception occurs, it is handled according to the exception's occurrence level. If a tag wide table write fails, no profile index record is generated for switching, and the real-time cache read pointer is not changed. If a profile index write fails, the new tag version record in the tag wide table's pending-effectiveness area is revoked, while historically valid tag versions are preserved.

[0154] When real-time cache switching fails, the new tag version in the tag wide table and profile index enters a cache-pending synchronization state. Downstream calls continue to read historically valid tag versions, and register a valid state only after the cache switch succeeds. When call record index registration fails, a call record is generated to supplement the registration, and the new tag version is restricted from being used as stable evidence. The write exception state is maintained until the exception level completes recovery registration; after recovery registration is completed, consistency verification is re-executed. When the exception exceeds the recovery period configured in the write level version, the tag version record enters a rollback-pending state.

[0155] When evidence withdrawal occurs, the evidence number, withdrawal source, withdrawal time, and withdrawal reason are read from the evidence withdrawal record. Candidate tag records and tag version records referencing that evidence number are then searched. If the corresponding tag version has not yet entered a valid state, that tag version is registered as invalid evidence withdrawal and does not enter a write switch. If the corresponding tag version has already entered a valid state, the list of evidence record numbers for that tag version is read.

[0156] If, besides the withdrawn evidence, there is still valid evidence with a source credibility level no lower than the withdrawn evidence that has not been withdrawn, the label version remains valid, the withdrawn evidence is removed from the evidence record number list, and an evidence update record is added. If, besides the withdrawn evidence, there is no valid evidence of the same level, the label version is registered as pending rollback, and the evidence withdrawal record is used as the reason for rollback.

[0157] When a conflict state remains unresolved, read the conflict state records in the candidate set that are still in the single-value conflict, mutual exclusion conflict, dependency conflict, anomaly impact conflict, or weak evidence conflict. When a new tag version has entered the writing state but has not yet completed the unified switch, revoke the new tag version records in the tag wide table's pending-effectiveness area and the profile index's pending-switch area. The real-time cache continues to point to the valid tag version corresponding to the rollback target, and the tag version record is registered as a conflict-unresolved revocation state.

[0158] When a new tag version has been uniformly switched over and registered as valid, the tag version record enters a pending rollback state, and the rollback reason is registered as a conflict state that has not been resolved.

[0159] In the rollback state, the valid tag version corresponding to the rollback target is restored in the order of real-time cache, profile index, tag wide table, and call record index.

[0160] First, switch the real-time cache read pointer to the rollback target version and record the cache rollback time. Then, remove the rolled-back version from the queryable area in the profile index and restore the rollback target version to the queryable area. Next, register the rolled-back version as a canceled version and the rollback target version as a restored valid version in the tag wide table. Finally, register the canceled version number, rollback target version number, rollback reason, restoration time, and affected call scope in the call record index. Cancelled versions cannot be restored to valid versions again; they can only be retained as historical versions. After the rollback is complete, re-execute the consistency verification. When the consistency verification passes, the rollback target version is restored to the current valid tag version.

[0161] If the rollback target does not exist, the tag enters a state of "no valid version pending verification". In this state, the real-time cache does not return the currently pending tag version or the canceled tag version; if there is no most recent valid tag version whose applicable time range still covers the current call time, the real-time cache returns to the pending verification state; the profile index stops using this tag as a formal query filtering condition; the tag wide table retains candidate evidence, canceled version records, and records of "no valid version pending verification"; the call record index registers the start time, triggering reason, and involved tag bits for "no valid version pending verification". The "no valid version pending verification" state persists until a new candidate set forms a new writable tag version through S3 conflict status registration and S4 pending processing path; after the new tag version is written and switched through S5, the "no valid version pending verification" state is lifted.

[0162] Through the above processing, the tag version completes hierarchical switching, unified switching, and consistency verification across the tag wide table, profile index, real-time cache, and call record index using the same tag version number. In the event of any write-level anomaly, evidence withdrawal, or unresolved conflict, the system can restore to a traceable, valid tag version based on the rollback target registered in S4. If the rollback target does not exist, the tag bit is explicitly restricted to a state without a valid version awaiting verification, preventing downstream systems from continuing to call tag versions that have been canceled, withdrawn, or whose consistency verification has not been completed.

[0163] Collaboration is reflected in the entry of candidate records from different sources into the same candidate set, unified conflict state, unified version chain, unified write switching and rollback, rather than simply calling multiple agents in parallel.

[0164] The above processing constrains the consistent switching of multi-source tag data in wide tables, indexes, caches, and call records by using the same profile processing session number, candidate set number, tag version number, and write hierarchy order. This represents an improvement in version consistency and anomaly recovery control during the digital data processing process.

[0165] In a specific application scenario, the portrait processing platform uses a 15-minute timeframe for data reception during a portrait processing session. The current portrait processing session's data reception start time is 10:00:00 on May 8, 2026, and the data reception end time is 10:15:00 on May 8, 2026. The time boundaries are inclusive of the start time but exclusive of the end time. In the evidence source configuration version, the allowed late registration time is 30 minutes, the field completion deadline is 10 minutes after the current portrait processing session ends, and the temporary portrait object retention time is 24 hours. All the above time parameters are derived from the evidence source configuration version referenced in the current portrait processing session and are only used for data reception, field completion, and temporary object retention control in this embodiment; they are not fixed values ​​for other portrait processing sessions.

[0166] In the tag configuration version, the active status tag is a single-value tag, the behavior tag is valid for 7 days, and the stable observation range is 2 consecutive profile processing sessions; the interest preference tag is a multi-value tag, with a maximum of 5 valid interest tags retained within the same applicable time range, the preference tag is valid for 30 days, and the stable period is 3 consecutive profile processing sessions; the consumption intention tag is a single-value tag and depends on the transaction status tag, content interaction tag, and consultation intention tag. In the evidence source configuration version, manually reviewed records and final transaction status records are registered as high-credibility sources, continuous behavior fragments are registered as behavior-credible sources, and single clicks, single searches, and text fragments without manual confirmation are registered as weak evidence sources. The source credibility level adopts a five-level configuration, with level one being the lowest credibility and level five being the highest credibility; the lowest source credibility level for official activation is level three, and the lowest source credibility level for observation pending verification is level two.

[0167] For example, in the current profile processing session, the profile object number U1001 generates a product browsing record at 10:03, a collection record at 10:04, and a purchase record at 10:05. The business object category of all three records is sports equipment, the source system number is APP01, and the event reception time falls within the data reception time range of the current profile processing session.

[0168] After the behavioral evidence agent reads the tags to form a rule table, it forms candidate tags for sports equipment corresponding to the interest preference tag bits. The candidate status is registered as mergeable, the source credibility level is registered as level three, the applicable start time is registered as the data reception deadline of the current profile processing session, and the applicable deadline is registered as the 30th day after that time.

[0169] If the same sports equipment candidate tag is generated for the portrait object in the next two portrait processing sessions, and there are no abnormal impact conflicts, mutual exclusion conflicts, or dependency conflicts, the candidate tag will enter the pending processing path; if the same candidate tag is not generated again in the next two portrait processing sessions, the candidate tag will remain in the observation pending verification state until the candidate retention period expires and then enter the invalid archive.

[0170] For example, the historical valid active status tag for portrait object number U2002 is "high active," and the tag version number is V-ACT-001. Consistency verification has been completed in the tag wide table, portrait index, real-time cache, and call record index. Only one access record has been received in the current portrait processing session, and the device status record shows that there was a network interruption and repeated client reconnection between 10:02 and 10:10.

[0171] If a low-activity candidate tag generated by a behavioral evidence agent falls within an abnormal time period, the candidate tag record will register an anomaly impact marker and enter S3 to form a candidate set. S3 will then record the anomaly impact conflict state based on the device status. Before the anomaly impact conflict state is resolved, the low-activity candidate tag cannot enter the pending processing path. After the anomaly is resolved, if a low-activity candidate tag is still generated within two consecutive profile processing sessions, and the source trust level reaches level three, it will then enter the observation and pending processing path. If subsequent access restores the historical high-activity state, the low-activity candidate tag will be entered into the invalid archive.

[0172] The write recovery period for the hierarchical configuration version is 5 minutes. The tag version to be effective is first written to the tag wide table's pending effective area, and then written to the portrait index's pending switch area; the real-time cache read pointer will only switch to the new tag version when both the tag wide table's pending effective area and the portrait index's pending switch area have the same portrait object number, the same tag bit number, the same applicable time range, and the same tag version number.

[0173] If the portrait index write fails, the new tag version in the tag wide table's pending-effectiveness area is registered as a write to be revoked, and the real-time cache continues to point to the valid tag version corresponding to the rollback target; if the real-time cache switch fails and is not restored after more than 5 minutes, the tag version record enters the pending rollback state, and the valid tag version corresponding to the rollback target is restored in the order of real-time cache, portrait index, tag wide table, and call record index.

[0174] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0175] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented in whole or in part by a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions of the embodiments of this application are implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted wirelessly or wiredly from one website, computer, server, or data center to another website, computer, server, or data center. Wired methods include optical fiber, twisted pair, coaxial cable, etc. Wireless methods include infrared, microwave, etc. Available media include any available media that can be accessed by a computer or data storage devices such as servers and data centers that contain one or more sets of available media. Available media can be magnetic media (floppy disks, hard disks, magnetic tapes), optical media (DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0176] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for dynamically processing user profile tags based on multi-agent collaboration, characterized in that, include: S1. Establish a portrait processing session, register the portrait object number, data reception time range, tag dictionary version, tag bit configuration version, evidence source configuration version, tag dependency configuration version, and write to the hierarchical list; S2. Receive behavior records, text records, fact records and device status records according to the portrait object number, and form candidate tag records with source record number, event time, source trust level, applicable time range and candidate status by different tag processing agents; S3. Generate a candidate set using the portrait object number, tag number, and applicable time range as the merge key. Read historical valid tag versions, mutually exclusive tag bits, dependent tag bits, and abnormal time period records, and register the conflict status of the candidate set. S4. Based on the conflict status, source trust level, event timeliness, historical valid tag versions, and tag dependencies, determine the version status, replacement relationship, writing level, and rollback target of the tag version record to form the tag version record; S5. Switch the tag version in the order of tag wide table, profile index, real-time cache and call record index, and restore the valid tag version corresponding to the rollback target if any of the following states occur: missing write level, evidence withdrawal, conflict state not resolved, change of historical valid tag version, and invalidation of applicable time range.

2. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, Establishing a profile processing session includes: Read the batch number, data reception start time, data reception end time, access system number, and batch verification mark from the data batch registration table; Write data whose event reception time reaches the data reception start time but is earlier than the data reception end time into the current profile processing session; Write data whose event reception time has reached the data reception deadline into the next profile processing session; Data whose event occurred earlier than the start time of data reception for the current portrait processing session, and whose event reception time falls within the current portrait processing session, are registered as late records.

3. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, The registration portrait object number includes: If a platform user ID exists in the source record, the platform user ID will be registered as the profile object ID; When the platform user ID is missing but the login account ID exists, read the binding record in the identity relationship table where the binding start time is no later than the event occurrence time, the unbinding time is not registered, and the binding source status is valid, and register the bound platform user ID as the profile object ID; When the platform user ID is missing but the login account ID exists, read the binding record in the identity relationship table whose binding start time is no later than the event occurrence time, whose unbinding time is later than the event occurrence time, and whose binding source status is valid, and register the bound platform user ID as the profile object ID; When both the platform user ID and login account ID are missing, a temporary profile object ID is generated in a fixed order of device ID, session ID, source system ID, and first event time. When a temporary profile object is subsequently matched with a valid platform user ID, its candidate tag records are transferred to the corresponding profile object ID and re-merged.

4. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, The registered configuration versions include: Read the tag bit number, tag value name, tag value level, and tag value scope from the tag dictionary version; Read the tag type, value range, single-value attribute, multi-value attribute, stability period, expiration condition, and allowed source from the tag configuration version; Read the source trust level, required fields, late arrival allowance, deduplication field and field completion deadline from the evidence source configuration version; Read the upstream tag bit, downstream tag bit, mutual exclusion relationship, dependency missing handling method and dependency conflict handling method in the tag dependency configuration version.

5. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, The candidate label record includes: The behavior records, text records, fact records, and device status records are deduplicated according to the deduplication field of the version registration based on the evidence source configuration. When the deduplication fields are completely identical, retain the source record that first entered the portrait processing session; When the deduplication fields are identical but the field contents differ, a source conflict pending verification record is registered. Candidate tag records are formed when the source record meets the tag bit number, source record type, trigger field, field value range, and minimum source trust level in the tag formation rule table.

6. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, Candidate label records are generated in the following way: Candidate tag numbers are formed in a fixed order of portrait processing session number, portrait object number, tag number, source record number, and candidate serial number; Write the candidate label value, candidate label level, source record type, event time, source trust level, applicable time range, candidate status, and agent number into the candidate label record; The time frame for events is determined based on the type of source record. For behavioral records, the time of event occurrence is used; for text records, the time of text generation is used; for fact records, the time of record effectiveness is used; and for device status records, the time of abnormal start and end and the time of abnormal impact are used, and these are not used as the formal starting point for the applicable time range of candidate tags.

7. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, Registration candidate status includes: When the required fields are complete, the event time is complete, the source trust level reaches the minimum source trust level registered in the tag formation rule table, and the candidate tag value exists in the tag dictionary version and is not restricted by abnormal time periods, it is registered as a mergeable state. When the event time is missing, it is registered as a time pending verification status; When a source record lacks a required field registered in the label formation rule table, it is registered as a field pending completion status; When the event time corresponding to the candidate tag falls within the abnormal period covered by the device status record, an abnormal impact flag is added to the candidate tag record, and the candidate tag record is brought into S3 for abnormal impact conflict registration. When the review conclusion field of the manual review record is registered as rejected, it is registered as a manual rejection status.

8. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, The generated candidate set includes: Read candidate tag records whose candidate status is mergeable, as well as candidate tag records with anomaly impact flags and whose required fields, event time, source trust level, and tag dictionary version meet the merging conditions; Merge keys are formed in a fixed order based on the portrait object number, tag number, and applicable time range; Write candidate label records with completely consistent applicable time ranges into the same candidate set; When the applicable time ranges overlap and the start and end times are inconsistent, the time segmentation granularity of the version registration is configured according to the tag bit and the time segmentation is divided into a unified time period, and a candidate set is generated according to the segmented applicable time range. Candidate set numbers are formed based on the portrait processing session number, portrait object number, tag number, applicable time range start point, applicable time range end point, and set serial number.

9. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, The conflict states of the registered candidate set include: When there are two or more different candidate label values ​​in the candidate set corresponding to a single-value label, register a single-value conflict state. When the number of candidate tag values ​​corresponding to a multi-value tag bit exceeds the capacity limit registered in the tag bit configuration version, a multi-value capacity conflict status is registered. When the candidate tag value and the valid tag version of the mutual exclusion tag bit satisfy the mutual exclusion relationship registered in the tag dependency configuration version, register the mutual exclusion conflict state; If no valid tag version exists in the upstream tag position, register the dependency missing status; When the candidate tag event time falls within an abnormal period covered by the device status record, register the abnormal impact conflict status. When the source credibility level is lower than the lowest effective level registered in the label configuration version, and the candidate label value and the historical effective label value have an inverse relationship in the label value direction relationship table, a weak evidence conflict state is registered.

10. The method for dynamic processing of user profile tags based on multi-agent collaboration according to claim 1, characterized in that, Performing tag version write switching includes: When the tag version record is in a pending state and the hierarchical registration is complete, the tag version will be written to the pending area of ​​the tag wide table. After the tag wide table is written to the area to be activated, write the same tag version number to the image index to be switched area; When the same image object number, the same tag position number, the same applicable time range, and the same tag version number are registered in both the tag wide table waiting to take effect area and the image index waiting to switch area, the real-time cache read pointer will be switched to the new tag version; After the real-time cache switch is completed, the tag version number, callable time, applicable time range, and version status are written into the call record index; If any of the following states occur, such as missing write level, evidence withdrawal, unresolved conflict, changes in historical valid tag version, or invalidation of applicable time range, and the rollback target is valid, the valid tag version corresponding to the rollback target is restored in the order of real-time cache, profile index, tag wide table, and call record index. If the rollback target is empty or invalid, the corresponding profile object number and tag bit number are registered as a state of no valid version pending verification.

Images