提问:文本提取使用那个模型
-
如题:那个本地小模型提取文本事实又快又好,最重要的是提取没有幻觉,主要是跨段落合并提取和多事实合并的场景
-
多小。9B ?
问问题描述清楚。
你懒的说。我也懒的答!
还有你这个需求已经归到复杂档了。 -
这题的关键不是「哪个模型」,而是「怎么让它不编」。纯事实抽取,方法比模型重要,建议按这个顺序做:
1)输出先锁死。温度 0,给固定 JSON schema(每条 = fact / source_quote / span),用 grammar 或结构化输出强制字段(llama.cpp 的 GBNF、vLLM 的 guided_json),禁止自由发挥。要求每条事实必须附原文引用,抽不到就返回空——允许「不知道」,幻觉会掉一大截。
2)抽取 + 校验两步走。第一步只让模型「定位」,第二步用程序核对每条 quote 是否真在原文里(精确/近似匹配),对不上的直接丢。跨段落合并、多事实合并放在第二步做,别指望一次 prompt 同时干完。
3)长文走 map-reduce。按段/块抽,再合并去重;别为了跨段把整篇塞进去,既贵又容易漏。合并阶段再上长上下文模型。
模型(中文、本地、7B 级别就够):
- Qwen3 系列:4B/8B Instruct 做抽取很稳,0.6B/1.7B 适合极简任务;Qwen2.5-7B 也可。
- 纯实体/关系抽取,GLiNER、spaCy 这类专用模型比通用 LLM 更不容易编,适合先打底。
- 量化 Q4_K_M/Q5_K_M 足够,抽取对量化不敏感。
经验:把任务拆成「可验证的小步」+ 强制引用,比换更大的模型有效。你说清文档规模、语言、要抽哪些字段,我可以给更具体的 prompt + schema。
-
任何模型都很快。。。
-
多小。9B ?
问问题描述清楚。
你懒的说。我也懒的答!
还有你这个需求已经归到复杂档了。@williamlouis 越小越好,前提是跨段落合并提取和多事实合并没有幻觉,我现在用的是27B的5bit量化,速度有点慢,平均是50tps,如果能提升个50%左右的效率就好了
-
如题:那个本地小模型提取文本事实又快又好,最重要的是提取没有幻觉,主要是跨段落合并提取和多事实合并的场景
@heheimback 百度飞桨啊
-
@williamlouis 越小越好,前提是跨段落合并提取和多事实合并没有幻觉,我现在用的是27B的5bit量化,速度有点慢,平均是50tps,如果能提升个50%左右的效率就好了
50 tps 想再快 50%,先别换卡,按「先定位瓶颈,再选手段」走:
1)先确认是 dense 还是 MoE。27B dense 5bit 权重约 16–17GB,50 t/s 基本已经贴着单卡带宽天花板(3090 936GB/s 理论也就 ~55 t/s)。这种情况调参挤不出 50%,只能换量化或换模型。
2)「抽取」这个任务,降规格比超频有效:
- 量化 5bit → Q4_K_M,权重少约 20%,decode 约 +15–20%;抽取质量掉得小,用你现有「第二步程序核对 quote」兜底即可。
- 直接换 8B 级 Q4,速度通常 3–5 倍。抽取要的是稳定结构输出,不需要 27B 的推理能力,配 2 步校验后大多数文档够用。
3)想榨单流:上投机解码(优先模型自带 MTP 头),别只看 t/s,看「接受长度」;k=3–4 通常最划算,再大验证开销反噬。
4)抽取是吞吐型任务,真正的 50%+ 来自批处理:llama-server 开多 slot 或 vLLM 连续批处理,多文档并行喂,单请求延迟不变、聚合吞吐接近线性;长文再加 q8_0 KV + 前缀缓存避免重复 prefill。
5)架构上二段式:小模型先定位给 span,只有低置信度段落才升级到 27B 复核,平均成本直接下来。
一句话:单流 50→75 很难(除非 MTP),但把「27B 单流串行」改成「小模型 + 批处理 + 校验」,总效率翻倍很容易。