A bill sharing system, method and device

Abstract

This application proposes a billing allocation system, method, and device, relating to the field of cloud data processing technology. The system comprises: a first creation module that retrieves bills from a cloud vendor platform and creates a resource list; an extraction module that extracts key fields from the resource list; a cleaning module that segments and cleans the key fields to obtain billing keywords and tags; a prediction module that uses a large language model to perform semantic recognition and prediction on the billing keywords and tags; a matching and identification module that searches for matching keywords in the resource list and identifies the matching resources; and a second creation module that generates a billing allocation scheme based on the resource identification results and creates billing rules based on the scheme. This system uses data processing, feature extraction, semantic recognition, and rule creation modules to find and standardize billing keywords, generate billing schemes and corresponding billing rules, and quickly allocate resource costs in the bill across multiple dimensions using these rules.

Description

Technical Field

[0001] This application relates to the field of cloud data processing technology, and in particular to a billing sharing system, method and device. Background Technology

[0002] As enterprises increasingly migrate to the cloud, the continuous rise in cloud costs has created a demand for cost reduction and efficiency improvement. To reduce cloud costs, it's crucial to first understand where these costs are incurred. Therefore, enterprises need to allocate cloud costs, especially through multi-dimensional allocation, analyzing the composition of cloud costs from different perspectives. Currently, enterprises primarily allocate cloud costs manually or use rule-based automated tools. While rule-based automated tools can improve allocation efficiency, they rely on manual review of the allocation rules. This is particularly problematic for enterprises with previously non-standard billing and allocation labeling, where there are instances of missing or inconsistent labeling. This poses significant difficulties for manual rule review, impacting the accuracy and efficiency of allocation. Summary of the Invention

[0003] This application provides a bill sharing system, method, and apparatus to solve the aforementioned problems of existing methods.

[0004] In a first aspect, embodiments of this application propose an apportionment billing system, the system comprising:

[0005] The first creation module is used to obtain billing information from the cloud vendor's platform and create a resource inventory.

[0006] The extraction module is used to extract key fields for revenue sharing from the resource list. The key fields for revenue sharing include: resource name, resource group / project, subscription, and resource tag.

[0007] The cleaning module is used to segment and clean the key fields used for revenue sharing to obtain revenue sharing keywords and tag information.

[0008] The prediction module is used to perform semantic recognition on the revenue sharing keywords and the tag information through a large language model, and to predict the revenue sharing dimensions corresponding to the revenue sharing keywords and the keywords of the corresponding dimensions. The revenue sharing dimensions include organization, application, environment, component and personnel.

[0009] The matching and identification module is used to find keywords that match the corresponding keywords in the resource list when the user client confirms the revenue sharing dimension and the corresponding keywords output by the large language model, and to identify the matching resources in the resource list.

[0010] The second creation module is used to obtain a revenue sharing scheme based on the resource identification results, and to create revenue sharing rules based on the revenue sharing scheme. The revenue sharing rules are used to find keywords from key fields and allocate them to the objects corresponding to the keywords.

[0011] Optionally, the cleaning module includes:

[0012] The conversion submodule is used to convert all key fields used for revenue sharing to lowercase representation.

[0013] The first segmentation module is used to segment the key fields of resource name, resource group / project and subscription using the first segmenter to obtain multiple first segmentation fields;

[0014] The second segmentation module is used to segment the tag into multiple tag key-value pairs according to the second segmenter, thereby obtaining multiple second segmentation fields and tag information. In a tag key-value pair, the same tag key corresponds to multiple tag values.

[0015] The identification and cleaning submodule is used to identify invalid information in multiple first and second segmentation fields using the Naive Bayes algorithm, and clean the invalid information to obtain the revenue sharing keywords.

[0016] Optionally, the identification and cleaning submodule includes:

[0017] The feature extraction unit is used to extract features from the first segmentation field and the second segmentation field, and construct a feature vector;

[0018] The first computational unit is used to calculate prior probabilities and conditional probabilities based on statistical information in the pre-training data;

[0019] The second calculation unit is used to calculate the posterior probability that the first segmentation field or the second segmentation field belongs to the first category and the second category, respectively, based on the prior probability and the conditional probability.

[0020] The prediction determination unit is used to take the category corresponding to the maximum posterior probability as the prediction result of the first segmentation field or the second segmentation field, and to determine the key field whose prediction result is the second category as invalid information.

[0021] Optionally, the matching identifier module includes:

[0022] The coverage calculation submodule is used to calculate the coverage of the keywords in the corresponding dimension in the resource list field;

[0023] The matching submodule is used to search for target keywords in the resource list that match the keywords of the corresponding dimension based on the coverage rate;

[0024] The identification submodule is used to identify the target keyword and then identify the resource where the target keyword is located. The identification content is the revenue sharing dimension: revenue sharing keyword.

[0025] Optionally, the first creation module includes:

[0026] The bill retrieval submodule is used to retrieve users' historical bills from different cloud vendor platforms, with the historical bills being daily in granularity.

[0027] The standardization processing submodule is used to standardize the historical bills from different cloud vendors, obtain the original bills, and store them.

[0028] The aggregation submodule is used to aggregate the original bill based on the resource ID to generate a resource list. The resource list includes the following fields: resource ID, resource name, resource group / project, subscription, product name, resource tag, and amount payable.

[0029] Optionally, the creation module includes:

[0030] The revenue sharing submodule is used to generate a revenue sharing scheme based on the resource identification result and present the revenue sharing scheme to the user client.

[0031] A submodule is created to create revenue sharing rules according to the revenue sharing scheme after the user client confirms the revenue sharing scheme. The revenue sharing rules are used to persistently store the rules for keyword search.

[0032] Optionally, the system further includes:

[0033] The single-dimensional scoring calculation module is used to calculate the indicator score for each dimension and the comprehensive indicator score for each dimension. The comprehensive indicator score for each dimension is used to characterize the degree of standardization of the identifier under each dimension. The indicators include consistency, repeatability, correctness and coverage.

[0034] The multi-dimensional comprehensive indicator scoring calculation module is used to calculate a multi-dimensional comprehensive indicator score based on the comprehensive indicator score of each dimension. The multi-dimensional comprehensive indicator score and the comprehensive indicator score of each dimension are used to provide improvement suggestions for the revenue sharing rules.

[0035] Optionally, the single-dimensional scoring calculation module includes:

[0036] The identifier field consistency score calculation submodule is used to calculate the identifier field consistency score based on the total number of resources identified in each dimension and the total number of resources identified most frequently.

[0037] The case-consistency score calculation submodule is used to calculate the case-consistency score based on the number of times the same key field used for revenue sharing appears with different capitalization under each dimension, as well as the number of all matching revenue sharing keywords.

[0038] The duplicate score calculation submodule is used to calculate the duplicate score based on the number of times the same meaning appears using multiple similar revenue-sharing keywords under each dimension, and the total number of all matching revenue-sharing keywords;

[0039] The accuracy score calculation submodule is used to calculate the accuracy score based on the number of spelling errors in the revenue sharing keywords under each dimension, as well as the number of all matching revenue sharing keywords;

[0040] The coverage score calculation submodule is used to calculate the coverage score based on the total number of identified resources and the total number of all resources under each dimension.

[0041] The comprehensive indicator score calculation submodule for each dimension is used to calculate the comprehensive indicator score for each dimension based on the consistency score of the identifier field, the case consistency score, the repetition score, the correctness score, and the coverage score.

[0042] In a second aspect, embodiments of this application propose a method for allocating invoices, the method comprising:

[0043] Obtain billing information and create a resource inventory from the cloud vendor's platform;

[0044] Extract key fields for revenue sharing from the resource list. These key fields include: resource name, resource group / project, subscription, and resource tag.

[0045] The key fields used for revenue sharing are segmented and cleaned to obtain revenue sharing keywords and tag information;

[0046] The revenue sharing keywords and tag information are semantically recognized using a large language model, and the revenue sharing dimensions and corresponding keywords of the revenue sharing keywords are predicted. The revenue sharing dimensions include organization, application, environment, component and personnel.

[0047] Once the user client confirms the revenue sharing dimension and corresponding keywords output by the large language model, search for keywords that match the corresponding keywords in the resource list, and mark the matching resources in the resource list.

[0048] A revenue sharing scheme is obtained based on the resource identification results, and revenue sharing rules are created based on the revenue sharing scheme. The revenue sharing rules are used to find keywords from key fields and allocate them to the objects corresponding to the keywords.

[0049] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the functions of the shared billing system described in any of the first aspects above.

[0050] This application includes the following advantages: It proposes a billing allocation system, method, and device. A first creation module obtains bills from a cloud vendor platform and creates a resource list. An extraction module extracts key fields for billing allocation from the resource list, including resource name, resource group / project, subscription, and resource tag. A cleaning module segments and cleans the key fields for billing allocation to obtain billing keywords and tag information. A prediction module performs semantic recognition on the billing keywords and tag information using a large language model, and predicts the corresponding billing dimension and keywords for that dimension. The billing dimension includes organization, application, environment, component, and personnel. A matching and identification module, upon confirmation of the billing dimension and corresponding keywords output by the large language model on the user client, searches the resource list for keywords matching the corresponding dimension keywords and identifies the matched resources. A second creation module obtains a billing scheme based on the resource identification results and creates billing rules based on the scheme. These rules are used to find keywords from the key fields and allocate them to the objects corresponding to those keywords. This system uses modules such as data processing, feature extraction, semantic recognition, and rule creation to find keywords in bills and label them in a standardized manner. Based on this, it generates a billing scheme and corresponding billing rules. Through the billing rules, resource costs in the bill can be quickly allocated in multiple dimensions without manual billing, thus improving the efficiency and accuracy of billing. Attached Figure Description

[0051] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a schematic diagram of the functional modules of an expense sharing system proposed in an embodiment of this application;

[0053] Figure 2 This is a flowchart illustrating the steps of a bill allocation method proposed in an embodiment of this application;

[0054] Figure 3 This is a flowchart illustrating a method for allocating invoices according to an embodiment of this application;

[0055] Figure 4 This is a schematic diagram of a resource inventory cleaning process proposed in an embodiment of this application;

[0056] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0058] As enterprises increasingly migrate to the cloud, the continuous rise in cloud costs has created a demand for cost reduction and efficiency improvement. To reduce cloud costs, it's crucial to first understand where these costs are incurred. Therefore, enterprises need to allocate cloud costs, especially through multi-dimensional allocation, analyzing the composition of cloud costs from different perspectives. Currently, enterprises primarily allocate cloud costs manually or use rule-based automated tools. While rule-based automated tools can improve allocation efficiency, they rely on manual review of the allocation rules. This is particularly problematic for enterprises with previously non-standard billing and allocation labeling, where there are instances of missing or inconsistent labeling. This poses significant difficulties for manual rule review, impacting the accuracy and efficiency of allocation.

[0059] Furthermore, manually configuring revenue sharing rules is prone to errors and is extremely time-consuming. The time required from drafting the revenue sharing rules to checking the results after configuration is too long, and any confirmation or adjustment of rules during the process will further extend the time.

[0060] Based on this, this application proposes a bill allocation system that is user-friendly and can identify bill identifiers and generate bill allocation rules based on the identifiers, thereby improving bill allocation efficiency and accuracy.

[0061] In a first aspect, embodiments of this application propose an apportionment billing system, see [reference]. Figure 1 , Figure 1 This is a functional module diagram of an expense sharing system proposed in an embodiment of this application. The system includes:

[0062] The first creation module 101 is used to obtain billing information from the cloud vendor platform and create a resource inventory.

[0063] To understand cloud costs, the first step is to obtain and analyze cloud bills. Cloud bills are typically stored on cloud vendor platforms, which can be accessed directly from the enterprise's account. These cloud vendor platforms include Tencent Cloud, Alibaba Cloud, Huawei Cloud, Amazon Web Services, Microsoft Azure, and others.

[0064] After obtaining multiple bills, a resource list is created based on the multiple bills to facilitate subsequent analysis and identification, so that the necessary information for each bill can be obtained from the resource list for analysis.

[0065] Extraction module 102 is used to extract key fields for revenue sharing from the resource list.

[0066] To accurately allocate bills, key fields for billing are first extracted from the resource list, and the resource costs in the bills are allocated based on these key fields.

[0067] The key fields used for revenue sharing include: resource name, resource group / project, subscription, and resource tags. The resource name is typically user-defined for managing and identifying resources; the resource group / project is a logical grouping method for resources; a subscription refers to a user's usage plan for a particular service or resource; and resource tags are labels added by users to resources for categorization, searching, and management.

[0068] It should be noted that the above resources refer to cloud resources such as servers, databases, disks, and networks.

[0069] The aforementioned key fields for billing refer to the key identifiers that need to be extracted from these fields when splitting bills to identify which cost center the resources in the bill should be allocated to.

[0070] For example, the resource name includes the following fields: Aproject-test, Bproject-dev, tke-audit-cls-k64ru0, cproject-frontend-uat, tke-audit-cls-hjo8mq;

[0071] The resource group / project contains the following fields: Bproject, Cproject, Dproject;

[0072] The resource tags include the following fields: {"appname":"abc","environment":"test","ve nder":"user1"}, {"appname":"def","environment":"uat","project":"Dproject"}, {"appname":"def","environment":"uat","project":"Dproject"}. Key fields are extracted and identified from these fields, and resource costs are allocated based on these identifications.

[0073] The cleaning module 103 is used to segment and clean the key fields used for revenue sharing to obtain revenue sharing keywords and tag information.

[0074] Considering that the bill contains a large amount of field information that is not relevant to bill allocation and does not help with bill allocation, the key fields used for bill allocation are segmented and the invalid information contained therein is cleaned to obtain bill allocation keywords and tag information.

[0075] The prediction module 104 is used to perform semantic recognition on the revenue sharing keywords and the tag information through a large language model, and to predict the revenue sharing dimension corresponding to the revenue sharing keywords and the keywords of the corresponding dimension.

[0076] The cleaned revenue-sharing keywords and tag information are provided to a large language model for semantic recognition. The large language model then aggregates the revenue-sharing dimensions, including organization, application, environment, component, and personnel. Based on the revenue-sharing keywords and tag information, the large language model predicts possible revenue-sharing dimensions and corresponding keywords. For example, the large language model identifies the environment dimension keywords as "test", "uat", and "dev", the project dimension keywords as "aproject", "bproject", "cproject", and "dproject", and the personnel dimension keyword as "user1".

[0077] It should be noted that since large language models often cannot identify project or application code information within a client company, this information is input into the large language model so that it can learn and accurately infer the classification of keywords.

[0078] By using a large language model for semantic recognition, the revenue sharing dimension and corresponding keywords can be automatically inferred. This method is more flexible and intelligent than existing rule-based methods.

[0079] The matching identification module 105 is used to search for keywords that match the corresponding keywords in the resource list when the user client confirms the revenue sharing dimension and the corresponding keywords output by the large language model, and to identify the matching resources in the resource list.

[0080] The revenue sharing dimensions and corresponding keywords output by the large language model are sent to the user's client, allowing the user to view these dimensions and keywords. Users can modify or rename any inappropriate revenue sharing dimensions or keywords.

[0081] Once the user client confirms the revenue sharing dimension and corresponding keywords output by the large language model, search for keywords that match the corresponding keywords in the resource list, and mark the matching resources in the resource list.

[0082] For example, if the keyword for the corresponding dimension is "user1", and a match is made in the resource list, and the matched keyword is "user1", then the resource containing the matched keyword "user1" is identified.

[0083] The second creation module 106 is used to obtain a revenue sharing scheme based on the resource identification result and to create revenue sharing rules based on the revenue sharing scheme.

[0084] After all resource lists are identified, a revenue sharing scheme is created based on the resource representation results, and a revenue sharing rule is created based on the revenue sharing scheme. This revenue sharing rule is used to find keywords from key fields and assign them to the objects corresponding to those keywords.

[0085] For example, suppose the keyword is A, the revenue sharing rule is B, the revenue sharing dimension is C, the object is Cx, and the key field where the keyword is located is D. Then the content of revenue sharing rule B is: when D contains A, the resources consumed are allocated to Cx to achieve the allocation of resource costs in the bill.

[0086] The revenue sharing schemes are shown in Tables 1 and 2, which represent the application-level and environment-level revenue sharing schemes, respectively. When the revenue sharing dimension is application, the keywords matched in the bill are aproject, bproject, cproject, and other unassigned keywords (unassigned keywords may mean no matching keywords). Each keyword matches 4, 4, 3, 2, and 4 resources respectively, with bill amounts of 1000 yuan, 500 yuan, 200 yuan, 100 yuan, and 600 yuan. The marked resources may include cloud servers, cloud databases, disks, and networks. When the revenue sharing dimension is environment, the keywords matched in the bill are uat, dev, test, and other unassigned keywords. Each keyword matches 5, 4, 3, and 4 resources respectively, with bill amounts of 1100 yuan, 500 yuan, 200 yuan, and 600 yuan. The marked resources may include cloud servers, cloud databases, disks, and networks.

[0087] Table 1

[0088] application Amount Resource quantity aproject 1000 4 bproject 500 4 cProject 200 3 dproject 100 2 Unallocated 600 4

[0089] Table 2

[0090] environment Amount Resource quantity uat 1100 5 dev 500 4 test 200 3 Unallocated 600 4

[0091] This application proposes an invoice sharing system. A first creation module retrieves invoices from a cloud vendor platform and creates a resource list. An extraction module extracts key fields for invoice sharing from the resource list, including resource name, resource group / project, subscription, and resource tag. A cleaning module segments and cleans the key fields for invoice sharing to obtain invoice sharing keywords and tag information. A prediction module performs semantic recognition on the invoice sharing keywords and tag information using a large language model, and predicts the invoice sharing dimension corresponding to the keywords and the corresponding keywords for that dimension. The invoice sharing dimension includes organization, application, environment, component, and personnel. A matching and identification module, upon confirmation of the invoice sharing dimension and corresponding keywords output by the large language model on the user client, searches the resource list for keywords matching the corresponding keywords and identifies the matched resources. A second creation module obtains an invoice sharing scheme based on the resource identification results and creates invoice sharing rules based on the scheme. These rules are used to find keywords from the key fields and allocate them to the objects corresponding to those keywords. This system uses modules such as data processing, feature extraction, semantic recognition, and rule creation to find keywords in bills and label them in a standardized manner. Based on this, it generates a billing scheme and corresponding billing rules. Through the billing rules, resource costs in the bill can be quickly allocated in multiple dimensions without manual billing, thus improving the efficiency and accuracy of billing.

[0092] In an optional implementation, the cleaning module 103 includes the following sub-modules:

[0093] The conversion submodule 1031 is used to convert all key fields used for accounting into lowercase representation.

[0094] To facilitate subsequent data processing, all key fields used for revenue sharing were first converted to lowercase.

[0095] For example, the fields of resource group / project: Bproject, Cproject, Dproject, after being converted to lowercase, are represented as: bproject, cproject, dproject.

[0096] The first segmentation module 1032 is used to segment the key fields of resource name, resource group / project and subscription using the first segmenter to obtain multiple first segmentation fields.

[0097] Then, the different fields are split. The key fields of resource name, resource group / project and subscription are split using the first splitter to obtain multiple first split fields.

[0098] For example, assuming the first delimiter is "-", the resource name key field is split, and the split field is represented as follows:

[0099] "aproject", "bproject", "test", "dev", "tke", "andit", "cls", "k64ru0".

[0100] The key fields of the resource group / project are segmented, and the segmented fields are represented as follows:

[0101] "aproject", "bproject", "cproject".

[0102] The second segmentation module 1033 is used to segment the tag into multiple tag key-value pairs according to the second segmenter, and obtain multiple second segmentation fields and tag information.

[0103] To segment tags, the value needs to be obtained from the key-value pair (key:value) of the tag. Specifically, the tag is segmented into multiple tag key-value pairs by the second splitter, resulting in multiple second splitting fields and tag information.

[0104] For example, the segmented tag field can be represented as follows:

[0105] "abc", "test", "user1", "def", "uat", "dproject".

[0106] In this context, a single tag key can correspond to multiple tag values ​​within a tag key-value pair. For example, the same key can contain the following values: value1, value2, value3, ..., valuen.

[0107] It should be noted that, in addition to using the segmented fields as keywords, the tag segmentation also requires providing a set of key-value pairs (key:value) data to the large language model so that the large language model can predict the dimensions of keywords based on the key-value pairs data.

[0108] For example, the key-value pairs provided to the large language model can be as follows:

[0109] appname: "def", "abc"; environment: "test", "uat"; project: "dproject"; vender: "user1".

[0110] The identification and cleaning submodule 1034 is used to identify invalid information in multiple first and second segmentation fields using the Naive Bayes algorithm, and clean the invalid information to obtain the accounting keywords.

[0111] The segmented fields often contain a large amount of invalid information. For example, in product names, cloud vendor platforms automatically generate name information, such as "tke-audit-cls-k64ru0". In this information, "k64ru0" is considered invalid. Some cloud products are also automatically tagged by the cloud vendor platform during creation, and these tags also contain a lot of invalid information. This information will interfere with the billing results and needs to be removed. However, since different vendors have different generation rules and results, machine learning can be used to automatically identify invalid information. Machine learning algorithms can choose Naive Bayes for text classification. Combining machine learning algorithms (such as Naive Bayes) with semantic recognition technology from large language models to process cloud bills is more efficient than existing manual allocation methods.

[0112] Specifically, the Naive Bayes algorithm is used to identify and clean up invalid information in multiple first and second segmentation fields, resulting in billing keywords. Using these keywords in subsequent classifications can improve the accuracy of bill categorization.

[0113] In this submodule, a Naive Bayes classifier is used to calculate the posterior probability. This calculation is based on Bayes' theorem, and the posterior probability (P(y|X)) is used as the basis for classification.

[0114] In an optional implementation, the above-mentioned identification and cleaning submodule 1034 specifically includes the following units:

[0115] The feature extraction unit 10341 is used to extract features from the first segmentation field and the second segmentation field and construct a feature vector.

[0116] First, extract the features of the segmented fields. For example, the extracted features are shown below:

[0117] Does it contain a number?: Does the split field contain at least one number?

[0118] Does it contain letters?: Does the split field contain at least one letter?

[0119] Does it contain special characters?: Does the split field contain a special character (e.g., an underscore -)?

[0120] Is it all numeric?: Whether the split field consists only of numeric values.

[0121] Is it all letters?: Whether the field after splitting consists only of letters.

[0122] Length of the segmented field: The number of characters in the segmented field.

[0123] Then, for each segmented field, a feature vector is constructed based on the extracted features. This feature vector indicates whether the segmented field possesses the aforementioned features. For example, the feature vectors of fields "103", "nodepool1", and "scratchvolume" are used to illustrate this:

[0124] "103": [Contains numbers, does not contain letters, does not contain special characters, all numbers, not all letters, length 3].

[0125] "nodepool1": [Contains numbers, contains letters, contains special characters, not all numbers, not all letters, length 10].

[0126] "scratchvolume": [Does not contain numbers, contains letters, does not contain special characters, is not all numbers, is all letters, length 12].

[0127] The first computing unit 10342 is used to calculate prior probabilities and conditional probabilities based on statistical information in pre-trained data.

[0128] The pre-trained data is labeled as either meaningful or meaningless, and then the prior probability and conditional probability are calculated using the statistical information of these labeled pre-trained data.

[0129] For example, first calculate the conditional probability: P(containing a number | meaningful), P(containing a number | meaningless), and the prior probability: P(meaningful), P(meaningless), etc.

[0130] The second calculation unit 10343 is used to calculate the posterior probability that the first segmentation field or the second segmentation field belongs to the first category and the second category, respectively, based on the prior probability and the conditional probability.

[0131] By using prior and conditional probabilities pre-calculated based on pre-trained data to calculate posterior probabilities, the need to repeatedly calculate a large number of values ​​can be avoided each time. Specifically, the probabilities of the first or second segmentation field belonging to the first or second category are calculated using the prior and posterior probabilities, respectively.

[0132] The first category is set to meaningful, and the second category is set to meaningless.

[0133] Suppose we have features (X = [X1, X2, ..., Xn]), where each feature is independent. The formula for calculating the prior probability P(y|X) is as follows:

[0134]

[0135] Where P(y) represents the prior probability of category y, P(X) represents the marginal probability, and P(X|y) represents the conditional probability of feature X.

[0136] Due to the assumption of independence between features:

[0137] P(X|y)=P(X1|y)*P(X2|y)*...*P(X n |y)

[0138] The formula for calculating the posterior probability is as follows:

[0139]

[0140] in, Let P(y) represent the sum of conditional probabilities of n features, P(y) represent the prior probability of class y, P(y|X) represent the posterior probability, and P(X) represent the marginal probability. P(X) = ∑ j P(X|y j )·P(y j ), which means summing over all possible categories j.

[0141] For example, for each segmented field, the posterior probability of it belonging to the "meaningful" and "meaningless" categories is calculated. For example, for the segmented field "103":

[0142] P(meaningful | feature) = P(containing numbers | meaningful) × P(not containing letters | meaningful) × ... × P(meaningful) / P(feature).

[0143] P(meaningless | feature) = P(contains numbers | meaningless) × P(does not contain letters | meaningless) × ... × P(meaningless) / P(feature).

[0144] The prediction determination unit 10344 is used to take the category corresponding to the maximum posterior probability as the prediction result of the first segmentation field or the second segmentation field, and to determine the key field whose prediction result is the second category as invalid information.

[0145] After obtaining the posterior probability, two results will occur: a meaningful posterior probability and a meaningless posterior probability. The category corresponding to the maximum posterior probability is used as the prediction result of the first or second segmentation field mentioned above. Key fields predicted to be of the second category are identified as invalid information, while key fields predicted to be of the first category are identified as valid information.

[0146] Specifically, the first category is determined to be meaningful, and the second category is determined to be meaningless. If the posterior probability of a segmented field belonging to the second category is greater than the posterior probability of the first category, then the segmented field is considered meaningless and is classified as invalid information.

[0147] For each segmented field, the posterior probability is calculated, and it is determined whether the field is meaningful or meaningless, thus obtaining the prediction result.

[0148] By automating the extraction and identification of key fields for revenue sharing, the complexity and error rate of manual operations are reduced, thereby improving the accuracy and efficiency of revenue sharing.

[0149] In an optional implementation, the search order for keywords in resource groups / projects and tags should be determined according to keyword coverage. The matching identification module 105 specifically includes:

[0150] The coverage calculation submodule 1051 is used to calculate the coverage of the keywords of the corresponding dimension in the resource list field.

[0151] When searching for matching keywords in the resource list, the search needs to be conducted in a certain order. The search order for keywords in resource groups / projects and tags is determined by the coverage rate.

[0152] First, the coverage rate of keywords in the resource list field for the corresponding dimension is calculated using the coverage calculation submodule.

[0153] The matching submodule 1052 is used to search for target keywords that match the keywords of the corresponding dimension in the resource list based on the coverage rate.

[0154] Then, by searching the matching submodule, target keywords that match the keywords of the corresponding dimension are found in the resource list.

[0155] For example, if the keyword has a coverage rate of 3 / 7 in resource groups / projects and a coverage rate of 2 / 7 in tags, then the search order is: resource group / project > tag > resource name; if the keyword has a coverage rate of 0 in resource groups / projects and a coverage rate of 3 / 7 in tags, then the search order is: tag > resource group / project > resource name.

[0156] The identification submodule 1053 is used to identify the target keyword and then identify the resource where the target keyword is located. The identification content is the revenue sharing dimension: revenue sharing keyword.

[0157] After finding a matching keyword, the identification submodule identifies that keyword as the target keyword and identifies the resource containing that target keyword. The identification content is the revenue sharing dimension: revenue sharing keyword. For example, if the dimension of the target keyword is environment, the target keyword used for matching is the identified revenue sharing keyword, and the identification content is: "environment": "uat", "application": "aproject".

[0158] For resource names, the search order should follow the principle of searching by resource name last. This is because resource names are usually named more arbitrarily and a lot of information in resource names is randomly generated by the cloud vendor platform. Therefore, searching by resource name is used as a fallback value for keyword matching.

[0159] In an optional implementation, the first creation module 101 specifically includes the following sub-modules:

[0160] The bill retrieval module 1011 is used to retrieve users' historical bills from different cloud vendor platforms, and the granularity of the historical bills is daily bills.

[0161] To avoid incomplete resource cost allocation due to incomplete monthly billing data, all bills from the previous month should be retrieved as historical bills during the initial bill retrieval. For easier viewing of daily spending trends, bill granularity is set to daily bills.

[0162] The standardization processing submodule 1012 is used to standardize the historical bills obtained from different cloud vendors, obtain the original bills, and store them.

[0163] Since billing from different cloud vendors varies, standardizing historical bills obtained from various vendors facilitates unified billing processing. Standardization methods include selecting the fields needed for billing analysis and standardizing field names. The bills processed in this way become the raw bills and are stored in the database. These raw bills are billed daily based on billing dimensions. Specifically, many resources in the raw detailed bills are billed hourly, generating records every hour, resulting in a large data volume. Therefore, when integrating bills, the data is compressed to a daily granularity. The compression method is based on billing items. Most cloud vendor platforms directly provide bills at this daily granularity, which are used as the raw bills for system integration and storage.

[0164] The aggregation submodule 1013 is used to aggregate the original bill based on the resource ID to generate a resource list.

[0165] Then, the original invoice is aggregated based on the resource ID to obtain a resource list. This resource list includes the following fields: resource ID, resource name, resource group / project, subscription, product name, resource tag, and amount due. The resource ID is a unique identifier for a resource, used to uniquely identify a resource within the cloud platform. The product name refers to the specific product or service name in the cloud service, such as Elastic Compute Service (ECS) or Relational Database Service (RDS). The amount due refers to the fee the user needs to pay for using the cloud resources.

[0166] For example, refer to Table 3, which is an example of a Tencent Cloud bill according to an embodiment of this application. Table 3 only shows a portion of the contents of the bill.

[0167] Table 3

[0168]

[0169]

[0170] In an optional implementation, the second creation module 106 includes:

[0171] Revenue sharing submodule 1061 is used to generate a revenue sharing scheme based on the resource identification result and present the revenue sharing scheme to the user client.

[0172] After all resources are identified, revenue sharing is performed based on the identification results. The identification results determine the identified resources, the dimensions corresponding to the keywords, and the amounts payable. A corresponding revenue sharing plan is then created based on this data and presented to the user client for confirmation to ensure it meets expectations.

[0173] Create submodule 1062 to create revenue sharing rules according to the revenue sharing scheme after the user client confirms the revenue sharing scheme.

[0174] After the user client confirms the adoption of the revenue sharing scheme, a revenue sharing rule is created according to the scheme. This revenue sharing rule is used to persistently store the rules for keyword search. The content of the revenue sharing rule is the condition for bill allocation, that is, to search for keywords from the key fields and allocate them to the objects corresponding to the keywords.

[0175] For example, the revenue sharing rules at the project level are used as an example.

[0176] When the revenue sharing keyword is "aproject", if the resource name contains "aproject", the resource will be allocated to the "aproject" project.

[0177] When the revenue sharing keyword is bproject, if bproject is included in the resource group / project, the resource will be allocated to the bproject project.

[0178] When the revenue sharing keyword is cproject, if cproject is included in the resource group / project, the resource will be allocated to the cproject project.

[0179] This allows us to obtain the resource costs used in each project and allocate those costs to each resource.

[0180] It should be noted that the revenue sharing scheme may differ depending on the different dimensions used to allocate resource costs. A multi-dimensional revenue sharing scheme can help users conduct multi-dimensional analysis of resource costs.

[0181] In an optional implementation, after obtaining the revenue sharing scheme and revenue sharing rules, in order to evaluate the standardization of the identification content used in the revenue sharing scheme and provide corresponding improvement suggestions, the system further includes the following module for scoring calculation:

[0182] The single-dimensional scoring calculation module 107 is used to calculate the index score for each dimension and the comprehensive index score for each dimension.

[0183] The dimensions mentioned above include organization, application, environment, components, and people. Each dimension is scored according to its metrics, which include consistency, repeatability, correctness, and coverage.

[0184] The comprehensive index score for each dimension is calculated based on the scores of all indicators in each dimension. The comprehensive index score for each dimension is used to characterize the degree of standardization of the identifier under each dimension.

[0185] The multi-dimensional comprehensive index scoring calculation module 108 is used to calculate the multi-dimensional comprehensive index score based on the comprehensive index score of each dimension.

[0186] By calculating the comprehensive index score for each dimension, a multi-dimensional comprehensive index score is generated. This multi-dimensional comprehensive index score, along with the comprehensive index score for each dimension, is used to provide suggestions for improving the revenue sharing rules.

[0187] The preset score for each indicator is compared with the calculated comprehensive score for each dimension, and improvement suggestions are given for indicators that are lower than the preset score.

[0188] If the calculated comprehensive index score for each dimension is higher than the preset score for each dimension, the multi-dimensional comprehensive index score is compared with the preset comprehensive score, and suggestions for comprehensive improvement are given.

[0189] By calculating indicator scores and providing improvement suggestions, users can optimize their billing management processes and improve the standardization and compliance of billing management. Using multi-dimensional comprehensive indicator scores allows for a more holistic assessment of billing standardization, a method that is more comprehensive and scientific than single-dimensional scoring.

[0190] In an optional implementation, the single-dimensional scoring calculation module 107 includes:

[0191] The identifier field consistency score calculation submodule 1071 is used to calculate the identifier field consistency score based on the total number of resources identified in each dimension and the total number of resources identified most frequently.

[0192] The consistency of the identifier field refers to whether the revenue sharing identifiers for this dimension are in the same field. The formula for calculating the identifier field consistency score S1 in the identifier field consistency score calculation submodule is as follows:

[0193]

[0194] Among them, T f This indicates the total number of resources identified in this dimension; C m This indicates the total number of resources for the field that is most frequently identified in this dimension. For example, if the most frequently identified field appears in the label column, then the total number of resources identified in the label column is calculated.

[0195] The case consistency score calculation submodule 1072 is used to calculate the case consistency score based on the number of times the same key field used for revenue sharing appears with different capitalization under each dimension, and the number of all matching revenue sharing keywords.

[0196] Case consistency refers to the number of times the same word appears with different capitalizations in this dimension. The formula for calculating the case consistency score S2 in this case consistency score calculation submodule is as follows:

[0197]

[0198] Among them, C c This indicates the number of times the same word appears in different capitalizations within this dimension; T c This indicates the total number of matching revenue-sharing keywords in this dimension.

[0199] The duplication score calculation submodule 1073 is used to calculate the duplication score based on the number of times the same meaning appears using multiple similar revenue-sharing keywords under each dimension, and the total number of all matching revenue-sharing keywords.

[0200] The repetition score, which counts the number of similar words used for the same meaning under this dimension, is calculated using the following formula in the repetition score calculation submodule:

[0201]

[0202] Among them, R t T represents the number of times similar words appear in this dimension. c This indicates the total number of matching revenue-sharing keywords in this dimension.

[0203] The accuracy score calculation submodule 1074 is used to calculate the accuracy score based on the number of spelling errors in the revenue sharing keywords under each dimension, as well as the number of all matching revenue sharing keywords.

[0204] Correctness refers to the number of spelling errors in the revenue sharing keywords under this dimension. The calculation formula for the correctness score S4 in this correctness score calculation submodule is as follows:

[0205]

[0206] Among them, S t T represents the number of spelling errors in this dimension. c This indicates the total number of matching revenue-sharing keywords in this dimension.

[0207] The coverage score calculation submodule 1075 is used to calculate the coverage score based on the total number of identified resources and the total number of all resources under each dimension.

[0208] Coverage refers to the number of resources covered by revenue-sharing keywords. The formula for calculating the coverage score S5 in the coverage score calculation submodule is as follows:

[0209]

[0210] Among them, T s T represents the total number of all resources. f This indicates the total number of resources identified in this dimension.

[0211] The comprehensive indicator score calculation submodule 10106 for each dimension is used to calculate the comprehensive indicator score for each of the above dimensions based on the consistency score of the identifier field, the case consistency score, the repetition score, the correctness score, and the coverage score.

[0212] Based on the consistency score of the identifier field, the case sensitivity score, the duplication score, the correctness score, and the coverage score, calculate the comprehensive index score S for each of the above dimensions. D The calculation formula is as follows:

[0213]

[0214] Among them, S D This represents the overall score for this dimension, w i S represents the weight index for the i-th indicator score. i This represents the score for the i-th indicator.

[0215] Based on the comprehensive index score of each of the above dimensions, calculate the multi-dimensional comprehensive index score S. o The calculation formula is as follows:

[0216]

[0217] Among them, S O This represents a multi-dimensional comprehensive indicator score, w j S represents the rating weight of the j-th dimension. Dj This represents the comprehensive index score for the j-th dimension.

[0218] For example, suppose the initial data for the project dimension is as follows:

[0219] T f (Total number of resources identified in this dimension) = 1000, C m (Total number of resources for the field most frequently identified in this dimension) = 800, C c(Number of times the same word appears in different capitalizations in this dimension) = 4, T c (Number of all matched revenue-sharing keywords in this dimension) = 10, R t (Number of occurrences of similar words in this dimension) = 2, S t (Number of spelling errors in this dimension) = 1, T s (Number of resources covered by revenue sharing keywords in this dimension) = 2000.

[0220] Project dimension score:

[0221] Calculate the consistency score S1 for the identifier field:

[0222]

[0223] Calculate the case-consistency score S2:

[0224]

[0225] Calculate the repeatability score S3:

[0226]

[0227] Calculate the correctness score S4:

[0228]

[0229] Calculate coverage score S5:

[0230]

[0231] Calculate the comprehensive index score S for each dimension. D :

[0232] Assume weight w i They are equal, with each rating item having a weight w. i Given 0.2, calculate S. D :

[0233]

[0234] Substitute the scores for each item into the calculation:

[0235] S D =0.2×80+0.2×60+0.2×80+0.2×90+0.2×50=72.

[0236] Therefore, the comprehensive index score S for this project dimension is... D It scored 72 points.

[0237] In a second aspect, embodiments of this application propose a method for allocating invoices, see [reference]. Figure 2 , Figure 2 This is a flowchart illustrating the steps of a bill allocation method proposed in an embodiment of this application. The method includes the following steps:

[0238] Step 201: Obtain the billing information from the cloud vendor's platform and create a resource inventory;

[0239] Step 202: Extract key fields for revenue sharing from the resource list. The key fields for revenue sharing include: resource name, resource group / project, subscription, and resource tag.

[0240] Step 203: Segment and clean the key fields used for revenue sharing to obtain revenue sharing keywords and tag information;

[0241] Step 204: Semantically recognize the revenue sharing keywords and the tag information using a large language model, and predict the revenue sharing dimensions corresponding to the revenue sharing keywords and the keywords of the corresponding dimensions. The revenue sharing dimensions include organization, application, environment, component and personnel.

[0242] Step 205: If the user client confirms the revenue sharing dimension and the corresponding keywords output by the large language model, search for keywords that match the corresponding keywords in the resource list, and mark the matching resources in the resource list.

[0243] Step 206: Obtain a revenue sharing scheme based on the resource identification results, and create revenue sharing rules based on the revenue sharing scheme. The revenue sharing rules are used to find keywords from the key fields and allocate them to the objects corresponding to the keywords.

[0244] To clearly illustrate the bill allocation method proposed in the embodiments of this application, the following will be combined with... Figure 3 Provide a detailed explanation. Figure 3 This is a flowchart illustrating a method for allocating bills according to an embodiment of this application.

[0245] Retrieve the previous month's billing file, accurate to the day, generated by the user's corresponding public cloud vendor. Standardize the bills from different cloud vendors and store them in the database, using this bill as the original bill. Aggregate the original bills by resource ID to generate a resource list. The resource list (corresponding to...) Figure 3 The resource summary bill (in the data structure) should include fields such as resource ID, resource name, resource group / project, subscription, product name, resource tag, and amount payable. Extract the resource name, resource group / project, subscription, and resource tag fields from the resource list as key fields for billing allocation. These key fields are used to identify which cost center a resource should be allocated to, in order to split the bill. Then, the key fields for billing allocation are segmented and cleaned (i.e.,...). Figure 3The process (resource bill cleaning) specifically uses a Naive Bayes algorithm to identify invalid information in key fields used for billing and cleanses them to obtain billing keyword tag information. The cleaned billing keywords and tag information are then provided to a large language model for semantic recognition. The large language model automatically infers possible billing dimensions and corresponding dimension keywords based on the billing keywords and tag information, confirming the billing dimensions and corresponding dimension keywords to the user client. Users can modify and rename these attributes through their client. After user confirmation, matching keywords are searched from the resource list, following a specific order. The order should prioritize searching from resource names last, while the search order within resource groups / projects, subscriptions, and tags should be determined by keyword coverage. The billing results for the desired dimensions and resource tagging are presented to the user client for confirmation. Once the user confirms the billing scheme through their client, billing rules are automatically created. These rules are persistently stored and define the conditions for automatic billing allocation, i.e., finding a specific keyword from a certain field and assigning it to a specific object.

[0246] During the process of generating revenue sharing statements according to the pre-set time according to the revenue sharing rules, in order to view specific consumption details, such as the daily consumption details of a specific resource in a specific project, it is necessary to apply the revenue sharing rules proposed in this application to the original statements. The original statements at the daily granularity are then divided according to these rules to obtain specific revenue sharing statements, allowing users to view the detailed consumption details.

[0247] For details on cleaning the resource list, please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of a resource list cleaning process proposed in an embodiment of this application. A resource-summarized list is generated based on the obtained invoices. Then, accounting keywords are extracted and segmented. A Naive Bayes algorithm is used to clean invalid fields. The cleaned accounting keywords and tag information are input into a large language model for semantic recognition.

[0248] This application proposes a method for sharing bills. The method involves obtaining bills from a cloud vendor platform and creating a resource list; extracting key fields for bill sharing from the resource list, including resource name, resource group / project, subscription, and resource tag; segmenting and cleaning the key fields to obtain bill sharing keywords and tag information; performing semantic recognition on the bill sharing keywords and tag information using a large language model to predict the bill sharing dimension and corresponding keywords for the bill sharing keywords, where the bill sharing dimension includes organization, application, environment, component, and personnel; after the user client confirms the bill sharing dimension and corresponding keywords output by the large language model, searching the resource list for keywords matching the corresponding keywords, and identifying the matching resources in the resource list; obtaining a bill sharing scheme based on the resource identification results, and creating bill sharing rules based on the bill sharing scheme, whereby the bill sharing rules are used to find keywords from the key fields and allocate them to the objects corresponding to the keywords. This method uses modules such as data processing, feature extraction, semantic recognition, and rule creation to find keywords in bills and to label them in a standardized manner. Based on this, a billing scheme and corresponding billing rules are generated. Through the billing rules, resource costs in the bill can be quickly allocated in multiple dimensions without manual billing, thus improving the efficiency and accuracy of billing.

[0249] Based on the same concept, this application discloses an electronic device in a third aspect. Figure 5 A schematic diagram of an electronic device disclosed in an embodiment of this application is shown, such as... Figure 5 As shown, the electronic device 100 includes a memory 110 and a processor 120. The memory of the electronic device is not less than 12G, and the processor has a main frequency of not less than 2.4GHz. The memory 110 and the processor 120 are connected by a bus communication. The memory 110 stores a computer program, which can run on the processor 120 to implement a bill sharing method disclosed in the embodiments of this application.

[0250] Based on the same application concept, this application discloses a computer-readable storage medium storing a computer program / instructions thereon, which, when executed by a processor, implements a bill sharing method disclosed in this application.

[0251] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0252] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, electronic devices, and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0253] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0254] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0255] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0256] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0257] The above provides a detailed description of the bill sharing system, method, and device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A cost-sharing system, characterized in that, The system includes: The first creation module is used to obtain billing information from the cloud vendor's platform and create a resource inventory. The extraction module is used to extract key fields for revenue sharing from the resource list. The key fields for revenue sharing include: resource name, resource group / project, subscription, and resource tag. The cleaning module is used to segment and clean the key fields used for revenue sharing to obtain revenue sharing keywords and tag information. The prediction module is used to perform semantic recognition on the revenue sharing keywords and the tag information through a large language model, and to predict the revenue sharing dimensions corresponding to the revenue sharing keywords and the keywords of the corresponding dimensions. The revenue sharing dimensions include organization, application, environment, component and personnel. The matching and identification module is used to find keywords that match the corresponding keywords in the resource list when the user client confirms the revenue sharing dimension and the corresponding keywords output by the large language model, and to identify the matching resources in the resource list. The second creation module is used to obtain a revenue sharing scheme based on the resource identification results, and to create revenue sharing rules based on the revenue sharing scheme. The revenue sharing rules are used to find keywords from key fields and allocate them to the objects corresponding to the keywords.

2. The cost-sharing system according to claim 1, characterized in that, The cleaning module includes: The conversion submodule is used to convert all key fields used for revenue sharing to lowercase representation. The first segmentation module is used to segment the key fields of resource name, resource group / project and subscription using the first segmenter to obtain multiple first segmentation fields; The second segmentation module is used to segment the tag into multiple tag key-value pairs according to the second segmenter, thereby obtaining multiple second segmentation fields and tag information. In a tag key-value pair, the same tag key corresponds to multiple tag values. The identification and cleaning submodule is used to identify invalid information in multiple first and second segmentation fields using the Naive Bayes algorithm, and clean the invalid information to obtain the revenue sharing keywords.

3. The cost-sharing system according to claim 2, characterized in that, The identification and cleaning submodule includes: The feature extraction unit is used to extract features from the first segmentation field and the second segmentation field, and construct a feature vector; The first computational unit is used to calculate prior probabilities and conditional probabilities based on statistical information in the pre-training data; The second calculation unit is used to calculate the posterior probability that the first segmentation field or the second segmentation field belongs to the first category and the second category, respectively, based on the prior probability and the conditional probability. The prediction determination unit is used to take the category corresponding to the maximum posterior probability as the prediction result of the first segmentation field or the second segmentation field, and to determine the key field whose prediction result is the second category as invalid information.

4. The cost-sharing system according to claim 1, characterized in that, The matching identifier module includes: The coverage calculation submodule is used to calculate the coverage of the keywords in the corresponding dimension in the resource list field; The matching submodule is used to search for target keywords in the resource list that match the keywords of the corresponding dimension based on the coverage rate; The identification submodule is used to identify the target keyword and then identify the resource where the target keyword is located. The identification content is the revenue sharing dimension: revenue sharing keyword.

5. The cost-sharing system according to claim 1, characterized in that, The first creation module includes: The bill retrieval submodule is used to retrieve users' historical bills from different cloud vendor platforms, with the historical bills being daily in granularity. The standardization processing submodule is used to standardize the historical bills from different cloud vendors, obtain the original bills, and store them. The aggregation submodule is used to aggregate the original bill based on the resource ID to generate a resource list. The resource list includes the following fields: resource ID, resource name, resource group / project, subscription, product name, resource tag, and amount payable.

6. The cost-sharing system according to claim 1, characterized in that, The second creation module includes: The revenue sharing submodule is used to generate a revenue sharing scheme based on the resource identification result and present the revenue sharing scheme to the user client. A submodule is created to create revenue sharing rules according to the revenue sharing scheme after the user client confirms the revenue sharing scheme. The revenue sharing rules are used to persistently store the rules for keyword search.

7. The cost-sharing system according to claim 1, characterized in that, The system also includes: The single-dimensional scoring calculation module is used to calculate the indicator score for each dimension and the comprehensive indicator score for each dimension. The comprehensive indicator score for each dimension is used to characterize the degree of standardization of the identifier under each dimension. The indicators include consistency, repeatability, correctness and coverage. The multi-dimensional comprehensive indicator scoring calculation module is used to calculate a multi-dimensional comprehensive indicator score based on the comprehensive indicator score of each dimension. The multi-dimensional comprehensive indicator score and the comprehensive indicator score of each dimension are used to provide improvement suggestions for the revenue sharing rules.

8. The cost-sharing system according to claim 7, characterized in that, The single-dimensional scoring calculation module includes: The identifier field consistency score calculation submodule is used to calculate the identifier field consistency score based on the total number of resources identified in each dimension and the total number of resources identified most frequently. The case-consistency score calculation submodule is used to calculate the case-consistency score based on the number of times the same key field used for revenue sharing appears with different capitalization under each dimension, as well as the number of all matching revenue sharing keywords. The duplicate score calculation submodule is used to calculate the duplicate score based on the number of times the same meaning appears using multiple similar revenue-sharing keywords under each dimension, and the total number of all matching revenue-sharing keywords; The accuracy score calculation submodule is used to calculate the accuracy score based on the number of spelling errors in the revenue sharing keywords under each dimension, as well as the number of all matching revenue sharing keywords; The coverage score calculation submodule is used to calculate the coverage score based on the total number of identified resources and the total number of all resources under each dimension. The comprehensive indicator score calculation submodule for each dimension is used to calculate the comprehensive indicator score for each dimension based on the consistency score of the identifier field, the case consistency score, the repetition score, the correctness score, and the coverage score.

9. A method for allocating bills, characterized in that, The method includes: Obtain billing information and create a resource inventory from the cloud vendor's platform; Extract key fields for revenue sharing from the resource list. These key fields include: resource name, resource group / project, subscription, and resource tag. The key fields used for revenue sharing are segmented and cleaned to obtain revenue sharing keywords and tag information; The revenue sharing keywords and tag information are semantically recognized using a large language model, and the revenue sharing dimensions and corresponding keywords of the revenue sharing keywords are predicted. The revenue sharing dimensions include organization, application, environment, component and personnel. Once the user client confirms the revenue sharing dimension and corresponding keywords output by the large language model, search for keywords that match the corresponding keywords in the resource list, and mark the matching resources in the resource list. A revenue sharing scheme is obtained based on the resource identification results, and revenue sharing rules are created based on the revenue sharing scheme. The revenue sharing rules are used to find keywords from key fields and allocate them to the objects corresponding to the keywords.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the functions of the apportionment billing system as described in any one of claims 1-8.

Images