随着 ChatGPT 的兴起及其背后的 AIGC 产业不断升温，向量数据库已成为备受业界瞩目的领域。FAISS、Milvus、Pinecone、Chroma、Qdrant 等产品层出不穷。市场调研公司 MarketsandMarkets 的数据显示，全球向量数据库市场规模预计将从 2020 年的 3.2 亿美元增长至 2025 年的 10.5 亿美元，年均复合增长率高达 26.8%。这表明向量数据库正从最初的不温不火逐步演变为大模型的 “超级大脑”。向量数据库，不仅解决了大模型在 “事实性” 和 “实时性” 方面的固有缺陷，还为企业重新定义了知识库管理方式。此外，与传统关系型数据库相比，向量数据库在处理大规模高维数据方面具有更高的查询效率和更强的处理能力。因此，向量数据库被认为是未来极具潜力的数据库产品。然而，面对非结构化数据的挑战，传统的关系型/非关系型数据库并未坐以待毙。开始支持向量数据库的特性，PostgrelSQL 就是其中的佼佼者。本文探讨的主题是：如何利用 PostgreSQL 实现向量检索以及全文检索。
从大模型的内卷说起
截止目前，OpenAI 官方支持的上下文长度上限为 128K，即 128000 个 token，这意味着它最多可支持约 64000 个汉字的内容。当然，如果考虑到输入、输出两部分的 token 消耗数量，这 64000 个汉字多少要大打折扣。除此以外，国外的 Claude 2、国内的 Moonshot AI，先后将上下文长度提升到 200K 量级，这似乎预示着大模型正在朝着 “更多参数” 和 “更长上下文” 两个方向“内卷”。众所周知的是，现阶段大模型的训练往往需要成百上千的显卡，不论是“更多参数”还是“更长上下文”，本质上都意味着成本增加，这一点，从 Kimi 近期的宕机事件就可以看出。
所以，为什么说 RAG(Retrieval-Augmented Generation) 是目前最为经济的 AI 应用开发方向呢？因为它在通过外挂知识库 “丰富” 大模型的同时，能更好地适应当前 “上下文长度受限” 这一背景。诚然，如果有一天，随着技术的不断发展，芯片的价格可以变得低廉起来，大模型可以天然地支持更长的上下文长度，或许大家就不需要 RAG 了。可至少在 2024 年这个时间节点下，不管是企业还是个人，如果你更看重知识库私有化和数据安全，RAG 始终是绕不过去的一个点。同济大学在 Retrieval-Augmented Generation for Large Language Models: A Survey 这篇论文中提出了 RAG 的三种不同范式，如下图所示：
实现向量检索
PostgreSQL，可以说是目前世界上功能最强大的数据库系统之一。针对这个观点，请你先不要急着反驳我。因为，你可以利用这个时间来阅读下面这篇文章《技术极简主义：一切皆用 Postgres》。更不必说，这篇文章里的内容，对于整个 PostgreSQL 生态而言，不过是沧海一粟。单单是向量检索这个话题，你可以看到诸如 pase、pgvector、pg_embedding、pg_vectorize 等解决方案。这里，博主以 pgvector 这个插件为例来进行说明。
pgvector 基本使用
CREATE EXTENSION IF NOT EXISTS vector;
首先，我们使用上面的 SQL 语句来启用 pgvector 插件。此时，我们可以创建一张表来存储向量数据：
CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3));
接下来，准备若干条数据进行查询测试，可以注意到，这里的向量为三维向量：
INSERT INTO items (embedding) VALUES ('[1,2,3]'), ('[4,5,6]'), ('[7,8,9]');
现在，假设我们有一个向量为：[3,2,1]，如何查询距离该向量最近的数据呢？
# L2/欧式距离
SELECT *, embedding <-> '[3,2,1]' AS distance FROM items ORDER BY distance ASC;
# 向量内积
SELECT *, 
