Hugging Face's logo

misbah-dev
/
trade-parse-qlora

MLX
qlora
lora
trading
structured-output
Model card Files
xet
 Community
trade-parse-qlora
File size: 3,920 Bytes
78fbf0e
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
66ac9a2
78fbf0e
 
 
66ac9a2
78fbf0e
66ac9a2
 
 
 
 
 
 
78fbf0e
66ac9a2
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6f398b0
 
 
 
 
 
 
 
 
 
 
66ac9a2
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
78fbf0e
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
---
base_model: mlx-community/Qwen2.5-1.5B-Instruct-4bit
tags:
- qlora
- lora
- mlx
- trading
- structured-output
license: apache-2.0
---

# TradeParse-QLoRA

QLoRA adapter for **Qwen2.5-1.5B-Instruct (4-bit, MLX)**, fine-tuned to convert natural language trade instructions into structured, schema-validated JSON.

**Example**

Input: `"Buy Reliance if it drops below 2800, sell above 3000, intraday"`

Output:
```json
{
  "symbol": "RELIANCE",
  "action_conditions": [
    {"trigger": "price_below", "value": 2800, "action": "buy"},
    {"trigger": "price_above", "value": 3000, "action": "sell"}
  ],
  "strategy_type": "intraday"
}
```

## Technique

- **Base model**: `mlx-community/Qwen2.5-1.5B-Instruct-4bit`
- **Method**: QLoRA (LoRA adapters trained on top of a 4-bit quantized base) via `mlx-lm`, chosen for feasible memory usage on Apple Silicon
- **Training data**: synthetic instruction → JSON pairs, including normal trade parses and structured error cases for missing/ambiguous information

## Eval results

V2 adapter eval on 240 generated validation examples:

| Metric | Result |
|---|---:|
| Valid JSON | 100.00% |
| Schema valid | 100.00% |
| Success exact match | 92.08% |
| Error exact match | 68.42% |
| Overall exact match | 88.33% |

The split matters: success exact match is measured over trade-parse cases only, while error exact match is measured over invalid/ambiguous instruction cases only.

## Three representative cases

### 1. Correct trade JSON

Input:

```text
Buy Infosys if it drops below 1500, sell above 1700, intraday
```

Expected/model output:

```json
{
  "symbol": "INFY",
  "action_conditions": [
    {"trigger": "price_below", "value": 1500, "action": "buy"},
    {"trigger": "price_above", "value": 1700, "action": "sell"}
  ],
  "strategy_type": "intraday"
}
```

This shows the normal target behavior: company-name normalization, two price conditions, and strategy extraction.

### 2. Correct structured error

Input:

```text
Buy ONGC when it's cheap, sell when it's expensive
```

Expected/model output:

```json
{
  "error": "missing_price_condition",
  "symbol": "ONGC",
  "message": "No numeric price condition found."
}
```

This should not be force-parsed. The instruction has a symbol and actions, but no concrete price levels.

### 3. Known wrong / limitation case

Input:

```text
buy this stock below 500, sell above 600, futures
```

model output:
```json
{
  "symbol": "AAPL", 
  "action_conditions": [
    {"trigger": "price_below", "value": 500, "action": "buy"}, 
    {"trigger": "price_above", "value": 600, "action": "sell"}], 
  "strategy_type": "futures"
}
```

Expected output:

```json
{
  "error": "missing_symbol",
  "symbol": null,
  "message": "No symbol or company name found."
}
```

This is a useful failure case to track. The model may produce valid-looking trade JSON even though the instruction never identifies which stock to trade. In a real trading workflow, this should be rejected or sent back for clarification.

**Known failure modes:**
- Vague price language like "cheap" or "expensive" requires a structured error unless another price-resolution system exists.
- Missing-symbol instructions can still tempt the model to hallucinate a symbol.
- Error-case accuracy is lower than normal trade parsing, so negative/error examples need more data and harder evaluation.

## Usage

Requires the base model + this adapter loaded together via `mlx-lm`:

```python
from mlx_lm import load, generate

model, tokenizer = load(
    "mlx-community/Qwen2.5-1.5B-Instruct-4bit",
    adapter_path="path/to/downloaded/adapter"
)
```

Full code, training data generation script, and eval scripts: [GitHub repo](https://github.com/Misbah-Asif/trade-parse-qlora)

## Scope

This is a translation layer (natural language → structured JSON), not a trading execution engine. Output is intended to be consumed by a downstream order/strategy system.