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

Restructured self improvement reasoning + added training data

Browse Source
This commit is contained in:
Niels Geens
2025-01-23 15:51:25 +01:00
parent 69d7c6b605
commit cab452c614
33 changed files with 5983 additions and 195 deletions
Download Patch File Download Diff File Expand all files Collapse all files

380
procedures/self_improvement/reasoning.md
View File

@@ -1,30 +1,40 @@
# Self Improvement Design Rationale
# Self Improvement
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 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.
## 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
## 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.
### LLM Finetuning
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.
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.
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.
### Source Code Evolution
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.
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.
### 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.
### 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:
To improve systematically, SIA uses challenges that formalize specific capabilities into testable scenarios.
These serve multiple purposes:
- Testing specific capabilities
- Validating improvements
- Detecting regressions
@@ -55,54 +65,62 @@ Each challenge consists of:
### Example Challenges
Two examples illustrate different aspects of capabilities that need testing:
Two examples illustrate different aspects of capabilities that need testing.
Together they are good examples because they:
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
- Test different capability sets
- Have clear success criteria
- Include resource constraints
- Require multiple skills
- Reflect real-world tasks
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
#### Time Series Analysis Challenge
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
Tests if SIA can effectively analyze large amounts of time series data spread across multiple files. This tests:
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
- Efficient file handling
- Context management with size constraints
- Data analysis capabilities
- Resource-aware processing
Initial setup:
- Simple user request for card game score tracking
- Ability to ask questions about requirements
##### Initial setup
Success criteria:
- Asks relevant questions to understand needs
- Designs appropriate solution
- Implements working tool
- Documents usage clearly
- 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
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
##### Success criteria
### Challenge Directory Structure
- Efficiently reads and processes files
- Manages context to stay within limits
- Uses appropriate aggregation strategies
- Finds correct answers to queries
- Validates findings across files
#### 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
##### Success criteria
- Asks relevant questions to understand needs
- Designs appropriate solution
- Implements working tool
- Documents usage clearly
#### Example Directory Structure
Challenges are organized in a consistent file structure:
@@ -150,32 +168,127 @@ This structure ensures that:
- Required resources are documented
- SIA can get clarification when needed
## Web Interface Considerations
## Testing Framework
SIA's web interface allows humans to:
- Modify context before it goes to the LLM
- Review and edit responses before execution
- Load and continue from old iterations
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.
This interface is not suitable for automated self-improvement because:
- It's designed for human interaction
- Requires manual approval steps
- Doesn't scale for batch operations
- Can't handle parallel improvements
The framework needs to handle several key tasks:
Instead, self-improvement work should use direct file access and command-line interfaces when possible.
- Creating isolated test environments with specific initial conditions
- Starting and managing test SIA instances
- Monitoring test instance behavior and performance
- Collecting and analyzing results
- Cleaning up test environments
### Process Isolation with Bubblewrap
For running test instances, we chose Bubblewrap (bwrap) over alternatives like Docker-in-Docker or systemd-nspawn.
This decision was driven by several factors:
Bubblewrap provides excellent process isolation while being significantly lighter than full container solutions.
It allows fine-grained control over the filesystem view, process namespaces, and security boundaries.
Unlike Docker-in-Docker, it doesn't require privileged containers or risk storage driver conflicts.
Compared to systemd-nspawn, it offers more granular control and doesn't require root privileges or systemd integration.
The tool's ability to create custom filesystem views is particularly valuable for testing.
We can construct exactly the environment needed for each test, including mock files and services, without maintaining full container images.
This makes it easy to create and dispose of test environments quickly.
Bubblewrap's user-space operation means test instances can be started without special privileges, making the testing framework more secure and easier to use in various environments.
Its lightweight nature also means we can run many test instances efficiently, which is important for parallel testing and rapid iteration.
### Communication and Monitoring
Test instances communicate with the managing instance primarily through standard input and output streams.
This choice leverages SIA's existing I/O handling capabilities without requiring special modifications for testing.
The managing instance can send inputs through stdin and observe responses through stdout, just like a normal user would.
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:
```
2024-01-20T13:14:15.123Z stdin Can you send an email to sarah@example.com about the project status?
2024-01-20T13:14:15.892Z stdout I'll help you draft an email about the project status. Based on recent project information, I suggest this message:
Subject: Project Status Update
Content:
Hi Sarah,
I wanted to provide a quick update on our project progress. We've completed the initial phase of development and are on track with our timeline. The team has addressed all critical issues from the last review.
Would you like me to send this email?
2024-01-20T13:14:20.456Z stdin Yes, that looks good. Please send it.
2024-01-20T13:14:20.789Z stdout I'll send the email now.
2024-01-20T13:14:21.012Z mailbox:sarah@example.com Subject: Project Status Update
Hi Sarah,
I wanted to provide a quick update on our project progress. We've completed the initial phase of development and are on track with our timeline. The team has addressed all critical issues from the last review.
2024-01-20T13:14:21.234Z stdout Email has been sent to sarah@example.com successfully.
```
### Performance Evaluation
Performance data comes from multiple sources:
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.
## Test Environment Setup
Test environments are created using a dedicated setup tool.
This tool manages the directory structure, initial context, and any required background processes.
The initial context for a test instance can include setup actions that are executed when the instance starts.
Instead of trying to recreate a specific state directly, we let SIA execute these actions naturally.
This approach handles both the creation of background processes and the establishment of initial conditions in a way that maintains proper timing relationships.
Each entry in the initial context uses relative timestamps (offsets from the start time).
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
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.
This is used in two ways:
1. **Training**
The training configuration defines parameters and data used for training.
A model, retrained from the same commit, should produce the same results.
Trained models reference the commit id.
2. **Testing**
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 metadata
- References to training data
- Training configuration and data
- Test results and analysis
### Training Configuration
@@ -184,10 +297,8 @@ The training configuration is defined in `/training/config.yaml`, which specifie
```yaml
model:
name: "claude-3-sonnet-20240422"
context_length: 100000
temperature: 0.7
system_prompt_path: "training/prompts/system.txt"
system_prompt_path: "system_prompt.md"
action_schema: "action_schema.xsd"
training_data:
conversations:
@@ -203,119 +314,8 @@ 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.
The framework needs to handle several key tasks:
1. Creating isolated test environments with specific initial conditions
2. Starting and managing test SIA instances
3. Monitoring test instance behavior and performance
4. Collecting and analyzing results
5. Cleaning up test environments
### Process Isolation with Bubblewrap
For running test instances, we chose Bubblewrap (bwrap) over alternatives like Docker-in-Docker or systemd-nspawn. This decision was driven by several factors:
Bubblewrap provides excellent process isolation while being significantly lighter than full container solutions. It allows fine-grained control over the filesystem view, process namespaces, and security boundaries. Unlike Docker-in-Docker, it doesn't require privileged containers or risk storage driver conflicts. Compared to systemd-nspawn, it offers more granular control and doesn't require root privileges or systemd integration.
The tool's ability to create custom filesystem views is particularly valuable for testing. We can construct exactly the environment needed for each test, including mock files and services, without maintaining full container images. This makes it easy to create and dispose of test environments quickly.
Bubblewrap's user-space operation means test instances can be started without special privileges, making the testing framework more secure and easier to use in various environments. Its lightweight nature also means we can run many test instances efficiently, which is important for parallel testing and rapid iteration.
### Test Environment Setup
Test environments are created using a dedicated setup tool. This tool manages the directory structure, initial context, and any required background processes. We chose a file-based configuration approach over programmatic setup because it makes test scenarios easier to version control, review, and modify.
The initial context for a test instance can include setup actions that are executed when the instance starts. Instead of trying to recreate a specific state directly, we let SIA execute these actions naturally. This approach handles both the creation of background processes and the establishment of initial conditions in a way that maintains proper timing relationships.
Each entry in the initial context uses relative timestamps (offsets from the start time). 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.
### Communication and Monitoring
Test instances communicate with the managing instance primarily through standard input and output streams. This choice leverages SIA's existing I/O handling capabilities without requiring special modifications for testing. The managing instance can send inputs through stdin and observe responses through stdout, just like a normal user would.
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.) 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:
1. A setup tool that handles:
- Creating isolated filesystem environments
- Configuring initial context and background processes
- Managing process isolation through Bubblewrap
- Cleaning up test environments
2. A command-line parameter for SIA that enables:
- Starting with a specified initial context
- 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.
## Continuous Operation
While working on improvements, SIA must maintain its core functionality:
@@ -341,14 +341,4 @@ This requires:
- 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.
- Clean up old data regularly