SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

上下文工程和检索增强生成

RAG 告诉你「怎么把外部知识喂给模型」,上下文工程告诉你「喂进去的东西质量怎么样、排得好不好、有没有塞爆窗口」。只聊 RAG 不谈上下文工程,大概率会把一个差劲的检索结果原封不动地塞给模型。

寓言

资料馆里的两道工序

城东有一座资料馆,馆里藏了几十万卷档案。馆长设计了一套流程:有人来查资料,管理员先去库里检索相关卷宗,挑出最像的二十卷,抱到阅览室桌上,请查资料的人自己翻。这套流程运转了一年多,馆长给它取了个名字叫「检索辅读」。

问题慢慢出现了。有些查资料的人反映,桌上二十卷东西里,真正有用的只有五六卷,剩下十几卷要么过时了,要么讲的是另一件事。更头疼的是,二十卷搬过来已经把桌子堆满了,他们想看更多相关信息,没地方放。

馆长请来一位整理师。整理师不碰检索那一步——她不管库里的卷宗怎么挑出来的。她只负责一件事:检索出来的二十卷到了阅览室之后,怎么整理、怎么排序、怎么取舍。

整理师在阅览室桌上加了三个工序。第一道叫筛选:二十卷里明显不相关的先撤掉,腾出桌面空间。第二道叫排序:剩下的卷宗按与查询的相关度重新排列,最相关的放最上面。第三道叫摘要:特别长的卷宗,把关键段落勾出来,让查资料的人一眼就能找到重点。

仅仅加了这三道工序,查资料的人反馈好了很多。桌面不再堆满无用信息,回答质量明显提升。但有意思的是,馆长之前一直把「资料查不准」归咎于检索系统不够好,反复调检索参数、换索引方案,效果始终有限。整理师来了以后,同样的检索结果,品质却上了一个台阶。

馆长于是把工序正式分成了两道:第一道叫「检索」,专注于从库里把相关卷宗找出来。第二道叫「上下文整理」,专注于整理、排序、截断和标注,确保真正送到查资料人眼前的信息是精炼过的。

后来资料馆对外介绍的时候,不再只说「我们有检索辅读」。馆长会补一句:检索是第一步,上下文整理是第二步。跳过第二步,再好的检索结果也可能被浪费掉。

有同行来取经,问馆长资料馆的核心竞争力是什么。馆长说:大家用的检索技术差不多,拉开差距的是上下文整理那道工序。谁把桌面收拾得干净,谁的服务就更好。

上下文工程

一门系统化管理和优化「模型最终看到什么」的工程实践。涵盖检索后的筛选、重排序、截断、压缩、去重和格式化,目标是让有限上下文窗口里的信息密度最大化。

检索增强生成 (RAG)

一种将外部知识检索与语言模型生成结合的架构模式。核心链路是:查询 → 检索 → 把结果拼入提示 → 模型生成回答。它定义了「怎么把知识喂进去」的整体框架。

故事对应

  • 检索系统从库中挑出二十卷:RAG 的检索环节。
  • 整理师的三道工序(筛选、排序、摘要):上下文工程的核心动作。
  • 馆长反复调检索参数但效果有限:只在 RAG 层面优化,忽略上下文工程。
  • 桌面空间有限:模型上下文窗口有长度限制,无效内容挤占了有效信息的空间。
  • 拉开差距的是上下文整理而非检索技术:当前 RAG 系统的瓶颈往往在检索之后。

落到项目里

评估 RAG 系统效果时,把检索质量和上下文质量分开测。检索质量看命中率和召回率,上下文质量看最终塞进提示的信息密度、相关性排序和截断损失。一个常见的诊断信号:检索命中率高但最终回答质量差,瓶颈大概率在上下文工程——比如重排序策略不合理,或者截断时把关键信息切掉了。