Skip to main content

Documentation Index

Fetch the complete documentation index at: https://threatbasis.io/llms.txt

Use this file to discover all available pages before exploring further.

Fine-tuning adapts pre-trained LLMs to specific security tasks by training on domain-specific data. While prompting and RAG solve most security AI needs, fine-tuning offers distinct advantages for high-volume, specialized tasks where consistent behavior and reduced latency justify the investment. Security teams typically consider fine-tuning when they need models that deeply understand organizational terminology, reliably follow specific output formats, or perform specialized classification tasks at scale. The decision to fine-tune should not be taken lightly. Fine-tuning requires significant upfront investment in training data curation, compute resources, and ongoing model management. However, for the right use cases—such as alert classification, log parsing, or compliance-sensitive outputs—fine-tuned models can deliver substantial improvements in accuracy, consistency, and response time compared to general-purpose prompting approaches.

​
When to Fine-Tune

The most important decision in LLM customization is choosing between prompting, RAG, and fine-tuning. Each approach involves different trade-offs between investment, flexibility, and performance. Prompting offers the lowest barrier to entry and highest flexibility, making it ideal for prototyping and varied tasks. You can iterate quickly on prompts without any training infrastructure, but may hit limits on complex tasks requiring deep domain understanding. Retrieval-Augmented Generation (RAG) excels at knowledge-intensive tasks where the model needs access to current or organization-specific information. RAG keeps knowledge separate from model weights, allowing updates without retraining. For most security AI applications involving documentation, threat intelligence, or procedural knowledge, RAG is the preferred approach. Fine-tuning makes sense when you need highly consistent behavior across thousands of similar requests, specialized understanding of domain terminology, or reduced latency by eliminating lengthy prompts. The investment is substantial—you need quality training data, compute resources, and ongoing maintenance—but the payoff can be significant for the right use cases.

​
Strong Indicators for Fine-Tuning

Fine-tuning is most likely to succeed when multiple indicators align:
  • Consistent format requirements — When outputs must strictly conform to a specific schema or label set, such as alert classification into predefined severity categories
  • Domain-specific terminology — When the model needs to understand organization-specific asset names, internal systems, or specialized security vocabulary
  • High-volume processing — When you’re processing thousands of similar requests daily, such as automated log analysis or bulk alert triage
  • Latency constraints — When you need to reduce response time by eliminating lengthy system prompts and few-shot examples
  • Behavior consistency — When compliance or operational requirements demand predictable, reproducible outputs

​
When to Avoid Fine-Tuning

Equally important is recognizing when fine-tuning is the wrong approach. Avoid fine-tuning when requirements change frequently—updating fine-tuned models is expensive and time-consuming. For knowledge-intensive tasks where information evolves, RAG provides far more flexibility. If you have fewer than a few hundred high-quality training examples, you’ll likely overfit. Most critically, validate your use case with prompting and RAG before committing to fine-tuning; many teams discover they can achieve adequate results without the fine-tuning investment.

​
Fine-Tuning Approaches

Several approaches exist for adapting LLMs, each with different compute requirements, data needs, and appropriate use cases.

​
Full Fine-Tuning

Full fine-tuning updates all model parameters using your training data. This approach offers maximum customization but requires substantial compute resources—training a 7B parameter model demands multiple high-end GPUs. Full fine-tuning makes sense only when you have large datasets (tens of thousands of examples), significant compute budget, and require deep behavioral changes. Most security teams should not pursue full fine-tuning.

​
LoRA and QLoRA

Low-Rank Adaptation (LoRA) is the most practical approach for security teams. Rather than updating all model weights, LoRA trains small “adapter” layers that modify the model’s behavior while keeping base weights frozen. This dramatically reduces compute requirements—you can fine-tune models on consumer GPUs—while achieving comparable results to full fine-tuning for many tasks. QLoRA extends this further by quantizing the base model to 4-bit precision, enabling fine-tuning of larger models on limited hardware. A security team could fine-tune a 70B parameter model on a single GPU using QLoRA, something impossible with full fine-tuning. LoRA adapters are also composable—you can train different adapters for different security tasks (alert classification, log parsing, report generation) and swap them at inference time while sharing the same base model. This modularity simplifies model management and enables task-specific optimization.

​
Instruction Tuning

Instruction tuning trains models to follow specific types of instructions more reliably. Rather than teaching new knowledge, instruction tuning aligns model behavior with your desired interaction patterns. This is useful when you need consistent formatting, specific reasoning approaches, or reliable tool use. OpenAI’s fine-tuning API and similar offerings are essentially instruction tuning services.

​
Continued Pre-Training

For organizations with large security document corpora (threat reports, incident histories, internal documentation), continued pre-training exposes the model to domain-specific text before fine-tuning on task examples. This helps the model understand security concepts, terminology, and writing styles before task-specific training. Continued pre-training requires significant data volume and compute but can improve performance on domain-specific tasks.

​
Training Data Preparation

Training data quality determines fine-tuning success more than any other factor. Poor data produces poor models, regardless of how sophisticated your training approach.

​
Data Requirements

Effective fine-tuning typically requires 100 to 10,000 examples depending on task complexity. Simple classification tasks may work with a few hundred examples, while complex generation tasks need thousands. More important than quantity is quality—inaccurate labels, inconsistent formatting, or ambiguous examples will degrade model performance. Every training example should be reviewed by domain experts. Security analysts should validate that alert classifications are correct, that investigation summaries capture key findings, and that recommended actions are appropriate. Automated data collection without expert review typically produces training data too noisy for effective fine-tuning. Training examples must also cover the full distribution of cases the model will encounter, including edge cases and rare scenarios. A model trained only on common alert types will fail when encountering unusual situations. Actively seek out difficult examples during data collection.

​
Security-Specific Data Considerations

Security training data carries particular sensitivity. Historical incidents contain details about vulnerabilities, attack techniques, and organizational weaknesses. Alert data may include IP addresses, hostnames, and user information. Threat reports reference sensitive intelligence sources. Before training, thoroughly sanitize data to remove personally identifiable information (PII), credentials, customer data, and operationally sensitive details. Replace specific identifiers with anonymized placeholders while preserving the semantic content needed for training. Document your data provenance and sanitization procedures for audit purposes. Be aware that fine-tuned models can memorize and potentially leak training data. Research has demonstrated extraction of training data from fine-tuned models through adversarial prompting. Treat your fine-tuned model as containing sensitive data equivalent to its training set and apply appropriate access controls.

​
Data Sources for Security Fine-Tuning

Historical incidents provide rich training data—investigation notes, analyst reasoning, and resolution steps capture expert knowledge valuable for training. Alert disposition records (the alert details paired with analyst decisions) are ideal for classification tasks. Threat intelligence reports can train analytical writing capabilities. Runbook executions demonstrate procedural reasoning. In all cases, expert curation and annotation improve data quality significantly.

​
Evaluation and Testing

Rigorous evaluation separates successful fine-tuning from wasted effort. Without proper evaluation, you won’t know if fine-tuning improved performance or introduced subtle regressions.

​
Evaluation Strategy

Establish baseline performance before fine-tuning by measuring how well prompting or RAG approaches perform on your test set. This baseline lets you quantify fine-tuning improvements and detect regressions. Create held-out test sets that the model never sees during training. Include representative examples across all categories and intentionally challenging edge cases. Evaluate on this test set after each training run to track progress and detect overfitting. For classification tasks, measure accuracy, precision, recall, and F1 score across all categories. Pay particular attention to rare but important categories—high overall accuracy can mask poor performance on critical edge cases. For generation tasks, evaluate output format compliance (does the model follow your schema?), factual accuracy (are claims correct?), and consistency (do similar inputs produce similar outputs?).

​
Security-Specific Evaluation

Fine-tuned security models require additional evaluation beyond standard metrics. Test adversarial inputs to verify the model resists prompt injection attacks—fine-tuning can sometimes increase or decrease injection resistance compared to base models. Verify the model doesn’t hallucinate false positives for threats or miss genuine indicators. Test consistency by running the same inputs multiple times to ensure reproducible outputs for compliance-sensitive applications. Red team your fine-tuned model before production deployment. Attempt to extract training data through adversarial prompting. Test whether the model leaks organizational details embedded in training examples. Verify guardrails remain effective after fine-tuning.

​
Operational Considerations

Fine-tuning creates ongoing operational responsibilities beyond initial training.

​
Model Management

Treat model development with the same rigor as software engineering. Version control your training data, hyperparameters, and resulting model weights. Document what data was used, when training occurred, and what evaluation results were achieved. This documentation enables debugging when model behavior changes and satisfies audit requirements. Deploy fine-tuned models alongside base models to enable A/B comparison in production. Monitor performance metrics continuously—accuracy can degrade as data distributions shift. Establish rollback procedures to revert to previous model versions if issues emerge. Plan for retraining. The security landscape evolves, new attack techniques emerge, and organizational infrastructure changes. Fine-tuned models need periodic updates to remain effective. Establish a retraining cadence based on how quickly your domain evolves—quarterly updates may suffice for some applications while others need monthly refreshes.

​
Security and Compliance

Fine-tuned models require security controls appropriate to their training data sensitivity. If training data contained sensitive security information, the model weights themselves should be treated as sensitive assets. Control access to model endpoints, secure model storage, and audit model usage. For regulated environments, document the complete model lifecycle including data sources, preprocessing steps, training procedures, and evaluation results. Demonstrate that training data was handled appropriately under relevant privacy regulations. Consider data residency requirements when selecting training infrastructure—some regulations may prohibit training on foreign infrastructure.

​
Common Pitfalls

Premature fine-tuning remains the most common mistake. Teams invest in fine-tuning before validating that simpler approaches are insufficient. Always demonstrate that prompting and RAG cannot meet your requirements before committing to fine-tuning. Insufficient training data leads to overfitting—the model memorizes training examples rather than learning generalizable patterns. If you can’t assemble at least a few hundred high-quality examples, fine-tuning is unlikely to succeed. Ignoring evaluation causes teams to deploy underperforming models. Without rigorous testing on held-out data, you can’t distinguish genuine improvement from training set memorization. Training on sensitive data without proper sanitization creates data leakage risks. Models can memorize and regurgitate training data through adversarial prompting. One-time training fails to account for domain evolution. Without planned retraining, model performance degrades as threats, tools, and procedures evolve.

​
References

​
Fine-Tuning Platforms

​
Efficient Fine-Tuning Techniques

​
Evaluation and Safety