Text-2-SQL-4-PM: NLP for PM Analytics

• Text-2-SQL-4-PM is a framework for natural-language querying in project management that integrates SQL generation, retrieval-augmented schema grounding, and logical query-plan construction.
• It addresses large-scale, schema-rich PM environments by decomposing tasks, handling domain shifts, and refining queries through execution feedback.
• The system employs multi-agent coordination, multilingual schema localization, and iterative self-correction for robust analytics in evolving enterprise workflows.

“Text-2-SQL-4-PM” (Editor’s term) denotes project-management-oriented natural-language access to structured and tabular data, especially where the data are large, schema-rich, and analytically demanding. In the literature summarized here, the relevant data include tasks, issues, sprints, resources, time logs, financials, activity logs, issue trackers, and KPI time series, while the technical scope spans classical text-to-SQL, retrieval-augmented schema grounding, logical query-plan generation outside a DBMS, and agentic refinement loops that use execution feedback rather than one-shot decoding alone (Zhang et al., 26 Aug 2025, Gladkykh et al., 3 Apr 2025).

1. Scope, problem setting, and motivating constraints

A project-management environment typically combines large tables with complex analytical needs. The cited work explicitly characterizes this environment as one containing tasks, issues, sprints, resources, time logs, and financials, and as demanding trend analysis, delay prediction, risk or anomaly detection, and KPIs across many dimensions rather than only simple SELECT/WHERE retrieval (Zhang et al., 26 Aug 2025). This immediately places Text-2-SQL-4-PM at the boundary between database querying and broader analytical orchestration.

The first technical pressure point is scale. One line of work argues that classic text-to-SQL becomes inadequate when tables are very large, including settings with thousands of columns and hundreds of thousands of rows, or when questions require operations such as PCA, anomaly detection, clustering, or value prediction that are not native to vanilla SQL (Zhang et al., 26 Aug 2025). A second pressure point is enterprise realism: MultiSpider 2.0 preserves Spider 2.0’s structural difficulty while adding eight languages, localized schema content, and dialect diversity across BigQuery, Snowflake, and SQLite, thereby moving evaluation closer to real organizational deployments (Pham et al., 29 Sep 2025).

A third pressure point is domain shift. In a formative study reported for SQLsynth, accuracy dropped by 13.3% for new columns and 9.1% for new tables after schema updates, while engineers reported that they could annotate only about 50 complex text–SQL pairs per day (Tian et al., 21 Feb 2025). For project-management systems, where schemas evolve as workflows, custom fields, and reporting logic change, this implies that Text-2-SQL-4-PM is not a static parsing task but a continuously adapted socio-technical system.

2. Core architectural patterns

One influential pattern is explicit pipeline decomposition. SPSQL breaks Text2SQL into four subtasks—table selection, column selection, SQL generation, and value filling—and casts them as a text classification problem, a sequence labeling problem, and two text generation problems, respectively (Shen et al., 2023). On marketing business data from the State Grid Corporation of China, this pipelined design reached 95.6% Logic Form Accuracy, compared with 81.5% for RAT-SQL, 68.0% for IGSQL, and 36.4% for IRNET, while also incorporating a named entity recognition module and data augmentation (Shen et al., 2023). For PM deployments, this pattern is attractive because table choice, metric choice, and literal-value grounding often fail for different reasons and benefit from separate controls.

A second pattern is schema reduction plus difficulty conditioning. RH-SQL applies a Refined Schema (RS) stage and a Hardness Prompt (HP) stage around a standard seq2seq generator, using a schema refiner to select the top 4 tables and top 5 columns, “totaling twenty highly relevant schema items,” and a RoBERTa-large classifier to prepend tokens such as [/easy], [/hard], or [/extra-hard] to the generation input (Yi et al., 2024). This yields 82.6% execution accuracy on Spider with RH-SQL-large+NatSQL, while reducing storage from 15.0 GB to 6.2 GB and training time from 102,800 s to 49,920 s relative to DQHP (Yi et al., 2024). For project-management use, this architecture directly targets the common case in which the database contains many irrelevant tables for any single query but the query’s structural hardness varies sharply.

A third pattern is retrieval-augmented grounding. Datrics Text2SQL constructs a knowledge base from database documentation, question–SQL examples, and domain-specific rules, and formalizes generation as

$$S^{R}_{code} = \text{LLM}(Q, \mathcal{T}, \mathcal{S}),$$

where $Q$ is the normalized user query, $\mathcal{T}$ are relevant table descriptions, and $\mathcal{S}$ are retrieved SQL examples (Gladkykh et al., 3 Apr 2025). The system stores structured documentation and examples as embeddings, retrieves via cosine-based similarity, and reranks with a cross-encoder (Gladkykh et al., 3 Apr 2025). In PM settings, this is well matched to environments where “cycle time,” “blocked,” “sprint velocity,” or “burndown” must be grounded in local schema and reporting conventions rather than inferred from generic pretraining alone.

3. From SQL strings to executable query plans

The most explicit departure from classical text-to-SQL is the “text-to-query-plan” formulation proposed in “Text to Query Plans for Question Answering on Large Tables” (Zhang et al., 26 Aug 2025). Rather than mapping natural language to a SQL string executed by a DBMS, the framework maps natural language to a logical query plan—a sequence or tree of operators—executed in Python over CSV, Excel, or dataframe representations. The system is the Tree-Driven Sequential Operation QA System (TSO), whose components are a Supervisor Agent (LLM), a Python toolset, a tree-structured plan representation, and a multi-level vector index for large schemas (Zhang et al., 26 Aug 2025).

The paper formalizes the planning problem by letting $\mathcal{D} = \{d_1,\dots,d_m\}$ be tables, $\mathcal{O} = \{o_1,\dots,o_n\}$ be operators, $q$ be a natural-language query, $P$ the space of logical plans, and $y_q$ the ground-truth answer, then optimizing

$$\min_{p \in P} \quad L\big( p(q, \mathcal{D}), \, y_q \big).$$

It further proves that generating the optimal plan is NP-hard, motivating an iterative ReAct-style loop of Thought, Action, Observation, and optional Backtracking (Zhang et al., 26 Aug 2025). This is a significant conceptual shift for Text-2-SQL-4-PM, because the unit of reasoning becomes an analyzable operator graph rather than only a final SQL string.

The TSO toolset includes SQL-like operators—selection, filtering, sorting, aggregation, grouping, join, and set operations—but also PCA, anomaly detection, PythonREPLTool, and value prediction / ML-style operations (Zhang et al., 26 Aug 2025). The agronomic evaluation uses tables with 266,033 records and 8,058 features, answers 16/20 custom queries correctly, and reports that PCA and dimensionality reduction tasks were answered correctly, while some complex ML or anomaly tasks failed because PythonREPLTool debugging loops hit iteration limits (Zhang et al., 26 Aug 2025). The same paper explicitly suggests that, for a Text-2-SQL-4-PM system, analogous operators could include trend analysis, risk spike detection, forecasting completion times, and clustering tasks by similarity or risk (Zhang et al., 26 Aug 2025). This suggests a broader definition of the field: PM-oriented natural-language analytics may be better modeled as “text-to-operations” than as “text-to-SQL” in the narrow sense.

The system’s handling of large schemas is also directly relevant. TSO introduces a hierarchical vector structure—table vectors, cluster vectors, and column vectors—and two algorithms for building vector stores and retrieving relevant columns. The key operational point is that the LLM never sees the full table; it sees column descriptions, table summaries, and sample rows, while heavy operations happen outside the model (Zhang et al., 26 Aug 2025). For PM data with many custom fields or telemetry columns, this is an explicit answer to context-length and schema-noise failure modes.

4. Robustness mechanisms: self-correction, critique, and voting

A major theme across recent work is that one-shot generation is insufficient. SelECT-SQL combines chain-of-thought prompting, self-correction, and ensemble refinement, and reports 84.2% execution accuracy on the Spider development set using GPT-3.5-Turbo, surpassing other GPT-3.5-Turbo-based baselines at 81.1% and exceeding the reported GPT-4 result at 83.5% (Shen et al., 2024). Its self-correction mechanism generates synthetic data, executes candidate SQL on that synthetic database, compares outputs to expected results, and then refines the query using human-crafted tips about joins, grouping, extrema, and case handling (Shen et al., 2024). For PM deployment, the practical lesson is that execution-guided repair can substitute for brute-force model scaling.

SEA-SQL pursues a similar goal under stronger cost constraints. It combines a semantic-enhanced schema, an Adaptive Bias Eliminator, and Dynamic Execution Adjustment, and reports that in the GPT-3.5 setting it achieves state-of-the-art performance with 9%-58% of the generation cost, while remaining comparable to GPT-4 with only 0.9%-5.3% of the generation cost (Li et al., 2024). On BIRD dev, removing the semantic-enhanced schema drops overall execution accuracy from 56.13% to 29.79%, which indicates that schema augmentation with representative values is not merely auxiliary but central to robust SQL generation in large, noisy databases (Li et al., 2024).

RSL-SQL focuses specifically on robust schema linking under large-schema pressure. It combines bidirectional schema linking, contextual information augmentation, binary selection strategy, and multi-turn self-correction, achieving 94% strict recall while reducing the number of input columns by 83%; with GPT-4o it reports 67.2% on BIRD and 87.9% on Spider (Cao et al., 2024). The paper’s central argument is that schema linking is useful only if the positive effects of simplification outweigh the damage done by omitting necessary elements or distorting database structure, and its full-mode versus simplified-mode voting mechanism is designed precisely to hedge this trade-off (Cao et al., 2024).

Open-model work reaches similar conclusions from a different angle. SQLfuse combines schema mining, schema linking, SQL generation, and a SQL critic module, and reports 85.6% execution accuracy on Spider while being deployed by Ant Group in “seven business contexts including the largest online analytical processing (OLAP) and transaction processing (OLTP) platforms within the company” (Zhang et al., 2024). MSc-SQL, by contrast, uses multiple small open-source generators and a multi-sample critiquing model that evaluates candidate SQL together with execution metadata; it reaches 65.6% execution accuracy on BIRD Dev and 84.7% on Spider 1.0 Test (Gorti et al., 2024). The shared principle is that robust Text-2-SQL-4-PM increasingly resembles a committee or control system: generate, execute, critique, and re-rank.

5. Multilingual and enterprise-grade requirements

Project-management systems are rarely monolingual, and the multilingual literature shows that this difficulty is structural rather than cosmetic. MultiSpider 2.0 extends Spider 2.0 to eight languages—English, German, French, Spanish, Portuguese, Japanese, Chinese, and Vietnamese—covering 5,056 NL–SQL pairs over 200 enterprise databases, with 632 examples per language and SQL dialects split across BigQuery: 33.86%, Snowflake: 31.33%, and SQLite: 34.81% (Pham et al., 29 Sep 2025). On this benchmark, state-of-the-art reasoning-only LLMs reach only about 4% execution accuracy, whereas a collaboration-driven language-agent baseline raises this to 15% (Pham et al., 29 Sep 2025). The paper’s conclusion is that multilingual, enterprise-grade text-to-SQL remains far from deployment quality.

The system-level response in that work is COLA, a collaborative architecture with a Classifier, Analyzer, and Corrector. The Classifier partitions a large database into smaller relevant sub-databases, the Analyzer decomposes a complex natural-language query into step-wise reasoning and SQL, and the Corrector executes SQL, observes syntax or runtime errors, and iteratively revises the query (Pham et al., 29 Sep 2025). The same paper reports that non-English languages show an average absolute drop of about 6.1% compared to English, and attributes the gap to English-skewed training data, tokenization and script issues, and code-switching with localized schema content (Pham et al., 29 Sep 2025). For PM products, this means that “translate the UI” is not a sufficient multilingual strategy.

Arabic results reinforce the point. Ar-Spider is the first Arabic cross-domain text-to-SQL dataset, with 9,691 questions over 166 databases; its best Arabic baseline, LGESQL + XLM-R, reaches 65.57% exact match, and the proposed context similarity relationship (CSR) approach raises this to 66.63%, reducing the Arabic–English gap to 7.73% (Almohaimeed et al., 2024). The paper explicitly identifies two challenges: schema linguistic difficulty, because user questions are in Arabic while schemas remain in English, and SQL structural difficulty, because Arabic morphology and syntax complicate mapping to SQL operators (Almohaimeed et al., 2024). For globally deployed Text-2-SQL-4-PM systems, multilinguality therefore requires schema-aware localization, cross-lingual schema linking, and robust handling of code-switched values and identifiers.

6. Domain adaptation, evaluation practice, and PM deployment patterns

Specialized domains require specialized data. SQLsynth addresses this with a human-in-the-loop text-to-SQL annotation system featuring schema visualization, sandbox database population, PCFG-based SQL generation, question generation and alignment, error detection and repair, confidence scoring, and diversity analysis (Tian et al., 21 Feb 2025). In a within-subjects study, SQLsynth achieves 95.56% overall accuracy, compared with 65.61% for manual annotation and 72.93% for ChatGPT-based annotation, while producing 8.75 pairs in 5 minutes versus 2.0 manually and 3.75 with ChatGPT (Tian et al., 21 Feb 2025). In PM contexts, where schema evolution and organizational terminology are continuous, this kind of annotation infrastructure is not peripheral; it is the mechanism by which a system remains aligned with its database and its users.

Evaluation practice also changes under PM and enterprise constraints. The TSO paper notes that some Spider “errors” arise from inconsistent DISTINCT, wrong handling of NULLs, misaligned domain terminology, type errors, ambiguous IDs vs human-readable names, and ties in aggregations not handled (Zhang et al., 26 Aug 2025). MultiSpider 2.0 emphasizes that EX and Pass@N are often more product-relevant than exact-match string comparison because they measure whether the right answer is returned, not whether the SQL matches a reference surface form (Pham et al., 29 Sep 2025). These observations are directly applicable to project-management analytics, where multiple SQLs may be semantically equivalent and where schema documentation, casting conventions, and business semantics often dominate syntactic exactness.

Agentic enterprise frameworks extend this line of work. The SSEV pipeline in “LLM-Based SQL Generation: Prompting, Self-Refinement, and Adaptive Weighted Majority Voting” reports 85.5% execution accuracy on Spider 1.0-Dev, 86.4% on Spider 1.0-Test, and 66.3% on BIRD-Dev, while ReCAPAgent-SQL reaches 31% execution accuracy on the first 100 queries of Spider 2.0-Lite by coordinating planning, external knowledge retrieval, critique, action generation, self-refinement, schema linking, and result validation through multiple specialized agents (Yang et al., 25 Jan 2026). The same work formalizes deterministic and randomized weighted-majority aggregation for SQL experts, which is a natural fit for PM deployments that combine multiple model families, dialect handlers, or policy-constrained generators (Yang et al., 25 Jan 2026). A plausible implication is that mature Text-2-SQL-4-PM systems will look less like a single model endpoint and more like an orchestrated control plane over models, retrievers, validators, and execution environments.

Taken together, the literature frames Text-2-SQL-4-PM as a convergence field. It begins with natural-language-to-SQL, but in realistic project-management settings it expands to schema curation, domain adaptation, multilingual localization, query-plan generation, execution-guided repair, analytics operators beyond relational algebra, and agentic coordination. The underlying trajectory is clear: the more closely a system approaches real PM data and real enterprise workflows, the less viable one-shot text-to-SQL becomes and the more central planning, retrieval, critique, validation, and continuous dataset construction become (Zhang et al., 26 Aug 2025, Tian et al., 21 Feb 2025, Yang et al., 25 Jan 2026).