为什么公有模型和私有模型使用效果很大差异

143 天前
 guoguobaba

我写了一段代码,解析发票,就是通过 pdfminer 将 pdf 发票里的每个字符串的位置信息一起带进来,传给 llm ,提示词类似于下面:

prompt = f"""
    你是一个擅长识别发票内容的 AI ,请从以下多个发票的 OCR 块中,提取结构化的发票信息。输出内容为 json 格式,不输出解释、思考或额外说明。
    
    每张发票以“ [文件: xxx.pdf ] ”标识其来源。请为每个文件分别返回结构化信息,输出如下 JSON 格式:
    
    {{
      "invoice001.pdf": {{
        "发票代码": "...",
        "发票号码": "...",
        "开票日期": "...",
        "购买方名称": "...",
        "销售方名称": "...",
        "价税合计": "...",
        "明细": [
          {{
            "名称": "...",
            "数量": "...",
            "单价": "...",
            "金额": "..."
          }}
        ]
      }},
      ...
    }}
    
    以下是多个文件的 OCR 文本及其坐标:
    {'\n'.join(all_text_blocks)}
        """.strip()

对接 gpt 和 deepseek 公有模型都好使,但是对接私有模型,比如 deepseek-r1-distill-qwen-32b ,deepseek-prover-v2-671b , 还有最新的 qwen3-30b-a3b ,效果都很差,基本上解析不了 json 格式。这是什么原因呢,需要怎么调试。

使用的是 langchain 框架,私有模型用的是 gpustack 在 macstudio m3ultra 上部署的。

2586 次点击
所在节点    编程
16 条回复
Mithril
143 天前
很正常,你的本地模型太小了。32B 的没法和满血的比。

你传进去的数据结构不要太复杂,尝试每次只处理一个 PDF 。另外你这种需求可以找个视觉模型来做,前面 OCR 的准确度也会影响你最终的效果的。OCR 切的太碎,后面 LLM 处理也会比较麻烦,那就需要更好的模型了。
neteroster
143 天前
> deepseek-r1-distill-qwen-32b
太小了(相对 V3/R1 本体)

> deepseek-prover-v2-671b
先了解一下这个模型是干啥的,别一上来就急着用

> qwen3-30b-a3b
太小了(相对 V3/R1 本体)

---

楼上说的挺对,找个好点的视觉模型比较好,比如 Gemini 2.5 Flash/Pro
guoguobaba
143 天前
@Mithril 不是使用 ocr 的,而是 pdfminer 解析文本块的,所以这个精准度没问题。
hahiru
143 天前
@guoguobaba #3 不是 ocr 为什么要用大模型。无脑大模型可不是明智之举。你这种简单且格式固定的需求写个代码手动解析更合适。
guoguobaba
143 天前
@hahiru 因为 pdf 本身是文本块,这些文本块的顺序有时候是有差异的,有一版是基于传统方式处理的,效果也还行,现在想用 llm 处理,deepseek 和 gpt 效果比传统方式要好很多,所以想着私有部署来一套。
guoguobaba
143 天前
@neteroster 我知道这个模型是干啥的,因为位置信息和文本相互的关联,感觉用这个效果会好一些。
openmynet
143 天前
你需要找那些支持工具调用的模型,deepseek-r1-distill-qwen-32b 是推理类型的模型,并不适合,qwen3-30b-a3b 需要将使用<no_think>不过效果一般。中小尺寸模型可以看下 mistral small 和 phi4, 以及一些专门针对工具调用微调的 qwen2.5, qwen3 模型。
asdblue
143 天前
大模型都有其能力边界的
1 、gpt 、deepseek:是非常强的通用大模型,做你这个需求问题不大
2 、deepseek-r1-distill-qwen-32b:其实不是 deepseek ,是以 qwen-32b 为基底蒸馏 deepseek 后的产物,相比满血的 671B 的 R1 ,差的太远了
3 、deepseek-prover-v2-671b:这个是 ProverV2 ,是 V3 (通用模型)基础上训练出来的数学领域专精的模型,所以虽然是 671b 的大参数,但你这个需求场景完全不适用。
4 、qwen3-30b-a3b:还是大小的问题,30b 太小了,算是普通用户私有化部署的玩具,当生产力工具有点吃紧。
mumbler
143 天前
这不废话吗,云端模型都是几千亿参数的,本地都是几百亿参数的,参数差 10 倍,能力肯定比不上

另外,你说这几个私有模型都不是多模态的,根本没有 OCR 能力,用 qwen2.5vl 7b 效果很好
guoguobaba
143 天前
@mumbler 我传的是 text block ,不是图像。
wwhc
143 天前
楼主如果能提供本地部署时的配置及参数或许会比较有助于了解原因
matrix1010
143 天前
解析不了 json 格式是指输出的 json 不对?让模型用自然语言输出能不能正常识别
handuo
143 天前
我做个对比 还不如找多模态模型直接 OCR 呢,比你的这种方式准确率高
iyaozhen
142 天前
基本上解析不了 json 格式。这是什么意思,解析不了你的输入还是?

你对比本地合云至少要相同参数呀。“这个精准度没问题” 为啥会有这个结论,现在不是明摆着有问题嘛
lxqxqxq
142 天前
雅迪哪有奥迪的性能哦
Mithril
142 天前
@guoguobaba 明白了。但还是建议你找个视觉模型,把你的发票直接当图片来处理。

你这个问题是,模型没法理解“相对位置”这种概念。比如你如果把单价提取成 “单价” 和 “10.0” 两个文本块,只带着坐标的话,就比较难把两个东西关联起来。

现在各种云厂商都有专门的发票识别 API ,你也可以看看他们用的什么技术,找个类似的试试。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1137529

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX