1. 什么是向量数据库？Milvus 解决了什么问题？

• 向量数据库用于存储和检索高维向量（Embedding）。

• Milvus 主要解决大规模ANN问题，兼顾性能与可扩展性。

• ANN：近似最近邻检索。
• 优点：不做全量精确比对，用近似方法快速找到“足够近”的向量
• 缺点：1.不是精确最优，结果稳定性受影响因素多 2.和业务目标不直接等价（受 rerank、prompt、LLM 生成影响）3.更新维护复杂：高频增删改时，索引质量可能漂移常需要增量策略或周期重建

• Milvus 在 RAG 中主要承担“召回相关知识片段”的角色。

2. Milvus 中 Collection、Field、Primary Key 分别是什么？

• Collection 类似一张表。

• Field 是字段（向量字段 + 标量字段）。

• Primary Key 用于唯一标识一条数据（可自定义或自动生成）。

3. L2、IP、Cosine 三种距离有什么区别？如何选择？

• L2：欧氏距离，用于图片，越小越相似。

• IP：内积，越大越相似。

• Cosine：余弦相似度，关注方向，主要用于文本。

• 若 embedding 已归一化，IP 与 Cosine 在排序上通常接近。

4. Milvus 常见索引类型有哪些？

1. FLAT（全量精确检索）
2. metric_type：L2 / IP / COSINE
3. topK：返回前 K 个结果
4. 数据规模（工程侧关键）：数据越大越慢，但准确率最高（基准组）

1. IVF_FLAT（最常问） IVF_FLAT 是“倒排分桶+精检”：先缩小搜索范围，再在候选里做精确距离计算。
2. nlist（建索引参数） 桶数量。越大，桶更细，潜在精度更高，但建索引和内存开销上升。
3. nprobe（查询参数） 查询时探测多少个桶。越大召回越高，但延迟越高。
4. metric_type（距离度量） 必须和 embedding 训练/归一化策略匹配，否则效果会差。 一句话调参：先定 nlist，再用 nprobe 在“召回率-延迟”之间找平衡。

1. HNSW 图检索
2. M（建图连边数） 越大图越密，召回通常更好，但内存更高。
3. efConstruction（建图搜索深度） 越大建图质量越好，但建索引更慢。
4. efSearch（查询搜索深度） 直观理解是查询时会探索多少候选节点。越大召回越好，但查询更慢。越小速度越快，但可能漏召回 一般efSearch要大于topK，再通过压测找平衡点

5. RAG 的基本流程是什么？

• 我一般会把 RAG 拆成两段：离线建库和在线问答。离线是清洗文档、切 chunk、做 embedding、写入 Milvus；在线是把用户问题重写，向量化，先召回，再重排，最后把上下文喂给大模型生成答案。

• 如果要一句话总结，就是“先把知识准备好，再把最相关的内容精准喂给模型”。 场景补充：

• 比如做企业客服机器人：产品手册每天更新，离线任务夜间增量入库；用户白天提问时，系统 200~500ms 内召回相关片段，再由大模型组织成可读答案。

6. 为什么要做文档切分（Chunking）？（口语化回答）

• 不切分的话，一段文本太长，语义会混在一起，向量表达不聚焦，召回容易偏。

• 切得太大，容易把无关信息一起带回来；切得太小，上下文又断裂。实际就是在“语义完整性”和“检索精度”之间找平衡。 场景补充：

• 我会按条款或小节切，不会按固定 1000 字硬切。这样问“违约责任”时，能直接命中对应条款，不会把整份合同噪声一起拉进来。

7.Chunking方案有哪些？

1. 固定长度 + overlap（基线方案）

2. 结构化 chunking（按标题/段落/页面/元素）

3. 语义 chunking（Semantic Chunking）

4. 分层 chunking（Parent-Child / Small-to-Big）

5. 托管检索的自动 chunking

8. 如何评估使用什么chunking方案

1. 先定业务目标

2. 构建小评测集（50-200 条真实问题）

3. 离线对比 3-4 个候选方案

4. 核心指标

5. 线上小流量 A/B

6. 决策原则

7. 一个实用默认建议

9. TopK 设置过大或过小分别有什么问题？（口语化回答）

• TopK 太小，可能没把关键证据召回来，模型就会“瞎补”。

• TopK 太大，会把噪声也带进上下文，模型注意力被稀释，延迟和 token 成本也会上去。

• 所以 TopK 不是越大越好，通常要结合评测集做网格调参。 场景补充：

• 我做过一个内部知识库，TopK 从 20 降到 8 后，答案准确率反而提升，因为无关片段少了，同时 P95(把所有请求延迟由大到小排序，95%不超过这个时间，衡量尾部慢请求时间) 延迟也明显下降。

10. 什么是 Metadata Filter？在 RAG 中有什么用？（口语化回答）

• Metadata Filter 就是“先按业务规则过滤，再做向量相似度排序”。

• 典型过滤条件有租户、部门、时间、生效状态、文档类型。它的价值是把召回范围限定在“本来就应该看的数据”里。 场景补充：

• 多租户 SaaS 场景里，同一句问题不同客户可能查到不同知识。加上 tenant_id 过滤后，既保证答案相关，也避免数据越权。

11. 造成“检索不到答案”的常见原因有哪些？（口语化回答）

• 第一类是“库里没有”：文档没收录或版本过旧。

• 第二类是“能检索但没命中”：chunk 策略不对、embedding 模型不匹配领域、metric 和归一化不一致。

• 第三类是“参数问题”：nprobe/efSearch 太保守，或过滤条件写得过严。 场景补充：

• 比如医疗问答，通用 embedding 对专有术语效果差，换成医疗领域模型后，Recall@10（返回top10结果的召回率） 往往会有明显提升。

12. Milvus 在业务中最基础的优化手段有哪些？（口语化回答）

• 我会先做三件事：批量写入、选对索引、按数据规模调查询参数。

• 然后再做两件事：加 metadata 过滤减少无效召回，以及对热门问题做缓存。

• 优化顺序一般是先保正确率，再压延迟，最后看成本。 场景补充：

• 例如电商导购助手：白天高峰时把 efSearch 从 128 调到 64，配合 rerank 保持效果，在可接受精度下提升每秒查询数。

二、面试题（架构设计 + 性能调优，口语化重写）

1. 你会如何设计一个可线上运行的 Milvus + RAG 架构？

• 我会按“离线建库 + 在线问答 + 评估闭环”三层来设计。

• 离线层负责把脏数据变成可检索数据：清洗、去重、切分、embedding、建索引、入 Milvus。

• 在线层负责稳定答复：query 改写、混合召回、重排、组装上下文、LLM 生成、引用返回。

• 评估层负责持续变好：记录检索链路日志、错误样本回流、每周迭代参数和模型。 场景补充：

• 比如企业内部知识助手，白天高并发问答，晚上增量同步文档。架构上我会把入库和在线查询解耦，避免更新任务影响白天服务。 追问延展（加分）：

• 我会明确比如 P95 延迟 800ms 内、回答引用命中率 > 85%，用这个目标反推每个环节预算。

2. IVF 和 HNSW 在生产里怎么选？

• 我一般不先“拍脑袋选索引”，而是先看数据规模、内存预算、延迟目标。

• IVF 更像“先分桶再精检”，资源更可控，适合大规模和稳定批量场景。

• HNSW 通常在召回和速度平衡上更好，但内存占用更高，参数也更敏感。

• 实际我会做同一批评测集对比：Recall@10、P95、QPS、内存占用，谁综合最优就选谁。 场景补充：

• HNSW 召回更好但内存超预算，那么可以在高峰业务用了 IVF_FLAT + rerank，低峰再跑高精度策略。

3. 你会如何做检索质量评估？

• 我会先做一套“小而真”的评测集，不追求大而全，先保证样本代表真实用户问题。

• 指标分三层：检索层看 Recall@K、MRR（最大边际相关性，它能保证和问题相关，并且结果不重复。平衡参数lambda大，偏相关性；小偏多样性）；生成层看答案正确率、引用命中率；工程层看 P95、失败率、成本。

• 如果答案错，我会追因是“没召回”“召回了没排到前面”还是“生成阶段胡说”，避免盲目调参。 场景补充：

• 比如 100 条高频问题，先跑基线，再替换 chunking 或 embedding，看 Recall@10 提升是否真实转化为答案准确率提升。

4. 混合检索（向量 + 关键词/BM25）为什么常见？

• 纯向量擅长语义相近，但对精确术语、版本号、报错码有时不稳定。

• 纯关键词擅长精确匹配，但对同义改写和自然语言问题覆盖弱。

• 所以线上常用“混合召回 + 融合重排”，把两者优点叠加，减少漏召回。 场景补充：

• 用户问“支付超时 504 怎么处理”，报错码 504 用关键词召回很强，处理步骤描述靠向量召回更完整，组合后效果更稳。

5. 为什么在 RAG 中常引入 Reranker？

• ANN 召回更像“粗排”，能把候选找回来，但前几条未必最相关。

• Reranker 的作用是“精排”，把真正和问题最匹配的片段推到前面。

• 对 LLM 来说，前几条上下文质量决定答案质量，所以 rerank 往往性价比很高。 场景补充：

• 我遇到过“召回看起来都相关，但答案仍然偏”的问题，加 rerank 后前 3 条证据明显更准，最终正确率提升明显。

6. 如何做多租户和权限隔离？

• 我会把权限控制放在检索前置，不是生成后补救。

• 具体做法是：数据入库时写入 tenant_id、部门、权限级别；查询时强制拼过滤条件。

• 对高敏数据再加一层业务网关校验，确保“没权限的数据根本召不回来”。 场景补充：

• SaaS 场景里，A 客户和 B 客户问同样问题，答案必须来自各自知识库，不能靠 prompt 约束，必须靠检索硬隔离。

7. 文档频繁更新时，索引和数据怎么维护？

• 我会采用“增量更新 + 定期重建”双策略。

• 日常小改动走增量，保证时效；周期性重建索引，解决长期碎片化和效果漂移。

• 同时做版本管理，回答里保留来源和版本，方便审计和回溯。 场景补充：

• 比如产品文档每天都有小改版，白天先增量入库保证可查，周末低峰全量重建，确保检索质量不随时间下降。

8. 延迟高时你会怎么排查？

• 我会按链路拆分耗时：query 改写、embedding、向量检索、rerank、LLM 生成，先找最大瓶颈。

• 检索侧优先看 topK、nprobe/efSearch 是否过高，过滤表达式是否低效。

• 生成侧看上下文是否过长、模型是否过重，必要时降级策略要能自动生效。 场景补充：

• 一次线上故障里，P95 飙升主要不是 Milvus，而是 rerank 模型变慢。把 rerank 从全量候选改成前 20 候选后，延迟很快回到 SLA。

9. 你会如何降低 RAG 幻觉？

• 我会从三层控幻觉：先提高召回质量，再限制生成边界，最后加输出校验。

• 召回层用混合检索和 rerank；生成层明确“只基于证据回答，不确定就说不知道”；输出层强制带引用。

• 评估时重点看“有引用但答错”和“无引用硬答”的比例，持续打样本。 场景补充：

• 在金融问答里，我会宁可提高拒答率，也不允许模型给出无证据建议，这是业务风险优先级问题。

10. 线上系统如何做可观测性和迭代闭环？

• 我会把每次问答的关键链路都记录下来：原问题、改写后问题、召回结果、重排分数、最终答案、用户反馈。

• 出现坏例后，必须能快速定位是“数据问题、检索问题还是生成问题”。

• 迭代上采用小步快跑：固定评测集 + A/B 测试，避免上线后靠主观感觉调系统。 场景补充：

• 我常用一个做法：每周抽取 Top 失败样本复盘，明确下周只做 1-2 个高收益改动，例如先优化 chunking，再换 rerank，而不是同时改一堆变量。

三、加分题（中级偏上，可选）

1. 什么时候考虑多向量检索（Multi-Vector）？

• 长文档或多视角语义场景（标题向量、正文向量、摘要向量）。

• 通过多路召回融合提升覆盖率与稳定性。

2. 如何设计领域知识库的分层检索？

• 先粗粒度路由到领域，再做细粒度向量召回。

• 可减少跨域噪声，降低延迟并提升准确率。

3. Milvus + RAG 的上线验收标准你会怎么定？

• 指标门槛：Recall@K、答案准确率、P95 延迟、可用性。

• 安全门槛：权限隔离、敏感内容治理、审计可追溯。

• 运营门槛：可回滚、可灰度、可监控告警。

Milvus 为什么解决 ANN，为什么不选 pgvector/Faiss/ES