你有没有想过一个问题：ChatGPT 为什么不敢回答"我的生日是哪天"？为什么明明你上周告诉过它，它转头就忘？答案很简单——大模型没有"长期记忆"。而向量数据库，就是给大模型装上"记忆体"的终极方案。

---

引子：大模型的两大致命缺陷

缺陷一：知识过时

GPT-4 的训练数据截止到某个时间点。你今天问它一些最新的事情，它要么不知道，要么胡说八道。

原因：模型的知识在训练那一刻就"冻结"了。它不会自动更新。

缺陷二：没有记忆

你和大模型聊了 10 轮对话，它表现得像个老朋友。但如果你关掉对话，重新打开——它又把你当陌生人。

原因：大模型本身没有"长期记忆"。每次对话都是"第一次见面"。

这两个缺陷怎么解决？

• 方案一：重新训练模型。成本几千万美元，耗时几个月。不现实。
• 方案二：把所有知识塞进 prompt。但大模型的上下文窗口有限，塞不下。不可行。
• 方案三：向量数据库（Vector Database）+ RAG（检索增强生成）。这就是答案。

---

第一章：什么是向量数据库？

1.1 从"向量"说起

在 AI 领域，向量就是一段数字数组，用来表示任何事物的"语义"。

把一句话变成向量，这个过程叫 Embedding（嵌入）：

"今天天气真好"  ->  [0.12, -0.56, 0.89, 0.33, ..., 0.71]  (768 维向量)
"it's a nice day"  ->  [0.15, -0.48, 0.92, 0.28, ..., 0.68]  (768 维向量)

关键点：语义相近的句子，它们的向量在空间中的距离也相近。

1.2 向量数据库是什么？

传统数据库存的是结构化数据（行、列、表），用"精确匹配"来查询：

SELECT * FROM users WHERE name = '张三';

向量数据库存的是向量数据（数字数组），用"相似度搜索"来查询：

client.search(collection="documents", vector=query_vector, limit=10)

1.3 一句话总结

传统数据库：找"一模一样的"。
向量数据库：找"最像的"。

---

第二章：大模型为什么需要向量数据库？

2.1 核心问题：幻觉

大模型有一个"天生缺陷"——幻觉（Hallucination）。它会在你不知道的时候，一本正经地胡说八道。

原因：大模型本质上是"文字接龙机"，它不"知道"事实，它只是"预测"下一个最合理的词。

2.2 解决方案：RAG（检索增强生成）

RAG 的核心理念：不让大模型"背"知识，而是让它"查"知识。

用户提问 -> 问题转向量(Embedding) -> 向量数据库检索 -> 检索到相关知识
    -> 组装 Prompt(问题 + 知识) -> 大模型生成回答 -> 最终回答

2.3 RAG 的工作原理

步骤一：构建知识库

把文档切分成小段，每段转成向量，存入向量数据库。

步骤二：实时检索

用户提问时，把问题转成向量，在数据库中检索最相关的 3-5 条知识。

步骤三：增强生成

把检索到的知识拼进 prompt，让大模型基于"已知信息"生成回答，而不是凭记忆。

2.4 RAG 的效果有多好？

场景	纯大模型	大模型 + RAG
回答准确率	60-70%（常出现幻觉）	90-95%（基于事实）
知识更新	需要重新训练	更新向量库即可
时效性	训练数据截止日期	实时更新
成本	训练成本极高	维护知识库即可
可解释性	黑盒，不知道来源	可追溯原文出处

---

第三章：向量数据库的核心原理

3.1 向量相似度计算

向量数据库的灵魂是"找相似"。计算两个向量距离的方法主要有三种：

余弦相似度（Cosine Similarity）：范围 -1 到 1，越接近 1 越相似。

def cosine_similarity(v1, v2):
    return np.dot(v1, v2) / (np.linalg.norm(v1) * np.linalg.norm(v2))

# 语义相近输出 0.99，语义无关输出 0.15

欧氏距离（Euclidean Distance）：越小越相似。

3.2 近似最近邻搜索（ANN）

如果向量库里有 10 亿个向量，要找到"最相似"的那一个，遍历所有向量？那速度会慢到让人崩溃。

向量数据库的杀招：ANN（Approximate Nearest Neighbor）

算法	特点	代表产品
HNSW	分层导航小世界图，速度最快	Milvus, Qdrant
IVF	倒排索引文件，内存友好	Faiss, Pinecone
PQ	乘积量化，压缩率高	Faiss, Weaviate

3.3 HNSW 算法通俗版

HNSW 的工作原理有点像地图导航：先在高楼层定位大致区域，再逐层向下，精确找到目标。

类比：找一家餐厅，先确定城市，再确定街道，最后找到具体门牌号。

---

第四章：主流向量数据库产品对比

4.1 Milvus / Zilliz Cloud

特性	说明
厂商	Zilliz（开源 + 云服务）
架构	分布式，云原生
性能	10 亿级向量，毫秒级响应
适用	企业级大规模部署

from pymilvus import Collection, connections
connections.connect(host="localhost", port="19530")
collection = Collection(name="rag_knowledge_base")
results = collection.search(data=[query_vector], anns_field="vector", limit=5)

4.2 Pinecone

特性	说明
厂商	Pinecone（纯 SaaS）
架构	全托管，零运维
性能	自动索引，毫秒级响应
适用	不想自己运维的团队

import pinecone
pc = pinecone.Pinecone(api_key="your-api-key")
pc.create_index(name="knowledge-base", dimension=768, metric="cosine")
index = pc.Index("knowledge-base")
index.upsert([("id1", [0.12, 0.34], {"text": "..."})])

4.3 Qdrant

特性	说明
厂商	Qdrant（开源 + 云服务）
架构	Rust 编写，性能极致
性能	单机百万级 QPS
适用	高性能、低延迟场景

4.4 Chroma

特性	说明
厂商	Chroma（开源）
架构	轻量级，嵌入式
性能	适合中小规模
适用	个人项目、原型开发

import chromadb
client = chromadb.Client()
collection = client.create_collection(name="my_docs")
collection.add(documents=["今天天气真好", "服务器宕机了"], ids=["doc1", "doc2"])
results = collection.query(query_texts=["天气怎么样"], n_results=1)

4.5 选型对比总结

产品	部署方式	适合规模	上手难度	成本
Milvus	自建/云	企业级(10亿+)	中等	高
Pinecone	纯 SaaS	中大型	简单	中高
Qdrant	自建/云	中大型	中等	中
Chroma	嵌入式	个人/小团队	简单	免费

---

第五章：实战：用向量数据库给大模型装上"记忆"

5.1 场景：企业知识库问答机器人

公司内部有一堆运维文档、技术手册、历史故障记录，员工遇到问题可以直接问 AI。

技术栈：LangChain + Chroma + 阿里云百炼

5.2 完整代码实现

import os
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.llms import OpenAI
from langchain.chains import RetrievalQA

with open("运维手册.md", "r", encoding="utf-8") as f:
    document = f.read()

text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = text_splitter.split_text(document)

embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_texts(texts=chunks, embedding=embeddings, persist_directory="./chroma_db")

llm = OpenAI(model="qwen-max-latest", temperature=0.1,
    api_key=os.getenv("DASHSCOPE_API_KEY"),
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1")

qa_chain = RetrievalQA.from_chain_type(llm=llm, chain_type="stuff",
    retriever=vectorstore.as_retriever(search_type="similarity", search_kwargs={"k": 3}),
    return_source_documents=True)

for q in ["服务器宕机了怎么处理？", "数据库连接超时怎么办？"]:
    result = qa_chain({"query": q})
    print(f"回答：{result['result']}")

5.3 输出效果

问题：服务器宕机了怎么处理？
回答：根据运维手册，服务器宕机后应按照以下步骤处理：
1. 首先检查网络连通性，ping 服务器 IP
2. 如果网络不通，检查物理链路和交换机
3. 如果网络通但服务不可用，登录服务器查看系统日志
4. 检查磁盘空间、内存使用率、CPU 负载
5. 根据具体原因采取相应措施

关键点：回答不是大模型"编"出来的，而是从知识库中检索相关信息后生成的。

---

第六章：向量数据库的更多应用场景

6.1 推荐系统

传统推荐：基于标签（“喜欢动作片，推荐动作片”）
向量推荐：基于语义（“喜欢《黑客帝国》，推荐《盗梦空间》”）

6.2 图片搜索

把图片转成向量，用语义搜图片。搜"红色的汽车"不需要图片标签，语义匹配即可。

6.3 异常检测

把正常行为模式存为向量，新行为如果离所有正常向量都很远，就是异常。

6.4 去重和相似内容检测

文章入库前转成向量，如果和已有文章相似度超过 95%，说明是重复内容，跳过入库。

---

第七章：向量数据库的局限与挑战

7.1 不是银弹

局限	原因	应对方案
精度不如全文搜索	ANN 是近似搜索	结合 BM25 混合检索
依赖 Embedding 质量	烂 Embedding 出烂结果	选对 Embedding 模型
冷启动问题	新数据需要时间积累	先用传统搜索过渡
成本	大规模索引吃内存	用量化压缩

---

总结：一张图看懂为什么大模型离不开向量数据库

大模型的缺陷：知识过时 + 没有记忆 + 产生幻觉
              |
              v
     向量数据库（RAG）来拯救
              |
              v
     给大模型装上"长时记忆"
     回答准确率从 60% 提升到 95%

一句话总结：大模型是"大脑"，向量数据库是"长时记忆"。没有记忆的大脑，再聪明也会犯傻。

---

相关阅读

• 安装 Hermes 桌面版，连接阿里云百炼
• 从 Excel 到湖仓一体：大数据架构 20 年演变史

关于作者

一名在 DBA 和 AI 之间反复横跳的技术人。写过数据库，也写过 AI 应用，最大的感悟是：技术不是目的，解决问题才是。