别关系与向量库，实战AI记忆层用PostgreSQL

先说吧，hen多小伙伴一听到“向量库”，脑子里立马浮现出那堆专门的搜索引擎。

我跟你讲，别急着去装逼买个 Milvus，先把业务数据放进 PostgreSQL，顺手加个 pgvector，就Neng把关系查询和语义检索揉在一块儿。

说实话，这玩意儿真的省事儿。

为啥要把记忆层放在关系库里？

咱们的 AI 对话数据本身就有两层属性。

一是结构化——用户、会话、消息dou有明确的主键外键。

二是语义化——每条消息dou想Neng被相似度召回。

Ru果把这俩分开存，你得维护两套写入、两套geng新，双写成本直接炸了。

而 PostgreSQL + pgvector 把它们合二为一，写一次 SQL，两件事dou搞定。

表结构随手敲，先弄好三个核心表

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE conversations (
  id SERIAL PRIMARY KEY,
  user_id INTEGER NOT NULL,
  title TEXT,
  created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
  CONSTRAINT fk_user FOREIGN KEY  REFERENCES users ON DELETE CASCADE
);
CREATE TABLE messages (
  id SERIAL PRIMARY KEY,
  conversation_id INTEGER NOT NULL,
  role TEXT NOT NULL CHECK ),
  content TEXT NOT NULL,
  embedding VECTOR,               -- 存向量
  created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
  CONSTRAINT fk_conv FOREIGN KEY  REFERENCES conversations ON DELETE CASCADE
);

上面那几句代码，你kan完了吧。别忘了给向量建个索引：

CREATE INDEX IF NOT EXISTS idx_messages_embedding 
ON messages USING hnsw ;

这行代码的作用就是让相似度搜索跑得飞快。

写入时顺带生成 embedding

我常说写消息的时候Ru果不顺手算一次向量，以后想检索就只Neng找空。

下面这段 Node.js 示例hen直白：

import { query } from "./db.js";
import { OpenAIEmbeddings } from "@langchain/openai";
let embedder;
function getEmbedder {
  if  {
    embedder = new OpenAIEmbeddings({
      model: "text-embedding-v3",
      apiKey: process.env.OPENAI_API_KEY
    });
  }
  return embedder;
}
export async function addMessage {
  if  {
    const vec = await getEmbedder.embedQuery;
    const { rows } = await query(
      `INSERT INTO messages 
       VALUES 
       RETURNING *`,
    );
    return rows;
  } else {
    const { rows } = await query(
      `INSERT INTO messages 
       VALUES  RETURNING *`,
    );
    return rows;
  }
}

哈哈，这里有点小坑：embedding 的维度一定要和模型输出保持一致，否则 INSERT 会直接报错。

对了你可Neng会好奇：“为什么百度不收录”这种技术博客？

其实原因hen简单——百度的爬虫对动态渲染和 JS 内容抓取不太友好，加上缺少结构化的 meta 信息，它们往往直接跳过。

所以Ru果你想让文章被搜到，Zui好在后台加点 和静态 HTML 内容。

语义检索：一句 SQL 把业务过滤和相似度排序拎在一起

export async function searchSimilar {
  const vec = await getEmbedder.embedQuery;
  const { rows } = await query(
    `SELECT id, role, content, created_at,
            -  AS similarity
     FROM messages
     WHERE conversation_id = $2 AND embedding IS NOT NULL
     ORDER BY embedding <=> $1::vector
     LIMIT $3`,
  );
  return rows;
}

注意这里用了 “- ” 来把相似度转成正数，好让 ORDER BY 正序排Zui相近的。害，这招我刚学会时差点忘记负号。

常见踩坑 & 小技巧

向量维度不匹配：模型升级后维度变了记得改表定义里的 VECTOR 长度，否则全盘报错。

双写一致性：Ru果业务还有独立日志库，一定要在事务里同步写入，否则后期召回会出现“旧语义”。

何时生成向量：不是所有文本dou值得Zuo embedding。系统日志、临时调试信息Ke以直接跳过省钱省算力。

PgVector 索引大小：数据多了索引会膨胀，记得定期 REINDEX 或者根据业务分片。

A/B 测试：PostgreSQL vs 独立向量库

我曾经在一个中等规模项目里试过两套方案，一套是 Postgres+pgvector，一套是 MySQL + Milvus。结果呢？前者部署成本低、运维统一；后者虽然单纯向量检索稍快，但双写、一致性问题天天爆炸。说实话，我geng倾向于“一体化”方案——尤其是团队还在摸索阶段。

如何把这套方案落地到生产环境

Docker Compose 启动 PG + PGAdmin：

services:
  postgres:
    image: pgvector/pgvector:pg16
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: ai_memory
    ports: 
    volumes:
      - ./init:/docker-entrypoint-initdb.d
  pgadmin:
    image: dpage/pgadmin4
    environment:
      PGADMIN_DEFAULT_EMAIL: 
      PGADMIN_DEFAULT_PASSWORD: admin
    ports: 
    depends_on:
      - postgres

初始化脚本放进 ./init 文件夹：

Create extension、tables、indexes.

Migrate 时务必确保 EXTENSION Yi加载，否则 VECTOR 类型报错。

Pnpm 安装依赖并跑通示例：

pnpm add pg @langchain/openai dotenv
node demo.js   # 演示创建会话、写入消息、语义搜索

监控与调优：

# 查询慢Ke以打开 pg_stat_statements kan具体耗时.

# HNSW 参数可根据数据规模微调.

一下这套方案到底值不值得玩？

先说Ru果你的 AI 产品处于快速迭代阶段，又需要“记住用户过去说过的话”，PostgreSQL + pgvector 是Zui省心的组合。

A：关系模型负责用户、会话、权限等硬约束；B：向量字段负责语义匹配；C：二者通过同一张表实现一次查询完成全部需求。咱就是说这种“一次请求，一次返回”的体验，对前端和用户dou是极大的加分项。

不过也别忘了边界：

If data volume reaches hundreds of millions and latency要求毫秒级，那独立专用向量库仍然有优势。

If you need complex ANN 搜索，Postgres 的功Neng可Neng稍显局限，需要外部工具配合。

总之啊，把 AI 长期记忆层安在 PostgreSQL 上，就像给老房子装了智Neng门锁——既保留了原来的结构，又多了一层高科技安全感。以后你再去折腾那些独立向量数据库，也Ke以先从这里起步，再决定是否要拆墙扩建。哈哈，这篇聊完啦，希望你们玩得开心！

---