# System Prompts & LLM

**URL:** </static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fsystem-prompts-llm%2F173290%3E%5C
**Category:** Models\
**Created:** [February 10, 2026, 2:36pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fsystem-prompts-llm%2F173290 "2026-02-10T14:36:20Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rahulprasadh03](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/rahulprasadh03/32/57885_2.png) [@Rahulprasadh03](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FRahulprasadh03)%5C
**Post date:** [February 10, 2026, 2:36pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fsystem-prompts-llm%2F173290%2F1 "2026-02-10T14:36:20Z")

</div>

Hi everyone,

I’m currently building an AI chatbot that converts natural language user queries into accurate SQL queries, executes them on a database, and returns the results in a simple, readable format.

At the moment, I’m using Qwen 30B locally and Groq’s LLaMA 70B for online inference.

I’d like to know:

- Which LLM models work best for text-to-SQL and analytics use cases like this?

- Which platforms or communities provide reliable system prompts, best practices, or examples that can be integrated into a Python-based implementation?

Any suggestions, resources, or real-world experiences would be greatly appreciated.  
Thanks in advance!

---

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [February 11, 2026, 8:39am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fsystem-prompts-llm%2F173290%2F2 "2026-02-11T08:39:24Z")

</div>

> Which LLM models work best for text-to-SQL and analytics use cases like this?

There are quite a few [models fine-tuned for text-to-SQL](https://huggingface.co/models?sort=downloads&search=sql).

* * *

## Context: why “analytics text-to-SQL” is harder than it sounds

A production system isn’t just **NL → SQL**. The most common failure points are:

- **Schema linking:** mapping “customers”, “ARR”, “active users” to the right tables/columns in a large schema.
- **Value grounding:** using valid filter values (e.g., `region='APAC'` vs `AsiaPacific`).
- **Dialect correctness:** Snowflake vs BigQuery vs Postgres function and date semantics.
- **Workflow realism:** real analytics requests often need multi-step SQL, validation, retries, and follow-up clarification—exactly what newer benchmarks like Spider 2.0 emphasize. ([spider2-sql.github.io](https://spider2-sql.github.io/ "Spider 2.0"))

Because of this, the best systems usually combine:

1. a **SQL-specialist model** for query generation/repair, and
2. a **general model** for clarification, orchestration, and explanation.

* * *

## 1) Models that work best for your use case

### A. SQL-specialist models (recommended for the SQL step)

These are trained/tuned to output executable SQL reliably.

**Snowflake Arctic-Text2SQL-R1 family (7B/14B/32B)**

- Designed specifically for text-to-SQL with **execution-based reward** training (GRPO). ([Hugging Face](https://huggingface.co/Snowflake/Arctic-Text2SQL-R1-7B "Snowflake/Arctic-Text2SQL-R1-7B"))
- Snowflake reports top-tier BIRD results for the family (with the 32B highlighted). ([Snowflake](https://www.snowflake.com/en/engineering-blog/arctic-text2sql-r1-sql-generation-benchmark/ "Arctic-Text2SQL-R1 Tops BIRD and Wins Broadly"))  
**Why it fits:** strong “SQL actually runs and returns correct results” focus; good default if you can run 7B locally for generation + an execution-guided repair loop.

**Defog SQLCoder (e.g., `defog/sqlcoder-7b-2`)**

- Explicitly positioned for analytics querying (and explicitly warns to use **read-only** DB access). ([Hugging Face](https://huggingface.co/defog/sqlcoder-7b-2 "defog/sqlcoder-7b-2"))
- Prompt templates are commonly referenced via Defog’s evaluation repo (sql-eval). ([GitHub](https://github.com/defog-ai/sql-eval "defog-ai/sql-eval: Evaluate the accuracy of LLM generated ..."))  
**Why it fits:** widely adopted baseline; lots of community Q&A and prompt guidance.

**Distil Labs Distil-Qwen3-4B-Text2SQL (Jan 2026)**

- Recent release; a 4B text2sql model distilled from DeepSeek-V3 per the model card, plus GGUF packaging for local inference. ([Hugging Face](https://huggingface.co/distil-labs/distil-qwen3-4b-text2sql "distil-labs/distil-qwen3-4b-text2sql"))  
**Why it fits:** fast local “first pass” generator; useful if latency matters, with fallback to a stronger model when validation fails.

**SambaNova / Numbers Station SambaCoder-nsql-llama-2-70b**

- HF model card describes training specifically for text-to-SQL pairs; SambaNova’s write-up claims strong Spider execution accuracy (their reported numbers). ([Hugging Face](https://huggingface.co/sambanovasystems/SambaCoder-nsql-llama-2-70b "sambanovasystems/SambaCoder-nsql-llama-2-70b"))  
**Why it fits:** a larger SQL-specialist option if you want a single heavy model (less attractive if cost/latency is critical).

### B. General-purpose LLMs (recommended for orchestration + narration)

Your current Groq LLaMA 70B usage is well aligned for:

- asking clarifying questions,
- deciding whether to query vs explain,
- summarizing results and handling follow-ups.

Benchmarks like LiveSQLBench explicitly focus on realistic success rates and system behavior over time (and they position themselves as contamination-resistant / evolving). ([livesqlbench.ai](https://livesqlbench.ai/ "LiveSQLBench"))  
Use this category primarily as the “product brain,” not the SQL generator.

* * *

## 2) What I would do in _your_ setup (Qwen 30B local + Groq LLaMA 70B)

### Recommended division of labor

**(1) Groq LLaMA 70B: router + clarifier + narrator**

- Decide: “ask a clarification” vs “run a query now”
- Convert result tables into a short, readable answer (no hallucinated rows)

**(2) Local SQL-specialist: generator + repair loop**

- Generate SQL-only with a strict contract
- If execution fails, repair using the DB error message

A practical local pairing:

- **Fast path:** Distil-Qwen3-4B-Text2SQL ([Hugging Face](https://huggingface.co/distil-labs/distil-qwen3-4b-text2sql "distil-labs/distil-qwen3-4b-text2sql"))
- **Accuracy path / fallback:** Arctic-Text2SQL-R1-7B ([Hugging Face](https://huggingface.co/Snowflake/Arctic-Text2SQL-R1-7B "Snowflake/Arctic-Text2SQL-R1-7B"))

### Non-negotiable safety + correctness layer (do this regardless of model)

1. **Parse and validate SQL before execution** (block DDL/DML by default, enforce allowlists)

2. **Read-only DB credentials** (SQLCoder explicitly warns about this risk). ([Hugging Face](https://huggingface.co/defog/sqlcoder-7b-2 "defog/sqlcoder-7b-2"))

3. **Timeouts + row limits** (protect warehouses; prevent “runaway” scans)

4. **Hard rule:** if the query returns 0 rows, answer “no results” (don’t let the narrator invent data)

OWASP’s LLM Top 10 is a good baseline for prompt injection and insecure output handling risks in “LLM → tool execution” apps. ([owasp.org](https://owasp.org/www-project-top-10-for-large-language-model-applications/ "OWASP Top 10 for Large Language Model Applications"))

* * *

## 3) Benchmarks/leaderboards to use (and how to interpret them)

Use multiple benchmarks because each measures different failure modes:

- **BIRD:** emphasizes correct _and efficient_ SQL; includes value/external-knowledge aspects closer to analytics. ([bird-bench.github.io](https://bird-bench.github.io/ "Bird SQL"))
- **Spider 2.0:** focuses on real enterprise workflows (large schemas, multi-step tasks, multiple systems). ([spider2-sql.github.io](https://spider2-sql.github.io/ "Spider 2.0"))
- **LiveSQLBench / BIRD-Interact ecosystem:** targets evolving, realistic tasks and interactive settings. ([livesqlbench.ai](https://livesqlbench.ai/ "LiveSQLBench"))

Important caveat: leaderboard numbers can be distorted by benchmark annotation errors; a CIDR 2026 analysis reports very high error rates on BIRD mini-dev and Spider2.0-Snow and re-evaluates top agents. ([vldb.org](https://vldb.org/cidrdb/papers/2026/p5-jin.pdf "Text-to-SQL Benchmarks are Broken: An In-Depth Analysis ..."))  
Practical implication: treat leaderboards as **shortlisting tools** , then decide using a private regression suite on your schema/KPIs.

* * *

## 4) Platforms/communities with reliable prompts, best practices, and Python-ready examples

### A. Prompt templates you can reuse directly

- **Defog sql-eval prompt templates** (commonly referenced as “the recommended SQLCoder prompt”). ([GitHub](https://github.com/defog-ai/sql-eval "defog-ai/sql-eval: Evaluate the accuracy of LLM generated ..."))
- **Anthropic prompt library (“SQL sorcerer”)**: a concrete text-to-SQL prompt pattern you can adapt even if you don’t use Claude. ([Claude](https://platform.claude.com/docs/en/resources/prompt-library/sql-sorcerer "SQL sorcerer - Claude API Docs"))

### B. Python frameworks with proven SQL-agent patterns

- **LangChain SQL Agent docs** : outlines a practical sequence (table discovery → pick relevant tables → fetch schemas → generate → double-check → execute). ([LangChain Docs](https://docs.langchain.com/oss/python/langchain/sql-agent "Build a SQL agent - Docs by LangChain"))
- **LlamaIndex SQL query engines** : examples combining structured SQL with unstructured retrieval (“auto vector” style). ([LlamaIndex](https://developers.llamaindex.ai/python/examples/query_engine/sqlautovectorqueryengine/ "SQL Auto Vector Query Engine"))
- **Hugging Face smolagents text-to-SQL example** : emphasizes why naive “single-shot SQL” is brittle and shows an agent-style approach. ([Hugging Face](https://huggingface.co/docs/smolagents/en/examples/text_to_sql "Text-to-SQL"))

### C. Provider/community cookbooks (especially relevant to your Groq usage)

- **Groq community guide: JSON mode + function calling for SQL** (predictable structured outputs; DuckDB example but transferable). ([Groq Community](https://community.groq.com/t/using-json-mode-and-function-calling-for-sql-querying/111 "Using JSON Mode and Function Calling for SQL Querying"))
- **Groq API cookbook** : includes “Text to SQL with JSON Mode” and “Verified SQL Function Calling” examples. ([GitHub](https://github.com/groq/groq-api-cookbook "groq-api-cookbook"))

### D. End-to-end open-source projects (useful for architecture patterns)

- **Dataherald** : NL→SQL engine aimed at enterprise QA over relational data. ([GitHub](https://github.com/Dataherald/dataherald "Dataherald monorepo"))
- **Vanna** : “agentic retrieval” approach for text-to-SQL, popular Python project. ([GitHub](https://github.com/vanna-ai/vanna "vanna-ai/vanna: 🤖 Chat with your SQL database ..."))
- **DB-GPT** : broader “AI native data app” framework; includes Text2SQL components and fine-tuning docs. ([GitHub](https://github.com/eosphoros-ai/DB-GPT "eosphoros-ai/DB-GPT: AI Native Data App Development ..."))

### E. Where implementation pitfalls show up first (high-signal)

- **Hugging Face model discussions** (prompt templates, chat formatting issues, dialect confusion). ([Hugging Face](https://huggingface.co/defog/sqlcoder-7b-2/discussions/16 "defog/sqlcoder-7b-2 · What would be the correct chat ..."))
- **Benchmark repos** (Spider2 tooling, “tool-call Spider-Agent”, reproducibility notes). ([GitHub](https://github.com/xlang-ai/Spider2 "xlang-ai/Spider2: [ICLR 2025 Oral] Spider 2.0: Evaluating ..."))

* * *

## 5) A concrete “minimum robust” Python design (fits your stack)

1. **Intent router (Groq 70B)**  
Output JSON: `{action: ask|query, clarifying_question?, constraints?}`

2. **Schema/value retrieval (code)**

3. **SQL generation (local SQL specialist)**  
Output **SQL only** (no markdown)

4. **SQL validation (SQLGlot + allowlists)** ([GitHub](https://github.com/tobymao/sqlglot "tobymao/sqlglot: Python SQL Parser and Transpiler"))

5. **Execute with read-only credentials + limits**

6. **Repair loop (local SQL specialist)**  
Provide DB error + minimal schema slice; retry 1–3 times

7. **Narration (Groq 70B or local Qwen 30B)**  
Summarize _only_ the returned rows; include rowcount; handle empty results deterministically.

* * *

## 6) “Best model” shortlist to try first (for your exact scenario)

- **Primary local SQL model:** Snowflake Arctic-Text2SQL-R1-7B ([Hugging Face](https://huggingface.co/Snowflake/Arctic-Text2SQL-R1-7B "Snowflake/Arctic-Text2SQL-R1-7B"))
- **Fast local first-pass:** distil-labs Distil-Qwen3-4B-Text2SQL (Jan 2026) ([Hugging Face](https://huggingface.co/distil-labs/distil-qwen3-4b-text2sql "distil-labs/distil-qwen3-4b-text2sql"))
- **Strong baseline / lots of prompt guidance:** defog/sqlcoder-7b-2 ([Hugging Face](https://huggingface.co/defog/sqlcoder-7b-2 "defog/sqlcoder-7b-2"))
- **Keep Groq LLaMA 70B for:** orchestration + clarifications + result narration (and use JSON mode / tool calling patterns). ([Groq Community](https://community.groq.com/t/using-json-mode-and-function-calling-for-sql-querying/111 "Using JSON Mode and Function Calling for SQL Querying"))