惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

MongoDB | Blog
MongoDB | Blog
宝玉的分享
宝玉的分享
博客园 - 三生石上(FineUI控件)
小众软件
小众软件
罗磊的独立博客
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
S
SegmentFault 最新的问题
Last Week in AI
Last Week in AI
人人都是产品经理
人人都是产品经理
博客园 - 聂微东
博客园 - 司徒正美
博客园 - 叶小钗
T
Tailwind CSS Blog
博客园 - Franky
V
V2EX
有赞技术团队
有赞技术团队
美团技术团队
雷峰网
雷峰网
爱范儿
爱范儿
Jina AI
Jina AI
D
DataBreaches.Net
H
Help Net Security
酷 壳 – CoolShell
酷 壳 – CoolShell

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
别再死磕RAG了,2026年大模型将直接淘汰这种过渡技术
为了罐罐 · 2026-01-21 · via 人人都是产品经理

RAG技术正成为企业知识库搭建的热门选择,但它的过渡属性已日益明显。随着大模型上下文窗口的指数级扩张,这项为解决记忆短板而生的技术或将面临淘汰。本文深度剖析RAG的先天缺陷,预测大模型进化路径,并给出避免技术锁死的3个关键策略,帮助企业把握AI落地的正确节奏。

如果你最近在做企业知识库,大概率绕不开一个词:RAG

无论是和做技术的朋友聊天,还是看行业方案,几乎所有人都在说用 RAG 搭知识库。但今天想跟大家聊个暴论 ——RAG 可能只是个过渡玩家,用不了多久就会被大模型的发展拍在沙滩上。

就像有朋友吐槽的:为了一盘醋,包了一顿饺子,RAG 本质上就是这样的存在。

一、RAG 的尴尬:为解决痛点而生,却自带一堆麻烦

为啥说 RAG 是为醋包饺子?核心原因很简单:它从出生就是个补丁技术。

大模型最开始的短板很明显 —— 记忆能力有限,没法记住企业里海量的内部文档、历史数据。

于是 RAG 应运而生:把文档切片、向量化、建索引,用户查询时再召回相关片段喂给模型,相当于给大模型装了个外挂记忆。

但这套流程用起来,麻烦可不少:

文档得切得够细,还得反复调试召回策略,不然模型容易答非所问;

要是公司文档更新频繁,索引得跟着重建,维护成本直线上升;

中间环节越多,bug 出现的概率越高,有时候调试半天还不如直接让员工翻文档。

最近和不少企业老板聊,大家都在吐槽这事:本来想省事儿,结果搭 RAG 的功夫,比整理文档还多。

其实这也不能怪 RAG 本身,它只是在大模型还不够强的时候,帮我们过渡的权宜之计。

二、Token 爆炸式增长,正在终结 RAG 的必要性

真正让 RAG 走向淘汰的,是大模型上下文窗口的爆发式增长 —— 这玩意儿完全遵循摩尔定律在进化。

你要问我什么是摩尔定律?

它的核心意思是:

集成电路上能容纳的晶体管数量,大约每两年就会翻一番

换句话说,芯片的性能会越来越强,而成本会越来越低,而且这个趋势会持续很多年。

你可以把它理解成:

科技的战斗力每隔一段时间就自动升级一次。

咱们看一组触目惊心的数据:

2023 年初,大模型的上下文还只有几千个 Token,连一篇长文档都装不下;

2023 年中,就涨到了几万 Token,能勉强容纳一本小书;

2024 年,已经突破上百万 Token,足以吞下一家中小企业的全部知识库;

按照这个节奏,2026 年初,千万级甚至亿级 Token 的上下文窗口就要来了。

想象一下,当大模型能直接记住你公司所有的文档、数据、历史案例,不需要切片、不需要向量化、不需要召回。

你直接把全量信息丢给它,它就能精准回答问题。那时候,RAG 这些复杂的工程操作,不就成了多余的步骤?

就像当年我们用 U 盘传文件,现在直接云端同步;当年用 MP3 存歌,现在直接在线听。

不是 U 盘和 MP3 不好,而是技术进步让它们的过渡使命完成了。RAG 也是一样,它有自己的历史价值,但注定会被更强大的大模型能力替代。

三、给企业的 3 个务实建议:别在过渡技术上押注太重

当然,不是说现在就要立刻抛弃 RAG—— 毕竟现阶段它依然能解决不少实际问题。但我们做技术选型时,得有前瞻性,别把所有鸡蛋放在 RAG 这个篮子里。

这里给大家 3 个务实的建议,供参考:

1.保留切换方案,别把架构绑死

搭知识库时,尽量设计灵活的架构,预留好从 RAG 切换到大模型全量输入的接口。将来一旦大模型能力达标,就能快速迁移,不用推倒重来。

2.RAG 投入够用就好,别过度优化

没必要在 RAG 的调优上花太多精力,比如纠结怎么切分文档更合理、怎么提升召回率 0.1%。现阶段能满足业务需求就行,把更多资源投入到数据整理、业务理解上 —— 这些核心资产,不管技术怎么变都有用。

3.盯紧大模型进展,及时跟进技术迭代

让技术团队保持对大模型的关注,尤其是上下文窗口大小和 Token 调用成本这两个关键指标。一旦这两个指标达到临界点,比如千万级 Token 加低成本调用,就果断切换技术栈,别抱着 RAG 缝缝补补。

最后说句实在话

技术迭代的本质,就是用更简单的方式解决更复杂的问题。

当年我们觉得切片加向量化是知识库的最优解,就像 2026 年大家觉得 Skills 工程是新趋势一样 —— 都是特定阶段的最优选择。但我们不能迷信任何一项技术,得学会站在趋势上看问题。

RAG 的时代终会过去,但企业对知识库的需求只会越来越强烈。与其死磕过渡技术,不如把目光放长远,跟着大模型的发展节奏走。

如果你正在用 RAG 做企业知识库,或者在 AI 落地中遇到了类似的技术选型难题,欢迎在留言区分享你的经历 —— 咱们一起交流,少走弯路。

本文由@为了罐罐 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。