我删除了整个 AI 微服务，只用了 Postgres（原因如下） 🐘⚡

Source: Dev.to

引言

几个月前，我需要构建一个大家现在都在需求的功能：“让用户与他们混乱的数据聊天”。对我而言，这是一大堆杂乱的客服工单。

典型技术栈的问题

如果你在 Google 上搜索如何实现，它会立刻给出一个 5 层架构的方案：

• 用于向量的数据库（vector DB）存放嵌入
• 用于关系的图数据库（graph DB）
• 用 LangChain 将所有东西粘合在一起
• 一个单独的 Python 微服务来运行整个流程

我被这套方案骗了，照着搭建了。结果是，当用户在主数据库中删除了一条工单时，该工单的向量表示仍然残留在向量数据库中，导致 AI 基于已删除的数据产生幻觉式的答案。

“啊哈”时刻 💡

我决定不再把 AI 当作需要专属生态系统的魔法实体，而是回归最可靠的后端工具：Postgres。

Postgres + pgvector = 心安 🧘‍♂️

1. 启用 pgvector 扩展。
2. 将原始数据和嵌入一起存放在同一张表中。

CREATE EXTENSION vector;

CREATE TABLE support_tickets (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid REFERENCES users(id) ON DELETE CASCADE,
  issue_text text,
  embedding vector(1536) -- OpenAI 的嵌入维度
);

注意 ON DELETE CASCADE —— 当工单被删除时，它的嵌入会自动消失。

丢掉沉重的框架 🗑️

大多数 AI 框架把实际的 API 调用隐藏在层层抽象之下，调试起来非常困难。使用 Postgres，整个检索增强生成（RAG）流水线可以简化为一条原始 SQL 查询和一次标准的 API 调用：

1. 用户提出问题。
2. 将问题转换为嵌入。
3. 在 SQL 中直接执行余弦相似度搜索：

SELECT issue_text
FROM support_tickets
ORDER BY embedding  $1
LIMIT 5;

4. 将这五条结果按照严格的 JSON schema 发送给 OpenAI/Anthropic API。

就这么简单——没有微服务，没有每月 80 美元的向量数据库费用，只有一个普通的单体后端高效地完成工作。

我分享这篇文章的原因 ☕

我花了大量时间测试架构、犯错、去除营销噱头，只为让你能够构建真正能在生产环境运行的东西。如果这篇文章帮你避免了不必要的架构重写、巨额 SaaS 费用，或是一个周末的同步错误调试，请考虑在 GitHub 上赞助我的工作：

👉 在 GitHub 上赞助 AmaLS367

赞助让我有自由继续实验、打破常规，并开源可直接在生产环境使用的模板，从而为你节省时间。

TL;DR

我很好奇——你现在是如何管理嵌入的？是使用独立的数据库，还是保持单体？在下方告诉我吧！ 👇