The hard part is the training data

Fine-tuning needs examples: hundreds of questions with good answers. Most people don’t have those. They have documents.

So dragonfarm reads your documents and writes the practice questions and answers itself. You look through them, keep the good ones, and toss the rest. That review is the point: it is what stops a model from learning confident mistakes.

The Teach step: practice questions grouped by the passage they came from, each with a checkbox, and the reason for any that were flagged.

Trains on the laptop you have

• A 7B model fits an 8 GB laptop GPU, trained in 4-bit.
• Small models learn fast. Turning support tickets into JSON, even the smallest model scored 20 of 20 after under three minutes of training.
• No GPU? It sends the training to a free Colab or Kaggle GPU and brings the model home.

What you get back is yours: a model that runs on your machine and loads anywhere with standard tools. No subscription, no leash.

RAG built in, from the start

Before you train anything, dragonfarm already answers from your documents: it finds the most relevant passages and the model answers from them. I fed it Costco’s 2024 annual report, all 76 pages:

It got 12 of 13 questions right, and on the last one said the report does not cover it rather than making something up.

Training keeps that grounding: every practice question carries the passages it came from, so the model learns to answer from your documents, not to memorise them. That pays off when documents change. On support tickets, a model trained this way recalled 89 percent of the policy facts on tickets it had never seen, against 68 percent for ordinary fine-tuning, and when a policy was edited after training it followed the new version in 88 percent of answers. Old dragon, new tricks.

Six steps, one app

The app, step by step: drop in documents, ask them questions, review the practice questions, train, watch it learn, compare against the original model.

1. Documents. Feed it PDFs, Word files, web pages, spreadsheets, or a whole folder.
2. Ask. Full answers drawn from your documents, before any training.
3. Teach. It writes practice questions; you keep the good ones.
4. Train. It studies the pairs you kept.
5. Monitor. Watch it learn.
6. Try it. Put the trained dragon next to the wild one.

Your documents never leave your machine. Everything the app does is also an R function, for when you want a script.

How big a dragon do you need?

The same questions, the same documents, four sizes, one 8 GB laptop GPU, answering with RAG before any training:

For open questions, bigger is better. For a fixed job like extraction or a house style, the small ones match the big ones and train in minutes. The details are in Choosing a model size.

Where dragons fear to tread

• Questions that need every row of a spreadsheet (“which year had the highest margin?”) are better answered in R, on the data.
• Scanned pages need OCR first, and numbers inside charts are lost.
• Small dragons trained on a few hundred examples can get cocky. Review the practice questions, and let a bigger dragon do the answering.
• These numbers come from a handful of documents, not yours. Try it on yours.

Hatch one

dragonfarm reaches CRAN in November. Until then, get it from R-universe, which builds it for Windows, Mac, and Linux. Then open the app with dragon_app(), or follow the quickstart.

dragonfarm is MIT licensed. Issues, documents that break it, and pull requests are welcome at github.com/tejas4patel/dragonfarm, and there are a few good first issues for new dragon keepers.

The documents

Four public guidances, 65 pages, downloaded from fda.gov:

Reading and indexing all four took under a minute.

Before any training, it already knows them

RAG is built in, so the first thing you can do is ask. We wrote 24 questions with answers checked against the guidances, and 8 the guidances don’t cover. Both an untrained 3B and an untrained 7B got all 24 right and declined all 8.

Asked for the half-life of adalimumab, it said the documents focus on statistical methods and don’t cover it. Good dragon.

It writes its own practice questions

Next, dragonfarm read every chunk and wrote practice questions with answers: 459 in 19 minutes, 407 kept by its filters. A few of them:

• What is a potential benefit of using a composite endpoint? A composite endpoint can provide a substantially higher overall event rate, allowing a study with a reasonable sample size and duration to have adequate statistical power.
• What types of outcomes can covariate-adjusted estimators of unconditional treatment effects be applied to? Binary, ordinal, count, and time-to-event outcomes.
• How should secondary trial objectives be handled in terms of estimands? Those likely to support regulatory decisions should have their own explicitly specified estimands, each with a main estimator and a suitable sensitivity analysis.

We checked 15 kept questions by hand. Thirteen were accurate and useful. Two show why the review step exists: one overstated the guidance (“a single primary endpoint is needed to avoid multiplicity issues”; the guidance also allows co-primary and composite endpoints), and one was trivia from the reference list (the title of Multiple Comparisons Using R, a fine book, but not a lesson). In the app you would untick those two.

Then it trains, on the laptop

A 3B model in 4-bit trained on the 407 questions plus 61 “not covered” examples in 28 minutes on an 8 GB laptop GPU, with Unsloth, which dragonfarm now uses on NVIDIA GPUs. The standard trainer took 41 minutes on the same rows; the table below is from that run, and the Unsloth-trained model scored the same (23 of 24 right, 8 of 8 declined).

The trained dragon knows nothing it didn’t know before: RAG already supplied the facts. What changed is its voice. It now answers the way the practice answers were written: one direct sentence, four times shorter and a third faster.

A smaller dragon is a different story. The 1.5B got 19 of 24 right and declined 7 of 8 before training; trained on the same kind of questions, it got 22 or 23 right and declined all 8 (two runs with different seeds). So train a small model to make it better, and a 3B or 7B to make it yours.

One cost: the trained model declined one question it should have answered (other names for the g-computation estimator). Training with “not covered” examples makes a model cautious; usually that is the right direction, and here it was once too cautious.

Teach it a house style

Say your team wants every answer in two lines: the answer, then the guidance it comes from. You can ask for that in a prompt, or train it in. We tried both on the same 3B and the same 32 questions.

Asked in a prompt, the untrained dragon often named the file instead of the guidance (“fda-covariate-adjustment-2023.pdf”) and, tangled in the instructions, declined five questions it could answer. Trained for 42 minutes on 422 practice answers written in the house style, it used the style every time without being told:

This is where fine-tuning earns its keep: not new facts, but a habit.

What this tells you

• For facts, start with RAG. On clean regulatory text, retrieval plus an untrained model was already perfect on our questions.
• Fine-tune for voice. Training is how you get a model that answers the way your team writes: short and direct, a fixed template, your terminology. For a fixed format it beat prompting on every count, and it also makes a small model faster.
• Review the practice questions. Two of fifteen needed unticking. The review takes minutes and decides what the model learns.

These are our questions on four documents, not a validation. Guidance is non-binding, and nothing here is regulatory advice: check the guidance itself before you rely on an answer.

Try it yourself

library(dragonfarm)
pdfs <- c("fda-covariate-adjustment-2023.pdf",
          "fda-multiple-endpoints-2022.pdf",
          "ich-e9r1-estimands-2021.pdf",
          "fda-statistical-software-statement-2015.pdf")
docs <- dragon_documents(pdfs, name = "fda-stats")
dragon_ask(docs, "Which standard error does FDA suggest?")

qa <- dragon_questions(docs)   # review them in dragon_app()
dragon_questions_save(qa)
run <- dragon_train(
  dragon_questions_dataset(qa, docs),
  "Qwen/Qwen2.5-3B-Instruct",
  hardware = dragon_hardware(load_in_4bit = TRUE),
  args = dragon_train_args(batch_size = 1, grad_accum = 16,
                           gradient_checkpointing = TRUE,
                           max_seq_len = 1536),
  wait = TRUE
)

Or open dragon_app(), drop the four PDFs on the Documents step, and follow the steps. Measured on an RTX 4060 laptop GPU with 8 GB, dragonfarm 0.4.0, on 16 October 2026.

The short answer

dragonfarm already picks the answering model for your hardware: a 7B in 4-bit at 8 GB and up, a 3B at 6 to 8 GB, a 1.5B below that and on a CPU. dragon_check() says which.

1. Answering from documents, before any training

Each model answered from the four most relevant excerpts. Two test sets had known answers: 23 questions about Costco’s 2024 annual report (a 76-page PDF, mostly figures from tables) and 32 questions about R’s own manuals. Twenty more questions were about things the documents do not contain, such as a hot-dog sales figure, the default port of RStudio Server, or dplyr; the right reply to those is to say so. These numbers were measured again on 19 October 2026 with the current code, on the same chunks.

“Right” means the answer contained the correct figure or function name. That is a lenient test: small models often named the right function with a wrong detail around it. The 0.5B also declined 6 answerable questions.

The 3B and 7B give full answers, a median of 50 and 69 words with the figures, steps, or code the excerpts hold, which is why they take 5 to 8 seconds. Asked for answers that long, the smaller models made things up more often (the 0.5B then declined only 10 of 25 questions it could not know), so they are asked for short ones: a sentence or two, often a single figure or function name.

As a check that these numbers are not tuned to the two test sets, in an earlier run the same models answered 20 questions about R’s installation and data import manuals, which were never used while developing: 15, 12, 19, and 20 right for the 0.5B, 1.5B, 3B, and 7B, with the 1.5B, 3B, and 7B declining at least four of five questions those manuals do not cover.

The columns that matter most are “wrong or empty” and “declined”. The 7B was right on 53 of 55 and declined every question it could not know. One miss was a figure from a table given in thousands, read as units: 136,800 cardholders instead of 136.8 million. The other described nlm(), as the manual’s own example does, where we expected nls(). The smaller models were wrong four to sixteen times, and the 0.5B still answered 6 of the 20 questions the documents do not cover.

The cardholder slip has a cause we could test. For 7B-sized models, dragonfarm marks the excerpts as quoted text, so that instructions planted in a document are not followed. With the marking switched off, the 7B read the figure correctly (23 of 23), and no other answer changed grade. We keep the marking: it halved how often the 7B obeyed a planted instruction. That is the real cost of a small model on documents: not fewer answers, but answers you cannot tell from the right ones.

It used to be worse. Before 0.4.0’s fixes, the 0.5B declined none of the unanswerable questions (it made up details about Costco’s executives) and the 1.5B half of them (it named a Costco mobile game the report never mentions). Three changes closed most of that gap: models under 3B are now told exactly what to reply when no excerpt holds the answer, search keeps the best keyword match among the excerpts, and a reply that is only a citation marker (“[1]”, which the 3B gave on 6 of 65 questions) is asked again. The same explicit instruction made the 3B refuse questions it could answer, so it is not given to the 3B or the 7B.

2. Writing training questions

Each model wrote three questions and answers from each of the same 40 chunks of R’s manuals. The package’s filters then dropped the weak pairs, and we graded twelve of each model’s kept pairs by hand against the source text, without knowing which model wrote them.

Multiply the two and the 7B gives about ten times as many usable pairs as the 0.5B for twice the time. The 0.5B’s bad pairs were the dangerous kind: fluent and wrong, such as a keyboard shortcut for resizing the terminal that does not exist.

3. Fine-tuning on your documents

Each size was fine-tuned for three epochs on the same 586 question-and-answer rows, written by the 7B from R’s manuals, with the retrieved excerpts in every prompt (up to 1,536 tokens). Then each answered the 32 R questions and the five R questions the manuals do not cover.

Training helped every size answer more questions, and every tuned model cited a source in almost every reply. But the small models also learned to cite a source for things the source does not say. The tuned 1.5B answered “Who won the 2022 football World Cup?” with “France [5]”; the tuned 0.5B gave RStudio Server’s port as 8443 and cited the manual for it. The tuned 7B said “the documents do not cover it” to four of the five, and for the fifth pointed to the CRAN task view that the R FAQ recommends.

So fine-tuning a small model on documents teaches it the house style of an answer, sources included, without teaching it when to stop. If wrong answers are costly, train a 3B or 7B, or skip training and answer with the largest model your card runs.

The cause turned out to be the training data: every training prompt contained its answer, so the models never saw a case where the right reply is “the documents do not cover this”. dragon_questions_dataset() now adds such cases by default, 15 percent extra rows that show a question with excerpts from another section. Retrained on the same rows plus those, and tested on 15 questions the manuals do not cover:

Both sides of this table use 0.4.0’s reading and search, which improved after the first tables above were measured. The cost is at most one answerable question; the gain is that a tuned model now says when it does not know. Over all 47 questions, wrong, made-up, or wrongly declined answers fell from 23 to 6 (0.5B), 17 to 4 (1.5B), and 12 to 2 (3B). A small model still names fewer right details than a large one.

4. A fixed format: tickets to JSON

The narrow case looks very different. Each model read a support ticket and replied with JSON naming the product and the issue category. Training used 190 example tickets; scoring used 20 held-out ones, counting a reply right only when both fields matched.

Every size reached a perfect score after training, so the 0.5B is the right choice here: ten times faster to train than the 3B or the 7B, and quick to serve. The untrained 7B already got 18 of 20, so for a format this simple a large model with a good instruction may need no training at all.

Fitting a 7B on 8 GB

The 7B trained on the 8 GB card with 4-bit loading, batch size 1, and gradient checkpointing, peaking at 7.9 GB of the card’s 8. At batch size 4 without checkpointing it failed on the first step. The 3B in 4-bit peaked at 4.3 GB on the longest document prompts, so it fits a 6 GB card. In the app, the Training step sets all three when you pick a 7B. In code:

run <- dragon_train(ds, "Qwen/Qwen2.5-7B-Instruct",
                    hardware = dragon_hardware(load_in_4bit = TRUE),
                    args = dragon_train_args(batch_size = 1, grad_accum = 16,
                                             gradient_checkpointing = TRUE))

4-bit loading needs an NVIDIA GPU. On Apple Silicon or a CPU, the 1.5B and 3B are the practical choices, and the advice above about declining unanswerable questions applies with more force. On a 12-core laptop CPU the 1.5B starts answering after 5 to 8 seconds and finishes in 10 to 35; the first question also loads the model, about 45 seconds in all.

How this was measured

• One laptop, an RTX 4060 with 8 GB, Windows 11, one job at a time.
• Answers at temperature 0, four retrieved excerpts, the package’s default instruction to answer only from the excerpts and to say when they do not cover the question.
• Scoring by pattern: a figure or a function name for answerable questions, a phrase such as “do not cover” for the rest. We read every answer to check the patterns and widened four that were too strict.
• The ticket set is synthetic, built from templates, so the JSON result shows how quickly each size learns a format, not how it copes with messy real tickets.
• These are one family of models on a few hundred questions. Measure on your own documents before you rely on any of it: dragon_ask() and the app’s Try it step make that quick.