Improved self improvement finetune info

This commit is contained in:
Niels Geens
2025-01-24 11:41:02 +01:00
parent 4fcb32e6a1
commit 1cd483fd3a

View File

@@ -267,7 +267,64 @@ Each entry in the initial context uses relative timestamps (offsets from the sta
When SIA executes these entries, they automatically align with the new instance's timeline.
This preserves the temporal relationships between entries while anchoring them to the test instance's actual start time.
## Version Control and Configuration
## Training Configuration
SIA takes a modular approach to model training by having separate specialized tools for each provider like train_mistral.py, train_openai.py, etc.
Each tool shares similar core functionality while handling provider-specific requirements.
While the training process is conceptually similar across providers, each has unique requirements for data formatting, API interactions, and job management.
By creating dedicated tools, we can properly encapsulate these differences without complicating the core training logic.
For example, Mistral needs JSONL files with specific message structures, while other providers might require different formats or metadata.
Training configuration should be consistent regardless of the provider.
All training tools read from the same config.yaml format, which defines essential parameters like the system prompt, action schema, and training data paths.
These parameters represent fundamental aspects of how we want the model to behave, independent of which provider handles the actual training.
The tools then translate these standard parameters into provider-specific settings.
Training tools enforce important safeguards around version control.
Before starting a training run, each tool verifies that all source files - including the config itself, training data, system prompt, and action schema - are committed to git.
This ensures reproducibility by guaranteeing we can recreate the exact training conditions that produced any given model.
The git commit hash becomes part of the internal tracking of model versions.
The tools follow a common workflow:
1. Read and validate the standard config.yaml format
2. Check that all source files are committed to git
3. Convert training data into the provider's required format
4. Upload data through the provider's API
5. Start training with the specified parameters
6. Return job information for monitoring progress
This separation of concerns makes it easier to:
- Add support for new training providers without changing existing code
- Maintain consistent training configuration across different providers
- Track and reproduce training runs reliably
- Handle provider-specific error cases and requirements appropriately
- Update individual providers' implementations as their APIs evolve
### Example
Config file:
```yaml
model:
system_prompt_path: "system_prompt.md"
action_schema: "action_schema.xsd"
params:
learning_rate: 1e-5
epochs: 3
data:
- "training/clean_start/"
- "training/delete_indicated_entries/"
- "training/list_entries_to_delete/"
```
Training command:
```bash
python train_mistral.py --model mistral-large-latest
```
## Repository Structure
All components that define SIA's behavior are version controlled in a single repository, providing a clear and reproducible state for any point in time.
@@ -283,31 +340,12 @@ This is used in two ways:
Test reports contain the commit id to track changes in the challenges.
### Repository Structure
The repository contains:
- Source code for SIA and its tools
- Procedures for handling various tasks
- Training configuration and data
- Test results and analysis
### Training Configuration
The training configuration is defined in `/training/config.yaml`, which specifies:
```yaml
model:
system_prompt_path: "system_prompt.md"
action_schema: "action_schema.xsd"
params:
learning_rate: 1e-5
epochs: 3
data:
- "training/clean_start/"
- "training/delete_indicated_entries/"
- "training/list_entries_to_delete/"
```
## Continuous Operation
While working on improvements, SIA must maintain its core functionality: