【免费下载链接】pycaretOpen-source, low-code AutoML platform for Python. PyCaret 4.0: sklearn-native engine React control plane.项目地址https://gitcode.com/gh_mirrors/py/pycaret点击查看免费下载PyCaret 4.0 在保留 3.x 笔记本「黄金路径」setup → compare_models → ...调用体验不变的前提下将传统低代码 AutoML 库重构为「sklearn 原生引擎 React 控制平面」的全栈平台。本文以仓库 docs/revamp/ARCHITECTURE.md 为骨架结合packages/engine、services/api、apps/web、infra等目录的源码实现系统讲解仓库布局、服务拓扑、引擎设计、后端运行编排、前端设计、部署设施、LLM 路由与统一配置契约读完即可对 PyCaret 4.0 的「一个引擎、四大入口」架构形成完整认知。1. Monorepo 布局一个仓库、两套工作区、四个顶层归宿PyCaret 4.0 仓库采用「单 git 仓库 uv workspace npm workspace」的双工作区结构根目录的pyproject.toml仅作为工作区清单存在本身不是可安装包Python 依赖由uv.lock锁定。整体划分为四个顶层目录职责完全分离pycaret/ repo root ├── pyproject.toml workspace manifest only (no package) ├── uv.lock Python lockfile ├── README.md AGENTS.md CONTRIBUTING.md │ ├── packages/ SHIPPABLE LIBRARIES (pip / npm install) │ ├── engine/ → published as pycaret on PyPI │ │ ├── pyproject.toml hatchling; 4.0.0a1 │ │ ├── pycaret/ the importable package │ │ └── tests/ 32 engine tests │ ├── sdk-python/ (V2) python client → pycaret-client on PyPI │ └── shared-schemas/ (V2) JSON schemas shared between Python TS │ ├── services/ LONG-RUNNING DEPLOYABLES │ ├── api/ FastAPI backend → pycaret-server on PyPI │ │ ├── pyproject.toml │ │ ├── pycaret_server/ importable package │ │ ├── alembic.ini migrations/ │ │ └── tests/ 30 server tests │ ├── worker/ (V2) background job runner │ └── deployment-runtime/ (V2) standalone inference server │ ├── apps/ USER-FACING APPLICATIONS │ ├── web/ React SPA → pycaret/ui (internal package) │ │ ├── package.json │ │ ├── src/ 6 vitest tests │ │ └── dist/ (built) │ └── desktop/ (V2) Electron wrapper │ ├── infra/ DEPLOYMENT OPS │ ├── docker/ Dockerfile.api, Dockerfile.ui, compose │ ├── helm/ (V2) Kubernetes chart │ └── terraform/ (V2) AWS / GCP / Azure modules │ ├── docs/ │ └── revamp/ VISION, SPEC, ROADMAP, STATUS, DECISIONS │ └── .github/workflows/ CI: lint, pytest matrix, UI pipeline这条布局由三条硬性规则约束packages/负责发布、services/负责运行、apps/是 UI、infra/是运维——根目录下每个目录只有且只有一个存在理由。Python 包名与源码树路径相互独立——pip install pycaret后import pycaret的体验与重构前完全一致只是源码位置变了pycaret-server同理。这一点保证了 3.x 用户的安装与导入习惯零迁移成本。禁止交叉污染——packages/engine对services/api一无所知services/api把pycaret当作普通依赖导入apps/web只通过 HTTP WebSocket 与services/api通信。从源码树看packages/engine/pycaret/下core/、api/、logging/、tasks/、classification/等子包结构与 docs/revamp/ARCHITECTURE_ENGINE.md 中规划的「新引擎包布局」完全对应services/api/pycaret_server/下api/、runs/、llm/、db/、migrations/等目录则承载了控制平面的全部后端能力。2. 服务拓扑MVP 进程内执行V2 升级为独立 Worker整个平台的运行时拓扑如下┌─────────────────┐ ┌────────────────────────┐ │ apps/web │ │ apps/desktop (V2) │ │ React SPA │ │ Electron shell │ └────────┬────────┘ └───────────┬────────────┘ │ HTTP WS │ (hosts both) ▼ ▼ ┌──────────────────────────────────────────────────┐ │ services/api │ │ FastAPI SQLAlchemy JWT auth │ │ │ │ /api/v1/workspaces …projects …experiments │ │ /api/v1/runs …artifacts …deployments │ │ /api/v1/describe …llm …monitoring │ │ /api/v1/deployments/{slug}/predict ← serving │ │ /ws runs/{id}/events ← stream │ └────┬───────────────┬────────────┬────────────┬──┘ │ │ │ │ ▼ ▼ ▼ ▼ ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ engine │ │ DB │ │ artifact │ │ LLM │ │ in-proc │ │ Postgres │ │ store │ │ provider │ │ (thread │ │ / SQLite │ │ fs/S3/.. │ │ router │ │ pool) │ │ │ │ │ │ │ └─────────┘ └──────────┘ └──────────┘ └──────────┘ ▲ │ (V2 promotion) ▼ ┌─────────────────────────┐ │ services/worker (V2) │ │ Job queue consumer │ └─────────────────────────┘MVP 形态引擎工作在 API 进程内部以ThreadPoolExecutor线程池方式执行V2 形态迁移到独立的services/worker从Job表拉取任务。两侧对上层暴露的是同一个接口——RunOrchestrator抽象将执行后端的差异完全隐藏见 orchestrator.py 的模块注释「No Celery / Redis — MVP runs inside the FastAPI process. Swap_executorfor a process pool or out-of-process queue without touching call sites.」这正是「先进程内跑通、再平滑外置」的关键设计。3. Engine 层packages/enginesklearn 原生、可组合、无全局状态引擎层的详细设计见 docs/revamp/ARCHITECTURE_ENGINE.md其要点可概括为四块pycaret.tasks—— 5 个任务子类ClassificationExperiment、RegressionExperiment、ClusteringExperiment、AnomalyExperiment、TimeSeriesExperiment全部是 sklearn 可组合的BaseEstimator子类。以 classification.py 为例ClassificationExperiment.__init__接收target、session_id、train_size0.7、fold10、fold_strategystratifiedkfold、preprocess、normalize、remove_outliers、feature_selection、use_gpu等参数并覆写__sklearn_tags__将estimator_type标记为classifier。pycaret.api—— 类型化自省接口list_models、describe_model、list_metrics、describe_setup_params直接驱动/experiments/:id页面上的动态表单。pycaret.logging——BaseLoggerEventEventKind结构化事件体系后端的DBEventLogger继承它实现持久化与广播。pycaret.core.results—— 为每个动词定义类型化 dataclassCompareResult、TuneResult、CreateResult、...替代 3.x 时代「用pycaret.pull()拿指标」的非结构化方式。3.1 引擎设计的七大原则ARCHITECTURE_ENGINE.md 明确了驱动这次重构的七条核心原则它们是理解 4.0 与 3.x 本质差异的钥匙Engine 就是一个BaseEstimator——Experiment实现get_params/set_params/__sklearn_tags__/__sklearn_is_fitted__因此可以干净地 pickle、可以嵌入 sklearn 的Pipeline/GridSearchCV、clone(exp)会保留不可变配置而丢弃已拟合状态。懂 sklearn 的人已经掌握了 80% 的 pycaret API。fit()就是 setupsetup()是函数式别名——OOP 是真正的 APIClassificationExperiment(targetPurchase, session_id42).fit(data)函数式setup(data, targetPurchase, session_id42)只是薄适配层通过contextvars.ContextVar持有当前实验对象线程安全、async 安全而非 3.x 的模块级全局变量。每个方法返回类型化 dataclass——CompareResult(models: list[Pipeline], leaderboard: DataFrame, best: Pipeline, events: list[Event])DataFrame 仍是面向笔记本用户的属性Agent 与 UI 消费结构化字段。构建在sklearn.pipeline.Pipeline之上而非取代它——create_model返回「预处理器 已拟合估计器」的 sklearn Pipelinetune_model/ensemble_model/calibrate_model返回同构对象predict_model(pipeline, X)就是pipeline.predict(X)加输出格式化没有自定义 Pipeline 类。预处理是ColumnTransformerPipeline不是自研图结构——PreprocessorBuilder组合 sklearn 自带的 imputer、encoder、scaler、特征选择器pycaret 特有的迭代填补、稀有类别编码等部件是遵循 sklearn 协议的单一职责 transformer。调参使用 sklearn 标准搜索 optuna——GridSearchCV、RandomizedSearchCV、HalvingGridSearchCV、HalvingRandomSearchCV、optuna.integration.OptunaSearchCV由Tuner抽象择一驱动不重造 CV 循环。日志是事件流不是 tracker 适配器——pycaret.logging通过BaseLogger发出结构化EventdataclassExperimentStarted、PreprocessorFitted、ModelCompared、ModelTuned…默认 logger 为内存 文件React UI 通过 WebSocket 消费同一条流。核心代码里根本不提 mlflow/comet/wandb。无 print、无交互输入、无隐藏状态——所有长耗时操作通过事件流驱动 UI 进度渲染引擎从不直接写 stdout。3.2 迁移策略把「god-class」逐方法抽干ARCHITECTURE_ENGINE.md 特别点明了这次多会话迁移的关键洞察pycaret.tasks.ClassificationExperiment在过渡期内部包裹 3.4.0 遗留的_SupervisedExperimentgod-class5,855 行每个动词compare_models、tune_model...先是薄委托return self._legacy.compare_models(...)再逐步原地重写。公共 API 从不中断god-class 被一个方法一个方法地抽干——这正是packages/engine里classification/、regression/等目录被保留为薄适配层functional.py委托 ContextVar、oop.py再导出 Experiment 子类的原因。从当前源码看classification.py 已无_build_legacy_experiment注释明确「Phase 6: removed _build_legacy_experiment. Native setup only.」说明迁移已经走到了原生实现阶段。3.3 面向未来的单一入口MVP 1 退出的方向是pycaret.engine.run(config: RunConfig) → RunResult作为唯一无状态入口包裹任务子类笔记本 / API / UI / LLM 生成的配置共用同一契约。4. Backendservices/api约 40 个端点、14 张表、事件驱动的运行编排4.1 路由面当前/api/v1/下的主要 RouterRouter文件职责setupapi/setup.py首次启动引导 状态authapi/auth.pylogin / refresh / logout / medescribeapi/describe.py引擎自省代理workspacesapi/workspaces.pyWorkspace CRUD 成员projectsapi/projects.pyProject CRUDexperimentsapi/experiments.pyExperiment CRUDrunsapi/runs.pyRun 提交 / 列表 / 查询 / 事件 / 等待 / 取消 WebSocketdata_sourcesapi/data_sources.pyCSV 上传 S3/Postgres 注册deploymentsapi/deployments.pyPipeline 提升 Deployment CRUD /predict4.2 数据模型14 张表详见 CONTROL_PLANE_SPEC.md § 4User ─┬─ Session (refresh tokens) └─ ApiKey Workspace ─┬─ WorkspaceMember (user × role) ├─ DataSource (CSV / S3 / Postgres) ├─ Pipeline ─────┐ (workspace-scoped model registry) ├─ Deployment ←──┘ └─ Project ─┬─ Experiment ─┬─ Run ─┬─ Event (event stream) │ │ ├─ Artifact │ │ └─ FoldMetric └─ PipelineProjectLink (m2m to Pipeline)MVP 2 完成期计划追加的表包括TrialRun 内每个 AutoML 候选一行、PredictionLog已部署端点的逐请求日志、DriftReport周期性漂移评分、ModelLibrary管理员可编辑的模型目录目前硬编码在引擎里、Job后台工作队列见 CONTROL_PLANE_SPEC.md § 16、LLMProviderSetting LLMConsultationAI 助手§ 12、AuditLog所有管理员相关操作留痕。值得注意的演进从 DECISIONS.md 的 ADR 看session 54 决定「Trials table leaderboard JSON」——每个成功的compare_models/automl/search运行在编排器提交时为每条榜单条目持久化一行TrialUI 的TrialsCard从trials表读取而非解析Run.leaderboardJSONsession 56 又决定「One promote, two writes」——单个POST /runs/{run_id}/trials/{trial_id}/promote端点在一个原子事务里同时写Pipeline行与RegisteredModelVersion行让「Promote 创建可治理工件」成为唯一语义。4.3 Run 执行链路POST /experiments/{id}/runs │ ▼ Run row (statusqueued) Run.snapshot (full reproducibility) │ ▼ RunOrchestrator.submit(RunSpec) │ threading.Event for cancellation ▼ Worker thread ├─ _load_data() sklearn_dataset | data_inline | data_source_path ├─ _build_experiment() dispatches to pycaret.tasks.* ├─ exp.logger DBEventLogger(run_id…, event_broker) ├─ exp.fit(df) ├─ execute_plan(setup | create | compare) │ _checkpoint() — cancellation poll at stage boundaries ├─ _save_pipeline() cloudpickle → artifact row └─ transition(statussucceeded, leaderboard, duration_ms, …) │ ▼ event_broker.close_run(run_id) → WS subscribers receive {kind: run.closed}这条链路在源码中有完整落点RunSpecdataclassorchestrator.py承载 worker 执行所需的一切run_id、experiment_id、task、target、setup_params、plan默认setup、model_id、plan_params以及三选一的数据来源sklearn_dataset | data_inline | data_source_path外加协作式取消用的cancel_event。Plans 层plans.py定义PlanName Literal[setup, create, compare, search]与PlanOutcomesetup只 fit 不训练createfit 后执行create_model(model_id, **plan_params)comparefit 后执行compare_models(**plan_params)返回 leaderboard。plan 与 orchestrator 分离使单元测试可以在不启动线程池的情况下、用内存实验对象直接验证 plan 逻辑。事件双写每个引擎Event都流经DBEventLogger.emit()——① 同步写入events行scope 会话内②event_broker.publish(run_id, event.to_dict())通过loop.call_soon_threadsafe(queue.put_nowait, event)扇出给所有 WebSocket 订阅者见 pubsub.py、logger_bridge.py。4.4 部署与在线推理ServingRun (succeeded pipeline_pickle artifact) │ POST /runs/{id}/promote ▼ Pipeline row (workspace-scoped, shareable across projects) │ POST /pipelines/{id}/deployments ▼ Deployment row (slug auth_mode metrics counters) │ ▼ DeploymentRegistry (in-process LRU p50/p95 rolling window) │ ▼ POST /api/v1/deployments/{slug}/predictdeployments.py 的模块注释把「Pipeline 注册表 Deployment CRUD 进程内 serving」三个关注点放在同一个 router 里理由是三者在调用上强耦合。_SLUG_RE ^[a-z0-9][a-z0-9-]{1,62}[a-z0-9]$限定了 deployment slug 的格式。每个 Deployment 支持三种鉴权模式workspaceJWTv1 默认/api-keyV2/publicV2限流。5. Frontendapps/web暗色优先、键盘优先的分析师工具5.1 技术栈Vite 5 React 18 TypeScript 5严格模式verbatimModuleSyntax Tailwind 3暗色优先 TanStack Query Zustand React Router 6 axios生产包 gzip 后约83 kB。5.2 目录结构apps/web/src/apps/web/src/ ├── main.tsx React root QueryClient ├── App.tsx route table ├── index.css Tailwind component primitives ├── api/ │ ├── client.ts axios instance single-flight 401 refresh │ ├── endpoints.ts one function per backend route │ └── types.ts hand-written mirrors of Pydantic schemas ├── state/ │ └── auth.ts Zustand store; refresh token in localStorage ├── components/ │ ├── AuthGate.tsx guards authenticated routes │ └── Layout.tsx top-nav shell for authed screens └── pages/ ├── Setup.tsx /setup ├── Login.tsx /login ├── Workspaces.tsx / └── WorkspaceDetail.tsx /workspaces/:id设计上遵循 CONTROL_PLANE_SPEC.md § 13 的约定极简无多余 chrome单列表单键盘优先、暗色优先darkMode: classhtml classdark浅色模式为 V2 可选、桌面优先分析师工具而非移动应用、无图标不带标签杜绝「迷之导航」。值得注意的演进随平台功能推进前端页面面已远超上述 MVP 清单——apps/web/src/pages/下已包含Schedules.tsx、ExperimentTemplates.tsx、Webhooks.tsx、AdminUsers.tsx、ModelCard.tsx、RegisteredModels.tsx、TrialCompare.tsx等与 DECISIONS.md session 24 决策「V2 功能各自独占独立页面、不塞进一个巨型 Settings 标签页」完全一致。6. Infrainfra/一条 docker compose 命令拉起全栈当前infra/docker/即可运行完整本地栈docker compose -f infra/docker/docker-compose.yml up --build # → http://localhost:3000UI 容器的 nginx 将/api与/ws反向代理到 API 容器浏览器看到的是单一来源无 CORS 困扰/api/v1/runs/*的 WebSocket 升级带 1 小时超时以支撑长 AutoML 运行。infra/helm/与infra/terraform/{aws,gcp,azure}/目前是 V2 占位 stubinfra/docker/下实际提供Dockerfile.api、Dockerfile.ui、docker-compose.prod.yml、nginx.ui.conf与入口脚本docker-entrypoint.sh并另有一份根目录 compose.yml 可供编排。7. LLM Router建议权归 LLM、执行权归引擎LLM 路由是 MVP 2 收官期的新增能力源于 DECISIONS.md 2026-04-24 session 13 决策 3「LLM router, not a single provider」。目录结构如下services/api/pycaret_server/llm/ ├── router.py LLMRouter (provider selection retries usage) ├── providers/ │ ├── base.py LLMProvider Protocol (chat_completion, tool_use) │ ├── anthropic.py Claude via anthropic SDK │ ├── openai.py GPT-4 / o-series via openai SDK │ └── __init__.py registry ├── consultations/ │ ├── dataset_analysis.py Per-type prompt templates output schemas │ ├── experiment_design.py │ ├── run_explainer.py │ ├── failure_debugger.py │ ├── deployment_review.py │ └── drift_analyst.py └── schemas.py Pydantic: LLMConsultation, LLMProviderSetting源码层面的实际形态与此一致且略有演进LLMRouterrouter.py是每个咨询consultation必经的单一入口加载 workspace 的LLMProviderSetting行 → 通过get_provider(...)构造 provider 实例 → 以 consultation 的 system/user/schema 调用provider.complete(...)→ 归一化为LLMAdvice→ 持久化LLMConsultation审计行即使失败也落库让错误在 UI 里可见。router 之所以是类而非裸函数是因为它是将来承载限流、缓存、成本核算、配额等横切关注点的正确位置。LLMAdvice输出信封schemas.pysuggested_config_json机器可读、RunConfig 形状的配置建议suggested_actionreasoning_summaryrisk_flags。PROVIDERS白名单已扩展到(anthropic, openai, google, azure_openai, ollama, custom_openai_compatible)CONSULTATION_TYPES覆盖dataset_analysis、experiment_design、metric_selection、pipeline_recommendation、run_summary、failure_debugging、deployment_risk_review、drift_analysis八类。关键约束不可逾越LLM 输出仅是建议advisory。每次咨询返回suggested_config_jsonsuggested_actionreasoning_summaryrisk_flags由用户批准后确定性的引擎才执行。即「LLM 提议 → 用户批准 → 引擎执行」详见 CONTROL_PLANE_SPEC.md § 12.3。8. RunConfig驱动四大入口的单一契约一份 JSON schema 同时驱动四个界面┌─────────────────────────────────────────┐ │ RunConfig (JSON) │ │ dataset task preprocessing │ │ model_selection evaluation │ │ automl tuning explainability │ └───────┬─────────┬───────────┬──────────┘ │ │ │ notebook API/CLI UI wizard engine. POST dynamic run(cfg) /runs form from describe_setup_params │ │ │ └─────────┼───────────┘ ▼ LLM-generated config (reviewed approved)四个入口分别是① 笔记本里的engine.run(cfg)② API/CLI 的POST /runs③ UI 向导基于describe_setup_params生成的动态表单④ LLM 生成的配置经人工审阅批准后执行。schema 的规范位置在packages/shared-schemas/V2 实现当前 API 以宽松 dict 形式接受Run.snapshot.setup_paramsMVP 1 退出要求迁移为严格 PydanticRunConfig。完整 schema 见 CONTROL_PLANE_SPEC.md § 6。这一契约与引擎「无隐式全局状态」的原则互为表里RunConfig是引擎唯一输入Experiment实例彼此独立天然适合被笔记本、API、UI 与 LLM 四方复用。9. CIPython 三版本矩阵 前端流水线 笔记本复跑.github/workflows/test.yml在每次向v4分支推送时运行JobMatrixGateLint (ruff)ubuntu-latestblockingTestsUbuntu Windows × Python 3.11/3.12/3.13blockingWeb (tsc eslint vitest vite build)ubuntu-latest, Node 22blockingNotebooks (re-execute canonical)ubuntu-latest, nightly onlyadvisoryci-statusaggregate gateblockingsession 13 之后的测试规模为32 engine 30 server 6 web 68 个测试从当前仓库看packages/engine/tests/已有 54 个 session 化测试文件如test_session42_ts_compare_models_drain.py、test_session54_plot_model_dispatcher.pyservices/api/tests/亦有 18 个测试文件规模持续增长。10. 这套架构刻意「不是什么」没有微服务地狱一个 API 进程、一个将来的worker 进程、一个 UI bundle仅此而已。没有 GraphQLREST OpenAPI 对这个 surface 更简单。没有自研 ORMSQLAlchemy 2.x。没有自研鉴权JWT bcrypt均为标准方案。不绑定单一 LLM 供应商Router 抽象从第一天起覆盖 Claude OpenAI。不依赖 MLflow / Comet / Weights Biases事件流、工件注册表等所需机制全部自持第三方 tracker 作为 V3 的可选适配器接入。引擎没有隐式全局状态3.x 基于ContextVar的会话状态已成为历史Experiment实例彼此独立RunConfig是唯一输入。11. 延伸阅读docs/revamp/VISION.md —— 一页纸产品陈述docs/revamp/CONTROL_PLANE_SPEC.md —— 完整规格24 节docs/revamp/ROADMAP.md —— MVP 1–4 / V2 / V3 阶段拆解docs/revamp/STATUS.md —— 当前进度docs/revamp/DECISIONS.md —— ADR 决策日志docs/revamp/ARCHITECTURE_ENGINE.md —— 引擎内部细节god-class 抽干、事件体系、类层次docs/revamp/PLATFORM_QUICKSTART.md —— 5 分钟从克隆到跑通赞分享【免费下载链接】pycaretOpen-source, low-code AutoML platform for Python. PyCaret 4.0: sklearn-native engine React control plane.项目地址https://gitcode.com/gh_mirrors/py/pycaret点击查看免费下载相关推荐PyCaret 4.0 引擎架构解析用 sklearn 可组合范式重构低代码 AutoML 核心PyCaret 4.0 引擎架构解析用 sklearn 可组合范式重构低代码 AutoML 核心 PyCaret 4.0 的引擎重构 docs/revampFlyte核心架构深度解析从控制平面到执行引擎Flyte核心架构深度解析从控制平面到执行引擎 本文深度解析Flyte工作流编排平台的核心架构涵盖FlyteAdmin控制平面、FlytePropeller后端任务调度工作流自动化云原生MLOps微服务PyCaret 4.0 Engine 深度指南sklearn 原生的配置驱动 AutoML 引擎与 Control PlanePyCaret 4.0 Engine 深度指南sklearn 原生的配置驱动 AutoML 引擎与 Control Plane PyCaret 4.0 eng上一篇洛雪音乐音源终极配置指南免费打造高品质无损音乐库下一篇Vegas最佳实践企业级数据可视化架构设计创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考