我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
为什么RAG是过渡技术
视频
音频
原始脚本
技术随笔，从亲身实践看，RAG 为何只是过渡，自主 Agent 搜索才是长期方向。 前言，这篇感悟算是后知后觉的复盘。 行业内早在一两年前就已经形成共识，传统一次性预加载 rag 会逐步被 agnetic search 智能体自主检索替代。 但我并非行业从业者。 只是业余，基于 Hermes Agent 搭建个人外置记忆系统 PAM Personal External Memory再完整走完记忆库开发、检索钩子改造、多检索工具重构全流程。 在经过真实个人资料检索实测后，才切身弄懂两代检索方案更迭的底层逻辑。 结合我检索 C 加加语言编程随笔。 多年 GCC bug 记录两个真实案例，记录这套技术眼镜背后的核心逻辑。 一、初代 rag 诞生，多重技术局限下的无奈折中方案，初代大模型时代。 所有人选择预加在式 RAG 并非这是最优解，而是当时软硬件模型能力、业务场景三重约束下唯一可行的路线。 核心短板可以总结为三点。 一、模型缺少交互闭环，无手无眼，无法自主调取外部资料。 早期大模型没有标准化 function calling 对齐能力。 即便模型能感知到自身缺少信息，需要查阅外部文档，也没办法稳定结构化输出清晰的检索指令。 无法说明要查哪一份资料，用什么关键词，筛选哪些条件。 没有标准化输出，等于没有手，程序无法自动解析模型的检索意图。 同时不存在工具结果回流的标准化链路。 就算人工完成一次查询，文本结果也不能自动回传给模型做二次判断，等于没有眼。 不存在模型检索工具结果回流再次检索的循环。 唯一的解决办法只能是人提前把全部文档预处理切片入库，一次性喂给模型，也就是 RAG 的核心逻辑。 二、模型能力不足，无法支撑多轮自主检索推理。 早年模型上下文理解、长文本语义拆解、多步骤规划能力偏弱。 很难完成理解模糊需求，拆解检索条件，根据检索结果修正查询词，二次检索。 这一套多轮思考流程，模糊碎片化，中英混合的查询场景完全无法适配。 只能依靠人提前预判所有可能用到的资料，做静态预加载。 三、落地场景高度固定，无需动态多轮检索。 当时商业化落地主流是客服机器人。 知识库范围固定，问题可预测，需求追求瞬时响应。 只需要单次检索固定知识库，就能回答绝大多数问题，不存在跨资料库、模糊回忆、多轮溯源的需求。 一次性 rag 刚好匹配这类标准化、低复杂度场景，短板被业务需求掩盖。 简单类比，初代大模型只是被动值守的售后营业员，只需要背诵固定话术与标准资料，不需要自主查找、翻阅零散存档。 二。 时代需求变化，我们需要能自主思考、自主查资料的通用智能体。 如今大家对 AI 的期待早已跳出固定客服场景，转向工程开发、代码调试、文档溯源、个人长期记忆管理等复杂场景。 对智能体的要求完全升级，智能体需要自主写代码、 debug 核对硬件配置、翻阅海量零散文档、追溯数年的历史记录。 就和人类一样，人脑无法永久存储全部碎片化信息，超过短期记忆窗口的内容必须依靠外部记录。 大模型同样受上下文窗口限制。 超出窗口的历史对话，私人文档会直接丢失，不可能把所有资料永久塞进上下文。 这种场景下，静态预加载 rag 的缺陷被无限放大。 人无法提前预判智能体所有潜在查询需求，海量文档一次性注入上下文会带来大量冗余噪声，大幅降低回答精准度。 我们需要的是能主动按需查找资料的工程师，而非只会背诵固定资料的营业员。 三、技术成熟补齐短板，AGENTIC SEARCH 成为可行路线。 最近两年，三大核心瓶颈全部打通，让自主检索闭环落地成为现实。 一、工具调用标准化成熟，补棋手经过专项对齐训练的模型，可稳定输出结构化工具调用指令，程序能无歧义识别模型意图，自动分发至不同检索工具。 二、结果回流，多轮循环链路成型。 补七眼，检索结果标准化封装后自动回流上下文，模型可以自主评估信息是否充足。 资料足够则停止检索，信息缺失则切换数据库，调整关键词再次检索，形成迭代闭环。 三、软硬件。 模型推理能力提升本地轻量化向量、全文检索、 FTS 五、 BM 二十五、终端消费及显卡本地推理普及。 不再强制要求云端毫秒级响应，大家接受 AI 先思考再检索的逻辑，不再追求无延迟及时输出。 对应我的实践改造。 我放弃了早期用后置 hook 强制合并内外记忆库的 plugin 式预加载方案，改为将日记、 Cloud 绘画、 C 加加技术文档、 GCC 报错记录。 各自封装独立检索 tool 并注册给 Hermes 模型自主判断调用哪一套记忆库。 内源对话记忆 state db 与各类外置 pm 资料彻底分层隔离。 由模型自主平衡检索效率与信息完整度。 后续还可叠加检索工具正反馈路由机制，长期使用后自动优化工具选择权重。 四、个人实测验证自主检索架构适配碎片化私人记忆两套真实检索案例，直观体现 AGENTIC SEARCH 相比传统关键词检索、老式 RAG 的碾压优势。 一、模糊概念检索 C 加加语言编程随笔。 仅模糊记得多年前日记里写过 meta programming 相关技术随笔，完全遗忘写作时间、原文语句、存储位置。 仅提供模糊概念，Hermes 自主完成语义联想检索，精准定位对应文档。 传统 grep Windows 文件搜索仅能字面匹配关键词。 极易漏检。 二、跨年度批量检索 GCC 历史 bug 反馈两年间零散提交的二三十条 GCC bug 记录，无完整关键词，无固定格式。 模型自主调整检索条件，一次性完整检索出全部28条相关记录，结果规整无遗漏。 同时我的个人记忆库存在大量中英混合文本。 海外通用检索工具天然忽略多语言场景，而依托大模型语义理解的自主检索可以完美兼容跨语种模糊查询，这是纯关键词检索永远无法解决的痛点。 五、总结。 RAG 从来不是错误的技术，而是初代大模型缺少手眼交互闭环、场景需求单一、软硬件受限时期的过渡方案。 当模型工具调用、多轮迭代检索链路成熟，我们对 AI 的需求从固定问答转向通用自主工程、长期记忆管理，由模型自主判断，按需发起多轮检索的，agantic search 就成为必然的长期技术路线。 作为非行业从业者，在 Hermes 上完整落地个人外置记忆系统，亲手完成架构重构后，才真正从实践层面印证这条演进方向的合理性。 对于管理跨度数年碎片化多语种的私人记忆而言。 分层 TOO 自主检索的 PEM 架构是目前最贴合需求、扩展性最强的解决方案。
修正脚本
技术随笔，从亲身实践看，RAG 为何只是过渡，自主 Agent 搜索才是长期方向。 前言，这篇感悟算是后知后觉的复盘。 行业内早在一两年前就已经形成共识，传统一次性预加载 rag 会逐步被 agentic search 智能体自主检索替代。 但我并非行业从业者。 只是业余，基于 Hermes Agent 搭建个人外置记忆系统 PAM Personal External Memory，再完整走完记忆库开发、检索钩子改造、多检索工具重构全流程。 在经过真实个人资料检索实测后，才切身弄懂两代检索方案更迭的底层逻辑。 结合我的C加加语言编程随笔、多年 GCC bug 记录两个真实案例，记录这套技术路径背后的核心逻辑。 一、初代 rag 诞生，多重技术局限下的无奈折中方案，初代大模型时代。 所有人选择预加载式 RAG 并非因为这是最优解，而是当时软硬件模型能力、业务场景三重约束下唯一可行的路线。 核心短板可以总结为三点。 一、模型缺少交互闭环，无手无眼，无法自主调取外部资料。 早期大模型没有标准化 function calling 对齐能力。 即便模型能感知到自身缺少信息，需要查阅外部文档，也没办法稳定结构化输出清晰的检索指令。 无法说明要查哪一份资料，用什么关键词，筛选哪些条件。 没有标准化输出，等于没有手，程序无法自动解析模型的检索意图。 同时不存在工具结果回流的标准化链路。 就算人工完成一次查询，文本结果也不能自动回传给模型做二次判断，等于没有眼。 不存在模型检索工具结果回流再次检索的循环。 唯一的解决办法只能是人提前把全部文档预处理切片入库，一次性喂给模型，也就是 RAG 的核心逻辑。 二、模型能力不足，无法支撑多轮自主检索推理。 早年模型上下文理解、长文本语义拆解、多步骤规划能力偏弱。 很难完成理解模糊需求、拆解检索条件、根据检索结果修正查询词、二次检索这一套多轮思考流程，模糊碎片化、中英混合的查询场景完全无法适配。 只能依靠人提前预判所有可能用到的资料，做静态预加载。 三、落地场景高度固定，无需动态多轮检索。 当时商业化落地主流是客服机器人。 知识库范围固定，问题可预测，需求追求瞬时响应。 只需要单次检索固定知识库，就能回答绝大多数问题，不存在跨资料库、模糊回忆、多轮溯源的需求。 一次性 rag 刚好匹配这类标准化、低复杂度场景，短板被业务需求掩盖。 简单类比，初代大模型只是被动值守的售后营业员，只需要背诵固定话术与标准资料，不需要自主查找、翻阅零散存档。 二、 时代需求变化，我们需要能自主思考、自主查资料的通用智能体。 如今大家对 AI 的期待早已跳出固定客服场景，转向工程开发、代码调试、文档溯源、个人长期记忆管理等复杂场景。 对智能体的要求完全升级，智能体需要自主写代码、 debug 核对硬件配置、翻阅海量零散文档、追溯数年的历史记录。 就和人类一样，人脑无法永久存储全部碎片化信息，超过短期记忆窗口的内容必须依靠外部记录。 大模型同样受上下文窗口限制。 超出窗口的历史对话、私人文档会直接丢失，不可能把所有资料永久塞进上下文。 这种场景下，静态预加载 rag 的缺陷被无限放大。 人无法提前预判智能体所有潜在查询需求，海量文档一次性注入上下文会带来大量冗余噪声，大幅降低回答精准度。 我们需要的是能主动按需查找资料的工程师，而非只会背诵固定资料的营业员。 三、技术成熟补齐短板，AGENTIC SEARCH 成为可行路线。 最近两年，三大核心瓶颈全部打通，让自主检索闭环落地成为现实。 一、工具调用标准化成熟，补齐手：经过专项对齐训练的模型，可稳定输出结构化工具调用指令，程序能无歧义识别模型意图，自动分发至不同检索工具。 二、结果回流，多轮循环链路成型。 补齐眼：检索结果标准化封装后自动回流上下文，模型可以自主评估信息是否充足。 资料足够则停止检索，信息缺失则切换数据库，调整关键词再次检索，形成迭代闭环。 三、软硬件能力提升。 模型推理能力提升，本地轻量化向量、全文检索、 FTS、BM25、终端消费级显卡本地推理普及。 不再强制要求云端毫秒级响应，大家接受 AI 先思考再检索的逻辑，不再追求无延迟及时输出。 对应我的实践改造。 我放弃了早期用后置 hook 强制合并内外记忆库的 plugin 式预加载方案，改为将日记、 Cloud 绘画、 C 加加技术文档、 GCC 报错记录，各自封装独立检索 tool 并注册给 Hermes 模型自主判断调用哪一套记忆库。 内源对话记忆 state db 与各类外置 PAM 资料彻底分层隔离。 由模型自主平衡检索效率与信息完整度。 后续还可叠加检索工具正反馈路由机制，长期使用后自动优化工具选择权重。 四、个人实测验证自主检索架构适配碎片化私人记忆两套真实检索案例，直观体现 AGENTIC SEARCH 相比传统关键词检索、老式 RAG 的碾压优势。 一、模糊概念检索 C 加加语言编程随笔。 仅模糊记得多年前日记里写过 meta programming 相关技术随笔，完全遗忘写作时间、原文语句、存储位置。 仅提供模糊概念，Hermes 自主完成语义联想检索，精准定位对应文档。 传统 grep Windows 文件搜索仅能字面匹配关键词。 极易漏检。 二、跨年度批量检索 GCC 历史 bug 反馈两年间零散提交的二三十条 GCC bug 记录，无完整关键词，无固定格式。 模型自主调整检索条件，一次性完整检索出全部28条相关记录，结果规整无遗漏。 同时我的个人记忆库存在大量中英混合文本。 海外通用检索工具天然忽略多语言场景，而依托大模型语义理解的自主检索可以完美兼容跨语种模糊查询，这是纯关键词检索永远无法解决的痛点。 五、总结。 RAG 从来不是错误的技术，而是初代大模型缺少手眼交互闭环、场景需求单一、软硬件受限时期的过渡方案。 当模型工具调用、多轮迭代检索链路成熟，我们对 AI 的需求从固定问答转向通用自主工程、长期记忆管理，由模型自主判断、按需发起多轮检索的agentic search 就成为必然的长期技术路线。 作为非行业从业者，在 Hermes 上完整落地个人外置记忆系统，亲手完成架构重构后，才真正从实践层面印证这条演进方向的合理性。 对于管理跨度数年碎片化多语种的私人记忆而言。 分层 Tool 自主检索的 PEM 架构是目前最贴合需求、扩展性最强的解决方案。
英文翻译
back to top