#RAG

辛宝Otto-Web Worker Podcast

1个月前

node.js ai sdk ，在后续发布的 v6 中会增加 rerank 的相关方法，在此之前，做 rag 的 rerank 时候需要用普通的对话模型，或者使用 api 来封装

#Node.js #AI SDK #rerank #RAG #v6

1个月前

Google 在 Gemini 生态里直接宣判了 RAG 的死刑。这个 File Search 一句话就能概括： Google 把 RAG 从工程领域直接删掉了。以前做 RAG 是一整条流水线：切 chunk → embedding → 向量库 → 检索策略 → 引用链路 → 缓存优化 → prompt 拼装。现在 Gemini 的 File Search 非常简单，把PDF/JSON/代码/Markdown 扔进一个 store，然后问问题。剩下全部交给模型。不需要理解 RAG，也不需要设计 RAG，甚至不需要知道 RAG 曾经长什么样。就这么简单，整个 RAG 技术链路的所有复杂度不可逆地被压到平台底层。 AI 应用的门槛又被 Google 掐了一次脖子。我也没想到有一天模型厂商竟然用这种方式吞掉了技术。

谷歌Deep Research：AI操作系统雏形？· 145 条信息

#Google #Gemini #RAG #File Search #AI应用

1个月前

小红书卖知识库的硬性标准是：保证你的顾客从未听说过什么是 RAG 这就好比肯德基的大部分顾客都不养鸡，一个道理

#小红书 #知识库 #RAG #肯德基 #顾客

karminski-牙医

2个月前

刷到了个25K Star 的 Claude 编程指南！内容包括使用Claude做 RAG，抽摘要，如何使用工具，做客服代理，与向量数据库集成，多模态（图像和图表解读，抽取最佳实践），以及更高级的子代理（用Opus调用Haiku）等等。地址：

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

#Claude #编程指南 #RAG #多模态 #子代理

2个月前

claude code 中的 agentic grep 用下来效果比一般的rag要好很多，业界有比较通用的agentic search 或者 agentic rag 的实现么？

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

#agentic grep #RAG #Agentic Search #Agentic RAG #Claude Code

2个月前

google 的 ai summary，竟然是 RAG。这是我没想到的。没这么想过。🤣 正在学的RAG课，每天一课，五天学完。我知道RAG很基础，ai圈说了两年说烂了。但我就是觉得基础的老生常谈的东西也得了解更多细节更多原理。反正不要钱，每天听一点试试呗

谷歌Deep Research：AI操作系统雏形？· 145 条信息

#RAG #Google AI #AI Summary #技术学习 #免费课程

2个月前

周末折腾RAG，怎么做好像效果都不太好。下午发现CloudFlare 也有自己的RAG方案，而且打包成产品叫Auto RAG 。貌似效果还不错。

#RAG #CloudFlare #Auto RAG #效果不佳 #周末

2个月前

之前看到 AK 对人类学习和记忆的推还不是特别理解。我们现在很多关于记忆的项目，就是用 RAG 胡乱召回，既不管场景也不是那么相关。而在最近高强度使用 Claude Code 的 md 文件上下文，加上 Skills 的发布，我觉得一个好的记忆系统越来越清晰了。相比个人偏好个人生活的记忆，解决问题的认知和策略的记忆，更有价值一些。 AK 的之前说的内容：许多人类的学习过程更像是一种系统提示的变化。当你遇到一个问题时，经过一番思考后得出某种结论，然后以相当明确的方式“记住”下来，以便下次使用。例如：“看来当我遇到这种和那种问题时，我应该尝试这种和那种方法或解决方案。” 这种感觉更像是给自己做笔记，类似于“记忆”功能，但不是用来存储与用户个人相关的随机事实，而是用于保存通用的、全局的问题解决知识和策略。从某种意义上说，大语言模型就像电影《记忆碎片》里的那个主人公，只不过我们还没有给它们配备自己的备忘录而已。

Claude Skills系统发布引发AI行业新变革· 66 条信息

#AK #RAG #Claude Code #记忆系统 #问题解决

2个月前

RAG已死？RAG已死的说法最近看到不少，很多是受Claude Code用grep的影响。问题是，grep就是一种信息检索手段啊，有grep就是RAG，只有那种每次把整个库都丢进去的不是RAG。另外，grep只是一种信息检索手段，只用grep做RAG目前还没有看到在非代码场景的成功案例，现在就断言以后用grep就行，我觉得应该都是没做过RAG。然后，很多人觉得向量化要切片，就觉得喂给LLM的就只是片段，不是全文。这都哪跟哪，命中切片之后难道不能把全文喂进去吗。要这么说，grep还命中的是一行呢，难道就喂一行。这些都是似是而非的说法。

#RAG #信息检索 #grep #LLM #技术讨论

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

2个月前

LLM客户端并无真正的“长期记忆”，而是通过“结构化存储 + 动态重构prompt”的方式模拟记忆。长会话上下文的核心任务在于取舍与压缩： •哪些历史内容保留？ •哪些内容通过摘要或检索再现？ •如何让prompt在token限制下仍保持语义连续？设计RAG，agent多轮对话，或者多agent与LLM交互，也要过类似LLM客户端上下文管理这一关！否则就是RAG猜，agent演，然后老板会说，就这？项目就黄了。

#多智能体之争：Anthropic生态VS单智能体· 81 条信息

#LLM客户端 #长期记忆 #结构化存储 #动态重构prompt #RAG #agent多轮对话 #上下文管理 #项目失败

3个月前

🚀Difyの新バージョン「ナレッジパイプライン」（Knowledge Pipeline）をリリースしました！主なアップデート内容： 🔹視覚的オーケストレーション：RAG全体のフローをキャンバス上で直感的に設計可能。オープンかつ柔軟なアーキテクチャを採用。 🔹ユニバーサルコネクタ：Notion、Google Drive、S3、Firecrawl対応。独自コネクタもプラグインで開発可能。 🔹プラガブルコンポーネント：ケースに応じて最適なパーサー・チャンク・エンベディングを選択可能。 🔹デバッグの可視化：パイプライン内で問題が発生した箇所を明確に確認、各ステップを詳細に検証可能。 🔹プロダクションテンプレート：実績あるパターンをすぐに利用開始、自作のフローの共有も可能。データ連携や複雑フォーマット処理、RAGデバッグの課題を一括解決する新体験を提供します。

#Dify #ナレッジパイプライン #RAG #データ連携 #視覚的オーケストレーション

土猛的员外

3个月前

周末两天看了好多AI Agents的案例，感觉我们前面扎根做知识库+RAG也算是一种正确的选择，特别是在toB场景中。

#AI Agents #知识库 #RAG #toB场景 #积极

3个月前

TestBrain：AI测试智能体从PRD直接生成标准格式化的测试用例，使用了RAG减少幻觉。通过维护企业的知识库，包括需求文档、设计文档、接口文档、过往具有参考价值的老用例、UI设计图等内容，可以生成更符合实际需求的测试用例。支持从metersphers接口定义文档，智能生成接口测试用例，后续还会支持apifox等。 Github：

#AI测试智能体 #TestBrain #RAG #测试用例生成 #知识库

3个月前

对比下两种不同的说法： 1）书，在未来会成为“embedding化的智能副本” 2）“把这本书RAG一下” 更具体一点，多说一句话来解释：把一本书的文本切块，处理成高维向量（embedding）后放进向量数据库（vector DB）；读者可以直接对书（的embedding）提问，用相似度算法把最相关段落检索出来，然后llm基于这本书的内容来回答读者问题。简称为“RAG”。

#Embedding #RAG #向量数据库 #LLM #文本处理

せんにゅう| アプリ開発

3个月前

Difyで高性能チャットボットを作成しました👍 自社HPに設置可能なクオリティ🔥 『ジャンル選択→RAGでナレッジ参照』会話変数の使い方、高度なIF/ELSEの使い方、HTMLでボタンを作成する方法など参考になると思います！フォロー&リプ「チャットボット」でDSLファイルをプレゼント🎁✨

#Dify #チャットボット #RAG #DSLファイル #HP

3个月前

抽空可以跑跑学习下，该仓库系统性地收集了多种LLM的应用案例，覆盖从入门到高级的AI代理、RAG、工作流等范畴，既有面向新手的快速上手代理，也有复杂的端到端流程与多Agent协作范例。

#LLM应用 #AI代理 #RAG #工作流 #多Agent协作

4个月前

#BestBlogs 基于 Elasticsearch 创建企业 AI 搜索应用实践 | InfoQ 中文文章基于 QCon 演讲实录，深入探讨了在智能时代，如何利用 Elasticsearch 构建企业级 AI 搜索应用，尤其强调通过结合大模型和 Elasticsearch 的技术，有效规避大模型幻觉。文章首先阐述了语义搜索的需求及传统搜索的局限，引出向量搜索的必要性。接着，详细介绍了 Elasticsearch 对密集向量和稀疏向量的支持、其向量搜索架构、操作步骤及混合搜索（RRF）机制。文章还重点讲解了 Elasticsearch 在性能优化（如量化技术、GPU 加速、并发查询）和未来 Serverless 架构上的创新。最后，通过 RAG、Agentic RAG 和 HyDE 等方法，结合 Elasticsearch 的多路召回能力，展示了如何实现更精准、高效的企业搜索实践。主要内容: 1. 结合传统与向量搜索的混合搜索能显著提升 AI 搜索精度 -- 传统关键词搜索与语义向量搜索各有优劣，通过 RRF 等机制融合两者的优势，可有效提高召回率和搜索结果的精准度。 2. Elasticsearch 通过多项技术创新支持高效、可扩展的 AI 搜索 -- 文章介绍了 Elasticsearch 在密集/稀疏向量、量化、GPU 加速、Serverless 架构等方面的进展，为大规模 AI 搜索提供了坚实基础。 3. RAG 结合 Elasticsearch 可有效解决大模型幻觉问题并优化企业搜索 -- 利用 Elasticsearch 作为外部知识库，通过多路召回、Agentic RAG 和 HyDE 等策略，为 LLM 提供实时、准确的上下文，规避幻觉，提升企业搜索实用性。文章链接：

#Elasticsearch #AI搜索 #向量搜索 #RAG #大模型幻觉

4个月前

llm 搜索和 RAG 确实像摄像头 vs 激光雷达之争 “设计精妙的搜索系统” 不如 “尽可能把接口和系统暴露给大模型”，后者更符合第一性原理，只是更费 token，也更依赖于模型的智能程度

谷歌Deep Research：AI操作系统雏形？· 145 条信息

#LLM #搜索系统 #RAG #摄像头 #激光雷达

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

4个月前

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

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

岸田崇史 | Omluc

4个月前

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

#Dify #RAG #MCP #AI #経費

4个月前

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

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

karminski-牙医

4个月前

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

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

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

土猛的员外

4个月前

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

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

4个月前

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

#RAG #搜索 #agent #For循环

4个月前

《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系统 #上下文管理