【万字】抛开 RAG 谈蒸馏.skill，大概率是形式主义

上周我拜访了前老板他们应该是国内做 AI 应用最深的一批公司相应着整个团队对 AI 的应用及理解都很到位于是乎我问了他一个问题老板你觉得什么是 AI 原生团队/应用对应着团队的组织结构会有什么变化吗说实话因为打招呼做得太倡促这并不是一个好问题因为问的太大了(无论是与模型对话还是与高端人士对话问对问题都很关键)挺不好切入的…然后对话在艰难的推进过程中老板嫌无聊还用 Codex 搓了个彩虹贪吃蛇在跟我边玩边聊最后总结下来他大概的回答是能用 AI 就用 AI并且一号位要先用这里的逻辑是对 AI 的能力边界要有清晰的判断信息很多我们这里不展开不可避免这里就会涉及个问题工作都被 AI 做了那员工做什么呢是不是又会引起裁员我本来还想小声点担心引起不必要的麻烦哪知道老板毫不在意并反问了一句你为什么要站在员工角度去思考问题呢为什么不站在公司角度更进一步站在要解决的问题去思考问题呢事后回想起来这里有两个核心首先人最重要的作用其实是起心动念也就是去许愿思考想要解决的问题这个是 AI 不具备的其次当前 AI 还有很多缺陷员工/人 需要补足 AI 的能力缺陷帮他跟世界接触并做一部分兜底然后话题就进入今日的重点了我们在员工会不会蒸馏、如何被蒸馏、蒸馏有没有用的问题上讨论了很久大概的后续是我们认为现在自媒体们或者不懂的同学在瞎扯淡蒸馏这件事在技术上还没突破但长久来说确实会发生所以我们今天的话题重点就是蒸馏.skill。同事.skill虽然 OpenClaw 这阵小龙虾热潮已经褪去但是他却大大的推动了 Agent 的整体进展于是最近一些看不懂的行为又开始了比如在各个群经常出现的同事 skill以及一些稀奇古怪的 skill关于 Skills 我们之前做过深入探讨他的本质是 Workflow 的迁移也就是 Skills 里面装的是我们的工作流比如我们敬爱的陈果.skill…于是这里问题就来了我们在聊蒸馏.skill 的时候到底是在聊一个人的动作还是一个人的工作流/思考方式/思考习惯或者是承载一个人的知识再基于知识的判断因为如果我们真的去拆你会发现很多所谓的蒸馏同事蒸馏出来的往往并不是一个人的完整能力而只是他工作中最容易被整理、最容易被复用、也最容易被自动化的那部分内容。这部分内容通常不叫人格不叫灵魂也不叫组织魅力它更接近一个词Workflow这也是为什么我们更多的对于蒸馏这个词嗤之以鼻了因为你真的去了解下模型蒸馏你会发现他们最核心蒸馏的是数据因为Workflow 不是全部SOP 也不是能力本身没有数据的流程也只是形式主义罢了并不解决问题举个例子你是真的相信法外狂徒张三.skill 给你的建议吗当然这并不是 Skills 里面完全不涉及知识只不过他做得实在太粗了比如陈果.skill 就额外加了一句你靠这个就想把果总的知识调取出来我只能说***太天真了***大家要记住skill 只能教 AI 怎么做却不一定能让 AI 知道为什么这么做而一旦问题走到这里今天真正的主角就出来了RAG。RAG在 AI 时代RAG 是当前应用最为成功技术而因为最近有很多新粉我们今天再系统性的介绍下 RAG以及为什么我们需要 RAG回答这个问题我们首先要理解大模型的的特征它是基于已有的公开知识提前预训练好的模型根据用户的输入来预测下一个可能出现的Token是什么。因此大模型有如下几个缺陷它只能回答训练时提供的知识未参与训练的知识它是不知道的。训练的知识具有时效性截止于模型训练完成的那一刻但是外部世界一直在发生变化新知识模型是不知道的。对于不清楚的知识模型很容易产生幻觉所谓幻觉就是一本正经的胡说八道缺乏可解释性在某些严肃场景比如法律、医疗、金融不仅需要答案还需要追溯答案的来源。大模型无法提供其回答所依据的证据链难以满足对可信度和可追溯性的要求。所以我们才说就算你有个法外狂徒张三.skill你也不敢信就是这个原因。为了解决这些问题我们把私有知识作为提示词输入给大模型让大模型根据私有知识来回答问题。# 任务按照提供的知识内容回答用户提出的问题。# 知识{{ 全量知识 }}# 要求1. 严格依据提供的知识进行回答确保内容客观、真实不得编造或添加知识以外的信息。2. 如果所提供的知识不足以回答用户问题请直接回复“不知道”不得尝试推测或自行补充。这种方式确实可行但是存在明显的问题当我们知识非常多的时候就有如下问题可能超出大模型的上下文限制模型响应时间很长Token消耗量大成本遭不住大量知识跟用户当前的问题无关干扰信息太多反而容易诱发模型产生幻觉因此更好的做法是只把与用户问题最相关的知识作为提示词再让大模型回答。# 任务按照提供的知识内容回答用户提出的问题。# 知识{{ 相关知识 }}# 要求省略。。。。至此大家就看出来蒸馏.skill的缺陷所在了他们属于一股脑将知识全部晒给模型的做法接下来我们继续介绍 RAG 的工作原理再说蒸馏.skill 要怎么进化RAG 工作原理我用过的很多知识库或 Agent 产品比如面向个人知识管理的 IMA、NotebookLM面向企业知识管理的飞书知识库、钉钉知识库甚至是我们写代码的AI编辑器Cursor、Trae、Qoder等这些产品内部都使用了RAG技术。除此之外RAG还有更广泛的应用场景比如智能客服、法律文书辅助、医疗临床辅助、金融投研分析、在线教育辅导等。可以看到RAG已经成为大模型连接外部知识的桥梁从这里也可以反思市面上的各种蒸馏.skill你就会发现他们很天真了真这么屌国外明星 AI 公司 OpenEvidence 与 Harvey 早被干死了进一步RAG内部的工作流程是怎么样的呢我们先看整体的流程图从图中可以看到整体流程分为两个大的部分其一是知识入库其二才是检索生成下面我们对这两部分详细分解一、知识入库知识入库我们也称之为构建索引。拿到知识之后首先需要对其进行数据清洗主要是清洗知识中没有使用价值的内容减少干扰信息避免垃圾进垃圾出。比如我的知识是一份带有广告和水印的 PDF 文件我读取到的 PDF 内容是包含了所有的内容清洗这一步就需要把广告、水印以及页头、页眉、页脚都去掉。除此之外我们还需要对知识中存在的一些敏感信息进行脱敏处理比如有的企业知识库中包含了人员的姓名、电话、邮箱、身份证和密钥等信息。PS现阶段大家在做蒸馏.skill 的时候是有点鸡贼的因为公众号的格式是比较好处理的在数据清理完成后我们需要对整个内容进行分块处理把一份大的知识文档分解为若干个小的知识片段这些小的知识片段将作为后面检索的最小返回单位。分块是非常重要的直接影响到后面的检索效果这里也有很多分块的策略稍后讲解。分块完成后就把知识片段存入到传统数据库中MySQL、PostgreSQL、MongoDB、Elasticsearch具体选择哪种数据库取决于业务场景以及选择的检索策略。然后采用异步事件分批次把文档片段使用向量模型转化为向量。所谓向量本质上是一组数字用来表示文本的语义信息。语义相似的文本在向量空间中的距离也更接近。向量模型的作用就是把人类语言映射到这种可计算的语义空间中从而支持后续的语义检索。得到向量后在把向量和对应的文档片段在传统数据库中的ID存入到向量数据库中。这里存储的原则是文档片段和向量分开存储向量存在向量数据库中文档片段存在传统数据库中它们之间通过文档ID进行关联这样耦合度更低后期更换向量数据库也更加方便。上面就是整个知识入库的全部过程这个过程通常是离线环境进行的。在整个流程中有一个关键因素会直接影响最终的检索效果分块策略。下面对这一部分做进一步展开。分块策略分块的核心目标是在语义完整和检索精度之间取得平衡。如果分块太大会引入过多无关信息影响模型理解向量表达变得模糊检索精度下降。如果分块太小语义又不完整检索结果太碎片化。下面是一些常见的分块策略分块策略解释特征固定长度分块按照固定的字符数切分比如每500或1000个字符一块实现简单易于控制。但是容易破坏语义结构比如把一句话切断滑动窗口分块在固定长度基础上增加重叠区域overlap比如每块500 字符重叠100 字符实现简单保留上下文连续性结构分块基于文档结构进行切分比如按章节、段落、标题层级语义自然、完整但是依赖文档结构语义分块通过大模型判断语义边界进行切分分块的语义最优需要消耗一定Token在这些策略中我们最为常用的是滑动窗口分块因为实际项目中我们拿到的原始知识文档大多数是杂乱的文档并没有经过结构化处理而滑动窗口这种分块方式在实现成本和效果之间相对其它方式更加平衡。二、知识检索生成知识检索分为多种方式包括向量检索、全文检索、知识图谱检索、结构化数据查询等每种检索方式的实现路径完全不同各有优劣不存在最优解在生产实践中常常是组合检索方案使用。下面是向量检索的流程使用向量模型对用户的问题进行向量化得到文本向量然后去向量数据中执行相似度搜索召回TopK个向量节点同时得到每个节点的相似度得分拿到召回的向量节点后根据向量节点的文档ID去文档数据库中查询该文档ID对应的原始文档内容通过知识检索拿到召回的知识片段后就可以让大模型基于这些知识片段回答用户的问题了。这就是整个RAG从索引构建、知识检索、答案生成的全部过程这个范式也叫做朴素RAGNaive RAG只不过现阶段是有很多变化的我们也展开聊聊RAG范式演进除了朴素RAG的范式还有很多其它的RAG范式而这些范式都是从朴素RAG演进出来的下面我们看看RAG范式的演进逻辑朴素RAG首先朴素RAG是直接把用户的问题进行向量化然后语义检索在基于检索结果生成答案。但这里存在明显的问题第一用户的问题往往是很宽泛的或者跟上下文语境相关即使用了语义检索也很难召回正确的知识片段。第二通过向量检索也就是语义检索回来的内容只能说跟问题很相似但不一定相关因此召回的知识质量难以保证。Advanced RAG因此衍生出了Advanced RAG范式这个范式在Naive RAG范式的基础上增加了两个优化环节检索前对问题进行改写以提升检索命中率在检索后对问题进行重排和过滤以提升召回内容的相关性和质量从而整体增强问答效果。Modular RAGModular RAG 又在 Advanced RAG 的基础上更进了一步把整个流程节点拆分成独立的模块比如构建索引、检索前处理、检索过程、检索后处理、生成等模块。通过模块化设计我们可以根据具体业务需求灵活组合和编排 RAG 流程从而提升系统的扩展性与可维护性。Agentic RAG前面这几种范式都有一个共同的特点即按照预定义流程执行检索和生成。而 Agentic RAG 则是把大语言模型的自主规划和推理能力与前面的RAG范式相结合能够自主判断是否需要检索、什么时候检索以及检索什么内容而不是按照固定的流程检索问答。这种方式更加灵活但是目前并没有看到很好的生产实践如果非要说其实最适合蒸馏.skill的技术范式就是 Agentic RAG 了。可以看出无论是Advanced RAG、Modular RAG还是很火热的Agentic RAG其实整个核心原理并没有本质变化唯一变化的只是工程范式。下面我们更进一步看看优化RAG效果的一些常见策略再回归到 RAG 如何增强 Skills 的问题RAG优化实践下面我们更进一步看看优化RAG效果的一些常见策略查询改写在实际场景中如果直接拿用户原始问题去做向量检索效果毋庸置疑一定是很差的。原因是用户问题通常是口语化表达、上下文不完整或语义模糊、包含多种意图这些都会直接影响检索命中率。因此在检索前需要进行查询改写主要包括消除指代词把省略的信息补齐把口语表达转为标准化表达引入更利于检索的关键词把复杂问题拆解为多个单一问题。例如用户先说了一句Memo这个功能听起来很不错然后接着又问了一个问题它怎么使用这种问题无法直接检索如果改写为“怎么使用Memo”之后检索效果会明显提升。在工程实现上查询改写一般通过大模型完成在检索前增加一次模型调用对问题做预处理。进一步可以采用多路查询即针对同一问题生成多个改写版本分别检索后合并结果这种方式可以提升召回率。混合检索单一的检索方式很难在所有场景下都表现良好因此在生产环境中通常不会只使用向量检索或全文检索而是采用多种检索方式组合的混合检索方案。向量检索的优势在于能够理解语义即使表达方式不同也可以找到相似内容但它的问题是对关键词不敏感容易召回看起来相关但实际上不相关的内容。而全文检索则刚好相反它对关键词非常敏感可以做到精准匹配但缺乏语义理解能力容易漏掉一些表达不同但语义相同的内容。混合检索的思路是就是把这两种能力结合起来用全文检索保证准确性用向量检索提升召回率。常见实现方式是并行召回即同时执行向量检索和关键词检索采用RRF进行融合并去重后返回TopK也可以对不同结果进行加权排序。工程实践中常见的方案是使用Elasticsearch做全文检索同时配合向量数据库做语义检索这种方式属于最佳实践在Coze知识库、Dify知识库、FastGPT知识库中都属于默认检索策略。结果重排检索得到的是一批候选知识片段但排序不一定合理也不一定真正相关因此需要借助重排模型进行结果重排。重排的目标是从看起来相似的结果中筛选出最相关并能回答用户问题的内容并按照相关性得分重新排序。前面的检索过程属于海选目的是尽可能多的从知识库中召回相似的内容而重排相当于是精选仅保留对回答问题有价值的内容。这里的重排模型也是一个预训练好的模型我们输入问题和多个候选知识片段给重排模型它会计算每个知识片段与问题的相关性得分然后按得分排序。它相比向量检索、全文检索计算成本更高但精度更高。经过重排处理后筛选出最相关的内容再交给大模型生成答案可以提升效果并减少幻觉。RAG 方案选型通过前面的介绍我们对于RAG有了一个基本的认识如果我们现在需要实现一个基于RAG的知识问答助手有哪些实现方案1. 开发平台知识库基本上是智能体开发平台的必备功能比如Coze、Dify、FastGPTRAGFlow等这些平台把整个流程进行了产品化封装极大的降低了使用门槛。这里以Coze为例子第一步创建知识库知识入库环节我们只需要上传知识文档到平台设置好分段的策略剩下的事情平台会自动处理。第二步流程编排知识入库完成后我们进入工作流编排平台提供了知识库检索节点将其添加到画布中来把这个节点的知识库来源配置为刚刚创建的知识库然后可以设置检索策略、最大召回数量、最小匹配度、查询改写、结果重排等配置这部分配置一般采用平台提供的默认值。知识检索完成后下一步添加一个大模型节点让大模型根据检索回来的知识回答用户的问题。流程编排就这么简单关键就是检索节点、大模型回答节点。第三步接入系统前面两步完成后已经具备知识问答能力了平台也支持一键发布功能发布完成后用平台提供的独立的链接地址来使用这个功能但是这里界面都是平台提供的。如果我们需要自定义界面或者自定义一些业务逻辑我们也可以把前面的流程以API的方式接入到我们业务系统中相当于把这部分流程作为独立的服务。其它的平台的使用流程也是类似且都支持本地化部署但是在知识库检索能力上有些差异RAGFlow FastGPT Dify Coze。其中RAGFlow最专业从其命名也可以看出更偏向底层RAG引擎上手门槛最高适合工程化团队使用。而Coze、Dify、FastGPT更偏向Agent应用开发平台知识库只是其能力之一。如果没有技术背景想快速验证想法推荐直接使用Coze。2. 工程化方案这里的工程化方案是指完全通过代码来实现在没有AI Coding之前完全从零到一来编码实现还是很难的但是现在有AI Coding的加持这件事情变得也很简单。我要实现一个基于RAG的知识问答助手先帮我初始化项目确保前后端项目都能正常启动暂不实现任何具体功能技术栈要求1. 后端技术栈uv Python FastAPI PostgreSQL pgvector2. 前端技术栈 pnpm vite ts react tailwindcss zustand axios依赖三方服务1. 大模型DeepSeek API2. 重排模型qwen3-rerank3. 向量模型text-embedding-v4通过上面的提示词我们就能完成项目的初始化搭建后续的功能只需要按照前面讲解的流程一步步实现即可。我们唯一需要做的是技术栈、分块策略、向量模型、重排模型、大语言模型、检索方案、向量数据库、文档存储数据库的选型。后端语言推荐使用python生态成熟对于AI非常友好。向量数据库其次向量数据库选型非常关键核心是看规模、性能要求和检索策略。如果只是学习用途可以用轻量的组合比如 FAISS SQLite这种方案部署简单、成本低但不太适合生产使用。如果希望快速落地、降低系统复杂度可以直接用 PostgreSQL pgvector。这种方式可以把向量数据和业务数据放在一起通过 SQL 就能完成混合检索FastGPT默认也采用的这种方案实现。如果数据量很大或者对检索速度要求很高比如亿级向量、低延迟可以把向量数据拆出去用专用向量数据库比如 Milvus、Weaviate、Pinecone或者底层库 FAISS这样可以获得更好的检索速度和扩展能力。对于混合检索关键词 向量要求较强的场景可以引入 Elasticsearch使用ES 向量库组合架构来获得更成熟的全文检索与排序能力。向量模型至于向量模型主要看向量维度和语言友好度如果是中文场景推荐使用国内大模型厂商的向量模型比如阿里的text-embedding-v4维度选择一般推荐1024维因为1024 维度是性能与成本的最佳平衡点适用于绝大多数语义检索任务。对于高精度要求领域可选择 1536 或 2048 维度。这会带来一定的精度提升但存储和计算开销会显著增加。在对成本非常敏感的场景下可选择 768 及以下维度。这能显著降低资源消耗但会损失部分语义信息。好了至此我们算是对 RAG 进行了简单的介绍也只有到现在各位才会知道如果抛开 RAG 去聊蒸馏.skill 是一件多么天真的事情。这里我们进入今天最后的课题RAG 应该如何增强 蒸馏.skillSkills RAG说到这里大家应该就非常清晰了如果抛开 RAG 去聊蒸馏.skill那大概率就是在搞形式主义。所以我们现在的任务是用 Skills 去承载流程用 RAG 去承载知识再让大模型去完成理解、衔接、生成与局部判断进一步拆解也就是说skill 负责定义怎么做RAG 负责提供做这件事时所需的知识模型负责基于流程和知识把事情串起来PS这个流程是非常复杂的所以我们这里只做简单实现我们再回归一个“同事”完整点的流程知道什么时候该走什么流程知道流程里面哪些地方需要查资料知道该去哪里查知道查回来的信息哪些能信、哪些不能信知道最终应该如何基于这些信息给出一个相对靠谱的结论前两步属于 skill后面三步就开始进入 RAG 的地盘了所以我们可以把这个事情说得再直接一点skill 只能教 AI 怎么做却不一定能让 AI 知道为什么这么做而 RAG 的价值就是给这个为什么提供动态知识支撑再进一步RAG 是负责给予模型 CoT 的存在这里特别解释一句很多同学对 RAG 的理解还停留在检索点资料给模型看看这个层面但RAG 真正的价值不只是把资料塞给模型而是让模型在做理解、推理、判断的时候有机会基于外部知识展开而不是只依赖参数记忆。这就涉及到深水区了也属于我们课件中最有价值的存在但是这里只能简单说下现实工作里很多判断并不是靠天赋做出来的而是靠当前任务的上下文相关规则与制度历史案例与先例专业资料与背景知识多个信息源之间的相互印证进一步说AI 的每一次对话是需要有自己完善的底层逻辑的。从这个角度你再看蒸馏.skill很多事情就清楚了。蒸馏一个同事最容易蒸馏出来的是他的常用操作顺序他的标准 SOP他的固定模板但真正难蒸馏的是下面这些东西他为什么优先看这个文档而不是另一个他为什么知道这个客户问题要参考上个月那次事故复盘他为什么会判断这个需求表面是 A实际是 B他为什么知道这里不能照常规流程走而这些东西恰恰都和数据有关。所以没有 RAG 的 skill更像是在模仿一个人的动作有了 RAG 之后skill 才开始有机会模仿一个人做判断时的信息组织方式这时候Skills RAG 的组合才算真正开始接近工作能力这个词。只是需要说明的是单独的 RAG 我们应用得已经很深了、单独的 Skills 也毫无难度只不过这两个合起来该怎么用我们暂时也只有简单案例复杂的还在各种测试很可能答案都不是用 skill 了skill 还有很多要升级的东西我想的那个复杂场景估计要 workflow 套 Agent 再套 workflow 的架构类似于复杂的AI客服这里不做展开但如果不把这个问题讲得太复杂一个 Skills RAG 的最小闭环大概可以这么设计第一步用 skill 定义骨架流程比如你要做一个“客服同事.skill”skill 里面先不要上来就灌大量知识而是先把骨架流程定义清楚识别用户问题类型判断是否需要查询知识库如果需要查询则构造检索问题从指定知识库中召回相关资料对召回结果进行过滤与重排基于结果回答用户如果知识不足则明确说不知道或者进入人工兜底与我们之前叙述的逻辑一致skill 负责的是任务编排。第二步在关键节点接入 RAG接下来凡是涉及需要依据资料做判断的地方都不要把知识写死进 prompt而是通过 RAG 去动态取。比如一个退款问题看起来只是客服话术其实后面可能要查最新退款政策活动期特殊规则特定渠道订单的补充说明历史 FAQ风险案例这些内容不可能全部塞进 skill 里因为一旦政策更新你整个 skill 就要跟着重写维护成本极高。所以更合理的方式是skill 负责决定什么时候查、查什么RAG 负责把相关知识拿回来模型负责基于这些知识输出答案第三步让模型对检索结果做局部推理多数同学做到第二步将知识丢给模型就到头了但经过测试RAG 检索回来的东西并不天然就能直接用。因为它可能会碰到很多问题检索回来的内容彼此冲突有些资料已经过期有些资料虽然相关但并不能回答当前问题这个最烦有些资料只是辅助信息不应该当成最终依据…所以模型这里是要做一轮基于上下文的局部推理这一步通常包括判断哪些资料与当前问题最相关判断多个资料之间是否冲突最终基于可信的资料形成一个相对稳妥的回答…从这里再次显示了 AI 项目一个特点更多的智能必定带来更多的 Token…为了回答效果RAG 在给模型的推理链条提供外部知识支撑。Skills RAG 简单实践聊完理论我们直接上实操一个真正能用的同事.skill内部到底该怎么把 RAG 接进去这里先来个反面案例name: 法外狂徒张三.skilldescription: 精通刑法、刑诉法擅长辩护策略knowledge: | 刑法第XX条... 刑诉法第XX条。。。 经典案例张某某故意伤害案.. 辩护策略模板...接下来我们以企业客服场景为例设计一个能处理退换货、投诉、政策咨询的客服 skill它的内部结构大致如下name: 客服同事.skilldescription: 处理退换货、投诉、政策咨询支持多轮对话rag_config: knowledge_base: company_kb # 关联的知识库ID retrieval: top_k: 5 min_score: 0.7 rerank_model: qwen3-rerank query_rewrite: true # 是否自动改写用户问题workflow: - step: classify_intent prompt: | 判断用户意图输出类别退换货/投诉/政策咨询/其他。 如果是其他直接进入人工兜底。 - step: retrieve_info condition: intent ! 其他 action: rag_search params: query: {rewritten_query} # 使用改写后的问题 filters: # 可选过滤条件 doc_type: [policy, faq, case] - step: filter_and_reason prompt: | 你收到了以下召回的知识片段 {retrieved_chunks} 请完成以下任务 1. 标记哪些片段已过期或与问题无关 2. 找出多个片段之间是否存在冲突 3. 基于最可信的1-2个片段给出回答草稿 4. 如果信息不足明确说“需要人工确认” - step: generate_response prompt: | 基于上一步的推理结果生成最终回复。 要求语气礼貌、信息准确、必要时提供政策链接或工单编号。这个骨架里skill 干了四件事分类意图决定什么时候查、查什么对查回来的知识做局部推理生成最终回答RAG 负责的是第二步里那个 rag_search 动作它背后是一整套索引、检索、重排的流水线。关键细节skill如何调用RAG现阶段skill 是声明式的它告诉系统我需要检索系统在运行时去执行 RAG- step: retrieve_info action: rag_search params: query: {user_query} knowledge_base: company_kb top_k: 5 min_relevance: 0.75 # 高级参数 hybrid_search: true # 混合检索向量关键词 rerank: true fallback: 如果召回结果都不相关则标记为need_human系统在执行这个 step 时会对 {user_query} 做查询改写如果配置了同时执行向量检索和关键词检索合并结果后用重排模型打分过滤掉低于 min_relevance 的片段将最终 TopK 结果以结构化数据比如 JSON注入到 prompt 的 {retrieved_chunks} 变量中这样skill 的作者并不关心 RAG 的底层实践对 RAG 的使用跟调用一个 MCP 的服务并没有本质的差异。skill与多路召回复杂的任务同事不会只查一个知识库比如一个产品经理.skill可能需要同时查需求文档库竞品分析库用户反馈库历史决策记录库…这时 skill 里可以这样写- step: multi_source_retrieve action: parallel_rag params: sources: - kb: prd_kb query: {user_query} 相关需求 top_k: 3 - kb: competitor_kb query: {user_query} 竞品做法 top_k: 2 - kb: feedback_kb query: {user_query} 用户投诉 top_k: 5 fusion: rrf # 合并策略Reciprocal Rank Fusion系统会并行发起多次检索然后把结果合并、去重、重排最终交给模型。这已经接近 Modular RAG 的思路了。基于证据的推理然后就是最后的部分了RAG 召回的知识片段不能直接塞给模型就完事类似的思路在 Hermes Agent 里其实已经能看到一些影子了比如检索后的 summarization、memory recall 里的 reflect/synthesisHermes并不只是查到就塞提示词而是已经开始往检索后整理、综合、再利用的方向走只不过真正显式的证据评估与反思闭环目前还更像一个正在补强的能力。这里感兴趣同学请移步《Hermes的架构解析》好话题回归模型需要做局部推理这个推理过程其实就是在模拟一个人拿到一堆资料后的思考方式可以把这一步单独拆成一个推理模板嵌入 skill- step: evidence_based_reasoning prompt: | 你是一个严谨的客服专员。现在有以下信息 【用户问题】 {user_query} 【召回的知识片段】 {retrieved_chunks} 【你的任务】 1. 逐一评估每个片段是否直接相关是否有明确的有效期是否与其它片段矛盾 2. 如果存在矛盾判断哪个片段更可信依据来源权威性、更新时间、与问题匹配度 3. 基于最可信的片段给出一个**可操作**的回答方案。如果所有片段都不足以回答问题输出“信息不足建议转人工”。 【输出格式】 评估结果[片段A] 相关且有效[片段B] 已过期[片段C] 与A矛盾。。。 最终判断[具体回答或转人工建议]…因为我们整体篇幅很长但实操这里细节太多就不完全展开了大家有这个感受就好我们最后总结下结语我突然想着上周老板玩那个傻逼的彩虹贪吃蛇为什么另外印象深刻l为什么另外印象深刻因为一个 CEO去学 Coding 这件事情 ROI 很低但他依旧在做。这件事的背后是能用 AI 就用 AI并且一号位要先用这里的逻辑是对 AI 的能力边界要有清晰的判断这个能力边界就是AI 擅长按流程做事skill也擅长基于给定资料做推理RAG但它不擅长凭空创造知识和自主判断该查什么资料这需要人先起心动念把业务逻辑拆解成 skill 和知识库的协作关系。所以下次再有人跟你吹我蒸馏了某某大牛.skill你可以很客气地问他一句请问这个 skill 里的知识是静态写死的还是通过 RAG 动态检索的如果知识更新了你的 skill 会自动同步吗学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】