GLM-5.3 is live. Run Z.ai's latest model on Friendli Model APIs. Try it today ➜
krishna382nitjsr
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Model Details
Model Provider
krishna382nitjsr
Model Tree
Qwen/Qwen2.5-Coder-1.5B-Instruct
Input Modalities
Output Modalities
Supported Functionality
Evaluated on the benchmark's single task (same GPU, same harness, greedy
decoding). Solved = the answer's cost reduction is within 2% of the best
known index; capture = share of the best index's improvement achieved.
| Split | Model | Valid | Solved | Capture | Mean reward |
|---|---|---|---|---|---|
| test (200) | base model | 98% | 37% | 37% | +0.33 |
| test (200) | this adapter | 100% | 97% | 99% | +0.95 |
| unseen templates (163) | base model | 72% | 72% | 72% | +0.33 |
| unseen templates (163) | this adapter | 72% | 72% | 72% | +0.33 |
| test / unseen | textbook rule (equality → range/sort columns) | 100% / 100% | 90% / 66% | 98% / 96% | – |
On query shapes seen in training, the adapter beats both the base model and a
textbook rule, including cases the base model never got right, such as a
partial index (WHERE status = 'pending') for a rare status. It shows no gain
on query templates held out of training, where it repeats a syntax mistake
(unparenthesised JSONB expression keys) that no training example needed. Treat
it as specialised to the benchmark's query shapes, not a general index advisor.
Details: training_run1.md.
Raw metrics and the training log are in results/.
python
from peft import PeftModelfrom transformers import AutoModelForCausalLM, AutoTokenizerimport torch base = "Qwen/Qwen2.5-Coder-1.5B-Instruct"tokenizer = AutoTokenizer.from_pretrained(base)# float32 or bfloat16. Avoid float16: Qwen2.5 degrades badly in float16.model = AutoModelForCausalLM.from_pretrained(base, dtype=torch.float32)model = PeftModel.from_pretrained(model, "krishna382nitjsr/index-drift-rl-qwen1.5b-grpo-v0.1") system = ("You are a PostgreSQL performance engineer. You recommend B-tree indexes that make " "slow queries fast without hurting production: always use CREATE INDEX CONCURRENTLY, " "prefer the smallest index that does the job, and recommend nothing when no index would help.")user = """Schema (only primary keys are indexed):CREATE TABLE orders (id bigint NOT NULL, tenant_id integer NOT NULL, customer_id bigint NOT NULL, status text NOT NULL, total numeric(12,2) NOT NULL, created_at timestamp with time zone NOT NULL, PRIMARY KEY (id)); -- ~1,000,000 rows Slow query:SELECT id, customer_id, total, created_at FROM orders WHERE tenant_id = 7 AND status = 'pending' ORDER BY created_at LIMIT 100 Current plan (EXPLAIN):Limit -> Sort -> Seq Scan on orders Filter: ((tenant_id = 7) AND (status = 'pending'::text)) Recommend the single best index for this query. Reply with exactly one SQL statement of the form `CREATE INDEX CONCURRENTLY <name> ON <table> (...);` or the words `NO INDEX` if no index would help. Do not explain.""" messages = [{"role": "system", "content": system}, {"role": "user", "content": user}]inputs = tokenizer.apply_chat_template(messages, add_generation_prompt=True, return_dict=True, return_tensors="pt")out = model.generate(**inputs, max_new_tokens=96, do_sample=False)print(tokenizer.decode(out[0, inputs["input_ids"].shape[1]:], skip_special_tokens=True))The exact prompt format is src/prompts.py in the repository. Always review a
suggested index before running it on a real database.
| Method | GRPO (TRL 1.16), 300 steps, 2 prompts × 8 completions per step, β = 0, lr 2e-5 |
| Adapter | LoRA r = 16, α = 32, dropout 0.05, all linear layers (~18M trainable parameters) |
| Data | 600 prompts from the single/train split of index-drift-rl-bench |
| Reward | src/environment.py: share of the best index's planner-cost reduction, averaged over 4 parameter sets; −1 invalid / destructive, −0.75 rejected by PostgreSQL, −0.5 missing CONCURRENTLY or UNIQUE; size, chatter and measured-latency-regression penalties |
| Hardware | free Kaggle T4, float32, 2.8 h |
The reward plateaued at about 0.93 after roughly 100 steps.
NO INDEX.from peft import PeftModelfrom transformers import AutoModelForCausalLM, AutoTokenizerimport torch base = "Qwen/Qwen2.5-Coder-1.5B-Instruct"tokenizer = AutoTokenizer.from_pretrained(base)# float32 or bfloat16. Avoid float16: Qwen2.5 degrades badly in float16.model = AutoModelForCausalLM.from_pretrained(base, dtype=torch.float32)model = PeftModel.from_pretrained(model, "krishna382nitjsr/index-drift-rl-qwen1.5b-grpo-v0.1") system = ("You are a PostgreSQL performance engineer. You recommend B-tree indexes that make " "slow queries fast without hurting production: always use CREATE INDEX CONCURRENTLY, " "prefer the smallest index that does the job, and recommend nothing when no index would help.")user = """Schema (only primary keys are indexed):CREATE TABLE orders (id bigint NOT NULL, tenant_id integer NOT NULL, customer_id bigint NOT NULL, status text NOT NULL, total numeric(12,2) NOT NULL, created_at timestamp with time zone NOT NULL, PRIMARY KEY (id)); -- ~1,000,000 rows Slow query:SELECT id, customer_id, total, created_at FROM orders WHERE tenant_id = 7 AND status = 'pending' ORDER BY created_at LIMIT 100 Current plan (EXPLAIN):Limit -> Sort -> Seq Scan on orders Filter: ((tenant_id = 7) AND (status = 'pending'::text)) Recommend the single best index for this query. Reply with exactly one SQL statement of the form `CREATE INDEX CONCURRENTLY <name> ON <table> (...);` or the words `NO INDEX` if no index would help. Do not explain.""" messages = [{"role": "system", "content": system}, {"role": "user", "content": user}]inputs = tokenizer.apply_chat_template(messages, add_generation_prompt=True, return_dict=True, return_tensors="pt")out = model.generate(**inputs, max_new_tokens=96, do_sample=False)print(tokenizer.decode(out[0, inputs["input_ids"].shape[1]:], skip_special_tokens=True))