Symbolic AI and Machine Learning

Learning outcomes

After studying this lesson, you will be able to:

• explain symbols, rules, knowledge bases, and inference engines;
• describe the ML cycle: data, training, model, and inference;
• distinguish explicit logic from parameters learned from data;
• choose an approach based on task requirements and constraints;
• recognize hybrid systems and explain their architecture.

1. What is symbolic AI?

Symbolic AI represents objects, relationships, and knowledge through symbols and structures: names, categories, logical expressions, graphs, rules, and facts. A system operates on these representations to derive conclusions or select actions.

A knowledge base might contain the fact “pump P-17 is located in room R-2” and the rule “if bearing temperature exceeds a threshold, raise a warning”. An inference engine checks the conditions and activates the conclusion.

Core components

• Knowledge representation: how objects, properties, relationships, and constraints are encoded.
• Facts: statements about a specific object or situation.
• Rules: IF–THEN constructions connecting conditions to conclusions or actions.
• Inference engine: a procedure that applies rules to facts.
• Explanation trace: the sequence of facts and rules that led to an output.

2. Example: a rule does not learn

def diagnose_temperature(temp_c, limit_c=85):
    if temp_c > limit_c:
        return {"status": "warning", "reason": "threshold exceeded"}
    return {"status": "normal", "reason": "within rule limit"}

print(diagnose_temperature(92))

The 85 °C threshold is specified by the developer. The program compares a measurement with the threshold, but does not estimate it from training examples. The presence of input data does not by itself mean machine learning.

3. Logical inference, search, and planning

Forward chaining starts with known facts and applies rules to derive new facts. Backward chaining starts with a hypothesis and searches for facts and rules that could support it.

Search operates over states and possible actions. A navigator may search a road graph; a planner may choose an operation sequence under resource constraints. These can be useful AI systems without training a neural network.

4. What is machine learning?

In ML, a model adjusts parameters using data or experience to perform a specified task. Developers still define the problem, choose a model family, prepare data, and specify an evaluation criterion. The algorithm estimates parameters from examples.

1. Data: observations, features, and target values.
2. Model: a family of functions with adjustable parameters.
3. Objective: a loss function or another performance measure.
4. Training: parameter estimation on training data.
5. Validation: evaluation on data not used for fitting.
6. Inference: applying the trained model to new data.

5. What does a model learn from data?

In a linear model, parameters may be coefficients; in a decision tree, split conditions; in a neural network, weights and biases. Training does not guarantee discovery of causal laws: the model optimizes a specified objective on available data.

Biased or incomplete data can produce undesirable patterns. Target leakage inflates evaluation scores. Data provenance, proper splits, and independent evaluation are essential parts of ML.

6. Comparing the approaches

7. When to use each approach

Rules are suitable when requirements are precise, logic is stable, and decisions must be auditable—for example, checking a sensor range or a required form field.

ML is useful when a pattern is difficult to describe manually, but representative examples are available and errors can be measured—for example, image defect detection or demand forecasting.

Choose based on the task, not fashion. A simple threshold rule may be more reliable than a complex model; hand-written rules may become brittle for visual and language tasks.

8. Hybrid AI systems

A real product may combine an ML model, rules, document retrieval, and human approval. For example, a model estimates equipment failure risk from vibration; rules check critical limits; retrieval finds manuals and repair history; an engineer decides. Calling the entire product “a neural network” is inaccurate: the network is one component.

9. Case study: monitoring a pump bearing

Imagine an industrial pump. A sensor measures bearing temperature, and an engineer wants to detect dangerous operating conditions early. A simple rule might say, “above 85 °C means an alarm.” Real operation is more complex: temperature depends on load, ambient conditions, start-up state, rotational speed, and lubrication. The same reading may be normal in one operating regime and concerning in another.

Option A: explicit rules

An expert defines several testable conditions: stop the pump above a critical safety limit; issue a warning when temperature rises faster than a specified rate; and request sensor inspection when the sensor is faulty instead of inferring bearing condition. Such rules are appropriate for mandatory safety constraints. They can be reviewed, approved, and traced in logs. However, rules require domain knowledge, and exceptions can make the rule set increasingly complex.

Option B: a model trained on data

Historical measurements of temperature, vibration, and load are collected together with inspection outcomes. Each time window receives a target label, such as “a defect was found within the next 24 hours.” A model learns combinations of features associated with that label. It is not given a universal hand-written temperature threshold. Instead, an algorithm adjusts parameters to reduce error on training examples.

The model is then evaluated on a later time period that was not used for fitting. This matters: randomly splitting adjacent sensor readings may place nearly identical fragments of the same failure event in both training and test sets. The reported score would exaggerate the system’s ability to work in the future.

Option C: a hybrid

The model estimates risk, independent rules enforce safety limits, and an engineer approves actions with high consequences. Each component has a distinct role: the statistical model detects complex signal combinations; rules enforce hard constraints; a person supplies context and makes the final decision. A hybrid is not automatically reliable: data hand-offs, rule priority, and behaviour when the model is unavailable must all be tested.

10. What model training actually does

Suppose a model predicts a simplified overheating risk from two features: temperature and vibration. Logistic regression calculates a weighted sum and transforms it into a value between 0 and 1. That value can be interpreted as a probability only when the task is correctly defined and the model is calibrated; it is not a guarantee.

During training, the algorithm compares predictions with known labels and changes coefficients to reduce a loss function. Keep four concepts separate:

• Features are measurements supplied as model inputs.
• The target variable is what the model is expected to predict.
• Parameters are values estimated by the training algorithm.
• Hyperparameters configure the training procedure separately, such as regularization strength.

If an engineer manually chooses coefficients and a threshold, those parameters have not been learned from data. If an algorithm estimates coefficients from labelled examples, it is machine learning—even when the resulting formula is simple and interpretable.

11. Evaluating a model without fooling ourselves

A model should not be evaluated only on examples used for training. The training set fits parameters; the validation set helps select a configuration; the test set provides a final independent estimate. Time-dependent data usually requires chronological splits. For multiple machines or patients, check whether related observations have leaked across the splits.

Metrics must reflect the cost of errors. In fault detection, missing a dangerous event and raising an unnecessary alarm are not equivalent. Accuracy can be misleading when failures are rare: a model that always predicts “no failure” may score highly while being useless. Precision, recall, a confusion matrix, a precision–recall curve, and decision costs may be more informative.

Robustness must also be checked when conditions change: new equipment, a different sensor, seasonality, or a changed operating regime. A change in the data distribution is often called drift. Strong performance on an old dataset does not guarantee performance after drift.

12. A practical decision framework

1. Can the rule be stated precisely, including its exceptions?
2. How important is it to audit every step of the decision?
3. Are enough representative examples available with reliable labels?
4. Can the consequences of false alarms and missed events be measured?
5. Will the operating environment change?
6. Must hard constraints be combined with a probabilistic estimate?

If a rule is short, stable, and safety-critical, replacing it with a model merely to use ML is usually unjustified. If the task involves complex images, speech, or many interacting signals, hand-written rules may be too brittle. If both flexibility and hard constraints are needed, consider a hybrid architecture.

13. Common design mistakes

• Confusing data with learning. A program can process millions of records and still consist entirely of pre-written rules.
• Calling every adaptation ML. An operator changing a threshold is not the same as an algorithm estimating parameters from examples.
• Assuming ML removes human decisions. Problem framing, data collection, metric selection, and operational oversight remain engineering responsibilities.
• Calling a hybrid product a neural network. That hides the roles of rules, search, databases, and people.
• Treating correlation as cause. A predictive association may disappear when conditions change.

14. Practical task