我们公司有国内某个垂直领域最全面的文档和文献, 上面想要根据这些资源来基于大模型构建一个行业知识库型问答系统, 先自己内部用, 然后再看看能不能直接打包卖方案给别的公司. 前期 POC 阶段, 用的 RAGFlow 和本地运行 deepseek-r1:14b, 但是效果并不算太好, 但是上面坚持要搞, 所以来问问目前有没有什么更好的方案.
目前预算是够运行满血版 deepseek-r1, 但是瓶颈出现在 RAG 的召回阶段, 并且本身这些文档对于向量化来说质量不算太好, 有很多图表. 所以是否需要专门雇人来将这些文档制作成大模型可用的数据集并微调模型, 然后再使用工作流的形式处理问答会比较好呢 ?
 |
1
WaterWestBolus Aug 27, 2025
虽然不太懂这方面 但是是不是可以考虑把这个问题丢到大模型里问问？
而且粗看一下，感觉对于 100 万预算的项目来说，14b 的有点小了吧 |
 |
2
wandehul Aug 27, 2025  4
30w 发个外包 ？
|
|
3
WaterWestBolus Aug 27, 2025
@WaterWestBolus 第二段没仔细看 忽略我（）
|
 |
4
fishlium Aug 27, 2025
知识库要上线本质还是不需要很大参数的模型，要做好意图识别和多路召回，意图识别节点在后续阶段可以使用微调小模型替代。
|
 |
5
suke119 Aug 27, 2025
100w 搞个锤子 还满血版还要高质量多模态的召回
|
 |
6
nkidgm Aug 27, 2025
100w 包硬件吗？ 100w 包硬件不够花噢，就算上国产软硬件平台也不够花。
|
 |
7
shanks Aug 27, 2025
你既然把问题描述清楚了，为什么不直接问 AI 。。 我理解 RAG 目前已经是比较成熟的方案了，无非就是那几个关键步骤，但是真正落到细节上肯定还有很多事情可以做
|
 |
8
soulflysimple123 Aug 27, 2025
直接打电话找 deepseek, glm,qwen 啥的让他们出个方案
|
 |
10
coefu Aug 27, 2025
@soulflysimple123 为什么你会认为他们会鸟你的电话？？？🤣
|
 |
11
Ricardoo Aug 27, 2025 9
分析下效果不好的原因是什么，是召回阶段还是答案生成阶段，不同问题阶段的处理方式不同
1. 召回阶段，做好多路召回，向量召回（ huggingface 上的知名 embedding 模型都试下，bge 、qwen 等）和传统 ES 召回都做下，效果不会太差，如果领域术语较多，可能 es 召回效果还要更好一些。 2. 答案生成阶段，这个评估的更多了，首先调 API 试试大尺寸模型，看对领域内理解够不够。 - 够的话直接部署大模型完事。 - 如果不行。1. 考虑做领域内 continue pretrain, 把领域内知识学进去，然后走 SFT ，也许需要 RL, 人力物力 100w 可能不够，这种方案需要一个团队来搞。2. 走 PE + 多 agent ，为大模型添加更多的上下文背景知识。现在领域内大模型都倾向于这种模式 |
 |
12
Solix Aug 27, 2025 via iPhone
中间要搞结构化处理
|
 |
13
netizen Aug 27, 2025
单纯做文档向量化检索的效果确实很差，可以研究下 #11 的思路。
|
 |
15
kosmosr Aug 27, 2025 1
|
 |
16
bytesfold Aug 27, 2025 via iPhone
垃圾进垃圾出
|
 |
17
Gilfoyle26 Aug 27, 2025 1
@wandehul #2 太多了，花 200 ，给大学生布置一个作业，然后弄不出来，没有毕业证
 |
 |
18
murmur Aug 27, 2025
知识库最重要的就是数据准备，这部分得找专业公司做，数据质量差后面再好也白扯
|
 |
19
mekingname Aug 27, 2025
向量检索真的非常垃圾。跟向量模型无关。我觉得就是向量检索其实根本没有『意图识别』的能力。
我举个例子，我的知识库里面有苹果手机、华为手机、OppO 手机的各种技术指标。但没有小米手机的任何数据。 然后当我提问：『小米手机的技术优势是什么』时，它会把苹果手机、华为手机的指标提出来给你，让你以为这是小米的指标。 所以向量检索有个屁的意图识别能力，它跟关键词匹配没有什么区别。 |
 |
20
ooTwToo Aug 27, 2025
RAG 做好召回很难很难， 普通文本向量化倒还好，一些复杂的多维表格和带图片的 pdf 根本搞不下去。
|
 |
21
urlpha Aug 27, 2025
行业知识库我的理解类似于传统的数据中台，对原始数据的处理能力很重要，需要内置一些面向咱们行业内容的预处理脚本，处理成面向 ragflow 等开发平台友好的输出结构。我认为这个部分是行业知识库大模型的竞争力或产品力所在。
|
 |
22
huangmiao233 Aug 27, 2025
deepseek-r1 685B 需要 6 张 H20 141G 去推理 , 目前整机服务器价格 大概是 120W 左右.
|
 |
23
hutng Aug 27, 2025 2
之前小型的搞过一个知识库。
模型不是重点，你用 deepseek ，qwen 都可以，我其实建议你上 qwen3 32B ，模型能力不是知识库的瓶颈。主要注意的是上下文大小和并发够不够。 重点是什么？是索引的精度，问题输入后 rag 拉出来的文本块和问题的匹配度高不高。如果这里不高，再强的大模型也是胡诌。 建议：先去详细梳理需求，整个问题库，分块大小，索引，测试。抓出的块符合预期了再去搞大模型。涉及到的内容：向量模型、重排模型、分块大小、怎么分块等等。 我这里的项目比较小，纯 rag 效果一般，尤其是数据量大的时候。 没用过 GraphRAG 这类高阶的，不做评判。 |
 |
24
dko Aug 27, 2025 1
根据我踩过的知识库搭建的坑，给你点建议：
1.先别想完整落地方案，把流程先走通，模型、向量数据库等先用云上资源测试通，最终评估到底要用哪个。不同行业类型知识库的调优都是个技术活儿。 2.提示词是个大爹，我 300+文档，提示词写了都快几千字。你先用少量知识库把流程走通，情感、问题分类搞好。 3.性能也是个大问题，以上先完成知道大概节点会卡在哪里，提前规划，不然知识库你要反复搞好几次。 |
 |
25
felixcode PRO 想好了，别钱花完了啥都没有
|
 |
26
raydied Aug 27, 2025 1
楼主已经注意到召回瓶颈，这点很关键。
我基于 dify 做了一些测试，用的是 word 文档，里面有文本、表格、无图片。 1 、同一文档的不同解析方式会影响 chunk 块 -> 会影响召回质量 -> 会影响首字返回和回答质量，所以文档解析和清洗方式都十分重要（自动化处理也很重要）。 2 、不同 chunk 方式会直接影响召回质量。 3 、基于不同嵌入模型的向量化会影响召回质量。 4 、因不同模型的指令执行能力不同，相同召回下给出的最终答案并不能都很好。 你不是有预算吗？嵌入模型（ text-embedding-3 等）、各大中转站的大模型 API 都挺便宜的。 最后，基于大量数据集的微调，100W 不够。所以，与其急着上大规模微调，不如先把文档解析和召回优化到位。 你可以做个实验：解析 、Chunk 、Embedding 、Rerank 、Prompt 、LLM 选型 、 微调。 |
 |
27
chairuosen Aug 27, 2025 2
我提一个思路，
先让模型扫一遍所有文档，把每个文档讲的啥总结一下做成目录，每个文档 100 字左右。总体控制在一次的输入限制长度内。 然后把用户问题对着这个总结让模型自己找可能有关的目录。 再只取这几篇的全文查看，回答问题。 |
 |
28
cooldong287671 Sep 25, 2025
大概率是召回的质量不行，可以试试增加一路 graphrag
|
 |
29
NotAProgrammer Sep 26, 2025
@Ricardoo #11 大佬你好 什么叫做 2. 走 PE + 多 agent
|
|
30
Ricardoo Sep 28, 2025
@NotAProgrammer PE -> prompt engineering, 就是调 prompt 。agent 架构有很多，可以知乎上搜索关键词
|
Select Language