Do Bigger AI Models Always Win? A CTO’s Perspective on Smarter Machine Learning

The prevailing story in AI right now is one of scale: bigger models, more parameters, more compute, better results. But not everyone building production AI is convinced that bigger is always better. Danijel Kivaranovic, co-founder and CTO of the data observability company digna, has spent his career on the engineering side of that question, and he argues that for a large class of real-world problems, the obsession with scale misses the point. We spoke with him about the case for smaller, faster models, and why his team deliberately went the opposite direction from the industry trend. 

Rather than pursuing marginal improvements in benchmark accuracy through increasingly complex models, digna has taken a different engineering approach. One built around adaptability, efficiency, and responding to changing data as quickly as possible. 

We spoke with Danijel about the trade-offs between model size and business value, why enterprise AI often has different priorities than consumer AI, and why he believes smarter machine learning isn’t always about building bigger models. 

Q: The whole industry seems to be racing toward larger models. You’re sceptical. Why? 

I’m not sceptical of large models in general. For some problems they’re genuinely the right tool. What I’m sceptical of is applying that logic everywhere by default. 

There’s an assumption that more computation always means better results, and that a bigger model is automatically a better model. 

But you have to ask a practical question: does it always make sense to invest enormous computation power to achieve, say, 0.05% better prediction accuracy? 

For a lot of real business problems, the answer is no. 

That last fraction of a percent costs you a huge amount in compute, in energy, in latency, and in complexity, and it often buys you almost nothing that matters to the customer. 

Business data changes every day. Sometimes every hour. 

If your models cannot adapt to those changes efficiently, slightly better benchmark accuracy may not translate into better business outcomes. 

Q: So the question isn’t “how accurate can we be,” it’s “how accurate do we need to be, at what cost”? 

Exactly. Engineering is about trade-offs, and somewhere along the way parts of the AI field started treating accuracy as the only axis that matters, as if cost and speed were someone else’s problem. 

But in production they’re your problem. If I can get a result that’s effectively just as useful with a fraction of the computation, and get it far faster, that’s not a compromise. 

In many cases that’s the better engineering decision. The 0.05% isn’t free. Someone pays for it, in cloud bills and in slower systems. 

For many enterprise workloads, especially those involving operational data, freshness matters more than model size. 

A model trained on yesterday’s assumptions may already be outdated if today’s data behaves differently. 

That’s why we approached the problem differently at digna. 

Q: What is different about digna’s approach? 

Instead of relying on one large model trained over long periods, our platform continuously adapts. 

Whenever new data arrives, digna trains lightweight statistical and AI models against the latest information. 

Because these models are much smaller and focused on current behavior, they can be trained extremely quickly. 

That means the platform reacts almost immediately when business patterns change. We’re optimizing for responsiveness rather than simply maximizing model complexity. 

Q: Why is retraining after every delivery such an important design choice? 

Because data changes, constantly, and it changes in ways you don’t expect. 

That’s the whole reason data quality is hard. If your model was trained months ago on how the data used to look, it’s going to struggle when the data shifts. By retraining after every delivery, digna reacts to changing data very fast. It’s always working from an up-to-date picture of what “normal” looks like right now, not what normal looked like last quarter. 

For catching anomalies, that freshness matters enormously. A model that’s perfectly accurate on stale assumptions is worse than a lighter model that’s current. You can see how that plays out in our anomaly detection approach, where the system learns each dataset’s normal behaviour and flags deviations automatically. 

Adaptive learning allows observability systems to respond as the business evolves instead of waiting for periodic retraining cycles. 

Q: Isn’t there a risk that smaller, frequently retrained models are less capable than one large model? 

It depends entirely on the problem. 

For our problem, no, and I’d argue the opposite. 

The task isn’t to have deep general knowledge of the world. The task is to understand the specific, current behaviour of a specific company’s data and notice when something deviates. 

A focused model that retrains constantly on that exact data is extremely well suited to that. A giant general model would be slower, more expensive, harder to run inside a customer’s environment, and not obviously better at the actual job. Matching the model to the problem beats maximising the model for its own sake. 

Q: Does this approach also benefit data scientists? 

Very much so. 

Data scientists spend a significant amount of time understanding whether their input data is reliable. 

If underlying data changes unexpectedly, model performance can deteriorate even though the model itself hasn’t changed. 

By continuously analyzing incoming datasets, observability systems can identify behavioral shifts before they begin affecting downstream analytics or machine learning workloads. 

That allows data science teams to respond earlier and with greater confidence. 

It’s one of the reasons we recently introduced the Python SDK, enabling developers and data scientists to integrate observability directly into their existing Python workflows. 

Q: You mentioned running inside the customer’s environment. Does the efficiency approach connect to that? 

It does, and it’s a point people often miss. 

Because our models are lightweight and fast, we can run them in-database, inside the customer’s own infrastructure, rather than shipping their data out to some massive external system. 

For the regulated industries we serve, finance, healthcare, the public sector, that’s essential. Their data can’t leave the building. If our approach required enormous compute clusters, that architecture simply wouldn’t be possible. 

So the “smaller and faster” decision isn’t only about cost. It’s what lets us keep the data where it belongs. 

Q: Where do you see enterprise AI heading over the next few years? 

I think we’ll see greater emphasis on adaptive intelligence rather than static intelligence. 

Organizations want AI systems that evolve alongside their business. 

That means models capable of learning continuously, responding quickly, and integrating naturally into operational workflows. 

We’ll also see tighter integration between observability, analytics, and AI. 

Instead of simply detecting problems, platforms will increasingly explain why they happened, how business behavior is changing, and what actions organizations should consider next. 

That requires AI that’s not only intelligent but practical. 

Q: What would you say to a team that assumes they need the biggest possible model for their problem? 

Don’t evaluate AI purely by model size. I’d say start from the problem, not from the model. 

Ask different questions. 

• How quickly does it adapt? 

• How much infrastructure does it require? 

• Can it operate with continuously changing data? 

• Does it deliver meaningful business outcomes? 

Very often, when you answer those questions honestly, you find you don’t need the biggest model. You need the right-sized one, running at the right time, in the right place. That’s not a lesser goal than scale. It’s a more disciplined one. 

Because in enterprise AI, success isn’t measured by how large the model is. 

It’s measured by how well it helps organizations make better decisions. 

Q: So, do bigger models always win? 

No. Better-matched models win. Sometimes that’s big. 

Often, in the real world, it’s smaller, faster, and closer to the data. The teams that understand that will build systems that are cheaper, quicker, and honestly more practical than the ones chasing scale for its own sake. 

About digna 

Founded in Austria in 2020, digna is a European data quality and observability platform that combines AI-powered anomaly detection, adaptive machine learning, data validation, schema monitoring, business observability, and analytics. 

The platform continuously evaluates changing data behavior to help organizations detect anomalies, improve data trust, and generate business insights without relying solely on manually configured rules.