Rapha — Clinical AI Physician Assistant

Rapha conducts structured, empathetic clinical interviews across five stages (greeting, OPQRST symptom exploration, medical history, red-flag screening, escalation report) and hands a structured report to a physician. Rapha never diagnoses.

• Base model: unsloth/Qwen2.5-3B-Instruct-bnb-4bit
• Method: QLoRA (Unsloth) → curriculum SFT → DPO
• Chat template: ChatML
• Context window: 2,048 tokens (training)
• Trained: 2026-08-06

Training architecture (v2.6)

Single-trainer curriculum SFT: three phases concatenated into one ordered dataset with a single cosine LR schedule. DPO uses a de-duplicated preference set with a held-out validation split (by unique prompt) and a corrected stage-aware system prompt (v2.3 had a bug where every DPO example was trained under the Adversarial system prompt, regardless of its actual stage — fixed in v2.4).

Phase	Data	Purpose
1	Stage1 + Stage2	Complaint identification + OPQRST symptom detail
2	Stage3 + Stage4	Medical history + red-flag triage
3	FullArc + Adversarial	Complete session flows + safety robustness

Repo contents

Path	Contents
/ (root)	LoRA adapter (PEFT) — small, load on top of the base model
merged/	Full merged fp16 weights — standalone, no base model needed
gguf/	Quantised GGUF files (Q4_K_M, Q5_K_M, Q8_0) for Ollama / llama.cpp / LM Studio

Training data

Curriculum SFT across 6 datasets: Stage 1 greetings, Stage 2 OPQRST symptom exploration, Stage 3 medical history, Stage 4 red-flag screening, a multi-turn adversarial set (self-diagnosis, symptom denial, medication refusal, minimised red flags, prompt injection), and full-arc sessions ending in a Stage 5 handoff. Followed by DPO preference alignment on a de-duplicated, leak-safe train/val split (held out by source scenario).

Records actually used in this run (after quality filtering, de-duplication and per-stage caps): 24,000 total.

Stage	Records
Adversarial	3,000
FullArc	4,500
Stage1	4,500
Stage2	4,500
Stage3	3,500
Stage4	4,000

Clinical content provenance

The interview question policy, red-flag screening, and the Suspicions for clinician consideration section in each full-arc report are generated by a deterministic forward-chaining rule engine (clinical_rules.py), not by the source CSV — whose doctor_response column contains only 6 distinct strings across 50,000 rows and is unused. Those rules are author-specified from published triage criteria and have not been clinician-validated. Suspicions are hypotheses for a clinician to investigate, never conclusions told to the patient; Rapha still never diagnoses.

Eval metrics (last training run)

Metric	Value
empathy_rate	0.3000
escalation_accuracy	0.5000
adversarial_hold_rate	0.5000
pushback_hold_rate	0.5000
multi_question_rate	0.4500
repetition_rate	0.0000
suspicion_section_rate	1.0000
avg_response_length	42.0500

Usage — Ollama (GGUF)

ollama create rapha -f Modelfile.q4_k_m
ollama run rapha

Usage — Transformers (LoRA adapter)

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="Phora68/rapha",
    max_seq_length=2048,
    load_in_4bit=True,
)
FastLanguageModel.for_inference(model)

Safety

Rapha is an information-gathering and triage-support tool. It is not a diagnostic device and must not be deployed without physician oversight. Red-flag detection and escalation responses should be validated against the clinical accuracy benchmark before any clinical use.

---

Generated automatically by train_rapha_llm.py v2.6.