4、检索基础设施与检索优化

Q4-1. 什么是向量数据库？它和传统数据库有什么区别？为什么不能只用 MySQL？

先下一个定义：向量数据库是一种专门面向“相似度检索”的存储系统，用来保存向量、原始内容和元数据，并支持近邻搜索、过滤和召回。

传统数据库擅长精确过滤、事务和结构化查询，而向量数据库擅长按“语义相似度”做近邻检索。两者不是替代关系，而是分工关系。

如果只用 MySQL，你当然也能存 Embedding，但一旦数据量上来，近似向量检索、ANN 索引、混合检索和大规模召回都会变得低效，而且工程复杂度会明显上升。企业里更常见的做法是：结构化条件走传统数据库，语义召回走向量库，再通过 metadata 把两边结合起来。

重要度：高频（出现次数：2次） | 难度：基础

**考察点：**底层检索设施理解。

对应章节：18 向量数据库与Embedding实战 §2、向量数据库；18 向量数据库与Embedding实战 §6、向量库的写入与检索

Q4-2. Embedding 是什么？它在应用开发里最核心的价值是什么？

Embedding 的本质，是把文本、图片这类原始内容变成一串固定长度的向量，让“语义关系”尽量映射成“空间关系”。换一种工程化表述，就是把“意思接近”变成“距离接近”，这样程序才能做相似度计算。

它在应用开发里最核心的价值，不只是“把文本编码成数字”，而是让系统第一次具备了按语义检索的能力。所以它常被拿来做语义搜索、相似匹配、去重、聚类、推荐和 RAG 召回。

放到 RAG 里，Embedding 决定的是“问题和知识能不能在向量空间里正确相遇”。如果 Embedding 选错了，后面的向量库、重排、Prompt 再怎么补，也只能在一个偏掉的召回基础上做优化。

另外有两个工程细节需要特别强调：

• 建库和查询最好用同一套 Embedding 模型，不然要么维度对不上，要么即使维度一样，相似度也可能没有意义。
• Embedding 只是把文本变成“稠密向量”这一层，真正检索时往往还会和标量字段过滤、甚至稀疏检索一起配合，不能把它理解成检索系统的全部。

重要度：高频（出现次数：1次） | 难度：基础

**考察点：**是否理解 Embedding 不是“附属模型”，而是检索基础设施。

对应章节：18 向量数据库与Embedding实战 §1、向量与向量化；18 向量数据库与Embedding实战 §4、Embedding 文本向量化

Q4-3. 如何选择一个合适的 Embedding 模型？评估它好坏看什么？

通常不会先看榜单，而是先看自己的知识类型和检索目标，再反推模型选型。更合理的思路是先看三件事：

• 语言和领域适配：中文、英文、多语言、代码、法律、金融，适合的模型可能完全不同。
• 建库和查询一致性：建库和查询尽量使用同一套 Embedding 模型，这是底线。
• 成本和延迟是否可接受：不是维度越高越好，也不是模型越大越好，要看知识库规模和查询量能不能撑住。

真正评估时，更应关注“它有没有把整条检索链路整体抬起来”，而不是只看一个榜单分数。比较实用的判断通常有三层：

• 检索层：相关片段有没有更容易被召回，坏例子有没有减少，重排前后的差距大不大。
• 业务层：最终答案的忠实度、引用准确性、任务完成率有没有变好。
• 工程层：延迟、成本、接入复杂度能不能接受。

工程上需要特别强调两点：

• Embedding 选型不是孤立问题，它会和切块策略、索引参数、混合检索、rerank 一起决定上限。
• 公开榜单只能做初筛，真正能决定要不要上线的，还是你自己的知识样本和 badcase。

所以更稳的做法通常是：先选两到三套候选模型跑通，再在自己的知识库样本上做小规模对比，观察召回质量、最终回答质量和成本延迟，最后再决定。

重要度：高频（出现次数：1次） | 难度：中等

**考察点：**Embedding 选型、评测意识，以及“模型一致性 + 检索链路联动”的理解。

对应章节：18 向量数据库与Embedding实战 §4、Embedding 文本向量化；18 向量数据库与Embedding实战 §6、向量库的写入与检索

Q4-4. 近似检索和精确检索怎么权衡？

精确检索效果更可控，但在大规模数据下成本高、延迟高。近似检索牺牲一部分精确性，换来更好的吞吐和响应速度，所以大部分线上系统都会优先用近似检索。

工程上不是简单二选一，而是看业务要求。如果是高风险检索、数据量不大、对结果一致性要求极高，可以用精确或更保守的索引策略。如果是通用知识问答、商品搜索、海量文档召回，近似检索通常更现实，再配合 rerank 做补偿。

重要度：中频（出现次数：1次） | 难度：中等

**考察点：**性能和效果取舍能力。

对应章节：18 向量数据库与Embedding实战 §2、向量数据库；18 向量数据库与Embedding实战 §5、通过向量计算语义相似度

Q4-5. 在什么场景下，知识图谱或图数据库比纯向量检索更有价值？

当问题的核心不只是“语义相似”，而是“实体关系、路径推理、多跳关联、结构化约束”时，知识图谱或图数据库会更有价值。

比如设备故障排查、商品属性关联、组织关系、法规条文引用、依赖链分析，这些场景往往更依赖“谁和谁有什么关系”，而不只是“哪段文本看起来最像”。这时候如果只靠向量检索，容易召回到语义接近但关系错误的内容。

工程上更适合把它理解成增强，而不是简单替代。比较稳的做法通常是：向量检索负责语义召回，知识图谱负责结构化约束、实体消歧和关系推理。只有在问题本身高度结构化、关系链特别关键时，图数据库才可能成为主通路。

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**对“语义召回”和“关系推理”边界的理解，以及检索架构选型能力。

Q4-6. GraphRAG 适合什么场景？和传统向量 RAG 怎么选？

GraphRAG 更适合实体关系密、需要多跳推理、社区摘要或结构化约束很强的场景。

比如组织关系分析、供应链依赖、设备故障链路、法规条款关联、人物事件网络，这些问题往往不是“哪段文字最像”，而是“谁和谁怎么关联、要经过几跳才能到答案”。这时候图谱或图数据库的优势会更明显。

但工程上通常不会默认一开始就做 GraphRAG。更常见的稳妥路径是：

• 先用传统向量 RAG 打底，解决大多数语义召回问题。
• 当 badcase 明显集中在多跳关系、实体消歧、结构约束时，再引入图谱增强。
• 真正落地时，也常常不是二选一，而是“向量召回 + 图谱召回 + 融合重排”一起做。

更准确的结论是：只有当问题核心在关系结构上时，图谱路线的收益才会大于复杂度。

常见追问：

• GraphRAG 和知识图谱数据库是什么关系？
• 什么情况下多路召回比纯图谱主路更现实？
• 图谱更新和维护成本会不会太高？

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**GraphRAG 选型能力，以及对复杂度和收益的权衡意识。