前几天帮一个朋友模拟 AI 大模型岗位的面试前几轮聊得都还行一到系统设计题就卡住了。题目其实很常规做一个基于大模型的文档问答系统资料都切好块、向量也都算好了你打算怎么存怎么检索他答得也挺顺用向量数据库先查相似向量再把结果拼回给大模型。面试官又追问了一句那你为什么不用 MySQL 自带的向量插件或者直接用 ES他沉默了几秒回了句“因为向量数据库就是用来存向量的”。这个回答没有错但远不够。面试官想听的不是“向量数据库能存向量”而是你有没有能力判断这个系统在真实数据量下能不能撑住召回结果准不准过滤逻辑怎么写RAG 有没有可能答非所问。换句话说“能存向量”只是入门条件真正的分水岭在于你能不能把向量数据库用对、用好、用出工程边界。这件事不是我第一次遇到。很多开发者和候选人把向量数据库当成“给 AI 用的 Redis”觉得只要能写进去、能查出来就行。但等到线上发现召回质量差、查询超时、脏数据污染了 RAG 结果、加了一个标量过滤后速度断崖式下跌才意识到自己根本不了解这层技术的设计逻辑。这篇文章想聊清楚一件事在 AI 大模型应用里向量数据库到底在解决什么问题选型和落地时有哪些不显眼但致命的细节面试官追问的每一个“为什么”背后其实在考察什么。1. 向量数据库解决的不是“存”而是“找得准、找得快”很多人对向量数据库的第一印象来自名字认为它就是“用来存向量的数据库”。这个理解不完整甚至有点危险。因为如果只是存向量一个文件、一张表、一段 JSON 都能做到。向量数据库真正要解决的是两件事一是用向量相似度把“语义上相关”的内容找出来二是在数据量很大的时候还能在可接受的延迟内做到这件事。这就引出了第一个核心结论向量数据库的核心能力不是存储而是检索。存储只是入口检索质量、检索性能、检索可控性才是决定它有没有价值的真正指标。1.1 从向量化到检索存储只是起点一个典型的向量检索流程是这样先把文本、图片、音视频等内容通过嵌入模型转成一串 float 数组比如 768 维、1024 维甚至 1536 维。然后把向量交给数据库保存。查询时把用户的问题也转成向量数据库在已有的向量集合里做相似度计算返回最接近的一批结果。到这里读者可能觉得“这不就是 K 近邻搜索吗”。是的最朴素的方案就是暴力计算把每个向量和查询向量挨个算一遍距离取 TopK。问题在于暴力计算的时间复杂度是 O(N)N 是向量总数。几万条时还能忍受到了百万、千万甚至上亿规模单次检索的延迟和计算成本就无法接受了。所以向量数据库真正比拼的不是谁能“算出相似度”而是谁能在海量向量里快速找出“足够相似”的候选集。大多数产品采用的都是近似最近邻搜索英文缩写作 ANN。它牺牲了少量精度换来数量级提升的检索速度。这也是为什么向量数据库的检索结果不一定每次都是数学上的严格最近邻但通常足够用。这里需要建立第一个观念向量数据库是“检索系统”不是“存储方案”。评估它时不能只看能不能写入向量要看召回质量、延迟、并发能力、可扩展性以及和标量条件的配合能力。1.2 “近似”的代价召回率、准确率和延迟怎么权衡面试中经常出现一个追问向量数据库返回的结果一定是全局最相似的吗答案是不一定是。很多主流向量索引追求的是“在很短时间内找到足够好的结果”而不是老老实实扫描全部向量。这个设计是有意的因为暴力搜索在数据量大时过慢很难支撑在线检索。于是厂商在索引结构和搜索策略上做折中有的参数能提高精度但变慢有的参数能提速但会丢一些结果。对开发者来说真正要关心的指标有三个召回率真实 TopK 里有多少条被检索出来了。准确率返回的结果里有多少条真正相关。延迟一次查询需要多久。这三个指标互相制约。把 TopK 从 10 调到 50召回可能变好但下游大模型的上下文变长成本和延迟都会增加。把索引的ef_search调大精度变高但查询变慢。没有“绝对最优”只有“场景适配”。实际落地时我建议先建一个小的评测集合不用太多几十到几百条典型问题就够了。每次修改索引参数、分块策略或嵌入模型后在评测集合上重新跑一遍观察召回有没有变差。不要凭感觉调参。1.3 面试必问距离度量选错会让召回结果完全跑偏向量之间“像不像”是通过距离函数算出来的。常见的度量有三种欧氏距离L2、内积IP、余弦相似度。很多人直接套默认值但这里其实有时间埋点。先说适用范围。余弦相似度看的是两个向量的方向是否一致常用于文本、语义检索因为文本向量的绝对大小和句子长度有关方向更能代表语义。欧氏距离看的是空间中的绝对距离适用于向量各维度尺度差异不大、且数值大小本身有意义的场景。内积则更多出现在某些推荐、召回模型导出的向量里模型训练时可能已经适配了内积打分方式。所以关键不是“哪个最好”而是“你的嵌入模型推荐哪种方式”。使用大多数开源 embedding 模型时官方文档会给出推荐的距离度量。如果不确定可以用一组样本跑一下比较结果质量而不是盲改配置。注意距离度量不是“加上就行”的装饰它直接决定相似度排序的语义。模型训练时用的是某种度量查询时换成另一种等于拿米尺量体重结果会很难解释。2. 选型前必须想清楚的四个维度“选哪个向量数据库”是 AI 大模型面试里出现频率极高的问题。这也是很多人容易露怯的地方因为只背过名字和标签没有理解背后的设计取舍。我总结了四个选型维度数据规模与索引类型、标量过滤能力、混合检索能力、场景匹配度。这四个维度不是并列的功能清单而是层层递进的关系。先从最基础的规模说起。2.1 数据规模和索引类型HNSW、IVF、暴力搜索常见的向量索引类型包括暴力搜索brute force、IVF倒排文件、HNSW分层可导航小世界图等。暴力搜索没有索引查询时扫描全量向量结果最准确但数据量大时不现实。IVF 的思路是把向量聚类成多个桶查询时只搜索最近的几个桶速度快但桶边界附近容易漏掉真实近邻。HNSW 的思路是构建一个多层图结构从高层快速定位到近似的区域再逐步细化到低层精确搜索。它在召回和速度之间通常有不错的表现是目前很多向量数据库和本地索引库的主流选择。面试里讲到 HNSW 时不需要背源码但要能说清它的代价内存占用高、参数敏感、构建时间较长。很多人以为加索引就是“加速”实际上 HNSW 的成本不在查询而在构建和内存。如果数据量大但内存有限HNSW 可能不是最优如果数据频繁更新HNSW 的动态插入删除也要重点关注。选型判断上可以参考几条经验百万级以下很多方案都能胜任选型更多看运维便利性和生态。千万级以上优先考虑支持分布式分片、水平扩展的方案。实时写入频繁时需要考虑索引更新策略和写入吞吐。离线批量导入和一个点一个点写入性能差异可能巨大。2.2 过滤能力标量过滤是不是一等公民真实业务里的向量检索很少是“全库找相似”。常见需求是技术文档只查最近三个月商品只查某个类目客户只查某个地区。这些条件在数据库里属于标量过滤。不少向量数据库早期版本对标量过滤的支持很弱要么先做向量检索再在后端挨条过滤导致搜索结果变少甚至为空要么先按标量条件筛掉大部分数据再在剩余子集上做向量搜索性能极不稳定。这个问题的本质是过滤条件和向量检索是联合执行还是分开执行。如果数据库能利用标量索引快速圈定候选范围再配合向量索引做近似检索性能会稳健很多。如果只是查询后过滤业务上会出现“明明有相关内容但 TopK 里被过滤掉了”的假阴性。所以选型时不要只看“能支持过滤”这个功能点要实测过滤条件下的延迟和召回变化。面试官问“如何在海量数据上做到精确过滤 向量召回”其实是在考察你是否理解这层联动关系。2.3 混合检索向量加关键词不是加分项是必选项语义检索能理解“苹果”和“水果”的关系但它不一定擅长处理品牌名、型号、API 函数名这类精确词。比如用户搜“Milvus 2.4 安装”如果只靠向量相似度可能召回一堆关于 Milvus 的通用介绍却漏掉真正包含安装步骤的段落。这时关键词或全文检索能锁定精确词和向量召回互补。所以“混合检索”不是花哨名词而是 RAG 系统里解决召回不全的关键手段。实现方式通常分两步先用向量检索找到语义相关再用全文检索找到精确匹配最后在 rerank 阶段把两类结果合并排序。也有的数据库直接支持组合查询把向量相似度和 BM25 分数加权计算。这篇文章想强调的是纯向量检索在很多场景下是不够的。如果你做的问答系统涉及大量专业术语、产品名、代码函数建议一开始就把混合检索纳入候选方案避免上线后召回质量被业务方质疑。2.4 场景匹配度RAG、推荐、去重、多模态的取舍不同的业务场景对向量数据库的核心诉求完全不同。RAG 问答最看重召回质量和过滤、混合检索能力因为错误召回会被放大成大模型的错误回答。推荐系统的向量召回更看重高并发低延迟通常需要几毫秒到十几毫秒返回候选。去重场景看重批量导入和精确匹配可能不需要太复杂的索引。多模态检索看重向量维度和嵌入模型匹配以及是否支持存储附带自定义字段。很多人选型时先看明星项目却不先定义自己的场景。实际上最强的数据库如果和你不匹配也是一种成本。可以先列出三个核心场景再把候选方案在这个场景下对比比看文档里的功能图更有效。3. 从能存到可用一次 RAG 检索链路的落地复盘前面讲的都是选型认知。接下来这部分直接落到操作。我们用常见的 RAG 文档问答场景来走一遍从文档入库到检索召回再到发现问题并排查完整链路应该怎么做。为什么单独用一章写 RAG因为这是目前 AI 大模型应用里向量数据库最常见的落地场景也是面试官最爱问的“系统设计”题出发点。3.1 最小链路embedding、写入、召回一个最小可用的 RAG 检索链路包括四个环节把文档切块。切块大小和重叠率会影响后续召回的粒度。用嵌入模型把每个块转成向量。把向量和原始文本块、文档来源、时间、类型等元数据一起写入向量数据库。查询时把问题转成向量在向量数据库里召回 TopK 块再喂给大模型生成回答。这四个环节里最容易出问题的是前两步。因为向量数据库本身不负责“理解文本”它只负责在向量空间里找距离近的点。如果文本切得太碎一个完整概念被拦腰截断向量表达就会缺乏语义上下文如果切得太大一个块里包含多主题内容检索出来的块可能只有一小段相关噪声增加。实际中我通常建议先按段落切块大小控制在 300 到 800 字上下具体根据文档类型调整。代码文档可以按函数切片合同和制度类可以按条款切。这里没有绝对标准应该用小范围样本测试再定型。3.2 关键参数TopK、分块大小、score 阈值、元数据设计RAG 系统里有几个参数会直接影响大模型的回答质量。第一个是 TopK。TopK 越大召回的信息越全但低相关结果也越多大模型越容易“看到太多不相关的内容”而答偏。同时 token 成本上升。TopK 太小则容易漏掉关键信息。常见起步值是 3 到 5 条再根据评测结果调整。第二个是相似度分数阈值。很多向量数据库会返回一个距离或相似度分数。但这个分数不能直接当“置信度”看不同索引、不同嵌入模型产出的分数分布差异很大。可以收集一批已知相关和不相关的查询观察分数分布再确定阈值。没有这一步阈值就是拍脑袋。第三个是元数据设计。每条向量通常可以附带若干标量字段。比如“文档标题”“页面编号”“作者”“发布时间”“是否生效”。这些字段不仅仅是展示信息还是过滤条件。设计元数据时要让业务可能出现的过滤需求都映射成可查询的字段避免以后为了加一个过滤条件重灌数据。建议先设计元数据模型再写入库脚本。不要等向量写入完毕后再反推过滤条件。3.3 不能只看召回结果日志、评测集、bad case 分析很多团队上线 RAG 后只看“用户提问有没有被回答”。但实际上召回阶段的质量必须单独评估否则出问题时会很难定位是嵌入模型的问题、分块的问题、索引参数的问题还是大模型生成的问题。我之前看过一个问答系统案例用户问“这个产品支持哪些操作系统”系统却答不出完整清单。查的时候发现文档里写系统要求的地方被切进了不同块召回 TopK 里只包含其中一块其他块被截掉了。这很好说明了问题不在大模型而在切块和召回。一个务实的做法是建立一套最小评测集。哪怕只有 20 条问题加对应答案所在的文档也足够发现明显的短板。每次改完分块策略或检索参数把评测集跑一遍记录召回率和回答质量。把召回错误或回答错误的问题存成 bad case每周分析一次。3.4 排查链路召回不准时先查输入、分块、索引、过滤、排序如果线上反馈“答非所问”很多人的第一反应是换大模型。但更合理的排查顺序应该是看输入的查询是否适合向量召回。如果是精确查询比如编号“ABC-2024-001”用关键词或全文检索更合适。看查询向量本身是否正常。嵌入模型对短查询和长文档的表现往往不同可以先判断查询是不是被写错或过度口语化。看分块是否包含完整语义。单独看召回哪几个块读一读是否真的覆盖问题答案。看索引参数是否选择合理。HNSW 的 ef_search 过低会导致召回不足加 filter 后候选范围过小也会导致无结果。看过滤条件是不是误伤了目标内容。最常见的坑是过滤字段的取值不一致比如写入时用category为news查询时过滤用类别为新闻。这个排查链路并不复杂但很有效。它能避免在一个可能根本没有问题的环节上浪费大量时间。4. 面试时怎样回答“向量数据库怎么选”才不容易被追问倒这一章专门写给准备 AI 大模型岗位面试的读者。但核心方法同样适用于实际选型。面试官问“向量数据库怎么选”时真正想听的往往不是“XX 数据库最好”而是你有没有一套判断框架能不能根据场景得出结论。4.1 一个可复用的三层判断框架我自己经常用三层框架来组织回答第一层先问数据规模和使用阶段。如果只是几十万条向量、个人项目或早期验证一个轻量方案就够。如果模型已经确定且数据量到了千万级再考虑分布式和性能更强的方案。第二层再问业务对检索能力的要求。是否需要标量过滤、混合检索、rerank 环节是否有高并发低延迟要求是否需要多租户隔离。这些直接决定选型边界。第三层最后看团队运维能力。团队有没有人力维护额外的集群能不能接受商业化的成本是否需要实时的监控告警和数据备份。有时候性能和运维负担需要一起权衡。框架的价值是让回答显得有层次。即使最终不确定选哪家面试官也能看到你具备判断思路而不是靠背产品对比表。4.2 现场推演轻量方案、开源方案、商业化服务怎么讲举个例子。假设面试官问“现在公司有一个 50 万条文档向量的问答系统团队只有三个人你会怎么选”我会这么拆数据规模 50 万条优先考虑部署和维护成本。这个规模不一定需要一上来就上大集群。如果团队已经有 PostgreSQL 基础可以优先评估 PG 生态自带的向量能力。它能让团队在一个数据库里同时处理业务数据和向量检索减少组件数量。如果召回质量要求高需要混合检索、过滤和多租户能力再考虑独立的开源向量数据库。如果数据量继续增长进入千万级甚至亿级再评估分布式能力或商业化服务。需要说明的是这不是唯一正确答案。关键在于你是从具体的量级、人员、功能要求出发而不是从“名气大”出发。4.3 生产落地的隐藏成本监控、备份、权限和版本升级很多人低估了向量数据库在生产环境中的运维成本。向量数据库本质上是一个基础组件任何基础组件都躲不开问题监控怎么做数据怎么备份权限怎么控制版本怎么升级索引坏了怎么办。监控至少需要覆盖写入速度、查询延迟、错误率、索引内存占用、CPU 和磁盘。备份不是简单导文件向量数据往往和元数据绑定恢复时还需要考虑索引重新构建的耗时。权限控制则要回答“谁能读”“谁能写”“谁能删”。这些都不能只看官网宣传的性能数字。没有监控预警索引膨胀导致查询变慢时你可能最后一个知道。4.4 长期维护索引重建、数据更新、脏数据和可观测性向量数据库的长期维护里最容易忽略的一点是数据更新。业务中文档会被修改、下架、替换。如果旧向量没有被正确删除检索时就会返回过期内容。如果文档经常更新向量更新策略很关键是删除旧向量再插入新向量还是用版本字段标记当前有效版本。脏数据也是一个常见问题。有些文本本身质量很差切块后产生了大量无意义向量它们不会影响搜索速度但会影响召回质量。比如一个空段落被嵌入成向量查询时常被莫名召回。早期就要设计清洗规则。推荐的实践是定期统计召回结果中出现频率高但无法带来有效信息的数据块。对已下架和过期内容做逻辑删除或向量删除。索引构建完成后记录向量数量和版本号方便异常时对比。保留每次检索请求的摘要信息方便回溯 bad case。这些工作听起来琐碎但它们是向量数据库从“能跑”到“稳定跑”的关键。4.5 适用边界不要用向量数据库硬扛所有问题最后必须明确边界。向量数据库不是解决近似搜索问题的唯一方式更不是所有语义问题的银弹。如果有这些场景可能要谨慎使用需要强事务、严格一致性的业务向量数据库通常不适合作为唯一数据源。需要精确匹配和复杂 SQL 聚合的查询传统关系数据库更合适。极低延迟的简单 KV 查询专门的缓存或键值存储更直接。对数学上要求完全真实 TopK、不能接受近似结果的场景需要先评估索引带来的误差。把边界说清楚反而比一味推荐更有说服力。面试官通常会喜欢这种有判断、有取舍的回答。写在最后下一次面试或选型前先做一件小事如果这篇文章读到这里你只记住一句话我希望是向量数据库不是“能存向量就行”它真正要回答的问题是在数据量大、查询复杂、业务多变时你还能不能稳定地找回最需要的信息。“能存向量”是门槛不是能力。能力体现在你有没有一套方法能判断检索质量、过滤条件、索引参数和运维成本之间如何平衡。下一次面试前或者下一次做技术选型前不需要急着背所有数据库的对比表。先拿一个小场景走一遍一批文档、一个嵌入模型、一个向量库、一组评测问题。跑通之后再去读各个方案的文档理解会完全不同。真正的技术判断力不是从资料里看出来的是从一次一次“召回质量不对劲”的排查里练出来的。