开源大模型在企业业务场景下的落地思考
我过去一年在一家中型企业带了两个开源大模型的落地项目，一个做内部 IT 工单智能分流，一个做合同条款风险审查。都"跑通了"，但过程远没有 PPT 上写的那么丝滑。下面把决策思路、架构演进和踩过的坑都摊开讲。
一、选型：别被 benchmark 带节奏
第一个坑：跑分高的模型，干业务未必行
我们最初选模型的时候，盯着各种 leaderboard 看半天。MMLU 分数高、HumanEval 代码能力强，那肯定选它对吧？结果上了业务线，用户问"这个会议室投影仪不亮怎么办"，模型回了一段关于投影仪光学原理的科普。
问题出在哪？benchmark 测的是"能力天花板"，业务场景要的是"稳定输出"。这俩不是一回事。
后来我们换了选型思路，不再只看跑分，而是按业务任务的实际表现来评：
业务测试用例与模型评估器
Python
import json
import time
import requests
from dataclasses import dataclass
from typing import List
@dataclass
class TestCase:
"""业务测试用例：不是通用能力，是真实业务场景"""
id: str
category: str # 工单分类
input: str # 用户输入
expected_intent: str # 期望识别的意图
expected_entities: dict # 期望提取的实体
difficulty: str # easy / medium / hard
# 真实业务用例（脱敏后）
BUSINESS_TEST_CASES = [
TestCase(
id="IT-001",
category="硬件故障",
input="会议室A302的投影仪开机后亮一下就灭了，试了两次都这样",
expected_intent="hardware_repair",
expected_entities={"device": "投影仪", "location": "A302",
"symptom": "开机后自动熄灭"},
difficulty="medium"
),
TestCase(
id="IT-002",
category="账号权限",
input="新入职同事需要开 Jira 和 Confluence 的权限，他叫张伟，部门是产品中心",
expected_intent="permission_request",
expected_entities={"systems": ["Jira", "Confluence"],
"user": "张伟", "department": "产品中心"},
difficulty="easy"
),
TestCase(
id="IT-003",
category="网络问题",
input="VPN 连上是连上了但是访问内网系统特别慢，有时候还超时，就今天开始的",
实际输出示例：
| | | |
| | | |
| | | |
最终我们选了 14B——7B 在 hard 场景上翻车严重（口语化描述识别不了），32B 准确率虽然满分但延迟快 1.5 秒，用户体感太慢。14B 在准确率和延迟之间取了个平衡。
二、资源规划：显存不是唯一成本
第二个坑：只算显存，不算运维
很多人一拍脑袋"买个 A100 就完了"，但实际成本远不止 GPU。我列个真实账单：
| | |
| | |
| | |
| | |
| | |
| | |
加上人力成本，一年下来总投入大概 25-30 万。老板看到这个数字会问："这个钱花出去，给我省回来了什么？"
所以资源规划不能只看显存，得算 ROI。我们当时的算法是：
代码块
Plain Text
人力成本节省 = 之前 3 个 IT 运维人工分类工单的工时 × 时薪
效率提升 = 工单平均处理时间从 4 小时 → 30 分钟
准确率提升带来的隐性收益 = 误派单率从 12% → 3%
这些数字你得提前算好，否则项目中期评审的时候，你拿什么跟老板交代？
三、从 Demo 到生产：架构的三次进化
第三个坑：用 demo 架构直接上生产
我们第一版就是最简单的：Flask + vLLM + 一个 if-else 判断意图。在测试环境跑得好好的，到了生产环境，第一天就崩了。原因是并发请求一来，vLLM 内部排队，HTTP 请求超时，前端就开始重试，越重试越堵。
后来经历了三次架构演进才稳定下来，第三次迭代的产物是一个生产级模型网关，解决了三个核心问题：
并发控制——防止 vLLM 被压垮
优先级调度——实时请求优先于批量任务
降级策略——模型挂了不影响业务
生产级模型网关（第三次架构迭代）
Python
import asyncio
import time
from dataclasses import dataclass
from enum import Enum
import aiohttp
import json
class RequestPriority(Enum):
"""请求优先级：不是所有请求都一样重要"""
CRITICAL = 1 # 用户实时对话，不能等太久
四、微调决策：不是所有问题都要微调
第四个坑：一上来就微调
团队有个同事特别热衷微调，模型效果不好就说"微调一下"。但微调是有成本的——数据标注人力、训练时间、版本管理、回滚风险——哪一样都不便宜。
我的原则是：先用 Prompt 解决，Prompt 解决不了再上 RAG，RAG 也不行才考虑微调。
我们最终微调的场景只有一个：工单分类的输出格式不稳定。模型有时输出 JSON、有时输出 Markdown、有时多一句"好的我来帮您分析"——这种格式一致性问题，Prompt 怎么调都偶尔翻车，微调 200 条数据就彻底解决了。
微调数据构建器
Python
import json
import random
class FineTuneDataBuilder:
"""微调数据构建器：从现有工单数据生成训练集"""
def __init__(self):
self.intent_map = {
"硬件故障": "hardware_repair",
"账号权限": "permission_request",
"网络问题": "network_diagnosis",
微调前后对比：输出格式一致率从 78% 提升到 99%，意图识别准确率从 80% 到 83%——格式问题彻底解决了，但准确率提升有限。说明准确率瓶颈不在模型能力，而在 Prompt 设计和 RAG 质量。
五、完整落地案例：IT 工单智能分流系统
业务背景
公司 IT 运维团队每天收到约 300 条工单（邮件、企业微信、电话转工单），需要人工分类后派给对应处理人。平均分类耗时 5 分钟/条，误派率 12%，高峰期积压严重。
系统架构
系统采用"模型网关 + AI 分析引擎 + 知识库检索"的组合架构：
用户通过工单渠道提交工单
模型网关转发工单内容到 AI 分析引擎
AI 分析引擎先从知识库检索相似历史工单（Top 3）
结合检索结果进行意图识别 + 实体提取
综合判断（AI + 知识库投票）后按置信度分流：
◦
置信度 > 0.85：自动派单
◦
置信度 0.5~0.85：建议分类，人工确认
◦
置信度 < 0.5：标记为待人工分类
处理完成后工单入库，每周用新工单数据增量更新知识库
效果数据
上线三个月后的数据：
| | | |
| | | |
| | | |
| | | |
| | | |
注意"人工干预率"从 100% 降到 18%——这意味着 82% 的工单是 AI 自动分类派单的。但那 18% 的人工干预是必须保留的，因为里面包含了多意图、模糊描述、新类型工单，这些让 AI 自己处理风险太高。
六、踩坑总结：这些弯路你可以不用走
💡
坑 1：用通用 benchmark 选业务模型。MMLU 考高分不代表能处理你的工单。一定要建业务测试集，哪怕只有 50 条，也比看跑分靠谱。
坑 2：单实例直接上生产。并发一来就 OOM。最少准备两个实例 + 健康检查 + 降级策略。第一天出事，后面就没人敢用了。
坑 3：不设置信度阈值。AI 什么都有信心回，没信心也说"我确定"。必须设阈值，低置信度的走人工——宁可不自动，不能乱自动。
坑 4：微调太早。Prompt 没调好就微调，等于在烂地基上盖楼。先穷尽 Prompt 和 RAG 的优化空间，确实不够了再微调。
坑 5：不做效果监控。上线不等于完成。每周跑一次评估集，发现准确率掉到 75% 以下就告警。
坑 6：知识库不更新。RAG 的知识库不是建好就完了。新工单类型出现、旧的处理流程变更，知识库都得跟着更新。
坑 7：忽略用户反馈。用户说"分类错了"的时候，那是最有价值的训练数据。做个反馈按钮，每次用户点"分类有误"，工单自动进入微调数据候选池。
开源大模型从"实验室能跑"到"业务能用"，中间隔着的东西，远比一个 docker run 命令复杂得多。选型要基于业务测试不是通用跑分，资源规划要算总账不是只看显存，架构要经过并发和故障的考验才敢说稳定，微调是最后的手段不是第一选择。
落地的核心思路就一句话：从业务问题出发，而不是从模型能力出发。别看到模型能做啥就想着业务能用上啥，而要看业务痛在哪，然后找模型能解决的那部分切入。剩下的部分用规则、用人工兜底、用流程补上。