这是一个创建于 233 天前的主题，其中的信息可能已经有所发展或是发生改变。
本地部署的是 DeepSeek-R1-Qwen-32B （ 32B 满血），每月的工单数量也就 1 万条左右，要生成月报，月报中要统计热点集中诉求，热点集中诉求的判断标准是被诉主体和被诉内容要保证一致，前端只请求一次，传递查询参数，其他的都交给后端来处理啦
问题：循环把工单传递给大模型，每次传递 120 条工单，传递数据使用的格式是 MD ，预留模型的上次分析结果的 token 数，120 条应该是可以传递的最大 token 数，然后保存上次的分析结果带到下次分析，不断循环，由于还有其它业务在用模型算力，调用一次大模型返回结果需要 1 分钟左右，一万条数据跑下来需要 80 多分钟，需要的时间长也就算了，数据还不准确
采用的方案：
方案一：写完提示词和使用上面方法循环调，效果不好（打算把每次大模型反馈的结果进行压缩 token,再带到下一次的请求中）
方案二：对工单数据进行预处理，分析工单有一定的规律，进行筛选，然后截取 top3 ，然后再交给大模型去分析，只需要调用一次大模型，最终结果相对于方案一结果上确实有所提高，但还是不准确（打算使用 hanpl 对工单进行预处理，仔细想了想可能效果还是不太理想）（本来之前准备用 spark 进行预处理的，但是部署和维护问难，引入成本太高）
想请教各位大佬，对于模型调用这方面和提高准确度这方面有什么建议没？真是技穷啦
算力现阶段是没有提高的打算的
问题：循环把工单传递给大模型，每次传递 120 条工单，传递数据使用的格式是 MD ，预留模型的上次分析结果的 token 数，120 条应该是可以传递的最大 token 数，然后保存上次的分析结果带到下次分析，不断循环，由于还有其它业务在用模型算力，调用一次大模型返回结果需要 1 分钟左右，一万条数据跑下来需要 80 多分钟，需要的时间长也就算了，数据还不准确
采用的方案：
方案一：写完提示词和使用上面方法循环调，效果不好（打算把每次大模型反馈的结果进行压缩 token,再带到下一次的请求中）
方案二：对工单数据进行预处理，分析工单有一定的规律，进行筛选，然后截取 top3 ，然后再交给大模型去分析，只需要调用一次大模型，最终结果相对于方案一结果上确实有所提高，但还是不准确（打算使用 hanpl 对工单进行预处理，仔细想了想可能效果还是不太理想）（本来之前准备用 spark 进行预处理的，但是部署和维护问难，引入成本太高）
想请教各位大佬，对于模型调用这方面和提高准确度这方面有什么建议没？真是技穷啦
算力现阶段是没有提高的打算的
 |
1
sentinelK 2025 年 5 月 29 日
我看楼主的需求场景，真正需要大模型能力的其实就只是“被诉主体和被诉内容要保证一致”，也就是借用于语义分析？
那完全没有必要使用大模型来进行统计。 难道这个工单是非格式化的（比如整个工单是一个文字叙述）？ 非精确数据要求一个精确的结果这也不合理啊。 |
 |
2
listen2wind 2025 年 5 月 29 日
我靠，甲方也要我们接入 DeepSeek 然后对工单进行总结。
|
 |
3
adgfr32 2025 年 5 月 29 日 via Android
如果大前提是一定要用大模型
不是特别明白为什么要批量请求，每个工单请求一次，做一些分析，分析结果做成结构化的数据保存起来。这样即使工单再多处理完也只是时间问题。不得不使用批量请求的原因是什么呢 |
 |
4
Dav1s 2025 年 5 月 29 日
"prompt": "分析工单，输出 JSON 格式,其中 is_consistent 判断标准：被诉主体和被诉内容是否匹配一致"：
{ "ticket_id": "工单 ID", "is_consistent": true/false, "complaint_type": "收费争议/服务质量/虚假宣传/合同违约等" } 我选择自费 671B......32B 输出感觉想约束其标准化输出有点难 |
 |
5
cowcomic 2025 年 5 月 29 日
先用大模型对每条数据进行结构化或者分类
再在这个基础上用 BI 进行统计，或者封装成指标，前端直接调用 |
 |
6
StarUDream 2025 年 5 月 29 日
上下文设置了多少，每次 120 条工单，还带着上次的结果。
|
 |
7
KingCoding OP @sentinelK 每个工单就是数据库存储的一条用户反馈的问题，还要生成工作建议、总体情况还有敏感诉求和突发事件等，最终生成月报 word
|
 |
8
encro 2025 年 5 月 29 日
多跑几次就可以了，
第一次跑出主要诉讼类别， 然后人工总结类别， 第二次跑让他按照你要求分类。 |
|
9
KingCoding OP @z1829909 由于算力限制和有其它业务也在调用大模型，不可能每个工单去调用一次，一次喂给大模型 120 条，1 万条左右的数据也需要 80 分钟，而且还是频繁调用大模型，对其他业务造成了影响，对数据做预筛选的原因就是尽可能少的去调用大模型
|
|
10
encro 2025 年 5 月 29 日
分类后，
然后总结变化， 然后让他根据变化再总结。 |
|
11
sentinelK 2025 年 5 月 29 日  1
@KingCoding 如果如此的话，万级 token 的上下文可能都不太够
每 120 条生成的“部分月报”和后面数据，并不是相同精度、相同层级的数据。这会导致误差累积和前后矛盾。而且你的误差累积是指数级别的。 所以我觉得有两条路来优化： 1 、要么像楼上说的，通过提示词建立一个评级标准，然后通过大模型对每条数据逐条分析，相当于对数据进行精简处理。然后最终靠大模型一次请求一万条数据获取结果。（前提是你的 token 数量得够） 2 、根据你 token 的大小限制，搞抽样。 |
 |
12
qieqie 2025 年 5 月 29 日
找一个最小体积的模型比如 qwen 0.6B/ 1.7B ，拿你历史上跑过的数据微调一下
|
|
13
KingCoding OP @StarUDream 16K
|
 |
14
hoythan 2025 年 5 月 29 日
随机从 1 万条抽 120 条出来总结，剩下的算运气不好。
|
 |
16
Lambdua 2025 年 5 月 29 日
其实思路应该向上泛化一层。
将工单转为结构化的数据库表结构。然后针对表数据，使用大模型来进行数据分析和报表生成，这样可以降低幻觉和提高数据的准确性以及效率。 不过细节是魔鬼，我给你的思路肯定是可行的。 |
|
17
adgfr32 2025 年 5 月 29 日 via Android
@KingCoding 用大模型跑数据反而是少量多次更好，相比较模型生成内容的时间，中间的网络消耗可以忽略不计。
影响模型算力的消耗最直接的因素是你上下文的长度，假设你 8k 的上下文能跑 50 并发，16k 上下文可能 20 都没有。之所以你需要等这么久也是因为上下文比较长。 另外我突然想到一件事，你们为啥要自己部署呢，打线上有些 mini 模型跑个 1w 条不要钱一样。 |
 |
18
DefoliationM 2025 年 5 月 29 日 via Android
没法，大小就是有限制，建议不要考虑用来干这个。
|
 |
19
qbuer 2025 年 5 月 29 日
数据不能出域么，1w 条也不多呀
|
 |
20
YsHaNg 2025 年 5 月 29 日 via iPhone
你这个是上下文召回率问题 r1-672b 都不怎么样 32b 更别想了 fiction.live/stories/Fiction-liveBench-April-29-2025/oQdzQvKHw8JyXbN87
|
|
21
qbuer 2025 年 5 月 29 日
“热点集中诉求的判断标准是被诉主体和被诉内容要保证一致”，楼主意思是想对每类投诉做个计数吧。可以先划分投诉类别，让后用模型做个分类么
|
 |
22
aminobody 2025 年 5 月 29 日
LLM 仅用来将非结构化数据进行结构化, 分析处理用其他工具实现. 最终写个 summary 也可以用 LLM.
|
|
23
KingCoding OP @z1829909 政务内网
|
|
24
KingCoding OP @qbuer 是的，主要是不知道如何划分，工单涵盖范围广泛，自定义划分规则肯定是不能覆盖完的
|
|
25
KingCoding OP @Lambdua 不错，我准备打标签，落库啦
|
 |
26
conn457567 2025 年 5 月 30 日 via Android
R1 的模型本来就不擅长结构化输出，擅长解决需要深入思考的复杂问题。我记得官方也说过这一点。你这个只是简单的数据提取，换 V3 的模型试试
|
|
27
StarUDream 2025 年 5 月 30 日 1
我之前碰到过类似的问题，R1 要思考，在很多文本处理上 32B 的模型并不是很好用，偶尔还会出现无限思考的情况（ think 内一直在重复同一段话），这种问题目前只在自己部署的 32B 模型上看到过。
要不试试 Qwen3-32B no_think ，有时候思考带来的确实会有副作用。 然后建议 prompt 让大模型返回 0-100 之间的数，然后定一个阈值，大于多少为满足要求。 |
 |
28
shadowyw 2025 年 5 月 30 日 1
如果让我做的话:
1. 换 qwen3-32B (或者 qwen3-30B-A3B) 关闭思考模式, 2. 将工单原始内容通过消息队列依次提交给模型分析打标, 生成格式化数据写入数据库 3. 全部工单打标完成后, 模型用 MCP 连接数据库, 查询目标标记, 汇总分析 |
 |
29
dualist 2025 年 5 月 30 日
这以前不是大数据干的吗 BI ES 栈就可以完成吧
|
 |
30
rogerer 2025 年 5 月 30 日
没必要用推理模型，推理模型对不需要推理的场景，可能并不能比得过普通的模型。
|
|
31
KingCoding OP @shadowyw 产品已经上线，甲方要求要有思考过程
|
|
32
KingCoding OP @StarUDream 确实存在，我们是通过提示词不断优化去尽可能控制的
|
|
33
shadowyw 2025 年 6 月 3 日
@KingCoding 需要保留思考过程, 可以考虑换成新鲜出炉的 deepseek-r1-0528-qwen3-8b, 据说其能力与 Qwen3-235B-thinking 相当. 每次推理的过程也保存到数据库中当作分析日志
|
|
34
KingCoding OP @shadowyw 已经上线了，不好改了
|
Select Language