Dejamos que un modelo de lenguaje invente sus propias variables de pronóstico. Después tuvimos que enseñarle al sistema a distinguir las buenas ideas de las malas — sin una persona en el medio, y sin jamás poner en producción un modelo peor. Este es el diseño que lo hace aprender por sí solo.
Ingeniería de APEXiA · Junio 2026
La mayoría de los sistemas de pronóstico son estáticos: un ingeniero elige las variables, ajusta el modelo y lo despliega. El nuestro no. Cada noche intenta mejorarse a sí mismo — propone una nueva señal de entrada, comprueba si esa señal realmente ayuda, y la conserva solo si lo hace. La promesa es simple y un poco audaz: a medida que conectamos nuevas fuentes de datos, el pronóstico aprende a usarlas por su cuenta.
Esa promesa tiene un filo. Un sistema capaz de agregarse variables a sí mismo también puede envenenarse a sí mismo. Esta es la historia de las dos barreras de protección que convierten a un modelo autónomo y automodificable de una amenaza en un activo — y de por qué hacen falta exactamente dos, no una.
Qué estamos pronosticando
El modelo predice la demanda diaria de productos de un fabricante — cientos de SKUs, fuerte estacionalidad, efectos de feriados y de ciclos de pago, y una larga cola de artículos intermitentes y de demanda irregular. Por debajo es híbrido: un modelo estructural de series de tiempo (Prophet) para los productos maduros y estacionales, y un modelo de árboles potenciados por gradiente (XGBoost) para los más nuevos y erráticos. Cada producto se enruta al enfoque que mejor encaje con su historia.
El número que le importa al negocio es el error ponderado en los productos de alto volumen — los que mueven las compras y el efectivo. Todo lo de abajo está al servicio de bajar ese número de forma honesta.
La palabra «honesta» carga con mucho peso
Cada modelo candidato se evalúa con validación walk-forward: se entrena con el pasado, se predice un mes futuro reservado (que el modelo no vio), se avanza, y se repite. Es más lento y da números más feos que evaluar sobre datos que el modelo ya conoció — y ese es justamente el punto. Un modelo puede parecer que mejora mientras en realidad empeora, simplemente porque lo mediste sobre la ventana equivocada. La validación walk-forward es lo que impide que el resto de este sistema se engañe a sí mismo.
El ciclo autónomo
Una vez por noche, el sistema corre un ciclo que se ve así:
construir variables→el LLM propone una variable nueva→evaluar con y sin ella
→COMPUERTA POR VARIABLE→ajustar hiperparámetros→reconstrucción final
→COMPUERTA DE ACTIVACIÓN→promover/bloquear
El nodo interesante es el segundo. Un modelo de lenguaje — al que se le da la forma de los datos y una descripción del negocio — propone una variable nueva: «los días desde la última venta», «un indicador de temporada de lluvias», «la presión de pagos a proveedores». El sistema escribe el código, construye la columna, y vuelve a entrenar el modelo con y sin la nueva señal sobre los mismos meses reservados. Si la variable se gana su lugar, se conserva; si no, se revierte.
Este es el motor de todo el asunto. Significa que el día que conectemos una nueva fuente de datos — una serie económica del banco central, datos de clima, permisos de construcción — el ciclo puede descubrir por sí mismo cuáles señales de esa fuente realmente predicen la demanda. Sin un ingeniero diseñando variables a mano. El modelo crece con los datos.
El modo de falla del que nadie te advierte
Esto lo aprendimos por las malas: a un LLM al que le pides que proponga variables siempre se le ocurrirá otra idea. Es infinitamente creativo y nunca dice «ya no queda nada útil que agregar». Eso es maravilloso para explorar y peligroso para un modelo en producción, porque la mayoría de las variables propuestas son ruido — y un ciclo que acepta ruido no solo malgasta cómputo, sino que degrada activamente.
Nuestra primera compuerta era demasiado generosa: aceptaba una variable ante el más leve indicio de mejora. A lo largo de semanas, el modelo fue acumulando una docena de señales casi inútiles. Cada una parecía inofensiva por separado. Juntas hicieron al pronóstico medibles veces peor — mientras que los tableros, evaluados de la manera fácil, decían que mejoraba. Solo lo detectamos porque el número honesto de walk-forward contradecía la historia.
El peligro de un sistema que se automejora no es que deje de mejorar. Es que siga «mejorándose» hacia un lugar peor, con confianza, todas las noches.
La solución no es «hacer el modelo más inteligente». Es darle al sistema un sentido de discernimiento — y, crucialmente, dividir ese discernimiento en dos tareas.
Dos compuertas, dos tareas
Gobernamos el ciclo con dos verificaciones independientes, cada una respondiendo a una pregunta distinta.
Compuerta 1 · por variable
El piso de ruido
Pregunta: ¿esta variable en particular carga señal real?
Una variable propuesta se admite solo si mejora el error honesto reservado por encima del ruido de medición del sistema. Por debajo de ese umbral, una «mejora» es indistinguible de la suerte en una ventana puntual — así que la tratamos como ruido y la rechazamos.
El listón se pone en el piso de ruido y nada más: aquí el objetivo no es ser estricto, es ser discriminante. La señal real — incluida la de una fuente de datos nueva — lo supera con facilidad. La basura nunca lo logra.
Compuerta 2 · modelo completo
El respaldo contra regresiones
Pregunta: ¿es el modelo terminado realmente mejor que una referencia austera y conocida?
Aun con una compuerta por variable limpia, las decisiones marginales y las interacciones entre variables pueden sumar mal. Así que antes de que un modelo salga a producción, el candidato completo se compara contra una referencia deliberadamente austera. Si no es al menos tan bueno, se bloquea — el modelo anterior sigue sirviendo, y la discrepancia se expone para revisión.
Nada peor que la referencia austera llega jamás a producción. Punto.
Por qué tienen que ser dos
Esta es la parte fácil de equivocar, y al inicio lo hicimos — al intentar que una sola compuerta hiciera ambas tareas. Una única compuerta muy estricta rechazaría variables genuinamente útiles pero modestas, estrangulando el aprendizaje para el que construimos todo el ciclo. Una única compuerta laxa deja que el registro se sature. Ninguna funciona.
Dividirla resuelve la tensión de forma limpia:
La compuerta por variable se mantiene laxa — apenas por encima del piso de ruido — para que el sistema siga aprendiendo, admitiendo toda señal real que ofrezca una nueva fuente de datos.
La compuerta de activación se mantiene estricta — el modelo completo contra una referencia austera — para que el sistema nunca retroceda, sin importar lo que se haya colado aguas arriba.
Las dos compuertas se diagnostican entre sí
Si la compuerta por variable queda calibrada demasiado laxa y empieza a admitir variables que en conjunto dañan, la compuerta de activación empieza a bloquear — y ese bloqueo es en sí mismo la señal de que el listón de aguas arriba necesita subir. El sistema te avisa cuando está mal ajustado. No tienes que adivinar.
Una sutileza más: absoluto, no relativo
Cuando fijas ese listón del piso de ruido, tienes que decidir si escala con el error actual del modelo o se mantiene fijo. Lo anclamos a una cantidad fija de mejora, a propósito. A medida que el pronóstico mejora con el tiempo — a medida que llegan nuevas fuentes de datos y el error baja — un listón definido como porcentaje del error actual se encogería en silencio, hasta caer por debajo del ruido de medición y volver a dejar entrar basura. Un listón fijo se mantiene anclado al piso de ruido, donde debe estar. Los estándares del sistema no se erosionan solo porque le esté yendo bien.
Qué nos da esto
El resultado es un ciclo de AutoML que es genuinamente autónomo y genuinamente seguro al mismo tiempo:
Aprende de datos nuevos por su cuenta. Conecta una fuente, y el ciclo descubre cuáles de sus señales predicen la demanda — sin ingeniería de variables.
Rechaza el ruido. La avalancha de ideas plausibles pero inútiles del proponente nunca llega al modelo.
Nunca retrocede. El peor caso es que producción siga sirviendo el último modelo bueno conocido — nunca uno peor.
Se poda y se autocorrige. Cuando algo sí se desvía, las compuertas lo atrapan y el sistema señala exactamente qué revisar.
Nada de esto requirió un modelo más inteligente. Requirió darle a un sistema autónomo lo único que separa a un buen ingeniero de uno prolífico: el criterio para saber cuáles de tus propias ideas descartar.
Aquí hay un patrón más amplio, y es la tesis detrás de todo lo que construimos. La inteligencia — el modelo de lenguaje proponiendo variables — es poderosa pero poco confiable por sí sola. El valor viene de envolverla en estructura determinista: evaluación honesta, barreras de protección estrictas, un respaldo con el que no se puede discutir. El modelo aporta la creatividad. El sistema aporta la disciplina. Ninguno es el producto por sí solo; el apalancamiento está en la costura entre ambos.
Engineering · AutoML
The Self-Governing Forecast
We let a language model invent its own forecasting features. Then we had to teach the system to tell good ideas from bad ones — without a human in the loop, and without ever shipping a worse model. Here's the design that makes it learn on its own.
APEXiA Engineering · June 2026
Most forecasting systems are static: an engineer picks the features, tunes the model, and ships it. Ours isn't. Every night it tries to improve itself — it proposes a new input signal, tests whether that signal actually helps, and keeps it only if it does. The promise is simple and a little audacious: as we connect new data sources, the forecast learns to use them on its own.
That promise has a sharp edge. A system that can add features to itself can also poison itself. This is the story of the two guardrails that turn an autonomous, self-modifying model from a liability into an asset — and why it takes exactly two, not one.
What we're forecasting
The model predicts daily product demand for a manufacturer — hundreds of SKUs, strong seasonality, holiday and pay-cycle effects, and a long tail of intermittent, spiky items. Under the hood it's a hybrid: a structural time-series model (Prophet) for the mature, seasonal products, and a gradient-boosted model (XGBoost) for the newer and lumpier ones. Each product is routed to whichever approach fits its history.
The number that matters to the business is weighted error on the high-volume products — the ones that drive purchasing and cash. Everything below is in service of pushing that number down honestly.
The word "honestly" is doing a lot of work
Every candidate model is scored with walk-forward validation: train on the past, predict a held-out future month, roll forward, repeat. This is slower and gives uglier numbers than scoring on data the model already saw — and that's the point. A model can look like it's improving while quietly getting worse, simply because you measured it on the wrong window. Walk-forward is what keeps the rest of this system from fooling itself.
The autonomous loop
Once a night, the system runs a loop that looks like this:
build features→LLM proposes a new feature→eval with vs without it
→FEATURE GATE→tune hyper-parameters→final rebuild
→ACTIVATION GATE→promote/block
The interesting node is the second one. A language model — given the shape of the data and a description of the business — proposes a new feature: "the days since the last sale," "a rainy-season indicator," "supplier-payment pressure." The system writes the code, builds the column, and re-trains the model with and without the new signal on the same held-out months. If the feature earns its place, it's kept; if not, it's reverted.
This is the engine of the whole thing. It means that the day we wire in a new data source — a central-bank economic series, a weather feed, construction-permit data — the loop can discover on its own which signals from that source actually predict demand. No engineer hand-crafting features. The model grows with the data.
The failure mode nobody warns you about
Here's what we learned the hard way: an LLM asked to propose features will always have another idea. It is endlessly creative and never says "there's nothing useful left to add." That's wonderful for exploration and dangerous for a production model, because most proposed features are noise — and a loop that accepts noise doesn't just waste compute, it actively degrades.
Our first gate was too generous: it accepted a feature on the faintest hint of improvement. Over weeks, the model accreted a dozen near-useless signals. Each one looked harmless in isolation. Together they made the forecast measurably worse — while the dashboards, scored the easy way, said it was improving. We only caught it because the honest walk-forward number disagreed with the story.
The danger of a self-improving system isn't that it stops improving. It's that it keeps "improving" itself into a worse place, confidently, every single night.
The fix is not "make the model smarter." It's to give the system a sense of discernment — and, crucially, to split that discernment into two jobs.
Two gates, two jobs
We govern the loop with two independent checks, each answering a different question.
Gate 1 · per feature
The noise floor
Question: does this one feature carry real signal?
A proposed feature is admitted only if it improves the honest held-out error by more than the system's measurement noise. Below that bar, an "improvement" is indistinguishable from luck on a particular fold — so we treat it as noise and reject it.
Set the bar at the noise floor and nothing more: the goal here is not to be strict, it's to be discriminating. Real signal — including from a brand-new data source — clears it easily. Junk never does.
Gate 2 · whole model
The regression backstop
Question: is the finished model actually better than a known-good lean baseline?
Even with a clean per-feature gate, marginal calls and feature interactions can add up wrong. So before any model goes live, the full candidate is scored against a deliberately lean reference. If it isn't at least as good, it is blocked — the previous model keeps serving, and the disagreement is surfaced for review.
Nothing worse than the lean baseline ever reaches production. Full stop.
Why it has to be two
This is the part that's easy to get wrong, and we did at first — by trying to make one gate do both jobs. A single very-strict gate would reject genuinely useful but modest features, strangling the learning we built the whole loop for. A single lenient gate lets the registry bloat. Neither works.
Splitting it resolves the tension cleanly:
The per-feature gate stays loose — just above the noise floor — so the system keeps learning, admitting every real signal a new data source offers.
The activation gate stays strict — the whole model versus a lean reference — so the system never regresses, no matter what slipped through upstream.
The two gates diagnose each other
If the per-feature gate is calibrated too loose and starts admitting features that cumulatively hurt, the activation gate begins to block — and that blocking is itself the signal that the upstream bar needs raising. The system tells you when it's mis-tuned. You don't have to guess.
One more subtlety: absolute, not relative
When you set that noise-floor bar, you have to decide whether it scales with the model's current error or stays fixed. We pin it to a fixed amount of improvement, deliberately. As the forecast gets better over time — as new data sources land and error drops — a bar defined as a percentage of the current error would quietly shrink, eventually dipping below the measurement noise and letting junk back in. A fixed bar stays anchored to the noise floor where it belongs. The system's standards don't erode just because it's doing well.
What this buys us
The result is an AutoML loop that is genuinely autonomous and genuinely safe at the same time:
It learns from new data on its own. Connect a source, and the loop discovers which of its signals predict demand — no feature engineering required.
It rejects noise. The flood of plausible-but-useless ideas from the proposer never makes it into the model.
It never regresses. The worst case is that production keeps serving the last known-good model — never a worse one.
It prunes and self-corrects. When something does drift, the gates catch it and the system flags exactly what to look at.
None of this required a smarter model. It required giving an autonomous system the one thing that separates a good engineer from a prolific one: the judgment to know which of your own ideas to throw away.
There's a broader pattern here, and it's the thesis behind everything we build. The intelligence — the language model proposing features — is powerful but unreliable on its own. The value comes from wrapping it in deterministic structure: honest evaluation, hard guardrails, a backstop that can't be argued with. The model supplies the creativity. The system supplies the discipline. Neither is the product alone; the leverage is in the seam between them.