#RAG

𝙩𝙮≃𝙛{𝕩}^A𝕀²·ℙarad𝕚g𝕞

2周前

LLM出现的第一天起，就有很多人想把LLM这种公域的认知智能应用于企业场景。首先面临的是需要喂给LLM企业具体场景的知识作为上下文，输出为企业场景需要的业务文本、逻辑和智能，以及结合agent自动化工作流提高效率。场景知识注入的挑战，表现为一个RAG问题，RAG从naive、advanced到modular，以及为了解决知识碎片化的GraphRAG，甚至近期更提出了agentic RAG，把知识提取作为一个更自主和自适应的企业AI Multi-Agengt应用的一个模块。

#LLM #企业应用 #知识注入 #RAG #自动化工作流 #GraphRAG #Agentic RAG

熊布朗

2周前

—— [转发]RAG之父：部署RAG Agents的10个经验教训昨天读了Douwe Kiela的一场演讲记录。两小时内，我推翻了过去3个月的AI项目方案。每年有数千家企业部署RAG系统，但87%最终沦为摆设。为什么？技术没问题，方法错了。系统集成比模型重要，数据价值比算法关键，企业落地比概念验证难。我是持续探索与AI协作方式，觉醒强大自己的周知。希望今天分享对你有启发。 1. 系统大于模型企业AI项目最常见的错误：过度关注语言模型性能。 "更好的大语言模型不是唯一答案，系统级能力优先于模型性能。" Kiela的第一条教训直指痛点。一家财富500强企业花费900万美元购买最先进的模型，最终用户却只用它来检查邮件拼写。他们忽略了完整的工作流程集成。另一家初创公司用开源模型构建了端到端系统，成本只有前者5%，却创造了10倍价值。成功的RAG项目都不是因为模型最强，而是因为系统最完整。性能差5%的模型，配上好的检索系统，胜过性能强20%但检索混乱的系统。AI不是孤岛，是协同系统。 2. 内部知识为王公司投入数百万训练定制AI，却忽略已有的专业知识库。这是本末倒置。 "企业内部积累的专业知识才是驱动AI产生价值的核心燃料。" Kiela的第二条教训提醒我们：专业知识比通用能力更宝贵。一家医疗器械公司原计划从零训练医疗大模型。后来他们转向构建专业知识RAG系统，成本降低90%，准确率提高35%。内部知识是你的竞争壁垒，不是模型参数。将现有专业知识与AI结合，比盲目追求更大的模型有效得多。 3. 数据处理是护城河 AI项目失败的第三大原因：数据准备过度理想化。 "大规模处理企业数据的能力才是护城河，重点要放在让AI有效处理大规模、多元和含噪数据上，而非过度清洗数据。" Kiela在讲到第三点时格外强调。真实世界数据总是混乱的。一家零售巨头花了6个月"完美"清洗数据，结果上线后发现模型无法处理新出现的数据变体。相比之下，另一家直接用"脏数据"训练，但构建了稳健的数据处理管道，三周内就实现了价值。完美的数据是幻想。能处理不完美数据的系统才是王道。构建处理真实世界数据的能力，比幻想完美数据集更实际。 4. 生产环境比试点难概念验证很容易，生产落地很困难。这是AI领域永恒的真理。 "建立小规模试点相对容易，但是如果要扩展到生产环境，就会面临巨大挑战。" Kiela的第四条教训直指许多项目死于从试点到生产的"死亡之谷"。某银行的AI诈骗检测系统在试点阶段准确率达95%，但部署到生产环境后跌至62%。原因是试点环境中没有考虑数据延迟和系统负载。生产环境和试点环境有天壤之别。从一开始就考虑规模化、安全性和集成问题，不要等到试点成功后才思考。 5.速度胜过完美追求完美是AI项目的头号杀手。 "速度比完美更重要。80分方案快速上线往往优于追求100分的延迟交付。" Kiela的第五条教训揭示了一个残酷现实：过早追求完美会延长开发周期，错失市场机会。一家物流公司花18个月打造"完美"AI调度系统，上线时发现业务需求已经变化。而竞争对手用8周上线了"足够好"的版本，抢占了市场。快速发布，持续迭代，是AI项目的制胜法则。先解决80%的问题，剩下的20%可以逐步完善。 6. 工程师时间最宝贵企业经常在错误的地方消耗技术资源。 "不要让工程师在无聊的事情上花费大量的时间。工程师的精力不能耗费在分块策略、提示工程等底层优化上。" Kiela的第六条教训指出了资源浪费的常见陷阱。某科技公司让五名工程师花了三个月优化提示词，结果被一个自动化提示词优化工具完全超越。这些工程师本可以解决更有价值的问题。我观察过的成功AI团队都有一个共同点：他们使用现成工具解决标准问题，将宝贵的工程资源集中在差异化功能上。工程师是最稀缺资源。让他们专注于创造独特价值，而不是重复发明轮子。使用成熟工具和框架，避免陷入技术细节的泥潭。 7. 降低使用门槛出色的技术如果没人用，等于零。 "要让AI易于消费，将AI嵌入现有业务系统而非独立工具，以降低用户使用门槛。" Kiela的第七条教训道出了许多AI项目的死因：用户采纳度低。一家保险公司开发了强大的客户分析AI，但要求员工学习新界面，结果采用率不到5%。后来他们将AI功能整合到现有CRM中，采用率飙升至78%。最好的AI是用户感知不到的AI。无缝集成到现有工作流程中，让用户不需要改变习惯就能获得价值。 8. 创造"惊叹时刻" 产品采纳的关键是情感连接，而非功能列表。 "要让AI应用产生粘性，让你的用户体验到惊叹时刻，比如用户首次使用AI解决历史难题，发现隐藏知识。" Kiela的第八条教训点明了用户留存的秘诀。某咨询公司的知识管理AI在首周使用率高，但很快下降。后来他们增加了"你知道吗"功能，展示用户不知道的相关信息，使用率立刻反弹。打造能让用户说"哇"的功能，而不仅仅是高效功能。情感连接比功能清单更能驱动持续使用。 9. 可观测胜过准确率企业常犯错误：过度关注准确率，忽视可解释性。 "可观测性比准确率更重要。在保证基础准确率后，重点要转向归因追溯、审计追踪和错误分析。" Kiela的第九条教训强调了AI系统透明度的重要性。一家金融机构部署了95%准确率的欺诈检测系统，但无法解释判断依据，导致合规部门拒绝使用。后来他们牺牲2%准确率换取完整归因能力，系统终获批准。用户不仅要知道结果，更要知道为什么。可解释性常比准确率后2%更重要。企业环境中，可追踪、可审计、可解释比额外的准确率更有价值。如果无法解释AI的决策过程，再准确的系统也难以获得信任。 10. 胆大心细最后也是最重要的一条：雄心决定高度。 "要有雄心壮志，因为项目失败往往不是因为目标太高，而是因为目标太低，所以要敢于挑战能真正带来业务转型的难题。" Kiela的最后一条教训道破了企业AI成功的终极密码。某制造商最初只想用AI优化库存预测，节省2%成本。后来他们重新定位项目，打造全面的供应链智能系统，不仅节省12%成本，还创造了新业务线。我见过太多企业用AI解决边缘问题。真正成功的是那些敢于用AI重构核心业务流程的公司。他们不是寻求10%的改进，而是10倍的突破。 AI不是为了小修小补，而是为了从根本上改变业务模式。小目标导致小成果，大胆设想才有可能实现大突破。

#RAG #AI项目 #技术部署 #系统集成 #数据价值

蓝点网

2周前

研究人员利用 #Copilot 中的逻辑漏洞让 AI 代理帮忙窃取敏感数据，整个过程不需要用户点击，只需要向目标企业员工发送一封普通的文本邮件即可。这封邮件包含提示词，邮件会被 RAG 收集并按照指令进行操作，AI 代理未经用户同意的情况下会将数据发送给攻击者。查看全文：

#Copilot #AI代理 #数据窃取 #RAG #网络攻击

BadUncle

2周前

RAG 向量实时搜索大混战，cursor cline windsurf aider claude code大比拼第一组：完全抛弃RAG的实时搜索派 Cline 和 Claude Code 相似点：都完全放弃了传统的RAG方法，采用实时动态搜索区别： - Cline使用ripgrep等文件系统工具进行正则搜索，模拟人类开发者的代码探索方式 - Claude Code使用”agentic search”，通过grep、glob等标准开发工具，由AI模型动态编排多轮搜索第二组：基于图结构的智能索引派 Aider 独树一帜使用AST+图结构，将代码文件作为节点，依赖关系作为边，通过自定义排名算法（不是PageRank）优化代码映射第三组：混合RAG+高级技术派 Cursor 和 Windsurf 相似点：都使用embeddings向量化+RAG，但加入了很多高级技术区别： - Cursor：使用OpenAI的embedding模型+TurboPuffer向量数据库，实验DSI技术，支持云端分布式架构 - Windsurf：使用”M-Query技术”+本地/远程混合索引，专注企业级部署，有Cascade代理系统技术路线的哲学差异实时派（Cline/Claude Code）认为准确性和实时性比效率更重要，愿意用更高的token消耗换取完美的代码同步。图结构派（Aider）把代码理解当作图优化问题而非语义相似性问题，在结构化理解方面表现出色。混合派（Cursor/Windsurf）试图在效率和准确性之间找平衡，通过技术创新提升传统RAG的性能。性能特点对比 Aider：token使用最少（1-8K），线性扩展，但无法理解运行时行为 Cline：数据完全同步，但token消耗较高，依赖文件系统性能 Cursor：查询响应快，处理大代码库好，但有embedding模型限制 Windsurf：延迟极低，内存使用高效，但需要大量初始索引时间 Claude Code：准确度最高，无需维护索引，但成本极高（有用户每天消费数千美元）总的来说，业界正在从静态预索引向动态、探索性系统转变，你的记忆是对的 - Aider确实使用AST，但用的是图算法而不是PageRank；Claude Code确实不用RAG，直接用grep等工具进行搜索。

AI编程工具激战：Claude Code、Gemini Cli崛起· 136 条信息

AI编程：Gemini领跑，协作创新涌现· 189 条信息

#RAG #向量搜索 #实时搜索 #Claude Code #Cline #技术比较 #搜索技术

wwwgoubuli

3周前

很久没聊 RAG 了，随便说点。 RAG 里的分块技术，某种程度上看起来确实显得越来越过时了。不是说完全抛弃不要，只是分块带来的弊端越来越明显，多高超的技巧都救不回来“信息完整度”的缺失。当然总有上下文窗口不够的情况，完整的大型文档丢进去，确实吃不下怎么办？凉拌。你就用最简单粗暴的方法，按长度来，丢过去做点预处理，总结，然后差不多行了。这种方法下，切割的问题依然存在，会有把完整信息切错乱，让上下文不精准的可能。但首先，影响真的不大。这种方法会有信息折损，但不会比你以前精妙的各种分块技术，各种组合，效果差到哪里去。不同的场景下会有差别，肯定有赶不上传统方案的时候，但——无伤大雅。以前的 RAG 到底做到了个什么水准，那么多雕花，最后的成果如何，大家心里都有数。其次，你要相信今天的模型。论聪明程度，这个意义不大。但论长上下文的处理，对超长文本的高维关系分析，人类已经连 LLM 的尾灯都看不到了。不会差到哪里去的。节省下来的时间力气，都足以在其他方面做很多新的探索。比如 PDF 不做 OCR，不分块，而是直接转图片给多模态。也不是说传统 chunk 技术就有什么问题，那里面其实已经诞生了很多可靠的实践，可以对不少效果兜底。但大多数情况下，做的就还是雕花的工作。原始数据有多脏，各种格式有多奇葩，各位应该多少有耳闻。雕花的事，少干点，有这技术就行，没必要天天弄。你看 Apple 刚 WWDC 上端出来的顶级雕花，真的一言难尽。

#RAG #分块技术 #信息完整度 #上下文窗口 #预处理 #切割问题

ginobefun

3周前

#BestBlogs RAG 技巧与底层代码剖析 | 阿里云开发者使用 Python 基础库从零实现 RAG 内核，深入剖析文本分块、语义搜索及上下文增强技巧。摘要：本文旨在通过手写代码的方式帮助读者深入理解 RAG 的工作原理，避免过度依赖现有框架。文章首先展示了使用 Python 基础库实现简易 RAG 系统的过程，包括数据导入、固定长度文本分块、Embedding 创建和基于余弦相似度的语义搜索，并提供了代码示例。接着，详细介绍了基于语义的文本分块方法，对比了其与传统方法的优势，并阐述了百分位法、标准差法、四分位距法等切分点判定策略，同样给出了基于语义分块的代码实现。最后，文章引入并实现了“上下文增强检索”技巧，即在检索到最相关文本块的同时包含其前后相邻块，以提供更丰富的上下文信息给语言模型，从而提升回答质量。通过代码实践，文章有效地揭示了 RAG 的核心逻辑和关键优化方向。主要内容: 1. 手写 RAG 核心模块有助于深入理解其工作原理。 -- 通过仅使用 Python 基础库和常用科学计算库实现 RAG 流程，能更清晰地掌握从数据处理到响应生成的底层逻辑。 2. 语义分块比固定长度分块更能捕获完整语义单元。 -- 基于句子间语义相似度进行智能切分，能有效避免语义割裂，提高检索到的上下文质量和相关性。 3. 上下文增强检索能为 LLM 提供更全面的信息。 -- 在检索结果中包含相关文本块的邻近内容，能丰富大模型获得的背景知识，减少因信息不完整导致的回答偏差。文章链接：

#RAG #Python #文本分块 #语义搜索 #上下文增强 #阿里云开发者 #手写代码 #工作原理

黄赟

1个月前

AI 客服大有可为，即便是麦当劳当前的自动化客服，依旧稀烂 !! 1/ 细腻的情感，仅靠 RAG, Fine Tunning 技术弥补不了。有经验的老手，与 AI 技术手之间，总有理解损耗 2/ 客服极考验体系化 SOP，机器人客服失败转人工，但前半程客服内容，并没有实时送入 RAG 等知识库，人工接手后还得从头来 3/ 用 AI 去动老登的蛋糕，必将困难重重。而用新业务当炮灰，九死一生。新业务要做好，前面两道关又必须闭环今天体验了一把浦东软件园麦当劳的 AI 客服，要不是我屁股坐 AI 技术这端，知道局限性，非让麦麦这帮老登给带歪了不可

#AI客服 #自动化客服 #RAG #技术挑战 #客服体系 #机器人客服 #麦当劳 #人工接手 #新旧业务竞争

岸田崇史 | Omluc

1个月前

Microsoft Copilot Studioを活用し、TeamsとDifyの連携を実現しました！ TeamsのチャットUIはそのままに、裏側でDifyのRAGチャットボットが動作します。これにより、情報検索や問い合わせ対応がさらにスムーズになります。 Copilot StudioとDifyを組み合わせることで、活用の幅がさらに広がりそう...！

#Microsoft #CopilotStudio #Teams #Dify #チャットボット #AI #RAG #技術統合

Y11

1个月前

分享5个大模型应用面试真题，各位自诩‘资深’的大模型专家，遇到如下面试题时，你会回答吗？ 1. 请详细阐述你所熟悉的一种主流深度学习框架的核心特点和优势，以及你在实际项目中是如何运用它？ 2. 大模型训练中遇到训练时间长，消耗大的问题，你是如何解决的请分享具体的经验。 3. RAG和Graph-based RAG各有特点，请对比这两种场景，并说明你在实际项目中是如何选择和应用它们？ 4. 假设你负责一个大模型应用项目，从需求分析到项目落地，你会遵循怎样的流程？请详细描述每个阶段的关键任务和注意事项。 5. 请举例说明你在使用Langchain或LlamaIndex等大模型应用开发框架时，遇到的最大挑战是什么，以及你是如何解决的？

#大模型 #面试 #深度学习 #RAG #Graph-based RAG

johann.GPT

1个月前

Cursor 是如何用 Merkle 树 + RAG 实现快速索引代码库？ 💡 核心思路： 1️⃣ 本地用 AST 分割代码 → 构建 Merkle 树"指纹" 2️⃣ 只同步变更文件（增量更新，节省 90%+ 带宽） 3️⃣ 代码块 → Embedding 向量 → Turbopuffer 向量数据库 4️⃣ 用户提问 → 语义搜索 → 本地读取源码 → LLM 生成答案 🛡️ 隐私保护：源代码永远不离开本地，只有向量上传云端 ⚡ 效率爆表：Merkle 树让大型代码库秒级同步 🧠 智能理解：用 RAG 检索

#Merkle树 #代码索引 #RAG #LLM #隐私保护 #语义搜索

ginobefun

1个月前

#BestBlogs 一文带你 "看见" MCP 的过程，彻底理解 MCP 的概念 | 阿里云开发者深度解析 AI 上下文协议（MCP），对比 RAG 与 Function Calling，并通过实践演示理解其工作流程。摘要：文章详细介绍了模型上下文协议（MCP），一个旨在标准化 AI 助手与外部系统连接的开放标准。作者首先回顾了 RAG 和 Function Calling 等相关概念，阐述了它们与 MCP 的联系和区别。接着，文章深入讲解了 MCP 的核心组件（主机、客户端、服务器）及客户端-服务器架构，并对比分析了 MCP 相较于传统 API 在动态适应性方面的优势。随后，文章通过 ModelScope 的 MCP 市场和 Cherry Studio 客户端，一步步演示了 MCP 的实际配置和调用过程，通过开发者模式让读者“看见”并理解模型选择工具并请求服务器的数据交互流程。最后，文章总结了 RAG、Function Calling 和 MCP 在借助外部工具增强大模型能力上的共同本质。主要内容: 1. MCP 是连接 AI 助手与外部数据/工具的开放标准 -- 模型上下文协议（MCP）由 Anthropic 开源，旨在为 AI 模型访问内容、工具提供标准化的“USB-C”式接口，提升 AI 应用的互操作性。 2. MCP 采用客户端-服务器架构，组件包括主机、客户端、服务器 -- 主机提供 AI 交互环境，客户端运行于主机内与 MCP 服务器通信，服务器暴露工具、资源、提示等功能，实现结构化互动。 3. MCP 通过动态能力描述克服传统 API 硬编码问题 -- 客户端能查询服务器当前功能并动态适应，无需硬编码参数变更，提高了 AI 应用与外部系统集成的灵活性和稳定性。 4. RAG、Function Calling、MCP 本质都是增强大模型外部能力 -- 这几种技术殊途同归，都是为了让大模型能够获取外部信息或使用外部工具，以完成更复杂、更准确的任务。 5. 通过开发者工具可“看见”MCP 调用的实际过程 -- 文章通过工具演示，展示了 AI 应用选择 MCP 工具、发送请求、接收结果，并最终由大模型生成回复的完整流程，增强体感理解。文章链接：

#AI #MCP #RAG #FunctionCalling #阿里云 #开发者 #技术

ginobefun

1个月前

#BestBlogs 淘宝 Java 工程师的 LLM 开发实践 | 大淘宝技术从 Java 工程师视角出发，详细介绍如何使用 Spring AI 框架进行 LLM 应用开发，包括对话、Function Calling 和 RAG 实践。摘要：本文为 Java 工程师提供了 LLM 应用开发的实战指南。首先分析了当前 LLM 的局限性，强调了应用开发的重要性。接着介绍了面向 Java 的 LLM 开发框架 Spring AI，并与主流的 Python LangChain 进行对比。文章核心内容详细阐述了三大应用场景的实现：一是对话聊天，讲解了角色、Prompt 和 Memory 概念与实现；二是联网搜索等通过 Function Calling 调用第三方 API；三是利用 RAG 技术构建个人知识库，深入解析了 RAG 原理、Embedding 和向量数据库，并提供了完整的数据构建与检索生成流程。文章结合具体代码示例，为 Java 开发者高效应用 LLM 提供了可操作的路径。主要内容: 1. LLM 应用开发对 Java 工程师提升效率至关重要 -- 相较于模型训练理论，掌握 LLM 应用开发更能帮助 Java 工程师在实际工作中利用 AI 技术提升效率和生活品质。 2. Spring AI 为 Java 开发者提供了高效的 LLM 开发框架 -- Spring AI 借鉴 LangChain 思路，使 Java 工程师无需学习新的语言，即可快速融入现有体系进行 LLM 应用开发。 3. Function Calling enables LLMs to interact with external APIs -- 利用 Function Calling 能力，LLM 可根据用户指令自动调用外部服务（如联网搜索），获取实时或特定数据，弥补自身知识盲区。 4. RAG 技术是构建个人知识库、解决 LLM 局限的关键 -- RAG 通过检索外部数据增强 LLM 生成能力，有效解决模型知识滞后、覆盖有限和产生幻觉等问题，提高生成内容的准确性和相关性。 5. Embedding 和向量数据库是 RAG 技术的基础设施 -- Embedding 将非结构化数据转化为向量，向量数据库高效存储和检索这些向量，是实现 RAG 检索增强功能的关键支撑技术。文章链接：

#JAVA #LLM #Spring AI #Function Calling #RAG #淘宝 #技术

宝玉

1个月前

一个专业人士，可以根据不同的问题源源不断的产生答案，随着专业能力精进还能产生更好的答案。AI只能训练这个人公开回答过的问题和答案，对于没有回答过的就不一定能回复好。当然AI的优势是基础知识库足够强大，回复速度快。另外这里说的知识库“训练”通常是指的RAG，本质上就是检索筛选，根据检索出的“片段”拼凑出答案。

#专业能力 #AI #知识库 #RAG #答案生成 #问题解决 #训练 #检索 #基础知识

idoubi

2个月前

关于 MCP 的几个理解误区： 1. 误区 1：MCP 协议需要大模型支持 MCP 全称模型上下文协议，是为了在用户与大模型对话过程中，补充上下文信息给大模型，让大模型更准确的回答用户提问而设计的。在 MCP 出来之前，有多种方式可以实现上下文信息的补充，比如： - 记忆存储。把对话过程的历史消息存储下来，每次新提问，带上历史消息一起发送给大模型 - RAG。在让大模型回答问题之前，先从本地知识库或者互联网上检索信息，作为上下文补充给大模型 - Function Calling。传递一堆工具给大模型挑选，根据大模型的返回参数，调用工具，用工具返回的结果作为上下文补充给大模型理解了给大模型补充上下文的原理，就可以知道，MCP 的本质，是指导应用层，如何更好的补充上下文信息给大模型。模型收到回复提问请求时，MCP 工作已经完成了。结论：MCP 协议不需要大模型支持，哪怕你使用古老的 gpt-2 作为问答模型，依然可以使用 MCP 协议补充上下文信息。 2. 误区 2：只有支持 Function Calling 的模型才支持 MCP 协议聊 MCP 协议，必须要理解 Function Calling 机制。 - Function Calling 是一种交互范式。基本流程是应用层传递一堆工具给大模型，大模型意图识别，做一次 Pick Tool 操作，返回应该调用的工具名称和调用参数，再由应用层发起 Call Tool 操作，拿到结果重新给到大模型回答。 Function Calling 这套机制下有三个角色：应用、资源方、大模型。两个核心步骤：Pick Tool 和 Call Tool。 Pick Tool 需要大模型推理，Call Tool 需要应用与资源方交互。 - MCP 协议是一套交互标准。可以理解为 MCP 是对 Function Calling 机制的包装与升级。 MCP 协议定义了三个角色：主机、客户端、服务器。跟 Function Calling 机制相比，MCP 协议相当于是把客户端-服务器作为一个黑盒。整体视角看，MCP 协议有四个角色：主机应用、黑盒（客户端-服务器）、资源方、大模型主机把请求给到客户端，客户端请求服务器，服务器对接资源方，主机最终得到黑盒返回的结果，作为补充上下文给到大模型回答。 Function Calling 是应用直接对接资源，MCP 是应用通过黑盒对接资源，对接更加标准化，资源接入成本更低。 Function Calling 是应用直接定义一堆工具，MCP 是应用从 MCP 服务器获取定义好的工具，应用无需重复编码。涉及到工具调用的环节，MCP 与 Function Calling 的交互形式一致。都依赖大模型的 Pick Tool 能力。所谓的大模型支持 Function Calling，是指大模型在 Pick Tool 环节，有更好的理解和推理能力，最终能返回更加准确的 Tool 和参数。不支持 Function Calling 的模型，依然可以通过提示词工程实现 Pick Tool。只不过准确度不如支持 Function Calling 的模型。结论：不支持 Function Calling 的模型，依然可以使用 MCP 协议补充上下文信息。 3. 误区 3：大模型原生支持 MCP 协议所谓的大模型原生支持 MCP 协议，正确的理解应该是大模型内化了 MCP 协议的定义，并且内置集成了大量基于 MCP 协议定义的工具。当接到用户提问时，应用即使不给大模型传递任何工具，大模型依然可以基于内化的工具列表进行推理，返回应该调用的工具名称和调用参数给应用。事实上，互联网上的资源是千差万别的，意味着对接资源的 MCP 服务器及其内部的工具是海量的，不可枚举的。另一个关键点是，某些资源是私有的，需要用户鉴权的，大模型训练时不可能内化用户的鉴权凭证。从这个角度来讲，大模型内化 MCP 协议下的海量工具，不现实也不可能。某些模型厂商，也许是为了蹭 MCP 的热度，某些自媒体，也许是对 MCP 协议理解不到位，宣称某大模型原生支持 MCP 协议。其实要表达的意思，也许只是，在随大模型一起发布的某个 agent 框架里面，加上了对 MCP 协议的支持。结论：大模型原生支持 MCP 协议，这种说法是不专业的。大模型现阶段不可能原生支持 MCP。本人认知有限，也许会有理解偏颇之处。欢迎补充交流。🙂

#MCP协议 #误区 #大模型 #上下文信息 #记忆存储 #RAG

马东锡 NLP 🇸🇪

2个月前

「Agent, RAG, Reasoning」论文 ReSearch: Learning to Reason with Search for LLMs via Reinforcement Learning ReSearch，充满了 ReAct 的影子。它教会模型“何时求助于世界”；但局限在于，ReSearch 只能依赖一种工具。作者提出了一种创新的框架，名为 ReSearch，旨在通过强化学习（RL）训练 LLM 在推理过程中有效地反复利用 search API 完成任务。从任务形式上，它解决的是增强LLM+ RAG的问题，但并不同于基于 embedding 的单轮相似度检索方法。它关注的是多次 query、反复调用 search API 来完成信息查询任务。并不同于基于embedding去单次算相似度的方法，它解决的是多次query，反复调用search API完成外部信息查询的问题。而反复调用 API，涉及推理能力去决策调用的时机，以及生成调用的参数 —— 这是一个典型的 agent + function calling 场景。 ReSearch目标将这种search的reasoning能力通过RL学到。具体来说，ReSearch 采用了专门为搜索功能设计的训练模版： <think>...</think>：表示模型的思考过程； <search>...</search>：表示模型发起的搜索查询； <result>...</result>：表示搜索引擎返回的结果； <answer>...</answer>：表示模型给出的最终答案。特别地，ReSearch 的奖励函数不是仅仅基于答案对错，而是采用 rule-based 的组合机制：基于答案的 F1 相似度 + 输出格式是否符合模板，以此优化 policy，微调语言模型参数。此时不免再次提及 ReAct：ReSearch 充满了 ReAct 的循环影子——： Reasoning：模型的思考过程； Action：模型发起的调用； Observation：工具返回的反馈。 ReAct 是神作，它以 verbal reasoning （人话）的方式，将原本充满数学公式的 RL 概念转化为语言链式推理，让 LLM 学会如何使用工具，优雅而简洁。一些思考： ReSearch 以及前几天分享的 ReTool 是非常类似的工作，它们都通过强化学习微调，将使用工具的能力内化于语言模型中，增强工具调用的鲁棒性。但它们的局限性也非常明显：ReSearch 和 ReTool 都只支持一种工具 —— search API 和 code interpreter。而 ReAct，通过 Prompt Engineering，就可以灵活调用多个外部工具。 ReSearch 和 ReTool 的 RL 框架是为“单工具、二选一调度”设计的。如果强行扩展为多工具，训练信号将更加稀疏、credit assignment 更加困难，其策略网络、reward assignment、以及 rollout 表达能力都需要重新设计。我们距离真正原生具备多轮、多工具能力的通用 Agent，还有一段距离。

#agent #RAG #reasoning #Research #React #强化学习 #大模型 #Reinforcement Learning #工具使用 #创新框架

Jixian Wang

2个月前

数据污染确实是一个不回避的问题，不过更高级的应用还是要靠Re/Act 和 RAG + MCP 的模式。只是用模型的推理和总结能力，限制模型幻觉。

#数据污染 #Re/Act #RAG #MCP #模型推理 #模型幻觉

宝玉

2个月前

问：宝玉老师，我想请教个rag的问题。我们想通过收集时事新闻报道编写分析报告，如果采用RAG方案对新闻进行处理，数据量提供多大出来的报告比较合适，亦或者这个需求有什么别的更好的处理方案吗答：通常在考虑使用 AI 解决问题时，我的第一个建议是先不要考虑 RAG 这些因素，而是回归聚焦到问题本身，搞清楚要解决什么问题，然后再看要不要使用 AI 的方案，以及怎么使用 AI 的方案。就拿这个问题来说，根本需求是：“收集时事新闻报道编写分析报告”。如果这个任务没有 AI 的时候我们怎么做？我能想到的做法可能是这样的，要写一个某个话题的分析报告，根据这个话题去找相关的时事新闻报道，从中挑出几篇最相关的质量最好的，基于它们去分析去撰写报告。这里面有两个核心的子任务： 1. 根据主题去检索和排序 2. 根据检索和筛选出来的内容去生成报告。这两点恰恰是 RAG 要解决的问题，检索、排序和生成。那么回到原始的问题，这个需求是不是就要用 RAG 呢？数据量提供多大出来的报告比较合适？我的建议是： 1. 不一定要用 RAG，可以用 RAG 结合传统搜索工具 2. 数据量多大比较合适取决于模型 3. AI 生成时，输入内容和生成结果最好都有专业人士辅助虽然 RAG 是要解决检索、排序和生成的问题，但现实是工程难度很高，实际效果并不算非常理想，难点在于： 1. 如何检索出真正相关的内容，并且摘录出最相关的部分 2. 上下文窗口长度有限，只能提供一部分内容作为上下文给大语言模型处理，但是选择哪些内容是很有挑战的。就我对大语言模型的了解，现在无论是在检索排序，还是在生成，AI 的结果都不能稳定的超过专业人士的水平，但如果专业人士借助 AI，是可以做到效率高质量也稳定的。所以这个任务，现阶段想完全基于 RAG 实现自动化检索生成，也不是不可以，但是要接受质量不稳定。如果想要质量好，就要有经验的人工介入，帮助 AI 去检索和排序、找出最相关最有价值的内容传给大模型的内容去生成，对于生成的结果再去审查和完善。另外要用好的模型。

#RAG #时事新闻 #分析报告 #AI方案 #问题解决 #数据量

宝玉

3个月前

问：什么是 RAG？ RAG（检索增强生成，Retrieval-Augmented Generation）是一种结合了信息检索和生成式人工智能的技术。通俗地讲，它先通过检索，从数据库或互联网等外部知识源中找到与问题相关的内容，再利用生成模型（如GPT）基于这些内容生成答案。这种方式让模型不仅依靠训练时学习到的知识，还能实时获取最新信息，从而更准确地回答问题。举个简单的例子：假设你问AI：“2025年奥运会在哪里举办？”普通生成模型可能无法回答，因为训练数据仅截至2023年。但使用RAG技术，AI会先去检索最新的网络或知识库内容，确认“2025年奥运会将在巴黎举行”，然后再生成具体回答。这种技术让AI变得更可靠、更具实时性。 RAG的核心优势在于既能发挥生成模型灵活表达的能力，又能利用检索保证信息的准确性和时效性，适用于问答系统、客服机器人、知识助手等场景，是未来人工智能发展的重要方向之一。

#RAG #检索增强生成 #信息检索 #生成式人工智能 #GPT #生成模型 #外部知识源 #实时获取信息

Leo Xiang

3个月前

OpenAI 这套开发工具把Agent开发需要的基础能力都提供了，搜索、RAG、意图识别、内容审核、Computer use 以及 Browser use，整个Agent开发的成本瞬间降低了很多。预期可见的会出来一批Agent方向的产品。

#OpenAI #开发工具 #agent #搜索 #RAG #意图识别 #内容审核 #Computer use #Browser Use

宝玉

5个月前

DailyDoseofDS 这个图把传统 RAG 和 Agentic RAG 之间的差异分的比较清楚。传统 RAG 就是先把文档向量化保存到向量数据库，然后在用户查询时，对用户的问题也做向量化，从向量数据库中找到相关的文档，再把问题和找出来的结果交给 LLM 去总结生成。这种方式的优点就是简单，由于不需要太多次和 LLM 之间的交互，成本也相对低，但缺点是经常会因为做相似检索时，找不到合适的结果，而导致生成结果不理想。 Agentic RAG 则是在过程中引入 AI 智能体： - 先对用户的查询内容用智能体进行重写，比如修正拼写错误等 - 智能体判断是不是还需要额外的信息，比如可以去搜索引擎搜索，或者调用工具获取必要的信息 - 当 LLM 生成内容后，在返回给用户之前，让智能体去检查答案是不是和问题相关，是不是能解决用户的问题，如果不行，则返回第一步，修改查询内容，继续迭代，直到找到相关的内容，或者判断该问题无法回答，告知用户结果。当然这样做的缺点是成本要相对高一些，并且耗时会更长。

#RAG #Agentic RAG #向量数据库 #LLM #自然语言处理 #信息检索 #数据处理

biantaishabi

5个月前

给我的机器人加了几个工具：编辑文件，他需要编辑部分而不是每次都是全部更新整个文件；增加经验，（这个还需要一个搜索的，所以以后应该会把他每天批量移到一个向量数据库理让机器人搜索，以后动态构建系统提示词）；查文档的，这个项目比较简单让他读文件，还做了一个查rag的我的机器人laoded了

#机器人 #编辑文件 #经验积累 #向量数据库 #系统提示词 #文档查阅 #RAG