- Dependencies
- Install
- Project structure
- Set up local infrastructure (for testing and development)
- Set up cloud infrastructure (for production)
- Usage of pipelines and other tools
- Inference
- Linting & formatting (QA)
- Tests
- π‘ How to run the project end-to-end
To install and run the project locally, you need the following dependencies (the code was tested with the specified versions of the dependencies):
- pyenv >=2.3.36 (optional: for installing multiple Python versions on your machine)
- Python 3.11
- Poetry >=1.8.3
- Docker >=27.1.1
- aws CLI >=2.15.42
- git >=2.44.0
The code also uses and depends on the following cloud services. For now, you don't have to do anything. We will guide you in the installation and deployment sections on how to use them:
- HuggingFace: Model registry
- Comet ML: Experiment tracker
- Opik (powered by Comet ML): Prompt monitoring
- ZenML: Orchestrator and artifacts layer
- AWS: Compute and storage
- MongoDB: NoSQL database
- Qdrant: Vector database
- GitHub Actions: CI/CD pipeline
In the LLM Engineer's Handbook, Chapter 2 will walk you through each tool, and in Chapters 10 and 11, you will have step-by-step guides on how to set everything you need.
The first step is to clone the repository to your local machine using git
:
git clone https://github.com/PacktPublishing/LLM-Engineers-Handbook.git
cd LLM-Engineers-Handbook
Next, we have to prepare your Python environment and its adjacent dependencies.
If you have a different global Python version than Python 3.11, you can use pyenv to install Python 3.11 only at the project level. Verify your Python version with:
python --version
First, verify that you have pyenv installed:
pyenv --version
# Output: pyenv 2.3.36
Install Python 3.11:
pyenv install 3.11.8
From the root of your repository, run the following to verify that everything works fine:
pyenv versions
# Output:
# system
# * 3.11.8 (set by <path/to/repo>/LLM-Engineers-Handbook/.python-version)
Because we defined a .python-version
file within the repository, pyenv will know to pick up the version from that file and use it locally whenever you are working within that folder. To double-check that, run the following command while you are in the repository:
python --version
# Output: Python 3.11.8
If you move out of this repository, both pyenv versions
and python --version
, might output different Python versions.
The first step is to verify that you have Poetry installed:
poetry --version
# Output: Poetry (version 1.8.3)
We use Poetry to install all the project's requirements to run it locally. Until deploying the code to AWS, we don't need to install any AWS dependencies. Also, we install Poe the Poet as a Poetry plugin to manage our CLI commands and pre-commit to verify our code before committing changes to git:
poetry env use 3.11
poetry install --without aws
poetry self add 'poethepoet[poetry_plugin]'
poetry run pre-commit install
We run all the scripts using Poe the Poet as our task manager.
To activate the environment created by Poetry, run:
poetry shell
Now, letβs configure our local project with all the necessary credentials and tokens to run the code locally.
After you have installed all the dependencies, you must create and fill aΒ .env
file with your credentials to appropriately interact with other services and run the project. Setting your sensitive credentials in a .env
file is a good security practice, as this file wonβt be committed to GitHub or shared with anyone else.
First, copy our example by running the following:
cp .env.example .env # The file must be at your repository's root!
Now, let's understand how to fill in all the essential variables within the .env
file to get you started.
The following are the mandatory settings we must complete when working locally:
To authenticate to OpenAI's API, you must fill out the OPENAI_API_KEY
env var with an authentication token.
β Check out this tutorial to learn how to provide one from OpenAI.
To authenticate to HuggingFace, you must fill out the HUGGINGFACE_ACCESS_TOKEN
env var with an authentication token.
β Check out this tutorial to learn how to provide one from HuggingFace.
Comet ML is required only during training.
To authenticate to Comet ML, you must fill out the COMET_API_KEY
env var with your authentication token.
β Check out this tutorial to learn how to get the Comet ML variables from above.
Opik monitors prompts during production. However, its seamless setup can also make it extremely useful for local development when debugging and testing the LLM and RAG inference logic.
As Opik is developed by Comet ML, we can leverage the COMET_API_KEY
env var issued in the previous step to authenticate. Thus, no additional action is required. Check out π this link to visualize their dashboard.
when deploying the project to the cloud, we must set additional settings for Mongo, Qdrant, and AWS.
If you are just working localy, the default values of these env vars will work out-of-the-box.
We will just highlight what has to be configured, as in Chapter 11 of the LLM Engineer's Handbook we provide step-by-step details on how to deploy the whole system to the cloud.
We must change the DATABASE_HOST
env var with the URL pointing to your cloud MongoDB cluster.
You can easily host a MongoDB cluster for free on their MongoDB serverless platform.
β Check out this tutorial to learn how to create a MongoDB cluster.
Change USE_QDRANT_CLOUD
to True
, QDRANT_CLOUD_URL
with the URL point to your cloud Qdrant cluster, and QDRANT_APIKEY
with its API key.
To work with Qdrant cloud, the env vars will look like this:
USE_QDRANT_CLOUD=true
QDRANT_CLOUD_URL="<your_qdrant_cloud_url>"
QDRANT_APIKEY="<your_qdrant_api_key>"
You can create a Qdrant cluster for free on Qdrant's serverless platform.
β Check out this tutorial to learn how to create a Qdrant cluster.
For your AWS set-up to work correctly, you need the AWS CLI installed on your local machine and properly configured with an admin user (or a user with permission to create new SageMaker, ECR and S3 resources; using an admin user will make everything more straightforward).
In Chapter 2, section Preparing for AWS, we provided step-by-step instructions on how to install the AWS CLI, create an admin user on AWS and get an access key to set up the AWS_ACCESS_KEY
and AWS_SECRET_KEY
environment variables.
If you already have an AWS admin user in place, you have to configure the following env vars in your .env
file:
AWS_REGION="eu-central-1" # Change it with your AWS region.
AWS_ACCESS_KEY="<your_aws_access_key>"
AWS_SECRET_KEY="<your_aws_secret_key>"
AWS credentials are typically stored in ~/.aws/credentials
. You can view this file directly using cat
or similar commands:
cat ~/.aws/credentials
Important
Find more configuration options in the settings.py file. Every variable from the Settings
class can be configured through the .env
file.
Here are the project's core folders that we have to understand:
.
βββ code_snippets/
βββ configs/
βββ llm_engineering/
β βββ application/
β βββ domain/
β βββ infrastructure/
β βββ model/
βββ pipelines/
βββ steps/
βββ tests/
βββ tools/
β βββ run.py
β βββ ml_service.py
β βββ rag.py
llm_engineering/
: The core Python package for the project, containing the main logic for Large Language Models (LLMs), Retrieval-Augmented Generation (RAG), and data collection.
Follows the Domain Driven Design (DDD) pattern, having the following structure:
domain/
: Defines all the entities, structures, and documents.application/
: Application level code, such as crawlers, processing logic and RAG.model/
: Training and inference code.infrastructure/
: Infrastructure code related to AWS, Qdrant, MongoDB, FastAPI and others.
The code logic and imports flow as follows: infrastructure
-> model
-> application
-> domain
pipelines/
: Contains the ZenML ML pipelines, which serve as the entry point for all the ML pipelines. Coordinates the data processing and model training stages of the ML lifecycle.
steps/
: Contains individual ZenML steps, which are reusable components for building and customizing ZenML pipelines. Steps perform specific tasks (e.g., data loading, preprocessing) and can be combined within the ML pipelines.
tests/
: Covers a few sample tests used as examples within the CI pipeline.
tools/
: Utility scripts used to call the ZenML pipelines and inference code.
It contains the following scripts:
run.py
: Entry point script to run ZenML pipelines.ml_service.py
: Starts the REST API inference server.rag.py
: Demonstrates usage of the RAG retrieval module.data_warehouse.py
: Used to export or import data from the MongoDB data warehouse through JSON files..
configs/
: Contains ZenML YAML configuration files to control the execution of pipelines and steps.
code_snippets/
: Holds independent code examples that can be executed independently.
When running the project locally, we host a MongoDB and Qdrant database using Docker. Also, a testing ZenML server is made available through their Python package.
Warning
You need Docker installed (>= v27.1.1)
For ease of use, you can start the whole local development infrastructure with the following command:
poetry poe local-infrastructure-up
Also, you can stop the ZenML server and all the Docker containers using the following command:
poetry poe local-infrastructure-down
Warning
When running on MacOS, before starting the server, export the following environment variable:
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
Otherwise, the connection between the local server and pipeline will break. π More details in this issue.
This is done by default when using Poe the Poet.
Start the inference real-time RESTful API:
poetry poe run-inference-ml-service
Important
The LLM microservice, called by the RESTful API, will work only after deploying the LLM to AWS SageMaker.
Dashboard URL: localhost:8237
Default credentials:
username
: defaultpassword
:
βπ Find more on using and setting up ZenML.
- REST API URL:
localhost:6333
- Dashboard URL:
localhost:6333/dashboard
βπ Find more on using and setting up Qdrant with Docker.
- database URI:
mongodb://llm_engineering:llm_engineering@127.0.0.1:27017
- database name:
twin
Default credentials:
username
: llm_engineeringpassword
: llm_engineering
βπ Find more on using and setting up MongoDB with Docker.
You can search your MongoDB collections using your IDEs MongoDB plugin (which you have to install separately), where you have to use the database URI to connect to the MongoDB database hosted within the Docker container: mongodb://llm_engineering:llm_engineering@127.0.0.1:27017
Important
Everything related to training or running the LLMs (e.g., training, evaluation, inference) can only be run if you set up AWS SageMaker, as explained in the next section on cloud infrastructure.
Here we will quickly present how to deploy the project to AWS and other serverless services. We won't go into the details (as everything is presented in the book) but only point out the main steps you have to go through.
First, reinstall your Python dependencies with the AWS group:
poetry install --with aws
By this point, we expect you to have AWS CLI installed and your AWS CLI and project's env vars (within the .env
file) properly configured with an AWS admin user.
To ensure best practices, we must create a new AWS user restricted to creating and deleting only resources related to AWS SageMaker. Create it by running:
poetry poe create-sagemaker-role
It will create a sagemaker_user_credentials.json
file at the root of your repository with your new AWS_ACCESS_KEY
and AWS_SECRET_KEY
values. But before replacing your new AWS credentials, also run the following command to create the execution role (to create it using your admin credentials).
To create the IAM execution role used by AWS SageMaker to access other AWS resources on our behalf, run the following:
poetry poe create-sagemaker-execution-role
It will create a sagemaker_execution_role.json
file at the root of your repository with your new AWS_ARN_ROLE
value. Add it to your .env
file.
Once you've updated the AWS_ACCESS_KEY
, AWS_SECRET_KEY
, and AWS_ARN_ROLE
values in your .env
file, you can use AWS SageMaker. Note that this step is crucial to complete the AWS setup.
Important
Step-by-step instructions on how to follow these steps are provided in Chapter 10, in the section Implementing the LLM microservice using AWS SageMaker.
We start the training pipeline through ZenML by running the following:
poetry poe run-training-pipeline
This will start the training code using the configs from configs/training.yaml
directly in SageMaker. You can visualize the results in Comet ML's dashboard.
We start the evaluation pipeline through ZenML by running the following:
poetry poe run-evaluation-pipeline
This will start the evaluation code using the configs from configs/evaluating.yaml
directly in SageMaker. You can visualize the results in *-results
datasets saved to your Hugging Face profile.
For creating an AWS SageMaker Inference Endpoint, run:
poetry poe deploy-inference-endpoint
To test it out, run:
poetry poe test-sagemaker-endpoint
To delete it, run:
poetry poe delete-inference-endpoint
Important
Step-by-step instructions on following these steps are in Chapter 10, in the section Implementing the LLM microservice using AWS SageMaker.
The ML pipelines, artifacts and containers are deployed to AWS by leveraging ZenML's deployment features. Thus, you must create an account with ZenML Cloud and follow their guide on deploying a ZenML stack to AWS. Otherwise, we provide step-by-step instructions in Chapter 11, section Deploying the LLM Twin's pipelines to the cloud on what you must do.
We leverage Qdrant's and MongoDB's serverless options when deploying the project. Thus, you can either follow Qdrant's and MongoDB's tutorials on how to create a freemium cluster for each or go through Chapter 11, section Deploying the LLM Twin's pipelines to the cloud and follow our step-by-step instructions.
We use GitHub Actions to implement our CI/CD pipelines. To implement your own, you have to fork our repository and set the following env vars as Actions secrets in your forked repository:
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_ECR_NAME
AWS_REGION
Also, we provide instructions on how to set everything up in Chapter 11, section Adding LLMOps to the LLM Twin.
You can visualize the results on their self-hosted dashboards if you created a Comet account and correctly set the COMET_API_KEY
env var. As Opik is powered by Comet, you don't have to set up anything else along Comet:
All the ML pipelines will be orchestrated behind the scenes by ZenML. A few exceptions exist when running utility scrips, such as exporting or importing from the data warehouse.
The ZenML pipelines are the entry point for most processes throughout this project. They are under the pipelines/
folder. Thus, when you want to understand or debug a workflow, starting with the ZenML pipeline is the best approach.
To see the pipelines running and their results:
- go to your ZenML dashboard
- go to the
Pipelines
section - click on a specific pipeline (e.g.,
feature_engineering
) - click on a specific run (e.g.,
feature_engineering_run_2024_06_20_18_40_24
) - click on a specific step or artifact of the DAG to find more details about it
Now, let's explore all the pipelines you can run. From data collection to training, we will present them in their natural order to go through the LLM project end-to-end.
Run the data collection ETL:
poetry poe run-digital-data-etl
Warning
You must have Chrome (or another Chrome-based browser) installed on your system for LinkedIn and Medium crawlers to work (which use Selenium under the hood). Based on your Chrome version, the Chromedriver will be automatically installed to enable Selenium support. Another option is to run everything using our Docker image if you don't want to install Chrome. For example, to run all the pipelines combined you can run poetry poe run-docker-end-to-end-data-pipeline
. Note that the command can be tweaked to support any other pipeline.
To add additional links to collect from, go to configs/digital_data_etl_[author_name].yaml
and add them to the links
field. Also, you can create a completely new file and specify it at run time, like this: python -m llm_engineering.interfaces.orchestrator.run --run-etl --etl-config-filename configs/digital_data_etl_[your_name].yaml
Run the feature engineering pipeline:
poetry poe run-feature-engineering-pipeline
Generate the instruct dataset:
poetry poe run-generate-instruct-datasets-pipeline
Generate the preference dataset:
poetry poe run-generate-preference-datasets-pipeline
Run all of the above compressed into a single pipeline:
poetry poe run-end-to-end-data-pipeline
Export the data from the data warehouse to JSON files:
poetry poe run-export-data-warehouse-to-json
Import data to the data warehouse from JSON files (by default, it imports the data from the data/data_warehouse_raw_data
directory):
poetry poe run-import-data-warehouse-from-json
Export ZenML artifacts to JSON:
poetry poe run-export-artifact-to-json-pipeline
This will export the following ZenML artifacts to the output
folder as JSON files (it will take their latest version):
- cleaned_documents.json
- instruct_datasets.json
- preference_datasets.json
- raw_documents.json
You can configure what artifacts to export by tweaking the configs/export_artifact_to_json.yaml
configuration file.
Run the training pipeline:
poetry poe run-training-pipeline
Run the evaluation pipeline:
poetry poe run-evaluation-pipeline
Warning
For this to work, make sure you properly configured AWS SageMaker as described in Set up cloud infrastructure (for production).
Call the RAG retrieval module with a test query:
poetry poe call-rag-retrieval-module
Start the inference real-time RESTful API:
poetry poe run-inference-ml-service
Call the inference real-time RESTful API with a test query:
poetry poe call-inference-ml-service
Remember that you can monitor the prompt traces on Opik.
Warning
For the inference service to work, you must have the LLM microservice deployed to AWS SageMaker, as explained in the setup cloud infrastructure section.
Check or fix your linting issues:
poetry poe lint-check
poetry poe lint-fix
Check or fix your formatting issues:
poetry poe format-check
poetry poe format-fix
Check the code for leaked credentials:
poetry poe gitleaks-check
Run all the tests using the following command:
poetry poe test
Based on the setup and usage steps described above, assuming the local and cloud infrastructure works and the .env
is filled as expected, follow the next steps to run the LLM system end-to-end:
-
Collect data:
poetry poe run-digital-data-etl
-
Compute features:
poetry poe run-feature-engineering-pipeline
-
Compute instruct dataset:
poetry poe run-generate-instruct-datasets-pipeline
-
Compute preference alignment dataset:
poetry poe run-generate-preference-datasets-pipeline
Important
From now on, for these steps to work, you need to properly set up AWS SageMaker, such as running poetry install --with aws
and filling in the AWS-related environment variables and configs.
-
SFT fine-tuning Llamma 3.1:
poetry poe run-training-pipeline
-
For DPO, go to
configs/training.yaml
, changefinetuning_type
todpo
, and runpoetry poe run-training-pipeline
again -
Evaluate fine-tuned models:
poetry poe run-evaluation-pipeline
Important
From now on, for these steps to work, you need to properly set up AWS SageMaker, such as running poetry install --with aws
and filling in the AWS-related environment variables and configs.
-
Call only the RAG retrieval module:
poetry poe call-rag-retrieval-module
-
Deploy the LLM Twin microservice to SageMaker:
poetry poe deploy-inference-endpoint
-
Test the LLM Twin microservice:
poetry poe test-sagemaker-endpoint
-
Start end-to-end RAG server:
poetry poe run-inference-ml-service
-
Test RAG server:
poetry poe call-inference-ml-service
This course is an open-source project released under the MIT license. Thus, as long you distribute our LICENSE and acknowledge our work, you can safely clone or fork this project and use it as a source of inspiration for whatever you want (e.g., university projects, college degree projects, personal projects, etc.).