metadata
base_model: Snowflake/snowflake-arctic-embed-m
datasets: []
language:
- en
library_name: sentence-transformers
license: apache-2.0
metrics:
- cosine_accuracy@1
- cosine_accuracy@3
- cosine_accuracy@5
- cosine_accuracy@10
- cosine_precision@1
- cosine_precision@3
- cosine_precision@5
- cosine_precision@10
- cosine_recall@1
- cosine_recall@3
- cosine_recall@5
- cosine_recall@10
- cosine_ndcg@10
- cosine_mrr@10
- cosine_map@100
pipeline_tag: sentence-similarity
tags:
- sentence-transformers
- sentence-similarity
- feature-extraction
- generated_from_trainer
- dataset_size:1490
- loss:MatryoshkaLoss
- loss:MultipleNegativesRankingLoss
widget:
- source_sentence: >-
How does ZenML facilitate connecting your deployment to various cloud
providers and infrastructure services?
sentences:
- >-
🔌Connect services (AWS, GCP, Azure, K8s etc)
Connect your ZenML deployment to a cloud provider and other
infrastructure services and resources.
A production-grade MLOps platform involves interactions between a
diverse combination of third-party libraries and external services
sourced from various different vendors. One of the most daunting hurdles
in building and operating an MLOps platform composed of multiple
components is configuring and maintaining uninterrupted and secured
access to the infrastructure resources and services that it consumes.
In layman's terms, your pipeline code needs to "connect" to a handful of
different services to run successfully and do what it's designed to do.
For example, it might need to connect to a private AWS S3 bucket to read
and store artifacts, a Kubernetes cluster to execute steps with Kubeflow
or Tekton, and a private GCR container registry to build and store
container images. ZenML makes this possible by allowing you to configure
authentication information and credentials embedded directly into your
Stack Components, but this doesn't scale well when you have more than a
few Stack Components and has many other disadvantages related to
usability and security.
Gaining access to infrastructure resources and services requires
knowledge about the different authentication and authorization
mechanisms and involves configuring and maintaining valid credentials.
It gets even more complicated when these different services need to
access each other. For instance, the Kubernetes container running your
pipeline step needs access to the S3 bucket to store artifacts or needs
to access a cloud service like AWS SageMaker, VertexAI, or AzureML to
run a CPU/GPU intensive task like training a model.
- >2-
┃┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ ID │
e316bcb3-6659-467b-81e5-5ec25bfd36b0
┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ NAME │
aws-sts-token
┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ TYPE │ 🔶
aws ┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ AUTH METHOD │
sts-token
┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ RESOURCE TYPES │ 🔶 aws-generic, 📦 s3-bucket, 🌀
kubernetes-cluster, 🐳 docker-registry ┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ RESOURCE NAME │
<multiple>
┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ SECRET ID │
971318c9-8db9-4297-967d-80cda070a121
┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ SESSION DURATION │
N/A
┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ EXPIRES IN │
11h58m17s
┃
┠──────────────────┼─────────────────────────────────────────────────────────────────────────┨
┃ OWNER │
default
┃
- >-
io ┃
┗━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┛If you already have one or more
Docker Service Connectors configured in your ZenML deployment, you can
check which of them can be used to access the container registry you
want to use for your Default Container Registry by running e.g.:
zenml service-connector list-resources --connector-type docker
--resource-id <REGISTRY_URI>
Example Command Output
$ zenml service-connector list-resources --connector-type docker
--resource-id docker.io
The resource with name 'docker.io' can be accessed by 'docker' service
connectors configured in your workspace:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┓
┃ CONNECTOR ID │ CONNECTOR NAME │ CONNECTOR TYPE
│ RESOURCE TYPE │ RESOURCE NAMES ┃
┠──────────────────────────────────────┼────────────────┼────────────────┼────────────────────┼────────────────┨
┃ cf55339f-dbc8-4ee6-862e-c25aff411292 │ dockerhub │ 🐳 docker
│ 🐳 docker-registry │ docker.io ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┛
After having set up or decided on a Docker Service Connector to use to
connect to the target container registry, you can register the Docker
Container Registry as follows:
zenml container-registry register <CONTAINER_REGISTRY_NAME> -f default \
--uri=<REGISTRY_URL>
Service Connector
zenml container-registry connect <CONTAINER_REGISTRY_NAME> -i
A non-interactive version that connects the Default Container Registry
to a target registry through a Docker Service Connector:
zenml container-registry connect <CONTAINER_REGISTRY_NAME> --connector
<CONNECTOR_ID>
Example Command Output
$ zenml container-registry connect dockerhub --connector dockerhub
- source_sentence: >-
How can I configure the orchestrator settings for each cloud provider in
ZenML?
sentences:
- >-
kip scoping its Resource Type during registration.a multi-instance
Service Connector instance can be configured once and used to gain
access to multiple resources of the same type, each identifiable by a
Resource Name. Not all types of connectors and not all types of
resources support multiple instances. Some Service Connectors Types like
the generic Kubernetes and Docker connector types only allow
single-instance configurations: a Service Connector instance can only be
used to access a single Kubernetes cluster and a single Docker registry.
To configure a multi-instance Service Connector, you can simply skip
scoping its Resource Name during registration.
The following is an example of configuring a multi-type AWS Service
Connector instance capable of accessing multiple AWS resources of
different types:
zenml service-connector register aws-multi-type --type aws
--auto-configure
Example Command Output
⠋ Registering service connector 'aws-multi-type'...
Successfully registered service connector `aws-multi-type` with access
to the following resources:
┏━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ RESOURCE TYPE │ RESOURCE NAMES ┃
┠───────────────────────┼──────────────────────────────────────────────┨
┃ 🔶 aws-generic │ us-east-1 ┃
┠───────────────────────┼──────────────────────────────────────────────┨
┃ 📦 s3-bucket │ s3://aws-ia-mwaa-715803424590 ┃
┃ │ s3://zenfiles ┃
┃ │ s3://zenml-demos ┃
┃ │ s3://zenml-generative-chat ┃
┃ │ s3://zenml-public-datasets ┃
┃ │ s3://zenml-public-swagger-spec ┃
┠───────────────────────┼──────────────────────────────────────────────┨
┃ 🌀 kubernetes-cluster │ zenhacks-cluster ┃
- >-
ister <STACK_NAME> -a <AZURE_STORE_NAME> ... --setWhen you register the
Azure Artifact Store, you can create a ZenML Secret to store a variety
of Azure credentials and then reference it in the Artifact Store
configuration:
to use an Azure storage account key , set account_name to your account
name and one of account_key or sas_token to the Azure key or SAS token
value as attributes in the ZenML secret
to use an Azure storage account key connection string , configure the
connection_string attribute in the ZenML secret to your Azure Storage
Key connection string
to use Azure Service Principal credentials , create an Azure Service
Principal and then set account_name to your account name and client_id,
client_secret and tenant_id to the client ID, secret and tenant ID of
your service principal in the ZenML secret
This method has some advantages over the implicit authentication method:
you don't need to install and configure the Azure CLI on your host
you don't need to care about enabling your other stack components
(orchestrators, step operators and model deployers) to have access to
the artifact store through Azure Managed Identities
you can combine the Azure artifact store with other stack components
that are not running in Azure
Configuring Azure credentials in a ZenML secret and then referencing
them in the Artifact Store configuration could look like this:
zenml secret create az_secret \
--account_name='<YOUR_AZURE_ACCOUNT_NAME>' \
--account_key='<YOUR_AZURE_ACCOUNT_KEY>'
zenml secret create az_secret \
--connection_string='<YOUR_AZURE_CONNECTION_STRING>'
zenml secret create az_secret \
--account_name='<YOUR_AZURE_ACCOUNT_NAME>' \
--tenant_id='<YOUR_AZURE_TENANT_ID>' \
--client_id='<YOUR_AZURE_CLIENT_ID>' \
--client_secret='<YOUR_AZURE_CLIENT_SECRET>'
- >-
. If not set, the cluster will not be autostopped.down: Tear down the
cluster after all jobs finish (successfully or abnormally). If
idle_minutes_to_autostop is also set, the cluster will be torn down
after the specified idle time. Note that if errors occur during
provisioning/data syncing/setting up, the cluster will not be torn down
for debugging purposes.
stream_logs: If True, show the logs in the terminal as they are
generated while the cluster is running.
docker_run_args: Additional arguments to pass to the docker run command.
For example, ['--gpus=all'] to use all GPUs available on the VM.
The following code snippets show how to configure the orchestrator
settings for each cloud provider:
Code Example:
from
zenml.integrations.skypilot_aws.flavors.skypilot_orchestrator_aws_vm_flavor
import SkypilotAWSOrchestratorSettings
skypilot_settings = SkypilotAWSOrchestratorSettings(
cpus="2",
memory="16",
accelerators="V100:2",
accelerator_args={"tpu_vm": True, "runtime_version": "tpu-vm-base"},
use_spot=True,
spot_recovery="recovery_strategy",
region="us-west-1",
zone="us-west1-a",
image_id="ami-1234567890abcdef0",
disk_size=100,
disk_tier="high",
cluster_name="my_cluster",
retry_until_up=True,
idle_minutes_to_autostop=60,
down=True,
stream_logs=True
docker_run_args=["--gpus=all"]
@pipeline(
settings={
"orchestrator.vm_aws": skypilot_settings
Code Example:
from
zenml.integrations.skypilot_gcp.flavors.skypilot_orchestrator_gcp_vm_flavor
import SkypilotGCPOrchestratorSettings
skypilot_settings = SkypilotGCPOrchestratorSettings(
cpus="2",
memory="16",
accelerators="V100:2",
accelerator_args={"tpu_vm": True, "runtime_version": "tpu-vm-base"},
use_spot=True,
spot_recovery="recovery_strategy",
region="us-west1",
zone="us-west1-a",
image_id="ubuntu-pro-2004-focal-v20231101",
disk_size=100,
disk_tier="high",
cluster_name="my_cluster",
retry_until_up=True,
idle_minutes_to_autostop=60,
down=True,
stream_logs=True
@pipeline(
settings={
"orchestrator.vm_gcp": skypilot_settings
- source_sentence: >-
What command do you use to create the resources after setting up the
roleRef for a Kubernetes cluster?
sentences:
- >-
pace: spark-namespace
roleRef:
kind: ClusterRolename: edit
apiGroup: rbac.authorization.k8s.io
---
And then execute the following command to create the resources:
aws eks --region=$REGION update-kubeconfig --name=$EKS_CLUSTER_NAME
kubectl create -f rbac.yaml
Lastly, note down the namespace and the name of the service account
since you will need them when registering the stack component in the
next step.
How to use it
To use the KubernetesSparkStepOperator, you need:
the ZenML spark integration. If you haven't installed it already,
runCopyzenml integration install spark
Docker installed and running.
A remote artifact store as part of your stack.
A remote container registry as part of your stack.
A Kubernetes cluster deployed.
We can then register the step operator and use it in our active stack:
zenml step-operator register spark_step_operator \
--flavor=spark-kubernetes \
--master=k8s://$EKS_API_SERVER_ENDPOINT \
--namespace=<SPARK_KUBERNETES_NAMESPACE> \
--service_account=<SPARK_KUBERNETES_SERVICE_ACCOUNT>
zenml stack register spark_stack \
o default \
s spark_step_operator \
a spark_artifact_store \
c spark_container_registry \
i local_builder \
--set
Once you added the step operator to your active stack, you can use it to
execute individual steps of your pipeline by specifying it in the @step
decorator as follows:
from zenml import step
@step(step_operator=<STEP_OPERATOR_NAME>)
def step_on_spark(...) -> ...:
"""Some step that should run with Spark on Kubernetes."""
...
After successfully running any step with a KubernetesSparkStepOperator,
you should be able to see that a Spark driver pod was created in your
cluster for each pipeline step when running kubectl get pods -n
$KUBERNETES_NAMESPACE.
Instead of hardcoding a step operator name, you can also use the Client
to dynamically use the step operator of your active stack:
from zenml.client import Client
step_operator = Client().active_stack.step_operator
@step(step_operator=step_operator.name)
- >-
et_historical_features(entity_dict, features)
...Note that ZenML's use of Pydantic to serialize and deserialize inputs
stored in the ZenML metadata means that we are limited to basic data
types. Pydantic cannot handle Pandas DataFrames, for example, or
datetime values, so in the above code you can see that we have to
convert them at various points.
For more information and a full list of configurable attributes of the
Feast feature store, check out the SDK Docs .
PreviousFeature Stores
NextDevelop a Custom Feature Store
Last updated 8 days ago
- >-
to get a quick global overview of our performance.# passing the results
from all our previous evaluation steps
@step(enable_cache=False)
def visualize_evaluation_results(
small_retrieval_eval_failure_rate: float,
small_retrieval_eval_failure_rate_reranking: float,
full_retrieval_eval_failure_rate: float,
full_retrieval_eval_failure_rate_reranking: float,
failure_rate_bad_answers: float,
failure_rate_bad_immediate_responses: float,
failure_rate_good_responses: float,
average_toxicity_score: float,
average_faithfulness_score: float,
average_helpfulness_score: float,
average_relevance_score: float,
) -> Optional[Image.Image]:
"""Visualizes the evaluation results."""
step_context = get_step_context()
pipeline_run_name = step_context.pipeline_run.name
normalized_scores = [
score / 20
for score in [
small_retrieval_eval_failure_rate,
small_retrieval_eval_failure_rate_reranking,
full_retrieval_eval_failure_rate,
full_retrieval_eval_failure_rate_reranking,
failure_rate_bad_answers,
scores = normalized_scores + [
failure_rate_bad_immediate_responses,
failure_rate_good_responses,
average_toxicity_score,
average_faithfulness_score,
average_helpfulness_score,
average_relevance_score,
labels = [
"Small Retrieval Eval Failure Rate",
"Small Retrieval Eval Failure Rate Reranking",
"Full Retrieval Eval Failure Rate",
"Full Retrieval Eval Failure Rate Reranking",
"Failure Rate Bad Answers",
"Failure Rate Bad Immediate Responses",
"Failure Rate Good Responses",
"Average Toxicity Score",
"Average Faithfulness Score",
"Average Helpfulness Score",
"Average Relevance Score",
fig, ax = plt.subplots(figsize=(10, 6))
y_pos = np.arange(len(labels))
ax.barh(y_pos, scores, align="center")
ax.set_yticks(y_pos)
ax.set_yticklabels(labels)
ax.invert_yaxis()
ax.set_xlabel("Score")
ax.set_xlim(0, 5)
ax.set_title(f"Evaluation Metrics for {pipeline_run_name}")
# Adjust the layout
plt.tight_layout()
- source_sentence: >-
What is the command to register and connect a Vertex AI Orchestrator Stack
Component to the target GCP project using ZenML?
sentences:
- >-
ggingFaceModelDeployer.get_active_model_deployer()# fetch existing
services with same pipeline name, step name and model name
existing_services = model_deployer.find_model_server(
pipeline_name=pipeline_name,
pipeline_step_name=pipeline_step_name,
model_name=model_name,
running=running,
if not existing_services:
raise RuntimeError(
f"No Hugging Face inference endpoint deployed by step "
f"'{pipeline_step_name}' in pipeline '{pipeline_name}' with name "
f"'{model_name}' is currently running."
return existing_services[0]
@step
def predictor(
service: HuggingFaceDeploymentService,
data: str
) -> Annotated[str, "predictions"]:
"""Run a inference request against a prediction service"""
prediction = service.predict(data)
return prediction
@pipeline
def huggingface_deployment_inference_pipeline(
pipeline_name: str, pipeline_step_name: str =
"huggingface_model_deployer_step",
):
inference_data = ...
model_deployment_service = prediction_service_loader(
pipeline_name=pipeline_name,
pipeline_step_name=pipeline_step_name,
predictions = predictor(model_deployment_service, inference_data)
For more information and a full list of configurable attributes of the
Hugging Face Model Deployer, check out the SDK Docs.
PreviousBentoML
NextDevelop a Custom Model Deployer
Last updated 15 days ago
- >-
Set up CI/CD
Managing the lifecycle of a ZenML pipeline with Continuous Integration
and Delivery
Until now, we have been executing ZenML pipelines locally. While this is
a good mode of operating pipelines, in production it is often desirable
to mediate runs through a central workflow engine baked into your CI.
This allows data scientists to experiment with data processing and model
training locally and then have code changes automatically tested and
validated through the standard pull request/merge request peer review
process. Changes that pass the CI and code-review are then deployed
automatically to production. Here is how this could look like:
Breaking it down
To illustrate this, let's walk through how this process might be set up
on a GitHub Repository.
A data scientist wants to make improvements to the ML pipeline. They
clone the repository, create a new branch, and experiment with new
models or data processing steps on their local machine.
Once the data scientist thinks they have improved the pipeline, they
create a pull request for their branch on GitHub. This automatically
triggers a GitHub Action that will run the same pipeline in the staging
environment (e.g. a pipeline running on a cloud stack in GCP),
potentially with different test data. As long as the pipeline does not
run successfully in the staging environment, the PR cannot be merged.
The pipeline also generates a set of metrics and test results that are
automatically published to the PR, where they can be peer-reviewed to
decide if the changes should be merged.
Once the PR has been reviewed and passes all checks, the branch is
merged into main. This automatically triggers another GitHub Action that
now runs a pipeline in the production environment, which trains the same
model on production data, runs some checks to compare its performance
with the model currently served in production and then, if all checks
pass, automatically deploys the new model.
- >-
━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┛
```register and connect a Vertex AI Orchestrator Stack Component to the
target GCP projectNOTE: If we do not specify a workload service account,
the Vertex AI Pipelines Orchestrator uses the Compute Engine default
service account in the target project to run pipelines. You must grant
this account the Vertex AI Service Agent role, otherwise the pipelines
will fail. More information on other configurations possible for the
Vertex AI Orchestrator can be found here.Copyzenml orchestrator register
vertex-ai-zenml-core --flavor=vertex --location=europe-west1
--synchronous=true
Example Command Output
```text
Running with active workspace: 'default' (repository)
Running with active stack: 'default' (repository)
Successfully registered orchestrator `vertex-ai-zenml-core`.
```
```sh
zenml orchestrator connect vertex-ai-zenml-core --connector
vertex-ai-zenml-core
```
Example Command Output
```text
Running with active workspace: 'default' (repository)
Running with active stack: 'default' (repository)
Successfully connected orchestrator `vertex-ai-zenml-core` to the
following resources:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┓
┃ CONNECTOR ID │ CONNECTOR NAME │
CONNECTOR TYPE │ RESOURCE TYPE │ RESOURCE NAMES ┃
┠──────────────────────────────────────┼──────────────────────┼────────────────┼────────────────┼────────────────┨
┃ f97671b9-8c73-412b-bf5e-4b7c48596f5f │ vertex-ai-zenml-core │ 🔵
gcp │ 🔵 gcp-generic │ zenml-core ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┛
```
Register and connect a GCP Container Registry Stack Component to a GCR
container registry:Copyzenml container-registry register gcr-zenml-core
--flavor gcp --uri=gcr.io/zenml-core
Example Command Output
```text
Running with active workspace: 'default' (repository)
- source_sentence: How can I develop a custom step operator in ZenML?
sentences:
- >-
Develop a Custom Step Operator
Learning how to develop a custom step operator.
Before diving into the specifics of this component type, it is
beneficial to familiarize yourself with our general guide to writing
custom component flavors in ZenML. This guide provides an essential
understanding of ZenML's component flavor concepts.
Base Abstraction
The BaseStepOperator is the abstract base class that needs to be
subclassed in order to run specific steps of your pipeline in a separate
environment. As step operators can come in many shapes and forms, the
base class exposes a deliberately basic and generic interface:
from abc import ABC, abstractmethod
from typing import List, Type
from zenml.enums import StackComponentType
from zenml.stack import StackComponent, StackComponentConfig, Flavor
from zenml.config.step_run_info import StepRunInfo
class BaseStepOperatorConfig(StackComponentConfig):
"""Base config for step operators."""
class BaseStepOperator(StackComponent, ABC):
"""Base class for all ZenML step operators."""
@abstractmethod
def launch(
self,
info: StepRunInfo,
entrypoint_command: List[str],
) -> None:
"""Abstract method to execute a step.
Subclasses must implement this method and launch a **synchronous**
job that executes the `entrypoint_command`.
Args:
info: Information about the step run.
entrypoint_command: Command that executes the step.
"""
class BaseStepOperatorFlavor(Flavor):
"""Base class for all ZenML step operator flavors."""
@property
@abstractmethod
def name(self) -> str:
"""Returns the name of the flavor."""
@property
def type(self) -> StackComponentType:
"""Returns the flavor type."""
return StackComponentType.STEP_OPERATOR
@property
def config_class(self) -> Type[BaseStepOperatorConfig]:
"""Returns the config class for this flavor."""
return BaseStepOperatorConfig
@property
@abstractmethod
def implementation_class(self) -> Type[BaseStepOperator]:
- >-
-grade deployments.
Installing the mlstacks extraTo install mlstacks, either run pip install
mlstacks or pip install "zenml[mlstacks]" to install it along with
ZenML.
MLStacks uses Terraform on the backend to manage infrastructure. You
will need to have Terraform installed. Please visit the Terraform docs
for installation instructions.
MLStacks also uses Helm to deploy Kubernetes resources. You will need to
have Helm installed. Please visit the Helm docs for installation
instructions.
Deploying a stack component
The ZenML CLI allows you to deploy individual stack components using the
deploy subcommand which is implemented for all supported stack
components. You can find the list of supported stack components here.
Deploying a stack
For deploying a full stack, use the zenml stack deploy command. See the
stack deployment page for more details of which cloud providers and
stack components are supported.
How does mlstacks work?
MLStacks is built around the concept of a stack specification. A stack
specification is a YAML file that describes the stack and includes
references to component specification files. A component specification
is a YAML file that describes a component. (Currently all deployments of
components (in various combinations) must be defined within the context
of a stack.)
ZenML handles the creation of stack specifications for you when you run
one of the deploy subcommands using the CLI. A valid specification is
generated and used by mlstacks to deploy your stack using Terraform. The
Terraform definitions and state are stored in your global configuration
directory along with any state files generated while deploying your
stack.
Your configuration directory could be in a number of different places
depending on your operating system, but read more about it in the Click
docs to see which location applies to your situation.
Deploy stack components individuallyIndividually deploying different
stack components.
- >-
rray": [[1,2,3,4]] } }'
Using a Service ConnectorTo set up the Seldon Core Model Deployer to
authenticate to a remote Kubernetes cluster, it is recommended to
leverage the many features provided by the Service Connectors such as
auto-configuration, local client login, best security practices
regarding long-lived credentials and fine-grained access control and
reusing the same credentials across multiple stack components.
Depending on where your target Kubernetes cluster is running, you can
use one of the following Service Connectors:
the AWS Service Connector, if you are using an AWS EKS cluster.
the GCP Service Connector, if you are using a GKE cluster.
the Azure Service Connector, if you are using an AKS cluster.
the generic Kubernetes Service Connector for any other Kubernetes
cluster.
If you don't already have a Service Connector configured in your ZenML
deployment, you can register one using the interactive CLI command. You
have the option to configure a Service Connector that can be used to
access more than one Kubernetes cluster or even more than one type of
cloud resource:
zenml service-connector register -i
A non-interactive CLI example that leverages the AWS CLI configuration
on your local machine to auto-configure an AWS Service Connector
targeting a single EKS cluster is:
zenml service-connector register <CONNECTOR_NAME> --type aws
--resource-type kubernetes-cluster --resource-name <EKS_CLUSTER_NAME>
--auto-configure
Example Command Output
$ zenml service-connector register eks-zenhacks --type aws
--resource-type kubernetes-cluster --resource-id zenhacks-cluster
--auto-configure
⠼ Registering service connector 'eks-zenhacks'...
Successfully registered service connector `eks-zenhacks` with access to
the following resources:
┏━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━━━┓
┃ RESOURCE TYPE │ RESOURCE NAMES ┃
┠───────────────────────┼──────────────────┨
┃ 🌀 kubernetes-cluster │ zenhacks-cluster ┃
┗━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━━━┛
model-index:
- name: zenml/finetuned-snowflake-arctic-embed-m
results:
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 384
type: dim_384
metrics:
- type: cosine_accuracy@1
value: 0.29518072289156627
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.6385542168674698
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.7228915662650602
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.7891566265060241
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.29518072289156627
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.21285140562248994
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.14457831325301201
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.0789156626506024
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.29518072289156627
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.6385542168674698
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.7228915662650602
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.7891566265060241
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.5552191347520903
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.47847819850831885
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.48706201897841145
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 256
type: dim_256
metrics:
- type: cosine_accuracy@1
value: 0.3253012048192771
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.6144578313253012
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.6987951807228916
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.7891566265060241
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.3253012048192771
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.2048192771084337
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.1397590361445783
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.0789156626506024
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.3253012048192771
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.6144578313253012
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.6987951807228916
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.7891566265060241
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.5597682297824715
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.4859987569324918
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.4930658557873217
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 128
type: dim_128
metrics:
- type: cosine_accuracy@1
value: 0.2710843373493976
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.5662650602409639
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.6385542168674698
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.7891566265060241
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.2710843373493976
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.18875502008032125
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.12771084337349395
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.0789156626506024
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.2710843373493976
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.5662650602409639
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.6385542168674698
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.7891566265060241
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.5242689178594545
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.4403614457831327
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.4468744710389297
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 64
type: dim_64
metrics:
- type: cosine_accuracy@1
value: 0.25301204819277107
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 0.4759036144578313
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 0.5783132530120482
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 0.6626506024096386
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 0.25301204819277107
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.15863453815261042
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.11566265060240961
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.06626506024096386
name: Cosine Precision@10
- type: cosine_recall@1
value: 0.25301204819277107
name: Cosine Recall@1
- type: cosine_recall@3
value: 0.4759036144578313
name: Cosine Recall@3
- type: cosine_recall@5
value: 0.5783132530120482
name: Cosine Recall@5
- type: cosine_recall@10
value: 0.6626506024096386
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 0.45397796379806826
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 0.38746175176898084
name: Cosine Mrr@10
- type: cosine_map@100
value: 0.39859357699776915
name: Cosine Map@100
Then you can load this model and run inference.
