尧图网站建设 
后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载2023 年 3 月PostgresML 团队正式发布了官方 SDK 的 1.0 稳定版本同时覆盖 Python 与 JavaScript 两种语言。本文以这篇发布公告为主线结合当前仓库中 pgml-sdks 的 Rust 核心源码完整讲解 Collection文档集合、Pipeline处理流水线、语义搜索 / 全文搜索 / 混合搜索、HuggingFace 模型接入、DEBUG 调试与 ER 图生成等核心能力帮助读者掌握在纯 PostgreSQL 环境中从建集合、写文档、跑流水线到向量检索的完整落地路径。1.0 版本官方 SDK 的稳定与定型在过去几个月里PostgresML 团队持续对 JavaScript 和 Python 两个版本的 SDK 进行稳定化与功能收尾最终在 2023 年 3 月 4 日发布 1.0 正式版。这一版本的发布公告正是本文关联的文档 the-1.0-sdk-is-here.md。1.0 版本带来了大量性能改进与新特性其核心能力可以概括为以下几点Collection创建用于存储、检索和管理成组文档的集合Pipeline定义强大且灵活的流水线统一编排文档的摄入ingest、切分splitting、嵌入embedding与索引indexing多模态搜索支持语义搜索semantic search、全文搜索full text search以及二者的混合搜索hybrid search并可基于文档的额外元数据做丰富的过滤模型生态几乎可以使用 HuggingFace 上所有主流 embedding 模型一切皆 SQLCollection 在数据库中就是一张张真实的表可以用 ER 图直观查看表结构甚至绕过 SDK 直接用 SQL 查询。SDK 本身是专为搜索这一任务而设计的。根据原公告PostgresML 团队用它驱动自家官网的搜索功能并在 ChatBot 演示中完成 RAG检索增强生成流程。从当前仓库的源码结构也可以印证这一技术路线pgml-dashboard/src/utils/markdown.rs 承担了官网内容渲染与检索相关的逻辑。为什么说这次发布值得兴奋任何一个公司 SDK 的本质工作都是相同的把管理 SQL 表、拼接复杂查询这些无聊且重复的工作抽象掉。单就 SDK 本身而言它并不算开创性发明。但 PostgresML 1.0 SDK 让人兴奋的原因在于它底层所依赖的技术SDK 完全依托于开源的 PostgresML PostgreSQL 扩展用 SQL 完成机器学习任务。闪电般快速的文档嵌入和魔术般的混合搜索本质上都是调用 PostgresML 扩展的简单 SQL 查询。所有计算都在你的数据库本地完成全程没有任何网络调用。这句话值得展开理解。当你在 Python/JavaScript 中写下collection.upsert_documents(documents)时SDK 并不是把数据发到某个 SaaS 平台而是在你的 PostgreSQL 实例中执行 INSERT、调用pgml.embed()生成向量、写入text_chunks/text_embeddings等表并借助 PgVector 扩展建立 HNSW 向量索引。这条技术路线与 pgml-sdks/pgml/python/README.md 中构建端到端向量搜索应用无需 OpenAI 与 Pinecone的定位完全一致。快速体验从建集合到向量检索下面这段代码是公告中的核心示例完整展示了 1.0 SDK 的三个关键动作创建 Collection 与 Pipeline、Upsert 文档、执行向量搜索。Python 与 JavaScript 两个版本的 API 几乎一一对应。JavaScript 版本// Create Collection and Pipeline const collection pgml.newCollection(my_collection); const pipeline pgml.newPipeline(my_pipeline, { text: { splitter: { model: recursive_character }, semantic_search: { model: Alibaba-NLP/gte-base-en-v1.5, }, }, }); await collection.add_pipeline(pipeline); // Upsert a document const documents [ { id: document_one, text: Here is some hidden value 1000 } ]; await collection.upsert_documents(documents); // Search over our collection const results await collection.vector_search( { query: { fields: { text: { query: What is the hidden value? }, }, }, limit: 5, }, pipeline, ); console.log(results);Python 版本# Create Collection and Pipeline collection Collection(my_collection) pipeline Pipeline( my_pipeline, { text: { splitter: {model: recursive_character}, semantic_search: { model: Alibaba-NLP/gte-base-en-v1.5, }, }, }, ) # Upsert a document documents [{id: document_one, text: Here is some hidden value 1000}] await collection.upsert_documents(documents) # Search over our collection results await collection.vector_search( { query: { fields: { text: {query: What is the hidden value?}, }, }, limit: 5, }, pipeline, ) print(results)这段示例展示了 1.0 SDK 的声明式流水线设计你只需要告诉 Pipeline对text字段先用recursive_character切分器切块再用Alibaba-NLP/gte-base-en-v1.5模型生成语义向量剩下的建表、建索引、切块、嵌入、检索全部由 SDK 自动完成。从源码看 Collection 与 Pipeline 的实现在 pgml-sdks/pgml/src/collection.rs 中Collection::new会校验集合名只能包含字母、数字、空白、-与_并据此生成name.pipelines与name.documents两张表名集合本身在数据库中对应pgml.collections表并与pgml.projects项目记录关联创建时还会写入SDK_VERSION当前源码中为1.0.0见 pgml-sdks/pgml/src/lib.rs用于版本兼容性管理。再看add_pipeline的调用链pgml-sdks/pgml/src/collection.rs其内部流程是若 Collection 尚不存在则先创建它在pipelines表中以ACTIVE TRUE写入 Pipeline 记录立即对 Pipeline 执行一次resync——删除旧的 chunks、embeddings、tsvectors 并按新 schema 重建。也就是说把 Pipeline 加进 Collection这个动作本身就触发了对已有文档的首次索引构建这与公告中Pipeline 自动编排摄入、切分、嵌入、索引的描述完全吻合。Pipeline schema 的字段级配置Pipeline 的 schema 按文档字段field维度组织每个字段可以配置三类动作见 pgml-sdks/pgml/src/pipeline.rs配置项作用关键子参数splitter文本切分model如recursive_character、parameters如chunk_size、chunk_overlapsemantic_search语义向量化modelHuggingFace 模型名、parameters如prompt、source本地/远程、hnswfull_text_searchPostgreSQL 全文检索configuration如english其中semantic_search的hnsw参数可以自定义 HNSW 向量索引的构建参数默认值为m 16、ef_construction 64见 pgml-sdks/pgml/src/pipeline.rs。在 pgml-sdks/pgml/src/lib.rs 的can_specify_custom_hnsw_parameters_for_pipelines测试中可以看到传入hnsw: {m: 100, ef_construction: 200}后SDK 生成的索引定义正是CREATE INDEX ... USING hnsw (embedding vector_cosine_ops) WITH (m100, ef_construction200)——索引参数完全透传到 PostgreSQL。切分器的默认模型是recursive_characterpgml-sdks/pgml/src/splitter.rs未指定时自动使用在 pgml-sdks/pgml/src/lib.rs 的测试can_add_pipeline_and_upsert_documents中一个带chunk_size: 1000、chunk_overlap: 40参数的 Pipeline 会把 2 个文档的body字段切出 12 个 chunk并同步生成 12 行 tsvector验证了切分与全文索引的联动行为。揭开魔术的面纱vector_search 背后的 SQLSDK 的封装看似魔术但公告特意强调你看到的每次搜索底层都是一段可审计的 SQL。上面vector_search调用实际生成的 SQL 如下WITH pipeline ( schema ) AS ( SELECT schema FROM my_collection.pipelines WHERE name my_pipeline ), text_embedding ( embedding ) AS ( SELECT pgml.embed (transformer ( SELECT SCHEMA # {text,semantic_search,model} FROM pipeline), text What is the hidden value?, kwargs {}) AS embedding ) SELECT document, chunk, score FROM ( SELECT 1 - (embeddings.embedding ( SELECT embedding FROM text_embedding)::vector) AS score, documents.id, chunks.chunk, documents.document FROM my_collection_my_pipeline.text_embeddings AS embeddings INNER JOIN my_collection_my_pipeline.text_chunks AS chunks ON chunks.id embeddings.chunk_id INNER JOIN my_collection.documents AS documents ON documents.id chunks.document_id ORDER BY embeddings.embedding ( SELECT embedding FROM text_embedding)::vector ASC LIMIT 5) AS s ORDER BY score DESC LIMIT 5这段 SQL 有几点值得拆解查询文本的嵌入是在数据库内部完成的pgml.embed(...)直接从pipelines表的 JSONB schema 中取出{text,semantic_search,model}对应的模型名Alibaba-NLP/gte-base-en-v1.5对查询串在线生成向量全程不离开数据库相似度用余弦距离计算1 - (embedding query_embedding)把 PgVector 的余弦距离换算成相似度分数score三表 JOINtext_embeddings向量→text_chunks文本块→documents原始文档搜索结果自然包含命中的 chunk 文本与完整 document。关于冗余 LIMIT 的说明这段 SQL 是程序化生成的设计目标是为了兼容一个查询搜索多个字段的场景。因此在单字段情况下你会看到一次多余的排序与 LIMIT。公告明确指出它对这个查询的速度没有实质性影响。这套查询生成器的实现位于 pgml-sdks/pgml/src/vector_search_query_builder.rs向量搜索与 pgml-sdks/pgml/src/search_query_builder.rs混合搜索。在 pgml-sdks/pgml/src/collection.rs 的vector_search方法中SDK 会执行生成好的 SQL并把结果组装为{document, chunk, score, rerank_score}四个字段的 JSON 数组返回。三种搜索模式与过滤能力公告列举了 1.0 SDK 的搜索能力语义搜索、全文搜索、混合搜索以及基于额外元数据的丰富过滤。对应到源码Collection上同时提供search可混合多字段多模式与vector_search纯向量召回两条入口。在 pgml-sdks/pgml/src/lib.rs 的测试can_search_with_local_embeddings中可以看到混合搜索的完整 query 形态{ query: { full_text_search: { title: { query: test 9, boost: 4.0 }, body: { query: Test, boost: 1.2 } }, semantic_search: { title: { query: This is a test, parameters: { prompt: query: }, boost: 2.0 }, body: { query: This is the body test, parameters: { prompt: query: }, boost: 1.01 } }, filter: { id: { $gt: 1 } } }, limit: 5 }要点逐字段配置full_text_search与semantic_search可以作用于不同的字段各自的 query 独立书写boost 加权每个字段的查询可以设置boost权重用于调整混合打分中各路信号的贡献比例元数据过滤顶层filter使用$gt、$eq等操作符对文档元数据做条件过滤其底层实现是 pgml-sdks/pgml/src/filter_builder.rs 中的FilterBuilder会把 JSON 过滤条件翻译成 SQL WHERE 子句结果可追溯混合搜索会在数据库中写入searches与search_results表记录每次搜索的 query 与排序后的结果列表并可通过add_search_eventpgml-sdks/pgml/src/collection.rs记录点击等行为事件为后续的效果监控与调优留好数据。向量搜索vector_search同样支持full_text_filter、boost、字段级parameters如 query 侧的prompt前缀以及document.keys只返回文档的指定字段测试见 pgml-sdks/pgml/src/lib.rs。打开调试日志看见每一次 SQLSDK 运行时的每一次数据库查询都是透明的。公告给出了开启 DEBUG 日志的方法Python 与 JavaScript 写法一致pgml.init_logger(DEBUG);pgml.init_logger(DEBUG)在源码层面init_logger的实现位于 pgml-sdks/pgml/src/lib.rs其日志级别映射为TRACE/DEBUG/INFO/WARN/ERROR未识别时默认ERROR输出格式可选Pretty默认或Json。除代码传参外还支持通过环境变量LOG_LEVEL与LOG_FORMAT控制方便在容器或生产环境中直接配置无需改动代码。当你把日志级别开到 DEBUG 时就能看到 SDK 实际执行的每一条 SQL——包括建表语句、切块/嵌入的同步语句、搜索的 CTE 查询等这既是排查问题的利器也是理解一切皆 SQL这一理念的最直观方式。用 ER 图看清你的 CollectionIts all SQL! 意味着 Collection 的每一个组成部分在数据库里都是真实可查的表。公告展示了如何直接打印 Collection 与 Pipeline 的实体关系图console.log(await collection.generate_er_diagram(pipeline));print(await collection.generate_er_diagram(pipeline))上述代码会输出一段PlantUML 脚本将其粘贴到 PlantUML 在线解释器中即可渲染出关系图。在 pgml-sdks/pgml/src/collection.rs 的generate_er_diagram实现中可以看到这张图实际上就是 SDK 在数据库里创建的表结构全景pgml.collections集合主表id、created_at、name、active、project_id、sdk_versioncollection.documents文档表id、source_uuid、documentJSONBcollection.pipelines流水线表name、active、schemaJSONBcollection_pipeline.field_chunks切分后的文本块表document_id、chunk_index、chunkcollection_pipeline.field_embeddings向量表chunk_id、embeddingvector仅在字段配置了semantic_search时生成collection_pipeline.field_tsvectors全文检索向量表chunk_id、tsvector仅在字段配置了full_text_search时生成。图上的表间关系documents → chunks → embeddings / tsvectors与搜索 SQL 中的 JOIN 链一一对应。换句话说ER 图不只是查看工具它直接反映了你在 SQL 层可以如何绕过 SDK 进行自定义查询——这正是公告强调query from it however you want的含义。进阶让 1.0 SDK 在生产中更好用除了公告中直接演示的能力当前仓库的源码还揭示了 1.0 SDK 面向生产使用的一系列细节1. 批量 Upsert 与并行upsert_documents支持两个可选参数batch_size默认 100与parallel_batches默认 1SDK 会把文档分批并用 tokio 的JoinSet并行提交事务见 pgml-sdks/pgml/src/collection.rs。对应测试can_add_pipeline_and_upsert_documents_with_parallel_batchespgml-sdks/pgml/src/lib.rs以batch_size: 2、parallel_batches: 5并行写入 20 个文档并断言了 chunk 数量。批量导入大量文档时合理调大这两个参数能显著提升吞吐。2. 连接与环境变量SDK 通过环境变量PGML_DATABASE_URL或回退到DATABASE_URL定位数据库连接串并以全局连接池的方式复用连接池的规模可通过PGML_POOL_MAX_CONNECTIONS默认 10、PGML_POOL_MIN_CONNECTIONS默认 0、PGML_POOL_ACQUIRE_TIMEOUT/PGML_CHECKOUT_TIMEOUT默认 30000 毫秒、PGML_POOL_MAX_LIFETIME、PGML_POOL_IDLE_TIMEOUT等变量调优见 pgml-sdks/pgml/src/lib.rs。在 pgml-sdks/pgml/python/README.md 的快速开始中第一步就是设置DATABASE_URL指向 PostgresML 数据库。3. 流水线生命周期管理除add_pipeline之外Collection 还提供remove_pipeline删除流水线并级联删除其 schema、enable_pipeline/disable_pipeline激活/停用流水线停用期间 upsert 的文档不会生成 chunk 与向量重新启用时会自动补齐以及get_pipeline_status查看每个字段的 chunks / embeddings / tsvectors 的同步进度synced、not_synced、total。对应的测试disable_enable_pipeline与pipeline_sync_status位于 pgml-sdks/pgml/src/lib.rs。4. 版本迁移SDK 版本间的变化并不保证完全向后兼容因此提供migrate()函数Python 中为from pgml import migrate; await migrate()见 pgml-sdks/pgml/src/lib.rs 与 pgml-sdks/pgml/python/README.md 的 Upgrading 一节它会把所有 Collection 迁移到与当前 SDK 兼容的结构升级 SDK 后应执行一次。5. 目录与文件摄入upsert_directory支持按file_types如[md, txt]、file_batch_size默认 10、follow_links、ignore_paths正则批量摄入目录下的文件upsert_file则可摄入单个文件pgml-sdks/pgml/src/collection.rs非常适合把本地知识库一键倒入 Collection作为 RAG 应用的数据底座。总结PostgresML 1.0 SDK 的意义不在于又一个客户端库而在于它把搜索应用的全部复杂度——表管理、文本切分、向量化、索引构建、混合排序——收敛为Collection Pipeline两个高层抽象并且每一层都保持 SQL 级透明上手快Python 与 JavaScript 两套 API 语义一致声明式 Pipeline 让建索引变成几行配置能力全语义搜索、全文搜索、混合搜索、元数据过滤、HNSW 参数透传、批量并行 upsert 一应俱全可审计DEBUG 日志输出全部 SQLER 图展示真实表结构搜索事件落库为调优与监控留足数据本地化嵌入与检索都在 PostgreSQL 内部完成不依赖外部网络调用。如果你正准备在自有 PostgreSQL 上搭建向量搜索或 RAG 应用可以按 pgml-sdks/pgml/python/README.md 的快速开始跑通第一个例子并用本文提到的init_logger(DEBUG)与generate_er_diagram深入观察 SDK 在数据库里做了什么——你会发现所谓魔术不过是一套组织良好的 SQL。赞分享后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载相关推荐pgvector-python: 在Python中拥抱PostgreSQL向量搜索pgvector python: 在Python中拥抱PostgreSQL向量搜索 项目介绍 pgvector python 是一个Python库旨在简化在P使用 LanceDB JavaScript SDK 构建向量检索应用安装、连接、建表与向量搜索实战使用 LanceDB JavaScript SDK 构建向量检索应用安装、连接、建表与向量搜索实战 本篇文章以 LanceDB 官方 JavaScript S数据库向量数据库全文检索人工智能Python Deep Dive上下文管理器资源安全管理与高级应用Python Deep Dive上下文管理器资源安全管理与高级应用 Python Deep Dive课程提供了全面的Python编程知识其中上下文管理器是确上一篇2025新范式gh_mirrors/co/comparator实现PHP复杂数据类型精准对比下一篇ts-jest测试代码审查清单确保测试质量的检查要点创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PostgresML 1.0 SDK 正式发布：用 Python 与 JavaScript 在 PostgreSQL 中构建端到端向量搜索
后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载2023 年 3 月PostgresML 团队正式发布了官方 SDK 的 1.0 稳定版本同时覆盖 Python 与 JavaScript 两种语言。本文以这篇发布公告为主线结合当前仓库中 pgml-sdks 的 Rust 核心源码完整讲解 Collection文档集合、Pipeline处理流水线、语义搜索 / 全文搜索 / 混合搜索、HuggingFace 模型接入、DEBUG 调试与 ER 图生成等核心能力帮助读者掌握在纯 PostgreSQL 环境中从建集合、写文档、跑流水线到向量检索的完整落地路径。1.0 版本官方 SDK 的稳定与定型在过去几个月里PostgresML 团队持续对 JavaScript 和 Python 两个版本的 SDK 进行稳定化与功能收尾最终在 2023 年 3 月 4 日发布 1.0 正式版。这一版本的发布公告正是本文关联的文档 the-1.0-sdk-is-here.md。1.0 版本带来了大量性能改进与新特性其核心能力可以概括为以下几点Collection创建用于存储、检索和管理成组文档的集合Pipeline定义强大且灵活的流水线统一编排文档的摄入ingest、切分splitting、嵌入embedding与索引indexing多模态搜索支持语义搜索semantic search、全文搜索full text search以及二者的混合搜索hybrid search并可基于文档的额外元数据做丰富的过滤模型生态几乎可以使用 HuggingFace 上所有主流 embedding 模型一切皆 SQLCollection 在数据库中就是一张张真实的表可以用 ER 图直观查看表结构甚至绕过 SDK 直接用 SQL 查询。SDK 本身是专为搜索这一任务而设计的。根据原公告PostgresML 团队用它驱动自家官网的搜索功能并在 ChatBot 演示中完成 RAG检索增强生成流程。从当前仓库的源码结构也可以印证这一技术路线pgml-dashboard/src/utils/markdown.rs 承担了官网内容渲染与检索相关的逻辑。为什么说这次发布值得兴奋任何一个公司 SDK 的本质工作都是相同的把管理 SQL 表、拼接复杂查询这些无聊且重复的工作抽象掉。单就 SDK 本身而言它并不算开创性发明。但 PostgresML 1.0 SDK 让人兴奋的原因在于它底层所依赖的技术SDK 完全依托于开源的 PostgresML PostgreSQL 扩展用 SQL 完成机器学习任务。闪电般快速的文档嵌入和魔术般的混合搜索本质上都是调用 PostgresML 扩展的简单 SQL 查询。所有计算都在你的数据库本地完成全程没有任何网络调用。这句话值得展开理解。当你在 Python/JavaScript 中写下collection.upsert_documents(documents)时SDK 并不是把数据发到某个 SaaS 平台而是在你的 PostgreSQL 实例中执行 INSERT、调用pgml.embed()生成向量、写入text_chunks/text_embeddings等表并借助 PgVector 扩展建立 HNSW 向量索引。这条技术路线与 pgml-sdks/pgml/python/README.md 中构建端到端向量搜索应用无需 OpenAI 与 Pinecone的定位完全一致。快速体验从建集合到向量检索下面这段代码是公告中的核心示例完整展示了 1.0 SDK 的三个关键动作创建 Collection 与 Pipeline、Upsert 文档、执行向量搜索。Python 与 JavaScript 两个版本的 API 几乎一一对应。JavaScript 版本// Create Collection and Pipeline const collection pgml.newCollection(my_collection); const pipeline pgml.newPipeline(my_pipeline, { text: { splitter: { model: recursive_character }, semantic_search: { model: Alibaba-NLP/gte-base-en-v1.5, }, }, }); await collection.add_pipeline(pipeline); // Upsert a document const documents [ { id: document_one, text: Here is some hidden value 1000 } ]; await collection.upsert_documents(documents); // Search over our collection const results await collection.vector_search( { query: { fields: { text: { query: What is the hidden value? }, }, }, limit: 5, }, pipeline, ); console.log(results);Python 版本# Create Collection and Pipeline collection Collection(my_collection) pipeline Pipeline( my_pipeline, { text: { splitter: {model: recursive_character}, semantic_search: { model: Alibaba-NLP/gte-base-en-v1.5, }, }, }, ) # Upsert a document documents [{id: document_one, text: Here is some hidden value 1000}] await collection.upsert_documents(documents) # Search over our collection results await collection.vector_search( { query: { fields: { text: {query: What is the hidden value?}, }, }, limit: 5, }, pipeline, ) print(results)这段示例展示了 1.0 SDK 的声明式流水线设计你只需要告诉 Pipeline对text字段先用recursive_character切分器切块再用Alibaba-NLP/gte-base-en-v1.5模型生成语义向量剩下的建表、建索引、切块、嵌入、检索全部由 SDK 自动完成。从源码看 Collection 与 Pipeline 的实现在 pgml-sdks/pgml/src/collection.rs 中Collection::new会校验集合名只能包含字母、数字、空白、-与_并据此生成name.pipelines与name.documents两张表名集合本身在数据库中对应pgml.collections表并与pgml.projects项目记录关联创建时还会写入SDK_VERSION当前源码中为1.0.0见 pgml-sdks/pgml/src/lib.rs用于版本兼容性管理。再看add_pipeline的调用链pgml-sdks/pgml/src/collection.rs其内部流程是若 Collection 尚不存在则先创建它在pipelines表中以ACTIVE TRUE写入 Pipeline 记录立即对 Pipeline 执行一次resync——删除旧的 chunks、embeddings、tsvectors 并按新 schema 重建。也就是说把 Pipeline 加进 Collection这个动作本身就触发了对已有文档的首次索引构建这与公告中Pipeline 自动编排摄入、切分、嵌入、索引的描述完全吻合。Pipeline schema 的字段级配置Pipeline 的 schema 按文档字段field维度组织每个字段可以配置三类动作见 pgml-sdks/pgml/src/pipeline.rs配置项作用关键子参数splitter文本切分model如recursive_character、parameters如chunk_size、chunk_overlapsemantic_search语义向量化modelHuggingFace 模型名、parameters如prompt、source本地/远程、hnswfull_text_searchPostgreSQL 全文检索configuration如english其中semantic_search的hnsw参数可以自定义 HNSW 向量索引的构建参数默认值为m 16、ef_construction 64见 pgml-sdks/pgml/src/pipeline.rs。在 pgml-sdks/pgml/src/lib.rs 的can_specify_custom_hnsw_parameters_for_pipelines测试中可以看到传入hnsw: {m: 100, ef_construction: 200}后SDK 生成的索引定义正是CREATE INDEX ... USING hnsw (embedding vector_cosine_ops) WITH (m100, ef_construction200)——索引参数完全透传到 PostgreSQL。切分器的默认模型是recursive_characterpgml-sdks/pgml/src/splitter.rs未指定时自动使用在 pgml-sdks/pgml/src/lib.rs 的测试can_add_pipeline_and_upsert_documents中一个带chunk_size: 1000、chunk_overlap: 40参数的 Pipeline 会把 2 个文档的body字段切出 12 个 chunk并同步生成 12 行 tsvector验证了切分与全文索引的联动行为。揭开魔术的面纱vector_search 背后的 SQLSDK 的封装看似魔术但公告特意强调你看到的每次搜索底层都是一段可审计的 SQL。上面vector_search调用实际生成的 SQL 如下WITH pipeline ( schema ) AS ( SELECT schema FROM my_collection.pipelines WHERE name my_pipeline ), text_embedding ( embedding ) AS ( SELECT pgml.embed (transformer ( SELECT SCHEMA # {text,semantic_search,model} FROM pipeline), text What is the hidden value?, kwargs {}) AS embedding ) SELECT document, chunk, score FROM ( SELECT 1 - (embeddings.embedding ( SELECT embedding FROM text_embedding)::vector) AS score, documents.id, chunks.chunk, documents.document FROM my_collection_my_pipeline.text_embeddings AS embeddings INNER JOIN my_collection_my_pipeline.text_chunks AS chunks ON chunks.id embeddings.chunk_id INNER JOIN my_collection.documents AS documents ON documents.id chunks.document_id ORDER BY embeddings.embedding ( SELECT embedding FROM text_embedding)::vector ASC LIMIT 5) AS s ORDER BY score DESC LIMIT 5这段 SQL 有几点值得拆解查询文本的嵌入是在数据库内部完成的pgml.embed(...)直接从pipelines表的 JSONB schema 中取出{text,semantic_search,model}对应的模型名Alibaba-NLP/gte-base-en-v1.5对查询串在线生成向量全程不离开数据库相似度用余弦距离计算1 - (embedding query_embedding)把 PgVector 的余弦距离换算成相似度分数score三表 JOINtext_embeddings向量→text_chunks文本块→documents原始文档搜索结果自然包含命中的 chunk 文本与完整 document。关于冗余 LIMIT 的说明这段 SQL 是程序化生成的设计目标是为了兼容一个查询搜索多个字段的场景。因此在单字段情况下你会看到一次多余的排序与 LIMIT。公告明确指出它对这个查询的速度没有实质性影响。这套查询生成器的实现位于 pgml-sdks/pgml/src/vector_search_query_builder.rs向量搜索与 pgml-sdks/pgml/src/search_query_builder.rs混合搜索。在 pgml-sdks/pgml/src/collection.rs 的vector_search方法中SDK 会执行生成好的 SQL并把结果组装为{document, chunk, score, rerank_score}四个字段的 JSON 数组返回。三种搜索模式与过滤能力公告列举了 1.0 SDK 的搜索能力语义搜索、全文搜索、混合搜索以及基于额外元数据的丰富过滤。对应到源码Collection上同时提供search可混合多字段多模式与vector_search纯向量召回两条入口。在 pgml-sdks/pgml/src/lib.rs 的测试can_search_with_local_embeddings中可以看到混合搜索的完整 query 形态{ query: { full_text_search: { title: { query: test 9, boost: 4.0 }, body: { query: Test, boost: 1.2 } }, semantic_search: { title: { query: This is a test, parameters: { prompt: query: }, boost: 2.0 }, body: { query: This is the body test, parameters: { prompt: query: }, boost: 1.01 } }, filter: { id: { $gt: 1 } } }, limit: 5 }要点逐字段配置full_text_search与semantic_search可以作用于不同的字段各自的 query 独立书写boost 加权每个字段的查询可以设置boost权重用于调整混合打分中各路信号的贡献比例元数据过滤顶层filter使用$gt、$eq等操作符对文档元数据做条件过滤其底层实现是 pgml-sdks/pgml/src/filter_builder.rs 中的FilterBuilder会把 JSON 过滤条件翻译成 SQL WHERE 子句结果可追溯混合搜索会在数据库中写入searches与search_results表记录每次搜索的 query 与排序后的结果列表并可通过add_search_eventpgml-sdks/pgml/src/collection.rs记录点击等行为事件为后续的效果监控与调优留好数据。向量搜索vector_search同样支持full_text_filter、boost、字段级parameters如 query 侧的prompt前缀以及document.keys只返回文档的指定字段测试见 pgml-sdks/pgml/src/lib.rs。打开调试日志看见每一次 SQLSDK 运行时的每一次数据库查询都是透明的。公告给出了开启 DEBUG 日志的方法Python 与 JavaScript 写法一致pgml.init_logger(DEBUG);pgml.init_logger(DEBUG)在源码层面init_logger的实现位于 pgml-sdks/pgml/src/lib.rs其日志级别映射为TRACE/DEBUG/INFO/WARN/ERROR未识别时默认ERROR输出格式可选Pretty默认或Json。除代码传参外还支持通过环境变量LOG_LEVEL与LOG_FORMAT控制方便在容器或生产环境中直接配置无需改动代码。当你把日志级别开到 DEBUG 时就能看到 SDK 实际执行的每一条 SQL——包括建表语句、切块/嵌入的同步语句、搜索的 CTE 查询等这既是排查问题的利器也是理解一切皆 SQL这一理念的最直观方式。用 ER 图看清你的 CollectionIts all SQL! 意味着 Collection 的每一个组成部分在数据库里都是真实可查的表。公告展示了如何直接打印 Collection 与 Pipeline 的实体关系图console.log(await collection.generate_er_diagram(pipeline));print(await collection.generate_er_diagram(pipeline))上述代码会输出一段PlantUML 脚本将其粘贴到 PlantUML 在线解释器中即可渲染出关系图。在 pgml-sdks/pgml/src/collection.rs 的generate_er_diagram实现中可以看到这张图实际上就是 SDK 在数据库里创建的表结构全景pgml.collections集合主表id、created_at、name、active、project_id、sdk_versioncollection.documents文档表id、source_uuid、documentJSONBcollection.pipelines流水线表name、active、schemaJSONBcollection_pipeline.field_chunks切分后的文本块表document_id、chunk_index、chunkcollection_pipeline.field_embeddings向量表chunk_id、embeddingvector仅在字段配置了semantic_search时生成collection_pipeline.field_tsvectors全文检索向量表chunk_id、tsvector仅在字段配置了full_text_search时生成。图上的表间关系documents → chunks → embeddings / tsvectors与搜索 SQL 中的 JOIN 链一一对应。换句话说ER 图不只是查看工具它直接反映了你在 SQL 层可以如何绕过 SDK 进行自定义查询——这正是公告强调query from it however you want的含义。进阶让 1.0 SDK 在生产中更好用除了公告中直接演示的能力当前仓库的源码还揭示了 1.0 SDK 面向生产使用的一系列细节1. 批量 Upsert 与并行upsert_documents支持两个可选参数batch_size默认 100与parallel_batches默认 1SDK 会把文档分批并用 tokio 的JoinSet并行提交事务见 pgml-sdks/pgml/src/collection.rs。对应测试can_add_pipeline_and_upsert_documents_with_parallel_batchespgml-sdks/pgml/src/lib.rs以batch_size: 2、parallel_batches: 5并行写入 20 个文档并断言了 chunk 数量。批量导入大量文档时合理调大这两个参数能显著提升吞吐。2. 连接与环境变量SDK 通过环境变量PGML_DATABASE_URL或回退到DATABASE_URL定位数据库连接串并以全局连接池的方式复用连接池的规模可通过PGML_POOL_MAX_CONNECTIONS默认 10、PGML_POOL_MIN_CONNECTIONS默认 0、PGML_POOL_ACQUIRE_TIMEOUT/PGML_CHECKOUT_TIMEOUT默认 30000 毫秒、PGML_POOL_MAX_LIFETIME、PGML_POOL_IDLE_TIMEOUT等变量调优见 pgml-sdks/pgml/src/lib.rs。在 pgml-sdks/pgml/python/README.md 的快速开始中第一步就是设置DATABASE_URL指向 PostgresML 数据库。3. 流水线生命周期管理除add_pipeline之外Collection 还提供remove_pipeline删除流水线并级联删除其 schema、enable_pipeline/disable_pipeline激活/停用流水线停用期间 upsert 的文档不会生成 chunk 与向量重新启用时会自动补齐以及get_pipeline_status查看每个字段的 chunks / embeddings / tsvectors 的同步进度synced、not_synced、total。对应的测试disable_enable_pipeline与pipeline_sync_status位于 pgml-sdks/pgml/src/lib.rs。4. 版本迁移SDK 版本间的变化并不保证完全向后兼容因此提供migrate()函数Python 中为from pgml import migrate; await migrate()见 pgml-sdks/pgml/src/lib.rs 与 pgml-sdks/pgml/python/README.md 的 Upgrading 一节它会把所有 Collection 迁移到与当前 SDK 兼容的结构升级 SDK 后应执行一次。5. 目录与文件摄入upsert_directory支持按file_types如[md, txt]、file_batch_size默认 10、follow_links、ignore_paths正则批量摄入目录下的文件upsert_file则可摄入单个文件pgml-sdks/pgml/src/collection.rs非常适合把本地知识库一键倒入 Collection作为 RAG 应用的数据底座。总结PostgresML 1.0 SDK 的意义不在于又一个客户端库而在于它把搜索应用的全部复杂度——表管理、文本切分、向量化、索引构建、混合排序——收敛为Collection Pipeline两个高层抽象并且每一层都保持 SQL 级透明上手快Python 与 JavaScript 两套 API 语义一致声明式 Pipeline 让建索引变成几行配置能力全语义搜索、全文搜索、混合搜索、元数据过滤、HNSW 参数透传、批量并行 upsert 一应俱全可审计DEBUG 日志输出全部 SQLER 图展示真实表结构搜索事件落库为调优与监控留足数据本地化嵌入与检索都在 PostgreSQL 内部完成不依赖外部网络调用。如果你正准备在自有 PostgreSQL 上搭建向量搜索或 RAG 应用可以按 pgml-sdks/pgml/python/README.md 的快速开始跑通第一个例子并用本文提到的init_logger(DEBUG)与generate_er_diagram深入观察 SDK 在数据库里做了什么——你会发现所谓魔术不过是一套组织良好的 SQL。赞分享后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载相关推荐pgvector-python: 在Python中拥抱PostgreSQL向量搜索pgvector python: 在Python中拥抱PostgreSQL向量搜索 项目介绍 pgvector python 是一个Python库旨在简化在P使用 LanceDB JavaScript SDK 构建向量检索应用安装、连接、建表与向量搜索实战使用 LanceDB JavaScript SDK 构建向量检索应用安装、连接、建表与向量搜索实战 本篇文章以 LanceDB 官方 JavaScript S数据库向量数据库全文检索人工智能Python Deep Dive上下文管理器资源安全管理与高级应用Python Deep Dive上下文管理器资源安全管理与高级应用 Python Deep Dive课程提供了全面的Python编程知识其中上下文管理器是确上一篇2025新范式gh_mirrors/co/comparator实现PHP复杂数据类型精准对比下一篇ts-jest测试代码审查清单确保测试质量的检查要点创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考