Introduction

Fine Tuining is an end-to-end educational fine-tuning project built around Qwen/Qwen3-0.6B. It is designed to turn educational PDF material into a locally runnable AI study assistant. The pipeline accepts PDFs containing content from areas such as philosophy, mathematics, computer science, and physics, extracts the text, cleans and normalizes it, converts it into supervised chat-style examples, tokenizes those examples with the Qwen3 chat template, fine-tunes the base model using PEFT/LoRA on CPU, merges the adapter with the base model, and prepares the result for deployment through Ollama.

The goal of this project is not to build a replacement for a teacher, textbook, or verified academic source. Instead, it is a practical demonstration of how a very small language model can be specialized for educational explanation tasks on modest hardware. Qwen3-0.6B is lightweight, fast, and easy to run locally, which makes it useful for experimentation, offline study support, and understanding the full lifecycle of a fine-tuned model: data extraction, dataset construction, tokenization, training, evaluation, merging, conversion, and local deployment.

A key clarification for this project is the model identity. This project uses Qwen/Qwen3-0.6B. The earlier label qwen3.5:0.8b was inaccurate. The trained checkpoint is Qwen3-0.6B, not Qwen3.5-0.8B. This distinction matters for reproducibility, evaluation, and anyone comparing the model against other checkpoints.

What the Project Does

At a high level, the project performs the following work:

• Extracts text from educational PDFs into page-level JSON.
• Cleans the extracted text and normalizes paragraphs.
• Builds supervised user/assistant chat examples in JSONL format.
• Applies the Qwen3 tokenizer and chat template to produce token IDs.
• Fine-tunes the base Qwen3-0.6B model with a LoRA adapter on CPU.
• Saves both the LoRA adapter and a merged Hugging Face model.
• Supports evaluation on held-out examples.
• Converts the merged model to GGUF for Ollama deployment.
• Allows the resulting model to be run locally and optionally published through an Ollama account.

The project is deliberately transparent. Every major stage produces an artifact that can be inspected, rebuilt, or replaced. The PDFs are treated as source inputs, while the raw, cleaned, processed, tokenized, adapter, merged, and GGUF outputs are generated artifacts. Most of these generated files are excluded from Git because they can be rebuilt from the original PDFs, though rebuilding may take time, disk space, or network access.

Pipeline Overview

The data pipeline has four preparation stages followed by CPU fine-tuning.

1. PDF extraction
   PDFs placed in the input directory are read and converted into page-level JSON. This preserves the connection between extracted text and its source page, which is useful for metadata and later review.

2. Text cleaning
   The extracted JSON is normalized. Paragraphs are cleaned and standardized so that the later dataset stage receives more consistent text.

3. Training dataset creation
   Cleaned page text is split into paragraphs. Very short paragraphs are skipped, and the remaining text is converted into JSONL chat examples. Each example contains a user message and an assistant message.

4. Tokenization
   The configured model tokenizer is applied to the chat examples. The Qwen3 chat template is used, and each example is truncated to a short maximum sequence length. The tokenized dataset is cached so training can consume it efficiently.

5. Fine-tuning
   The base model is loaded and trained with a PEFT LoRA adapter. The adapter is saved, then merged with the base model to produce a complete Hugging Face model directory.

6. Evaluation
   The merged model can be scored on held-out JSONL examples. The evaluator reports likelihood-based metrics and exact-match generation metrics, and it saves predictions for qualitative review.

7. Deployment preparation
   The merged model can be converted to GGUF format and imported into Ollama. The included Modelfile is intended to point at the converted GGUF model.

Dataset Design and Learning Objective

Each generated training record follows a chat-style structure with a user message, an assistant message, and metadata. The user message asks the model to explain a piece of educational content clearly. The assistant target is the same paragraph that was used to build the example.

This means the training objective is primarily a basic reconstruction task. The model learns to reproduce or restate educational paragraphs in a helpful explanatory format. This is useful for teaching tone, formatting, and paragraph-level explanation behavior, but it does not create independent question-answer pairs, and it does not verify factual accuracy.

For a stronger educational assistant, the dataset would need to be redesigned. Instead of copying paragraphs, a better dataset might include:

• Real questions with verified answers.
• Step-by-step mathematics solutions.
• Physics problems with units and sign conventions.
• Computer science explanations with code and complexity analysis.
• Philosophy prompts that compare arguments, identify assumptions, and avoid false attribution.
• Socratic hints, misconceptions, and corrections.
• Examples where the model says “I don’t know” or recommends verifying with a source.

Because the current dataset is paragraph-based, users should review the generated examples before training if they want a different learning objective.

Training Approach

Training is intentionally configured for CPU-only use. This makes the project accessible on machines without a dedicated GPU, but it also means training is slow and sensitive to available memory.

The training configuration uses:

• Base model loaded in float32 on CPU.
• LoRA with rank 16, alpha 32, and dropout 0.05.
• Attention and MLP projection modules as LoRA targets.
• One epoch of training.
• Batch size 1 with gradient accumulation of 8.
• A short maximum sequence length.
• Non-reentrant gradient checkpointing to reduce activation memory.
• Disabled fp16/bf16 and pinned-memory data loading.
• BOS/EOS/PAD IDs aligned with the tokenizer before training.

This setup reduces memory pressure, but it does not eliminate the risk of an operating-system out-of-memory kill. If the training process is terminated with Killed, it is usually because the system ran out of memory. On memory-constrained machines, increasing sequence length or batch size is not recommended.

Evaluation Details

Evaluation must use examples that were not included in the model’s training data. The current project does not automatically create a held-out split, so a separate evaluation file is needed. That file should use the same message format as the training data and should end with a reference assistant answer.

The evaluator can report:

• Mean negative log-likelihood for reference answer tokens.
• Perplexity for reference answer tokens.
• Normalized exact-match rate for greedy generated answers.
• Saved predictions containing both reference and generated answers.

Exact match is a strict copying metric. It is not a measure of semantic equivalence, and it should not be treated as a complete measure of educational quality. Perplexity should also be interpreted carefully because this project’s training objective is paragraph reconstruction rather than open-ended question answering.

A useful comparison is to evaluate both the fine-tuned model and the original base checkpoint on the same held-out file. This helps show whether fine-tuning improved the desired behavior or simply changed the model’s output style.

Outputs Produced by the Project

Successful training and preparation can produce:

• A LoRA adapter directory containing the trained adapter and tokenizer files.
• A merged Hugging Face model directory containing the base model with the adapter merged in.
• A GGUF file converted from the merged model for use with Ollama.
• Evaluation summaries and prediction files for review.

The LoRA adapter alone is not a complete model. It must be merged with the base model before conversion and deployment. The merged model is the correct source for GGUF conversion.

Generated model files, tokenized datasets, and intermediate outputs are generally excluded from Git. The original PDFs are source inputs and should not be treated as disposable build output. If generated artifacts are deleted, they can usually be rebuilt, but rebuilding may require significant time, memory, disk space, or network access.

Deployment Overview

Deployment is intended to happen through Ollama. Ollama imports GGUF models, and the included Modelfile is designed to point at the converted GGUF file. The model can then be run locally and, if desired, published under an Ollama account so other users can pull it.

On Windows, importing a Safetensors directory directly into Ollama may fail because Ollama can report that the MLX runtime is unavailable. In that case, the correct approach is to convert the merged Hugging Face model to GGUF first and point the Modelfile at the resulting .gguf file. Ollama imports GGUF as provided, so the conversion step is important for Windows compatibility.

Ollama’s local API is available while its service is running, which allows the model to be used by local applications in addition to the command-line interface.

Intended Use

This project is intended for:

• Local educational experimentation.
• Offline study support.
• Demonstrating a full PDF-to-model fine-tuning pipeline.
• Testing how a small model behaves after domain-specific LoRA training.
• Learning about tokenization, chat templates, PEFT, GGUF conversion, and Ollama deployment.

It is not intended for:

• High-stakes academic or professional decisions.
• Replacing verified textbooks, teachers, or peer review.
• Advanced mathematical proofs without verification.
• Nuanced philosophical claims without source checking.
• Reliable factual recall across large domains.

Because Qwen3-0.6B is very small, it has limited reasoning capacity and may hallucinate. Fine-tuning on educational paragraphs can improve style and formatting, but it does not guarantee factual accuracy. For stronger results, the model should be combined with retrieval-augmented generation, calculators, Python execution, or other external tools.

Useful Notes and Limitations

• CPU fine-tuning is slow, and memory exhaustion can terminate the process.
• Tokenized cache mismatches can cause index errors; rebuilding and validating the tokenized data resolves this.
• Windows users should convert to GGUF before importing into Ollama.
• PyTorch deprecation warnings are not necessarily training failures.
• Review the generated dataset before training if you need independent question-answer examples.
• Always evaluate on held-out data.
• Keep evaluation separate from training data.
• Treat exact match as a strict copying metric, not a semantic quality score.
• Interpret perplexity in the context of the paragraph-copy training objective.
• Do not increase sequence length or batch size on a memory-constrained machine.
• The model is experimental and should be used with verification.