6 篇博文 含有标签「RAG」

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。

上一篇开源 RAG 知识库横评里我实测了 14 个 RAG 平台的默认向量库，留下一个没展开的问题：这些向量库本身怎么选？

这篇补上。做四件事：先分类（它们不是同一类东西）→ 用两个独立数据源回答「企业实际在用哪些」（结论和赛道热度是反的）→ 逐家拆解 19 个方案 → 两张表讲清真正的技术分水岭（过滤+ANN、量化）。

文中 star、协议、版本、容器数均为 2026-09-20 实测：GitHub API + LICENSE 原文 + docker-compose + PyPI 下载量。厂商自测的性能数字一律单独标注。凡我没能从一手来源核实的，直接写「未证实」——这次有好几处，包括一整个云厂商。

上一篇 开源 RAG 知识库横评 解决的是「底座用什么」。这篇往上走一层：底座之上，哪些 Agent 场景真的能赚钱。

这篇做四件事：先给一把判断「高 ROI」的尺子（厂商数字有三个系统性偏差）→ 深挖智能客服（含那个被反复引用的「76% 解决率」到底怎么回事）→ 深挖商业尽调（真实账本 + 一条不能碰的合规红线）→ 另外 8 个场景的落地水位表。

文中数字分三级标注：[已核实]（直接读到原始文件/论文/采购公示）、[二手]（权威第三方转述）、[厂商自述]（厂商官网或案例页，无第三方验证）。标 [厂商自述] 的数字请勿当作 ROI 证据使用——这篇的大半篇幅其实是在解释为什么。

上一篇聊了 RAG 的现状与那条「像素方案」，那是「技术面」。这篇落到选型：中小企业想私有一部署一套 RAG 知识库，市面上这十几个开源项目到底怎么挑。

这篇做四件事：先把它们分类（它们根本不在一个赛道）→ 逐家拆解（含停更避坑区）→ 一张实测横评表 → 三个必须读 LICENSE 原文的坑。文中的 star 数、协议原文、最新版本、容器数全部是 2026-09-19 用 GitHub API 与 docker-compose 原文实测，不是二手转述；一手核不到的地方我直接标注「未证实」。

一句话先给结论：要编排能力 → Dify；要文档解析精度 → RAGFlow；要最省运维 → MaxKB；要开箱即用 → AnythingLLM；要把知识库嵌进现有系统 → AnythingLLM / LightRAG 这类「引擎」而不是「平台」。

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

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

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

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

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

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

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