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.
|
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.
|
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.
|
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.
|
Test reports contain the commit id to track changes in the challenges.
|
||||||
|
|
||||||
### Repository Structure
|
|
||||||
|
|
||||||
The repository contains:
|
The repository contains:
|
||||||
- Source code for SIA and its tools
|
- Source code for SIA and its tools
|
||||||
- Procedures for handling various tasks
|
- Procedures for handling various tasks
|
||||||
- Training configuration and data
|
- Training configuration and data
|
||||||
- Test results and analysis
|
- 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
|
## Continuous Operation
|
||||||
|
|
||||||
While working on improvements, SIA must maintain its core functionality:
|
While working on improvements, SIA must maintain its core functionality:
|
||||||
|
|||||||
Reference in New Issue
Block a user