Customer demand-oriented server complete machine price intelligent configuration method and system

Abstract

The application discloses a customer demand-oriented server complete machine price intelligent configuration method and system, and relates to the technical field of server price configuration. The method comprises the following steps: analyzing a customer demand text and extracting key demand items to generate a demand feature vector; dynamically constructing a feature space of a server complete machine based on the demand feature vector; performing dimension-by-dimension matching according to a feature dimension in the feature space and a pre-established price elasticity matrix to obtain an initial price subspace of each feature dimension; detecting resource constraint conflicts among the initial price subspaces, wherein the resource constraint conflicts comprise power consumption constraint conflicts, heat dissipation constraint conflicts and physical space constraint conflicts; generating a conflict resolution path according to the detected resource constraint conflicts; and iteratively correcting elasticity coefficients in the price elasticity matrix based on an adjustment sequence until all resource constraint conflicts are eliminated to generate a final price scheme.

Description

Technical Field

[0001] This invention relates to the field of server pricing configuration technology, specifically to a method and system for intelligent configuration of server unit pricing based on customer needs. Background Technology

[0002] Server system pricing requires translating customers' vague, unstructured needs into concrete, actionable hardware combinations and pricing ranges. Existing solutions typically rely on manual experience or simple rule matching, with sales personnel manually selecting processors, memory, storage, and other hardware components and generating quotes based on the customer's application scenario and budget. This approach is inefficient when handling large numbers of customized requests and struggles to guarantee the feasibility of configurations within engineering constraints such as power consumption, heat dissipation, and physical space.

[0003] Existing automated requirements analysis methods mostly remain at the level of keyword extraction and simple classification, failing to systematically map the extracted requirements to the multi-dimensional feature space of server hardware components. This results in a semantic gap between requirements understanding and hardware selection. The pricing process typically employs fixed markups or linearly accumulating static component price lists, ignoring the price linkage effects caused by market supply and demand, and technological compatibility, resulting from different component combinations. A more significant deficiency lies in the lack of global detection and dynamic coordination capabilities for system-wide physical constraints in existing configuration and pricing methods. When a processor is selected, its associated memory, storage, and network card combinations may generate total power consumption exceeding the power supply capacity or chassis cooling capacity. Such a configuration is physically unfeasible, but current technology cannot automatically identify and correct such conflicts during the pricing stage. Furthermore, when physical conflicts are detected, existing solutions lack a closed-loop feedback adjustment mechanism, failing to reflect conflict information back to price parameters, causing a disconnect between price adjustments and configuration feasibility verification.

[0004] The challenge lies in embedding cross-detection and proactive resolution capabilities for overall power consumption, heat dissipation, and spatial constraints during the generation of the multidimensional price subspace. This would enable the price ranges of each component to be coordinated and contracted based on global physical constraints after independent generation. Furthermore, it is necessary to transform the resolution path of resource constraint conflicts into a quantitative correction signal for the price elasticity coefficient, achieving convergence of the configuration scheme from a conflict state to a feasible state through iterative adjustments. Summary of the Invention

[0005] This invention provides a method and system for intelligent configuration of server system pricing tailored to customer needs. During the process from parsing the requirement text to generating a pricing scheme, cross-dimensional power consumption, heat dissipation, and physical space constraint conflicts are detected in the dynamically constructed price subspaces for each hardware dimension. A directed conflict resolution path is generated to guide the contraction and adjustment of the price subspace. The contraction operations generated during conflict resolution are quantified as correction values ​​for the price elasticity matrix. Through closed-loop iteration, the elasticity coefficients are changed to ensure that the final output server system configuration scheme simultaneously meets both customer requirement constraints and physical feasibility constraints.

[0006] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a method for intelligent configuration of server system pricing based on customer needs, comprising: parsing customer demand text and extracting key demand items; using a pre-built demand dictionary and a thesaurus to classify candidate keywords into demand categories such as application scenarios, performance indicators, and budget ranges, generating a demand feature vector containing demand intensity coefficients; dynamically constructing a feature space for the server system based on the demand feature vector, the feature space containing multiple feature dimensions such as processor, memory, storage, and network interface, aggregating hardware component models with the same type identifier within each feature dimension and sorting them by performance level; matching the feature dimensions with a pre-established price elasticity matrix dimension by dimension, and obtaining the matching elasticity by cross-comparing the elasticity coefficient row vector with the component model list. The method dynamically constructs a feature space and adaptively corrects the elasticity coefficients, multiplying them with the price benchmark vector to obtain the initial price subspace for each dimension. It then detects power consumption, heat dissipation, and physical space constraints within these initial price subspaces, traversing and recording the conflict type and severity value for each candidate system configuration combination. Conflict resolution paths are generated based on the severity values, and priority or cost-first strategies from the resolution strategy library are used to sequentially apply shrinkage adjustments to the initial price subspaces of relevant feature dimensions, forming an adjustment sequence. Based on the adjustment sequence, the elasticity coefficients in the price elasticity matrix are iteratively corrected. Resource constraint conflict detection is then re-executed using the shrunken and adjusted price subspaces until all conflicts are eliminated and the change in the elasticity matrix is ​​less than the convergence threshold. This generates a final pricing scheme composed of a component model list, pricing range, and resource constraint detection identifiers. This method, by dynamically constructing the feature space and adaptively correcting the elasticity coefficients, automatically derives a system price that meets customer needs and is cost-effective while satisfying multiple constraints such as power consumption, heat dissipation, and physical space constraints, significantly improving the intelligence level and configuration efficiency of customized server pricing.

[0007] Preferably, after generating the final pricing plan, customer feedback is also collected. When the feedback type is adjustment feedback, performance-related keywords and cost-related keywords are identified from the adjustment description text to determine whether the adjustment direction is performance improvement or cost reduction. The corresponding adjustment magnitude value is calculated and encoded as the demand intensity coefficient in the adjustment vector correction demand feature vector. The steps from dynamically constructing the feature space to generating the final pricing plan are re-executed using the adjusted demand feature vector, thereby achieving iterative optimization of pricing based on customer interaction and improving the acceptability and flexibility of the pricing plan.

[0008] As a technical solution of the present invention, the price elasticity matrix adopts a sparse matrix storage format, which only saves the dimension identifier and model combination corresponding to the non-zero elasticity coefficient, thereby effectively reducing storage and computing overhead while ensuring matching accuracy.

[0009] As another technical solution of the present invention, when detecting resource constraint conflicts, the total power consumption value, total heat dissipation value and total physical size of the candidate whole machine configuration are obtained respectively, and compared with the preset upper limit value of power supply capacity, upper limit value of heat dissipation system capacity and available space of chassis in turn. When any value exceeds the corresponding upper limit, the corresponding type of constraint conflict is marked and the degree of conflict is quantified, so as to provide an accurate basis for the location of conflict source for subsequent resolution.

[0010] This invention also provides an intelligent configuration system for server whole-machine pricing based on customer needs, including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of the method. This system can parse unstructured customer requirement text in real time, automatically complete intelligent selection of hardware components, concurrent detection and conflict resolution of multi-dimensional resource constraints, and generation of flexible pricing ranges. This significantly improves the response speed and accuracy of customized server whole-machine pricing and reduces repeated trial and error in manual configuration.

[0011] The technical effects and advantages provided by the present invention in the above technical solution are as follows: The process involves parsing customer requirement text to extract key requirement items and generating requirement feature vectors. Based on these feature vectors, a feature space is dynamically constructed, encompassing dimensions such as processor, memory, storage, and network interfaces. Each dimension of the feature space is matched against the price elasticity matrix to obtain an independent initial price subspace for each dimension. Building upon this, hardware component models corresponding to price ranges are selected from each initial price subspace and cross-combined to form candidate system configurations. The total power consumption, total heat dissipation, and physical size of each candidate configuration are calculated and compared with the upper limits of power supply capacity, cooling system capacity, and available chassis space, marking three types of resource constraint conflicts and their severity. This configuration-level physical constraint cross-checking, performed during the price generation phase, verifies the physical feasibility of component combinations from different price subspaces before they are output as the final solution. This avoids the problem of configuration schemes being found to have infeasibility issues such as power overload or insufficient heat dissipation only in the later engineering verification stage, as is common in traditional methods. By placing physical constraint verification within the price calculation process, the path from requirement to feasible configuration is shortened.

[0012] Upon detecting resource constraint conflicts, a conflict sorting queue is generated based on conflict severity values. The contraction magnitude and direction identifier are extracted from the conflict resolution strategy library according to the conflict type. Contraction adjustments are then performed on the price subspace of the feature dimensions involved in the conflict, generating adjustment instructions and constructing an adjustment sequence. The resolution strategy library includes priority strategies and cost-priority strategies, which respectively control the priority contraction of non-core feature dimensions or feature dimensions with the largest reduction in unit cost. The contraction magnitude in the adjustment sequence is mapped to the decreasing correction amount of the corresponding elasticity coefficient in the price elasticity matrix. The price elasticity matrix is ​​iteratively corrected, and the price subspace is regenerated using the corrected elasticity coefficient until all resource constraint conflicts are eliminated. The adjustment of the price elasticity coefficient is directly controlled by the resolution magnitude of physical constraint conflicts, forming a closed-loop iterative circuit from constraint conflict detection to elasticity coefficient correction to feasible solution verification. This allows the price parameters to adaptively converge with the physical feasibility state of the configuration scheme, outputting a pricing range and component list that satisfies both customer demand intensity and overall machine physical constraints. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0014] Figure 1 This is a flowchart of a method for intelligent configuration of server system pricing based on customer needs; Figure 2 This is a flowchart illustrating the process of constructing the server's overall feature space based on customer requirement text. Figure 3 This is a flowchart of feature dimension matching and initial price subspace generation; Figure 4 This is a flowchart of the pricing scheme adjustment process based on customer feedback; Figure 5 It is a distribution curve of customer demand intensity coefficient; Figure 6 This is a chart showing the overall performance rating and benchmark price distribution of server hardware components; Figure 7 This is a comparison chart of the price elasticity coefficient distribution before and after iterative correction. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0016] See Figure 1 This invention provides a method for intelligent configuration of server system pricing based on customer needs, comprising: parsing customer demand text and extracting key demand items; generating demand feature vectors based on key demand items; dynamically constructing a feature space for the server system based on the demand feature vectors, wherein the feature space contains multiple feature dimensions, each corresponding to a server hardware component type; performing dimension-by-dimensional matching between the feature dimensions in the feature space and a pre-established price elasticity matrix to obtain an initial price subspace for each feature dimension; detecting resource constraint conflicts between the initial price subspaces, including power consumption constraint conflicts, heat dissipation constraint conflicts, and physical space constraint conflicts; generating conflict resolution paths based on the detected resource constraint conflicts, wherein the conflict resolution paths include an adjustment sequence for shrinking and adjusting the initial price subspaces; iteratively correcting the elasticity coefficients in the price elasticity matrix based on the adjustment sequence until all resource constraint conflicts are eliminated, thereby generating a final pricing scheme.

[0017] Example 1: In specific implementation, please refer to Figure 2When parsing customer requirement text and extracting key requirements, the customer requirement text is input into the word segmentation module. The word segmentation module uses a conditional random field-based word segmentation model to segment the customer requirement text into a word sequence and outputs a requirement word sequence. The method for selecting candidate keywords related to the server's overall configuration from the requirement word sequence is as follows: a server configuration terminology whitelist is pre-established. This whitelist includes processor model, memory specifications, hard drive type, network interface speed, application scenario name, performance description terms, and budget description terms. Each word in the requirement word sequence is traversed; if a word appears in the server configuration terminology whitelist, it is marked as a candidate keyword.

[0018] The candidate keywords are matched with a pre-defined requirement dictionary. This dictionary includes application scenario terms, performance metric terms, and budget range terms. Each term maintains a set of standard keywords. For example, the application scenario term includes standard keywords such as "virtualization consolidation," "database processing," and "artificial intelligence inference"; the performance metric term includes standard keywords such as "high throughput," "low latency," and "large capacity"; and the budget range term includes standard keywords such as "cost-sensitive," "mainstream," and "high-performance." The pre-defined requirement dictionary also includes a thesaurus, which stores a set of synonyms for each standard keyword. For example, the synonym set for the standard keyword "artificial intelligence inference" includes "AI inference" and "inference computation." For each candidate keyword, a precise match is first performed on the standard keywords of the three word classes in the demand dictionary. If a match is successful, the demand category to which the candidate keyword belongs is directly determined. If no match is found in the standard keywords, the candidate keyword is compared with each synonym set in the thesaurus. If it exists in a synonym set, the candidate keyword is mapped to the corresponding standard keyword in that thesaurus, and the demand category to which the candidate keyword belongs is determined. If the candidate keyword neither matches the standard keywords nor any synonyms in the thesaurus, the candidate keyword is discarded.

[0019] After matching and classification, a key requirement item is generated for each non-empty requirement category among the application scenario, performance indicator, and budget range categories. The key requirement item includes a requirement type identifier and a requirement intensity coefficient. The requirement type identifier uses predefined enumeration constants, where "SCENE" corresponds to application scenario, "PERF" to performance indicator, and "BUDGET" to budget range. The requirement intensity coefficient is calculated as follows: for a requirement category, all candidate keywords matched under that category are counted, and the term frequency-inverse document frequency (TNF) value of each candidate keyword in the customer requirement text is obtained. This TNF value is used as the initial weight of the candidate keyword. The initial weight is linearly normalized so that the normalized weight value is within the range [0,1]. The normalized weight values ​​are then summed; if the sum exceeds 1, it is truncated to 1 to obtain the requirement intensity coefficient. All generated key requirement items are arranged in a fixed order of application scenario, performance indicator, and budget range to construct a three-dimensional requirement feature vector base vector, where each position in the base vector corresponds to a requirement category. The demand intensity coefficient for each key demand item is filled into the corresponding position in the base vector, with positions where no key demand items are generated filled with the value 0. This forms the demand feature vector, which is represented as follows: ,in Represents the intensity coefficient of demand in the application scenario. The demand intensity coefficient represents the performance index. This represents the demand intensity coefficient within the budget range.

[0020] In practical implementation, when dynamically constructing the feature space of the entire server based on the demand feature vector, a hardware component mapping table is pre-established. This table uses the demand intensity range as the index key and a list of hardware component models as the storage value. The demand intensity range is divided as follows: the range of demand intensity coefficients [0,1] is divided into three continuous and non-overlapping sub-ranges, where the low-intensity range is […]. , The medium intensity range is [ , The high-intensity range is [ , For each demand intensity coefficient in the demand feature vector, determine the demand intensity interval to which the coefficient falls, and determine the partition of the hardware component mapping table to be retrieved based on the demand category to which the coefficient belongs. Different demand categories use independent hardware component mapping table partitions, and each partition corresponds one-to-one with the application scenario, performance index, and budget range. Extract the list of hardware component models corresponding to the demand intensity interval from the corresponding hardware component mapping table partition. Merge all extracted hardware component model lists and perform deduplication to obtain the initial component set.

[0021] Iterate through each hardware component model in the initial component set and query the pre-built hardware component-dimensional association table. This table records the correspondence between hardware component models and feature dimension identifiers. These identifiers include processor, memory, storage, and network interface identifiers, represented by the strings "CPU", "MEM", "STOR", and "NET", respectively. By querying the table, obtain the feature dimension identifier associated with each hardware component model. Aggregate hardware component models with the same feature dimension identifier into the same feature dimension group, thus forming four feature dimension groups: processor, memory, storage, and network interface.

[0022] Within each feature dimension group, hardware component models are sorted according to performance level, with the ranking determined by a comprehensive performance score. The comprehensive performance score is calculated as follows: the performance scoring function for the processor dimension group is defined as follows: ,in Indicates the number of processor cores. Indicates the processor's base clock speed. and As a weighting factor, The value is 0.6. The value is 0.4, derived from regression analysis of the contribution of core count and clock speed to overall performance in server benchmark tests; the performance scoring function for the memory dimension group is... , Indicates memory capacity. Indicates the memory operating frequency. Take 0.7, Set to 0.3; the performance scoring function for the storage dimension group is... , This indicates the number of input / output operations per second. Indicates transmission bandwidth. Take 0.5, Set to 0.5; the performance scoring function for the network interface dimension group is... , Indicates port speed. We set the value to 1.0. Calculate the comprehensive performance score for each hardware component model within the feature dimension group based on the corresponding performance scoring function. Sort the hardware component models from highest to lowest based on their comprehensive performance scores. Each feature dimension group then forms an ordered list. The ordered lists of all feature dimension groups together constitute a structured representation of the feature space. This structured representation is a mapping structure with feature dimension identifiers as keys and ordered hardware component model lists as values. This mapping structure serves as the input for subsequent dimension-by-dimensional matching and price configuration.

[0023] See Figure 5 In the graph, the horizontal axis represents the customer number, ranging from 0 to 500, and the vertical axis represents the demand intensity coefficient, ranging from 0 to 1. The graph shows the changing trends of three types of demand intensity coefficients: application scenario demand intensity coefficient (solid line connecting dots), performance indicator demand intensity coefficient (dashed line connecting triangles), and budget range demand intensity coefficient (dotted line connecting squares).

[0024] Observing the curve trends, both the application scenario demand intensity coefficient and the performance indicator demand intensity coefficient fluctuate within the range of 0.4 to 0.85, and their trends are quite similar and frequently intersect. This indicates that in multiple customer demand texts, the term frequency-inverse document frequency values ​​of keywords related to application scenarios and performance indicators are relatively prominent, and the corresponding demand intensity coefficients are all in the medium-to-high intensity range. This reflects the characteristics of parsing customer demand texts and calculating demand intensity coefficients in Example 1. Specifically, the application scenario demand intensity coefficient repeatedly peaked above 0.8, reflecting the strong demand of some customers for specific application scenarios; the performance indicator demand intensity coefficient also repeatedly reached similar levels, indicating that performance indicator demand accounts for a significant proportion of user demand.

[0025] In contrast, the demand intensity coefficient curve for the budget range is significantly lower than the previous two, maintaining a low intensity range of 0 to 0.25 overall, with a small fluctuation range and no obvious peak fluctuations. This indicates that most customers have low word frequency-inverse document frequency values ​​for budget range-related demands, and budget demands are relatively less obvious than application scenario and performance indicator demands. This is consistent with the actual case in Example 1 where the budget range demand category is assigned a value at the corresponding position in the demand feature vector.

[0026] Combining the overall trend of the three curves in the graph, we can see the demand feature vector. middle and The values ​​are relatively close to and higher than This figure reflects the intensity characteristics of key requirement items extracted from customer requirement text in Example 1. It effectively illustrates the practical application effect of the requirement intensity coefficient calculation step in Example 1 and its accurate representation of customer requirements.

[0027] Example 2: In specific implementation, please refer to Figure 3When performing dimension-by-dimensional matching based on the feature dimensions in the feature space and the pre-established price elasticity matrix, the feature space is a structured representation that includes processor, memory, storage, and network interface dimensions. Each feature dimension contains a list of hardware component models sorted by performance level. A feature dimension is sequentially extracted from the feature space as the current matching dimension, specifically by traversing the mapping structure of the feature space, processing one feature dimension before moving on to the next.

[0028] Retrieve the dimension identifier of the current matching dimension and the list of hardware component models within the dimension. The dimension identifier is a string constant, namely "CPU", "MEM", "STOR", and "NET". The list of hardware component models is an ordered sequence containing all candidate hardware component models under this dimension.

[0029] The price elasticity matrix is ​​used to locate the row vector of elasticity coefficients corresponding to the dimension identifiers. The price elasticity matrix employs a sparse matrix storage format, storing only the dimension identifiers and model combinations corresponding to non-zero elasticity coefficients. This sparse matrix storage format is implemented using a mapping container. The key of the mapping container is the dimension identifier, and the value is an array of records. Each element in the array consists of a model combination field and an elasticity coefficient field. The model combination field stores a hardware component model, and the elasticity coefficient field stores the corresponding price elasticity coefficient value. Dimension identifiers not appearing in the price elasticity matrix indicate that the price elasticity coefficients of all hardware component models under that dimension are zero. For dimension identifiers that appear, only hardware component models with non-zero elasticity coefficients under that dimension will occupy a record in the record array; hardware component models with zero elasticity coefficients are not stored. The price elasticity coefficients reflect the adjustment range of market supply and demand fluctuations and component generational updates on the benchmark price. The values ​​of the price elasticity coefficients are derived from offline statistical analysis. The average elasticity coefficient for each model is calculated by collecting the ratio of hardware component transaction prices over several quarters to the benchmark price, and this average is periodically updated in the price elasticity matrix.

[0030] After obtaining the elasticity coefficient row vector corresponding to the dimension identifier, the elasticity coefficient row vector corresponds to the record array. The hardware component model list within the dimension is cross-referenced with the model combinations in the elasticity coefficient row vector. The cross-reference process is as follows: Each hardware component model in the hardware component model list is traversed. For each hardware component model, the record array of the elasticity coefficient row vector is searched for a record whose model combination field is completely identical to that hardware component model. If a completely identical record exists, the price elasticity coefficient in that record is extracted, marked as the matching elasticity coefficient corresponding to that hardware component model, and that hardware component model is added to the matching model set. If no completely identical record exists, then that hardware component model does not have a matching elasticity coefficient, and a price range is not generated for it in the initial price subspace of this feature dimension.

[0031] After filtering out all hardware component models with matching elasticity coefficients, a pre-defined price benchmark vector is obtained. The price benchmark vector is a global benchmark price table, indexed by hardware component model, storing the benchmark price for each model. The benchmark price is determined by the official catalog price provided by the server component vendor. For each hardware component model in the matching model set, its benchmark price is extracted from the price benchmark vector, and the matching elasticity coefficient is multiplied by this benchmark price to calculate the benchmark adjusted price. The benchmark adjusted price represents the basic pricing reference value for that hardware component model after considering demand elasticity and market price changes.

[0032] Optionally, to characterize the price fluctuations allowed in actual sales, a preset price fluctuation ratio is set. The price range corresponding to each hardware component model in the initial price subspace is obtained by adjusting the benchmark price upwards and downwards, and the specific calculation uses the following formula:

[0033] in: Indicates hardware component model The benchmark price corresponding to the price benchmark vector. A unique identifier for the hardware component model; Indicates hardware component model The corresponding matching elasticity coefficient; This indicates the preset price fluctuation percentage. The value is set based on the historical price fluctuation data of server complete machine sales. It takes the average deviation rate of the actual transaction price of components relative to the quoted price in all complete machine orders in the past 12 months. If the average deviation rate is less than 0.03, it takes 0.03; if it is greater than 0.08, it takes 0.08; otherwise, it takes the actual average deviation rate.

[0034] Based on the formula above, a price range is calculated for each matched hardware component model. All price ranges together constitute the initial price subspace for the current matching dimension. Each price range in the initial price subspace corresponds one-to-one with a hardware component model. The above matching process is performed on all feature dimensions in the feature space, ultimately yielding the initial price subspaces for the processor, memory, storage, and network interface dimensions.

[0035] See Figure 6 The chart shows the distribution of overall performance scores and corresponding benchmark prices for hardware component models across four feature dimensions: processor, memory, storage, and network interface. The horizontal axis represents the overall performance score, and the vertical axis represents the benchmark price (in yuan). Different symbols in the legend correspond to the four feature dimensions: solid circles represent the processor dimension, solid triangles represent the memory dimension, solid squares represent the storage dimension, and solid diamonds represent the network interface dimension.

[0036] As can be seen from the figure, the overall performance scores of hardware components in the processor and memory dimensions are relatively small. The overall performance scores of the processor dimension are concentrated in the range of 0 to 55, while the overall performance scores of the memory dimension are concentrated in the range of 0 to 50. Moreover, the base price of both shows a clear positive correlation with the increase of the overall performance score. In particular, the price of the processor dimension rises rapidly with the increase of the performance score, with the price range ranging from about 1,000 yuan to 7,000 yuan, reflecting the strong relationship between the hardware performance level and price elasticity in the processor dimension.

[0037] The overall performance score for storage is wide-ranging, covering a range of approximately 0 to 500. The price distribution is relatively dispersed and covers a wide range, from several hundred yuan to over six thousand yuan. This shows that the relationship between the performance score and price of storage hardware component models is complex, and the price elasticity varies widely.

[0038] The overall performance score and benchmark price of the network interface dimension are both low. The performance score is concentrated between 0 and 100, and the price fluctuates between 0 and 1000 yuan. Moreover, the price and performance score show a weak positive correlation, reflecting that the price elasticity of the network interface dimension is relatively low and the price range is narrow.

[0039] Overall, the hardware component models for each feature dimension in the figure are generated according to the feature dimension groups sorted by performance score as described in Example 2. The elasticity coefficients stored in the price elasticity matrix correspond to the benchmark prices of different hardware component models in the figure. The data shown in the figure is the input basic data in the dimension-by-dimensional matching process. By combining the distribution trends of performance scores and benchmark prices, the matching basis of the price elasticity matrix and feature space in this embodiment of the invention is demonstrated.

[0040] Example 3: In practical implementation, when detecting resource constraint conflicts between initial price subspaces, each initial price subspace consists of a set of price ranges for the processor, memory, storage, and network interface dimensions. Each feature dimension's initial price subspace contains price ranges corresponding to one or more hardware component models. The method for selecting a price range from each initial price subspace employs a Cartesian product combination strategy: traversing all price ranges in the processor dimension's initial price subspace, and for each processor dimension price range, traversing all price ranges in the memory dimension's initial price subspace, and so on, until all price ranges for the four feature dimensions are combined. Each combination contains four price ranges, corresponding to the processor, memory, storage, and network interface dimensions, respectively. The hardware component models corresponding to the four price ranges in each combination are extracted to form a candidate system configuration. The candidate system configuration consists of four fields: processor hardware component model, memory hardware component model, storage hardware component model, and network interface hardware component model.

[0041] For each candidate system configuration, the total power consumption is obtained. This is achieved by: pre-setting a component power consumption database, indexed by hardware component model, storing typical power consumption values ​​for each hardware component model under its design power consumption. These typical power consumption values ​​are derived from the technical specifications provided by the hardware component manufacturers. The database is then used to query the typical power consumption values ​​for the processor, memory, storage, and network interface hardware components in the candidate system configuration. These four typical power consumption values ​​are summed to obtain the total power consumption of the candidate system configuration. This total power consumption is then compared to a pre-set upper limit for power supply capacity. This upper limit is determined based on the rated power of the power supply module in the target server chassis, and is set to 85% of the rated power of the power supply module. If the total power consumption exceeds the upper limit, the candidate system configuration is marked as having a power consumption constraint conflict. Simultaneously, a power consumption excess ratio is calculated as the degree of conflict, calculated as the difference between the total power consumption and the upper limit for power supply capacity, divided by the upper limit for power supply capacity.

[0042] The total heat dissipation value of the candidate system configuration is obtained. This value is obtained by: pre-setting a component heat dissipation database, indexed by hardware component model, storing the thermal design power (TDP) of each hardware component model under full load. The TDP values ​​are derived from the thermal specifications provided by the hardware component manufacturers. The TDP values ​​for the four hardware component models in the candidate system configuration are retrieved from the component heat dissipation database, and these four TDP values ​​are summed to obtain the total heat dissipation value of the candidate system configuration. This total heat dissipation value is compared with a pre-set upper limit for the cooling system capacity. The upper limit for the cooling system capacity is determined by the maximum cooling capacity of the cooling fan assembly and the airflow design of the target server chassis. The upper limit for the cooling system capacity is the total heat dissipation of the cooling fan assembly at its highest speed multiplied by a heat dissipation efficiency coefficient. A heat dissipation efficiency coefficient of 0.9 indicates that the cooling system maintains 90% cooling efficiency under actual operating conditions. If the total heat dissipation exceeds the upper limit of the heat dissipation system capacity, the candidate system configuration is marked as having a heat dissipation constraint conflict. At the same time, the heat dissipation excess ratio is calculated as the conflict degree value of the heat dissipation constraint conflict. The heat dissipation excess ratio is the difference between the total heat dissipation and the upper limit of the heat dissipation system capacity, divided by the upper limit of the heat dissipation system capacity.

[0043] Obtain the physical dimensions of each hardware component model in the candidate system configuration. The physical dimensions are determined as follows: A pre-built component physical dimension database is established, indexed by the hardware component model, storing the length, width, and height of each hardware component model in millimeters. The database is then used to query the length, width, and height of each of the four hardware component models in the candidate system configuration. For each hardware component model, its physical volume is calculated as length multiplied by width multiplied by height. The volumes of the four hardware component models are summed to obtain the total volume of the candidate system configuration. Considering the need to maintain gaps between components and the space occupied by cables during actual assembly, the total volume is multiplied by a space utilization factor. This factor is set to 1.25, indicating that the actual volume occupied is 1.25 times the sum of the component volumes. The total volume multiplied by the space utilization factor is compared with the pre-built available chassis space. The available chassis space is the effective volume of the available assembly space inside the server chassis, calculated from the available internal length, width, and height indicated in the chassis design drawings. If the total occupied volume exceeds the available chassis space, the candidate system configuration is marked as having a physical space constraint conflict. At the same time, the space excess ratio is calculated as the conflict degree value of the physical space constraint conflict. The space excess ratio is the difference between the total occupied volume and the available chassis space, divided by the available chassis space.

[0044] Following the above method, all possible candidate system configuration combinations are traversed. For each candidate system configuration, the type and severity of resource constraint conflicts are recorded. Candidate system configurations without any resource constraint conflicts are marked as feasible and recorded separately; their corresponding four price range combinations become one source of subsequent feasible pricing solutions. For candidate system configurations with resource constraint conflicts, their conflict type, conflict severity, and the model information of the four hardware components involved are recorded together in a conflict record table. The conflict record table structure includes a candidate configuration identifier field, a conflict type field, a conflict severity value field, and a set of involved feature dimensions field.

[0045] In practice, when generating conflict resolution paths based on detected resource constraint conflicts, all resource constraint conflicts in the conflict record table are sorted from highest to lowest conflict severity value. The conflict severity value is the maximum conflict excess ratio among the various conflict types that may exist in the candidate system configuration. If power consumption constraint conflict, heat dissipation constraint conflict, and physical space constraint conflict exist simultaneously, the conflict severity value is the maximum of the power consumption excess ratio, heat dissipation excess ratio, and space excess ratio. After sorting, a conflict sorting queue is generated. Each element in the conflict sorting queue represents a resource constraint conflict, containing the models of the four hardware components involved in the candidate system configuration corresponding to that resource constraint conflict, the conflict type, and the conflict severity value.

[0046] The resource constraint conflict with the highest conflict severity value is selected from the conflict sorting queue as the current conflict to be processed. The set of feature dimensions involved in the current conflict is then determined. The set of feature dimensions is determined as follows: if the current conflict type is only a power consumption constraint conflict or a heat dissipation constraint conflict, then the set of feature dimensions includes all four feature dimensions of the candidate system configuration that generated the conflict; if the current conflict type is only a physical space constraint conflict, then the set of feature dimensions includes the feature dimensions corresponding to the two hardware component models with the largest volume in the candidate system configuration that generated the conflict; if the current conflict includes multiple conflict types, then the set of feature dimensions includes the union of the feature dimensions involved in all conflict types.

[0047] Based on the type of conflict being resolved, the corresponding resolution operation sequence is extracted from the resolution strategy library. The library contains three pre-defined entries: power consumption constraint resolution strategy, heat dissipation constraint resolution strategy, and physical space constraint resolution strategy. Each strategy entry stores a corresponding resolution operation sequence, which consists of multiple resolution steps. Each step includes a shrinkage magnitude value and a shrinkage direction identifier. The shrinkage direction identifier indicates whether to shrink towards the lower price range or the higher price range in the initial price subspace of the corresponding feature dimension. Specifically, it takes two values: "LOW" and "HIGH." In resource constraint conflict resolution scenarios, the shrinkage direction identifier is fixed at "LOW," meaning shrinking towards lower-priced hardware components to reduce resource consumption. The shrinkage magnitude value is a percentage, representing the percentage by which the lower limit of the current price range needs to be shifted upwards in the price subspace of the corresponding feature dimension. The shrinkage magnitude value is expressed as a percentage of the price range span.

[0048] The conflict resolution strategy library also includes two policy control logics: priority policy and cost priority policy. The priority policy prioritizes shrinking the price subspace of non-core feature dimensions (memory and network interface dimensions), while core feature dimensions include processor and storage dimensions. When the priority policy is enabled, for the set of feature dimensions involved in the current conflict resolution, resolution operation sequences are first generated on the memory and network interface dimensions. The shrinkage magnitude is then evenly distributed across these sequences. If the resolution on the memory and network interface dimensions cannot completely resolve the conflict, then resolution operation sequences are generated on the processor and storage dimensions. The cost priority policy prioritizes shrinking the feature dimensions with the largest unit cost reduction. The unit cost reduction is calculated using a pre-defined component price gradient table, which records the price reduction corresponding to each hardware component model being downgraded by one performance level. When the cost-first strategy is enabled, it iterates through all hardware component models in the feature dimension set involved in the current conflict resolution, queries the component price gradient table to obtain the unit cost reduction of each hardware component model, sorts them from largest to smallest unit cost reduction, and assigns the resolution operation sequence to the feature dimension with the largest unit cost reduction.

[0049] The total amount of contraction magnitude in the resolution operation sequence is determined as follows: The conflict severity value of the current conflict being processed is compared with the conflict resolution threshold, which is set to 0.05. If the conflict severity value is less than or equal to the conflict resolution threshold, the total contraction magnitude is the conflict severity value multiplied by the price range of the relevant hardware component models in the candidate system configurations involved in the conflict. If the conflict severity value is greater than the conflict resolution threshold, the total contraction magnitude is the conflict severity value multiplied by the price range and then multiplied by an acceleration resolution coefficient, which is set to 1.5. The acceleration resolution coefficient is chosen to provide sufficient contraction space in a single adjustment to reduce the number of iterations. After the total amount of contraction magnitude is determined, it is allocated to each resolution step according to the aforementioned priority strategy or cost-first strategy.

[0050] The resolution operation sequence is applied to the initial price subspace corresponding to the set of feature dimensions involved in the current conflict resolution. For each resolution step in the sequence, the contraction magnitude and contraction direction identifier are extracted. In the initial price subspace of the corresponding feature dimension, the price range of the currently matched hardware component model within that feature dimension is contracted. The contraction method involves shifting the lower limit of the price range upward by the contraction magnitude. Specifically, the original lower limit price of the price range is extracted, and the original lower limit price is multiplied by (1 plus the contraction magnitude) to obtain the new lower limit price. The upper limit of the price range remains unchanged. A single adjustment instruction is generated to contract and adjust the initial price subspace. The data structure of the single adjustment instruction includes an instruction identifier, a target feature dimension identifier, a target hardware component model, a contraction magnitude, and an adjusted price range.

[0051] A single adjustment instruction is added to the end of the adjustment sequence. After completing the current conflict resolution operation sequence, the candidate system configuration is reconstructed based on the adjusted initial price subspace, and the conflict severity value of the current conflict is recalculated according to the resource constraint conflict detection method described above. If the conflict severity value is still greater than the conflict tolerance threshold (set to 0.02, where 0.02 represents resource consumption exceeding the upper limit by less than 2% considered within an acceptable safety margin), the current conflict is re-inserted into the conflict sorting queue, with the re-insertion position sorted according to the new conflict severity value. If the conflict severity value is less than or equal to the conflict tolerance threshold, the current conflict is removed from the conflict sorting queue. This process is repeated, with the resource constraint conflict with the highest conflict severity value being processed each time, until the conflict sorting queue is empty. When the conflict sorting queue is empty, it indicates that all detected resource constraint conflicts have been resolved below the conflict tolerance threshold, and a complete adjustment sequence is output as the conflict resolution path.

[0052] Example 4: In practical implementation, when iteratively correcting the elasticity coefficients in the price elasticity matrix based on the adjustment sequence, the adjustment sequence is a linear set of ordered adjustment instructions generated by the conflict resolution path. Each adjustment instruction in the adjustment sequence includes an instruction identifier, a target feature dimension identifier, a target hardware component model, a contraction magnitude value, and an adjusted price range. An adjustment instruction is sequentially retrieved from the adjustment sequence in the natural order of its arrangement. The retrieval method involves maintaining an instruction processing pointer, which initially points to the first element of the adjustment sequence. After each retrieval, the instruction processing pointer is shifted one position to the right.

[0053] For the retrieved adjustment instruction, obtain the target feature dimension identifier and the target contraction magnitude value pointed to by the adjustment instruction. The target feature dimension identifier is one of "CPU", "MEM", "STOR", or "NET", and the target contraction magnitude value is the contraction magnitude value recorded in the adjustment instruction. The contraction magnitude value is a floating-point number greater than zero, representing the percentage by which the lower limit of the price range needs to be shifted upward.

[0054] Locate the row vector of elasticity coefficients corresponding to the target feature dimension identifier in the price elasticity matrix. The price elasticity matrix uses a sparse matrix storage format, with the dimension identifier as the key indexing the corresponding record array. Extract the elasticity coefficients to be corrected from the elasticity coefficient row vectors that are associated with the adjustment instruction. The association method is as follows: search the record array of the elasticity coefficient row vector for records where the model combination field is completely consistent with the target hardware component model in the adjustment instruction. If a consistent record is found, mark the elasticity coefficient in that record as the elasticity coefficient to be corrected; if no consistent record is found, it indicates that the target hardware component model originally did not have a non-zero elasticity coefficient in the price elasticity matrix. In this case, add a new record to the record array, fill the target hardware component model in the model combination field of the new record, set the initial value of the elasticity coefficient to 1.0, and use this elasticity coefficient as the elasticity coefficient to be corrected.

[0055] The elasticity coefficient to be corrected is adjusted decreasingly according to the target contraction magnitude. The specific calculation for the decreasing adjustment is as follows:

[0056] in: Indicates the target hardware component model The corresponding elastic coefficient to be corrected, A unique identifier for the target hardware component model; Indicates the target contraction magnitude value. The value range of is (0,1). The value is obtained directly from the adjustment command; This represents the elasticity coefficient after a decreasing adjustment. The formula means that the elasticity coefficient to be corrected is reduced proportionally to the contraction magnitude; the reduced elasticity coefficient reflects the degree to which prices contract towards lower levels due to the alleviation of resource constraints.

[0057] The result after decreasing adjustment Write back the elasticity coefficient field of the corresponding record in the price elasticity matrix, replacing the original elasticity coefficient to be corrected. After completing the elasticity coefficient correction, re-execute the dimension-by-dimensional matching operation using the price elasticity matrix replaced with the corrected elasticity coefficient. Specifically, for the target feature dimension, use the decreasing elasticity coefficient. Replace the original matching elasticity coefficient, and Multiplying the price range by the base price corresponding to the target hardware component model in the price benchmark vector yields the shrunken price range. The shrunken price subspace replaces the price subspace portion of the original initial price subspace corresponding to the feature dimension. The replacement range covers the price range corresponding to the target hardware component model involved in the adjustment instruction, while the price ranges for other hardware component models under the same feature dimension remain unchanged.

[0058] After replacing the original initial price subspace with the shrunken price subspace, resource constraint conflict detection is re-executed. The resource constraint conflict detection process is consistent with the initial constraint detection process, namely, traversing all combinations of feature dimension price subspaces to generate candidate system configurations. For each candidate system configuration, the total power consumption, total heat dissipation, and total occupied volume are calculated and compared with the upper limits of power supply capacity, cooling system capacity, and available chassis space, respectively. If a new resource constraint conflict is detected, supplementary adjustment instructions are generated based on the new resource constraint conflict. The generation method for supplementary adjustment instructions is as follows: the newly detected resource constraint conflict is added to the conflict sorting process, sorted according to the conflict severity value, and resolved sequentially to generate new adjustment instructions, which are then appended to the end of the adjustment sequence. If no new resource constraint conflict is detected, the next adjustment instruction in the adjustment sequence is processed. The instruction processing pointer is moved forward and the next adjustment instruction is retrieved from the adjustment sequence. The complete process of obtaining the target feature dimension, correcting the elasticity coefficient, replacing the price subspace, and re-detecting constraints is repeated.

[0059] When all adjustment instructions in the adjustment sequence have been processed, i.e., the instruction processing pointer has exceeded the end of the adjustment sequence, an iterative correction is completed. After completing an iterative correction, the values ​​of each elasticity coefficient in the price elasticity matrix after this iterative correction are recorded. The change in the price elasticity matrix before and after the iterative correction is calculated as follows: a snapshot of the price elasticity matrix before this iterative correction is obtained. The elasticity coefficients of all hardware component models in all dimensions of the snapshot of the price elasticity matrix before the iterative correction are compared item by item with the corresponding elasticity coefficients in the price elasticity matrix after this iterative correction. For each pair of elasticity coefficients, the absolute value of the difference between the two is calculated. The absolute values ​​of all differences are summed to obtain the total change in elasticity coefficients. The total change in elasticity coefficients is compared with a convergence threshold, which is set to 0.001. A convergence threshold of 0.001 indicates that when the total change in elasticity coefficients is less than one-thousandth, the price elasticity matrix is ​​considered to have entered a stable state and no further iterative correction is needed.

[0060] If the total change in elasticity coefficients is less than the convergence threshold, the iteration stops, and the price elasticity matrix corrected in this iteration is output as the final price elasticity matrix. If the total change in elasticity coefficients is greater than or equal to the convergence threshold, the initial price subspace is regenerated based on the price elasticity matrix corrected in this iteration. This is achieved by re-performing a dimension-by-dimensional matching operation between the corrected price elasticity matrix and the price benchmark vector to obtain a new initial price subspace. Based on the new initial price subspace, the resource constraint conflict detection and conflict resolution path generation process is re-executed to generate a new adjustment sequence, and the next iteration is performed based on this new adjustment sequence. This iterative correction process is repeated until the total change in elasticity coefficients is less than the convergence threshold.

[0061] In practical implementation, when generating the final pricing scheme, the final price subspace corresponding to the price elasticity matrix after iterative correction is obtained. The final price subspace is obtained by performing a dimension-by-dimensional matching between the final price elasticity matrix and the price benchmark vector, and calculating the price range for each hardware component model using the same preset price fluctuation ratio, resulting in the final price subspaces for the processor dimension, memory dimension, storage dimension, and network interface dimension. Each final price subspace contains the price range corresponding to one or more hardware component models.

[0062] The method for selecting a price range from each final price subspace is as follows: traverse all combinations of final price subspaces to generate multiple candidate system configurations. Perform resource constraint conflict detection on each candidate system configuration, and filter out candidate system configurations that do not generate any resource constraint conflicts. Among the candidate system configurations that do not generate conflicts, select the candidate system configuration with the lowest base price as the final system configuration. The four price ranges contained in the final system configuration are the selected price ranges.

[0063] Obtain the unit price of each hardware component model in the final system configuration. The unit price is the midpoint value of the corresponding price range. The midpoint value of the price range is calculated by adding the lower limit and the upper limit of the price range and then dividing by two. Add up the unit prices of the processor, memory, storage, and network interface hardware components in the final system configuration to obtain the base price.

[0064] The price fluctuation range is calculated based on the difference between the upper and lower limits of each price interval in the final price subspace. The price fluctuation range consists of two parts: a lower limit fluctuation value and an upper limit fluctuation value. The lower limit fluctuation value is calculated by summing the lower limits of the price intervals for each of the four hardware component models in the final system configuration, and then subtracting the sum of the lower limits from the base price. The upper limit fluctuation value is calculated by summing the upper limits of the price intervals for each of the four hardware component models in the final system configuration, and then subtracting the base price from the sum of the upper limits. The lower limit fluctuation value minus the base price is the lower limit of the pricing range, and the upper limit fluctuation value plus the base price is the upper limit of the pricing range. The combination of the lower and upper limits of the pricing range constitutes the final pricing range.

[0065] A resource constraint pass flag is generated. This flag is a Boolean variable; a true value indicates that the final system configuration has passed all resource constraint checks. The final system configuration's component model list, pricing range, and resource constraint pass flag are packaged into a structure. The component model list includes text descriptions of the processor, memory, storage, and network interface hardware component models. The pricing range includes the lower and upper limits of the pricing range. This structure is serialized into the system's standard output format as the final pricing scheme.

[0066] See Figure 7The figure illustrates a comparison of the distribution of elasticity coefficients before and after iterative correction of the price elasticity matrix based on the adjustment sequence in Example 4. The horizontal axis represents the price elasticity coefficient, ranging from approximately 0.3 to 2.5, while the vertical axis represents the number of hardware component models, reflecting the frequency of the corresponding hardware component models within each elasticity coefficient range. Two different fill styles are used in the figure to distinguish between the "elasticity coefficient before iterative correction" and the "elasticity coefficient after iterative correction": the former is represented by a diagonal line fill, and the latter by a diagonal line fill with a dashed border.

[0067] As shown in the figure, before the iterative correction, the elasticity coefficients were concentrated in the range of 1.1 to 1.6, with nearly 100 peak hardware component models, indicating that most hardware component models had relatively high elasticity coefficients. After the iterative correction, the elasticity coefficients shifted significantly to the left (towards lower values), concentrated in the range of 0.9 to 1.3, with approximately 115 peaks. The peak positions decreased by about 0.3 compared to before the correction, indicating that through iterative correction based on the adjustment sequence, the price elasticity coefficients decreased overall, reflecting the trend of prices contracting towards lower price ranges during the process of resource constraint mitigation.

[0068] Furthermore, the distribution curve of the elasticity coefficient after iterative correction is more concentrated than before correction, and the extension of the tail towards high elasticity coefficients is significantly reduced, indicating that the extreme high values ​​of the elasticity coefficients have been effectively suppressed, thus improving the stability and rationality of price adjustments. This distribution change corresponds to the specific operation of the adjustment sequence in Example 4 to decrease the elasticity coefficients in the price elasticity matrix, reflecting the process of gradually eliminating resource constraint conflicts and guiding the price scheme towards rationality and stability through continuous iterative correction.

[0069] In summary, the adjustment trend of the elasticity coefficient distribution shown in the figure verifies the effectiveness of the price elasticity matrix based on the iterative correction of the adjustment sequence described in Example 4. The overall decrease and distribution convergence of the elasticity coefficients indicate that the iterative correction gradually reaches the convergence threshold, ultimately achieving the goal of optimizing the pricing scheme and eliminating resource constraints in the intelligent configuration of server whole machine prices to meet customer needs.

[0070] Example 5: In specific implementation, please refer to Figure 4After generating the final pricing plan, the system collects customer feedback through a client interface or program call API. The feedback data structure consists of two parts: a feedback type field and an adjustment description text field. The feedback type field takes the value of an enumerated constant, which includes three flags: Accept Feedback Flag, Adjust Feedback Flag, and Reject Feedback Flag, represented by the string constants "ACCEPT", "ADJUST", and "REJECT", respectively. The adjustment description text field is a variable-length string. When the feedback type is adjustment feedback, the adjustment description text field stores the natural language adjustment instructions filled in by the customer; when the feedback type is accept feedback or reject feedback, the adjustment description text field can be empty.

[0071] After receiving feedback, the system checks the feedback type field. If the feedback type is "acceptance feedback," the final pricing plan is confirmed, and the process ends. If the feedback type is "rejection feedback," the pricing configuration process terminates. If the feedback type is "adjustment feedback," the system enters the adjustment processing flow, extracting the adjustment direction indication from the adjustment feedback.

[0072] When extracting adjustment direction instructions from the adjustment feedback, the adjustment description text in the feedback is parsed. The adjustment description text is parsed by inputting it into a pre-defined adjustment intent parsing module. This module contains a word segmenter and a keyword classifier. The word segmenter uses the same conditional random field-based segmentation model as when parsing customer requirement text, segmenting the adjustment description text into word sequences and outputting an adjustment word sequence. The keyword classifier maintains two keyword sets: a performance-related keyword set and a cost-related keyword set. The performance-related keyword set includes words semantically related to performance improvement, such as "faster," "increased computing power," "enhanced processor," "expanded memory," "improved storage performance," "high throughput," and "reduced latency." The cost-related keyword set includes words semantically related to cost reduction, such as "price reduction," "cost saving," "budget reduction," "economical," "lower price," "reduced expenses," and "controllable spending."

[0073] Iterate through each word in the adjustment word sequence, performing an exact match between each word and both the performance-related keyword set and the cost-related keyword set. If the word exists in the performance-related keyword set, increment the performance-related keyword count; if it exists in the cost-related keyword set, increment the cost-related keyword count. After matching all words, compare the performance-related keyword count with the cost-related keyword count. If the performance-related keyword count exceeds the cost-related keyword count, the adjustment direction is determined to be performance improvement; if the cost-related keyword count exceeds the performance-related keyword count, the adjustment direction is determined to be cost reduction; if the performance-related keyword count and the cost-related keyword count are equal, the adjustment direction is determined to be cost reduction, and cost reduction is set as the default adjustment direction.

[0074] After determining the adjustment direction indication, the corresponding adjustment magnitude value is calculated. For performance improvement direction adjustments, performance degree adverbs appearing in the adjustment description text are extracted and stored in a pre-defined performance degree adverb mapping table. The performance degree adverb mapping table is a key-value pair structure, where the key is the degree adverb text and the value is the corresponding adjustment magnitude impact factor. The performance degree adverb mapping table contains the following entries: "slightly" corresponds to an impact factor of 0.1, "somewhat" corresponds to an impact factor of 0.1, "moderately" corresponds to an impact factor of 0.2, "significantly" corresponds to an impact factor of 0.35, "significantly" corresponds to an impact factor of 0.5, and "extremely" corresponds to an impact factor of 0.6. All words in the adjustment description text are traversed. If a word matches the key set in the performance degree adverb mapping table, the corresponding impact factor is obtained. All matched impact factors are summed, and the sum is used as the adjustment magnitude value for the performance improvement direction adjustment. If no performance degree adverb is matched in the adjustment description text, the adjustment magnitude of the performance improvement direction adjustment will be the default value of 0.2. The default value of 0.2 is based on the statistical results of the average expected performance improvement magnitude when customers did not specify the degree in historical adjustment feedback.

[0075] For cost reduction adjustments, cost degree adverbs appearing in the adjustment description text are extracted and stored in a pre-defined cost degree adverb mapping table. The cost degree adverb mapping table is a key-value pair structure, where the key is the degree adverb text and the value is the corresponding adjustment magnitude impact factor. The cost degree adverb mapping table contains the following entries: "slightly reduced" corresponds to an impact factor of 0.1, "slightly reduced" corresponds to an impact factor of 0.1, "appropriately reduced" corresponds to an impact factor of 0.2, "significantly reduced" corresponds to an impact factor of 0.35, "significantly reduced" corresponds to an impact factor of 0.5, and "maximum compression" corresponds to an impact factor of 0.6. All words in the adjustment description text are traversed. If a word matches a key in the cost degree adverb mapping table, its corresponding impact factor is obtained. All matched impact factors are summed, and the sum is used as the adjustment magnitude value for the cost reduction direction adjustment. If no cost degree adverb is matched in the adjustment description text, the adjustment magnitude value for the cost reduction direction adjustment is set to the default value of 0.2. The default value of 0.2 is based on the statistical results of the average expected cost reduction magnitude in historical adjustment feedback when customers did not specify the degree.

[0076] After obtaining the adjustment direction indication and adjustment magnitude value, these are encoded into an adjustment vector. The adjustment vector has the same dimension as the requirement feature vector, both being three-dimensional vectors. The three dimensions correspond to the application scenario requirements, performance indicator requirements, and budget range requirements, respectively. The encoding rule is as follows: if the adjustment direction indication is a performance improvement direction adjustment, then the element value at the position corresponding to the performance indicator requirement in the adjustment vector is set to... The element value corresponding to the application scenario requirement is set to 1.0, and the element value corresponding to the budget range requirement is also set to 1.0. This represents the adjustment magnitude for performance improvement; if the adjustment direction indicates cost reduction, then the element value corresponding to the budget interval demand in the adjustment vector is set to... The element value corresponding to the application scenario requirement is set to 1.0, and the element value corresponding to the performance indicator requirement is also set to 1.0. This represents the adjustment magnitude for the cost reduction direction. The adjustment vector is represented as... , Represents the application scenario adjustment factor. Represents the performance indicator adjustment factor. This represents the budget range adjustment factor, and the value of the adjustment factor follows the coding rules described above.

[0077] After generating the adjustment vector, use the adjustment vector to adjust the required feature vector. Then, adjust the adjustment vector... Adjustment factors and demand feature vectors The demand intensity coefficients at corresponding positions are multiplied to generate the adjusted demand feature vector. The adjusted demand feature vector is represented as follows: The adjusted application scenario demand intensity coefficient Equal to the original application scenario demand intensity coefficient Multiply by the application scenario adjustment factor Adjusted performance index demand intensity coefficient Equal to the original performance index demand intensity coefficient Multiply by performance index adjustment factor Adjusted budget range demand intensity coefficient equal to the demand intensity coefficient of the original budget range Multiply by the budget range adjustment factor If any adjusted demand intensity coefficient exceeds the range [0,1], then a truncation process is performed: if the adjusted demand intensity coefficient is greater than 1, it is set to 1; if the adjusted demand intensity coefficient is less than 0, it is set to 0.

[0078] The adjusted demand feature vector is used to re-execute the complete steps from dynamically constructing the feature space to generating the final pricing plan. The re-executed steps include: based on each demand intensity coefficient in the adjusted demand feature vector, extracting the corresponding hardware component model through a hardware component mapping table to form an initial component set; traversing the initial component set to query feature dimension identifiers and aggregating and sorting them to dynamically construct a new feature space; matching the feature dimensions in the new feature space with the price elasticity matrix dimension-by-dimensional to obtain a new initial price subspace; detecting resource constraint conflicts between the new initial price subspaces and generating new conflict resolution paths and adjustment sequences; iteratively correcting the elasticity coefficients in the price elasticity matrix based on the new adjustment sequences, eliminating all resource constraint conflicts, and generating a new final pricing plan. The new final pricing plan is then output to the customer again, and the feedback collection phase re-enters until the customer's feedback indicates acceptance, at which point the entire pricing configuration process terminates.

[0079] Optionally, the intelligent configuration system for server pricing based on customer needs includes a memory, a processor, and a computer program stored in the memory and running on the processor. The memory stores a demand dictionary, a thesaurus, a hardware component mapping table, a price elasticity matrix, a price benchmark vector, a component power consumption database, a component heat dissipation database, a component physical size database, a resolution strategy library, and demand feature vectors, feature space, initial price subspace, resource constraint conflict data, adjustment sequences, and the final pricing scheme generated during intermediate calculations. When the processor executes the computer program, it implements all the steps of the intelligent configuration method for server pricing based on customer needs described in the above embodiments.

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

Claims

1. A method for intelligent configuration of server system pricing based on customer needs, characterized in that: include: Parse the customer requirement text and extract key requirement items, and generate requirement feature vectors based on the key requirement items; The feature space of the entire server is dynamically constructed based on the demand feature vector. The feature space contains multiple feature dimensions, and each feature dimension corresponds to a server hardware component type. The initial price subspace for each feature dimension is obtained by matching the feature dimensions in the feature space with the pre-established price elasticity matrix dimension by dimension. Detect resource constraint conflicts between initial price subspaces, including power consumption constraint conflicts, heat dissipation constraint conflicts, and physical space constraint conflicts; Based on the detected resource constraint conflicts, a conflict resolution path is generated, which includes an adjustment sequence for shrinking the initial price subspace. The elasticity coefficients in the price elasticity matrix are adjusted iteratively based on the adjustment sequence until all resource constraint conflicts are eliminated, generating the final price scheme.

2. The intelligent configuration method for server system pricing based on customer needs as described in claim 1, characterized in that, The steps of parsing customer requirement text and extracting key requirement items specifically include: The customer requirement text is segmented to obtain a requirement word sequence, and candidate keywords related to the overall configuration of the server are selected from the requirement word sequence; Match candidate keywords with a pre-defined requirement dictionary, which includes application scenario terms, performance indicator terms, and budget range terms. Based on the matching results, candidate keywords are categorized into corresponding demand categories. Under each demand category, a key demand item is generated, which includes a demand type identifier and a demand intensity coefficient. Arrange all key requirements items in order of requirement category to generate a base vector of requirement feature vectors, and fill the corresponding position of the base vector with the requirement intensity coefficient of each key requirement item.

3. The intelligent configuration method for server system pricing based on customer needs as described in claim 2, characterized in that, The pre-built demand dictionary includes a thesaurus, which maps synonyms of candidate keywords to the same demand category.

4. The intelligent configuration method for server system pricing based on customer needs as described in claim 2, characterized in that, The steps for dynamically constructing the feature space of the entire server based on the demand feature vector specifically include: Obtain the hardware component mapping table corresponding to each demand intensity coefficient in the demand feature vector. The hardware component mapping table records the correspondence between the demand intensity range and the hardware component model. Based on each demand intensity coefficient, extract the corresponding hardware component model from the hardware component mapping table, and combine all the extracted hardware component models into an initial component set; Iterate through each hardware component model in the initial component set and query the feature dimension identifier associated with that hardware component model. The feature dimension identifier includes processor dimension identifier, memory dimension identifier, storage dimension identifier, and network interface dimension identifier. Hardware component models with the same feature dimension are aggregated into the same feature dimension, and within each feature dimension, they are sorted according to the performance level of the hardware component models to form a structured representation of the feature space.

5. The intelligent configuration method for server system pricing based on customer needs as described in claim 4, characterized in that, The step of performing dimension-by-dimensional matching based on the feature dimensions in the feature space and the pre-established price elasticity matrix specifically includes: Take one feature dimension from the feature space in sequence as the current matching dimension, and obtain the dimension identifier and the list of hardware component models within the dimension; In the price elasticity matrix, find the row vector of elasticity coefficients corresponding to the dimension identifier. The row vector of elasticity coefficients contains multiple price elasticity coefficients, and each price elasticity coefficient corresponds to a combination of hardware component models. Cross-compare the list of hardware component models within the dimension with the model combinations in the row vector of elasticity coefficients, and filter out the matching elasticity coefficients that match the model list and model combinations. Multiply the matching elasticity coefficient by the preset price benchmark vector to obtain the initial price subspace for this feature dimension. The initial price subspace contains the price range corresponding to each hardware component model under this feature dimension.

6. The intelligent configuration method for server system pricing based on customer needs as described in claim 4, characterized in that, The price elasticity matrix adopts a sparse matrix storage format, storing only the dimension identifier and model combination corresponding to the non-zero elasticity coefficient.

7. The intelligent configuration method for server system pricing based on customer needs as described in claim 5, characterized in that, The steps for detecting resource constraint conflicts between initial price subspaces specifically include: Select a price range from each initial price subspace, and combine the hardware component models corresponding to all selected price ranges into a candidate complete system configuration; Obtain the total power consumption value of the candidate system configuration, compare the total power consumption value with the preset power capacity limit value, and mark it as a power consumption constraint conflict if the total power consumption value exceeds the power capacity limit value. Obtain the total heat dissipation value of the candidate system configuration, compare the total heat dissipation value with the preset upper limit of the heat dissipation system capacity, and mark it as a heat dissipation constraint conflict if the total heat dissipation value exceeds the upper limit of the heat dissipation system capacity. Obtain the physical dimensions of each hardware component model in the candidate complete system configuration, calculate the total physical dimensions occupied by all hardware component models, compare the total with the preset available chassis space, and mark it as a physical space constraint conflict if the total exceeds the available chassis space. Iterate through all possible candidate system configuration combinations and record the type and degree of resource constraint conflicts in each candidate system configuration.

8. The intelligent configuration method for server system pricing based on customer needs as described in claim 7, characterized in that, The step of generating a conflict resolution path based on the detected resource constraint conflict specifically includes: Sort all detected resource constraint conflicts in descending order of conflict severity value to generate a conflict sorting queue; Extract the resource constraint conflict with the highest conflict severity value from the conflict sorting queue as the current conflict to be processed, and determine the set of feature dimensions involved in the current conflict to be processed; Based on the type of conflict being handled, the corresponding resolution operation sequence is extracted from the resolution strategy library. The resolution operation sequence includes the contraction magnitude value and contraction direction identifier to be executed sequentially. The resolution operation sequence is applied to the initial price subspace corresponding to the set of feature dimensions involved in the current conflict handling, generating a single adjustment instruction to shrink and adjust the initial price subspace; Add a single adjustment instruction to the end of the adjustment sequence and recalculate the conflict severity value of the currently processed conflict. If the conflict severity value is still greater than the conflict tolerance threshold, reinsert the currently processed conflict into the conflict sorting queue; otherwise, remove the currently processed conflict from the conflict sorting queue. Repeat the above steps until the conflict sorting queue is empty, and output the complete adjustment sequence as the conflict resolution path.

9. The intelligent configuration method for server system pricing based on customer needs as described in claim 8, characterized in that, The resolution strategy library includes a priority strategy and a cost-priority strategy. The priority strategy is used to shrink the price subspace of non-core feature dimensions first, while the cost-priority strategy is used to shrink the feature dimensions with the largest reduction in unit cost first.

10. A server system pricing intelligent configuration system tailored to customer needs, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the intelligent configuration method for server whole machine price based on customer needs as described in any one of claims 1 to 9.

Images