Retired battery scene matching and knowledge evolution system based on large language model

Abstract

The invention relates to the technical field of decommissioned battery evaluation and large language models, in particular to a decommissioned battery scene matching and knowledge evolution system based on a large language model, which extracts multi-dimensional characteristics such as SoH and internal resistance of a decommissioned battery and requirements such as scene power requirement and cycle frequency, and performs LLM reasoning on adaptation degree and interpretation and vector retrieval similarity to obtain a decommissioned battery scene matching and knowledge evolution model. Carrying out weight fusion according to 0.6: 0.4 to obtain a comprehensive score for judgment and matching; a knowledge graph is constructed to associate battery-scene-constraint, incremental evolution is realized through semantic deduplication and graph combination, cloud-edge-end deployment is adopted, the method is based on a large language model decommissioned battery scene matching and knowledge evolution system, the Top-3 hit rate is 92.7%, the coverage rate of six-month newly-added scenes is 90.4%, the time delay of 1000 pieces of increment combination is 14.2 s, the interpretation readability is 4.6 / 5, and the method has the advantages of being high in reliability and high in reliability. And local deployment is supported to guarantee enterprise data security.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of retired battery evaluation and large language model, and particularly relates to a retired battery scene matching and knowledge evolution system based on a large language model. BACKGROUND

[0002] The state of health (SoH) of the retired power battery is between 60%-80%, which still has secondary utilization value and can be applied to secondary scenes such as communication base station standby power, household energy storage, forklifts and electric two-wheel vehicles. With the development of the industry, new ladder utilization scenes such as mobile energy storage vehicles and virtual power plants are also emerging. The large language model (LLM) has the ability to understand natural language requirements and reason about constraints→adaptability. If it is combined with vector retrieval technology and incremental knowledge graph, it can realize the dynamic evolution of the retired battery scene matching and knowledge base, and provide technical support for solving the scene matching problem in the ladder utilization of retired batteries.

[0003] In the process of matching the ladder utilization scene of the retired power battery, the traditional matching process relies on manual retrieval of working condition requirements and battery parameter tables, and the whole process lacks a unified knowledge system as support, resulting in low matching efficiency and difficulty in ensuring accuracy. At the same time, with the emergence of new ladder utilization scenes such as mobile energy storage vehicles and virtual power plants, the updating speed of the existing scene library is seriously lagging behind the development needs of the industry, and new scenes cannot be timely integrated into the matching system, further limiting the promotion of the scale and efficiency of the ladder utilization of retired power batteries. Therefore, in view of the above status, it is urgent to develop a retired battery scene matching and knowledge evolution system based on a large language model to overcome the deficiencies in current practical applications. SUMMARY

[0004] The purpose of the present application is to provide a retired battery scene matching and knowledge evolution system based on a large language model to solve the problems raised in the background.

[0005] To achieve the above purpose, the present application provides the following technical scheme:

[0006] A retired battery scene matching and knowledge evolution system based on a large language model, comprising:

[0007] A battery characterization layer for extracting the core features of the retired battery and constructing a battery feature vector;

[0008] A scene demand layer for clearly defining the core requirements of the application scene and constructing a scene demand vector, while retaining the scene text description;

[0009] An LLM reasoning layer for reasoning the adaptation score of the retired battery and the application scene based on the battery feature vector, the scene demand vector and the scene text description, and outputting explanation information containing hindering factors and recommended measures.

[0010] a vector retrieval layer configured to perform semantic vectorization on the battery feature vector and the scenario demand vector respectively to obtain a battery embedding vector and a scenario embedding vector, and to calculate a similarity between the battery embedding vector and the scenario embedding vector;

[0011] a comprehensive score layer configured to fuse the adaptation score output by the LLM inference layer and the similarity output by the vector retrieval layer to obtain a comprehensive matching score, and to determine whether to generate a scenario matching suggestion according to a preset threshold;

[0012] a knowledge graph layer configured to construct and store three types of entities, i.e., batteries, scenarios, and constraints, and semantic associations between the three types of entities;

[0013] an incremental evolution layer configured to perform semantic deduplication on newly added application scenarios, to merge incremental knowledge determined as non-duplicate to the knowledge graph layer, and to perform version management on the merged knowledge graph;

[0014] a cloud-edge-end collaborative deployment architecture configured to realize the collaboration of edge layer data collection, cloud layer core calculation, and application end result display, and to guarantee data security and real-time response.

[0015] As a further scheme of the application, the battery feature vector includes a state of health SoH of the retired battery, an internal resistance R int , a capacity consistency deviation σ Q , and a temperature window parameter, the temperature window parameter including a minimum working temperature T min and a maximum working temperature T max of the retired battery.

[0016] As a further scheme of the application, the scenario demand vector includes a power demand P req , a cycle frequency f cyc , and an environmental temperature T env of the application scenario, and the scenario text description contains an application scenario name and key working constraint conditions under the scenario.

[0017] As a further scheme of the application, the LLM inference layer performs inference using a constraint-driven templated Prompt, the templated Prompt including a battery parameter module, a scenario demand module, and an output structure module, the output structure module defining an output format of the adaptation score, the hindering factor, and the recommended measure.

[0018] As a further scheme of the application, in the comprehensive score layer, a weight coefficient of the adaptation score is greater than a weight coefficient of the similarity, and a sum of the weight coefficient of the adaptation score and the weight coefficient of the similarity is 1.

[0019] As a further scheme of the application: the knowledge graph layer is a graph structure G=(V, E), wherein the node set V={Battery, Scene, Constraint}, and the edge set E is a semantic association edge between the three types of entities, and the edge weight of the semantic association edge is the comprehensive matching score.

[0020] As a further scheme of the application: the incremental evolution layer determines semantic deduplication by calculating the hybrid similarity of the newly added scene and the existing scene, and the hybrid similarity combines the Hausdorff distance and the Jaccard similarity.

[0021] If the hybrid similarity is not lower than the preset similarity threshold, it is determined that the two are similar scenes, and the attribute of the corresponding semantic association edge is updated.

[0022] If the hybrid similarity is lower than the preset similarity threshold, a new scene node is generated and merged into the knowledge graph layer, and a knowledge graph snapshot is generated for version tracing and rollback.

[0023] As a further scheme of the application: the cloud-edge-end collaborative deployment architecture supports local deployment, which is used to store retired battery test data and enterprise confidential data in the scene matching process, to prevent data leakage.

[0024] As a further scheme of the application: the preset threshold value ranges from 0.73 to 0.77, and when the comprehensive matching score is not lower than the preset threshold value, the comprehensive scoring layer generates a scene matching suggestion, and writes the association relationship between the retired battery and the corresponding application scene into the knowledge graph layer.

[0025] Compared with the prior art, the application has the following advantages:

[0026] Greatly improve the accuracy and interpretability of scene matching: by combining the LLM and vector retrieval technology, a comprehensive scoring mechanism is constructed, so that the Top-3 hit rate of scene matching reaches 92.7%, which is significantly better than the traditional rule threshold method (68.5%); at the same time, the LLM inference layer can output clear obstacles and recommended measures, and the interpretability reaches 4.6 / 5 (5-point system), solving the problem of poor interpretability of traditional matching methods.

[0027] Realize the dynamic and automatic update of the scene library: relying on the incremental evolution mechanism of the knowledge graph, using the "semantic deduplication + graph merging" strategy, and combining snapshot hashing for version management, the 6-month new scene coverage rate reaches 90.4%, which is much higher than the traditional method (12.3%), and the 1000-knowledge incremental merging delay is only 14.2s, which is much lower than the traditional method of 8min, ensuring that the scene library can be updated in real time with the development of the industry.

[0028] Supports multi-dimensional feature joint reasoning: The system can perform joint reasoning based on multi-dimensional features of retired batteries, such as SoH, internal resistance, capacity consistency deviation and temperature window, and demand features such as power requirements, cycle frequency and permissible temperature of the scenario, to comprehensively consider the adaptability of batteries and scenarios and avoid deviations caused by single feature matching.

[0029] Ensuring enterprise data security: The system supports localized deployment mode, which can effectively protect confidential data generated by enterprises during the testing and scenario matching of retired batteries, avoid the risk of data leakage, and meet the core data security needs of enterprises. Attached Figure Description

[0030] Fig. 1 This is a diagram of the overall layered architecture of the system in an embodiment of the present invention.

[0031] Fig. 2 This is a diagram of the cloud-edge-device collaborative deployment architecture in an embodiment of the present invention.

[0032] Fig. 3 This is a schematic diagram of entity association in a knowledge graph according to an embodiment of the present invention. Detailed Implementation

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

[0034] The specific implementation of the present invention will be described in detail below with reference to specific embodiments.

[0035] Please see Figs. 1-3 This invention provides a retired battery scenario matching and knowledge evolution system based on a large language model, which solves the problems of traditional retired battery scenario matching relying on manual retrieval, lacking a unified knowledge system, and lagging scenario database updates. It achieves accurate matching between retired batteries and application scenarios and dynamic evolution of the knowledge base. The specific content is as follows:

[0036] I. System Overall Architecture

[0037] This system adopts a hierarchical structure consisting of a battery characterization layer, a scenario requirement layer, an LLM inference layer, a vector retrieval layer, a comprehensive scoring layer, a knowledge layer, and an incremental evolution layer. It is also equipped with a three-layer collaborative deployment architecture of cloud, edge, and device, balancing matching accuracy, real-time responsiveness, and data security. Each layer is tightly connected and works collaboratively to form a complete closed loop from battery feature acquisition to scenario matching output and dynamic updates to the knowledge base. The specific architectural logic is as follows:

[0038] The edge layer collects and preprocesses raw data from retired batteries, the cloud layer executes core reasoning, retrieval, and knowledge evolution tasks, the interface layer implements data interaction scheduling, and the application (terminal layer) provides visualization operations and result display.

[0039] II. The layered technical architecture follows a progressive process of "feature input—dual-path matching—comprehensive decision—knowledge update," ensuring that each step supports the final scene matching and knowledge evolution. Detailed implementation methods for each layer are as follows:

[0040] (1) Battery characterization layer

[0041] The battery characterization layer is used to extract the core features of retired batteries and construct battery feature vectors. Its expression is:

[0042]

[0043] The meanings and acquisition methods of each feature are as follows:

[0044] SoH (State of Health): Calculated by comparing the battery capacity test with the rated capacity, the value range is 60%–80% (typical health range of retired power batteries).

[0045] R int (Internal resistance): Obtained by AC impedance method, unit is mΩ;

[0046] σ Q (Capacity consistency deviation): Calculated statistically based on multiple sets of charge-discharge cycle test data, expressed as a percentage;

[0047] T min (Minimum operating temperature) and T max (Maximum operating temperature): Determined through high and low temperature environment testing, constituting the battery temperature window;

[0048] Feature preprocessing: The collected bench / field data are subjected to dimensional unification and outlier correction. Methods such as 3σ truncation and quantile stretching are used to ensure the reliability of the feature data.

[0049] By accurately extracting and standardizing the multidimensional core features of the battery, a unified and high-quality input data foundation is provided for subsequent scene matching, avoiding matching deviations caused by inconsistent features or abnormal data, and ensuring the accuracy of the matching process.

[0050] (2) Scenario requirement layer

[0051] The scenario requirement layer is used to clarify the core requirements of various application scenarios and construct scenario requirement vectors. Its expression is:

[0052]

[0053] Simultaneously, the scene text description is retained for semantic matching. The required parameters and their acquisition methods are as follows:

[0054] P req (Power requirement): Determined based on the actual operating power of the scenario, such as the power requirement of a mobile energy storage vehicle being 100kW / 15min peak.

[0055] f cyc (Cycle Frequency): The average number of charge-discharge cycles per day in the statistical scenario, such as the daily cycle of backup power for communication base stations being ≤1 time;

[0056] T env (Ambient temperature): Determine the temperature range of the working environment of the scenario, such as the ambient temperature of the backup power supply for a communication base station is 0–45℃;

[0057] Scene text description: The scene name and key constraints are clearly stated using natural language, such as backup power for communication base stations, ambient temperature of 0–45℃, and daily cycle of ≤1 time, providing semantic input for LLM inference.

[0058] By quantifying the core requirements of the scenario and preserving semantic descriptions, a multi-dimensional and structured expression of scenario requirements is achieved. This satisfies the matching and calculation requirements at the numerical level and provides a foundation for semantic reasoning, ensuring that scenario requirements can be accurately parsed and matched.

[0059] (3) LLM inference layer

[0060] The core task of the LLM inference layer is based on battery feature vectors. and scenario demand vector The system infers the compatibility between the two at the natural language level and outputs explanatory results. The specific implementation process is as follows:

[0061] A constraint-driven templated Prompt is used. The Prompt structure includes a battery parameter block, a scenario requirement block, and an output structure block (JSON Schema), as shown in the example below: Battery parameters: SoH=72%, R int =21mΩ; Scenario: Backup power for communication base stations; Ambient temperature: 0–45℃; Output adaptability and recommendations.

[0062] Calling large language models (such as ChatGPT, Qwen, Llama3, etc.) to perform multi-step chain-of-thought (CoT) reasoning, the model output is structured as follows:

[0063]

[0064] in, The score is for LLM inference adaptation. For a set of constraints (e.g., if the internal resistance is slightly high, parallel connection is required); To optimize the suggestion set (e.g., recommend air cooling, with SOC controlled in the range of 30%-90%).

[0065] A multi-sample self-consistency (K=5) and temperature annealing (T=0.3→0.1) strategy is employed to ensure inference consistency. Valid results are selected through confidence level calculation, using the following formula:

[0066]

[0067] in, These are the probability values ​​output by the autoregressive model. The function is a valid structure indicator. Failed parsing samples are scored as 0 points and error cases are recorded.

[0068] By using templated Prompt and CoT inference, the large language model can accurately understand the matching logic between batteries and scenarios. It not only outputs quantified fit scores, but also provides clear obstacles and recommendation measures. The interpretability reaches 4.6 / 5 (out of 5), which solves the problem of lack of interpretability in traditional matching methods. The confidence filtering mechanism effectively filters out invalid inference results, ensuring the reliability of the inference output.

[0069] (4) Vector retrieval layer

[0070] The vector retrieval layer is used to quickly retrieve the scene most similar to the current battery features in a large-scale scene library. The core is semantic vectorization and cosine similarity matching. The specific implementation process is as follows:

[0071] Semantic embedding: An embedding function is used to encode the battery feature vector, scenario requirement vector, and text description respectively to obtain the battery embedding vector. With scene embedding vector The expression is:

[0072]

[0073] in, An embedding function for the features of retired batteries; This is the embedding function for scene semantic features; (dimension is) (semantic embedding vector);

[0074] Similarity calculation: The standard cosine similarity is used to measure the similarity between the two, and the formula is:

[0075]

[0076] in, This is an inner product operation; for Norm;

[0077] Indexing and Retrieval: An ANN index (FAISS or Annoy) is used to construct the scene library index. The retrieval complexity is approximately O(logN). A similarity threshold δ∈[0.82,0.88] (depending on the embedding space density distribution) is set. This threshold corresponds to the 95% confidence lower bound within the LLM inference confidence interval. Candidate sets are then filtered.

[0078]

[0079] And perform rerank optimization on the candidate set.

[0080] The combination of ANN indexing and cosine similarity matching enables fast retrieval of large-scale scene libraries, with vector retrieval latency as low as 0.3s, significantly improving the efficiency of scene matching; semantic embedding technology transforms the features of batteries and scenes into vectors in a unified semantic space, which can capture potential relationships beyond numerical values, providing semantic support for comprehensive matching.

[0081] (5) Comprehensive scoring layer

[0082] The comprehensive scoring layer is used to fuse LLM inference results and vector retrieval results to obtain the final comprehensive matching score, thereby improving matching accuracy. The specific implementation process is as follows:

[0083] Comprehensive scoring formula:

[0084]

[0085] Where α=0.6 and β=0.4 are the fusion weights (satisfying α+β=1). For LLM inference adaptation score, Vector similarity;

[0086] Matching decision: Set the fit threshold θ≈0.75±0.02 (range 0.73-0.77). This threshold is determined through ROC curve analysis (taking the maximum TPR point when FPR≤0.05), Youden index calculation (J(θ)=TPR(θ)−FPR(θ) taking the maximum value), and business constraint verification (ensuring Top-3 hit rate ≥92% and coverage ≥90%). If the value is greater than or equal to θ, then a matching suggestion is generated and written into the knowledge graph; otherwise, the matching result is discarded.

[0087] By weighted fusion of the logical adaptability of LLM inference and the semantic similarity of vector retrieval, the comprehensive matching score can fully reflect the adaptability of the battery and the scene, achieving a Top-3 hit rate of 92.7%, which is significantly better than the traditional rule threshold method (68.5%). The scientific threshold determination mechanism takes into account both the accuracy and fault tolerance of the matching, avoiding the problems of missed or mismatched matching.

[0088] (6) Knowledge Layer

[0089] Knowledge graphs are used to uniformly describe three types of entities—battery, scenario, and constraint—and their semantic relationships, constructing a structured knowledge system. The specific implementation process is as follows:

[0090] Knowledge graph definition: A knowledge graph G=(V,E), where the node set V={Battery,Scene,Constraint} and the edge set... , border rights For overall compatibility ;

[0091] Storage and Management: The Neo4j graph database is used to store the knowledge graph structure. It works in conjunction with the MySQL database to achieve collaborative management of battery feature data and graph structure data, and supports efficient querying, modification and deletion of nodes and edges.

[0092] Semantic association construction: For the equivalence relationship between new scenarios and existing scenarios (such as mobile energy storage vehicles and emergency power vehicles), construct equivalence type edges to realize the explicit expression of semantic association.

[0093] Structured knowledge graphs integrate scattered battery data, scene data, and constraints into a unified knowledge system, solving the problem of traditional matching methods lacking a unified knowledge framework; the use of graph databases ensures efficient knowledge management and related queries, providing structured knowledge support for knowledge evolution and scene matching.

[0094] (7) Incremental Evolution Layer

[0095] The incremental evolution layer is used to dynamically update the knowledge graph, automatically absorbing new scenarios and data to ensure that the knowledge base keeps pace with industry development. The specific implementation process is as follows:

[0096] New scenario semantic deduplication: When a new scenario When an instance appears, the Hausdorff-Jaccard mixture similarity is calculated to determine whether it is a repetition of an existing scene. The formula is as follows:

[0097]

[0098] in, The distance to Hausdorff; Jaccard similarity; These are weighting coefficients; A comprehensive measure of semantic and feature similarity;

[0099] The definition and parameters of mixed similarity are disclosed as follows:

[0100] This invention constructs a hybrid similarity using Hausdorff distance and Jaccard similarity. Its mathematical definition is as follows:

[0101]

[0102] in, For set The Hausdorff distance between them; As a normalization constant, we can take the maximum Hausdorff distance observed in historical data, such that... ; The Jaccard similarity score has a range of values. ; These are weighting coefficients used to balance the contributions of geometric feature similarity and semantic / set similarity.

[0103] The range of values ​​for the weighting coefficients is as follows:

[0104] To ensure the stability and interpretability of the similarity values, this invention imposes the following constraints on the weighting coefficients:

[0105]

[0106] Preferably, to emphasize the consistency of shape and distribution, the preferred value range is:

[0107]

[0108] In one specific embodiment, take , Experiments have shown that this set of parameters can achieve a better balance between detection rate and false alarm rate.

[0109] The weighting coefficients are determined as follows:

[0110] Data partitioning: Divide the complete dataset into training and validation sets, for example, by... Division;

[0111] Candidate weight set: under constraints Let there be a finite candidate set, for example

[0112]

[0113] Performance evaluation: For each set of weights, the mixed similarity obtained on the validation set is evaluated comprehensively using metrics such as F1 score, precision, or recall.

[0114] Optimal choice: Select the set of comprehensive evaluation indicators that are optimal. As the final parameter.

[0115] Following the above process, the same or equivalent parameter combinations can be repeatedly obtained, ensuring that the hybrid similarity calculation method of the present invention is reproducible and feasible.

[0116] like If the condition is similar to another scenario, only update the edge attributes; otherwise, generate a new node.

[0117] Knowledge graph merging: A query-before-write graph update mechanism is adopted. The formula for merging new nodes / edges is:

[0118]

[0119] in, As incremental knowledge units; For graph merging operations; Annoy indexes are used to optimize merging efficiency, resulting in a merging complexity of O(log n). ;

[0120] Version control: Snapshot hash is generated after each merge.

[0121]

[0122] Snapshots are stored in the object storage system (MinIO) to enable version tracking and rollback recovery; when querying old scenes, newly added scene aliases are automatically identified to ensure query compatibility.

[0123] The semantic deduplication and incremental merging mechanism enables automatic updates of the scenario library, with a 90.4% coverage rate of newly added scenarios in 6 months, far exceeding the traditional method (12.3%). The merging latency of 1,000 incremental knowledge entries is only 14.2 seconds, far lower than the 8 minutes of the traditional method, which efficiently supports the dynamic evolution of the knowledge library. The version snapshot mechanism ensures the traceability and rollback consistency of knowledge evolution, improving the reliability of the system.

[0124] (8) Cloud-edge-device collaborative deployment architecture

[0125] The cloud-edge-device collaborative deployment architecture achieves efficient collaboration between the edge layer, cloud layer, interface layer, and application end through layered functional division, standardized communication protocols, and collaborative scheduling strategies. It balances real-time data processing, core computing performance, and enterprise data security. The specific collaboration mechanism is as follows:

[0126] 1. Hierarchical Functional Coordination Allocation

[0127] Edge layer: Deployed on retired battery test benches or field sites, using Jetson Orin Nano industrial computer hardware configuration, core functions include acquisition of raw data of retired batteries (SoH, internal resistance, temperature, etc.), real-time SoH estimation and feature preprocessing (3σ outlier truncation, quantile stretching dimension unification), only uploading the preprocessed standardized feature data to the cloud, reducing the overhead of invalid data transmission.

[0128] Cloud layer: Based on a server configuration of Xeon 24C CPU + GPU A6000 + 128G BRAM, it undertakes the core computing tasks of the system, including LLM inference (adaptation score and interpretation generation), vector retrieval (ANN index construction and similarity calculation), knowledge graph storage (Neo4j database) and incremental evolution (semantic deduplication and graph merging), and receives standardized feature data uploaded from the edge layer and outputs matching results to the interface layer.

[0129] Interface Layer: An API gateway is built using a Flask / Gunicorn / Nginx architecture, serving as a communication bridge between the cloud layer and the application. It enables data interaction scheduling, receives matching task requests from the application and forwards them to the cloud layer, receives matching results and knowledge graph update information output from the cloud layer and synchronizes them to the application. At the same time, a load balancing strategy ensures stable response to concurrent requests from multiple users.

[0130] Application side: Includes a web visualization interface (developed based on React / Ant Design) and mobile terminals. It is only responsible for displaying matching results (comprehensive matching score, hindering factors, and recommendation measures), reviewing knowledge graphs (viewing newly added scene nodes and semantic association edges), and submitting user tasks. It does not participate in core calculations and ensures smooth interface interaction.

[0131] 2. Data communication collaboration mechanism

[0132] Communication connectivity: The edge layer and cloud layer establish a secure connection through an SSH / SSL encrypted tunnel to prevent data leakage during transmission; the interface layer and application end use TLS1.3 encrypted communication to ensure the security of user requests and result data.

[0133] Communication Protocol: A hybrid MQTT+HTTP protocol is adopted. The edge layer uploads real-time feature data to the cloud layer using the MQTT protocol (lightweight and low bandwidth consumption), while the application submits task requests to the interface layer and the interface layer forwards requests to the cloud layer using the HTTP protocol (high reliability and easy parsing), balancing the requirements of real-time performance and reliability.

[0134] Data flow cycle: The edge layer data reporting cycle is set to 30-60 seconds, and the calculation formula is as follows:

[0135]

[0136] In a typical deployment scenario (N=200, S msg With 8KB and Δt=30s, the average bandwidth requirement is approximately 53KB / s, which is suitable for typical enterprise network environments.

[0137] 3. Deployment and Operation Collaboration Strategy

[0138] Containerized collaborative deployment: Docker+Docker Compose is used to achieve containerized deployment of the entire system. The edge layer collection script, cloud layer computing modules (LLM Service, Vector DB, Graph DB), and interface layer API gateway are encapsulated as independent containers. Interconnection between containers is achieved through Docker networking (bridge mode). The / data / mnt / persistent volume is mounted in a unified manner to store model weights, index files and graph snapshots, ensuring deployment consistency and data sharing.

[0139] Collaborative operation and maintenance mechanism: Daily incremental backups are enabled for the database (MySQL + Neo4j), and a snapshot hash is generated after each merge of the knowledge graph. t It is stored in the MinIO object storage system, supporting version tracking and rollback; all containers are configured with health checks and automatic restart policies (Docker Restart Policy), automatically restarting when the LLM inference container or vector retrieval container is abnormal, and the interface layer automatically switches the faulty node through load balancing to ensure continuous system operation.

[0140] Localized Collaborative Adaptation: Supports localized private deployment, storing raw test data of retired batteries and confidential data required by enterprise scenarios on local NVMe 4TB storage devices, performing core computing only on local cloud nodes, and not transmitting sensitive data to external public clouds, thus meeting enterprise data security compliance requirements.

[0141] 4. Performance and scalability are coordinated and guaranteed.

[0142] Real-time collaboration: edge layer preprocessing reduces data volume, cloud layer GPU accelerates LLM inference and vector retrieval (inference latency ≈ 1.8s, retrieval latency ≈ 0.3s), interface layer load balancing, three-level collaboration ensures that the end-to-end response latency of the system meets the needs of actual applications; the latency of merging 1000 knowledge increments is ≈ 14.2s, ensuring the efficiency of dynamic evolution of knowledge graph.

[0143] Scalability and Collaboration: By horizontally scaling container replicas (such as adding LLM inference containers or vector retrieval containers) or increasing edge nodes and cloud servers, it can support more than 10 6 Concurrent reasoning and real-time knowledge graph evolution for individual battery samples, adapting to the application scenarios of enterprises of different sizes.

[0144] III. System Deployment and Operation Support

[0145] (1) Hardware deployment and configuration

[0146] The system adopts a containerized deployment solution (Docker + Docker Compose), and the hardware configuration and function allocation are as follows:

[0147]

[0148] Edge nodes connect to the cloud via an encrypted tunnel (SSH / SSL), employing a hybrid MQTT+HTTP communication protocol. The data reporting cycle is set to 30-60 seconds to balance real-time performance and bandwidth.

[0149]

[0150] in, This represents the average bandwidth requirement. This represents the number of concurrent nodes. This refers to the volume of a single message; under typical deployment ( , KB, (s), average bandwidth requirement approximately KB / s, capable of stable operation in typical enterprise networks.

[0151] (2) Software and security configuration

[0152] Software environment: Developed based on Python 3.10, relying on tool libraries such as FAISS / Annoy (vector retrieval), PyTorch (model inference) and CUDA (GPU acceleration), and experimental scripts and configurations are managed through Git versioning;

[0153] Security mechanisms: All communication uses TLS 1.3 encryption, the database is backed up daily, containers support health checks and automatic restarts, and semi-automatic review and suspension of merge transactions are triggered when graph merge conflicts occur to avoid knowledge graph pollution;

[0154] Error handling: When LLM outputs invalid or missing fields in the JSON, If the sample is 0, it is considered a failure; if the embedding encoding fails, it falls back to the rule threshold method to ensure stable system operation.

[0155] (3) Operational performance and scalability

[0156] In a real-world test environment (24-core CPU + A6000 GPU), the LLM inference latency is approximately 1.8 seconds, the vector retrieval latency is approximately 0.3 seconds, and the graph merging latency (1000 nodes) is approximately 14.2 seconds. The system supports horizontal scaling; by adding container replicas or nodes, it can support more than 10...6 Concurrent reasoning and real-time knowledge graph evolution for individual battery samples can adapt to application scenarios of different scales.

[0157] IV. Scene Matching Examples

[0158] Taking the matching of retired batteries with backup power for communication base stations as an example, the workflow and effects of this system will be explained in detail:

[0159] Battery feature input: battery b i The characteristic parameters are SoH=72%, R int =21mΩ =1.8%, temperature window 0-40℃; Scenario requirement input: Scenario s j The demand vector for backup power to communication base stations is P. req (Meets the backup power requirements for base stations), f cyc ≤1 time / day, T env =0-45℃;

[0160] LLM inference: Drives model inference through a Prompt template, outputting... The main obstacle is slightly high internal resistance, requiring parallel connection. Recommended solutions include air cooling and 30% [other measures]. <SOC<90%;

[0161] Vector retrieval: Encoding yields e b With e s Calculate cosine similarity ;

[0162] Overall score: according to formula =0.6×0.82+0.4× Calculate the overall matching score. If the score is ≥0.75, the match is considered successful.

[0163] Knowledge Update: Battery b i Scene s j The comprehensive matching score is written into the knowledge graph, and the adaptation relationship edge between the two is established;

[0164] Results output: Returns successful matching results, hindering factors, and recommended measures to the application, which users can view through a web visualization interface.

[0165] In this example, the system not only accurately determined the compatibility between the battery and the scenario, but also provided actionable optimization suggestions, fully meeting the needs of actual engineering applications. At the same time, the matching relationship was incorporated into the knowledge graph to provide knowledge support for similar matching in the future.

[0166] It should be noted that, in this invention, although the specification describes the embodiments, not every embodiment contains only one independent technical solution. This way of describing the specification is only for clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A large language model-based retired battery scene matching and knowledge evolution system, characterized in that, The method comprises the following steps: a battery characterization layer for extracting core features of the retired battery and constructing a battery feature vector; a scenario demand layer for determining the core requirements of the application scenario and constructing a scenario demand vector, while retaining the scenario text description; an LLM inference layer for inferring the adaptation score of the retired battery and the application scenario based on the battery feature vector, the scenario demand vector, and the scenario text description, and outputting explanation information including hindering factors and recommended measures; a vector retrieval layer for performing semantic vectorization processing on the battery feature vector and the scenario demand vector respectively to obtain a battery embedding vector and a scenario embedding vector, and calculating the similarity between the two vectors; a comprehensive scoring layer for fusing the adaptation score output by the LLM inference layer and the similarity output by the vector retrieval layer to obtain a comprehensive matching score, and determining whether to generate a scenario matching suggestion according to a preset threshold; a knowledge graph layer for constructing and storing batteries, scenarios, and constraints, as well as the semantic associations between the three types of entities; an incremental evolution layer for performing semantic de-duplication judgment on newly added application scenarios, merging incremental knowledge that is determined to be non-repetitive to the knowledge graph layer, and performing version management on the merged knowledge graph; a cloud-edge-end collaborative deployment architecture for realizing the collaboration of edge layer data collection, cloud layer core calculation, and application end result display, and ensuring data security and real-time response.

2. The large language model-based decommissioned battery scenario matching and knowledge evolution system according to claim 1, characterized in that, The battery feature vector includes a state of health SoH of the retired battery, an internal resistance R int , a capacity consistency deviation σ Q , and a temperature window parameter including a lowest working temperature T min and a highest working temperature T max of the retired battery.

3. The large language model-based decommissioned battery scenario matching and knowledge evolution system according to claim 1, characterized in that, The scenario requirement vector includes power requirement P req , cycle frequency f cyc , and ambient temperature T env of the application scenario, and the scenario text description contains the application scenario name and key working constraint conditions under the scenario.

4. The large language model-based decommissioned battery scenario matching and knowledge evolution system according to claim 1, characterized in that, The LLM inference layer uses a constraint-driven templated Prompt to perform inference, and the templated Prompt includes a battery parameter module, a scenario demand module, and an output structure module, which limits the output format of the adaptation score, hindering factors, and recommended measures.

5. The large language model-based decommissioned battery scenario matching and knowledge evolution system according to claim 1, characterized in that, In the comprehensive scoring layer, the weight coefficient of the adaptation score is greater than the weight coefficient of the similarity, and the sum of the weight coefficient of the adaptation score and the weight coefficient of the similarity is 1.

6. The large language model-based decommissioned battery scenario matching and knowledge evolution system according to claim 1, characterized in that, The knowledge graph layer is a graph structure G=(V,E), where the node set V={Battery, Scene, Constraint}, and the edge set E is the semantic association edge between the three types of entities. The edge weight of the semantic association edge is the comprehensive matching score.

7. The large language model-based retired battery scenario matching and knowledge evolution system according to claim 1, characterized in that, The incremental evolution layer performs semantic de-duplication judgment by calculating the hybrid similarity between the newly added scenario and the existing scenario. The hybrid similarity combines Hausdorff distance and Jaccard similarity. If the hybrid similarity is not less than a preset similarity threshold, it is determined that the two are similar scenarios and the properties of the corresponding semantic association edge are updated. If the hybrid similarity is less than the preset similarity threshold, a new scenario node is generated and merged into the knowledge graph layer, and a knowledge graph snapshot is generated for version tracing and rollback.

8. The large language model-based decommissioned battery scenario matching and knowledge evolution system according to claim 1, characterized in that, The cloud-edge-end collaborative deployment architecture supports localized deployment, which is used to store retired battery test data and enterprise confidential data during the scenario matching process to prevent data leakage.

9. The large language model-based decommissioned battery scenario matching and knowledge evolution system according to claim 1, characterized in that, The value range of the preset threshold is 0.73-0.

77. When the comprehensive matching score is not less than the preset threshold, the comprehensive scoring layer generates a scenario matching suggestion, and the association between the retired battery and the corresponding application scenario is written into the knowledge graph layer.

Images