检索增强生成（RAG）已经成为大模型落地最主流的工程范式之一：它不改动模型权重，而是把外部知识以“检索 + 拼接”的方式送进上下文。问题也随之而来——很多团队把精力全花在提示词和模型选型上，却低估了检索层的重要性。检索没召回对，再强的模型也只能基于错误信息作答。
一、向量数据库到底解决什么问题
RAG 的核心是把文本转成向量（embedding），再按语义相似度找出最相关的片段。向量数据库就是承载这一步的基础设施：它负责高维向量的存储、近邻检索和元数据过滤。与传统关键字检索不同，向量检索匹配的是“意思相近”而非“字面相同”，这让它能处理同义表达、跨语言和模糊提问。
二、选型的几个关键维度
1. 检索算法与索引：主流实现基于 HNSW（分层可导航小世界图）或 IVF（倒排文件）等近似最近邻（ANN）算法。HNSW 通常召回率高、延迟低，但内存占用较大；IVF 系列更省内存，适合超大规模数据。
2. 过滤能力：真实场景几乎都需要“先按业务字段过滤、再做向量检索”（比如限定某个租户、某段时间）。是否支持带过滤的向量检索、过滤与近邻搜索是否能高效融合，是选型的分水岭。
3. 规模与成本：百万级和十亿级向量的方案完全不同。小规模可以直接用内存索引甚至暴力检索；规模上来后再考虑分布式与磁盘索引。
4. 运维与生态：是否需要与现有的 PostgreSQL、Elasticsearch 等技术栈共存。很多项目会优先选择已有的数据库加上向量扩展（如 pgvector），以降低运维负担。
三、调优比选型更重要
选对了数据库只是开始，以下几点往往决定最终效果：
- 分块（chunking）策略：按语义边界切分，而不是机械地按固定长度截断。块太大引入噪声，太小则丢失上下文。
- 混合检索：把向量检索与 BM25 等关键字检索结合，再重排序，通常能显著提升召回质量。
- 重排序（rerank）：用交叉编码器对初筛结果精排，是提升精度性价比很高的一步。
- 评估闭环：建立固定的评测集，用召回率、命中率等指标驱动迭代，而不是凭感觉调参。
四、常见误区
- 迷信“更大更好的模型”，忽视检索质量；
- 把 chunk 切得极碎，导致模型看不到完整语义；
- 不做评估，靠个案体验判断优劣。
结语
RAG 的效果上限，很大程度上由检索层决定。选型看的是算法、过滤、规模和生态的匹配度，调优看的是分块、混合检索与重排序的组合。把检索这一环做扎实，往往比频繁更换大模型更划算。
【参考来源】综合整理自公开发布的行业信息