1

1

agent 可能更合适一点了现在，譬如检索。顶尖的 agent ，譬如 claude code ，codex 已经很精确了。底层也不复杂，不需要什么向量数据库。

2

1

你的需求似乎也不复杂，不想用太多 token 的话向量数据库混合索引的简单 naive rag ，愿意用 token 的话好好组织文件结构用 agentic 搜索应该问题都不大

3

@YanSeven 我用的本地模型，试了 qwen 和 llama ，感觉 llama 稍微好点。但整体还是难以让人满意。
比如，我文档里，有 logrotate.md ，介绍了日志压缩的一些知识点，logrotate 的一些配置。我在问答里，要求找日志压缩，它告诉我说我库里没这方面的内容。

4

@fennu2333 需求当然简单，但这是初始需求，先探索一下，后续会把业务文档放进去，那个就量大了。
文档不用能外面的 ai ，数据不能外传，所以用的本地模型，暂时用的小模型，比如 3b 这种。
其实我这种需求，直接用 es 做索引不就行了吗，试一试 LLM 是因为，这不感觉它挺强的吗，必然要尝试新技术。

5

1

notebooklm 试了吗？我用过完全没有幻觉。

6

1

数据最好是结构化的，chunk 切分合理。我发现召回的 chunk 和文档整体的关联也很困难，比如人物的第一次出场是第几章。

11

1

其实吧，现在 LLM 的上下文已经足够，为什么要切呢，直接喂整页就好了。只要 LLM 能根据问题，定位到所需的一页或几页即可。

12

还不如先调用 bash mcp 'grep -i ssh*.md' 一波，

13

1

@archxm 你这种情况，我碰到过类似的，你没法用外面的 AI ，本地模型又是比较小的，只能自己累一点搞复杂一点，首先你的数据是否有结构化的可能，不然不好弄，自己能总结出来或者喂一部分典型样例给 AI 让 AI 总结出来，然后用 AI 对数据进行结构化处理，再整体转成向量化数据库，用的时候配合余弦相似度和元数据索引，效果还可以，向量化用的模型需要你自己好好挑一下，国内有几款比国外的更适配中文

14

用本地搭建的 3b 小模型的使用效果；来评价现在的商用大模型？
再固执的程序员也得承认 AI 有用，而且代码写的很好吧；时代已经来了，抗拒也没用啊

15

11

看了半天，你用的本地 3b 模型。你搁着拿着自己焊的三轮车评价保时捷呢

16

@sunzhuo notebooklm 是谷歌的吧？我想试，但提示说我所在区域不支持使用。再次询问谷歌 ai ，说让我在外区重新注册账号，太麻烦了，不现实，再说公司内部文档，不方便透露出去，不能调用外部 api

20

1

21

1

都不说 claude 、gpt 、gemini 御三家了，要测试大模型能力好歹部署个满血的 glm-5.1 、minimax 2.7 、deepseek v3.2 吧，3b 测了跟没测有什么区别。😅

22

@lu5je0 公司电脑弱，用的 3b ，感觉 qwen 不如 llama 。
家里的高配电脑能跑 35b ，昨晚也试了，总体感觉也是，不堪用。

23

5

@archxm 你的观点是 RAG 不行，我的观点是 3B 不行，没人说一定要一开始就大投入，但你不应该因为 3B 不行就说 RAG 不行。

26

2

@archxm #19 哥们，越争辩越暴漏了你真的不了解。3b 连测试的必必要性都没有。Livid 建议的 Gemm4 27b 感觉各方面就很均衡

27

@Livid #20
@GPLer #21 我也就 20 几个 markdown ，都是日常 linux 的运维经验，每个文档也就 3k 左右，这个数据量，3b 也该够了吧？实际上，家里电脑跑 27b 似乎也是效果一般。

29

3

@archxm 3b 模型只能日常对话，基本上没有实用价值，数据量和模型大小没有直接关系，跟上下文长度以及长文本能力有关，3b 也许长文本能力还行，但是模型能力不行也没用。
27b 风评还是不错的，如果效果一般可能是 RAG 配置问题，可以先不用 RAG ，试试都放到一个文件夹里，然后用 opencode 等 agent 平台配置模型，然后将目录所在位置告诉它，测试这种情况下的问答效果，速度会慢很多，但是大模型自己探索后应该能答对，如果这样子可以，后面可以让模型写个 skills ，将检索的技巧做成技能。

30

1

确实难以让人满意，后面真能让人满意了估计又会迎来一波 ai 的爆发

31

2

@GPLer 另外 目前家用最强的模型 gemma4 31b 、qwen3.5 27b 、qwen3.6 35b_a3b ，如果要测试最好在这三个里选，测试下来稠密模型效果比激活参数小的 MoE 模型好很多。

32

@qppq54s 整体看，我是看好 ai 的，确实能提高生产力，比搜索引擎方便。
但如果想要对 ai 进行二次加工，我觉得还是有很多活要干的。

33

fastgpt 云服务 先体验下

35

1

楼主看看这个，这是我们自己实现的 RAG 系统，采用向量+FTS 双重检索，准确率非常的高。更别说那些大厂做的产品了。

36

1

obsidian+claude code 。大力出奇迹

37

只要你学得够慢，你就不用学。
ai 时代发展前期，迭代太快，像龙虾之后又来个爱马仕，再迭代 2 个月，再出个占用更低内存，不用 token ，全依赖本地模型，你怎么办……

39

2

42

2

45

2

现在真的应该用 RAG 的是那种超长上下文模型的内部研究. 就目前的个人来说 RAG 确实是上不去下不来,因为 rerank 和嵌入太费劲了,对个人用户来说投入太大.如果公司的文档有个目录,还不如让 ai 直接理解目录层级的语义来 grep 搜索,比 RAG 好用多了.

46

本来就是有这个缺陷,先做一轮 gerp + 数据清洗,效果会很大提升。

47

做过跟楼主一样的事，本地 ollama 跑了个 8b 的 qwen 搞 rag
实际是这玩意连函数调用都不支持，效果当然跟智障没啥区别
所以得先搞定模型再谈后面的

49

50

@archxm #27 你要是这么点文档数量的话根本没必要上 RAG,徒增复杂度，还不如直接拼接成一个完整的 markdown 然后直接上传给 gemini 或者 notebooklm 就完事了

51

老哥的工程化能力不够，简单的还是不行。今年有个大学要求低算力资源+离线+低参数模型+知识图谱搜索。那你说说这大学怕不是来许愿的。

52

就算自己实现一个 rag 都不至于这样吧，dense sparse 都有，搜索关键词，应该直接分词就能出来了。具体不准在哪里?比如你问 ssh ，他回答的什么

53

模型固然重要，但是核心还是召回的数据完整性。

55

要搭配 FTS 单纯 rag 关键词匹配都做不到

59

@Enivel FTS 一开始没反应过来，查了下这不就是双路召回的其中一路吗，都 2026 年了，早就标配了。

61

@YanSeven 这些不需要向量数据库是因为偏向代码开发，而代码是有逻辑和规范的，class 、function 这关键字足够正则匹配出来，但是文档则不同，没有明确的规则，分段一旦不合理那就是检索不到，再 rerank 也不行。

63

@archxm #27 大模型能力不是这么评估的...不是看要处理的数据量大小，而是看模型参数量啊，模型参数量不够，你就算处理的数据再少，不行就是不行

64

65

@akadanjuan101 可以的
gemma4 31b 没有官方量化，我还在找合适的使用方式
qwopus 我最近在试，这个因为是非官方的我没写，确实忘了😂

67

@GPLer 另外因为目前看下来还是稠密模型能力强，所以一般不推荐 AI Max+ 395 128GB 和 DGX Spark 128GB ，跑 27B 模型速度太慢没法用，苹果只是单纯力大砖飞+高性价比所以才写上去了。

73

74

75

我最近也在搞这个, 新手不太懂,看看大家的方案学习学习.

77

1

我一直在用 RAG ，主要是和法规方面有关的，砖头那么厚的资料放了 400+ 进去分成 6 个库 + 2 个全文检索工具 + 1 web search ，模型用的 Gemini 的，效果杠杠的，提示词、召回重排。。。 这些都要做好啊，你单纯一个向量化没效果的

79