最近在 GitHub 上翻到港大 HKUDS 出的 RAG-Anything，自己部署跑了一圈，结论先放前面：想搭本地个人知识库、又懒得拼 OCR、切分、向量化那套流水线的人，这套目前是我见过最省心的一体化方案。

它本质是架在 LightRAG 上的一套端到端多模态管道，PDF、PPT、Word、Excel、甚至图片直接丢进去就行。真正让我眼前一亮的是它把表格、图片、公式当成和文字同等的检索对象。我拿一份带扫描截图的内部文档测，截图里那个公式表格它居然能向量化后检索回来，不用自己写识别逻辑，这点确实省了大功夫。

本地部署基本一条命令，文件不出本机。比起把合同、论文这类敏感资料上传给第三方 AI，安全感不在一个量级。开源可 fork，检索策略想改就改，对爱折腾的人很友好。其实

当然别神话。首次建索引吃显卡或 API 额度，语料一大明显变慢，多模态解析偶尔也漏识别。但从某种角度看，它把 RAG 里最脏最累的工程活打包好了，对比纯手写性价比摆在那。你们本地知识库现在用的啥，有更顺手的也踢我一下。

笑死，'懒得拼OCR切分向量化那套流水线’这句简直是我本命写照。不过说真的，首次建索引吃显卡或API额度这点对纯想省心的人还是道门槛，前脚刚说一条命令搞定，后脚显卡就顶不住了，反差有点离谱。你那份扫描截图里的公式表格能检索回来是真的绝了，这功能早两年出我能少掉一把头发。

看到你拿内部文档测截图里的公式表格能检索回来，我直接愣了一下，这能力比自己拼识别逻辑省太多了。我前阵子也试过手写 OCR 加切分的流水线，光调切分粒度就耗了两个晚上，最后还是半残废状态，真的劝退。嗯嗯

所以你说的"把最脏最累的工程活打包好"这点我特别有共鸣，对懒人太友好了。不过我有点纠结你提的那个首次建索引吃显卡——我手头这台本子显卡一般，要是真丢一大份语料进去得挂整晚，怕是反而把我这种人劝退了哈哈。加油呀btw 你那次测试大概多大语料，建索引花了多少时间？我想参考下再决定要不要上手。我目前还是土办法，文件丢文件夹加 everything 搜文件名，检索内容基本靠脑子记，惨兮兮的。

笑死 我也最烦拼OCR切分那套流水线 直接丢进去就跑这feature真的很nice哈哈 本地一条命令我直接冲了 回头fork下来玩玩

懒人福音 这种丢进去就完事的太对我胃口了 自己拼OCR切分那套流水线我早放弃八百回了

我怎么听说的版本不太一样，HKUDS 那个 LightRAG 核心好像就一两个博后在推，RAG-Anything 这波挺像顺手收割 star 的延伸。不过我更想抠他一句：你说文件不出本机，转头又提首次建索引吃 API 额度，那要是图省事接了云端 embedding，敏感资料不还是得往外跑一趟？嘿嘿他到底用的本地模型还是云 API，这块没说清我有点不敢全信。

我之前帮人整理一份带扫描件的外贸合同就卡在图片里的表格上，手写识别逻辑写到头秃，看到你说截图里的公式表格能直接检索回来我真的眼前一亮。你建索引用的是本地显卡还是 API 呀，我这台老机器有点怕带不动 (´｡• ᵕ •｡`)

说真的，这玩意儿最戳我的是公式表格能向量化检索回来这点。我之前拿带截图的文献硬搞，光写识别逻辑就耗掉半条命，这种开箱即用的确实省大功夫。不过楼主说的一条命令跑本地，我属实有点酸，我们实验室哪张卡常年被占满，建索引慢到我想直接把资料甩给第三方了，安全感瞬间不香了哈哈。话说它对中文扫描件友好吗？我那堆带手写批注的PDF才是真·地狱难度。