万字详解面试题库

第一，非结构化数据的语义存储。传统数据库存的是结构化表格，无法直接存储文本、图片这类非结构化数据。向量数据库把这类数据转成高维向量，实现语义层面的存储。

第二，语义相似度检索。传统数据库只能做精确匹配，比如查"苹果"就找不到"iPhone"。向量数据库基于向量距离计算语义相似度，能找出意思相近的内容。

第三，高效的大规模检索。面对百万甚至千万级别的向量数据，向量数据库通过专门的索引算法（如HNSW、IVF），把检索复杂度从O(N)降到O(logN)，保证毫秒级响应。

在AI Agent里，向量数据库通常用来存知识库和对话历史，让Agent能快速找到相关的背景信息。

存储方式不同。关系型数据库存的是行和列，数据之间通过主键外键关联。向量数据库存的是高维向量，每个向量代表一段文本或图片的语义特征。

检索逻辑不同。关系型数据库用SQL做精确查询，条件必须完全匹配。向量数据库用相似度算法（余弦相似度、欧氏距离）做模糊匹配，找的是"最像"的结果而不是"完全相等"的结果。

适用场景不同。关系型数据库适合存配置信息、业务数据这些结构化内容。向量数据库适合存知识库、用户画像、推荐特征这些需要语义匹配的内容。

实际项目中两者往往是互补关系，不是替代关系。

RAG系统里向量数据库的工作分为两个阶段：

索引阶段（离线）：

第一步是文档切分。把长文档切成合适大小的片段，通常200-500字一段，既能保留完整语义，又不会太长导致检索不精准。

第二步是向量化。用Embedding模型（如BGE、M3E）把文本片段转成向量，通常是768维或1024维。

第三步是入库。把向量连同原始文本、文档ID、分类标签等元数据一起写入向量数据库，同时创建向量索引加速后续检索。

查询阶段（在线）：

用户提问后，先把问题转成向量，然后在向量数据库里做相似度搜索，召回Top K个最相关的文档片段，最后把这些片段拼进Prompt传给大模型生成答案。

选型主要考虑四个维度：

语言适配。中文场景优先选BGE、M3E、Text2Vec这些中文模型，英文场景可选OpenAI的text-embedding-ada-002或sentence-transformers系列。

向量维度。维度越高表达能力越强，但存储和计算成本也越高。常见有384维、768维、1024维，一般768维是性价比比较好的选择。

上下文长度。模型能处理的最大文本长度，要覆盖你的文档片段大小。常见有512、1024、2048、8192，如果文档片段较长，要选长上下文模型。

效果指标。参考模型在C-MTEB、MTEB等评测集上的MRR、NDCG、Recall@K指标，但也要在自己的业务数据上实测验证。

实际选型建议先用开源模型验证效果，达不到要求再考虑商用API。

常见的向量数据库及其特点：

Milvus - 专门的向量数据库，支持分布式部署、多种索引类型、混合查询，适合大规模生产环境，是目前国内用得最多的开源方案。

Faiss - Facebook开源的向量检索库，适合小规模本地部署，支持多种索引算法，但不支持分布式和持久化，一般用于原型验证。

Pinecone - 托管云服务，开箱即用但成本较高，适合快速验证想法，不适合数据敏感的场景。

pgvector - PostgreSQL的向量扩展，适合已有PG基础设施的项目，可以复用现有的运维能力。

Elasticsearch - 也支持向量搜索，适合需要同时做关键词搜索和向量搜索的混合场景。

选型要根据数据规模、查询QPS、团队技术栈、运维能力综合考虑。

HNSW和IVF是两种主流的向量索引算法：

HNSW（分层导航小世界图）基于图结构构建索引，查询时从顶层开始逐层向下导航，直到找到最近邻。特点是构建慢、查询快、精度高，适合数据相对静态、查询频繁的场景。

IVF（倒排文件索引）先把向量聚类成多个簇，查询时只检索最相关的几个簇。特点是构建快、查询相对慢一些，适合数据频繁更新的场景。

选型建议：

数据量小（万级以内）、对准确率要求极高（如医疗、法律）选IVF_FLAT暴力检索。

数据量大（十万级以上）、对查询速度要求高（如客服系统）选HNSW。

数据频繁更新选IVF，数据相对静态选HNSW。

召回和重排是检索流程中两个不同的阶段：

召回阶段的目标是从海量文档中快速筛选出可能相关的候选集。追求高召回率，宁可错杀不可放过。通常用向量相似度搜索，速度快但精度一般，召回几十到几百个结果。

重排阶段的目标是对召回的候选集进行精确排序，找出最相关的文档。追求高准确率，确保排在前面的都是真正相关的。通常用Cross-Encoder等更精确的模型，直接计算Query和文档的交互相关性，速度较慢但精度高，一般只处理Top K个候选。

为什么分两阶段：

如果直接用Cross-Encoder对所有文档打分，计算量太大无法接受。先用向量检索快速召回候选，再用重排模型精确排序，是效率和效果的平衡。

提高检索准确率可以从三个层面入手：

查询优化层面：

查询扩展 - 用LLM把用户问题改写成多个同义表达，增加命中概率。

查询分解 - 把复杂问题拆成多个子问题分别检索。

HyDE技术 - 用LLM生成假设答案，再用答案去检索相似文档。

索引优化层面：

文档切分策略优化 - 按语义边界切分而不是固定长度。

元数据增强 - 给文档打上标签、分类、时间等元数据，检索时先过滤再搜索。

摘要索引 - 存储文档摘要用于粗排，原始文本用于精排。

重排序层面：

用更精确的模型对召回结果二次排序，比如用Cross-Encoder计算问题和文档的相关性分数。

常用的相似度算法有四种：

余弦相似度计算两个向量夹角的余弦值，值域[-1, 1]，1表示方向完全相同。优点是对向量长度不敏感，只关注语义方向，适合文本语义匹配。这是AI Agent中最主流的算法。

欧氏距离计算向量空间中的直线距离，距离越小越相似。对向量绝对差异敏感，适合多模态数据检索（如图像+文本匹配）。

点积直接计算向量对应元素相乘再求和。计算最快，适合大规模检索，但受向量长度影响，需要配合归一化使用。

曼哈顿距离计算各维度差值的绝对值之和。计算速度快，适合低维度向量、对检索速度要求高的轻量场景。

实际应用中，文本检索首选余弦相似度，多模态检索可以考虑欧氏距离。

文档更新处理有三种策略：

全量重建最简单的方式，文档更新后重新切分、向量化、构建索引。适合更新频率低的场景，但数据量大时耗时很长。

增量更新更高效的方式，只处理变更的文档。新文档直接添加到索引，删除的文档从索引中移除，修改的文档先删除旧版本再添加新版本。

索引分区按时间或类别分区，更新时只重建受影响的分区，减少重建范围。

更新策略：

实时更新 - 文档变更立即触发索引更新，适合对实时性要求高的场景。

定时更新 - 比如每小时或每天批量更新一次，适合更新频率适中的场景。

还要考虑更新期间的查询服务不中断，通常采用双索引切换或者索引版本管理来实现平滑过渡。

这两个参数都需要通过实验确定，没有固定标准。

分块大小的考虑：

太小会丢失上下文信息，比如一个段落被切成多块，每块单独看都语义不完整。

太大会降低检索精度，一个块包含太多内容，只有一小部分相关，会干扰模型注意力。

通常几百个Token比较合适，比如256到512之间。还要考虑文档结构，按段落或章节边界切分比固定长度切分效果更好。

topK参数的选择：

要权衡召回率和成本，K太小可能漏掉相关信息，K太大会增加噪声和成本。

通常先设置一个较大的值比如10到20，然后通过实验找到最优值。

评估方法是用测试集测试不同K值的Recall和Precision，找到平衡点。

实际应用中还可以动态调整，对于复杂问题增大K值，简单问题减小K值。

元数据过滤是提升检索效率的重要手段。

基本思路：在向量化存储时，除了存储向量本身，还要存储相关的元数据，比如文档ID、分类标签、创建时间、来源渠道等。检索时先通过元数据条件过滤，缩小搜索范围，再在这个子集上做向量相似度搜索。

典型场景：

按时间过滤 - 只检索最近一个月的知识。

按分类过滤 - 只检索某个产品线的文档。

按权限过滤 - 只检索用户有权限查看的内容。

实现方式：

Milvus等向量数据库支持标量字段索引，可以在向量检索前先用标量条件过滤，减少向量计算的数据量。

生产环境部署要考虑以下几个方面：

高可用：多实例部署，负载均衡，避免单点故障。数据要有备份机制，防止数据丢失。

性能监控：监控检索延迟、吞吐量、存储空间使用率。设置告警阈值，及时发现性能瓶颈。

容量规划：根据向量维度和数据量估算存储需求。向量数据比原始文本大得多，768维的float32向量每个占3KB左右。

索引维护：定期检查索引状态，数据量大的时候考虑分片策略。增量更新频繁时要关注索引碎片问题。

安全配置：如果数据敏感，要做好访问控制，考虑数据加密传输和存储。

多Agent共享向量数据库需要考虑三个问题：

数据权限控制。不同Agent应该有不同的访问权限，有的只能检索，有的可以入库修改。可以通过API层的权限控制或者数据库层面的用户权限来实现。

并发访问处理。多个Agent同时读写可能产生冲突。可以通过加锁、批量处理、或者使用支持高并发的向量数据库来解决。

数据一致性。确保多个Agent对数据库的修改能实时同步，避免出现知识不一致的情况。分布式部署时要关注数据同步延迟。

实现方式：

把向量数据库部署为独立服务，多个Agent通过统一的API访问。或者使用支持多租户的向量数据库，为每个Agent分配独立的命名空间。

向量数据库和LLM的联动流程：

第一步，Agent接收用户query后，先用LLM进行意图解析，理解用户真正想要什么。

第二步，把解析后的query转成向量，调用向量数据库检索相关知识。

第三步，把检索到的知识片段和用户问题一起拼成Prompt，传给LLM生成最终回答。

开发要点：

Prompt设计要明确告诉模型基于提供的上下文回答，不能编造。

检索结果要做长度控制，避免超出模型上下文限制。

可以要求模型给出引用来源，增强答案可信度。

向量数据库可以存储和检索多种类型的数据：

文本向量最常见，用BERT、BGE等文本Embedding模型生成。

图像向量用CLIP、ResNet等视觉模型生成，可以实现以图搜图或者图文互搜。

语音向量先把语音转成文本，再用文本Embedding模型，或者用专门的语音Embedding模型。

统一存储的关键：

使用支持多模态的Embedding模型（如CLIP可以把文本和图像映射到同一向量空间），或者确保不同类型数据的向量维度一致。

检索时可以通过元数据标记数据类型，按类型筛选后再做相似度匹配。

检索结果不相关通常有这几个原因：

Embedding模型不匹配。检查用的模型是否适合当前数据类型，比如用文本模型处理专业领域内容效果可能不好。解决方法是换用领域适配的模型或者在领域数据上微调。

向量索引配置不合理。查看索引类型是否适配数据量，索引参数是否合理。比如HNSW的efSearch值过低会导致精度下降。解决方法是调整索引参数或者重建索引。

相似度阈值设置不当。阈值过低会引入大量低相关结果，阈值过高可能漏掉相关内容。需要通过测试找到平衡点。

知识库质量问题。检查知识库预处理是否到位，是否存在大量无关、冗余的知识片段。解决方法是重新清洗数据，删除无关内容。

排查方法：

先用几个标准测试用例验证，看是普遍问题还是特定query的问题。然后逐一检查模型、索引、阈值、数据质量这几个环节。

性能优化可以从索引、查询、架构三个层面入手：

索引优化：

选择合适的索引类型，HNSW适合查询多，IVF适合更新多。

调整索引参数，比如HNSW的efConstruction和efSearch要在精度和速度之间找平衡。

考虑向量量化压缩，用PQ等方法减少存储和传输开销。

查询优化：

缓存热门查询结果。

先用元数据过滤缩小检索范围，再做向量搜索。

批量检索，减少API调用次数。

架构优化：

读写分离，查询走从节点，写入走主节点。

水平扩展，增加节点分担查询压力。

就近部署，把向量数据库部署在离应用最近的位置，减少网络延迟。