File size: 4,129 Bytes
53d3799
 
 
 
 
 
4f73277
 
53d3799
 
 
 
4f73277
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
---
title: Trace RAG
emoji: πŸŒ–
colorFrom: red
colorTo: red
sdk: gradio
sdk_version: 5.9.1
python_version: '3.11'
app_file: app.py
pinned: false
---

# Text-to-SQL Trace RAG β€” Prototype (Gradio / HF Spaces)

A minimal prototype of **reasoning-trace RAG** applied to retail BI queries.

Instead of retrieving documents/facts, this retrieves **verified past
question β†’ SQL β†’ reasoning examples** and uses them as few-shot patterns
to guide new SQL generation. Built for repeat-shaped BI questions
("total X by Y for period Z", "top N by metric", "compare A vs B").

Runs as a **Gradio app** β€” deploys directly on HuggingFace Spaces'
free Gradio SDK. (Docker Spaces are no longer free on HF, so this
version drops the Dockerfile entirely.)

## How it works

1. `TRACE_LIBRARY` holds verified past questions with their correct SQL
   and the reasoning steps that produced it.
2. Each question is embedded with `sentence-transformers` and indexed in
   FAISS.
3. A new question is embedded, FAISS retrieves the most structurally
   similar past example(s).
4. Those examples are inserted into the prompt as exemplars β€” the model
   (via Groq) reuses the query-building *pattern*, not just column names.
5. The generated SQL runs against a DuckDB table and returns real results.
6. A second tab lets you manually confirm a generated query was correct
   and add it back into the trace library β€” this is how the library
   compounds over time.

This is the same retrieve β†’ augment β†’ generate mechanism as normal RAG.
The only difference is what gets indexed: solved query patterns instead
of documents.

## Files

- `app.py` β€” Gradio app (toy DuckDB table + FAISS index + Groq generation
  + UI to grow the trace library)
- `requirements.txt` β€” pinned dependencies (includes `gradio`)
- `README.md` β€” this file

## Run locally

```bash
pip install -r requirements.txt --break-system-packages
export GROQ_API_KEY=your_key_here
python app.py
```

Opens at `http://127.0.0.1:7860`.

## Deploy on HuggingFace Spaces (free, no Docker)

1. Create a new Space β†’ SDK: **Gradio** (not Docker).
2. Upload `app.py` and `requirements.txt` to the Space repo (matches
   your usual HF Spaces deployment pattern).
3. Go to **Settings β†’ Repository secrets** on the Space and add:
   - `GROQ_API_KEY` = your Groq key
4. Space builds automatically and launches `app.py`.

No Dockerfile needed β€” Spaces installs `requirements.txt` and runs
`app.py` directly on the Gradio SDK runtime.

## Making this real (not a toy)

1. **Replace the toy `sales` table** in `app.py` with a real extract of
   your actual schema (or connect DuckDB to your real source instead of
   the in-memory `CREATE TABLE` block).
2. **Replace `TRACE_LIBRARY`** with your team's actual most-common BI
   question shapes. Hand-verify the correct SQL for each entry before
   adding it β€” a wrong example teaches the model a wrong pattern, which
   is worse than no example at all.
3. **Use the "Add verified example" tab** as the feedback loop: after a
   generated query is confirmed correct, add it there so future similar
   questions benefit. Note the library currently resets on app
   restart (it's in-memory) β€” for a persistent version, write
   `TRACE_LIBRARY` to a small JSON file or SQLite table on add, and load
   it on startup, instead of keeping it as a plain Python list.
4. **Don't force-fit this everywhere.** This pattern only earns its
   complexity on repeat-shaped analytical/diagnostic questions. For
   fact-lookup use cases (order status, policy answers β€” e.g. Reem),
   plain document RAG is the right tool; this adds nothing there.

## Caveats

- The trace library needs *coverage of distinct question shapes*, not
  raw volume β€” a few dozen verified examples covering your real question
  patterns will outperform hundreds of near-duplicates.
- Never auto-add unverified traces to the library; incorrect examples
  compound into worse output over time, not just missing info.
- In-memory `TRACE_LIBRARY` resets every time the Space restarts/sleeps
  on the free tier β€” fine for a prototype demo, not for production use.