3 篇博文 含有标签「向量检索」

Postgres 上做混合检索，过去的标准姿势是「pgvector 管向量 + tsvector 管关键词 + 一条 SQL 自己融合」——本站 pgvector 入门 里那条 WITH ... RRF 就是这个写法。

ParadeDB 想解决的是这套姿势里最别扭的部分：两套索引、两份候选、两个计划。它的答案是——把文本列和向量列放进同一个索引，让 BM25 和向量距离在同一趟扫描里完成。

但有个反直觉的事实，我这次实测才确认：

ParadeDB 不提供 rrf() 函数，也不提供 hybrid_search() 之类的 API。 它的「RRF」是一段要你自己写的 SQL 模式——RANK() 窗口函数排名次、weight / (k + rank) 算权重、sum() 融合。

我查了 pg_proc，pg_search 0.25.10 里不存在任何名字含 rrf / fuse 的函数。这和 Milvus 是两个路线：Milvus 内置 RRFRanker()（本站 Milvus 入门 验算过它的分数就是教科书公式），ParadeDB 则把融合层的控制权原样交回 SQL。

这篇把它的实现路径跑了一遍，所有数字都来自真实执行（脚本与日志留档在 source/paradedb/）。

命名说明：你说的「RFF 算法」，业界标准名是 RRF（Reciprocal Rank Fusion，互惠排名融合），本文统一用 RRF。

「单路检索不够用，要上多路」——这话现在几乎是共识。但多路到底怎么融合、路怎么选、效果怎么证明，多数文章停在「向量 + 关键词，效果更好」。

这篇想把它做实。我做了一个可复现的三通道检索实验（向量 / 关键词 / 图谱，对应语义、精确、关系三条通道），把 RRF 的公式、k 常数、加权、以及查询路由都跑了一遍，然后用准确率/召回率逐查询拆开看——结果推翻了我自己一开始的预期：

融合的收益被均值严重高估了。 在这个语料上，三路等权 RRF 的平均 nDCG 只比最好的单通道高 1.8%；而在某一类查询上，等权 RRF 反而比单独用图谱通道差了将近一半。

命名说明：你说的「RFF 算法」，业界标准名是 RRF（Reciprocal Rank Fusion，互惠排名融合），本文统一用 RRF。

「RAG 已死」这种标题这两年轮着上：先是长上下文说要取代它，后来 Agent 说要吸收它。但把噪音去掉，真实情况更像一句评价：RAG 没死，它长大了——从「一条流水线」长成了「一个分层能力」。

这篇聊四件事：传统 RAG 的结构性毛病 → 2026 年的现状与主流解法 → 一个被低估的问题（解析损失） → 最近很热的「像素方案」（视觉/像素级 RAG）到底是什么、什么时候值得用。

文中行业数据来自公开资料（论文、厂商博客、技术评测），统计口径与时点不一，已尽量标注；相关结论请以原文为准。本文也会连到本站已有的 agent / 协议系列。