Juhuu/slowestlooser-v2-4bit

SlowestLooser FoodJSON+Activity v2

HuggingFace: https://huggingface.co/Juhuu/slowestlooser-v2-4bit Published: 2026-05-13 Status: Active. Supersedes v1 (food-only).

What this model does

QLoRA fine-tune of mlx-community/Qwen3-1.7B-4bit that handles both the SlowestLooser food-text path AND the activity-text path. iOS routes by system prompt; the model emits the matching JSON schema.

• Food queries (system: foodAnalysisSystemNoTools): CompositeDTO JSON with items[]
• Activity queries (system: activityAnalysisSystem with embedded 40-entry MET catalog): Single object {"name", "minutes", "calories"} (multi-activity sums into one row)

Base model

mlx-community/Qwen3-1.7B-4bit (1.72B params, pre-quantized 4-bit MXFP)

Training (QLoRA via mlx-lm on M4 Pro)

Setting	Value
Method	QLoRA
Optimizer	AdamW
Iterations	1500 (vs v1's 1000)
Batch size	4
Learning rate	2e-4
LoRA rank	32
LoRA target layers	last 16 attention layers
Max seq length	2048
Trainable params	4.98M (0.29% of base)
Wall time	135 min
Peak memory	16.4 GB

Loss trajectory

Iter	Val loss	Train loss
1	2.892	—
500	0.068	0.073
1000	0.061	0.056
1500	0.046	0.047

Val loss still improving at iter 1500 — extending from v1's 1000 was worth it. v1 plateaued at val=0.053 (iter 900).

Dataset

4802 records (4321 train + 481 holdout).

Slice	Records	Share
Food	3644	84%
Activity	677	16%

Food dataset (unchanged from v1):

• 38 curated DB entries oversampled to 20 variants each
• 400 simple-label OFF entries × 4 variants
• 30% multi-ingredient queries; 60% include ≥1 curated seed

Activity dataset (new in v2):

• 40-entry curated MET catalog (daily life → endurance sports; broad → specific)
• 15 variants per activity via GPT-4o-mini synthesis (durations, intensity modifiers, Swiss German + English synonyms)
• 10% multi-activity composites
• Calorie targets computed deterministically: MET × 70kg × hours

See data/activity_catalog.json for the full 40-entry MET catalog used in both training data and the iOS system prompt.

Eval: Matrix sweep against iOS QualitySpec (real production prompts)

Real prompts mirrored from SlowestLooser/Services/QualitySpecs.swift::QualitySpec.all.

Food (39 prompts)

	Base Qwen3 1.7B	v1 FT	v2 FT
Valid JSON	1/39 (3%)	39/39 (100%)	39/39 (100%)
Avg latency	3.10s	1.69s	~2.4s

Activity (19 prompts; one empty-string prompt skipped)

	v2 FT
Valid JSON	19/19 (100%)
Avg latency	~0.7s (no DB prefetch needed)

Single-activity calorie sanity

The v2 model emits deterministic, MET-formula-correct calories:

Prompt	Output	Expected	Status
Joggen / 30 min Joggen	30min / 245kcal	7.0 × 70 × 0.5 = 245	exact
Velofahren	30min / 210kcal	6.0 × 70 × 0.5 = 210	exact
Schwimmen	30min / 280kcal	8.0 × 70 × 0.5 = 280	exact
HIIT	30min / 350kcal	10.0 × 70 × 0.5 = 350	exact
Sprinten	30min / 420kcal	12.0 × 70 × 0.5 = 420	exact
1 Stunde Velo	60min / 420kcal	6.0 × 70 × 1.0 = 420	exact
45 Minuten Schwimmen	45min / 385kcal	8.0 × 70 × 0.75 = 420	~ 9% under
2h Wandern	120min / 700kcal	5.5 × 70 × 2 = 770	~ 9% under
Spazieren	30min / 122kcal	3.5 × 70 × 0.5 = 122.5	exact

Multi-activity calorie sums

Less precise — model interpolates between known activities:

Prompt	v2 Output	Catalog-strict sum
Joggen und Schwimmen	60min / 595kcal	245 + 280 = 525
30 min Velo dann 15 min Joggen	60min / 560kcal	210 + 122.5 = 332.5

Acceptable for ship; could tighten in v3 with more multi-activity training samples.

Drift comparison (the v1 production motivation)

Activity calorie variance for "30 min Joggen" in v1.30.x production releases:

Release	Output	Source
v1.30.1	168	Base Qwen
v1.30.3	147	OpenAI (consistent across runs)
v1.30.4	140	Base Qwen
v1.30.5	110	Base Qwen — drift continued
v2 FT	245	Deterministic

v2 emits the canonical MET-formula answer (245) on every run.

Known issues

• g_wasser filtering (carried over from v1) — water entry with 0 kcal gets filtered by load_vector_index. Query "Wasser" matches "Birken Wasser" from BM25. Relax to cals < 0 in v3.
• dl unit not parsed (carried over from v1) — 1.5dl Milch embeds quantity in name. Add dl/cl to QuantityParser.
• Multi-activity calorie sum is approximate — see table above. ~12% over on tested cases. Acceptable for ship but could tighten with more multi-activity training data.
• 2h Wandern slight under-estimate — model used MET=5 instead of catalog 5.5 (700 vs 770 kcal).

Notes on design

• Design B chosen for activity MET routing: 40-entry catalog embedded in system prompt (compact Name=MET comma-separated, ~250 tokens). Avoided full RAG (Design C) — Swift-side activity matcher would have added infrastructure for a 40-entry static dataset.
• MET catalog Python ↔ Swift byte-equal: prompt.py::SYSTEM_ACTIVITY and PromptTemplates.swift::activityAnalysisSystem are intentionally byte-equal. Training prompt = production prompt = no drift.
• One combined model (vs two separate adapters): saves a download + a model load on iOS. The 1.7B has capacity for both schemas.

Commits

• Activity training + model card scaffolding: b4ee122
• 40-entry catalog + Design B compact MET prompt: 8011d10 (Python) + a6a4eef (iOS)
• v2 dataset + training: (commit hash after this docs commit)

Why retired v1

v1 was food-only. Users were typing "30 min joggen" and getting drifting calorie values (168/140/110 across releases). v2 trains one combined model on both schemas with deterministic calorie math baked in.