你的 RAG 答非所问，大概率不是大模型的锅

你的 RAG 应用明明存进去了正确的文档，回答却驴唇不对马嘴。

这不是大模型的错。问题出在检索环节。

纯向量检索有一个系统性的盲区：它擅长理解"意思"，但不擅长匹配"字面量"。你搜索"Spring Boot 3.5 的新特性"，它给你返回 Spring Boot 2.7 的迁移指南。因为对向量模型来说，这两个版本的描述在语义空间里就是邻居——都是关于 Spring Boot 版本特性，模型只理解了这层语义，3.5 和 2.7 的精确区分，它做不好。

这导致了 RAG 应用中一个普遍但常被忽视的现象：文档是对的那不是模型的问题，检索没找到对的文档。

问题的本质在于，纯向量检索在处理产品编号、版本号、错误码、CVE 编号这类精确字面量时，天生弱势。而大量真实场景恰恰需要这种精确匹配。

解决方案其实不复杂：把向量检索和传统的关键词检索拼在一起。向量检索负责理解语义，关键词检索负责命中字面量，两条路各返回排序结果，用 RRF 算法融合。这就叫混合检索。

刚刚发布的 langchain4j 1.11.0，在 PgVector 模块中原生支持了这一能力。

对 Java 生态来说，这可能是今年以来最实用的一次更新。大多数 Java 项目标配 PostgreSQL，PgVector 已经是做 RAG 的主流选择。现在要开启混合检索，只需要在构建 Store 时加一行 .searchMode(SearchMode.HYBRID)，搜索时多传一个 query 参数。数据不需要做任何变更，GIN 索引会自动创建。迁移成本几乎为零。

底层 SQL 的实现也很干净：一个 CTE 结构，向量检索和关键词检索各跑一段，FULL OUTER JOIN 合并，RRF 公式算最终分数。一次数据库往返就搞定，不需要在应用层做结果合并。

如果你做 RAG 时遇到过"答非所问"的困扰，不妨检视一下你的检索层。很多时候，大模型的能力已经过剩，瓶颈反而在最基础的检索这一环。在 PgVector 上加混合检索，是当前改动最小、收益最直接的优化路径。