#RAG

1周前

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

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

土猛的员外

1周前

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

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

2周前

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

4周前

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

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

1个月前

#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 #大模型幻觉

1个月前

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

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

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

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

1个月前

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

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

岸田崇史 | Omluc

1个月前

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

#Dify #RAG #MCP #AI #経費

1个月前

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

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

karminski-牙医

1个月前

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

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

#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 #上下文工程

2个月前

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

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

Jesse Lau 遁一子

2个月前

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

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

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

3个月前

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

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

3个月前

—— [转发]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项目 #技术部署 #系统集成 #数据价值

3个月前

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

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

3个月前

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崛起· 898 条信息

#RAG #实时搜索 #代码理解 #技术对比 #性能

3个月前

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

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

3个月前

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

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