MLflow

MLflow — це open-source платформа для керування життєвим циклом машинного навчання, LLM-застосунків, AI-агентів і моделей у production.

MLflow допомагає командам відстежувати експерименти, зберігати параметри й метрики, керувати артефактами, реєструвати моделі, розгортати їх, оцінювати якість, трасувати LLM-запити, аналізувати AI-агентів і будувати відтворюваний MLOps-процес.

Офіційна сторінка MLflow описує платформу як open-source AI engineering platform for agents, LLMs, and ML models, що допомагає debug, evaluate, monitor and optimize production-quality AI applications. ^[1]

Головна ідея

Головна ідея MLflow — навести порядок у ML- і AI-розробці.

Без MLflow команда часто зберігає результати експериментів хаотично:

метрики в Excel;
параметри в блокнотах;
моделі в різних папках;
графіки в окремих файлах;
датасети без версій;
код без зв’язку з моделлю;
production-модель невідомого походження;
LLM-prompts без історії;
agent traces без observability.

MLflow дає єдину систему, де можна бачити:

хто запускав експеримент;
які параметри використовувалися;
які метрики отримано;
яка модель збережена;
які артефакти створено;
яку версію моделі розгорнуто;
як поводиться LLM-застосунок;
які prompts, tools, retrieval і responses були використані.

MLflow не робить модель автоматично якісною. Він допомагає керувати процесом так, щоб модель можна було відтворити, порівняти, перевірити й розгорнути відповідально.

Що таке MLflow

MLflow — це платформа для AI engineering і MLOps.

Вона використовується для:

experiment tracking;
model registry;
model packaging;
model deployment;
model evaluation;
GenAI evaluation;
LLM tracing;
prompt management;
AI observability;
agent monitoring;
artifact management;
reproducibility;
production ML;
CI/CD для моделей;
інтеграції з ML-фреймворками;
командної роботи над ML-проєктами.

MLflow починався як інструмент для традиційного machine learning lifecycle, але в MLflow 3 отримав значний фокус на generative AI, LLM-застосунках і AI-агентах. Офіційний реліз MLflow 3 у червні 2025 року описував його як версію з production-ready generative AI capabilities. ^[2]

Основні компоненти MLflow

Класичні компоненти MLflow:

MLflow Tracking — відстеження експериментів;
MLflow Models — стандартний формат упаковки моделей;
MLflow Model Registry — реєстр моделей і версій;
MLflow Projects — упаковка коду для відтворюваних запусків;
MLflow Deployments — робота з deployment targets;
MLflow Evaluation — оцінювання моделей;
MLflow Tracing — tracing для LLM і agent застосунків;
MLflow GenAI — інструменти для prompts, evaluation, tracing і monitoring generative AI.

У сучасному MLflow важливо розглядати не тільки класичні ML-моделі, а й AI-застосунки, які складаються з prompts, retrievers, tools, LLM calls і agent logic.

MLflow Tracking

MLflow Tracking — це система для запису й перегляду експериментів.

Вона дозволяє логувати:

parameters;
metrics;
artifacts;
models;
tags;
source code;
run metadata.

Типовий приклад:

import mlflow

with mlflow.start_run():
    mlflow.log_param("learning_rate", 0.001)
    mlflow.log_metric("accuracy", 0.92)
    mlflow.log_artifact("confusion_matrix.png")

Після цього результати можна переглянути в MLflow UI.

Tracking потрібен для того, щоб не губити інформацію про експерименти й мати змогу порівнювати моделі не по пам’яті, а за збереженими даними.

Experiment

Experiment у MLflow — це логічна група запусків.

Наприклад:

churn_prediction;
demand_forecasting;
product_classification;
invoice_ocr;
support_ticket_routing;
llm_rag_experiment;
fraud_detection.

В одному experiment може бути багато runs.

Experiment допомагає організувати роботу так, щоб не змішувати різні задачі в одному списку.

Run

Run — це один запуск коду або експерименту.

Run може містити:

parameters;
metrics;
artifacts;
model file;
dataset information;
tags;
logs;
code version;
start time;
end time.

Наприклад, один run може відповідати навчанню моделі RandomForest із певними hyperparameters, а інший — XGBoost або neural network.

Runs дозволяють порівнювати підходи.

Parameters

Parameters — це вхідні налаштування експерименту.

Наприклад:

learning_rate;
batch_size;
max_depth;
n_estimators;
optimizer;
model_name;
embedding_model;
chunk_size;
prompt_template;
temperature.

Parameters зазвичай не змінюються під час одного run.

Вони відповідають на питання: з якими налаштуваннями запущено експеримент?

Metrics

Metrics — це числові показники якості або продуктивності.

Наприклад:

accuracy;
precision;
recall;
F1;
AUC;
RMSE;
MAE;
latency;
cost;
token usage;
hallucination score;
relevance;
faithfulness;
user rating.

Metrics можуть логуватися один раз або багато разів протягом training.

Наприклад, loss може логуватися на кожній epoch.

Artifacts

Artifacts — це файли, які зберігаються разом із run.

Artifacts можуть бути:

модель;
графік;
confusion matrix;
feature importance;
dataset sample;
tokenizer;
prompt file;
evaluation report;
JSON результат;
PDF;
trace export;
log file.

Artifacts допомагають зберегти не тільки числа, а й супровідні матеріали експерименту.

MLflow UI

MLflow UI — вебінтерфейс для перегляду експериментів.

Через UI можна:

переглядати runs;
порівнювати метрики;
дивитися parameters;
відкривати artifacts;
бачити моделі;
фільтрувати experiments;
аналізувати training;
переглядати traces для LLM-застосунків.

Зазвичай UI запускається командою:

mlflow ui

або через tracking server.

Tracking Server

MLflow Tracking Server — сервер, який приймає й зберігає experiment data.

У простому локальному режимі MLflow може зберігати дані у файловій системі.

У командному або production-сценарії краще використовувати tracking server із backend store і artifact store.

Типова схема:

backend store — база даних для metadata;
artifact store — S3, Azure Blob, GCS, local storage або інше сховище;
MLflow UI — інтерфейс для команди;
training jobs — логують runs у tracking server.

Backend Store

Backend Store зберігає metadata MLflow.

Це можуть бути:

experiments;
runs;
parameters;
metrics;
tags;
model registry metadata.

Для локальних тестів можна використовувати файлове сховище.

Для команди краще використовувати базу даних, наприклад PostgreSQL або MySQL.

Artifact Store

Artifact Store зберігає файли.

Наприклад:

model.pkl;
model.keras;
model.pt;
графіки;
reports;
datasets samples;
embeddings;
evaluation files.

Artifact store може бути:

local filesystem;
S3;
Azure Blob Storage;
Google Cloud Storage;
DBFS у Databricks;
інше object storage.

Artifacts можуть бути великими, тому їх краще не змішувати з metadata database.

MLflow Models

MLflow Models — це стандартний спосіб упаковки моделей.

Модель у MLflow може мати кілька flavors.

Наприклад:

python_function;
sklearn;
pytorch;
keras;
tensorflow;
xgboost;
lightgbm;
spark;
transformers.

Flavor дозволяє MLflow розуміти, як завантажити й використати модель.

Це важливо для deployment і reproducibility.

Python Function flavor

python_function або pyfunc — універсальний flavor MLflow.

Він дозволяє завантажувати модель через єдиний інтерфейс:

import mlflow.pyfunc

model = mlflow.pyfunc.load_model("runs:/.../model")
predictions = model.predict(data)

Pyfunc зручний, бо приховує конкретний фреймворк моделі.

Наприклад, модель може бути sklearn, XGBoost або custom Python model, але виклик виглядає однаково.

Model Signature

Model Signature описує вхідні й вихідні дані моделі.

Це може включати:

schema input;
schema output;
column names;
data types;
tensor shapes.

Signature корисний для:

validation;
deployment;
documentation;
inference API;
помилок сумісності;
повторного використання моделі.

Без signature складніше зрозуміти, які саме дані очікує модель.

Input Example

Input example — приклад вхідних даних для моделі.

Він допомагає:

зрозуміти формат;
тестувати inference;
документувати модель;
перевіряти deployment;
уникати помилок у schema.

Input example особливо корисний для команд, де модель використовують не ті самі люди, які її тренували.

MLflow Model Registry

MLflow Model Registry — це реєстр моделей і їхніх версій.

Він допомагає керувати життєвим циклом моделі:

створити registered model;
додати model version;
описати модель;
порівняти версії;
перевести модель у stage або alias;
зберігати metadata;
керувати production-кандидатами.

Model Registry потрібен, щоб команда знала, яка модель є актуальною, яка тестується, а яка вже використовується в production.

Registered Model

Registered Model — це іменована модель у реєстрі.

Наприклад:

demand_forecasting_model;
churn_classifier;
invoice_ocr_model;
ticket_priority_model;
rag_answer_evaluator.

Registered Model може мати багато versions.

Model Version

Model Version — конкретна версія registered model.

Наприклад:

churn_classifier v1;
churn_classifier v2;
churn_classifier v3.

Кожна версія може бути пов’язана з конкретним run, artifacts, metrics і description.

Це дозволяє відстежити, як саме була отримана production-модель.

Stages і aliases

У старих workflow MLflow часто використовували stages:

Staging;
Production;
Archived.

У сучасних registry-підходах дедалі частіше використовуються aliases і більш гнучкі lifecycle patterns.

Наприклад:

@champion;
@challenger;
@production;
@candidate.

Ідея однакова: команда має явно знати, яка версія моделі зараз використовується для конкретного середовища або ролі.

MLflow Projects

MLflow Projects — це спосіб упаковки ML-коду у відтворюваний формат.

Проєкт може містити:

code;
environment;
entry points;
parameters;
MLproject file.

Це дозволяє запускати експеримент однаково на різних машинах або в різних середовищах.

Приклад ідеї:

mlflow run . -P learning_rate=0.001

MLflow Projects корисні для reproducibility, але на практиці багато команд також використовують Docker, Poetry, Conda, CI/CD і workflow orchestrators.

MLflow Deployments

MLflow Deployments — інструменти для розгортання моделей або роботи з deployment targets.

Deployment може включати:

локальний inference;
REST API;
batch inference;
cloud deployment;
Databricks Model Serving;
Kubernetes;
custom serving;
MLflow pyfunc serving.

Простий приклад локального serving:

mlflow models serve -m runs:/.../model

У production потрібно додати authentication, monitoring, scaling, rollback, logging і security.

Model Evaluation

MLflow має інструменти для оцінювання моделей.

Класична evaluation-система MLflow використовує mlflow.models.evaluate(), EvaluationMetric і custom metrics. Офіційна документація окремо зазначає, що для GenAI/LLM evaluation варто використовувати mlflow.genai.evaluate() і Scorer objects. ^[3]

Evaluation потрібна для:

порівняння моделей;
перевірки якості;
regression testing;
production readiness;
виявлення overfitting;
вибору champion model;
аналізу помилок.

GenAI Evaluation

GenAI Evaluation — оцінювання LLM-застосунків, prompts, RAG і agents.

На відміну від класичного ML, де часто є чітка правильна відповідь, у GenAI потрібно оцінювати:

relevance;
faithfulness;
groundedness;
toxicity;
hallucinations;
retrieval quality;
answer correctness;
tool correctness;
format correctness;
latency;
cost;
user feedback.

MLflow GenAI documentation описує платформу як all-in-one platform для track prompts, evaluate quality, deploy AI agents і monitor performance. ^[4]

MLflow Tracing

MLflow Tracing — observability для LLM-застосунків і AI-агентів.

Офіційна документація описує MLflow Tracing як OpenTelemetry-compatible LLM observability solution, яка capture inputs, outputs, latency, costs і metadata для проміжних кроків запиту. ^[5]

Tracing корисний, коли AI-застосунок складається з кількох етапів:

користувач ставить питання;
система виконує retrieval;
агент викликає tool;
LLM формує відповідь;
система перевіряє output;
відповідь повертається користувачу.

Без tracing складно зрозуміти, де саме сталася помилка.

LLM Observability

LLM observability — це здатність бачити, як працює LLM-застосунок.

Потрібно бачити:

prompt;
system instruction;
user input;
retrieved documents;
tool calls;
model response;
tokens;
latency;
cost;
errors;
retries;
user feedback;
traces;
spans;
model version;
prompt version.

MLflow Tracing дозволяє аналізувати такі дані й знаходити bottlenecks, hallucinations, неправильні tools або слабкий retrieval.

OpenTelemetry

OpenTelemetry — відкритий стандарт для observability.

MLflow Tracing заявлено як fully OpenTelemetry-compatible і сумісне з GenAI Semantic Conventions. Це важливо, бо дозволяє уникати vendor lock-in і інтегрувати traces з існуючим observability stack. ^[6]

OpenTelemetry корисний для команд, які вже мають monitoring, tracing і logging у production.

Prompt Management

У GenAI-проєктах prompt є частиною продукту.

Його потрібно версіонувати так само, як код.

Prompt management потрібен для:

збереження prompt templates;
порівняння prompt versions;
rollback;
A/B testing;
evaluation;
approval;
documentation;
production release.

У 2026 році MLflow активно розвиває GenAI-напрям навколо tracing, evaluation, human feedback, prompt versioning і AI governance. ^[7]

AI Gateway

AI Gateway — шар, який допомагає керувати доступом до AI-моделей, costs, routing і policies.

У MLflow release notes 3.12.0 згадуються Gateway guardrails, які дозволяють встановлювати guardrails на gateway endpoints для запобігання unsafe або non-compliant inputs and outputs. ^[8]

Gateway корисний для:

централізованого доступу до моделей;
контролю витрат;
routing між providers;
access control;
guardrails;
logging;
policy enforcement;
audit.

MLflow 3.12.0

Станом на травень 2026 року актуальним релізом на офіційній сторінці був MLflow 3.12.0, випущений 5 травня 2026 року.

Release notes описують MLflow 3.12.0 як реліз, focused on improving LLM observability workflows, зокрема multimodal tracing, tracing support для Codex, Gemini і Qwen coding agents, gateway guardrails і pagination для trace table. ^[9]

Це показує, що MLflow уже не лише класичний MLOps-інструмент, а й платформа для AI agents, LLM tracing і GenAI observability.

MLflow і Databricks

MLflow історично тісно пов’язаний із Databricks, але MLflow є open-source проєктом.

Databricks надає managed MLflow із додатковими enterprise-можливостями.

Документація Databricks описує MLflow 3 як платформу для experiment tracking, model evaluation, production model registry, model deployment, а також observability, evaluation і prompt management для agents and LLM applications. ^[10]

Різниця:

open-source MLflow — потрібно самостійно налаштовувати infrastructure, security і storage;
managed MLflow на Databricks — має глибшу інтеграцію з Databricks, Unity Catalog, governance і enterprise features.

MLflow і PyTorch

MLflow добре інтегрується з PyTorch.

Він може логувати:

model artifacts;
parameters;
metrics;
checkpoints;
training curves;
custom artifacts;
PyTorch models.

Типовий сценарій:

навчити PyTorch-модель;
залогувати parameters і metrics;
зберегти модель у MLflow;
зареєструвати її в Model Registry;
розгорнути inference endpoint.

MLflow не замінює PyTorch. PyTorch тренує модель, MLflow керує lifecycle.

MLflow і Keras / TensorFlow

MLflow також використовується з Keras і TensorFlow.

Можна логувати:

Keras model;
training history;
validation metrics;
model signature;
artifacts;
callbacks outputs.

MLflow корисний для порівняння різних training runs, де змінюються layers, optimizer, learning rate, batch size або preprocessing.

MLflow і scikit-learn

Для scikit-learn MLflow дуже зручний.

Типові задачі:

класифікація;
регресія;
clustering;
tabular ML;
baseline models;
pipelines;
hyperparameter tuning.

MLflow може логувати sklearn-моделі й зберігати їх у форматі MLflow Model.

Це один із найпростіших сценаріїв для старту з MLflow.

MLflow і XGBoost / LightGBM

MLflow часто використовують з XGBoost і LightGBM.

Це корисно для:

tabular ML;
scoring models;
demand forecasting;
fraud detection;
churn prediction;
ranking;
classification.

Для таких моделей MLflow допомагає відстежувати hyperparameters, feature sets, metrics і model versions.

MLflow і LangChain

MLflow може використовуватися поруч із LangChain.

LangChain відповідає за orchestration LLM-застосунків:

prompts;
chains;
agents;
tools;
retrieval;
memory.

MLflow може відповідати за:

tracing;
evaluation;
prompt tracking;
observability;
production monitoring;
artifacts;
datasets;
cost and latency analysis.

Офіційна MLflow Tracing документація зазначає інтеграції з LLM providers і agent frameworks, включно з LangChain, LlamaIndex, DSPy і Pydantic AI. ^[11]

MLflow і LlamaIndex

LlamaIndex часто використовується для document-centric RAG.

MLflow може допомогти:

логувати experiments;
трасувати retrieval;
оцінювати відповіді;
зберігати datasets;
порівнювати retrievers;
оцінювати latency і cost;
збирати feedback;
monitor production RAG.

RAG-система без observability важко підтримується: користувач бачить лише фінальну відповідь, але не бачить, які документи були знайдені й чому модель відповіла саме так.

MLflow і Ollama

Ollama може запускати локальні LLM.

MLflow може бути корисним для:

трасування локального LLM-застосунку;
порівняння моделей;
evaluation локальних prompts;
логування latency;
аналізу RAG;
збереження результатів експериментів.

Наприклад, команда може порівняти Mistral, Llama і Qwen через Ollama, а результати evaluation зберегти в MLflow.

MLflow і Mistral AI / OpenAI / Gemini

MLflow можна використовувати з різними LLM-провайдерами:

Mistral AI;
OpenAI;
Google Gemini;
Anthropic;
local models;
custom endpoints.

MLflow не є LLM-провайдером. Він є платформою для керування, оцінювання й спостереження за AI-застосунками.

Це важливо: MLflow допомагає не прив’язувати всю інженерну систему до одного провайдера.

MLflow і CI/CD

MLflow часто є частиною CI/CD або MLOps pipeline.

Типовий pipeline:

підготувати дані;
навчити модель;
залогувати run;
оцінити модель;
порівняти з baseline;
зареєструвати model version;
запустити tests;
перевести модель у candidate;
розгорнути staging;
виконати validation;
розгорнути production;
monitor.

CI/CD для ML складніший, ніж для звичайного коду, бо потрібно контролювати не тільки код, а й дані, метрики, модель і drift.

MLflow і DVC

DVC часто використовують для versioning datasets і pipelines.

MLflow — для experiment tracking і model lifecycle.

Вони можуть доповнювати одне одного:

DVC — версії даних і pipeline;
MLflow — runs, metrics, models, registry.

У серйозному ML-проєкті потрібно версіонувати не лише модель, а й dataset, preprocessing і training code.

MLflow і Airflow / Prefect / Dagster

Workflow orchestrators можуть запускати MLflow jobs.

Наприклад:

Airflow запускає training;
training логить run у MLflow;
evaluation записує metrics;
registry оновлює model version;
deployment job розгортає модель.

MLflow не завжди замінює orchestrator. Він частіше доповнює orchestration, зберігаючи metadata, metrics і models.

MLflow для RAG

У RAG-проєктах MLflow корисний для:

tracking prompt versions;
tracing retrieval;
logging retrieved documents;
evaluation answers;
measuring latency;
measuring token usage;
collecting human feedback;
comparing chunk sizes;
comparing embedding models;
comparing vector stores;
monitoring production traces.

Наприклад, можна порівняти:

chunk_size = 500;
chunk_size = 1000;
chunk_size = 1500;

і подивитися, як змінюється relevance, faithfulness, latency і cost.

MLflow для AI-агентів

AI-агенти складніші за простий chatbot.

Agent може:

планувати;
викликати tools;
робити кілька LLM calls;
використовувати memory;
читати документи;
звертатися до API;
виконувати actions.

MLflow Tracing допомагає бачити кожен крок agent workflow.

Без tracing агент схожий на чорну скриньку: він щось зробив, але незрозуміло, чому саме.

MLflow для production monitoring

Production monitoring потрібен після deployment.

Потрібно відстежувати:

latency;
error rate;
model drift;
data drift;
prediction distribution;
cost;
token usage;
user feedback;
hallucination reports;
failed tool calls;
retriever quality;
traffic patterns;
version changes.

MLflow Tracing documentation описує production monitoring як один зі сценаріїв LLM і agent tracing, включно з latency, token usage і quality metrics. ^[12]

Human Feedback

Для GenAI-систем важливий human feedback.

Користувач або експерт може оцінювати:

відповідь правильна чи ні;
корисність;
tone;
completeness;
groundedness;
safety;
citation quality;
next action.

Human feedback можна використовувати для:

evaluation datasets;
regression tests;
prompt improvement;
retriever tuning;
model comparison;
production monitoring.

MLflow Tracing документація згадує human feedback як один зі сценаріїв роботи з LLM і agent traces. ^[13]

Datasets у MLflow

Для evaluation потрібні datasets.

Dataset може містити:

input question;
expected answer;
reference documents;
ground truth label;
expected tool call;
metadata;
user segment;
language;
difficulty.

У класичному ML dataset потрібен для training і testing.

У GenAI dataset потрібен для evaluation prompts, RAG, agents і regression testing.

Reproducibility

Reproducibility — здатність відтворити результат.

Для ML це складно, бо на результат впливають:

code version;
dataset version;
random seed;
library versions;
hardware;
preprocessing;
model parameters;
training environment;
prompt version;
LLM provider version;
temperature;
retrieved context.

MLflow допомагає зберігати частину цієї інформації, але не вирішує все автоматично.

Для повної reproducibility потрібні також Git, dataset versioning, dependency management і containerization.

MLflow і Docker

Docker часто використовують разом із MLflow.

Docker допомагає:

зафіксувати environment;
запускати tracking server;
створити inference image;
розгорнути model server;
запускати training jobs;
уникати “works on my machine”.

MLflow може зберігати модель, а Docker — середовище для її запуску.

MLflow і Kubernetes

Kubernetes може використовуватися для production deployment ML-сервісів.

MLflow може бути частиною цього процесу:

tracking server у Kubernetes;
artifact store у S3;
model serving у pod;
deployment через CI/CD;
monitoring через Prometheus / OpenTelemetry;
scaling inference endpoints.

Але MLflow сам по собі не замінює Kubernetes, DevOps і security architecture.

Безпека MLflow

Безпека MLflow залежить від того, як його розгорнули.

У локальному режимі MLflow часто не має enterprise security.

У production потрібно налаштувати:

authentication;
authorization;
network isolation;
TLS;
reverse proxy;
database credentials;
object storage permissions;
secrets management;
audit logs;
backups;
access control;
retention;
artifact scanning.

Databricks documentation окремо зазначає, що в open-source MLflow користувач має самостійно забезпечувати security layer, тоді як managed MLflow у Databricks має enterprise security. ^[14]

Що не варто логувати в MLflow

Не варто без політики логувати:

паролі;
API-ключі;
приватні токени;
credentials;
персональні дані;
медичну інформацію;
фінансові дані;
raw customer data;
confidential documents;
production secrets;
приватний код без доступів;
повні prompts із sensitive data;
traces із персональними даними без обробки.

MLflow може зберігати artifacts і traces довго. Якщо в них потрапили секрети, це стає security incident.

Access Control

У командному MLflow потрібно контролювати доступ.

Питання:

хто може бачити experiments;
хто може видаляти runs;
хто може реєструвати model versions;
хто може переводити модель у production;
хто може бачити artifacts;
хто може бачити LLM traces;
хто може бачити prompts;
хто може налаштовувати gateway endpoints.

Без access control MLflow може стати місцем витоку моделей, даних і prompts.

Governance

Governance у MLflow означає контроль життєвого циклу моделей і AI-застосунків.

Governance включає:

model approval;
lineage;
ownership;
documentation;
evaluation criteria;
registry policies;
access control;
audit;
rollback;
monitoring;
risk review;
compliance.

У GenAI governance також включає:

prompt versions;
trace review;
safety checks;
human feedback;
guardrails;
model provider policy;
cost monitoring.

MLflow у бізнесі

У бізнесі MLflow корисний для:

прогнозування попиту;
churn prediction;
scoring;
fraud detection;
recommendation systems;
OCR-моделей;
класифікації звернень;
RAG;
AI-помічників;
LLM-застосунків;
agents;
model registry;
production monitoring;
evaluation.

Бізнес-цінність MLflow полягає не в тому, що він тренує модель краще, а в тому, що він робить ML-процес керованим, прозорим і повторюваним.

MLflow і ERP-системи

MLflow не є ERP-системою.

Він не веде облік, не проводить документи, не керує складом і не рахує фінанси.

У контексті ERP MLflow може бути інструментом для супроводу AI- і ML-компонентів поруч із ERP.

Наприклад, у K2 ERP MLflow можна було б використовувати для:

tracking експериментів прогнозування попиту;
реєстру моделей класифікації документів;
evaluation OCR або text classification;
versioning ML-моделей;
monitoring AI-помічника;
tracing RAG по документації;
порівняння моделей для аналітики.

Але MLflow не повинен самостійно змінювати облікові дані, проводити документи або обходити права доступу ERP.

MLflow для звітності

MLflow може допомагати зі звітністю по ML-проєктах.

Можна показувати:

які експерименти запускалися;
які метрики були досягнуті;
яка модель стала champion;
які параметри працювали краще;
які версії моделей у production;
яка latency;
які costs;
які GenAI traces мають проблеми;
які prompts покращили quality.

Це корисно для технічних команд і менеджменту, бо ML-рішення стають прозорішими.

Типовий MLflow workflow

Типовий workflow:

створити experiment;
запустити training;
залогувати parameters;
залогувати metrics;
зберегти artifacts;
зберегти модель;
оцінити модель;
зареєструвати model version;
порівняти з baseline;
перевести candidate у staging;
протестувати;
розгорнути production;
monitor;
rollback за потреби.

Для GenAI workflow:

створити prompt;
запустити evaluation dataset;
зібрати traces;
оцінити відповіді;
порівняти model providers;
зібрати human feedback;
оновити prompt;
задеплоїти;
monitor production traces.

Типові помилки при використанні MLflow

Поширені помилки:

логувати тільки accuracy і не логувати parameters;
не зберігати dataset version;
не зберігати preprocessing code;
не використовувати model signature;
не налаштувати artifact store;
запускати tracking server без security;
логувати secrets;
не використовувати model registry;
не мати approval process;
плутати experiment tracking і production monitoring;
не перевіряти drift;
не оцінювати LLM-застосунки на dataset;
не трасувати agent tools;
не контролювати cost і latency.

Хороші практики

Під час роботи з MLflow варто дотримуватися таких правил:

Логувати parameters, metrics і artifacts системно.
Використовувати зрозумілі назви experiments.
Зберігати model signature.
Версіонувати dataset окремо.
Прив’язувати runs до Git commit.
Використовувати Model Registry.
Мати approval process для production models.
Не логувати secrets і sensitive data.
Налаштовувати access control.
Використовувати artifact store для великих файлів.
Для GenAI використовувати tracing і evaluation.
Вимірювати latency, cost і quality.
Перевіряти drift після deployment.
Документувати champion/challenger models.
Регулярно очищати застарілі artifacts і runs за політикою retention.

Коли MLflow особливо корисний

MLflow особливо корисний для:

ML-команд;
data science teams;
MLOps;
model registry;
experiment tracking;
production ML;
GenAI evaluation;
LLM tracing;
AI agents;
RAG;
prompt management;
model comparison;
reproducibility;
enterprise AI;
CI/CD для моделей;
командної роботи над AI.

Коли MLflow може бути зайвим

MLflow може бути зайвим, якщо:

є один маленький експеримент;
модель не йде в production;
немає команди;
немає потреби в registry;
немає deployment;
достатньо простого notebook;
немає повторних запусків;
задача вирішується SQL або правилом;
немає ML lifecycle.

Але якщо експерименти повторюються, моделей багато або є production — MLflow швидко стає корисним.

Обмеження MLflow

MLflow має обмеження.

Він не:

очищає дані автоматично;
навчає модель краще сам по собі;
замінює Git;
замінює data versioning;
замінює orchestrator;
замінює monitoring stack повністю;
гарантує security без налаштувань;
самостійно вирішує governance;
виправляє hallucinations;
замінює human review;
робить AI-застосунок production-ready без інженерії.

MLflow — це платформа для керування lifecycle, а не магічна кнопка “зробити AI правильно”.

Практичний висновок

MLflow — одна з найважливіших open-source платформ для MLOps і AI engineering.

Його сильні сторони:

experiment tracking;
parameters, metrics, artifacts;
MLflow UI;
Model Registry;
MLflow Models;
model deployment;
model evaluation;
GenAI evaluation;
LLM tracing;
OpenTelemetry-compatible observability;
prompt management;
AI Gateway;
integrations із Python ML-екосистемою;
Databricks integration;
підтримка класичних ML і сучасних LLM/agent workflow.

Його обмеження:

потребує правильної інфраструктури;
security треба налаштовувати;
dataset versioning потрібно вирішувати окремо;
production monitoring потребує архітектури;
GenAI evaluation не скасовує human review;
MLflow не замінює MLOps-культуру.

MLflow найкраще використовувати як центральний журнал і контрольну систему для AI-розробки: він не створює якість автоматично, але допомагає команді бачити, порівнювати, відтворювати, оцінювати й розгортати моделі відповідально.

Пояснення термінів

MLflow — open-source платформа для ML lifecycle, MLOps, GenAI evaluation і LLM tracing.
MLOps — практики розробки, розгортання й супроводу ML-моделей у production.
Experiment — група MLflow runs.
Run — один запуск експерименту або коду.
Parameter — вхідне налаштування експерименту.
Metric — числовий показник якості або продуктивності.
Artifact — файл, збережений разом із run.
Tracking Server — сервер MLflow для збереження metadata runs.
Backend Store — сховище metadata MLflow.
Artifact Store — сховище файлів і моделей.
MLflow Models — формат упаковки моделей.
Flavor — спосіб опису моделі для конкретного фреймворку.
Pyfunc — універсальний Python Function flavor MLflow.
Model Signature — опис input і output schema моделі.
Model Registry — реєстр моделей і версій.
Registered Model — іменована модель у registry.
Model Version — конкретна версія registered model.
Deployment — розгортання моделі для inference.
Evaluation — оцінювання якості моделі або AI-застосунку.
GenAI Evaluation — оцінювання generative AI, LLM, RAG і agents.
Tracing — запис кроків виконання LLM або agent workflow.
OpenTelemetry — відкритий стандарт observability.
Prompt Management — керування версіями prompts.
AI Gateway — шар керування доступом до AI-моделей і policies.
RAG — Retrieval-Augmented Generation, генерація відповіді з пошуком документів.
Agent — AI-система, яка може використовувати tools і виконувати workflow.
Drift — зміна розподілу даних або поведінки моделі після deployment.
Champion model — поточна найкраща або production-модель.
Challenger model — нова модель-кандидат для порівняння.

Дивіться також

Джерела

[1] ttps://mlflow.org/

[2] ttps://mlflow.org/releases/3/

[3] ttps://mlflow.org/docs/latest/ml/evaluation/

[4] ttps://mlflow.org/docs/latest/genai/

[5] ttps://mlflow.org/docs/latest/genai/tracing/

[6] ttps://mlflow.org/docs/latest/genai/tracing/

[7] ttps://mlflow.org/blog/structured-ai-eval/

[8] ttps://mlflow.org/releases/

[9] ttps://mlflow.org/releases/

[10] ttps://docs.databricks.com/aws/en/mlflow/

[11] ttps://mlflow.org/docs/latest/genai/tracing/

[12] ttps://mlflow.org/docs/latest/genai/tracing/

[13] ttps://mlflow.org/docs/latest/genai/tracing/

[14] ttps://learn.microsoft.com/ru-ru/azure/databricks/mlflow/

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]