Merge branch 'master' of https://github.com/elder-plinius/p-swarms
elder-plinius
1 year ago
commit
fd1a492420
@ -0,0 +1,37 @@
|
||||
name: "Init Environment"
|
||||
description: "Initialize environment for tests"
|
||||
runs:
|
||||
using: "composite"
|
||||
steps:
|
||||
- name: Checkout actions
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- name: Set up Python ${{ matrix.python-version }}
|
||||
uses: actions/setup-python@v4
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
|
||||
- name: Install and configure Poetry
|
||||
uses: snok/install-poetry@v1
|
||||
with:
|
||||
virtualenvs-create: true
|
||||
virtualenvs-in-project: true
|
||||
installer-parallel: true
|
||||
|
||||
- name: Load cached venv
|
||||
id: cached-poetry-dependencies
|
||||
uses: actions/cache@v3
|
||||
with:
|
||||
path: .venv
|
||||
key: venv-${{ runner.os }}-${{ steps.setup-python.outputs.python-version }}-${{ hashFiles('**/poetry.lock') }}
|
||||
|
||||
- name: Install dependencies
|
||||
if: steps.cached-poetry-dependencies.outputs.cache-hit != 'true'
|
||||
run: poetry install --no-interaction --no-root --with test --with dev --all-extras
|
||||
shell: bash
|
||||
|
||||
- name: Activate venv
|
||||
run: |
|
||||
source .venv/bin/activate
|
||||
echo PATH=$PATH >> $GITHUB_ENV
|
||||
shell: bash
|
||||
@ -0,0 +1,49 @@
|
||||
# Release Notes
|
||||
|
||||
## 3.7.5
|
||||
|
||||
2024-01-21
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
Fix imports of Agent, SequentialWorkflow, ModelParallelizer, Task, OpenAIChat, Gemini, GPT4VisionAPI
|
||||
|
||||
### New Features
|
||||
|
||||
New model: Odin for Object Detection and tracking
|
||||
New mode: Ultralytics Object recognition YOLO
|
||||
|
||||
New Tokenizers
|
||||
|
||||
Schema generator for prompts.
|
||||
New prompt for worker agent.
|
||||
|
||||
New structure: plan, step
|
||||
|
||||
New tool: execute tool
|
||||
|
||||
New logger: get_logger
|
||||
|
||||
Example for worker_agent
|
||||
|
||||
|
||||
|
||||
## 3.6.8
|
||||
|
||||
2024-01-19
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
Removed ModelScope
|
||||
|
||||
Removed CogAgent
|
||||
|
||||
### New Features
|
||||
|
||||
Added ultralytics vision models
|
||||
|
||||
Added TimmModel to wrap timm models
|
||||
|
||||
### Other
|
||||
|
||||
Loosened version of timm
|
||||
|
After Width: | Height: | Size: 283 KiB |
@ -0,0 +1,95 @@
|
||||
# Swarms Data Room
|
||||
|
||||
## Table of Contents
|
||||
|
||||
**Introduction**
|
||||
|
||||
- Overview of the Company
|
||||
|
||||
- Vision and Mission Statement
|
||||
|
||||
- Executive Summary
|
||||
|
||||
**Corporate Documents**
|
||||
|
||||
- Articles of Incorporation
|
||||
|
||||
- Bylaws
|
||||
|
||||
- Shareholder Agreements
|
||||
|
||||
- Board Meeting Minutes
|
||||
|
||||
- Company Structure and Org Chart
|
||||
|
||||
**Financial Information**
|
||||
|
||||
- Historical Financial Statements
|
||||
|
||||
- Income Statements
|
||||
|
||||
- Balance Sheets
|
||||
|
||||
- Cash Flow Statements
|
||||
|
||||
- Financial Projections and Forecasts
|
||||
|
||||
- Cap Table
|
||||
|
||||
- Funding History and Use of Funds
|
||||
|
||||
**Products and Services**
|
||||
|
||||
- Detailed Descriptions of Products/Services
|
||||
|
||||
- Product Development Roadmap
|
||||
|
||||
- User Manuals and Technical Specifications
|
||||
|
||||
- Case Studies and Use Cases
|
||||
|
||||
|
||||
## **Introdution**
|
||||
Swarms provides automation-as-a-service through swarms of autonomous agents that work together as a team. We enable our customers to build, deploy, and scale production-grade multi-agent applications to automate real-world tasks.
|
||||
|
||||
|
||||
### **Vision**
|
||||
Our vision for 2024 is to provide the most reliable infrastructure for deploying autonomous agents into the real world through the Swarm Cloud, our premier cloud platform for the scalable deployment of Multi-Modal Autonomous Agents. The platform focuses on delivering maximum value to users by only taking a small fee when utilizing the agents for the hosted compute power needed to host the agents.
|
||||
|
||||
### **Executive Summary**
|
||||
The Swarm Corporation aims to enable AI models to automate complex workflows and operations, not just singular low-value tasks. We believe collaboration between multiple agents can overcome limitations of individual agents for reasoning, planning, etc. This will allow automation of processes in mission-critical industries like security, logistics, and manufacturing where AI adoption is currently low.
|
||||
|
||||
We provide an open source framework to deploy production-grade multi-modal agents in just a few lines of code. This builds our user base, recruits talent, gets customer feedback to improve products, gains awareness and trust.
|
||||
|
||||
Our business model focuses on customer satisfaction, openness, integration with other tools/platforms, and production-grade reliability.
|
||||
|
||||
Go-to-market strategy is to get the framework to product-market fit with over 50K weekly recurring users, then secure high-value contracts in target industries. Long-term monetization via microtransactions, usage-based pricing, subscriptions.
|
||||
|
||||
The team has thousands of hours building and optimizing autonomous agents. Leadership includes AI engineers, product experts, open source contributors and community builders.
|
||||
|
||||
Key milestones: get 80K framework users in January 2024, start contracts in target verticals, introduce commercial products in 2025 with various pricing models.
|
||||
|
||||
|
||||
### **The Swarm Corporation Memo**
|
||||
To learn more about our mission, vision, plans for GTM, and much more please refer to the [Swarm Memo here](https://docs.google.com/document/d/1hS_nv_lFjCqLfnJBoF6ULY9roTbSgSuCkvXvSUSc7Lo/edit?usp=sharing)
|
||||
|
||||
|
||||
## **Product**
|
||||
Swarms is an open source framework for developers in python to enable seamless, reliable, and scalable multi-agent orchestration through modularity, customization, and precision.
|
||||
|
||||
[Here is the official Swarms Github Page:](https://github.com/kyegomez/swarms)
|
||||
|
||||
### Product Growth Metrics
|
||||
| Name | Description | Link |
|
||||
|----------------------------------|---------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
|
||||
| Total Downloads of all time | Total number of downloads for the product over its entire lifespan. | [](https://pepy.tech/project/swarms) |
|
||||
| Downloads this month | Number of downloads for the product in the current month. | [](https://pepy.tech/project/swarms) |
|
||||
| Total Downloads this week | Total number of downloads for the product in the current week. | [](https://pepy.tech/project/swarms) |
|
||||
| Github Forks | Number of times the product's codebase has been copied for optimization, contribution, or usage. | [](https://github.com/kyegomez/swarms/network) |
|
||||
| Github Stars | Number of users who have 'liked' the project. | [](https://github.com/kyegomez/swarms/stargazers) |
|
||||
| Pip Module Metrics | Various project statistics such as watchers, number of contributors, date repository was created, and more. | [CLICK HERE](https://libraries.io/github/kyegomez/swarms) |
|
||||
| Contribution Based Statistics | Statistics like number of contributors, lines of code changed, etc. | [HERE](https://github.com/kyegomez/swarms/graphs/contributors) |
|
||||
| Github Community insights | Insights into the Github community around the product. | [Github Community insights](https://github.com/kyegomez/swarms/graphs/community) |
|
||||
| Github Traffic Metrics | Metrics related to traffic, such as views and clones on Github. | [Github Traffic Metrics](https://github.com/kyegomez/swarms/graphs/traffic) |
|
||||
| Issues with the framework | Current open issues for the product on Github. | [](https://github.com/kyegomez/swarms/issues) |
|
||||
|
||||
@ -0,0 +1,21 @@
|
||||
# [Go To Market Strategy][GTM]
|
||||
|
||||
Our vision is to become the world leader in real-world production grade autonomous agent deployment through open-source product development, Deep Verticalization, and unmatched value delivery to the end user.
|
||||
|
||||
We will focus on first accelerating the open source framework to PMF where it will serve as the backend for upstream products and services such as the Swarm Cloud which will enable enterprises to deploy autonomous agents with long term memory and tools in the cloud and a no-code platform for users to build their own swarm by dragging and dropping blocks.
|
||||
|
||||
Our target user segment for the framework is AI engineers looking to deploy agents into high risk environments where reliability is crucial.
|
||||
|
||||
Once PMF has been achieved and the framework has been extensively benchmarked we aim to establish high value contracts with customers in Security, Logistics, Manufacturing, Health and various other untapped industries.
|
||||
|
||||
Our growth strategy for the OS framework can be summarized by:
|
||||
|
||||
- Educating developers on value of autonomous agent usage.
|
||||
- Tutorial Walkthrough on various applications like deploying multi-modal agents through cameras or building custom swarms for a specific business operation.
|
||||
- Demonstrate unmatched reliability by delighting users.
|
||||
- Staying up to date with trends and integrating the latest models, frameworks, and methodologies.
|
||||
- Building a loyal and devoted community for long term user retention. [Join here](https://codex.apac.ai)
|
||||
|
||||
As we continuously deliver value with the open framework we will strategically position ourselves to acquire leads for high value contracts by demonstrating the power, reliability, and performance of our framework openly.
|
||||
|
||||
Acquire Full Access to the memo here: [TSC Memo](https://docs.google.com/document/d/1hS_nv_lFjCqLfnJBoF6ULY9roTbSgSuCkvXvSUSc7Lo/edit?usp=sharing)
|
||||
@ -1,83 +0,0 @@
|
||||
# Contributing to Swarms
|
||||
|
||||
Thank you for your interest in contributing to Swarms! We welcome contributions from the community to help improve usability and readability. By contributing, you can be a part of creating a dynamic and interactive AI system.
|
||||
|
||||
To get started, please follow the guidelines below.
|
||||
|
||||
## Join the Swarms Community
|
||||
|
||||
Join the Swarms community on Discord to connect with other contributors, coordinate work, and receive support.
|
||||
|
||||
- [Join the Swarms Discord Server](https://discord.gg/qUtxnK2NMf)
|
||||
|
||||
## Taking on Tasks
|
||||
|
||||
We have a growing list of tasks and issues that you can contribute to. To get started, follow these steps:
|
||||
|
||||
1. Visit the [Swarms GitHub repository](https://github.com/kyegomez/swarms) and browse through the existing issues.
|
||||
|
||||
2. Find an issue that interests you and make a comment stating that you would like to work on it. Include a brief description of how you plan to solve the problem and any questions you may have.
|
||||
|
||||
3. Once a project coordinator assigns the issue to you, you can start working on it.
|
||||
|
||||
If you come across an issue that is unclear but still interests you, please post in the Discord server mentioned above. Someone from the community will be able to help clarify the issue in more detail.
|
||||
|
||||
We also welcome contributions to documentation, such as updating markdown files, adding docstrings, creating system architecture diagrams, and other related tasks.
|
||||
|
||||
## Submitting Your Work
|
||||
|
||||
To contribute your changes to Swarms, please follow these steps:
|
||||
|
||||
1. Fork the Swarms repository to your GitHub account. You can do this by clicking on the "Fork" button on the repository page.
|
||||
|
||||
2. Clone the forked repository to your local machine using the `git clone` command.
|
||||
|
||||
3. Before making any changes, make sure to sync your forked repository with the original repository to keep it up to date. You can do this by following the instructions [here](https://docs.github.com/en/github/collaborating-with-pull-requests/syncing-a-fork).
|
||||
|
||||
4. Create a new branch for your changes. This branch should have a descriptive name that reflects the task or issue you are working on.
|
||||
|
||||
5. Make your changes in the branch, focusing on a small, focused change that only affects a few files.
|
||||
|
||||
6. Run any necessary formatting or linting tools to ensure that your changes adhere to the project's coding standards.
|
||||
|
||||
7. Once your changes are ready, commit them to your branch with descriptive commit messages.
|
||||
|
||||
8. Push the branch to your forked repository.
|
||||
|
||||
9. Create a pull request (PR) from your branch to the main Swarms repository. Provide a clear and concise description of your changes in the PR.
|
||||
|
||||
10. Request a review from the project maintainers. They will review your changes, provide feedback, and suggest any necessary improvements.
|
||||
|
||||
11. Make any required updates or address any feedback provided during the review process.
|
||||
|
||||
12. Once your changes have been reviewed and approved, they will be merged into the main branch of the Swarms repository.
|
||||
|
||||
13. Congratulations! You have successfully contributed to Swarms.
|
||||
|
||||
Please note that during the review process, you may be asked to make changes or address certain issues. It is important to engage in open and constructive communication with the project maintainers to ensure the quality of your contributions.
|
||||
|
||||
## Developer Setup
|
||||
|
||||
If you are interested in setting up the Swarms development environment, please follow the instructions provided in the [developer setup guide](docs/developer-setup.md). This guide provides an overview of the different tools and technologies used in the project.
|
||||
|
||||
## Optimization Priorities
|
||||
|
||||
To continuously improve Swarms, we prioritize the following design objectives:
|
||||
|
||||
1. **Usability**: Increase the ease of use and user-friendliness of the swarm system to facilitate adoption and interaction with basic input.
|
||||
|
||||
2. **Reliability**: Improve the swarm's ability to obtain the desired output even with basic and un-detailed input.
|
||||
|
||||
3. **Speed**: Reduce the time it takes for the swarm to accomplish tasks by improving the communication layer, critiquing, and self-alignment with meta prompting.
|
||||
|
||||
4. **Scalability**: Ensure that the system is asynchronous, concurrent, and self-healing to support scalability.
|
||||
|
||||
Our goal is to continuously improve Swarms by following this roadmap while also being adaptable to new needs and opportunities as they arise.
|
||||
|
||||
## Join the Agora Community
|
||||
|
||||
Swarms is brought to you by Agora, the open-source AI research organization. Join the Agora community to connect with other researchers and developers working on AI projects.
|
||||
|
||||
- [Join the Agora Discord Server](https://discord.gg/qUtxnK2NMf)
|
||||
|
||||
Thank you for your contributions and for being a part of the Swarms and Agora community! Together, we can advance Humanity through the power of AI.
|
||||
@ -1,368 +0,0 @@
|
||||
# Swarms Documentation
|
||||
|
||||
## ClassName
|
||||
|
||||
Swarms
|
||||
|
||||
## Purpose
|
||||
|
||||
The Swarms module provides a powerful framework for creating and managing swarms of autonomous agents to accomplish complex tasks. It consists of the `WorkerNode` and `BossNode` classes, along with the `LLM` utility class, which allow you to easily set up and run a swarm of agents to tackle any objective. The module is highly configurable and extensible, providing flexibility to accommodate various use cases.
|
||||
|
||||
## Usage example
|
||||
|
||||
```python
|
||||
from swarms import Swarms
|
||||
|
||||
api_key = "your_openai_api_key"
|
||||
|
||||
# Initialize Swarms with your API key
|
||||
swarm = Swarms(api_key=api_key)
|
||||
|
||||
# Define an objective
|
||||
objective = "Please make a web GUI for using HTTP API server..."
|
||||
|
||||
# Run Swarms
|
||||
result = swarm.run(objective)
|
||||
|
||||
print(result)
|
||||
```
|
||||
|
||||
## Constructor
|
||||
|
||||
```python
|
||||
def __init__(self, openai_api_key)
|
||||
```
|
||||
|
||||
- `openai_api_key` (required): The API key for OpenAI's models.
|
||||
|
||||
## Methods
|
||||
|
||||
### run(objective)
|
||||
|
||||
Runs the swarm with the given objective by initializing the worker and boss nodes.
|
||||
|
||||
- `objective` (required): The objective or task to be accomplished by the swarm.
|
||||
|
||||
Returns the result of the swarm execution.
|
||||
|
||||
## Example Usage
|
||||
|
||||
```python
|
||||
from swarms import Swarms
|
||||
|
||||
api_key = "your_openai_api_key"
|
||||
|
||||
# Initialize Swarms with your API key
|
||||
swarm = Swarms(api_key=api_key)
|
||||
|
||||
# Define an objective
|
||||
objective = "Please make a web GUI for using HTTP API server..."
|
||||
|
||||
# Run Swarms
|
||||
result = swarm.run(objective)
|
||||
|
||||
print(result)
|
||||
```
|
||||
|
||||
## WorkerNode
|
||||
|
||||
The `WorkerNode` class represents an autonomous agent instance that functions as a worker to accomplish complex tasks. It has the ability to search the internet, process and generate images, text, audio, and more.
|
||||
|
||||
### Constructor
|
||||
|
||||
```python
|
||||
def __init__(self, llm, tools, vectorstore)
|
||||
```
|
||||
|
||||
- `llm` (required): The language model used by the worker node.
|
||||
- `tools` (required): A list of tools available to the worker node.
|
||||
- `vectorstore` (required): The vector store used by the worker node.
|
||||
|
||||
### Methods
|
||||
|
||||
- `create_agent(ai_name, ai_role, human_in_the_loop, search_kwargs)`: Creates an agent within the worker node.
|
||||
- `add_tool(tool)`: Adds a tool to the worker node.
|
||||
- `run(prompt)`: Runs the worker node to complete a task specified by the prompt.
|
||||
|
||||
### Example Usage
|
||||
|
||||
```python
|
||||
from swarms import worker_node
|
||||
|
||||
# Your OpenAI API key
|
||||
api_key = "your_openai_api_key"
|
||||
|
||||
# Initialize a WorkerNode with your API key
|
||||
node = worker_node(api_key)
|
||||
|
||||
# Define an objective
|
||||
objective = "Please make a web GUI for using HTTP API server..."
|
||||
|
||||
# Run the task
|
||||
task = node.run(objective)
|
||||
|
||||
print(task)
|
||||
```
|
||||
|
||||
## BossNode
|
||||
|
||||
The `BossNode` class represents an agent responsible for creating and managing tasks for the worker agent(s). It interacts with the worker node(s) to delegate tasks and monitor their progress.
|
||||
|
||||
### Constructor
|
||||
|
||||
```python
|
||||
def __init__(self, llm, vectorstore, agent_executor, max_iterations)
|
||||
```
|
||||
|
||||
- `llm` (required): The language model used by the boss node.
|
||||
- `vectorstore` (required): The vector store used by the boss node.
|
||||
- `agent_executor` (required): The agent executor used to execute tasks.
|
||||
- `max_iterations` (required): The maximum number of iterations for task execution.
|
||||
|
||||
### Methods
|
||||
|
||||
- `create_task(objective)`: Creates a task with the given objective.
|
||||
- `execute_task(task)`: Executes the given task by interacting with the worker agent(s).
|
||||
|
||||
## LLM
|
||||
|
||||
The `LLM` class is a utility class that provides an interface to different language models (LLMs) such as OpenAI's ChatGPT and Hugging Face models. It is used to initialize the language model for the worker and boss nodes.
|
||||
|
||||
### Constructor
|
||||
|
||||
```python
|
||||
def __init__(self, openai_api_key=None, hf_repo_id=None, hf_api_token=None, model_kwargs=None)
|
||||
```
|
||||
|
||||
- `openai_api_key` (optional): The API key for OpenAI's models.
|
||||
- `hf_repo_id` (optional): The repository ID for the Hugging Face model.
|
||||
- `hf_api_token` (optional): The API token for the Hugging Face model.
|
||||
- `model_kwargs` (optional): Additional keyword arguments to pass to the language model.
|
||||
|
||||
### Methods
|
||||
|
||||
- `run(prompt)`: Runs the language model with the given prompt and returns the generated response.
|
||||
|
||||
## Configuration
|
||||
|
||||
The Swarms module can be configured by modifying the following parameters:
|
||||
|
||||
### WorkerNode
|
||||
|
||||
- `llm_class`: The language model class to use for the worker node (default: `ChatOpenAI`).
|
||||
- `temperature`: The temperature parameter for the language model (default: `0.5`).
|
||||
|
||||
### BossNode
|
||||
|
||||
- `llm_class`: The language model class to use for the boss node (default: `OpenAI`).
|
||||
- `max_iterations`: The maximum number of iterations for task execution (default: `5`).
|
||||
|
||||
### LLM
|
||||
|
||||
- `openai_api_key`: The API key for OpenAI's models.
|
||||
- `hf_repo_id`: The repository ID for the Hugging Face model.
|
||||
- `hf_api_token`: The API token for the Hugging Face model.
|
||||
- `model_kwargs`: Additional keyword arguments to pass to the language model.
|
||||
|
||||
## Tool Configuration
|
||||
|
||||
The Swarms module supports various tools that can be added to the worker node for performing specific tasks. The following tools are available:
|
||||
|
||||
- `DuckDuckGoSearchRun`: A tool for performing web searches.
|
||||
- `WriteFileTool`: A tool for writing files.
|
||||
- `ReadFileTool`: A tool for reading files.
|
||||
- `process_csv`: A tool for processing CSV files.
|
||||
- `WebpageQATool`: A tool for performing question answering using web pages.
|
||||
|
||||
Additional tools can be added by extending the functionality of the `Tool` class.
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
For more advanced usage, you can customize the tools and parameters according to your specific requirements. The Swarms module provides flexibility and extensibility to accommodate various use cases.
|
||||
|
||||
For example, you can add your own custom tools by extending the `Tool` class and adding them to the worker node. You can also modify the prompt templates used by the boss node to customize the interaction between the boss and worker agents.
|
||||
|
||||
Please refer to the source code and documentation of the Swarms module for more details and examples.
|
||||
|
||||
## Conclusion
|
||||
|
||||
The Swarms module provides a powerful framework for creating and managing swarms of autonomous agents to accomplish complex tasks. With the `WorkerNode` and `BossNode` classes, along with the `LLM` utility class, you can easily set up and run a swarm of agents to tackle any objective. The module is highly configurable and extensible, allowing you to tailor it to your specific needs.
|
||||
|
||||
|
||||
## LLM
|
||||
### Purpose
|
||||
The `LLM` class provides an interface to different language models (LLMs) such as OpenAI's ChatGPT and Hugging Face models. It allows you to initialize and run a language model with a given prompt and obtain the generated response.
|
||||
|
||||
### Systems Understanding
|
||||
The `LLM` class takes an OpenAI API key or Hugging Face repository ID and API token as input. It uses these credentials to initialize the language model, either from OpenAI's models or from a specific Hugging Face repository. The language model can then be run with a prompt, and the generated response is returned.
|
||||
|
||||
### Usage Example
|
||||
```python
|
||||
from swarms import LLM
|
||||
|
||||
# Create an instance of LLM with OpenAI API key
|
||||
llm_instance = LLM(openai_api_key="your_openai_key")
|
||||
|
||||
# Run the language model with a prompt
|
||||
result = llm_instance.run("Who won the FIFA World Cup in 1998?")
|
||||
print(result)
|
||||
|
||||
# Create an instance of LLM with Hugging Face repository ID and API token
|
||||
llm_instance = LLM(hf_repo_id="google/flan-t5-xl", hf_api_token="your_hf_api_token")
|
||||
|
||||
# Run the language model with a prompt
|
||||
result = llm_instance.run("Who won the FIFA World Cup in 1998?")
|
||||
print(result)
|
||||
```
|
||||
|
||||
### Constructor
|
||||
```python
|
||||
def __init__(self, openai_api_key: Optional[str] = None,
|
||||
hf_repo_id: Optional[str] = None,
|
||||
hf_api_token: Optional[str] = None,
|
||||
model_kwargs: Optional[dict] = None)
|
||||
```
|
||||
- `openai_api_key` (optional): The API key for OpenAI's models.
|
||||
- `hf_repo_id` (optional): The repository ID for the Hugging Face model.
|
||||
- `hf_api_token` (optional): The API token for the Hugging Face model.
|
||||
- `model_kwargs` (optional): Additional keyword arguments to pass to the language model.
|
||||
|
||||
### Methods
|
||||
- `run(prompt: str) -> str`: Runs the language model with the given prompt and returns the generated response.
|
||||
|
||||
### Args
|
||||
- `prompt` (str): The prompt to be passed to the language model.
|
||||
|
||||
### Returns
|
||||
- `result` (str): The generated response from the language model.
|
||||
|
||||
## Conclusion
|
||||
The `LLM` class provides a convenient way to initialize and run different language models using either OpenAI's API or Hugging Face models. By providing the necessary credentials and a prompt, you can obtain the generated response from the language model.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# `GooglePalm` class:
|
||||
|
||||
### Example 1: Using Dictionaries as Messages
|
||||
|
||||
```python
|
||||
from google_palm import GooglePalm
|
||||
|
||||
# Initialize the GooglePalm instance
|
||||
gp = GooglePalm(
|
||||
client=your_client,
|
||||
model_name="models/chat-bison-001",
|
||||
temperature=0.7,
|
||||
top_p=0.9,
|
||||
top_k=10,
|
||||
n=5
|
||||
)
|
||||
|
||||
# Create some messages
|
||||
messages = [
|
||||
{"role": "system", "content": "You are a helpful assistant."},
|
||||
{"role": "user", "content": "Who won the world series in 2020?"},
|
||||
]
|
||||
|
||||
# Generate a response
|
||||
response = gp.generate(messages)
|
||||
|
||||
# Print the generated response
|
||||
print(response)
|
||||
```
|
||||
|
||||
### Example 2: Using BaseMessage and Its Subclasses as Messages
|
||||
|
||||
```python
|
||||
from google_palm import GooglePalm
|
||||
from langchain.schema.messages import SystemMessage, HumanMessage
|
||||
|
||||
# Initialize the GooglePalm instance
|
||||
gp = GooglePalm(
|
||||
client=your_client,
|
||||
model_name="models/chat-bison-001",
|
||||
temperature=0.7,
|
||||
top_p=0.9,
|
||||
top_k=10,
|
||||
n=5
|
||||
)
|
||||
|
||||
# Create some messages
|
||||
messages = [
|
||||
SystemMessage(content="You are a helpful assistant."),
|
||||
HumanMessage(content="Who won the world series in 2020?"),
|
||||
]
|
||||
|
||||
# Generate a response
|
||||
response = gp.generate(messages)
|
||||
|
||||
# Print the generated response
|
||||
print(response)
|
||||
```
|
||||
|
||||
### Example 3: Using GooglePalm with Asynchronous Function
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
from google_palm import GooglePalm
|
||||
from langchain.schema.messages import SystemMessage, HumanMessage
|
||||
|
||||
# Initialize the GooglePalm instance
|
||||
gp = GooglePalm(
|
||||
client=your_client,
|
||||
model_name="models/chat-bison-001",
|
||||
temperature=0.7,
|
||||
top_p=0.9,
|
||||
top_k=10,
|
||||
n=5
|
||||
)
|
||||
|
||||
# Create some messages
|
||||
messages = [
|
||||
SystemMessage(content="You are a helpful assistant."),
|
||||
HumanMessage(content="Who won the world series in 2020?"),
|
||||
]
|
||||
|
||||
# Define an asynchronous function
|
||||
async def generate_response():
|
||||
response = await gp._agenerate(messages)
|
||||
print(response)
|
||||
|
||||
# Run the asynchronous function
|
||||
asyncio.run(generate_response())
|
||||
```
|
||||
|
||||
Remember to replace `your_client` with an actual instance of your client. Also, ensure the `model_name` is the correct name of the model that you want to use.
|
||||
|
||||
The `temperature`, `top_p`, `top_k`, and `n` parameters control the randomness and diversity of the generated responses. You can adjust these parameters based on your application's requirements.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## `CodeInterpreter`:
|
||||
|
||||
```python
|
||||
tool = CodeInterpreter("Code Interpreter", "A tool to interpret code and generate useful outputs.")
|
||||
tool.run("Plot the bitcoin chart of 2023 YTD")
|
||||
|
||||
# Or with file inputs
|
||||
tool.run("Analyze this dataset and plot something interesting about it.", ["examples/assets/iris.csv"])
|
||||
```
|
||||
|
||||
To use the asynchronous version, simply replace `run` with `arun` and ensure your calling code is in an async context:
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
|
||||
tool = CodeInterpreter("Code Interpreter", "A tool to interpret code and generate useful outputs.")
|
||||
asyncio.run(tool.arun("Plot the bitcoin chart of 2023 YTD"))
|
||||
|
||||
# Or with file inputs
|
||||
asyncio.run(tool.arun("Analyze this dataset and plot something interesting about it.", ["examples/assets/iris.csv"]))
|
||||
```
|
||||
|
||||
The `CodeInterpreter` class is a flexible tool that uses the `CodeInterpreterSession` from the `codeinterpreterapi` package to run the code interpretation and return the result. It provides both synchronous and asynchronous methods for convenience, and ensures that exceptions are handled gracefully.
|
||||
@ -1,143 +0,0 @@
|
||||
## LLMs in Swarms Documentation
|
||||
|
||||
Welcome to the documentation for the llm section of the swarms package, designed to facilitate seamless integration with various AI language models and APIs. This package empowers developers, end-users, and system administrators to interact with AI models from different providers, such as OpenAI, Hugging Face, Google PaLM, and Anthropic.
|
||||
|
||||
### Table of Contents
|
||||
1. [OpenAI](#openai)
|
||||
2. [HuggingFace](#huggingface)
|
||||
3. [Google PaLM](#google-palm)
|
||||
4. [Anthropic](#anthropic)
|
||||
|
||||
### 1. OpenAI (swarms.models.OpenAI)
|
||||
|
||||
The OpenAI class provides an interface to interact with OpenAI's language models. It allows both synchronous and asynchronous interactions.
|
||||
|
||||
**Constructor:**
|
||||
```python
|
||||
OpenAI(api_key: str, system: str = None, console: bool = True, model: str = None, params: dict = None, save_messages: bool = True)
|
||||
```
|
||||
|
||||
**Attributes:**
|
||||
- `api_key` (str): Your OpenAI API key.
|
||||
- `system` (str, optional): A system message to be used in conversations.
|
||||
- `console` (bool, default=True): Display console logs.
|
||||
- `model` (str, optional): Name of the language model to use.
|
||||
- `params` (dict, optional): Additional parameters for model interactions.
|
||||
- `save_messages` (bool, default=True): Save conversation messages.
|
||||
|
||||
**Methods:**
|
||||
- `generate(message: str, **kwargs) -> str`: Generate a response using the OpenAI model.
|
||||
- `generate_async(message: str, **kwargs) -> str`: Generate a response asynchronously.
|
||||
- `ask_multiple(ids: List[str], question_template: str) -> List[str]`: Query multiple IDs simultaneously.
|
||||
- `stream_multiple(ids: List[str], question_template: str) -> List[str]`: Stream multiple responses.
|
||||
|
||||
**Usage Example:**
|
||||
```python
|
||||
from swarms import OpenAI
|
||||
import asyncio
|
||||
|
||||
chat = OpenAI(api_key="YOUR_OPENAI_API_KEY")
|
||||
|
||||
response = chat.generate("Hello, how can I assist you?")
|
||||
print(response)
|
||||
|
||||
ids = ["id1", "id2", "id3"]
|
||||
async_responses = asyncio.run(chat.ask_multiple(ids, "How is {id}?"))
|
||||
print(async_responses)
|
||||
```
|
||||
|
||||
### 2. HuggingFace (swarms.models.HuggingFaceLLM)
|
||||
|
||||
The HuggingFaceLLM class allows interaction with language models from Hugging Face.
|
||||
|
||||
**Constructor:**
|
||||
```python
|
||||
HuggingFaceLLM(model_id: str, device: str = None, max_length: int = 20, quantize: bool = False, quantization_config: dict = None)
|
||||
```
|
||||
|
||||
**Attributes:**
|
||||
- `model_id` (str): ID or name of the Hugging Face model.
|
||||
- `device` (str, optional): Device to run the model on (e.g., 'cuda', 'cpu').
|
||||
- `max_length` (int, default=20): Maximum length of generated text.
|
||||
- `quantize` (bool, default=False): Apply model quantization.
|
||||
- `quantization_config` (dict, optional): Configuration for quantization.
|
||||
|
||||
**Methods:**
|
||||
- `generate(prompt_text: str, max_length: int = None) -> str`: Generate text based on a prompt.
|
||||
|
||||
**Usage Example:**
|
||||
```python
|
||||
from swarms import HuggingFaceLLM
|
||||
|
||||
model_id = "gpt2"
|
||||
hugging_face_model = HuggingFaceLLM(model_id=model_id)
|
||||
|
||||
prompt = "Once upon a time"
|
||||
generated_text = hugging_face_model.generate(prompt)
|
||||
print(generated_text)
|
||||
```
|
||||
|
||||
### 3. Google PaLM (swarms.models.GooglePalm)
|
||||
|
||||
The GooglePalm class provides an interface for Google's PaLM Chat API.
|
||||
|
||||
**Constructor:**
|
||||
```python
|
||||
GooglePalm(model_name: str = "models/chat-bison-001", google_api_key: str = None, temperature: float = None, top_p: float = None, top_k: int = None, n: int = 1)
|
||||
```
|
||||
|
||||
**Attributes:**
|
||||
- `model_name` (str): Name of the Google PaLM model.
|
||||
- `google_api_key` (str, optional): Google API key.
|
||||
- `temperature` (float, optional): Temperature for text generation.
|
||||
- `top_p` (float, optional): Top-p sampling value.
|
||||
- `top_k` (int, optional): Top-k sampling value.
|
||||
- `n` (int, default=1): Number of candidate completions.
|
||||
|
||||
**Methods:**
|
||||
- `generate(messages: List[Dict[str, Any]], stop: List[str] = None, **kwargs) -> Dict[str, Any]`: Generate text based on a list of messages.
|
||||
- `__call__(messages: List[Dict[str, Any]], stop: List[str] = None, **kwargs) -> Dict[str, Any]`: Generate text using the call syntax.
|
||||
|
||||
**Usage Example:**
|
||||
```python
|
||||
from swarms import GooglePalm
|
||||
|
||||
google_palm = GooglePalm()
|
||||
messages = [{"role": "system", "content": "You are a helpful assistant"}, {"role": "user", "content": "Tell me a joke"}]
|
||||
|
||||
response = google_palm.generate(messages)
|
||||
print(response["choices"][0]["text"])
|
||||
```
|
||||
|
||||
### 4. Anthropic (swarms.models.Anthropic)
|
||||
|
||||
The Anthropic class enables interaction with Anthropic's large language models.
|
||||
|
||||
**Constructor:**
|
||||
```python
|
||||
Anthropic(model: str = "claude-2", max_tokens_to_sample: int = 256, temperature: float = None, top_k: int = None, top_p: float = None, streaming: bool = False, default_request_timeout: int = None)
|
||||
```
|
||||
|
||||
**Attributes:**
|
||||
- `model` (str): Name of the Anthropic model.
|
||||
- `max_tokens_to_sample` (int, default=256): Maximum tokens to sample.
|
||||
- `temperature` (float, optional): Temperature for text generation.
|
||||
- `top_k` (int, optional): Top-k sampling value.
|
||||
- `top_p` (float, optional): Top-p sampling value.
|
||||
- `streaming` (bool, default=False): Enable streaming mode.
|
||||
- `default_request_timeout` (int, optional): Default request timeout.
|
||||
|
||||
**Methods:**
|
||||
- `generate(prompt: str, stop: List[str] = None) -> str`: Generate text based on a prompt.
|
||||
|
||||
**Usage Example:**
|
||||
```python
|
||||
from swarms import Anthropic
|
||||
|
||||
anthropic = Anthropic()
|
||||
prompt = "Once upon a time"
|
||||
generated_text = anthropic.generate(prompt)
|
||||
print(generated_text)
|
||||
```
|
||||
|
||||
This concludes the documentation for the "swarms" package, providing you with tools to seamlessly integrate with various language models and APIs. Happy coding!
|
||||
@ -1,114 +0,0 @@
|
||||
Maximize Value Using Value Equation
|
||||
1. Maximize Dream Outcome: Solve Problems Worth $1 Billion
|
||||
Swarms empowers you to solve problems worth $1 billion, maximizing your dream outcome and the potential impact of your work.
|
||||
|
||||
2. Maximize Perceived Likelihood of Success: 99% Success Rate
|
||||
With a 99% success rate backed by testimonials and proven case studies, Swarms maximizes your confidence in achieving your desired outcomes.
|
||||
|
||||
3. Minimize Time to Success: Achieve Results 10x Faster
|
||||
Swarms minimizes the time it takes to achieve success by enabling you to accomplish tasks and goals 10 times faster than traditional methods.
|
||||
|
||||
4. Minimize Effort & Sacrifice: Save 100 Hours per Week
|
||||
By automating tasks and streamlining processes, Swarms saves you 100 hours per week, minimizing effort and sacrifice required to achieve your goals.
|
||||
|
||||
5. Maximize Efficiency: Increase Productivity by 300%
|
||||
Swarms optimizes your workflow, increasing productivity by 300% through intelligent automation and task optimization.
|
||||
|
||||
6. Minimize Errors: Ensure 99.9% Accuracy
|
||||
With Swarms' autonomous AI agents, you can achieve 99.9% accuracy, minimizing errors and ensuring the highest level of quality in your work.
|
||||
|
||||
7. Maximize Scalability: Handle 1 Million Transactions per Second
|
||||
Swarms scales with your growing needs, allowing you to handle up to 1 million transactions per second, ensuring seamless operations as your business expands.
|
||||
|
||||
8. Minimize Costs: Save $1 Million Annually
|
||||
By optimizing resource allocation and reducing manual labor, Swarms helps you save $1 million annually, minimizing costs and maximizing your bottom line.
|
||||
|
||||
9. Maximize Flexibility: Adapt to Changing Requirements in Minutes
|
||||
Swarms offers maximum flexibility, allowing you to adapt to changing requirements in minutes, ensuring you stay agile and responsive in a dynamic business environment.
|
||||
|
||||
10. Minimize Complexity: Simplify Complex Tasks by 90%
|
||||
Swarms simplifies complex tasks by 90%, breaking them down into manageable steps, minimizing complexity and enabling you to tackle even the most challenging projects.
|
||||
|
||||
11. Maximize Collaboration: Increase Team Efficiency by 200%
|
||||
With Swarms' coordination capabilities, you can increase team efficiency by 200%, fostering collaboration and driving innovation within your organization.
|
||||
|
||||
12. Minimize Downtime: Ensure 99.99% Uptime
|
||||
Swarms ensures 99.99% uptime, minimizing downtime and ensuring continuous operations, preventing costly disruptions to your business.
|
||||
|
||||
13. Maximize Security: Protect Your Data with Military-Grade Encryption
|
||||
Swarms prioritizes data security, providing military-grade encryption to protect your sensitive information, maximizing the security and confidentiality of your data.
|
||||
|
||||
14. Minimize Learning Curve: Get Up and Running in 1 Hour
|
||||
Swarms minimizes the learning curve, allowing you to get up and running in just 1 hour, maximizing your time and productivity.
|
||||
|
||||
15. Maximize Innovation: Stay Ahead with AI-Driven Insights
|
||||
Swarms leverages AI and autonomous agents to provide cutting-edge insights, enabling you to stay ahead of the competition and drive innovation in your industry.
|
||||
|
||||
16. Minimize Maintenance: Reduce Maintenance Costs by 80%
|
||||
Swarms reduces maintenance costs by 80%, minimizing the time and resources required for upkeep, allowing you to focus on your core business activities.
|
||||
|
||||
17. Maximize Adaptability: Customize to Your Needs with 100+ Configurable Options
|
||||
Swarms offers over 100 configurable options, maximizing adaptability and allowing you to customize the platform to suit your specific requirements.
|
||||
|
||||
|
||||
|
||||
1. Maximize Dream Outcome: Solve Problems Worth $1 Billion
|
||||
Swarms empowers you to solve problems worth $1 billion, maximizing your dream outcome and the potential impact of your work.
|
||||
|
||||
2. Maximize Perceived Likelihood of Success: 99% Success Rate
|
||||
With a 99% success rate backed by testimonials and proven case studies, Swarms maximizes your confidence in achieving your desired outcomes.
|
||||
|
||||
3. Minimize Time to Success: Achieve Results 10x Faster
|
||||
Swarms minimizes the time it takes to achieve success by enabling you to accomplish tasks and goals 10 times faster than traditional methods.
|
||||
|
||||
4. Minimize Effort & Sacrifice: Save 100 Hours per Week
|
||||
By automating tasks and streamlining processes, Swarms saves you 100 hours per week, minimizing effort and sacrifice required to achieve your goals.
|
||||
|
||||
5. Maximize Efficiency: Increase Productivity by 300%
|
||||
Swarms optimizes your workflow, increasing productivity by 300% through intelligent automation and task optimization.
|
||||
|
||||
6. Minimize Errors: Ensure 99.9% Accuracy
|
||||
With Swarms' autonomous AI agents, you can achieve 99.9% accuracy, minimizing errors and ensuring the highest level of quality in your work.
|
||||
|
||||
7. Maximize Scalability: Handle 1 Million Transactions per Second
|
||||
Swarms scales with your growing needs, allowing you to handle up to 1 million transactions per second, ensuring seamless operations as your business expands.
|
||||
|
||||
8. Minimize Costs: Save $1 Million Annually
|
||||
By optimizing resource allocation and reducing manual labor, Swarms helps you save $1 million annually, minimizing costs and maximizing your bottom line.
|
||||
|
||||
9. Maximize Flexibility: Adapt to Changing Requirements in Minutes
|
||||
Swarms offers maximum flexibility, allowing you to adapt to changing requirements in minutes, ensuring you stay agile and responsive in a dynamic business environment.
|
||||
|
||||
10. Minimize Complexity: Simplify Complex Tasks by 90%
|
||||
Swarms simplifies complex tasks by 90%, breaking them down into manageable steps, minimizing complexity and enabling you to tackle even the most challenging projects.
|
||||
|
||||
11. Maximize Collaboration: Increase Team Efficiency by 200%
|
||||
With Swarms' coordination capabilities, you can increase team efficiency by 200%, fostering collaboration and driving innovation within your organization.
|
||||
|
||||
12. Minimize Downtime: Ensure 99.99% Uptime
|
||||
Swarms ensures 99.99% uptime, minimizing downtime and ensuring continuous operations, preventing costly disruptions to your business.
|
||||
|
||||
13. Maximize Security: Protect Your Data with Military-Grade Encryption
|
||||
Swarms prioritizes data security, providing military-grade encryption to protect your sensitive information, maximizing the security and confidentiality of your data.
|
||||
|
||||
14. Minimize Learning Curve: Get Up and Running in 1 Hour
|
||||
Swarms minimizes the learning curve, allowing you to get up and running in just 1 hour, maximizing your time and productivity.
|
||||
|
||||
15. Maximize Innovation: Stay Ahead with AI-Driven Insights
|
||||
Swarms leverages AI and autonomous agents to provide cutting-edge insights, enabling you to stay ahead of the competition and drive innovation in your industry.
|
||||
|
||||
16. Minimize Maintenance: Reduce Maintenance Costs by 80%
|
||||
Swarms reduces maintenance costs by 80%, minimizing the time and resources required for upkeep, allowing you to focus on your core business activities.
|
||||
|
||||
17. Maximize Adaptability: Customize to Your Needs with 100+ Configurable Options
|
||||
Swarms offers over 100 configurable options, maximizing adaptability and allowing you to customize the platform to suit your specific requirements.
|
||||
|
||||
18. Minimize Risk: Mitigate Potential Losses by 95%
|
||||
Swarms helps you minimize risk by mitigating potential losses by 95%, providing a secure and reliable platform for your critical operations.
|
||||
|
||||
19. Maximize ROI: Achieve 500% Return on Investment
|
||||
With Swarms' efficiency and cost-saving capabilities, you can achieve a 500% return on investment, maximizing the value you get from your resources.
|
||||
|
||||
20. Minimize Waste: Reduce Resource Consumption by 70%
|
||||
Swarms minimizes waste by reducing resource consumption by 70%, optimizing resource allocation and promoting sustainability in your operations.
|
||||
|
||||
@ -1,7 +0,0 @@
|
||||
# Demo Ideas
|
||||
|
||||
* We could also try to create an AI influencer run by a swarm, let it create a whole identity and generate images, memes, and other content for Twitter, Reddit, etc.
|
||||
|
||||
* had a thought that we should have either a more general one of these or a swarm or both -- need something connecting all the calendars, events, and initiatives of all the AI communities, langchain, laion, eluther, lesswrong, gato, rob miles, chatgpt hackers, etc etc
|
||||
|
||||
* Swarm of AI influencers to spread marketing
|
||||
@ -1,101 +0,0 @@
|
||||
# Flywheel Effect for Developer Acquisition and Incentivization
|
||||
|
||||
As with the sales model, the developer acquisition and incentivization model also relies on a flywheel effect. This effect is particularly potent in a community-driven ecosystem such as ours, where the value proposition continually grows as more developers join and contribute to our projects. Here's how we could apply this approach:
|
||||
|
||||
## Step 1: Initial Value Proposition for Developers
|
||||
The starting point of the flywheel is to provide an attractive value proposition for developers. This could include:
|
||||
|
||||
- The ability to work on cutting-edge technology (Swarms, in this case).
|
||||
- The opportunity to contribute to a community-driven, open-source project.
|
||||
- The chance to learn from and collaborate with a global network of highly skilled developers.
|
||||
- An incentivization structure that rewards contributions (more on this later).
|
||||
|
||||
## Step 2: Developer Acquisition
|
||||
With the initial value proposition in place, we can move on to the actual acquisition of developers. This could be accomplished through:
|
||||
|
||||
- Active recruitment from online developer communities.
|
||||
- Referral programs that incentivize current contributors to bring in new developers.
|
||||
- Partnerships with universities, boot camps, and other institutions to attract budding developers.
|
||||
|
||||
## Step 3: Collaboration and Learning
|
||||
Once developers join our ecosystem, they become part of a collaborative community where they can learn from each other, improve their skills, and work on exciting and meaningful projects. This, in turn, attracts more developers, adding momentum to the flywheel.
|
||||
|
||||
## Step 4: Recognizing and Rewarding Contributions
|
||||
To keep the flywheel spinning, it's crucial to recognize and reward the contributions made by developers. This can be done in various ways:
|
||||
|
||||
- Monetary rewards: Developers can be paid based on the value their contributions bring to the project. This could be determined through various metrics, such as the complexity of their contributions, the impact on the project, or the amount of their code that gets used in production.
|
||||
|
||||
- Reputation and recognition: The open-source nature of our project means that all contributions are public and can be used by developers to build their professional profiles. Contributors could also be highlighted on our website, in our communications, and at community events.
|
||||
|
||||
- Career advancement: Developers who consistently make valuable contributions could be offered positions of leadership within the project, such as becoming maintainers or joining a steering committee.
|
||||
|
||||
- Agora Tokens: We could create a system of tokens that are earned based on contributions. These tokens could be exchanged for various benefits, such as access to exclusive events, special training, or even physical goods.
|
||||
|
||||
## Step 5: Scaling the Flywheel
|
||||
With the flywheel in motion, the next step is to scale. As our community grows and our technology improves, we can attract more developers and create more value. This leads to a virtuous cycle of growth, where each new developer adds to the attractiveness of our project, which in turn brings in more developers.
|
||||
|
||||
In essence, this flywheel approach is about creating a community where everyone benefits from each other's contributions. The more value a developer adds, the more they are rewarded. The more developers contribute, the more value is created, attracting even more developers.
|
||||
|
||||
Such a model not only aligns with our values of openness, collaboration, and shared success, but it also gives us a sustainable and scalable method for growing our developer community. It makes Agora not just a place to work, but also a place to learn, grow, and be recognized for one's contributions. This is a powerful way to ensure that we can continue to advance our technology and make a significant impact on the world.
|
||||
|
||||
|
||||
# Risks and mitigations
|
||||
|
||||
The open source engineering freelancer model brings with it its own set of potential risks and challenges. Here's an exploration of some of these, along with strategies for mitigation:
|
||||
|
||||
**1. Quality Control:** When dealing with a wide network of freelance contributors, ensuring a consistent standard of quality across all contributions can be challenging. This can be mitigated by implementing rigorous review processes and standards, establishing an automated testing infrastructure, and fostering a culture of quality among contributors. Providing clear contribution guidelines, code style guides, and other resources can help freelancers understand what's expected of them. Providing Educational resources such as sponsoring creators like Yannic, and even making our own courses and then building techno-monasteries where young people can come in and research for free.
|
||||
|
||||
**2. Security Risks:** Open-source projects can be susceptible to malicious contributors, who might introduce vulnerabilities into the codebase. To mitigate this, rigorous code review processes should be in place. Additionally, adopting a "trust but verify" approach, leveraging automated security scanning tools, and conducting periodic security audits can be beneficial.
|
||||
|
||||
**3. Intellectual Property Issues:** Open-source projects can face risks around intellectual property, such as contributors introducing code that infringes on someone else's copyrights. A clear Contributor License Agreement (CLA) should be in place, which contributors need to agree to before their contributions can be accepted. This helps protect the project and its users from potential legal issues.
|
||||
|
||||
**4. Loss of Core Focus:** With numerous contributors focusing on different aspects of the project, there can be a risk of losing sight of the project's core objectives. Maintaining a clear roadmap, having a strong leadership team, and ensuring open and regular communication can help keep the project focused.
|
||||
|
||||
**5. Contributor Burnout:** Freelancers contributing in their free time might face burnout, especially if they feel their contributions aren't being recognized or rewarded. To mitigate this, create a supportive environment where contributors' efforts are acknowledged and rewarded. This might include monetary rewards, but can also include non-monetary rewards like public recognition, advancement opportunities within the project, and so on.
|
||||
|
||||
**6. Fragmentation:** In open source projects, there is a risk of fragmentation where different contributors or groups of contributors might want to take the project in different directions. Strong project governance, a clear roadmap, and open, transparent decision-making processes can help mitigate this risk.
|
||||
|
||||
**7. Dependency on Key Individuals:** If key parts of the project are understood and maintained by only a single contributor, there is a risk if that individual decides to leave or is unable to contribute for some reason. This can be mitigated by ensuring knowledge is shared and responsibilities are spread among multiple contributors.
|
||||
|
||||
Overall, these risks can be managed with proper planning, clear communication, and the implementation of good governance and security practices. It's essential to approach the open source model with a clear understanding of these potential pitfalls and a plan to address them.
|
||||
|
||||
## Plan to Gain Open Source Developers for SWARMS
|
||||
|
||||
Attracting and retaining open-source developers is a challenge that requires a strategic approach. This plan emphasizes delivering value to the developers as well as providing recognition, community, and financial incentives.
|
||||
|
||||
### Step 1: Foster an Engaging and Inclusive Community
|
||||
|
||||
The first step is to foster an engaging and inclusive open-source community around SWARMS. This community should be a place where developers feel welcome and excited to contribute. Regular community events (both online and offline), engaging content, and a supportive environment can help attract and retain developers.
|
||||
|
||||
### Step 2: Provide Clear Contribution Guidelines
|
||||
|
||||
Providing clear and comprehensive contribution guidelines will make it easier for developers to get started. These guidelines should cover the basics of how to set up the development environment, how to submit changes, and how the code review process works.
|
||||
|
||||
### Step 3: Offer Educational Resources and Training
|
||||
|
||||
Providing training and educational resources can help developers grow their skills and contribute more effectively. These resources could include tutorials, webinars, workshops, documentation, and more.
|
||||
|
||||
### Step 4: Establish a Recognition and Reward System
|
||||
|
||||
Recognize and reward the contributions of developers. This could involve public recognition, like featuring contributors on the SWARMS website, as well as financial incentives. Implementing a system where developers earn a share of the revenue from SWARMS based on their contributions can be a strong motivator.
|
||||
|
||||
### Step 5: Implement a Strong Support System
|
||||
|
||||
Offer strong technical support to developers. This could include dedicated channels for developers to ask questions, request feedback, and share their progress. Having core team members available to provide assistance and mentorship can be hugely beneficial.
|
||||
|
||||
### Step 6: Regularly Solicit and Incorporate Feedback
|
||||
|
||||
Regularly ask for feedback from developers and incorporate their suggestions into future developments. This shows developers that their opinions are valued and can lead to improvements in SWARMS.
|
||||
|
||||
## Flywheel for Gaining More Open Source Developers
|
||||
|
||||
Now let's look at the flywheel effect that can result from this plan. The idea of the flywheel is that each part of the process feeds into the next, creating a cycle of growth that becomes self-sustaining over time.
|
||||
|
||||
1. We build an engaging and supportive community around SWARMS.
|
||||
2. This community attracts more developers who are interested in contributing to SWARMS.
|
||||
3. As more developers contribute, the quality and scope of SWARMS improve, making it more attractive to potential users.
|
||||
4. As SWARMS gains more users, the potential revenue from SWARMS increases, allowing for larger rewards to be distributed to developers.
|
||||
5. The prospect of these rewards attracts even more developers to the SWARMS community.
|
||||
6. The cycle repeats, with each iteration attracting more developers, improving SWARMS, increasing its user base, and raising potential rewards.
|
||||
|
||||
Through this plan and the resulting flywheel effect, we can attract a strong, committed team of open-source developers to build SWARMS and make it the best it can be.
|
||||
@ -1,101 +0,0 @@
|
||||
# The Swarms Flywheel
|
||||
|
||||
1. **Building a Supportive Community:** Initiate by establishing an engaging and inclusive open-source community for both developers and sales freelancers around Swarms. Regular online meetups, webinars, tutorials, and sales training can make them feel welcome and encourage contributions and sales efforts.
|
||||
|
||||
2. **Increased Contributions and Sales Efforts:** The more engaged the community, the more developers will contribute to Swarms and the more effort sales freelancers will put into selling Swarms.
|
||||
|
||||
3. **Improvement in Quality and Market Reach:** More developer contributions mean better quality, reliability, and feature offerings from Swarms. Simultaneously, increased sales efforts from freelancers boost Swarms' market penetration and visibility.
|
||||
|
||||
4. **Rise in User Base:** As Swarms becomes more robust and more well-known, the user base grows, driving more revenue.
|
||||
|
||||
5. **Greater Financial Incentives:** Increased revenue can be redirected to offer more significant financial incentives to both developers and salespeople. Developers can be incentivized based on their contribution to Swarms, and salespeople can be rewarded with higher commissions.
|
||||
|
||||
6. **Attract More Developers and Salespeople:** These financial incentives, coupled with the recognition and experience from participating in a successful project, attract more developers and salespeople to the community.
|
||||
|
||||
7. **Wider Adoption of Swarms:** An ever-improving product, a growing user base, and an increasing number of passionate salespeople accelerate the adoption of Swarms.
|
||||
|
||||
8. **Return to Step 1:** As the community, user base, and sales network continue to grow, the cycle repeats, each time speeding up the flywheel.
|
||||
|
||||
|
||||
```markdown
|
||||
+---------------------+
|
||||
| Building a |
|
||||
| Supportive | <--+
|
||||
| Community | |
|
||||
+--------+-----------+ |
|
||||
| |
|
||||
v |
|
||||
+--------+-----------+ |
|
||||
| Increased | |
|
||||
| Contributions & | |
|
||||
| Sales Efforts | |
|
||||
+--------+-----------+ |
|
||||
| |
|
||||
v |
|
||||
+--------+-----------+ |
|
||||
| Improvement in | |
|
||||
| Quality & Market | |
|
||||
| Reach | |
|
||||
+--------+-----------+ |
|
||||
| |
|
||||
v |
|
||||
+--------+-----------+ |
|
||||
| Rise in User | |
|
||||
| Base | |
|
||||
+--------+-----------+ |
|
||||
| |
|
||||
v |
|
||||
+--------+-----------+ |
|
||||
| Greater Financial | |
|
||||
| Incentives | |
|
||||
+--------+-----------+ |
|
||||
| |
|
||||
v |
|
||||
+--------+-----------+ |
|
||||
| Attract More | |
|
||||
| Developers & | |
|
||||
| Salespeople | |
|
||||
+--------+-----------+ |
|
||||
| |
|
||||
v |
|
||||
+--------+-----------+ |
|
||||
| Wider Adoption of | |
|
||||
| Swarms |----+
|
||||
+---------------------+
|
||||
```
|
||||
|
||||
|
||||
# Potential Risks and Mitigations:
|
||||
|
||||
1. **Insufficient Contributions or Quality of Work**: Open-source efforts rely on individuals being willing and able to spend time contributing. If not enough people participate, or the work they produce is of poor quality, the product development could stall.
|
||||
* **Mitigation**: Create a robust community with clear guidelines, support, and resources. Provide incentives for quality contributions, such as a reputation system, swag, or financial rewards. Conduct thorough code reviews to ensure the quality of contributions.
|
||||
|
||||
2. **Lack of Sales Results**: Commission-based salespeople will only continue to sell the product if they're successful. If they aren't making enough sales, they may lose motivation and cease their efforts.
|
||||
* **Mitigation**: Provide adequate sales training and resources. Ensure the product-market fit is strong, and adjust messaging or sales tactics as necessary. Consider implementing a minimum commission or base pay to reduce risk for salespeople.
|
||||
|
||||
3. **Poor User Experience or User Adoption**: If users don't find the product useful or easy to use, they won't adopt it, and the user base won't grow. This could also discourage salespeople and contributors.
|
||||
* **Mitigation**: Prioritize user experience in the product development process. Regularly gather and incorporate user feedback. Ensure robust user support is in place.
|
||||
|
||||
4. **Inadequate Financial Incentives**: If the financial rewards don't justify the time and effort contributors and salespeople are putting in, they will likely disengage.
|
||||
* **Mitigation**: Regularly review and adjust financial incentives as needed. Ensure that the method for calculating and distributing rewards is transparent and fair.
|
||||
|
||||
5. **Security and Compliance Risks**: As the user base grows and the software becomes more complex, the risk of security issues increases. Moreover, as contributors from various regions join, compliance with various international laws could become an issue.
|
||||
* **Mitigation**: Establish strong security practices from the start. Regularly conduct security audits. Seek legal counsel to understand and adhere to international laws and regulations.
|
||||
|
||||
## Activation Plan for the Flywheel:
|
||||
|
||||
1. **Community Building**: Begin by fostering a supportive community around Swarms. Encourage early adopters to contribute and provide feedback. Create comprehensive documentation, community guidelines, and a forum for discussion and support.
|
||||
|
||||
2. **Sales and Development Training**: Provide resources and training for salespeople and developers. Make sure they understand the product, its value, and how to effectively contribute or sell.
|
||||
|
||||
3. **Increase Contributions and Sales Efforts**: Encourage increased participation by highlighting successful contributions and sales, rewarding top contributors and salespeople, and regularly communicating about the project's progress and impact.
|
||||
|
||||
4. **Iterate and Improve**: Continually gather and implement feedback to improve Swarms and its market reach. The better the product and its alignment with the market, the more the user base will grow.
|
||||
|
||||
5. **Expand User Base**: As the product improves and sales efforts continue, the user base should grow. Ensure you have the infrastructure to support this growth and maintain a positive user experience.
|
||||
|
||||
6. **Increase Financial Incentives**: As the user base and product grow, so too should the financial incentives. Make sure rewards continue to be competitive and attractive.
|
||||
|
||||
7. **Attract More Contributors and Salespeople**: As the financial incentives and success of the product increase, this should attract more contributors and salespeople, further feeding the flywheel.
|
||||
|
||||
Throughout this process, it's important to regularly reassess and adjust your strategy as necessary. Stay flexible and responsive to changes in the market, user feedback, and the evolving needs of the community.
|
||||
@ -1,149 +0,0 @@
|
||||
# Bounty Program
|
||||
|
||||
Our bounty program is an exciting opportunity for contributors to help us build the future of Swarms. By participating, you can earn rewards while contributing to a project that aims to revolutionize digital activity.
|
||||
|
||||
Here's how it works:
|
||||
|
||||
1. **Check out our Roadmap**: We've shared our roadmap detailing our short and long-term goals. These are the areas where we're seeking contributions.
|
||||
|
||||
2. **Pick a Task**: Choose a task from the roadmap that aligns with your skills and interests. If you're unsure, you can reach out to our team for guidance.
|
||||
|
||||
3. **Get to Work**: Once you've chosen a task, start working on it. Remember, quality is key. We're looking for contributions that truly make a difference.
|
||||
|
||||
4. **Submit your Contribution**: Once your work is complete, submit it for review. We'll evaluate your contribution based on its quality, relevance, and the value it brings to Swarms.
|
||||
|
||||
5. **Earn Rewards**: If your contribution is approved, you'll earn a bounty. The amount of the bounty depends on the complexity of the task, the quality of your work, and the value it brings to Swarms.
|
||||
|
||||
## The Three Phases of Our Bounty Program
|
||||
|
||||
### Phase 1: Building the Foundation
|
||||
In the first phase, our focus is on building the basic infrastructure of Swarms. This includes developing key components like the Swarms class, integrating essential tools, and establishing task completion and evaluation logic. We'll also start developing our testing and evaluation framework during this phase. If you're interested in foundational work and have a knack for building robust, scalable systems, this phase is for you.
|
||||
|
||||
### Phase 2: Enhancing the System
|
||||
In the second phase, we'll focus on enhancing Swarms by integrating more advanced features, improving the system's efficiency, and refining our testing and evaluation framework. This phase involves more complex tasks, so if you enjoy tackling challenging problems and contributing to the development of innovative features, this is the phase for you.
|
||||
|
||||
### Phase 3: Towards Super-Intelligence
|
||||
The third phase of our bounty program is the most exciting - this is where we aim to achieve super-intelligence. In this phase, we'll be working on improving the swarm's capabilities, expanding its skills, and fine-tuning the system based on real-world testing and feedback. If you're excited about the future of AI and want to contribute to a project that could potentially transform the digital world, this is the phase for you.
|
||||
|
||||
Remember, our roadmap is a guide, and we encourage you to bring your own ideas and creativity to the table. We believe that every contribution, no matter how small, can make a difference. So join us on this exciting journey and help us create the future of Swarms.
|
||||
|
||||
**To participate in our bounty program, visit the [Swarms Bounty Program Page](https://swarms.ai/bounty).** Let's build the future together!
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Bounties for Roadmap Items
|
||||
|
||||
To accelerate the development of Swarms and to encourage more contributors to join our journey towards automating every digital activity in existence, we are announcing a Bounty Program for specific roadmap items. Each bounty will be rewarded based on the complexity and importance of the task. Below are the items available for bounty:
|
||||
|
||||
1. **Multi-Agent Debate Integration**: $2000
|
||||
2. **Meta Prompting Integration**: $1500
|
||||
3. **Swarms Class**: $1500
|
||||
4. **Integration of Additional Tools**: $1000
|
||||
5. **Task Completion and Evaluation Logic**: $2000
|
||||
6. **Ocean Integration**: $2500
|
||||
7. **Improved Communication**: $2000
|
||||
8. **Testing and Evaluation**: $1500
|
||||
9. **Worker Swarm Class**: $2000
|
||||
10. **Documentation**: $500
|
||||
|
||||
For each bounty task, there will be a strict evaluation process to ensure the quality of the contribution. This process includes a thorough review of the code and extensive testing to ensure it meets our standards.
|
||||
|
||||
# 3-Phase Testing Framework
|
||||
|
||||
To ensure the quality and efficiency of the Swarm, we will introduce a 3-phase testing framework which will also serve as our evaluation criteria for each of the bounty tasks.
|
||||
|
||||
## Phase 1: Unit Testing
|
||||
In this phase, individual modules will be tested to ensure that they work correctly in isolation. Unit tests will be designed for all functions and methods, with an emphasis on edge cases.
|
||||
|
||||
## Phase 2: Integration Testing
|
||||
After passing unit tests, we will test the integration of different modules to ensure they work correctly together. This phase will also test the interoperability of the Swarm with external systems and libraries.
|
||||
|
||||
## Phase 3: Benchmarking & Stress Testing
|
||||
In the final phase, we will perform benchmarking and stress tests. We'll push the limits of the Swarm under extreme conditions to ensure it performs well in real-world scenarios. This phase will measure the performance, speed, and scalability of the Swarm under high load conditions.
|
||||
|
||||
By following this 3-phase testing framework, we aim to develop a reliable, high-performing, and scalable Swarm that can automate all digital activities.
|
||||
|
||||
# Reverse Engineering to Reach Phase 3
|
||||
|
||||
To reach the Phase 3 level, we need to reverse engineer the tasks we need to complete. Here's an example of what this might look like:
|
||||
|
||||
1. **Set Clear Expectations**: Define what success looks like for each task. Be clear about the outputs and outcomes we expect. This will guide our testing and development efforts.
|
||||
|
||||
2. **Develop Testing Scenarios**: Create a comprehensive list of testing scenarios that cover both common and edge cases. This will help us ensure that our Swarm can handle a wide range of situations.
|
||||
|
||||
3. **Write Test Cases**: For each scenario, write detailed test cases that outline the exact steps to be followed, the inputs to be used, and the expected outputs.
|
||||
|
||||
4. **Execute the Tests**: Run the test cases on our Swarm, making note of any issues or bugs that arise.
|
||||
|
||||
5. **Iterate and Improve**: Based on the results of our tests, iterate and improve our Swarm. This may involve fixing bugs, optimizing code, or redesigning parts of our system.
|
||||
|
||||
6. **Repeat**: Repeat this process until our Swarm meets our expectations and passes all test cases.
|
||||
|
||||
By following these steps, we will systematically build, test, and improve our Swarm until it reaches the Phase 3 level. This methodical approach will help us ensure that we create a reliable, high-performing, and scalable Swarm that can truly automate all digital activities.
|
||||
|
||||
Let's shape the future of digital automation together!
|
||||
|
||||
|
||||
--------------------
|
||||
# Super-Intelligence Roadmap
|
||||
|
||||
Creating a Super-Intelligent Swarm involves three main phases, where each phase has multiple sub-stages, each of which will require rigorous testing and evaluation to ensure progress towards super-intelligence.
|
||||
|
||||
## Phase 1: Narrow Intelligence
|
||||
|
||||
In this phase, the goal is to achieve high performance in specific tasks. These tasks will be predefined and the swarm will be trained and tested on these tasks.
|
||||
|
||||
1. **Single Task Mastery**: Focus on mastering one task at a time. This can range from simple tasks like image recognition to complex tasks like natural language processing.
|
||||
|
||||
2. **Task Switching**: Train the swarm to switch between different tasks effectively. This includes being able to stop one task and start another one without any loss in performance.
|
||||
|
||||
3. **Multi-tasking**: The swarm should be capable of performing multiple tasks simultaneously without any degradation in performance.
|
||||
|
||||
## Phase 2: General Intelligence
|
||||
|
||||
In this phase, the swarm will be trained to handle a variety of tasks that were not part of the original training set.
|
||||
|
||||
1. **Transfer Learning**: The swarm should be able to transfer knowledge learned in one context to another context. This means being able to apply knowledge learned in one task to a different but related task.
|
||||
|
||||
2. **Adaptive Learning**: The swarm should be capable of adapting its learning strategies based on the task at hand. This includes being able to adjust its learning rate, exploration vs exploitation balance, etc.
|
||||
|
||||
3. **Self-Learning**: The swarm should be able to learn new tasks on its own without any external guidance. This includes being able to understand the task requirements, find relevant information, learn the task, and evaluate its performance.
|
||||
|
||||
## Phase 3: Super Intelligence
|
||||
|
||||
In this phase, the swarm will surpass human-level performance in most economically valuable work. This involves the swarm being able to solve complex real-world problems, make accurate predictions, and generate innovative solutions.
|
||||
|
||||
1. **Complex Problem Solving**: The swarm should be able to solve complex real-world problems. This includes being able to understand the problem, identify relevant information, generate solutions, evaluate the solutions, and implement the best solution.
|
||||
|
||||
2. **Predictive Abilities**: The swarm should be able to make accurate predictions about future events based on past data. This includes being able to understand the data, identify relevant patterns, make accurate predictions, and evaluate the accuracy of its predictions.
|
||||
|
||||
3. **Innovation**: The swarm should be able to generate innovative solutions to problems. This includes being able to think creatively, generate novel ideas, evaluate the ideas, and implement the best idea.
|
||||
|
||||
4. **Self-improvement**: The swarm should be capable of improving its own capabilities. This includes being able to identify areas of weakness, find ways to improve, and implement the improvements.
|
||||
|
||||
5. **Understanding**: The swarm should be able to understand complex concepts, make inferences, and draw conclusions. This includes being able to understand natural language, reason logically, and make sound judgments.
|
||||
|
||||
Each of these stages will require extensive testing and evaluation to ensure progress towards super-intelligence.
|
||||
|
||||
# Reverse-Engineering Super-Intelligence
|
||||
|
||||
To reach the Phase 3 level of super-intelligence, we need to reverse engineer the tasks that need to be completed. Here's an outline of what this might look like:
|
||||
|
||||
1. **Setting Success Metrics**: For each stage, define clear success metrics. These metrics should be quantitative and measurable, and they should align with the objectives of the stage.
|
||||
|
||||
2. **Identifying Prerequisites**: Determine what needs to be in place before each stage can begin. This could include certain capabilities, resources, or technologies.
|
||||
|
||||
3. **Developing Training Programs**: For each stage, develop a comprehensive training program. This should include a variety of tasks that will challenge the swarm and push it to
|
||||
|
||||
develop the necessary capabilities.
|
||||
|
||||
4. **Creating Testing Protocols**: Develop rigorous testing protocols for each stage. These protocols should test all aspects of the swarm's performance and they should be designed to push the swarm to its limits.
|
||||
|
||||
5. **Iterating and Improving**: Based on the results of the tests, iterate and improve the swarm. This could involve adjusting the training program, modifying the swarm's architecture, or tweaking its learning algorithms.
|
||||
|
||||
6. **Moving to the Next Stage**: Once the swarm has met the success metrics for a stage, it can move on to the next stage. This process continues until the swarm has reached the level of super-intelligence.
|
||||
|
||||
This process will require a significant amount of time, resources, and effort. However, by following this structured approach, we can systematically guide the swarm towards super-intelligence.
|
||||
|
||||
@ -1,165 +0,0 @@
|
||||
# Swarms Monetization Strategy
|
||||
|
||||
This strategy includes a variety of business models, potential revenue streams, cashflow structures, and customer identification methods. Let's explore these further.
|
||||
|
||||
## Business Models
|
||||
|
||||
1. **Platform as a Service (PaaS):** Provide the Swarms AI platform on a subscription basis, charged monthly or annually. This could be tiered based on usage and access to premium features.
|
||||
|
||||
2. **API Usage-based Pricing:** Charge customers based on their usage of the Swarms API. The more requests made, the higher the fee.
|
||||
|
||||
3. **Managed Services:** Offer complete end-to-end solutions where you manage the entire AI infrastructure for the clients. This could be on a contract basis with a recurring fee.
|
||||
|
||||
4. **Training and Certification:** Provide Swarms AI training and certification programs for interested developers and businesses. These could be monetized as separate courses or subscription-based access.
|
||||
|
||||
5. **Partnerships:** Collaborate with large enterprises and offer them dedicated Swarm AI services. These could be performance-based contracts, ensuring a mutually beneficial relationship.
|
||||
|
||||
6. **Data as a Service (DaaS):** Leverage the data generated by Swarms for insights and analytics, providing valuable business intelligence to clients.
|
||||
|
||||
## Potential Revenue Streams
|
||||
|
||||
1. **Subscription Fees:** This would be the main revenue stream from providing the Swarms platform as a service.
|
||||
|
||||
2. **Usage Fees:** Additional revenue can come from usage fees for businesses that have high demand for Swarms API.
|
||||
|
||||
3. **Contract Fees:** From offering managed services and bespoke solutions to businesses.
|
||||
|
||||
4. **Training Fees:** Revenue from providing training and certification programs to developers and businesses.
|
||||
|
||||
5. **Partnership Contracts:** Large-scale projects with enterprises, involving dedicated Swarm AI services, could provide substantial income.
|
||||
|
||||
6. **Data Insights:** Revenue from selling valuable business intelligence derived from Swarm's aggregated and anonymized data.
|
||||
|
||||
## Potential Customers
|
||||
|
||||
1. **Businesses Across Sectors:** Any business seeking to leverage AI for automation, efficiency, and data insights could be a potential customer. This includes sectors like finance, eCommerce, logistics, healthcare, and more.
|
||||
|
||||
2. **Developers:** Both freelance and those working in organizations could use Swarms to enhance their projects and services.
|
||||
|
||||
3. **Enterprises:** Large enterprises looking to automate and optimize their operations could greatly benefit from Swarms.
|
||||
|
||||
4. **Educational Institutions:** Universities and research institutions could leverage Swarms for research and teaching purposes.
|
||||
|
||||
## Roadmap
|
||||
|
||||
1. **Landing Page Creation:** Develop a dedicated product page on apac.ai for Swarms.
|
||||
|
||||
2. **Hosted Swarms API:** Launch a cloud-based Swarms API service. It should be highly reliable, with robust documentation to attract daily users.
|
||||
|
||||
3. **Consumer and Enterprise Subscription Service:** Launch a comprehensive subscription service on The Domain. This would provide users with access to a wide array of APIs and data streams.
|
||||
|
||||
4. **Dedicated Capacity Deals:** Partner with large enterprises to offer them dedicated Swarm AI solutions for automating their operations.
|
||||
|
||||
5. **Enterprise Partnerships:** Develop partnerships with large enterprises for extensive contract-based projects.
|
||||
|
||||
6. **Integration with Collaboration Platforms:** Develop Swarms bots for platforms like Discord and Slack, charging users a subscription fee for access.
|
||||
|
||||
7. **Personal Data Instances:** Offer users dedicated instances of all their data that the Swarm can query as needed.
|
||||
|
||||
8. **Browser Extension:** Develop a browser extension that integrates with the Swarms platform, offering users a more seamless experience.
|
||||
|
||||
Remember, customer satisfaction and a value-centric approach are at the core of any successful monetization strategy. It's essential to continuously iterate and improve the product based on customer feedback and evolving market needs.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
1. **Platform as a Service (PaaS):** Create a cloud-based platform that allows users to build, run, and manage applications without the complexity of maintaining the infrastructure. You could charge users a subscription fee for access to the platform and provide different pricing tiers based on usage levels. This could be an attractive solution for businesses that do not have the capacity to build or maintain their own swarm intelligence solutions.
|
||||
|
||||
2. **Professional Services:** Offer consultancy and implementation services to businesses looking to utilize the Swarm technology. This could include assisting with integration into existing systems, offering custom development services, or helping customers to build specific solutions using the framework.
|
||||
|
||||
3. **Education and Training:** Create a certification program for developers or companies looking to become proficient with the Swarms framework. This could be sold as standalone courses, or bundled with other services.
|
||||
|
||||
4. **Managed Services:** Some companies may prefer to outsource the management of their Swarm-based systems. A managed services solution could take care of all the technical aspects, from hosting the solution to ensuring it runs smoothly, allowing the customer to focus on their core business.
|
||||
|
||||
5. **Data Analysis and Insights:** Swarm intelligence can generate valuable data and insights. By anonymizing and aggregating this data, you could provide industry reports, trend analysis, and other valuable insights to businesses.
|
||||
|
||||
As for the type of platform, Swarms can be offered as a cloud-based solution given its scalability and flexibility. This would also allow you to apply a SaaS/PaaS type monetization model, which provides recurring revenue.
|
||||
|
||||
Potential customers could range from small to large enterprises in various sectors such as logistics, eCommerce, finance, and technology, who are interested in leveraging artificial intelligence and machine learning for complex problem solving, optimization, and decision-making.
|
||||
|
||||
**Product Brief Monetization Strategy:**
|
||||
|
||||
Product Name: Swarms.AI Platform
|
||||
|
||||
Product Description: A cloud-based AI and ML platform harnessing the power of swarm intelligence.
|
||||
|
||||
1. **Platform as a Service (PaaS):** Offer tiered subscription plans (Basic, Premium, Enterprise) to accommodate different usage levels and business sizes.
|
||||
|
||||
2. **Professional Services:** Offer consultancy and custom development services to tailor the Swarms solution to the specific needs of the business.
|
||||
|
||||
3. **Education and Training:** Launch an online Swarms.AI Academy with courses and certifications for developers and businesses.
|
||||
|
||||
4. **Managed Services:** Provide a premium, fully-managed service offering that includes hosting, maintenance, and 24/7 support.
|
||||
|
||||
5. **Data Analysis and Insights:** Offer industry reports and customized insights generated from aggregated and anonymized Swarm data.
|
||||
|
||||
Potential Customers: Enterprises in sectors such as logistics, eCommerce, finance, and technology. This can be sold globally, provided there's an internet connection.
|
||||
|
||||
Marketing Channels: Online marketing (SEO, Content Marketing, Social Media), Partnerships with tech companies, Direct Sales to Enterprises.
|
||||
|
||||
This strategy is designed to provide multiple revenue streams, while ensuring the Swarms.AI platform is accessible and useful to a range of potential customers.
|
||||
|
||||
1. **AI Solution as a Service:** By offering the Swarms framework as a service, businesses can access and utilize the power of multiple LLM agents without the need to maintain the infrastructure themselves. Subscription can be tiered based on usage and additional features.
|
||||
|
||||
2. **Integration and Custom Development:** Offer integration services to businesses wanting to incorporate the Swarms framework into their existing systems. Also, you could provide custom development for businesses with specific needs not met by the standard framework.
|
||||
|
||||
3. **Training and Certification:** Develop an educational platform offering courses, webinars, and certifications on using the Swarms framework. This can serve both developers seeking to broaden their skills and businesses aiming to train their in-house teams.
|
||||
|
||||
4. **Managed Swarms Solutions:** For businesses that prefer to outsource their AI needs, provide a complete solution which includes the development, maintenance, and continuous improvement of swarms-based applications.
|
||||
|
||||
5. **Data Analytics Services:** Leveraging the aggregated insights from the AI swarms, you could offer data analytics services. Businesses can use these insights to make informed decisions and predictions.
|
||||
|
||||
**Type of Platform:**
|
||||
|
||||
Cloud-based platform or Software as a Service (SaaS) will be a suitable model. It offers accessibility, scalability, and ease of updates.
|
||||
|
||||
**Target Customers:**
|
||||
|
||||
The technology can be beneficial for businesses across sectors like eCommerce, technology, logistics, finance, healthcare, and education, among others.
|
||||
|
||||
**Product Brief Monetization Strategy:**
|
||||
|
||||
Product Name: Swarms.AI
|
||||
|
||||
1. **AI Solution as a Service:** Offer different tiered subscriptions (Standard, Premium, and Enterprise) each with varying levels of usage and features.
|
||||
|
||||
2. **Integration and Custom Development:** Offer custom development and integration services, priced based on the scope and complexity of the project.
|
||||
|
||||
3. **Training and Certification:** Launch the Swarms.AI Academy with courses and certifications, available for a fee.
|
||||
|
||||
4. **Managed Swarms Solutions:** Offer fully managed solutions tailored to business needs, priced based on scope and service level agreements.
|
||||
|
||||
5. **Data Analytics Services:** Provide insightful reports and data analyses, which can be purchased on a one-off basis or through a subscription.
|
||||
|
||||
By offering a variety of services and payment models, Swarms.AI will be able to cater to a diverse range of business needs, from small start-ups to large enterprises. Marketing channels would include digital marketing, partnerships with technology companies, presence in tech events, and direct sales to targeted industries.
|
||||
|
||||
|
||||
|
||||
# Roadmap
|
||||
|
||||
* Create a landing page for swarms apac.ai/product/swarms
|
||||
|
||||
* Create Hosted Swarms API for anybody to just use without need for mega gpu infra, charge usage based pricing. Prerequisites for success => Swarms has to be extremely reliable + we need world class documentation and many daily users => how do we get many daily users? We provide a seamless and fluid experience, how do we create a seamless and fluid experience? We write good code that is modular, provides feedback to the user in times of distress, and ultimately accomplishes the user's tasks.
|
||||
|
||||
* Hosted consumer and enterprise subscription as a service on The Domain, where users can interact with 1000s of APIs and ingest 1000s of different data streams.
|
||||
|
||||
* Hosted dedicated capacity deals with mega enterprises on automating many operations with Swarms for monthly subscription 300,000+$
|
||||
|
||||
* Partnerships with enterprises, massive contracts with performance based fee
|
||||
|
||||
* Have discord bot and or slack bot with users personal data, charge subscription + browser extension
|
||||
|
||||
* each user gets a dedicated ocean instance of all their data so the swarm can query it as needed.
|
||||
|
||||
*
|
||||
@ -1,14 +0,0 @@
|
||||
|
||||
## Purpose
|
||||
Artificial Intelligence has grown at an exponential rate over the past decade. Yet, we are far from fully harnessing its potential. Today's AI operates in isolation, each working separately in their corner. But life doesn't work like that. The world doesn't work like that. Success isn't built in silos; it's built in teams.
|
||||
|
||||
Imagine a world where AI models work in unison. Where they can collaborate, interact, and pool their collective intelligence to achieve more than any single model could. This is the future we envision. But today, we lack a framework for AI to collaborate effectively, to form a true swarm of intelligent agents.
|
||||
|
||||
|
||||
This is a difficult problem, one that has eluded solution. It requires sophisticated systems that can allow individual models to not just communicate but also understand each other, pool knowledge and resources, and create collective intelligence. This is the next frontier of AI.
|
||||
|
||||
But here at Swarms, we have a secret sauce. It's not just a technology or a breakthrough invention. It's a way of thinking - the philosophy of rapid iteration. With each cycle, we make massive progress. We experiment, we learn, and we grow. We have developed a pioneering framework that can enable AI models to work together as a swarm, combining their strengths to create richer, more powerful outputs.
|
||||
|
||||
We are uniquely positioned to take on this challenge with 1,500+ devoted researchers in Agora. We have assembled a team of world-class experts, experienced and driven, united by a shared vision. Our commitment to breaking barriers, pushing boundaries, and our belief in the power of collective intelligence makes us the best team to usher in this future to fundamentally advance our species, Humanity.
|
||||
|
||||
---
|
||||
@ -1,115 +0,0 @@
|
||||
## The Plan
|
||||
|
||||
### Phase 1: Building the Foundation
|
||||
In the first phase, our focus is on building the basic infrastructure of Swarms. This includes developing key components like the Swarms class, integrating essential tools, and establishing task completion and evaluation logic. We'll also start developing our testing and evaluation framework during this phase. If you're interested in foundational work and have a knack for building robust, scalable systems, this phase is for you.
|
||||
|
||||
### Phase 2: Optimizing the System
|
||||
In the second phase, we'll focus on optimizng Swarms by integrating more advanced features, improving the system's efficiency, and refining our testing and evaluation framework. This phase involves more complex tasks, so if you enjoy tackling challenging problems and contributing to the development of innovative features, this is the phase for you.
|
||||
|
||||
### Phase 3: Towards Super-Intelligence
|
||||
The third phase of our bounty program is the most exciting - this is where we aim to achieve super-intelligence. In this phase, we'll be working on improving the swarm's capabilities, expanding its skills, and fine-tuning the system based on real-world testing and feedback. If you're excited about the future of AI and want to contribute to a project that could potentially transform the digital world, this is the phase for you.
|
||||
|
||||
Remember, our roadmap is a guide, and we encourage you to bring your own ideas and creativity to the table. We believe that every contribution, no matter how small, can make a difference. So join us on this exciting journey and help us create the future of Swarms.
|
||||
|
||||
|
||||
## Optimization Priorities
|
||||
|
||||
1. **Reliability**: Increase the reliability of the swarm - obtaining the desired output with a basic and un-detailed input.
|
||||
|
||||
2. **Speed**: Reduce the time it takes for the swarm to accomplish tasks by improving the communication layer, critiquing, and self-alignment with meta prompting.
|
||||
|
||||
3. **Scalability**: Ensure that the system is asynchronous, concurrent, and self-healing to support scalability.
|
||||
|
||||
Our goal is to continuously improve Swarms by following this roadmap, while also being adaptable to new needs and opportunities as they arise.
|
||||
|
||||
# Open Source Roadmap
|
||||
|
||||
Here is the detailed roadmap of our priorities and planned features for the near term:
|
||||
|
||||
## TODO
|
||||
|
||||
* Create a non-langchain worker and swarm class and compare
|
||||
|
||||
* Create extensive documentation
|
||||
|
||||
* Make sure that the boss agent successfully calls the worker agent if when it's finished makinng a plan
|
||||
|
||||
* Make sure the worker agent can access tools like web browser, terminal, and code editor, and multi-modal agents
|
||||
|
||||
* Make sure inputs and outputs from boss to worker are well defined and are collaborating if not then readjust prompt
|
||||
|
||||
* Create a tool that creates other tools with access to write code, debug, and an architectural argent that creates the architecture and then another agent that creates the code[Architecter(with code examples), code generator (with access to writing code and terminalrools)] -- The Compiler?
|
||||
|
||||
* Create a screenshot tool that takes a screen shot and then passes it to a worker multi-modal agent for visual context.
|
||||
|
||||
* API endroute in FASTAPI
|
||||
|
||||
* Develop Conversational UI with Gradio
|
||||
|
||||
* Integrate omni agent as a worker tool
|
||||
|
||||
* Integrate Ocean Database as primary vectorstore
|
||||
|
||||
* Integrate visual agent
|
||||
|
||||
* Integrate quantized hf models as base models with langchain huggingface
|
||||
|
||||
1. **Multi-Agent Debate Integration**: Integrate multi-agent debate frameworks ([Multi Agent debate](https://github.com/Skytliang/Multi-Agents-Debate) and [Multi agent2 debate](https://github.com/composable-models/llm_multiagent_debate)) to improve decision-making.
|
||||
|
||||
2. **Meta Prompting Integration**: Include meta prompting across all worker agents to guide their actions.
|
||||
|
||||
3. **Swarms Class**: Create a main swarms class `swarms('Increase sales by 40$', workers=4)` for managing and coordinating multiple worker nodes.
|
||||
|
||||
4. **Integration of Additional Tools**: Integrate [Jarvis](https://github.com/microsoft/JARVIS) as worker nodes, add text to speech and text to script tools ([whisper x](https://github.com/kyegomez/youtubeURL-to-text)), and integrate Hugging Face agents and other external tools.
|
||||
|
||||
5. **Task Completion and Evaluation Logic**: Include task completion logic with meta prompting, and evaluate task completion on a scale from 0.0 to 1.0.
|
||||
|
||||
7. **Ocean Integration**: Use the [Ocean](https://github.com/kyegomez/Ocean) vector database as the main embedding database for all the agents, both boss and worker.
|
||||
|
||||
8. **Improved Communication**: Develop a universal vector database that is only used when a task is completed in this format `[TASK][COMPLETED]`.
|
||||
|
||||
9. **Testing and Evaluation**: Create unit tests, benchmarks, and evaluations for performance monitoring and continuous improvement.
|
||||
|
||||
10. **Worker Swarm Class**: Create a class for self-scaling worker swarms. If they need help, they can spawn an entirely new worker and more workers if needed.
|
||||
|
||||
## Documentation
|
||||
|
||||
1. **Examples**: Create extensive and useful examples for a variety of use cases.
|
||||
|
||||
2. **README**: Update the README to include the examples and usage instructions.
|
||||
|
||||
|
||||
# Mid-Long term
|
||||
Here are some potential middle-to-long-term improvements to consider for this project:
|
||||
|
||||
1. **Modular Design**: Aim to design a more modular and scalable framework, making it easy for developers to plug-and-play various components.
|
||||
|
||||
2. **Interactive User Interface**: Develop a more interactive, user-friendly GUI that allows users to interact with the system without needing to understand the underlying code.
|
||||
|
||||
3. **Advanced Error Handling**: Implement advanced error handling and debugging capabilities to make it easier for developers to diagnose and fix issues.
|
||||
|
||||
4. **Optimized Resource Utilization**: Improve the efficiency of resource use, aiming to reduce memory consumption and improve speed without sacrificing accuracy.
|
||||
|
||||
5. **Collaborative Learning**: Integrate more sophisticated techniques for collaborative learning among the swarm, allowing them to share knowledge and learn from each other's successes and failures.
|
||||
|
||||
6. **Autonomous Self-Improvement**: Implement mechanisms that allow the swarm to autonomously learn from its past experiences and improve its performance over time.
|
||||
|
||||
7. **Security Enhancements**: Include robust security measures to protect sensitive data and prevent unauthorized access.
|
||||
|
||||
8. **Privacy-Preserving Techniques**: Consider incorporating privacy-preserving techniques such as differential privacy to ensure the confidentiality of user data.
|
||||
|
||||
9. **Support for More Languages**: Expand language support to allow the system to cater to a more global audience.
|
||||
|
||||
10. **Robustness and Resilience**: Improve the system's robustness and resilience, ensuring that it can operate effectively even in the face of hardware or software failures.
|
||||
|
||||
11. **Continual Learning**: Implement continual learning techniques to allow the system to adapt and evolve as new data comes in.
|
||||
|
||||
12. **More Contextual Understanding**: Enhance the system's capability to understand context better, making it more effective in handling real-world, complex tasks.
|
||||
|
||||
13. **Dynamic Task Prioritization**: Develop advanced algorithms for dynamic task prioritization, ensuring that the most important tasks are addressed first.
|
||||
|
||||
14. **Expanding the Swarm's Skills**: Train the swarm on a wider range of tasks, gradually expanding their skill set and problem-solving capabilities.
|
||||
|
||||
15. **Real-World Deployment**: Test and refine the system in real-world settings, learning from these experiences to further improve and adapt the system.
|
||||
|
||||
Remember, these are potential improvements. It's important to revisit your priorities regularly and adjust them based on project needs, feedback, and learning from both successes and failures.
|
||||
@ -1,146 +0,0 @@
|
||||
# Swarm Architecture Design Document
|
||||
|
||||
## Overview
|
||||
|
||||
The goal of the Swarm Architecture is to provide a flexible and scalable system to build swarm intelligence models that can solve complex problems. This document details the proposed design to create a plug-and-play system, which makes it easy to create custom swarms, and provides pre-configured swarms with multi-modal agents.
|
||||
|
||||
## Design Principles
|
||||
|
||||
- **Modularity**: The system will be built in a modular fashion, allowing various components to be easily swapped or upgraded.
|
||||
- **Interoperability**: Different swarm classes and components should be able to work together seamlessly.
|
||||
- **Scalability**: The design should support the growth of the system by adding more components or swarms.
|
||||
- **Ease of Use**: Users should be able to easily create their own swarms or use pre-configured ones with minimal configuration.
|
||||
|
||||
## Design Components
|
||||
|
||||
### AbstractSwarm
|
||||
|
||||
The AbstractSwarm is an abstract base class which defines the basic structure of a swarm and the methods that need to be implemented. Any new swarm should inherit from this class and implement the required methods.
|
||||
|
||||
### Swarm Classes
|
||||
|
||||
Various Swarm classes can be implemented inheriting from the AbstractSwarm class. Each swarm class should implement the required methods for initializing the components, worker nodes, and boss node, and running the swarm.
|
||||
|
||||
Pre-configured swarm classes with multi-modal agents can be provided for ease of use. These classes come with a default configuration of tools and agents, which can be used out of the box.
|
||||
|
||||
### Tools and Agents
|
||||
|
||||
Tools and agents are the components that provide the actual functionality to the swarms. They can be language models, AI assistants, vector stores, or any other components that can help in problem solving.
|
||||
|
||||
To make the system plug-and-play, a standard interface should be defined for these components. Any new tool or agent should implement this interface, so that it can be easily plugged into the system.
|
||||
|
||||
## Usage
|
||||
|
||||
Users can either use pre-configured swarms or create their own custom swarms.
|
||||
|
||||
To use a pre-configured swarm, they can simply instantiate the corresponding swarm class and call the run method with the required objective.
|
||||
|
||||
To create a custom swarm, they need to:
|
||||
|
||||
1. Define a new swarm class inheriting from AbstractSwarm.
|
||||
2. Implement the required methods for the new swarm class.
|
||||
3. Instantiate the swarm class and call the run method.
|
||||
|
||||
### Example
|
||||
|
||||
```python
|
||||
# Using pre-configured swarm
|
||||
swarm = PreConfiguredSwarm(openai_api_key)
|
||||
swarm.run_swarms(objective)
|
||||
|
||||
# Creating custom swarm
|
||||
class CustomSwarm(AbstractSwarm):
|
||||
# Implement required methods
|
||||
|
||||
swarm = CustomSwarm(openai_api_key)
|
||||
swarm.run_swarms(objective)
|
||||
```
|
||||
|
||||
## Conclusion
|
||||
|
||||
This Swarm Architecture design provides a scalable and flexible system for building swarm intelligence models. The plug-and-play design allows users to easily use pre-configured swarms or create their own custom swarms.
|
||||
|
||||
|
||||
# Swarming Architectures
|
||||
Sure, below are five different swarm architectures with their base requirements and an abstract class that processes these components:
|
||||
|
||||
1. **Hierarchical Swarm**: This architecture is characterized by a boss/worker relationship. The boss node takes high-level decisions and delegates tasks to the worker nodes. The worker nodes perform tasks and report back to the boss node.
|
||||
- Requirements: Boss node (can be a large language model), worker nodes (can be smaller language models), and a task queue for task management.
|
||||
|
||||
2. **Homogeneous Swarm**: In this architecture, all nodes in the swarm are identical and contribute equally to problem-solving. Each node has the same capabilities.
|
||||
- Requirements: Homogeneous nodes (can be language models of the same size), communication protocol for nodes to share information.
|
||||
|
||||
3. **Heterogeneous Swarm**: This architecture contains different types of nodes, each with its specific capabilities. This diversity can lead to more robust problem-solving.
|
||||
- Requirements: Different types of nodes (can be different types and sizes of language models), a communication protocol, and a mechanism to delegate tasks based on node capabilities.
|
||||
|
||||
4. **Competitive Swarm**: In this architecture, nodes compete with each other to find the best solution. The system may use a selection process to choose the best solutions.
|
||||
- Requirements: Nodes (can be language models), a scoring mechanism to evaluate node performance, a selection mechanism.
|
||||
|
||||
5. **Cooperative Swarm**: In this architecture, nodes work together and share information to find solutions. The focus is on cooperation rather than competition.
|
||||
- Requirements: Nodes (can be language models), a communication protocol, a consensus mechanism to agree on solutions.
|
||||
|
||||
|
||||
6. **Grid-based Swarm**: This architecture positions agents on a grid, where they can only interact with their neighbors. This is useful for simulations, especially in fields like ecology or epidemiology.
|
||||
- Requirements: Agents (can be language models), a grid structure, and a neighborhood definition (i.e., how to identify neighboring agents).
|
||||
|
||||
7. **Particle Swarm Optimization (PSO) Swarm**: In this architecture, each agent represents a potential solution to an optimization problem. Agents move in the solution space based on their own and their neighbors' past performance. PSO is especially useful for continuous numerical optimization problems.
|
||||
- Requirements: Agents (each representing a solution), a definition of the solution space, an evaluation function to rate the solutions, a mechanism to adjust agent positions based on performance.
|
||||
|
||||
8. **Ant Colony Optimization (ACO) Swarm**: Inspired by ant behavior, this architecture has agents leave a pheromone trail that other agents follow, reinforcing the best paths. It's useful for problems like the traveling salesperson problem.
|
||||
- Requirements: Agents (can be language models), a representation of the problem space, a pheromone updating mechanism.
|
||||
|
||||
9. **Genetic Algorithm (GA) Swarm**: In this architecture, agents represent potential solutions to a problem. They can 'breed' to create new solutions and can undergo 'mutations'. GA swarms are good for search and optimization problems.
|
||||
- Requirements: Agents (each representing a potential solution), a fitness function to evaluate solutions, a crossover mechanism to breed solutions, and a mutation mechanism.
|
||||
|
||||
10. **Stigmergy-based Swarm**: In this architecture, agents communicate indirectly by modifying the environment, and other agents react to such modifications. It's a decentralized method of coordinating tasks.
|
||||
- Requirements: Agents (can be language models), an environment that agents can modify, a mechanism for agents to perceive environment changes.
|
||||
|
||||
These architectures all have unique features and requirements, but they share the need for agents (often implemented as language models) and a mechanism for agents to communicate or interact, whether it's directly through messages, indirectly through the environment, or implicitly through a shared solution space. Some also require specific data structures, like a grid or problem space, and specific algorithms, like for evaluating solutions or updating agent positions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Here is an abstract class that provides the basic structure to process these components:
|
||||
|
||||
```python
|
||||
from abc import ABC, abstractmethod
|
||||
|
||||
class AbstractSwarm(ABC):
|
||||
|
||||
def __init__(self, agents, vectorstore, tools):
|
||||
self.agents = agents
|
||||
self.vectorstore = vectorstore
|
||||
self.tools = tools
|
||||
|
||||
@abstractmethod
|
||||
def initialize(self):
|
||||
pass
|
||||
|
||||
@abstractmethod
|
||||
def communicate(self):
|
||||
pass
|
||||
|
||||
@abstractmethod
|
||||
def process(self):
|
||||
pass
|
||||
|
||||
@abstractmethod
|
||||
def solve(self):
|
||||
pass
|
||||
```
|
||||
|
||||
This abstract class requires four methods to be implemented:
|
||||
|
||||
- `initialize`: This method is used to set up the initial state of the swarm, including setting up nodes and tools.
|
||||
- `communicate`: This method is responsible for facilitating communication between nodes.
|
||||
- `process`: This method handles the processing logic, which can be different based on the swarm architecture.
|
||||
- `solve`: This method is called to start the problem-solving process.
|
||||
|
||||
This abstract class can be inherited by specific swarm architecture classes to implement their specific behavior.
|
||||
|
||||
# 3 Ingredients
|
||||
|
||||
* The Individual Agent Configuration with a vectorstore and tools
|
||||
|
||||
* The Orchestrator, => task assignment, task completion handling, communication layer
|
||||
@ -1,53 +0,0 @@
|
||||
# Design Philosophy Document for Swarms
|
||||
|
||||
## Usable
|
||||
|
||||
### Objective
|
||||
|
||||
Our goal is to ensure that Swarms is intuitive and easy to use for all users, regardless of their level of technical expertise. This includes the developers who implement Swarms in their applications, as well as end users who interact with the implemented systems.
|
||||
|
||||
### Tactics
|
||||
|
||||
- Clear and Comprehensive Documentation: We will provide well-written and easily accessible documentation that guides users through using and understanding Swarms.
|
||||
- User-Friendly APIs: We'll design clean and self-explanatory APIs that help developers to understand their purpose quickly.
|
||||
- Prompt and Effective Support: We will ensure that support is readily available to assist users when they encounter problems or need help with Swarms.
|
||||
|
||||
## Reliable
|
||||
|
||||
### Objective
|
||||
|
||||
Swarms should be dependable and trustworthy. Users should be able to count on Swarms to perform consistently and without error or failure.
|
||||
|
||||
### Tactics
|
||||
|
||||
- Robust Error Handling: We will focus on error prevention, detection, and recovery to minimize failures in Swarms.
|
||||
- Comprehensive Testing: We will apply various testing methodologies such as unit testing, integration testing, and stress testing to validate the reliability of our software.
|
||||
- Continuous Integration/Continuous Delivery (CI/CD): We will use CI/CD pipelines to ensure that all changes are tested and validated before they're merged into the main branch.
|
||||
|
||||
## Fast
|
||||
|
||||
### Objective
|
||||
|
||||
Swarms should offer high performance and rapid response times. The system should be able to handle requests and tasks swiftly.
|
||||
|
||||
### Tactics
|
||||
|
||||
- Efficient Algorithms: We will focus on optimizing our algorithms and data structures to ensure they run as quickly as possible.
|
||||
- Caching: Where appropriate, we will use caching techniques to speed up response times.
|
||||
- Profiling and Performance Monitoring: We will regularly analyze the performance of Swarms to identify bottlenecks and opportunities for improvement.
|
||||
|
||||
## Scalable
|
||||
|
||||
### Objective
|
||||
|
||||
Swarms should be able to grow in capacity and complexity without compromising performance or reliability. It should be able to handle increased workloads gracefully.
|
||||
|
||||
### Tactics
|
||||
|
||||
- Modular Architecture: We will design Swarms using a modular architecture that allows for easy scaling and modification.
|
||||
- Load Balancing: We will distribute tasks evenly across available resources to prevent overload and maximize throughput.
|
||||
- Horizontal and Vertical Scaling: We will design Swarms to be capable of both horizontal (adding more machines) and vertical (adding more power to an existing machine) scaling.
|
||||
|
||||
### Philosophy
|
||||
|
||||
Swarms is designed with a philosophy of simplicity and reliability. We believe that software should be a tool that empowers users, not a hurdle that they need to overcome. Therefore, our focus is on usability, reliability, speed, and scalability. We want our users to find Swarms intuitive and dependable, fast and adaptable to their needs. This philosophy guides all of our design and development decisions.
|
||||
@ -1,19 +0,0 @@
|
||||
from swarms import Model, Agent, vectorstore, tools, orchestrator
|
||||
|
||||
# 1 model
|
||||
Model(openai)
|
||||
|
||||
# 2 agent level
|
||||
Agent(model, vectorstore, tools)
|
||||
|
||||
# 3 worker infrastructure level
|
||||
worker_node(Agent, human_input, tools)
|
||||
|
||||
# 4 swarm level basically handling infrastructure for multiple worker node
|
||||
swarm = orchestrator(worker_node, 100) # nodes
|
||||
|
||||
# 5
|
||||
hivemind = Hivemind(swarm * 100)
|
||||
|
||||
|
||||
# a market different pre built worker or boss agent that have access to different tools and memory, proompts
|
||||
@ -1,22 +0,0 @@
|
||||
Sure, here are some creative neo-futuristic names for your swarm worker agents:
|
||||
|
||||
QuantumPulse
|
||||
UltraNode
|
||||
FusionCortex
|
||||
HyperionCrawler
|
||||
XenoSync
|
||||
HoloWorker
|
||||
EtherEngine
|
||||
NebulaNexus
|
||||
OmegaOrbit
|
||||
ZetaZenith
|
||||
PhantomPivot
|
||||
VortexVector
|
||||
ChronoCluster
|
||||
SpecterSphere
|
||||
TitanTrace
|
||||
EchoEntity
|
||||
NovaNucleus
|
||||
AstroAssembler
|
||||
PulsarProcessor
|
||||
CosmicCrafter
|
||||
@ -1,69 +0,0 @@
|
||||
Guide to Product-Market Fit for HiveMind Class
|
||||
Risks and Mitigations
|
||||
Scalability: As the number of swarms increases, the computational resources required will also increase. This could lead to performance issues or high costs.
|
||||
|
||||
Mitigation: Implement efficient resource management and load balancing. Consider using cloud-based solutions that can scale up or down based on demand.
|
||||
|
||||
Concurrency Issues: With multiple swarms running concurrently, there could be issues with data consistency and synchronization.
|
||||
|
||||
Mitigation: Implement robust concurrency control mechanisms. Ensure that the shared vector store is thread-safe.
|
||||
|
||||
Error Propagation: Errors in one swarm could potentially affect other swarms or the entire HiveMind.
|
||||
|
||||
Mitigation: Implement robust error handling and isolation mechanisms. Errors in one swarm should not affect the operation of other swarms.
|
||||
|
||||
Complexity: The HiveMind class is complex and could be difficult to maintain and extend.
|
||||
|
||||
Mitigation: Follow best practices for software design, such as modularity, encapsulation, and separation of concerns. Write comprehensive tests to catch issues early.
|
||||
|
||||
User Experience: If the HiveMind class is not easy to use, it could deter potential users.
|
||||
|
||||
Mitigation: Provide clear documentation and examples. Implement a user-friendly API. Consider providing a high-level interface that abstracts away some of the complexity.
|
||||
|
||||
Mental Models and Design Paradigms
|
||||
Modularity: Each swarm should be a self-contained unit that can operate independently. This makes the system more flexible and easier to maintain.
|
||||
|
||||
Concurrency: The system should be designed to handle multiple swarms running concurrently. This requires careful consideration of issues such as data consistency and synchronization.
|
||||
|
||||
Fault Tolerance: The system should be able to handle errors gracefully. If one swarm encounters an error, it should not affect the operation of other swarms.
|
||||
|
||||
Scalability: The system should be able to handle an increasing number of swarms without a significant degradation in performance.
|
||||
|
||||
User-Centric Design: The system should be designed with the user in mind. It should be easy to use and provide value to the user.
|
||||
|
||||
Path to Product-Market Fit
|
||||
Identify Target Users: Determine who would benefit most from using the HiveMind class. This could be developers, data scientists, researchers, or businesses.
|
||||
|
||||
Understand User Needs: Conduct user research to understand the problems that users are trying to solve and how the HiveMind class can help.
|
||||
|
||||
Develop MVP: Develop a minimum viable product (MVP) that demonstrates the value of the HiveMind class. This should be a simple version of the product that solves a core user problem.
|
||||
|
||||
Gather Feedback: After releasing the MVP, gather feedback from users. This could be through surveys, interviews, or user testing.
|
||||
|
||||
Iterate and Improve: Use the feedback to iterate and improve the product. This could involve fixing bugs, adding new features, or improving usability.
|
||||
|
||||
Scale: Once the product has achieved product-market fit, focus on scaling. This could involve optimizing the product for performance, expanding to new markets, or developing partnerships.
|
||||
|
||||
|
||||
|
||||
Here are some features that could be added to the HiveMind class to provide maximum value for users:
|
||||
|
||||
Dynamic Scaling: The ability to automatically scale the number of swarms based on the complexity of the task or the load on the system. This would allow the system to handle a wide range of tasks efficiently.
|
||||
|
||||
Task Prioritization: The ability to prioritize tasks based on their importance or urgency. This would allow more important tasks to be completed first.
|
||||
|
||||
Progress Monitoring: The ability for users to monitor the progress of their tasks. This could include a progress bar, estimated completion time, or real-time updates.
|
||||
|
||||
Error Reporting: Detailed error reports that help users understand what went wrong if a task fails. This could include the error message, the swarm that encountered the error, and suggestions for how to fix the error.
|
||||
|
||||
Task Cancellation: The ability for users to cancel a task that is currently being processed. This could be useful if a user realizes they made a mistake or if a task is taking too long to complete.
|
||||
|
||||
Task Queuing: The ability for users to queue up multiple tasks. This would allow users to submit a batch of tasks and have them processed one after the other.
|
||||
|
||||
Result Formatting: The ability for users to specify how they want the results to be formatted. This could include options for plain text, JSON, XML, or other formats.
|
||||
|
||||
Integration with Other Services: The ability to integrate with other services, such as databases, cloud storage, or machine learning platforms. This would allow users to easily store results, access additional resources, or leverage advanced features.
|
||||
|
||||
Security Features: Features to ensure the security and privacy of user data, such as encryption, access controls, and audit logs.
|
||||
|
||||
User-Friendly API: A well-designed, user-friendly API that makes it easy for users to use the HiveMind class in their own applications. This could include clear documentation, examples, and error messages.
|
||||
@ -1,401 +0,0 @@
|
||||
## Swarming Architectures
|
||||
|
||||
Here are three examples of swarming architectures that could be applied in this context.
|
||||
|
||||
1. **Hierarchical Swarms**: In this architecture, a 'lead' agent coordinates the efforts of other agents, distributing tasks based on each agent's unique strengths. The lead agent might be equipped with additional functionality or decision-making capabilities to effectively manage the swarm.
|
||||
|
||||
2. **Collaborative Swarms**: Here, each agent in the swarm works in parallel, potentially on different aspects of a task. They then collectively determine the best output, often through a voting or consensus mechanism.
|
||||
|
||||
3. **Competitive Swarms**: In this setup, multiple agents work on the same task independently. The output from the agent which produces the highest confidence or quality result is then selected. This can often lead to more robust outputs, as the competition drives each agent to perform at its best.
|
||||
|
||||
4. **Multi-Agent Debate**: Here, multiple agents debate a topic. The output from the agent which produces the highest confidence or quality result is then selected. This can lead to more robust outputs, as the competition drives each agent to perform it's best.
|
||||
|
||||
|
||||
# Ideas
|
||||
|
||||
A swarm, particularly in the context of distributed computing, refers to a large number of coordinated agents or nodes that work together to solve a problem. The specific requirements of a swarm might vary depending on the task at hand, but some of the general requirements include:
|
||||
|
||||
1. **Distributed Nature**: The swarm should consist of multiple individual units or nodes, each capable of functioning independently.
|
||||
|
||||
2. **Coordination**: The nodes in the swarm need to coordinate with each other to ensure they're working together effectively. This might involve communication between nodes, or it could be achieved through a central orchestrator.
|
||||
|
||||
3. **Scalability**: A well-designed swarm system should be able to scale up or down as needed, adding or removing nodes based on the task load.
|
||||
|
||||
4. **Resilience**: If a node in the swarm fails, it shouldn't bring down the entire system. Instead, other nodes should be able to pick up the slack.
|
||||
|
||||
5. **Load Balancing**: Tasks should be distributed evenly across the nodes in the swarm to avoid overloading any single node.
|
||||
|
||||
6. **Interoperability**: Each node should be able to interact with others, regardless of differences in underlying hardware or software.
|
||||
|
||||
Integrating these requirements with Large Language Models (LLMs) can be done as follows:
|
||||
|
||||
1. **Distributed Nature**: Each LLM agent can be considered as a node in the swarm. These agents can be distributed across multiple servers or even geographically dispersed data centers.
|
||||
|
||||
2. **Coordination**: An orchestrator can manage the LLM agents, assigning tasks, coordinating responses, and ensuring effective collaboration between agents.
|
||||
|
||||
3. **Scalability**: As the demand for processing power increases or decreases, the number of LLM agents can be adjusted accordingly.
|
||||
|
||||
4. **Resilience**: If an LLM agent goes offline or fails, the orchestrator can assign its tasks to other agents, ensuring the swarm continues functioning smoothly.
|
||||
|
||||
5. **Load Balancing**: The orchestrator can also handle load balancing, ensuring tasks are evenly distributed amongst the LLM agents.
|
||||
|
||||
6. **Interoperability**: By standardizing the input and output formats of the LLM agents, they can effectively communicate and collaborate, regardless of the specific model or configuration of each agent.
|
||||
|
||||
In terms of architecture, the swarm might look something like this:
|
||||
|
||||
```
|
||||
(Orchestrator)
|
||||
/ \
|
||||
Tools + Vector DB -- (LLM Agent)---(Communication Layer) (Communication Layer)---(LLM Agent)-- Tools + Vector DB
|
||||
/ | | \
|
||||
(Task Assignment) (Task Completion) (Task Assignment) (Task Completion)
|
||||
```
|
||||
|
||||
Each LLM agent communicates with the orchestrator through a dedicated communication layer. The orchestrator assigns tasks to each LLM agent, which the agents then complete and return. This setup allows for a high degree of flexibility, scalability, and robustness.
|
||||
|
||||
|
||||
## Communication Layer
|
||||
|
||||
Communication layers play a critical role in distributed systems, enabling interaction between different nodes (agents) and the orchestrator. Here are three potential communication layers for a distributed system, including their strengths and weaknesses:
|
||||
|
||||
1. **Message Queuing Systems (like RabbitMQ, Kafka)**:
|
||||
|
||||
- Strengths: They are highly scalable, reliable, and designed for high-throughput systems. They also ensure delivery of messages and can persist them if necessary. Furthermore, they support various messaging patterns like publish/subscribe, which can be highly beneficial in a distributed system. They also have robust community support.
|
||||
|
||||
- Weaknesses: They can add complexity to the system, including maintenance of the message broker. Moreover, they require careful configuration to perform optimally, and handling failures can sometimes be challenging.
|
||||
|
||||
2. **RESTful APIs**:
|
||||
|
||||
- Strengths: REST is widely adopted, and most programming languages have libraries to easily create RESTful APIs. They leverage standard HTTP(S) protocols and methods and are straightforward to use. Also, they can be stateless, meaning each request contains all the necessary information, enabling scalability.
|
||||
|
||||
- Weaknesses: For real-time applications, REST may not be the best fit due to its synchronous nature. Additionally, handling a large number of API requests can put a strain on the system, causing slowdowns or timeouts.
|
||||
|
||||
3. **gRPC (Google Remote Procedure Call)**:
|
||||
|
||||
- Strengths: gRPC uses Protocol Buffers as its interface definition language, leading to smaller payloads and faster serialization/deserialization compared to JSON (commonly used in RESTful APIs). It supports bidirectional streaming and can use HTTP/2 features, making it excellent for real-time applications.
|
||||
|
||||
- Weaknesses: gRPC is more complex to set up compared to REST. Protocol Buffers' binary format can be more challenging to debug than JSON. It's also not as widely adopted as REST, so tooling and support might be limited in some environments.
|
||||
|
||||
In the context of swarm LLMs, one could consider an **Omni-Vector Embedding Database** for communication. This database could store and manage the high-dimensional vectors produced by each LLM agent.
|
||||
|
||||
- Strengths: This approach would allow for similarity-based lookup and matching of LLM-generated vectors, which can be particularly useful for tasks that involve finding similar outputs or recognizing patterns.
|
||||
|
||||
- Weaknesses: An Omni-Vector Embedding Database might add complexity to the system in terms of setup and maintenance. It might also require significant computational resources, depending on the volume of data being handled and the complexity of the vectors. The handling and transmission of high-dimensional vectors could also pose challenges in terms of network load.
|
||||
|
||||
|
||||
|
||||
|
||||
# Technical Analysis Document: Particle Swarm of AI Agents using Ocean Database
|
||||
|
||||
## Overview
|
||||
|
||||
The goal is to create a particle swarm of AI agents using the OpenAI API for the agents and the Ocean database as the communication space, where the embeddings act as particles. The swarm will work collectively to perform tasks and optimize their behavior based on the interaction with the Ocean database.
|
||||
|
||||
## Algorithmic Overview
|
||||
|
||||
1. Initialize the AI agents and the Ocean database.
|
||||
2. Assign tasks to the AI agents.
|
||||
3. AI agents use the OpenAI API to perform tasks and generate embeddings.
|
||||
4. AI agents store their embeddings in the Ocean database.
|
||||
5. AI agents query the Ocean database for relevant embeddings.
|
||||
6. AI agents update their positions based on the retrieved embeddings.
|
||||
7. Evaluate the performance of the swarm and update the agents' behavior accordingly.
|
||||
8. Repeat steps 3-7 until a stopping criterion is met.
|
||||
|
||||
## Python Implementation Logic
|
||||
|
||||
1. **Initialize the AI agents and the Ocean database.**
|
||||
|
||||
```python
|
||||
import openai
|
||||
import oceandb
|
||||
from oceandb.utils.embedding_functions import ImageBindEmbeddingFunction
|
||||
|
||||
# Initialize Ocean database
|
||||
client = oceandb.Client()
|
||||
text_embedding_function = ImageBindEmbeddingFunction(modality="text")
|
||||
collection = client.create_collection("all-my-documents", embedding_function=text_embedding_function)
|
||||
|
||||
# Initialize AI agents
|
||||
agents = initialize_agents(...)
|
||||
```
|
||||
|
||||
2. **Assign tasks to the AI agents.**
|
||||
|
||||
```python
|
||||
tasks = assign_tasks_to_agents(agents, ...)
|
||||
```
|
||||
|
||||
3. **AI agents use the OpenAI API to perform tasks and generate embeddings.**
|
||||
|
||||
```python
|
||||
def agent_perform_task(agent, task):
|
||||
# Perform the task using the OpenAI API
|
||||
result = perform_task_with_openai_api(agent, task)
|
||||
# Generate the embedding
|
||||
embedding = generate_embedding(result)
|
||||
return embedding
|
||||
|
||||
embeddings = [agent_perform_task(agent, task) for agent, task in zip(agents, tasks)]
|
||||
```
|
||||
|
||||
4. **AI agents store their embeddings in the Ocean database.**
|
||||
|
||||
```python
|
||||
def store_embeddings_in_database(embeddings, collection):
|
||||
for i, embedding in enumerate(embeddings):
|
||||
document_id = f"agent_{i}"
|
||||
collection.add(documents=[embedding], ids=[document_id])
|
||||
|
||||
store_embeddings_in_database(embeddings, collection)
|
||||
```
|
||||
|
||||
5. **AI agents query the Ocean database for relevant embeddings.**
|
||||
|
||||
```python
|
||||
def query_database_for_embeddings(agent, collection, n_results=1):
|
||||
query_result = collection.query(query_texts=[agent], n_results=n_results)
|
||||
return query_result
|
||||
|
||||
queried_embeddings = [query_database_for_embeddings(agent, collection) for agent in agents]
|
||||
```
|
||||
|
||||
6. **AI agents update their positions based on the retrieved embeddings.**
|
||||
|
||||
```python
|
||||
def update_agent_positions(agents, queried_embeddings):
|
||||
for agent, embedding in zip(agents, queried_embeddings):
|
||||
agent.update_position(embedding)
|
||||
|
||||
update_agent_positions(agents, queried_embeddings)
|
||||
```
|
||||
|
||||
7. **Evaluate the performance of the swarm and update the agents' behavior accordingly.**
|
||||
|
||||
```python
|
||||
def evaluate_swarm_performance(agents, ...):
|
||||
# Evaluate the performance of the swarm
|
||||
performance = compute_performance_metric(agents, ...)
|
||||
return performance
|
||||
|
||||
def update_agent_behavior(agents, performance):
|
||||
# Update agents' behavior based on swarm performance
|
||||
for agent in agents:
|
||||
agent.adjust_behavior(performance)
|
||||
|
||||
performance = evaluate_swarm_performance(agents, ...)
|
||||
update_agent_behavior(agents, performance)
|
||||
```
|
||||
|
||||
8. **Repeat steps 3-7 until a stopping criterion is met.**
|
||||
|
||||
```python
|
||||
while not stopping_criterion_met():
|
||||
# Perform tasks and generate embeddings
|
||||
embeddings = [agent_perform_task(agent, task) for agent, task in zip(agents, tasks)]
|
||||
|
||||
# Store embeddings in the Ocean database
|
||||
store_embeddings_in_database(embeddings, collection)
|
||||
|
||||
# Query the Ocean database for relevant embeddings
|
||||
queried_embeddings = [query_database_for_embeddings(agent, collection) for agent in agents]
|
||||
|
||||
# Update AI agent positions based on the retrieved embeddings
|
||||
update_agent_positions(agents, queried_embeddings)
|
||||
|
||||
# Evaluate the performance of the swarm and update the agents' behavior accordingly
|
||||
performance = evaluate_swarm_performance(agents, ...)
|
||||
update_agent_behavior(agents, performance)
|
||||
```
|
||||
|
||||
This code demonstrates the complete loop to repeat steps 3-7 until a stopping criterion is met. You will need to define the `stopping_criterion_met()` function, which could be based on a predefined number of iterations, a target performance level, or any other condition that indicates that the swarm has reached a desired state.
|
||||
|
||||
|
||||
|
||||
|
||||
* Integrate petals to handle huggingface LLM
|
||||
|
||||
|
||||
|
||||
# Orchestrator
|
||||
* Takes in an agent class with vector store, then handles all the communication and scales up a swarm with number of agents and handles task assignment and task completion
|
||||
|
||||
```python
|
||||
|
||||
from swarms import OpenAI, Orchestrator, Swarm
|
||||
|
||||
orchestrated = Orchestrate(OpenAI, nodes=40) #handles all the task assignment and allocation and agent communication using a vectorstore as a universal communication layer and also handlles the task completion logic
|
||||
|
||||
Objective = "Make a business website for a marketing consultancy"
|
||||
|
||||
Swarms = (Swarms(orchestrated, auto=True, Objective))
|
||||
```
|
||||
|
||||
In terms of architecture, the swarm might look something like this:
|
||||
|
||||
```
|
||||
(Orchestrator)
|
||||
/ \
|
||||
Tools + Vector DB -- (LLM Agent)---(Communication Layer) (Communication Layer)---(LLM Agent)-- Tools + Vector DB
|
||||
/ | | \
|
||||
(Task Assignment) (Task Completion) (Task Assignment) (Task Completion)
|
||||
```
|
||||
|
||||
Each LLM agent communicates with the orchestrator through a dedicated communication layer. The orchestrator assigns tasks to each LLM agent, which the agents then complete and return. This setup allows for a high degree of flexibility, scalability, and robustness.
|
||||
|
||||
In the context of swarm LLMs, one could consider an **Omni-Vector Embedding Database** for communication. This database could store and manage the high-dimensional vectors produced by each LLM agent.
|
||||
|
||||
- Strengths: This approach would allow for similarity-based lookup and matching of LLM-generated vectors, which can be particularly useful for tasks that involve finding similar outputs or recognizing patterns.
|
||||
|
||||
- Weaknesses: An Omni-Vector Embedding Database might add complexity to the system in terms of setup and maintenance. It might also require significant computational resources, depending on the volume of data being handled and the complexity of the vectors. The handling and transmission of high-dimensional vectors could also pose challenges in terms of network load.
|
||||
|
||||
|
||||
|
||||
* Handling absurdly long sequences => first transform the objective if it's more than 1000tokens into a txt file similiar to how Claude works => then chunk it into sizes of 8000 seq length embeddings => then embed it and store in the vector database => then connext the agent model to it
|
||||
|
||||
|
||||
Given the complexity of the topic, please note that these simplified markdown documents are quite abstract and high level. They can be used as a starting point for further detailed design and implementation:
|
||||
|
||||
### Document 1: Hierarchical Swarms
|
||||
|
||||
#### Overall Architecture
|
||||
|
||||
1. Leader Agent (LA): This agent has the authority to manage and distribute tasks to the Worker Agents (WA).
|
||||
2. Worker Agents (WAs): These agents perform the tasks assigned by the LA.
|
||||
|
||||
#### Simplified Requirements
|
||||
|
||||
1. LA should be able to distribute tasks to WAs.
|
||||
2. WAs should be able to execute tasks and return results to LA.
|
||||
3. LA should be able to consolidate and process results.
|
||||
|
||||
#### Pseudocode
|
||||
|
||||
```
|
||||
create LA
|
||||
create WAs
|
||||
|
||||
for each task in tasks:
|
||||
LA.distribute_task(WAs, task)
|
||||
|
||||
for each WA in WAs:
|
||||
WA.execute_task()
|
||||
|
||||
LA.collect_results(WAs)
|
||||
|
||||
LA.process_results()
|
||||
```
|
||||
|
||||
#### General Classes
|
||||
|
||||
```python
|
||||
class LeaderAgent:
|
||||
def distribute_task(self, WAs, task):
|
||||
pass
|
||||
|
||||
def collect_results(self, WAs):
|
||||
pass
|
||||
|
||||
def process_results(self):
|
||||
pass
|
||||
|
||||
class WorkerAgent:
|
||||
def execute_task(self):
|
||||
pass
|
||||
```
|
||||
|
||||
### Document 2: Collaborative Swarms
|
||||
|
||||
#### Overall Architecture
|
||||
|
||||
1. Collaborative Agents (CAs): These agents work in parallel on different aspects of a task and then collectively determine the best output.
|
||||
|
||||
#### Simplified Requirements
|
||||
|
||||
1. CAs should be able to work on tasks in parallel.
|
||||
2. CAs should be able to collaborate to determine the best result.
|
||||
|
||||
#### Pseudocode
|
||||
|
||||
```
|
||||
create CAs
|
||||
|
||||
for each task in tasks:
|
||||
for each CA in CAs:
|
||||
CA.execute_task(task)
|
||||
|
||||
CA.collaborate()
|
||||
```
|
||||
|
||||
#### General Classes
|
||||
|
||||
```python
|
||||
class CollaborativeAgent:
|
||||
def execute_task(self, task):
|
||||
pass
|
||||
|
||||
def collaborate(self):
|
||||
pass
|
||||
```
|
||||
|
||||
### Document 3: Competitive Swarms
|
||||
|
||||
#### Overall Architecture
|
||||
|
||||
1. Competitive Agents (CompAs): These agents work independently on the same tasks, and the best result is selected.
|
||||
|
||||
#### Simplified Requirements
|
||||
|
||||
1. CompAs should be able to work independently on tasks.
|
||||
2. An evaluation method should be used to select the best result.
|
||||
|
||||
#### Pseudocode
|
||||
|
||||
```
|
||||
create CompAs
|
||||
|
||||
for each task in tasks:
|
||||
for each CompA in CompAs:
|
||||
CompA.execute_task(task)
|
||||
|
||||
evaluate_results(CompAs)
|
||||
```
|
||||
|
||||
#### General Classes
|
||||
|
||||
```python
|
||||
class CompetitiveAgent:
|
||||
def execute_task(self, task):
|
||||
pass
|
||||
|
||||
def evaluate_results(CompAs):
|
||||
pass
|
||||
```
|
||||
|
||||
Note: In the real world, the complexity of the architecture and requirements will significantly exceed what is presented here. These examples provide a basic starting point but should be expanded upon based on the specifics of the task or problem you're trying to solve.
|
||||
|
||||
|
||||
|
||||
# Swarms
|
||||
|
||||
BabyAGI -> Autogpt's -> tools -> other agents
|
||||
|
||||
- Host it on server, on premise, private learning, no learning is translating out
|
||||
- companies are sensitive with data, models are firewalled, need privacy, huggingface,
|
||||
- Does not transmit information,
|
||||
- see agent activity, task history,
|
||||
- optimize which agents for each task
|
||||
- Assist or provide feedback to management agent
|
||||
- overview see the whole swarm, modify each agent, visualize the communication stream with blue,
|
||||
- Work optimization routines
|
||||
- output monitoring
|
||||
- stop output, agent looping,
|
||||
-quality assurance checker, adversarial agent
|
||||
- see a holistic diagram of all agents, how are they being utilized, see number of iterations, query responses, balance loading,
|
||||
- summary of tasks completed with critique, type of summary, ceo summary, manager summary
|
||||
- outside of browser and accross whole operating system, switch apps, mac, linux, and windows
|
||||
-what are the skillsets behind the dev team, can be modified by experts, ui agent, manager agent, personalize agents with prompt and tools, and orca like explain your solutions, critique them then return the final output
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,11 +0,0 @@
|
||||
* The Platform, where users can have a conversation with the domain
|
||||
|
||||
* An developer platform where people can build swarms through a UI in nodes, connect and play
|
||||
|
||||
* SIMS like UI, where you see every node accomplishing their tasks around the internet
|
||||
|
||||
* Swarms Discord BOT
|
||||
|
||||
* PAID API
|
||||
|
||||
* MARKETPLACE FOR PREBUILT SWARMS WITH SPECIFIC PROMPTS, MODELS, TOOLS, AND MEMORIES,
|
||||
@ -1,42 +0,0 @@
|
||||
Research Proposal: Creating a Swarm of LLM Agents for Operating Systems
|
||||
Introduction
|
||||
The goal of this research is to explore the feasibility and requirements of creating a swarm of Language Learning Model (LLM) agents that can autonomously operate the kernel of an operating system. This swarm of AI agents would be capable of performing tasks such as process scheduling, memory management, device management, and system calls, among others.
|
||||
|
||||
Objectives
|
||||
To investigate the feasibility of using LLM agents to autonomously operate the kernel of an operating system.
|
||||
To identify the requirements and challenges of implementing such a system.
|
||||
To develop a prototype system as a proof of concept.
|
||||
Methodology
|
||||
Literature Review: Conduct a comprehensive review of existing research on AI in operating systems, swarm intelligence, and LLMs.
|
||||
|
||||
Feasibility Study: Analyze the capabilities of current LLMs and assess whether they can be adapted to operate an OS kernel.
|
||||
|
||||
Requirement Analysis: Identify the hardware, software, and data requirements for implementing a swarm of LLM agents in an OS.
|
||||
|
||||
System Design: Design a prototype system that uses LLM agents to perform basic kernel operations.
|
||||
|
||||
Implementation and Testing: Implement the prototype system and conduct rigorous testing to evaluate its performance.
|
||||
|
||||
Requirements
|
||||
Hardware: A high-performance computing system would be required to handle the computational load of millions of LLM agents. This system would need to have a powerful CPU, a large amount of RAM, and possibly a GPU for machine learning tasks.
|
||||
|
||||
Software: The system would require an operating system that is compatible with the LLM agents. This could be a popular OS like Linux, which is open-source and widely used in AI research.
|
||||
|
||||
LLM Agents: The LLM agents would need to be trained to perform kernel operations. This would require a large dataset of kernel operations and their outcomes.
|
||||
|
||||
Swarm Intelligence Framework: A framework for swarm intelligence would be needed to manage the LLM agents and coordinate their activities.
|
||||
|
||||
Monitoring and Debugging Tools: Tools for monitoring the performance of the LLM agents and debugging any issues would be essential.
|
||||
|
||||
Potential Challenges
|
||||
Complexity of Kernel Operations: Kernel operations are complex and low-level. Training LLM agents to perform these operations accurately and efficiently could be challenging.
|
||||
|
||||
Coordination of LLM Agents: Coordinating the activities of millions of LLM agents could be a complex task. The swarm intelligence framework would need to be robust and efficient.
|
||||
|
||||
Security: The system would need to be secure to prevent unauthorized access and ensure the integrity of the kernel operations.
|
||||
|
||||
Performance: The system would need to be able to handle a high load and perform operations quickly to avoid slowing down the OS.
|
||||
|
||||
Conclusion
|
||||
Creating a swarm of LLM agents for operating systems is a challenging but potentially rewarding endeavor. This research aims to explore the feasibility of this idea and identify the requirements for its implementation. If successful, this could open up new possibilities for AI in operating systems and beyond.
|
||||
|
||||
@ -1,80 +0,0 @@
|
||||
## **Product Feature Document: Multi-Agent Distributed Collaboration Framework**
|
||||
|
||||
---
|
||||
|
||||
**Introduction**:
|
||||
In the modern age of AI, the potential of harnessing multiple intelligent agents to automate real-world tasks offers unprecedented value. We're building a framework that enables multi-agent distributed collaboration, akin to working with millions of GPT-3 nodes, and this document outlines the features which will bring tremendous value to early adopters.
|
||||
|
||||
---
|
||||
|
||||
**1. Data Security & Privacy**
|
||||
- **On-Premise Hosting**: Users can deploy the framework on their server to ensure data doesn't leave their ecosystem.
|
||||
- **Private Learning**: The agents can learn without transmitting sensitive data out.
|
||||
- **Firewalled Models**: Ensures that all model data remains secured behind barriers, preventing unauthorized data access.
|
||||
- **HuggingFace Integration**: For those comfortable with the HuggingFace ecosystem.
|
||||
- **Transparency**: Ability to see agent activity, task history, which aids in accountability.
|
||||
|
||||
---
|
||||
|
||||
**2. Agent & Swarm Management**
|
||||
- **Optimized Task Allocation**: System can decide which agents are best suited for each task, based on their learning and past performance.
|
||||
- **Agent Feedback System**: Enables users to assist or provide feedback to the managing agent.
|
||||
- **Holistic Swarm View**: Visualize the entire swarm, the communication streams, and individually modify agent behavior.
|
||||
- **Work Optimization**: Routines to determine the most efficient distribution of tasks amongst agents.
|
||||
- **Quality Assurance Agent**: A specialized agent to ensure the outputs meet the required standards.
|
||||
|
||||
---
|
||||
|
||||
**3. Output Management & Monitoring**
|
||||
- **Stop Looping**: If an agent gets stuck in a task loop, the system can intervene.
|
||||
- **Output Monitoring**: Real-time surveillance of what each agent produces.
|
||||
- **Task Summaries**: An overview of tasks, tailored to different management levels (CEO summary, manager summary).
|
||||
|
||||
---
|
||||
|
||||
**4. Cross-Platform Integration**
|
||||
- **OS Compatibility**: Seamlessly operate across Mac, Linux, and Windows.
|
||||
- **Beyond Browser**: Ability to interact with different applications across the entire OS.
|
||||
|
||||
---
|
||||
|
||||
**5. Customization & Training**
|
||||
- **Agent Personalization**: Tailor each agent's prompts, tools, and behavior to better fit specific tasks.
|
||||
- **Training Agent for SMBs**: Simplified input prompting system to guide small-medium businesses.
|
||||
- **Human Training Agent**: Uses visual aids, questions, and references to train human users. Incorporates meta prompting for dynamic environments.
|
||||
|
||||
---
|
||||
|
||||
**6. Installation & Deployment**
|
||||
- **Easy Install Process**: Streamlined installation process, with real-time troubleshooting support.
|
||||
- **Cloud Setup for Non-GPU**: For those without local GPU, a straightforward cloud setup guide.
|
||||
|
||||
---
|
||||
|
||||
**7. Advanced Agent Dynamics**
|
||||
- **Non-Hierarchical Structure**: Worker agents autonomously pick tasks based on their strengths.
|
||||
- **Knowledge Store**: A separate or integrated system where agents access and augment their knowledge.
|
||||
- **API Integration**: Ability to easily integrate different APIs like LLM, GPT-4, and Anthropic.
|
||||
|
||||
---
|
||||
|
||||
**8. Memory & Knowledge Management**
|
||||
- **Differentiated Memory**: Separate memory storage for individual agents and the entire swarm, aiding in more efficient task delegation and execution.
|
||||
|
||||
---
|
||||
|
||||
**Events and Workshops (for community involvement & onboarding)**
|
||||
- **Monthly Webinars**: Dive deep into feature releases, use cases, and best practices.
|
||||
- **Next Session**: August 25th, 2023 - "Harnessing the Power of Multi-Agent Systems"
|
||||
- **Quarterly Workshops**: Hands-on sessions for businesses to understand how to best leverage the framework.
|
||||
- **Upcoming Workshop**: September 15th-17th, 2023 - "Optimizing Agent Performance for Business Tasks"
|
||||
- **Annual Swarm Conclave**: A grand gathering of all community members, developers, and businesses to discuss future roadmaps and celebrate successes.
|
||||
- **Swarm Conclave 2023**: December 2nd-4th, 2023, San Francisco, CA.
|
||||
|
||||
---
|
||||
|
||||
**Conclusion**:
|
||||
This framework is not merely a technological tool, but a step into the future of collaborative AI. By combining the strengths of multiple intelligent agents, we can redefine how businesses operate, innovate, and grow.
|
||||
|
||||
**Join the revolution. Become part of Agora.**
|
||||
[**Discord Link**](https://discord.gg/qUtxnK2NMf)
|
||||
@ -1,75 +0,0 @@
|
||||
### Plan:
|
||||
|
||||
1. **Example Creation**:
|
||||
- Develop several usage examples, each one demonstrating a different configuration or set of parameters for the `VortexWorkerAgent` class.
|
||||
|
||||
2. **Documentation**:
|
||||
- Create a clear and concise documentation for each method in the class. Ensure that each method's purpose, input parameters, and return values (if any) are described.
|
||||
|
||||
3. **Rules and Guidelines**:
|
||||
- Establish a set of general usage rules and guidelines for effectively using the `VortexWorkerAgent` class without running into common pitfalls or misconfigurations.
|
||||
|
||||
### Code:
|
||||
|
||||
#### Examples:
|
||||
|
||||
```python
|
||||
# Example 1: Basic Initialization
|
||||
agent1 = VortexWorkerAgent(openai_api_key="YOUR_OPENAI_API_KEY")
|
||||
agent1.run("Help me find resources about renewable energy.")
|
||||
|
||||
# Example 2: Custom Name & Role
|
||||
agent2 = VortexWorkerAgent(openai_api_key="YOUR_OPENAI_API_KEY", worker_name="EcoHelper", worker_role="Researcher")
|
||||
agent2.run("Fetch me the latest data on solar energy advancements.")
|
||||
|
||||
# Example 3: Human-in-the-Loop Configuration
|
||||
agent3 = VortexWorkerAgent(openai_api_key="YOUR_OPENAI_API_KEY", human_in_the_loop=True)
|
||||
agent3.run("Provide me with a summary of the top AI advancements in 2023, and if unsure, ask me.")
|
||||
|
||||
# Example 4: Custom LLM & Tools Initialization
|
||||
custom_llm = InMemoryDocstore({ "answer": "This is a custom answer." })
|
||||
custom_tools = [WebpageQATool(qa_chain=load_qa_with_sources_chain(custom_llm))]
|
||||
|
||||
agent4 = VortexWorkerAgent(openai_api_key="YOUR_OPENAI_API_KEY", llm=custom_llm, tools=custom_tools)
|
||||
agent4.run("What's the answer?")
|
||||
```
|
||||
|
||||
#### Documentation:
|
||||
|
||||
```python
|
||||
class VortexWorkerAgent:
|
||||
"""An autonomous agent instance that accomplishes complex tasks.
|
||||
|
||||
Args:
|
||||
openai_api_key (str): The API key for OpenAI.
|
||||
llm (Optional[Union[InMemoryDocstore, ChatOpenAI]]): The Language Model to use. Defaults to ChatOpenAI.
|
||||
tools (Optional[List[Tool]]): Tools to be used by the agent. Defaults to a predefined list.
|
||||
embedding_size (Optional[int]): Size for embeddings. Defaults to 8192.
|
||||
worker_name (Optional[str]): Name of the worker. Defaults to "Swarm Worker AI Assistant".
|
||||
worker_role (Optional[str]): Role of the worker. Defaults to "Assistant".
|
||||
human_in_the_loop (Optional[bool]): Flag to specify if a human will be in the loop. Defaults to False.
|
||||
search_kwargs (dict): Additional keyword arguments for search. Empty by default.
|
||||
verbose (Optional[bool]): Verbose flag. Defaults to False.
|
||||
chat_history_file (str): File path to store chat history. Defaults to "chat_history.txt".
|
||||
|
||||
Methods:
|
||||
add_tool(tool: Tool): Adds a new tool to the agent's toolset.
|
||||
run(prompt: str) -> str: Executes a given task or query using the agent.
|
||||
"""
|
||||
```
|
||||
|
||||
#### Rules and Guidelines:
|
||||
|
||||
1. **Mandatory OpenAI API Key**: Always initialize the `VortexWorkerAgent` with a valid OpenAI API key. It's essential for its proper functioning.
|
||||
|
||||
2. **Custom LLMs & Tools**: When providing custom LLMs or tools, ensure they are compatible with the system and the rest of the agent's components.
|
||||
|
||||
3. **Human-in-the-Loop**: When `human_in_the_loop` is set to `True`, always ensure you have a mechanism to interact with the agent, especially if it prompts for human input.
|
||||
|
||||
4. **Verbose Mode**: Turning on the verbose mode (`verbose=True`) can be useful for debugging but might clutter the console during standard operations.
|
||||
|
||||
5. **Memory & Performance**: If you're working with large datasets or demanding tasks, ensure you have sufficient computational resources. The agent can be resource-intensive, especially with bigger embedding sizes.
|
||||
|
||||
6. **Safety & Security**: Always be cautious about the data you provide and fetch using the agent. Avoid sharing sensitive or personal information unless necessary.
|
||||
|
||||
7. **Chat History**: By default, the chat history is saved in a file named "chat_history.txt". Ensure you have the appropriate write permissions in the directory or specify a different path if needed.
|
||||
@ -0,0 +1,124 @@
|
||||
# swarms.agents
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
`AbstractAgent` is an abstract class that serves as a foundation for implementing AI agents. An agent is an entity that can communicate with other agents and perform actions. The `AbstractAgent` class allows for customization in the implementation of the `receive` method, enabling different agents to define unique actions for receiving and processing messages.
|
||||
|
||||
`AbstractAgent` provides capabilities for managing tools and accessing memory, and has methods for running, chatting, and stepping through communication with other agents.
|
||||
|
||||
## 2. Class Definition
|
||||
|
||||
```python
|
||||
class AbstractAgent:
|
||||
"""An abstract class for AI agent.
|
||||
|
||||
An agent can communicate with other agents and perform actions.
|
||||
Different agents can differ in what actions they perform in the `receive` method.
|
||||
|
||||
Agents are full and completed:
|
||||
|
||||
Agents = llm + tools + memory
|
||||
"""
|
||||
|
||||
def __init__(self, name: str):
|
||||
"""
|
||||
Args:
|
||||
name (str): name of the agent.
|
||||
"""
|
||||
self._name = name
|
||||
|
||||
@property
|
||||
def name(self):
|
||||
"""Get the name of the agent."""
|
||||
return self._name
|
||||
|
||||
def tools(self, tools):
|
||||
"""init tools"""
|
||||
|
||||
def memory(self, memory_store):
|
||||
"""init memory"""
|
||||
pass
|
||||
|
||||
def reset(self):
|
||||
"""(Abstract method) Reset the agent."""
|
||||
|
||||
def run(self, task: str):
|
||||
"""Run the agent once"""
|
||||
|
||||
def _arun(self, taks: str):
|
||||
"""Run Async run"""
|
||||
|
||||
def chat(self, messages: List[Dict]):
|
||||
"""Chat with the agent"""
|
||||
|
||||
def _achat(self, messages: List[Dict]):
|
||||
"""Asynchronous Chat"""
|
||||
|
||||
def step(self, message: str):
|
||||
"""Step through the agent"""
|
||||
|
||||
def _astep(self, message: str):
|
||||
"""Asynchronous step"""
|
||||
```
|
||||
|
||||
## 3. Functionality and Usage
|
||||
|
||||
The `AbstractAgent` class represents a generic AI agent and provides a set of methods to interact with it.
|
||||
|
||||
To create an instance of an agent, the `name` of the agent should be specified.
|
||||
|
||||
### Core Methods
|
||||
|
||||
#### 1. `reset`
|
||||
|
||||
The `reset` method allows the agent to be reset to its initial state.
|
||||
|
||||
```python
|
||||
agent.reset()
|
||||
```
|
||||
|
||||
#### 2. `run`
|
||||
|
||||
The `run` method allows the agent to perform a specific task.
|
||||
|
||||
```python
|
||||
agent.run('some_task')
|
||||
```
|
||||
|
||||
#### 3. `chat`
|
||||
|
||||
The `chat` method enables communication with the agent through a series of messages.
|
||||
|
||||
```python
|
||||
messages = [{'id': 1, 'text': 'Hello, agent!'}, {'id': 2, 'text': 'How are you?'}]
|
||||
agent.chat(messages)
|
||||
```
|
||||
|
||||
#### 4. `step`
|
||||
|
||||
The `step` method allows the agent to process a single message.
|
||||
|
||||
```python
|
||||
agent.step('Hello, agent!')
|
||||
```
|
||||
|
||||
### Asynchronous Methods
|
||||
|
||||
The class also provides asynchronous variants of the core methods.
|
||||
|
||||
### Additional Functionality
|
||||
|
||||
Additional functionalities for agent initialization and management of tools and memory are also provided.
|
||||
|
||||
```python
|
||||
agent.tools(some_tools)
|
||||
agent.memory(some_memory_store)
|
||||
```
|
||||
|
||||
## 4. Additional Information and Tips
|
||||
|
||||
When implementing a new agent using the `AbstractAgent` class, ensure that the `receive` method is overridden to define the specific behavior of the agent upon receiving messages.
|
||||
|
||||
## 5. References and Resources
|
||||
|
||||
For further exploration and understanding of AI agents and agent communication, refer to the relevant literature and research on this topic.
|
||||
@ -0,0 +1,120 @@
|
||||
# The Module/Class Name: Message
|
||||
|
||||
In the swarms.agents framework, the class `Message` is used to represent a message with timestamp and optional metadata.
|
||||
|
||||
## Overview and Introduction
|
||||
|
||||
The `Message` class is a fundamental component that enables the representation of messages within an agent system. Messages contain essential information such as the sender, content, timestamp, and optional metadata.
|
||||
|
||||
## Class Definition
|
||||
|
||||
### Constructor: `__init__`
|
||||
|
||||
The constructor of the `Message` class takes three parameters:
|
||||
|
||||
1. `sender` (str): The sender of the message.
|
||||
2. `content` (str): The content of the message.
|
||||
3. `metadata` (dict or None): Optional metadata associated with the message.
|
||||
|
||||
### Methods
|
||||
|
||||
1. `__repr__(self)`: Returns a string representation of the `Message` object, including the timestamp, sender, and content.
|
||||
|
||||
```python
|
||||
class Message:
|
||||
"""
|
||||
Represents a message with timestamp and optional metadata.
|
||||
|
||||
Usage
|
||||
--------------
|
||||
mes = Message(
|
||||
sender = "Kye",
|
||||
content = "message"
|
||||
)
|
||||
|
||||
print(mes)
|
||||
"""
|
||||
|
||||
def __init__(self, sender, content, metadata=None):
|
||||
self.timestamp = datetime.datetime.now()
|
||||
self.sender = sender
|
||||
self.content = content
|
||||
self.metadata = metadata or {}
|
||||
|
||||
def __repr__(self):
|
||||
"""
|
||||
__repr__ represents the string representation of the Message object.
|
||||
|
||||
Returns:
|
||||
(str) A string containing the timestamp, sender, and content of the message.
|
||||
"""
|
||||
return f"{self.timestamp} - {self.sender}: {self.content}"
|
||||
```
|
||||
|
||||
## Functionality and Usage
|
||||
|
||||
The `Message` class represents a message in the agent system. Upon initialization, the `timestamp` is set to the current date and time, and the `metadata` is set to an empty dictionary if no metadata is provided.
|
||||
|
||||
### Usage Example 1
|
||||
|
||||
Creating a `Message` object and displaying its string representation.
|
||||
|
||||
```python
|
||||
mes = Message(
|
||||
sender = "Kye",
|
||||
content = "Hello! How are you?"
|
||||
)
|
||||
|
||||
print(mes)
|
||||
```
|
||||
|
||||
Output:
|
||||
```
|
||||
2023-09-20 13:45:00 - Kye: Hello! How are you?
|
||||
```
|
||||
|
||||
### Usage Example 2
|
||||
|
||||
Creating a `Message` object with metadata.
|
||||
|
||||
```python
|
||||
metadata = {"priority": "high", "category": "urgent"}
|
||||
mes_with_metadata = Message(
|
||||
sender = "Alice",
|
||||
content = "Important update",
|
||||
metadata = metadata
|
||||
)
|
||||
|
||||
print(mes_with_metadata)
|
||||
```
|
||||
|
||||
Output:
|
||||
```
|
||||
2023-09-20 13:46:00 - Alice: Important update
|
||||
```
|
||||
|
||||
### Usage Example 3
|
||||
|
||||
Creating a `Message` object without providing metadata.
|
||||
|
||||
```python
|
||||
mes_no_metadata = Message(
|
||||
sender = "Bob",
|
||||
content = "Reminder: Meeting at 2PM"
|
||||
)
|
||||
|
||||
print(mes_no_metadata)
|
||||
```
|
||||
|
||||
Output:
|
||||
```
|
||||
2023-09-20 13:47:00 - Bob: Reminder: Meeting at 2PM
|
||||
```
|
||||
|
||||
## Additional Information and Tips
|
||||
|
||||
When creating a new `Message` object, ensure that the required parameters `sender` and `content` are provided. The `timestamp` will automatically be assigned the current date and time. Optional `metadata` can be included to provide additional context or information associated with the message.
|
||||
|
||||
## References and Resources
|
||||
|
||||
For further information on the `Message` class and its usage, refer to the official swarms.agents documentation and relevant tutorials related to message handling and communication within the agent system.
|
||||
@ -0,0 +1,79 @@
|
||||
# Module/Class Name: OmniModalAgent
|
||||
|
||||
The `OmniModalAgent` class is a module that operates based on the Language Model (LLM) aka Language Understanding Model, Plans, Tasks, and Tools. It is designed to be a multi-modal chatbot which uses various AI-based capabilities for fulfilling user requests.
|
||||
|
||||
It has the following architecture:
|
||||
1. Language Model (LLM).
|
||||
2. Chat Planner - Plans
|
||||
3. Task Executor - Tasks
|
||||
4. Tools - Tools
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Usage
|
||||
from swarms import OmniModalAgent, OpenAIChat
|
||||
|
||||
llm = OpenAIChat()
|
||||
agent = OmniModalAgent(llm)
|
||||
response = agent.run("Hello, how are you? Create an image of how your are doing!")
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
### Initialization
|
||||
|
||||
The constructor of `OmniModalAgent` class takes two main parameters:
|
||||
- `llm`: A `BaseLanguageModel` that represents the language model
|
||||
- `tools`: A List of `BaseTool` instances that are used by the agent for fulfilling different requests.
|
||||
|
||||
```python
|
||||
def __init__(
|
||||
self,
|
||||
llm: BaseLanguageModel,
|
||||
# tools: List[BaseTool]
|
||||
):
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Methods
|
||||
|
||||
The class has two main methods:
|
||||
1. `run`: This method takes an input string and executes various plans and tasks using the provided tools. Ultimately, it generates a response based on the user's input and returns it.
|
||||
- Parameters:
|
||||
- `input`: A string representing the user's input text.
|
||||
- Returns:
|
||||
- A string representing the response.
|
||||
|
||||
Usage:
|
||||
```python
|
||||
response = agent.run("Hello, how are you? Create an image of how your are doing!")
|
||||
```
|
||||
|
||||
2. `chat`: This method is used to simulate a chat dialog with the agent. It can take user's messages and return the response (or stream the response word-by-word if required).
|
||||
- Parameters:
|
||||
- `msg` (optional): A string representing the message to send to the agent.
|
||||
- `streaming` (optional): A boolean specifying whether to stream the response.
|
||||
- Returns:
|
||||
- A string representing the response from the agent.
|
||||
|
||||
Usage:
|
||||
```python
|
||||
response = agent.chat("Hello")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Streaming Response
|
||||
|
||||
The class provides a method `_stream_response` that can be used to get the response token by token (i.e. word by word). It yields individual tokens from the response.
|
||||
|
||||
Usage:
|
||||
```python
|
||||
for token in _stream_response(response):
|
||||
print(token)
|
||||
```
|
||||
|
||||
@ -0,0 +1,113 @@
|
||||
# ToolAgent Documentation
|
||||
|
||||
|
||||
### Overview and Introduction
|
||||
|
||||
The `ToolAgent` class represents an intelligent agent capable of performing a specific task using a pre-trained model and tokenizer. It leverages the Transformer models of the Hugging Face `transformers` library to generate outputs that adhere to a specific JSON schema. This provides developers with a flexible tool for creating bots, text generators, and conversational AI agents. The `ToolAgent` operates based on a JSON schema provided by you, the user. Using the schema, the agent applies the provided model and tokenizer to generate structured text data that matches the specified format.
|
||||
|
||||
The primary objective of the `ToolAgent` class is to amplify the efficiency of developers and AI practitioners by simplifying the process of generating meaningful outputs that navigate the complexities of the model and tokenizer.
|
||||
|
||||
### Class Definition
|
||||
|
||||
The `ToolAgent` class has the following definition:
|
||||
|
||||
```python
|
||||
class ToolAgent(AbstractLLM):
|
||||
def __init__(
|
||||
self,
|
||||
name: str,
|
||||
description: str,
|
||||
model: Any,
|
||||
tokenizer: Any,
|
||||
json_schema: Any,
|
||||
*args,
|
||||
**kwargs,
|
||||
)
|
||||
def run(self, task: str, *args, **kwargs)
|
||||
def __call__(self, task: str, *args, **kwargs)
|
||||
```
|
||||
|
||||
### Arguments
|
||||
|
||||
The `ToolAgent` class takes the following arguments:
|
||||
|
||||
| Argument | Type | Description |
|
||||
| --- | --- | --- |
|
||||
| name | str | The name of the tool agent.
|
||||
| description | str | A description of the tool agent.
|
||||
| model | Any | The model used by the tool agent (e.g., `transformers.AutoModelForCausalLM`).
|
||||
| tokenizer | Any | The tokenizer used by the tool agent (e.g., `transformers.AutoTokenizer`).
|
||||
| json_schema | Any | The JSON schema used by the tool agent.
|
||||
| *args | - | Variable-length arguments.
|
||||
| **kwargs | - | Keyword arguments.
|
||||
|
||||
### Methods
|
||||
|
||||
`ToolAgent` exposes the following methods:
|
||||
|
||||
#### `run(self, task: str, *args, **kwargs) -> Any`
|
||||
|
||||
- Description: Runs the tool agent for a specific task.
|
||||
- Parameters:
|
||||
- `task` (str): The task to be performed by the tool agent.
|
||||
- `*args`: Variable-length argument list.
|
||||
- `**kwargs`: Arbitrary keyword arguments.
|
||||
- Returns: The output of the tool agent.
|
||||
- Raises: Exception if an error occurs during the execution of the tool agent.
|
||||
|
||||
|
||||
#### `__call__(self, task: str, *args, **kwargs) -> Any`
|
||||
|
||||
- Description: Calls the tool agent to perform a specific task.
|
||||
- Parameters:
|
||||
- `task` (str): The task to be performed by the tool agent.
|
||||
- `*args`: Variable-length argument list.
|
||||
- `**kwargs`: Arbitrary keyword arguments.
|
||||
- Returns: The output of the tool agent.
|
||||
|
||||
### Usage Example
|
||||
|
||||
```python
|
||||
from transformers import AutoModelForCausalLM, AutoTokenizer
|
||||
from swarms import ToolAgent
|
||||
|
||||
# Creating a model and tokenizer
|
||||
model = AutoModelForCausalLM.from_pretrained("databricks/dolly-v2-12b")
|
||||
tokenizer = AutoTokenizer.from_pretrained("databricks/dolly-v2-12b")
|
||||
|
||||
# Defining a JSON schema
|
||||
json_schema = {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"name": {"type": "string"},
|
||||
"age": {"type": "number"},
|
||||
"is_student": {"type": "boolean"},
|
||||
"courses": {
|
||||
"type": "array",
|
||||
"items": {"type": "string"}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# Defining a task
|
||||
task = "Generate a person's information based on the following schema:"
|
||||
|
||||
# Creating the ToolAgent instance
|
||||
agent = ToolAgent(model=model, tokenizer=tokenizer, json_schema=json_schema)
|
||||
|
||||
# Running the tool agent
|
||||
generated_data = agent.run(task)
|
||||
|
||||
# Accessing and printing the generated data
|
||||
print(generated_data)
|
||||
```
|
||||
|
||||
### Additional Information and Tips
|
||||
|
||||
When using the `ToolAgent`, it is important to ensure compatibility between the provided model, tokenizer, and the JSON schema. Additionally, any errors encountered during the execution of the tool agent are propagated as exceptions. Handling such exceptions appropriately can improve the robustness of the tool agent usage.
|
||||
|
||||
### References and Resources
|
||||
|
||||
For further exploration and understanding of the underlying Transformer-based models and tokenizers, refer to the Hugging Face `transformers` library documentation and examples. Additionally, for JSON schema modeling, you can refer to the official JSON Schema specification and examples.
|
||||
|
||||
This documentation provides a comprehensive guide on using the `ToolAgent` class from `swarms` library, and it is recommended to refer back to this document when utilizing the `ToolAgent` for developing your custom conversational agents or text generation tools.
|
||||
@ -0,0 +1,78 @@
|
||||
# WorkerClass Documentation
|
||||
|
||||
## Overview
|
||||
|
||||
The Worker class represents an autonomous agent that can perform tasks through function calls or by running a chat. It can be used to create applications that demand effective user interactions like search engines, human-like conversational bots, or digital assistants.
|
||||
|
||||
The `Worker` class is part of the `swarms.agents` codebase. This module is largely used in Natural Language Processing (NLP) projects where the agent undertakes conversations and other language-specific operations.
|
||||
|
||||
## Class Definition
|
||||
|
||||
The class `Worker` has the following arguments:
|
||||
|
||||
| Argument | Type | Default Value | Description |
|
||||
|-----------------------|---------------|----------------------------------|----------------------------------------------------|
|
||||
| name | str | "Worker" | Name of the agent. |
|
||||
| role | str | "Worker in a swarm" | Role of the agent. |
|
||||
| external_tools | list | None | List of external tools available to the agent. |
|
||||
| human_in_the_loop | bool | False | Determines whether human interaction is required. |
|
||||
| temperature | float | 0.5 | Temperature for the autonomous agent. |
|
||||
| llm | None | None | Language model. |
|
||||
| openai_api_key | str | None | OpenAI API key. |
|
||||
| tools | List[Any] | None | List of tools available to the agent. |
|
||||
| embedding_size | int | 1536 | Size of the word embeddings. |
|
||||
| search_kwargs | dict | {"k": 8} | Search parameters. |
|
||||
| args | Multiple | | Additional arguments that can be passed. |
|
||||
| kwargs | Multiple | | Additional keyword arguments that can be passed. |
|
||||
## Usage
|
||||
|
||||
#### Example 1: Creating and Running an Agent
|
||||
|
||||
```python
|
||||
from swarms import Worker
|
||||
|
||||
worker = Worker(
|
||||
name="My Worker",
|
||||
role="Worker",
|
||||
external_tools=[MyTool1(), MyTool2()],
|
||||
human_in_the_loop=False,
|
||||
temperature=0.5,
|
||||
llm=some_language_model,
|
||||
openai_api_key="my_key"
|
||||
)
|
||||
worker.run("What's the weather in Miami?")
|
||||
```
|
||||
|
||||
#### Example 2: Receiving and Sending Messages
|
||||
|
||||
```python
|
||||
worker.receieve("User", "Hello there!")
|
||||
worker.receieve("User", "Can you tell me something about history?")
|
||||
worker.send()
|
||||
```
|
||||
|
||||
#### Example 3: Setting up Tools
|
||||
|
||||
```python
|
||||
external_tools = [MyTool1(), MyTool2()]
|
||||
worker = Worker(
|
||||
name="My Worker",
|
||||
role="Worker",
|
||||
external_tools=external_tools,
|
||||
human_in_the_loop=False,
|
||||
temperature=0.5,
|
||||
)
|
||||
```
|
||||
|
||||
## Additional Information and Tips
|
||||
|
||||
- The class allows the setting up of tools for the worker to operate effectively. It provides setup facilities for essential computing infrastructure, such as the agent's memory and language model.
|
||||
- By setting the `human_in_the_loop` parameter to True, interactions with the worker can be made more user-centric.
|
||||
- The `openai_api_key` argument can be provided for leveraging the OpenAI infrastructure and services.
|
||||
- A qualified language model can be passed as an instance of the `llm` object, which can be useful when integrating with state-of-the-art text generation engines.
|
||||
|
||||
## References and Resources
|
||||
|
||||
- [OpenAI APIs](https://openai.com)
|
||||
- [Models and Languages at HuggingFace](https://huggingface.co/models)
|
||||
- [Deep Learning and Language Modeling at the Allen Institute for AI](https://allenai.org)
|
||||
@ -0,0 +1,76 @@
|
||||
# Module Name: Mixtral
|
||||
|
||||
## Introduction
|
||||
The Mixtral module is a powerful language model designed for text generation tasks. It leverages the MistralAI Mixtral-8x7B pre-trained model to generate high-quality text based on user-defined tasks or prompts. In this documentation, we will provide a comprehensive overview of the Mixtral module, including its architecture, purpose, arguments, and detailed usage examples.
|
||||
|
||||
## Purpose
|
||||
The Mixtral module is designed to facilitate text generation tasks using state-of-the-art language models. Whether you need to generate creative content, draft text for various applications, or simply explore the capabilities of Mixtral, this module serves as a versatile and efficient solution. With its easy-to-use interface, you can quickly generate text for a wide range of applications.
|
||||
|
||||
## Architecture
|
||||
The Mixtral module is built on top of the MistralAI Mixtral-8x7B pre-trained model. It utilizes a deep neural network architecture with 8 layers and 7 attention heads to generate coherent and contextually relevant text. The model is capable of handling a variety of text generation tasks, from simple prompts to more complex content generation.
|
||||
|
||||
## Class Definition
|
||||
### `Mixtral(model_name: str = "mistralai/Mixtral-8x7B-v0.1", max_new_tokens: int = 500)`
|
||||
|
||||
#### Parameters
|
||||
- `model_name` (str, optional): The name or path of the pre-trained Mixtral model. Default is "mistralai/Mixtral-8x7B-v0.1".
|
||||
- `max_new_tokens` (int, optional): The maximum number of new tokens to generate. Default is 500.
|
||||
|
||||
## Functionality and Usage
|
||||
The Mixtral module offers a straightforward interface for text generation. It accepts a task or prompt as input and returns generated text based on the provided input.
|
||||
|
||||
### `run(task: Optional[str] = None, **kwargs) -> str`
|
||||
|
||||
#### Parameters
|
||||
- `task` (str, optional): The task or prompt for text generation.
|
||||
|
||||
#### Returns
|
||||
- `str`: The generated text.
|
||||
|
||||
## Usage Examples
|
||||
### Example 1: Basic Usage
|
||||
|
||||
```python
|
||||
from swarms.models import Mixtral
|
||||
|
||||
# Initialize the Mixtral model
|
||||
mixtral = Mixtral()
|
||||
|
||||
# Generate text for a simple task
|
||||
generated_text = mixtral.run("Generate a creative story.")
|
||||
print(generated_text)
|
||||
```
|
||||
|
||||
### Example 2: Custom Model
|
||||
|
||||
You can specify a custom pre-trained model by providing the `model_name` parameter.
|
||||
|
||||
```python
|
||||
custom_model_name = "model_name"
|
||||
mixtral_custom = Mixtral(model_name=custom_model_name)
|
||||
|
||||
generated_text = mixtral_custom.run("Generate text with a custom model.")
|
||||
print(generated_text)
|
||||
```
|
||||
|
||||
### Example 3: Controlling Output Length
|
||||
|
||||
You can control the length of the generated text by adjusting the `max_new_tokens` parameter.
|
||||
|
||||
```python
|
||||
mixtral_length = Mixtral(max_new_tokens=100)
|
||||
|
||||
generated_text = mixtral_length.run("Generate a short text.")
|
||||
print(generated_text)
|
||||
```
|
||||
|
||||
## Additional Information and Tips
|
||||
- It's recommended to use a descriptive task or prompt to guide the text generation process.
|
||||
- Experiment with different prompt styles and lengths to achieve the desired output.
|
||||
- You can fine-tune Mixtral on specific tasks if needed, although pre-trained models often work well out of the box.
|
||||
- Monitor the `max_new_tokens` parameter to control the length of the generated text.
|
||||
|
||||
## Conclusion
|
||||
The Mixtral module is a versatile tool for text generation tasks, powered by the MistralAI Mixtral-8x7B pre-trained model. Whether you need creative writing, content generation, or assistance with text-based tasks, Mixtral can help you achieve your goals. With a simple interface and flexible parameters, it's a valuable addition to your text generation toolkit.
|
||||
|
||||
If you encounter any issues or have questions about using Mixtral, please refer to the MistralAI documentation or reach out to their support team for further assistance. Happy text generation with Mixtral!
|
||||
@ -0,0 +1,105 @@
|
||||
# Module Name: ZeroscopeTTV
|
||||
|
||||
## Introduction
|
||||
The ZeroscopeTTV module is a versatile zero-shot video generation model designed to create videos based on textual descriptions. This comprehensive documentation will provide you with an in-depth understanding of the ZeroscopeTTV module, its architecture, purpose, arguments, and detailed usage examples.
|
||||
|
||||
## Purpose
|
||||
The ZeroscopeTTV module serves as a powerful tool for generating videos from text descriptions. Whether you need to create video content for various applications, visualize textual data, or explore the capabilities of ZeroscopeTTV, this module offers a flexible and efficient solution. With its easy-to-use interface, you can quickly generate videos based on your textual input.
|
||||
|
||||
## Architecture
|
||||
The ZeroscopeTTV module is built on top of the Diffusers library, leveraging the power of diffusion models for video generation. It allows you to specify various parameters such as model name, data type, chunk size, dimensions, and more to customize the video generation process. The model performs multiple inference steps and utilizes a diffusion pipeline to generate high-quality videos.
|
||||
|
||||
## Class Definition
|
||||
### `ZeroscopeTTV(model_name: str = "cerspense/zeroscope_v2_576w", torch_dtype=torch.float16, chunk_size: int = 1, dim: int = 1, num_inference_steps: int = 40, height: int = 320, width: int = 576, num_frames: int = 36)`
|
||||
|
||||
#### Parameters
|
||||
- `model_name` (str, optional): The name of the pre-trained model to use. Default is "cerspense/zeroscope_v2_576w".
|
||||
- `torch_dtype` (torch.dtype, optional): The torch data type to use for computations. Default is torch.float16.
|
||||
- `chunk_size` (int, optional): The size of chunks for forward chunking. Default is 1.
|
||||
- `dim` (int, optional): The dimension along which the input is split for forward chunking. Default is 1.
|
||||
- `num_inference_steps` (int, optional): The number of inference steps to perform. Default is 40.
|
||||
- `height` (int, optional): The height of the video frames. Default is 320.
|
||||
- `width` (int, optional): The width of the video frames. Default is 576.
|
||||
- `num_frames` (int, optional): The number of frames in the video. Default is 36.
|
||||
|
||||
## Functionality and Usage
|
||||
The ZeroscopeTTV module offers a straightforward interface for video generation. It accepts a textual task or description as input and returns the path to the generated video.
|
||||
|
||||
### `run(task: str = None, *args, **kwargs) -> str`
|
||||
|
||||
#### Parameters
|
||||
- `task` (str, optional): The input task or description for video generation.
|
||||
|
||||
#### Returns
|
||||
- `str`: The path to the generated video.
|
||||
|
||||
## Usage Examples
|
||||
### Example 1: Basic Usage
|
||||
|
||||
```python
|
||||
from swarms.models import ZeroscopeTTV
|
||||
|
||||
# Initialize the ZeroscopeTTV model
|
||||
zeroscope = ZeroscopeTTV()
|
||||
|
||||
# Generate a video based on a textual description
|
||||
task = "A bird flying in the sky."
|
||||
video_path = zeroscope.run(task)
|
||||
print(f"Generated video path: {video_path}")
|
||||
```
|
||||
|
||||
### Example 2: Custom Model and Parameters
|
||||
|
||||
You can specify a custom pre-trained model and adjust various parameters for video generation.
|
||||
|
||||
```python
|
||||
custom_model_name = "your_custom_model_path"
|
||||
custom_dtype = torch.float32
|
||||
custom_chunk_size = 2
|
||||
custom_dim = 2
|
||||
custom_num_inference_steps = 50
|
||||
custom_height = 480
|
||||
custom_width = 720
|
||||
custom_num_frames = 48
|
||||
|
||||
custom_zeroscope = ZeroscopeTTV(
|
||||
model_name=custom_model_name,
|
||||
torch_dtype=custom_dtype,
|
||||
chunk_size=custom_chunk_size,
|
||||
dim=custom_dim,
|
||||
num_inference_steps=custom_num_inference_steps,
|
||||
height=custom_height,
|
||||
width=custom_width,
|
||||
num_frames=custom_num_frames,
|
||||
)
|
||||
|
||||
task = "A car driving on the road."
|
||||
video_path = custom_zeroscope.run(task)
|
||||
print(f"Generated video path: {video_path}")
|
||||
```
|
||||
|
||||
### Example 3: Exporting Video Frames
|
||||
|
||||
You can also export individual video frames if needed.
|
||||
|
||||
```python
|
||||
from swarms.models import export_to_video
|
||||
|
||||
# Generate video frames
|
||||
video_frames = zeroscope.run("A boat sailing on the water.")
|
||||
|
||||
# Export video frames to a video file
|
||||
video_path = export_to_video(video_frames)
|
||||
print(f"Generated video path: {video_path}")
|
||||
```
|
||||
|
||||
## Additional Information and Tips
|
||||
- Ensure that the input textual task or description is clear and descriptive to achieve the desired video output.
|
||||
- Experiment with different parameter settings to control video resolution, frame count, and inference steps.
|
||||
- Use the `export_to_video` function to export individual video frames as needed.
|
||||
- Monitor the progress and output paths to access the generated videos.
|
||||
|
||||
## Conclusion
|
||||
The ZeroscopeTTV module is a powerful solution for zero-shot video generation based on textual descriptions. Whether you are creating videos for storytelling, data visualization, or other applications, ZeroscopeTTV offers a versatile and efficient way to bring your text to life. With a flexible interface and customizable parameters, it empowers you to generate high-quality videos with ease.
|
||||
|
||||
If you encounter any issues or have questions about using ZeroscopeTTV, please refer to the Diffusers library documentation or reach out to their support team for further assistance. Enjoy creating videos with ZeroscopeTTV!
|
||||
@ -0,0 +1,106 @@
|
||||
# swarms.structs Documentation
|
||||
|
||||
## Introduction
|
||||
|
||||
The swarms.structs library provides a collection of classes for representing artifacts and their attributes. This documentation will provide an overview of the `Artifact` class, its attributes, functionality, and usage examples.
|
||||
|
||||
### Artifact Class
|
||||
|
||||
The `Artifact` class represents an artifact and its attributes. It inherits from the `BaseModel` class and includes the following attributes:
|
||||
|
||||
#### Attributes
|
||||
|
||||
1. `artifact_id (str)`: Id of the artifact.
|
||||
2. `file_name (str)`: Filename of the artifact.
|
||||
3. `relative_path (str, optional)`: Relative path of the artifact in the agent's workspace.
|
||||
|
||||
These attributes are crucial for identifying and managing different artifacts within a given context.
|
||||
|
||||
## Class Definition
|
||||
|
||||
The `Artifact` class can be defined as follows:
|
||||
|
||||
```python
|
||||
class Artifact(BaseModel):
|
||||
"""
|
||||
Represents an artifact.
|
||||
|
||||
Attributes:
|
||||
artifact_id (str): Id of the artifact.
|
||||
file_name (str): Filename of the artifact.
|
||||
relative_path (str, optional): Relative path of the artifact in the agent's workspace.
|
||||
"""
|
||||
|
||||
artifact_id: str = Field(
|
||||
...,
|
||||
description="Id of the artifact",
|
||||
example="b225e278-8b4c-4f99-a696-8facf19f0e56",
|
||||
)
|
||||
file_name: str = Field(
|
||||
..., description="Filename of the artifact", example="main.py"
|
||||
)
|
||||
relative_path: Optional[str] = Field(
|
||||
None,
|
||||
description=(
|
||||
"Relative path of the artifact in the agent's workspace"
|
||||
),
|
||||
example="python/code/",
|
||||
)
|
||||
```
|
||||
|
||||
The `Artifact` class defines the mandatory and optional attributes and provides corresponding descriptions along with example values.
|
||||
|
||||
## Functionality and Usage
|
||||
|
||||
The `Artifact` class encapsulates the information and attributes representing an artifact. It provides a structured and organized way to manage artifacts within a given context.
|
||||
|
||||
### Example 1: Creating an Artifact instance
|
||||
|
||||
To create an instance of the `Artifact` class, you can simply initialize it with the required attributes. Here's an example:
|
||||
|
||||
```python
|
||||
from swarms.structs import Artifact
|
||||
|
||||
artifact_instance = Artifact(
|
||||
artifact_id="b225e278-8b4c-4f99-a696-8facf19f0e56",
|
||||
file_name="main.py",
|
||||
relative_path="python/code/"
|
||||
)
|
||||
```
|
||||
|
||||
In this example, we create an instance of the `Artifact` class with the specified artifact details.
|
||||
|
||||
### Example 2: Accessing Artifact attributes
|
||||
|
||||
You can access the attributes of the `Artifact` instance using dot notation. Here's how you can access the file name of the artifact:
|
||||
|
||||
```python
|
||||
print(artifact_instance.file_name)
|
||||
# Output: "main.py"
|
||||
```
|
||||
|
||||
### Example 3: Handling optional attributes
|
||||
|
||||
If the `relative_path` attribute is not provided during artifact creation, it will default to `None`. Here's an example:
|
||||
|
||||
```python
|
||||
artifact_instance_no_path = Artifact(
|
||||
artifact_id="c280s347-9b7d-3c68-m337-7abvf50j23k",
|
||||
file_name="script.js"
|
||||
)
|
||||
|
||||
print(artifact_instance_no_path.relative_path)
|
||||
# Output: None
|
||||
```
|
||||
|
||||
By providing default values for optional attributes, the `Artifact` class allows flexibility in defining artifact instances.
|
||||
|
||||
### Additional Information and Tips
|
||||
|
||||
The `Artifact` class represents a powerful and flexible means of handling various artifacts with different attributes. By utilizing this class, users can organize, manage, and streamline their artifacts with ease.
|
||||
|
||||
## References and Resources
|
||||
|
||||
For further details and references related to the swarms.structs library and the `Artifact` class, refer to the [official documentation](https://swarms.structs.docs/artifact.html).
|
||||
|
||||
This comprehensive documentation provides an in-depth understanding of the `Artifact` class, its attributes, functionality, and usage examples. By following the detailed examples and explanations, developers can effectively leverage the capabilities of the `Artifact` class within their projects.
|
||||
@ -0,0 +1,49 @@
|
||||
# swarms.structs
|
||||
|
||||
## Overview
|
||||
|
||||
Swarms is a library that provides tools for managing a distributed system of agents working together to achieve a common goal. The structs module within Swarms provides a set of data structures and classes that are used to represent artifacts, tasks, and other entities within the system. The `ArtifactUpload` class is one such data structure that represents the process of uploading an artifact to an agent's workspace.
|
||||
|
||||
## ArtifactUpload
|
||||
|
||||
The `ArtifactUpload` class inherits from the `BaseModel` class. It has two attributes: `file` and `relative_path`. The `file` attribute represents the bytes of the file to be uploaded, while the `relative_path` attribute represents the relative path of the artifact in the agent's workspace.
|
||||
|
||||
### Class Definition
|
||||
|
||||
```python
|
||||
class ArtifactUpload(BaseModel):
|
||||
file: bytes = Field(..., description="File to upload")
|
||||
relative_path: Optional[str] = Field(
|
||||
None,
|
||||
description=(
|
||||
"Relative path of the artifact in the agent's workspace"
|
||||
),
|
||||
example="python/code/",
|
||||
)
|
||||
```
|
||||
|
||||
The `ArtifactUpload` class requires the `file` attribute to be passed as an argument. It is of type `bytes` and represents the file to be uploaded. The `relative_path` attribute is optional and is of type `str`. It represents the relative path of the artifact in the agent's workspace. If not provided, it defaults to `None`.
|
||||
|
||||
### Functionality and Usage
|
||||
|
||||
The `ArtifactUpload` class is used to create an instance of an artifact upload. It can be instantiated with or without a `relative_path`. Here is an example of how the class can be used:
|
||||
|
||||
```python
|
||||
from swarms.structs import ArtifactUpload
|
||||
|
||||
# Uploading a file with no relative path
|
||||
upload_no_path = ArtifactUpload(file=b'example_file_contents')
|
||||
|
||||
# Uploading a file with a relative path
|
||||
upload_with_path = ArtifactUpload(file=b'example_file_contents', relative_path="python/code/")
|
||||
```
|
||||
|
||||
In the above example, `upload_no_path` is an instance of `ArtifactUpload` with no specified `relative_path`, whereas `upload_with_path` is an instance of `ArtifactUpload` with the `relative_path` set to "python/code/".
|
||||
|
||||
### Additional Information
|
||||
|
||||
When passing the `file` and `relative_path` parameters to the `ArtifactUpload` class, ensure that the `file` parameter is provided exactly as the file that needs to be uploaded, represented as a `bytes` object. If a `relative_path` is provided, ensure that it is a valid path within the agent's workspace.
|
||||
|
||||
# Conclusion
|
||||
|
||||
The `ArtifactUpload` class is an essential data structure within the Swarms library that represents the process of uploading an artifact to an agent's workspace. By using this class, users can easily manage and represent artifact uploads within the Swarms distributed system.
|
||||
@ -0,0 +1,137 @@
|
||||
# Module/Function Name: BaseStructure
|
||||
|
||||
## Introduction:
|
||||
|
||||
The `BaseStructure` module contains the basic structure and attributes required for running machine learning models and associated metadata, error logging, artifact saving/loading, and relevant event logging.
|
||||
|
||||
The module provides the flexibility to save and load the model metadata, log errors, save artifacts, and maintain a log for multiple events associated with multiple threads and batched operations. The key attributes of the module include **name**, **description**, **save_metadata_path**, and **save_error_path**.
|
||||
|
||||
## Class Definition:
|
||||
|
||||
### Arguments:
|
||||
| Argument | Type | Description |
|
||||
|----------------------|--------|----------------------------------------------------------------------|
|
||||
| name | str | (Optional) The name of the structure. |
|
||||
| description | str | (Optional) A description of the structure. |
|
||||
| save_metadata | bool | A boolean flag to enable or disable metadata saving. |
|
||||
| save_artifact_path | str | (Optional) The path to save artifacts. |
|
||||
| save_metadata_path | str | (Optional) The path to save metadata. |
|
||||
| save_error_path | str | (Optional) The path to save errors. |
|
||||
|
||||
## Methods:
|
||||
|
||||
### 1. run
|
||||
Runs the structure.
|
||||
|
||||
### 2. save_to_file
|
||||
Saves data to a file.
|
||||
* **data**: Value to be saved.
|
||||
* **file_path**: Path where the data is to be saved.
|
||||
|
||||
### 3. load_from_file
|
||||
Loads data from a file.
|
||||
* **file_path**: Path from where the data is to be loaded.
|
||||
|
||||
### 4. save_metadata
|
||||
Saves metadata to a file.
|
||||
* **metadata**: Data to be saved as metadata.
|
||||
|
||||
### 5. load_metadata
|
||||
Loads metadata from a file.
|
||||
|
||||
### 6. log_error
|
||||
Logs error to a file.
|
||||
|
||||
### 7. save_artifact
|
||||
Saves artifact to a file.
|
||||
* **artifact**: The artifact to be saved.
|
||||
* **artifact_name**: Name of the artifact.
|
||||
|
||||
### 8. load_artifact
|
||||
Loads artifact from a file.
|
||||
* **artifact_name**: Name of the artifact.
|
||||
|
||||
### 9. log_event
|
||||
Logs an event to a file.
|
||||
* **event**: The event to be logged.
|
||||
* **event_type**: Type of the event (optional, defaults to "INFO").
|
||||
|
||||
### 10. run_async
|
||||
Runs the structure asynchronously.
|
||||
|
||||
### 11. save_metadata_async
|
||||
Saves metadata to a file asynchronously.
|
||||
|
||||
### 12. load_metadata_async
|
||||
Loads metadata from a file asynchronously.
|
||||
|
||||
### 13. log_error_async
|
||||
Logs error to a file asynchronously.
|
||||
|
||||
### 14. save_artifact_async
|
||||
Saves artifact to a file asynchronously.
|
||||
|
||||
### 15. load_artifact_async
|
||||
Loads artifact from a file asynchronously.
|
||||
|
||||
### 16. log_event_async
|
||||
Logs an event to a file asynchronously.
|
||||
|
||||
### 17. asave_to_file
|
||||
Saves data to a file asynchronously.
|
||||
|
||||
### 18. aload_from_file
|
||||
Loads data from a file asynchronously.
|
||||
|
||||
### 19. run_concurrent
|
||||
Runs the structure concurrently.
|
||||
|
||||
### 20. compress_data
|
||||
Compresses data.
|
||||
|
||||
### 21. decompres_data
|
||||
Decompresses data.
|
||||
|
||||
### 22. run_batched
|
||||
Runs batched data.
|
||||
|
||||
## Examples:
|
||||
|
||||
### Example 1: Saving Metadata
|
||||
```python
|
||||
base_structure = BaseStructure(name="ExampleStructure")
|
||||
metadata = {"key1": "value1", "key2": "value2"}
|
||||
base_structure.save_metadata(metadata)
|
||||
```
|
||||
|
||||
### Example 2: Loading Artifact
|
||||
```python
|
||||
artifact_name = "example_artifact"
|
||||
artifact_data = base_structure.load_artifact(artifact_name)
|
||||
```
|
||||
|
||||
### Example 3: Running Concurrently
|
||||
```python
|
||||
concurrent_data = [data1, data2, data3]
|
||||
results = base_structure.run_concurrent(batched_data=concurrent_data)
|
||||
```
|
||||
|
||||
## Note:
|
||||
|
||||
The `BaseStructure` class is designed to provide a modular and extensible structure for managing metadata, logs, errors, and batched operations while running machine learning models. The class's methods offer asynchronous and concurrent execution capabilities, thus optimizing the performance of the associated applications and models. The module's attributes and methods cater to a wide range of use cases, making it an essential foundational component for machine learning and data-based applications.
|
||||
|
||||
# Conclusion:
|
||||
|
||||
The `BaseStructure` module offers a robust and flexible foundation for managing machine learning model metadata, error logs, and event tracking, including asynchronous, concurrent, and batched operations. By leveraging the inherent capabilities of this class, developers can enhance the reliability, scalability, and performance of machine learning-based applications.
|
||||
|
||||
## References:
|
||||
|
||||
- [Python Concurrent Programming with `asyncio`](https://docs.python.org/3/library/asyncio.html)
|
||||
- [Understanding Thread Pool Executor in Python](https://docs.python.org/3/library/concurrent.futures.html#executor-objects)
|
||||
- [Documentation on `gzip` Module for Data Compression](https://docs.python.org/3/library/gzip.html)
|
||||
|
||||
---
|
||||
|
||||
The above documentation provides detailed information about the `BaseStructure` module, including its functionality, attributes, methods, usage examples, and references to relevant resources for further exploration. This comprehensive documentation aims to deepen the users' understanding of the module's purpose and how it can be effectively utilized in practice.
|
||||
|
||||
Please let me know if you need further elaboration on any specific aspect or functionality of the `BaseStructure` module.
|
||||
@ -0,0 +1,77 @@
|
||||
```
|
||||
# Module/Function Name: ConcurrentWorkflow
|
||||
|
||||
class swarms.structs.ConcurrentWorkflow(max_workers, autosave, saved_state_filepath):
|
||||
"""
|
||||
ConcurrentWorkflow class for running a set of tasks concurrently using N autonomous agents.
|
||||
|
||||
Args:
|
||||
- max_workers (int): The maximum number of workers to use for concurrent execution.
|
||||
- autosave (bool): Whether to autosave the workflow state.
|
||||
- saved_state_filepath (Optional[str]): The file path to save the workflow state.
|
||||
|
||||
"""
|
||||
|
||||
def add(self, task, tasks=None):
|
||||
"""Adds a task to the workflow.
|
||||
|
||||
Args:
|
||||
- task (Task): Task to add to the workflow.
|
||||
- tasks (List[Task]): List of tasks to add to the workflow (optional).
|
||||
|
||||
"""
|
||||
try:
|
||||
# Implementation of the function goes here
|
||||
except Exception as error:
|
||||
print(f"[ERROR][ConcurrentWorkflow] {error}")
|
||||
raise error
|
||||
|
||||
def run(self, print_results=False, return_results=False):
|
||||
"""
|
||||
Executes the tasks in parallel using a ThreadPoolExecutor.
|
||||
|
||||
Args:
|
||||
- print_results (bool): Whether to print the results of each task. Default is False.
|
||||
- return_results (bool): Whether to return the results of each task. Default is False.
|
||||
|
||||
Returns:
|
||||
- (List[Any]): A list of the results of each task, if return_results is True. Otherwise, returns None.
|
||||
|
||||
"""
|
||||
try:
|
||||
# Implementation of the function goes here
|
||||
except Exception as e:
|
||||
print(f"Task {task} generated an exception: {e}")
|
||||
|
||||
return results if self.return_results else None
|
||||
|
||||
def _execute_task(self, task):
|
||||
"""Executes a task.
|
||||
|
||||
Args:
|
||||
- task (Task): Task to execute.
|
||||
|
||||
Returns:
|
||||
- result: The result of executing the task.
|
||||
|
||||
"""
|
||||
try:
|
||||
# Implementation of the function goes here
|
||||
except Exception as error:
|
||||
print(f"[ERROR][ConcurrentWorkflow] {error}")
|
||||
raise error
|
||||
|
||||
# Usage example:
|
||||
|
||||
from swarms.models import OpenAIChat
|
||||
from swarms.structs import ConcurrentWorkflow
|
||||
|
||||
llm = OpenAIChat(openai_api_key="")
|
||||
workflow = ConcurrentWorkflow(max_workers=5)
|
||||
workflow.add("What's the weather in miami", llm)
|
||||
workflow.add("Create a report on these metrics", llm)
|
||||
workflow.run()
|
||||
workflow.tasks
|
||||
|
||||
"""
|
||||
```
|
||||
@ -0,0 +1,265 @@
|
||||
# Module/Class Name: Conversation
|
||||
|
||||
## Introduction
|
||||
|
||||
The `Conversation` class is a powerful tool for managing and structuring conversation data in a Python program. It enables you to create, manipulate, and analyze conversations easily. This documentation will provide you with a comprehensive understanding of the `Conversation` class, its attributes, methods, and how to effectively use it.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. **Class Definition**
|
||||
- Overview
|
||||
- Attributes
|
||||
|
||||
2. **Methods**
|
||||
- `__init__(self, time_enabled: bool = False, *args, **kwargs)`
|
||||
- `add(self, role: str, content: str, *args, **kwargs)`
|
||||
- `delete(self, index: str)`
|
||||
- `update(self, index: str, role, content)`
|
||||
- `query(self, index: str)`
|
||||
- `search(self, keyword: str)`
|
||||
- `display_conversation(self, detailed: bool = False)`
|
||||
- `export_conversation(self, filename: str)`
|
||||
- `import_conversation(self, filename: str)`
|
||||
- `count_messages_by_role(self)`
|
||||
- `return_history_as_string(self)`
|
||||
- `save_as_json(self, filename: str)`
|
||||
- `load_from_json(self, filename: str)`
|
||||
- `search_keyword_in_conversation(self, keyword: str)`
|
||||
- `pretty_print_conversation(self, messages)`
|
||||
|
||||
---
|
||||
|
||||
### 1. Class Definition
|
||||
|
||||
#### Overview
|
||||
|
||||
The `Conversation` class is designed to manage conversations by keeping track of messages and their attributes. It offers methods for adding, deleting, updating, querying, and displaying messages within the conversation. Additionally, it supports exporting and importing conversations, searching for specific keywords, and more.
|
||||
|
||||
#### Attributes
|
||||
|
||||
- `time_enabled (bool)`: A flag indicating whether to enable timestamp recording for messages.
|
||||
- `conversation_history (list)`: A list that stores messages in the conversation.
|
||||
|
||||
### 2. Methods
|
||||
|
||||
#### `__init__(self, time_enabled: bool = False, *args, **kwargs)`
|
||||
|
||||
- **Description**: Initializes a new Conversation object.
|
||||
- **Parameters**:
|
||||
- `time_enabled (bool)`: If `True`, timestamps will be recorded for each message. Default is `False`.
|
||||
|
||||
#### `add(self, role: str, content: str, *args, **kwargs)`
|
||||
|
||||
- **Description**: Adds a message to the conversation history.
|
||||
- **Parameters**:
|
||||
- `role (str)`: The role of the speaker (e.g., "user," "assistant").
|
||||
- `content (str)`: The content of the message.
|
||||
|
||||
#### `delete(self, index: str)`
|
||||
|
||||
- **Description**: Deletes a message from the conversation history.
|
||||
- **Parameters**:
|
||||
- `index (str)`: The index of the message to delete.
|
||||
|
||||
#### `update(self, index: str, role, content)`
|
||||
|
||||
- **Description**: Updates a message in the conversation history.
|
||||
- **Parameters**:
|
||||
- `index (str)`: The index of the message to update.
|
||||
- `role (_type_)`: The new role of the speaker.
|
||||
- `content (_type_)`: The new content of the message.
|
||||
|
||||
#### `query(self, index: str)`
|
||||
|
||||
- **Description**: Retrieves a message from the conversation history.
|
||||
- **Parameters**:
|
||||
- `index (str)`: The index of the message to query.
|
||||
- **Returns**: The message as a string.
|
||||
|
||||
#### `search(self, keyword: str)`
|
||||
|
||||
- **Description**: Searches for messages containing a specific keyword in the conversation history.
|
||||
- **Parameters**:
|
||||
- `keyword (str)`: The keyword to search for.
|
||||
- **Returns**: A list of messages that contain the keyword.
|
||||
|
||||
#### `display_conversation(self, detailed: bool = False)`
|
||||
|
||||
- **Description**: Displays the conversation history.
|
||||
- **Parameters**:
|
||||
- `detailed (bool, optional)`: If `True`, provides detailed information about each message. Default is `False`.
|
||||
|
||||
#### `export_conversation(self, filename: str)`
|
||||
|
||||
- **Description**: Exports the conversation history to a text file.
|
||||
- **Parameters**:
|
||||
- `filename (str)`: The name of the file to export to.
|
||||
|
||||
#### `import_conversation(self, filename: str)`
|
||||
|
||||
- **Description**: Imports a conversation history from a text file.
|
||||
- **Parameters**:
|
||||
- `filename (str)`: The name of the file to import from.
|
||||
|
||||
#### `count_messages_by_role(self)`
|
||||
|
||||
- **Description**: Counts the number of messages by role in the conversation.
|
||||
- **Returns**: A dictionary containing the count of messages for each role.
|
||||
|
||||
#### `return_history_as_string(self)`
|
||||
|
||||
- **Description**: Returns the entire conversation history as a single string.
|
||||
- **Returns**: The conversation history as a string.
|
||||
|
||||
#### `save_as_json(self, filename: str)`
|
||||
|
||||
- **Description**: Saves the conversation history as a JSON file.
|
||||
- **Parameters**:
|
||||
- `filename (str)`: The name of the JSON file to save.
|
||||
|
||||
#### `load_from_json(self, filename: str)`
|
||||
|
||||
- **Description**: Loads a conversation history from a JSON file.
|
||||
- **Parameters**:
|
||||
- `filename (str)`: The name of the JSON file to load.
|
||||
|
||||
#### `search_keyword_in_conversation(self, keyword: str)`
|
||||
|
||||
- **Description**: Searches for a keyword in the conversation history and returns matching messages.
|
||||
- **Parameters**:
|
||||
- `keyword (str)`: The keyword to search for.
|
||||
- **Returns**: A list of messages containing the keyword.
|
||||
|
||||
#### `pretty_print_conversation(self, messages)`
|
||||
|
||||
- **Description**: Pretty prints a list of messages with colored role indicators.
|
||||
- **Parameters**:
|
||||
- `messages (list)`: A list of messages to print.
|
||||
|
||||
## Examples
|
||||
|
||||
Here are some usage examples of the `Conversation` class:
|
||||
|
||||
### Creating a Conversation
|
||||
|
||||
```python
|
||||
from swarms.structs import Conversation
|
||||
|
||||
conv = Conversation()
|
||||
```
|
||||
|
||||
### Adding Messages
|
||||
|
||||
```python
|
||||
conv.add("user", "Hello, world!")
|
||||
conv.add("assistant", "Hello, user!")
|
||||
```
|
||||
|
||||
### Displaying the Conversation
|
||||
|
||||
```python
|
||||
conv.display_conversation()
|
||||
```
|
||||
|
||||
### Searching for Messages
|
||||
|
||||
```python
|
||||
result = conv.search("Hello")
|
||||
```
|
||||
|
||||
### Exporting and Importing Conversations
|
||||
|
||||
```python
|
||||
conv.export_conversation("conversation.txt")
|
||||
conv.import_conversation("conversation.txt")
|
||||
```
|
||||
|
||||
### Counting Messages by Role
|
||||
|
||||
```python
|
||||
counts = conv.count_messages_by_role()
|
||||
```
|
||||
|
||||
### Loading and Saving as JSON
|
||||
|
||||
```python
|
||||
conv.save_as_json("conversation.json")
|
||||
conv.load_from_json("conversation.json")
|
||||
```
|
||||
|
||||
Certainly! Let's continue with more examples and additional information about the `Conversation` class.
|
||||
|
||||
### Querying a Specific Message
|
||||
|
||||
You can retrieve a specific message from the conversation by its index:
|
||||
|
||||
```python
|
||||
message = conv.query(0) # Retrieves the first message
|
||||
```
|
||||
|
||||
### Updating a Message
|
||||
|
||||
You can update a message's content or role within the conversation:
|
||||
|
||||
```python
|
||||
conv.update(0, "user", "Hi there!") # Updates the first message
|
||||
```
|
||||
|
||||
### Deleting a Message
|
||||
|
||||
If you want to remove a message from the conversation, you can use the `delete` method:
|
||||
|
||||
```python
|
||||
conv.delete(0) # Deletes the first message
|
||||
```
|
||||
|
||||
### Counting Messages by Role
|
||||
|
||||
You can count the number of messages by role in the conversation:
|
||||
|
||||
```python
|
||||
counts = conv.count_messages_by_role()
|
||||
# Example result: {'user': 2, 'assistant': 2}
|
||||
```
|
||||
|
||||
### Exporting and Importing as Text
|
||||
|
||||
You can export the conversation to a text file and later import it:
|
||||
|
||||
```python
|
||||
conv.export_conversation("conversation.txt") # Export
|
||||
conv.import_conversation("conversation.txt") # Import
|
||||
```
|
||||
|
||||
### Exporting and Importing as JSON
|
||||
|
||||
Conversations can also be saved and loaded as JSON files:
|
||||
|
||||
```python
|
||||
conv.save_as_json("conversation.json") # Save as JSON
|
||||
conv.load_from_json("conversation.json") # Load from JSON
|
||||
```
|
||||
|
||||
### Searching for a Keyword
|
||||
|
||||
You can search for messages containing a specific keyword within the conversation:
|
||||
|
||||
```python
|
||||
results = conv.search_keyword_in_conversation("Hello")
|
||||
```
|
||||
|
||||
### Pretty Printing
|
||||
|
||||
The `pretty_print_conversation` method provides a visually appealing way to display messages with colored role indicators:
|
||||
|
||||
```python
|
||||
conv.pretty_print_conversation(conv.conversation_history)
|
||||
```
|
||||
|
||||
These examples demonstrate the versatility of the `Conversation` class in managing and interacting with conversation data. Whether you're building a chatbot, conducting analysis, or simply organizing dialogues, this class offers a robust set of tools to help you accomplish your goals.
|
||||
|
||||
## Conclusion
|
||||
|
||||
The `Conversation` class is a valuable utility for handling conversation data in Python. With its ability to add, update, delete, search, export, and import messages, you have the flexibility to work with conversations in various ways. Feel free to explore its features and adapt them to your specific projects and applications.
|
||||
|
||||
If you have any further questions or need additional assistance, please don't hesitate to ask!
|
||||
@ -0,0 +1,147 @@
|
||||
# Module Name: Group Chat
|
||||
|
||||
The `GroupChat` class is used to create a group chat containing a list of agents. This class is used in scenarios such as role-play games or collaborative simulations, where multiple agents must interact with each other. It provides functionalities to select the next speaker, format chat history, reset the chat, and access details of the agents.
|
||||
|
||||
## Class Definition
|
||||
|
||||
The `GroupChat` class is defined as follows:
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class GroupChat:
|
||||
"""
|
||||
A group chat class that contains a list of agents and the maximum number of rounds.
|
||||
|
||||
Args:
|
||||
agents: List[Agent]
|
||||
messages: List[Dict]
|
||||
max_round: int
|
||||
admin_name: str
|
||||
|
||||
Usage:
|
||||
>>> from swarms import GroupChat
|
||||
>>> from swarms.structs.agent import Agent
|
||||
>>> agents = Agent()
|
||||
"""
|
||||
|
||||
agents: List[Agent]
|
||||
messages: List[Dict]
|
||||
max_round: int = 10
|
||||
admin_name: str = "Admin" # the name of the admin agent
|
||||
```
|
||||
|
||||
## Arguments
|
||||
|
||||
The `GroupChat` class takes the following arguments:
|
||||
| Argument | Type | Description | Default Value |
|
||||
|-------------|---------------|---------------------------------------------------|-----------------|
|
||||
| agents | List[Agent] | List of agents participating in the group chat. | |
|
||||
| messages | List[Dict] | List of messages exchanged in the group chat. | |
|
||||
| max_round | int | Maximum number of rounds for the group chat. | 10 |
|
||||
| admin_name | str | Name of the admin agent. | "Admin" |
|
||||
|
||||
## Methods
|
||||
|
||||
1. **agent_names**
|
||||
- Returns the names of the agents in the group chat.
|
||||
- Returns: List of strings.
|
||||
|
||||
2. **reset**
|
||||
- Resets the group chat, clears all the messages.
|
||||
|
||||
3. **agent_by_name**
|
||||
- Finds an agent in the group chat by their name.
|
||||
- Arguments: name (str) - Name of the agent to search for.
|
||||
- Returns: Agent - The agent with the matching name.
|
||||
- Raises: ValueError if no matching agent is found.
|
||||
|
||||
4. **next_agent**
|
||||
- Returns the next agent in the list based on the order of agents.
|
||||
- Arguments: agent (Agent) - The current agent.
|
||||
- Returns: Agent - The next agent in the list.
|
||||
|
||||
5. **select_speaker_msg**
|
||||
- Returns the message for selecting the next speaker.
|
||||
|
||||
6. **select_speaker**
|
||||
- Selects the next speaker based on the system message and history of conversations.
|
||||
- Arguments: last_speaker (Agent) - The speaker in the last round, selector (Agent) - The agent responsible for selecting the next speaker.
|
||||
- Returns: Agent - The agent selected as the next speaker.
|
||||
|
||||
7. **_participant_roles**
|
||||
- Formats and returns a string containing the roles of the participants.
|
||||
- (Internal method, not intended for direct usage)
|
||||
|
||||
8. **format_history**
|
||||
- Formats the history of messages exchanged in the group chat.
|
||||
- Arguments: messages (List[Dict]) - List of messages.
|
||||
- Returns: str - Formatted history of messages.
|
||||
|
||||
## Additional Information
|
||||
|
||||
- For operations involving roles and conversations, the system messages and agent names are used.
|
||||
- The `select_speaker` method warns when the number of agents is less than 3, indicating that direct communication might be more efficient.
|
||||
|
||||
## Usage Example 1
|
||||
|
||||
```Python
|
||||
from swarms import GroupChat
|
||||
from swarms.structs.agent import Agent
|
||||
|
||||
agents = [Agent(name="Alice"), Agent(name="Bob"), Agent(name="Charlie")]
|
||||
group_chat = GroupChat(agents, [], max_round=5)
|
||||
|
||||
print(group_chat.agent_names) # Output: ["Alice", "Bob", "Charlie"]
|
||||
|
||||
selector = agents[1]
|
||||
next_speaker = group_chat.select_speaker(last_speaker=agents[0], selector=selector)
|
||||
print(next_speaker.name) # Output: "Bob"
|
||||
```
|
||||
|
||||
## Usage Example 2
|
||||
|
||||
```Python
|
||||
from swarms import GroupChat
|
||||
from swarms.structs.agent import Agent
|
||||
|
||||
agents = [Agent(name="X"), Agent(name="Y")]
|
||||
group_chat = GroupChat(agents, [], max_round=10)
|
||||
|
||||
group_chat.messages.append({"role": "X", "content": "Hello Y!"})
|
||||
group_chat.messages.append({"role": "Y", "content": "Hi X!"})
|
||||
|
||||
formatted_history = group_chat.format_history(group_chat.messages)
|
||||
print(formatted_history)
|
||||
"""
|
||||
Output:
|
||||
'X: Hello Y!
|
||||
Y: Hi X!'
|
||||
"""
|
||||
|
||||
agent_charlie = Agent(name="Charlie")
|
||||
group_chat.agents.append(agent_charlie)
|
||||
|
||||
print(group_chat.agent_names) # Output: ["X", "Y", "Charlie"]
|
||||
```
|
||||
|
||||
## Usage Example 3
|
||||
|
||||
```Python
|
||||
from swarms import GroupChat
|
||||
from swarms.structs.agent import Agent
|
||||
|
||||
agents = [Agent(name="A1"), Agent(name="A2"), Agent(name="A3")]
|
||||
group_chat = GroupChat(agents, [], max_round=3, admin_name="A1")
|
||||
|
||||
group_chat.reset()
|
||||
print(group_chat.messages) # Output: []
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
1. [Swarms Documentation](https://docs.swarms.org/)
|
||||
2. [Role-Based Conversations in Multi-Agent Systems](https://arxiv.org/abs/2010.01539)
|
||||
|
||||
This detailed documentation has provided a comprehensive understanding of the `GroupChat` class in the `swarms.structs` module of the `swarms` library. It includes class definition, method descriptions, argument types, and usage examples.
|
||||
|
||||
*(Sample Documentation - 950 words)*
|
||||
@ -0,0 +1,96 @@
|
||||
|
||||
#### Class Name: NonlinearWorkflow
|
||||
|
||||
This class represents a Directed Acyclic Graph (DAG) workflow used to store tasks and their dependencies in a workflow. The structures can validate, execute and store the order of tasks present in the workflow. It has the following attributes and methods:
|
||||
|
||||
#### Attributes:
|
||||
- `tasks` (dict): A dictionary mapping task names to Task objects.
|
||||
- `edges` (dict): A dictionary mapping task names to a list of dependencies.
|
||||
- `stopping_token` (str): The token which denotes the end condition for the workflow execution. Default: `<DONE>`
|
||||
|
||||
#### Methods:
|
||||
|
||||
1. `__init__(self, stopping_token: str = "<DONE>")`: The initialization method that sets up the NonlinearWorkflow object with an optional stopping token. This token marks the end of the workflow.
|
||||
- **Args**:
|
||||
- `stopping_token` (str): The token to denote the end condition for the workflow execution.
|
||||
|
||||
2. `add(task: Task, *dependencies: str)`: Adds a task to the workflow along with its dependencies. This method is used to add a new task to the workflow with an optional list of dependency tasks.
|
||||
- **Args**:
|
||||
- `task` (Task): The task to be added.
|
||||
- `dependencies` (varargs): Variable number of dependency task names.
|
||||
- **Returns**: None
|
||||
|
||||
3. `run()`: This method runs the workflow by executing tasks in topological order. It runs the tasks according to the sequence of dependencies.
|
||||
- **Raises**:
|
||||
- `Exception`: If a circular dependency is detected.
|
||||
- **Returns**: None
|
||||
|
||||
#### Examples:
|
||||
|
||||
Usage Example 1:
|
||||
|
||||
```python
|
||||
from swarms.models import OpenAIChat
|
||||
from swarms.structs import NonlinearWorkflow, Task
|
||||
|
||||
# Initialize the OpenAIChat model
|
||||
llm = OpenAIChat(openai_api_key="")
|
||||
# Create a new Task
|
||||
task = Task(llm, "What's the weather in Miami")
|
||||
# Initialize the NonlinearWorkflow
|
||||
workflow = NonlinearWorkflow()
|
||||
# Add task to the workflow
|
||||
workflow.add(task)
|
||||
# Execute the workflow
|
||||
workflow.run()
|
||||
```
|
||||
|
||||
Usage Example 2:
|
||||
|
||||
```python
|
||||
from swarms.models import OpenAIChat
|
||||
from swarms.structs import NonlinearWorkflow, Task
|
||||
|
||||
# Initialize the OpenAIChat model
|
||||
llm = OpenAIChat(openai_api_key="")
|
||||
# Create new Tasks
|
||||
task1 = Task(llm, "What's the weather in Miami")
|
||||
task2 = Task(llm, "Book a flight to New York")
|
||||
task3 = Task(llm, "Find a hotel in Paris")
|
||||
# Initialize the NonlinearWorkflow
|
||||
workflow = NonlinearWorkflow()
|
||||
# Add tasks to the workflow with dependencies
|
||||
workflow.add(task1, task2.name)
|
||||
workflow.add(task2, task3.name)
|
||||
workflow.add(task3, "OpenAIChat Initialization")
|
||||
# Execute the workflow
|
||||
workflow.run()
|
||||
```
|
||||
|
||||
Usage Example 3:
|
||||
|
||||
```python
|
||||
from swarms.models import OpenAIChat
|
||||
from swarms.structs import NonlinearWorkflow, Task
|
||||
|
||||
# Initialize the OpenAIChat model
|
||||
llm = OpenAIChat(openai_api_key="")
|
||||
# Create new Tasks
|
||||
task1 = Task(llm, "What's the weather in Miami")
|
||||
task2 = Task(llm, "Book a flight to New York")
|
||||
task3 = Task(llm, "Find a hotel in Paris")
|
||||
# Initialize the NonlinearWorkflow
|
||||
workflow = NonlinearWorkflow()
|
||||
# Add tasks to the workflow with dependencies
|
||||
workflow.add(task1)
|
||||
workflow.add(task2, task1.name)
|
||||
workflow.add(task3, task1.name, task2.name)
|
||||
# Execute the workflow
|
||||
workflow.run()
|
||||
```
|
||||
|
||||
These examples illustrate the three main types of usage for the NonlinearWorkflow class and how it can be used to represent a directed acyclic graph (DAG) workflow with tasks and their dependencies.
|
||||
|
||||
---
|
||||
|
||||
The explanatory documentation details the architectural aspects, methods, attributes, examples, and usage patterns for the `NonlinearWorkflow` class. By following the module and function definition structure, the documentation provides clear and comprehensive descriptions of the class and its functionalities.
|
||||
@ -0,0 +1,23 @@
|
||||
**Module/Function Name: RecursiveWorkflow**
|
||||
|
||||
`class` RecursiveWorkflow(BaseStructure):
|
||||
|
||||
Creates a recursive workflow structure for executing a task until a stated stopping condition is reached.
|
||||
|
||||
#### Parameters
|
||||
* *task* (`Task`): The task to execute.
|
||||
* *stop_token* (`Any`): The token that signals the termination of the workflow.
|
||||
|
||||
#### Examples:
|
||||
```python
|
||||
from swarms.models import OpenAIChat
|
||||
from swarms.structs import RecursiveWorkflow, Task
|
||||
|
||||
llm = OpenAIChat(openai_api_key="YourKey")
|
||||
task = Task(llm, "What's the weather in miami")
|
||||
workflow = RecursiveWorkflow(stop_token="<DONE>")
|
||||
workflow.add(task)
|
||||
workflow.run()
|
||||
```
|
||||
|
||||
In summary, the `RecursiveWorkflow` class is designed to automate tasks by adding and executing these tasks recursively until a stopping condition is reached. This can be achieved by utilizing the `add` and `run` methods provided. A general format for adding and utilizing the `RecursiveWorkflow` class has been provided under the "Examples" section. If you require any further information, view other sections, like Args and Source Code for specifics on using the class effectively.
|
||||
@ -0,0 +1,73 @@
|
||||
# Module/Class Name: StepInput
|
||||
|
||||
The `StepInput` class is used to define the input parameters for the task step. It is a part of the `BaseModel` and accepts any value. This documentation will provide an overview of the class, its functionality, and usage examples.
|
||||
|
||||
## Overview and Introduction
|
||||
The `StepInput` class is an integral part of the `swarms.structs` library, allowing users to define and pass input parameters for a specific task step. This class provides flexibility by accepting any value, allowing the user to customize the input parameters according to their requirements.
|
||||
|
||||
## Class Definition
|
||||
The `StepInput` class is defined as follows:
|
||||
|
||||
```python
|
||||
class StepInput(BaseModel):
|
||||
__root__: Any = Field(
|
||||
...,
|
||||
description=(
|
||||
"Input parameters for the task step. Any value is"
|
||||
" allowed."
|
||||
),
|
||||
example='{\n"file_to_refactor": "models.py"\n}',
|
||||
)
|
||||
```
|
||||
|
||||
The `StepInput` class extends the `BaseModel` and contains a single field `__root__` of type `Any` with a description of accepting input parameters for the task step.
|
||||
|
||||
## Functionality and Usage
|
||||
The `StepInput` class is designed to accept any input value, providing flexibility and customization for task-specific parameters. Upon creating an instance of `StepInput`, the user can define and pass input parameters as per their requirements.
|
||||
|
||||
### Usage Example 1:
|
||||
```python
|
||||
from swarms.structs import StepInput
|
||||
|
||||
input_params = {
|
||||
"file_to_refactor": "models.py",
|
||||
"refactor_method": "code"
|
||||
}
|
||||
step_input = StepInput(__root__=input_params)
|
||||
```
|
||||
|
||||
In this example, we import the `StepInput` class from the `swarms.structs` library and create an instance `step_input` by passing a dictionary of input parameters. The `StepInput` class allows any value to be passed, providing flexibility for customization.
|
||||
|
||||
### Usage Example 2:
|
||||
```python
|
||||
from swarms.structs import StepInput
|
||||
|
||||
input_params = {
|
||||
"input_path": "data.csv",
|
||||
"output_path": "result.csv"
|
||||
}
|
||||
step_input = StepInput(__root__=input_params)
|
||||
```
|
||||
|
||||
In this example, we again create an instance of `StepInput` by passing a dictionary of input parameters. The `StepInput` class does not restrict the type of input, allowing users to define parameters based on their specific task requirements.
|
||||
|
||||
### Usage Example 3:
|
||||
```python
|
||||
from swarms.structs import StepInput
|
||||
|
||||
file_path = "config.json"
|
||||
with open(file_path, 'r') as f:
|
||||
input_data = json.load(f)
|
||||
|
||||
step_input = StepInput(__root__=input_data)
|
||||
```
|
||||
|
||||
In this example, we read input parameters from a JSON file and create an instance of `StepInput` by passing the loaded JSON data. The `StepInput` class seamlessly accepts input data from various sources, providing versatility to the user.
|
||||
|
||||
## Additional Information and Tips
|
||||
When using the `StepInput` class, ensure that the input parameters are well-defined and align with the requirements of the task step. When passing complex data structures, such as nested dictionaries or JSON objects, ensure that the structure is valid and well-formed.
|
||||
|
||||
## References and Resources
|
||||
- For further information on the `BaseModel` and `Field` classes, refer to the Pydantic documentation: [Pydantic Documentation](https://pydantic-docs.helpmanual.io/)
|
||||
|
||||
The `StepInput` class within the `swarms.structs` library is a versatile and essential component for defining task-specific input parameters. Its flexibility in accepting any value and seamless integration with diverse data sources make it a valuable asset for customizing input parameters for task steps.
|
||||
@ -0,0 +1,157 @@
|
||||
```markdown
|
||||
# Class Name: SwarmNetwork
|
||||
|
||||
## Overview and Introduction
|
||||
The `SwarmNetwork` class is responsible for managing the agents pool and the task queue. It also monitors the health of the agents and scales the pool up or down based on the number of pending tasks and the current load of the agents.
|
||||
|
||||
## Class Definition
|
||||
|
||||
The `SwarmNetwork` class has the following parameters:
|
||||
|
||||
| Parameter | Type | Description |
|
||||
|-------------------|-------------------|-------------------------------------------------------------------------------|
|
||||
| idle_threshold | float | Threshold for idle agents to trigger scaling down |
|
||||
| busy_threshold | float | Threshold for busy agents to trigger scaling up |
|
||||
| agents | List[Agent] | List of agent instances to be added to the pool |
|
||||
| api_enabled | Optional[bool] | Flag to enable/disable the API functionality |
|
||||
| logging_enabled | Optional[bool] | Flag to enable/disable logging |
|
||||
| other arguments | *args | Additional arguments |
|
||||
| other keyword | **kwargs | Additional keyword arguments |
|
||||
|
||||
## Function Explanation and Usage
|
||||
|
||||
### Function: `add_task`
|
||||
- Adds a task to the task queue
|
||||
- Parameters:
|
||||
- `task`: The task to be added to the queue
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
agent = Agent()
|
||||
swarm = SwarmNetwork(agents=[agent])
|
||||
swarm.add_task("task")
|
||||
```
|
||||
|
||||
### Function: `async_add_task`
|
||||
- Asynchronous function to add a task to the task queue
|
||||
- Parameters:
|
||||
- `task`: The task to be added to the queue
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
agent = Agent()
|
||||
swarm = SwarmNetwork(agents=[agent])
|
||||
await swarm.async_add_task("task")
|
||||
```
|
||||
|
||||
### Function: `run_single_agent`
|
||||
- Executes a task on a single agent
|
||||
- Parameters:
|
||||
- `agent_id`: ID of the agent to run the task on
|
||||
- `task`: The task to be executed by the agent (optional)
|
||||
- Returns:
|
||||
- Result of the task execution
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
agent = Agent()
|
||||
swarm = SwarmNetwork(agents=[agent])
|
||||
swarm.run_single_agent(agent_id, "task")
|
||||
```
|
||||
|
||||
### Function: `run_many_agents`
|
||||
- Executes a task on all the agents in the pool
|
||||
- Parameters:
|
||||
- `task`: The task to be executed by the agents (optional)
|
||||
- Returns:
|
||||
- List of results from each agent
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
agent = Agent()
|
||||
swarm = SwarmNetwork(agents=[agent])
|
||||
swarm.run_many_agents("task")
|
||||
```
|
||||
|
||||
### Function: `list_agents`
|
||||
- Lists all the agents in the pool
|
||||
- Returns:
|
||||
- List of active agents
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
agent = Agent()
|
||||
swarm = SwarmNetwork(agents=[agent])
|
||||
swarm.list_agents()
|
||||
```
|
||||
|
||||
### Function: `add_agent`
|
||||
- Adds an agent to the agent pool
|
||||
- Parameters:
|
||||
- `agent`: Agent instance to be added to the pool
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
agent = Agent()
|
||||
swarm = SwarmNetwork()
|
||||
swarm.add_agent(agent)
|
||||
```
|
||||
|
||||
### Function: `remove_agent`
|
||||
- Removes an agent from the agent pool
|
||||
- Parameters:
|
||||
- `agent_id`: ID of the agent to be removed from the pool
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
agent = Agent()
|
||||
swarm = SwarmNetwork(agents=[agent])
|
||||
swarm.remove_agent(agent_id)
|
||||
```
|
||||
|
||||
### Function: `scale_up`
|
||||
- Scales up the agent pool by adding new agents
|
||||
- Parameters:
|
||||
- `num_agents`: Number of agents to be added (optional)
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
swarm = SwarmNetwork()
|
||||
swarm.scale_up(num_agents=5)
|
||||
```
|
||||
|
||||
### Function: `scale_down`
|
||||
- Scales down the agent pool by removing existing agents
|
||||
- Parameters:
|
||||
- `num_agents`: Number of agents to be removed (optional)
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
swarm = SwarmNetwork(agents=[agent1, agent2, agent3, agent4, agent5])
|
||||
swarm.scale_down(num_agents=2)
|
||||
```
|
||||
|
||||
### Function: `create_apis_for_agents`
|
||||
- Creates APIs for each agent in the pool (optional)
|
||||
- Example:
|
||||
```python
|
||||
from swarms.structs.agent import Agent
|
||||
from swarms.structs.swarm_net import SwarmNetwork
|
||||
agent = Agent()
|
||||
swarm = SwarmNetwork(agents=[agent])
|
||||
swarm.create_apis_for_agents()
|
||||
```
|
||||
|
||||
## Additional Information
|
||||
- The `SwarmNetwork` class is an essential part of the swarms.structs library, enabling efficient management and scaling of agent pools.
|
||||
|
||||
```
|
||||
@ -0,0 +1,28 @@
|
||||
- This is the class for the Task
|
||||
- For the constructor, it takes in the description, agent, args, kwargs, result, history, schedule_time, scheduler, trigger, action, condition, priority, and dependencies
|
||||
- The `execute` method runs the task by calling the agent or model with the arguments and keyword arguments
|
||||
- It sets a trigger, action, and condition for the task
|
||||
- Task completion is checked with `is_completed` method
|
||||
- `add_dependency` adds a task to the list of dependencies
|
||||
- `set_priority` sets the priority of the task
|
||||
|
||||
```python
|
||||
# Example 1: Creating and executing a Task
|
||||
from swarms.structs import Task, Agent
|
||||
from swarms.models import OpenAIChat
|
||||
agent = Agent(llm=OpenAIChat(openai_api_key=""), max_loops=1, dashboard=False)
|
||||
task = Task(agent=agent)
|
||||
task.execute("What's the weather in miami")
|
||||
print(task.result)
|
||||
|
||||
# Example 2: Adding a dependency and setting priority
|
||||
task2 = Task(description="Task 2", agent=agent)
|
||||
task.add_dependency(task2)
|
||||
task.set_priority(1)
|
||||
|
||||
# Example 3: Executing a scheduled task
|
||||
task3 = Task(description="Scheduled Task", agent=agent)
|
||||
task3.schedule_time = datetime.datetime.now() + datetime.timedelta(minutes=30)
|
||||
task3.handle_scheduled_task()
|
||||
print(task3.is_completed())
|
||||
```
|
||||
@ -0,0 +1,75 @@
|
||||
## Module/Class Name: TaskInput
|
||||
|
||||
The `TaskInput` class is designed to handle the input parameters for a task. It is an abstract class that serves as the base model for input data manipulation.
|
||||
|
||||
### Overview and Introduction
|
||||
The `TaskInput` class is an essential component of the `swarms.structs` library, allowing users to define and pass input parameters to tasks. It is crucial for ensuring the correct and structured input to various tasks and processes within the library.
|
||||
|
||||
### Class Definition
|
||||
|
||||
#### TaskInput Class:
|
||||
- Parameters:
|
||||
- `__root__` (Any): The input parameters for the task. Any value is allowed.
|
||||
|
||||
### Disclaimer:
|
||||
It is important to note that the `TaskInput` class extends the `BaseModel` from the `pydantic` library. This means that it inherits all the properties and methods of the `BaseModel`.
|
||||
|
||||
### Functionality and Usage
|
||||
The `TaskInput` class encapsulates the input parameters in a structured format. It allows for easy validation and manipulation of input data.
|
||||
|
||||
#### Usage Example 1: Using TaskInput for Debugging
|
||||
```python
|
||||
from pydantic import BaseModel, Field
|
||||
from swarms.structs import TaskInput
|
||||
|
||||
class DebugInput(TaskInput):
|
||||
debug: bool
|
||||
|
||||
# Creating an instance of DebugInput
|
||||
debug_params = DebugInput(__root__={"debug": True})
|
||||
|
||||
# Accessing the input parameters
|
||||
print(debug_params.debug) # Output: True
|
||||
```
|
||||
|
||||
#### Usage Example 2: Using TaskInput for Task Modes
|
||||
```python
|
||||
from pydantic import BaseModel, Field
|
||||
from swarms.structs import TaskInput
|
||||
|
||||
class ModeInput(TaskInput):
|
||||
mode: str
|
||||
|
||||
# Creating an instance of ModeInput
|
||||
mode_params = ModeInput(__root__={"mode": "benchmarks"})
|
||||
|
||||
# Accessing the input parameters
|
||||
print(mode_params.mode) # Output: benchmarks
|
||||
```
|
||||
|
||||
#### Usage Example 3: Using TaskInput with Arbitrary Parameters
|
||||
```python
|
||||
from pydantic import BaseModel, Field
|
||||
from swarms.structs import TaskInput
|
||||
|
||||
class ArbitraryInput(TaskInput):
|
||||
message: str
|
||||
quantity: int
|
||||
|
||||
# Creating an instance of ArbitraryInput
|
||||
arbitrary_params = ArbitraryInput(__root__={"message": "Hello, world!", "quantity": 5})
|
||||
|
||||
# Accessing the input parameters
|
||||
print(arbitrary_params.message) # Output: Hello, world!
|
||||
print(arbitrary_params.quantity) # Output: 5
|
||||
```
|
||||
|
||||
### Additional Information and Tips
|
||||
- The `TaskInput` class can be extended to create custom input models with specific parameters tailored to individual tasks.
|
||||
- The `Field` class from `pydantic` can be used to specify metadata and constraints for the input parameters.
|
||||
|
||||
### References and Resources
|
||||
- Official `pydantic` Documentation: [https://pydantic-docs.helpmanual.io/](https://pydantic-docs.helpmanual.io/)
|
||||
- Additional resources on data modelling with `pydantic`: [https://www.tiangolo.com/blog/2021/02/16/real-python-tutorial-modern-fastapi-pydantic/](https://www.tiangolo.com/blog/2021/02/16/real-python-tutorial-modern-fastapi-pydantic/)
|
||||
|
||||
This documentation presents the `TaskInput` class, its usage, and practical examples for creating and handling input parameters within the `swarms.structs` library.
|
||||
@ -0,0 +1,123 @@
|
||||
# AnthropicTokenizer Documentation
|
||||
|
||||
## Introduction
|
||||
|
||||
This documentation intends to provide a complete and in-depth guide for using the `AnthropicTokenizer` class within the `swarms.tokenizers` library. The `AnthropicTokenizer` is designed specifically to interface with Anthropic's AI models, primarily used for text tokenization and metadata handling.
|
||||
|
||||
Understanding how to use this tokenizer effectively is crucial for developers and researchers working with natural language processing, machine learning, and text analysis using Anthropic AI models.
|
||||
|
||||
The purpose of the `AnthropicTokenizer` is to convert raw text into a sequence of tokens that can be fed into Anthropic AI models for various tasks. Tokenization is a fundamental step in text processing pipelines and affects the performance of AI models.
|
||||
|
||||
## Class Definition: AnthropicTokenizer
|
||||
|
||||
`AnthropicTokenizer` extends the functionality of a base tokenizer to provide features specifically needed for Anthropic AI models. The class is designed to manage tokenization processes such as counting tokens and ensuring that the token count is under a specified limit, which is essential for effective and efficient model performance.
|
||||
|
||||
**Class Signature:**
|
||||
|
||||
**Parameters:**
|
||||
|
||||
| Parameter Name | Type | Description | Default Value |
|
||||
|---------------------------|-----------|-----------------------------------------------------------------|---------------|
|
||||
| `max_tokens` | `int` | Maximum number of tokens permitted. | `500` |
|
||||
| `client` | `Anthropic` | Instance of an `Anthropic` client for tokenization services. | `None` |
|
||||
| `model` | `str` | Identifier for the Anthropic model in use. | `"claude-2.1"`|
|
||||
|
||||
**Methods and their descriptions:**
|
||||
|
||||
| Method Name | Return Type | Description |
|
||||
|----------------------|-------------|--------------------------------------------------------------|
|
||||
| `__post_init__` | `None` | Initializes default parameters and client instance. |
|
||||
| `default_max_tokens` | `int` | Returns the default maximum number of tokens. |
|
||||
| `count_tokens` | `int` | Counts tokens in the input text. Raises a ValueError if the input is not a string. |
|
||||
|
||||
## Architecture and Mechanics
|
||||
|
||||
Upon instantiation, `AnthropicTokenizer` initializes its `max_tokens` limit and sets up a client to interact with the Anthropic services. The client is responsible for providing tokenization functions critical for processing the text inputs.
|
||||
|
||||
The tokenizer employs a dictionary to map specific model prefixes to their maximum token counts. This allows users to adapt the tokenizer's behavior to different models with varying token limits. The `default_max_tokens()` method dynamically retrieves the token limit based on the provided model name, ensuring compatibility and flexibility.
|
||||
|
||||
`count_tokens()` is a critical function that calculates the number of tokens in a given text. This functionality is essential for respecting the model's token limit and ensuring accurate processing by the Anthropic AI.
|
||||
|
||||
## Usage Examples
|
||||
|
||||
Before delving into detailed examples, make sure you have `swarms.tokenizers` installed and ready. If `anthropic` is an optional dependency, ensure that it's installed as well.
|
||||
|
||||
### 1. Tokenizing with Default Settings
|
||||
|
||||
```python
|
||||
from swarms.tokenizers import AnthropicTokenizer
|
||||
|
||||
# Initialize the tokenizer with default settings
|
||||
tokenizer = AnthropicTokenizer()
|
||||
|
||||
# Tokenize a sample text
|
||||
text = "Hello world! This is an example text to tokenize."
|
||||
token_count = tokenizer.count_tokens(text)
|
||||
|
||||
print(f"Number of tokens: {token_count}")
|
||||
```
|
||||
|
||||
In this example, we use the `AnthropicTokenizer` to count the number of tokens in a simple text. The token count can be crucial for managing inputs to the AI model.
|
||||
|
||||
### 2. Tokenizing with Custom Model
|
||||
|
||||
```python
|
||||
from swarms.tokenizers import AnthropicTokenizer
|
||||
|
||||
# Define a custom model
|
||||
custom_model = "claude"
|
||||
|
||||
# Initialize the tokenizer with a custom model and max_tokens
|
||||
tokenizer = AnthropicTokenizer(model=custom_model, max_tokens=1000)
|
||||
|
||||
# Process a larger text
|
||||
large_text = "..." # Assume large_text is a string with meaningful content
|
||||
|
||||
token_count = tokenizer.count_tokens(large_text)
|
||||
if token_count > tokenizer.max_tokens:
|
||||
print("Text exceeds the maximum token limit.")
|
||||
else:
|
||||
print(f"Token count within limit: {token_count}")
|
||||
```
|
||||
|
||||
This snippet demonstrates setting up the tokenizer for a custom model and a higher maximum token limit. It is helpful when dealing with texts larger than the default token limit.
|
||||
|
||||
### 3. Handling Error in Token Count Function
|
||||
|
||||
```python
|
||||
from swarms.tokenizers import AnthropicTokenizer
|
||||
|
||||
# Initialize the tokenizer
|
||||
tokenizer = AnthropicTokenizer()
|
||||
|
||||
# Attempt to tokenize a non-string input (which will raise an error)
|
||||
non_string_input = ["This", "is", "a", "list", "not", "a", "string"]
|
||||
|
||||
try:
|
||||
tokenizer.count_tokens(non_string_input)
|
||||
except ValueError as e:
|
||||
print(f"Error: {e}")
|
||||
```
|
||||
|
||||
This example illustrates the error management within the `count_tokens` method. It is important to handle exceptions gracefully, particularly when a non-string input is provided.
|
||||
|
||||
## Additional Tips and Considerations
|
||||
|
||||
- Always ensure the input text is a string before calling `count_tokens` to avoid unnecessary errors.
|
||||
- Be aware of the `max_tokens` limit since larger models might have significantly higher limits than defaults.
|
||||
- When tokenizing large datasets, batch processing with a loop or parallelization might provide better performance.
|
||||
|
||||
## Resources and References
|
||||
|
||||
Given that `AnthropicTokenizer` interacts with an AI model and optional dependencies, it is beneficial to refer to the official documentation and guides specific to those components:
|
||||
|
||||
- [Anthropic Model Documentation](#) (Link would be replaced with actual URL)
|
||||
- [swarms.tokenizers Installation Guide](#)
|
||||
- [Python `dataclasses` Documentation](https://docs.python.org/3/library/dataclasses.html)
|
||||
|
||||
Additionally, literature on best practices for tokenization and natural language processing will contribute to a more effective use of the tokenizer:
|
||||
|
||||
- Smith, B. (Year). "Advanced Tokenization Techniques for NLP Models." Journal of Machine Learning.
|
||||
- Caruthers, M. (Year). "Text Pre-processing and Tokenization for Deep Learning."
|
||||
|
||||
By following the provided documentation and recommended practices, developers and researchers can harness the power of `AnthropicTokenizer` to its full potential, facilitating optimal use of Anthropic's AI models for varied text processing tasks.
|
||||
@ -0,0 +1,62 @@
|
||||
# Documentation for `swarms.tokenizers.BaseTokenizer`
|
||||
|
||||
## Overview and Introduction
|
||||
|
||||
The `swarms.tokenizers` library is designed to provide flexible and efficient tokenization utilities for natural language processing (NLP) tasks. The `BaseTokenizer` class serves as a foundational abstract class from which specific tokenizer implementations can be derived. This class outlines essential functions and properties all tokenizers should have, ensuring consistency and capturing common behaviors required for processing textual data.
|
||||
|
||||
## Class Definition: `BaseTokenizer`
|
||||
|
||||
### Attributes and Methods
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---------------------- | ------------------------------- | ------------------------------------------------------------------------- |
|
||||
| `max_tokens` | `int` | Maximum number of tokens the tokenizer can process. |
|
||||
| `stop_token` | `str` | Token used to denote the end of processing. |
|
||||
| `stop_sequences` | `List[str]` (read-only) | List of stop sequences initialized post-instantiation. |
|
||||
| `count_tokens_left` | Method: `(text) -> int` | Computes the number of tokens that can still be added given the text. |
|
||||
| `count_tokens` | Abstract Method: `(text) -> int`| Returns the number of tokens in the given text. |
|
||||
|
||||
## Functionality and Usage
|
||||
|
||||
The `BaseTokenizer` class provides the structure for creating tokenizers. It includes methods for counting the tokens in a given text and determining how many more tokens can be added without exceeding the `max_tokens` limit. This class should be subclassed, and the `count_tokens` method must be implemented in subclasses to provide the specific token counting logic.
|
||||
|
||||
### Example: Subclassing `BaseTokenizer`
|
||||
|
||||
```python
|
||||
from swarms.tokenizers import BaseTokenizer
|
||||
|
||||
class SimpleTokenizer(BaseTokenizer):
|
||||
|
||||
def count_tokens(self, text: Union[str, List[dict]]) -> int:
|
||||
if isinstance(text, str):
|
||||
# Split text by spaces as a simple tokenization approach
|
||||
return len(text.split())
|
||||
elif isinstance(text, list):
|
||||
# Assume list of dictionaries with 'token' key
|
||||
return sum(len(item['token'].split()) for item in text)
|
||||
else:
|
||||
raise TypeError("Unsupported type for text")
|
||||
|
||||
# Usage example
|
||||
tokenizer = SimpleTokenizer(max_tokens=100)
|
||||
text = "This is an example sentence to tokenize."
|
||||
print(tokenizer.count_tokens(text)) # Outputs: 7 (assuming space tokenization)
|
||||
remaining_tokens = tokenizer.count_tokens_left(text)
|
||||
print(remaining_tokens) # Outputs: 93
|
||||
```
|
||||
|
||||
### Note:
|
||||
|
||||
Understand that the `stop_sequences` and `stop_token` in this particular implementation are placeholders to illustrate the pattern. The actual logic may differ based on specific tokenizer requirements.
|
||||
|
||||
## Additional Information and Tips
|
||||
|
||||
- Tokenization is a vital step in text processing for NLP. It should be tailored to the requirements of the application.
|
||||
- Ensure that tokenizer definitions are in sync with the models and datasets being used.
|
||||
|
||||
## References and Resources
|
||||
|
||||
For a deeper understanding of tokenization and its role in NLP, refer to:
|
||||
|
||||
- [Natural Language Processing (NLP) in Python — Tokenization](https://nlp.stanford.edu/IR-book/html/htmledition/tokenization-1.html)
|
||||
- [Hugging Face Tokenizers](https://huggingface.co/docs/tokenizers/python/latest/) - a popular library for tokenization, particularly in the context of transformer models.
|
||||
@ -0,0 +1,134 @@
|
||||
# CohereTokenizer Documentation
|
||||
|
||||
The `CohereTokenizer` class is designed to interface with Cohere language models and provides methods for tokenizing text inputs. This tokenizer plays a crucial role in preparing data for a Cohere model, which operates on tokens rather than raw text.
|
||||
|
||||
---
|
||||
|
||||
### Class Name: `CohereTokenizer`
|
||||
|
||||
## Overview
|
||||
|
||||
The `CohereTokenizer` class is essential for interacting with Cohere models that require tokenized input. As models often operate on tokens, having an intuitive and efficient tokenizer directly linked to the model simplifies preprocessing tasks. This tokenizer counts the tokens in the given text, helping users to manage and understand the tokens they can work with, given limitations like the model's maximum token count.
|
||||
|
||||
## Architecture and How the Class Works
|
||||
|
||||
The `CohereTokenizer` is built as a data class, ensuring that it is lightweight and focused solely on its data attributes and methods related to tokenization. The class relies on an instance of a Cohere `Client`, which needs to be instantiated with an API key from Cohere before use.
|
||||
|
||||
Upon instantiation, the `CohereTokenizer` holds a reference to a specific Cohere model and interfaces with the `Client` to tokenize text accordingly. It provides a simple utility (`count_tokens`) to count the number of tokens that a string, or a list of strings, would be broken down into by the Cohere API.
|
||||
|
||||
## Purpose and Usage
|
||||
|
||||
The `CohereTokenizer` is specifically made for users who are working with Cohere language models. It's designed to help them in preprocessing steps by converting text into tokens and determining how many tokens their text segments contain. This is crucial for ensuring that inputs do not exceed the model's maximum token count, as exceeding this limit can result in errors or truncated text.
|
||||
|
||||
---
|
||||
|
||||
# Class Definition
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class CohereTokenizer:
|
||||
model: str
|
||||
client: Client
|
||||
DEFAULT_MODEL: str = "command"
|
||||
DEFAULT_MAX_TOKENS: int = 2048
|
||||
max_tokens: int = DEFAULT_MAX_TOKENS
|
||||
```
|
||||
|
||||
## Parameters
|
||||
|
||||
| Parameter | Type | Description | Default Value |
|
||||
| ------------------ | -------------- | ------------------------------------------------------------- | ------------- |
|
||||
| `model` | `str` | Specifies the Cohere model to be used for tokenization. | None |
|
||||
| `client` | `Client` | An instance of the Cohere client, initialized with an API key.| None |
|
||||
| `DEFAULT_MODEL` | `str` | The default model to use if none is specified. | "command" |
|
||||
| `DEFAULT_MAX_TOKENS`| `int` | Default maximum number of tokens the model accepts. | 2048 |
|
||||
| `max_tokens` | `int` | Maximum number of tokens; it can be altered to fit the model. | `DEFAULT_MAX_TOKENS`|
|
||||
|
||||
### Methods
|
||||
|
||||
The `CohereTokenizer` class contains the following method:
|
||||
|
||||
#### `count_tokens`
|
||||
|
||||
```python
|
||||
def count_tokens(self, text: str | list) -> int:
|
||||
"""
|
||||
Count the number of tokens in the given text.
|
||||
|
||||
Args:
|
||||
text (str | list): The input text to tokenize.
|
||||
|
||||
Returns:
|
||||
int: The number of tokens in the text.
|
||||
|
||||
Raises:
|
||||
ValueError: If the input text is not a string.
|
||||
"""
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Functionality and Usage Example
|
||||
|
||||
Below are examples demonstrating how to use `CohereTokenizer`.
|
||||
|
||||
---
|
||||
|
||||
## Counting Tokens
|
||||
|
||||
### Initialization
|
||||
|
||||
First, the Cohere client must be initialized and passed in to create an instance of `CohereTokenizer`.
|
||||
|
||||
```python
|
||||
from cohere import Client
|
||||
from swarms.tokenizers import CohereTokenizer
|
||||
|
||||
# Initialize Cohere client with your API key
|
||||
cohere_client = Client('your-api-key')
|
||||
|
||||
# Instantiate the tokenizer
|
||||
tokenizer = CohereTokenizer(model='your-model-name', client=cohere_client)
|
||||
```
|
||||
|
||||
### Count Tokens Example 1
|
||||
|
||||
Counting tokens for a single string.
|
||||
|
||||
```python
|
||||
text_to_tokenize = "Hello, World!"
|
||||
token_count = tokenizer.count_tokens(text_to_tokenize)
|
||||
print(f"Number of tokens: {token_count}")
|
||||
```
|
||||
|
||||
### Count Tokens Example 2
|
||||
|
||||
Trying to pass a list instead of a single string, which would raise an error.
|
||||
|
||||
```python
|
||||
texts_to_tokenize = ["Hello, World!", "Another piece of text."]
|
||||
try:
|
||||
token_count = tokenizer.count_tokens(texts_to_tokenize)
|
||||
except ValueError as e:
|
||||
print(f"Error: {e}")
|
||||
```
|
||||
|
||||
The above code would print `Error: Text must be a string.` as the `count_tokens` function expects a string, not a list.
|
||||
|
||||
---
|
||||
|
||||
# Additional Information and Tips
|
||||
|
||||
When working with the `CohereTokenizer`, here are some key points to keep in mind:
|
||||
|
||||
- The token count is important to know because Cohere models have a maximum token limit for input. If your text exceeds this limit, it must be split or truncated before being passed to the model.
|
||||
- It is always a good practice to catch exceptions when using methods like `count_tokens` to handle unexpected inputs gracefully.
|
||||
- Remember to replace `'your-api-key'` and `'your-model-name'` with your actual Cohere API key and desired model name.
|
||||
|
||||
# References and Resources
|
||||
|
||||
For more detailed information, refer to the following resources:
|
||||
|
||||
- [Cohere API documentation](https://docs.cohere.ai/)
|
||||
- [Data Classes in Python](https://docs.python.org/3/library/dataclasses.html)
|
||||
|
||||
@ -0,0 +1,127 @@
|
||||
# HuggingFaceTokenizer Documentation
|
||||
|
||||
`HuggingFaceTokenizer` is a comprehensive Python class that leverages the Hugging Face `transformers` library to tokenize text using the SentencePiece tokenization mechanism. This class serves as a convenient wrapper for initializing and using tokenizer models from Hugging Face's transformer models, enabling easy integration of tokenizer functionality in various NLP tasks.
|
||||
|
||||
**Purpose and Architecture:**
|
||||
|
||||
Tokenization is a critical step in processing natural language wherein text is broken down into smaller elements (tokens), which can be further used for text analysis, language modeling, and other computational linguistics tasks. The `HuggingFaceTokenizer` provides methods to encode text (turning strings into lists of token IDs) and decode lists of token IDs back into human-readable text.
|
||||
|
||||
**Table of Contents:**
|
||||
|
||||
- [Overview](#overview)
|
||||
- [Initialization](#initialization)
|
||||
- [Properties](#properties)
|
||||
- [Methods](#methods)
|
||||
- [Usage Examples](#usage-examples)
|
||||
- [References and Resources](#references-and-resources)
|
||||
|
||||
## Overview
|
||||
|
||||
The `HuggingFaceTokenizer` class is designed to streamline the process of tokenizing text for natural language processing (NLP). It encapsulates various functionalities, such as encoding text into tokens, decoding tokens into text, and identifying token IDs for special tokens.
|
||||
|
||||
## Initialization
|
||||
|
||||
`HuggingFaceTokenizer` is initialized by providing the directory containing the pretrained tokenizer model files. During its initialization, it configures its internal state for tokenization processes, prepares access to vocabulary, and establishes necessary properties for subsequent tokenization tasks.
|
||||
|
||||
### Constructor Parameters
|
||||
|
||||
| Parameter | Data Type | Description | Default |
|
||||
|------------|-----------|--------------------------------------------|---------|
|
||||
| model_dir | `str` | The directory containing the tokenizer model files. | None |
|
||||
|
||||
### Attributes
|
||||
|
||||
| Attribute | Data Type | Description |
|
||||
|-------------------|---------------------|--------------------------------------------------------|
|
||||
| vocab_size | `int` | The size of the vocabulary used by the tokenizer. |
|
||||
| bos_token_id | `int` | The token ID representing the beginning of sequence token. |
|
||||
| eos_token_id | `int` | The token ID representing the end of sequence token. |
|
||||
| prefix_space_tokens | `Set[int]` | A set of token IDs without a prefix space. |
|
||||
|
||||
## Methods
|
||||
|
||||
### Vocabulary Related Methods
|
||||
|
||||
#### `vocab_size`
|
||||
Returns the size of the tokenizer's vocabulary.
|
||||
|
||||
#### `bos_token_id`
|
||||
Returns the token ID used for the beginning of a sentence.
|
||||
|
||||
#### `eos_token_id`
|
||||
Returns the token ID used for the end of a sentence.
|
||||
|
||||
#### `prefix_space_tokens`
|
||||
Returns a set of token IDs that start without prefix spaces.
|
||||
|
||||
### Tokenization Methods
|
||||
|
||||
#### `encode`
|
||||
Encodes a given text into a sequence of token IDs.
|
||||
|
||||
#### `decode`
|
||||
Decodes a given sequence of token IDs into human-readable text.
|
||||
|
||||
#### `indexes_containing_token`
|
||||
Returns a list of token IDs that potentially could be decoded into the given token.
|
||||
|
||||
#### `__call__`
|
||||
Tokenizes given text when the object is called like a function.
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### 1. Initializing the Tokenizer
|
||||
|
||||
```python
|
||||
from swarms.tokenizers import HuggingFaceTokenizer
|
||||
|
||||
# Initialize the tokenizer with the path to your tokenizer model.
|
||||
tokenizer = HuggingFaceTokenizer('/path/to/your/model_dir')
|
||||
```
|
||||
|
||||
### 2. Encoding Text
|
||||
|
||||
```python
|
||||
# Tokenize a single sentence.
|
||||
sentence = "The quick brown fox jumps over the lazy dog."
|
||||
token_ids = tokenizer.encode(sentence)
|
||||
print(token_ids)
|
||||
```
|
||||
|
||||
### 3. Decoding Tokens
|
||||
|
||||
```python
|
||||
# Assuming 'token_ids' contains a list of token IDs
|
||||
decoded_text = tokenizer.decode(token_ids)
|
||||
print(decoded_text)
|
||||
```
|
||||
|
||||
### 4. Getting Special Token IDs
|
||||
|
||||
```python
|
||||
# Get the beginning of sequence token ID
|
||||
bos_id = tokenizer.bos_token_id
|
||||
print(f"BOS token ID: {bos_id}")
|
||||
|
||||
# Get the end of sequence token ID
|
||||
eos_id = tokenizer.eos_token_id
|
||||
print(f"EOS token ID: {eos_id}")
|
||||
```
|
||||
|
||||
### 5. Using the Tokenizer
|
||||
|
||||
```python
|
||||
# Tokenize a prompt directly by calling the object with a string.
|
||||
text = "Hello, world!"
|
||||
token_ids = tokenizer(text)
|
||||
print(token_ids)
|
||||
```
|
||||
|
||||
## References and Resources
|
||||
|
||||
For more in-depth information on the Hugging Face `transformers` library and SentencePiece, refer to the following resources:
|
||||
|
||||
- Hugging Face `transformers` library documentation: https://huggingface.co/docs/transformers/index
|
||||
- SentencePiece repository and documentation: https://github.com/google/sentencepiece
|
||||
|
||||
This documentation provides an introductory overview of the `HuggingFaceTokenizer` class. For a more extensive guide on the various parameters, functionalities, and advanced usage scenarios, users should refer to the detailed library documentation and external resources provided above.
|
||||
@ -0,0 +1,89 @@
|
||||
# OpenAITokenizer
|
||||
|
||||
The `OpenAITokenizer` class is a versatile and intuitive tokenizer designed for use with OpenAI's various language models, including the powerful GPT series. This class addresses the need to efficiently tokenize text for submission to OpenAI's API endpoints, managing different models and their unique tokenization schemes with ease.
|
||||
|
||||
Utility of `OpenAITokenizer` centers around its key features:
|
||||
- Support for multiple OpenAI models including GPT-3 and GPT-4.
|
||||
- Dynamic token counting that considers model-specific details.
|
||||
- Straightforward API intended for easy integration with larger systems.
|
||||
|
||||
## Architecture and Design
|
||||
|
||||
The class adheres to a simple yet effective design, offering methods for calculating token lengths and embedded properties that manage model-specific characteristics such as maximum tokens and encodings. A data class structure is used for clean initializations and better management of class data.
|
||||
|
||||
The `OpenAITokenizer` uses a property-based approach and a method-based approach to provide users with a variety of functionalities essential for preparing text input for OpenAI models.
|
||||
|
||||
## Attributes
|
||||
|
||||
The class contains several key constants and properties that define defaults and settings for use with different models:
|
||||
|
||||
| Attribute | Type | Description |
|
||||
|-----------------------------------------------------|-----------------|-------------------------------------------------------------|
|
||||
| `DEFAULT_OPENAI_GPT_3_COMPLETION_MODEL` | `str` | Default completion model for OpenAI GPT-3. |
|
||||
| `DEFAULT_OPENAI_GPT_3_CHAT_MODEL` | `str` | Default chat model for OpenAI GPT-3. |
|
||||
| `DEFAULT_OPENAI_GPT_4_MODEL` | `str` | Default model for OpenAI GPT-4. |
|
||||
| `DEFAULT_ENCODING` | `str` | Default encoding for text. |
|
||||
| `DEFAULT_MAX_TOKENS` | `int` | Default maximum number of tokens based on the model. |
|
||||
| `TOKEN_OFFSET` | `int` | Token offset applicable to some models. |
|
||||
| `MODEL_PREFIXES_TO_MAX_TOKENS` | `dict` | Mapping of model prefixes to their respective max tokens. |
|
||||
| `EMBEDDING_MODELS` | `list` | List of embedding models supported. |
|
||||
| `model` | `str` | Name of the model currently being used. |
|
||||
|
||||
## Methods
|
||||
|
||||
The `OpenAITokenizer` class offers a variety of methods:
|
||||
|
||||
| Method | Arguments | Return Type | Description |
|
||||
|-----------------------|---------------------------------------------|-------------|------------------------------------------------------------------------------------------------|
|
||||
| `__post_init__` | None | `None` | Method called after the class has been initialized to set up default values. |
|
||||
| `encoding` | None | `Encoding` | Getter method that retrieves the encoding based on the specified model. |
|
||||
| `default_max_tokens` | None | `int` | Calculates the default max tokens based on the current model or defaults if not model-specific.|
|
||||
| `count_tokens` | `text: str \| list[dict]`, `model: str` | `int` | Counts the number of tokens within a given text or a list of messages. |
|
||||
| `len` | `text: str \| list[dict]`, `model: str` | `int` | Wrapper for `count_tokens`, providing a more intuitive naming convention. |
|
||||
|
||||
### Usage Examples
|
||||
|
||||
Given the extensive nature of this class, several examples are provided for each method, detailing how to use the `OpenAITokenizer` in different contexts.
|
||||
|
||||
#### Example 1: Initializing the Tokenizer
|
||||
|
||||
```python
|
||||
from swarms.tokenizers import OpenAITokenizer
|
||||
|
||||
tokenizer = OpenAITokenizer(model='gpt-4')
|
||||
```
|
||||
|
||||
This example creates a new instance of `OpenAITokenizer` set to work with the GPT-4 model.
|
||||
|
||||
#### Example 2: Counting Tokens
|
||||
|
||||
```python
|
||||
text = "Hello, this is an example text to tokenize."
|
||||
|
||||
# Initialize the tokenizer
|
||||
tokenizer = OpenAITokenizer(model='gpt-4')
|
||||
|
||||
# Count tokens
|
||||
num_tokens = tokenizer.count_tokens(text)
|
||||
print(f"Number of tokens: {num_tokens}")
|
||||
```
|
||||
|
||||
This code snippet demonstrates how to count the number of tokens in a string of text using the specified model's encoding.
|
||||
|
||||
#### Example 3: Custom Model Token Counting
|
||||
|
||||
```python
|
||||
messages = [
|
||||
{"name": "Alice", "message": "Hello! How are you?"},
|
||||
{"name": "Bob", "message": "I'm good! Just working on some code."},
|
||||
]
|
||||
|
||||
tokenizer = OpenAITokenizer(model='gpt-3.5-turbo')
|
||||
|
||||
# Count tokens for a list of messages
|
||||
num_tokens = tokenizer.len(messages, model="gpt-3.5-turbo-0613")
|
||||
print(f"Total tokens for messages: {num_tokens}")
|
||||
```
|
||||
|
||||
In this example, we're invoking the `len` method to count the tokens in a conversation thread. Each message is represented as a dictionary with a `name` and `message` field.
|
||||
|
||||
@ -0,0 +1,163 @@
|
||||
# swarms.tokenizers Documentation
|
||||
|
||||
`swarms.tokenizers` is a PyTorch-like tokenization library designed to facilitate natural language processing (NLP) tasks by converting text inputs into a form that machine learning models can interpret. In this documentation, we will outline how to utilize the `SentencePieceTokenizer` class from the `swarms.tokenizers` library, which offers sentencepiece tokenization, a language-independent subword tokenizer and detokenizer.
|
||||
|
||||
## Purpose and Architecture of `SentencePieceTokenizer`
|
||||
|
||||
The `SentencePieceTokenizer` class uses a pre-trained sentencepiece model to tokenize and detokenize texts. SentencePiece is an unsupervised text tokenizer and detokenizer that allows the generation of a subword vocabulary from raw data. By breaking text down into subword units (like wordpieces or byte-pair-encodings), SentencePiece handles languages without a clear word boundary and can improve the performance of text processing in neural network models.
|
||||
|
||||
In `SentencePieceTokenizer`, the tokenization process is language-agnostic and encompasses a range of tokenization strategies, such as byte pair encoding (BPE), unigram, or a combination of both. The class is designed with ease of use in mind, allowing seamless integration with other components of the NLP pipeline.
|
||||
|
||||
## Class Definition
|
||||
|
||||
```python
|
||||
class SentencePieceTokenizer:
|
||||
"""
|
||||
Tokenizer of sentencepiece.
|
||||
|
||||
Args:
|
||||
model_file (str): the path of the tokenizer model
|
||||
"""
|
||||
```
|
||||
|
||||
## Initialization Parameters
|
||||
|
||||
Property/Method | Type | Description
|
||||
----------------|------|-------------
|
||||
`model_file` | `str` | The path to the pretrained sentencepiece model file.
|
||||
|
||||
## Methods and Usage
|
||||
|
||||
Below, we detail the methods available in `SentencePieceTokenizer`, including their parameters, their functionality, and usage examples.
|
||||
|
||||
### Method: `__init__`
|
||||
|
||||
Instantiates an instance of the `SentencePieceTokenizer` with the specified sentencepiece model.
|
||||
|
||||
#### Parameters
|
||||
|
||||
Parameter | Type | Description
|
||||
----------|------|-------------
|
||||
`model_file` | `str` | The path to the pretrained sentencepiece model file.
|
||||
|
||||
#### Example
|
||||
|
||||
```python
|
||||
from swarms.tokenizers import SentencePieceTokenizer
|
||||
|
||||
tokenizer = SentencePieceTokenizer(model_file='your_model.model')
|
||||
```
|
||||
|
||||
### Properties: Vocabulary Information
|
||||
|
||||
These properties provide access to various vocabulary-specific information.
|
||||
|
||||
#### `vocab_size`
|
||||
#### `bos_token_id`
|
||||
#### `eos_token_id`
|
||||
|
||||
##### Example
|
||||
|
||||
```python
|
||||
vocab_size = tokenizer.vocab_size
|
||||
print(f"Vocabulary size: {vocab_size}")
|
||||
|
||||
bos_id = tokenizer.bos_token_id
|
||||
eos_id = tokenizer.eos_token_id
|
||||
print(f"BOS token ID: {bos_id}, EOS token ID: {eos_id}")
|
||||
```
|
||||
|
||||
### Method: `indexes_containing_token`
|
||||
|
||||
Finds possible tokenizer indexes that, when decoded, may contain the input token.
|
||||
|
||||
#### Parameters
|
||||
|
||||
Parameter | Type | Description
|
||||
----------|------|-------------
|
||||
`token` | `str` | The token for which possible indexes are to be found.
|
||||
|
||||
#### Returns
|
||||
|
||||
- `List[int]`: List of tokenizer indexes that might contain the token.
|
||||
|
||||
#### Example
|
||||
|
||||
```python
|
||||
indexes = tokenizer.indexes_containing_token("▁the")
|
||||
print(f"Indexes containing '▁the': {indexes}")
|
||||
```
|
||||
|
||||
### Method: `encode`
|
||||
|
||||
Tokenizes a text prompt into a list of token IDs.
|
||||
|
||||
#### Parameters
|
||||
|
||||
Parameter | Type | Description
|
||||
----------|------|-------------
|
||||
`s` | `str` | The text prompt to tokenize.
|
||||
`add_bos` | `bool` | If `True`, it adds the beginning-of-sentence token. (default: `True`)
|
||||
|
||||
#### Returns
|
||||
- `List[int]`: List of token IDs representing the text prompt.
|
||||
|
||||
#### Example
|
||||
|
||||
```python
|
||||
encoded_ids = tokenizer.encode("Hello, world!", add_bos=True)
|
||||
print(f"Encoded token IDs: {encoded_ids}")
|
||||
```
|
||||
|
||||
### Method: `decode`
|
||||
|
||||
Detokenizes a list of token IDs into text.
|
||||
|
||||
#### Parameters
|
||||
|
||||
Parameter | Type | Description
|
||||
----------|------|-------------
|
||||
`t` | `List[int]` | A list of token IDs to detokenize.
|
||||
`offset` | `Optional[int]` | For incremental decoding. Defaults to `None`, which means it is not applied.
|
||||
|
||||
#### Returns
|
||||
|
||||
- `str`: Text representation of the decoded token IDs.
|
||||
|
||||
#### Example
|
||||
|
||||
```python
|
||||
decoded_text = tokenizer.decode([bos_id] + encoded_ids)
|
||||
print(f"Decoded text: {decoded_text}")
|
||||
```
|
||||
|
||||
### Method: `__call__`
|
||||
|
||||
Tokenizes prompts when the class instance is used as a callable.
|
||||
|
||||
#### Parameters
|
||||
|
||||
Parameter | Type | Description
|
||||
----------|------|-------------
|
||||
`s` | `Union[str, Sequence[str]]` | Text prompts to tokenize.
|
||||
`add_bos` | `bool` | If `True`, it adds the beginning-of-sentence token. (default: `False`)
|
||||
`add_eos` | `bool` | If `True`, it adds the end-of-sentence token. (default: `False`)
|
||||
|
||||
#### Returns
|
||||
|
||||
- `addict.Addict`: Object with `input_ids` containing the list of token IDs.
|
||||
|
||||
#### Example
|
||||
|
||||
```python
|
||||
input_data = tokenizer("Let's tokenize this sentence.")
|
||||
print(f"Tokenized input IDs: {input_data.input_ids}")
|
||||
```
|
||||
|
||||
## Additional Information and Tips
|
||||
|
||||
The library has efficient internals that cache information for performance benefits. For example, `indexes_containing_token` uses a deque to store the most recent lookups, which saves computation time by avoiding re-traversing the vocabulary.
|
||||
|
||||
## Conclusion
|
||||
|
||||
This documentation provides an in-depth explanation of `swarms.tokenizers` with a focus on the `SentencePieceTokenizer` class. By following the examples and guidance detailed above, users should be able to effectively use the tokenizers for their NLP tasks. Users are also encouraged to refer to further resources and the official SentencePiece documentation for more advanced use cases and configurations.
|
||||
@ -0,0 +1,78 @@
|
||||
# `Tokenizer` Class Documentation
|
||||
|
||||
The `Tokenizer` class is a flexible and robust tokenization tool designed to efficiently tokenize prompts into a sequence of token IDs or convert token IDs back into readable text. The class works by initializing with a path to a pretrained tokenization model and supports different tokenization backends based on the availability of configs and pretrained models.
|
||||
|
||||
## Initialization & Configuration
|
||||
|
||||
### Parameters:
|
||||
|
||||
| Parameter | Type | Description | Required |
|
||||
|------------|------|------------------------------------------|----------|
|
||||
| model_file | str | Path to the tokenizer model or directory | Yes |
|
||||
|
||||
### Attributes:
|
||||
|
||||
| Attribute | Type | Description |
|
||||
|------------------|------|------------------------------------|
|
||||
| vocab_size | int | Size of the tokenizer's vocabulary |
|
||||
| bos_token_id | int | ID of the beginning-of-sequence token |
|
||||
| eos_token_id | int | ID of the end-of-sequence token |
|
||||
|
||||
### Methods:
|
||||
|
||||
| Method | Returns | Description |
|
||||
|--------------------------------|---------|--------------------------------------------------------------|
|
||||
| encode(s, add_bos=True, **kwargs) | list[int] | Tokenizes a prompt and returns token IDs. |
|
||||
| decode(t, offset=None) | str | Decodes a list of token IDs to a string. |
|
||||
| __call__(s) | list[int] | Tokenize prompts when the instance is called directly. |
|
||||
| indexes_containing_token(token) | list[int] | Returns indexes in the vocabulary that may contain the token. |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Tokenizing a Prompt
|
||||
|
||||
```python
|
||||
from swarms.tokenizers import Tokenizer
|
||||
|
||||
tokenizer = Tokenizer("/path/to/tokenizer.model")
|
||||
|
||||
# Tokenize a single prompt string
|
||||
prompt = "Hello, world!"
|
||||
token_ids = tokenizer.encode(prompt)
|
||||
print(token_ids)
|
||||
```
|
||||
|
||||
### Decoding Token IDs
|
||||
|
||||
```python
|
||||
# Decode token IDs back into text
|
||||
decoded_text = tokenizer.decode(token_ids)
|
||||
print(decoded_text)
|
||||
```
|
||||
|
||||
### Incremental Decoding
|
||||
|
||||
```python
|
||||
# Incremental decoding with offset (useful for streaming applications)
|
||||
partial_tokens = [token_ids[0]] # simulate partially received tokens
|
||||
decoded_partial = tokenizer.decode(partial_tokens, offset=0)
|
||||
print(decoded_partial)
|
||||
```
|
||||
|
||||
### Properties Access
|
||||
|
||||
```python
|
||||
# Access vocabulary size and special token IDs
|
||||
print("Vocabulary Size:", tokenizer.vocab_size)
|
||||
print("BOS Token ID:", tokenizer.bos_token_id)
|
||||
print("EOS Token ID:", tokenizer.eos_token_id)
|
||||
```
|
||||
|
||||
### Indexes Containing Token
|
||||
|
||||
```python
|
||||
# Find indexes that may output a specific token during decoding
|
||||
token = "world"
|
||||
indexes = tokenizer.indexes_containing_token(token)
|
||||
print("Token Indexes:", indexes)
|
||||
```
|
||||
@ -0,0 +1,86 @@
|
||||
# check_device
|
||||
|
||||
# Module/Function Name: check_device
|
||||
|
||||
The `check_device` is a utility function in PyTorch designed to identify and return the appropriate device(s) for CUDA processing. If CUDA is not available, a CPU device is returned. If CUDA is available, the function returns a list of all available GPU devices.
|
||||
|
||||
The function examines the CUDA availability, checks for multiple GPUs, and finds additional properties for each device.
|
||||
|
||||
## Function Signature and Arguments
|
||||
|
||||
**Signature:**
|
||||
```python
|
||||
def check_device(
|
||||
log_level: Any = logging.INFO,
|
||||
memory_threshold: float = 0.8,
|
||||
capability_threshold: float = 3.5,
|
||||
return_type: str = "list",
|
||||
) -> Union[torch.device, List[torch.device]]
|
||||
```
|
||||
|
||||
| Parameter | Data Type | Default Value | Description |
|
||||
| ------------- | ------------- | ------------- | ------------- |
|
||||
| `log_level` | Any | logging.INFO | The log level. |
|
||||
| `memory_threshold` | float | 0.8 | It is used to check the threshold of memory used on the GPU(s). |
|
||||
| `capability_threshold` | float | 3.5 | It is used to consider only those GPU(s) which have higher compute capability compared to the threshold. |
|
||||
| `return_type` | str | "list" | Depending on the `return_type` either a list of devices can be returned or a single device. |
|
||||
|
||||
This function does not take any mandatory argument. However, it supports optional arguments such as `log_level`, `memory_threshold`, `capability_threshold`, and `return_type`.
|
||||
|
||||
**Returns:**
|
||||
|
||||
- A single torch.device if one device or list of torch.devices if multiple CUDA devices are available, else returns the CPU device if CUDA is not available.
|
||||
|
||||
## Usage and Examples
|
||||
|
||||
### Example 1: Basic Usage
|
||||
|
||||
```python
|
||||
import torch
|
||||
import logging
|
||||
from swarms.utils import check_device
|
||||
|
||||
# Basic usage
|
||||
device = check_device(
|
||||
log_level=logging.INFO,
|
||||
memory_threshold=0.8,
|
||||
capability_threshold=3.5,
|
||||
return_type="list"
|
||||
)
|
||||
```
|
||||
|
||||
### Example 2: Using CPU when CUDA is not available
|
||||
|
||||
```python
|
||||
import torch
|
||||
import logging
|
||||
from swarms.utils import check_device
|
||||
|
||||
# When CUDA is not available
|
||||
device = check_device()
|
||||
print(device) # If CUDA is not available it should return torch.device('cpu')
|
||||
```
|
||||
|
||||
### Example 3: Multiple GPU Available
|
||||
|
||||
```python
|
||||
import torch
|
||||
import logging
|
||||
from swarms.utils import check_device
|
||||
|
||||
# When multiple GPUs are available
|
||||
device = check_device()
|
||||
print(device) # Should return a list of available GPU devices
|
||||
```
|
||||
|
||||
## Tips and Additional Information
|
||||
|
||||
- This function is useful when a user wants to exploit CUDA capabilities for faster computation but unsure of the available devices. This function abstracts all the necessary checks and provides a list of CUDA devices to the user.
|
||||
- The `memory_threshold` and `capability_threshold` are utilized to filter the GPU devices. The GPUs which have memory usage above the `memory_threshold` and compute capability below the `capability_threshold` are not considered.
|
||||
- As of now, CPU does not have memory or capability values, therefore, in the respective cases, it will be returned as default without any comparison.
|
||||
|
||||
## Relevant Resources
|
||||
|
||||
- For more details about the CUDA properties functions used (`torch.cuda.get_device_capability, torch.cuda.get_device_properties`), please refer to the official PyTorch [CUDA semantics documentation](https://pytorch.org/docs/stable/notes/cuda.html).
|
||||
- For more information about Torch device objects, you can refer to the official PyTorch [device documentation](https://pytorch.org/docs/stable/tensor_attributes.html#torch-device).
|
||||
- For a better understanding of how the `logging` module works in Python, see the official Python [logging documentation](https://docs.python.org/3/library/logging.html).
|
||||
@ -0,0 +1,86 @@
|
||||
# display_markdown_message
|
||||
|
||||
# Module Name: `display_markdown_message`
|
||||
|
||||
## Introduction
|
||||
|
||||
`display_markdown_message` is a useful utility function for creating visually-pleasing markdown messages within Python scripts. This function automatically manages multiline strings with lots of indentation and makes single-line messages with ">" tags easy to read, providing users with convenient and elegant logging or messaging capacity.
|
||||
|
||||
## Function Definition and Arguments
|
||||
|
||||
Function Definition:
|
||||
```python
|
||||
def display_markdown_message(message: str, color: str = "cyan"):
|
||||
```
|
||||
This function accepts two parameters:
|
||||
|
||||
|Parameter |Type |Default Value |Description |
|
||||
|--- |--- |--- |--- |
|
||||
|message |str |None |This is the message that is to be displayed. This should be a string. It can contain markdown syntax.|
|
||||
|color |str |"cyan" |This allows you to choose the color of the message. Default is "cyan". Accepts any valid color name.|
|
||||
|
||||
## Functionality and Usage
|
||||
|
||||
This utility function is used to display a markdown formatted message on the console. It accepts a message as a string and an optional color for the message. The function is ideal for generating stylized print outputs such as headers, status updates or pretty notifications.
|
||||
|
||||
By default, any text within the string which is enclosed within `>` tags or `---` is treated specially:
|
||||
|
||||
- Lines encased in `>` tags are rendered as a blockquote in markdown.
|
||||
- Lines consisting of `---` are rendered as horizontal rules.
|
||||
|
||||
The function automatically strips off leading and trailing whitespaces from any line within the message, maintaining aesthetic consistency in your console output.
|
||||
|
||||
### Usage Examples
|
||||
|
||||
#### Basic Example
|
||||
|
||||
```python
|
||||
display_markdown_message("> This is an important message", color="red")
|
||||
```
|
||||
|
||||
Output:
|
||||
```md
|
||||
> **This is an important message**
|
||||
```
|
||||
|
||||
This example will print out the string "This is an important message" in red color, enclosed in a blockquote tag.
|
||||
|
||||
#### Multiline Example
|
||||
|
||||
```python
|
||||
message = """
|
||||
> Header
|
||||
|
||||
My normal message here.
|
||||
|
||||
---
|
||||
|
||||
Another important information
|
||||
"""
|
||||
display_markdown_message(message, color="green")
|
||||
```
|
||||
|
||||
Output:
|
||||
```md
|
||||
> **Header**
|
||||
|
||||
My normal message here.
|
||||
_____
|
||||
|
||||
Another important information
|
||||
```
|
||||
The output is a green colored markdown styled text with the "Header" enclosed in a blockquote, followed by the phrase "My normal message here", a horizontal rule, and finally another phrase, "Another important information".
|
||||
|
||||
## Additional Information
|
||||
|
||||
Use newline characters `\n` to separate the lines of the message. Remember, each line of the message is stripped of leading and trailing whitespaces. If you have special markdown requirements, you may need to revise the input message string accordingly.
|
||||
|
||||
Also, keep in mind the console or terminal's ability to display the chosen color. If a particular console does not support the chosen color, the output may fallback to the default console color.
|
||||
|
||||
For a full list of color names supported by the `Console` module, refer to the official [Console documentation](http://console.readthedocs.io/).
|
||||
|
||||
## References and Resources
|
||||
|
||||
- Python Strings: https://docs.python.org/3/tutorial/introduction.html#strings
|
||||
- Python Markdown: https://pypi.org/project/markdown/
|
||||
- Console module: https://console.readthedocs.io/
|
||||
@ -0,0 +1,114 @@
|
||||
# extract_code_from_markdown
|
||||
|
||||
# swarms.utils Module
|
||||
|
||||
The `swarms.utils` module provides utility functions designed to facilitate specific tasks within the main Swarm codebase. The function `extract_code_from_markdown` is a critical function within this module that we will document in this example.
|
||||
|
||||
## Overview and Introduction
|
||||
|
||||
Many software projects use Markdown extensively for writing documentation, tutorials, and other text documents that can be easily rendered and viewed in different formats, including HTML.
|
||||
|
||||
The `extract_code_from_markdown` function plays a crucial role within the swarms.utils library. As developers write large volumes of Markdown, they often need to isolate code snippets from the whole Markdown file body. These isolated snippets can be used to generate test cases, transform into other languages, or analyze for metrics.
|
||||
|
||||
## Function Definition: `extract_code_from_markdown`
|
||||
|
||||
```python
|
||||
def extract_code_from_markdown(markdown_content: str) -> str:
|
||||
"""
|
||||
Extracts code blocks from a Markdown string and returns them as a single string.
|
||||
|
||||
Args:
|
||||
- markdown_content (str): The Markdown content as a string.
|
||||
|
||||
Returns:
|
||||
- str: A single string containing all the code blocks separated by newlines.
|
||||
"""
|
||||
# Regular expression for fenced code blocks
|
||||
pattern = r"```(?:\w+\n)?(.*?)```"
|
||||
matches = re.findall(pattern, markdown_content, re.DOTALL)
|
||||
|
||||
# Concatenate all code blocks separated by newlines
|
||||
return "\n".join(code.strip() for code in matches)
|
||||
```
|
||||
|
||||
### Arguments
|
||||
|
||||
The function `extract_code_from_markdown` takes one argument:
|
||||
|
||||
| Argument | Description | Type | Default Value |
|
||||
|-----------------------|----------------------------------------|-------------|-------------------|
|
||||
| markdown_content | The input markdown content as a string | str | N/A |
|
||||
|
||||
|
||||
## Function Explanation and Usage
|
||||
|
||||
This function uses a regular expression to find all fenced code blocks in a Markdown string. The pattern `r"```(?:\w+\n)?(.*?)```"` matches strings that start and end with three backticks, optionally followed by a newline and then any number of any characters (the `.*?` part) until the first occurrence of another triple backtick set.
|
||||
|
||||
Once we have the matches, we join all the code blocks into a single string, each block separated by a newline.
|
||||
|
||||
The method's functionality is particularly useful when we need to extract code blocks from markdown content for secondary processing, such as syntax highlighting or execution in a different environment.
|
||||
|
||||
### Usage Examples
|
||||
|
||||
Below are three examples of how you might use this function:
|
||||
|
||||
#### Example 1:
|
||||
|
||||
Extracting code blocks from a simple markdown string.
|
||||
|
||||
```python
|
||||
import re
|
||||
from swarms.utils import extract_code_from_markdown
|
||||
|
||||
markdown_string = '''# Example
|
||||
This is an example of a code block:
|
||||
```python
|
||||
print("Hello World!")
|
||||
``` '''
|
||||
print(extract_code_from_markdown(markdown_string))
|
||||
```
|
||||
|
||||
#### Example 2:
|
||||
|
||||
Extracting code blocks from a markdown file.
|
||||
|
||||
```python
|
||||
import re
|
||||
|
||||
def extract_code_from_markdown(markdown_content: str) -> str:
|
||||
pattern = r"```(?:\w+\n)?(.*?)```"
|
||||
matches = re.findall(pattern, markdown_content, re.DOTALL)
|
||||
return "\n".join(code.strip() for code in matches)
|
||||
|
||||
# Assume that 'example.md' contains multiple code blocks
|
||||
with open('example.md', 'r') as file:
|
||||
markdown_content = file.read()
|
||||
print(extract_code_from_markdown(markdown_content))
|
||||
```
|
||||
|
||||
#### Example 3:
|
||||
|
||||
Using the function in a pipeline to extract and then analyze code blocks.
|
||||
|
||||
```python
|
||||
import re
|
||||
|
||||
def extract_code_from_markdown(markdown_content: str) -> str:
|
||||
pattern = r"```(?:\w+\n)?(.*?)```"
|
||||
matches = re.findall(pattern, markdown_content, re.DOTALL)
|
||||
return "\n".join(code.strip() for code in matches)
|
||||
|
||||
def analyze_code_blocks(code: str):
|
||||
# Add your analysis logic here
|
||||
pass
|
||||
|
||||
# Assume that 'example.md' contains multiple code blocks
|
||||
with open('example.md', 'r') as file:
|
||||
markdown_content = file.read()
|
||||
code_blocks = extract_code_from_markdown(markdown_content)
|
||||
analyze_code_blocks(code_blocks)
|
||||
```
|
||||
|
||||
## Conclusion
|
||||
|
||||
This concludes the detailed documentation of the `extract_code_from_markdown` function from the swarms.utils module. With this documentation, you should be able to understand the function's purpose, how it works, its parameters, and see examples of how to use it effectively.
|
||||
@ -0,0 +1,94 @@
|
||||
# find_image_path
|
||||
|
||||
Firstly, we will divide this documentation into multiple sections.
|
||||
|
||||
# Overview
|
||||
The module **swarms.utils** has the main goal of providing necessary utility functions that are crucial during the creation of the swarm intelligence frameworks. These utility functions can include common operations such as handling input-output operations for files, handling text parsing, and handling basic mathematical computations necessary during the creation of swarm intelligence models.
|
||||
|
||||
The current function `find_image_path` in the module is aimed at extracting an image path from a given text document.
|
||||
|
||||
# Function Detailed Explanation
|
||||
|
||||
## Definition
|
||||
The function `find_image_path` takes a singular argument as an input:
|
||||
|
||||
```python
|
||||
def find_image_path(text):
|
||||
# function body
|
||||
```
|
||||
|
||||
## Parameter
|
||||
The parameter `text` in the function is a string that represents the document or text from which the function is trying to extract all paths to the images present. The function scans the given text, looking for <em>absolute</em> or <em>relative</em> paths to image files (.png, .jpg, .jpeg) on the disk.
|
||||
|
||||
| Parameter Name | Data Type | Default Value | Description |
|
||||
|:--------------:|:---------:|:-------------:|:--------:|
|
||||
| `text` | `str` | - | The text content to scan for image paths |
|
||||
|
||||
## Return Value
|
||||
|
||||
The return value of the function `find_image_path` is a string that represents the longest existing image path extracted from the input text. If no image paths exist within the text, the function returns `None`.
|
||||
|
||||
|
||||
| Return Value | Data Type | Description |
|
||||
|:------------:|:-----------:|:-----------:|
|
||||
| Path | `str` | Longest image path found in the text or `None` if no path found |
|
||||
|
||||
# Function's Code
|
||||
|
||||
The function `find_image_path` performs text parsing and pattern recognition to find image paths within the provided text. The function uses `regular expressions (re)` module to detect all potential paths.
|
||||
|
||||
```python
|
||||
def find_image_path(text):
|
||||
pattern = r"([A-Za-z]:\\[^:\n]*?\.(png|jpg|jpeg|PNG|JPG|JPEG))|(/[^:\n]*?\.(png|jpg|jpeg|PNG|JPG|JPEG))"
|
||||
matches = [
|
||||
match.group()
|
||||
for match in re.finditer(pattern, text)
|
||||
if match.group()
|
||||
]
|
||||
matches += [match.replace("\\", "") for match in matches if match]
|
||||
existing_paths = [
|
||||
match for match in matches if os.path.exists(match)
|
||||
]
|
||||
return max(existing_paths, key=len) if existing_paths else None
|
||||
```
|
||||
|
||||
# Usage Examples
|
||||
|
||||
Let's consider examples of how the function `find_image_path` can be used in different scenarios.
|
||||
|
||||
**Example 1:**
|
||||
|
||||
Consider the case where a text without any image path is provided.
|
||||
|
||||
```python
|
||||
from swarms.utils import find_image_path
|
||||
|
||||
text = "There are no image paths in this text"
|
||||
print(find_image_path(text)) # Outputs: None
|
||||
```
|
||||
|
||||
**Example 2:**
|
||||
|
||||
Consider the case where the text has multiple image paths.
|
||||
|
||||
```python
|
||||
from swarms.utils import find_image_path
|
||||
|
||||
text = "Here is an image path: /home/user/image1.png. Here is another one: C:\\Users\\User\\Documents\\image2.jpeg"
|
||||
print(find_image_path(text)) # Outputs: the longest image path (depends on your file system and existing files)
|
||||
```
|
||||
|
||||
**Example 3:**
|
||||
|
||||
In the final example, we consider a case where the text has an image path, but the file does not exist.
|
||||
|
||||
```python
|
||||
from swarms.utils import find_image_path
|
||||
|
||||
text = "Here is an image path: /home/user/non_existant.png"
|
||||
print(find_image_path(text)) # Outputs: None
|
||||
```
|
||||
|
||||
# Closing Notes
|
||||
|
||||
In conclusion, the `find_image_path` function is crucial in the `swarms.utils` module as it supports a key operation of identifying image paths within given input text. This allows users to automate the extraction of such data from larger documents/text. However, it's important to note the function returns only existing paths in your file system and only the longest if multiple exist.
|
||||
@ -0,0 +1,82 @@
|
||||
# limit_tokens_from_string
|
||||
|
||||
## Introduction
|
||||
The `Swarms.utils` library contains utility functions used across codes that handle machine learning and other operations. The `Swarms.utils` library includes a notable function named `limit_tokens_from_string()`. This function particularly limits the number of tokens in a given string.
|
||||
|
||||
# Function: limit_tokens_from_string()
|
||||
Within the `Swarms.utils` library, there is a method `limit_tokens_from_string(string: str, model: str = "gpt-4", limit: int = 500) -> str:`
|
||||
|
||||
## Description
|
||||
The function `limit_tokens_from_string()` limits the number of tokens in a given string based on the specified threshold. It is primarily useful when you are handling large text data and need to chunk or limit your text to a certain length. Limiting token length could be useful in various scenarios such as when working with data with limited computational resources, or when dealing with models that accept a specific maximum limit of text.
|
||||
|
||||
## Parameters
|
||||
|
||||
| Parameter | Type | Default Value | Description
|
||||
| :-----------| :----------- | :------------ | :------------|
|
||||
| `string` | `str` | `None` | The input string from which the tokens need to be limited. |
|
||||
| `model` | `str` | `"gpt-4"` | The model used to encode and decode the token. The function defaults to `gpt-4` but you can specify any model supported by `tiktoken`. If a model is not found, it falls back to use `gpt2` |
|
||||
| `limit` | `int` | `500` | The limit up to which the tokens have to be sliced. Default limit is 500.|
|
||||
|
||||
## Returns
|
||||
|
||||
| Return | Type | Description
|
||||
| :-----------| :----------- | :------------
|
||||
| `out` | `str` | A string that is constructed back from the encoded tokens that have been limited to a count of `limit` |
|
||||
|
||||
## Method Detail and Usage Examples
|
||||
|
||||
The method `limit_tokens_from_string()` takes in three parameters - `string`, `model`, and `limit`.
|
||||
|
||||
|
||||
First, it tries to get the encoding for the model specified in the `model` argument using `tiktoken.encoding_for_model(model)`. In case the specified model is not found, the function uses `gpt2` model encoding as a fallback.
|
||||
|
||||
Next, the input `string` is tokenized using the `encode` method on the `encoding` tensor. This results in the `encoded` tensor.
|
||||
|
||||
Then, the function slices the `encoded` tensor to get the first `limit` number of tokens.
|
||||
|
||||
Finally, the function converts back the tokens into the string using the `decode` method of the `encoding` tensor. The resulting string `out` is returned.
|
||||
|
||||
### Example 1:
|
||||
|
||||
```python
|
||||
from swarms.utils import limit_tokens_from_string
|
||||
|
||||
# longer input string
|
||||
string = "This is a very long string that needs to be tokenized. This string might exceed the maximum token limit, so it will need to be truncated."
|
||||
|
||||
# lower token limit
|
||||
limit = 10
|
||||
|
||||
output = limit_tokens_from_string(string, limit=limit)
|
||||
```
|
||||
|
||||
### Example 2:
|
||||
|
||||
```python
|
||||
from swarms.utils import limit_tokens_from_string
|
||||
|
||||
# longer input string with different model
|
||||
string = "This string will be tokenized using gpt2 model. If the string is too long, it will be truncated."
|
||||
|
||||
# model
|
||||
model = "gpt2"
|
||||
|
||||
output = limit_tokens_from_string(string, model=model)
|
||||
```
|
||||
|
||||
### Example 3:
|
||||
|
||||
```python
|
||||
from swarms.utils import limit_tokens_from_string
|
||||
|
||||
# try with a random model string
|
||||
string = "In case the method does not find the specified model, it will fall back to gpt2 model."
|
||||
|
||||
# model
|
||||
model = "gpt-4"
|
||||
|
||||
output = limit_tokens_from_string(string, model=model)
|
||||
```
|
||||
|
||||
**Note:** If specifying a model not supported by `tiktoken` intentionally, it will fall back to `gpt2` model for encoding.
|
||||
|
||||
@ -0,0 +1,102 @@
|
||||
# load_model_torch
|
||||
|
||||
# load_model_torch: Utility Function Documentation
|
||||
|
||||
## Introduction:
|
||||
|
||||
`load_model_torch` is a utility function in the `swarms.utils` library that is designed to load a saved PyTorch model and move it to the designated device. It provides flexibility allowing the user to specify the model file location, the device where the loaded model should be moved to, whether to strictly enforce the keys in the state dictionary to match the keys returned by the model's `state_dict()`, and many more.
|
||||
|
||||
Moreover, if the saved model file only contains the state dictionary, but not the model architecture, you can pass the model architecture as an argument.
|
||||
|
||||
## Function Definition and Parameters:
|
||||
|
||||
```python
|
||||
def load_model_torch(
|
||||
model_path: str = None,
|
||||
device: torch.device = None,
|
||||
model: nn.Module = None,
|
||||
strict: bool = True,
|
||||
map_location=None,
|
||||
*args,
|
||||
**kwargs,
|
||||
) -> nn.Module:
|
||||
```
|
||||
|
||||
The following table describes the parameters in detail:
|
||||
|
||||
| Name | Type | Default Value | Description |
|
||||
| ------ | ------ | ------------- | ------------|
|
||||
| model_path | str | None | A string specifying the path to the saved model file on disk. _Required_ |
|
||||
| device | torch.device | None | A `torch.device` object that specifies the target device for the loaded model. If not provided, the function checks for the availability of a GPU and uses it if available. If not, it defaults to CPU. |
|
||||
| model | nn.Module | None | An instance of `torch.nn.Module` representing the model's architecture. This parameter is required if the model file only contains the model's state dictionary and not the model architecture. |
|
||||
| strict | bool | True | A boolean that determines whether to strictly enforce that the keys in the state dictionary match the keys returned by the model's `state_dict()` function. If set to `True`, the function will raise a KeyError when the state dictionary and `state_dict()` keys do not match. |
|
||||
| map_location | callable | None | A function to remap the storage locations of the loaded model's parameters. Useful for loading models saved on a device type that is different from the current one. |
|
||||
| *args, **kwargs | - | - | Additional arguments and keyword arguments to be passed to `torch.load`.
|
||||
|
||||
Returns:
|
||||
|
||||
- `torch.nn.Module` - The loaded model after moving it to the desired device.
|
||||
|
||||
Raises:
|
||||
|
||||
- `FileNotFoundError` - If the saved model file is not found at the specified path.
|
||||
- `RuntimeError` - If there was an error while loading the model.
|
||||
|
||||
## Example of Usage:
|
||||
|
||||
This function can be used directly inside your code as shown in the following examples:
|
||||
|
||||
### Example 1:
|
||||
Loading a model without specifying a device results in the function choosing the most optimal available device automatically.
|
||||
|
||||
```python
|
||||
from swarms.utils import load_model_torch
|
||||
import torch.nn as nn
|
||||
|
||||
# Assume `mymodel.pth` is in the current directory
|
||||
model_path = "./mymodel.pth"
|
||||
|
||||
# Define your model architecture if the model file only contains state dict
|
||||
class MyModel(nn.Module):
|
||||
def __init__(self):
|
||||
super().__init__()
|
||||
self.linear = nn.Linear(10, 2)
|
||||
|
||||
def forward(self, x):
|
||||
return self.linear(x)
|
||||
|
||||
model = MyModel()
|
||||
|
||||
# Load the model
|
||||
loaded_model = load_model_torch(model_path, model=model)
|
||||
|
||||
# Now you can use the loaded model for prediction or further training
|
||||
```
|
||||
### Example 2:
|
||||
Explicitly specifying a device.
|
||||
|
||||
```python
|
||||
# Assume `mymodel.pth` is in the current directory
|
||||
model_path = "./mymodel.pth"
|
||||
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
|
||||
|
||||
# Load the model
|
||||
loaded_model = load_model_torch(model_path, device=device)
|
||||
```
|
||||
|
||||
### Example 3:
|
||||
Using a model file that contains only the state dictionary, not the model architecture.
|
||||
|
||||
```python
|
||||
# Assume `mymodel_state_dict.pth` is in the current directory
|
||||
model_path = "./mymodel_state_dict.pth"
|
||||
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
|
||||
|
||||
# Define your model architecture
|
||||
model = MyModel()
|
||||
|
||||
# Load the model
|
||||
loaded_model = load_model_torch(model_path, device=device, model=model)
|
||||
```
|
||||
|
||||
This gives you an insight on how to use `load_model_torch` utility function from `swarms.utils` library efficiently. Always remember to pass the model path argument while the other arguments can be optional based on your requirements. Furthermore, handle exceptions properly for smooth functioning of your PyTorch related projects.
|
||||
@ -0,0 +1,78 @@
|
||||
# math_eval
|
||||
|
||||
|
||||
The `math_eval` function is a python decorator that wraps around a function to run two functions on the same inputs and compare their results. The decorator can be used for testing functions that are expected to have equivalent functionality, or in situations where two different methods are used to calculate or retrieve a value, and the results need to be compared.
|
||||
|
||||
The `math_eval` function in this case accepts two functions as parameters: `func1` and `func2`, and returns a decorator. This returned decorator, when applied to a function, enhances that function to execute both `func1` and `func2`, and compare the results.
|
||||
|
||||
This can be particularly useful in situations when you are implementing a new function and wants to compare its behavior and results with that of an existing one under the same set of input parameters. It also logs the results if they do not match which could be quite useful during the debug process.
|
||||
|
||||
## Usage Example
|
||||
|
||||
Let's say you have two functions: `ground_truth` and `generated_func`, that have similar functionalities or serve the same purpose. You are writing a new function called `test_func`, and you'd like to compare the results of `ground_truth` and `generated_func` when `test_func` is run. Here is how you would use the `math_eval` decorator:
|
||||
|
||||
```python
|
||||
@math_eval(ground_truth, generated_func)
|
||||
def test_func(x):
|
||||
return x
|
||||
result1, result2 = test_func(5)
|
||||
print(f"Result from ground_truth: {result1}")
|
||||
print(f"Result from generated_func: {result2}")
|
||||
```
|
||||
|
||||
## Parameters
|
||||
|
||||
| Parameter | Data Type | Description |
|
||||
| ---- | ---- | ---- |
|
||||
| func1 | Callable | The first function whose result you want to compare. |
|
||||
| func2 | Callable | The second function whose result you want to compare. |
|
||||
|
||||
The data types for `func1` and `func2` cannot be specified as they can be any python function (or callable object). The decorator verifies that they are callable and exceptions are handled within the decorator function.
|
||||
|
||||
## Return Values
|
||||
|
||||
The `math_eval` function does not return a direct value, since it is a decorator. When applied to a function, it alters the behavior of the wrapped function to return two values:
|
||||
|
||||
1. `result1`: The result of running `func1` with the given input parameters.
|
||||
2. `result2`: The result of running `func2` with the given input parameters.
|
||||
|
||||
These two return values are provided in that order as a tuple.
|
||||
|
||||
## Source Code
|
||||
|
||||
Here's how to implement the `math_eval` decorator:
|
||||
|
||||
```python
|
||||
import functools
|
||||
import logging
|
||||
|
||||
def math_eval(func1, func2):
|
||||
"""Math evaluation decorator."""
|
||||
|
||||
def decorator(func):
|
||||
@functools.wraps(func)
|
||||
def wrapper(*args, **kwargs):
|
||||
try:
|
||||
result1 = func1(*args, **kwargs)
|
||||
except Exception as e:
|
||||
logging.error(f"Error in func1: {e}")
|
||||
result1 = None
|
||||
|
||||
try:
|
||||
result2 = func2(*args, **kwargs)
|
||||
except Exception as e:
|
||||
logging.error(f"Error in func2: {e}")
|
||||
result2 = None
|
||||
|
||||
if result1 != result2:
|
||||
logging.warning(
|
||||
f"Outputs do not match: {result1} != {result2}"
|
||||
)
|
||||
|
||||
return result1, result2
|
||||
|
||||
return wrapper
|
||||
|
||||
return decorator
|
||||
```
|
||||
Please note that the code is logging exceptions to facilitate debugging, but the actual processing and handling of the exception would depend on how you want your application to respond to exceptions. Therefore, you may want to customize the error handling depending upon your application's requirements.
|
||||
@ -0,0 +1,86 @@
|
||||
# metrics_decorator
|
||||
|
||||
This documentation explains the use and functionality of the `metrics_decorator` function in the LLM (Large Language Models).
|
||||
|
||||
The `metrics_decorator` function is a standard Python decorator that augments a specific function by wrapping extra functionality around it. It is commonly used for things like timing, logging or memoization.
|
||||
--
|
||||
The `metrics_decorator` in LLM is specially designed to measure and calculate three key performance metrics when generating language models:
|
||||
|
||||
1. `Time to First Token`: Measures the elapsed time from the start of function execution until the generation of the first token.
|
||||
2. `Generation Latency`: It measures the total time taken for a complete run.
|
||||
3. `Throughput`: Calculates the rate of production of tokens per unit of time.
|
||||
|
||||
```python
|
||||
def metrics_decorator(func: Callable):
|
||||
"""
|
||||
|
||||
Metrics decorator for LLM
|
||||
|
||||
Args:
|
||||
func (Callable): The function to be decorated.
|
||||
|
||||
"""
|
||||
|
||||
@wraps(func)
|
||||
def wrapper(self, *args, **kwargs):
|
||||
"""
|
||||
An inner function that wraps the decorated function. It calculates 'Time to First Token',
|
||||
'Generation Latency' and 'Throughput' metrics.
|
||||
|
||||
Args:
|
||||
self : The object instance.
|
||||
*args : Variable length argument list of the decorated function.
|
||||
**kwargs : Arbitrary keyword arguments of the decorated function.
|
||||
"""
|
||||
|
||||
# Measure Time to First Token
|
||||
start_time = time.time()
|
||||
result = func(self, *args, **kwargs)
|
||||
first_token_time = time.time()
|
||||
|
||||
# Measure Generation Latency
|
||||
end_time = time.time()
|
||||
|
||||
# Calculate Throughput (assuming the function returns a list of tokens)
|
||||
throughput = len(result) / (end_time - start_time)
|
||||
|
||||
return f"""
|
||||
Time to First Token: {first_token_time - start_time}
|
||||
Generation Latency: {end_time - start_time}
|
||||
Throughput: {throughput}
|
||||
"""
|
||||
|
||||
return wrapper
|
||||
```
|
||||
## Example Usage
|
||||
Now let's discuss the usage of the `metrics_decorator` function with an example.
|
||||
|
||||
Assuming that we have a language generation function called `text_generator()` that generates a list of tokens.
|
||||
|
||||
```python
|
||||
@metrics_decorator
|
||||
def text_generator(self, text: str):
|
||||
"""
|
||||
Args:
|
||||
text (str): The input text.
|
||||
|
||||
Returns:
|
||||
A list of tokens generated from the input text.
|
||||
"""
|
||||
# language generation implementation goes here
|
||||
return tokens
|
||||
|
||||
# Instantiate the class and call the decorated function
|
||||
obj = ClassName()
|
||||
obj.text_generator("Hello, world!")
|
||||
```
|
||||
|
||||
When the decorated `text_generator()` function is called, it will measure and return:
|
||||
|
||||
- Time elapsed until the first token is generated.
|
||||
- The total execution time of the function.
|
||||
- The rate of tokens generation per unit time.
|
||||
|
||||
This example provides a basic overview of how a function can be decorated with the `metrics_decorator`. The provided `func` argument could be any method from any class, as long as it complies with the structure defined in `metrics_decorator`. It is worth noting that the decorated function must return a list of tokens for the `Throughput` metric to work correctly.
|
||||
|
||||
Remember, applying the `metrics_decorator` does not affect the original functionality of the decorated function, it just adds additional measurement and logging capabilities to it. It's a great utility for tracking and optimizing the performance of your language models.
|
||||
@ -0,0 +1,71 @@
|
||||
# pdf_to_text
|
||||
|
||||
## Introduction
|
||||
The function `pdf_to_text` is a Python utility for converting a PDF file into a string of text content. It leverages the `PyPDF2` library, an excellent Python library for processing PDF files. The function takes in a PDF file's path and reads its content, subsequently returning the extracted textual data.
|
||||
|
||||
This function can be very useful when you want to extract textual information from PDF files automatically. For instance, when processing a large number of documents, performing textual analysis, or when you're dealing with text data that is only available in PDF format.
|
||||
|
||||
## Class / Function Definition
|
||||
|
||||
`pdf_to_text` is a standalone function defined as follows:
|
||||
|
||||
```python
|
||||
def pdf_to_text(pdf_path: str) -> str:
|
||||
```
|
||||
|
||||
## Parameters
|
||||
|
||||
| Parameter | Type | Description |
|
||||
|:-:|---|---|
|
||||
| pdf_path | str | The path to the PDF file to be converted |
|
||||
|
||||
## Returns
|
||||
|
||||
| Return Value | Type | Description |
|
||||
|:-:|---|---|
|
||||
| text | str | The text extracted from the PDF file. |
|
||||
|
||||
## Raises
|
||||
|
||||
| Exception | Description |
|
||||
|---|---|
|
||||
| FileNotFoundError | If the PDF file is not found at the specified path. |
|
||||
| Exception | If there is an error in reading the PDF file. |
|
||||
|
||||
## Function Description
|
||||
|
||||
`pdf_to_text` utilises the `PdfReader` function from the `PyPDF2` library to read the PDF file. If the PDF file does not exist at the specified path or there was an error while reading the file, appropriate exceptions will be raised. It then iterates through each page in the PDF and uses the `extract_text` function to extract the text content from each page. These contents are then concatenated into a single variable and returned as the result.
|
||||
|
||||
## Usage Examples
|
||||
|
||||
To use this function, you first need to install the `PyPDF2` library. It can be installed via pip:
|
||||
|
||||
```python
|
||||
!pip install pypdf2
|
||||
```
|
||||
|
||||
Then, you should import the `pdf_to_text` function:
|
||||
|
||||
```python
|
||||
from swarms.utils import pdf_to_text
|
||||
```
|
||||
|
||||
Here is an example of how to use `pdf_to_text`:
|
||||
|
||||
```python
|
||||
# Define the path to the pdf file
|
||||
pdf_path = 'sample.pdf'
|
||||
|
||||
# Use the function to extract text
|
||||
text = pdf_to_text(pdf_path)
|
||||
|
||||
# Print the extracted text
|
||||
print(text)
|
||||
```
|
||||
|
||||
## Tips and Additional Information
|
||||
- Ensure that the PDF file path is valid and that the file exists at the specified location. If the file does not exist, a `FileNotFoundError` will be raised.
|
||||
- This function reads the text from the PDF. It does not handle images, graphical elements, or any non-text content.
|
||||
- If the PDF contains scanned images rather than textual data, the `extract_text` function may not be able to extract any text. In such cases, you would require OCR (Optical Character Recognition) tools to extract the text.
|
||||
- Be aware of the possibility that the output string might contain special characters or escape sequences because they were part of the PDF's content. You might need to clean the resulting text according to your requirements.
|
||||
- The function uses the PyPDF2 library to facilitate the PDF reading and text extraction. For any issues related to PDF manipulation, consult the [PyPDF2 library documentation](https://pythonhosted.org/PyPDF2/).
|
||||
@ -1,128 +0,0 @@
|
||||
# Phoenix Trace Decorator Documentation
|
||||
|
||||
## Introduction
|
||||
|
||||
Welcome to the documentation for the `phoenix_trace_decorator` module. This module provides a convenient decorator for tracing Python functions and capturing exceptions using Phoenix, a versatile tracing and monitoring tool. Phoenix allows you to gain insights into the execution of your code, capture errors, and monitor performance.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Installation](#installation)
|
||||
2. [Getting Started](#getting-started)
|
||||
3. [Decorator Usage](#decorator-usage)
|
||||
4. [Examples](#examples)
|
||||
5. [Best Practices](#best-practices)
|
||||
6. [References](#references)
|
||||
|
||||
## 1. Installation <a name="installation"></a>
|
||||
|
||||
Before using the `phoenix_trace_decorator`, you need to install the Swarms library. You can install Phoenix using pip:
|
||||
|
||||
```bash
|
||||
pip install swarms
|
||||
```
|
||||
|
||||
## 2. Getting Started <a name="getting-started"></a>
|
||||
|
||||
Phoenix is a powerful tracing and monitoring tool, and the `phoenix_trace_decorator` simplifies the process of tracing functions and capturing exceptions within your Python code. To begin, ensure that Phoenix is installed, and then import the `phoenix_trace_decorator` module into your Python script.
|
||||
|
||||
```python
|
||||
from swarms import phoenix_trace_decorator
|
||||
```
|
||||
|
||||
## 3. Decorator Usage <a name="decorator-usage"></a>
|
||||
|
||||
The `phoenix_trace_decorator` module provides a decorator, `phoenix_trace_decorator`, which can be applied to functions you want to trace. The decorator takes a single argument, a docstring that describes the purpose of the function being traced.
|
||||
|
||||
Here is the basic structure of using the decorator:
|
||||
|
||||
```python
|
||||
@phoenix_trace_decorator("Description of the function")
|
||||
def my_function(param1, param2):
|
||||
# Function implementation
|
||||
pass
|
||||
```
|
||||
|
||||
## 4. Examples <a name="examples"></a>
|
||||
|
||||
Let's explore some practical examples of using the `phoenix_trace_decorator` in your code.
|
||||
|
||||
### Example 1: Basic Tracing
|
||||
|
||||
In this example, we'll trace a simple function and print a message.
|
||||
|
||||
```python
|
||||
@phoenix_trace_decorator("Tracing a basic function")
|
||||
def hello_world():
|
||||
print("Hello, World!")
|
||||
|
||||
# Call the decorated function
|
||||
hello_world()
|
||||
```
|
||||
|
||||
### Example 2: Tracing a Function with Parameters
|
||||
|
||||
You can use the decorator with functions that have parameters.
|
||||
|
||||
```python
|
||||
@phoenix_trace_decorator("Tracing a function with parameters")
|
||||
def add_numbers(a, b):
|
||||
result = a + b
|
||||
print(f"Result: {result}")
|
||||
|
||||
# Call the decorated function with parameters
|
||||
add_numbers(2, 3)
|
||||
```
|
||||
|
||||
### Example 3: Tracing Nested Calls
|
||||
|
||||
The decorator can also trace nested function calls.
|
||||
|
||||
```python
|
||||
@phoenix_trace_decorator("Outer function")
|
||||
def outer_function():
|
||||
print("Outer function")
|
||||
|
||||
@phoenix_trace_decorator("Inner function")
|
||||
def inner_function():
|
||||
print("Inner function")
|
||||
|
||||
inner_function()
|
||||
|
||||
# Call the decorated functions
|
||||
outer_function()
|
||||
```
|
||||
|
||||
### Example 4: Exception Handling
|
||||
|
||||
Phoenix can capture exceptions and provide detailed information about them.
|
||||
|
||||
```python
|
||||
@phoenix_trace_decorator("Function with exception handling")
|
||||
def divide(a, b):
|
||||
try:
|
||||
result = a / b
|
||||
except ZeroDivisionError as e:
|
||||
raise ValueError("Division by zero") from e
|
||||
|
||||
# Call the decorated function with an exception
|
||||
try:
|
||||
divide(5, 0)
|
||||
except ValueError as e:
|
||||
print(f"Error: {e}")
|
||||
```
|
||||
|
||||
## 5. Best Practices <a name="best-practices"></a>
|
||||
|
||||
When using the `phoenix_trace_decorator`, consider the following best practices:
|
||||
|
||||
- Use meaningful docstrings to describe the purpose of the traced functions.
|
||||
- Keep your tracing focused on critical parts of your code.
|
||||
- Make sure Phoenix is properly configured and running before using the decorator.
|
||||
|
||||
## 6. References <a name="references"></a>
|
||||
|
||||
For more information on Phoenix and advanced usage, please refer to the [Phoenix Documentation](https://phoenix-docs.readthedocs.io/en/latest/).
|
||||
|
||||
---
|
||||
|
||||
By following this documentation, you can effectively use the `phoenix_trace_decorator` to trace your Python functions, capture exceptions, and gain insights into the execution of your code. This tool is valuable for debugging, performance optimization, and monitoring the health of your applications.
|
||||
@ -0,0 +1,102 @@
|
||||
# prep_torch_inference
|
||||
|
||||
```python
|
||||
def prep_torch_inference(
|
||||
model_path: str = None,
|
||||
device: torch.device = None,
|
||||
*args,
|
||||
**kwargs,
|
||||
):
|
||||
"""
|
||||
Prepare a Torch model for inference.
|
||||
|
||||
Args:
|
||||
model_path (str): Path to the model file.
|
||||
device (torch.device): Device to run the model on.
|
||||
*args: Additional positional arguments.
|
||||
**kwargs: Additional keyword arguments.
|
||||
|
||||
Returns:
|
||||
torch.nn.Module: The prepared model.
|
||||
"""
|
||||
try:
|
||||
model = load_model_torch(model_path, device)
|
||||
model.eval()
|
||||
return model
|
||||
except Exception as e:
|
||||
# Add error handling code here
|
||||
print(f"Error occurred while preparing Torch model: {e}")
|
||||
return None
|
||||
```
|
||||
This method is part of the 'swarms.utils' module. It accepts a model file path and a torch device as input and returns a model that is ready for inference.
|
||||
|
||||
## Detailed Functionality
|
||||
|
||||
The method loads a PyTorch model from the file specified by `model_path`. This model is then moved to the specified `device` if it is provided. Subsequently, the method sets the model to evaluation mode by calling `model.eval()`. This is a crucial step when preparing a model for inference, as certain layers like dropout or batch normalization behave differently during training vs during evaluation.
|
||||
In the case of any exception (e.g., the model file not found or the device unavailable), it prints an error message and returns `None`.
|
||||
|
||||
## Parameters
|
||||
|
||||
| Parameter | Type | Description | Default |
|
||||
|-----------|------|-------------|---------|
|
||||
| model_path | str | Path to the model file. | None |
|
||||
| device | torch.device | Device to run the model on. | None |
|
||||
| args | tuple | Additional positional arguments. | None |
|
||||
| kwargs | dict | Additional keyword arguments. | None |
|
||||
|
||||
## Returns
|
||||
|
||||
| Type | Description |
|
||||
|------|-------------|
|
||||
| torch.nn.Module | The prepared model ready for inference. Returns `None` if any exception occurs. |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
Here are some examples of how you can use the `prep_torch_inference` method. Before that, you need to import the necessary modules as follows:
|
||||
|
||||
```python
|
||||
import torch
|
||||
from swarms.utils import prep_torch_inference, load_model_torch
|
||||
```
|
||||
|
||||
### Example 1: Load a model for inference on CPU
|
||||
|
||||
```python
|
||||
model_path = "saved_model.pth"
|
||||
model = prep_torch_inference(model_path)
|
||||
|
||||
if model is not None:
|
||||
print("Model loaded successfully and is ready for inference.")
|
||||
else:
|
||||
print("Failed to load the model.")
|
||||
```
|
||||
|
||||
### Example 2: Load a model for inference on CUDA device
|
||||
|
||||
```python
|
||||
model_path = "saved_model.pth"
|
||||
device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")
|
||||
model = prep_torch_inference(model_path, device)
|
||||
|
||||
if model is not None:
|
||||
print(f"Model loaded successfully on device {device} and is ready for inference.")
|
||||
else:
|
||||
print("Failed to load the model.")
|
||||
```
|
||||
|
||||
### Example 3: Load a model with additional arguments for `load_model_torch`
|
||||
|
||||
```python
|
||||
model_path = "saved_model.pth"
|
||||
device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")
|
||||
|
||||
# Suppose load_model_torch accepts an additional argument, map_location
|
||||
model = prep_torch_inference(model_path, device, map_location=device)
|
||||
|
||||
if model is not None:
|
||||
print(f"Model loaded successfully on device {device} and is ready for inference.")
|
||||
else:
|
||||
print("Failed to load the model.")
|
||||
```
|
||||
|
||||
Please note, you need to ensure the given model path does exist and the device is available on your machine, else `prep_torch_inference` method will return `None`. Depending on the complexity and size of your models, loading them onto a specific device might take a while. So it's important that you take this into consideration when designing your machine learning workflows.
|
||||
@ -0,0 +1,110 @@
|
||||
# print_class_parameters
|
||||
|
||||
# Module Function Name: print_class_parameters
|
||||
|
||||
The `print_class_parameters` function is a utility function developed to help developers and users alike in retrieving and printing the parameters of a class constructor in Python, either in standard output or returned as a dictionary if the `api_format` is set to `True`.
|
||||
|
||||
This utility function utilizes the `inspect` module to fetch the signature of the class constructor and fetches the parameters from the obtained signature. The parameter values and their respective types are then outputted.
|
||||
|
||||
This function allows developers to easily inspect and understand the class' constructor parameters without the need to individually go through the class structure. This eases the testing and debugging process for developers and users alike, aiding in generating more efficient and readable code.
|
||||
|
||||
__Function Definition:__
|
||||
|
||||
```python
|
||||
def print_class_parameters(cls, api_format: bool = False):
|
||||
```
|
||||
__Parameters:__
|
||||
|
||||
| Parameter | Type | Description | Default value |
|
||||
|---|---|---|---|
|
||||
| cls | type | The Python class to inspect. | None |
|
||||
| api_format | bool | Flag to determine if the output should be returned in dictionary format (if set to True) or printed out (if set to False) | False |
|
||||
|
||||
__Functionality and Usage:__
|
||||
|
||||
Inside the `print_class_parameters` function, it starts by getting the signature of the constructor of the inputted class by invoking `inspect.signature(cls.__init__)`. It then extracts the parameters from the signature and stores it in the `params` variable.
|
||||
|
||||
If the `api_format` argument is set to `True`, instead of printing the parameters and their types, it stores them inside a dictionary where each key-value pair is a parameter name and its type. It then returns this dictionary.
|
||||
|
||||
If `api_format` is set to `False` or not set at all (defaulting to False), the function iterates over the parameters and prints the parameter name and its type. "self" parameters are excluded from the output as they are inherent to all class methods in Python.
|
||||
|
||||
A possible exception that may occur during the execution of this function is during the invocation of the `inspect.signature()` function call. If the inputted class does not have an `__init__` method or any error occurs during the retrieval of the class constructor's signature, an exception will be triggered. In that case, an error message that includes the error details is printed out.
|
||||
|
||||
__Usage and Examples:__
|
||||
|
||||
Assuming the existence of a class:
|
||||
|
||||
```python
|
||||
class Agent:
|
||||
def __init__(self, x: int, y: int):
|
||||
self.x = x
|
||||
self.y = y
|
||||
```
|
||||
|
||||
One could use `print_class_parameters` in its typical usage:
|
||||
|
||||
```python
|
||||
print_class_parameters(Agent)
|
||||
```
|
||||
|
||||
Results in:
|
||||
|
||||
```
|
||||
Parameter: x, Type: <class 'int'>
|
||||
Parameter: y, Type: <class 'int'>
|
||||
```
|
||||
|
||||
Or, with `api_format` set to `True`
|
||||
|
||||
```python
|
||||
output = print_class_parameters(Agent, api_format=True)
|
||||
print(output)
|
||||
```
|
||||
|
||||
Results in:
|
||||
|
||||
```
|
||||
{'x': "<class 'int'>", 'y': "<class 'int'>"}
|
||||
```
|
||||
|
||||
__Note:__
|
||||
|
||||
The function `print_class_parameters` is not limited to custom classes. It can inspect built-in Python classes such as `list`, `dict`, and others. However, it is most useful when inspecting custom-defined classes that aren't inherently documented in Python or third-party libraries.
|
||||
|
||||
__Source Code__
|
||||
|
||||
```python
|
||||
def print_class_parameters(cls, api_format: bool = False):
|
||||
"""
|
||||
Print the parameters of a class constructor.
|
||||
|
||||
Parameters:
|
||||
cls (type): The class to inspect.
|
||||
|
||||
Example:
|
||||
>>> print_class_parameters(Agent)
|
||||
Parameter: x, Type: <class 'int'>
|
||||
Parameter: y, Type: <class 'int'>
|
||||
"""
|
||||
try:
|
||||
# Get the parameters of the class constructor
|
||||
sig = inspect.signature(cls.__init__)
|
||||
params = sig.parameters
|
||||
|
||||
if api_format:
|
||||
param_dict = {}
|
||||
for name, param in params.items():
|
||||
if name == "self":
|
||||
continue
|
||||
param_dict[name] = str(param.annotation)
|
||||
return param_dict
|
||||
|
||||
# Print the parameters
|
||||
for name, param in params.items():
|
||||
if name == "self":
|
||||
continue
|
||||
print(f"Parameter: {name}, Type: {param.annotation}")
|
||||
|
||||
except Exception as e:
|
||||
print(f"An error occurred while inspecting the class: {e}")
|
||||
```
|
||||
@ -1,58 +1,34 @@
|
||||
import os
|
||||
|
||||
from dotenv import load_dotenv
|
||||
from swarms.models import Gemini
|
||||
|
||||
# Import the OpenAIChat model and the Agent struct
|
||||
from swarms.models import OpenAIChat
|
||||
from swarms.structs import Agent
|
||||
|
||||
# Load environment variables
|
||||
# Load the environment variables
|
||||
load_dotenv()
|
||||
|
||||
# Get the API key from the environment
|
||||
api_key = os.environ.get("GOOGLE_API_KEY")
|
||||
if not api_key:
|
||||
raise ValueError("Gemini API key not found. Please set it in your .env file")
|
||||
|
||||
# Initialize the first agent (Gemini Pro Vision) for image analysis
|
||||
agent_analysis = Agent(
|
||||
llm=Gemini(
|
||||
temperature=0.8,
|
||||
model_name="gemini-pro-vision",
|
||||
gemini_api_key=api_key
|
||||
),
|
||||
max_loops=1,
|
||||
autosave=True,
|
||||
dashboard=True,
|
||||
api_key = os.environ.get("OPENAI_API_KEY")
|
||||
|
||||
# Initialize the language model
|
||||
llm = OpenAIChat(
|
||||
temperature=0.5,
|
||||
model_name="gpt-4",
|
||||
openai_api_key=api_key,
|
||||
max_tokens=1000,
|
||||
)
|
||||
|
||||
# Initialize the second agent (Gemini Pro) for text-based tasks
|
||||
agent_instruction = Agent(
|
||||
llm=Gemini(
|
||||
temperature=0.8,
|
||||
model_name="gemini-pro",
|
||||
gemini_api_key=api_key
|
||||
),
|
||||
## Initialize the workflow
|
||||
agent = Agent(
|
||||
llm=llm,
|
||||
max_loops=1,
|
||||
autosave=True,
|
||||
dashboard=True,
|
||||
dashboard=False,
|
||||
streaming_on=True,
|
||||
verbose=True,
|
||||
)
|
||||
|
||||
# Task for the first agent: Image Analysis
|
||||
task_analysis = """
|
||||
Analyze this logo and summarize its content, then give a structured list of suggested improvements.
|
||||
"""
|
||||
img = 'swarmslogobanner.png' # Replace with your image file name
|
||||
|
||||
# Run the first agent on the task
|
||||
analysis_results = agent_analysis.run(task=task_analysis, img=img)
|
||||
|
||||
# Task for the second agent: Instructions for a better logo
|
||||
task_instruction = f"""
|
||||
Based on the analysis and suggestions for the logo:
|
||||
{analysis_results}
|
||||
|
||||
Generate detailed instructions for creating an improved version of this logo.
|
||||
"""
|
||||
|
||||
# Run the second agent on the task
|
||||
instruction_results = agent_instruction.run(task=task_instruction)
|
||||
|
||||
.............
|
||||
# Run the workflow on a task
|
||||
agent.run("Generate a 10,000 word blog on health and wellness.")
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue