-
文档是日常工作的运维知识点。
- 比如设置 ssh 免密登陆、设置 sudo 权限、git 的常用操作、等等。
- 暂时用这些文档来，后续想把公司业务流程放进去。
- 先后试了 obsidian 和 anythingllm ，都不能达到目的。
- 我想要的是：我输入一个关键词，它能找到相关文档。
- 当然，这是初步需求。
- 后续需求，大概是，进行适当联想和总结。
- 现状是，比如我让它给我找 ssh 内容，压根就不准。
- 我想，现在这些 ai 产品，大概率就是骗投资的。
-
类似秦国时期的商鞅变法，先做宣传：
- 谁把这根柱子从西门搬到东门，谁就得 10 根金条。
- 这种蠢事，就很容易得到宣传，先把气氛搞起来。
- 我认为， 如今的 ai ，或者说：大模型，确实是可以提升生产力的。
-
但是，这玩意盈利模式，不清晰。
- 结局就是，普遍做做样子，东西搞出来，投资人满意，赏你个三瓜两枣。
- 但是实际使用，很难用。
- 最近公司不太忙，待会我找个 python 库，再搭一个看看。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 43 days ago, the information mentioned may be changed or developed.
Supplement 1 · Apr 22
我问了谷歌 AI：
我试了一些 rag ，比如 obsidian+copilot ，以及 anythingllm ，用的都是我本地模型。我发现，它们都不太好用。通过观察，我注意到，他们都是先做粗略向量化，然后存储向量，当我需要检索时，系统根据我的关键词，找到存储的向量，并找到周围的一段段原文文字，再丢给 LLM 去做总结。我的想法时，当我提供我的文档出来时，我希望 LLM 可以分析我的文字，打 TAG ，并做关联，再向量化存储。这样我检索时才能更准确。
它的回答：
你的观察非常敏锐。你提到的这种“切片 + 向量化 + 相似度搜索”的模式被称为 Naive RAG （初级 RAG ）。它的局限性在于缺乏对文档语义结构的理解，导致在处理复杂关联或跨文档查询时效果不佳。
你想要的那种“分析文字、打标签、做关联”的思路，在业界正朝着 Advanced RAG （高级 RAG ） 和 Graph RAG （图 RAG ） 的方向演进。
以下是实现你这种想法的几种主流方案和对应工具：
1. Graph RAG (基于知识图谱的 RAG)
这是目前最符合你“打标签、做关联”想法的方案。它不再只是把文字变成向量，而是让 LLM 先读取文档，提取出实体（ Entities ）和关系（ Relationships ），构建一张知识网。
原理：当你提问时，系统不仅寻找相似文字，还会沿着“关系”找到关联的知识节点。
工具推荐：
GraphRAG (by Microsoft)：目前最火的框架。它会先对文档进行全局社区检测，生成摘要和关联。
LightRAG：号称比微软的更轻量、更适合个人和本地模型，强调双层检索。
2. Multi-Vector Retriever (多向量检索 / 摘要检索)
这种方法是在存储时，不直接存原文，而是存 LLM 生成的摘要或关键词。
原理：LLM 先分析一段文字，总结出它的核心标签或摘要。系统将这个“精简版”存为向量。检索时，先通过摘要匹配到相关块，再把背后的原文喂给 LLM 。
本地实现：在 LangChain 或 LlamaIndex 框架中可以通过 MultiVectorRetriever 轻松配置。你可以配置一个 Prompt ，让模型在入库前自动打 Tag 。
3. Agentic RAG (智能体化 RAG)
这种方案让 LLM 变成一个“图书管理员”。
原理：检索不是一次性的。LLM 会先看你的问题，决定去哪些标签（ Tag ）下找，或者先查一下目录，发现关联后，再去翻找具体的文档细节。
工具推荐：Dify.ai 或 Coze 。这两个平台允许你编排工作流：你可以设置一个节点专门负责“预处理和打标”，另一个节点负责“多路召回”。
4. 针对本地模型（ Local LLM ）的进阶建议
如果你坚持使用本地模型（如通过 Ollama 驱动），目前 AnythingLLM 等工具确实过于“一键式”，屏蔽了这些复杂逻辑。建议尝试：
RAGFlow：一个非常强调“语义分析”的开源 RAG 引擎。它对文档的解析（ DeepDoc ）做得极其精细，能够识别文档中的层级关系，而不仅仅是切片。
自行搭建 LlamaIndex 流程：
使用 Inference 模式让 LLM 生成 Metadata （元数据）。
将元数据（ Tags, Summary ）存入向量数据库的 Metadata 字段。
检索时使用 Metadata Filtering （元数据过滤），这比单纯向量搜索准确得多。
总结建议：
如果你有一定技术背景，可以尝试部署 GraphRAG 或 RAGFlow 。它们能从本质上解决“语义孤岛”的问题，让模型先“理解”再“记忆”。
你想尝试手动搭建一套这种“先打标再存储”的自动化工作流，还是寻找更现成的高级 RAG 软件？
我试了一些 rag ，比如 obsidian+copilot ，以及 anythingllm ，用的都是我本地模型。我发现，它们都不太好用。通过观察，我注意到，他们都是先做粗略向量化，然后存储向量，当我需要检索时，系统根据我的关键词，找到存储的向量，并找到周围的一段段原文文字，再丢给 LLM 去做总结。我的想法时，当我提供我的文档出来时，我希望 LLM 可以分析我的文字，打 TAG ，并做关联，再向量化存储。这样我检索时才能更准确。
它的回答：
你的观察非常敏锐。你提到的这种“切片 + 向量化 + 相似度搜索”的模式被称为 Naive RAG （初级 RAG ）。它的局限性在于缺乏对文档语义结构的理解，导致在处理复杂关联或跨文档查询时效果不佳。
你想要的那种“分析文字、打标签、做关联”的思路，在业界正朝着 Advanced RAG （高级 RAG ） 和 Graph RAG （图 RAG ） 的方向演进。
以下是实现你这种想法的几种主流方案和对应工具：
1. Graph RAG (基于知识图谱的 RAG)
这是目前最符合你“打标签、做关联”想法的方案。它不再只是把文字变成向量，而是让 LLM 先读取文档，提取出实体（ Entities ）和关系（ Relationships ），构建一张知识网。
原理：当你提问时，系统不仅寻找相似文字，还会沿着“关系”找到关联的知识节点。
工具推荐：
GraphRAG (by Microsoft)：目前最火的框架。它会先对文档进行全局社区检测，生成摘要和关联。
LightRAG：号称比微软的更轻量、更适合个人和本地模型，强调双层检索。
2. Multi-Vector Retriever (多向量检索 / 摘要检索)
这种方法是在存储时，不直接存原文，而是存 LLM 生成的摘要或关键词。
原理：LLM 先分析一段文字，总结出它的核心标签或摘要。系统将这个“精简版”存为向量。检索时，先通过摘要匹配到相关块，再把背后的原文喂给 LLM 。
本地实现：在 LangChain 或 LlamaIndex 框架中可以通过 MultiVectorRetriever 轻松配置。你可以配置一个 Prompt ，让模型在入库前自动打 Tag 。
3. Agentic RAG (智能体化 RAG)
这种方案让 LLM 变成一个“图书管理员”。
原理：检索不是一次性的。LLM 会先看你的问题，决定去哪些标签（ Tag ）下找，或者先查一下目录，发现关联后，再去翻找具体的文档细节。
工具推荐：Dify.ai 或 Coze 。这两个平台允许你编排工作流：你可以设置一个节点专门负责“预处理和打标”，另一个节点负责“多路召回”。
4. 针对本地模型（ Local LLM ）的进阶建议
如果你坚持使用本地模型（如通过 Ollama 驱动），目前 AnythingLLM 等工具确实过于“一键式”，屏蔽了这些复杂逻辑。建议尝试：
RAGFlow：一个非常强调“语义分析”的开源 RAG 引擎。它对文档的解析（ DeepDoc ）做得极其精细，能够识别文档中的层级关系，而不仅仅是切片。
自行搭建 LlamaIndex 流程：
使用 Inference 模式让 LLM 生成 Metadata （元数据）。
将元数据（ Tags, Summary ）存入向量数据库的 Metadata 字段。
检索时使用 Metadata Filtering （元数据过滤），这比单纯向量搜索准确得多。
总结建议：
如果你有一定技术背景，可以尝试部署 GraphRAG 或 RAGFlow 。它们能从本质上解决“语义孤岛”的问题，让模型先“理解”再“记忆”。
你想尝试手动搭建一套这种“先打标再存储”的自动化工作流，还是寻找更现成的高级 RAG 软件？
 |
1
YanSeven Apr 17  1
agent 可能更合适一点了现在，譬如检索。顶尖的 agent ，譬如 claude code ，codex 已经很精确了。底层也不复杂，不需要什么向量数据库。
|
 |
2
fennu2333 Apr 17 1
你的需求似乎也不复杂，不想用太多 token 的话向量数据库混合索引的简单 naive rag ，愿意用 token 的话好好组织文件结构用 agentic 搜索应该问题都不大
|
 |
3
archxm OP @YanSeven 我用的本地模型，试了 qwen 和 llama ，感觉 llama 稍微好点。但整体还是难以让人满意。
比如，我文档里，有 logrotate.md ，介绍了日志压缩的一些知识点，logrotate 的一些配置。我在问答里，要求找日志压缩，它告诉我说我库里没这方面的内容。 |
|
4
archxm OP @fennu2333 需求当然简单，但这是初始需求，先探索一下，后续会把业务文档放进去，那个就量大了。
文档不用能外面的 ai ，数据不能外传，所以用的本地模型，暂时用的小模型，比如 3b 这种。 其实我这种需求，直接用 es 做索引不就行了吗，试一试 LLM 是因为，这不感觉它挺强的吗，必然要尝试新技术。 |
 |
5
sunzhuo Apr 17 1
notebooklm 试了吗？我用过完全没有幻觉。
|
 |
6
meteor957 Apr 17 via Android 1
数据最好是结构化的，chunk 切分合理。我发现召回的 chunk 和文档整体的关联也很困难，比如人物的第一次出场是第几章。
|
 |
8
clemente Apr 17
rag 是为了省成本的用法.
|
 |
9
coder01 Apr 17 1
腾讯的 ima 呢？
|
 |
10
Edwardlyz Apr 17
试试 Engram 吧，等等 deepseek
|
 |
11
elevioux Apr 17 1
其实吧，现在 LLM 的上下文已经足够，为什么要切呢，直接喂整页就好了。只要 LLM 能根据问题，定位到所需的一页或几页即可。
|
 |
12
nomansky Apr 17
还不如先调用 bash mcp 'grep -i ssh*.md' 一波，
|
 |
13
zhaoziling Apr 17 1
@archxm 你这种情况，我碰到过类似的，你没法用外面的 AI ，本地模型又是比较小的，只能自己累一点搞复杂一点，首先你的数据是否有结构化的可能，不然不好弄，自己能总结出来或者喂一部分典型样例给 AI 让 AI 总结出来，然后用 AI 对数据进行结构化处理，再整体转成向量化数据库，用的时候配合余弦相似度和元数据索引，效果还可以，向量化用的模型需要你自己好好挑一下，国内有几款比国外的更适配中文
|
 |
14
woshishui2022 Apr 17
用本地搭建的 3b 小模型的使用效果；来评价现在的商用大模型？
再固执的程序员也得承认 AI 有用，而且代码写的很好吧；时代已经来了，抗拒也没用啊 |
 |
15
lu5je0 Apr 17 11
看了半天，你用的本地 3b 模型。你搁着拿着自己焊的三轮车评价保时捷呢
|
|
16
archxm OP @sunzhuo notebooklm 是谷歌的吧？我想试，但提示说我所在区域不支持使用。再次询问谷歌 ai ，说让我在外区重新注册账号，太麻烦了，不现实，再说公司内部文档，不方便透露出去，不能调用外部 api
|
 |
18
Livid MOD PRO 1
 |
|
19
archxm OP @woshishui2022 总得有个深入浅出吧？难道我一开始就花 10 几万，买台高端机器，部署 35b 的大模型吗？
|
|
20
Livid MOD PRO 1
NLEmbedding + Gemma4 的效果，全部跑在本地 Mac 上。
 |
 |
21
GPLer Apr 17 1
都不说 claude 、gpt 、gemini 御三家了，要测试大模型能力好歹部署个满血的 glm-5.1 、minimax 2.7 、deepseek v3.2 吧，3b 测了跟没测有什么区别。😅
|
|
27
archxm OP |
|
29
GPLer Apr 17 3
@archxm 3b 模型只能日常对话，基本上没有实用价值，数据量和模型大小没有直接关系，跟上下文长度以及长文本能力有关，3b 也许长文本能力还行，但是模型能力不行也没用。
27b 风评还是不错的，如果效果一般可能是 RAG 配置问题，可以先不用 RAG ，试试都放到一个文件夹里，然后用 opencode 等 agent 平台配置模型，然后将目录所在位置告诉它，测试这种情况下的问答效果，速度会慢很多，但是大模型自己探索后应该能答对，如果这样子可以，后面可以让模型写个 skills ，将检索的技巧做成技能。 |
 |
30
qppq54s Apr 17 1
确实难以让人满意，后面真能让人满意了估计又会迎来一波 ai 的爆发
|
|
31
GPLer Apr 17 2
@GPLer 另外 目前家用最强的模型 gemma4 31b 、qwen3.5 27b 、qwen3.6 35b_a3b ，如果要测试最好在这三个里选，测试下来稠密模型效果比激活参数小的 MoE 模型好很多。
|
 |
33
fkmc Apr 17
fastgpt 云服务 先体验下
|
 |
34
chioplkijhman Apr 17 1
我用向量召回+重排，效果也不好。我也在怀疑 RAG
|
 |
35
dsd2077 PRO 2
楼主看看这个，这是我们自己实现的 RAG 系统，采用向量+FTS 双重检索，准确率非常的高。更别说那些大厂做的产品了。
  |
 |
36
sampeng Apr 17 via iPhone 1
obsidian+claude code 。大力出奇迹
|
 |
37
deepbytes Apr 17 via iPhone
只要你学得够慢，你就不用学。
ai 时代发展前期，迭代太快，像龙虾之后又来个爱马仕，再迭代 2 个月，再出个占用更低内存，不用 token ，全依赖本地模型，你怎么办…… |
 |
38
Lemonadeccc Apr 17
感觉再过几个月 rag 也没啥用了
|
 |
39
huaweii Apr 17 via Android 2
rag 的核心是 chunck/sectionization 和 embedding 。
都是需要根据实际使用场景定制才有好的召回效果。当然更灵活的是 agentic rag 但是一样需要定制。 不在乎隐私的试试 notion 。 obsidian 和 anythingllm 这种你要把它们当成一个项目开发的大框架，仔细配置和定制，才能有你这种复杂的使用效果。 |
 |
40
coefu Apr 17 2
RAG 有门槛的，要一些工程优化的手段。准不准的关键在 rerank 。 当然了，细节上肯定是有语义丢失的，要想更精准，还是要新东西支持。RAG 本身就是个过渡方案。一两年之后，还有没有人继续用都是个问题。
给你介绍几个路线，免得被说嘴炮了： 1 ，又多又准，又省资源的路线： https://github.com/EverMind-AI/MSA ，这个技术可以将知识放到内存，省显存方案 2 ，又快又准： https://github.com/mempalace/mempalace ，启动 token O(1) 级别的快，还能记的准。 1 ，难一点，2 ，简单一点。 |
 |
41
hefish Apr 17
我用 maxkb ，社区版。
|
 |
42
laminux29 Apr 17 2
RAG 这种需求非常难做。
如果想把所有文档全量导入 AI ，现有 AI 没有这么大的上下文窗口。前面有人提到 Google 的 NotebookLLM 效果好，是因为它的窗口比其他主流 AI 大，但也只是大一些。当文档数量超出某个数量级，它也会出现问题。 如果做剪枝，比如提取关键字、向量化、分块、甚至引入复杂的搜索引擎与工作流，都容易出现丢失信息与精度不够的问题。 这种情况下，要确保精度，只能学习人类，把文档一页一页地拆解，拆解后的内容与规范文档一段一段地喂给 AI ，这样做虽然精度足够了，但 tokens 与任务完成时间又会爆炸。如果不介意浪费 tokens ，不介意任务运行时间，可以使用这条途径。 |
 |
45
zxjxzj9 Apr 17 2
现在真的应该用 RAG 的是那种超长上下文模型的内部研究. 就目前的个人来说 RAG 确实是上不去下不来,因为 rerank 和嵌入太费劲了,对个人用户来说投入太大.如果公司的文档有个目录,还不如让 ai 直接理解目录层级的语义来 grep 搜索,比 RAG 好用多了.
|
 |
46
merkle2222 Apr 17
本来就是有这个缺陷,先做一轮 gerp + 数据清洗,效果会很大提升。
|
 |
47
Godykc Apr 17
做过跟楼主一样的事，本地 ollama 跑了个 8b 的 qwen 搞 rag
实际是这玩意连函数调用都不支持，效果当然跟智障没啥区别 所以得先搞定模型再谈后面的 |
|
49
GPLer Apr 17
@Lykos 我自己有一张 3090 24g ，35b 和 27b Q4 用 Ollama 勉强能跑，但是上下文开不高，还是推荐 5090 32g 或 4090 48g ，另外 mac m5 max 64g 版本也是不错的选择，算下来整机成本大概 3w ~ 4w 左右，再往上家用就太贵了。
本来 24g 显存显卡最合适的是用 vllm 跑 27b q4 ，但是 qwen 官方量化的 q4 有问题，权重和 fp8 一样大，只能等 qwen3.6 27b 再看看了。 目前公司里用 A6000 48g 和 4090 48g 在用 vllm 私有化部署模型，48g 显存部署 fp8/q8 精度上下文能拉满原生 256k 上下文，非代码类任务用用还行。 --- 另外如果不要求长上下文的话，27b 模型 16g + gguf 极限量化应该也能跑，35b 模型内存+显存混合使用应该也能跑，不过我没试过，所以不做推荐 --- 丐的方案也有，比如 v100 32g x4 、2080ti 22g x2 、3090 24g x2 、m1 ultra 128g 、m2 ultra 128g/256g ，但是这些方案要么太老要么功耗太高又没质保，并且我没试过，所以就不推荐了。 |
 |
50
HENQIGUAI Apr 17
@archxm #27 你要是这么点文档数量的话根本没必要上 RAG,徒增复杂度，还不如直接拼接成一个完整的 markdown 然后直接上传给 gemini 或者 notebooklm 就完事了
|
 |
51
Censhuang Apr 17 via iPhone
老哥的工程化能力不够，简单的还是不行。今年有个大学要求低算力资源+离线+低参数模型+知识图谱搜索。那你说说这大学怕不是来许愿的。
|
 |
52
xuwuruoshui Apr 17
就算自己实现一个 rag 都不至于这样吧，dense sparse 都有，搜索关键词，应该直接分词就能出来了。具体不准在哪里?比如你问 ssh ，他回答的什么
|
 |
53
cfer Apr 17
模型固然重要，但是核心还是召回的数据完整性。
|
 |
55
Enivel PRO 要搭配 FTS 单纯 rag 关键词匹配都做不到
|
 |
56
akadanjuan101 Apr 17
@GPLer 我在用 3080 20g x2 还挺好的性价比也不错
|
|
57
GPLer Apr 17
@akadanjuan101 但是这种现在没有全新的了，容易买到矿，本身也是魔改卡，质保也是个问题，所以我说了有丐的方案但是不推荐 😂
|
|
58
GPLer Apr 17
@akadanjuan101 所以你 40g 显存目前用啥模型啊
|
|
60
akadanjuan101 Apr 17
@GPLer gemma-4-31B-it 和 Qwen3.5 的 opus 蒸馏版都还可以
|
 |
61
vishun Apr 17
@YanSeven 这些不需要向量数据库是因为偏向代码开发，而代码是有逻辑和规范的，class 、function 这关键字足够正则匹配出来，但是文档则不同，没有明确的规则，分段一旦不合理那就是检索不到，再 rerank 也不行。
|
 |
64
iorilu Apr 17
claude, codex 不是都证明了吗, 不需要 RAG
临时用 rg 搜索下就够了 |
|
65
GPLer Apr 17 via Android
|
|
67
GPLer Apr 17 via Android
@GPLer 另外因为目前看下来还是稠密模型能力强，所以一般不推荐 AI Max+ 395 128GB 和 DGX Spark 128GB ，跑 27B 模型速度太慢没法用，苹果只是单纯力大砖飞+高性价比所以才写上去了。
|
 |
68
someonelikeyouah Apr 17
@fennu2333 #2 naive 还是 native ？ 我是真不懂
 |
|
69
fennu2333 Apr 17 1
@someonelikeyouah naive rag, 你可以理解为最简单的那种向量搜索，没有太多黑魔法的 rag 。其实这个词不是那么官方，只是社区里为了区别后来出现的复杂手段 rag 发明的，比如这个文章介绍了 naive rag https://www.articsledge.com/post/naive-retrieval-augmented-generation-rag ，感觉就好像一大堆框架出现之后管纯 ja 叫 vanilla js 一样
|
 |
71
zsj1029 Apr 17
你需要的是 openwebui
|
 |
72
yechentide Apr 17 via iPhone
@someonelikeyouah naive.
Naive RAG > Advanced RAG > Modular RAG > Graph(Hybrid RAG) > Agentic RAG |
 |
73
fengsi Apr 17
硕士就是做这方面的研究的
rag 工程落地有着极高的要求，不建议深入这块，很多都是无用功。不说别的，先想清楚一件事，你打算如何评估效果？ |
 |
74
diudiuu Apr 17
我现在弄了一个多维度判断这个是不是同一个学者
就是数据量略大,自己没办法微调模型,就搞得 rag |
 |
75
dyncan Apr 17
我最近也在搞这个, 新手不太懂,看看大家的方案学习学习.
|
 |
77
xyz8899 Apr 18 1
我一直在用 RAG ，主要是和法规方面有关的，砖头那么厚的资料放了 400+ 进去分成 6 个库 + 2 个全文检索工具 + 1 web search ，模型用的 Gemini 的，效果杠杠的，提示词、召回重排。。。 这些都要做好啊，你单纯一个向量化没效果的
|
|
78
xyz8899 Apr 18
还有就是模型要用好的=贵的
|
 |
79
winnerczwx Apr 18
看你正文我就很疑惑, 特别是你说 AI 产品是"骗投资"的.
难怪网上有些人评价 AI 的结论跟我实际体验差距很大, 都是在自身一知半解的情况下就妄下结论... |
|
80
Livid MOD PRO 1
|
 |
82
avenger Apr 19 1
参考下 Vercel 写的这个方案
Build knowledge agents without embeddings https://vercel.com/blog/build-knowledge-agents-without-embeddings |
|
84
coefu Apr 22
|
Select Language