LLM Fine-Tuning: Teaching a Small Model to Analyze 10-K Risk DisclosuresLLM 微調實務：以小型模型分析 10-K 風險揭露

Fine-tuning adapts a pretrained model to reproduce one specific behavior. The hard part isn't starting the training job — it's deciding what that behavior should be, building examples that express it consistently, and proving the resulting adapter actually beats a well-prompted baseline.

This article is organized into four parts:

1. Part I: Fine-Tuning Overview
2. Part II: LoRA and QLoRA
3. Part III: Evaluating a Fine-Tuned Model
4. Part IV: Hands-On SEC 10-K Risk-Analysis Case

This article assumes familiarity with decoder-only Transformers — see LLM Pretrain: Anatomy of a Decoder-Only Transformer for background.

Part I: Fine-Tuning Overview

Fine-tuning is useful when a desired behavior is repeated, specific, and difficult to obtain reliably through prompting alone. It is an optimization step, not an automatic first step.

Is Fine-Tuning the Right Tool?

Before investing compute and time into training, it is crucial to establish a strong baseline using few-shot prompting or Retrieval-Augmented Generation (RAG). Prompting injects facts and context, whereas fine-tuning alters a model's fundamental tone, structure, and reasoning pathways.

You should consider moving from prompting to fine-tuning when:

• You are consistently maxing out your context window with complex, highly specific few-shot examples.
• You require rigid, guaranteed output formats (such as a strict JSON schema mapping out 10-K risk severities) that prompting alone cannot reliably enforce.
• Cost or latency constraints dictate replacing a massive proprietary model with a smaller, specialized open-weights model (e.g., an 8B parameter model).

Requirement	Recommended Approach
Improve a one-off instruction	Prompt engineering
Access current or private documents	Retrieval-augmented generation (RAG)
Add frequently changing financial facts	Retrieval-augmented generation (RAG), not model memory
Reproduce a stable tone, taxonomy, or output schema	Fine-tuning
Teach consistent decisions from labeled examples	Fine-tuning
Reproduce a stable tone, taxonomy, or JSON schema	Fine-tuning

These approaches are complementary; in our 10-K experiment, retrieval supplies the relevant SEC disclosure, while fine-tuning teaches the model exactly how to analyze and format it.

The Supervised Fine-Tuning (SFT) Objective

Fine-tuning encompasses several distinct objectives. A model might undergo continued pretraining for domain terminology, SFT for task behavior, and preference tuning (like DPO or RLHF) to refine its output choices.

Fine-tuning is not a single training objective; it encompasses several distinct methods that teach different kinds of adaptation.

Method	What it teaches
Continued pretraining	Domain language, terminology, and document patterns through next-token prediction
Supervised fine-tuning (SFT)	Desired input-to-output behaviour from labelled demonstrations
Preference tuning	Which of two responses is preferable, using methods such as Direct Preference Optimisation (DPO)
Reinforcement learning	Behaviour that maximises a reward signal, using approaches such as RLHF or RLAIF

For our 10-K experiment, the primary objective is SFT because our desired output can be expressed as labeled prompt-completion pairs.

The causal language-modeling objective does not fundamentally change from pretraining: the model still predicts the next token. What changes is the data distribution. While raw documents teach the model to merely continue text, curated SFT demonstrations teach it to respond to a specific request in a consistent, structural way.

Chat Templates: The Training Contract

A conversation represented as role and content objects must eventually become one token sequence. A chat template inserts the control tokens that mark system, user, assistant, and message boundaries:

Structured messages
        ↓ model-specific chat template
[system control tokens   ]  instruction
[user control tokens     ]  request
[assistant control tokens]  response
        ↓ tokenizer
Training token IDs

Different model families use entirely different control tokens. For example, LLaMA-3 structures its prompts using <|start_header_id|> and <|eot_id|>, while Mistral uses [INST] and [/INST]. Training and inference must use the exact template associated with the selected tokenizer. Manually reproducing another model's format will materially degrade response quality.

The transformers library exposes this conversion through tokenizer.apply_chat_template:

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.1")
chat = [
  {"role": "system", "content": "You are a financial assistant."},
  {"role": "user", "content": "Analyze this 10-K excerpt."},
  {"role": "assistant", "content": "{\"risks\": [...]}"}
]

# This outputs the properly formatted flat string with control tokens
tokenizer.apply_chat_template(chat, tokenize=False)

Hugging Face chat-template guide

Loss Masking: Completion-Only Loss

Once the text is formatted, we must tell the optimizer what to learn. During completion-only training, prompt tokens provide necessary context, but they should not contribute to the loss. We only want to penalize the model for errors in the assistant's response.

We achieve this using a label mask. The ignore value -100 tells the PyTorch cross-entropy implementation not to score those positions:

Tokens: [system instruction] [user prompt] [assistant response]
Labels: [       -100      ] [   -100    ] [ compute loss here ]

By masking the prompt, we concentrate the learning signal entirely on the behavior the model must produce. In current versions of the TRL (Transformer Reinforcement Learning) library, prompt-completion datasets use completion-only loss by default. Conversational datasets can trigger this behavior using assistant_only_loss=True, provided the chat template supplies a valid generation mask. (For implementation details, refer to the TRL SFTTrainer loss-masking documentation)

Training on the full sequence is also a legitimate objective in other settings, so response-only masking should be selected deliberately rather than treated as a universal rule.

Full Fine-Tuning vs. PEFT

Full fine-tuning updates every parameter in the model, demanding massive memory for gradients and optimizer states. Every specialized model requires storing a complete set of multi-gigabyte weights.

Parameter-efficient fine-tuning (PEFT) freezes most of the base model and trains a fraction of the parameters. The industry standard taxonomy divides PEFT into three high-level strategies:

PEFT Strategy	Mechanism	Representative Methods
Additive	Freezes the base model and introduces new trainable parameters.	Adapter modules, prompt tuning, prefix tuning, P-tuning
Selective	Updates only a chosen subset of existing parameters.	BitFit, LayerNorm tuning, partial layer unfreezing
Reparameterisation	Expresses weight updates through a compact mathematical structure.	LoRA, AdaLoRA, DoRA

LoRA belongs to the reparameterization family, and QLoRA simply pairs LoRA with a quantized base model. While PEFT drastically reduces compute costs, it does not compensate for poor data; your adaptation is only as good as your labels.

This taxonomy is presented in Scaling Down to Scale Up: A Guide to Parameter-Efficient Fine-Tuning.

Part II: LoRA and QLoRA

LoRA: Low-Rank Adaptation

LoRA observes that the useful parameter change for a downstream task—like adapting a general model to parse complex SEC 10-K filings— often has a much lower intrinsic dimension than the original weight matrix.

For a frozen weight matrix $W_0$, LoRA learns an update:

$$W' = W_0 + \Delta W$$

Instead of training a massive dense matrix, the update is factorized into two smaller matrices:

$$\Delta W = \frac{\alpha}{r}BA$$

Where $A \in \mathbb{R}^{r \times k}$ and $B \in \mathbb{R}^{d \times r}$ are trainable, $r$ is the adapter rank, and $\alpha$ controls the scale. By keeping $r$ smaller than $d$ and $k$, trainable parameters drop drastically from $dk$ to approximately $r(d+k)$.

For example, a square $768 \times 768$ update contains 589,824 parameters. A rank-16 LoRA factorisation contains:

$$16(768+768)=24{,}576$$

trainable parameters—24 times fewer for that matrix. The saving depends on the matrix shape, chosen rank, and number of modules adapted.

The low-rank hypothesis is not that the original weight matrix is low rank. It is that the task-specific change $\Delta W$ can often be expressed through a much smaller number of useful directions. LoRA learns those directions while leaving $W_0$ frozen.

LoRA is commonly applied to attention projection layers and sometimes to the feed-forward projections as well. A higher rank provides more adaptation capacity but increases memory, storage, and the risk of fitting noise. Rank is therefore a model-selection parameter, not a quality setting that should always be maximised.

Initialization, Scaling, and Target Modules

LoRA must begin without disturbing the pretrained model. A common initialization gives one factor non-zero random values and initializes the other to zero. The standard Hugging Face PEFT initialization sets $A$ with random values and $B$ to zero. Because $BA=0$, the first forward pass behaves exactly like the base model.

Rank ($r$) dictates the adapter's learning capacity and parameter count, while the ratio $\alpha/r$ scales the update. There is no universally optimal ratio, so both parameters require empirical tuning for your specific dataset.

While early LoRA research focused strictly on attention projections, modern LLM recipes often target a wider array of layers, including query, key, value, and output projections, as well as the gate, up, and down projections in the feed-forward network. For our 10-K case study, setting target_modules="all-linear" ensures we target both attention and feed-forward projections without needing to hard-code model-specific layer names.

After training, you must decide how to deploy the LoRA update:

• Dynamic Swapping (Keep Separate): Highly memory-efficient if one base model serves several different tasks (e.g., swapping between a 10-K risk adapter and a general summarization adapter on the fly).
• Weight Merging (Fuse to Base): Merging the adapter into the base weights removes the separate adapter computation during inference. This is ideal when deploying a single, fixed variant dedicated purely to financial analysis.

The original method is detailed in LoRA: Low-Rank Adaptation of Large Language Models. The current PEFT implementation exposes rank, scaling, dropout, and target modules through LoraConfig (see the Hugging Face PEFT LoRA guide)

QLoRA: Reducing the Frozen Model's Memory

While LoRA reduces trainable parameters, the massive frozen base model must still be loaded into VRAM. QLoRA bridges this gap, making single-accelerator fine-tuning practical by loading the base model in 4-bit precision while training higher-precision LoRA adapters through the quantised model.

The vital distinctions are:

• Pretrained base weights are quantized to 4-bit and remain frozen.
• The LoRA adapter parameters remain trainable.
• Matrix multiplication computations occur in higher precision (e.g., BF16).

Core Mechanisms

QLoRA can make single-accelerator experiments practical, but it is not free. Quantisation introduces representation error, backend compatibility matters, and the final model must still be evaluated on the target task. The Transformers documentation recommends NF4 for training 4-bit base models.

QLoRA achieves these extreme memory savings through three specific innovations:

1. Normal Float 4-bit (NF4): A 4-bit data type mathematically optimized to match the normal distribution of pretrained neural network weights. More values near 0, and fewer values at extremes.
2. Double quantisation: Quantizing the scale constants used by the first quantisation step, further reducing metadata overhead.
3. Paged optimisers: Leveraging unified memory paging to absorb temporary optimizer memory spikes-automatically pages optimizer states to CPU RAM when GPU runs out, preventing out-of-memory crashes.

The original QLoRA paper demonstrated fine-tuning a 65-billion-parameter model on a single 48 GB GPU. That result demonstrates the method's potential, not a universal hardware guarantee. Total training memory also includes quantisation metadata, activations, LoRA parameters, optimiser state, temporary workspaces, and a workload-dependent context length; it cannot be inferred from the raw 4-bit weight size alone.

See:
QLoRA: Efficient Finetuning of Quantized LLMs
Hugging Face bitsandbytes guide

Part III: Evaluating a Fine-Tuned Model

Evaluation asks a much broader question than whether training loss decreased: did the adaptation produce a reliable, practical improvement on unseen data? Answering this requires rigorous baselines, protected test sets, task-level metrics, and error analysis.

Establishing Meaningful Baselines

Before declaring the fine-tuning a success, at minimum, compare the fine-tuned model with the unchanged model using the same test examples and decoding settings. The unchanged model should receive a strong prompt containing the task definition, output format, and, where appropriate, a small number of demonstrations.

A useful comparison can include:

1. The base model with a zero-shot prompt.
2. The base model with the strongest few-shot prompt.
3. The fine-tuned model with its intended inference prompt.

This isolation proves whether your costly training process actually generated new capabilities, or if the same result could have been achieved through clever prompting alone.

Preventing Data Leakage

Training, validation, and test data have different purposes. Training examples produce parameter updates, validation examples guide model and hyperparameter selection, and the test set provides the final estimate after those decisions have been made.

A random train/test split is dangerous when documents contain duplicates, revisions, or repeated templates. Split by the unit that could leak—for example, document, customer, company, or time period—and keep near-duplicates in the same split. The test set should also represent the conditions under which the model will be used, including difficult and negative examples.

If you split your dataset randomly by paragraph, your test set will contain near-duplicates of your training data.

• Split by Entity: Group your splits by company ticker or CIK. This ensures the model is evaluated on entirely unseen organizations.
• Preserve Distributions: Ensure your test set represents the actual production environment, including difficult edge cases and negative examples (documents where no material risks are present).

Measuring the Application Contract

Perplexity and validation loss measure token prediction; it does not measure if the application works safely. Evaluation metrics should reflect the behaviour that users depend on:

Evaluation Dimension	Example Measures
Task Accuracy	Precision, recall, F1, exact match, or field-level accuracy
Output Contract	Parse rate, schema validity, and allowed-value compliance
Grounding	Evidence validity, factual consistency, and unsupported-claim rate
Abstention	Accuracy when evidence is missing, irrelevant, or ambiguous
Robustness	Performance by input length, domain, difficulty, and unseen source
General capability	Regression tests for instruction following and unrelated tasks
Operational efficiency	Latency, throughput, memory use, and adapter storage

Not every task needs every metric. A classifier may be judged primarily by precision, recall, and calibration; a structured extraction system also needs schema and evidence checks; an open-ended assistant requires a carefully defined human-review rubric.

Deterministic checks (like JSON parsing and exact-string matching for evidence) should be fully automated. However, semantic properties—such as completeness, faithfulness, clarity, and appropriate uncertainty often require a carefully defined human-review rubric or a validated LLM-as-a-judge pipeline.

Human comparisons should use a written rubric and anonymised outputs so that reviewers do not know which system produced each response. Report results by important slices rather than only as one average, and inspect representative false positives, false negatives, hallucinations, and formatting failures.

Ultimately, a fine-tuned model is successful only when its improvement over the baseline justifies its training, evaluation, storage, and serving costs.

Part IV: Hands-On SEC 10-K Risk-Analysis Case

The analysis notebooks can be found here.

1. Problem statement, objectives, and task

Risk disclosures in Item 1A of a 10-K are valuable to analysts, compliance teams, and risk managers, but they are lengthy, repetitive, and expressed in unstructured language. Similar risks can be described differently across companies, while manual categorisation and summarisation may be inconsistent.

The proposed system is an analytical assistant rather than an investment or materiality engine. It converts a supplied disclosure passage into a structured, reviewable record. Its objectives are to:

1. reduce the effort needed to identify disclosed risks;
2. normalise those risks into a consistent schema;
3. preserve exact evidence for traceability; and
4. determine whether fine-tuning improves on a well-prompted base model.

The model receives a 10-K excerpt:

A substantial portion of our cash is held outside our home market. 
Restrictions on transferring those funds or adverse currency movements 
could reduce the amount available for domestic operations.

and outputs:

{
  "risks": [
    {
      "category": "Financial",
      "summary": "Transfer restrictions and currency movements may reduce cash available for domestic operations.",
      "evidence": "Restrictions on transferring those funds or adverse currency movements could reduce the amount available for domestic operations."
    }
  ],
  "insufficient_evidence": false
}

It must identify zero or more risks, assign an experiment-specific category, summarise each risk, copy supporting evidence, and abstain when the passage does not support an extraction. It must not use outside facts or predict whether the risk will occur. Comparing disclosures between years is a possible downstream task, but it is deliberately excluded from this first experiment.

2. The data problem

The modelling task begins with a data-engineering problem. A production pipeline would retrieve filings from SEC EDGAR, identify Item 1A, remove filing markup, split the section into coherent disclosure passages, and retain enough provenance to trace every passage back to its source. At minimum, a record should preserve the company identifier, accession number, filing date, source URL, section, and source text.

SEC EDGAR API documentation

This experiment uses synthetic disclosures so that the workflow is reproducible and redistributable. The synthetic data is suitable for testing the training and evaluation pipeline, but it cannot establish performance on real filings.

The source of truth is a canonical annotation record rather than a model-specific prompt. A simplified record looks like this:

{
  "example_id": "train_001",
  "split": "train",
  "issuer_id": "issuer_01",
  "filing_year": 2023,
  "source_text": "Restrictions on transferring those funds or adverse currency movements could reduce the amount available for domestic operations.",
  "risks": [
    {
      "category": "Financial",
      "summary": "Transfer restrictions and currency movements may reduce cash available for domestic operations.",
      "evidence": "Restrictions on transferring those funds or adverse currency movements could reduce the amount available for domestic operations."
    }
  ],
  "insufficient_evidence": false
}

The risk taxonomy is deliberately small and operational. It standardises the expected output without pretending to be a universal classification of 10-K risks:

Category	Examples of disclosed risk
Financial	Liquidity, credit, currency, interest-rate, or funding exposure
Operational	Supply-chain, manufacturing, capacity, or business-continuity disruption
Market	Demand, pricing, competition, or macroeconomic exposure
Regulatory	Laws, investigations, compliance obligations, or policy changes
Cybersecurity	Security incidents, system compromise, or data exposure
Strategic	Acquisitions, concentration, execution, or business-model risk
People	Talent retention, labour availability, leadership, or workforce risk

The dataset contains 68 examples:

Split	Examples	Design
Training	40	2022–2023 disclosures from development issuers
Validation	12	2024 disclosures from the same issuers
Test	16	2025 disclosures from entirely held-out issuers

All splits contain positive, negative, and multi-risk examples. Negative examples teach abstention; multi-risk examples prevent the model from assuming that every passage contains exactly one label. Evidence must be copied exactly from the source text, which makes grounding mechanically verifiable.

The split is designed to reduce leakage. Development issuers appear only in the training and validation sets, while test issuers are held out completely. Normalised passages are also compared across splits so that near-duplicate language cannot turn evaluation into memorisation.

Only after these checks is each canonical record converted into the conversational prompt-completion structure required for SFT:

{
  "prompt": [
    {"role": "system", "content": "Extract only risks supported by the supplied 10-K excerpt..."},
    {"role": "user", "content": "<10-K excerpt>"}
  ],
  "completion": [
    {"role": "assistant", "content": "{\"risks\": [...], \"insufficient_evidence\": false}"}
  ]
}

Keeping canonical annotations separate from rendered prompts makes it possible to change a chat template or model family without rewriting the labels. Before training, the pipeline validates the schema, category values, exact evidence spans, abstention logic, split membership, near-duplicate controls, and token lengths.

3. Methodology: a controlled LoRA–QLoRA comparison

The experiment starts from Qwen/Qwen3-0.6B. It is an instruction-following causal language model small enough for an accessible demonstration while still supporting the chat-template and structured-generation workflow used by larger models. Starting from an instruction model is intentional: the experiment is specialising an existing assistant for a constrained extraction behaviour, not trying to teach a base model how to follow instructions from a small dataset.

Two adapters are trained against the same checkpoint and data. The ordinary LoRA run keeps the frozen base weights in BF16 or FP16. The QLoRA run stores those frozen weights in four-bit NF4 and performs adapter computation at a higher precision. In both cases, the trainable update is LoRA.

Setting	Value
Task	Grounded multi-risk extraction to JSON
Base checkpoint	Qwen/Qwen3-0.6B
Training objective	Completion-only causal language modelling
LoRA rank and alpha	r=16, alpha=32
Target modules	All linear attention and feed-forward projections
Context limit	1,024 tokens
Evaluation systems	Base zero-shot, base few-shot, LoRA, and QLoRA

The intended experimental difference is therefore how the frozen base model is stored during training:

Training arm	Frozen base model	Trainable parameters
LoRA	BF16 or FP16	LoRA adapter
QLoRA	Four-bit NF4 with double quantisation	LoRA adapter

To make the comparison meaningful, both arms use the same dataset splits, prompt format, maximum sequence length, rank, scaling, target modules, optimiser settings, random seed, and evaluation protocol. The LoRA configuration is:

lora_config = LoraConfig(
    task_type="CAUSAL_LM", # The model performs causal next-token generation
    r=16,                  # Capacity and size of the low-rank update
    lora_alpha=32,         # Scale applied to that update
    lora_dropout=0.05,     # Regularisation
    target_modules="all-linear", # Model layers receiving LoRA adapters, generally including: attention and feed-forward network
    bias="none",           # Whether existing bias parameters are trained
)

target_modules="all-linear" applies adapters to the model's linear attention and feed-forward projections. It is convenient for this experiment because it avoids hard-coding architecture-specific module names, although a production study should still inspect the matched modules and report them.

This is not a comparison between two different adapter algorithms. QLoRA still trains LoRA parameters; quantisation reduces the memory required to keep the frozen base model available during training. The expected trade-off is lower peak memory, potentially accompanied by a small change in training dynamics.

The controlled question is therefore whether QLoRA reduces peak training memory without materially reducing extraction accuracy, grounding, or schema compliance relative to ordinary LoRA.

4. Training with completion-only SFT

Each training arm uses the same prepared prompt-completion records and LoRA configuration. The experiment is controlled by a TRAINING_METHOD flag; only the frozen base-model loading path changes.

For QLoRA, we dynamically inject a 4-bit quantization configuration:

if TRAINING_METHOD == "qlora":
    load_kwargs["quantization_config"] = BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_quant_type="nf4",
        bnb_4bit_use_double_quant=True,
        bnb_4bit_compute_dtype=compute_dtype,
    )

Configuring the Trainer

The tutorial configuration uses five epochs, a learning rate of 2e-4, an adapter rank of 16, and memory-saving techniques like gradient accumulation and checkpointing. A maximum sequence length of 1024 accommodates the SEC excerpts. These are experiment settings rather than universal defaults.

The trainer receives the conversational records and is explicitly instructed to use completion-only loss:

training_args = SFTConfig(
    learning_rate=2e-4,
    num_train_epochs=5,
    per_device_train_batch_size=1,
    gradient_accumulation_steps=4,
    gradient_checkpointing=True,
    max_length=1024,
    completion_only_loss=True,
    eval_strategy="epoch",
    save_strategy="epoch",
)

trainer = SFTTrainer(
    model=model,
    args=training_args,
    processing_class=tokenizer,
    train_dataset=dataset["train"],
    eval_dataset=dataset["validation"],
)

Passing processing_class=tokenizer is critical: it tells the trainer how to apply the chat template, render the strings, and convert them into token IDs.

Understanding the Training Batch Tensors

Behind the scenes, trainer.get_train_dataloader() constructs the batches that enter the model. Each batch is composed of three aligned integer matrices, typically with the shape [batch_size, sequence_length].

Tensor	Purpose
input_ids	Vocabulary index integers representing the rendered system message, user excerpt, and assistant completion.
attention_mask	Contains 1 for real tokens and 0 for padding, telling the attention mechanism which positions to ignore.e
labels	The target tokens used for gradient calculation. Prompt and padding positions are set to -100.

Here is a conceptual look at a single training row showing how completion-only loss masks the prompt:

Position	Content	input_ids	attention_mask	labels (Target)
0	System	101	1	-100 (Ignored)
1	User	205	1	-100 (Ignored)
2	User	301	1	-100 (Ignored)
3	Assistant	401	1	401 (Supervised)
4	Assistant	402	1	402 (Supervised)
5	Padding	0	0	-100 (Ignored)

While the visual representation above is simplified, understanding the mechanics of these tensors is essential for debugging:

• The Causal Shift: Notice that at supervised positions (3 and 4), the labels ID is identical to the input_ids value. This is because PyTorch's causal language modeling loss internally shifts the labels by one position. The model's prediction at position $t$ is evaluated against the label at position $t+1$.

• Dynamic Padding: With per_device_train_batch_size=1, each matrix has exactly one row. If the batch size increases, shorter examples are dynamically padded to match the longest sequence in that specific batch. The sequence length is capped at 1,024, but most batches will be narrower than that.

• Indices vs. Embeddings: The input_ids matrix does not contain dense vector embeddings. It contains simple vocabulary indices that the model uses to look up the actual embeddings, which then produce a hidden-state tensor of shape [batch_size, sequence_length, d_model].

Finally, each run records the model identifier, random seed, LoRA settings, trainable parameters, peak GPU memory, and training duration. While validation loss is logged to monitor optimization health, it does not replace the rigorous task-level evaluation detailed in Part III.

Each run records the model identifier, random seed, LoRA settings, library versions, trainable and total parameters, training duration, peak GPU memory, and trainer metrics. Validation loss monitors optimisation; it does not replace task-level evaluation.

5. Evaluation and base-model comparison

The evaluation protocol is designed to compare four systems under the same held-out data, output limit, and deterministic decoding policy:

1. the unchanged base model with a zero-shot instruction;
2. the unchanged base model with representative positive and negative examples;
3. the LoRA adapter; and
4. the QLoRA adapter.

The completed run used Qwen/Qwen3-0.6B and all 16 held-out synthetic examples from eight issuers. Inference ran in FP16 on Apple MPS. Both adapters were loaded separately onto the same higher-precision base checkpoint used by the baselines. The comparison therefore measures the behaviour learned by each adapter rather than comparing FP16 and 4-bit inference.

Metric	What it tests
JSON and schema validity	Whether downstream code can safely consume the response.
Risk precision, recall, and F1	Whether labelled risks are extracted without extras or omissions.
Category macro F1	Whether performance extends beyond the most frequent category.
Evidence validity	Whether each quoted span explicitly occurs in the supplied excerpt.
Unsupported-evidence rate	How often generated evidence is hallucinated.
Abstention accuracy	Whether non-risk passages are rejected correctly.
Latency and tokens per second	Runtime cost under the declared test setup.
Peak training memory and duration	Training-resource footprint (comparable only on identical hardware).
Adapter size	Per-task storage requirement.

Note: Invalid JSON, unsupported evidence, and missed risks are explicitly decoupled. A schema failure is a formatting error, not automatically a hallucinated claim. The automated metrics below precede our blinded human-review rubric for summary faithfulness.

Quality Results

System	JSON valid	Schema valid	Risk precision	Risk recall	Risk F1	Category macro F1	Evidence valid	Abstention accuracy
Base, zero-shot	100.0%	56.3%	11.1%	6.7%	8.3%	2.4%	100.0%	43.8%
Base, few-shot	100.0%	100.0%	33.3%	20.0%	25.0%	20.0%	100.0%	81.3%
LoRA adapter	100.0%	100.0%	63.6%	46.7%	53.8%	76.2%	100.0%	100.0%
QLoRA adapter	100.0%	100.0%	58.3%	46.7%	51.9%	70.1%	91.7%	93.8%

Few-shot prompting was already a much stronger baseline than the zero-shot instruction. Relative to that stronger baseline, Both adapters maintained perfect schema validity. LoRA significantly outperformed the strong few-shot baseline, boosting risk F1 by 28.8 points and abstention accuracy by 18.8 points. QLoRA followed closely. While LoRA retained a slight edge in precision and grounding over QLoRA, the small sample size ($n=16$) means these figures serve to demonstrate our pipeline's analytical rigor rather than proving general algorithmic superiority.

Efficiency Results

System	Mean latency	Output tokens/s	Adapter size	Peak training memory	Training time
Base, zero-shot	1.47 s	58.90	—	—	—
Base, few-shot	0.72 s	54.30	—	—	—
LoRA adapter	1.19 s	36.67	49.46 MiB	Not recorded	63.63 s
QLoRA adapter	1.25 s	36.41	49.46 MiB	1.63 GiB	84.84 s

Latency was measured sequentially on Apple MPS and includes varying output lengths and unmerged PEFT overhead. Consequently, these figures serve as an observational baseline rather than a hardware-independent benchmark. Both adapters predictably share an identical 49.46 MiB footprint; 4-bit quantization compresses the frozen base model during training, but does not alter the saved adapter's dimensions.

Similarly, the training times (63.63s for LoRA; 84.84s for QLoRA) and memory allocations (a 1.27 GiB end-of-run snapshot for LoRA versus a 1.63 GiB recorded peak for QLoRA) strictly reflect this specific MPS environment. Because the memory profiling captured different lifecycle phases, these values do not provide a controlled baseline for quantifying QLoRA's memory savings.

The Path to Production

Aggregate metrics only tell part of the story. Meaningful evaluation requires slicing errors across sectors, risk categories, negative examples, and multi-risk passages. While our 16-example synthetic dataset successfully validates the evaluation mechanics, proving true production readiness demands significantly more rigor, including:

• An expansive, strictly held-out test set of manually reviewed EDGAR excerpts.
• Systematic uncertainty estimation and blinded domain review.
• Broad regression testing outside the core extraction task.

Ultimately, fine-tuning earns its place in the stack only if an adapter demonstrably outperforms the strongest reasonable prompting baseline, flawlessly preserves evidence grounding, and delivers a performance gain that explicitly justifies the added operational complexity.

結構化訊息
        ↓ 模型專屬的聊天樣板
[system 控制符號]     指令
[user 控制符號]       請求
[assistant 控制符號]  回應
        ↓ 分詞器（tokenizer）
訓練用的 Token ID

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.1")
chat = [
  {"role": "system", "content": "You are a financial assistant."},
  {"role": "user", "content": "Analyze this 10-K excerpt."},
  {"role": "assistant", "content": "{\"risks\": [...]}"}
]

# 這會輸出一個帶有控制符號、格式正確的扁平字串
tokenizer.apply_chat_template(chat, tokenize=False)

Token：  [系統指令]     [使用者提示]     [助理回應]
標籤：   [   -100   ]   [   -100   ]     [ 在此計算損失 ]

A substantial portion of our cash is held outside our home market. 
Restrictions on transferring those funds or adverse currency movements 
could reduce the amount available for domestic operations.

{
  "risks": [
    {
      "category": "Financial",
      "summary": "Transfer restrictions and currency movements may reduce cash available for domestic operations.",
      "evidence": "Restrictions on transferring those funds or adverse currency movements could reduce the amount available for domestic operations."
    }
  ],
  "insufficient_evidence": false
}

{
  "example_id": "train_001",
  "split": "train",
  "issuer_id": "issuer_01",
  "filing_year": 2023,
  "source_text": "Restrictions on transferring those funds or adverse currency movements could reduce the amount available for domestic operations.",
  "risks": [
    {
      "category": "Financial",
      "summary": "Transfer restrictions and currency movements may reduce cash available for domestic operations.",
      "evidence": "Restrictions on transferring those funds or adverse currency movements could reduce the amount available for domestic operations."
    }
  ],
  "insufficient_evidence": false
}

{
  "prompt": [
    {"role": "system", "content": "Extract only risks supported by the supplied 10-K excerpt..."},
    {"role": "user", "content": "<10-K excerpt>"}
  ],
  "completion": [
    {"role": "assistant", "content": "{\"risks\": [...], \"insufficient_evidence\": false}"}
  ]
}

lora_config = LoraConfig(
    task_type="CAUSAL_LM", # 模型執行的是因果式的下一個 token 生成
    r=16,                  # 低秩更新量的容量與大小
    lora_alpha=32,         # 套用在該更新量上的縮放係數
    lora_dropout=0.05,     # 正則化（regularisation）
    target_modules="all-linear", # 套用 LoRA adapter 的模型層，一般包含注意力機制與前饋網路
    bias="none",           # 是否訓練既有的 bias 參數
)

if TRAINING_METHOD == "qlora":
    load_kwargs["quantization_config"] = BitsAndBytesConfig(
        load_in_4bit=True,
        bnb_4bit_quant_type="nf4",
        bnb_4bit_use_double_quant=True,
        bnb_4bit_compute_dtype=compute_dtype,
    )

training_args = SFTConfig(
    learning_rate=2e-4,
    num_train_epochs=5,
    per_device_train_batch_size=1,
    gradient_accumulation_steps=4,
    gradient_checkpointing=True,
    max_length=1024,
    completion_only_loss=True,
    eval_strategy="epoch",
    save_strategy="epoch",
)

trainer = SFTTrainer(
    model=model,
    args=training_args,
    processing_class=tokenizer,
    train_dataset=dataset["train"],
    eval_dataset=dataset["validation"],
)