Rules vs ML vs DL vs LLMs

Start with which tool should own the decision

Define outcome, failure cost, data shape, label quality, latency, privacy boundary, explanation need, and maintenance owner. Then ask for the simplest testable system. Tool choice follows the decision contract, not fashion.

Explicit rules

Rules fit known invariants, compliance checks, and safe fallbacks. They are auditable and cheap, but become brittle when exceptions grow faster than the team can review them. A spreadsheet can be the right system when policy is stable and enumerable.

Classical machine learning

Linear models and tree ensembles are natural baselines for structured data with representative labels. They train quickly, support clear deployment-shaped evaluation, and usually have manageable serving costs.

Deep learning

Neural models are useful for images, audio, text, sequences, and large datasets when learned representations provide demonstrated lift. They require stronger compute, data coverage, monitoring, and artifact discipline.

Large generative models

Generative models fit open-ended language, code, or media when examples or instructions express the task better than fixed rules. They need task-specific evaluation, grounding where facts matter, cost and latency controls, and checks around variable output. No universal accuracy threshold makes them appropriate: 95% may be fine for drafting and unacceptable for medication or payments.

Real systems divide responsibility among layers

Rules may validate inputs, embeddings retrieve candidates, a classifier ranks risk, a generative layer drafts an explanation, and a human decides high-impact cases. Specify which layer can abstain, which has final authority, and how errors propagate.

Include operating cost in the comparison

Compare current workflow, rule baseline, simple learned model, and complex candidate on the same deployment-shaped evidence. Include acquisition, inference, latency, review burden, drift risk, and rollback—not only an offline metric. Prefer the smaller system when gains are within uncertainty or do not change the product decision.

Climb from the simplest layer only when evidence requires it

Complexity must purchase a measured capability the simpler design lacks. Document that capability, its evidence, and when the extra layer should be removed or replaced. The best architecture is the one the team can evaluate, operate, and improve without guessing.

Code

Decision template a team can argue against·python

def choose(problem):
    if problem.is_stable_and_auditable:
        return "rules"
    if problem.is_tabular and problem.has_labels:
        return "classical_ml_lightgbm"
    if problem.is_perception:
        return "deep_learning"
    if problem.is_unstructured_text and problem.labels_scarce:
        return "llm_with_eval_set"
    return "clarify_problem_first"

Always carry the rule-based fallback·python

def serve(features, model, rule_fn, ok_to_use_model):
    rule_decision = rule_fn(features)
    if not ok_to_use_model() or rule_decision is not None:
        return rule_decision  # auditable path
    try:
        return model.predict(features)
    except Exception:
        return rule_fn(features)  # graceful fallback