尧图网站建设 
pgvector 入门在 PostgreSQL 里搭向量搜索的完整路径【免费下载链接】pgvectorOpen-source vector similarity search for Postgres项目地址: https://gitcode.com/GitHub_Trending/pg/pgvector想给已经跑了好几年的老系统加一个按意思搜一下的功能比如用户输一句上周那个接口报错的复盘系统就能找到那篇标题里根本没这几个字的文档。正常做法是再引入一套向量数据库结果多运维一个组件、多一条同步链路、多一个可能挂掉的环节。其实不用。pgvector 是 PostgreSQL 的开源扩展装进数据库里就能建向量列、算相似度、建近邻索引。你的数据、事务、JOIN 都在原来的库里向量只是多出来的一种数据类型——这也是本文的主角pgvector PostgreSQL 向量搜索一篇中文教程带你在 Windows 上从零把它装好、用起来。先判断这东西适不适合你一句话价值pgvector 让你用写 SQL 的方式做向量相似度检索数据不出 PostgreSQL。适合你业务数据本来就在 PostgreSQL 里团队不想再维护一套 Milvus/Weaviate 之类的独立向量库数据量在几千万条以内查询要能跟业务字段 JOIN、带事务。不适合你纯向量场景、百亿级向量、需要极致召回调优的大规模检索集群。那种情况独立向量库仍是更专业的选择。满足第一条就继续往下看。概念速通三分钟理解向量搜索这节解决什么问题把后面所有术语的为什么先讲清楚装完不用回头查名词。向量是什么。任何文本、图片都能被模型翻译成一串数字比如 768 个浮点数这就是向量。语义相近的内容数字也相近。所以按意思找就变成了找数字上最近的点。类比图书馆里按书名找书是精确匹配向量搜索是按内容找书——你不用知道书名只说我想要本讲咖啡的管理员就能把相关的全挑出来。余弦距离、-L2 距离这些算子就是量两本书有多像的尺子。为什么 PostgreSQL 能干这事。pgvector 以扩展形式塞进了 PG本质是注册了一个新数据类型vector(768)加一组距离算子。PG 的扩展机制允许 C 代码提供新的类型和索引方法所以它天然享受 PG 的 ACID 事务、备份恢复、权限体系。两种近似索引先混个脸熟HNSW把向量想象成一张多层的地图每个点连着附近几个点查询时从高层一路跳、逐层逼近目标。查询快、召回好但建索引慢、吃内存。IVFFlat先把所有向量聚类成一个个格子查询时只翻最可能相关的几个格子。建得快、省内存但召回上限略低。不装索引也不影响用此时是逐行精确计算结果 100% 准确只是数据多了会慢。一次装对Windows 安装 pgvector 的完整主线这节解决什么问题把环境、编译、验证压成一条照做就成的流水线外加两个最高频的报错。前置清单PostgreSQL 13 及以上装好并能正常psql连进去Visual Studio 2019 或更新安装时勾选C 桌面开发工作负载——编译用的就是它的编译器命令行里能正常git clone。按顺序执行以管理员身份打开x64 Native Tools Command Prompt for VS不要开普通 PowerShell那个环境里找不到 VS 编译器。set PGROOTC:\Program Files\PostgreSQL\18 cd %TEMP% git clone --branch v0.8.6 https://gitcode.com/GitHub_Trending/pg/pgvector.git cd pgvector nmake /F Makefile.win nmake /F Makefile.win install白话解释PGROOT告诉编译器去哪找 PG 的头文件和库nmake /F Makefile.win是 Windows 下的编译命令Linux/macOS 上是make本仓库同时提供Makefile和Makefile.win两套构建脚本最后一条把生成的vector.dll和 SQL 文件复制进 PG 的对应目录安装完成。两个高频报错报找不到 postgres.h 或 PGROOT 未设置十有八九是PGROOT没设或路径写错了注意你的 PG 实际版本目录名18 还是 16。确认路径下include目录确实存在。nmake不是内部命令你开错了终端。必须用上面说的 x64 Native Tools Command Prompt而不是系统自带 cmd。验证安装打开 psql连上你的目标库执行下面这段——启用扩展、建一张 3 维小表、插两条数据、按 L2 距离找最近的点。能返回两行结果说明全链路通了CREATE EXTENSION vector; CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3)); INSERT INTO items (embedding) VALUES ([1,2,3]), ([4,5,6]); SELECT * FROM items ORDER BY embedding - [3,1,2] LIMIT 5;一个任务串起来企业知识库的语义检索这节解决什么问题用公司文档库按语义搜索这一个场景把建表、建索引、调参、查询完整走一遍以后换别的业务照抄结构就行。表结构和普通业务表没什么两样只是多一列embedding存放文档内容的 768 维向量由你的 embedding 模型生成CREATE TABLE documents ( doc_id bigserial PRIMARY KEY, title text, content text, department text, embedding vector(768) );数据灌进去之后建 HNSW 索引。注意vector_cosine_ops它声明了这个索引按余弦距离来比你用哪个距离算子查询就得建对应 ops 的索引否则索引白建CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);查询时把ef_search调大一点用余弦距离排序取 Top 5。白话解释ef_search是搜索时的候选队列长度默认 40调越大越接近精确结果但越慢1 - 距离把距离翻转成相似度分1 表示完全一样SET hnsw.ef_search 100; SELECT title, department, 1 - (embedding [0.1,0.2,...]::vector(768)) AS score FROM documents WHERE department 技术部 ORDER BY embedding [0.1,0.2,...]::vector(768) LIMIT 5;到这里你已经拥有了一个带向量列的业务表、一个能加速的近似索引、一条按意思搜的 SQL。剩下的就是换场景复用。踩坑实录三个最容易翻车的地方这节解决什么问题把上线后最常见的三个我明明做了为什么没效果提前解决。⚠️ 坑一索引建了查询还是全表扫。近似索引只在排序 限量的形状下才会被选用。确认你的查询长这样ORDER BY embedding 距离算子 常量 LIMIT n。缺了LIMIT或者排序的是表达式而不是列本身规划器都会放弃索引。用EXPLAIN看一眼执行计划里有没有Index Scan一眼便知。⚠️ 坑二结果不太准召回率低。别急着怀疑数据先调参数HNSW 调hnsw.ef_search40 → 100 → 200 试IVFFlat 调ivfflat.probes1 → 10。如果 IVFFlat 效果始终上不去检查lists数量是否离谱——经验值百万行以内取行数/1000百万以上取sqrt(行数)。⚠️ 坑三内存吃紧或建索引慢到怀疑人生。HNSW 建索引时图能放进maintenance_work_mem会快很多可以临时SET maintenance_work_mem 8GB别大到把机器吃死数据量大又没多少内存就换 IVFFlat或用半精度halfvec列把存储和内存直接砍半。大批量灌数据用COPY而不是逐条INSERT。要不要上高阶这节解决什么问题告诉你天花板在哪方向给你不展开。混合检索全文检索擅长精确词、向量擅长语义把ts_rank文本分和余弦相似度分加权融合是知识库产品的常见做法——思路见 sql/ 里的扩展定义和 README 的相关章节。二进制量化把向量压成 bit 串bit类型 汉明距离算子先做粗筛再回原向量精排索引体积和内存能降一个数量级。README 的 Scaling 一节有完整演示属于量上去了再回来做的事。收尾下一步做什么通读官方文档仓库根目录的README.md是所有特性的权威索引存储、查询、索引、量化全覆盖比任何教程都新。翻源码理解实现HNSW 的核心逻辑在 src/hnsw.c 和 src/hnswbuild.cIVFFlat 在 src/ivfflat.cC 写得相当直白。看测试学姿势test/sql/ 里每个.sql配一份 test/expected/ 期望输出等于官方给的几百个用例照着抄最稳。装好、建表、建索引、写出第一条语义查询——四步走完你的 PostgreSQL 就已经会按意思找数据了。剩下的调参和进阶等你遇到具体的性能问题再回来翻上面几节。【免费下载链接】pgvectorOpen-source vector similarity search for Postgres项目地址: https://gitcode.com/GitHub_Trending/pg/pgvector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 pgvector 入门：在 PostgreSQL 里搭向量搜索的完整路径
pgvector 入门在 PostgreSQL 里搭向量搜索的完整路径【免费下载链接】pgvectorOpen-source vector similarity search for Postgres项目地址: https://gitcode.com/GitHub_Trending/pg/pgvector想给已经跑了好几年的老系统加一个按意思搜一下的功能比如用户输一句上周那个接口报错的复盘系统就能找到那篇标题里根本没这几个字的文档。正常做法是再引入一套向量数据库结果多运维一个组件、多一条同步链路、多一个可能挂掉的环节。其实不用。pgvector 是 PostgreSQL 的开源扩展装进数据库里就能建向量列、算相似度、建近邻索引。你的数据、事务、JOIN 都在原来的库里向量只是多出来的一种数据类型——这也是本文的主角pgvector PostgreSQL 向量搜索一篇中文教程带你在 Windows 上从零把它装好、用起来。先判断这东西适不适合你一句话价值pgvector 让你用写 SQL 的方式做向量相似度检索数据不出 PostgreSQL。适合你业务数据本来就在 PostgreSQL 里团队不想再维护一套 Milvus/Weaviate 之类的独立向量库数据量在几千万条以内查询要能跟业务字段 JOIN、带事务。不适合你纯向量场景、百亿级向量、需要极致召回调优的大规模检索集群。那种情况独立向量库仍是更专业的选择。满足第一条就继续往下看。概念速通三分钟理解向量搜索这节解决什么问题把后面所有术语的为什么先讲清楚装完不用回头查名词。向量是什么。任何文本、图片都能被模型翻译成一串数字比如 768 个浮点数这就是向量。语义相近的内容数字也相近。所以按意思找就变成了找数字上最近的点。类比图书馆里按书名找书是精确匹配向量搜索是按内容找书——你不用知道书名只说我想要本讲咖啡的管理员就能把相关的全挑出来。余弦距离、-L2 距离这些算子就是量两本书有多像的尺子。为什么 PostgreSQL 能干这事。pgvector 以扩展形式塞进了 PG本质是注册了一个新数据类型vector(768)加一组距离算子。PG 的扩展机制允许 C 代码提供新的类型和索引方法所以它天然享受 PG 的 ACID 事务、备份恢复、权限体系。两种近似索引先混个脸熟HNSW把向量想象成一张多层的地图每个点连着附近几个点查询时从高层一路跳、逐层逼近目标。查询快、召回好但建索引慢、吃内存。IVFFlat先把所有向量聚类成一个个格子查询时只翻最可能相关的几个格子。建得快、省内存但召回上限略低。不装索引也不影响用此时是逐行精确计算结果 100% 准确只是数据多了会慢。一次装对Windows 安装 pgvector 的完整主线这节解决什么问题把环境、编译、验证压成一条照做就成的流水线外加两个最高频的报错。前置清单PostgreSQL 13 及以上装好并能正常psql连进去Visual Studio 2019 或更新安装时勾选C 桌面开发工作负载——编译用的就是它的编译器命令行里能正常git clone。按顺序执行以管理员身份打开x64 Native Tools Command Prompt for VS不要开普通 PowerShell那个环境里找不到 VS 编译器。set PGROOTC:\Program Files\PostgreSQL\18 cd %TEMP% git clone --branch v0.8.6 https://gitcode.com/GitHub_Trending/pg/pgvector.git cd pgvector nmake /F Makefile.win nmake /F Makefile.win install白话解释PGROOT告诉编译器去哪找 PG 的头文件和库nmake /F Makefile.win是 Windows 下的编译命令Linux/macOS 上是make本仓库同时提供Makefile和Makefile.win两套构建脚本最后一条把生成的vector.dll和 SQL 文件复制进 PG 的对应目录安装完成。两个高频报错报找不到 postgres.h 或 PGROOT 未设置十有八九是PGROOT没设或路径写错了注意你的 PG 实际版本目录名18 还是 16。确认路径下include目录确实存在。nmake不是内部命令你开错了终端。必须用上面说的 x64 Native Tools Command Prompt而不是系统自带 cmd。验证安装打开 psql连上你的目标库执行下面这段——启用扩展、建一张 3 维小表、插两条数据、按 L2 距离找最近的点。能返回两行结果说明全链路通了CREATE EXTENSION vector; CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3)); INSERT INTO items (embedding) VALUES ([1,2,3]), ([4,5,6]); SELECT * FROM items ORDER BY embedding - [3,1,2] LIMIT 5;一个任务串起来企业知识库的语义检索这节解决什么问题用公司文档库按语义搜索这一个场景把建表、建索引、调参、查询完整走一遍以后换别的业务照抄结构就行。表结构和普通业务表没什么两样只是多一列embedding存放文档内容的 768 维向量由你的 embedding 模型生成CREATE TABLE documents ( doc_id bigserial PRIMARY KEY, title text, content text, department text, embedding vector(768) );数据灌进去之后建 HNSW 索引。注意vector_cosine_ops它声明了这个索引按余弦距离来比你用哪个距离算子查询就得建对应 ops 的索引否则索引白建CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);查询时把ef_search调大一点用余弦距离排序取 Top 5。白话解释ef_search是搜索时的候选队列长度默认 40调越大越接近精确结果但越慢1 - 距离把距离翻转成相似度分1 表示完全一样SET hnsw.ef_search 100; SELECT title, department, 1 - (embedding [0.1,0.2,...]::vector(768)) AS score FROM documents WHERE department 技术部 ORDER BY embedding [0.1,0.2,...]::vector(768) LIMIT 5;到这里你已经拥有了一个带向量列的业务表、一个能加速的近似索引、一条按意思搜的 SQL。剩下的就是换场景复用。踩坑实录三个最容易翻车的地方这节解决什么问题把上线后最常见的三个我明明做了为什么没效果提前解决。⚠️ 坑一索引建了查询还是全表扫。近似索引只在排序 限量的形状下才会被选用。确认你的查询长这样ORDER BY embedding 距离算子 常量 LIMIT n。缺了LIMIT或者排序的是表达式而不是列本身规划器都会放弃索引。用EXPLAIN看一眼执行计划里有没有Index Scan一眼便知。⚠️ 坑二结果不太准召回率低。别急着怀疑数据先调参数HNSW 调hnsw.ef_search40 → 100 → 200 试IVFFlat 调ivfflat.probes1 → 10。如果 IVFFlat 效果始终上不去检查lists数量是否离谱——经验值百万行以内取行数/1000百万以上取sqrt(行数)。⚠️ 坑三内存吃紧或建索引慢到怀疑人生。HNSW 建索引时图能放进maintenance_work_mem会快很多可以临时SET maintenance_work_mem 8GB别大到把机器吃死数据量大又没多少内存就换 IVFFlat或用半精度halfvec列把存储和内存直接砍半。大批量灌数据用COPY而不是逐条INSERT。要不要上高阶这节解决什么问题告诉你天花板在哪方向给你不展开。混合检索全文检索擅长精确词、向量擅长语义把ts_rank文本分和余弦相似度分加权融合是知识库产品的常见做法——思路见 sql/ 里的扩展定义和 README 的相关章节。二进制量化把向量压成 bit 串bit类型 汉明距离算子先做粗筛再回原向量精排索引体积和内存能降一个数量级。README 的 Scaling 一节有完整演示属于量上去了再回来做的事。收尾下一步做什么通读官方文档仓库根目录的README.md是所有特性的权威索引存储、查询、索引、量化全覆盖比任何教程都新。翻源码理解实现HNSW 的核心逻辑在 src/hnsw.c 和 src/hnswbuild.cIVFFlat 在 src/ivfflat.cC 写得相当直白。看测试学姿势test/sql/ 里每个.sql配一份 test/expected/ 期望输出等于官方给的几百个用例照着抄最稳。装好、建表、建索引、写出第一条语义查询——四步走完你的 PostgreSQL 就已经会按意思找数据了。剩下的调参和进阶等你遇到具体的性能问题再回来翻上面几节。【免费下载链接】pgvectorOpen-source vector similarity search for Postgres项目地址: https://gitcode.com/GitHub_Trending/pg/pgvector创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考