metadata
language:
- en
license: apache-2.0
tags:
- sentence-transformers
- sentence-similarity
- feature-extraction
- generated_from_trainer
- dataset_size:36
- loss:MatryoshkaLoss
- loss:MultipleNegativesRankingLoss
base_model: Snowflake/snowflake-arctic-embed-m-v1.5
widget:
- source_sentence: >-
How do you configure the necessary RBAC resources in Kubernetes to enable
Spark access for managing driver executor pods, and what are the
subsequent steps needed to register the stack component using ZenML?
sentences:
- >-
Google Cloud Image Builder
Building container images with Google Cloud Build
The Google Cloud image builder is an image builder flavor provided by
the ZenML gcp integration that uses Google Cloud Build to build
container images.
When to use it
You should use the Google Cloud image builder if:
you're unable to install or use Docker on your client machine.
you're already using GCP.
your stack is mainly composed of other Google Cloud components such as
the GCS Artifact Store or the Vertex Orchestrator.
How to deploy it
Would you like to skip ahead and deploy a full ZenML cloud stack
already, including the Google Cloud image builder? Check out the
in-browser stack deployment wizard, the stack registration wizard, or
the ZenML GCP Terraform module for a shortcut on how to deploy &
register this stack component.
In order to use the ZenML Google Cloud image builder you need to enable
Google Cloud Build relevant APIs on the Google Cloud project.
How to use it
To use the Google Cloud image builder, we need:
The ZenML gcp integration installed. If you haven't done so, run:
zenml integration install gcp
A GCP Artifact Store where the build context will be uploaded, so Google
Cloud Build can access it.
A GCP container registry where the built image will be pushed.
Optionally, the GCP project ID in which you want to run the build and a
service account with the needed permissions to run the build. If not
provided, then the project ID and credentials will be inferred from the
environment.
Optionally, you can change:
the Docker image used by Google Cloud Build to execute the steps to
build and push the Docker image. By default, the builder image will be
'gcr.io/cloud-builders/docker'.
The network to which the container used to build the ZenML pipeline
Docker image will be attached. More information: Cloud build network.
The build timeout for the build, and for the blocking operation waiting
for the build to finish. More information: Build Timeout.
- |-
_run.steps[step_name]
whylogs_step.visualize()if __name__ == "__main__":
visualize_statistics("data_loader")
visualize_statistics("train_data_profiler", "test_data_profiler")
PreviousEvidentlyNextDevelop a custom data validator
Last updated 1 month ago
- "ngs/python/Dockerfile -u 0 build\n\nConfiguring RBACAdditionally, you may need to create the several resources in Kubernetes in order to give Spark access to edit/manage your driver executor pods.\n\nTo do so, create a file called rbac.yaml with the following content:\n\napiVersion: v1\nkind: Namespace\nmetadata:\n name: spark-namespace\n---\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n name: spark-service-account\n namespace: spark-namespace\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n name: spark-role\n namespace: spark-namespace\nsubjects:\n - kind: ServiceAccount\n name: spark-service-account\n namespace: spark-namespace\nroleRef:\n kind: ClusterRole\n name: edit\n apiGroup: rbac.authorization.k8s.io\n---\n\nAnd then execute the following command to create the resources:\n\naws eks --region=$REGION update-kubeconfig --name=$EKS_CLUSTER_NAME\n\nkubectl create -f rbac.yaml\n\nLastly, 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.\n\nHow to use it\n\nTo use the KubernetesSparkStepOperator, you need:\n\nthe ZenML spark integration. If you haven't installed it already, run\n\nzenml integration install spark\n\nDocker installed and running.\n\nA remote artifact store as part of your stack.\n\nA remote container registry as part of your stack.\n\nA Kubernetes cluster deployed.\n\nWe can then register the step operator and use it in our active stack:\n\nzenml step-operator register spark_step_operator \\\n\t--flavor=spark-kubernetes \\\n\t--master=k8s://$EKS_API_SERVER_ENDPOINT \\\n\t--namespace=<SPARK_KUBERNETES_NAMESPACE> \\\n\t--service_account=<SPARK_KUBERNETES_SERVICE_ACCOUNT>\n\n# Register the stack\nzenml stack register spark_stack \\\n -o default \\\n -s spark_step_operator \\\n -a spark_artifact_store \\\n -c spark_container_registry \\\n -i local_builder \\\n --set"
- source_sentence: >-
What is the function of a ZenML BaseService registry in the context of
model deployment?
sentences:
- >-
🗄️Handle Data/Artifacts
Step outputs in ZenML are stored in the artifact store. This enables
caching, lineage and auditability. Using type annotations helps with
transparency, passing data between steps, and serializing/des
For best results, use type annotations for your outputs. This is good
coding practice for transparency, helps ZenML handle passing data
between steps, and also enables ZenML to serialize and deserialize
(referred to as 'materialize' in ZenML) the data.
@step
def load_data(parameter: int) -> Dict[str, Any]:
training_data = [[1, 2], [3, 4], [5, 6]]
labels = [0, 1, 0]
return {'features': training_data, 'labels': labels}
@step
def train_model(data: Dict[str, Any]) -> None:
total_features = sum(map(sum, data['features']))
total_labels = sum(data['labels'])
print(f"Trained model using {len(data['features'])} data points. "
f"Feature sum is {total_features}, label sum is {total_labels}")
@pipeline
def simple_ml_pipeline(parameter: int):
dataset = load_data(parameter=parameter) # Get the output
train_model(dataset) # Pipe the previous step output into the downstream step
In this code, we define two steps: load_data and train_model. The
load_data step takes an integer parameter and returns a dictionary
containing training data and labels. The train_model step receives the
dictionary from load_data, extracts the features and labels, and trains
a model (not shown here).
Finally, we define a pipeline simple_ml_pipeline that chains the
load_data and train_model steps together. The output from load_data is
passed as input to train_model, demonstrating how data flows between
steps in a ZenML pipeline.
PreviousDisable colorful loggingNextHow ZenML stores data
Last updated 4 months ago
- >-
🧙Installation
Installing ZenML and getting started.
ZenML is a Python package that can be installed directly via pip:
pip install zenml
Note that ZenML currently supports Python 3.8, 3.9, 3.10, and 3.11.
Please make sure that you are using a supported Python version.
Install with the dashboard
ZenML comes bundled with a web dashboard that lives inside a sister
repository. In order to get access to the dashboard locally, you need to
launch the ZenML Server and Dashboard locally. For this, you need to
install the optional dependencies for the ZenML Server:
pip install "zenml[server]"
We highly encourage you to install ZenML in a virtual environment. At
ZenML, We like to use virtualenvwrapper or pyenv-virtualenv to manage
our Python virtual environments.
Installing onto MacOS with Apple Silicon (M1, M2)
A change in how forking works on Macs running on Apple Silicon means
that you should set the following environment variable which will ensure
that your connections to the server remain unbroken:
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
You can read more about this here. This environment variable is needed
if you are working with a local server on your Mac, but if you're just
using ZenML as a client / CLI and connecting to a deployed server then
you don't need to set it.
Nightly builds
ZenML also publishes nightly builds under the zenml-nightly package
name. These are built from the latest develop branch (to which work
ready for release is published) and are not guaranteed to be stable. To
install the nightly build, run:
pip install zenml-nightly
Verifying installations
Once the installation is completed, you can check whether the
installation was successful either through Bash:
zenml version
or through Python:
import zenml
print(zenml.__version__)
If you would like to learn more about the current release, please visit
our PyPi package page.
Running with Docker
- >-
e details of the deployment process from the user.It needs to act as a
ZenML BaseService registry, where every BaseService instance is used as
an internal representation of a remote model server (see the
find_model_server abstract method). To achieve this, it must be able to
re-create the configuration of a BaseService from information that is
persisted externally, alongside, or even as part of the remote model
server configuration itself. For example, for model servers that are
implemented as Kubernetes resources, the BaseService instances can be
serialized and saved as Kubernetes resource annotations. This allows the
model deployer to keep track of all externally running model servers and
to re-create their corresponding BaseService instance representations at
any given time. The model deployer also defines methods that implement
basic life-cycle management on remote model servers outside the coverage
of a pipeline (see stop_model_server , start_model_server and
delete_model_server).
Putting all these considerations together, we end up with the following
interface:
from abc import ABC, abstractmethod
from typing import Dict, List, Optional, Type
from uuid import UUID
from zenml.enums import StackComponentType
from zenml.services import BaseService, ServiceConfig
from zenml.stack import StackComponent, StackComponentConfig, Flavor
DEFAULT_DEPLOYMENT_START_STOP_TIMEOUT = 300
class BaseModelDeployerConfig(StackComponentConfig):
"""Base class for all ZenML model deployer configurations."""
class BaseModelDeployer(StackComponent, ABC):
"""Base class for all ZenML model deployers."""
@abstractmethod
def perform_deploy_model(
self,
id: UUID,
config: ServiceConfig,
timeout: int = DEFAULT_DEPLOYMENT_START_STOP_TIMEOUT,
) -> BaseService:
"""Abstract method to deploy a model."""
- source_sentence: How can I implement the abstract method to deploy a model using ZenML?
sentences:
- >-
> \
--build_timeout=<BUILD_TIMEOUT_IN_SECONDS># Register and set a stack with the new image builder
zenml stack register <STACK_NAME> -i <IMAGE_BUILDER_NAME> ... --set
Caveats
As described in this Google Cloud Build documentation page, Google Cloud
Build uses containers to execute the build steps which are automatically
attached to a network called cloudbuild that provides some Application
Default Credentials (ADC), that allow the container to be authenticated
and therefore use other GCP services.
By default, the GCP Image Builder is executing the build command of the
ZenML Pipeline Docker image with the option --network=cloudbuild, so the
ADC provided by the cloudbuild network can also be used in the build.
This is useful if you want to install a private dependency from a GCP
Artifact Registry, but you will also need to use a custom base parent
image with the keyrings.google-artifactregistry-auth installed, so pip
can connect and authenticate in the private artifact registry to
download the dependency.
FROM zenmldocker/zenml:latest
RUN pip install keyrings.google-artifactregistry-auth
The above Dockerfile uses zenmldocker/zenml:latest as a base image, but
is recommended to change the tag to specify the ZenML version and Python
version like 0.33.0-py3.10.
PreviousKaniko Image BuilderNextDevelop a Custom Image Builder
Last updated 21 days ago
- >-
:
"""Abstract method to deploy a model."""@staticmethod
@abstractmethod
def get_model_server_info(
service: BaseService,
) -> Dict[str, Optional[str]]:
"""Give implementation-specific way to extract relevant model server
properties for the user."""
@abstractmethod
def perform_stop_model(
self,
service: BaseService,
timeout: int = DEFAULT_DEPLOYMENT_START_STOP_TIMEOUT,
force: bool = False,
) -> BaseService:
"""Abstract method to stop a model server."""
@abstractmethod
def perform_start_model(
self,
service: BaseService,
timeout: int = DEFAULT_DEPLOYMENT_START_STOP_TIMEOUT,
) -> BaseService:
"""Abstract method to start a model server."""
@abstractmethod
def perform_delete_model(
self,
service: BaseService,
timeout: int = DEFAULT_DEPLOYMENT_START_STOP_TIMEOUT,
force: bool = False,
) -> None:
"""Abstract method to delete a model server."""
class BaseModelDeployerFlavor(Flavor):
"""Base class for model deployer flavors."""
@property
@abstractmethod
def name(self):
"""Returns the name of the flavor."""
@property
def type(self) -> StackComponentType:
"""Returns the flavor type.
Returns:
The flavor type.
"""
return StackComponentType.MODEL_DEPLOYER
@property
def config_class(self) -> Type[BaseModelDeployerConfig]:
"""Returns `BaseModelDeployerConfig` config class.
Returns:
The config class.
"""
return BaseModelDeployerConfig
@property
@abstractmethod
def implementation_class(self) -> Type[BaseModelDeployer]:
"""The class that implements the model deployer."""
This is a slimmed-down version of the base implementation which aims to
highlight the abstraction layer. In order to see the full implementation
and get the complete docstrings, please check the SDK docs .
Building your own model deployers
- >-
se you decide to switch to another Data Validator.All you have to do is
call the whylogs Data Validator methods when you need to interact with
whylogs to generate data profiles. You may optionally enable whylabs
logging to automatically upload the returned whylogs profile to WhyLabs,
e.g.:
import pandas as pd
from whylogs.core import DatasetProfileView
from zenml.integrations.whylogs.data_validators.whylogs_data_validator
import (
WhylogsDataValidator,
)
from zenml.integrations.whylogs.flavors.whylogs_data_validator_flavor
import (
WhylogsDataValidatorSettings,
)
from zenml import step
whylogs_settings = WhylogsDataValidatorSettings(
enable_whylabs=True, dataset_id="<WHYLABS_DATASET_ID>"
)
@step(
settings={
"data_validator": whylogs_settings
}
)
def data_profiler(
dataset: pd.DataFrame,
) -> DatasetProfileView:
"""Custom data profiler step with whylogs
Args:
dataset: a Pandas DataFrame
Returns:
Whylogs profile generated for the data
"""
here
data_validator = WhylogsDataValidator.get_active_data_validator()
profile = data_validator.data_profiling(
dataset,
)
data_validator.upload_profile_view(profile)
happen here
return profile
Have a look at the complete list of methods and parameters available in
the WhylogsDataValidator API in the SDK docs.
Call whylogs directly
You can use the whylogs library directly in your custom pipeline steps,
and only leverage ZenML's capability of serializing, versioning and
storing the DatasetProfileView objects in its Artifact Store. You may
optionally enable whylabs logging to automatically upload the returned
whylogs profile to WhyLabs, e.g.:
- source_sentence: >-
How can I register and configure a GCP Service Connector for accessing GCP
Cloud Build services in ZenML?
sentences:
- |-
System Architectures
Different variations of the ZenML architecture depending on your needs.
PreviousZenML ProNextZenML SaaS
Last updated 21 days ago
- >-
quired for your GCP Image Builder by running e.g.:zenml
service-connector list-resources --resource-type gcp-generic
Example Command Output
The following 'gcp-generic' resources can be accessed by service
connectors that you have configured:
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┓
┃ CONNECTOR ID │ CONNECTOR NAME │ CONNECTOR TYPE
│ RESOURCE TYPE │ RESOURCE NAMES ┃
┠──────────────────────────────────────┼────────────────┼────────────────┼────────────────┼────────────────┨
┃ bfdb657d-d808-47e7-9974-9ba6e4919d83 │ gcp-generic │ 🔵 gcp
│ 🔵 gcp-generic │ zenml-core ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┛
After having set up or decided on a GCP Service Connector to use to
authenticate to GCP, you can register the GCP Image Builder as follows:
zenml image-builder register <IMAGE_BUILDER_NAME> \
--flavor=gcp \
--cloud_builder_image=<BUILDER_IMAGE_NAME> \
--network=<DOCKER_NETWORK> \
--build_timeout=<BUILD_TIMEOUT_IN_SECONDS>
zenml image-builder connect <IMAGE_BUILDER_NAME> -i
A non-interactive version that connects the GCP Image Builder to a
target GCP Service Connector:
zenml image-builder connect <IMAGE_BUILDER_NAME> --connector
<CONNECTOR_ID>
Example Command Output
- >2-
your GCP Image Builder to the GCP cloud platform.To set up the GCP Image Builder to authenticate to GCP and access the GCP Cloud Build services, it is recommended to leverage the many features provided by the GCP Service Connector such as auto-configuration, best security practices regarding long-lived credentials and reusing the same credentials across multiple stack components.
If you don't already have a GCP Service Connector configured in your
ZenML deployment, you can register one using the interactive CLI
command. You also have the option to configure a GCP Service Connector
that can be used to access more than just the GCP Cloud Build service:
zenml service-connector register --type gcp -i
A non-interactive CLI example that leverages the Google Cloud CLI
configuration on your local machine to auto-configure a GCP Service
Connector for the GCP Cloud Build service:
zenml service-connector register <CONNECTOR_NAME> --type gcp
--resource-type gcp-generic --resource-name <GCS_BUCKET_NAME>
--auto-configure
Example Command Output
$ zenml service-connector register gcp-generic --type gcp
--resource-type gcp-generic --auto-configure
Successfully registered service connector `gcp-generic` with access to
the following resources:
┏━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━━┓
┃ RESOURCE TYPE │ RESOURCE NAMES ┃
┠────────────────┼────────────────┨
┃ 🔵 gcp-generic │ zenml-core ┃
┗━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━━┛
Note: Please remember to grant the entity associated with your GCP
credentials permissions to access the Cloud Build API and to run Cloud
Builder jobs (e.g. the Cloud Build Editor IAM role). The GCP Service
Connector supports many different authentication methods with different
levels of security and convenience. You should pick the one that best
fits your use case.
If you already have one or more GCP Service Connectors configured in
your ZenML deployment, you can check which of them can be used to access
generic GCP resources like the GCP Image Builder required for your GCP
Image Builder by running e.g.:
- source_sentence: >-
How can ZenML be used to finetune LLMs for specific tasks or to improve
their performance and cost?
sentences:
- >2-
build to finish. More information: Build Timeout.We can register the image builder and use it in our active stack:
zenml image-builder register <IMAGE_BUILDER_NAME> \
--flavor=gcp \
--cloud_builder_image=<BUILDER_IMAGE_NAME> \
--network=<DOCKER_NETWORK> \
--build_timeout=<BUILD_TIMEOUT_IN_SECONDS>
zenml stack register <STACK_NAME> -i <IMAGE_BUILDER_NAME> ... --set
You also need to set up authentication required to access the Cloud
Build GCP services.
Authentication Methods
Integrating and using a GCP Image Builder in your pipelines is not
possible without employing some form of authentication. If you're
looking for a quick way to get started locally, you can use the Local
Authentication method. However, the recommended way to authenticate to
the GCP cloud platform is through a GCP Service Connector. This is
particularly useful if you are configuring ZenML stacks that combine the
GCP Image Builder with other remote stack components also running in
GCP.
This method uses the implicit GCP authentication available in the
environment where the ZenML code is running. On your local machine, this
is the quickest way to configure a GCP Image Builder. You don't need to
supply credentials explicitly when you register the GCP Image Builder,
as it leverages the local credentials and configuration that the Google
Cloud CLI stores on your local machine. However, you will need to
install and set up the Google Cloud CLI on your machine as a
prerequisite, as covered in the Google Cloud documentation , before you
register the GCP Image Builder.
Stacks using the GCP Image Builder set up with local authentication are
not portable across environments. To make ZenML pipelines fully
portable, it is recommended to use a GCP Service Connector to
authenticate your GCP Image Builder to the GCP cloud platform.
- |-
Finetuning LLMs with ZenML
Finetune LLMs for specific tasks or to improve performance and cost.
PreviousEvaluating finetuned embeddingsNextSet up a project repository
Last updated 6 months ago
- >-
Spark
Executing individual steps on Spark
The spark integration brings two different step operators:
Step Operator: The SparkStepOperator serves as the base class for all
the Spark-related step operators.
Step Operator: The KubernetesSparkStepOperator is responsible for
launching ZenML steps as Spark applications with Kubernetes as a cluster
manager.
Step Operators: SparkStepOperator
A summarized version of the implementation can be summarized in two
parts. First, the configuration:
from typing import Optional, Dict, Any
from zenml.step_operators import BaseStepOperatorConfig
class SparkStepOperatorConfig(BaseStepOperatorConfig):
"""Spark step operator config.
Attributes:
master: is the master URL for the cluster. You might see different
schemes for different cluster managers which are supported by Spark
like Mesos, YARN, or Kubernetes. Within the context of this PR,
the implementation supports Kubernetes as a cluster manager.
deploy_mode: can either be 'cluster' (default) or 'client' and it
decides where the driver node of the application will run.
submit_kwargs: is the JSON string of a dict, which will be used
to define additional params if required (Spark has quite a
lot of different parameters, so including them, all in the step
operator was not implemented).
"""
master: str
deploy_mode: str = "cluster"
submit_kwargs: Optional[Dict[str, Any]] = None
and then the implementation:
from typing import List
from pyspark.conf import SparkConf
from zenml.step_operators import BaseStepOperator
class SparkStepOperator(BaseStepOperator):
"""Base class for all Spark-related step operators."""
def _resource_configuration(
self,
spark_config: SparkConf,
resource_configuration: "ResourceSettings",
) -> None:
"""Configures Spark to handle the resource configuration."""
pipeline_tag: sentence-similarity
library_name: sentence-transformers
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
model-index:
- name: zenml/finetuned-snowflake-arctic-embed-m-v1.5
results:
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 384
type: dim_384
metrics:
- type: cosine_accuracy@1
value: 1
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 1
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 1
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 1
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 1
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.3333333333333333
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.2
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.1
name: Cosine Precision@10
- type: cosine_recall@1
value: 1
name: Cosine Recall@1
- type: cosine_recall@3
value: 1
name: Cosine Recall@3
- type: cosine_recall@5
value: 1
name: Cosine Recall@5
- type: cosine_recall@10
value: 1
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 1
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 1
name: Cosine Mrr@10
- type: cosine_map@100
value: 1
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 256
type: dim_256
metrics:
- type: cosine_accuracy@1
value: 1
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 1
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 1
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 1
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 1
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.3333333333333333
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.2
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.1
name: Cosine Precision@10
- type: cosine_recall@1
value: 1
name: Cosine Recall@1
- type: cosine_recall@3
value: 1
name: Cosine Recall@3
- type: cosine_recall@5
value: 1
name: Cosine Recall@5
- type: cosine_recall@10
value: 1
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 1
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 1
name: Cosine Mrr@10
- type: cosine_map@100
value: 1
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 128
type: dim_128
metrics:
- type: cosine_accuracy@1
value: 1
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 1
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 1
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 1
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 1
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.3333333333333333
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.2
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.1
name: Cosine Precision@10
- type: cosine_recall@1
value: 1
name: Cosine Recall@1
- type: cosine_recall@3
value: 1
name: Cosine Recall@3
- type: cosine_recall@5
value: 1
name: Cosine Recall@5
- type: cosine_recall@10
value: 1
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 1
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 1
name: Cosine Mrr@10
- type: cosine_map@100
value: 1
name: Cosine Map@100
- task:
type: information-retrieval
name: Information Retrieval
dataset:
name: dim 64
type: dim_64
metrics:
- type: cosine_accuracy@1
value: 1
name: Cosine Accuracy@1
- type: cosine_accuracy@3
value: 1
name: Cosine Accuracy@3
- type: cosine_accuracy@5
value: 1
name: Cosine Accuracy@5
- type: cosine_accuracy@10
value: 1
name: Cosine Accuracy@10
- type: cosine_precision@1
value: 1
name: Cosine Precision@1
- type: cosine_precision@3
value: 0.3333333333333333
name: Cosine Precision@3
- type: cosine_precision@5
value: 0.2
name: Cosine Precision@5
- type: cosine_precision@10
value: 0.1
name: Cosine Precision@10
- type: cosine_recall@1
value: 1
name: Cosine Recall@1
- type: cosine_recall@3
value: 1
name: Cosine Recall@3
- type: cosine_recall@5
value: 1
name: Cosine Recall@5
- type: cosine_recall@10
value: 1
name: Cosine Recall@10
- type: cosine_ndcg@10
value: 1
name: Cosine Ndcg@10
- type: cosine_mrr@10
value: 1
name: Cosine Mrr@10
- type: cosine_map@100
value: 1
name: Cosine Map@100
Then you can load this model and run inference.
