RAG与知识库 on AI 观察

RAG 评测正在变难：忠实于错误证据，比胡编更危险

Thu, 15 Oct 2026 08:06:43 +0800

检索增强生成（RAG）一度被当成「解决幻觉」的标准答案：先找文档，再按文档回答。2026 年的新研究却把问题说得更尖锐——模型忠实于检索到的内容，并不等于答案正确；当知识库本身被污染、过时或自相矛盾时，「只信文档」反而可能把本来答对的问题改错。

企业知识库问答落地：从文档治理到权限控制的完整路径

Tue, 29 Sep 2026 20:11:40 +0800

“让员工像问同事一样问公司制度、产品资料和技术文档”，是几乎每家企业都想做的大模型应用。技术演示往往几天就能做出来，但真正上线后，问题接踵而至：答案引用了过期的制度、不同部门的文档互相矛盾、实习生问出了高管薪酬方案。企业知识库问答的难点，七成不在模型，而在文档治理和权限控制。

向量数据库怎么选？主流方案类型对比与选型清单

Mon, 21 Sep 2026 21:26:42 +0800

开始做 RAG 项目时，很多人第一个问题就是“用哪个向量数据库”。市场上的选择非常多，宣传口径也各不相同。实际上，对于大多数中小规模项目，向量数据库并不是决定成败的关键，选一个团队能运维好、满足过滤和权限需求的方案，比追求极致性能更重要。

向量数据库做什么

向量数据库负责存储文本、图片等内容的向量表示，并根据查询向量快速找出最相似的若干条记录。为了在海量数据中实现毫秒级检索，它们通常使用近似最近邻（ANN）索引，例如基于图结构的 HNSW 或基于聚类的 IVF 等算法，用少量精度损失换取大幅速度提升。

重排序模型（Reranker）指南：提升 RAG 检索精度的关键一步

Wed, 26 Aug 2026 16:31:27 +0800

一个常见的 RAG 问题是：正确答案所在的段落其实被检索到了，却排在第八名，而送进大模型的只有前三名。重排序模型（Reranker）的作用，就是在初步检索得到的候选集上，用更精细但更慢的方式重新打分排序，把真正相关的内容推到最前面。 在很多项目中，加入重排序是提升回答准确率最立竿见影的一步。

PDF 与表格解析：RAG 数据入库最容易踩的坑与应对方法

Sat, 15 Aug 2026 17:21:34 +0800

在企业 RAG 项目中，有一个经常被低估的事实：输入的数据质量决定了系统效果的上限，而大量企业知识以 PDF 形式存在。 PDF 本质上是为打印和显示设计的格式，它记录的是“哪个字符出现在页面的哪个坐标”，而不是“这是一个标题、这是一段正文、这是一张表格”。把 PDF 还原为结构清晰的文本，比大多数人想象的要难。

RAG 文档切分策略：块大小、重叠与结构化切分实践

Tue, 11 Aug 2026 10:49:16 +0800

搭建 RAG 知识库时，大家通常把精力放在选模型和选向量数据库上，却很少认真对待文档切分。实际上，切分方式决定了检索的基本单位，切得不好，后面的检索和生成再强也无法弥补：要么关键信息被切断在两个块之间，要么一个块里塞了太多无关内容，稀释了语义。

为什么需要切分

一方面，Embedding 模型有输入长度上限，整篇长文档无法直接编码；另一方面，一个向量很难同时准确代表一篇文档里的多个主题。把文档切成较小的片段，每个片段语义更集中，检索时也能只把相关部分送进大模型，节省上下文和成本。Embedding 的基本原理可参考文本向量入门。

混合检索实战：BM25 关键词检索与向量检索如何结合

Fri, 07 Aug 2026 10:54:42 +0800

很多团队在搭建 RAG 时直接上了向量数据库，结果发现：用户搜一个具体的产品型号、一个错误码或一个人名，系统却返回了一堆“语义相近”但完全不相关的内容。向量检索和关键词检索各有盲区，把两者结合起来的混合检索，往往是提升召回质量最直接的方法之一。

两种检索方式的特点

关键词检索（BM25）

BM25 是经典的关键词相关性算法，核心思想是：查询词在文档中出现得越多、在整个语料中越稀有，文档得分越高，同时对文档长度做归一化。

GraphRAG 是什么？知识图谱增强检索的原理与适用场景

Wed, 22 Jul 2026 12:59:57 +0800

传统 RAG 的工作方式是把文档切成片段，根据问题检索最相关的几段。这对“报销流程是什么”这类局部问题很有效，但面对“这一百份访谈记录中，客户最常抱怨的问题有哪些”或“A 公司和 B 公司之间通过哪些人和项目产生了关联”这类问题时，就显得力不从心。GraphRAG 的思路是先从文档中抽取实体和关系，构建知识图谱，再基于图结构进行检索和推理，以弥补纯片段检索的不足。

RAG 还是长上下文？两种方案的成本、效果与适用场景对比

Tue, 14 Jul 2026 11:53:23 +0800

随着大模型的上下文窗口扩展到数十万甚至百万 Token，一个问题被反复提起：既然模型能一次读完整个知识库，还有必要费力搭建 RAG 吗？ 答案取决于你的数据规模、使用频率和对准确性的要求。在大多数生产场景中，两者不是二选一，而是互相补充。

两种方案的基本思路

长上下文：把相关文档全部放进提示词，让模型自己阅读和寻找答案；
RAG：先根据问题检索出最相关的少量片段，只把这些片段交给模型。

逐项对比

成本

长上下文方案每次请求都要为全部文档付费。如果同一批文档被频繁查询，成本会迅速累积。部分服务商提供的提示缓存功能可以降低重复部分的费用，但并非所有场景都适用。RAG 每次只发送少量片段，单次成本低得多，代价是需要建设和维护检索系统。