Fine-Tuning an LLM Based on My PhD Advisor's Publication

Large language models (LLMs) are constantly getting better. Each month seems to bring another announcement about a model surpassing someone else’s flagship system. The way these models are benchmarked is a topic that deserves its own discussion, but a useful high-level snapshot can be found on the Arena leaderboard. During this period of rapid progress and competition between AI companies, much of the improvement has come with increasing computational cost. That naturally raises the question of whether smaller models can still be useful for narrow, domain-specific tasks. This is especially relevant for agentic systems, a point also emphasized in recent work from NVIDIA researchers. With that in mind, I wanted to see how a small Llama model would behave in three settings on questions related to computational biophysics: untouched, fine-tuned, and paired with retrieval-augmented generation.

When I started this mini-project, I was never going to produce a model with broad scientific understanding. My goal was much smaller and targeted to a specific domain of theoretical chemistry.

Why try this?

Many of the current flagship models are still, for the most part, black boxes. There is limited information about the data used to train them. Consequently, it is difficult to determine how much domain knowledge an LLM already carries into a specialized task. Given that uncertainty, I wanted to see what happens when a very specific field of chemistry is used to fine-tune a model. I also wanted to see whether I could build something that might be genuinely useful for my own research.

Building the training set

For the Benoît Roux-focused model, I did not build a question-answer instruction dataset. Instead, I treated the project as a small continued-pretraining experiment on a narrow, domain-specific corpus. I assembled 40 documents in computational biophysics, including papers associated with Benoît Roux, dissertation material from former students, and selected work in statistical mechanics. Those texts were converted into a plain-text corpus that a Llama 3.2 model could train on with next-token prediction. That distinction matters: the model was not being taught labeled answers. It was being exposed to the vocabulary, framing, and recurring concepts that define this corner of the literature.

The preprocessing pipeline was simple, but it ended up being one of the most important parts of the project. After extracting the PDFs into text and markdown, I removed bibliography sections when they were mostly noise, repaired broken hyphenation from PDF parsing, split each source into paragraph-like chunks, collapsed each chunk onto a single line, and discarded short fragments that were clearly extraction artifacts. I also prefixed every chunk with a source tag so I could trace generated text back to the original document. The final result was a cleaned plain-text corpus in which each line corresponded to one training example. This project happened to overlap with the release of IBM’s docling, which made the document-to-text conversion much more usable than my earlier attempts.

Once the corpus was in shape, the training behaved roughly the way I hoped for a small continued-pretraining experiment: the loss dropped rapidly at early steps and then relaxed into a noisier but still downward trend. I do not want to over-interpret that curve, but as a first diagnostic it was reassuring. At the very least, the optimization was moving into the corpus rather than wandering off immediately.

I will not review the exact fine-tuning recipe in full here, because that really deserves its own discussion. For this project, though, I chose QLoRA because it repeatedly came up as the most practical approach for limited computational resources, especially if the goal was to run the entire workflow on my local desktop rather than on a large shared cluster. In broad terms, the method reduces the memory burden by keeping the base model in quantized form and learning only a small set of low-rank adapter weights, which makes this kind of experiment much more realistic under a tight hardware budget.

The figure below is not the entire training history of the model I ultimately benchmarked. It corresponds to the first QLoRA stage, which started from the base Llama 3.2 3B checkpoint and trained on the cleaned corpus with a learning rate of 1e-4, 20 epochs, max_seq_len=64, batch_size=4, gradient_accumulation_steps=1, and warmup=200. In that initial calculation I saved adapter weights only, with activation checkpointing and activation offloading disabled. All of this was run on a single NVIDIA GTX 1080 Ti, which is part of why I was careful about sequence length, batch size, and the staged continuation strategy. The common settings that remained fixed throughout the rest of the workflow were a Llama 3.2 3B QLoRA setup with LoRA applied to q_proj and v_proj, lora_rank=8, lora_alpha=16, lora_dropout=0.05, AdamW with weight_decay=0.01, seed=1234, dtype=fp32, device=cuda, packed=false, and add_eos=true.

The checkpoint I actually used for the benchmark was the final locally exported model from this restart chain. It was not produced in one uninterrupted run. Instead, I treated the training more like a sequence of controlled restarts. After the initial 20-epoch pass on February 7, 2026, I continued from that model at max_seq_len=256 with a lower learning rate of 5e-5: first for 2 additional epochs on February 10, then 3 more on February 11, and then 5 more on February 12. In other words, the model I benchmarked had already passed through a short-context adaptation stage and then a longer-context refinement stage.

I then did a final low-learning-rate continuation at 1e-5, still with max_seq_len=256, batch_size=1, gradient_accumulation_steps=8, and warmup=200, but this time under an explicit early-stopping rule with Patience=2, MinDelta=0.02, and at most 5 additional one-epoch passes. Only the first of those passes counted as a genuine improvement according to the early-stopping criterion; the next two were run but not accepted as better models. That detail matters because the final exported model is the best accepted pass, not simply the last pass written to disk. From a computational chemistry point of view, I think of this less as one monolithic optimization and more as a staged refinement protocol: first force the model into the right region of parameter space, then increase the sequence length, then reduce the step size and keep only improvements that survive a stricter criterion.

I also wanted a retrieval baseline, so the corpus had to serve a second purpose beyond continued pretraining. The same cleaned text became the source for a local vector database that I could use to compare plain generation, retrieval-augmented generation, and the fine-tuned model under the same set of questions.

Building the retrieval baseline

I built the local vector database from the cleaned corpus with a custom preprocessing and chunking pipeline. Each line carried a source tag, which let me reconstruct the underlying documents before splitting them by tokens rather than characters. I used a chunk size of 220 tokens, with 40 tokens of overlap and a minimum trailing chunk of 40 tokens. The resulting index contained 40 source documents and 4,030 chunks.

I did not use a separate sentence-transformer for embeddings. Instead, the retrieval pipeline reused the Llama model itself: it added BOS/EOS tokens, ran the first four transformer layers, mean-pooled the hidden states, and L2-normalized the result. That produced parallel embedding indices for the base and fine-tuned models, which made it possible to compare retrieval behavior across the two representations.

For question answering, the benchmark pipeline loaded the retrieval metadata together with the base-model index, embedded the user question with the base model, scored chunks by dot product, selected the top k matches, and inserted those snippets into a prompt of the form:

Use the context snippets to answer the question.
If context is insufficient, say so briefly.

[Context 1] source=... chunk_id=...
...

Q: ...
A:

One important detail is easy to miss: the benchmark was not fine-tuned + RAG. The three systems in the comparison were base, base + RAG, and fine-tuned. Retrieval always came from the base-model index, and the answer in the RAG condition was generated by the base model. The fine-tuned model was evaluated separately, without retrieval.

In the saved benchmark run from February 26, 2026, I used top_k = 3, temperature = 0.0, max_gen_len = 220, max_seq_len = 1024, and retrieval embeddings from the first four layers. Those settings are not the main point of the post, but they matter enough to record because they shape the comparison that follows.

What Fine-Tuning Can Help With

One reason to fine-tune a smaller model is practical: once model size grows, generating domain-specific responses can become expensive very quickly. A fine-tuned model offers a different compromise. If the target domain is narrow enough, it can internalize some of the vocabulary, style, and conceptual framing of that field while still remaining local and comparatively cheap to run.

For a subject like computational biophysics, that is appealing because many questions reuse the same language, notation, and scientific context. In the best case, fine-tuning reduces some of the friction of repeatedly teaching the model how this literature talks.

Where Fine-Tuning Breaks Down

That said, fine-tuning is not the same thing as reliable retrieval. It can make a model sound more comfortable in a domain without guaranteeing that it will reproduce specific facts faithfully. In other words, it may improve fluency before it improves accuracy.

This is especially important for technical questions where the answer depends on a precise statement buried in a particular paper. In that setting, retrieval has an obvious advantage: it can point the model back to the relevant source at inference time, whereas fine-tuning has to rely on what the weights happened to absorb during training.

Results: Base vs. Retrieval vs. Fine-Tuned

To make the comparison concrete, I pulled the saved benchmark run from February 26, 2026. Each question below shows the generated response from the three configurations I actually benchmarked: base, base + retrieval, and fine-tuned. The middle panel is retrieval on top of the base model, not retrieval on top of the fine-tuned model.

I kept the answers essentially as generated and only removed the terminal <|end_of_text|> token where it appeared, because the repetitions and prompt spillover are part of what this comparison reveals.

Closing thoughts

This mini-project taught me several lessons. For one thing, I now appreciate much more clearly how much work goes into cleaning text and producing corpora that are actually usable for training. The original GPT paper describes training on Reddit, a broad web corpus, and Wikipedia, all of which already provide text in relatively workable form. More modern models, by contrast, often have to absorb material from books and scans that are not naturally formatted for machine learning pipelines. I found Docling genuinely useful, but it still did not handle some LaTeX-heavy equations especially well. One limitation I did not test carefully was whether the model could reliably recall expressions such as the Smoluchowski equation. I will also note that I do not believe this model can perform arithmetic or mathematical operations correctly.

I also think the comparison between the base model, base + RAG, and the fine-tuned model is genuinely interesting. I still want to look more carefully at retrieval and prompt-engineering strategies, but even this first pass suggests that for recall-type questions, RAG does not do badly at all. All three systems still hallucinated, of course, and some of those failures were honestly a little funny, but the broader pattern was still informative.

I probably will not be using this particular fine-tuned model for anything serious. The weak answers suggest to me that better performance would require a much larger and cleaner dataset, along with more expensive training than I was willing to do for this experiment. Even so, the project was valuable because it made the hidden labor of fine-tuning much more concrete to me: data curation, model size, learning rate, sequence length, hardware limits, and evaluation design all matter. If nothing else, this was an educational exercise that gave me a better sense of what has to go right before a fine-tuned scientific model becomes genuinely useful.