你的 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 上加混合检索，是当前改动最小、收益最直接的优化路径。

RAG 系统的性能优化是一个系统工程。从文档处理到检索策略到生成融合，每个环节都可能成为瓶颈。文档切分是 RAG 的基础，切得太细检索精度高但上下文不完整，切得太粗上下文完整但检索精度低。实践中常用的策略是语义切分，根据文档的段落和标题结构来切分。检索策略的选择同样关键，纯向量检索无法处理精确匹配需求，全文关键词检索无法理解语义，混合检索可以兼顾两者。RRF 融合算法是目前最实用的混合检索结合方式，它不需要对两种检索的分数做归一化，直接基于排名位置做融合。Embedding 模型的选择直接影响检索质量，bge-m3 和 gte-qwen2 等中文优化模型可以让中文 RAG 系统的检索质量有明显提升。Reranker 可以在检索结果的 TOP-K 中做精排，尽管增加了系统复杂度和延迟，但对于需要高精度的场景来说，带来的提升是值得的。

技术的价值不在于它有多前沿，而在于它能在多大程度上解决实际问题。AI 技术的快速迭代不是用来追赶的潮流，而是用来解决业务痛点的工具箱。在实际应用中，有时候简单的方案反而最有效。一个 RAG 系统用了最复杂的检索策略但文档处理没做好，效果不如一个文档处理完善但检索策略简单的系统。一个 Agent 系统用了最贵的模型但 prompt 设计粗糙，效果不如一个精心设计 prompt 的普通模型。建议在追求技术先进性之前，先把基础工作做扎实。文档清洗、数据标注、评测体系、监控告警，这些看似基础的工作，往往是决定 AI 项目成败的关键。