added to wip self improvement
This commit is contained in:
@@ -145,7 +145,7 @@ challenges/
|
|||||||
└── score_tracker/
|
└── score_tracker/
|
||||||
├── description.md # Core challenge: create card game score tracker
|
├── description.md # Core challenge: create card game score tracker
|
||||||
├── initial_context/
|
├── initial_context/
|
||||||
│ │ ├── context.xml # Initial context with SIA in conversation with the user
|
│ ├── context.xml # Initial context with SIA in conversation with the user
|
||||||
│ ├── user_request.txt # "Need tool to track card game scores"
|
│ ├── user_request.txt # "Need tool to track card game scores"
|
||||||
│ ├── tool_directory.txt # Shows where tools are stored and basic structure
|
│ ├── tool_directory.txt # Shows where tools are stored and basic structure
|
||||||
│ └── example_tool/ # Simple tool showing expected structure/style
|
│ └── example_tool/ # Simple tool showing expected structure/style
|
||||||
|
|||||||
@@ -1,54 +1,243 @@
|
|||||||
I'm working on the self improvement procedure.
|
# Self Improvement Design Rationale
|
||||||
I want to think about the testing Framework. How to run challenge tests and how to validate improvements.
|
|
||||||
To do so we need to know how to track progress. What metrics to collect and how to store these results.
|
|
||||||
To run a challenge a new SIA instance needs to be started and managed.
|
|
||||||
This instance needs to have its own environment and be able to communicate with the controlling instance.
|
|
||||||
Or we could have a managing instance and an instance under test, both managed by the main instance.
|
|
||||||
How do you suggest we handle all aspects of testing?
|
|
||||||
|
|
||||||
2. **Training Data Management**
|
This document explains how SIA improves itself through systematic learning and adaptation. It covers both the theoretical foundations and practical implementation details of the self-improvement system.
|
||||||
- Organizing labeled iterations
|
|
||||||
- Storing validation notes
|
|
||||||
- Managing finetuning data
|
|
||||||
- Tracking training results
|
|
||||||
|
|
||||||
3. **Progress Tracking**
|
## Core Philosophy
|
||||||
- What metrics to collect
|
|
||||||
- How to store results
|
|
||||||
- When to update progress
|
|
||||||
- How to resume interrupted work
|
|
||||||
|
|
||||||
3. **Testing Framework**
|
SIA operates as a learning system that constantly seeks to enhance its capabilities while maintaining stable and reliable operation. This improvement happens through several complementary mechanisms, each serving different aspects of the system's evolution.
|
||||||
- How to run challenge tests
|
|
||||||
- What to measure and track
|
|
||||||
- How to validate improvements
|
|
||||||
- When to run regression tests
|
|
||||||
|
|
||||||
## Common Mistakes to Avoid
|
### Improvement Mechanisms
|
||||||
|
|
||||||
1. **Context Management**
|
The system can improve in several ways:
|
||||||
- Keeping too much history in context
|
|
||||||
- Losing track of current state after interruptions
|
|
||||||
- Missing important user information
|
|
||||||
- Not cleaning up unused entries
|
|
||||||
|
|
||||||
2. **Resource Usage**
|
1. LLM Finetuning
|
||||||
- Running expensive tests during user interaction
|
The foundation of SIA's intelligence is its Large Language Model. Through careful analysis of its performance, SIA identifies cases where its reasoning or actions could have been better. These examples, when properly validated and organized, become valuable training data for improving the model's capabilities.
|
||||||
- Accumulating too much training data
|
|
||||||
- Not cleaning up after experiments
|
|
||||||
- Overloading system resources
|
|
||||||
|
|
||||||
3. **Improvement Strategy**
|
2. Source Code Evolution
|
||||||
- Making changes without clear benefits
|
SIA can modify its own Python source code, enabling both architectural and functional improvements. When stopped, SIA restarts and reloads the Python files, allowing code changes to take effect. While powerful, this capability requires robust validation to prevent system instability.
|
||||||
- Breaking existing capabilities
|
|
||||||
- Over-optimizing edge cases
|
|
||||||
- Not documenting why changes work
|
|
||||||
- Losing track of improvements after interruptions
|
|
||||||
|
|
||||||
4. **Training Data**
|
3. Procedure Refinement
|
||||||
- Mixing good and bad examples
|
Procedures provide guided reasoning paths for complex tasks. By analyzing its operational history, SIA can identify common patterns and create new procedures or optimize existing ones. This improves consistency and efficiency while carrying lower risk than direct code modifications.
|
||||||
- Not validating training data
|
|
||||||
- Missing important context
|
|
||||||
- Duplicating existing data
|
|
||||||
|
|
||||||
|
4. Tool Development
|
||||||
|
SIA can develop new tools and enhance existing ones, expanding its capabilities by creating new ways to interact with systems and data.
|
||||||
|
|
||||||
|
## Challenge-Based Testing
|
||||||
|
|
||||||
|
To improve systematically, SIA uses challenges that formalize specific capabilities into testable scenarios. These serve multiple purposes:
|
||||||
|
- Testing specific capabilities
|
||||||
|
- Validating improvements
|
||||||
|
- Detecting regressions
|
||||||
|
- Guiding learning
|
||||||
|
- Documenting known limitations
|
||||||
|
|
||||||
|
### Challenge Structure
|
||||||
|
|
||||||
|
Each challenge consists of:
|
||||||
|
|
||||||
|
1. Description
|
||||||
|
- Clear statement of what capability is being tested
|
||||||
|
- Why this capability matters
|
||||||
|
- Success criteria
|
||||||
|
- Resource constraints
|
||||||
|
|
||||||
|
2. Initial Context
|
||||||
|
- Minimal but complete starting state
|
||||||
|
- Required user information
|
||||||
|
- System files and directories needed
|
||||||
|
- Clear separation between essential context and noise
|
||||||
|
|
||||||
|
3. Validation
|
||||||
|
- Precise success criteria
|
||||||
|
- Resource limits (CPU, memory, time)
|
||||||
|
- Required outputs or state changes
|
||||||
|
- What to measure or track
|
||||||
|
|
||||||
|
### Example Challenges
|
||||||
|
|
||||||
|
1. Time Series Analysis Challenge
|
||||||
|
Tests if SIA can effectively analyze large amounts of time series data spread across multiple files. This tests:
|
||||||
|
- Efficient file handling
|
||||||
|
- Context management with size constraints
|
||||||
|
- Data analysis capabilities
|
||||||
|
- Resource-aware processing
|
||||||
|
|
||||||
|
2. Tool Development Challenge
|
||||||
|
Tests if SIA can develop a score tracking tool based on vague user requirements. This tests:
|
||||||
|
- Requirements gathering through questions
|
||||||
|
- Software design capabilities
|
||||||
|
- User interface development
|
||||||
|
- Integration with existing systems
|
||||||
|
- Documentation skills
|
||||||
|
|
||||||
|
### Challenge Directory Structure
|
||||||
|
|
||||||
|
Challenges are organized consistently:
|
||||||
|
|
||||||
|
```
|
||||||
|
challenges/
|
||||||
|
├── timeseries_analysis/
|
||||||
|
│ ├── description.md # Core challenge description
|
||||||
|
│ ├── initial_context/
|
||||||
|
│ │ ├── context.xml # Initial context with conversation
|
||||||
|
│ │ ├── user_request.txt # Initial user prompt
|
||||||
|
│ │ ├── available_paths.txt # File system setup
|
||||||
|
│ │ └── data_generator.py # Test data generation
|
||||||
|
│ │
|
||||||
|
│ ├── validation/
|
||||||
|
│ │ ├── criteria.md # Success metrics and limits
|
||||||
|
│ │ ├── setup.sh # Environment preparation
|
||||||
|
│ │ └── known_patterns.md # Expected findings
|
||||||
|
│ │
|
||||||
|
│ └── answers/ # Standard responses
|
||||||
|
└── data_format.txt # File format details
|
||||||
|
```
|
||||||
|
|
||||||
|
## Version Control and Configuration
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
### Repository Structure
|
||||||
|
|
||||||
|
The repository contains:
|
||||||
|
- Source code for SIA and its tools
|
||||||
|
- Procedures for handling various tasks
|
||||||
|
- Training configuration and metadata
|
||||||
|
- References to training data
|
||||||
|
- Test results and analysis
|
||||||
|
|
||||||
|
### Training Configuration
|
||||||
|
|
||||||
|
The training configuration is defined in `/training/config.yaml`, which specifies:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
model:
|
||||||
|
name: "claude-3-sonnet-20240422"
|
||||||
|
context_length: 100000
|
||||||
|
temperature: 0.7
|
||||||
|
system_prompt_path: "training/prompts/system.txt"
|
||||||
|
|
||||||
|
training_data:
|
||||||
|
conversations:
|
||||||
|
- path: "training/data/general/basic_interactions/"
|
||||||
|
description: "General user interactions"
|
||||||
|
hash: "abc123"
|
||||||
|
tasks:
|
||||||
|
- path: "training/data/code_generation/"
|
||||||
|
description: "Code writing examples"
|
||||||
|
hash: "def456"
|
||||||
|
|
||||||
|
training_params:
|
||||||
|
batch_size: 32
|
||||||
|
learning_rate: 1e-5
|
||||||
|
epochs: 3
|
||||||
|
|
||||||
|
evaluation:
|
||||||
|
metrics:
|
||||||
|
- "accuracy"
|
||||||
|
- "response_coherence"
|
||||||
|
challenge_subset: ["code_gen", "file_ops"]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Testing Framework Design
|
||||||
|
|
||||||
|
### Process Isolation
|
||||||
|
|
||||||
|
Tests run in isolated environments using Bubblewrap, which provides:
|
||||||
|
- Lightweight process isolation
|
||||||
|
- Custom filesystem views
|
||||||
|
- Security boundaries
|
||||||
|
- No privileged container requirements
|
||||||
|
|
||||||
|
This approach allows:
|
||||||
|
- Rapid test environment creation
|
||||||
|
- Precise control over available resources
|
||||||
|
- Clean separation between test instances
|
||||||
|
- Efficient parallel testing
|
||||||
|
|
||||||
|
### Test Results Storage
|
||||||
|
|
||||||
|
Test results are organized hierarchically:
|
||||||
|
|
||||||
|
```
|
||||||
|
test_runs/
|
||||||
|
20240120_131415_commit_abc123/ # Timestamp and commit
|
||||||
|
challenge_name/
|
||||||
|
iterations/ # Complete iteration history
|
||||||
|
io.log # External interaction log
|
||||||
|
```
|
||||||
|
|
||||||
|
The io.log captures all external interactions:
|
||||||
|
```
|
||||||
|
timestamp|source|content
|
||||||
|
2024-01-20T13:14:15.123Z|stdin|user input
|
||||||
|
2024-01-20T13:14:15.892Z|stdout|sia response
|
||||||
|
2024-01-20T13:14:16.234Z|mailbox:user@example.com|email content
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Evaluation
|
||||||
|
|
||||||
|
Performance data comes from multiple sources:
|
||||||
|
1. Process metrics through system monitoring
|
||||||
|
2. Iteration logs showing decision patterns
|
||||||
|
3. Filesystem changes tracking task completion
|
||||||
|
4. Standard output demonstrating interaction quality
|
||||||
|
|
||||||
|
## Training Data Management
|
||||||
|
|
||||||
|
Training data requires special handling:
|
||||||
|
|
||||||
|
1. Separation from Production Data
|
||||||
|
- Training iterations kept separate
|
||||||
|
- Examples can be modified or synthesized
|
||||||
|
- Bad examples can be corrected
|
||||||
|
- Multiple instances can contribute data
|
||||||
|
|
||||||
|
2. Organization
|
||||||
|
- Clear labeling of good and bad examples
|
||||||
|
- Context for why examples are good/bad
|
||||||
|
- Links to related challenges
|
||||||
|
- Documentation of improvements
|
||||||
|
|
||||||
|
3. Validation
|
||||||
|
- Examples must be complete and correct
|
||||||
|
- Context must be sufficient
|
||||||
|
- Success criteria must be clear
|
||||||
|
- Resource usage must be reasonable
|
||||||
|
|
||||||
|
## Continuous Operation
|
||||||
|
|
||||||
|
While working on improvements, SIA must maintain its core functionality:
|
||||||
|
- Monitoring for user input
|
||||||
|
- Managing running tasks
|
||||||
|
- Handling scheduled events
|
||||||
|
- Tracking system resources
|
||||||
|
|
||||||
|
This requires:
|
||||||
|
1. Active Monitoring
|
||||||
|
- Check for user input on stdin
|
||||||
|
- Track running background tasks
|
||||||
|
- Handle scheduled events
|
||||||
|
- Monitor system resources
|
||||||
|
|
||||||
|
2. Interruption Handling
|
||||||
|
- Pause improvement work when needed
|
||||||
|
- Store progress and state
|
||||||
|
- Clean up temporary resources
|
||||||
|
- Maintain context awareness
|
||||||
|
|
||||||
|
3. Resource Management
|
||||||
|
- Balance improvement with responsiveness
|
||||||
|
- Monitor system resource usage
|
||||||
|
- Prevent training impact on user tasks
|
||||||
|
- Clean up old data regularly
|
||||||
|
|
||||||
|
## Looking Forward
|
||||||
|
|
||||||
|
The self-improvement system is designed to evolve with SIA. Future enhancements might include:
|
||||||
|
- Automated improvement suggestion generation
|
||||||
|
- More sophisticated regression testing
|
||||||
|
- Enhanced performance analytics
|
||||||
|
- Broader capability testing
|
||||||
|
|
||||||
|
Through this systematic approach to self-improvement, SIA can continue to enhance its capabilities while maintaining reliable operation and clear accountability for changes. The combination of challenge-based testing, careful version control, and comprehensive result tracking creates a foundation for sustained, measurable improvement over time.
|
||||||
Reference in New Issue
Block a user