Language models generate plausible outputs. Smelting furnaces run on feasible ones. Here is the difference, and why it matters operationally.
Many smelting operations have this one file: someone in the operation built it years ago, someone else has been updating it ever since, and it works well enough that nobody has questioned it seriously.
Until the ore parcel changes. Or manganese prices move. Or a new reductant supplier comes in at a different fixed carbon content. Then the recipe stops being a decision and becomes a negotiation between the metallurgist, the planner, and whoever controls the spreadsheet.
The question is whether ChatGPT or another large language model (LLM) can solve this. The question is reasonable. These tools are genuinely impressive, and the vendor pitches are compelling.
And the short answer is no. The longer answer is worth understanding, because the reason tells you something important about what kind of problem charge design actually is.
What LLMs are actually doing when they answer your question
LLMs like ChatGPT are trained to predict the most statistically likely next token given a sequence of input text. That is the mechanism, full stop. They are not reasoning about your problem. They pattern-match against an enormous corpus of text and return what a plausible answer looks like.
For many tasks, that is exactly what you need. Drafting a maintenance report, summarizing a shift log, and explaining what MILP stands for to a non-technical stakeholder. Language problems. LLMs are genuinely good at these.
Charge design is not a language problem. It is a constrained optimization problem. The difference is not semantic. It is structural.
When you ask ChatGPT for an optimal charge blend, it will return a table. The table will look correct. It will reference ore grades, reductant ratios, and energy targets. What it will not have done is check whether those numbers satisfy your mass balance, your furnace power limits, your alloy specification tolerance bands, and your reductant inventory simultaneously. It has no model of your system. It has a model of text about systems like yours.
This is what the research community calls confabulation: the model produces a confident, well-formatted output that may be physically or chemically infeasible. In a furnace, that distinction has real consequences.
A language model knows what a good charge recipe looks like. A math solver knows whether your charge recipe is feasible.
Why charge design is a math problem, not a language problem
Charge design for manganese smelting involves balancing a set of variables that interact simultaneously and non-trivially. Specifically:
- Ore blend ratios across parcels with varying Mn%, Fe%, SiO2, Al2O3, phosphorus, and moisture content
- Reductant selection across coke, char, and coal blends, each with different fixed carbon content and reactivity profiles
- Energy input targets in kWh/t, constrained by furnace transformer limits and tariff windows.
- Alloy specification targets for FeMn or SiMn grades, with defined tolerance bands on key elements
- Budget and inventory constraints per campaign
These variables do not sit in separate buckets. Changing the ore blend to reduce phosphorus alters the slag chemistry, affecting energy consumption and, in turn, the optimal reductant ratio. You cannot solve these in sequence and expect to find the global optimum. The interdependencies are the problem.
This is precisely the class of problem that Mixed-Integer Linear Programming (MILP) was designed for. A MILP formulation represents your charge design as a system of linear constraints and an objective function, typically minimizing cost or maximizing alloy recovery, and uses a solver to find the best feasible solution across the entire solution space simultaneously.
Choosing the right optimizer matters in production environments where model solve time must fit within operational planning cycles. This is where Modaai comes in to help.
The data problem nobody talks about
Even when operations teams understand the solver side of this, there is a second layer that catches most implementations: data structure.
A dataset that is clean enough for a Python ML pipeline will fail in an optimization solver if it has not been mapped to the right mathematical structure. Ore grades need to be decision variables with defined bounds. Mass balance relationships need to be expressed as linear equality or inequality constraints. Blending coefficients need to be organized into index-aligned matrices that the solver can traverse efficiently.
This is what we call decision-ready data, and it is a different artifact from analytics-ready data. Building it correctly and maintaining it as ore parcels and supplier mixes change is often more consequential than the solver configuration itself. It is also where many in-house optimization attempts break down.
Common questions
Can ChatGPT produce a usable charge design?
It can produce a formatted output that resembles one. Whether that output satisfies your mass balance, alloy spec, and furnace constraints simultaneously is a different question, and one it has no mechanism to verify. LLMs do not solve constraint satisfaction problems. They generate text. For an initial brainstorm or a stakeholder explanation, that may be useful. For an actual charge, it is not sufficient.
What does a MILP charge optimization model actually optimize for?
Typically, the cost per tonne of alloy produced, subject to constraints on alloy specification, mass balance, reductant availability, furnace power, and campaign budget. The objective function and constraint set are defined to match the specific operation. Some models also incorporate alloy recovery rate or slag volume as secondary objectives. The formulation depends entirely on what the operation is actually trying to optimize, which is why starting with the decision rather than the technology matters.
What is the difference between predictive and prescriptive analytics in this context?
Predictive analytics answers: what is likely to happen? Forecasting ore grade variability or energy demand falls here. Prescriptive analytics answers: given what we know right now, what is the best decision to make? Charge design optimization is prescriptive. It takes current conditions as inputs and returns an action, not a forecast. Both types have value. The question is which one your operation actually needs at any given decision point.
How long does it take to build and deploy a charge optimization model?
It depends heavily on data readiness and model scope. A focused, single-furnace charge-optimization model, with strong historical data and clear constraint definitions, can deliver a working prototype in weeks. Production deployment, which includes integration with live assay data, validation against historical campaigns, and operator handover, takes longer. The data structuring phase, building decision-ready inputs from raw operational data, is usually what determines the timeline more than the solver work itself.
Choosing the right tool starts with understanding the problem type.
LLMs are useful tools. They are the wrong tool for charge design. Mathematical optimization, specifically MILP, formulated around your actual constraints and solved with a capable commercial solver, is built for this class of problem.
Modaai builds production-ready optimization models for mining and metallurgy operations. Our work is grounded in operations research, integrated with operational data systems, and backed by IBM Silver Partner and Gurobi Approved Partner credentials. We start with the decision, not the technology.
For operations and planning leaders
If your charge design process still lives in a spreadsheet, let’s talk through what an optimization model would actually look like for your operation. Get in touch.