TL;DR:
We cleaned underlying data models, saved up to 20% on data processing costs as a side bonus, achieved 100% consistency in produced answers by Hex threads
We worked with a client who had already implemented AI-driven analytics on top of their warehouse using Hex threads, and on paper everything looked correct — solid dbt models, structured data, and an AI layer that should have been able to answer business questions quickly and reliably.
In practice, the outputs were inconsistent enough that stakeholders stopped trusting them, because even if some answers were occasionally correct, the lack of consistency made the system unusable for real decision-making.
At first, it looked like a limitation of AI.
It wasn’t.
The actual problem
The issue was not the model, but the data layer it was operating on.
The warehouse contained multiple models describing very similar concepts, often with inconsistent naming and no clear indication of which one should be treated as the source of truth. It was common to see models like dim_accounts, fact_accounts, accounts, or dim_users__accounts, each partially overlapping but without clearly defined boundaries.
From a human perspective, this is manageable with enough context.
From an AI perspective, this creates ambiguity, because there is no clear signal which model represents the correct definition of an entity or metric.
On top of that, there were very few semantic models and limited documentation in YAML, so even when the data itself was technically correct, it lacked the business context needed for consistent interpretation.
The AI wasn’t failing.
It was guessing.
What we did
Instead of trying to improve prompts or change the model, we focused entirely on the data layer.
We reorganized the project to introduce a clear structure with proper separation between fact and dimension tables, standardized naming conventions so that models became predictable and unambiguous, and expanded the semantic layer to explicitly define metrics and relationships.
At the same time, we completed missing YAML documentation at both the model and column level and introduced a tool to make maintaining this metadata easier going forward.
The most important change, however, was reduction.
We removed redundant and overlapping models, reducing the number of entities the system had to reason about and making the remaining ones much clearer.
The result
After these changes, the same AI system started producing consistent and reliable answers, because it no longer had to resolve ambiguity across multiple similar models.
Accuracy improved, but more importantly, stakeholder trust returned, which is ultimately what determines whether such a system is actually usable.
As an additional benefit, simplifying the data model also reduced warehouse costs by around 10–20% per run.
Takeaway
AI analytics doesn’t fail because the model is weak.
It fails because the data is ambiguous.
If your system produces inconsistent answers, the solution is rarely adding more data or switching tools, but rather improving structure, naming, and semantics while reducing unnecessary complexity.
How we made AI analytics work smoothly? was originally published in Lortech Solutions Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
