我的征尘是星辰大海。。。
The dirt and dust from my pilgrimage forms oceans of stars...
-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆
作者:黄教授
手机视频列表
从RAG谜思到Agent觉醒
视频
音频
原始脚本
从 Rag 迷思到 Agent 觉醒，为何顶尖团队弃用向量数据库？当 Rag 检索增强生成技术被捧为解决大模型幻觉的终极方案时，AI 领域顶尖团队的转向却敲响了警钟。 Anthropic 的 claude code 团队，在代码理解领域备受推崇的顶尖力量。 正放弃复杂的向量数据库，转而采用纯文本索引加命令行工具的极简方案。 这种看似倒退的选择，实则揭开了 RAG 技术的深层困境，也印证了无数实践者的切身体验。 一、顶尖团队的复古解法，Agent 主导的检索革命。 Anthropic 团队的核心思路是回归问题本质，让真正懂语义的大模型主导检索，而非依赖简化的向量系统。 这套方案的架构堪称大道至简，分为三个核心环节。 一、构建图书馆目录，纯文本索引替代向量库。 团队并未将文档拆分成碎片化向量，而是创建类似 langchain 的 LM 点 txt 纯文本文件，仅存储每份文档的高质量摘要与存储路径。 这些摘要如同图书馆的目录卡，精准概括文档核心内容却不丢失关键语义，且无需复杂的向量化转换。 二 配备工具包，复用程序员的原生工具，摒弃向量相似度计算，直接集成 grep、find 等命令行工具。 这些工具虽不具备语义理解的噱头，却能实现毫秒级精确检索。 无论是查找特定关键词、筛选包含某类信息的文档，还是排除无关内容，都能做到零误差执行。 三， Agent 全程操盘，复刻人类的检索逻辑。 将检索的决策权完全交给大模型 Agent 。 当接收用户问题后， Agent 先通过纯文本摘要快速定位潜在相关文档，类似人类查目录。 再调用命令行工具调取完整文档通读，若信息不足，则进一步用工具精准定位细节，直至获取足够信息。 Martin 的测试显示，在300万 token 规模，20个编程问题的场景中，该方案效果远超传统 RAG。 二， LAG 的三重困境，为何期待中的语义优势成了泡影？RAG 的核心承诺是通过向量匹配实现精准语义检索，但现实中却陷入事倍功半的泥潭。 结合技术原理与实践教训，其问题根源集中在三点。 一、语义理解的断层，缺失 QKV 的向量只是表面功夫。 大模型的语义理解能力源于 Transformer 架构的 QKV、查询、键值、注意力机制。 通过计算每个 token 与其他所有 token 的关联度，实现对上下文的深度解析。 比如中文里 你今天吃饭了与你今天吃饭了吗的差异，正是通过注意力机制捕捉语气词带来的语义变化。 但绝大多数 RAG 系统的向量生成，仅依赖独立的第三方嵌入模型，如 Sentence Bert，做简单的线性变换，完全跳过了 QKV 的核心计算。 这种向量只能捕捉文本的浅层特征，无法区分细微却关键的语义差别。 Google DeepMind 的研究更证实，向量嵌入在理论上存在先天局限性，即便优化模型，也无法完全解决语义表达不足的问题。 二，检索效率的陷阱，向量比对比想象中更笨重。 传统数据库的二分法检索能实现毫秒级响应，但向量检索却面临效率难题。 向量相似度需通过点乘计算夹角距离，最朴素的实现是全量比对，将查询向量与数据库中所有向量逐一计算，随数据量增长响应速度呈线性下讲。 即便采用 Meta 等公司的聚类算法，预先将向量分簇，用代表向量筛选，也只是缓解而非解决问题。 聚类后的向量仍围绕代表向量形成一个锥形面。 通俗解释锥形面，你可以把每个向量想象成指南针上的一根指针，指向某个特定方向。 向量相似度就是两根指针之间的夹角大小，夹角越小，相似度越高。 锥形面就像以查询向量为中心，画一个固定角度的圆锥，所有落在这个圆锥范围内的向量，都被认为是相似的。 但这些向量可能指向完全不同的具体方向，它们只是大体上和查询向量朝向一致。 这就导致大量相似度接近的候选结果，筛选时非常模糊。 聚类本身需额外计算成本，最终陷入效率没提升，精度还下降的困境。 某电商数据显示，向量检索延迟超过500毫秒时，23%的用户会直接放弃查询。 三、实践中的误区，将相似度等同于语义相关。 一个普遍的误解是向量相似度高就等同于语义相关，但事实并非如此。 例如，你今天吃饭了和你今天吃饭了吗，只差一个语气词。 从向量相似度看，它们非常接近。 但从语义上看，一个是陈述句，一个是疑问句，意思完全不同。 这种细微差别只有经过 QKV 机制的深度语义建模才能捕捉，简单的向量相似度计算根本无法区分。 这使得 RADA 的检索结果常常看似相关，实则不然。 三、为何简单方法反而更有效？Anthropic 团队的转向并非否定外部知识增强的价值，而是纠正了技术路线的偏差，语义理解的核心在大模型本身，而非外部向量系统。 传统工具如 Grab 的优势在于精准高效，大模型的优势在于语义决策。 将二者结合的 Agantic Retrieval 模式恰恰避开了 RAG 的短板。 这种模式的核心是用摘要做导航，用工具做检索，让大模型做决策。 这种方法之所以高效，是因为它让专业的组件做专业的事。 而 RAG 的问题在于，它试图让向量系统同时承担这两个角色，但两个角色它都做不好。 四、回归本质，检索的核心是找得准而非技术性。 Rock 并非一无是处，在特定场景下仍有价值。 但它的语义优势需要建立在与大模型原生能力对齐的基础上。 而对于多数中小规模、高精准需求的场景，或许像 Anthropic 团队那样，让 Agent 带着 Grab 查目录才是更聪明的选择。 技术选型不应迷信概念热度，而应回归问题本质。 当简单工具能解决问题时，无需为复杂技术支付额外成本。 当需要语义理解时，应信任大模型的原生能力，而非简化的替代方案。
修正脚本
从 Rag 迷思到 Agent 觉醒，为何顶尖团队弃用向量数据库？当 Rag 检索增强生成技术被捧为解决大模型幻觉的终极方案时，AI 领域顶尖团队的转向却敲响了警钟。 Anthropic 的 claude code 团队，在代码理解领域备受推崇的顶尖力量。 正放弃复杂的向量数据库，转而采用纯文本索引加命令行工具的极简方案。 这种看似倒退的选择，实则揭开了 RAG 技术的深层困境，也印证了无数实践者的切身体验。 一、顶尖团队的复古解法，Agent 主导的检索革命。 Anthropic 团队的核心思路是回归问题本质，让真正懂语义的大模型主导检索，而非依赖简化的向量系统。 这套方案的架构堪称大道至简，分为三个核心环节。 一、构建图书馆目录，纯文本索引替代向量库。 团队并未将文档拆分成碎片化向量，而是创建类似 langchain 的 LM.txt 纯文本文件，仅存储每份文档的高质量摘要与存储路径。 这些摘要如同图书馆的目录卡，精准概括文档核心内容却不丢失关键语义，且无需复杂的向量化转换。 二、配备工具包，复用程序员的原生工具，摒弃向量相似度计算，直接集成 grep、find 等命令行工具。 这些工具虽不具备语义理解的噱头，却能实现毫秒级精确检索。 无论是查找特定关键词、筛选包含某类信息的文档，还是排除无关内容，都能做到零误差执行。 三、Agent 全程操盘，复刻人类的检索逻辑。 将检索的决策权完全交给大模型 Agent 。 当接收用户问题后，Agent 先通过纯文本摘要快速定位潜在相关文档，类似人类查目录。 再调用命令行工具调取完整文档通读，若信息不足，则进一步用工具精准定位细节，直至获取足够信息。 Martin 的测试显示，在300万 token 规模，20个编程问题的场景中，该方案效果远超传统 RAG。 二、RAG 的三重困境，为何期待中的语义优势成了泡影？RAG 的核心承诺是通过向量匹配实现精准语义检索，但现实中却陷入事倍功半的泥潭。 结合技术原理与实践教训，其问题根源集中在三点。 一、语义理解的断层，缺失 QKV 的向量只是表面功夫。 大模型的语义理解能力源于 Transformer 架构的 QKV、查询、键值、注意力机制。 通过计算每个 token 与其他所有 token 的关联度，实现对上下文的深度解析。 比如中文里“你今天吃饭了”与“你今天吃饭了吗”的差异，正是通过注意力机制捕捉语气词带来的语义变化。 但绝大多数 RAG 系统的向量生成，仅依赖独立的第三方嵌入模型，如 Sentence Bert，做简单的线性变换，完全跳过了 QKV 的核心计算。 这种向量只能捕捉文本的浅层特征，无法区分细微却关键的语义差别。 Google DeepMind 的研究更证实，向量嵌入在理论上存在先天局限性，即便优化模型，也无法完全解决语义表达不足的问题。 二、检索效率的陷阱，向量比对比想象中更笨重。 传统数据库的二分法检索能实现毫秒级响应，但向量检索却面临效率难题。 向量相似度需通过点乘计算夹角距离，最朴素的实现是全量比对，将查询向量与数据库中所有向量逐一计算，随数据量增长响应速度呈线性下降。 即便采用 Meta 等公司的聚类算法，预先将向量分簇，用代表向量筛选，也只是缓解而非解决问题。 聚类后的向量仍围绕代表向量形成一个锥形面。 通俗解释锥形面，你可以把每个向量想象成指南针上的一根指针，指向某个特定方向。 向量相似度就是两根指针之间的夹角大小，夹角越小，相似度越高。 锥形面就像以查询向量为中心，画一个固定角度的圆锥，所有落在这个圆锥范围内的向量，都被认为是相似的。 但这些向量可能指向完全不同的具体方向，它们只是大体上和查询向量朝向一致。 这就导致大量相似度接近的候选结果，筛选时非常模糊。 聚类本身需额外计算成本，最终陷入效率没提升，精度还下降的困境。 某电商数据显示，向量检索延迟超过500毫秒时，23%的用户会直接放弃查询。 三、实践中的误区，将相似度等同于语义相关。 一个普遍的误解是向量相似度高就等同于语义相关，但事实并非如此。 例如，“你今天吃饭了”和“你今天吃饭了吗”，只差一个语气词。 从向量相似度看，它们非常接近。 但从语义上看，一个是陈述句，一个是疑问句，意思完全不同。 这种细微差别只有经过 QKV 机制的深度语义建模才能捕捉，简单的向量相似度计算根本无法区分。 这使得 RAG 的检索结果常常看似相关，实则不然。 三、为何简单方法反而更有效？Anthropic 团队的转向并非否定外部知识增强的价值，而是纠正了技术路线的偏差，语义理解的核心在大模型本身，而非外部向量系统。 传统工具如 grep 的优势在于精准高效，大模型的优势在于语义决策。 将二者结合的 Agantic Retrieval 模式恰恰避开了 RAG 的短板。 这种模式的核心是用摘要做导航，用工具做检索，让大模型做决策。 这种方法之所以高效，是因为它让专业的组件做专业的事。 而 RAG 的问题在于，它试图让向量系统同时承担这两个角色，但两个角色它都做不好。 四、回归本质，检索的核心是找得准而非炫技。 RAG 并非一无是处，在特定场景下仍有价值。 但它的语义优势需要建立在与大模型原生能力对齐的基础上。 而对于多数中小规模、高精准需求的场景，或许像 Anthropic 团队那样，让 Agent 带着 grep 查目录才是更聪明的选择。 技术选型不应迷信概念热度，而应回归问题本质。 当简单工具能解决问题时，无需为复杂技术支付额外成本。 当需要语义理解时，应信任大模型的原生能力，而非简化的替代方案。
英文翻译
From RAG Myth to Agent Awakening: Why Are Top Teams Abandoning Vector Databases? When RAG (Retrieval-Augmented Generation) was hailed as the ultimate solution to large model hallucinations, a shift by top AI teams has sounded the alarm. Anthropic’s Claude Code team, a highly respected force in code comprehension, is abandoning complex vector databases in favor of a minimalist approach using plain-text indexes plus command-line tools. This seemingly regressive choice actually reveals the deep-seated troubles of RAG technology and echoes the real-world experiences of countless practitioners. 1. The Vintage Solution by Top Teams: Agent-Led Retrieval Revolution. The core idea of the Anthropic team is to return to the essence of the problem: let the large model, which truly understands semantics, take charge of retrieval, rather than relying on simplified vector systems. The architecture of this solution is elegantly simple, consisting of three core steps: 1. Build a library catalog: Use plain-text indexes instead of vector stores. Instead of fragmenting documents into vector chunks, the team creates plain-text files (similar to LangChain’s LM.txt) that only store high-quality summaries and file paths for each document. These summaries act like library catalog cards, accurately capturing the core content of documents without losing key semantics, and without requiring complex vectorization. 2. Equip with a toolkit: Reuse programmers’ native tools, abandon vector similarity calculations, and directly integrate command-line tools like grep and find. These tools may lack the hype of semantic understanding, but they achieve millisecond-level precise retrieval. Whether searching for specific keywords, filtering documents containing certain information, or excluding irrelevant content, they execute with zero error. 3. Let the Agent take full control: Replicate human retrieval logic. The retrieval decision-making is entirely handed over to the large model Agent. When a user question is received, the Agent first quickly locates potentially relevant documents via plain-text summaries (similar to a human checking a catalog). Then it calls command-line tools to retrieve the full document and read it. If information is insufficient, it further uses tools to pinpoint details until enough information is gathered. Martin’s tests showed that over a scale of 300 million tokens and 20 programming questions, this solution far outperformed traditional RAG. 2. The Triple Plight of RAG: Why Did the Expected Semantic Advantage Vanish? RAG’s core promise is to achieve precise semantic retrieval through vector matching, but in practice it falls into a quagmire of diminishing returns. Combining technical principles with practical lessons, the root problems lie in three areas: 1. Semantic understanding gap: Vectors without QKV are just superficial. The semantic understanding capability of large models comes from the QKV (Query, Key, Value) attention mechanism in the Transformer architecture. By computing the correlation of each token with every other token, it achieves deep contextual understanding. For example, the difference between “你今天吃饭了” (You had a meal today) and “你今天吃饭了吗” (Did you have a meal today?) is captured by the attention mechanism’s handling of modal particles. However, most RAG systems generate vectors using independent third-party embedding models (e.g., Sentence-BERT) with simple linear transformations, completely bypassing the core QKV computation. Such vectors can only capture shallow features of text and cannot distinguish subtle but critical semantic differences. Google DeepMind’s research further confirms that vector embeddings have inherent theoretical limitations, and even optimized models cannot fully resolve inadequate semantic representation. 2. Retrieval efficiency pitfalls: Vector comparisons are heavier than imagined. Traditional database binary search can achieve millisecond response times, but vector retrieval faces efficiency challenges. Vector similarity requires point-wise multiplication to compute angular distance; the simplest implementation is full comparison—calculating the query vector against every vector in the database one by one, with response time degrading linearly as data volume grows. Even using clustering algorithms from companies like Meta, which pre-cluster vectors and filter by representative vectors, only alleviates but does not solve the problem. After clustering, vectors still form a cone around the representative vector. In simple terms, imagine each vector as a needle on a compass pointing in a specific direction. Vector similarity is the angle between two needles: the smaller the angle, the more similar. A cone is like drawing a cone of fixed angle centered on the query vector; all vectors falling within this cone are considered similar. But these vectors may point in completely different concrete directions; they only roughly align with the query vector. This leads to many candidate results with similar similarity scores, making filtering very fuzzy. Clustering itself requires additional computational cost, ultimately leading to a situation where efficiency doesn’t improve and precision drops. E-commerce data shows that when vector retrieval latency exceeds 500 ms, 23% of users abandon the query. 3. Practical misunderstanding: Equating similarity with semantic relevance. A common misconception is that high vector similarity equals semantic relevance, but that’s not true. For example, “你今天吃饭了” and “你今天吃饭了吗” differ only by a modal particle. From a vector similarity perspective, they are very close. But semantically, one is a declarative sentence, the other an interrogative sentence, with completely different meanings. This subtle difference can only be captured by deep semantic modeling via the QKV mechanism; simple vector similarity computation cannot distinguish it at all. This means RAG retrieval results often appear relevant but actually are not. 3. Why Are Simple Methods More Effective? Anthropic’s shift does not negate the value of external knowledge augmentation, but corrects a technical deviation: the core of semantic understanding lies in the large model itself, not in an external vector system. Traditional tools like grep excel in precision and efficiency; large models excel in semantic decision-making. Combining the two in an “Agentic Retrieval” model precisely avoids RAG’s weaknesses. The core of this approach is: use summaries for navigation, use tools for retrieval, and let the large model make decisions. This method is efficient because it lets specialized components do what they do best. RAG’s problem is that it tries to make the vector system play both roles, but it fails at both. 4. Back to Basics: The Core of Retrieval Is Accuracy, Not Gimmicks. RAG is not entirely useless; it still has value in certain scenarios. But its semantic advantage depends on alignment with the large model’s native capabilities. For most small-to-medium-scale, high-precision scenarios, perhaps the smarter choice is to let the Agent take grep to the catalog, just like the Anthropic team. Technical selection should not be swayed by conceptual hype but should return to the essence of the problem. When simple tools solve the problem, there’s no need to pay extra for complex technology. When semantic understanding is needed, trust the large model’s native capabilities, not simplified substitutes.
back to top