#RAG

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

1天前

RAG踩不完的坑，agent走不出三重门，Palantir学不会，企业AI落地怎么才能生根？

#RAG #agent #Palantir #企业AI落地 #技术挑战

岸田崇史 | Omluc

5天前

社内でDifyを浸透させるカギは、現場が日常的にアプリに触れることです。例えば、経理や総務に届く「これ経費で落ちますか？」という質問を、社内規定を元にAIが一次判断し、難しい場合だけTeamsで担当者に通知する。この仕組みを今回のワークフローではRAGとMCPで実現しています。小さな事例を通じてDifyに触れる機会が増えると、「この機能、他の業務にも使えるのでは？」と、現場は発想を広げやすくなります。まずは社員全員が関わる、ちょっと面倒な業務を1つ選び、それをどんな機能で解決できるのか？を棚卸してみましょう。保存して、お盆明けに試してみてください！

#Dify #RAG #MCP #AI #経費

5天前

一些企业描述为知识库的需求，实际上是没有办法通过当前的 RAG 来满足的，更像是一个本地的 Deepresearch 或者其他的 agent 可以 cover 的场景。不要被带到坑里。

#知识库 #RAG #DeepResearch #agent #本地

karminski-牙医

1周前

GPT-5 召回的确牛逼，所以接 RAG 目前应该是最佳选择。 Fiction.LiveBench 测试数据，192K上下文仍然有 87.5%, 妥妥 SOTA 了. 奥特曼其实应该把这个数据拿出来炫的，从o3开始其实 OpenAI 系列模型的召回能力都是可圈可点的。 #GPT5

OpenAI新德里发布会：ChatGPT语音翻译功能引发热议· 327 条信息

#GPT-5 #RAG #OpenAI #奥特曼 #SOTA

土猛的员外

1周前

很多人都认为AI知识库就是RAG，其实RAG是知识应用中的重要一环，但远不是全部。除了知识应用，还有知识构建和知识运营。今天写的一篇文章：

#AI知识库 #RAG #知识应用 #知识构建 #知识运营

1周前

RAG就是搜索，Agent就是For循环

#RAG #搜索 #agent #For循环

2周前

《How to Fix Your Context》这篇上下文工程指南，建议跟 Manus 六大上下文工程法则一起看，它们分别来自两个方向：一个是跑在工程一线踩过坑的 Agent 系统实践者，一个是站在系统架构角度思考 LLM 工作方式的认知构建者。我把这两篇文章有一起读了一篇，有种“内功交叉灌顶”的感觉。作者回顾了长上下文为什么会失败？ 1️⃣ 上下文污染：当幻觉或其他错误进入上下文，并被反复引用时。 2️⃣ 上下文干扰：当上下文变得过长，以至于模型过度关注上下文，忽视了训练期间学到的内容。 3️⃣ 上下文混淆：当上下文中的多余信息被模型用来生成低质量的响应时。 4️⃣ 语境冲突：当你在语境中积累了与提示中的其他信息相冲突的新信息和工具时。回忆下是不是都是自己遇到的问题，作者给了一些解决的思路，有很多跟 manus 惊人的一致。 1️⃣ RAG：有选择地添加相关信息以帮助 LLM 生成更好的响应统一下认知，信息添加的底层逻辑一定不是查到了，而是查对了。作者强调 RAG 要有选择性的添加，而不是全部贴上；重点是围绕当前任务构建语义增强。 Manus 的做法是干脆放弃查入，把信息挂载在文件系统，留 path + 摘要 + 可调用工具。能明显感觉到 manus 对 token 成本的极致敏感🤭。我自己的实践中最常见的失败是，RAG 查得很准，但 LLM 输出完全无感，因为 context 本身没告诉它该往这个方向推理。RAG 本质是建模信息在认知链条中的地位，不重要的别查入，重要的也别硬塞，要设计成“知道在哪 + 能够调”。这跟这两篇文章的底层逻辑就高度一致，真正高质量的 RAG，不在检索，在策略。 2️⃣ 工具配置：仅选择相关的工具定义添加到您的上下文中作者提倡按需加载工具定义，而 Manus 的哲学是工具全集保持不变，用 mask 控制直接把权重干成负数。相比而言 Manus 的做法太巧妙了，可以说是对大模型底层原理应用的最佳实践了。如果你踩过“工具定义变了导致 cache miss + hallucination 增多”的坑，一定能彻底折服。但这两种方式解决的问题都高度一致，无非是你是靠 prompt 配置行为，还是靠 logits 控制行为？我理解只要你希望上下文命中率高、模型行为稳定，就必须构建一个“行为可变但结构不变”的系统。至于选择哪种，重点都在让模型以为它有哪些选择。 3️⃣ 上下文隔离：将上下文隔离在各自专用的线程中作者讲上下文隔离是为避免多任务混淆。Manus 虽然没有“线程”的抽象，但通过 append-only 的 context + 每轮状态复述 + 工具调用封装，其实完成了逻辑线程的构建。失败的上下文不要强行修复，而是重新创建一个上下文分支，把之前的 trace 作为引用历史保存下来。这点在实际开发中很关键，很多工程实践中都会出现“污染后还想继续用旧 context”的习惯，反而越补越乱。我现在更倾向于一旦感知幻觉或目标漂移，就把当前上下文 snapshot 掉，开一个 fresh context thread，哪怕代价是多一次调用，也比把幻觉当真实继续往前错更稳定。 4️⃣ 上下文修剪：从上下文中移除不相关或不需要的信息很多人以为修剪就是删“旧内容”，其实真正的 pruning，是删除“结构上已经失效的信息”。他们的“能 offload 的就 offload，不能 offload 的就摘要”。我也一度以为摘要是浪费时间，但后来发现一段带摘要的 context，远比一堆片段更有推理价值。尤其是在长任务执行中，摘要除了压缩信息，更多的是给大模型构造构造注意力锚点。我现在会把某些任务 summary 放在末尾，一方面压缩 token，另一方面也是引导模型聚焦。顺带一提，很多人会选择把失败信息也修剪掉，但其实保留失败的 trace 本身也是一种重要策略。Manus 的做法是把失败信息 offload 到外部 trace 文件中（参考6️⃣），再在后续回顾或 summary 阶段引用。这跟人学习有点像，错误是成本最大的训练材料，不应该被直接忘掉。补充个方法论：上下文修剪，千万不要认为目的是“省空间”，核心是要让每个 token 都承担“策略密度”。我们最终修建掉的是模型注意力的错位。 5️⃣ 上下文总结：将累积的上下文浓缩成一个简要的总结作者强调总结是为了更高效的行为生成。Manus 做得更极致，每一轮都复述当前目标 + 状态 + 期望动作，用自然语言重新激活注意力焦点。我实测过不复述 vs 复述的差别：前者行为漂移率接近 30%，后者几乎稳定在主任务路径上。你能感受到的是 LLM 的注意力其实是个滑动窗口，不持续提醒，很容易跑偏，这一点就跟我们管理一个想法很多的员工一个道理。说白了，总结不是让模型记住，而是让他去遗忘，终极目的是要做注意力的再分配。 6️⃣ 上下文卸载：将信息存储在 LLM 的上下文之外，通常通过一个存储和管理数据的工具来实现这一部分我必须单独点个赞，确实简单有力量，很多人不以为然：就把信息放到外面嘛，有什么大不了的？但真正在 Agent 系统里跑起来你才会发现：Context Offloading 是少数能从认知层面、工程层面、可扩展性层面都闭环的设计策略。作者在文中提到 Anthropic 的 “think” 工具，他们干的事儿就很朴素：给 Claude 搞了一个专用 scratchpad，让它在正式输出前可以先写一写、想一想。我们过去总觉得 scratchpad 是辅助产出，但 Anthropic 的设计更像是，让 Claude 在回答前自己反刍一下。 Manus 给出的做法本质也是一样的，只不过它没有叫 scratchpad，而是把这套行为模块化写进 agent 文件系统，每一个都是模型在任务过程中产生的“中间态”，不属于主 memory，但又比 response 更结构化。我们太容易陷入一个错觉，以为上下文是一个扔进去的信息堆，但其实真正有用的信息往往是过程中的状态，而不是最终的答案。但是这些状态恰恰是最不适合塞在主上下文里的，既容易冲淡主任务注意力，又会拖垮 token 成本。实际上验证下来，给 Agent 留出一块临时记忆区，效果极其稳定，特别是在多步骤长任务里，模型不担不会迷失，反而行为会越来越收敛。作者说得对，这东西简单到你不相信它有用。也许未来大模型的长记忆系统，真正的突破口不是在上下文窗口扩到多少 M，而是什么该存在主线程里，什么该写在 scratch 区。简单总结下：从“怎么放信息”到“怎么设计上下文作为系统运行时” 加上最近对 vibe coding 的观察和体验，我现在越来越确信：未来 AI 系统真正的代码，一定是你写给模型的上下文构建逻辑。这两篇文章，建议放进上下文工程必读清单。搞懂它们，搞 Agent 才算入门。

#上下文工程 #LLM #RAG #Agent系统 #上下文管理

2周前

最近一个月在学习Cherry Studio的源码，了解了RAG、Websearch、MCP等功能是怎么实现的，写了下面这篇关于联网搜索的使用教程，尽量兼顾可读性和实用性，避免正文中出现大片的代码。使用第三方联网搜索功能会导致 1.token消耗增加 2.偶发搜索失败更多内容点击👇查阅

#Cherry Studio #RAG #WebSearch #MCP #联网搜索教程

𝗖𝘆𝗱𝗶𝗮𝗿

2周前

我用实际举例，AI 这个赛道有多快吧！因为，Juchats 进入这个赛道非常早，以至于很多技术架构，直接影响到了她的发展方向！在这期间，还经过了一次架构升级、优化后端架构、优化前端架构、重构前端各类组件、重构各种细节！大家最近都在说上下文工程，这些其实一直都在优化中。而且，数据结构这个事情，对于整个产品结构影响太大了。无论是展示、细节、还是交互！同时我们沉淀了很多！一套完整的网关系统，用于支撑 Juchats 所有模型的调度、健康、甚至复刻到其他项目！一套 RAG / Agentic RAG / Distributed RAG 不断的演变！下个阶段可能会沉淀更多东西，继续努力！这个赛道就是这样，还是那句话：“不要下车，也不要瞎扯，容易上不来，也容易蛋碎！”

#AI #Juchats #技术架构 #RAG #上下文工程

3周前

推荐下好友 Evan 的 RAG 专栏： 1/ 体系化的 RAG 知识框架，一本通全流程和关键技术； 2/ 从 0 到 1 真实知识库项目实操 3/ 定期剖析 RAG 最新论文 Evan 是 LLM + 信息检索方向的博士，他经常活跃我群，组织大家打各种 AI 竞赛。所以兄弟们，下方扫码，滴滴

#RAG #LLM #知识库 #信息检索 #AI竞赛

Jesse Lau 遁一子

3周前

看没啥知名度的武侠小说感觉像看context window不够R A G也没做好的A I写作高手突然蹦出来，然后突然又没了

#武侠小说 #AI写作 #context window #RAG #高手

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

1个月前

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

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

1个月前

—— [转发]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 #网络攻击

2个月前

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

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

2个月前

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

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

2个月前

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

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

岸田崇史 | Omluc

2个月前

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

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

2个月前

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

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

2个月前

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

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

2个月前

#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 #阿里云 #开发者 #技术

2个月前

#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 #淘宝 #技术

3个月前

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

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

3个月前

关于 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 🇸🇪

3个月前

「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 #工具使用 #创新框架