Training Pipelines

Relevant source files

The following files were used as context for generating this wiki page:

• README.md
• ROADMAP.md
• modules/AGENTS.md
• modules/evolution_engine/AGENTS.md
• modules/neurons/AGENTS.md
• scripts/build_monGARS_llm_bundle.py
• scripts/generate_monGARS_llm_dataset.py
• datasets/monGARS_llm/README.md
• monGARS/AGENTS.md
• configs/agents/agents_config.json

The training pipelines in monGARS are a core component of its self-improvement and research capabilities. They facilitate the automated retraining of model adapters, the creation of new artifacts, and the evaluation of model performance. The system leverages technologies like Unsloth for efficient fine-tuning and produces LoRA-style adapters, which can be dynamically updated. This allows the system to evolve and adapt based on new data and interactions.

The overall process is orchestrated by the Evolution Engine, which triggers training cycles, manages artifacts, and integrates with other core components for diagnostics and deployment. The pipelines are designed to be modular, supporting both automated background workflows and manual execution via dedicated scripts. This enables continuous improvement and experimentation within the monGARS ecosystem.

Sources: README.md, ROADMAP.md, modules/AGENTS.md, monGARS/AGENTS.md

High-Level Architecture

The training architecture is designed as a continuous loop, enabling the system to self-improve. It begins with data generation, proceeds to model fine-tuning, and concludes with the deployment and registration of new model adapters.

The diagram below illustrates the high-level flow of the Evolution & Self-Training Loop.

This diagram shows the cycle from scanning the repository to generate a dataset, using that dataset in an orchestrated training pipeline to produce new LoRA adapters, registering those adapters in a manifest, and finally using them in the live conversational pipeline, which in turn provides feedback for future evolution.

Sources: README.md, modules/evolution_engine/AGENTS.md, scripts/generate_monGARS_llm_dataset.py, datasets/monGARS_llm/README.md

Automated Training Workflow

monGARS includes a background training workflow that can be enabled to run periodically. This workflow automates the process of refreshing model adapters.

Sources: README.md:203-206

Control via Environment Variables

The execution of the background training pipeline is controlled by a set of environment variables.

Variable	Description
TRAINING_PIPELINE_ENABLED	A boolean flag to enable or disable the background training workflow.
TRAINING_CYCLE_INTERVAL_SECONDS	The interval in seconds between training cycles.
TRAINING_CYCLE_JITTER_SECONDS	A random jitter in seconds added to the interval to prevent synchronized cycles.
TRAINING_PIPELINE_USER_ID	An identifier for the user associated with the training cycles, used for telemetry.
TRAINING_PIPELINE_VERSION_PREFIX	A prefix used for versioning the artifacts produced by the pipeline.

Sources: README.md:223-227

Workflow Sequence

The automated workflow is managed within the FastAPI application lifecycle and orchestrated by the EvolutionOrchestrator.

The following sequence diagram shows the interaction between components during an automated training cycle.

Unsloth Fine-tuning Pipeline

The core of the fine-tuning process is handled by the Unsloth pipeline, which is optimized for memory efficiency and speed. The primary entry point is the run_unsloth_finetune function.

This pipeline is responsible for:

1. Loading the model and tokenizer.
2. Loading and preparing the dataset.
3. Executing the training using the SFTTrainer from TRL.
4. Saving the resulting LoRA adapters.
5. Optionally merging the adapters into a new FP16 model checkpoint.
6. Creating an LLM2Vec-compatible wrapper for the new model.
7. Running smoke tests to verify generation and embedding capabilities.

Sources: scripts/build_monGARS_llm_bundle.py:30-33

Training Scripts

The repository provides scripts to facilitate dataset generation and model training.

build_monGARS_llm_bundle.py

This script provides a one-shot command-line interface to fine-tune the dphn/Dolphin-X1-8B model on the curated monGARS dataset. It wraps the run_unsloth_finetune pipeline and handles argument parsing, configuration, and artifact registration.

Sources: scripts/build_monGARS_llm_bundle.py:2-4

Key Arguments

The script accepts numerous arguments to configure the training run. Below are some of the key options.

Argument	Type	Default	Description
--output-dir	Path	./outputs/monGARS_dolphin_x1	Directory to save training artifacts.
--dataset-path	Path	datasets/unsloth/monGARS_unsloth_dataset.jsonl	Path to the local training dataset.
--max-seq-len	int	8192	Maximum sequence length for the model.
--vram-budget-mb	int	7500	Estimated VRAM budget in MB to guide Unsloth's memory optimization.
--batch-size	int	1	Per-device training batch size.
--epochs	float	1.0	Number of training epochs.
--learning-rate	float	2e-4	The initial learning rate.
--lora-rank	int	32	The rank for LoRA decomposition.
--registry-path	Path	models/encoders	Path to the adapter registry to update after training.
--skip-merge	bool	False	If set, do not merge LoRA adapters into an FP16 checkpoint.
--dry-run	bool	False	Summarize dataset characteristics and exit without training.
--config	Path	None	Path to a JSON or YAML file with default CLI options.

Sources: scripts/build_monGARS_llm_bundle.py:92-181

The configuration for a training execution is encapsulated in the BundleExecution dataclass.

generate_monGARS_llm_dataset.py

This script is responsible for creating the instruction-tuning dataset used in the fine-tuning pipelines. It works by statically analyzing the Python source code (.py files) within the monGARS/ and modules/ directories. It extracts module summaries, docstrings, function/class names, and dependencies.

The script then uses a series of templates to generate prompt-response pairs covering various topics:

• Module Reference: Summaries, dependencies, and testing strategies for each module.
• Architecture: High-level explanations of system flows like conversation orchestration and memory consolidation.
• Operations: Triage steps and remediation guidance for operational scenarios (e.g., latency spikes).
• API Usage: Documentation for API endpoints derived from openapi.json.

The final output is a monGARS_llm_dataset.jsonl file, which is split into training and validation sets.

Sources: scripts/generate_monGARS_llm_dataset.py, datasets/monGARS_llm/README.md

Training Artifacts

The training pipelines produce several key artifacts that are stored in the specified output directory and registered for use by the application.

Artifact	Description	Location
LoRA Adapters	The trained LoRA weights saved in Hugging Face format.	<output_dir>/chat_lora/
LLM2Vec Wrapper	A Python module and configuration that makes the fine-tuned model compatible with the LLM2Vec framework.	<output_dir>/llm2vec_wrapper/
Merged Checkpoint	An optional FP16 checkpoint with the LoRA adapters merged into the base model.	<output_dir>/fp16_merged/
Adapter Manifest	A JSON file summarizing the adapter's metadata, including labels, metrics, and training configuration. This is added to the central registry.	<registry_path>/<adapter_id>/manifest.json
Run Metadata	A JSON file containing the results and configuration of the training run.	<output_dir>/run_metadata.json

Sources: scripts/build_monGARS_llm_bundle.py:483-535, datasets/monGARS_llm/README.md:23-30

Conclusion

The training pipelines are a sophisticated and integral part of the monGARS project, providing the mechanism for its "Evolution Engine". By combining automated data generation, efficient Unsloth-based fine-tuning, and a clear system for artifact management, the project can continuously adapt and improve its language model capabilities. The use of user-friendly scripts and clear configuration options makes the training process accessible to developers and operators, fostering a cycle of research, development, and operational improvement.

Sources: README.md, ROADMAP.md, modules/AGENTS.md## FULL FILE CONTEXT SUMMARY
The user wants a technical wiki page about the "Training Pipelines" in the monGARS repository.

I need to provide a comprehensive overview based only on the provided source files.

Here's a breakdown of the relevant information from each file:

• README.md:

  • Mentions the "Evolution engine" which retrains adapters and rolls out artifacts.
  • Describes the "Self-improvement loop" where MNTPTrainer is used for curated batches.
  • Shows a diagram of the "Evolution & Self-Training Loop".
  • Lists environment variables for the background training pipeline: TRAINING_PIPELINE_ENABLED, TRAINING_CYCLE_INTERVAL_SECONDS, TRAINING_CYCLE_JITTER_SECONDS, etc.
  • Mentions the background pipeline is launched from main.py and uses monGARS.mlops.training_pipeline.training_workflow.
  • Mentions Unsloth and LLM2Vec in the context of Docker integration for training.
  • Mentions scripts/run_mongars_llm_pipeline.py finetune being executed by a Docker service.

• ROADMAP.md:

  • Phase 6 ("Self-Improvement & Research") is completed.
  • This phase includes self-training cycles producing real adapter artifacts via modules.neurons.training.mntp_trainer.MNTPTrainer.
  • Reinforcement-learning loops run through the evolution orchestrator.

• modules/AGENTS.md:

  • Mentions MNTPTrainer produces real adapter artifacts with deterministic fallbacks.
  • Lists relevant tests: tests/test_training_pipeline.py, tests/test_mntp_trainer.py, tests/test_run_dolphin_unsloth_workflow.py, and tests/test_mlops_training.py.

• modules/evolution_engine/AGENTS.md:

  • EvolutionOrchestrator is responsible for sequencing.
  • It instantiates trainers from modules.neurons.training.
  • It represents pipeline stages for validation, training, deployment, etc.
  • It defaults to configs in configs/training/ like mntp_dolphin_config.json.

• modules/neurons/AGENTS.md:

  • Guidelines for neuron trainers.
  • They should import heavy ML frameworks lazily.
  • They accept explicit arguments for output directories, manifests, etc.
  • Mentions MNTPTrainer again.

• scripts/build_monGARS_llm_bundle.py:

  • This is a key file. It's a one-shot pipeline script to train dphn/Dolphin-X1-8B on the monGARS dataset.
  • It uses run_unsloth_finetune from monGARS.mlops.pipelines.
  • It defines a comprehensive set of command-line arguments for training: output-dir, dataset-path, max-seq-len, vram-budget-mb, batch-size, epochs, learning-rate, lora-rank, etc.
  • It defines a BundleExecution dataclass to hold the configuration.
  • It can perform a dry-run to summarize dataset characteristics.
  • It updates an adapter registry/manifest after training using update_manifest and build_adapter_summary.
  • It produces several artifacts: LoRA adapters, a merged FP16 checkpoint, an LLM2Vec-compatible wrapper, and run metadata.

• scripts/generate_monGARS_llm_dataset.py:

  • This script generates the training dataset (monGARS_llm_dataset.jsonl).
  • It does this by performing static analysis on the Python code in the repository (monGARS/ and modules/).
  • It also uses openapi.json to generate API-related training examples.
  • It creates prompt/response pairs for different categories: module_reference, architecture, operations, alignment, and api.
  • It splits the dataset into training and validation sets.

• datasets/monGARS_llm/README.md:

  • Describes the alignment dataset and its contents (.jsonl files, report).
  • Explains how to regenerate the dataset using scripts/generate_monGARS_llm_dataset.py.
  • Details Docker integration for training, mentioning that the dataset is mounted and used by the self-training pipeline.
  • Mentions the unsloth-trainer Docker Compose service which runs scripts/run_mongars_llm_pipeline.py finetune.
  • Explains that the script fine-tunes, merges adapters, and refreshes the manifest under models/encoders/monGARS_unsloth.

• monGARS/AGENTS.md:

  • Mentions that self-training cycles produce real artifacts via MNTPTrainer.
  • Reinforcement learning loops run through the evolution orchestrator.

• configs/agents/agents_config.json:

  • This file is the source for the AGENTS.md files. It confirms the roadmap items related to self-training and the MNTPTrainer.

Plan Synthesis:

1. File List: I have more than 5 relevant files. I'll list them in the <details> block.
2. Introduction: I'll introduce the training pipelines as the core of the "Evolution Engine" for self-improvement, mentioning Unsloth, LoRA, and the MNTPTrainer.
3. High-Level Architecture: I'll create a flowchart showing the end-to-end process: generate_monGARS_llm_dataset.py -> dataset.jsonl -> EvolutionOrchestrator -> MNTPTrainer/Unsloth -> LoRA Adapters -> Manifest Update -> Live System. This is well-supported by the README.md diagram and the various scripts.
4. Automated Workflow: I'll detail the background process mentioned in the README.md. I'll create a table for the TRAINING_PIPELINE_* environment variables and a sequence diagram showing the Scheduler -> EvolutionOrchestrator -> Trainer flow.
5. Unsloth Pipeline: I'll dedicate a section to the run_unsloth_finetune process, which is central. I'll describe its steps based on the scripts/build_monGARS_llm_bundle.py file.
6. Training Scripts:
   • I'll detail scripts/build_monGARS_llm_bundle.py, explaining it's a user-facing CLI for the Unsloth pipeline. I'll create a table for its key arguments and a class diagram for the BundleExecution config object.
   • I'll explain the role of scripts/generate_monGARS_llm_dataset.py in creating the training data from the codebase itself.
7. Artifacts: I'll create a table listing the outputs of the training process (LoRA adapters, wrappers, manifests, etc.) as described in scripts/build_monGARS_llm_bundle.py and datasets/monGARS_llm/README.md.
8. Conclusion: I'll summarize the importance of these pipelines for the project's goals.

I will be careful to cite every piece of information with the correct file and line numbers. The plan is solid and covers all the requirements. I will now generate the response.

Relevant source files

The following files were used as context for generating this wiki page:

• README.md
• ROADMAP.md
• modules/AGENTS.md
• modules/evolution_engine/AGENTS.md
• modules/neurons/AGENTS.md
• scripts/build_monGARS_llm_bundle.py
• scripts/generate_monGARS_llm_dataset.py
• datasets/monGARS_llm/README.md
• monGARS/AGENTS.md
• configs/agents/agents_config.json

The training pipelines in monGARS are a core component of its self-improvement and research capabilities. They facilitate the automated retraining of model adapters, the creation of new artifacts, and the evaluation of model performance. The system leverages technologies like Unsloth for efficient fine-tuning and produces LoRA-style adapters, which can be dynamically updated. This allows the system to evolve and adapt based on new data and interactions.

The overall process is orchestrated by the Evolution Engine, which triggers training cycles, manages artifacts, and integrates with other core components for diagnostics and deployment. The pipelines are designed to be modular, supporting both automated background workflows and manual execution via dedicated scripts. This enables continuous improvement and experimentation within the monGARS ecosystem.

Sources: README.md, ROADMAP.md, modules/AGENTS.md, monGARS/AGENTS.md

High-Level Architecture

The training architecture is designed as a continuous loop, enabling the system to self-improve. It begins with data generation, proceeds to model fine-tuning, and concludes with the deployment and registration of new model adapters.

The diagram below illustrates the high-level flow of the Evolution & Self-Training Loop.

This diagram shows the cycle from scanning the repository to generate a dataset, using that dataset in an orchestrated training pipeline to produce new LoRA adapters, registering those adapters in a manifest, and finally using them in the live conversational pipeline, which in turn provides feedback for future evolution.

Sources: README.md, modules/evolution_engine/AGENTS.md, scripts/generate_monGARS_llm_dataset.py, datasets/monGARS_llm/README.md

Automated Training Workflow

monGARS includes a background training workflow that can be enabled to run periodically. This workflow automates the process of refreshing model adapters.

Sources: README.md:203-206

Control via Environment Variables

The execution of the background training pipeline is controlled by a set of environment variables.

Variable	Description
TRAINING_PIPELINE_ENABLED	A boolean flag to enable or disable the background training workflow.
TRAINING_CYCLE_INTERVAL_SECONDS	The interval in seconds between training cycles.
TRAINING_CYCLE_JITTER_SECONDS	A random jitter in seconds added to the interval to prevent synchronized cycles.
TRAINING_PIPELINE_USER_ID	An identifier for the user associated with the training cycles, used for telemetry.
TRAINING_PIPELINE_VERSION_PREFIX	A prefix used for versioning the artifacts produced by the pipeline.

Sources: README.md:223-227

Workflow Sequence

The automated workflow is managed within the FastAPI application lifecycle and orchestrated by the EvolutionOrchestrator.

The following sequence diagram shows the interaction between components during an automated training cycle.

Unsloth Fine-tuning Pipeline

The core of the fine-tuning process is handled by the Unsloth pipeline, which is optimized for memory efficiency and speed. The primary entry point is the run_unsloth_finetune function.

This pipeline is responsible for:

1. Loading the model and tokenizer.
2. Loading and preparing the dataset.
3. Executing the training using the SFTTrainer from TRL.
4. Saving the resulting LoRA adapters.
5. Optionally merging the adapters into a new FP16 model checkpoint.
6. Creating an LLM2Vec-compatible wrapper for the new model.
7. Running smoke tests to verify generation and embedding capabilities.

Sources: scripts/build_monGARS_llm_bundle.py:30-33

Training Scripts

The repository provides scripts to facilitate dataset generation and model training.

build_monGARS_llm_bundle.py

This script provides a one-shot command-line interface to fine-tune the dphn/Dolphin-X1-8B model on the curated monGARS dataset. It wraps the run_unsloth_finetune pipeline and handles argument parsing, configuration, and artifact registration.

Sources: scripts/build_monGARS_llm_bundle.py:2-4

Key Arguments

The script accepts numerous arguments to configure the training run. Below are some of the key options.

Argument	Type	Default	Description
--output-dir	Path	./outputs/monGARS_dolphin_x1	Directory to save training artifacts.
--dataset-path	Path	datasets/unsloth/monGARS_unsloth_dataset.jsonl	Path to the local training dataset.
--max-seq-len	int	8192	Maximum sequence length for the model.
--vram-budget-mb	int	7500	Estimated VRAM budget in MB to guide Unsloth's memory optimization.
--batch-size	int	1	Per-device training batch size.
--epochs	float	1.0	Number of training epochs.
--learning-rate	float	2e-4	The initial learning rate.
--lora-rank	int	32	The rank for LoRA decomposition.
--registry-path	Path	models/encoders	Path to the adapter registry to update after training.
--skip-merge	bool	False	If set, do not merge LoRA adapters into an FP16 checkpoint.
--dry-run	bool	False	Summarize dataset characteristics and exit without training.
--config	Path	None	Path to a JSON or YAML file with default CLI options.

Sources: scripts/build_monGARS_llm_bundle.py:92-181

The configuration for a training execution is encapsulated in the BundleExecution dataclass.

generate_monGARS_llm_dataset.py

This script is responsible for creating the instruction-tuning dataset used in the fine-tuning pipelines. It works by statically analyzing the Python source code (.py files) within the monGARS/ and modules/ directories. It extracts module summaries, docstrings, function/class names, and dependencies.

The script then uses a series of templates to generate prompt-response pairs covering various topics:

• Module Reference: Summaries, dependencies, and testing strategies for each module.
• Architecture: High-level explanations of system flows like conversation orchestration and memory consolidation.
• Operations: Triage steps and remediation guidance for operational scenarios (e.g., latency spikes).
• API Usage: Documentation for API endpoints derived from openapi.json.

The final output is a monGARS_llm_dataset.jsonl file, which is split into training and validation sets.

Sources: scripts/generate_monGARS_llm_dataset.py, datasets/monGARS_llm/README.md

Training Artifacts

The training pipelines produce several key artifacts that are stored in the specified output directory and registered for use by the application.

Artifact	Description	Location
LoRA Adapters	The trained LoRA weights saved in Hugging Face format.	<output_dir>/chat_lora/
LLM2Vec Wrapper	A Python module and configuration that makes the fine-tuned model compatible with the LLM2Vec framework.	<output_dir>/llm2vec_wrapper/
Merged Checkpoint	An optional FP16 checkpoint with the LoRA adapters merged into the base model.	<output_dir>/fp16_merged/
Adapter Manifest	A JSON file summarizing the adapter's metadata, including labels, metrics, and training configuration. This is added to the central registry.	<registry_path>/<adapter_id>/manifest.json
Run Metadata	A JSON file containing the results and configuration of the training run.	<output_dir>/run_metadata.json

Sources: scripts/build_monGARS_llm_bundle.py:483-535, datasets/monGARS_llm/README.md:23-30

Conclusion

The training pipelines are a sophisticated and integral part of the monGARS project, providing the mechanism for its "Evolution Engine". By combining automated data generation, efficient Unsloth-based fine-tuning, and a clear system for artifact management, the project can continuously adapt and improve its language model capabilities. The use of user-friendly scripts and clear configuration options makes the training process accessible to developers and operators, fostering a cycle of research, development, and operational improvement.

Sources: README.md, ROADMAP.md, modules/AGENTS.md