In AG2, agents use LLMs as key components to understand and react. To configure an agent’s access to LLMs, you can specify an llm_config argument in its constructor. For example, the following snippet shows a configuration that uses gpt-4o:
Different tasks may require different models, and the config_list allows specifying the different endpoints and configurations that are to be used. It is a list of dictionaries, each of which contains the following keys depending on the kind of endpoint being used:
OpenAI
Azure OpenAI
Other OpenAI compatible
api_type (str, required): The model provider
model (str, required): The identifier of the model to be used, such as ‘gpt-4o’, ‘gpt-4o-mini’.
api_key (str, optional): The API key required for authenticating requests to the model’s API endpoint.
base_url (str, optional): The base URL of the API endpoint. This is the root address where API calls are directed.
tags (List[str], optional): Tags which can be used for filtering.
A common, useful pattern used is to define this config_list via JSON (specified as a file or an environment variable set to a JSON-formatted string) and then use the from_json method to load it:
llm_config = autogen.LLMConfig.from_json( env="OAI_CONFIG_LIST", # Or path="path/to/config.json")# Then, create the assistant agent with the configwith llm_config: assistant = autogen.AssistantAgent(name="assistant")
This can be helpful as it keeps all the configuration in one place across different projects or notebooks.This function interprets the env_or_file argument as follows:
If env_or_file is an environment variable then:
It will first try to load the file from the path specified in the environment variable.
If there is no file, it will try to interpret the environment variable as a JSON string.
Otherwise, it will try to open the file at the path specified by env_or_file.
Being a list allows you to define multiple models that can be used by the agent. This is useful for a few reasons:
If one model times out or fails, the agent can try another model.
Having a single global list of models and filtering it based on certain keys (e.g. name, tag) in order to pass select models into a certain agent (e.g. use cheaper GPT 4o-mini for agents solving easier tasks)
While the core agents, (e.g. conversable or assistant) do not have special logic around selecting configs, some of the specialized agents may have logic to select the best model based on the task at hand.
How does an agent decide which model to pick out of the list?
An agent uses the very first model available in the “config_list” and makes LLM calls against this model. If the model fails (e.g. API throttling) the agent will retry the request against the 2nd model and so on until prompt completion is received (or throws an error if none of the models successfully completes the request). In general there’s no implicit/hidden logic inside agents that is used to pick “the best model for the task”. However, some specialized agents may attempt to choose “the best model for the task”. It is developers responsibility to pick the right models and use them with agents.
As described above the list can be filtered based on certain criteria. This is defined as a dictionary of key to filter on and values to filter by. For example, if you have a list of configs and you want to select the one with the model “gpt-4o-mini” you can use the following filter:
filter_dict = {"model": ["gpt-4o-mini"]}
This can then be applied to a config when constructing LLM_CONFIG with where method:
Model names can differ between OpenAI and Azure OpenAI, so tags offer an easy way to smooth over this inconsistency. Tags are a list of strings in the config_list, for example for the following config_list:
Then when filtering the config_list you can can specify the desired tags. A config is selected if it has at least one of the tags specified in the filter. For example, to just get the llama model, you can use the following filter:
In AG2, a deepcopy is used on llm_config to ensure that the llm_config passed by user is not modified internally. You may get an error if the llm_config contains objects of a class that do not support deepcopy. To fix this, you need to implement a __deepcopy__ method for the class.The below example shows how to implement a __deepcopy__ method for http client and add a proxy.
Besides the config_list, there are other parameters that can be used to configure the LLM. These are split between parameters specifically used by Autogen and those passed into the model client.
cache_seed - This is a legacy parameter and not recommended to be used unless the reason for using it is to disable the default caching behavior. To disable default caching, set this to None. Otherwise, by default or if an int is passed the DiskCache will be used. For the new way of using caching, pass a Cache object into initiate_chat.
It is also possible to passthrough parameters through to the OpenAI client. Parameters that correspond to the OpenAI client or the OpenAI completions create API can be supplied.This is commonly used for things like temperature, or timeout.
get_config_list: Generates configurations for API calls, primarily from provided API keys.
config_list_openai_aoai: Constructs a list of configurations using both Azure OpenAI and OpenAI endpoints, sourcing API keys from environment variables or local files.
config_list_from_models: Creates configurations based on a provided list of models, useful when targeting specific models without manually specifying each configuration.
config_list_from_dotenv: Constructs a configuration list from a .env file, offering a consolidated way to manage multiple API configurations and keys from a single file.
See this notebook for examples of using the above functions.