Vector Database（向量数据库）
先用一句话说清楚
Vector Database（向量数据库）是用于存储向量并支持相似度搜索的数据库组件，常用于 RAG（检索增强生成）的检索层。
新手通俗解释
Embedding（嵌入向量）把文本变成向量，Vector Database（向量数据库）负责把这些向量存起来，并在用户提问时快速找到相似的文档片段。
你可以把它理解成一个“按意思找资料”的索引库。但它不是完整知识库，也不是自动问答系统。它只负责找到可能相关的片段，后面还需要 Reranker（重排序器）、LLM（大语言模型）、Citation（引用来源）和拒答机制。
为什么智能体工程师岗位会问它
很多 JD（职位描述）会写“熟悉向量数据库、RAG（检索增强生成）、知识库”。面试官问 Vector Database（向量数据库），是想看你是否理解组件选型和工程边界。
常见考察点：
| 考察点 | 应该怎么讲 |
|---|---|
| 作用边界 | 向量数据库负责相似度检索，不负责保证答案正确 |
| 元数据过滤 | 权限、来源、版本、业务范围要随片段一起存 |
| 选型 | 看部署方式、性能、过滤能力、成本和运维 |
| 更新 | 文档变更后如何增量索引或重建索引 |
| 评估 | 检索命中、延迟、成本和失败样例 |
它在项目里到底怎么用
企业知识库里，一个 Vector Database（向量数据库）条目不应该只有向量和文本，还应该带上 Metadata（元数据）：
| 信息 | 为什么重要 |
|---|---|
| 原文片段 | 生成回答时提供证据 |
| 文档标题 | 方便用户理解来源 |
| 文档版本 | 避免旧资料和新资料混用 |
| 权限范围 | 防止用户检索到无权资料 |
| 业务分类 | 支持按部门、产品、场景过滤 |
| Chunk（分块）编号 | 方便引用和复盘 |
| 入库时间 | 判断资料新旧 |
如果只把文本向量塞进去，没有这些信息，后面就很难做权限、引用、评估和运维。
和普通数据库的区别
普通关系型数据库擅长精确条件查询，比如按订单号、用户 ID（编号）、日期范围查记录。Vector Database（向量数据库）擅长相似度搜索，比如按用户问题找语义相关的资料片段。真实项目里两者常常一起用：业务事实在关系型数据库，知识片段在向量数据库。
面试时可以说：向量数据库不是替代所有数据库，而是补充语义检索能力。
常见误解
| 误解 | 为什么不对 | 正确理解 |
|---|---|---|
| 有 Vector Database（向量数据库）就有知识库 | 缺少资料治理、分块、权限、引用和评估 | 它只是检索组件 |
| 向量库选型决定 RAG（检索增强生成）效果 | 效果还受资料、分块、Embedding（嵌入向量）和重排影响 | 要看完整链路 |
| 所有资料都应该入向量库 | 低质量或无权限资料会污染检索 | 入库要有标准 |
| 只存向量就够了 | 没有元数据无法过滤和追踪 | 向量和业务元数据要一起管理 |
面试官可能怎么追问
1. 向量数据库怎么选？
考察点： 是否会做工程取舍。
参考回答： 我会按部署方式、数据量、检索延迟、元数据过滤能力、中文效果、运维成本、权限管理、备份恢复和团队技术栈选择。作品集可以用轻量方案，企业项目要更关注稳定性、权限和监控。
容易扣分： 只背几个产品名。
2. 向量数据库里应该存什么？
考察点： 是否理解可追溯性。
参考回答： 除了向量和文本片段，还要存文档来源、标题、版本、页码或段落位置、权限范围、业务分类、更新时间、Chunk（分块）编号和 Embedding（嵌入向量）模型版本。这样才能做过滤、引用、重建索引和问题复盘。
容易扣分： 只说“存文本和向量”。
3. 检索慢或不准怎么办？
考察点： 是否能从系统角度排查。
参考回答： 慢要看数据量、索引参数、过滤条件、网络、并发和缓存；不准要看资料质量、分块、Embedding（嵌入向量）模型、查询改写、混合检索和 Reranker（重排序器）。不能只盯着向量数据库一个组件。
容易扣分： 直接换库。
作品集里怎么展示它
建议展示一个“索引管理页”或说明表：
- 文档入库后生成了哪些 Chunk（分块）。
- 每个片段有哪些 Metadata（元数据）。
- 用户问题命中了哪些片段。
- 权限过滤前后结果有什么变化。
- 资料更新后如何重建或增量更新索引。
这能让面试官看到你理解知识库工程，而不是只会连一个向量库。