Cómo una fábrica dominicana de materiales corre pronósticos de demanda que se automejoran en un solo servidor — y qué nos dice la investigación de Berkeley y Databricks sobre por qué esta arquitectura funciona.
La demanda de pronósticos en la manufactura pequeña y mediana es enorme. Una fábrica de materiales de construcción en la República Dominicana necesita saber exactamente cuánto cemento, acero y madera pedir cada semana. Errar por un cinco por ciento significa o ventas perdidas por quiebres de inventario, o inventario muerto que inmoviliza el flujo de caja.
La respuesta convencional es el «AutoML»: lanzarle una caja negra a tus datos y esperar que produzca un modelo preciso. Pero las cajas negras son opacas, difíciles de auditar y notoriamente difíciles de mejorar cuando empiezan a degradarse. Y la alternativa que se promociona hoy es la «IA agéntica» (agentic AI): apuntar un modelo de lenguaje grande (LLM) a tu pipeline y dejar que decida el siguiente paso.
Nosotros construimos la tercera opción: iAx Científico, un sistema de compound AI donde un LLM propone variables (features), solvers reales entrenan los modelos, PostgreSQL guarda la memoria institucional y n8n coordina la orquestación. Cada componente hace lo que de verdad sabe hacer bien. Ninguno es el sistema. El sistema es la cooperación.
El argumento a favor de los sistemas compuestos frente a los LLMs monolíticos o los ciclos puramente agénticos ya no es teórico. Es el consenso entre la gente que de verdad está construyendo IA de producción.
En su influyente artículo de febrero de 2024 «The Shift from Models to Compound AI Systems», Matei Zaharia, Omar Khattab y sus colegas del laboratorio de investigación en IA de UC Berkeley analizaron qué es lo que realmente está entregando los resultados de punta en la IA. Su hallazgo fue contundente:
«Los resultados de IA de vanguardia se obtienen cada vez más mediante sistemas compuestos con múltiples componentes, no solo con modelos monolíticos.»
La evidencia era clara. AlphaCode 2 alcanzó un desempeño del percentil 85 humano en concursos de programación no mediante un único modelo más grande, sino mediante un sistema cuidadosamente diseñado: generar 1M de soluciones candidatas, filtrarlas, puntuarlas, agruparlas. AlphaGeometry combinó un LLM con un motor de matemática simbólica para alcanzar un nivel entre plata y oro en la Olimpiada Internacional de Matemática. MedPrompt, de Microsoft, superó la precisión de GPT-4 en exámenes médicos en un 9% mediante un sistema de cadena de pensamiento (chain-of-thought) + búsqueda de vecinos más cercanos + ensamble de 11 muestras.
Los investigadores identificaron cuatro razones por las que los sistemas compuestos superan a los enfoques monolíticos:
Databricks llegó a la misma conclusión desde otra dirección: los despliegues en producción de sus clientes. En su anuncio de junio de 2024 de Mosaic AI Agent Bricks, documentaron un caso de estudio concreto:
La firma de investigación financiera FactSet desplegó un LLM comercial para su tarea de texto-a-fórmula-financiera. El enfoque monolítico logró un 55% de precisión. Cuando modularizaron la tarea en un sistema compuesto — clasificar la consulta, recuperar las fórmulas relevantes, generar la fórmula, validar la sintaxis — la precisión saltó al 85%.
55%
LLM monolítico
85%
Sistema compuesto
Su investigación mostró que el 60% de las aplicaciones con LLM ya usan RAG y el 30% usan cadenas multi-paso. La industria ya practicaba los sistemas compuestos antes de que la investigación les pusiera nombre.
iAx Científico es el componente de AutoML de la familia de productos APEXiA, en operación para una fábrica de materiales de construcción en la República Dominicana. Construye y mantiene de forma continua modelos de pronóstico de demanda y de predicción de churn — sin un científico de datos humano sentado frente al teclado.
La arquitectura es un ejemplo de libro del patrón de compound AI. Este es el diagrama completo del sistema:
El sistema tiene cuatro componentes que cooperan. Ninguno es el sistema. El sistema es lo que obtienes cuando cooperan.
Ingiere los datos del día del sistema fuente desde el sistema contable Oracle y refresca las vistas materializadas en los esquemas ia.* y bi.*. Este es el sustrato de datos sobre el que razona el LLM. El ETL es Python determinista — sin ningún LLM de por medio.
A un LLM (Qwen3.6 local) se le pasa un prompt con:
El LLM propone una variable candidata con su código de construcción en SQL/Python y un párrafo de razonamiento. El sistema materializa la variable sobre el historial completo, reentrena el modelo, mide el delta de WMAPE y la confirma solo si al menos 4 de 6 corridas con hiperparámetros perturbados superan el listón.
Las variables rechazadas van al cientifico.demand_feature_registry con una etiqueta revisit_when — «esto habría movido el WMAPE si existiera cement_price_data».
Lee el conjunto de variables vigente, propone nuevas regiones de hiperparámetros, reentrena con Prophet y XGBoost, y escribe nuevas predicciones en una tabla diaria. Está acoplado con el ciclo de FE: cuando FE acepta tentativamente una variable, el ciclo de HP reajusta para el nuevo espacio de variables; cuando HP cambia sustancialmente, el ciclo de FE reevalúa las variables desactivadas recientemente.
Lee las vistas materializadas de los dashboards, alimenta los datos estructurados de KPIs al LLM y genera un resumen ejecutivo en lenguaje llano, en español. Se escribe de vuelta a bi.executive_summaries como un UPSERT.
La tabla más importante del sistema no es ninguna vista operativa ni ningún dashboard materializado. Es cientifico.demand_feature_registry — una bitácora de teorías donde cada variable que el sistema haya probado alguna vez vive de forma permanente, con su razonamiento.
CREATE TABLE cientifico.demand_feature_registry (
id SERIAL PRIMARY KEY,
feature_name TEXT UNIQUE NOT NULL,
feature_type TEXT NOT NULL, -- 'calendar' or 'query'
build_code TEXT NOT NULL, -- materialization SQL/Python
forecast_code TEXT NOT NULL, -- inference-time expression
prophet_compatible BOOLEAN DEFAULT TRUE,
xgboost_compatible BOOLEAN DEFAULT TRUE,
fill_value NUMERIC DEFAULT 0,
enabled BOOLEAN DEFAULT TRUE,
proposed_by TEXT DEFAULT 'manual',
reasoning TEXT, -- the theory
revisit_when TEXT[], -- "what data is needed to revisit"
run_id UUID, -- run-id discipline
created_at TIMESTAMPTZ DEFAULT NOW()
);Al día de hoy existen 62 filas. 17 están habilitadas (activas en producción). 45 están deshabilitadas. La tasa de aceptación ronda el 27% — alta en comparación con el AutoML tradicional, porque las propuestas del LLM están guiadas por hipótesis, no son fuerza bruta indiscriminada. Cada variable aceptada tiene una teoría adjunta. Cada variable rechazada tiene una razón.
En la República Dominicana, la mayoría de los trabajadores cobra dos veces al mes (el 15 y a fin de mes). Es el ciclo quincenal, y es un motor real de la demanda de materiales de construcción — los contratistas pequeños se abastecen alrededor de los días de pago.
Claude Opus la propuso 9 veces en distintas formas. Todas fueron rechazadas. Qwen propuso una variable similar una sola vez — una bandera binaria limpia — y entró. ¿Por qué? Qwen tenía un prior distinto sobre qué hace buena a una variable para árboles potenciados por gradiente. Los árboles no necesitan codificaciones sinusoidales ni métricas de distancia. Necesitan cortes binarios.
Esto es la diversidad de proponentes en acción. Correr múltiples LLMs como proponentes produce un espacio de búsqueda más amplio que el de cualquier modelo individual. Es la misma lógica que hace funcionar a los métodos de ensamble, aplicada al nivel meta de la ingeniería de variables.
Esta es la pregunta que más importa en 2026. Un ciclo agéntico apuntaría un LLM a los datos, le daría herramientas y lo dejaría decidir el siguiente paso de extremo a extremo. En la superficie parece el siguiente paso natural después de los sistemas compuestos. Pero para pronósticos en producción tiene tres problemas estructurales.
La forma correcta de plantearlo: la IA agéntica es mejor en tareas donde un solo modelo capaz puede sostener el problema completo en su cabeza. Para tareas genuinamente complejas — construir y mantener continuamente un modelo de pronóstico en producción contra datos que derivan — la disciplina de ingeniería que ha funcionado durante cuarenta años (separación de responsabilidades, solvers reales para la matemática, trazas de auditoría) no desaparece porque el modelo de lenguaje ahora sea inteligente.
iAx Científico corre en un solo host — 128GB de RAM, dos GPUs AMD Radeon AI PRO R9700, sin Kubernetes, sin orquestación gestionada. Así se combinan los componentes de Linux:
El LLM local se sirve con vLLM con cuantización MXFP4, decodificación especulativa MTP y un parser de tool-calling qwen3_xml. Se gestiona como servicio de systemd: apexia-vllm-qwen.service. La arquitectura MoE (3B activos / 35B totales) significa que solo 3 mil millones de parámetros se activan por token — lo que lo hace lo bastante rápido para tool-calling en tiempo real dentro del ciclo compuesto.
Todos los esquemas viven en un solo contenedor: Postgres. El search path está configurado a ia, public. El esquema cientifico.* guarda los registros de variables, el estado de las corridas y los modelos entrenados. El esquema bi.* guarda las vistas materializadas de los dashboards. Un rol de solo lectura valida el SQL.
Un solo contenedor Docker con su propio Postgres. El editor visual de workflows de n8n me permite iterar sobre los trade-offs de costo/calidad cambiando de modelo en un solo nodo HTTP — distinta URL, misma forma de workflow. Ese intercambio de baja fricción es lo que realmente habilita la diversidad de proponentes: el ciclo de Claude, el ciclo de Qwen, el experimento con Gemma — todos coexisten y pueden activarse bajo demanda.
Cada servicio es una unidad de systemd: el serving de vLLM, el pipeline de ETL, las notificaciones de respaldo, el heartbeat del ETL. Sin Kubernetes — sin scheduler, sin executor, sin base de datos de metadatos. Solo systemctl start y journalctl. Es la elección apropiada al presupuesto para un stack de un solo operador y un solo host.
El artículo de Berkeley AI Research identificó cuatro razones por las que los sistemas compuestos superan a los enfoques monolíticos. Así es como iAx Científico se corresponde con ellas:
| PRINCIPIO DE BERKELEY | CÓMO LO IMPLEMENTA iAx Científico |
|---|---|
| Diseño de sistema > escalar el modelo | Un ciclo compuesto hecho a la medida (propuesta de FE → entrenamiento real → WMAPE medido) produce mejores pronósticos de los que daría cualquier modelo individual, e itera más rápido de lo que podría cualquier corrida de entrenamiento. |
| Los sistemas son dinámicos | Integración de datos macroeconómicos del BCRD, nuevas fuentes de datos externas — la cola revisit_when reactiva variables previamente rechazadas cuando llegan datos nuevos. |
| Control y confianza | Cada variable tiene su razonamiento adjunto. Cada decisión es trazable a un run_id. La bitácora de teorías es una traza de auditoría — una caja negra no lo es. |
| Objetivos de desempeño variables | Arquitectura de proponentes por niveles: Qwen (local, gratis) para la operación diaria, Claude (API de pago) para el nivel premium. Costos distintos, misma arquitectura. |
El caso FactSet de Databricks es la prueba en el mundo real: 55% → 85% de precisión al modularizar la tarea en pasos compuestos especializados en lugar de confiar en un solo modelo.
Llegará el día en que los sistemas agénticos sean lo bastante rápidos, baratos y precisos como para manejar el AutoML de extremo a extremo en una sola llamada al modelo. Cuando eso ocurra, la versión agéntica de este sistema podría ser posible.
Pero la versión compuesta seguirá produciendo el mismo pronóstico por una fracción del costo. El cómputo gastado en razonamiento del modelo de lenguaje en cada paso de un ciclo agéntico es exactamente el costo que las arquitecturas compuestas evitan al enrutar la matemática hacia la matemática y el lenguaje hacia el lenguaje.
En otras palabras: la transición agéntica convertirá a las arquitecturas compuestas de «la única manera que funciona» en «la manera costo-optimizada que funciona». Para operadores que cuidan el margen por tenant — como una fábrica de materiales donde la precisión del pronóstico se traduce directamente en inventario y flujo de caja — esa es, de todos modos, la versión que importa.
La arquitectura también se beneficia de dos trayectorias distintas de progreso de los modelos, simultáneamente. Los modelos locales open-source (Qwen, Gemma) seguirán mejorando — lo que significa que el puesto de proponente local se hará más fuerte en silencio, gratis, sobre hardware que ya se posee. Mientras tanto, los modelos frontera del nivel premium harán trabajo genuinamente agéntico que nada de lo actual puede igualar. La arquitectura compuesta aloja a ambos; el operador no tiene que predecir cuál nivel dominará.
El sistema tiene bordes inacabados conocidos — todos son adiciones tratables al mismo ciclo:
Ninguno requiere re-deliberar el sistema. Son adiciones al ciclo, en el espíritu del mismo ciclo.
How a Dominican materials factory runs self-improving demand forecasting on a single server — and what Berkeley and Databricks research tells us about why this architecture works.
The demand for forecasting in small and mid-sized manufacturing is enormous. A construction-materials factory in the Dominican Republic needs to know exactly how much cement, steel, and lumber to order each week. Missing the mark by five percent means either lost sales from stockouts or dead inventory that ties up cash flow.
The conventional answer is "AutoML" — throw a black box at your data and hope it produces an accurate model. But black boxes are opaque, hard to audit, and notoriously difficult to improve when they start degrading. And the alternative pitched today is "agentic AI" — point a Large Language Model at your pipeline and let it decide the next step.
We built the third option: iAx Científico, a Compound AI System where an LLM proposes features, real solvers train models, PostgreSQL stores institutional memory, and n8n coordinates the orchestration. Every component does what it's actually good at. None of them is the system. The system is the cooperation.
The argument for compound systems over monolithic LLMs or pure agentic loops is no longer theoretical. It's the consensus among the people actually building production AI.
In their landmark February 2024 paper "The Shift from Models to Compound AI Systems", Matei Zaharia, Omar Khattab, and colleagues at UC Berkeley's AI Research lab analyzed what's actually delivering state-of-the-art results across AI. Their finding was definitive:
"State-of-the-art AI results are increasingly obtained by compound systems with multiple components, not just monolithic models."
The evidence was clear. AlphaCode 2 achieved 85th-percentile human performance on coding contests not through a single larger model, but through a carefully engineered system: generate 1M candidate solutions, filter them, score them, cluster them. AlphaGeometry combined an LLM with a symbolic math engine to reach between silver and gold at the International Math Olympiad. Microsoft's MedPrompt exceeded GPT-4's medical-exam accuracy by 9% through a chain-of-thought + nearest-neighbor-search + 11-sample ensemble system.
The researchers identified four reasons compound systems outperform monolithic approaches:
Databricks reached the same conclusion from a different direction — the production deployments of their customers. In their June 2024 announcement of Mosaic AI Agent Bricks, they documented a concrete case study:
Financial research firm FactSet deployed a commercial LLM for their Text-to-Financial-Formula task. The monolithic approach achieved 55% accuracy. When they modularized the task into a compound system — classifying the query, retrieving relevant formulas, generating the formula, validating syntax — accuracy jumped to 85%.
55%
Monolithic LLM
85%
Compound System
Their research showed that 60% of LLM applications already use RAG and 30% use multi-step chains. The industry was already practicing compound systems before the research named it.
iAx Científico is the AutoML component of the APEXiA product family, running for a construction-materials factory in the Dominican Republic. It builds and continuously maintains demand-forecasting and churn-prediction models — without a human data scientist sitting at the keyboard.
The architecture is a textbook example of the compound AI pattern. Here's the full system diagram:
The system has four cooperating components. None is the system. The system is what you get when they cooperate.
Ingests the day's source-system data from the Oracle accounting system, refreshes materialized views across ia.* and bi.* schemas. This is the data substrate the LLM reasons over. The ETL is deterministic Python — no LLM involved.
An LLM (Qwen3.6 local) is prompted with:
The LLM proposes one candidate feature with SQL/Python build code and a paragraph of reasoning. The system materializes the feature on the full history, retrains the model, measures WMAPE delta, and commits only if at least 4 of 6 hyperparameter-perturbed trials clear the bar.
Rejected features go to the cientifico.demand_feature_registry with a revisit_when tag — "this would have moved WMAPE if cement_price_data existed."
Reads the current feature set, proposes new hyperparameter regions, retrains with Prophet and XGBoost, and writes new predictions to a daily table. Coupled with the FE loop: when FE tentatively accepts a feature, the HP loop retunes for the new feature space; when HP substantially shifts, the FE loop re-evaluates recently-disabled features.
Reads dashboard materialized views, feeds structured KPI data to the LLM, and generates a plain-language executive summary in Spanish. Written back to bi.executive_summaries as an UPSERT.
The most important table in the system isn't any operational view or materialized dashboard. It's cientifico.demand_feature_registry — a theory log where every feature the system has ever tried lives permanently, with its reasoning.
CREATE TABLE cientifico.demand_feature_registry (
id SERIAL PRIMARY KEY,
feature_name TEXT UNIQUE NOT NULL,
feature_type TEXT NOT NULL, -- 'calendar' or 'query'
build_code TEXT NOT NULL, -- materialization SQL/Python
forecast_code TEXT NOT NULL, -- inference-time expression
prophet_compatible BOOLEAN DEFAULT TRUE,
xgboost_compatible BOOLEAN DEFAULT TRUE,
fill_value NUMERIC DEFAULT 0,
enabled BOOLEAN DEFAULT TRUE,
proposed_by TEXT DEFAULT 'manual',
reasoning TEXT, -- the theory
revisit_when TEXT[], -- "what data is needed to revisit"
run_id UUID, -- run-id discipline
created_at TIMESTAMPTZ DEFAULT NOW()
);As of today, 62 rows exist. 17 are enabled (active in production). 45 are disabled. The acceptance rate is around 27% — which is high relative to traditional AutoML because the LLM proposals are hypothesis-driven, not brute-force kitchen-sink. Every accepted feature has a theory attached. Every rejected feature has a reason.
In the Dominican Republic, most workers are paid twice a month (the 15th and end of month). This is the quincenal cycle, and it's a real driver of construction-materials demand — small contractors stock up around paydays.
Claude Opus proposed it 9 times in different shapes. All were rejected. Qwen proposed a similar feature once — a clean binary flag — and it landed. Why? Qwen had a different prior about what makes a good feature for gradient-boosted trees. Trees don't need sinusoidal encodings or distance metrics. They need binary splits.
This is proposer diversity in action. Running multiple LLMs as proposers produces a wider search space than any single model. This is the same logic that makes ensemble methods work, applied at the meta level of feature engineering.
This is the question that matters most in 2026. An agentic loop would point an LLM at the data, give it tools, and let it decide the next step end-to-end. On the surface this seems like the natural next step after compound systems. But for production forecasting, it has three structural problems.
The right way to put it: agentic AI is best at tasks where a single capable model can hold the whole problem in its head. For genuinely complex tasks — building and continuously maintaining a production forecasting model against drifting data — the engineering discipline that has worked for forty years (separation of concerns, real solvers for math, audit trails) doesn't go away because the language model is now smart.
iAx Científico runs on a single host — 128GB RAM, two AMD Radeon AI PRO R9700 GPUs, no Kubernetes, no managed orchestration. Here's how Linux components combine:
The local LLM is served by vLLM with MXFP4 quantization, MTP speculative decoding, and a qwen3_xml tool-calling parser. It's managed as a systemd service: apexia-vllm-qwen.service. The MoE architecture (3B active / 35B total) means only 3 billion parameters activate per token — making it fast enough for real-time tool-calling in the compound loop.
All schemas live in one container: Postgres. The search path is set to ia, public. The cientifico.* schema holds feature registries, run state, and trained models. The bi.* schema holds materialized dashboard views. A read-only role validates the SQL.
A single Docker container with its own Postgres. n8n's visual workflow editor lets me iterate on cost/quality tradeoffs by swapping models in a single HTTP node — different URL, same workflow shape. This low-friction swapping is what actually enables proposer diversity: the Claude loop, the Qwen loop, the Gemma experiment — all coexist and can be activated on demand.
Every service is a systemd unit: vLLM serving, the ETL pipeline, backup notifications, ETL heartbeat. No Kubernetes — no scheduler, no executor, no metadata DB. Just systemctl start and journalctl. This is the budget-appropriate choice for a single-operator, single-host stack.
The Berkeley AI Research paper identified four reasons compound systems outperform monolithic approaches. Here's how iAx Científico maps to them:
| BERKELEY PRINCIPLE | HOW iAx Científico IMPLEMENTS IT |
|---|---|
| System design > model scaling | Purpose-built compound loop (FE proposal → real training → measured WMAPE) produces better forecasts than any single model would, and iterates faster than any training run could. |
| Systems are dynamic | BCRD macroeconomic data integration, new external data sources — the revisit_when queue reactivates previously-rejected features when new data lands. |
| Control and trust | Every feature has reasoning attached. Every decision is traceable to a run_id. The theory log is an audit trail — a black box isn't. |
| Variable performance goals | Tiered proposer architecture: Qwen (local, free) for daily operations, Claude (paid API) for premium tier. Different costs, same architecture. |
The Databricks FactSet case study is the real-world proof: 55% → 85% accuracy by modularizing the task into specialized compound steps rather than trusting a single model.
There will come a day when agentic systems are fast enough, cheap enough, and accurate enough to handle end-to-end AutoML on a single model call. When that happens, the agentic version of this system might be possible.
But the compound version will still produce the same forecast for a fraction of the cost. The compute spent on language-model reasoning at every step of an agentic loop is exactly the cost that compound architectures avoid by routing math to math and language to language.
In other words: the agentic transition will turn compound architectures from "the only way that works" into "the cost-optimized way that works." For operators who care about margin per tenant — like a materials factory where forecast accuracy directly maps to inventory and cash flow — that's the version that matters anyway.
Architecture also benefits from two different model-progress trajectories simultaneously. Local open-source models (Qwen, Gemma) will keep improving — meaning the local proposer slot will silently get stronger, for free, on hardware already owned. Meanwhile, premium-tier frontier models will do genuinely agentic work that nothing today can match. The compound architecture hosts both; the operator doesn't have to predict which tier will dominate.
The system has known unfinished edges — all tractable additions to the same loop:
None require redeliberating the system. They're additions to the loop, in the same loop's spirit.