シカゴ犯罪データを自然文で検索するSQLエージェント
An Iterative LangGraph Agent for Text-to-SQL: Natural Language Access to the Chicago Crime Database
この論文をやさしく読む
ひとことで言うと
自然文の質問をSQLに変え、シカゴ犯罪データベースで実行して結果を説明する仕組みを評価した研究。
何に役立つ？
データベースを自然文で検索する仕組みの設計や、プロンプトの変更が結果にどう影響するかの検討に役立つ。
この研究の面白いところ
LIMIT 10という指示が複数行の回答を切り詰めていたことを見つけ、その削除が改善の最大要因になったと報告している。
どこまで分かった？
評価は手作りの100問、単一モデル、同じエージェントの2版の比較である。外部システムや公開ベンチマークとの比較はない。
v1のアブストラクトに基づくAI解説。日本語訳とは別に、用途の解釈を含みます。
アブストラクトの日本語訳
SQLを書けない非技術職の利用者は、業務データベースから必要な情報を取り出しにくい。本研究では、この問題に対応する自然文からSQLへの変換エージェントを構築・評価した。6ノードの LangGraph StateGraph が、質問の関連性の判定、稼働中のスキーマの取得、PostgreSQL文の生成、試行実行による検証、失敗時の再試行、クエリの実行、結果集合の平易な英語での説明を順に行う。エージェントはプロンプトの工夫だけを用い、モデルの微調整はしていない。 約850万件・22属性のシカゴ犯罪データを対象に、正解SQLを備えた手作りの自然文質問100件で評価した。内訳は易30件、中40件、難30件である。同じエージェントの2つのプロンプト改訂版を比較すると、改訂版V2は有効なSQLの割合が87%から93%に、関係的な同値性を組み込んだ複合指標による実行正確度が47%から60%に上がった。厳密なJSON一致では12%から19%、結果の説明品質の平均は5点満点中3.91から4.34に上がった。最大の改善要因は、複数行の回答を切り詰めていたシステムプロンプト中の LIMIT 10 指示を削除したことだった。 残る失敗の原因として、関連性判定器による誤った却下、質問の意味の曖昧さ、無料枠APIの回数制限を挙げており、言語生成部分が主因ではないとしている。外部のベースラインシステムや公開ベンチマークとの比較は報告していない。単一モデルを用いた工学的な評価である。
v1の要旨から自動生成。本文の精読・人による確認は未実施。
- 初稿
- 2026-09-19（UTC）
- 最新改訂
- 2026-09-19 · v1
- 査読・掲載
- 査読状況未確認
更新履歴
- v1 2026-09-19 この版を読む
取得できた版を表示。版の更新は査読済みを意味しません。過去版の本文差分は未解析です。
原文の要旨
Non-technical stakeholders frequently cannot write the SQL needed to extract insights from operational databases. We built and evaluated a Text-to-SQL agent that closes this gap end to end: a six-node LangGraph StateGraph checks question relevance, fetches the live schema, generates PostgreSQL, validates it with a dry run, retries on failure, executes the query, and narrates the result set in plain English. The agent uses prompt engineering only; no model was fine-tuned. We evaluated it on the Chicago Crime dataset (approximately 8.5 million records, 22 attributes) against a hand-built benchmark of 100 natural language questions with ground-truth SQL, stratified into 30 Easy, 40 Medium and 30 Hard items. Comparing two prompt revisions of the same agent, the revised system (V2) reached a Valid SQL Rate of 93% (from 87%), an Execution Accuracy of 60% under a hybrid relational equivalence metric (from 47%; 19% from 12% under strict JSON matching), and a mean Synthesis Quality of 4.34 out of 5 (from 3.91). The single largest driver was removing a LIMIT 10 instruction from the system prompt, which had been truncating multi-row answers. Error analysis attributes the residual failures to relevance-checker false rejections, ambiguous question semantics, and free-tier API rate limits rather than to the language generation step. We report no comparison against an external baseline system or a public benchmark; the study is a single-model engineering evaluation.
arXiv ID: 2609.22917 ／ 要約の誤りについて