向量数据库是什么：什么时候需要，什么时候不需要

很多人听到向量数据库，会以为它是普通数据库的升级版。其实它解决的问题不同。MySQL、PostgreSQL 这类数据库擅长精确查询，比如 user_id 等于 1001，订单状态等于 paid，创建时间在某个范围内。向量数据库擅长相似度检索，比如这句话和哪些文档语义接近。

向量可以理解成一组数字，用来表示文本、图片或音频的语义特征。比如用户问如何申请退款，和文档里的售后退款流程虽然字面不完全一样，但语义接近。把问题和文档都转成向量后，就可以通过距离或相似度找到相关资料。

向量数据库的价值不在存数据本身，而在快速找到语义相似的数据。RAG、语义搜索、推荐、去重、相似图片搜索都可能用到它。但如果你的查询是精确条件过滤，普通数据库更合适。

关键词搜索依赖词面匹配。用户搜退款，文档里也有退款，就容易命中。如果文档写售后申请、费用退回，而没有退款这个词，关键词搜索可能找不到。向量检索更关注语义接近，所以能处理同义词、近义表达和口语化提问。

但向量检索不是万能。它可能找到语义相近但业务上不准确的内容。例如用户问退款，系统可能召回售后政策、取消订单、赔付规则，这些都相关，但不一定都是答案。RAG 里通常会结合关键词、元数据过滤和重排序，不能只靠向量距离。

最稳的搜索系统往往是混合的。关键词搜索保证精确词命中，向量搜索补充语义召回，元数据过滤控制范围，比如只搜当前产品、当前版本、当前语言的资料。

当你的用户会用自然语言提问，而资料里表达方式不固定时，向量数据库就有价值。比如企业知识库问答、客服文档检索、技术文档助手、合同条款查找、产品说明搜索。用户不一定知道文档里的精确词，但希望系统理解意思。

当资料数量比较多，普通关键词搜索命中率不稳定时，也可以考虑向量检索。比如上千篇文档、几万条 FAQ、很多段产品说明，人工维护关键词会很累。向量检索能降低用户必须输入准确词的门槛。

当你要做 RAG，通常会用到向量库或向量检索能力。用户问题先转成向量，召回相关片段，再交给大模型回答。向量库不是 RAG 的全部，但它常常是检索层的重要组成部分。

如果数据量很小，比如只有 20 条 FAQ，直接关键词匹配或人工配置就够了。为了 20 条内容上向量数据库，维护成本可能高于收益。如果问题和答案都很固定，比如营业时间、客服电话、固定链接，也不一定需要向量。

如果查询条件是明确字段过滤，比如订单号、手机号、商品 ID、状态、时间范围，普通数据库更合适。向量数据库不能替代业务数据库。用户问我的订单到哪了，应该查订单系统，而不是在文档里做语义检索。

如果资料质量很差，也不要急着上向量库。乱码、重复、过期、冲突、标题缺失的资料，进入向量库后只会让检索更混乱。先整理资料，再考虑向量化。

第一，整理资料。去掉过期内容、重复内容和无关内容。第二，给资料加元数据，比如来源、分类、产品、版本、更新时间。第三，决定切片方式。切片太长会混主题，切片太短会缺上下文。第四，准备测试问题，评估召回结果是否准确。

元数据很重要。比如同样是退款政策，不同产品、不同地区、不同版本可能不一样。如果没有元数据过滤，向量检索可能召回错误范围的资料。很多 RAG 答错，不是模型不会，而是检索阶段拿错资料。

工具帮的文本清洗、Markdown 工具和关键词分析工具可以帮助做前期整理。向量化之前，先让资料对人可读；资料对人都不清楚，对机器也很难稳定。

不要只看最终回答，要先看召回的资料片段。用户问退款流程，前 3 条召回是否真的包含退款规则？是否命中了过期文档？是否缺少关键步骤？如果召回错了，大模型后面很难答对。

建议准备一批测试问题，每个问题标注理想命中文档。上线前先跑召回评估，再看生成回答。召回质量、回答质量、引用准确性要分开看。否则你只知道效果不好，却不知道问题出在资料、切片、向量模型、检索参数还是提示词。

向量数据库是 AI 应用里的基础设施，不是装上就有效。它需要资料治理、测试集、监控和持续优化。理性使用，才能让它真正帮你解决搜索和问答问题。