langroid 0.1.12

Harness LLMs with Multi-Agent Programming

Langroid

Contributors:

• Prasad Chalasani (Independent ML Consultant)
• Somesh Jha (Professor of CS, U Wisc at Madison)
• Mohannad Alhanahnah (Research Associate, U Wisc at Madison)
• Ashish Hooda (PhD Candidate, U Wisc at Madison)

Set up dev env

We use poetry to manage dependencies, and python 3.11 for development.

First install poetry, then create virtual env and install dependencies:

# clone this repo and cd into repo root
git clone ...
cd <repo_root>
# create a virtual env under project root, .venv directory
python3 -m venv .venv

# activate the virtual env
. .venv/bin/activate

# use poetry to install dependencies (these go into .venv dir)
poetry install

# To be able to run `dockerchat` you need some extras:
poetry install -E docker

To add packages, use poetry add <package-name>. This will automatically find the latest compatible version of the package and add it to pyproject. toml. Do not manually edit pyproject.toml to add packages.

Set up environment variables (API keys, etc

Copy the .env-template file to a new file .env and insert these secrets:

• OpenAI API key,
• GitHub Personal Access Token (needed by PyGithub to analyze git repos; token-based API calls are less rate-limited).
• Redis Password (ask @pchalasani for this) for the redis cache.
• Qdrant API key (ask @pchalasani for this) for the vector db.

cp .env-template .env
# now edit the .env file, insert your secrets as above

Currently only OpenAI models are supported. Others will be added later.

Run tests

To verify your env is correctly setup, run all tests using make tests.

Generate docs (private only for now)

Generate docs: make docs, then go to the IP address shown at the end, like http://127.0.0.1:8000/ Note this runs a docs server in the background. To stop it, run make nodocs. Also, running make docs next time will kill any previously running mkdocs server.

Contributing, and Pull requests

In this Python repository, we prioritize code readability and maintainability. To ensure this, please adhere to the following guidelines when contributing:

1. Type-Annotate Code: Add type annotations to function signatures and variables to make the code more self-explanatory and to help catch potential issues early. For example, def greet(name: str) -> str:.

2. Google-Style Docstrings: Use Google-style docstrings to clearly describe the purpose, arguments, and return values of functions. For example:

   def greet(name: str) -> str:
       """Generate a greeting message.
   
       Args:
           name (str): The name of the person to greet.
   
       Returns:
           str: The greeting message.
       """
       return f"Hello, {name}!"
   

3. PEP8-Compliant 80-Char Max per Line: Follow the PEP8 style guide and keep lines to a maximum of 80 characters. This improves readability and ensures consistency across the codebase.

If you are using an LLM to write code for you, adding these instructions will usually get you code compliant with the above:

use type-annotations, google-style docstrings, and pep8 compliant max 80 
     chars per line.

By following these practices, we can create a clean, consistent, and easy-to-understand codebase for all contributors. Thank you for your cooperation!

To check for issues locally, run make check, it runs linters black, ruff, flake8 and type-checker mypy. Issues flagged by black can usually be auto-fixed using black ., and to fix ruff issues, do:

poetry run ruff . --fix

• When you run this, black may warn that some files would be reformatted. If so, you should just run black . to reformat them. Also,
• flake8 may warn about some issues; read about each one and fix those issues.

You can also run make lint to (try to) auto-tix black and ruff issues.

So, typically when submitting a PR, you would do this sequence:

• run pytest tests -nc (-nc means "no cache", i.e. do not use cached LLM API call responses)
• fix things so tests pass, then proceed to lint/style/type checks
• make check to see what issues there are
• make lint to auto-fix some of them
• make check again to see what issues remain
• possibly manually fix flake8 issues, and any mypy issues flagged.
• make check again to see if all issues are fixed.
• repeat if needed, until all clean.

When done with these, git-commit, push to github and submit the PR. If this is an ongoing PR, just push to github again and the PR will be updated.

Strongly recommend to use the gh command-line utility when working with git. Read more here.

Run some examples

There are now several examples under examples and examples_dev. They are typically run with python3 examples/.../chat.py, but sometimes the app name may not be chat.py. Generally speaking, these commands can take additional command-line options, e.g.:

• -nc to disable using cached LLM responses (i.e. forces fresh response)
• -d or --debug to see more output
• -f to enable using OpenAI function-calling instead of Langroid tools.

Here are some apps to try (others will be described later):

"Chat" with a set of URLs.

python3 examples/docqa/chat.py

Ask a question you want answered based on the URLs content. The default URLs are about various articles and discussions on LLM-based agents, compression and intelligence. If you are using the default URLs, try asking:

who is Pattie Maes?

and then a follow-up question:

what did she build?

"Chat" with a code repo, given the GitHub URL

python3 examples_dev/codechat/codechat.py

For the default URL, try asking:

What version of python is used?

"chat"-based dockerfile creator.

This is a 3-agent system to generate a docker file for a (Python) github repo.

python3 examples_dev/dockerfile/chat.py

Logs of multi-agent interactions

When running a multi-agent chat, e.g. using task.run(), two types of logs are generated:

• plain-text logs in logs/<task_name>.log
• tsv logs in logs/<task_name>.tsv

We will go into details of inter-agent chat structure in another place, but for now it is important to realize that the logs show every attempt at responding to the current pending message, even those that are not allowed. The ones marked with an asterisk (*) are the ones that are considered the responses for a given step() (which is a "turn" in the conversation).

The plain text logs have color-coding ANSI chars to make them easier to read by doing less <log_file>. The format is:

(TaskName) Responder SenderEntity (EntityName) (=> Recipient) TOOL Content

The structure of the tsv logs is similar. A great way to view these is to install and use visidata (https://www.visidata.org/):

vd logs/<task_name>.tsv