Improved self improvement finetune info
This commit is contained in:
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user