我写了一段代码，解析发票，就是通过 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 上部署的。
第 1 条附言 · 3 天前
是我的问题，对接 deepseek/qwen 这类私有模型，langchain 应该用 llm.stream(messages)，然后再一个 chunk 一个 chunk 读出来就 ok 了，这样 32b 也能取得比较好的效果。用 llm.invoke 容易显示不全
 |
1
Mithril 6 天前
很正常，你的本地模型太小了。32B 的没法和满血的比。
你传进去的数据结构不要太复杂，尝试每次只处理一个 PDF 。另外你这种需求可以找个视觉模型来做，前面 OCR 的准确度也会影响你最终的效果的。OCR 切的太碎，后面 LLM 处理也会比较麻烦，那就需要更好的模型了。 |
 |
2
neteroster 6 天前
> deepseek-r1-distill-qwen-32b
太小了（相对 V3/R1 本体） > deepseek-prover-v2-671b 先了解一下这个模型是干啥的，别一上来就急着用 > qwen3-30b-a3b 太小了（相对 V3/R1 本体） --- 楼上说的挺对，找个好点的视觉模型比较好，比如 Gemini 2.5 Flash/Pro |
 |
3
guoguobaba OP @Mithril 不是使用 ocr 的，而是 pdfminer 解析文本块的，所以这个精准度没问题。
|
 |
4
hahiru 6 天前
@guoguobaba #3 不是 ocr 为什么要用大模型。无脑大模型可不是明智之举。你这种简单且格式固定的需求写个代码手动解析更合适。
|
|
5
guoguobaba OP @hahiru 因为 pdf 本身是文本块，这些文本块的顺序有时候是有差异的，有一版是基于传统方式处理的，效果也还行，现在想用 llm 处理，deepseek 和 gpt 效果比传统方式要好很多，所以想着私有部署来一套。
|
|
6
guoguobaba OP @neteroster 我知道这个模型是干啥的，因为位置信息和文本相互的关联，感觉用这个效果会好一些。
|
 |
7
openmynet 6 天前
你需要找那些支持工具调用的模型，deepseek-r1-distill-qwen-32b 是推理类型的模型，并不适合，qwen3-30b-a3b 需要将使用<no_think>不过效果一般。中小尺寸模型可以看下 mistral small 和 phi4, 以及一些专门针对工具调用微调的 qwen2.5, qwen3 模型。
|
 |
8
asdblue 6 天前  1
大模型都有其能力边界的
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 太小了，算是普通用户私有化部署的玩具，当生产力工具有点吃紧。 |
 |
9
mumbler 6 天前
这不废话吗，云端模型都是几千亿参数的，本地都是几百亿参数的，参数差 10 倍，能力肯定比不上
另外，你说这几个私有模型都不是多模态的，根本没有 OCR 能力，用 qwen2.5vl 7b 效果很好 |
|
10
guoguobaba OP @mumbler 我传的是 text block ，不是图像。
|
 |
11
wwhc 6 天前
楼主如果能提供本地部署时的配置及参数或许会比较有助于了解原因
|
 |
12
matrix1010 6 天前
解析不了 json 格式是指输出的 json 不对？让模型用自然语言输出能不能正常识别
|
 |
13
handuo 5 天前 via Android
我做个对比 还不如找多模态模型直接 OCR 呢，比你的这种方式准确率高
|
 |
14
iyaozhen 5 天前
基本上解析不了 json 格式。这是什么意思，解析不了你的输入还是？
你对比本地合云至少要相同参数呀。“这个精准度没问题” 为啥会有这个结论，现在不是明摆着有问题嘛 |
 |
15
lxqxqxq 5 天前
雅迪哪有奥迪的性能哦
|
|
16
Mithril 5 天前
@guoguobaba 明白了。但还是建议你找个视觉模型，把你的发票直接当图片来处理。
你这个问题是，模型没法理解“相对位置”这种概念。比如你如果把单价提取成 “单价” 和 “10.0” 两个文本块，只带着坐标的话，就比较难把两个东西关联起来。 现在各种云厂商都有专门的发票识别 API ，你也可以看看他们用的什么技术，找个类似的试试。 |
Select Language