Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

From Data Center IoT Telemetry to Data Analytics Chatbots -- Virtual Knowledge Graph is All You Need

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims that building a query-specific Virtual Knowledge Graph and grounding an on-premise LLM on it yields a data center telemetry chatbot with 92.5% answer accuracy and 3.03s average end-to-end latency.

desk verdict Solid engineering extension with real latency gains, but the 92.5% accuracy headline is inherited and not backed by fresh evidence in this paper. read the letter →

arxiv 2506.22267 v2 pith:T7YFLG3U submitted 2025-06-27 cs.DC

Junaid Ahmed Khan , Hiari Pizzini Cavagna , Andrea Proia , Andrea Bartolini This is my paper
classification cs.DC
keywords virtualknowledgegraphdatacentertelemetrynaturallanguagequeryingSPARQLgenerationLLMgroundingIoTanalyticsRDFchatbot
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that an LLM grounded in a small, query-specific Virtual Knowledge Graph—not a full telemetry graph and not raw NoSQL tables—can turn natural-language questions about data center telemetry into correct SPARQL queries. If true, it would remove the three-fold expertise barrier of domain knowledge, deployment knowledge, and query-language knowledge that keeps operators from using the telemetry their systems produce. The measured claim is 92.5% accuracy versus 25% for LLM-to-NoSQL, with average end-to-end latency cut from 20.36s to 3.03s and per-query graph storage below 179 MiB. A reader should care because the paper offers a concrete recipe: build a temporary graph containing only the data the question needs, then let the LLM write SPARQL against that graph's schema.

What carries the argument

The load-bearing mechanism is the Virtual Knowledge Graph, a temporary RDF graph that contains only the data needed to answer a single user question. Its construction has four steps: regex-based entity extraction over a fixed set of categories (node, rack, job, metric, plugin, start time, end time); data fetching from the IoT datalake (NoSQL or Parquet files) using a fast columnar processing library; creation of RDF triples that follow the telemetry ontology; and storage in a graph database. The LLM never sees the raw datalake: its prompt contains the ontology schema and a few-shot examples, so the SPARQL it emits stays within the schema, and a regex-based query refinement step then repairs syntax and invalid property references. Parallelizing LLM inference with VKG construction and serializing triples in N-Triples format are what bring the average total from 20.36s down to 3.03s.

What would settle it

Take the same chatbot and ask a test set of paraphrases of the twelve archetypes—for example, 'What was the average power use of node 42 in the past week?' instead of a metric name and explicit timestamps—then measure end-to-end accuracy. If accuracy drops substantially, the claimed natural-language access is limited to the predefined templates rather than general.

Watch

Extended reading notes

Core claim

The paper's central claim is that the obstacle to natural-language IoT analytics is not the LLM but the missing semantic scaffold. Raw NoSQL telemetry has no fixed schema, so an LLM asked to produce queries against it has to guess table names, column names, and join paths; on the twelve archetype questions it succeeds only 25% of the time. A pre-built full knowledge graph solves this by encoding relationships, but materializing one month of one metric plugin costs 2,979.84 GiB. The paper's solution is to construct a Virtual Knowledge Graph on demand: from the user's question, extract entities such as node, rack, job, metric, and time range; fetch only the relevant readings from the datalake; serialize them as RDF triples following the telemetry ontology; and store this small graph so the LLM can generate SPARQL against a schema it can actually see. With this scaffold the same questions are answered correctly 92.5% of the time, and the whole cycle averages 3.03s per question. The authors present this as evidence that a per-query VKG combines the grounding benefit of a knowledge graph with the storage feasibility of a datalake, making a practical first IoT chatbot.

Load-bearing premise

The system assumes users will phrase questions in the twelve predefined patterns with recognized metric names and strict timestamps; if someone asks with synonyms or casual time phrases, those patterns miss and the claimed accuracy no longer applies.

Editorial extensions

If this is right

  • A user can ask about rack topology, job-to-node mapping, metric statistics, threshold violations, and job durations in plain language and get a correct answer in about three seconds.
  • Data center operators no longer need to know the NoSQL schema or SPARQL; the ontology and graph scaffold do that work.
  • The per-query VKG keeps storage overhead below 179 MiB, making graph grounding feasible on infrastructure that could not hold a full 2,979.84 GiB knowledge graph.
  • Generating SPARQL instead of NoSQL code cuts LLM output tokens by more than half, reducing inference time from 2.98s to 1.28s on the same hardware.
  • Because the pipeline is rule-based at the entity layer and schema-guided at the query layer, the same code can be pointed at another IoT installation by changing the ontology and entity patterns.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Inference: the 92.5% accuracy is an upper bound for the evaluated templates; a broader evaluation with free-form questions would likely expose the regex entity extraction as the main failure point, not SPARQL generation.
  • Inference: the architecture transfers to other IoT domains, but the tail latencies (graph storing up to 92.5s and VKG creation up to 49.3s for large questions) mean interactive experience depends on keeping per-query graphs small or adding chunked ingestion.
  • Inference: replacing regex entity extraction with an LLM for entity extraction—already floated in the paper—could generalize the interface, but would add latency and could introduce a second source of hallucination, so the net benefit is an empirical question.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents a Data Analytics (DA) chatbot for data center IoT telemetry that combines a Large Language Model (LLM) with a rule-based Virtual Knowledge Graph (VKG) construction process. The system translates natural language questions into SPARQL queries over per-query virtual knowledge graphs, with an on-premises LLM inference service, and reports 92.5% answer accuracy, a reduction in average end-to-end latency from 20.36 s to 3.03 s, and VKG sizes below 179 MiB. The evaluation uses 100 questions generated from twelve query archetypes on the M100 data center telemetry dataset, compares four deployment configurations, and provides detailed latency breakdowns across VKG subtasks, LLM inference, query refinement, and query execution. The paper also releases source code and discusses limitations of the regex-based entity extraction and scalability of in-memory RDF graph construction.

Significance. If the claims were fully validated, the paper would contribute a practical blueprint for grounding LLM-generated SPARQL queries in IoT telemetry via query-specific virtual knowledge graphs, with a reproducible implementation and a careful latency breakdown. The internal same-hardware comparison between the naive and optimized VKG implementations (Table V) is a genuine contribution, and the public release of the chatbot code is a practical strength. However, the headline accuracy number is inherited from prior work and is not newly measured here, and the latency reduction claim is weakened by hardware mismatch and extreme tail latencies. The central conceptual contribution is therefore plausible but only partially supported.

major comments (4)
  1. [§VI-C and Table II] The 92.5% accuracy figure is not established in this paper. Section VI-C lists 'Answer accuracy' as an evaluation metric but never defines a scoring protocol, and Table II simply repeats 92.5% for every VKG configuration, with no per-configuration accuracy measurement. The number is attributed to prior work [5] in Section II-D. Because the 100 user questions are generated by substituting values into the twelve archetypes of Table I, the measured accuracy can at most characterize template-following behavior, not general natural-language understanding. This is load-bearing because the abstract's central claim is 'accurate natural language access'; the paper should either report a fresh accuracy evaluation with a precise correctness metric on a defined test set, or explicitly re-scope the claim.
  2. [§VI-D and §VI-G] The 85% latency reduction (20.36 s to 3.03 s) is an apples-to-oranges comparison. The 20.36 s baseline is taken from prior work [5], while the new measurements are on a server with an H100 GPU and TensorRT-LLM (Section VI-A); no same-hardware measurement of the prior implementation is reported. The internal comparison in Table V (VKG-Naive vs VKG-Optimized on the same hardware) is valid and is a solid contribution, but it yields a 57.2% reduction in VKG latency for the Parquet configuration, not the 85% headline. The claim should be re-anchored to the measured internal improvement, or the prior-work baseline should be reproduced on the same hardware.
  3. [Table VII and §VI-G] The 3.03 s average end-to-end latency hides extreme tail latencies that undermine the 'real-time chatbot' claim. Table VII shows that Total VKG Latency has mean 2.90 s, median 0.127 s, and maximum 156.91 s, with a standard deviation of 16.29 s; GraphDB Storing alone reaches 92.49 s and VKG Creation reaches 49.31 s. Since VKG generation runs concurrently with LLM inference, the end-to-end latency inherits this heavy-tailed distribution. The paper should report percentiles (e.g., 95th and 99th) and discuss how the tail affects interactive usability; the current presentation overstates the typical experience.
  4. [§VII and Algorithm 2] The paper's own limitation statement confirms that the evaluation distribution excludes questions that the system cannot process. Section VII states that conceptual terms (e.g., 'average power consumption') and flexible temporal phrasing (e.g., 'last week') fall outside the regex patterns of Algorithm 1, and Algorithm 2 raises ValueError when no key entity or time range can be extracted. Consequently, any question not matching the predefined grammar fails before the LLM is invoked or is absent from the test set. This is not merely a future limitation; it means the reported 92.5% accuracy is conditional on inputs conforming to the twelve archetypes, contradicting the abstract's unqualified claim of 'natural language access.' The abstract and conclusion should be scoped accordingly.
minor comments (5)
  1. [§II-C] There is a typo: 'evalutates' should be 'evaluates'.
  2. [§VI-C and Table II] The storage overhead for the VKG configurations is reported as 0.17 GiB in Table II, but Table VII reports the maximum storage size as 179.4 MiB (≈0.175 GiB); this is consistent, but the units are mixed across tables and should be unified.
  3. [§V-A, Algorithm 1] The regex patterns used for entity extraction are not shown in the paper; providing them (or pointing to the released code location) would strengthen reproducibility, since the algorithm's behavior is central to the evaluation.
  4. [§VI-D, Table III] The output throughput values for LLM-to-NoSQL and LLM-to-SPARQL (117.58 vs 117.99 tokens/s) are nearly identical despite very different output token counts; a sentence explaining why throughput is independent of context length would help the reader.
  5. [§VI-F, Table VI] The serialization benchmark uses 5 million triples described as 'approximately 16% larger than the biggest VKG in our dataset'; since Table VII later reports a max of 4,299,260 triples, 5 million is actually about 16% larger than that, which is consistent, but the wording is slightly confusing and could be rephrased.

Circularity Check

1 steps flagged · score 4.0 of 10

Headline 92.5% accuracy is inherited from the authors' prior EXASAGE work through the reused VKG implementation, making the accuracy claim self-citation load-bearing; the 85% latency reduction is independently measured and not circular.

  1. self citation load bearing [Section II-D and Section VI-C (Table II), with implementation reuse stated in Section V-B]
    "In [5], the authors propose the EXASAGE framework, which extends the KG approach introduced in [6] to enable a natural language LLM interface that translates natural language into SPARQL queries, achieving 92.5% accuracy on data center telemetry data. ... As the VKG, we used the implementation proposed in [5], which is available at (https://gitlab.com/ecs-lab/exasage), but with the optimized LLM inference proposed in this paper."

    The abstract and conclusion present '92.5% accuracy' as this work's achievement, but Table II repeats 92.5% for every VKG configuration without defining how accuracy was scored in this paper. The text explicitly attributes the 92.5% figure to [5] and states that the VKG implementation was adopted from [5]. Because the question-refinement step is also taken from [5], the accuracy number is not a new measurement or derivation in the present work; it is a prior result carried by self-citation. This is load-bearing because that same number is used to support the central claim that VKG-grounded LLMs deliver accurate natural-language access to heterogeneous IoT data. The latency improvement is separately benchmarked and does not reduce to this citation.

full rationale

The paper's genuinely new contribution is the latency optimization: Table V and Table VII break down VKG sub-task timings, Table III and Table IV report LLM inference, query refinement, and query execution latencies, and Figure 3 reconstructs the 3.03 s end-to-end average. Those measurements are concrete, implementation-specific, and not circular. The circularity burden is confined to the accuracy claim: the 92.5% number is inherited from the authors' prior EXASAGE paper [5] via the reused VKG implementation and query-refinement code, with no accuracy-scoring protocol defined in this paper. Section VII is explicit that Algorithm 1 'depends on predefined patterns' and fails on conceptual terms such as 'average power consumption' and flexible temporal phrases like 'last week', so the inherited accuracy applies only to the 12 archetype templates of Table I and cannot be read as general natural-language understanding. That limitation reduces the evidential weight of the 92.5% headline but is a generalization risk rather than an additional circular step. Overall, the central accuracy claim is partially circular because it is a self-cited input rather than an independently verified result; the latency result, which is the main new technical content, is self-contained.

Assumptions & free parameters 4 free parameters · 3 assumptions · 0 invented entities

The reported accuracy (92.5%) is not derived in this paper; it is inherited from the authors' prior EXASAGE work [5], which also supplies the VKG implementation and the ontology from [6]. The system's behavior depends on hand-crafted regex patterns, plugin-metric mappings, few-shot examples, and query-refinement rules that are specific to the M100 dataset and the 12 query archetypes. No new physical or conceptual entities are introduced.

free parameters (4)
  • Entity extraction regex patterns = Not disclosed (hard-coded in Algorithm 1)
    The categories (node, rack, job, metric, plugin, start_time, end_time) and their regex patterns are hand-crafted for the M100 dataset and the 12 query archetypes; they determine which data is fetched and thus the answer accuracy. See Section V-A, Algorithm 1.
  • Plugin-metric map = Not disclosed
    Maps metric names (e.g., 'power') to plugin/sensor names in the datalake. Used in Algorithm 1 to identify the plugin when a metric is mentioned; dataset-specific and manually curated.
  • Few-shot examples in LLM prompt = Not disclosed (number not reported)
    The LLM prompt includes a schema and a set of few-shot examples. The choice of examples affects SPARQL generation accuracy; the paper does not report how many were used or how they were selected. See Section III.3 and Section VI.
  • Query refinement regex rules = Inherited from [5]
    The query refinement step applies hand-coded regex rules to correct syntax errors and invalid property references; these rules are dataset/ontology-specific and were introduced in the authors' prior EXASAGE work. See Section V-B.
assumptions (3)
  • domain assumption The M100 domain ontology from [6] is correct and complete for representing telemetry entities and relations.
    The VKG is built on this ontology, and SPARQL generation relies on its schema. If the ontology omits relevant entities or relations, queries fail. See Sections II-B and V.
  • domain assumption The Base-KG static metadata (spatial layout, rack configurations, node locations) for M100 is accurate and sufficient for answering topological queries.
    The system skips VKG generation for rack/node-only questions and answers from the Base-KG. Inaccuracy in this static data would produce wrong answers. See Section VI-A.
  • ad hoc to paper The 12 query archetypes defined by the authors are representative of user queries on data center telemetry.
    The 92.5% accuracy is measured only on 100 questions derived from these archetypes. The paper does not test on queries outside these patterns, and Section VII acknowledges the entity extraction fails on conceptual terms like 'average power consumption' unless the metric name matches. See Section VI-B.

how reviews work

0 comments
Cite this review

Pith. "Pith review of From Data Center IoT Telemetry to Data Analytics Chatbots -- Virtual Knowledge Graph is All You Need." pith.science (2026). https://pith.science/paper/T7YFLG3U

@misc{pith2026250622267,
  author       = {Pith},
  title        = {Pith review of: From Data Center IoT Telemetry to Data Analytics Chatbots -- Virtual Knowledge Graph is All You Need},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/T7YFLG3U}},
  note         = {Machine review of arXiv:2506.22267}
}
read the original abstract

Industry 5.0 demands IoT systems that support seamless human-machine collaboration, yet current IoT data analysis requires deep domain, deployment, and query expertise. We show that combining Large Language Models (LLMs) with Knowledge Graphs (KGs) enables natural language access to heterogeneous IoT data. Focusing on data center IoT telemetry, we introduce a rule-based Virtual Knowledge Graph (VKG) construction process and an on-premise LLM inference service to create an end-to-end Data Analytics (DA) chatbot. Our system dynamically generates VKGs per query and translates user input into SPARQL, achieving 92.5% accuracy (vs. 25% for LLM-to-NoSQL) while reducing latency by 85% (20.36s to 3.03s) and keeping VKG sizes under 179 MiB. This work demonstrates that VKG-powered LLM interfaces deliver accurate, low-latency, and relationship-aware access to large-scale telemetry, bridging the gap between users and complex IoT systems in Industry 5.0.

Figures

Figures reproduced from arXiv: 2506.22267 by the authors.

Figure 1
Figure 1. Data Analytics (DA) Chatbot Architecture Block Diagram. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Frontend built using Python framework Streamlit containing a setup page and a main page. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Timeline of a single user question cycle showing [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Memory usage vs. number of RDF triples added to an [PITH_FULL_IMAGE:figures/full_fig_p011_4.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. A Unified Ontology for Scalable Knowledge Graph-Driven Operational Data Analytics in High-Performance Computing Systems

    cs.DC 2025-07 conditional novelty 5.0 of 10

    A single ontology models telemetry from Marconi100 and Fugaku, and design optimizations cut knowledge-graph storage by up to 38.84 percent.

Reference graph

Works this paper leans on

28 extracted references · 23 canonical work pages · cited by 1 Pith paper

  1. [5]

    EXASAGE: The First Data Center Operational Data Co-pilot,

    J. A. Khan, M. Molan, and A. Bartolini, “EXASAGE: The First Data Center Operational Data Co-pilot,” TechRxiv, February 2025

    work page 2025

  2. [1]

    The semioe ontology: A semantic model solution for an ioe-based industry,

    M. Arazzi, A. Nocera, and E. Storti, “The semioe ontology: A semantic model solution for an ioe-based industry,” IEEE Internet of Things Journal, vol. 11, no. 24, pp. 40 376–40 387, 2024

    work page 2024

  3. [2]

    50 years of queries,

    D. Chamberlin, “50 years of queries,” Commun. ACM, vol. 67, no. 8, p. 110–121, Aug. 2024. [Online]. Available: https://doi.org/10.1145/ 3649887

    work page 2024

  4. [3]

    Grafana: The open observability platform,

    Grafana Labs, “Grafana: The open observability platform,” https:// grafana.com, 2025, accessed: 2025-08-06

    work page 2025

  5. [4]

    Integrating large language models with internet of things applications,

    M. Zong, A. Hekmati, M. Guastalla, Y . Li, and B. Krishnamachari, “Integrating large language models with internet of things applications,”

    work page

  6. [6]

    ExaQuery: Proving Data Structure to Unstructured Telemetry Data in Large-Scale HPC,

    J. A. Khan, M. Molan, M. Angelinelli, and A. Bartolini, “ExaQuery: Proving Data Structure to Unstructured Telemetry Data in Large-Scale HPC,” in Companion of the 15th ACM/SPEC International Conference on Performance Engineering , ser. ICPE ’24 Companion. New York, NY , USA: Association for Computing Machinery, May 2024, pp. 127– 134

    work page 2024

  7. [7]

    M100 exadata: a data collection campaign on the cineca’s marconi100 tier-0 supercomputer,

    A. Borghesi, C. Di Santi, M. Molan et al. , “M100 exadata: a data collection campaign on the cineca’s marconi100 tier-0 supercomputer,” Scientific Data , vol. 10, p. 288, 2023. [Online]. Available: https://doi.org/10.1038/s41597-023-02174-3

    doi:10.1038/s41597-023-02174-3 2023

  8. [8]

    (2023) The cost of compute: A $7 trillion dollar race to scale data centers

    McKinsey & Company. (2023) The cost of compute: A $7 trillion dollar race to scale data centers. Accessed: 2025-07-24. [Online]. Available: https://tinyurl.com/2s2s388y

    work page 2023

Show all 28 references
  1. [9]

    ExaMon-X: a predictive maintenance framework for automatic monitoring in industrial iot sys- tems,

    A. Borghesi, A. Burrello, and A. Bartolini, “ExaMon-X: a predictive maintenance framework for automatic monitoring in industrial iot sys- tems,” IEEE Internet of Things Journal , 2021

    2021

  2. [10]

    A conceptual frame- work for hpc operational data analytics,

    A. Netti, W. Shin, M. Ott, T. Wilde, and N. Bates, “A conceptual frame- work for hpc operational data analytics,” in 2021 IEEE International Conference on Cluster Computing (CLUSTER) , 2021, pp. 596–603

    2021

  3. [11]

    Global experiences with hpc operational data measurement, collection and analysis,

    M. Ott, W. Shin, and et al., “Global experiences with hpc operational data measurement, collection and analysis,” in 2020 IEEE International Conference on Cluster Computing , 2020

    2020

  4. [12]

    Sql over nosql: Smarter data decisions,

    R. De, “Sql over nosql: Smarter data decisions,” https://medium.com/ @rituparna.de12/sql-over-nosql-smarter-data-decisions-d36d2c12ea29, 2020, accessed: 2025-07-29

    2020

  5. [13]

    Querying heterogeneous data in graph-oriented nosql systems,

    M. El Malki, H. Ben Hamadou, M. Chevalier, A. P ´eninou, and O. Teste, “Querying heterogeneous data in graph-oriented nosql systems,” in Big Data Analytics and Knowledge Discovery: 20th International Conference, DaWaK 2018, Regensburg, Germany, September 3–6, 2018, Proceedings...

    2018 doi

  6. [14]

    Managing schema evolution in nosql data stores,

    S. Scherzinger, M. Klettke, and U. St ¨orl, “Managing schema evolution in nosql data stores,” 2013. [Online]. Available: https: //arxiv.org/abs/1308.0514

    2013 arXiv

  7. [15]

    A group discovery method based on collaborative filtering and knowledge graph for iot scenarios,

    K. Yao, H. Wang, Y . Li, J. J. P. C. Rodrigues, and V . H. C. de Al- buquerque, “A group discovery method based on collaborative filtering and knowledge graph for iot scenarios,” IEEE Transactions on Compu- tational Social Systems , vol. 9, no. 1, pp. 279–290, 2022

    2022

  8. [16]

    Kg-ibl: Knowledge graph driven incremental broad learning for few-shot specific emitter identification,

    M. Hua, Y . Zhang, Q. Zhang, H. Tang, L. Guo, Y . Lin, H. Sari, and G. Gui, “Kg-ibl: Knowledge graph driven incremental broad learning for few-shot specific emitter identification,” IEEE Transactions on Information Forensics and Security , vol. 19, pp. 10 016–10 028, 2024

    2024

  9. [17]

    Multilayer internet-of- things middleware based on knowledge graph,

    C. Xie, B. Yu, Z. Zeng, Y . Yang, and Q. Liu, “Multilayer internet-of- things middleware based on knowledge graph,” IEEE Internet of Things Journal, vol. 8, no. 4, pp. 2635–2648, 2021

    2021

  10. [18]

    Knowledge- based fault diagnosis in industrial internet of things: A survey,

    Y . Chi, Y . Dong, Z. J. Wang, F. R. Yu, and V . C. M. Leung, “Knowledge- based fault diagnosis in industrial internet of things: A survey,” IEEE Internet of Things Journal , vol. 9, no. 15, pp. 12 886–12 900, 2022

    2022

  11. [19]

    A survey on hallucination in large language models: Principles, taxonomy, challenges, and open questions,

    L. Huang, W. Yu, W. Ma, W. Zhong, Z. Feng, H. Wang, Q. Chen, W. Peng, X. Feng, B. Qin, and T. Liu, “A survey on hallucination in large language models: Principles, taxonomy, challenges, and open questions,” ArXiv, vol. abs/2311.05232, 2023. [Online]. Available: https://api.sem...

    2023 arXiv

  12. [20]

    Unifying large language models and knowledge graphs: A roadmap,

    S. Pan, L. Luo, Y . Wang, C. Chen, J. Wang, and X. Wu, “Unifying large language models and knowledge graphs: A roadmap,” arXiv preprint arXiv:2306.08302, 2023

    2023 arXiv

  13. [21]

    A survey on knowledge graphs: Representation, acquisition, and applications,

    S. Ji, S. Pan, E. Cambria, P. Marttinen, and P. S. Yu, “A survey on knowledge graphs: Representation, acquisition, and applications,” IEEE Transactions on Neural Networks and Learning Systems , vol. 33, no. 2, pp. 494–514, 2021

    2021

  14. [22]

    Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls,

    J. Li, B. Hui, G. Qu, J. Yang, B. Li, B. Li, B. Wang, B. Qin, R. Geng, N. Huo, X. Zhou, C. Ma, G. Li, K. C. Chang, F. Huang, R. Cheng, and Y . Li, “Can llm already serve as a database interface? a big bench for large-scale database grounded text-to-sqls,” in Proceedings of the...

    2024

  15. [23]

    Retrieval- augmented generation for knowledge-intensive nlp tasks,

    P. Lewis, E. Perez, A. Piktus, F. Petroni, V . Karpukhin, N. Goyal, H. Ku ˇttl´er, M. Lewis, W.-t. Yih, T. Rockt ¨aschel et al. , “Retrieval- augmented generation for knowledge-intensive nlp tasks,” in Advances in neural information processing systems, vol. 33, 2020, pp. 9459–9474

    2020

  16. [24]

    Gotham dataset 2025: A reproducible large-scale iot network dataset for intrusion detection and security research,

    O. Belarbi, T. Spyridopoulos, E. Anthi, O. Rana, P. Carnelli, and A. Khan, “Gotham dataset 2025: A reproducible large-scale iot network dataset for intrusion detection and security research,” 2025. [Online]. Available: https://arxiv.org/abs/2502.03134

    2025 arXiv

  17. [25]

    Edge-iiotset: A new comprehensive realistic cyber security dataset of iot and iiot applications: Centralized and federated learning,

    M. A. Ferrag, O. Friha, D. Hamouda, L. Maglaras, and H. Janicke, “Edge-iiotset: A new comprehensive realistic cyber security dataset of iot and iiot applications: Centralized and federated learning,” 2022. [Online]. Available: https://dx.doi.org/10.21227/mbc1-1h68

    2022 doi

  18. [26]

    Polars vs. pandas: Benchmarking the performance,

    JetBrains, “Polars vs. pandas: Benchmarking the performance,” 2024, accessed: 2025-04-20. [Online]. Available: https://blog.jetbrains.com/ pycharm/2024/07/polars-vs-pandas/

    2024

  19. [27]

    Benchmarking energy performance of polars,

    Polars, “Benchmarking energy performance of polars,” 2024, accessed: 2025-04-20. [Online]. Available: https://pola.rs/posts/ benchmark-energy-performance/

    2024

  20. [2024]

    Available: https://arxiv.org/abs/2410.19223

    [Online]. Available: https://arxiv.org/abs/2410.19223

    arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.