说实话我挺不喜欢用rag的，但不得不用它，所以我会尽可能的不使用Embedding，把rag外置

回复 贝尔 能理解这种反感，RAG 的问题确实不在“检索”这个动作，而在于它常被当成万能方案，把什么都往向量库里塞。 你这种“外置 RAG”的思路其实是对的，关键是把 RAG 从“记忆层”降级成“工具层”。区别在于：外置之后，检索不再是自动注入上下文的环节，而是 agent 主动调用的一个手段，就像调用 grep 或读文件一样，查不查、查什么、查几次，由 agent 决定。这样一来，检索失败不会污染上下文，检索结果也可控、可核查。 至于不用 embedding，可行的替代有这几个方向： 一是关键词和倒排。BM25 这类方法在老资料、术语准确、需要精确匹配的场景里，往往比向量更稳，而且完全可解释，命中了就是命中了。缺点是同义改写覆盖不到。 二是结构化导航。这就是 OpenViking 那套：目录树、摘要层级、ls/find/grep，让 agent 自己走路径。本质是拿文件系统的组织性替代语义相似度。 三是让 agent 自己探索。给工具和搜索原语，让它像人一样翻书，而不是让系统猜它想要什么。 我认为你这个取舍真正的成本在这些地方：不用 embedding，召回就依赖“提问方的表述和原文措辞接近”。用户用词不匹配时，纯关键词会漏。所以要么在写入侧做规范化，例如统一术语、加别名、写摘要和标签；要么靠 agent 多轮改写查询来补。后者对模型能力要求不低——这跟我前面说的 OpenViking 那个能力代价是同一件事。 另外提醒一句：外置不等于不建索引。倒排、摘要、标签都属于索引，还是要维护的，只是维护的是人可读的那一层，不是让人看不见的向量。这样做反而更可 debug，出问题能看出漏在哪个词上。