When enterprises build knowledge graphs, the real challenge is often not whether a graph can be built, but whether it can support real business needs after it is built.
Simply converting data from existing databases, business systems, and documents into nodes and relationships can easily result in a large and visually complex network.
But when business users actually start asking questions, they may find that:
The same device exists as multiple entities.Relationship directions are inconsistent.Data sources cannot be traced.It is unclear which node users should start from when querying.
The value of a knowledge graph does not lie in how many nodes and relationships it contains.
It lies in whether it can organize fragmented data according to unified business semantics and ultimately support real enterprise queries, analysis, and business decisions.
Therefore, when building an enterprise knowledge graph in the qKnow Intelligent Agent Building Platform, the starting point is not “How much data should be imported?”
Instead, it begins with two questions:
- First: How should an enterprise plan a knowledge graph that is genuinely usable?
- Second: Once the model is defined, how can qKnow gradually transform data into knowledge that can be queried, verified, and continuously updated?
1. Think Like an Enterprise Product Designer: Design the Graph Model Before Connecting the Data
Building a knowledge graph does not end once data has been imported into the platform.
A knowledge graph that can be used continuously needs to go through a complete process:
Business Problem Definition → Knowledge Graph Model Design → Data Integration → Knowledge Extraction → Manual Review → Entity Normalization → Knowledge Fusion → Graph Validation → Application → Feedback and Iteration
Only when this loop is established can a knowledge graph evolve from a one-time implementation into a continuously optimized system, improving its accuracy and usability through ongoing business use.
01. Start with One Question: What Problem Is This Knowledge Graph Supposed to Solve?
The first step in building a knowledge graph is not connecting databases or importing files in bulk.
What should be determined first is:
Who will use this graph? When will they use it? What questions do they need to answer? And what business action should be taken after the query is completed?
For example, in a pumping station equipment operation and maintenance scenario, when maintenance personnel receive an equipment alarm, they may need to continue querying:
- Which equipment or components are associated with the current fault symptom?
- What possible causes could have led to it?
- Has similar equipment experienced similar problems in the past?
- What maintenance measures have been used historically?
- Who should be responsible for handling the current issue?
Only around this business process should the first-stage graph be planned to include concepts such as:
- Main equipment units;
- Mechanical components;
- Electrical equipment;
- Sensors;
- Fault symptoms;
- Fault causes;
- Operating conditions;
- Maintenance strategies;
- Personnel;
- Historical cases.
In other words:
The scope of the knowledge graph should be determined by business questions, not by the enterprise’s existing data catalog.
If a certain type of data cannot currently help users complete a query, make a judgment, or take a subsequent business action, there is no need to include all of that data in the first phase simply because the volume is large.
02. Understand the Business Through Scenarios, Time, Space, Objects, and Processes
Enterprise business is naturally multi-dimensional.
A knowledge graph for equipment failures may contain business objects such as equipment, personnel, and components, while also involving time information such as alarm time and maintenance time.
It may also involve spatial information such as the pumping station and equipment area where the equipment is located, as well as business processes such as anomaly detection, diagnosis, work assignment, maintenance, and acceptance.
These dimensions can be understood as follows:
- Scenario dimension
Where is the graph used?
Examples: fault diagnosis, operation monitoring, inspection, maintenance.
- Time dimension
How do objects and events change over time?
Examples: alarm time, maintenance time, equipment status changes.
- Spatial dimension
Where is an object located, and which area does it belong to?
Examples: pumping station, equipment area, workshop, pipeline location.
- Object dimension
What are the core entities managed by the enterprise?
Examples: pumping station, main equipment unit, motor, sensor, personnel.
- Process dimension
How are business actions connected in sequence?
Examples: detecting an anomaly, diagnosis, work assignment, maintenance, acceptance.
- Organizational dimension
Who is responsible, who uses the knowledge, and who reviews it?
Examples: operation and maintenance team, maintenance personnel, equipment supervisor.
These dimensions should not be turned into several unrelated graphs.
For example, fault diagnosis can use equipment objects as the main axis, use time to describe when the fault occurred and how it was handled, use space to determine equipment location, and use process relationships to connect diagnosis, maintenance, and acceptance.
Multiple dimensions should be organized around the same business question.
03. Do Not Simply Divide Knowledge Graphs by Department or Business System
A common problem in enterprise knowledge graph development is to build separate graphs directly according to ERP, MES, document systems, or departmental boundaries.
This may appear clear, but it can easily create new knowledge silos.
For example, the same main equipment unit may exist simultaneously in the asset management system, maintenance system, and technical documentation.
If separate graphs are built for each system, the same equipment may eventually become three entities with no direct connection.
A more practical approach is to:
First identify the enterprise’s core business objects and establish unified identifiers, then associate attributes, records, documents, and business events from different systems with the same object.
Systems and departments can continue to serve as:
- Data sources;
- Management scopes;
- Permission boundaries.
But they should not automatically become the boundaries of the knowledge graph model.
04. Clearly Define Concepts, Attributes, Relationships, and Identifiers
In qKnow, the graph model provides the common foundation for:
- Structured extraction;
- Unstructured extraction;
- Knowledge fusion;
- Application queries.
A basically usable model should clearly define at least:
- Concepts：Business objects such as equipment, components, personnel, faults, and work orders.
- Attributes：Information such as equipment codes, models, locations, statuses, and timestamps.
- Relationships：Connections such as contains, belongs to, is responsible for, causes, affects, and requires.
- Unique identifiers：Used to determine whether two records represent the same entity.
- Relationship constraints：Define which types of concepts can establish certain relationships.
- Model versions：Define how changes to the model affect historical data and existing applications.
The first-stage model does not need to pursue a “large and comprehensive” structure.
Compared with establishing hundreds of concepts at once, it is more important to ensure that the names of core concepts, unique identifiers, and relationship directions remain stable, and that every newly added concept or relationship corresponds to a real business question.
A practical approach is to organize a set of real questions before modeling.
For example:
“What could be causing abnormal vibration in the main equipment unit?”
This requires equipment, fault symptoms, fault causes, and their relationships.
“What alarms have occurred in this area over the past month?”
This requires the graph to represent the area, events, and time together.
“Who is responsible for this maintenance task, and which spare parts were used?”
This requires a complete path connecting the maintenance task, personnel, equipment, and spare parts.
If a real business question cannot be transformed into a clear path of entities, attributes, and relationships, the model should be adjusted first rather than relying on manual interpretation after the data enters the platform.
Once model planning is complete, the actual data construction stage can begin.
2. Operational Workflow: Creating and Using a Knowledge Graph in qKnow
Using a Pumping Station Equipment Fault Diagnosis and Maintenance Knowledge Graph as an example, let’s look at how an enterprise knowledge graph can be gradually built in the qKnow Intelligent Agent Building Platform—from the model and data to the final business query.
The specific concepts, fields, relationships, data scope, and review roles should all be designed according to the enterprise’s own business requirements.
Step 1: Create the Target Knowledge Graph
Enter Knowledge Graph at the top of qKnow and create a new graph from the graph list.
The graph name should ideally reflect both the business object and the application purpose.
For example:
Pumping Station Equipment Fault Diagnosis and Maintenance Knowledge Graph
At the same time, configure the label, owner, and publication status.
During the first stage, it is recommended to keep the graph unpublished.
Only after the model, data extraction, and relationship checks are completed should it be formally opened for use.
When creating the graph, the initial scope should also be defined:
- What types of equipment are included?
- Which areas are covered?
- What time range is covered?
- Which business problems will the first phase solve?
- Which content will not be included for now?
This helps prevent the graph from expanding without clear boundaries during implementation.
Step 2: Establish a Unified Model Through Graph Model Management
Go to:
Graph Model → Graph Model Management → Add
Enter the model name, labels, department, and model description.
Under the same business topic, regardless of whether the data later comes from databases or technical documents, structured and unstructured extraction should, as far as possible, reuse the same graph model.
Before configuring the platform, the enterprise can first prepare a model list that clearly defines:
Concept Name → Business Definition → Unique Identifier → Core Attributes → Data Source → Owner
Special attention should be paid to differences in how the same business object is understood by different departments.
For example, if the equipment department, operation and maintenance department, and production department have different interpretations of the same object, the definition should be unified before entering the platform configuration stage.
Otherwise, when data from different departments enters the graph, those original differences in data definitions will also be introduced into the knowledge system.
Step 3: Configure Concepts and Attributes in the Graph
Enter Concept Configuration on the model details page.
Build the concepts required for the initial business scenario, such as:
Operation and maintenance personnel,Main equipment units,Mechanical components,Electrical cabinets,Valves and pipe fittings,Sensors,Fault symptoms,Maintenance strategies,Operating conditions
Five points require particular attention here.
- 1. Distinguish Between Objects and Categories
For example, Main Equipment Unit can be a concept, while Main Equipment Unit No. 1 is a specific entity.
Concepts and instances should not be mixed within the model.
- 2. Give Core Objects Stable Unique Identifiers
Equipment can use equipment codes.
Personnel can use employee IDs.
Materials can use material codes.
Otherwise, when data from different systems is integrated, duplicate entities can easily be created.
- 3. Attributes Do Not Need to Be as Numerous as Possible
Keep only the attributes that genuinely support business queries and decision-making.
For example, equipment model, operating status, installation location, and update time are more important than a large number of fields that will rarely be used by the business.
- 4. Standardize Time, Space, and Status Formats
For example, date formats, area hierarchies, and equipment status enumerations should be standardized in advance.
- 5. Concept Definitions Need to Be Understandable Across Roles
When model designers, data processing personnel, and business reviewers see the same concept, they should understand it as the same business object.
Step 4: Configure Relationships and Directions Between Entities
After completing the concepts, enter Relationship Configuration.
When configuring relationships, clearly define:
Start → Relationship → End
For example:
- Operation and maintenance personnel → Responsible for → Main equipment unit
- Mechanical component → Belongs to → Main equipment unit
- Fault symptom → Causes → Maintenance strategy
At the same time, determine whether the relationship should be reversible based on the business scenario.
Relationship names should preferably use verbs with clear business meaning rather than relying heavily on vague relationships such as “related to,” “associated with,” or “other.”
Another easily overlooked issue is query direction.
If users frequently need to “search from a fault to its cause,” the relationship paths in the model should allow them to continue querying from the fault symptom to the fault cause.
Relationship definitions are also part of the subsequent knowledge retrieval experience.
Step 5: Prepare Databases and Enterprise Knowledge Files
Once the model is complete, the process moves into the data integration stage.
The knowledge sources handled in qKnow can generally be divided into two categories.
- 1. Structured Data
Database connections can be configured through:
Data Management → Data Sources
The following should also be clearly defined:
- Connection information;
- Data tables;
- Primary keys;
- Update times;
- Subsequent synchronization frequency.
2. Unstructured Knowledge
Examples include:
- Fault reports
- Maintenance summaries;
- Technical manuals;
- Acceptance records;
- Operation and maintenance documents.
These materials can first enter the Knowledge Center or Knowledge Files, where file versions, applicable scope, and parsing quality should be confirmed.
Before formal extraction, it is recommended to first establish a data mapping:
Which table or file → Which concept → Which field corresponds to which attribute → Which fields generate which relationships
Do not simply turn a database table name directly into a concept and a field name directly into a graph attribute.
Database structures solve data storage problems.Graph models express business semantics.The two are not completely equivalent.
Step 6: Create Unstructured Knowledge Extraction Tasks
For technical documents, fault reports, and maintenance records, go to:
Knowledge Extraction → Unstructured Extraction → Add
Enter the task name, select the corresponding files from the Knowledge Center, and import or configure the triples that need to be extracted.
The same extraction task should, as far as possible, process files with similar content structures and business types.
For example:
- Fault reports can form one task.
- Technical manuals can form another task.
- Maintenance summaries can form a separate task.
After the task is executed, check the results in:
Extraction Results and Execution Logs
Pay particular attention to:
- Whether entity boundaries are correct;
- Whether relationship directions are correct;
- Whether a large number of synonymous entities have been created;
- Whether knowledge has been generated without support from the source content;
Completing unstructured extraction does not mean the knowledge is ready to enter the formal graph directly.
Results that have not undergone business review should not be published for direct use.
Step 7: Create Structured Knowledge Extraction Tasks
For data such as equipment records, alarm records, and maintenance work orders in databases, structured extraction can be used.
Go to:
Knowledge Extraction → Structured Extraction → Add
The process generally includes three core stages:
Basic Information → Table Mapping → Relationship Mapping
Basic Information:Select the data source and configure the data update method.Depending on actual business requirements, you can configure full updates or incremental updates, as well as the execution frequency for subsequent tasks.
Table Mapping:Map business tables in the database to the graph concepts that have already been designed, while mapping fields to concept attributes.
Relationship Mapping：Establish relationships between entities based on primary keys, foreign keys, or other associated fields.After configuration is completed, it is not recommended to synchronize all production data immediately for the first run.
A more cautious approach is:
Test Connection → Sample Review → Small-Scale Execution → Check Entities and Relationships → Expand the Synchronization Scope
After the task is completed, check the extraction logs, including:
- Success status;
- Failure status;
- Start time;
- End time.
Even if the task status shows “Success,” it is still necessary to sample the generated entities, attributes, and relationships to verify whether they actually conform to the business model.
Step 8: Conduct Business Review of Knowledge Extraction Results
Once a knowledge graph enters enterprise business use, technical “successful task execution” and business-level “correct knowledge” are two different concepts.
Therefore, extraction results need to undergo further review.
Business users should focus on checking:
- Whether entity names are complete;
- Whether unique identifiers are accurate;
- Whether duplicate entities have been generated;
- Whether attribute values, units, time, and data sources are correct;
- Whether relationship names and directions conform to the model design;
- Whether the knowledge actually comes from the corresponding original data or files.
Role boundaries also need to be clearly defined.
Platform administrators can be responsible for:
- Connection status;
- Task status;
- Platform operation issues.
Business roles such as equipment experts and operation and maintenance personnel should be responsible for whether the knowledge itself is correct.
Technical review and business review cannot replace each other.
Step 9: Use Entity Normalization and Knowledge Fusion to Resolve Different Names for the Same Object
Once enterprise knowledge is truly aggregated, a very common problem appears:
The same object may have different names in different data sources.
For example, the same equipment may be described as:
- Main equipment unit;
- Pump unit;
- Water pump unit.
Without normalization, these may become three separate entities.
In qKnow, users can go to: Knowledge Fusion → Entity Normalization to maintain standard names and corresponding aliases.
A knowledge fusion task can then be established to identify duplicate or similar entities.
The system can display candidate entities, attributes, and their associated triples.
Reviewers can then determine based on the actual data:
Same entity / Different entities / Temporarily unable to determine
However, entity fusion should not rely only on name similarity.
For example:
- Equipment should primarily be checked against equipment codes, models, and locations.
- Personnel should primarily be checked against employee IDs and departments.
- Materials should primarily be checked against material codes and specifications.
If attributes from different sources conflict, the enterprise also needs to define in advance:
Which source has priority, and how should data with different update times be handled?
Only after these rules are defined can multi-source enterprise data truly be organized around unified business objects.
Step 10: Use Graph Exploration to Check the Model and Data
After the knowledge is published, enter Graph Exploration.
qKnow provides:General View,Relationship View,Timeline View,Table View.
These views are not simply different ways of displaying the graph.
They can also support different types of checks.
For example:
- General View:Check the overall graph structure.
- Relationship View:Check the components, faults, personnel, and maintenance strategies surrounding a specific equipment entity.
- Timeline View:Check how equipment status, alarms, and maintenance events change over time.
- Table View:Directly verify subjects, relationships, objects, and data sources.
Here again, it is recommended to start from real business questions rather than simply checking whether the graph is “complex enough.”
For example, search for a known main equipment unit and:
- Check whether its core attributes are complete.
- Continue expanding to its associated components.
- Check which faults have occurred.
- Check which causes and maintenance measures correspond to those faults.
- Check which personnel are responsible.
- Check whether different events have the correct timestamps.
- Check whether the equipment is associated with the correct area.
If isolated nodes, duplicate nodes, or incorrect relationship directions are discovered, return to the model, knowledge extraction, or fusion stages for further adjustment.
Step 11: Use Entity-Relationship Search to Verify Whether the Graph Is Truly Usable
At this stage, the acceptance criterion should not simply be:
“The data has entered the graph.”
The process still needs to return to the business questions defined at the beginning.
Go to:
Application Center → Cross-Functional General Applications → Entity-Relationship Search
Enter entity or relationship keywords.
Multiple keywords can be separated by commas, while the search scope, labels, and advanced search conditions can also be used.
For example, the original set of business questions can be used for first-stage validation.
- Enter Main Equipment Unit, Abnormal Vibration to check whether the relevant entities and associated graph can be found.
- Enter Communication/Sensor, Loose Wiring to check whether the corresponding fault and “causes” relationship can be found.
- Enter an area and time condition to check whether the corresponding alarms and maintenance events can be located.
- Enter a specific component to continue viewing its associated equipment, historical faults, and maintenance strategies.
If there are too many results, advanced conditions such as concepts, relationships, and labels can be used to narrow the search.
If the expected object cannot be found, troubleshooting can follow a relatively clear path:
Has the data been integrated → Is the mapping correct → Was the extraction task executed → Has the result been published → Was the entity incorrectly fused → Has the retrieval index been updated
This is also an important step in moving knowledge graph development from a construction problem toward engineering-oriented troubleshooting.
Step 12: Continuously Adjust the Graph Based on Real Usage
An enterprise knowledge graph does not remain unchanged after a one-time data import.
New equipment will be added.
Documents will continue to be updated.
Business rules will change.
Users will also raise new query requirements.
Therefore, application feedback needs to continuously flow back into the knowledge construction process.
For example:
Cannot find an entity or case:Add data sources, files, or synchronization scope.
Incorrect entity or relationship recognition:Adjust extraction rules and review again.
Different names for the same object / same name for different objects:Improve primary keys, aliases, and fusion rules.
Unable to represent real business questions:Adjust concepts, attributes, relationships, and relationship directions.
Inaccurate time or spatial queries:Standardize time formats, location hierarchies, and mappings.
Data is not updated for a long period of time:Clarify update frequency, task status, and responsible personnel.
For important model changes, their impact on existing data, extraction tasks, and application queries should also be evaluated.
Model version records should be maintained, and corresponding tasks should be executed again when necessary.
The Final Acceptance Criterion Should Not Be the Number of Nodes
Whether a knowledge graph has been successfully built should not be judged only by:
- Number of nodes;
- Number of relationships;
- Complexity of the visualization page.
More importantly, enterprises should check whether:
- Real business questions can be transformed into clear entity and relationship paths.
- Core entities have unified identifiers and trustworthy data sources.
- Time, space, objects, and business processes can be correctly associated.
- Extraction results have been reviewed and errors can continue to be traced.
- Entity-relationship search can support real troubleshooting and analysis.
- New data can continuously enter the graph according to the defined process.
If a graph can only display a complex network of nodes but cannot help the enterprise complete queries, make judgments, or take subsequent business actions, then it has still not solved the problem of “building a graph just for the sake of building one.”
Conclusion
For enterprise intelligent agents, the significance of a knowledge graph is not simply to add another form of knowledge storage.
What it truly addresses is:
How to organize structured data in databases, unstructured knowledge in enterprise documents, and business objects distributed across different systems through unified semantics and clearly defined relationships.
In qKnow, this process can start with business questions and graph model design, then gradually move through:
Data Integration → Knowledge Extraction → Manual Review → Entity Normalization → Knowledge Fusion → Graph Exploration → Entity-Relationship Search
Issues discovered during application can then be fed back into the model and data processing stages.
Plan the model before connecting the data.
Ensure knowledge is trustworthy before validating actual applications.
When this closed loop can operate continuously, the knowledge graph is no longer merely a visualization result.
It can gradually become the knowledge foundation that enables enterprise intelligent agents to understand business objects, connect enterprise knowledge, and support subsequent applications.
Top comments (0)