向量数据库是什么？

向量数据库只回答一个问题，而且答得很快

给它一串数字，它就返回与之最接近的存储数字串。这就是它全部的交互方式。

这些数字串就是嵌入向量。嵌入模型把一段文字、一条商品描述或一张图片转换成几百到几千个数字，让含义相近的内容在数字空间里彼此靠近，什么是AI中的嵌入向量介绍了具体做法。向量数据库就是这些数字串在数量变大之后的存放之处。它为每一条记录附上ID和一些元数据，在它们之上建立索引，并回答最近邻搜索的问题："这是一个查询向量，给我最接近的十个。"

难点在于"快"这个字。把一个查询向量和一百万条各含1,536个数字的存储向量逐一比较，需要15亿次乘法运算，如果每敲一次键盘都要这样算一遍，根本无法扩展。所以向量数据库使用近似最近邻索引，最常见的是HNSW，这是Malkov和Yashunin在2016年发表的一篇论文中提出的图结构，它只访问几百个候选项而不是全部一百万个，却几乎每次都能给出正确答案。这个"几乎"就是取舍所在：牺牲一点召回率，换来上千倍的速度提升。

你现有的数据库匹配文字，向量数据库匹配含义

关系型数据库查找值匹配的行：WHERE customer_id = 4127。全文索引查找包含某些词的文档：退款 AND 政策。向量数据库查找含义相近的条目：查询"我怎样才能拿回我的钱"会返回标题为"退货与退款"的段落，尽管两者没有一个共同的词。

最后一行说明了这个分类有多模糊。pgvector为普通的Postgres加上向量列和HNSW索引，而Elasticsearch自2019年的7.0版起就带有向量字段，2022年的8.0版起又加入了HNSW搜索。所谓"向量数据库"，很多时候只是你已经在用的数据库里的一项能力，而不是全新的产品，独立产品之间比拼的是规模和运维打磨，而不是做一些Postgres做不到的事。

文档问答本质上是向量搜索加上末端的一个模型

检索增强生成（RAG）分为搜索和写作两步，什么是RAG对此有详细说明。向量数据库承担的就是搜索这一步。

1. 把每份文档拆成几百到一千个token的段落。
2. 对每个段落做嵌入，把向量连同段落文本和来源一起存入向量数据库。
3. 问题到来时，对问题做嵌入，向数据库请求最接近的段落。
4. 把这些段落连同问题一起交给语言模型，让它写出答案。

第1步和第2步只在文档被加入时发生一次，第3步和第4步在每次提问时都会发生。语言模型永远看不到整个文档集，它看到的是数据库挑出的五到十个段落。这就是为什么答案的好坏完全取决于搜索的好坏：如果最近的向量对应的是错误的段落，模型就会自信地回答错了问题，什么是AI幻觉把这归为检索失误，而不是凭空捏造。

什么时候需要它，什么时候整篇发送更好

这个决定关乎大小。模型一次只能考虑它的上下文窗口所能容纳的内容，其中每一个token在每一轮对话里都要付费。向量数据库存在的意义，就是只把相关的那一小片内容放到模型面前。对于能塞进去的单份文档，检索这一步是可以跳过的；对于塞不进去的文档集，它就是唯一的办法。

以一份30万token、几百页的报告为例，问十个问题，每个问题检索五段各1,000个token的段落，来对比这两种方案的成本。每次都发送整份文件，累计是300万输入token。每个问题检索五段各1,000个token，累计是5万。按AI模型成本指数（数据取自2026-08-20的OpenRouter）中的标价输入费率，各个模型上的差距都是60倍。在提供商支持提示词缓存的地方，重复读取同一份文件按标价的十分之一到一半计费，这会把差距缩小到大约6倍到30倍之间。检索方案仍然更划算，只是领先幅度变小了。

如果文件的大小在预算之内，整篇发送的方案能用这笔钱换来一些东西：一份60页、大约4万token的合同，能让模型回答那些需要通览全篇的问题，比如"这里有没有哪一处和第14条矛盾"，而检索方式无法回答这类问题，因为它从来没有在同一批内容里同时看到第14条和那处矛盾。由此得出的规则是：单份文档，或者少量几份，整篇放进去；一整个文档库，就走向量数据库。介于两者之间时，按主题拆分上传内容，让模型拿到它需要的那一部分。

Whizi直接发送文本本身，单轮最多4万token

Whizi不会为你的对话运行向量数据库。当你附加一个文件时，文档上传流程会提取文本，把它作为提示词文本发给模型，单轮预算固定为4万token；超出的上传内容会被截断，并附带一个提示条和消息内的标记说明这一点。项目文件的原理相同：项目功能最多固定10个文件，每条消息都会把它们的文本重新组入提示词，单个文件上限3.2万字符，整个项目区块上限12万字符。

这些上限就是这套设计的边界。固定文件超过3.2万字符会被截断，附件超过单轮4万token的预算会被裁剪，而一个项目是一个文件夹，不是可搜索的资料库。这个取舍是刻意为之的：对于能塞进单轮预算的合同或论文，让文本原样在场，比让它被搜索更好，而真正管用的检验方式，也就是让模型引用它所依据的原文段落，之所以有效，正是因为这段原文确实在场。对于成千上万份文档，向量数据库才是正确的工具，聊天应用不是。

由此衍生出两个习惯。当附加了多个文件时，在你的问题里点名要用哪个文件，否则模型会默默自己选一个。而且对于任何你会据此采取行动的答案，都要求它给出原文引用。检索系统可能返回错误的段落，整篇发送的系统则可能凭记忆而不是原文来回答。要求引用能同时防住这两种情况。