The best thing my fine-tune learned was to wait
“It is a capital mistake to theorise before one has data.”
A small assistant I fine-tuned answers one kind of factual question through a tool: which zodiac sign the Sun or Moon was in on a given date. Asked from memory, the 3B base model stated a sign on 3 of 5 date prompts and got 2 wrong. Another base run cited the lookup tool as its source without calling it. The fine-tune calls the tool with the right date and body, and says nothing about the sign until the tool answers. My first grader could not tell those apart. Now it can.
The case, in four numbers
Signs the base model stated from memory that were wrong: Pisces for 21 Mar 2024 and Virgo for 23 Sep 2024.
Date prompts where the fine-tune called the tool with exactly the right date and body.
Prompts where the fine-tune named a sign before the tool returned.
Right arguments from an earlier adapter. It asked about the Sun on a Moon question, and my old grader passed it.
Transcript
Sources and honest limits
PREDPredictions of the base model and two adapters on the main set, 21 and 24 Sep 2026 (private lab)EQXUS Naval Observatory, Earth seasons 2024, equinox times in UTC: https://aa.usno.navy.mil/api/seasons?year=2024GRDHeld-out tool-intent fixtures and argument checks, 6 Oct 2026 (private lab)DOYArthur Conan Doyle, A Scandal in Bohemia, in The Adventures of Sherlock Holmes, Project Gutenberg ebook 1661: https://www.gutenberg.org/ebooks/1661
The Sun entered Aries at the equinox on 20 Mar 2024, 03:06 UTC, and Libra on 22 Sep 2024, 12:44 UTC, so both base answers named the sign the Sun had just left. One sample per prompt, and the base runs used two different hosts. The fine-tune does not compute positions; the tool does, and the model has to wait for it. The new checks are lexical: a sign named anywhere in an answer before the tool result fails it. The held-out date tests have no score for the served model yet. Product and client names are left out.
Clear solution.