当前位置: 首页 > news >正文

RAG is really dead? 大模型和知识之间的桥梁没了? - spader

作者:SpaderMan

从 RAG 到上下文工程:理性思考 AI 应用开发,以交付业务结果为目标

最近,Latent Space 播客发布了一期标题为["RAG 已死,上下文工程为王"](https://www.latent.space/p/chroma ""RAG 已死,上下文工程为王"")的访谈,其中开源向量数据库 Chroma 的创始人 Jeff Huber 的观点引发了广泛讨论。这个观点触及了一个核心问题:我们是否真的理解自己在构建什么?

理解 RAG:概念与争议

RAG(Retrieval Augmented Generation,检索增强生成)是当前 AI 应用的主流技术架构。其核心思想是:当大语言模型需要回答问题时,先从外部知识库检索相关信息,将这些信息加入到提示词中,最后生成答案。

这个架构解决了大语言模型(LLM)的两个固有问题:知识的时效性和准确性。模型不再依赖训练时的静态知识,而是能够动态获取最新、最相关的信息。

然而,Jeff Huber 对"RAG"这个术语的观点值得我们思考:

"We never use the term RAG. I hate the term RAG... Are three concepts put together into one thing? Like, that's just really confusing."

他的核心观点是:RAG 这个缩写将检索(Retrieval)、增强(Augmented)、生成(Generation)三个独立且复杂的环节简单组合到了一起。这种"概念打包"带来的副作用使许多开发者误认为搭建了向量检索就算实现了 RAG,而忽略了每个环节都需要的精心设计和优化。

上下文工程(Context Engineering)的本质

Jeff Huber 提出的上下文工程定义:

"Context engineering is the job of figuring out what should be in the context window for any given LLM generation step."

上下文工程关注的核心问题是:在有限的上下文窗口中,如何选择和组织最相关的信息,以获得最佳的生成效果。

这个概念的提出基于一个重要发现——上下文腐烂(Context Rot)。Chroma 的研究表明,大语言模型(LLM)的性能并非随上下文长度线性提升。相反,当上下文包含过多信息时,模型的注意力会分散,推理能力会下降。即使是拥有百万 token 窗口的模型,最佳性能往往出现在 2000-5000 tokens 的范围内。

这个发现颠覆了"信息越多越好"的直觉。上下文工程的核心挑战就在于此:如何在信息充分性和信息过载之间找到最佳平衡点。

RAG 与上下文工程:对立还是互补

表面上看,RAG 和上下文工程似乎是对立的概念。但深入分析后,我们认为它们代表了同一问题的不同层次:

RAG 是架构层面的解决方案。它定义了一个清晰的系统结构:外部知识库、检索机制、生成模型。这个架构本身是合理且有效的。

上下文工程是实现层面的优化方法论。它不否定 RAG 架构,而是深化了对"增强"环节的理解。当我们的关注点从'如何检索信息'转向'如何组织信息'时,实际上是在做更精细的工程优化。

这种关系类似于"算法"与"工程"的关系。算法提供理论框架,工程关注实际效果。RAG 告诉我们"要检索",上下文工程告诉我们"如何更好地利用检索结果"。

超越概念之争

这场讨论的价值不在于判定 RAG 或上下文工程孰优孰劣,而在于它促使我们重新思考 AI 应用开发的方法论。

第一,警惕概念简化。当复杂系统被简化为流行词汇时,实践者容易陷入表面理解。真正的工程能力体现在对每个组件的深入理解和精细优化。

第二,重视工程思维。Jeff 反复强调要让 AI 开发"更像工程,更少像炼金术"。这意味着建立可测量的目标、可重复的流程、可验证的改进。

第三,平衡理论与实践。RAG 提供了有用的概念框架,上下文工程强调了实践优化。两者结合才能构建真正可用的系统。

结语: 从概念验证到工程优化

"RAG 已死"更像是一种警示,其真正含义是:粗糙的、教条的 RAG 实践需要进化。上下文工程不是要替代 RAG,而是让 RAG 变得更加精细和有效。

无论是 RAG 还是上下文工程,本质都是在有限的计算资源下,为 AI 提供最有用的信息。名词会变,但工程师解决问题的使命不变。真正的进步,是让每一个 token 都有价值,让每一次推理都更精准。

这场讨论的最大意义在于:它提醒我们,AI 应用正在从"能跑"走向"跑得好",从概念验证走向工程优化。这是整个行业走向成熟的标志。

关于 Spader.AI

Spader.AI,北京与星以舟智能科技有限公司,是一支专注于人工智能与云计算技术的创新团队,致力于推动前沿技术的发展和实际应用。
我们构建高性能、可扩展的 AI 基础设施,提供灵活、安全的智能解决方案,帮助企业轻松应对复杂计算任务,加速 AI 应用落地。我们相信,智能技术应当开放、可及,并真正创造价值。因此,我们不断优化算法与架构,以提升算力效率、降低使用门槛,让人工智能成为推动产业升级的重要驱动力。

如果您对高性价比算力、大模型训练训练及推理以及相关业务场景的技术感兴趣,或者对本篇分享中提到的某些观点有自己的见解希望讨论,扫码秒加 SpaderMan 客服,SpaderMan 会带您入群,和各领域技术大佬共同探讨最前沿的 AI 技术。

http://www.hskmm.com/?act=detail&tid=20698

相关文章:

  • opencv学习记录4
  • 深入解析:Java-136 深入浅出 MySQL Spring Boot @Transactional 使用指南:事务传播、隔离级别与异常回滚策略
  • .NET操作Excel:高效材料读写与批量运行
  • Qwen-Image技术报告
  • IOS-和安卓-AR-游戏开发指南-全-
  • Winform/C# 输出到Release VS中Release模式下生成去掉生成pdb文件
  • 【OpenCV】12 图像轮廓
  • IntroJS-即时入门-全-
  • 数字设计的新篇章:前沿技术与未来趋势
  • 2025 镀锌方管厂家最新权威推荐排行榜:聚焦行业标杆与新锐品牌,镀锌方管优质厂家深度解析
  • mysql启动方式导致链接数max_connections查询的值不一致
  • cmakelist
  • 供应商协同平台:打造高效安全供应链的关键
  • 互斥锁和信号量机制
  • NSIS为当前用户安装和为所有用户安装的选择
  • 数据中台厂商选型|解决方案厂商与独立中台厂商详细解读
  • 深度学习项目全流程实践与核心技术解析:从数据处理到模型优化 - 教程
  • 直接使用的NLog帮助类
  • 【每日一面】setTimeout 延时为 0 的情况
  • AI元人文:悟空博弈框架
  • sway - wayland下截图方案
  • 不同网络间文件互传怎么实现?
  • sway wayland下 wps-office无法输入中文
  • 科学史笔记
  • Spring XML 设置简介
  • 2025 年真空泵品牌最新权威推荐排行榜:覆盖真空泵维修,真空泵机组,真空泵油,真空泵配件领域选择指南
  • 专业的跨网文件交换系统 和传统FTP/U盘拷贝有什么区别?
  • 0voice-2.1.4-http服务器的实现
  • CF *2600 思维题 2
  • 中低压配网设备介绍