求助：大模型如何处理大量工单数据

[KingCoding]

本地部署的是 DeepSeek-R1-Qwen-32B （ 32B 满血），每月的工单数量也就 1 万条左右，要生成月报，月报中要统计热点集中诉求，热点集中诉求的判断标准是被诉主体和被诉内容要保证一致，前端只请求一次，传递查询参数，其他的都交给后端来处理啦
问题：循环把工单传递给大模型，每次传递 120 条工单，传递数据使用的格式是 MD ，预留模型的上次分析结果的 token 数，120 条应该是可以传递的最大 token 数，然后保存上次的分析结果带到下次分析，不断循环，由于还有其它业务在用模型算力，调用一次大模型返回结果需要 1 分钟左右，一万条数据跑下来需要 80 多分钟，需要的时间长也就算了，数据还不准确

采用的方案：
方案一：写完提示词和使用上面方法循环调，效果不好（打算把每次大模型反馈的结果进行压缩 token,再带到下一次的请求中）
方案二：对工单数据进行预处理，分析工单有一定的规律，进行筛选，然后截取 top3 ，然后再交给大模型去分析，只需要调用一次大模型，最终结果相对于方案一结果上确实有所提高，但还是不准确（打算使用 hanpl 对工单进行预处理，仔细想了想可能效果还是不太理想）（本来之前准备用 spark 进行预处理的，但是部署和维护问难，引入成本太高）

想请教各位大佬，对于模型调用这方面和提高准确度这方面有什么建议没？真是技穷啦
算力现阶段是没有提高的打算的

[sentinelK]

我看楼主的需求场景，真正需要大模型能力的其实就只是“被诉主体和被诉内容要保证一致”，也就是借用于语义分析？
那完全没有必要使用大模型来进行统计。

难道这个工单是非格式化的（比如整个工单是一个文字叙述）？

非精确数据要求一个精确的结果这也不合理啊。

[listen2wind]

我靠，甲方也要我们接入 DeepSeek 然后对工单进行总结。

[zh3256]

如果大前提是一定要用大模型
不是特别明白为什么要批量请求，每个工单请求一次，做一些分析，分析结果做成结构化的数据保存起来。这样即使工单再多处理完也只是时间问题。不得不使用批量请求的原因是什么呢

[Dav1s]

"prompt": "分析工单，输出 JSON 格式,其中 is_consistent 判断标准：被诉主体和被诉内容是否匹配一致"：
{
"ticket_id": "工单 ID",
"is_consistent": true/false,
"complaint_type": "收费争议/服务质量/虚假宣传/合同违约等"
}

我选择自费 671B......32B 输出感觉想约束其标准化输出有点难

[cowcomic]

先用大模型对每条数据进行结构化或者分类
再在这个基础上用 BI 进行统计，或者封装成指标，前端直接调用

[StarUDream]

上下文设置了多少，每次 120 条工单，还带着上次的结果。

[KingCoding]

@sentinelK 每个工单就是数据库存储的一条用户反馈的问题，还要生成工作建议、总体情况还有敏感诉求和突发事件等，最终生成月报 word

[encro]

多跑几次就可以了，
第一次跑出主要诉讼类别，
然后人工总结类别，
第二次跑让他按照你要求分类。

[KingCoding]

@z1829909 由于算力限制和有其它业务也在调用大模型，不可能每个工单去调用一次，一次喂给大模型 120 条，1 万条左右的数据也需要 80 分钟，而且还是频繁调用大模型，对其他业务造成了影响，对数据做预筛选的原因就是尽可能少的去调用大模型

[encro]

分类后，
然后总结变化，
然后让他根据变化再总结。

[sentinelK]

@KingCoding 如果如此的话，万级 token 的上下文可能都不太够

每 120 条生成的“部分月报”和后面数据，并不是相同精度、相同层级的数据。这会导致误差累积和前后矛盾。而且你的误差累积是指数级别的。

所以我觉得有两条路来优化：

1 、要么像楼上说的，通过提示词建立一个评级标准，然后通过大模型对每条数据逐条分析，相当于对数据进行精简处理。然后最终靠大模型一次请求一万条数据获取结果。（前提是你的 token 数量得够）

2 、根据你 token 的大小限制，搞抽样。

[qieqie]

找一个最小体积的模型比如 qwen 0.6B/ 1.7B ，拿你历史上跑过的数据微调一下

[KingCoding]

@StarUDream 16K

[hoythan]

随机从 1 万条抽 120 条出来总结，剩下的算运气不好。

[zhifubao]

@hoythan 高手

[Lambdua]

其实思路应该向上泛化一层。
将工单转为结构化的数据库表结构。然后针对表数据，使用大模型来进行数据分析和报表生成，这样可以降低幻觉和提高数据的准确性以及效率。

不过细节是魔鬼，我给你的思路肯定是可行的。

[zh3256]

@KingCoding 用大模型跑数据反而是少量多次更好，相比较模型生成内容的时间，中间的网络消耗可以忽略不计。
影响模型算力的消耗最直接的因素是你上下文的长度，假设你 8k 的上下文能跑 50 并发，16k 上下文可能 20 都没有。之所以你需要等这么久也是因为上下文比较长。
另外我突然想到一件事，你们为啥要自己部署呢，打线上有些 mini 模型跑个 1w 条不要钱一样。

[DefoliationM]

没法，大小就是有限制，建议不要考虑用来干这个。

[qbuer]

数据不能出域么，1w 条也不多呀

[YsHaNg]

你这个是上下文召回率问题 r1-672b 都不怎么样 32b 更别想了 fiction.live/stories/Fiction-liveBench-April-29-2025/oQdzQvKHw8JyXbN87

[qbuer]

“热点集中诉求的判断标准是被诉主体和被诉内容要保证一致”，楼主意思是想对每类投诉做个计数吧。可以先划分投诉类别，让后用模型做个分类么

[aminobody]

LLM 仅用来将非结构化数据进行结构化, 分析处理用其他工具实现. 最终写个 summary 也可以用 LLM.

[KingCoding]

@z1829909 政务内网

[KingCoding]

@qbuer 是的，主要是不知道如何划分，工单涵盖范围广泛，自定义划分规则肯定是不能覆盖完的

[KingCoding]

@Lambdua 不错，我准备打标签，落库啦

[conn457567]

R1 的模型本来就不擅长结构化输出，擅长解决需要深入思考的复杂问题。我记得官方也说过这一点。你这个只是简单的数据提取，换 V3 的模型试试

[StarUDream]

我之前碰到过类似的问题，R1 要思考，在很多文本处理上 32B 的模型并不是很好用，偶尔还会出现无限思考的情况（ think 内一直在重复同一段话），这种问题目前只在自己部署的 32B 模型上看到过。
要不试试 Qwen3-32B no_think ，有时候思考带来的确实会有副作用。

然后建议 prompt 让大模型返回 0-100 之间的数，然后定一个阈值，大于多少为满足要求。

[shadowyw]

如果让我做的话:
1. 换 qwen3-32B (或者 qwen3-30B-A3B) 关闭思考模式,
2. 将工单原始内容通过消息队列依次提交给模型分析打标, 生成格式化数据写入数据库
3. 全部工单打标完成后, 模型用 MCP 连接数据库, 查询目标标记, 汇总分析

[dualist]

这以前不是大数据干的吗 BI ES 栈就可以完成吧

[rogerer]

没必要用推理模型，推理模型对不需要推理的场景，可能并不能比得过普通的模型。

[KingCoding]

@shadowyw 产品已经上线，甲方要求要有思考过程

[KingCoding]

@StarUDream 确实存在，我们是通过提示词不断优化去尽可能控制的

[shadowyw]

@KingCoding 需要保留思考过程, 可以考虑换成新鲜出炉的 deepseek-r1-0528-qwen3-8b, 据说其能力与 Qwen3-235B-thinking 相当. 每次推理的过程也保存到数据库中当作分析日志

[KingCoding]

@shadowyw 已经上线了，不好改了