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

New architecture

Browse Source
This commit is contained in:
Niels Geens
2024-10-31 18:08:35 +01:00
parent bd5c5911af
commit ee089e5be7
6 changed files with 347 additions and 140 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
diagrams/SIA_Class_Diagram.puml
View File

@@ -1,75 +0,0 @@
@startuml
skinparam classAttributeIconSize 0
class AgentCore {
- LLMEngine llmEngine
- List<CoreAction> actions
+ run()
+ templateActions(): List[Element]
+ systemInfo(): Element
+ buildContext(systemInfo: Element, actions: List[Element]): str
+ parseResponse(response: str): List[CoreAction], List[int]
+ deleteActions(List[int])
+ deleteAction(id: int)
+ stop()
}
class ServerCore {
- WebSystem webSystem
+ run()
}
class WebSystem {
+ updateContext(context: str)
+ getUpdatedContext(): str
+ updateActions(actions: List[CoreAction])
+ getUpdatedActions(): List[CoreAction]
}
class LLMEngine {
+ infer(context: str): Iterator[str]
}
class CoreAction {
+ id: str
+ template(id: str): Element
+ execute()
}
class SingleShotAction extends CoreAction {
}
class RepeatAction extends CoreAction {
}
class BackgroundAction extends CoreAction {
}
class DeleteAction {
+ execute(context: Context)
}
class InferenceResult {
+ reasoning: str
+ actions: List[CoreAction]
+ {static} parse(llmOutput: str): InferenceResult
}
Agent o-- LLMEngine
Agent o-- AgentCore
Agent o-- ServerCore
Agent o-- CoreAction
AgentCore o-- Context
AgentCore o-- InferenceResult
AgentCore o-- CoreAction
ServerCore o-- WebSystem
ServerCore o-- InferenceResult
ServerCore o-- CoreAction
CoreAction <|-- SingleShotAction
CoreAction <|-- RepeatAction
CoreAction <|-- BackgroundAction
CoreAction o-- DeleteAction
@enduml

46
diagrams/SIA_Component_Model.puml
View File

@@ -1,46 +0,0 @@
@startuml SIA_Component_Model
skinparam componentStyle uml2
package "SIA System" as SS {
[LLM Engine] as LLM
[Context Template] as CT
[Agent Core] as AC
package "Modules" {
[Process Module] as PM
[Docker Module] as DM
[Reinforcement Learning Module] as RLM
}
}
cloud "Docker Engine" as DE {
collections Instances
collections Images
}
database "File System" as FS {
database "Git Repository" as GIT
}
AC -d-> LLM : Context
LLM -u-> AC : Reasoning and actions
AC -u-> CT : Context data
CT -d-> AC : Context
AC -r-> Modules : Commands to execute
Modules -l-> AC : Context data
DM -d-> DE : Container management
DM <-d-> FS : Mount volumes
RLM -d-> FS : Store trained models
PM -d-> GIT : SIA update
Instances -u-> GIT : Modifies
Instances -r-> Images : Create
FS ----u-> LLM : Model weights
@enduml

1
diagrams/SIA_Component_Model.svg
View File

File diff suppressed because one or more lines are too long
Side by Side

Before

Width:  |  Height:  |  Size: 18 KiB

6
diagrams/render.sh
View File

@@ -1,6 +0,0 @@
#!/bin/bash
export MSYS_NO_PATHCONV=1
cd "$( dirname "${BASH_SOURCE[0]}" )"
docker run --rm -v $(pwd):/work -w /work plantuml/plantuml:latest -svg *.puml

345
readme.md
View File

@@ -145,10 +145,13 @@ This is usefull in case a previous context is embedded.
The LLM is free to escape data any way it wants,
as long as it results in valid XML.
The response is validated against a schema.
The Context is escaped using CDATA blocks.
Except when the data contains CDATA closing sequences.
Then the whole block is escaped using standard XML escaping.
### The SIA process
SIA is typically runs with the `restart.sh` script.
@@ -169,3 +172,345 @@ It will display the context for editing before handing it to the LLM.
After each run of the LLM, before parsing, it will display the reasoning and actions.
It interactively displays if the actions can be parsed.
At any time, the user can write to the standard input of SIA.
## Architecture
SIA follows a modular architecture centered around an agent that processes context through an LLM to generate actions.
The system can run in two modes: a standard command-line mode and an interactive web mode for debugging and human feedback.
### Core Components
#### Agent Architecture
The core of SIA is the agent, which exists in two variants:
- ProceduralAgent: Runs in a simple loop, processing context and executing actions directly
- WebAgent: Uses a state machine to allow human intervention and feedback through a web interface
Both agent types share common components:
- WorkingMemory: Maintains the current state through a collection of entries and system metrics
- ResponseParser: Converts LLM output into commands or entries
- XMLValidator: Validates responses against a schema
- IOBuffer: Handles input/output operations in an agent-appropriate way
#### Working Memory
The working memory stores the current state of the system through different types of entries:
- Script Entries:
- SingleShotEntry: Results of one-time script executions
- RepeatEntry: Continuously refreshed script outputs
- BackgroundEntry: Status of long-running processes
- ReasoningEntry: LLM's thought process documentation
- ParseErrorEntry: XML validation or parsing errors
- IOEntry: Input/output operations
Each entry can be serialized to XML for inclusion in the LLM context.
Working memory is cleaned through explicit delete commands or when context size limits are reached.
#### Command Processing
SIA distinguishes between two types of LLM outputs:
1. Commands: Immediate actions that modify the system
- DeleteCommand: Removes entries from working memory
- StopCommand: Terminates the agent
2. Entries: Records that become part of working memory
- Created from script executions, IO operations, reasoning, or errors
- Persist until explicitly deleted or context limits are reached
#### IO Handling
IO operations are abstracted through an IOBuffer interface:
- StandardIOBuffer: Direct access to system stdin/stdout
- WebIOBuffer: Buffer for web interface communication
This abstraction allows the ResponseParser to generate consistent IOEntries regardless of agent type.
### Processing Flow
#### Standard Agent Flow
1. Update system metrics and context size
2. Compile context from working memory entries
3. Process context through LLM
4. Validate XML response
5. Parse response into command or entry
6. Execute command or update working memory
7. Return to step 1 unless stopped
#### Web Agent Flow
1. Update system metrics and context size
2. Compile context and await human approval
3. Process approved context through LLM
4. Validate XML response
5. Present validation results and await human review
6. Parse approved response into command or entry
7. Execute command or update working memory
8. Return to step 1 unless stopped
### Web Interface
The web interface provides interactive debugging and human feedback through a WebSocket-based protocol:
#### Server-Client Communication
- Server Messages:
- Context updates for review
- Validation results from LLM responses
- Output updates from script execution
- State updates for UI synchronization
- Client Messages:
- Context approval decisions
- Response modifications
- User input for stdin operations
#### WebServer Architecture
The web server manages:
- WebSocket connections to clients
- Message routing to/from the WebAgent
- Broadcasting state updates to all connected clients
This architecture allows for:
- Real-time monitoring of agent state
- Interactive debugging of LLM responses
- Human-in-the-loop operation for testing and development
- Collection of human feedback for reinforcement learning
### Standard Agent Flow
```mermaid
stateDiagram-v2
direction LR
state "Standard Agent Flow" as standard_agent_flow {
[*] --> UpdateSystem: Start
UpdateSystem --> CompileContext: Updated Metrics & Size
CompileContext --> ProcessLLM
ProcessLLM --> ValidateXML: LLM Response
ValidateXML --> ParseResponse: Valid XML
ValidateXML --> UpdateEntries: Invalid XML\nCreate ParseErrorEntry
ParseResponse --> ExecuteCommands: Command
ParseResponse --> UpdateEntries: Entry
ExecuteCommands --> [*]: Stop Command
ExecuteCommands --> UpdateEntries: Delete Command
UpdateEntries --> UpdateSystem: Continue Loop
}
```
### Web Agent Flow
```mermaid
stateDiagram-v2
direction LR
state "Web Agent Flow" as web_agent_flow {
[*] --> UpdateSystem: Start
UpdateSystem --> CompileContext: Updated Metrics & Size
CompileContext --> WaitForContextApproval: Send Context
WaitForContextApproval --> ProcessLLM: Context Approved
ProcessLLM --> ValidateXML: LLM Response
ValidateXML --> WaitForResponseApproval: Send Validation Result
ValidateXML --> UpdateEntries: Invalid XML\nCreate ParseErrorEntry
WaitForResponseApproval --> ValidateXML: Modified Response
WaitForResponseApproval --> ParseResponse: Approved Response
ParseResponse --> ExecuteCommands: Command
ParseResponse --> UpdateEntries: Entry
ExecuteCommands --> [*]: Stop Command
ExecuteCommands --> UpdateEntries: Delete Command
UpdateEntries --> UpdateSystem: Continue Loop
}
```
### Class Diagram
```mermaid
classDiagram
direction LR
class BaseAgent {
<<abstract>>
#working_memory WorkingMemory
#metrics SystemMetrics
#llm LLMEngine
#parser ResponseParser
#validator XMLValidator
#io_buffer IOBuffer
#compile_context() str
}
class LLMEngine {
+LLMEngine(path str)
+set_model_path(path str)
+inference(context str) Iterator~str~
}
class StandardAgent {
+run()
}
class WebAgent {
-current_state WebAgentState
+get_current_state() WebAgentState
+proceed()
+add_state_change_handler(handler func())
}
class WebAgentState {
<<enumeration>>
UPDATE
CONTEXT_APPROVAL
INFERENCE
RESPONSE_APPROVAL
}
class WorkingMemory {
-entries List~Entry~
+add_entry(entry Entry)
+remove_entry(id str)
+update()
+generate_context() List~ElementTree~
}
class SystemMetrics {
+generate_context(entries List~ElementTree~) ElementTree
}
class XMLValidator {
-schema ElementTree
+XMLValidator(schema_path str)
+validate(xml str) Optional~str~
}
class ResponseParser {
-io_buffer IOBuffer
+parse(xml str) Command | Entry
}
class Entry {
<<abstract>>
+id str
+timestamp datetime
+update()*
+generate_context() ElementTree*
}
class SingleShotEntry {
+script str
+stdout str
+stderr str
+exit_code int
+update()
+generate_context() ElementTree
}
class RepeatEntry {
+script str
+stdout str
+stderr str
+exit_code int
+update()
+generate_context() ElementTree
}
class BackgroundEntry {
+script str
+stdout str
+stderr str
+process Process
+update()
+generate_context() ElementTree
}
class ReasoningEntry {
+content str
+update()
+generate_context() ElementTree
}
class ParseErrorEntry {
+content str
+error str
+update()
+generate_context() ElementTree
}
class ReadEntry {
+content str
+update()
+generate_context() ElementTree
}
class WriteEntry {
+content str
+update()
+generate_context() ElementTree
}
class IOBuffer {
<<interface>>
+read() str*
+write(content str)*
+buffer_length() int*
}
class StandardIOBuffer {
+read() str
+write(content str)
+buffer_length() int
}
class WebIOBuffer {
-stdin_buffer str
-stdout_buffer str
+read() str
+write(content str)
+buffer_length() int
+append_stdin(content str)
+get_stdout() str
+clear_stdout()
}
class Command {
<<abstract>>
+execute(memory &WorkingMemory)*
}
class DeleteCommand {
+id: str
+execute(memory &WorkingMemory)
}
class StopCommand {
+execute(memory &WorkingMemory)
}
class WebServer {
-agent WebAgent
-clients List~WebSocket~
-broadcast_state_change()
}
BaseAgent <|-- WebAgent
BaseAgent <|-- StandardAgent
BaseAgent "1" *-- "1" IOBuffer
BaseAgent "1" *-- "1" WorkingMemory
BaseAgent "1" *-- "1" SystemMetrics
BaseAgent "1" *-- "1" XMLValidator
BaseAgent "1" *-- "1" LLMEngine
BaseAgent "1" *-- "1" ResponseParser
WebServer "1" *-- "1" WebIOBuffer
WebServer "1" *-- "1" WebAgent
WebAgent "1" *-- "1" WebAgentState
WorkingMemory "1" *-- "*" Entry
Entry <|-- ReasoningEntry
Entry <|-- ParseErrorEntry
Entry <|-- ReadEntry
Entry <|-- WriteEntry
Entry <|-- SingleShotEntry
Entry <|-- RepeatEntry
Entry <|-- BackgroundEntry
Command <|-- DeleteCommand
Command <|-- StopCommand
IOBuffer <|.. WebIOBuffer
IOBuffer <|.. StandardIOBuffer
```

10
sia/llm_engine.py
View File

@@ -76,13 +76,3 @@ class LlmEngine:
thread = Thread(target=self.pipeline, kwargs=pipeline_kwargs)
thread.start()
return util.stop_before_value(streamer, '<|eot_id|>')
def finetune(self, dataset_paths: list, output_dir: str):
"""
Fine-tune the model with new datasets and save the updated model weights.
Args:
dataset_paths: List of paths to datasets for fine-tuning.
output_dir: Directory where the updated model weights will be saved.
"""
pass