Most AI analytics tools start with a simple idea: connect an LLM to a database and let users ask questions in natural language.
But connecting an LLM to data is only the beginning.
A database contains tables, columns, identifiers, and relationships. A business user thinks in terms of revenue, customers, performance, and trends. Bridging these two worlds requires more than generating SQL from a prompt.
That is one of the problems I am working on with AdeloopData, an AI-powered data analytics platform I am building as part of Adeloop AI.
The idea is straightforward: let users bring their own data, organize it into a semantic domain, and analyze it using either an interactive notebook or a ChatGPT-like conversational interface designed specifically for data analytics.
The problem: data access is not data understanding
Imagine connecting an AI assistant to a database containing orders, customers, products, and payments.
You ask:
What was our revenue last month, and which product category contributed most to the change?
The model needs to understand several things before it can answer reliably:
- Which tables contain the relevant information?
- How are orders related to products and payments?
- What does revenue mean in this dataset?
- How should cancelled orders or refunds be handled?
- Which date field defines the reporting period?
- How should the result be aggregated and visualized?
A model can generate SQL without correctly answering these questions.
This is why I think semantic modeling is an important part of building useful AI analytics systems.
1. Turning data into a semantic domain
In AdeloopData, users can connect external data sources or upload their own datasets. The goal is to transform that raw input into a semantic domain that AI-assisted analysis can use.
A semantic domain provides a structured understanding of a particular dataset or business area.
For example, an e-commerce domain might contain:
- Entities: customers, orders, products, and payments.
- Relationships: customers place orders, and orders contain products.
- Metrics: revenue, order count, and average order value.
- Dimensions: product category, country, and date.
- Business definitions: rules governing how metrics should be calculated.
Instead of relying entirely on an LLM to infer the meaning of every column whenever a question is asked, the system can use semantic context to guide its analysis.
The distinction matters: raw data tells us what values exist, while semantic definitions help explain what those values represent.
A semantic domain is not automatically correct just because it has been generated. Definitions and relationships still need to be validated, especially when business rules are ambiguous.
2. Two ways to analyze data
One of the central ideas behind AdeloopData is that users should not be forced into a single analytics workflow.
Different people prefer different ways of working with data. Some want to explore interactively, while others want to write code and control each step.
AdeloopData brings these approaches together.
The notebook: analysis with control
The notebook environment is designed for users who prefer a more hands-on workflow.
They can work through a sequence of cells, inspect intermediate results, refine their analysis, and build upon earlier steps.
For example, an analyst might:
- Load a dataset.
- Inspect missing values and data types.
- Calculate monthly revenue.
- Compare product categories.
- Create a visualization.
This workflow is useful when an analysis requires reproducibility, experimentation, or detailed control over individual operations.
The notebook and conversational interface serve different needs, but they can share the same underlying data context.
The conversational analytics page: ask questions, explore results
Not everyone wants to write code or manually construct every query.
AdeloopData also provides a ChatGPT-like interface dedicated to data analytics.
Instead of asking a general-purpose assistant a question about an uploaded spreadsheet, users can interact with their data through a workflow designed around analysis and visualization.
For example:
Analyze sales performance over the last six months. Identify the strongest product categories and visualize the monthly trend.
An AI-assisted workflow can interpret the request, use the available semantic context, retrieve or calculate the relevant results, and present the findings.
Rather than returning only a paragraph of text, the interface can render appropriate visualizations, such as:
- Line charts for trends over time.
- Bar charts for comparing categories.
- Tables for detailed results.
- Summary metrics for key indicators.
The goal is to make data exploration more accessible without removing the ability to investigate the underlying results.
3. Why the semantic layer connects these experiences
The semantic layer becomes particularly valuable when multiple interfaces operate on the same data.
Imagine defining a metric called net_revenue once.
The conversational interface can use that definition when answering a question. A notebook-based analysis can reference the same business definition, and a dashboard can display the resulting metric.
Without shared definitions, separate workflows may implement the same calculation differently.
A semantic layer can reduce that inconsistency by providing a common representation of metrics, entities, relationships, and business rules.
Conceptually, the architecture looks like this:
Data sources and uploads → Semantic domain → Analytics interface → Query or computation → Results → Charts and insights
The semantic layer is not the execution engine itself. Queries and computations still need to run against the appropriate data or execution environment. Its role is to provide the meaning and structure that make those operations more consistent.
4. Why not just use RAG and an LLM?
RAG, semantic modeling, and LLMs solve different problems.
RAG helps retrieve relevant context from documents and other indexed information. An LLM interprets requests and can help plan analyses or generate queries. A semantic layer represents business concepts and relationships.
For example, documentation might explain how a company defines net revenue. RAG can retrieve that explanation, while the semantic layer can provide a structured metric definition that an analytics workflow can use.
The query engine then performs the actual calculation.
Combining these components can be more reliable than expecting one prompt to handle data discovery, business logic, query generation, computation, and visualization correctly.
Of course, the quality of the result still depends on the data, semantic definitions, generated query, and validation process.
5. From a question to a visualization
Consider this request:
"Which product categories experienced the largest decline in sales this quarter?"
A well-designed analytics workflow needs to do more than generate a chart.
It needs to determine the relevant sales metric, identify the appropriate date range, select the correct category dimension, compute comparable values, and rank the results.
The workflow can then return a table showing the changes and a chart that makes the differences easier to understand.
Ideally, users should also be able to ask follow-up questions:
- Why did this category decline?
- How does it compare with the previous quarter?
- Show the same analysis by country.
- Can you display this as a line chart instead?
Each follow-up should build on the available analytical context rather than treating every message as an entirely unrelated task.
This is the experience I want AdeloopData to provide: an iterative analytical workflow where conversation and visual exploration work together.
6. What makes this architecture challenging?
Building this kind of system involves several engineering problems beyond integrating an LLM API.
Semantic accuracy: Incorrect metric definitions or relationships can lead to incorrect results.
Query generation: Generated SQL or other operations must be validated before execution.
Data security: Connected sources need appropriate permissions, and the AI layer must not bypass them.
Visualization selection: A chart should match the structure of the result and the question being asked.
Reproducibility: Users should be able to understand where results came from and reproduce important calculations.
Shared analytical context: Notebooks and conversational analysis should use consistent definitions instead of implementing separate versions of the same business logic.
These challenges are why I see AI analytics as a data architecture problem as much as an interface or model problem.
7. The direction of AdeloopData
My goal with AdeloopData is to bring data ingestion, semantic modeling, interactive analysis, and AI-generated visualizations into one environment.
Users should be able to connect a source or upload a dataset, organize it into a meaningful semantic domain, and choose how they want to investigate it.
They can work step by step in a notebook or explore through a conversational analytics interface.
The broader idea is to make data more accessible without treating the underlying structure and business logic as an afterthought.
I am still exploring how these components should evolve, but I believe a shared semantic foundation is a promising way to connect traditional analytical workflows with conversational AI.
I would love to hear from other developers building AI analytics tools:
How are you handling semantic definitions, text-to-SQL, and consistent business logic across notebooks, dashboards, and conversational interfaces?
Are you using an existing semantic layer, building your own, or taking a different approach?
Top comments (0)