Construction pipelines and knowledge refinement

5.1 Treat construction as an iterative process

Knowledge graph construction is usually an ongoing process of acquisition, reconciliation, validation, and revision. Zhong and colleagues review acquisition, refinement, and evolution as major parts of automatic construction [3]. This broader view is useful because a graph rarely stays correct after a single import. Sources change, extractors improve, and users discover mistakes. A design that anticipates revision can turn those changes into routine maintenance rather than repeated reconstruction from scratch.

The proposed pipeline begins with a source inventory. Each source receives an identifier, owner, access policy, format, update schedule, and permitted use. A content hash identifies an exact file version, while metadata records the acquisition date and original location. The raw source is retained separately from extracted text. This separation lets the team diagnose whether an error came from the original document, text conversion, model interpretation, or later reconciliation.

Parsing produces structural units such as sections, paragraphs, tables, captions, and references. Chunking（分块）then creates processing units while preserving links back to the document structure. Chunk size should follow the task. Entity detection may need local context, while interpreting a result can require the methods section and table notes. Overlapping chunks help preserve context but create duplicate candidates, so the merge policy must recognize that several extractions may come from the same underlying passage.

5.2 Separate staging from accepted knowledge

A staging area（暂存区）holds candidate entities and claims before acceptance. The main graph serves records that satisfy the current acceptance policy. This separation gives the system a place to keep uncertain outputs without presenting them as established knowledge. Rejected candidates can remain available for debugging with appropriate retention controls. The staging area should record the reason for rejection so that the team can distinguish malformed output from unsupported meaning.

An extraction run receives a versioned configuration: model, prompt, schema version, parser, chunker, and relevant parameters. Reprocessing the same document with a new model produces a new run rather than silently replacing the old record. The system can compare outputs and decide which changes to accept. This is especially valuable when a model update improves recall while introducing a new kind of false positive. Without run level provenance, the resulting graph changes are hard to explain.

Idempotency（幂等性）means that repeating an ingestion operation does not create unintended duplicates. A practical key might combine document version, source span, relation type, normalized arguments, and extraction policy. The key must reflect the semantics of the record: two separate experiments in one document should not merge merely because they share the same method and dataset. Idempotency therefore requires both technical identifiers and a clear definition of what counts as the same assertion.

5.3 Fusion conflict and review

Knowledge fusion（知识融合）combines information from different sources while preserving its origin. A simple attribute such as a publication year can still conflict because a preprint, online publication, and issue date differ. A resolution policy should identify which date the application needs rather than choosing the most common value. For source dependent attributes, the graph may retain several values with qualifiers and expose a preferred value for a specific view.

Duplicate detection should distinguish repeated reporting from independent evidence. A journal article and its preprint may be versions of one study. A review article may summarize that study without adding a new experiment. A social media post may repeat the review. If all three are counted as separate supporting studies, the graph creates a false impression of consensus. Modeling publication lineage and evidence origin helps prevent this error, though ambiguous cases may still require review.

Human review should have a defined scope. A reviewer may confirm that an extraction matches the source without endorsing the source's scientific conclusion. Another reviewer may assess methodological quality. The system should record these as different activities. Otherwise, a generic “reviewed” label can be interpreted too broadly by downstream users. The same principle applies to automatic checks: passing a datatype validation is not equivalent to passing a scientific reliability review.

5.4 Updates deletions and repair

Incremental updates should identify which derived records depend on a changed source. If a document is corrected, its claims, summaries, embeddings, and cached answers may all need revision. A dependency graph（依赖图）can track these relationships. The graph itself then becomes part of the maintenance mechanism: it tells the system which outputs may have become stale. Dependencies should be recorded when artifacts are created, because reconstructing them later is often unreliable.

Deletion requires a policy for original content, extracted representations, backups, and derived artifacts. Removing a raw file while leaving its text in an embedding store does not fully remove the information from the system. Similarly, deleting a claim while retaining a community summary that repeats it can continue to mislead users. A repair process should propagate changes across every relevant representation and record the state of that propagation.

A failed update should not leave the accepted graph halfway between versions. Small related changes can use a transaction（事务）; larger imports may use a staged release and switch the active snapshot after validation. The choice depends on database capabilities and data volume. The important requirement is that users can identify which coherent version they are querying. An explicit snapshot identifier is often more informative than a vague “last updated” timestamp on the homepage.

5.5 Construction as a measurable service

Pipeline monitoring should include source freshness, extraction coverage, unresolved identities, validation failures, review backlog, and repair time. These measures describe whether the system is keeping up with its knowledge obligations. Node and edge counts alone are weak indicators. A rising edge count could reflect successful enrichment, duplicate imports, or a model that overproduces speculative relations. Operational metrics should connect to the competency questions established during schema design.

The proposed service publishes a small release report with each graph version. It lists changed sources, accepted and rejected assertions, schema changes, and known limitations. For a personal project, this report can be a simple file. For an organization, it may feed a dashboard and audit process. Its purpose is to make knowledge maintenance visible and repeatable, so that confidence in the graph rests on observable practices rather than on the apparent sophistication of the extraction model.