llm/SIA
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

merged reasoning for self improvement

Browse Source
This commit is contained in:
Niels Geens
2025-01-23 11:44:55 +01:00
parent f152914431
commit 69d7c6b605
2 changed files with 178 additions and 335 deletions
Download Patch File Download Diff File Expand all files Collapse all files

270
procedures/self_improvement/reasoning.md
View File

@@ -1,44 +1,26 @@
# Self Improvement Design Rationale
## Core Concepts
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.
SIA is an agentic AI system that autonomously completes complex tasks by writing and executing scripts. While handling tasks, it gathers data about its performance and can work on improving itself when no other tasks need attention.
## Core Philosophy
SIA has several mechanisms for self-improvement:
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.
1. **LLM Finetuning**
The Large Language Model at SIA's core can be retrained with better examples. By analyzing its history, SIA can identify cases where its reasoning or actions could have been better and collect these as training examples. This data needs careful validation and organization to be useful for training.
### Improvement Mechanisms
2. **Source Code Modification**
SIA can modify its own Python source code. When stopped, SIA restarts and reloads the Python files, allowing code changes to take effect. This enables both architectural and functional improvements. However, code modifications are high-risk and need robust validation.
The system can improve in several ways:
3. **Procedure Creation and Optimization**
Procedures provide guided reasoning paths for complex tasks. By analyzing its history, SIA can identify common patterns and create new procedures or optimize existing ones. This improves consistency and efficiency while being less risky than code changes.
1. LLM Finetuning
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.
4. **Tool Development**
SIA can develop new tools and improve existing ones. These tools expand SIA's capabilities by providing new ways to interact with systems and data.
2. Source Code Evolution
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.
## Continuous Operation Requirements
3. Procedure Refinement
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.
While working on improvements, SIA must maintain its core functionality:
1. **Active Monitoring**
- Check for user input on stdin
- Track running background tasks
- Handle scheduled events and timers
- Monitor system resources
2. **Interruption Handling**
- Pause improvement work when high-priority tasks arrive
- Store progress and state for resuming later
- Clean up any temporary resources
- Maintain context awareness
3. **Resource Management**
- Balance improvement work with responsiveness
- Monitor CPU, memory, and disk usage
- Prevent training tasks from impacting user tasks
- Clean up old data and temporary files
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
@@ -53,19 +35,19 @@ To improve systematically, SIA uses challenges that formalize specific capabilit
Each challenge consists of:
1. **Description**
1. Description
- Clear statement of what capability is being tested
- Why this capability matters
- Success criteria
- Resource constraints
2. **Initial Context**
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**
3. Validation
- Precise success criteria
- Resource limits (CPU, memory, time)
- Required outputs or state changes
@@ -75,54 +57,54 @@ Each challenge consists of:
Two examples illustrate different aspects of capabilities that need testing:
1. **Time Series Analysis Challenge**
Testing 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
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
Initial setup:
- Directory with many CSV files containing time series data (created by a script)
- Files too large to load into context at once
- Need to find patterns/anomalies in the data
- Resource constraints on memory usage
- Directory with many CSV files containing time series data (created by a script)
- Files too large to load into context at once
- Need to find patterns/anomalies in the data
- Resource constraints on memory usage
Success criteria:
- Efficiently reads and processes files
- Manages context to stay within limits
- Uses appropriate aggregation strategies
- Finds correct answers to queries
- Validates findings across files
- Efficiently reads and processes files
- Manages context to stay within limits
- Uses appropriate aggregation strategies
- Finds correct answers to queries
- Validates findings across files
2. **Tool Development Challenge**
Testing 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 for deployment
- Documentation skills
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
Initial setup:
- Simple user request for card game score tracking
- Ability to ask questions about requirements
- Simple user request for card game score tracking
- Ability to ask questions about requirements
Success criteria:
- Asks relevant questions to understand needs
- Designs appropriate solution
- Implements working tool
- Documents usage clearly
- Asks relevant questions to understand needs
- Designs appropriate solution
- Implements working tool
- Documents usage clearly
These challenges are good examples because they:
- Test different capability sets
- Have clear success criteria
- Include resource constraints
- Require multiple skills
- Reflect real-world tasks
- Test different capability sets
- Have clear success criteria
- Include resource constraints
- Require multiple skills
- Reflect real-world tasks
### Challenge Directory Structure
Challenges are organized in a consistent structure:
Challenges are organized in a consistent file structure:
```
challenges/
@@ -168,28 +150,6 @@ This structure ensures that:
- Required resources are documented
- SIA can get clarification when needed
## Training Data Management
Training data for improving the LLM comes from analyzing SIA's performance on real tasks and challenges. This data needs special handling:
1. **Separation from Production Data**
- Training iterations are kept separate from the main SIA instance
- 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
## Web Interface Considerations
SIA's web interface allows humans to:
@@ -205,6 +165,52 @@ This interface is not suitable for automated self-improvement because:
Instead, self-improvement work should use direct file access and command-line interfaces when possible.
## 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 Rationale
Testing self-improvement capabilities requires running SIA instances in various scenarios while monitoring their behavior and performance. These test instances must operate in isolation to prevent interference with the main instance or each other. However, they must also be observable so that the managing instance can evaluate their performance and collect data for improvement.
@@ -240,16 +246,58 @@ Test instances communicate with the managing instance primarily through standard
For deeper inspection, the managing instance monitors the test instance's iterations directory. Since SIA already serializes its context for each iteration, this provides a complete record of the test instance's behavior without requiring additional instrumentation. This approach maintains clean separation between the test instance and the monitoring system.
### 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. Direct process metrics (CPU, memory, etc.) obtained through the host system
1. Direct process metrics (CPU, memory, etc.) as stored in the iteration logs
2. Iteration logs showing decision-making patterns
3. Filesystem changes indicating task completion and side effects
4. Standard output showing interaction quality
This multi-faceted approach provides a comprehensive view of performance without requiring modifications to SIA's core code. The managing instance can collect and analyze this data without interfering with the test instance's operation.
## Training Data Management
Training data for improving the LLM comes from analyzing SIA's performance on real tasks and challenges. This data needs special handling:
1. Separation from Production Data
- Training iterations are kept separate from the main SIA instance
- 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
## Tooling and integration in SIA
The testing framework consists of two main components:
@@ -265,4 +313,42 @@ The testing framework consists of two main components:
- Running in test mode with appropriate defaults
- Maintaining isolation awareness
The simplicity of this design is intentional. By keeping the framework minimal and focused, we reduce the chances of the testing infrastructure itself affecting test results. The framework provides the necessary capabilities for testing while maintaining clean separation between test instances and the managing system.
The simplicity of this design is intentional. By keeping the framework minimal and focused, we reduce the chances of the testing infrastructure itself affecting test results. The framework provides the necessary capabilities for testing while maintaining clean separation between test instances and the managing system.
## 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.

243
procedures/self_improvement/reasoning_2.md
View File

@@ -1,243 +0,0 @@
# Self Improvement Design Rationale
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.
## Core Philosophy
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.
### Improvement Mechanisms
The system can improve in several ways:
1. LLM Finetuning
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.
2. Source Code Evolution
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.
3. Procedure Refinement
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.
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.