mlflow.langchain

mlflow.langchain 模块提供了一个用于记录和加载 LangChain 模型的 API。该模块以 langchain 风格导出多元 LangChain 模型，并以 pyfunc 风格导出单变量 LangChain 模型：

LangChain (原生) 格式

这是可以通过 LangChain API 访问的主要风格。

mlflow.pyfunc

为基于通用 pyfunc 的部署工具和批量推理而生成。

mlflow.langchain.autolog(log_input_examples=False, log_model_signatures=False, log_models=False, log_datasets=False, log_inputs_outputs=None, disable=False, exclusive=False, disable_for_unsupported_versions=False, silent=False, registered_model_name=None, extra_tags=None, extra_model_classes=None, log_traces=True)[源代码]

备注

实验性功能：此功能可能在未来的版本中无警告地更改或移除。

备注

Autologging 已知与以下包版本兼容：0.1.0 <= langchain <= 0.3.1。使用此范围之外的包版本时，Autologging 可能无法成功。

启用（或禁用）并配置从 Langchain 到 MLflow 的自动日志记录。

参数:

  • log_input_examples – 如果 True，推理数据中的输入示例将与Langchain模型工件一起收集并记录在推理过程中。如果 False，则不记录输入示例。注意：输入示例是MLflow模型属性，只有在 log_models 也是 True 时才会收集。

  • log_model_signatures – 如果 True，在推理过程中，描述模型输入和输出的 模型签名 将与 Langchain 模型工件一起收集和记录。如果 False，则不记录签名。注意：模型签名是 MLflow 模型属性，只有在 log_models 也为 True 时才会收集。

  • log_models – 如果 True，langchain 模型会被记录为 MLflow 模型工件。如果 False，langchain 模型不会被记录。当 log_models 为 False 时，输入示例和模型签名（MLflow 模型的属性）也会被省略。

  • log_datasets – 如果 True，则在适用的情况下将数据集信息记录到 MLflow 跟踪中。如果 False，则不记录数据集信息。

  • log_inputs_outputs – 已弃用 用于记录推理输入和输出的传统参数。此参数将在MLflow的未来版本中移除。替代方法是使用``log_traces``，它记录Langchain模型的跟踪信息，包括每个阶段的输入和输出。如果为``True``，推理数据和结果将合并到一个pandas DataFrame中，并作为工件记录到MLflow跟踪中。如果为``False``，推理数据和结果将不会被记录。默认为``False``。

  • disable – 如果 True，禁用 Langchain 自动日志记录集成。如果 False，启用 Langchain 自动日志记录集成。

  • exclusive – 如果 True ，自动记录的内容不会记录到用户创建的 fluent 运行中。如果 False ，自动记录的内容会记录到活动的 fluent 运行中，这可能是用户创建的。

  • disable_for_unsupported_versions – 如果 True，则对未经过此版本 MLflow 客户端测试或不兼容的 langchain 版本禁用自动日志记录。

  • silent – 如果 True，在 Langchain 自动记录期间抑制 MLflow 的所有事件日志和警告。如果 False，在 Langchain 自动记录期间显示所有事件和警告。

  • registered_model_name – 如果提供，每次训练模型时，它都会被注册为具有此名称的已注册模型的新的模型版本。如果该注册模型尚不存在，则会创建它。

  • extra_tags – 一个字典，包含要为 autologging 创建的每个托管运行设置的额外标签。

  • extra_model_classes – 除了默认类之外，要记录的 langchain 类列表。我们不保证此列表中指定的类可以作为模型记录，但将支持跟踪。请注意，列表中的所有类都必须是 Runnable 的子类，并且我们仅对 invoke、batch 和 stream 方法进行跟踪补丁。

  • log_traces – 如果 True，则在推理期间使用 MlflowLangchainTracer 作为回调来记录 Langchain 模型的跟踪。如果 False，则在推理期间不收集跟踪。默认为 True。

mlflow.langchain.get_default_conda_env()[源代码]
返回:

通过调用 save_model() 和 log_model() 生成的 MLflow 模型的默认 Conda 环境。

mlflow.langchain.get_default_pip_requirements()[源代码]
返回:

此flavor生成的MLflow模型的默认pip需求列表。调用 save_model() 和 log_model() 会生成一个pip环境，该环境至少包含这些需求。

mlflow.langchain.load_model(model_uri, dst_path=None)[源代码]

备注

实验性功能：此功能可能在未来的版本中无警告地更改或移除。

备注

‘langchain’ MLflow 模型集成已知与以下包版本范围兼容：0.0.354 - 0.3.1。当使用此范围之外的包版本时，MLflow 模型与 langchain 的集成可能不会成功。

从本地文件或运行中加载一个 LangChain 模型。

参数:

  • model_uri – MLflow 模型的位置，采用 URI 格式。例如： - /Users/me/path/to/local/model - relative/path/to/local/model - s3://my_bucket/path/to/model - runs:/<mlflow_run_id>/run-relative/path/to/model 有关支持的 URI 方案的更多信息，请参阅 引用工件。

  • dst_path – 下载模型工件的本地文件系统路径。此目录必须已经存在。如果未指定，将创建一个本地输出路径。

返回:

一个 LangChain 模型实例。

mlflow.langchain.log_model(lc_model, artifact_path, conda_env=None, code_paths=None, registered_model_name=None, signature: ModelSignature = None, input_example: DataFrame | ndarray | dict | list | csr_matrix | csc_matrix | str | bytes | tuple = None, await_registration_for=300, pip_requirements=None, extra_pip_requirements=None, metadata=None, loader_fn=None, persist_dir=None, example_no_conversion=None, run_id=None, model_config=None, streamable=None, resources=None)[源代码]

备注

实验性功能：此功能可能在未来的版本中无警告地更改或移除。

备注

‘langchain’ MLflow 模型集成已知与以下包版本范围兼容：0.0.354 - 0.3.1。当使用此范围之外的包版本时，MLflow 模型与 langchain 的集成可能不会成功。

将 LangChain 模型记录为当前运行的 MLflow 工件。

参数:

  • lc_model – 一个LangChain模型，可以是 Chain、Agent、或 retriever，或者是包含上述类型 LangChain模型代码 的路径。当使用模型路径时，确保通过 mlflow.models.set_model() 设置模型。.. 注意:: 实验性：使用模型路径可能在未来的版本中无警告地更改或移除。

  • artifact_path – 运行相对的工件路径。

  • conda_env –

    一个Conda环境的字典表示形式，或Conda环境yaml文件的路径。如果提供，这将描述模型应运行的环境。至少，它应指定包含在 get_default_conda_env() 中的依赖项。如果为 None，则通过 mlflow.models.infer_pip_requirements() 推断的pip要求添加一个conda环境到模型中。如果要求推断失败，则回退到使用 get_default_pip_requirements()。来自 conda_env 的pip要求被写入一个pip requirements.txt 文件，完整的conda环境被写入 conda.yaml。以下是一个conda环境的字典表示形式的*示例*:

    {
    "name": "mlflow-env",
    "channels": ["conda-forge"],
    "dependencies": [
        "python=3.8.15",
        {
            "pip": [
                "langchain==x.y.z"
            ],
        },
    ],
}

  • code_paths – 本地文件系统路径列表，指向Python文件依赖项（或包含文件依赖项的目录）。这些文件在加载模型时会被*前置*到系统路径中。如果为给定模型声明了依赖关系，则应从公共根路径声明相对导入，以避免在加载模型时出现导入错误。有关``code_paths``功能的详细解释、推荐的使用模式和限制，请参阅`code_paths使用指南 <https://mlflow.org/docs/latest/model/dependencies.html?highlight=code_paths#saving-extra-code-with-an-mlflow-model>`_。

  • registered_model_name – 此参数可能在未来的版本中更改或移除，且不会提前警告。如果提供，将在 registered_model_name 下创建一个模型版本，如果给定名称的注册模型不存在，则同时创建一个注册模型。

  • signature – ModelSignature 描述模型的输入和输出 Schema。如果没有指定，模型签名将根据 lc_model.input_keys 和 lc_model.output_keys 作为列名，以及 DataType.string 作为列类型来设置。或者，您可以显式指定模型签名。模型签名可以从具有有效模型输入（例如，省略目标列的训练数据集）和有效模型输出（例如，在训练数据集上生成的模型预测）的数据集中 推断，例如：

  • input_example – 一个或多个有效的模型输入实例。输入示例用作提示，指示应向模型提供哪些数据。它将被转换为Pandas DataFrame，然后使用Pandas的面向分割的格式序列化为json，或者是一个numpy数组，其中示例将通过将其转换为列表来序列化为json。字节被base64编码。当``signature``参数为``None``时，输入示例用于推断模型签名。

  • await_registration_for – 等待模型版本完成创建并处于 READY 状态的秒数。默认情况下，函数等待五分钟。指定 0 或 None 以跳过等待。

  • pip_requirements – 可以是 pip 需求字符串的可迭代对象（例如 ["langchain", "-r requirements.txt", "-c constraints.txt"]），或者是本地文件系统上的 pip 需求文件的字符串路径（例如 "requirements.txt"）。如果提供，这将描述该模型应运行的环境。如果为 None，则通过 mlflow.models.infer_pip_requirements() 从当前软件环境中推断默认的需求列表。如果需求推断失败，则回退到使用 get_default_pip_requirements()。需求和约束都会自动解析并分别写入 requirements.txt 和 constraints.txt 文件，并作为模型的一部分存储。需求也会写入模型 conda 环境（conda.yaml）文件的 pip 部分。

  • extra_pip_requirements – 可以是 pip 需求字符串的可迭代对象（例如 ["pandas", "-r requirements.txt", "-c constraints.txt"]），或者是本地文件系统上的 pip 需求文件的字符串路径（例如 "requirements.txt"）。如果提供，这将描述附加的 pip 需求，这些需求会被追加到根据用户当前软件环境自动生成的一组默认 pip 需求中。需求和约束会分别自动解析并写入 requirements.txt 和 constraints.txt 文件，并作为模型的一部分存储。需求也会被写入模型的 conda 环境（conda.yaml）文件的 pip 部分。 .. 警告:: 以下参数不能同时指定： - conda_env - pip_requirements - extra_pip_requirements 这个示例 展示了如何使用 pip_requirements 和 extra_pip_requirements 指定 pip 需求。

  • metadata – 传递给模型并在 MLmodel 文件中存储的自定义元数据字典。

  • loader_fn – 一个对于包含非LangChain原生序列化对象的模型所必需的函数。该函数接受一个字符串 persist_dir 作为参数，并返回模型所需的具体对象。根据模型的不同，这可能是检索器、向量存储、请求包装器、嵌入或数据库。对于RetrievalQA链和检索器模型，该对象是 (检索器)。对于APIChain模型，它是 (请求包装器)。对于HypotheticalDocumentEmbedder模型，它是 (嵌入)。对于SQLDatabaseChain模型，它是 (数据库)。

  • persist_dir – 存储对象的目录。loader_fn 将此字符串作为参数来加载对象。对于不通过 LangChain 原生序列化的对象模型，这是可选的。MLflow 将此目录中的内容记录为名为 persist_dir_data 的子目录中的工件。以下是使用 loader_fn 和 persist_dir 记录 RetrievalQA 链的代码片段： .. 注意:: 在 langchain_community >= 0.0.27 中，加载 pickle 数据需要提供 allow_dangerous_deserialization 参数。 .. code-block:: python

  • example_no_conversion – 此参数已被弃用，并将在未来的版本中移除。它不再使用，可以安全地移除。输入示例不再被转换。

  • run_id – 与该模型版本关联的 run_id。如果指定，我们将恢复该运行并记录模型到该运行。否则，将创建一个新的运行。默认为 None。

  • model_config – 如果从代码中保存模型，则应用于模型的模型配置。此配置在加载模型期间可用。 .. 注意:: 实验性：此参数可能在未来的版本中更改或删除，恕不另行通知。

  • streamable – 一个布尔值，指示模型是否支持流式预测。如果为 True，模型必须实现 stream 方法。如果为 None，如果模型实现了 stream 方法，则将 streamable 设置为 True。默认为 None。

  • resources – 模型资源列表或包含所需资源列表的 resources.yaml 文件。.. 注意:: 实验性：此参数可能在未来的版本中更改或删除，恕不另行通知。

返回:

一个包含记录模型元数据的 ModelInfo 实例。

mlflow.langchain.save_model(lc_model, path, conda_env=None, code_paths=None, mlflow_model=None, signature: ModelSignature = None, input_example: DataFrame | ndarray | dict | list | csr_matrix | csc_matrix | str | bytes | tuple = None, pip_requirements=None, extra_pip_requirements=None, metadata=None, loader_fn=None, persist_dir=None, example_no_conversion=None, model_config=None, streamable: bool | None = None)[源代码]

备注

实验性功能：此功能可能在未来的版本中无警告地更改或移除。

备注

‘langchain’ MLflow 模型集成已知与以下包版本范围兼容：0.0.354 - 0.3.1。当使用此范围之外的包版本时，MLflow 模型与 langchain 的集成可能不会成功。

将一个 LangChain 模型保存到本地文件系统的一个路径中。

参数:

  • lc_model – 一个 LangChain 模型，可以是 Chain、Agent、retriever 或 RunnableSequence，或者是包含上述类型 LangChain 模型代码 的路径。当使用模型路径时，请确保通过使用 mlflow.models.set_model() 来设置模型。.. 注意:: 实验性：使用模型路径可能会在未来的版本中更改或被移除，而不会提前警告。

  • path – 序列化模型（以 YAML 格式）要保存的本地路径。

  • conda_env –

    一个Conda环境的字典表示形式，或Conda环境yaml文件的路径。如果提供，这将描述模型应运行的环境。至少，它应指定包含在 get_default_conda_env() 中的依赖项。如果为 None，则通过 mlflow.models.infer_pip_requirements() 推断的pip要求添加一个conda环境到模型中。如果要求推断失败，则回退到使用 get_default_pip_requirements()。来自 conda_env 的pip要求被写入一个pip requirements.txt 文件，完整的conda环境被写入 conda.yaml。以下是一个conda环境的字典表示形式的*示例*:

    {
    "name": "mlflow-env",
    "channels": ["conda-forge"],
    "dependencies": [
        "python=3.8.15",
        {
            "pip": [
                "langchain==x.y.z"
            ],
        },
    ],
}

  • code_paths – 本地文件系统路径列表，指向Python文件依赖项（或包含文件依赖项的目录）。这些文件在加载模型时会被*前置*到系统路径中。如果为给定模型声明了依赖关系，则应从公共根路径声明相对导入，以避免在加载模型时出现导入错误。有关``code_paths``功能的详细解释、推荐的使用模式和限制，请参阅`code_paths使用指南 <https://mlflow.org/docs/latest/model/dependencies.html?highlight=code_paths#saving-extra-code-with-an-mlflow-model>`_。

  • mlflow_model – mlflow.models.Model 正在添加此风格。

  • signature – ModelSignature 描述模型的输入和输出 Schema。如果没有指定，模型签名将根据 lc_model.input_keys 和 lc_model.output_keys 作为列名，以及 DataType.string 作为列类型来设置。或者，您可以显式指定模型签名。模型签名可以从具有有效模型输入（例如，省略目标列的训练数据集）和有效模型输出（例如，在训练数据集上生成的模型预测）的数据集中 推断，例如：

  • input_example – 一个或多个有效的模型输入实例。输入示例用作提示，指示应向模型提供哪些数据。它将被转换为Pandas DataFrame，然后使用Pandas的面向分割的格式序列化为json，或者是一个numpy数组，其中示例将通过将其转换为列表来序列化为json。字节被base64编码。当``signature``参数为``None``时，输入示例用于推断模型签名。

  • pip_requirements – 可以是 pip 需求字符串的可迭代对象（例如 ["langchain", "-r requirements.txt", "-c constraints.txt"]），或者是本地文件系统上的 pip 需求文件的字符串路径（例如 "requirements.txt"）。如果提供，这将描述该模型应运行的环境。如果为 None，则通过 mlflow.models.infer_pip_requirements() 从当前软件环境中推断默认的需求列表。如果需求推断失败，则回退到使用 get_default_pip_requirements()。需求和约束都会自动解析并分别写入 requirements.txt 和 constraints.txt 文件，并作为模型的一部分存储。需求也会写入模型 conda 环境（conda.yaml）文件的 pip 部分。

  • extra_pip_requirements – 可以是 pip 需求字符串的可迭代对象（例如 ["pandas", "-r requirements.txt", "-c constraints.txt"]），或者是本地文件系统上的 pip 需求文件的字符串路径（例如 "requirements.txt"）。如果提供，这将描述附加的 pip 需求，这些需求会被追加到根据用户当前软件环境自动生成的一组默认 pip 需求中。需求和约束会分别自动解析并写入 requirements.txt 和 constraints.txt 文件，并作为模型的一部分存储。需求也会被写入模型的 conda 环境（conda.yaml）文件的 pip 部分。 .. 警告:: 以下参数不能同时指定： - conda_env - pip_requirements - extra_pip_requirements 这个示例 展示了如何使用 pip_requirements 和 extra_pip_requirements 指定 pip 需求。

  • metadata – 传递给模型并在 MLmodel 文件中存储的自定义元数据字典。

  • loader_fn – 一个对于包含非LangChain原生序列化对象的模型所必需的函数。该函数接受一个字符串 persist_dir 作为参数，并返回模型所需的具体对象。根据模型的不同，这可能是检索器、向量存储、请求包装器、嵌入或数据库。对于RetrievalQA链和检索器模型，该对象是 (检索器)。对于APIChain模型，它是 (请求包装器)。对于HypotheticalDocumentEmbedder模型，它是 (嵌入)。对于SQLDatabaseChain模型，它是 (数据库)。

  • persist_dir – 存储对象的目录。loader_fn 将此字符串作为参数来加载对象。对于不通过 LangChain 原生序列化的对象模型，这是可选的。MLflow 将此目录中的内容记录为名为 persist_dir_data 的子目录中的工件。以下是使用 loader_fn 和 persist_dir 记录 RetrievalQA 链的代码片段： .. 注意:: 在 langchain_community >= 0.0.27 中，加载 pickle 数据需要提供 allow_dangerous_deserialization 参数。 .. code-block:: python

  • example_no_conversion – 此参数已被弃用，并将在未来的版本中移除。它不再使用，可以安全地移除。输入示例不再被转换。

  • model_config – 如果从代码中保存模型，则应用于模型的模型配置。此配置在加载模型期间可用。 .. 注意:: 实验性：此参数可能在未来的版本中更改或删除，恕不另行通知。

  • streamable – 一个布尔值，指示模型是否支持流式预测。如果为 True，模型必须实现 stream 方法。如果为 None，如果模型实现了 stream 方法，则 streamable 设置为 True。默认为 None。