SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

检索增强生成和知识库问答

很多人建了知识库、接上大模型,就说自己做了 RAG。其实检索增强生成是一个完整的系统工程——包括数据切分、向量化、检索、排序、生成和评估;知识库问答只是其中一个应用场景。把整套工程等同于一个功能界面,最容易出现的后果是:搜到了但答错了,然后所有人回去改知识库,改完还是不对。

寓言

老书库的档案员和柜台上的查档台

老书库藏了三百年档案,雇了一位档案员老周。老周的活不只是在架子上找书——他要先把每年新入的档案拆成不同大小的卷宗、给每卷挂上标签,然后按标签建检索卡,再决定哪些书脊上要写多长摘要。外人眼里,他做的事就两个动作:接查询条、递档案。

后来书库在正门口设了一台查档台,让访客自己在台子上输入问题,机器对着检索卡库找出相关档案摘抄几段,拼成一段回复递给访客。访客们大喜,觉得终于不用等老周了。

问题出在第二个月。一位学者来查本省的盐铁税账,查档台告诉他某年税额为三万两。学者摘录后发表,被期刊审稿人指出数字完全错误。学者怒冲冲回到书库,老周翻出同一批检索卡,指着一条批注说:查档台抽到的是当季预估数,实收数在下一卷,但它没看懂卷与卷之间的承接关系,就信心十足地引用了。

书库于是召集老周和查档台的工程师对坐了一整天。工程师才发现,之前他们只改了检索卡库的标签体系,没有检查检索排序规则——查档台总是把标题最像的档案排第一,从来不追问这份档案是不是权威版本、有没有勘误。

老周画了一张图:从原始档案到检索卡到排序规则到摘抄逻辑再到最终回复,每一步都可能出错。查档台只是这张图的最上层界面,把它修好要动的是底下好几层——拆分方式、标签策略、排序权重、来源标注习惯。而这些都不是在知识库里多加几本书能解决的。

最后书库立了一个新规矩:以后有人反馈回答不准,先在检索卡旁边写争议标记,不急着拆档案。连续十次争议指向同一个标签策略,才轮到这个标签被重做。老周说这是治本,不是治标。

学者后来再来,发现查档台每段引用后面都标了来源档案号和是否权威版本,他不再需要回到老周那里验证。书库门口多了一行字:搜得着和讲得对中间隔着一整条工程。

年终时,书库把查档台的费用从采购预算改成了运维预算——因为它的真正成本不在那台机器,在于持续优化检索链路的人。

检索增强生成

一个完整的系统工程,涵盖数据预处理、索引构建、向量检索、结果排序、上下文拼接和大模型生成,每一环节都影响最终回答质量。

知识库问答

RAG 的一个具体应用场景,表现为用户在知识库上直接做自然语言问答;它依赖底层的 RAG 工程链路,但本身不包含索引和检索策略的治理。

故事对应

  • 老周做档案员的七步(拆分、标签、检索卡、排序、摘抄):RAG 的完整工程链路
  • 正门查档台:知识库问答的应用界面,只代表最上层
  • 盐铁税账的错误引用:检索排序问题被误认为是知识库不准
  • 争议标记新规矩:不应一错就拆档案,要溯源到链路某一环
  • 来源标注和权威版本:RAG 链路中排序和可追溯性的重要性

落到 Soloharness 项目里

客户说知识库不准时,不要马上去加文档。先看检索返回了什么、排序是不是把噪音排到了前面、切分是不是把答案裁成了碎片。修三层链路比加十本书有效。给客户报价时也要分开:搭建知识库问答界面是一笔小工程,打通整个 RAG 链路并持续优化是另一笔更大的投入。