Aviary
Aviary is a gymnasium for defining custom language agent RL environments. The library features pre-existing environments on math , general knowledge , biological sequences , scientific literature search , and protein stability. Aviary is designed to work in tandem with its sister library LDP (https://github.com/Future-House/ldp) which enables the user to define custom language agents as Language Decision Processes. See the following tutorial for an example of how to run an LDP language agent on an Aviary environment.
Overview | Getting Started | Documentation | Paper
What's New?
We have a new environment to run Jupyter notebooks at packages/notebook.
Overview
A pictorial overview of the five implemented Aviary environments and the language decision process framework.
Getting Started
To install aviary (note fh stands for FutureHouse):
pip install fhaviaryTo install aviary together with the incumbent environments:
pip install 'fhaviary[gsm8k,hotpotqa,labbench,lfrqa,notebook]'To run the tutorial notebooks:
Developer Installation
For local development, please see CONTRIBUTING.md.
Tutorial Notebooks
Defining a Custom Environment
The example below walks through defining a custom environment in Aviary. We define a simple environment where an agent takes actions to modify a counter. The example is also featured in the following notebook.
Evaluating an Agent on the Environment
Following the definition of our custom environment, we can now evaluate a language agent on the environment using Aviary's sister library LDP (https://github.com/Future-House/ldp).
Below we expand on some of the core components of the Aviary library together with more advanced usage examples.
Environment
An environment should have two methods, env.reset and env.step:
Communication is achieved through messages.
The action_msg is an instance of ToolRequestMessage which comprises one or more calls to the tools returned by env.reset method.
The obs_msgs are either general obseravation messages or instances of ToolResponseMessage returned from the environment. while reward is a scalar value, and done and truncated are Boolean values.
We explain the message formalism in further detail below.
Messages
Communication between the agent and environment is achieved via messages. We follow the OpenAI standard. Messages have two attributes:
The content attribute can be a string but can also comprise objects such as images. For example, the create_message method can be used to create a message with images:
In this case, content will be a list of dictionaries with the keys text and image_url.
The role, see the table below. You can change around roles as desired, except for tool which has a special meaning in aviary.
assistant
Agent
An agent's tool selection message
system
Agent system prompt
"You are an agent."
user
Environment system prompt or emitted observation
HotPotQA problem to solve, or details of an internal env failure
tool
Result of a tool run in the environment
The output of the calculator tool for a GSM8K question
The Message class is extended in ToolRequestMessage and ToolResponseMessage to include the relevant tool name and arguments.
Subclassing Environments
If you need more control over Environments and tools, you may wish to subclass Environment. We illustrate this with an example environment in which an agent is tasked to write a story.
We subclass Environment and define a state. The state consists of all variables that change per step that we wish to bundle together. It will be accessible in tools, so you can use state to store information you want to persist between steps and tool calls.
We do not have other variables aside from state for this environment, although we could also have variables like configuration, a name, tasks, etc. attached to it.
Defining Tools
We will define a single tool that prints a story. Tools may optionally take a final argument state which is the environment state. This argument will not be exposed to the agent as a parameter but will be injected by the environment (if part of the function signature).
The tool is built from the following parts of the function: its name, its argument's names, the arguments types, and the docstring. The docstring is parsed to obtain a description of the function and its arguments, so be sure to match the syntax carefully.
Environment episode completion is indicated by setting state.done = True. This example terminates immediately - other termination conditions are also possible.
It is also possible make the function async - the environment will account for that when the tool is called.
Advanced Tool Descriptions
Aviary also supports more sophisticated signatures:
Multiline docstrings
Non-primitive type hints (e.g. type unions)
Default values
Exclusion of info below
\f(see below)
If you have summary-level information that belongs in the docstring, but you don't want it to be part of the Tool.info.description, add a r prefix to the docstring and inject \f before the summary information to exclude. This convention was created by FastAPI (docs).
The Environment reset Method
reset MethodNext we define the reset function which initializes the tools and returns one or more initial observations as well as the tools. The reset function is async to allow for database interactions or HTTP requests.
The Environment step Method
step MethodNext we define the step function which takes an action and returns the next observation, reward, done, and whether the episode was truncated.
You will probably often use this specific syntax for calling the tools - calling exec_tool_calls with the action.
Environment export_frame Method
export_frame MethodOptionally, we can define a function to export a snapshot of the environment and its state for visualization or debugging purposes.
Viewing Environment Tools
If an environment can be instantiated without anything other than the task (i.e., it implements from_task), you can start a server to view its tools:
This will start a server that allows you to view the tools and call them, viewing the descriptions/types and output that an agent would see when using the tools.
Incumbent Environments
Below we list some pre-existing environments implemented in Aviary:
Task Datasets
Included with some environments are collections of problems that define training or evaluation datasets. We refer to these as TaskDatasets, e.g. for the HotpotQADataset subclass of TaskDataset:
Functional Environments
An alternative way to create an environment is using the functional interface, which uses functions and decorators to define environments. Let's define an environment that requires an agent to write a story about a particular topic by implementing its start function:
The start decorator begins the definition of an environment.
The function, my_env, takes an arbitrary input and returns a tuple containing the first observation and any information you wish to store about the environment state (used to persist/share information between tools).
The state will always have an optional reward and a Boolean done that indicate if the environment episode is complete. Next we define some tools:
The tools will be converted into objects visible for LLMs using the type hints and the variable descriptions. Thus, the type hinting can be valuable for an agent that uses it correctly. The docstrings are also passed to the LLM and is the primary means (along with the function name) for communicating the intended tool usage.
You can access the state variable in tools, which will have any fields you passed in the return tuple of start(). For example, if you returned {'foo': 'bar'}, then you could access state.foo in the tools.
You may stop an environment or set a reward via the state variable as shown in the second print_story tool. If the reward is not set, it is treated as zero. Next we illustrate how to use our environment:
Citing Aviary
If Aviary is useful for your work please consider citing the following paper:
References
Last updated



