[!NOTE]
The Canopy team is no longer maintaining this repository. Thank you for your support and enthusiasm for the project! If you're looking for a high quality managed RAG solution with continued updates and improvements, please check out the Pinecone Assistant.
Canopy is an open-source Retrieval Augmented Generation (RAG) framework and context engine built on top of the Pinecone vector database. Canopy enables you to quickly and easily experiment with and build applications using RAG. Start chatting with your documents or text data with a few simple commands.
Canopy takes on the heavy lifting for building RAG applications: from chunking and embedding your text data to chat history management, query optimization, context retrieval (including prompt engineering), and augmented generation.
Canopy provides a configurable built-in server so you can effortlessly deploy a RAG-powered chat application to your existing chat UI or interface. Or you can build your own, custom RAG application using the Canopy library.
Canopy lets you evaluate your RAG workflow with a CLI based chat tool. With a simple command in the Canopy CLI you can interactively chat with your text data and compare RAG vs. non-RAG workflows side-by-side.
Check out our blog post to learn more, or see a quick tutorial here.
Canopy implements the full RAG workflow to prevent hallucinations and augment your LLM with your own text data.
Canopy has two flows: knowledge base creation and chat. In the knowledge base creation flow, users upload their documents and transform them into meaningful representations stored in Pinecone's Vector Database. In the chat flow, incoming queries and chat history are optimized to retrieve the most relevant documents, the knowledge base is queried, and a meaningful context is generated for the LLM to answer.
ChatEngine
formulates relevant queries to the ContextEngine
, then uses the LLM to generate a knowledgeable response.ContextEngine
utilizes the underlying KnowledgeBase
to retrieve the most relevant documents, then formulates a coherent textual context to be used as a prompt for the LLM. More information about the Core Library usage can be found in the Library Documentation
Canopy Server - This is a webservice that wraps the Canopy Core library and exposes it as a REST API. The server is built on top of FastAPI, Uvicorn and Gunicorn and can be easily deployed in production.
The server also comes with a built-in Swagger UI for easy testing and documentation. After you start the server, you can access the Swagger UI at http://host:port/docs
(default: http://localhost:8000/docs
)
set up a virtual environment (optional)
python3 -m venv canopy-env
source canopy-env/bin/activate
More information about virtual environments can be found here
install the package
pip install canopy-sdk
export PINECONE_API_KEY="<PINECONE_API_KEY>"
export OPENAI_API_KEY="<OPENAI_API_KEY>"
export INDEX_NAME="<INDEX_NAME>"
canopy
Output should be similar to this:
Canopy: Ready
Usage: canopy [OPTIONS] COMMAND [ARGS]...
# rest of the help message
In this quickstart, we will show you how to use the Canopy to build a simple question answering system using RAG (retrieval augmented generation).
As a one-time setup, Canopy needs to create a new Pinecone index that is configured to work with Canopy, just run:
canopy new
And follow the CLI instructions. The index that will be created will have a prefix canopy--<INDEX_NAME>
.
You only have to do this process once for every Canopy index you want to create.
To learn more about Pinecone indexes and how to manage them, please refer to the following guide: Understanding indexes
You can load data into your Canopy index using the command:
canopy upsert /path/to/data_directory
# or
canopy upsert /path/to/data_directory/file.parquet
# or
canopy upsert /path/to/data_directory/file.jsonl
# or
canopy upsert /path/to/directory_of_txt_files/
# ...
Canopy supports files in jsonl
, parquet
and csv
formats. Additionally, you can load plaintext data files in .txt
format. In this case, each file will be treated as a single document. The document id will be the filename, and the source will be the full path of the file.
Note: Document fields are used in the RAG flow and should comply with the following schema:
+----------+--------------+--------------+---------------+
| id(str) | text(str) | source | metadata |
| | | Optional[str]| Optional[dict]|
|----------+--------------+--------------+---------------|
| "id1" | "some text" | "some source"| {"key": "val"}|
+----------+--------------+--------------+---------------+
# id - unique identifier for the document
#
# text - the text of the document, in utf-8 encoding.
#
# source - the source of the document, can be any string, or null.
# ** this will be used as a reference in the generated context. **
#
# metadata - optional metadata for the document, for filtering or additional context.
# Dict[str, Union[str, int, float, List[str]]]
This notebook shows how you create a dataset in this format, Follow the instructions in the CLI when you upload your data.
[!TIP] If you would like to separate your data into namespaces, you can use the
--namespace
option or theINDEX_NAMESPACE
environment variable.
The Canopy server exposes Canopy's functionality via a REST API. Namely, it allows you to upload documents, retrieve relevant docs for a given query, and chat with your data. The server exposes a /chat.completion
endpoint that can be easily integrated with any chat application.
To start the server, run:
canopy start
Now, you should be prompted with the following standard Uvicorn message:
...
INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
That's it! you can now start using the Canopy server with any chat application that supports a /chat.completion
endpoint.
The canopy start command will keep the terminal occupied (recommended use). If you want to run the server in the background, you can use the following command -
nohup canopy start &
To stop the server, simply press CTRL+C
in the terminal where you started it.
Canopy's CLI comes with a built-in chat app that allows you to interactively chat with your text data and compare RAG vs. non-RAG workflows side-by-side to evaluate the results
In a new terminal window, set the required environment variables then run:
canopy chat
This will open a chat interface in your terminal. You can ask questions and the RAG-infused chatbot will try to answer them using the data you uploaded.
To compare the chat response with and without RAG use the --no-rag
flag
Note: This method is only supported with OpenAI at the moment.
canopy chat --no-rag
This will open a similar chat interface window, but will show both the RAG and non-RAG responses side-by-side.
Thank you for considering contributing to Canopy! Please see our contributing guidelines for more information.
If you already have an application that uses the OpenAI API, you can migrate it to Canopy by simply changing the API endpoint to http://host:port/v1
, for example with the default configuration:
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1")
If you would like to use a specific index namespace for chatting, you can just append the namespace to the API endpoint:
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1/my-namespace")
Canopy is using FastAPI as the web framework and Uvicorn as the ASGI server.
To use Canopy in production, it is recommended to utilize Canopy's docker image, available on GitHub Packages,
for your production needs.
For guidance on deploying Canopy on the Google Cloud Platform (GCP), refer to the example provided in the
Deployment to GCP documentation.
Alternatively, you can use Gunicorn as production-grade WSGI, more details here.
Set your desired PORT
and WORKER_COUNT
envrionment variables, and start the server with:
gunicorn canopy_server.app:app --worker-class uvicorn.workers.UvicornWorker --bind 0.0.0.0:$PORT --workers $WORKER_COUNT
[!IMPORTANT] The server interacts with services like Pinecone and OpenAI using your own authentication credentials. When deploying the server on a public web hosting provider, it is recommended to enable an authentication mechanism, so that your server would only take requests from authenticated users.