Caramelo 4.4.1: The Style-Correction Method Transfers to a New Base (Gemma 4 E4B)

A new base model, the same fine-tuning method, and a blind A/B against both the base and the previous production version.

Guilherme Favaron · Technical report, 2 July 2026 · ia-caramelo.com · huggingface.co/guifav/caramelo-gemma4-e4b

Abstract

We report the second cycle of Caramelo, a personal-voice assistant previously documented as a LoRA fine-tune of google/gemma-3-4b-it (see the 3.4.2 technical report). This cycle moves the base model a full generation forward, to google/gemma-4-E4B-it, and asks a narrow question: does a style-correction method built for one base transfer to another without modification? We reuse the same 414-pair {instruction, response} dataset and the same QLoRA recipe (rank 16, alpha 32, dropout 0.05, three epochs), changing only what the new base requires: the adapter targets the text decoder of a multimodal Gemma4ForConditionalGeneration model, leaving its vision and audio towers untouched. Training loss falls from 2.53 to 1.33 over three epochs on a 34.9-million-parameter adapter, 0.44 percent of total parameters. In blind A/B evaluation, the resulting model, caramelo 4.4.1, beats the untuned Gemma 4 E4B base by 100 percent on style and 91 to 100 percent on quality, and beats the previous production version, caramelo 3.4.2, by 79 to 87 percent on style and 87 to 91 percent on quality across two independent judges. Response length rises by roughly half, from an average of 270.6 to 400.8 tokens across 32 held-out prompts, driven by the new base's tendency toward more complete answers rather than by any change to the training data. Reasoning was not re-measured in this cycle; the 3.4.2 report's ENEM result (57.5 percent versus 57.2 percent for its base, a statistical tie) remains the most recent evidence that the method does not measurably erode reasoning, and we flag its absence here as a limitation rather than extrapolate it across a base change. The central finding is that the style-correction method is not tied to a specific base: the same data, the same filter, and the same training recipe produce a decisive win on a model from a newer, larger, multimodal family, with no re-engineering beyond adjusting which parameters LoRA targets.

1. Introduction

The 3.4.2 report told the story of a method: a first fine-tuning attempt that made a 4-billion-parameter model worse than its base, a diagnosis of the failure as a data-format problem, and a style-correction pipeline that reversed the result. That report closed with a question left open for the next cycle: production model lifecycles do not stop after one success, and the base model underneath a fine-tune is not a fixed point. Google shipped a new Gemma generation, and Caramelo's base moved from google/gemma-3-4b-it to google/gemma-4-E4B-it, a jump of one full model generation and a change in architecture family, from a text-only dense model to a multimodal model with an effective active parameter count of about 4 billion, marketed as E4B.

This report documents what changed and, more importantly, what did not. The training data is the same 414 pairs used for 3.4.2, built by the style-correction pipeline described in the previous report: base-model drafts rewritten in the author's voice by parallel LLM subagents anchored to real excerpts, then filtered by objective anti-pattern markers. The QLoRA hyperparameters are the same. What changes is dictated entirely by the new base's architecture: a multimodal model has a text decoder, a vision encoder, and (in this generation) audio input handling, and only the text decoder is relevant to a text-only style adapter. The rest of the base is frozen and, for Caramelo's purposes, invisible.

The question this cycle answers is whether a fine-tuning method validated on one base generalizes to the next one without modification, or whether each new base requires its own diagnostic cycle of the kind that produced the 3.4.2 method in the first place. We find the former: the same recipe, applied to the new base with only the necessary architectural adjustment, produces a decisive win in blind evaluation against both the untuned base and the prior production model. We report the evaluation protocol, the numbers, and the one honesty gap that remains: reasoning capability was not re-measured on the new base, and we flag that as a limitation rather than infer it from the previous cycle.

2. Background

The method, its motivation, and its full history are documented in the 3.4.2 technical report and are not re-derived here. In summary: the first fine-tuning attempt (retroactively named caramelo 3.4.1) trained on {theme, article} pairs and taught the model the shape of an article rather than how to answer a question, losing a blind A/B against its own base on both style (21 percent) and quality (15 percent). The style-correction dataset that followed reframed training pairs as {instruction, response}, anchored voice rewrites to real excerpts without copying their content, and filtered outputs by objective markers for the author's documented anti-patterns. That adapter, caramelo 3.4.2, reversed the result decisively and was promoted to production. The present report assumes familiarity with that narrative and focuses on what is new in this cycle: a different base model and a second confirmation of the method against it.

3. Base change: Gemma 4 E4B

Caramelo 4.4.1 is built on google/gemma-4-E4B-it, loaded through the Gemma4ForConditionalGeneration architecture. Unlike the Gemma 3 4B base used previously, Gemma 4 E4B is a multimodal model: it accepts image and audio inputs alongside text, and its parameter count is distributed across a decoder stack, a vision encoder, and associated projection layers, with an effective active-parameter budget in the 4-billion range that gives the "E4B" designation its name.

This matters for a LoRA fine-tune because it changes what "the model" means as a set of trainable modules. Caramelo's fine-tuning goal is unchanged: teach the model to answer in a specific written voice. That goal is a property of text generation, not of image or audio understanding, so the adapter is attached exclusively to the text decoder, targeting the attention and projection layers under model.language_model.layers.*. The vision tower, the audio pathway, and any cross-modal projection layers are left frozen and untouched by the adapter, exactly as they would be for any other downstream user of the base model who does not intend to change its multimodal behavior.

One practical consequence of this scoping decision is reflected in how the merged model is published: the Hugging Face repository for guifav/caramelo-gemma4-e4b declares pipeline_tag: text-generation, not an image-text-to-text or multimodal tag, because the fine-tune neither touches nor is intended to change the model's non-text capabilities. Caramelo remains, by design, a text chat model built on top of a multimodal base; the multimodal capability of the base is present in the weights but outside the scope of what the adapter modifies or what the served product exposes.

4. Method

The dataset and recipe are unchanged from the 3.4.2 cycle, and their full derivation, including the failed first attempt, the five-stage style-correction pipeline, and the objective marker filter, is documented in the 3.4.2 technical report. This section records only what is specific to the 4.4.1 run.

Dataset. Training reuses the same 414 {instruction, response} pairs published as guifav/caramelo-dataset, without regeneration, re-filtering, or any change to the style rubric. No new prompts were generated and no new voice rewrites were produced for this cycle; the entire premise of this report is that the existing dataset, built for a different base, is reused as-is.

Recipe. Training uses the same QLoRA configuration validated in the 3.4.2 cycle: rank 16, alpha 32, dropout 0.05, learning rate 2e-4, three epochs. The only architecture-driven change is the LoRA target module list, scoped to the text decoder layers of the multimodal base as described in Section 3, rather than the dense decoder layers of Gemma 3 4B.

Pinned base revision. The training run pins the exact base model revision used, recorded in the committed training_config.json alongside the rest of the run configuration, so that the adapter's provenance is reproducible against a specific snapshot of google/gemma-4-E4B-it rather than a moving tag.

Adapter size. The resulting LoRA adapter has 34.9 million trainable parameters, 0.44 percent of the base model's total parameter count, consistent with the low-rank, parameter-efficient profile expected of a QLoRA adapter at this rank.

Training dynamics. Training loss falls from 2.53 at the start of training to 1.33 by the end of three epochs. This is a larger absolute drop than the 3.4.2 run's loss curve (which reached roughly 1.58), consistent with a newer, larger base model finding a lower-loss fit to the same 414-pair style dataset, though the two loss values are not directly comparable across different base architectures and tokenizers.

5. Evaluation Protocol

The evaluation protocol is the same one defined in the 3.4.2 technical report: a blind, randomized-order A/B preference test over 24 held-out prompts, disjoint from the training set, judged independently by two model judges, GLM-5.2 and the Codex CLI running in a read-only sandbox, on style and on overall quality as separate questions. Judges see paired answers without labels identifying which model produced which response, and the promotion rule remains a hard gate: a candidate is only promoted if it beats what it is compared against.

This cycle runs the protocol against two separate comparisons rather than one:

vs. Gemma 4 E4B base. The untuned base model versus caramelo 4.4.1, isolating the effect of the fine-tune from a clean baseline on the new architecture.

vs. caramelo 3.4.2. The previous production model versus caramelo 4.4.1, isolating whether moving the base model forward a generation, with the same fine-tuning method, produces a better served product than what was already in production.

Both comparisons use the same 24 held-out prompts, the same two judges, and the same blind randomized presentation, with complete 24-of-24 coverage from both judges. The per-judge verdict tallies for both comparisons are committed to the repository (eval/out/judge_results.json for vs-3.4.2, eval/out/judge_results_base.json for vs-base); the held-out prompts and the model generations themselves are kept private to protect the integrity of the blind evaluation set.

In addition to preference judging, this cycle measures a fourth quantity not scored by either judge: response length and completeness, using a separate 32-prompt held-out set spanning advice, conceptual, and technical categories, counted in tokens rather than characters.

6. Results

6.1 Win rate

Caramelo 4.4.1 wins both comparisons decisively, and both are reported per judge from committed verdict tallies.

The vs-3.4.2 row is drawn directly from the committed per-judge verdict file: GLM scores caramelo 4.4.1 ahead on style 19 times out of 24 and on quality 22 times out of 24; Codex scores it ahead on style 21 times out of 24 and on quality 21 times out of 24, with no ties and full 24-of-24 coverage from both judges. Taken together, these numbers span a range of 79 to 87 percent on style and 87 to 91 percent on quality, matching what is published as the headline result for this comparison.

Against the untuned Gemma 4 E4B base the margin is wider still. Both judges prefer caramelo 4.4.1 on all 24 prompts for style. On quality, Codex prefers it on all 24, and GLM-5.2 prefers it on 22 of 24 with the other two judged ties and none lost, a quality win rate of 91.7 to 100 percent across the two judges. This is the comparison that isolates the fine-tune from the base model itself: the win over the raw base is not an artifact of a stronger base generation but of what the adapter adds on top of it, on nearly every prompt.

6.2 Response length and completeness

Response length was measured across 32 held-out prompts spanning advice, conceptual, and technical categories, comparing the token count of caramelo 4.4.1's answers (served without any concision overlay, matching production) against caramelo 3.4.2's answers to the same prompts.

On average, caramelo 4.4.1 answers with roughly 400 tokens against roughly 270 for caramelo 3.4.2, an increase of close to half again as much content per response. Qualitative review of the underlying transcripts attributes this to completeness rather than verbosity for its own sake: the previous production version more frequently truncated or omitted parts of a multi-part question, while the new base's answers on the same prompts more consistently address every part asked. An experimental concision overlay was also evaluated in this cycle (mean 354.4 tokens across the same 32 prompts) as a way to pull response length back toward the previous version's range, but it is not what is served in production; caramelo 4.4.1 in production uses the base persona without a concision overlay, corresponding to the 400.8-token figure above.

6.3 Reasoning: not re-measured this cycle

Reasoning capability was evaluated in the 3.4.2 cycle using 1,432 non-annulled ENEM multiple-choice questions, scored zero-shot by the log-likelihood of the final-token answer letter. That evaluation found caramelo 3.4.2 at 57.5 percent against its Gemma 3 4B base at 57.2 percent, a difference within statistical noise and read as reasoning preserved rather than improved or degraded by the fine-tune.

This benchmark was not re-run in the 4.4.1 cycle. We report the 3.4.2-cycle number here for context and comparability, not as a claim about the current model: it measures a different base architecture entirely, and extrapolating a tie observed on Gemma 3 4B to a conclusion about Gemma 4 E4B would overstate what has actually been measured. Whether caramelo 4.4.1 preserves reasoning to the same degree as its predecessor did is, honestly, unknown at the time of this report, and is listed as a limitation in Section 8 and as follow-up work in Section 9.

7. Discussion

The result of this cycle is narrower than the result of the last one, and that is by design. The 3.4.2 cycle discovered and validated a method; this cycle asks whether that method is a one-off fix for a specific base or a transferable recipe. The evidence supports transfer: the same 414-pair dataset, the same style-correction filter, and the same QLoRA hyperparameters, applied to a base model from a newer generation and a different architecture family, produce a decisive blind-evaluation win over both the untuned base and the model it replaces in production. The only change required by the new base was mechanical, adjusting which parameter groups the LoRA adapter targets to account for a multimodal architecture, not a re-derivation of the training data or the filtering logic.

This supports a broader claim made informally in the 3.4.2 report: that communication quality is a component of model performance in its own right, separable from raw reasoning capability, and that a small, well-targeted intervention on how a model communicates can be preserved across a base model upgrade through a small adapter, rather than having to be re-derived for each new base. The style-correction dataset does not encode facts about the world; it encodes a manner of answering, and a manner of answering, once captured in {instruction, response} pairs and filtered to remove format artifacts, appears to be a property that a new base model can absorb through a small adapter regardless of the specifics of its own pretraining.

The completeness finding in Section 6.2 is a secondary but genuine result of the base change. The increase of roughly half in effective response length was not something this cycle set out to engineer; it emerged from moving to a newer base and was validated, not designed, by the held-out length measurement. Combined with the qualitative observation that the previous version more often left parts of a question unanswered, this suggests that some of what looked like a stable tradeoff between concision and completeness in the 3.4.2 cycle was in part an artifact of that specific base's tendencies, and not an immutable property of the style-correction method itself.

8. Limitations

Reasoning was not re-measured. The ENEM result reported in Section 6.3 is carried over from the 3.4.2 cycle and reflects the previous base model, not the current one. This is the most significant gap in this report's evidence: we do not know, from measurement rather than inference, whether caramelo 4.4.1 preserves reasoning capability relative to its Gemma 4 E4B base to the same degree that caramelo 3.4.2 preserved it relative to Gemma 3 4B.

Higher verbosity is a tradeoff, not an unambiguous win. The roughly 50 percent increase in response length documented in Section 6.2 improves completeness on multi-part questions but is not costless: longer responses take longer to read and to generate, and the 3.4.2 cycle's own experience shows that response length can independently move a model's win rate on usefulness judging in either direction depending on task type. This cycle did not run the equivalent conversational usefulness benchmark (the MT-Bench-PT protocol from the 3.4.2 report) against the new base, so whether the increased length is net positive for general conversational helpfulness, as opposed to answer completeness specifically, is not directly measured here.

LLM-judge bias. Both judges used in this cycle are themselves language models and inherit the known biases of LLM-as-judge evaluation, including verbosity bias, which is particularly relevant given the response-length change documented above. Blind, randomized-order presentation and the use of two independent judges mitigate but do not eliminate this risk, consistent with the same caveat in the 3.4.2 report.

Scope remains PT-BR, short-to-medium form. As in the previous cycle, the training data, the held-out evaluation prompts, and the intended use case are Brazilian Portuguese, conversational-to-technical in register, and short-to-medium in length. Nothing in this report speaks to long-form generation, other languages, or multimodal input and output, even though the underlying base model is capable of the latter.

9. Reproducibility and Artifacts

All code and artifacts referenced in this report are public or available on request.

Models (Hugging Face):

• guifav/caramelo-gemma4-e4b-lora-adapter — the 4.4.1 LoRA adapter.
• guifav/caramelo-gemma4-e4b — the merged model, published with pipeline_tag: text-generation, and its GGUF conversion for llama.cpp serving.
• guifav/caramelo-dataset — the same 414 {instruction, response} training pairs used in the 3.4.2 cycle, reused without modification.

Code:

• finetune/gemma4_e4b/train_lora.py — the training script for this cycle, including the text-decoder-only LoRA target configuration described in Section 3.
• A pinned training_config.json, committed alongside the training run, recording the exact base model revision, LoRA hyperparameters, and target modules used.

Evaluation:

• Committed per-judge verdict tallies for both comparisons: eval/out/judge_results.json (vs-3.4.2) and eval/out/judge_results_base.json (vs-base). Each holds the per-item A/B verdicts and the aggregate counts behind Section 6.1, with no prompt or generation text.
• The held-out prompts and the model generations, including the response-length set behind Section 6.2, are deliberately kept private so the blind evaluation set cannot be trained against or gamed. The committed tallies are sufficient to audit the reported win rates; reproducing the judgements from scratch requires the private generation set.

Open item for a future cycle: re-run the ENEM reasoning benchmark against caramelo 4.4.1 and its Gemma 4 E4B base, the one axis this cycle did not re-measure on the new base, to close the gap noted in Section 6.3.

10. Conclusion

Caramelo 4.4.1 answers the question this cycle set out to ask: the style-correction method built and validated in the 3.4.2 cycle transfers to a new base model from a newer generation, without requiring a new diagnostic cycle of its own. The same 414-example dataset, the same objective marker filter, and the same QLoRA recipe, adjusted only to target the text decoder of a multimodal architecture, produce a model that decisively beats both its own untuned base and the production model it replaces, in the same blind evaluation protocol used to validate the original method. The gains are not without an honest gap: reasoning was not re-measured on the new base, named here as a limitation rather than inferred from the previous cycle; both blind comparisons are otherwise backed by committed per-judge tallies. This is in keeping with the discipline the 3.4.2 report argued for: a result is only as trustworthy as the measurement behind it, and where the measurement is incomplete, the report should say so plainly.

References

• The Caramelo 3.4.2 technical report documents the full style-correction method, the failed first attempt, the five-stage dataset pipeline, and the original evaluation protocol, all reused without modification in this cycle.
• Hu, E. et al. (2021). LoRA: Low-Rank Adaptation of Large Language Models. arXiv:2106.09685.
• Dettmers, T. et al. (2023). QLoRA: Efficient Finetuning of Quantized LLMs. arXiv:2305.14314.
• Zheng, L. et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv:2306.05685.
• Google DeepMind (2026). Gemma 4 Technical Report.

Appendix A. Style rubric (summary)

The style rubric applied to this cycle's training data is unchanged from the 3.4.2 cycle and is summarized in full in the 3.4.2 technical report, Appendix A. In brief, it asks for a short opening that answers immediately, real data and examples over abstraction, rhythmic variation between short and long sentences, and natural Brazilian Portuguese, while explicitly forbidding the em-dash inside a sentence and the negation-correction construction ("not X, but Y"). No changes to the rubric were made for this cycle; the dataset filtered by this rubric for 3.4.2 is the same dataset used to train 4.4.1.

Appendix B. Production persona and safety

The served persona and safety layer are, as in the 3.4.2 cycle, injected server-side rather than trained into the weights, and are documented in full in the 3.4.2 technical report, Appendix B. For this cycle, the identity anchor in the served prompt was updated to name Gemma 4 E4B as the underlying base rather than Gemma 3 4B, and the completeness instruction from the 3.4.2 persona remains in place. No other changes to the persona or safety layer were required by the base model change described in this report.