Data centers aren’t just labs full of blinking LEDs and humming fans; they’re living ecosystems of sensors, power lines, cooling loops, and job schedules that generate streams of telemetry every second. For operators, researchers, and the AI systems that increasingly rely on that telemetry, the challenge isn’t just collecting data — it’s turning it into insight fast enough to matter. The bigger the center, the bigger the data, and the more the clock pressure to translate those numbers into decisions that prevent outages, save energy, and optimize performance.
That’s the backdrop for a recent line of work from a team at the University of Bologna’s DEI Department, led by Junaid Ahmed Khan, with collaborators Hiari Pizzini Cavagna, Andrea Proia, and Andrea Bartolini. They built an end-to-end Operational Data Analytics (ODA) Chatbot that uses a lightweight, on-demand construct called a Virtual Knowledge Graph (VKG) to turn natural-language questions into fast, precise SPARQL queries against a telemetry data lake. The result isn’t just a clever proof of concept; it’s a blueprint for making sense of sprawling, schema-less data in real time — something that felt out of reach just a few years ago.
In the world of HPC and data center analytics, the math is blunt: you can have scale, or you can have schema, but you can’t usually have both at the speed modern AI demands. The Bologna team’s work leans into a provocative idea: by building tiny, query-specific graphs on the fly, you can ground a language model’s understanding in a concrete data structure without paying the price of storing a full knowledge graph for every data source you’ve ever touched. In their experiments with the Marconi100 (M100) data set and surrounding telemetry ecosystems, the researchers show that this VKG approach can deliver accurate, real-time-like chat responses with a fraction of the storage and a fraction of the latency compared to previous attempts. The paper highlights a central claim with striking numbers: accuracy soars to around 92.5% when the system grounds its reasoning in a graph, while end-to-end latency can shrink from a few dozen seconds to a few seconds per query, depending on data format. These are not just numbers; they map a pathway to conversational analytics that could reshape how operators interact with their own infrastructure—and how AI assistants work with large, messy data stores.
A map for unpredictable data
Ask a human expert to find a needle in the haystack of HPC telemetry, and you’ll probably get a careful, manual tour through dozens of tables and time ranges. In NoSQL databases, the same task gets messier: the data isn’t forced into a single schema, so the relationships between data sources aren’t obvious by design. You can build a knowledge graph to impose structure, but traditional graphs scale poorly when you’re talking about multivariate time series that stretch across power, cooling, and job execution. That’s where the VKG idea shines: it’s a lightweight, runtime graph tailored specifically to the question at hand.
The VKG approach is not a replacement for a full, static ontology, but a pragmatic on-demand construct that captures only the relationships needed to answer a user’s query. It’s like having a small, perfectly mapped city for your current journey, rather than a huge, static atlas of a thousand cities you’ll never visit all at once. When a user asks about, say, the average power consumption of a set of jobs over a time window, the VKG conjures exactly the nodes, edges, and edges’ attributes that matter, and nothing more. This dramatically reduces the memory footprint and data transfer while keeping the reasoning bound to a faithful representation of the underlying telemetry schema.
The study emphasizes two critical outcomes. First, knowledge graphs provide structural context that helps a language model generate SPARQL queries that align with the data’s real-world relationships. Second, generating a VKG on demand makes it feasible to keep the data lake lean. The combination yields two surprising outcomes: high accuracy and surprisingly low latency, once the pipeline is tuned. The authors underline a bold takeaway: you don’t need a colossal, always-on KG to benefit from graph-grounded language models; you need a clever, query-driven VKG that fetches only what’s necessary.
The VKG architecture in plain language
The authors walk us through a five-part architecture that sits between a natural-language question and the data it seeks. On the surface, it’s a chatbot: you type a question, you get a data-backed answer. Behind the curtain, though, is a modular pipeline designed for speed, reliability, and reproducibility.
First, there’s the frontend, a user-friendly chat interface built with Streamlit. It’s the doorway through which facility managers, operators, and analysts pose their questions and receive results in tabular or CSV form. Second, the backend orchestrates everything. It triggers two parallel tracks: a Large Language Model (LLM) inference service that writes a SPARQL query from the user’s question, and a VKG-generation pipeline that assembles just the right slice of data into a temporary graph. When both tasks finish, the system refines the query and runs it against a graph database that hosts the VKG and the core ontology. The results are then pushed back to the user through the same chat channel.
The LLM inference service is not just string-putzing; it’s anchored by a textual representation of an extended ODA ontology and a set of few-shot examples that guide the model to produce syntactically and semantically viable SPARQL queries. The aim is not to bypass the ontology; it’s to leverage it so the LLM speaks the graph’s language. The VKG, meanwhile, is the dynamically generated, query-specific knowledge graph that pulls in only the data necessary to answer the question — everything else stays in the ODA datalake, waiting for its moment to shine in a future query.
There’s a practical twist: the VKG is stored in a graph database (GraphDB, in this study) and is created on the fly from the ODA datalake, which contains the raw telemetry. The VKG’s job, shape, and size are carefully bounded so that you don’t end up constructing a giant graph for every possible query. The end result is a system that preserves the flexibility of NoSQL storage while delivering the conceptual clarity of graphs for the LLM to reason with.
The paper doesn’t stop at architecture diagrams; it dives into four sub-tasks that make VKG generation possible: Entity Extraction, Data Fetching, VKG Creation, and GraphDB Storing. The entity extraction identifies the “what” in a user’s question (nodes, racks, jobs, metrics, time windows, etc.). Data fetching pulls the right slices from the datalake. VKG Creation translates those slices into RDF triples that populate the temp graph. GraphDB Storing persists the VKG for subsequent query execution. It’s a careful choreography where each step matters, and bottlenecks are diagnosed and addressed through practical engineering choices—most notably, replacing Pandas with Polars for data handling, and switching serialization formats to speed up storage and ingestion.
One of the paper’s most practical wins is in the spirit of efficiency. The researchers quantify a dramatic reduction in latency when moving from a naive, all-purpose KG approach to a VKG-based workflow. In experiments using historical and production-like data, the VKG-Optimized path reduces total VKG latency and, crucially, slashes the end-to-end response time to around a few seconds per query. The authors show that the optimized VKG route keeps memory and storage demands modest while preserving the high accuracy that graph-grounded reasoning enables.
Why speed and storage finally converge
The numbers in the study are more than impressive; they’re a roadmap for how to deploy AI-assisted data analytics in the real world. A key point is the contrast between several deployment configurations. The most naïve approach—an LLM that tries to generate NoSQL queries directly against a sprawling telemetry store—lags terribly: end-to-end latency tops 100 seconds per query, and accuracy hovers around 25%. In other words, the system can talk, but it often talks nonsense in the service of speed, a classic hallucination risk in AI systems that operate on unstructured data. The practical takeaway is stark: without a grounding structure, even the best LLMs struggle to translate user intent into correct data retrieval steps when the data has no fixed schema.
If you push the data into a pre-built ODA knowledge graph, the story changes dramatically. You can slash end-to-end latency to about 1.4 seconds and achieve 92.5% accuracy. That’s a huge improvement in reliability, but there’s a catch: the full, static KG for even a single data source (like a specific IPMI plugin or a month of telemetry) can be enormous — in the paper’s example, nearly 3,000 GiB. It’s a reminder that “more knowledge” isn’t always practical when it sits in a single, monolithic structure that must be deployed and kept up to date across every data source and time window.
The VKG approach — building a small, query-tailored graph on the fly — bridges that gap. The researchers compare VKG-based routes in two datalake configurations: a NoSQL NoSQL store and Parquet files (as historical data). The VKG-Naive approach yields end-to-end times around 9 seconds (NoSQL) or 6–7 seconds (Parquet), with the same 92.5% accuracy. The real leap comes from optimizing VKG creation and Inference: the VKG-Optimized path reduces the end-to-end time to roughly 3 seconds per question in the Parquet configuration and around 6.5 seconds in NoSQL, while keeping the accuracy unchanged at 92.5%. Perhaps the most striking stat is the storage footprint: without VKG on demand, the static KG would gobble up terabytes of space; with VKG on demand, the system stays lean, pulling in and discarding data as each query requires it, and capping the peak VKG size well below what a full KG would demand.
The authors also report practical engineering decisions that mattered. They experimented with data formats for VKG serialization, finding that N-Triples offered the best latency-versus-size trade-off for large RDF graphs, and they restructured the VKG assembly to minimize in-memory growth. It’s a reminder that in the real world, a few smart engineering choices can compound into meaningful, user-facing speedups. The end-to-end story isn’t just about clever ideas; it’s about a system designed to run continuously, on commodity hardware, with predictable response times for operators who must make split-second decisions about energy, cooling, and workloads in a live data center.
And yes, the paper is honest about limits. The current entity-extraction logic relies on predefined categories and pattern matches, which can misinterpret novel terms or unconventional phrasings. Temporal expressions remain a soft spot, and memory management for very large VKGs is an ongoing concern. The authors sketch a realistic research arc: enable smarter NLP-based extraction, introduce chunking to manage memory for huge VKGs, experiment with alternative triplestores to improve ingestion throughput, and explore transitions to more scalable property-graph databases. The goal is not a perfect system today, but a practical path to a future where AI copilots can converse with live data centers in real time, understand the domain, and fetch just the right slice of data every time.
It’s worth noting who’s behind this work. The study is anchored in the University of Bologna’s DEI Department, with Junaid Ahmed Khan as lead author and collaborators Hiari Pizzini Cavagna, Andrea Proia, and Andrea Bartolini contributing to the architecture, experiments, and evaluation. The paper’s ambition is both technical and humane: to empower the people who manage some of the world’s most intricate computing systems with a conversational tool that makes telemetry approachable, actionable, and timely. By tying a language model’s reasoning to a live, query-specific VKG, the researchers show how to preserve semantic fidelity without surrendering speed or scalability. In other words, they’re not just teaching machines to talk; they’re teaching machines to listen, reason, and fetch the right facts when it matters most.
The practical future of data, AI, and conversation
What does this mean for the broader world of AI-assisted data analytics? The most immediate impact is literal: a working prototype for real-time, conversational access to complex telemetry data. The ODA Chatbot, powered by VKG, points toward a future where operators can ask in natural language not only what happened, but why it happened and what to do about it — all grounded in the data that actually exists in the system, not in a model’s guesswork. If you squint at the bigger picture, the implication is even bigger: as AI tools become more capable of handling unstructured, heterogeneous data, the bottleneck shifts from “can we extract the data?” to “can we reason with the data in a trustworthy, computationally efficient way?”. Grounding the AI in a live graph that mirrors the data center’s own relationships is a powerful way to answer that question.
Yet the path is not a hype-laden leap. The study is careful to frame VKGs as a practical, scalable alternative to building full knowledge graphs for every data source. It’s a design philosophy that recognizes the costs of scale and the realities of production environments. The practical recipe—on-demand VKGs plus a lean LLM-inference loop, plus a refined SPARQL query path—offers a viable blueprint for other domains with heavy telemetry, multivariate streams, and the same demand for real-time interpretation: energy grids, industrial IoT, and complex cloud infrastructures alike. The paper’s combination of system design, empirical evaluation, and candid discussion of limitations invites other researchers and practitioners to build on this approach, test it in new environments, and push the envelope toward even more responsive, reliable, and human-friendly data analytics copilots.
In one line of work, the future looks like a co-pilot that doesn’t just summarize dashboards but speaks the language of the data itself. It doesn’t pretend to replace human expertise; it augments it by translating intent into precise queries, then back again into human-readable answers. The University of Bologna team has demonstrated that, when done thoughtfully, a Virtual Knowledge Graph can be more than a clever trick — it can be the hinge on which real-time data analytics swing open a door to faster decisions, cleaner operations, and a more intuitive partnership between humans and AI in the noisy, dynamic world of data centers.
