企业官网建设流程全解析

先交代下背景，我不是算法科班出身。平时主要写后端服务、处理业务数据，对 AI 的印象一直停留在“很厉害但跟我关系不大”的阶段。群里大家聊大模型、RAG、AI Agent，我每个单词都认识，拼在一起就完全懵。后来一个做后端的朋友建议我别去看那堆 Transformer 推导，先花一个小时把 PGVector 跑通，说跑完你就知道 AI 应用到底是怎么回事了。

那天下午我抱着“我很笨，但想试试”的心态，装好 PGVector、建了一张带向量的表、把几段话存进去，再写了一句查询语句查相似内容。也就是这一个小时，原本抽象的那些概念突然全对上了：文档拆分、Embedding、向量数据库、相似度检索、拼 Prompt、让大模型回答，一条完整的 AI 应用链路就摆在眼前。PGVector 帮我捅破的，不是某个神秘算法，而是“AI 应用到底在干嘛”这层窗户纸。

这篇文章就当作一份给和我一样非科班、想快速上手的同学的学习笔记。内容里没有复杂的公式推导，主要是把 PGVector 怎么装、怎么用、背后解决什么问题讲清楚。顺着这个流程走一遍，你会发现 AI 的基本原理并没有想象中那么高不可攀。

1. 为什么是 PGVector：先把“向量”跑起来，再去理解 AI 原理

我一开始也犯过常识性错误，以为想搞懂 AI 就得先去啃神经网络、反向传播、注意力机制。后来才明白，那是在研究“造模型”，而绝大多数人做 AI 应用，是在“用模型”。两者的知识栈差距很大。你可以不太清楚大模型内部是怎么训练的，但你必须搞清楚：怎么把用户问题变成模型能处理的形式，怎么把已有的资料变成模型可以参考的内容，怎么让模型不乱回答。这一套完整的链路，才是 AI 应用开发者的日常。

RAG（检索增强生成）正好是这套链路最典型的代表。它不是新模型，而是一种架构，把“外部知识检索”和“大模型生成”拼在一起。为什么需要外部知识检索？因为大模型的知识来自训练数据，训练结束之后，模型本身不会因为你新写的一篇内部文档就自动更新，也没有能力访问你公司数据库里的私有数据。所以你就需要先把这些文档切成小块、转成向量、存进一个能快速检索相似内容的数据库里。用户提问后，你从库里找出最相关的几段，连同问题一起丢给大模型，让它“看着资料回答”。

PGVector 在这里扮演的角色，就是这个“能快速检索相似内容的数据库”。它不是一个全新的数据库产品，而是 PostgreSQL 的一个扩展。装上它，你的普通 PostgreSQL 就多了一种叫 vector 的数据类型，还多了几种距离运算函数和索引支持。也就是说，你不用把项目里现有的用户表、订单表迁到别的系统里去，就能在 Postgres 里直接实现对文本、图片特征的向量检索。

我记得刚知道这点时挺惊讶的。原来让 AI“懂知识”的数据库，不需要单独搭一套复杂系统。只要把普通的表加一列 vector 类型，往里塞一串数字，再查询时按距离排序，就能做到“语义相关”的召回。这种学习路径对后端开发来说，门槛低太多了。

1.1 大模型不是“全知”，而是“知识停在训练时点的同学”

想要理解 RAG 为什么存在，第一步得改变对大模型的错误预期。把大模型想象成一个很会读书、但记性有明确边界的同学。它确实读过海量资料，能写文案、能解释概念、能总结信息，但它的知识停留在训练完成的那一刻。你问它上个月你们产品的新功能，它大概率不知道，因为那部分内容根本没被写进它的参数里。

更麻烦的是“幻觉”问题。模型本质上在做“给定上文预测下一个词”的任务，它并不知道某个事实是不是真的存在。当用户问到一个它没掌握的知识点时，它可能为了把句子编圆，硬是生成一段看起来像模像样、实际上完全不对的内容。这个毛病在开放问答里特别常见。

所以，面向真实业务场景的 AI 应用，基本不会只用裸模型，而是会搭一层知识库。把业务文档、产品手册、客服话术放进去，用户提问时先做检索把相关资料捞出来，再让模型基于资料回答。这样既能把模型知识延伸到私有资料上，又能降低瞎编概率。PGVector 负责的正是“从知识库里捞出相关资料”这一步。

1.2 为什么初学者用 PGVector 比直接用专用向量库更友好

现在市面上有 Milvus、Weaviate、Qdrant 这些独立的向量数据库，功能很强，但对于只想搞懂原理的人来说，引入它们的学习成本相对高。你需要额外部署一个服务，学习它的 API，还要考虑数据同步、备份恢复、权限管理。而 PGVector 完全不一样，它就是一个 PostgreSQL 扩展，你原先会用的 SQL 仍然有效。

对新手来说，最大的好处是“心智负担小”。普通表怎么建，向量表就怎么建；普通单值查询怎么做，向量距离排序就怎么做。你完全可以把向量检索理解成：

SELECT content FROM docs ORDER BY embedding <-> '[0.1,0.2,0.3]' LIMIT 5;

这条语句的语义很直观：给定一个向量，找出和它距离最近的 5 条内容，按距离从小到大排序。如果你之前写过ORDER BY created_at DESC LIMIT 10这种分页查询，那你已经掌握向量检索的查询骨架了，差别只是排序字段从普通数字变成了多维向量，比较方式从大于小于变成了距离远近。

这也是我强烈建议新手从 PGVector 入门的原因。先别看太多抽象概念，把这条 SQL 亲手跑通，再回头看所谓“AI 基本原理”，你会发现底层无非是“把语义变成坐标，然后按距离检索”。

2. 环境准备：用 Docker 部署 PGVector，5 分钟跑起来

第一次实验，建议别在自己的生产库上折腾，也不要着急编译源码。直接在本地用 Docker 拉一个带 PGVector 的 PostgreSQL 镜像，用完可以随时删掉重来，非常干净。

我知道不少参考文档会教你从源码编译 PGVector，步骤里既有make又有make install，还要确保 PostgreSQL 的开发头文件版本匹配。这一步对老手没什么，但对新手来说特别容易卡住。Docker 镜像pgvector/pgvector:pg16已经把扩展预装好了，省去了一大堆环境问题。你只需要关注业务层面的操作，不用在编译期耗费耐心。

2.1 用 Docker 一键启动 PGVector 实例

打开终端，执行下面的命令：

docker run --name pgvector-demo \ -e POSTGRES_USER=postgres \ -e POSTGRES_PASSWORD=postgres \ -e POSTGRES_DB=vectordb \ -p 5432:5432 \ -d pgvector/pgvector:pg16

这里有个细节我要特别说一下，POSTGRES_DB=vectordb并不是可省可不省的参数。如果你不指定，容器默认会创建一个与用户名相同的postgres库，你后面连接时还得自己建数据库。直接指定vectordb后，容器启动就会帮你建好，方便不少。

启动成功后，进入容器打开 psql：

docker exec -it pgvector-demo psql -U postgres -d vectordb

然后执行：

CREATE EXTENSION IF NOT EXISTS vector;

看到CREATE EXTENSION的提示就说明扩展已经装好了。这一步做完，你的 PostgreSQL 现在已经具备向量存储和检索能力。如果你用的是本机自己装的 PostgreSQL，镜像相关的内容改成常规源码编译安装即可，但新手阶段用 Docker 容错率更高。

2.2 建一张带向量列的示例表

接下来在 psql 里执行下面的建表语句：

CREATE TABLE docs ( id bigserial PRIMARY KEY, content text, embedding vector(384) );

这里的embedding vector(384)，就是核心点。括号里的 384 表示向量维度是 384 维。为什么是 384？因为我后面用的开源 Embedding 模型all-MiniLM-L6-v2会把每条文本转成 384 维的向量。如果你换用其他模型，维度可能变成 768、1024 甚至 1536，建表时就要跟着改。

每个文本片段都会对应一条向量记录。比如“PGVector 是 PostgreSQL 的向量检索扩展”这句话，经过 Embedding 模型处理后，会变成一串包含 384 个浮点数的数组，像这样：

INSERT INTO docs (content, embedding) VALUES ( 'PGVector 是 PostgreSQL 的向量检索扩展', '[0.0123, -0.0456, 0.0789, ...]' );

当然实际项目里一般不会手写这种 INSERT，而是通过 Python 程序批量写入。我这里先展示手动插入，主要是让你建立最直观的印象：向量，就是可以存进数据库字段的一串数字。

2.3 给向量列创建索引，数据量大才不会卡成 PPT

表刚建完，数据没多少时，你直接查询也不会感觉慢。但一旦知识库里有几千上万条文档，每次查询都把所有向量一个一个算距离，在计算资源有限的情况下会变得异常吃力，接口响应时间会急剧上升。这里需要给向量列建立索引。

PGVector 支持两类索引：IVFFlat 和 HNSW。对于新手，优先建议使用 HNSW，它的查询速度更快，而且不需要像 IVFFlat 那样纠结训练数据量。建索引用下面的 SQL：

CREATE INDEX ON docs USING hnsw (embedding vector_l2_ops);

vector_l2_ops表示索引针对欧氏距离（L2）优化。如果你更习惯用余弦距离或内积，也可以改成vector_cosine_ops或vector_ip_ops。需要注意，索引类型必须和你在查询时用的距离函数匹配，不然索引就可能发挥不出作用。这个坑我在后面排查章节里细说。

3. 核心原理拆解：Embedding、距离计算和索引到底是什么

环境跑通之后，接下来 20 分钟我基本都在琢磨一个问题：为什么数字组成的向量能代表语义？这个卡点一旦想明白，后面就通透了。假如没有搞懂，你只能照着别人的代码复制粘贴，遇到检索结果不准时就不知道去哪里调。

3.1 把句子变成一串数字，Embedding 到底是什么

我一开始觉得 Embedding 很玄，后来自己打了比方就明白了。你要给外人描述一个人的长相，可以报身高、体重、发色、瞳色等一堆特征。把这些特征按固定顺序排好，就形成了一串坐标，比如“175cm，70kg，黑色短发，棕色眼睛”。两个长得像的人，各个坐标也接近。句子也是同理。

Embedding 模型做的是：把一段文字转换成一串固定长度的浮点数，这串数字可以看成文字在高维空间里的坐标。因为模型在训练时见过海量文本，学会了把“苹果”“香蕉”“水果”这类语义相近的词，映射到彼此靠近的坐标区域。所以，坐标越近，语义就越接近。

举个例子，“今天天气怎么样”和“明天会下雨吗”这两句话在向量空间里会很靠近；而“今天天气怎么样”和“PGVector 索引配置指南”这两句话，坐标就离得比较远。这就是机器没有人类语义理解能力，却也能做“语义检索”的根本原因——它靠的是向量坐标之间的距离。

3.2 PGVector 里三种距离函数怎么选

PGVector 支持三种距离算子，对应的 SQL 符号分别是：

• <->：欧氏距离（L2），结果越小越相似
• <=>：余弦距离，结果越小越相似
• <#>：负内积，结果越大越相似

其中余弦距离理解起来最直观。余弦相似度本身的取值范围是 -1 到 1，数值越大表示方向越一致。PGVector 里的<=>返回的是“1 减去余弦相似度”，所以查询结果越小反而越相似。新手刚上手时，容易只记得用余弦相似度，结果发现排序规律跟预期是反的，这里要特别留意。

实际项目里怎么选择呢？

文本检索场景我更推荐先用余弦距离。因为它对文本长度不那么敏感，两段讲同一个事情但篇幅不同的文本，余弦相似度往往比欧氏距离更能体现真实相关性。我演示的建表脚本里用了 384 维向量，查询用<=>会更合适。

3.3 HNSW 索引查询为什么快

索引这块是很多人忽略的“最后一公里”。没有它，检索准确度可能还行，但速度完全扛不住。PGVector 首推的 HNSW，全称是 Hierarchical Navigable Small World，是一种基于图的近似最近邻索引。不用被这个名字吓到，你可以把它理解成“朋友圈式查找”。

你认识的人里，不同人有不同圈子。想找到一个不太熟的人，你不用挨个访问所有人，而是先问最像“社交达人”的朋友，他会推荐更接近目标的人，接着继续沿着这个网络往下走。HNSW 就是给高维空间里的向量建了多层“社交网络”，顶层是稀疏的连接，帮你快速跳到大概区域，越往下层越精细，最后找到距离最近的节点。

使用中有一个容易踩的坑：HNSW 索引在建索引时就需要把所有向量加入图的构建过程，如果先建索引后导数据，后来插入的数据会增量加入，性能会有下降。更推荐的做法是：先批量灌入已有数据，再执行CREATE INDEX。如果数据量特别大，建议分批次插入并设置合理的m（每个节点的最大连接数）和ef_construction参数，这些参数会影响索引构建开销和查询精度，默认值能满足大多数场景，但追求极致性能时值得手动调优。

4. 知识库实操：把“检索 + 生成”完整跑通

原理只是铺垫，接下来我们来点真东西。这部分内容比较多，但它完整展示了一个最简版知识库问答系统的全流程。如果你完全跟着操作一遍，并观察每一步的输入输出，那一整条 AI 应用的链路基本就没悬念了。

4.1 准备一份测试文档，并做合理切块

先别急着找很大体量的业务文档。我第一次实验用的是公司内部一个产品 FAQ 片段，大概五六个问题。这里的关键不在这份文档有多专业，而是让你看到流程怎么运转。

假设有这几段内容：

1. PGVector 是 PostgreSQL 的向量检索扩展。 2. 它允许你在 PostgreSQL 中存储和查询向量数据。 3. RAG 指检索增强生成，先检索相关资料，再交给大模型生成回答。 4. Embedding 是把文本转为向量，让语义相近的文本在空间中靠近。 5. 安装 PGVector 后，可以使用 SQL 完成相似度查询。 6. 文本切块时建议按段落切分，块大小要兼顾上下文完整性和检索粒度。

数据量虽然很小，但每一句讲一个独立知识点，就足以模拟知识库的基本形态。想用真实产品手册也可以，但切块需要注意块文件不能太碎。假设切得太小，“今天天气如何”和“明天要不要带伞”被拆成两块独立文本，检索时拿不到完整上下文；切得太大，一块文本里塞了太多无关信息，检索出来的相关性会被稀释。常用的做法是每个块 300 到 800 字之间，块之间可以保留少量重叠，防止上下文被截断。

4.2 安装依赖，把文档转成向量并写入 PGVector

我这里以 Python 为例。先安装两个库：

pip install psycopg2-binary sentence-transformers

sentence-transformers负责文本转向量，psycopg2负责连接 PostgreSQL。写一个简单的入库脚本：

from sentence_transformers import SentenceTransformer import psycopg2 # 1. 加载开源 Embedding 模型 model = SentenceTransformer('sentence-transformers/all-MiniLM-L6-v2') # 2. 原始文本片段 texts = [ "PGVector 是 PostgreSQL 的向量检索扩展。", "它允许你在 PostgreSQL 中存储和查询向量数据。", "RAG 指检索增强生成，先检索相关资料，再交给大模型生成回答。", "Embedding 是把文本转为向量，让语义相近的文本在空间中靠近。", "安装 PGVector 后，可以使用 SQL 完成相似度查询。", "文本切块时建议按段落切分，块大小要兼顾上下文完整性和检索粒度。", ] # 3. 统一转成向量 vectors = model.encode(texts) # 4. 写入 PGVector conn = psycopg2.connect( host="localhost", port=5432, dbname="vectordb", user="postgres", password="postgres" ) cur = conn.cursor() for text, vec in zip(texts, vectors): cur.execute( "INSERT INTO docs (content, embedding) VALUES (%s, %s)", (text, vec.tolist()) ) conn.commit() cur.close() conn.close()

第一次运行时会自动下载模型文件，如果网络比较慢，需要多等一会儿。模型下载完并加载后，内存占用会增加，这正常。等下跑通后，观察库里记录数：

SELECT id, content FROM docs;

如果只使用 psql 看数据，content 能看到文本，embedding 会显示为一大串数字，说明向量已经正确入库了。

4.3 用户提问，先做相似度查询，找出最相关片段

向量入库的目的是为了之后查询使用。当用户提出一个问题时，你不用拿原始文本去数据库里做关键词匹配，而是把用户问题也用同一个模型转成向量，然后在 PGVector 里按距离排序找到最相近的几条。

查询代码如下：

import psycopg2 from sentence_transformers import SentenceTransformer model = SentenceTransformer('sentence-transformers/all-MiniLM-L6-v2') user_question = "PGVector 可以跑在哪？" question_vector = model.encode([user_question])[0] conn = psycopg2.connect( host="localhost", dbname="vectordb", user="postgres", password="postgres" ) cur = conn.cursor() cur.execute( """ SELECT content, embedding <=> %s AS distance FROM docs ORDER BY distance LIMIT 3 """, (question_vector.tolist(),) ) for row in cur.fetchall(): print(row)

可以看到返回结果里排在最前面的，大概率是“PGVector 是 PostgreSQL 的向量检索扩展”之类的语句，因为它在语义上最贴近用户的问题。就算文本里没有出现一模一样的词，只要语义相近，向量检索也能把它捞回来。这就是关键词搜索和向量检索最大的区别。

4.4 把检索结果拼成 Prompt，交给大模型生成回答

检索到相关内容之后，大模型才该上场。我把它理解成“先给证据，再让模型作答”。如果不给证据，模型只能凭训练记忆瞎猜；给了证据，它就有依据了。

下面的代码会拼接一个上下文提示词，然后调用 OpenAI 兼容接口：

from openai import OpenAI client = OpenAI( base_url="你的大模型服务地址", api_key="你的API Key" ) context = "\n".join([row[0] for row in results]) # 上一步查到的知识片段 prompt = f"""请基于以下资料回答问题。如果资料中没有相关信息，请明确说不知道。 资料： {context} 问题： {user_question} 回答： """ resp = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "user", "content": prompt} ] ) print(resp.choices[0].message.content)

到这里，整个 RAG 主链路已经跑通了。用户输入问题，系统将问题转向量，在 PGVector 里检索最相关的资料，把资料拼接成清晰的 Prompt，最后交给大模型生成自然语言回答。你只需要一次提问，系统便完成了“资料读取 + 阅读理解 + 回答生成”三件事。

不夸张地说，我那一小时里最“豁然开朗”的时刻，就是跑完这段流程。原来所谓“给 AI 接入知识库”，不是把文档直接扔给大模型，而是让大模型“带着资料上场”。从这个角度回头再看各种 AI 产品，很多不过是这套链路在工程层面的变形。

5. 常见问题与排查技巧实录

环境、脚本都跑通之后，接下来就是实战排坑时间了。我把自己踩过、以及身边朋友踩过的问题整理成了一份速查表，你在折腾 PGVector 时大概率也会碰到。

5.1 启用扩展失败，找不到 vector 扩展

执行CREATE EXTENSION vector;时报错：extension "vector" is not available，多半是版本或容器镜像问题。如果你是在 mac/Windows 用 Docker 跑 PostgreSQL，一定要使用官方提供的pgvector/pgvector镜像，而不是直接用默认的postgres镜像，因为后者默认没装这个扩展。如果你是在 Linux 上直接用 PostgreSQL，可以按 PGVector 官方文档从源码编译安装，确保 PostgreSQL 的开发头文件版本和扩展源码版本匹配。

从源码编译最容易遇到的问题在于 PostgreSQL 和 PGVector 版本不对应。比如 PostgreSQL 15 环境装错 16 分支代码，虽然可能不会立刻报错，但运行时会出现 ABI 不兼容，建议装之前先看官方 README 的分支说明。

5.2 查询报错，提示维度不匹配

错误信息类似different vector dimensions 384 and 1536，说明写入的向量和查询向量来自不同的 Embedding 模型。比如建库时用了text-embedding-ada-002生成的 1536 维向量，查询时却用 384 维的本地方模型去编码新问题，维度自然对不上。

解决办法是统一模型。知识库入库时用哪个模型，用户查询时也必须用同一个模型。生产环境里尤其要记住这个约束，不能中途随意切换模型而不重建向量。真要迁移模型，最稳妥的方式是用新模型把整库重算一遍，不要试图混着用。

5.3 数据量不大，但查询依然很慢

很多人建完表就往里插入几千条数据，查询时确实也能出结果，但需要不断调大表内存或忍受较高的延迟。此时重点检查有没有给向量列建索引，以及查询语句是否真的用上了索引。

PGVector 的默认行为是如果没有更合适的计划，他可能会对整个表做全量扫描后再排序，这在几万行以上的表中非常致命。用EXPLAIN ANALYZE看一下执行计划，如果出现Seq Scan而不是Index Scan using hnsw，说明 SQL 写法没有命中索引。常见原因是把排序字段包了一层函数，比如ORDER BY embedding <=> '[...]'::vector。建议保持原始字段的比较形式，让索引生效。

5.4 检索结果不理想，相关文档没被召回

索引没问题、维度也统一，但结果还是不对，大概率是切块策略或距离算子需要调整。比如你选了欧氏距离，而文本长短差异又很大，长文本的向量模长较大，相似度会受长度影响。改用余弦距离往往能改善不少。

块切得太大也是问题。一个大块中包含多个子主题时，用户问题只和块中某个片段相关，但由于整块向量被“平均化”了，查询结果相关度被稀释。这种情况建议适当缩小块大小，或者做重叠切块，保持每个块只聚焦一个主题。检索基本逻辑是“先保证前几名真的相关”，再谈继续优化。

5.5 常见问题速查表

6. 学完 PGVector 后，我对 AI 应用开发的整体认识

把流程亲手跑通之后，再回头翻各种 AI 相关的文章和架构图，很多都不会觉得无从下手了。因为我已经能识别出它们在整条链路里属于哪个位置。无论是最近特别火的 AI Agent，还是大家常说的 AI 应用开发，底层仍然离不开几个核心组件：模型、数据、检索、编排。

6.1 AI Agent 和知识库的关系

很多人以为 Agent 是某种更高阶的模型，实际它更像一个“调度器”。比如一个客服智能体，用户提问后，它先判定用户意图，必要时调用知识库检索工具、查订单接口或天气接口，最后把结果整合成回答。这里的知识库检索工具，往往就跑在 PGVector 或者类似向量数据库上。

所以你会发现，学会 PGVector 并不是学了一个孤立组件。它正好补上了 Agent 记忆和外部知识之间那块拼图。有些 Agent 还会维护对话历史，从历史记录里找相似问题作为参考，这同样用得到向量检索。甚至很多编程辅助场景中，插件把代码片段向量化后存进库里，用户提问时就能快速召回相关代码，本质上和 RAG 的流程一脉相承。

6.2 别把 RAG 当成唯一答案，但它是很好的起点

学习过程中也要保持清醒。RAG 能解决“私有知识实时入库”和“缓解幻觉”的问题，但它不是银弹。如果业务场景需要让模型学会某种固定的推理模式、特定文风或专门领域表达能力，可能还需要配合微调。RAG 偏重于“给模型提供检索到的资料”，微调则更偏重“改变模型自身的行为习惯”，两者解决的问题不在一个维度。

对刚接触 AI 应用开发的人来说，我建议从 RAG 入手，因为它能把复杂度控制到最低。不需要昂贵的训练资源，只借助现有大模型接口和向量数据库，就能做出一些实际可用的产品。多跑通几个类似的小实验后，再决定要不要往微调方向深入，性价比会高很多。

6.3 给和我一样“觉得自己笨”的人几句实在话

如果你现在也觉得自己不是搞算法的料，每次看到新概念都头晕，我特别能理解。但请相信，AI 应用开发大部分时间拼的不是推导公式的能力，而是“把流程拆清楚、把工具用熟、把边界摸明白”的工程能力。工具可以不会造，但一定要会用。而“会用”这件事，真的很简单——装上它，跑通一个最小示例，观察数据流怎么流动。

所以我特别推荐你也花一个小时，找一篇最基础的 PGVector 教程，按步骤建一个同样简单的知识库，再试着问它两个问题。当你亲眼看到一条含糊的问题被转成向量、在数据库里找到相似文档、最后生成一段有依据的回答时，你对 AI 的基本原理就已经有感觉了。剩下的深度，完全可以一点点慢慢补。

我把这当作给自己“笨人”的鼓励，也给正在看这篇笔记的你。只要你开始动手了，你离“懂”其实只差一次成功的运行而已。