Qian Xuesen’s 1954 Engineering Control Theory: The Unexpected Blueprint for Large‑Model Harnessing and Ontology

1. A Story

In 1954 Qian Xuesen wrote "Engineering Control Theory" to make rockets obey commands, long before computers or AI.

Seventy years later engineers at OpenAI and DeepSeek encounter the same problems when training large models: black‑box behavior, difficult testing, and crashes after a single adjustment.

Many overlook a deeper question: what exactly are we trying to control?

This is the domain of ontology.

2. Three Concepts in Plain Language

Ontology – “What is it?”

It asks: what entities exist in the world and how are they related?

In practice: identify the “cards” you are playing with.

Medical model: “disease”, “symptom”, “drug”.

Legal model: “statute”, “case”, “party”.

Autonomous driving: “pedestrian”, “traffic light”, “lane marking”.

Ontology provides a concept map of the domain.

Without it you are “shooting in the dark”.

Engineering Control Theory – “How to control?”

Given a goal, how to make the system obey?

In plain terms: once you know the cards, how to play them to win.

This corresponds to the “observe → think → act → correct” loop.

Harness – “Measure accurately”

How to know whether the system actually works?

In plain terms: run a round, see if you win, then adjust for the next round.

The three are linked:

Ontology (what) → Control Theory (how) → Harness (measure)
    ↓                ↓                ↓
Build concept map   Design control   Verify effect
“Clarify object”    “Make object obey” “Confirm it truly obeys”

Without ontology, control theory is blind; without control theory, harness is random; without harness, the first two are just self‑satisfaction.

3. Why Large Models Need Ontology

Scenario 1: Medical Models

Team without ontology: “We tested the model on 1,000 medical questions.”

Problem: what kinds of questions? diagnosis, prescription, anatomy? Are they exhaustive?

Team with ontology (using SNOMED‑CT): built a taxonomy of 12 top‑level and 156 sub‑categories, ensuring full coverage and no missing relations.

Difference: the former merely piles questions; the latter builds a map.

Scenario 2: Legal Models

Team without ontology: “The model scored 85 on a legal exam.”

Team with ontology (law‑ontology of statutes‑cases‑elements‑consequences): evaluated on “causal‑relation identification”, “statute‑citation accuracy”, and “case‑matching”.

This pinpoints whether the issue is “not understanding statutes” or “cannot apply them”, etc.

Scenario 3: Multimodal Models

Without ontology: the model is a “messy stew”.

“The model looks good on images… maybe?”

With ontology: a visual ontology defines four layers – “object”, “attribute”, “relation”, “event”. Evaluation is split into “recognition”, “description”, “reasoning”, “prediction”.

This yields a controllable, measurable system.

4. The Ontology‑Control‑Harness Closed Loop

Combining the three yields a complete engineering framework:

Step 1: Build Ontology
   Define concepts → Sort relations → Build hierarchy → Form map
   ↓
Step 2: Set Goals (Control Theory)
   Derive metrics from ontology → Every concept gets an evaluation point
   ↓
Step 3: Create Sensors (Harness)
   Generate tests aligned with ontology → Cover every node and relation
   ↓
Step 4: Run Closed Loop (Feedback Control)
   Evaluate → Locate weak concepts → Targeted training → Re‑evaluate

Key insight: Harness sensors must align with the ontology.

If the ontology contains “causal relation”, the harness must include causal‑reasoning items.

If the ontology links “drug–side effect”, the harness must test that relation.

If the ontology lacks “rare disease”, the harness cannot measure it, and the model will never learn it.

Thus ontology sets the ceiling for harness effectiveness.

5. Real‑World Example: Medical Model Ontology‑Based Harness

Steps (converted from the original table):

Build Map : Define a five‑element ontology “disease‑symptom‑exam‑drug‑prognosis”.

Set Goal : Require >90 % accuracy on each node.

Create Tests : Generate questions covering 156 ontology nodes.

Evaluate : Discovered low score on “drug interaction” node.

Diagnose : Root cause – unclear “drug‑drug” relation in ontology.

Fix : Enrich ontology with missing relations; adjust training data distribution.

Validate : Add adversarial tests; re‑evaluate and confirm improvement.

The problem originated in the ontology, manifested in the harness, and was resolved by returning to the ontology.

6. Three Takeaways

If you are an algorithm engineer

Don’t rush to benchmark; first draw a concept map. Does your test set have ontology support, or is it just “feels right”?

If you are a product manager

The requirements document is the ontology. “Smart客服” is not a requirement; the ontology “user intent‑business scenario‑response strategy” is.

If you are a founder

The clarity of your business‑domain ontology determines how far AI can go. Fragmented knowledge limits large‑model deployment.

7. One‑Sentence Summary

Ontology answers “what”, control theory answers “how”, and harness answers “measure accurately”; together they form the complete paradigm for large‑model engineering.