Context Enrichment & Plant Memory

Context Enrichment & Plant Memory

Classification accuracy comes from how much relevant context the LLM sees before it answers. This page covers the parts of the platform that build and maintain that context.

The retrieval pipeline, in plain terms

Before the LLM classifies a signal, the platform:

  1. Pre-processes and translates the description — expanding domain abbreviations (see Vocabulary, below) and translating it into English IEC technical vocabulary while preserving numeric identifiers (unit numbers, sensor numbers, …).
  2. Retrieves the most relevant supporting evidence from three vector collections: general Reference signals, previously Validated signals, and — if a plant is set — that plant's own PlantSignal_{rds_top_node} collection (see Plant Collections, below). Retrieval is hybrid (keyword + semantic) so exact codes and unit numbers aren't lost the way pure semantic search can lose them.
  3. Reranks the candidates with a dedicated cross-encoder model before handing the short list to the classification step.

Signals retrieved from a plant's own history are trusted more than generic reference signals or other plants' validated signals — same-plant evidence is the strongest signal the pipeline has that a code is correct for this plant specifically.

Vocabulary

The Vocabulary page (sidebar → Config → Vocabulary, route /vocabulary) manages the two files the pre-processing step uses to expand domain abbreviations before translation:

  • single.txt — single-word abbreviations.
  • bigrams.txt — multi-word abbreviation pairs.

Both use the same format, one entry per line: key: value1, value2, … — where key is the canonical expansion and the comma-separated values are the abbreviations that should expand to it (e.g. Turbine: TB, TURB). The page is a full code editor with syntax highlighting; saving is blocked if a line doesn't match the key: value, value format, with the offending line number reported. There's no dedicated "add term" form or delete button — you edit the file's text directly, the same way you'd edit any line-delimited config file.

Vector DB Config

The Vector DB Config pages (sidebar → Config → Vector DB Config, routes /vector-db-config/master|reference|validated-signals|ontology) are sync and operations pages, not data browsers — you won't see individual records here. Each tab:

  • Shows the live connection status to both the SQL source and Weaviate.
  • Lets you configure the SQL connection (host, port, database, credentials).
  • Offers Start Sync to pull current data from SQL into the matching Weaviate collection (Master = BL0/BL1/BL2 hierarchy, Reference = reference signal library, Validated Signals = human-validated signals), with live progress shown as the sync streams.
  • Offers Recreate Collection — a destructive option that drops and rebuilds the collection from scratch before syncing; use it after a schema change, not for routine refreshes.

The Ontology tab is the exception to the pattern above: its source is not the SQL database but the RDF knowledge backend, so it has no connection form. It reads RDF_KNOWLEDGE_BACKEND_URL and RDF_KNOWLEDGE_BACKEND_API_KEY from the server environment, and Test connection simply checks that {URL}/docs answers 200. Start Sync downloads the whole ontology, parses it, turns every OWL entity (class, property, individual) into one OntologyChunk, and uploads them keyed by entity URI — so re-running without Recreate Collection updates existing entries in place instead of duplicating them. Changing the two environment variables requires an application restart to take effect.

Plant Collections

The Plant Collections page (sidebar → Config → Plant Collections, route /plant-collections) is where each plant's own validated-signal history lives — the PlantSignal_{rds_top_node} collection that the retrieval pipeline draws same-plant evidence from. Signals land here when you click Persist at the end of a supervised Classify Bulk run (see Classification Modes).

The sidebar lists every plant with saved signals and how many it holds; click one to open its panel (/plant-collections/{plant} deep-links directly to it). The panel header offers two actions:

  • Delete all — clears every signal for that plant.
  • Recreate collection — drops and rebuilds the collection from scratch; flagged with a warning since it's irreversible.

Below the header, a paginated table lists that plant's signals — description, full classified code, the BL0/BL1/BL2 breakdown, and the Logical Node class — with a delete button per row.

Building up this collection plant by plant is what lets future classifications for that same plant draw on its own corrected history, in addition to general reference and validated signals — the system gets more accurate for a plant the more it's used on that plant.