批了 100 万预算让我负责搭建行业知识库大模型, 但是目前还没有思路

虽然不太懂这方面 但是是不是可以考虑把这个问题丢到大模型里问问？

而且粗看一下，感觉对于 100 万预算的项目来说，14b 的有点小了吧

30w 发个外包 ？

@WaterWestBolus 第二段没仔细看 忽略我（）

知识库要上线本质还是不需要很大参数的模型，要做好意图识别和多路召回，意图识别节点在后续阶段可以使用微调小模型替代。

100w 搞个锤子 还满血版还要高质量多模态的召回

100w 包硬件吗？ 100w 包硬件不够花噢，就算上国产软硬件平台也不够花。

你既然把问题描述清楚了，为什么不直接问 AI 。。 我理解 RAG 目前已经是比较成熟的方案了，无非就是那几个关键步骤，但是真正落到细节上肯定还有很多事情可以做

直接打电话找 deepseek, glm,qwen 啥的让他们出个方案

@nkidgm 100w 是单独给硬件的费用, 人力成本等另算, 可以允许我自由抽调集团内的开发小组

@soulflysimple123 为什么你会认为他们会鸟你的电话？？？

分析下效果不好的原因是什么，是召回阶段还是答案生成阶段，不同问题阶段的处理方式不同
1. 召回阶段，做好多路召回，向量召回（ huggingface 上的知名 embedding 模型都试下，bge 、qwen 等）和传统 ES 召回都做下，效果不会太差，如果领域术语较多，可能 es 召回效果还要更好一些。
2. 答案生成阶段，这个评估的更多了，首先调 API 试试大尺寸模型，看对领域内理解够不够。
- 够的话直接部署大模型完事。
- 如果不行。1. 考虑做领域内 continue pretrain, 把领域内知识学进去，然后走 SFT ，也许需要 RL, 人力物力 100w 可能不够，这种方案需要一个团队来搞。2. 走 PE + 多 agent ，为大模型添加更多的上下文背景知识。现在领域内大模型都倾向于这种模式

中间要搞结构化处理

单纯做文档向量化检索的效果确实很差，可以研究下 #11 的思路。

@Ricardoo 非常感谢，给了我很多思路

可以看看这个帖子
https://datawhalechina.github.io/all-in-rag/#/

垃圾进垃圾出

@wandehul #2 太多了，花 200 ，给大学生布置一个作业，然后弄不出来，没有毕业证

知识库最重要的就是数据准备，这部分得找专业公司做，数据质量差后面再好也白扯

向量检索真的非常垃圾。跟向量模型无关。我觉得就是向量检索其实根本没有『意图识别』的能力。

我举个例子，我的知识库里面有苹果手机、华为手机、OppO 手机的各种技术指标。但没有小米手机的任何数据。

然后当我提问：『小米手机的技术优势是什么』时，它会把苹果手机、华为手机的指标提出来给你，让你以为这是小米的指标。

所以向量检索有个屁的意图识别能力，它跟关键词匹配没有什么区别。

RAG 做好召回很难很难， 普通文本向量化倒还好，一些复杂的多维表格和带图片的 pdf 根本搞不下去。

行业知识库我的理解类似于传统的数据中台，对原始数据的处理能力很重要，需要内置一些面向咱们行业内容的预处理脚本，处理成面向 ragflow 等开发平台友好的输出结构。我认为这个部分是行业知识库大模型的竞争力或产品力所在。

deepseek-r1 685B 需要 6 张 H20 141G 去推理 , 目前整机服务器价格 大概是 120W 左右.

之前小型的搞过一个知识库。

模型不是重点，你用 deepseek ，qwen 都可以，我其实建议你上 qwen3 32B ，模型能力不是知识库的瓶颈。主要注意的是上下文大小和并发够不够。

重点是什么？是索引的精度，问题输入后 rag 拉出来的文本块和问题的匹配度高不高。如果这里不高，再强的大模型也是胡诌。

建议：先去详细梳理需求，整个问题库，分块大小，索引，测试。抓出的块符合预期了再去搞大模型。涉及到的内容：向量模型、重排模型、分块大小、怎么分块等等。

我这里的项目比较小，纯 rag 效果一般，尤其是数据量大的时候。 没用过 GraphRAG 这类高阶的，不做评判。

根据我踩过的知识库搭建的坑，给你点建议：
1.先别想完整落地方案，把流程先走通，模型、向量数据库等先用云上资源测试通，最终评估到底要用哪个。不同行业类型知识库的调优都是个技术活儿。
2.提示词是个大爹，我 300+文档，提示词写了都快几千字。你先用少量知识库把流程走通，情感、问题分类搞好。
3.性能也是个大问题，以上先完成知道大概节点会卡在哪里，提前规划，不然知识库你要反复搞好几次。

想好了，别钱花完了啥都没有

楼主已经注意到召回瓶颈，这点很关键。

我基于 dify 做了一些测试，用的是 word 文档，里面有文本、表格、无图片。
1 、同一文档的不同解析方式会影响 chunk 块 -> 会影响召回质量 -> 会影响首字返回和回答质量，所以文档解析和清洗方式都十分重要（自动化处理也很重要）。
2 、不同 chunk 方式会直接影响召回质量。
3 、基于不同嵌入模型的向量化会影响召回质量。
4 、因不同模型的指令执行能力不同，相同召回下给出的最终答案并不能都很好。

你不是有预算吗？嵌入模型（ text-embedding-3 等）、各大中转站的大模型 API 都挺便宜的。

最后，基于大量数据集的微调，100W 不够。所以，与其急着上大规模微调，不如先把文档解析和召回优化到位。
你可以做个实验：解析 、Chunk 、Embedding 、Rerank 、Prompt 、LLM 选型 、 微调。

我提一个思路，
先让模型扫一遍所有文档，把每个文档讲的啥总结一下做成目录，每个文档 100 字左右。总体控制在一次的输入限制长度内。
然后把用户问题对着这个总结让模型自己找可能有关的目录。
再只取这几篇的全文查看，回答问题。

大概率是召回的质量不行，可以试试增加一路 graphrag

@Ricardoo #11 大佬你好 什么叫做 2. 走 PE + 多 agent

@NotAProgrammer PE -> prompt engineering, 就是调 prompt 。agent 架构有很多，可以知乎上搜索关键词