Garage Brain: An Open Model Fine-Tuned to Turn My Friend's Car and Bike Knowledge Into a Buying Advisor

Sahil Nagpure — Mon, 05 Oct 2026 01:55:32 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

My friend, can tell you the torque figure of a bike that launched last month, why one hatchback feels better than its spec sheet suggests, and which ₹2 lakh motorcycle you should buy if you hate vibrations. He watches reviews constantly, rides and drives a lot, and gets excited about every new launch.

The problem is that all of that knowledge lives in his head and in a hundred browser tabs. People keep asking him, "What should I buy?", and the answer depends on whatever he happens to remember that day.

So I built Garage Brain: a personal knowledge base of the cars and bikes he's tested or researched, with a buying advisor on top.

He feeds it text: a video transcript, an article, or his own notes.
A model turns it into a structured spec card: engine, power, torque, weight, price, mileage, pros, cons, who it's for.
He reviews and approves each card. Nothing reaches the advisor until he's checked it.
Anyone can ask a question like "bike under ₹2 lakh for city commuting plus weekend highway rides" and get a ranked answer. It uses only vehicles in his collection, with trade-offs for each pick.

The advisor can't recommend a bike he's never looked at, and it can't invent a horsepower figure, because everything comes from his approved cards.

Demo

garage-brain.onrender.com

Code

SahilNagpure07 / GarageBrain

Garage Brain

A personal car and bike knowledge base with a buying advisor, built for one enthusiast Open-weight Qwen3-8B (LoRA fine-tuned with Tinker), open embeddings (bge-small) MongoDB Atlas, FastAPI, deployed on Render.

How it works

In /admin, paste a transcript, article, or note. The fine-tuned Qwen3-8B extracts a JSON spec card (any spec not stated in the text = null).
The owner reviews and corrects the card, then approves it. Corrections are stored.
A visitor asks, e.g., "₹2L bike for city + occasional highway" on the public page. The base Qwen3-8B parses the request into filters, MongoDB applies hard constraints (type, price), embeddings rank the rest by fit, and the model explains the top picks using only the saved notes.
/api/export-training turns approved cards into new training data, so you can retrain v2.

Which model does what

Step	Model
Card extraction (admin)	Qwen3-8B + our LoRA (fine-tuned on Tinker)

…

View on GitHub

How I Built It

The idea: fine-tune for a skill, retrieve for knowledge.

My first instinct was to train the model on my friend's opinions. I changed my mind because a small fine-tune is good at learning formats and habits and poor at memorizing facts. A model with the facts baked in couldn't tell what my friend said from what it half-remembers from the internet. It also couldn't be updated without retraining.

So the pipeline splits the work:

Extraction (fine-tuned). I trained Qwen3-8B with LoRA on Tinker to turn messy text into a strict JSON card. The key lesson I wanted it to learn is that any spec not stated in the text must be null, never guessed. Auto-captions garble names ("Duke" becomes "duck"), prices come in lakhs, and reviews ramble. The tuned model has to cope with all of that.
Storage. Approved cards go into MongoDB with an embedding of their pros, cons and verdict.
Advice (base model plus retrieval). For a question, the base model parses it into filters (type, budget). MongoDB applies those as hard constraints, because numeric limits shouldn't be left to an LLM. The embeddings rank the remaining candidates, and the model explains the top picks using only the cards it's handed.
A feedback loop. Every correction my friend makes in the review screen can be exported as new training data for the next version.

Why Does Open Innovation Matter?

1. I could fine-tune the model for exactly the behavior I needed.
The most important property of this app is that the model says "I don't know" (null) instead of making up a number. Prompting a closed model for that is a hope. Fine-tuning an open-weight model on examples that reward null made it a habit, and I could measure the difference.

2. His knowledge stays in a database he controls.
The collection of cards lives in my MongoDB, in plain JSON he can read, export and correct. It isn't locked inside a chatbot's memory. The advisor is grounded in it, so if he disagrees with an answer, he fixes the card.

3. I can swap the model without losing the work.
The training data, schema and evaluation script don't depend on one model. When a better open model appears, I can retrain on the same examples and compare it against today's numbers in the same table.

4. The weights are mine.
Tinker handles the GPU work, but the result is a LoRA adapter on an open model, not a rented behavior behind an API.

Prize Categories

Best Use of Render: the web app and API run as a Render web service, deployed from a render.yaml Blueprint.
Best Use of Tinker: the LoRA fine-tune of Qwen3-8B and the sampling client both run on Tinker.
Best Use of MongoDB Atlas: all approved spec cards, their embeddings, and the review status live in Atlas. The advisor uses it for hard filters (vehicle type and budget) before ranking by embedding similarity. It also stores the corrections that become training data for the next model version.

DEV Community: Sahil Nagpure