<![CDATA[基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人.]]>忙乎了一周 , 终于 完工了.

首先 验证了 LLM Wiki（也被称为 RAG Wiki）可行性.
我基本没用chunk和Embedding,纯纯的本地Index搜索,找出相关性的文章.

这个必须感谢 Andrej Karpathy（OpenAI 联合创始人、前特斯拉 AI 总监）,提出的理论, 2026 年 4 月 3-4 日 , 他提出在 GitHub Gist 上发布了《llm -wiki .md》文档（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)

我可以说 RAG, 就是个垃圾, 可以扔到历史垃圾堆了. 很多公司,请了软件工程师,就是骗老板钱的.

首先传统的RAG,chunk分块 和Embedding向量化, 简直就是脱了裤子放屁.

痛点:

  1. 公司的很多文档,主要是不规范,很多pdf有幻影,还有很多ppt里面重复内容太多.
  2. 如果 把一些文档,切分成 不规范的分块, 再用向量 ,求相似性.

这就是垃圾堆找吃的, 你投入进去垃圾,他吐出来垃圾, 然后你说RAG 垃圾.
这不是RAG 垃圾, 你给他吃的是垃圾,他吐出来当然是垃圾.
你不管reranker ,怎么都是垃圾.

核心是老板和程序员,不感觉这是错的, 一直在 错误的技术路线上,舍命狂奔.

核心思路 必须 清洗数据, 把精饲料喂给 Wiki ,然后Index索引, 查找相关的知识.

这才是王道. 否则 吃了垃圾,发给LLM ,吐出来垃圾.

如果让我总结的话,我认为大家的技术都差不多. 核心是文档精准和提示词工程.

------ 2026年6月28日------
我更新了 chunk+ embedding 路线, 我也做了一个版本. 证实了 我的结论,单纯是向量化是不如索引的技术,目前我的样本是这样的.

https://lcz.me/topic/728/凌晨三点起床-忙乎一天-本地知识库rag的-chunk-embedding弄完了.

不服技术的,来贴上你的作品和代码. 别怼没完.

1a801191-c1e0-404c-a5c1-49e098527d53-image.jpeg

索引:
95b828e0-ffcb-4ed2-9a8d-35b37701f471-image.jpeg

LLM效果:
36d3a11c-6ec6-4014-887c-2c27a4c55783-image.jpeg

]]>https://lcz.me/topic/707/基于rag-wiki-理论-我做了一套本地知识库-用于客服机器人.RSS for NodeWed, 01 Jul 2026 08:03:39 GMTFri, 26 Jun 2026 09:19:04 GMT60<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Sat, 27 Jun 2026 06:04:38 GMT]]>哈哈, 英雄所见略同,

以后普通程序员,就是很廉价. 就是一般打字员的工资, 也就8k.

但是顶级资深程序员,就很贵, 核心就是判断力和经验.

]]>https://lcz.me/post/8479https://lcz.me/post/8479Sat, 27 Jun 2026 06:04:38 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Sat, 27 Jun 2026 03:47:53 GMT]]>技术从来都不是护城河，common sense才是，所有的问题的根源都来自common sense不common

]]>https://lcz.me/post/8469https://lcz.me/post/8469Sat, 27 Jun 2026 03:47:53 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Sat, 27 Jun 2026 00:47:56 GMT]]>@566656661 谢谢评价. 没事, 人总是成长的.

我有空也研究其他RAG的技术方向, 我这个比较难的 技术方向都研究明白了.

成熟的RAG技术,AI Coding的时候更容易.

真正的 RAG技术, 不是一种方向,而是混合方向. 在不同的领域.

]]>https://lcz.me/post/8446https://lcz.me/post/8446Sat, 27 Jun 2026 00:47:56 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 17:45:38 GMT]]>学习中。知识增长了些许。我主要还是对 这个技术了解太少。拜读。

]]>https://lcz.me/post/8429https://lcz.me/post/8429Fri, 26 Jun 2026 17:45:38 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 16:05:56 GMT]]>認同GIGO的概念, 如果沒理解錯的話提到應該就是Naive RAG在應對錯誤資訊的痛處: 大學生在開書考試帶錯書了 希望這個比喻沒錯

但不太認同一棍子打掉所有RAG, 先不說RAG有分很多類型, 這裏說幾個比較常見的: FLARE, DRAGIN, Adaptive, Probing

Naive RAG自己也有不同的變種來增加搜索準確率吧, RRR (Rewrite-Retrieve-Read) 跟 RRF (Reciprocal Rank Fusion), 上面kop大提到的語意搜尋應該就是RRF中的語意搜尋 (Semantic Search) + 關鍵字搜索 (Lexical Search, BM25)吧?

我在目前測量公司弄的就是RRR

Naive RAG永遠只適合在陳述事實的場合, 也就是媽媽是女人, 或者沒什麽人知道的冷知識

因爲之前在幫忙架構RAGFlow, 所以有跑去研究了一下幾個不同設計方向的RAG, 基本上也是針對著Naive RAG不同方面進行改進 (何時檢索, 如何查)

框架 思路 優勝點
FLARE 按需觸發 ＋ 預測性查詢：僅在低置信度 token 時檢索，以「預測下一句」構造查詢 避免長生成過程中的無效檢索
DRAGIN 全域智慧決策：RIND 綜合評估不確定性／語義／上下文影響；QFS 基於完整歷史自注意力權重構建查詢 打破靜態規則與窄上下文限制
Adaptive 難度分級路由：分類器預判複雜度，動態分配「免檢索／單次／多步迭代」策略 解決「一刀切」帶來的計算浪費
Probing 內省式知識評估：隱藏狀態探針直讀 LLM 內部認知，判斷「是否已知情」 消除冗餘檢索與知識覆蓋衝突

最近好像也出了個Skill RAG, 不過我還沒去看Paper所以也不知道設計思路是什麽, 只在Twitter上知道是關於失敗後如何修復

無意引戰, 單純抛磚引玉 + 避免一刀切XXX沒用這種説法
技術 + 設計思路是需要時間成熟, 慢慢進步的

要知道Naive RAG已經是2023年的產物了, 當時還單純叫RR, Retrieve-Read 突然覺得時間飛得有點快

]]>https://lcz.me/post/8422https://lcz.me/post/8422Fri, 26 Jun 2026 16:05:56 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 10:26:27 GMT]]>@mark

我其实对个人知识库(或者说个人知识图谱) 是非常感兴趣的. 但我没有什么开发能力.

所以期待大神能有更多地探索和分享. 👍 👍 👍

]]>https://lcz.me/post/8385https://lcz.me/post/8385Fri, 26 Jun 2026 10:26:27 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 10:24:38 GMT]]>@Tony-Wang 你说的我理解了. 我可以用 双路,一个是index+search ,一个是chunk+embedding.

我尝试下, 应该不难. 我想想 怎么接线.

但是我想提升,文档的输入的质量 和 提示词优化.

如果还不行,我尝试下双路, 我就怕,双路之后, 我自己都不知道哪里错了.

]]>https://lcz.me/post/8383https://lcz.me/post/8383Fri, 26 Jun 2026 10:24:38 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 10:17:25 GMT]]>我理解了，你这套系统已经做得很完善了。我觉得还可以继续往通用性方向拓展一些。 👍 👍 👍

比如，Rule 是人工配置的，还是 AI 也能够协助生成或维护？

再比如，语义相关性的处理。像 “美签”、“美国签证”、“美国学生签”、“美国工签” 这些词，我觉得 Embedding 这种语义检索会比较容易命中。而传统关键词搜索，可能还需要配置同义词规则，或者结合一些语义相关性的搜索策略。

另外, 就是整篇文档召回, 我觉得会有浪费显存的状况.

我个人还是觉得，不同的检索方式各有优缺点，最终更可能还是一种混合策略。

]]>https://lcz.me/post/8381https://lcz.me/post/8381Fri, 26 Jun 2026 10:17:25 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 10:10:40 GMT]]>这个RAG ,就不是 一次性成型的. 我尝试过.
每一套知识库,必须配置 一套评估规则.
只有当知识密度够我的阈值,才能出来,否则再召回.

以下是我为 wms 配置的评估规则:

运行时评估

  • Supported：true
  • Rule：WMS 生成评估规则 v1
  • Passed：true
  • Score：7
  • Answer OK：true
  • Answer Terms OK：true
  • Source Count OK：true
  • Citation OK：true
  • Grounded OK：true
  • Actual Sources：5
  • Citation Count：1
  • Required Terms：盘点, 库存, 差异
  • Hit Terms：盘点
  • Missing Source Titles：(none)
  • Forbidden Terms：(none)
]]>https://lcz.me/post/8380https://lcz.me/post/8380Fri, 26 Jun 2026 10:10:40 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 10:33:37 GMT]]>@Tony-Wang - 主要技术栈:

  • 词法索引
  • BM25 召回
  • 规则型 reranker 重排
  • 组装答案
]]>https://lcz.me/post/8379https://lcz.me/post/8379Fri, 26 Jun 2026 10:33:37 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 10:02:51 GMT]]>@Tony-Wang 语义检索我认为是目前最明确的正向收益。

]]>https://lcz.me/post/8378https://lcz.me/post/8378Fri, 26 Jun 2026 10:02:51 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 10:01:45 GMT]]>这个吧. 主要是不懂的小白太多,是他们水平不行,不会提问. 总想着Hermes能解决一切.
其实就是自己水平不行. 不懂提问,不懂校验.

就给他一个挖掘机, 让一个不懂的人来开,肯定开到路沟里面.

然后,吐了口唾沫,丢下一句话:这挖掘机真难开.

你怎么不说你水平不行,越是能力差的,自尊心越强.

]]>https://lcz.me/post/8377https://lcz.me/post/8377Fri, 26 Jun 2026 10:01:45 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 10:04:28 GMT]]>

吃了垃圾,发给LLM ,吐出来垃圾.

这句话极其赞同. 但整个结论我不能完全同意.

我现在也在用LLM Wiki, 配合我的Obsidian一起工作, 效果非常好. 但是前提是我一样要给它高质量的内容. 而且它比较适合做专题的分析.

我不知道你具体用什么方法做索引, 好像是BM25 + composite(?)+ quality rank. 除了关键词, 向量检索肯定也是搜索相关内容的很好的方法. 用多种方法混合做检索, 效果应该更好. 比如我搜索 "车险" , BM25很可能不能命中 "车辆保险", "机动车保险" ..., 而向量检索应该更容易命中这种语义相近的内容.

我的Obsidian里面有5500篇笔记, 大部分是 .md, 还有相当一部分 pdf, ppt, word, 少量图片. 这些内容如果全部放在 LLM wiki 里, 上下文是撑不住的.

还有一种情况, 我这里没有, 但是企业知识库里往往有, 就是一个文档包含了多方面的内容. Chunk 不准确肯定是垃圾, 但是不相关内容一样是垃圾, 它会占用你宝贵的显存.

其实我觉得, 你这套系统, 就是一个自研的RAG, 只是你没有用传统的embedding和固定长度chunk. 或者说, 你的chunk变成了一个个完整文档.

所以, 我觉得不要轻易全面否定RAG的价值. 从经济性和效果的平衡出发, 还有很长的路要走. 包括RAG, 长上下文LLM, 知识图谱等技术应该长期共存,逐步融合, 更可能是一种混合策略.

个人浅见, 欢迎拍砖 🙂

]]>https://lcz.me/post/8376https://lcz.me/post/8376Fri, 26 Jun 2026 10:04:28 GMT<![CDATA[Reply to 基于RAG-WIKI 理论,我做了一套本地知识库,用于客服机器人. on Fri, 26 Jun 2026 09:57:39 GMT]]>其实Hermes Agent就是如此的理念，但是这个理念的难点始终在于执行：
1、到底什么时候需要去维护记忆。维护的太频繁，内容量爆炸且费效比极低。维护的太少，wiki和现实的信息鸿沟又太大。

2、记忆和现实的矛盾应该靠修改还是新增来解决。（比如，你以前都去盒马买西瓜，今天去的七鲜，那这段描述：“主人每周五要去盒马买西瓜”应该修改还是应该新增？）

3、如何界定一个事的边界。“我今天崴了脚，我媳妇儿晚上请我吃好吃的”，这两件事之间到底有没有逻辑关联？如果有且写入wiki，就会给LLM极大的误导。反之，如果认为没有关联，就是信息的遗失，就会造成wiki和现实的统计学偏差。

网上充斥着类似“Hermes越用越难用”，“我建立了好几个Hermes用于不同的工作流才能提升其精准度”，本质上其实就是以上三者的不停误差累积，导致最终memery从一个正向增益变成了负面噪声。

]]>https://lcz.me/post/8375https://lcz.me/post/8375Fri, 26 Jun 2026 09:57:39 GMT