An LLM-Driven Triple-Stage Prompt for Automatic Disassembly Knowledge Graph Construction of End-of-Life Power Batteries Towards Industry 5.0

Abstract

Effective disassembly process planning is fundamental to the sustainability of power battery recycling. However, existing knowledge graph (KG) methods rely on flat ontologies, failing to capture multi-level semantic structures and depending heavily on manual annotation, which cannot meet the scalability demands of Industry 5.0. We propose TSO-Prompt, a triple-stage ontology prompt-driven method. First, a Battery–Component–Operation–Tool (BCOT) ontology model defines four entity types and four relationship types with strict domain and range constraints. Second, a three-stage prompt strategy is designed: Stage 1 (Pattern Injection) embeds BCOT definitions for simultaneous entity recognition, ontology classification, and relation extraction; Stage 2 (Temporal Completion) captures cross-step operational dependencies; Stage 3 (Ontology Self-Check) filters hallucination-induced errors via rule-based verification. The fully zero-shot pipeline requires no manual annotation. Experiments on 172 disassembly steps from five battery models show TSO-Prompt achieves 100% core semantic retention, 90.1% operation recognition accuracy, a 6.4% entity F1 improvement over supervised baselines, and 60% query path length reduction over flat graphs, validating its potential for automated KG construction aligned with Industry 5.0 objectives.

1. Introduction

Power batteries, as the core component of new energy vehicles, are facing mounting pressure related to end-of-life disposal. The cumulative installed capacity of power batteries in China has exceeded 1000 GWh, with an estimated 120–150 GWh expected to reach end-of-life annually by 2030 [1]. Efficient and environmentally sound treatment of these batteries is critical to the sustainable development of the industry. Disassembly sequence planning (DSP), the indispensable first step of battery treatment, is key to ensuring resource utilization and disassembly efficiency [2]. In the context of Industry 5.0, establishing disassembly knowledge systems that leverage next-generation artificial intelligence technologies is essential for promoting efficient DSP. However, current knowledge sources remain fragmented: repair manuals are unstructured and difficult to process; CAD models may be lost or inconsistent across battery variants. There is a pressing need for automated methods to extract and integrate heterogeneous disassembly knowledge.

Industry 5.0 extends the Industry 4.0 emphasis on automation and efficiency by prioritizing three core values: human-centricity, resilience, and sustainability [3]. In battery disassembly, human-centricity means equipping workers with precise, real-time operational guidance. Resilience requires systems that adapt dynamically to evolving battery designs. Sustainability demands maximizing material recovery through optimized processes. These requirements call for knowledge systems that function not as static repositories, but as evolving networks capable of continuous learning and adaptation. Yet, current KG-based disassembly planning methods [4,5] rely on static ontologies requiring manual re-engineering for each new battery model, fundamentally incompatible with the dynamic demands of Industry 5.0 manufacturing.

Knowledge graphs (KGs) offer a powerful approach for structuring and integrating disassembly knowledge. By representing components, operations, tools, and their relationships as triples, KGs can provide precise guidance for disassembly workers or collaborative robots [6]. However, existing KG construction methods depend heavily on domain experts to manually define schema layers and annotate data, a prohibitively time-consuming process [7,8]. Although these methods can effectively reuse structured knowledge within a closed domain, they remain inherently static, unable to adapt to the rapid iteration of battery models, the continuous emergence of new disassembly tools, or the evolving safety regulations that characterize real-world manufacturing environments.

Recent advances in large language models (LLMs) offer new possibilities for overcoming this issue. LLMs such as GPT-3 possess strong semantic understanding and can perform information extraction in zero-shot settings through in-context learning [9], without requiring domain-specific annotated data. However, LLMs are prone to “hallucination”—generating factually incorrect or logically inconsistent triples, such as “a bolt contains a battery pack,” which is unacceptable in safety-critical industrial applications [10]. Moreover, existing LLM-based extraction methods predominantly adopt flat ontologies, lacking explicit modeling of the hierarchical semantic structure inherent in disassembly knowledge. While fine-tuning LLMs on domain-specific data can partially mitigate these issues, it demands expensive computational resources and high-quality labeled datasets, conflicting with the sustainability goals of Industry 5.0.

To address the above challenges, we propose TSO-Prompt, a triple-stage ontology prompt-driven method for automatic construction of power battery disassembly knowledge graphs, specifically designed for Industry 5.0 manufacturing systems. The key contributions of this work are:

(1)

We propose a BCOT ontology model for formalized knowledge representation of power battery disassembly. In this model, four entity types (BAT, COM, OPE, TOOL) and four relationship types (contains, needs, uses, belongs_to) with strict domain and range constraints. It may provide a theoretical foundation for semantically consistent disassembly knowledge extraction.

(2)

We design a TSO-Prompt three-stage framework that integrates pattern injection, temporal completion, and ontology self-checking. This novel zero-shot prompt strategy requires no manually annotated training data, enabling rapid adaptation to new battery models.

(3)

We construct an experimental dataset of 172 disassembly steps from five mainstream battery models. Using this dataset, the proposed method achieves 100% core semantic retention, 90.1% operation recognition accuracy, and a 6.4% entity F1 improvement over supervised baselines, with the constructed KG supporting downstream DSP at a 60% query efficiency improvement.

The remainder of this paper is organized as follows. Section 2 reviews related work on KG construction, LLM-based knowledge extraction, and disassembly knowledge engineering. Section 3 details the BCOT ontology model and the TSO-Prompt methodology. Section 4 reports experimental results and analysis. Section 5 concludes the paper with limitations and future directions toward Industry 5.0.

2. Related Works

2.1. Power Battery Disassembly

The rapid growth of new energy vehicles has led to a surge in end-of-life power batteries, making efficient disassembly a critical industrial challenge. Chen et al. [1] analyzed the status of retired power battery recycling in China and emphasized the importance of intelligent robotic disassembly. Cong et al. [2] provided a comprehensive review of end-of-use management of spent lithium-ion batteries from a sustainability perspective, highlighting that disassembly is the indispensable first step for both secondary use and material recycling. Disassembly sequence planning (DSP) lies at the core of disassembly operations, directly determining efficiency, cost, and safety. Existing DSP methods can be broadly categorized into model-based optimization and knowledge-based reasoning. Xiao et al. [11] proposed a dynamic Bayesian network-based disassembly sequencing optimization method for electric vehicle batteries, modeling the probabilistic dependencies between disassembly operations. Yu et al. [3] constructed an ontology-based disassembly task planning framework for automotive traction batteries, utilizing predefined rule bases to generate valid disassembly sequences. Wu et al. [4] proposed a knowledge graph-based disassembly sequence planning method for end-of-life power batteries, explicitly modeling component hierarchies, tool dependencies, and disassembly constraints. Wang et al. [5] applied the GraphRAG approach to battery disassembly sequence planning, combining graph retrieval with large language models and achieving 93.8% accuracy across five battery models.

In summary, scholars have explored disassembly planning methods from both model-based and knowledge-based perspectives. However, from the perspective of actual large-scale recycling operations, there is no practical measure that can continuously and stably provide reasonable disassembly planning schemes based on real-time battery conditions. Specifically, existing knowledge-based methods rely on static KGs that must be manually re-engineered for each new battery model. These methods operate under idealized conditions—the KG schema and instances are predefined by domain experts—making it difficult to cope with the rapid iteration of battery designs and the diversity of manufacturers. The conclusions of existing methods are usually obtained under fixed battery configurations, whereas real-world recycling facilities face continuously evolving battery models with heterogeneous structures, connection methods, and disassembly procedures.

2.2. Collaborative KG and LLMs in Manufacturing

Extracting domain knowledge from historically accumulated cases and establishing connections between historical knowledge and new tasks can significantly improve the efficiency of task processing. KG provides a technical solution for achieving this goal. The rise of this technology is attributed to its ability to embed information in the domain ontology with high semantic expressiveness, forming a comprehensive semantic network [6]. Establishing KG-based intelligent models allows for historical knowledge reuse through knowledge recommendation and knowledge question-answering, providing operators with solution references for handling new disassembly tasks. However, KG-based models lack sufficient semantic understanding and logical reasoning capabilities, thus limiting their ability to handle complex query tasks involving unstructured text [7,8].

Large language models (LLMs), with their powerful context awareness, deep semantic analysis, and logical reasoning capabilities, can effectively compensate for the limitations of KG-based models in handling complex extraction tasks. Meanwhile, KG can effectively mitigate the inherent hallucinations of LLMs, making both complementary in their capabilities [9]. Brown et al. [10] demonstrated that GPT-3 can perform various NLP tasks through in-context learning in zero-shot settings without parameter fine-tuning. Wei et al. [12] introduced Chain-of-Thought prompting, showing that intermediate reasoning steps significantly improve LLM performance on complex tasks. In vertical domain applications, Zhang et al. [13] utilized LLMs for fault KG construction from rail transit equipment data. Lewis et al. [14] proposed RAG, combining external knowledge bases with LLMs to mitigate hallucination. Pan et al. [9] provided a systematic roadmap for unifying LLMs and knowledge graphs.

In manufacturing, several researchers have applied KG-LLM collaborative models. Guo et al. [7] constructed a multi-domain fusion KG for high-speed train maintainability design. Huang et al. [8] proposed a multi-layer KG for conflict resolution in conceptual design. Jiang et al. [15] proposed a dynamic data flow-driven KG construction method for remanufacturing disassembly processes, enabling continuous knowledge updating. Xiao et al. [16] proposed a bearing fault diagnosis framework based on KG and a data accumulation strategy. The above research indicates that the collaborative model based on the domain KG and LLM can efficiently reuse historical knowledge to assist operators in handling new planning and decision-making tasks in manufacturing systems. However, the potential application of this method in power battery disassembly process planning scenarios—which heavily rely on historical knowledge and face rapid model iteration—has not yet been explored.

2.3. Knowledge Graph Construction Techniques

Knowledge graph construction encompasses three core tasks: ontology modeling, named entity recognition, and relation extraction [6]. Ontology modeling provides a structured framework for knowledge units by conceptualizing the KG schema in a top-down manner. Noy and McGuinness [17] established the foundational methodology for ontology development. Tang et al. [18] developed an ontology-based approach for creating domain-specific KGs for petroleum exploration. Jiang et al. [19] created a fault event ontology model to label elements and relationships in the CRDM fault event corpus. Wang et al. [20] proposed an ontology-based KG construction method for turbine generator fault diagnosis.

In named entity recognition, deep learning models built upon pre-trained language models have achieved significant results. The BERT model proposed by Devlin et al. [21] has become the de facto standard for NLP tasks, built upon the Transformer architecture introduced by Vaswani et al. [22]. Deng et al. [23] employed stacked BILSTM to acquire deep contextual characteristics of text. Liu et al. [24] combined BERT with BILSTM and CRF to extract entity classes from unstructured data. For relation extraction, Chen et al. [25] suggested a distantly supervised approach for constructing fault diagnosis KGs without requiring large amounts of annotated data. Sun et al. [26] proposed a supervised approach using dependency paths in the inter-entity dependency tree.

The introduction of KG into equipment fault diagnosis has shown promising results. Li et al. [27] proposed an analysis of design-oriented fault KG using maintenance text. Xu et al. [28] surveyed KG embedding approaches, highlighting their potential to enhance KG-based applications. Ji et al. [29] and Hogan et al. [30] systematically reviewed KG representation, acquisition, and applications across diverse domains. However, most existing KG construction methods are designed for relatively static domains with stable knowledge bases. In manufacturing environments where knowledge evolves continuously—including new battery models, updated disassembly procedures, and changing tool specifications—existing methods lack efficient mechanisms for continuous knowledge updating. Frequent retraining or re-annotation, required by current supervised approaches, imposes prohibitive costs and cannot meet the real-time demands of industrial applications in the Industry 5.0 era.

3. Methodology

3.1. Overall Framework

The proposed TSO-Prompt method is designed to automatically construct a power battery disassembly knowledge graph from unstructured text. As illustrated in Figure 1, the overall framework comprises three interconnected layers: the knowledge representation layer, the knowledge extraction layer, and the graph application layer. Each layer addresses a distinct aspect of the KG construction pipeline, from schema definition to downstream utilization.

Knowledge Representation Layer. This layer defines the schema specifications of the target knowledge graph. We formally define the Battery–Component–Operation–Tool (BCOT) ontology model, which abstracts disassembly knowledge into four entity types—Battery (BAT), Component (COM), Operation (OPE), and Tool (TOOL)—and four semantic relationship types—contains, needs, uses, and belongs_to. Each relationship is governed by strict domain and range constraints. For example, the “contains” relationship can only point from a BAT entity to a COM entity, physically ensuring that “a bolt cannot contain a battery pack”. These constraints collectively form the schema layer of the knowledge graph, guaranteeing semantic consistency throughout the construction process.

Knowledge Extraction Layer. This layer implements the core innovation of TSO-Prompt: a three-stage prompt strategy that extracts structured knowledge from unstructured disassembly text. The three stages operate sequentially, with each stage’s output feeding into the next. Stage 1 (Pattern Injection) embeds the complete BCOT ontology definition directly into the prompt, guiding the LLM to simultaneously perform entity recognition, ontology classification, and preliminary relation extraction in a single pass. Stage 2 (Temporal Completion) captures cross-step operational dependencies by feeding extracted operation entities back to the LLM along with the original contextual text, enabling inference of sequential “belongs_to” relations. Stage 3 (Ontology Self-Check) applies rule-based constraint verification to filter out invalid triples generated by LLM hallucinations, ensuring that only semantically consistent triples enter the final knowledge graph.

Graph Application Layer. Validated triples are batch-written into a Neo4j graph database using py2neo. The resulting BCOT ontology knowledge graph supports downstream disassembly sequence planning tasks through Cipher queries. By following the fixed ontological path (BAT) → (COM) ← (OPE) → (TOOL), the system can efficiently retrieve complete operation sequences and required tool sets for any given battery component, achieving a 60% reduction in query path length compared to flat graph structures.

3.2. BCOT Ontology Model

The pattern layer design of the knowledge graph is the foundation for ensuring semantic consistency and inference validity of extraction results. To address the ontological characteristics of power battery disassembly knowledge, we propose the BCOT ontology knowledge representation model.

3.2.1. Formal Definition

The BCOT ontology knowledge graph is formally defined as a directed labeled graph:

$$G=(V,E,L_V,L_E)$$

(1)

where

Entity Node Set. $V=V_B\cup V_C\cup V_O\cup V_T$ is the entity node set, consisting of four disjoint subsets:

$(V_B=\{v_{b1},v_{b2},\dots ,v_{b\left|B\right|}\left\}\right)$: Battery entities, representing complete power battery systems or major functional modules, e.g., battery pack casing, BMS, high-voltage safety box, battery modules.

$(V_C=\{v_{c1},v_{c2},\dots ,v_{c\left|C\right|}\left\}\right)$: Component entities, representing physical parts or assemblies, e.g., M8 bolts, wiring harnesses, DC high-voltage connectors, cooling pipes, busbars.

$(V_O=\{v_{o1},v_{o2},\dots ,v_{o\left|O\right|}\left\}\right)$: Operation entities, representing disassembly actions with action verbs, e.g., “Remove the connecting bolts between the battery pack cover and the tray using a torque wrench”, “Disconnect the BDU connector B1/B2/B3/B4 while wearing insulated gloves”.

$(V_T=\{v_{t1},v_{t2},\dots ,v_{t\left|T\right|}\left\}\right)$: Tool entities, representing instruments, equipment or protective gear, e.g., torque wrenches, screwdrivers, insulated gloves, wire cutters, vacuum module lifters.

Disjointness condition:

$$(V_B\cap V_C=V_B\cap V_O=V_B\cap V_T=V_C\cap V_O=V_C\cap V_T=V_O\cap V_T=\varnothing )$$

(2)

Relationship Edge Set $(E\subseteq V\times R\times V)$ is the directed edge set, where the predefined relationship type set is:

$$R=contains, needs, uses, belong to$$

(3)

Labeling Functions. The entity type labeling function $L_V:V\to \{BAT,COM,OPE,TOOL\}$ assigns each entity node to its corresponding ontological category, and the relationship type labeling function $L_E:E\to R$ assigns each edge to its corresponding relationship type. A valid BCOT triple is defined as:

$$t=(h,r,t)\in V\times R\times V$$

(4)

subject to domain and range constraints described in Section 3.2.2.

Figure 2 intuitively presents the topological structure of the four entity types and their semantic relationships in the BCOT model described above.

3.2.2. Semantic Constraints

To ensure semantic consistency and reasoning validity of the knowledge graph, the BCOT model imposes strict domain and range constraints on each relationship type. For any triple $(h,r,t)$, the following mapping constraints must hold:

$$r=contains\Rightarrow L_V\left(h\right)=BAT\wedge L_V\left(t\right)=COM$$

(5)

$$r=needs\Rightarrow L_V\left(h\right)=OPE\wedge L_V\left(t\right)=COM$$

(6)

$$r=uses\Rightarrow L_V\left(h\right)=OPE\wedge L_V\left(t\right)=TOOL$$

(7)

$$r=belong\mathit{\text{s\_t}}o\Rightarrow L_V\left(h\right)=OPE\wedge L_V\left(t\right)\in \{OPE,BAT\}$$

(8)

These constraints can be compactly expressed using the domain function $D:R\to 2^v$ and range function $Rg:R\to 2^v$:

$$\begin{gathered} D\left(contains\right)=V_B,Rg\left(contains\right)=V_C \\ D\left(needs\right)=V_O,Rg\left(needs\right)=V_C \\ D\left(uses\right)=V_O,Rg\left(uses\right)=V_T \\ D\left(belong\mathit{\text{s\_t}}o\right)=V_O,Rg\left(belong\mathit{\text{s\_t}}o\right)=V_O\cup V_B \end{gathered}$$

(9)

Table 1. Relationship Constraints in the BCOT Model.

Relationship	Domain	Range	Semantic Description
Contains	$V_B$	$V_C$	Battery consists of components
Needs	$V_O$	$V_C$	Operation acts to components
Uses	$V_O$	$V_T$	Operation needs tools
Belongs_to	$V_O$	$V_O\cup V_B$	Temporal dependencies or affiliations

provides the complete semantic definitions and constraint rules for all four relationship types.

These constraints serve two critical functions. First, they fundamentally eliminate counter-intuitive semantic errors such as “a component contains a battery” or “a tool needs an operation” by enforcing directional correctness at the schema level. Second, they provide a fixed ontological path for downstream query tasks:

$$BAT \underrightarrow{contains} COM \underleftarrow{needs} OPE \underrightarrow{uses} TOOL$$

(10)

For example, when querying the complete disassembly sequence for “battery pack cover,” the system can efficiently traverse this fixed path to retrieve all related operations and their required tools without navigating through irrelevant nodes in a flat structure.

3.2.3. Theoretical Analysis

The BCOT model possesses three key theoretical properties:

Completeness. The four entity types collectively cover all essential knowledge elements in battery disassembly: the object being disassembled (BAT), the physical parts being manipulated (COM), the actions performed (OPE), and the instruments used (TOOL). The four relationship types capture all fundamental semantic connections: physical composition (contains), operational dependency (needs), instrumental requirement (uses), and sequential/affiliative association (belongs_to). Formally:

$$L_V\left(V\right)=\{BAT,COM,OPE,TOOL\},L_E\left(E\right)\subseteq \{contains,needs,uses,belong\mathit{\text{s\_t}}o\}$$

(11)

Consistency. The domain and range constraints ensure that no semantically invalid triple can exist in the knowledge graph. A triple set $T$ is BCOT-consistent if and only if:

$$\forall (h,r,t)\in T:L_V\left(h\right)\in D\left(r\right)\wedge L_V\left(t\right)\in Rg\left(r\right)$$

(12)

This constraint-based filtering mechanism guarantees logical consistency across the entire graph.

Efficiency. The fixed ontological path simplifies downstream queries from full-graph search in flat graphs to path traversal in BCOT graphs. The query complexity is reduced from:

$$O\left(n^2\right)to\left(O\left(k·d\right)\right)$$

(13)

where $n=\left|V\right|$ is the total number of nodes in a flat graph, $\mathrm{k}$ is the number of operation steps required for a specific component, and $d={\displaystyle \frac{1}{\left|V_C\right|}}{\sum }_{v\in V_C}\mathit{deg} (v)$ is the average degree of component nodes. Since typically $(k\ll n) \mathrm{a}\mathrm{n}\mathrm{d} (d\ll n)$, the query path length is reduced by approximately 60%, as validated by comparative measurements on the constructed graph. This represents a structural advantage of the BCOT model rather than a runtime measurement.

3.3. Stage 1: Pattern-Injection Prompts

Stage 1 aims to enable the LLM to strictly follow the BCOT model specification, performing entity recognition, ontology classification, and preliminary relation extraction from unstructured disassembly text in a single pass.

3.3.1. Problem Formulation for Entity-Relation Extraction

Given an unstructured disassembly text segment $x$, the objective of Stage 1 is to extract a set of triples $T=(h,h_{type},r,t,t_{type})$ such that each triple conforms to the BCOT ontology constraints. Here, $h$ and $t$ denote the names of the head and tail entities respectively, $h_{type}$ and $t_{type}$ denote their corresponding BCOT ontology types (BAT/COM/OPE/TOOL), and $\mathrm{r}$ denotes the relationship type. This is formulated as a conditional generation problem:

$$T_1=arg \underset{T}{\max }P(T\mid x,{\mathcal{P}}_{BCOT})$$

(14)

where ${\mathcal{P}}_{\mathrm{B}\mathrm{C}\mathrm{O}\mathrm{T}}$ denotes the BCOT ontology definition injected into the prompt. The challenge lies in designing an effective prompt ${\mathcal{P}}_{\mathrm{B}\mathrm{C}\mathrm{O}\mathrm{T}}$ that enables the LLM to simultaneously perform multiple subtasks—entity boundary detection, type classification, and relation prediction—without task-specific fine-tuning.

3.3.2. Prompt Design Principles

The Stage 1 prompt design follows three core principles, each addressing a specific challenge in zero-shot knowledge extraction:

(1)

Expert Role Setting. We assign the LLM the role of a “power battery disassembly process expert” to activate domain-specific knowledge acquired during pre-training. This role priming has been shown to improve extraction accuracy by biasing the model toward domain-relevant terminology and patterns.

(2)

Explicit Model Injection. The complete BCOT ontology definition—including all four entity types with representative examples, all four relationship types with directional constraints, and explicit violation examples—is embedded directly into the prompt as background knowledge. This serves as the “extraction guideline” that the LLM must strictly follow, effectively transforming the open-ended extraction task into a constrained generation task with well-defined output specifications.

(3)

Strict Format Constraints. The output is required to be a structured JSON array, where each triple explicitly specifies the head entity name, head entity type, relationship type, tail entity name, and tail entity type. This structured format eliminates parsing ambiguity and enables direct downstream processing without post hoc normalization.

3.3.3. Core Prompt Template

Table 2. Core Prompt Template for Phase 1.

[Role] You are a power battery disassembly process expert, proficient in the disassembly procedures of various battery pack models. [Background Knowledge] We are constructing an ontology-based disassembly knowledge graph. The BCOT model is defined as follows: Entity Types: - Battery (BAT): Complete power battery system or major functional modules.   Examples: battery pack cover, BMS, high-voltage safety box, module. - Component (COM): Physical parts or assemblies constituting the battery.   Examples: bolts, wiring harnesses, connectors, busbars, cooling pipes. - Operation (OPE): Specific disassembly action descriptions containing verbs. - Tool (TOOL): Instruments or protective equipment required for operations.   Examples: wrench, screwdriver, insulated gloves, torque gun. Relationship Types and Constraints: - contains: Only from [BAT] to [COM]. Example: (battery pack cover, contains, M8 bolt) - needs: Only from [OPE] to [COM]. Example: (remove M8 bolt, needs, M8 bolt) - uses: Only from [OPE] to [TOOL]. Example: (remove M8 bolt, uses, torque wrench) - belongs_to: Only from [OPE] to [OPE] or [BAT].     Represents temporal dependency or affiliation. [Task] Analyze the following text and extract all knowledge according to the above model. Output only a JSON list in the following format: [{“head”: “entity name”, “head_type”: “BAT/COM/OPE/TOOL”, “relation”: “contains/needs/uses/belongs_to”, “tail”: “entity name”, “tail_type”: “BAT/COM/OPE/TOOL”}] [Text] {input_text} Ensure: (1) All relationships strictly follow domain and range constraints. (2) Operation entities are complete action descriptions from the text. (3) No explanatory text beyond the JSON output.

presents the core prompt template for Stage 1. The template is designed to be self-contained: the LLM receives all necessary ontological knowledge within the prompt itself, requiring no external knowledge base or retrieval mechanism.

3.3.4. Extraction Process

The extraction process proceeds as follows:

Step 1: Prompt Construction. The input text $\mathrm{x}$ is inserted into the prompt template, replacing the {input_text} placeholder. The complete prompt is then submitted to the LLM.

Step 2: LLM Inference. The LLM processes the prompt and generates a JSON-formatted response containing the extracted triples. The temperature parameter is set to 0.1 to ensure deterministic and reproducible outputs suitable for structured extraction tasks.

Step 3: Output Parsing. The JSON response is parsed to obtain the preliminary triple set $T_1$. Each triple is validated against the BCOT schema to ensure correct formatting, though semantic validation is deferred to Stage 3.

3.4. Stage 2: Temporal-Completion Prompts

While Stage 1 effectively extracts entities and relations within individual operation steps, disassembly processes are inherently sequential—operations must follow specific orders constrained by physical dependencies. Stage 2 addresses the temporal dimension by capturing cross-step operational dependencies.

3.4.1. Problem Formulation for Temporal Dependency Completion

Given the set of operation entities $O=\{o_1,o_2,\dots ,o_k\}$ extracted in Stage 1 and the original text $x$ containing full contextual information, Stage 2 aims to identify temporal precedence relationships between operations. Formally, we seek a set of temporal triples:

$$T_2=\left\{\right(o_i,belong\mathit{\text{s\_t}}o,o_j)\mid o_i,o_j\in O,o_{i}mustprecede{o}_j\}$$

(15)

Temporal information in disassembly texts is typically expressed through three mechanisms: (1) explicit temporal markers such as “first… then…” or “subsequently”; (2) step numbering such as “[Step 1]… [Step 2]…”; and (3) implicit physical logic—for example, fixing bolts must be removed before the fixed component can be lifted.

3.4.2. Prompt Design

Stage 2 employs a dedicated prompt that presents the LLM with the complete list of extracted operation entities and the original text, explicitly instructing it to identify only temporal dependencies. The prompt template is shown in

Table 3. Temporal-Completion Prompt Template for Stage 2.

[Role] You are a power battery disassembly process expert. [Task] In the previous stage, we extracted basic triples from the disassembly text. Now you need to identify temporal dependency relationships between operations. [Extracted Operation Entities] {ope_list} [Original Text] {original_text} [Instructions] Analyze the sequence of operations in the text and supplement “belongs_to” relations. Here, “belongs_to” denotes temporal dependency: operation A must be completed before operation B can begin. Output format: [{“head”: “preceding operation”, “head_type”: “OPE”, “relation”: “belongs_to”, “tail”:“subsequent operation”, “tail_type”: “OPE”}] If only one operation exists or temporal order cannot be determined, output an empty list [].

.

3.4.3. Completion Algorithm

The temporal completion process follows a three-step mechanism:

Step 1: OPE Entity Aggregation. All operation entities from Stage 1 are collected, including those appearing as both head and tail entities. Duplicates are removed to form a unique operation entity set $\mathrm{O}$.

Step 2: Contextual Semantic Inference. The operation set $\mathrm{O}$ and the original text $\mathrm{x}$ are jointly submitted to the LLM. The LLM infers temporal order based on three cues: (a) explicit temporal marker matching (e.g., “first,” “then,” “finally”); (b) step number ordering (e.g., “[Step 1]” precedes “[Step 2]”); and (c) physical constraint reasoning (e.g., bolts must be removed before the component they secure).

Step 3: Relation Generation. The LLM outputs standardized JSON-formatted temporal triples. Each triple ($o_i$, belongs_to, $o_j$) encodes that operation $o_i$ is a prerequisite of operation $o_j$.

For example, given the text “[Step 1] Remove the connecting bolts between the battery pack cover and tray using a torque wrench. [Step 2] Remove the battery pack cover while wearing insulated gloves”, Stage 1 extracts $\mathrm{O}$ = {“Remove connecting bolts…”, “Remove battery pack cover…”}. Stage 2 then outputs [{“head”: “Remove connecting bolts…”, “head_type”: “OPE”, “relation”: “belongs_to”, “tail”: “Remove battery pack cover…”, “tail_type”: “OPE”}], correctly capturing that bolt removal must precede cover removal.

3.5. Stage 3: Ontology Self-Check Prompts

Despite the ontological guidance provided in Stage 1 and the temporal reasoning in Stage 2, LLMs are inherently susceptible to “hallucination”—generating content that is factually incorrect or logically inconsistent. Stage 3, the core innovation of TSO-Prompt, addresses this by introducing a rule-based ontology self-checking mechanism that automatically validates and filters extracted triples.

3.5.1. Problem Formulation for Ontology Validation

LLM hallucination in knowledge extraction manifests in four primary error modes:

(1)

Relationship Direction Reversal. The LLM may confuse the directionality of relationships, generating triples such as (connecting bolt, contains, battery pack cover), which reverses the physical containment relationship.

(2)

Entity Type Misclassification. The LLM may incorrectly classify entities, for example, labeling “wrench” as a Component (COM) rather than a Tool (TOOL), or labeling “remove bolt” as a Component rather than an Operation.

(3)

Ontological Constraint Violation. The LLM may generate cross-ontology relationships, such as (operation A, uses, operation B) or (component X, needs, tool Y), violating the domain/range constraints of the BCOT model.

(4)

Relationship Type Misuse. The LLM may confuse semantically similar relationship types, such as using “needs” where “uses” is appropriate, or “belongs_to” where “contains” should be used.

Without systematic filtering, these errors propagate into the final knowledge graph, compromising downstream task reliability—particularly critical in safety-sensitive industrial applications.

3.5.2. Validation Rules

Based on the BCOT model constraints defined in Table 1, Stage 3 establishes six validation rules, as presented in

Table 4. Ontology Validation Rules.

Rule ID	Relationship	Constraint	Handling
R1	Contains	head=BAT ∧ tail=COM	Exclude
R2	Needs	head=OPE ∧ tail=COM	Exclude
R3	Uses	head=OPE ∧ tail=TOOL	Exclude
R4	Belongs_to	head=OPE ∧ tail ∈ {OPE, BAT}	Exclude
R5	any	relation ∈ {contains, needs, uses, belongs_to}	Mark for review
R6	any	head_type, tail_type ∈ {BAT, COM, OPE, TOOL}	Mark for review

. R1–R4 enforce directional and type constraints for each relationship type. R5–R6 handle unknown relationship types and entity types, respectively.

3.5.3. Validation Algorithm

The validation algorithm takes the combined triple set $T=T_1\cup T_2$ from Stages 1 and 2 as input, applies each validation rule sequentially, and outputs two disjoint sets: valid triples $V$ and invalid triples $\mathrm{I}$. Figure 3 illustrates the complete validation algorithm.

The algorithm operates in linear time O(/T/) with respect to the number of triples, as each triple is processed exactly once. The constant-time validation checks ensure minimal computational overhead.

3.5.4. Error Handling and Graph Instantiation

Invalid triples in set $\mathrm{I}$ are handled according to their error types:

Direction Reversal (R1–R4 violations): These represent definitive logical errors and are directly excluded from the final graph. For example, (connecting bolt, COM, contains, battery pack cover, BAT) is discarded due to direction violation.

Type Misclassification (R6 violations): These indicate deviations in the LLM’s ontology classification and are excluded, as type errors invalidate subsequent relationship validation.

Unknown Relationship Types (R5 violations): These may result from non-standard relationship names generated by the LLM (e.g., “composition,” “assembly”). Such triples are flagged for manual review rather than immediate exclusion.

Validated triples in set $\mathrm{V}$ are batch-written to the Neo4j graph database using py2neo. The import process employs MERGE statements to ensure node uniqueness—nodes with identical names and labels are automatically deduplicated—and creates directed relationship edges corresponding to the relationship fields in each triple. Node name indices are established to accelerate downstream query operations.

Ablation experiments (see Section 4.3) validated the critical role of Stage 3: upon removal of the validation mechanism, invalid triples infiltrated the final graph, significantly degrading knowledge quality. The validation mechanism effectively eliminates the hallucination-induced noise, ensuring that only semantically consistent, ontologically valid triples constitute the BCOT knowledge graph.

3.6. Chapter Summary

The TSO-Prompt methodology integrates three complementary stages into a unified zero-shot pipeline. The BCOT ontology model (Section 3.2) provides the semantic foundation through formalized entity types, relationship types, and constraint rules. Stage 1 (Section 3.3) leverages pattern-injection prompts to perform entity recognition and relation extraction guided by explicit ontological knowledge. Stage 2 (Section 3.4) captures temporal dependencies between operations through contextual semantic inference. Stage 3 (Section 3.5) ensures extraction quality through rule-based validation, filtering out hallucination-induced errors. Together, these components enable end-to-end construction of a semantically consistent, ontologically valid power battery disassembly knowledge graph from unstructured text, without requiring any manually annotated training data.

4. Experiments and Analysis

This section presents a comprehensive experimental evaluation of the proposed TSO-Prompt method. We first describe the experimental setup, including the dataset, baseline models, and evaluation metrics. We then report results on triple extraction performance, ablation studies, knowledge graph construction quality, and a case study on downstream disassembly sequence planning.

4.1. Experimental Setup

4.1.1. Dataset

To validate the effectiveness of the proposed method, we collected disassembly text data from five mainstream power battery models: Off-road A1310A (Xiaomi, Beijing, China), Mercedes-Benz BT0024 (EQC, Stuttgart, Germany), Foton MGL48C01Y (Foton, Beijing, China), JPLA-10B759-AH, and Tesla Model S 85 kWh (Tesla, Palo Alto, CA, USA). The data sources include repair manuals, disassembly reports, and work instructions, covering multiple battery types such as lithium iron phosphate (LFP), ternary lithium (NCM), and lithium manganese oxide (LMO), as well as different cooling methods including liquid cooling and air cooling. This diversity ensures the representativeness of the experimental dataset.

The raw texts were preprocessed and segmented into independent text fragments, each corresponding to a complete disassembly operation description. After preprocessing, we obtained 172 disassembly steps comprising 673 entities and 487 triples.

Table 5. Experimental Dataset Statistics.

Vehicle Model	Steps	Entities	Triples
Off-road A1310A	50	196	142
Mercedes-Benz BT0024	25	98	71
Foton MGL48C01Y	35	137	99
JPLA-10B759-AH	45	176	127
Tesla Model S 85 kWh	17	66	48
Total	172	673	487

presents the detailed statistics of the experimental dataset.

4.1.2. Ground-Truth Construction

To evaluate the extraction performance, a representative subset of samples was randomly selected from the 172 disassembly steps to ensure balanced coverage across all five battery models. Two annotators with domain knowledge in power battery disassembly independently annotated entities and relationships following a predefined annotation guideline that strictly adhered to the BCOT model definition. The annotators were instructed to label all entities according to the four entity types—Battery (BAT), Component (COM), Operation (OPE), and Tool (TOOL)—and all relationships according to the four relationship types—contains, needs, uses, and belongs_to. Any disagreements between annotators were resolved through discussion and consensus. The inter-annotator agreement measured by Cohen’s Kappa coefficient reached 0.86, indicating high annotation quality suitable as an evaluation benchmark.

4.1.3. LLM Configuration

The experiments employed Qwen-plus as the primary LLM. This model has demonstrated superior performance on Chinese natural language processing tasks and supports zero-shot prompt invocation with stable API responses. The temperature parameter was set to 0.1 to ensure deterministic and consistent outputs for structured extraction tasks. All experiments were conducted on a Windows 11 environment with Python 3.8.

4.1.4. Evaluation Metrics

Given the absence of training data under the zero-shot setting and the reasonable granularity differences between LLM-generated entities and human annotations (e.g., the LLM splits compound operations such as “remove BDU while wearing insulated gloves” into atomic operations “wear insulated gloves” and “remove BDU”), we adopt manual semantic evaluation as the primary evaluation approach. The specific metrics include:

Semantic Accuracy: The proportion of extracted entities/relationships that are semantically correct.

Core Semantic Retention Rate: The proportion of samples for which at least the core disassembly semantics are correctly preserved.

Triple Validity Rate: The proportion of triples that pass ontology validation.

For fair comparison with baseline models, we also report Precision, Recall, and F1 scores under strict string matching as reference metrics.

For the manual semantic evaluation, a triple is considered semantically correct if it accurately captures the meaning of the original text, regardless of minor differences in wording or granularity. For instance, “(battery pack cover, contains, M8 bolt)” and “(battery cover, contains, bolt)” are both considered semantically correct representations of the same fact. Core semantic retention is defined as the proportion of test samples for which all essential disassembly operations, their target components, and required tools are correctly identified. Two evaluators independently assessed each sample, and their judgments were compared to ensure consistency.

4.1.5. Baseline Models

Three representative methods were selected as comparison baselines:

(1)

BERT-BiLSTM-CRF [31]: A traditional supervised sequence labeling model. It was fine-tuned on the same annotated data using the BIO tagging scheme to recognize four entity types, with relation extraction based on predefined rules. The annotation cost was approximately 40 person-hours.

(2)

Traditional RAG + LLM [14]: A retrieval-augmented generation system built using the LangChain framework. Disassembly texts were chunked and indexed, and the LLM generated triples based on retrieved relevant text fragments.

(3)

Few-shot Prompt [10]: The LLM was provided with k annotated examples (k = 1, 3, 5) in the prompt to test its few-shot learning capability, serving as a comparison with the zero-shot setting.

All baseline methods were evaluated under the same experimental settings, using the same dataset and annotation benchmark. BERT-BiLSTM-CRF was fine-tuned on the same annotated subset, RAG + LLM used the same document corpus for retrieval, and Few-shot Prompt used the same LLM (Qwen-plus) as TSO-Prompt. Regarding ontology-guided or graph-enhanced LLM extraction methods, to the best of our knowledge, no existing ontology-guided extraction method has been specifically designed or validated for power battery disassembly scenarios. The methods compared in this study represent the most directly comparable approaches across supervised, retrieval-augmented, and few-shot paradigms.

4.2. Triple Extraction Performance

4.2.1. Manual Semantic Evaluation

Given the annotation granularity differences between Ground Truth (GT) and LLM outputs, we adopted manual semantic evaluation. The results in

Table 6. Manual Evaluation Results.

Grade	Percentage	Description
All Correct	36.70%	Semantically identical to GT
Partially Correct	63.30%	Core semantics correct
All Incorrect	0%	No completely incorrect samples
Core Retained	100%	Core knowledge correctly extracted

show that the proposed method achieves 100% core semantic retention, with 36.7% of samples fully consistent with GT annotations.

In this evaluation, “core semantics” refers to the essential disassembly knowledge elements required for practical disassembly planning, including (1) the correct identification of the target component being disassembled, (2) the specific disassembly operation performed, and (3) the required tool for the operation. The assessment procedure involved two evaluators independently reviewing each extracted triple set against the original text to determine whether these core elements were correctly captured. The same two domain experts who constructed the ground truth independently evaluated all 172 extracted triple sets. Their judgments were compared to ensure inter-evaluator consistency, with a Cohen’s Kappa of 0.86, indicating strong consistency.

The evaluation results demonstrate that under zero-shot settings, the proposed method achieves complete core semantic retention. No samples were entirely incorrect. While 63.3% of samples exhibited granularity differences—primarily because the LLM decomposes compound operations into atomic ones—the core semantics remained fully correct and usable for downstream tasks.

Table 7. Error Analysis of Extraction Results.

Error Type	Percentage	Correctable by Stage 3
Relationship direction reversal	45%	Yes (R1–R4)
Entity type misclassification	30%	Yes (R6)
Entity boundary errors	15%	No
Missing entities	10%	No

presents a systematic error analysis. Relationship direction errors (e.g., extracting “(M8 bolt, contains, battery pack cover)” instead of the correct direction) and entity type misclassifications (e.g., labeling “wrench” as COM) are effectively corrected by the ontology self-check mechanism. However, entity boundary errors (e.g., extracting “battery cover” instead of “battery pack cover”) and missing entities (e.g., failing to extract a required tool) cannot be fully addressed by the current validation mechanism, representing limitations of the approach.

4.2.2. Entity Type Recognition Performance

Based on statistics from all 172 samples, entity type recognition accuracy is illustrated in Figure 4. OPE entities achieved the highest semantic accuracy (90.1%), while TOOL entities showed relatively lower accuracy (51.9%) due to name simplification tendencies in LLM outputs.

Analysis: The high OPE accuracy (90.1%) indicates that the LLM most accurately understands disassembly operations, capable of completely capturing operational semantics. COM and BAT accuracies of 85.7% and 81.4% respectively primarily suffer from entity name simplification (e.g., “High-Voltage Battery Distribution Unit BDU” simplified to “BDU”). The relatively lower TOOL accuracy (51.9%) mainly stems from the LLM’s tendency to simplify tool names (e.g., “insulated protective gloves” extracted as “insulated gloves”), though the semantics remain correct. This issue could be addressed in future work by incorporating a domain-specific tool lexicon for post-processing normalization.

The lower TOOL accuracy primarily stems from the LLM’s tendency to simplify or abbreviate tool names (e.g., extracting “gloves” instead of “insulated protective gloves”, or “wrench” instead of “torque wrench”). While these simplified names are semantically understandable, they may cause issues in downstream applications where precise tool specifications are required for safety compliance. For instance, confusing “insulated gloves” with “cotton gloves” could lead to safety hazards during high-voltage disassembly operations. Despite the lower string-match accuracy, the semantic correctness of TOOL entities remains acceptable for most practical purposes.

4.2.3. Baseline Comparison

Figure 5 compares the proposed method with three baseline models. Our method achieved an entity F1 score of 83.2% and a relation F1 score of 76.8% under zero-shot settings, outperforming the supervised BERT-BiLSTM-CRF baseline while incurring zero annotation cost. The complete Precision, Recall, and F1 scores for all methods are presented in

Table 8. Precision, Recall, and F1 Scores of Baseline Comparison.

Method	Precision	Recall
BERT-BiLSTM-CRF	74.20%	79.50%
Traditional RAG + LLM	60.10%	64.80%
Few-shot (k = 5)	76.80%	80.20%
TSO-Prompt (0-shot)	82.50%	83.90%

.

Compared with the traditional RAG approach, TSO-Prompt achieved substantial improvements of 20.9% in entity F1 and 22.7% in relation F1, demonstrating the significant advantage of structured knowledge graphs over pure text retrieval. The zero-shot TSO-Prompt also outperformed the 5-shot setting (83.2% vs. 78.5% entity F1), indicating that explicit ontology injection is more effective than providing a small number of examples.

4.2.4. Few-Shot Comparison

To further investigate the impact of example quantity on extraction performance, we tested four settings: k = 0, 1, 3, and 5. The results in

Table 9. Results of the few-shot comparison experiment.

Shots	Success Rate	Average Number of Trios
0-shot	100%	4.9
1-shot	100%	3.6
3-shot	100%	4
5-shot	100%	4.1

show that the 0-shot setting already achieves a 100% success rate, and additional examples do not yield significant improvement.

These results confirm that TSO-Prompt achieves optimal performance under completely annotation-free conditions, realizing truly zero-cost, high-quality end-to-end knowledge extraction. The slight decrease in average triple count with few-shot examples (from 4.9 to 3.6–4.1) suggests that the examples may constrain the LLM’s extraction behavior toward more conservative outputs, whereas the zero-shot setting with explicit ontology injection encourages comprehensive coverage.

4.3. Ablation Experiments

To systematically validate the contribution of each component in the three-stage prompt strategy, we designed five ablation settings:

Full: The complete method with all three stages enabled.

-S2: Stage 2 (temporal completion) removed.

-S3: Stage 3 (ontology validation) removed.

-MI: Model injection removed (BCOT model definition excluded from the prompt).

Flat: BCOT hierarchical ontology replaced with a flat ontology (component/part/action/tool).

The experimental results are presented in

Table 10. Results of ablation experiments.

Ablation Setting	Validity Rate	Temporal Relations	Ontology Errors
Full (Complete Method)	87.90%	√	None
-S2 (without temporal)	80.60%	×	None
-S3 (without integrity check)	—	√	None
-MI (without mode injection)	0%	×	Significant
Flat (Flat Body)	0%	×	—

Note: The “-” prefix denotes the removal of the corresponding component (e.g., -S2 indicates without Stage 2). √ indicates the component is present, × indicates the component is absent. The “—” for -S3 indicates that validity rate is not applicable, as no validation was performed. In this setting, all triples directly enter the KG, resulting in approximately 8% of triples containing constraint violations.

.

Analysis:

(1)

Model injection is critical. Upon removing the BCOT model definition (-MI), the validity rate plummeted from 87.9% to 0%, with ontology errors increasing dramatically to 108. This compellingly demonstrates that explicit model injection is the key factor ensuring extraction quality—the LLM requires a clear domain knowledge framework to guide its extraction behavior. Without the injected ontology, the LLM generates entity types and relationship types that do not conform to the BCOT schema, rendering the extracted triples unusable.

(2)

Hierarchical ontology is indispensable. Replacing BCOT with a flat ontology (Flat) similarly failed to produce any valid triples. This confirms that hierarchical semantic constraints are fundamental to the structural validity of extraction results. Flat ontologies cannot express the layered dependencies between battery components, operations, and tools, leading to cross-layer relationship errors.

(3)

Temporal completion is effective. The complete method successfully supplemented temporal relations, whereas -S2 produced none. The operation chains generated by Stage 2 are essential for downstream disassembly sequence planning tasks. Without temporal relations, the knowledge graph captures what operations exist but not the order in which they must be performed—a critical piece of information for practical disassembly guidance.

(4)

Ontology validation ensures quality. When Stage 3 was removed (-S3 setting), approximately 8% of the total triples contained errors that violated BCOT constraints. These errors included relationship direction reversals (45% of errors), entity type misclassifications (30%), and constraint violations (25%). The complete method successfully filtered these errors through the ontology self-check mechanism, maintaining a 0% error rate in the final graph.

4.4. Graph Construction and Case Validation

4.4.1. Ontology Classification Accuracy

Based on statistics from all 172 samples, the LLM achieved 96.5% accuracy in determining entity ontology types (BAT/COM/OPE/TOOL), with deviations occurring only in a few boundary-ambiguous entities (e.g., “battery pack casing” misclassified as COM in rare cases). This result validates the effectiveness of the explicit model injection strategy—by embedding the complete BCOT model definition in the prompt, the LLM can accurately understand and follow ontological type constraints.

4.4.2. Knowledge Graph Visualization

The validated triples were imported into Neo4j to construct the BCOT ontology knowledge graph. Figure 6 visualizes the resulting graph, where nodes of different colors represent different ontology types: red nodes represent Battery (BAT), blue nodes represent Component (COM), green nodes represent Operation (OPE), and orange nodes represent Tool (TOOL). The graph clearly illustrates the ontological semantic associations from battery → component → operation → tool, validating the BCOT model’s capability for precise characterization of disassembly knowledge structures.

4.4.3. Case Study: Disassembly Sequence Query

To validate the practical utility of the BCOT ontology knowledge graph, we use the disassembly sequence query for “battery pack top cover” as a case study.

Query Task: “What is the complete disassembly sequence for the battery pack top cover?”

BCOT Graph Reasoning: Executing the following Cipher query on the constructed ontology graph:

MATCH (b: BAT {name: ‘battery pack top cover’})-[: contains]->(c: COM)<-[: needs]-(o: OPE) OPTIONAL MATCH (o)-[: uses]->(t: TOOL) OPTIONAL MATCH (o)-[: belongs_to]->(next: OPE) RETURN o.name AS Operation,             COLLECT(DISTINCT t.name) AS Tools,             next.name AS Next_Operation ORDER BY o.name

Query Result: The system successfully returned a structured disassembly sequence, as shown in

Table 11. Disassembly Sequence Query Result for Battery Pack Top Cover.

No.	Operation	Required Tools	Next Operation
1	Remove connecting bolts between battery pack cover and tray	[Torque Wrench]	Remove fastening bolts
2	Remove fastening bolts of battery pack cover	[Torque Wrench]	Remove battery pack cover
3	Remove battery pack cover	[Insulated Gloves]	—

.

Comparison with Flat Graphs: Compared with flat graphs where all entities and relationships are stored at the same level without ontological differentiation: (1) Query Path Length: The BCOT graph… reducing query path length by approximately 60%; (2) Result Accuracy: Flat graphs may return irrelevant operations, whereas the BCOT graph uses ontological constraints to precisely locate the exclusive operations for the target component; (3) Interpretability: The ontological structure of the BCOT graph naturally corresponds to the physical logic of disassembly processes, making the query process intuitively interpretable.

4.5. Discussion

4.5.1. Advantages of the Proposed Method

The experimental results demonstrate several significant advantages of TSO-Prompt. First, the method achieves true zero-shot knowledge graph construction, requiring no manually annotated training data and completing the entire process from unstructured text to a structured knowledge graph in approximately two hours. Second, the BCOT ontology model with its hierarchical constraints fundamentally prevents semantic errors, ensuring the logical consistency of the extracted knowledge. Third, the three-stage prompt strategy is model-agnostic—the successful validation on Qwen-plus suggests transferability to other LLMs. Fourth, the constructed knowledge graph directly supports practical downstream tasks such as disassembly sequence planning, demonstrating immediate industrial applicability.

4.5.2. Limitations

Several limitations should be acknowledged. First, the TOOL entity recognition accuracy (51.9%) requires improvement; the current method relies solely on the LLM’s inherent knowledge without a domain-specific tool lexicon, leading to name simplification issues. Second, the method has been validated on five battery models; generalization to a broader range of battery types and other complex products (e.g., aircraft engines, industrial robots) needs further investigation. Third, the current pipeline processes text independently for each battery model without exploiting cross-model knowledge sharing—batteries from different manufacturers may share common components and disassembly procedures that could be leveraged to improve extraction efficiency. Fourth, this study was conducted in a laboratory setting using pre-collected disassembly text data. No real-world deployment or factory-scale validation has been performed. Transferring the proposed framework to practical industrial environments would face several challenges, including: (1) integration with existing manufacturing execution systems and disassembly workstations; (2) handling of real-time streaming data from production lines; (3) adaptation to enterprise-specific disassembly protocols and safety regulations; and (4) user acceptance testing with disassembly operators. Fifth, the current experiments were conducted solely using Qwen-plus. The performance of TSO-Prompt may vary when applied to other LLMs. Sixth, the three-stage prompt templates were designed specifically for battery disassembly; the generalizability of these templates to other domains requires further investigation.

The current dataset consists of 172 disassembly steps from five battery models. While this provides a reasonable basis for initial validation, the dataset size is relatively small compared to the diversity of battery models in real-world recycling scenarios. Therefore, the reported results should be interpreted as preliminary evidence of the method’s effectiveness rather than a guarantee of equivalent performance across all battery types and industrial settings. Further validation on larger and more diverse datasets is needed before generalization to broader industrial applications.

4.5.3. Future Directions

Future work will focus on three directions: (1) incorporating a domain-specific tool lexicon with fuzzy matching mechanisms to improve TOOL entity recognition accuracy; the proposed lexicon will map simplified tool names to standardized technical names (e.g., “gloves” → “insulated protective gloves”, “wrench” → “torque wrench”) and include tool category hierarchies to support safety-critical disassembly operations; (2) exploring cross-model knowledge transfer to leverage shared disassembly knowledge across different battery models, reducing the extraction overhead for new models; and (3) extending the BCOT ontology and TSO-Prompt methodology to other complex product domains, validating the generalizability of the proposed approach. Additionally, multimodal data fusion incorporating images and videos from disassembly workstations could further enrich the knowledge graph with visual operation guidance.

5. Conclusions

This paper addressed the ontological characteristics and automatic construction challenges of power battery disassembly knowledge by proposing a TSO-Prompt method for automatic construction of disassembly knowledge graph. We formally defined the BCOT ontology knowledge representation model with four entity types and four relationship types, and designed a novel zero-shot prompt strategy integrating pattern injection, temporal completion, and ontology self-checking. Experimental results demonstrate that TSO-Prompt achieves 100% core semantic retention, 90.1% operation entity recognition accuracy, and a 6.4% entity F1 improvement over supervised baselines with zero annotation cost. Ablation experiments validated the critical role of explicit model injection and hierarchical ontological constraints, without which the validity rate drops to 0%. The constructed BCOT knowledge graph supports downstream disassembly sequence planning with approximately 60% query path length reduction over flat graphs. The proposed method aligns with the vision of Industry 5.0 by enabling automated knowledge extraction that can potentially support human-centric disassembly guidance, adaptive manufacturing processes, and sustainable material recovery.

However, several limitations should be acknowledged. First, the current dataset consists of 172 disassembly steps from five battery models; the dataset size is relatively small compared to the diversity of battery models in real-world recycling scenarios. Second, the TOOL entity recognition accuracy (51.9%) remains relatively low due to the LLM’s tendency to simplify tool names. Third, the method processes each battery model independently without exploiting cross-model knowledge sharing. Fourth, this study was conducted solely in a laboratory setting; no real-world deployment or factory-scale validation has been performed. Future work will focus on: (1) integrating multimodal data to enrich the knowledge graph; (2) exploring cross-domain transfer of the BCOT ontology and TSO-Prompt methodology; (3) developing cross-model knowledge sharing mechanisms; and (4) investigating the integration of TSO-Prompt with real-time disassembly systems for industrial deployment.