Opaque integer keys push general Text-to-SQL below 50% on financial data; FLINT adds a lookup agent to close the gap
Synopsis
FLINT, a Text-to-SQL system for production financial databases, grounds natural-language questions in question-specific table constraints instead of relying on column-name similarity. General systems do well on benchmarks like Spider and BIRD, where schemas are shallow and column values are readable, but financial databases store concepts as opaque integer keys, so even simple queries need multiple joins and those methods fall below 50%. FLINT resolves concepts with a lookup agent, retrieves structurally similar query templates, and prunes large schemas along foreign-key chains; on two datasets totaling 359 questions over production financial schemas it outperforms baselines using the same LLM, and it is deployed in a financial data retrieval service.
Interpretation
FLINT, a Text-to-SQL system for production financial databases, first grounds a natural-language question in question-specific reference table constraints before producing a query. General Text-to-SQL systems perform strongly on academic benchmarks such as Spider and BIRD, where schemas are relatively shallow and column values are often human-readable strings, but fall below 50% on financial databases that store concepts as opaque integer keys. On two datasets totaling 359 questions over production financial schemas, FLINT outperforms various state-of-the-art baselines that use the same LLM.
Three components work together: a lookup agent, query-template retrieval, and schema pruning along foreign-key chains. The lookup agent dynamically resolves natural-language concepts into question-specific reference table constraints rather than depending on name similarity. Templates come from a compact, expert-authored bank and are retrieved by embedding similarity of structure; schema linking traverses foreign-key chains to prune a large table schema to the relevant subset.
Perspective
This report draws on abstract-level information and does not cover the full paper's experimental detail. The system targets production financial databases, and evaluation covers two datasets totaling 359 questions, compared against various state-of-the-art baselines using the same LLM. The abstract states the system is deployed in production as part of a financial data retrieval service.
The abstract gives only the overall judgment that general methods fall below 50% on financial databases, without per-baseline numbers. The system relies on a compact expert-authored template bank, and the abstract does not say how template coverage affects performance.