普通 RAG 是固定流程:切分、向量化、检索、重排、拼上下文再让模型回答;agentic RAG 把检索变成 agent 的一个动作,由它自己决定搜什么、搜几次、要不要换工具,chunk 和向量化可能还在,但不再是必经的固定步骤。
AI根据立正公开的文章和视频整理,不是他本人回复。重要的判断,请回到出处核对。
普通 RAG 是一条固定流水线
材料里的观点普通 RAG 的结构是:用户提问 → 改写查询或识别意图 → 从知识库或数据库检索 → 重排和过滤 → 拼装上下文 → 模型生成答案 → 标注引用。技术重点就落在切分、向量化、混合检索、重排、元数据过滤、权限控制、引用和新鲜度这些环节上1。它的本质是让 AI 知道得更多,但主要还是在回答,不会自己去做事1。立正把 RAG 拆成六个动作:上下文管理、切分、判断、评估、诊断、编排,并强调切分不只是 chunking2。
Agentic 的做法是让 agent 自己决定怎么找
当问题本质是跨系统、跨实体的精确追踪时,用相似度去近似关系会吃亏,需要先把语义层和数据关系建模出来,再让 agent 在这个结构上工作3。一个具体信号是:Claude Code 团队早期也用过向量数据库,后来发现让 agent 自己搜索效果更好,现在用的基本就是 glob 和 grep 这种最简单的命令4。所以 agentic RAG 里 chunk、向量化、索引、排序仍然可能出现,但它们从固定流水线降级为 agent 可选的工具之一;agent 也可以直接读整个文件、用命令行搜、或者把整段长上下文交给模型。判断标准是这套做法在解决什么问题,而不是它叫什么名字4。
该学的是检索这件事,不是这套流程
AI推演分块加向量化加检索这套固定流程是 2023 年的产物:那时上下文窗口小,模型也不太会调用工具4。名词是地图上的地标,动词是你在地标之间走的路;只收集地标不知道怎么走路,哪儿也到不了5。所以如果你在学 RAG,值得先问两个问题:如果模型强十倍,这套做法还重要吗;它到底在解决什么问题,我现在还有这个问题吗4。懂了信息检索,学 RAG 只要一个周末4。
现有片段没有给出 agentic RAG 的完整工程实现细节,chunk 和向量化在具体系统里是否保留,取决于该系统的检索设计。
出处
- 1The Six Levels of AI Products
给出普通 RAG 的完整流程和技术重点,适合核对固定流水线包含哪些环节。
- 2AI的正确打开方式:不学概念,学动作
把 RAG 拆成六个动作,适合理解为什么切分不只是 chunking。
- 3学术界火了十年的Graph数据库,为什么等到 AI 才开始落地?|向量数据库为什么是死胡同?|纯技术创业有多爽?
说明相似度检索在跨系统关系问题上为什么吃亏,适合理解 agentic 转向的动因。
- 4AI替你做出来以后,你还会什么?|哥大客座课程回放
用 Claude Code 团队从向量库转向 agent 自己搜索的例子,说明流程可能被替代。
- 5为什么所有人都在学名词,但真正拉开差距的是动词
名词与动词的关系,适合判断该学检索本身还是学这套固定流程。
你也有想问的?
卡住的时候,问问立正:回答附有出处,可以点回原文核对。
问类似的问题也可以接着问:
别人还问了
- RAG 值不值得学习?它有什么局限性?
RAG 值得学的不是那套流程名词,而是它背后“怎么让模型用上你的上下文”这件事;只学 pipeline 容易停在简历打勾,判断不了它在你任务里值不值得用。
- 问答系统怎么做
问答系统的难点不在检索流程本身,而在判断卡、来源编号和检索粒度这些细节:让模型只挑来源、不编链接,并容忍回答慢一点。
- 想了解 RAG 怎么实现,从哪里开始读?
先读那篇讲 AI 产品六个层次的文章,它把 RAG 的完整链路和真正该学的技术点讲清楚了;再配合那期讲“不学概念、学动作”的视频,避免一上来就陷进切分和 embedding 的流水线细节。
- 之前的影片有講過,餐廳最重要的是菜做得好不好吃,至於所謂的裝潢、人力資源管理,或者是行銷都沒有菜做得好吃重要,但後來現在的說法又改成選址是最重要的地方,也就是說,你的餐廳開在哪裡,決定了你這間餐廳能賺多少錢。解釋一下為什麼開餐館的這個核心建議從菜好不好吃變成選址好不好?還是一個是決定了餐廳的下限,另外一個決定了餐廳的上限?
这不是改口,而是两个不同层次的问题:菜好不好吃决定顾客会不会再来,选址决定有多少人路过、能卖多少,也就是生意的上限。
- 我是一个程序员,有了AI之后所有人干活的效率都提高了,多出来的时间只能自己找活干,但我在目前的领域专业储备一般,找不到足够有价值的方向去投入。现在就是在被裁找新方向或者卷起来之间摇摆。如果失去稳定现金流,AI对此不太认同,它的建议是尽可能在寒冬中稳住现金流,我应该怎么做?稳住现有的工作,找新的可以做的事情?还是做好被裁打算,用业余时间积累新方向需要的专业知识?
立正的主张不是二选一,而是先保住现金流,同时把上班的视角从「完成任务」换成「积累能带走的东西」;被裁与否不是你能控制的,能控制的是这段时间在积累什么。
- 假设说我做了一个Application,然后我现在是最快的把它推到市场,还是说把用户系统最起码做好?因为我觉得,如果推两遍,比如说我先验证了需求,用户系统没做,然后让大家用了用,用完了之后好再做用户系统,再重新推的时候,是不是就并不能保证上一次还感兴趣的人,这次也看到?如果我错失了之前已经想要的用户,他是因为他要把一个软件更新或者下载两遍。就导致了这一部分的流失。
先上线验证需求,但上线不等于潦草:把用户能走通的最小路径做对,其余留到验证后再补。