V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
sodayo
V2EX  ›  Local LLM

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

  •  
  •   sodayo · 21 小时 3 分钟前 · 2966 次点击

    我们公司有国内某个垂直领域最全面的文档和文献, 上面想要根据这些资源来基于大模型构建一个行业知识库型问答系统, 先自己内部用, 然后再看看能不能直接打包卖方案给别的公司. 前期 POC 阶段, 用的 RAGFlow 和本地运行 deepseek-r1:14b, 但是效果并不算太好, 但是上面坚持要搞, 所以来问问目前有没有什么更好的方案.

    目前预算是够运行满血版 deepseek-r1, 但是瓶颈出现在 RAG 的召回阶段, 并且本身这些文档对于向量化来说质量不算太好, 有很多图表. 所以是否需要专门雇人来将这些文档制作成大模型可用的数据集并微调模型, 然后再使用工作流的形式处理问答会比较好呢 ?

    第 1 条附言  ·  19 小时 22 分钟前
    发帖的时候有个错误修改下,100 万预算确实不够 deepseek-r1:671b

    目前预算是够运行满血版 deepseek-r1 -> qwen3:235b
    27 条回复    2025-08-27 19:48:34 +08:00
    WaterWestBolus
        1
    WaterWestBolus  
       20 小时 21 分钟前
    虽然不太懂这方面 但是是不是可以考虑把这个问题丢到大模型里问问?

    而且粗看一下,感觉对于 100 万预算的项目来说,14b 的有点小了吧
    wandehul
        2
    wandehul  
       20 小时 21 分钟前   ❤️ 4
    30w 发个外包 ?
    WaterWestBolus
        3
    WaterWestBolus  
       20 小时 21 分钟前
    @WaterWestBolus 第二段没仔细看 忽略我()
    fishlium
        4
    fishlium  
       20 小时 12 分钟前
    知识库要上线本质还是不需要很大参数的模型,要做好意图识别和多路召回,意图识别节点在后续阶段可以使用微调小模型替代。
    suke119
        5
    suke119  
       20 小时 12 分钟前
    100w 搞个锤子 还满血版还要高质量多模态的召回
    nkidgm
        6
    nkidgm  
       20 小时 7 分钟前
    100w 包硬件吗? 100w 包硬件不够花噢,就算上国产软硬件平台也不够花。
    shanks
        7
    shanks  
       19 小时 56 分钟前
    你既然把问题描述清楚了,为什么不直接问 AI 。。 我理解 RAG 目前已经是比较成熟的方案了,无非就是那几个关键步骤,但是真正落到细节上肯定还有很多事情可以做
    soulflysimple123
        8
    soulflysimple123  
       19 小时 48 分钟前
    直接打电话找 deepseek, glm,qwen 啥的让他们出个方案
    sodayo
        9
    sodayo  
    OP
       19 小时 43 分钟前
    @nkidgm 100w 是单独给硬件的费用, 人力成本等另算, 可以允许我自由抽调集团内的开发小组
    coefu
        10
    coefu  
       19 小时 29 分钟前
    @soulflysimple123 为什么你会认为他们会鸟你的电话???🤣
    Ricardoo
        11
    Ricardoo  
       19 小时 24 分钟前   ❤️ 8
    分析下效果不好的原因是什么,是召回阶段还是答案生成阶段,不同问题阶段的处理方式不同
    1. 召回阶段,做好多路召回,向量召回( huggingface 上的知名 embedding 模型都试下,bge 、qwen 等)和传统 ES 召回都做下,效果不会太差,如果领域术语较多,可能 es 召回效果还要更好一些。
    2. 答案生成阶段,这个评估的更多了,首先调 API 试试大尺寸模型,看对领域内理解够不够。
    - 够的话直接部署大模型完事。
    - 如果不行。1. 考虑做领域内 continue pretrain, 把领域内知识学进去,然后走 SFT ,也许需要 RL, 人力物力 100w 可能不够,这种方案需要一个团队来搞。2. 走 PE + 多 agent ,为大模型添加更多的上下文背景知识。现在领域内大模型都倾向于这种模式
    gaobh
        12
    gaobh  
       19 小时 23 分钟前 via iPhone
    中间要搞结构化处理
    netizen
        13
    netizen  
       19 小时 10 分钟前
    单纯做文档向量化检索的效果确实很差,可以研究下 #11 的思路。
    sodayo
        14
    sodayo  
    OP
       18 小时 31 分钟前 via Android
    @Ricardoo 非常感谢,给了我很多思路
    kosmosr
        15
    kosmosr  
       18 小时 23 分钟前   ❤️ 1
    bytesfold
        16
    bytesfold  
       18 小时 16 分钟前 via iPhone
    垃圾进垃圾出
    Gilfoyle26
        17
    Gilfoyle26  
       17 小时 41 分钟前   ❤️ 1
    @wandehul #2 太多了,花 200 ,给大学生布置一个作业,然后弄不出来,没有毕业证
    murmur
        18
    murmur  
       17 小时 38 分钟前
    知识库最重要的就是数据准备,这部分得找专业公司做,数据质量差后面再好也白扯
    mekingname
        19
    mekingname  
       17 小时 10 分钟前
    向量检索真的非常垃圾。跟向量模型无关。我觉得就是向量检索其实根本没有『意图识别』的能力。

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

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

    所以向量检索有个屁的意图识别能力,它跟关键词匹配没有什么区别。
    ooTwToo
        20
    ooTwToo  
       17 小时 6 分钟前
    RAG 做好召回很难很难, 普通文本向量化倒还好,一些复杂的多维表格和带图片的 pdf 根本搞不下去。
    urlpha
        21
    urlpha  
       16 小时 30 分钟前
    行业知识库我的理解类似于传统的数据中台,对原始数据的处理能力很重要,需要内置一些面向咱们行业内容的预处理脚本,处理成面向 ragflow 等开发平台友好的输出结构。我认为这个部分是行业知识库大模型的竞争力或产品力所在。
    huangmiao233
        22
    huangmiao233  
       15 小时 9 分钟前
    deepseek-r1 685B 需要 6 张 H20 141G 去推理 , 目前整机服务器价格 大概是 120W 左右.
    hutng
        23
    hutng  
       14 小时 41 分钟前   ❤️ 1
    之前小型的搞过一个知识库。

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

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

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

    我这里的项目比较小,纯 rag 效果一般,尤其是数据量大的时候。 没用过 GraphRAG 这类高阶的,不做评判。
    dko
        24
    dko  
       14 小时 20 分钟前
    根据我踩过的知识库搭建的坑,给你点建议:
    1.先别想完整落地方案,把流程先走通,模型、向量数据库等先用云上资源测试通,最终评估到底要用哪个。不同行业类型知识库的调优都是个技术活儿。
    2.提示词是个大爹,我 300+文档,提示词写了都快几千字。你先用少量知识库把流程走通,情感、问题分类搞好。
    3.性能也是个大问题,以上先完成知道大概节点会卡在哪里,提前规划,不然知识库你要反复搞好几次。
    felixcode
        25
    felixcode  
       13 小时 28 分钟前 via Android
    想好了,别钱花完了啥都没有
    raydied
        26
    raydied  
       12 小时 37 分钟前
    楼主已经注意到召回瓶颈,这点很关键。

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

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

    最后,基于大量数据集的微调,100W 不够。所以,与其急着上大规模微调,不如先把文档解析和召回优化到位。
    你可以做个实验:解析 、Chunk 、Embedding 、Rerank 、Prompt 、LLM 选型 、 微调。
    chairuosen
        27
    chairuosen  
       11 小时 26 分钟前   ❤️ 1
    我提一个思路,
    先让模型扫一遍所有文档,把每个文档讲的啥总结一下做成目录,每个文档 100 字左右。总体控制在一次的输入限制长度内。
    然后把用户问题对着这个总结让模型自己找可能有关的目录。
    再只取这几篇的全文查看,回答问题。
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1166 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 23:14 · PVG 07:14 · LAX 16:14 · JFK 19:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.