后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载PostgresML 是一个将机器学习能力直接内建到 PostgreSQL 中的扩展允许用户在数据库内完成训练、推理与向量检索。本仓库中 pgml-dashboard/content/docs/about/roadmap.md 是项目团队公开的路线图文档明确指出当前项目仍处于proof of concept概念验证阶段并列举了五项正在思考或推进中的重要方向生产环境部署、模型管理仪表盘、数据浏览器、更多算法支持以及定时训练。本文以该路线图为骨架逐项拆解每个规划点背后的技术动机并结合当前仓库中的源码、文档与配置呈现这些构想如今的实际落地程度帮助你理解 PostgresML 的能力边界与发展方向。路线图整体定位概念验证阶段的能力规划路线图开篇就为整个项目定了基调——This project is currently a proof of concept。这意味着仓库中呈现的并不是一份面向最终用户的成熟产品文档而是一份记录正在思考或正在推进的功能清单。五项规划分别是Production deployment生产环境部署——解决托管数据库无法运行自定义扩展的问题Model management dashboard模型管理仪表盘——提供类似 MLFlow / SageMaker 的可视化管理界面Data explorer数据浏览器——让用户能够浏览生产数据集、寻找可用于建模的表与特征More algorithms更多算法——在 Scikit-Learn 之外引入 TensorFlow、PyTorch 等框架Scheduled training定时训练——按日、按周自动重训练模型。下文将逐一还原每个规划的技术背景并用仓库中的实现证据说明其进展。生产环境部署逻辑复制与代理方案路线图中关于生产部署的阐述非常具体许多公司使用 AWS RDS、Digital Ocean、Azure 等托管服务运行 PostgreSQL但这些服务不允许安装自定义扩展因此 PostgresML 只能直接运行在 EC2、droplet 等虚拟机VM上。由此产生的核心问题是如何把生产数据库的数据实时同步到 PostgresML 实例路线图给出的答案是中小型数据库采用logical replication逻辑复制而多 TB 级别的大规模部署考虑使用Debezium。逻辑复制方案在仓库中已形成完整的操作文档见 逻辑复制指南。该文档把逻辑复制描述为一种 pub/sub 机制主数据库决定发布哪些表PostgresML 订阅这些变更并实时下载。整套流程分为四步第一步配置主数据库。需要确保以下 PostgreSQL 参数生效修改后必须重启数据库设置值wal_levellogicalwal_senders大于 0max_replication_slots大于 0rds.logical_replication仅 AWS RDS1第二步检查连通性。PostgresML 默认可以通过公网连接其他数据库可用dblink扩展验证SELECT dblink( postgres://user:passwordyour-production-db.amazonaws.com:5432/production_db, SELECT 1 AS one ) AS t1(one integer);第三步在主库创建发布Publication。发布即主库愿意共享的一组表CREATE PUBLICATION postgresml_users FOR TABLE users, blog_posts;第四步在 PostgresML 中订阅。逻辑复制只传输数据本身因此需要先在目标库创建结构一致的表——可以用pg_dump --schema-only --no-owner --no-privileges导出 schema再用psql -f导入随后创建订阅数据即开始实时同步pg_dump \ postgres://user:passwordyour-production-db.amazonaws.com:5432/production_db \ --schema-only \ --no-owner \ --no-privileges \ -t users \ -t blog_posts \ schema.sqlCREATE SUBSCRIPTION postgresml CONNECTION postgres://user:passwordyour-production-db.amazonaws.com:5432/production_db PUBLICATION postgresml;从这份文档可以看出路线图中实时复制生产数据的构想已经演化为可执行的完整步骤。针对数据库没有公网访问能力的场景仓库还提供了两种辅助手段VPC 内连接指南如果生产数据库无法访问互联网需要一个 TCP 代理来转发连接文档同时列出了各区域的 PostgresML 出口 IPpgml-rds-proxy一个基于 pgcat 的 PostgreSQL 代理专门解决AWS RDS 等托管数据库无法直接访问 PostgresML的问题。它通过 Docker 一键启动docker run \ -e DATABASE_URLpostgres://pg:mlsql.cloud.postgresml.org:38042/pgml \ -p 6432:6432 \ ghcr.io/postgresml/pgml-rds-proxy:latest运行在 EC2 上时需将实例放入与 RDS 相同的 VPC并确保 RDS 能通过 TCP 6432 端口访问代理。随后在 RDS 侧使用postgres_fdw建立外部服务器与用户映射再通过dblink调用 PostgresML 函数例如生成 embeddingSELECT * FROM dblink( postgresml, SELECT * FROM pgml.embed(Alibaba-NLP/gte-base-en-v1.5, embed this text) AS embedding ) AS t1(embedding real[386]);换句话说路线图中在 VM 上自建运行的命题在仓库里已经沉淀为逻辑复制指南 FDW/代理方案两层可落地的实践路径。模型管理仪表盘从规划到落地路线图指出一个好看且有用的 UI 能带来巨大价值并明确以MLFlow 或 AWS SageMaker为参照目标是让用户与 PostgresML 的交互体验尽可能顺畅。这一规划在仓库中已经落地为完整的pgml-dashboard项目见 pgml-dashboard一个基于 RustRocket 框架构建的 Web 应用。其 API 层直接围绕机器学习生命周期设计部署 API 模块 下包含projects.rs——项目Project管理对应一个建模任务snapshots.rs——数据集快照Snapshot即用于训练/评估的数据切分deployment_models.rs——模型与部署管理notebooks.rs 与 uploader.rs——Notebook 与文件上传。数据库迁移文件进一步佐证了这些功能migrations/20221125201109_notebook.up.sql、20221129170843_notebooks_data.up.sql、20221130170423_uploaded_files.up.sql分别建立了 notebook、notebook 数据与上传文件的存储结构。模板目录 templates/content/dashboard 下则包含 25 个仪表盘页面模板覆盖 SQL 编辑器、Notebook、Playground 等交互界面。由此可见模型管理仪表盘已不再是纸面构想Project/Snapshot/Model 三级管理、Notebook、文件上传等 MLFlow 式核心能力都已具备实现。数据浏览器围绕数据集展开的探索工具路线图对数据浏览器的定义是允许任何人浏览生产环境中的数据集找到有用的表和特征以便构建有效的机器学习模型。这对应机器学习工作流中最前端的一环——特征发现feature discovery。在仓库中这一诉求体现在两个层面。一是 pgml-dashboard 提供了 Notebook、SQL 查询页面sql.html与 Playgroundplayground.html用户可以直接以 SQL 交互方式探查数据二是扩展层的数据集快照机制在 pgml-extension 的 ORM 层 中Snapshot::create负责基于表创建带采样策略与训练/测试切分的数据快照配套的Sampling枚举见 sampling.rs控制数据采样方式测试代码bindings/mod.rs中也有load_diabetes、load_breast_cancer等数据集加载与建模流程的验证。可以推断路线图中的数据浏览器愿景正是要在这套快照与 SQL 能力之上提供更直观的表格、特征可视化入口降低非技术用户发现特征的难度。更多算法从 Scikit-Learn 出发的扩展体系路线图表示Scikit-Learn 只是一个好的起点团队还在考虑引入TensorFlow、PyTorch以及更多模型。这一规划在源码中的进展可以从扩展的算法绑定bindings目录完整观察到pgml-extension/src/bindings/ 目前已包含类别实现Python 生态sklearn、catboost、langchain、transformersRust 原生linfa.rs、smartcore.rs、lightgbm.rs、xgboost.rs通用运行时python/mod.rsPython 运行时入口所有算法统一收敛到一个核心抽象——Bindingstrait见 bindings/mod.rs它定义了predict、predict_proba、to_bytes、from_bytes四个接口屏蔽了各框架的序列化差异注释中明确解释了不依赖 Serde 的原因scikit-learn 估计器以纯 Python pickle 对象序列化而 xgboost、linfa 也未完整实现 serde。从架构上可以推断路线图中加入 TensorFlow、PyTorch的诉求实际上是通过同一套Bindings抽象以插件方式接入的——只要实现统一的预测与序列化接口即可纳入系统。需要说明的是当前仓库中尚无 TensorFlow / PyTorch 的具体绑定实现它们仍停留在路线图规划层面这一点在阅读时应与已实现的算法区分开。定时训练自动重训练的运维诉求路线图最后一项是定时训练在数据频繁变化的应用中按计划例如每天、每周自动重训练模型非常有用。这是将机器学习从一次性实验推向持续化生产的典型运维能力与模型版本管理、监控等诉求天然关联。从当前仓库的代码检索结果看pgml-extension 与 pgml-dashboard 中尚未出现 cron / 定时调度相关的实现代码。因此可以判断定时训练目前仍处于路线图的规划阶段属于尚未落地的方向之一。从工程视角看它未来最自然的实现路径很可能是借助 PostgreSQL 自身的定时任务机制如pg_cron调度pgml.train之类的训练函数——这一点是基于项目整体一切皆 SQL设计风格的推断而非仓库中已存在的事实。路线图现状一览综合上述分析可以将五项规划在仓库中的落地情况汇总如下路线图规划核心内容仓库现状生产环境部署逻辑复制 Debezium 实时同步生产数据已落地逻辑复制完整操作文档、VPC 指南、pgml-rds-proxy 代理模型管理仪表盘类似 MLFlow / SageMaker 的管理 UI已落地pgml-dashboard 的 Project/Snapshot/Model API、Notebook、文件上传数据浏览器浏览生产数据集、发现特征部分实现Notebook/SQL/Playground 界面 数据集快照机制更多算法在 Scikit-Learn 之外引入 TensorFlow、PyTorch部分实现已接入 sklearn、xgboost、lightgbm、catboost、linfa、smartcore、transformers 等TensorFlow/PyTorch 尚未实现定时训练按日/周自动重训练模型未实现仓库中暂无调度相关代码这份路线图的价值在于它既展示了 PostgresML 作为概念验证项目时的原始构想也让后来者能够对照仓库现状理解产品演进脉络从如何把数据搬进数据库逻辑复制到如何在数据库里管理模型生命周期仪表盘与算法绑定再到未来如何让模型持续自我更新定时训练。如果你想深入了解某一方向的细节可以从上表中的源码路径直接切入对应模块继续研究。赞分享后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载相关推荐从开发到生产Dagster部署架构的完整演进路线从开发到生产Dagster部署架构的完整演进路线 你是否还在为数据管道从开发环境迁移到生产环境而头疼配置不一致、依赖缺失、扩展性不足等问题是否反复出现本文后端数据编排数据工程任务调度可观测性数据集成Paramiko 版本演进全览从 changelog 看 SSHv2 库的安全加固、算法扩展与 API 演进Paramiko 版本演进全览从 changelog 看 SSHv2 库的安全加固、算法扩展与 API 演进 导读 本文以 Paramiko 官方变更日志后端网络通信密码学Vita3K未来发展方向从实验性到生产级的演进路线Vita3K未来发展方向从实验性到生产级的演进路线 Vita3K作为一款实验性的PlayStation Vita模拟器正处在从早期开发阶段向成熟稳定版本演进游戏开发系统底层图形学跨平台音视频上一篇SPT-AKI存档编辑器5分钟彻底掌握塔科夫单机版游戏进度下一篇Spek音频频谱分析器免费开源的声音可视化完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
