This project was an exercise in building the whole LLM system, not wrapping a chat interface around a hosted model. I prepared the training data, fine-tuned an open model, built a retrieval pipeline and deployed each application layer to the platform that suited it.
- Model
- Qwen3-4B
- Knowledge base
- 500+ medical articles
- AI approach
- Fine-tuning with RAG
- Deployment
- Vercel, Fly.io and RunPod
The experiment
What changes when you own the model layer?
I wanted to understand the work hidden beneath a polished AI feature. Using House, M.D. episode transcripts as the domain material, I fine-tuned Qwen3-4B with Unsloth on Google Compute Engine and served it through a private endpoint on RunPod.
The fictional framing made the output easy to evaluate: the system needed a recognisable conversational style while still having access to external medical context.
Retrieval
Give the model context it was never trained to recall
I processed and vectorised more than 500 medical Wikipedia articles into Pinecone. At runtime, Gemini supports context-aware retrieval so the application can assemble relevant reference material before generating a response.
Fine-tuning shaped the voice. Retrieval supplied the situational knowledge. The application needed both.
Delivery
A model is only one part of the product
The Next.js frontend runs on Vercel, the FastAPI backend on Fly.io and the private inference endpoint on RunPod. The boundaries made deployment concerns visible: request latency, service availability, credentials and the contract between the user-facing app and specialised infrastructure.
If I extend this case study, this is where I would add model evaluations, latency measurements and examples of retrieval failures. Those would turn a working technical demonstration into a stronger account of system quality.