2.3 Where AI could enter: retrieval, learning and language

The classical trio of the previous section computes from rules and equations. The obvious question follows: could any of this work be done — or done better — by systems that learn from data instead? That is where the second half of the taxonomy lives. Three mechanisms genuinely learn, and they are the ones this whole study is really about.

2.3.1 The AI trio: K, ML, L

• K — Retrieval (similarity search; K for knowledge, the layer of work it serves — see §2.4). "Find past parts like this one." Given a new geometry, search an archive for the closest previous designs and surface what happened to them — their gate positions, their mould changes, their defects. Retrieval is the quiet, underrated mechanism: it learns a useful representation of shape from raw geometry, and, crucially, it needs no outcome labels — an archive of CAD files is enough to build it. It does not predict anything; it reminds you of what you already have.
• ML — Machine learning. Models trained to map an input to an output from examples: a surrogate that predicts warpage from geometry, a neural solver that imitates a physics run in a fraction of the time, a vision model that spots a defect on a moulded part. This is learning in the full sense — the model's behaviour comes from the data it was trained on, not from equations a person wrote. It is also the mechanism with the steepest data requirements.
• L — Language models (document AI). The LLMs behind chatbots, copilots and retrieval-augmented (RAG) assistants. They genuinely learn — but they learn language and documents, not physics. An LLM can read a requirements specification, draft a report, or answer "what does our standard say about rib thickness?" It has no model of what a rib actually does in a mould — only of what people have written about ribs.

2.3.2 What the learning mechanisms learn from

A learning system is only as good as what it is trained on, and in this field the learned systems — ML models and language assistants alike — tend to be taught by one of three teachers:

1. Simulation-taught (ML). Trained on the outputs of a physics solver. A surrogate or neural moulding solver learns to reproduce what the simulator would have said, much faster. Useful — but it can never be more right than the simulation it imitates, because the simulation is all it ever saw.
2. Document-taught (L). The copilots and RAG assistants of the previous section. They learn from text and drawings, so they help with navigation and paperwork, and know nothing about the physics of the part.
3. Sensor-taught, in-process (ML). Trained on signals from a running press — cavity pressures, melt temperatures, cycle timings. This learns from reality, which the other two never touch — but it sees only the machine, not the design; it watches the press, not the geometry.

2.3.3 The interesting gap: geometry meets outcome

Line those three up and a fourth possibility is conspicuous by its absence: a system trained on geometry paired with what actually happened to that geometry in production — thousands of past part designs and their measured warpage, their scrap rates, the tool changes they needed — that has learned the mapping from shape to real-world outcome. That is the system that could answer the question a rules checker cannot: not "does this wall have draft?" but "will this geometry, in this material, actually warp enough to matter?"

Why is that fourth kind so much harder than it sounds? Not compute, and not algorithms — the academic building blocks (geometry-learning networks, large open CAD datasets) are mature and freely available. The obstacle is labeled data. A CAD archive is full of geometry, but geometry carries no outcomes: a CAD file does not record whether the part warped, how much was scrapped, or how many times the tool was re-cut. The shape sits in one system; the outcome — if it was recorded at all — sits in another, often at a different company, on the far side of the hand-offs Chapter 1 described. Joining the two is the central difficulty of learned DFM.

Whether anyone has actually built systems of each kind — how far retrieval, learned prediction and language models have really reached into moulded-parts engineering, and whether that fourth, label-hungry system exists anywhere in practice — is exactly what the rest of this study sets out to find. Before we can look, though, we need one more piece of vocabulary: a way to say where in the workflow a given capability sits. That is the AI stack, and it is the last section of this chapter.