系列文章：总篇 · 上篇 · 中篇 · 下篇
接中篇
在中篇中，我详细拆解了 Phase 2 的实战过程——从Agent基础（ReAct/Tool Use）到多Agent协作（LangGraph状态机），从人工审核节点到Java侧的服务治理集成。
如果你跟着做到了这一步，那么现在你已经能让AI自主完成复杂任务了。
但作为一个消费者，很快会和我一样意识到一个问题：
我们不可能让所有请求都走 GPT，太贵了，而且很多时候根本不需要那么强的模型！
于是进入 Phase 3——模型层与平台化。这也是整个转型的"分水岭"：从"用AI做项目"升级到"为整个组织设计AI基础设施"。
本文是系列文章的下篇，也是终章。
一、模型选型：为什么"一个模型打天下"是错的
很多团队刚开始用AI时，所有人的默认选择都是 GPT 或 Claude。这是最贵的"懒政"。
不同任务对模型能力的需求差异巨大：
| 任务类型 | 所需能力 | 推荐模型 | 单次成本（估算） |
|---|---|---|---|
| 简单问答/分类 | 基础理解 | Qwen / GLM | ¥0.001-0.01 |
| 代码生成/补全 | 代码能力 | DeepSeek / CodeLlama | ¥0.01-0.05 |
| 复杂推理/分析 | 深度思考 | GPT / Claude | ¥0.1-0.5 |
| 多模态/视觉 | 图文理解 | GPT / Qwen | ¥0.2-1.0 |
| 长文档摘要 | 长上下文 | Claude（200K窗口） | ¥0.1-0.3 |
| 金融专业问答 | 领域知识 | 微调后的领域模型 | 取决于部署方式 |
差距是 100 倍。 如果你让所有请求都走最贵的模型，一年下来成本可能是百万级别的。
1.1 智能路由：用"小模型做初筛，大模型做终审"
这里的设计思路借鉴了负载均衡算法：
用户请求
↓
┌─────────────────────────────┐
│ 模型路由网关 │
│ │
│ ① 意图分类（小模型/Qwen） │ ← 判断这是什么类型的任务
│ ② 复杂度评估 │ ← 简单/中等/复杂
│ ③ 路由决策 │
│ ├─ 简单 → Qwen │ ←（便宜，延迟低）
│ ├─ 中等 → DeepSeek │ ←（性价比高）
│ └─ 复杂 → GPT │ ←（强，但贵）
│ │
│ ④ 降级策略 │ ← 主模型挂了自动切备用
└─────────────────────────────┘
↓
返回结果
1.2 路由网关代码实现
# model_router.py
import openai
from enum import Enum
class TaskComplexity(Enum):
SIMPLE = "simple" # 分类、短问答、关键词提取
MEDIUM = "medium" # 代码生成、摘要、翻译
COMPLEX = "complex" # 多步推理、分析报告、创意写作
# 模型配置
MODEL_CONFIG = {
TaskComplexity.SIMPLE: {
"model": "qwen",
"max_tokens": 512,
"temperature": 0.3,
"cost_per_1k": 0.001, # 元
},
TaskComplexity.MEDIUM: {
"model": "deepseek",
"max_tokens": 2048,
"temperature": 0.5,
"cost_per_1k": 0.014,
},
TaskComplexity.COMPLEX: {
"model": "gpt",
"max_tokens": 4096,
"temperature": 0.7,
"cost_per_1k": 0.3,
},
}
class ModelRouter:
def __init__(self):
self.client = openai.OpenAI()
self.classifier = self._init_classifier()
def _init_classifier(self):
"""用小模型做意图分类，极快极便宜"""
return openai.OpenAI() # 实际可用本地部署的Qwen
def classify_task(self, user_message: str) -> TaskComplexity:
"""判断任务复杂度"""
prompt = f"""将以下用户请求分类为 simple/medium/complex：
- simple: 简单问答、分类、关键词提取、格式化
- medium: 代码生成、文档摘要、数据提取、翻译
- complex: 多步推理、深度分析、创意写作、报告生成
用户请求：{user_message}
只输出分类结果（simple/medium/complex），不要其他内容。"""
response = self.classifier.chat.completions.create(
model="qwen",
messages=[{"role": "user", "content": prompt}],
max_tokens=10,
temperature=0,
)
result = response.choices[0].message.content.strip().lower()
if "simple" in result: return TaskComplexity.SIMPLE
if "complex" in result: return TaskComplexity.COMPLEX
return TaskComplexity.MEDIUM
def route(self, user_message: str) -> str:
"""主路由方法"""
complexity = self.classify_task(user_message)
config = MODEL_CONFIG[complexity]
print(f"[路由决策] 任务类型: {complexity.value} → 模型: {config['model']} → 预估成本: ¥{config['cost_per_1k']}/1k tokens")
try:
response = self.client.chat.completions.create(
model=config["model"],
messages=[{"role": "user", "content": user_message}],
max_tokens=config["max_tokens"],
temperature=config["temperature"],
)
return response.choices[0].message.content
except Exception as e:
# 降级：主模型失败 → 切到备用模型
print(f"[降级] 主模型失败: {e}，切换备用模型")
return self._fallback(user_message)
def _fallback(self, user_message: str) -> str:
"""降级策略：用最稳定的模型兜底"""
response = self.client.chat.completions.create(
model="qwen", # 国产大模型，稳定性好
messages=[{"role": "user", "content": user_message}],
max_tokens=2048,
)
return response.choices[0].message.content
# 使用
router = ModelRouter()
result = router.route("帮我分析一下这段Java代码的性能瓶颈...")
print(result)
这个路由网关应用后测试发现，我们的AI调用成本降低了约 60%左右，而我们感知到的回答质量几乎没有下降。
二、模型微调：让AI真正"懂行"（第21-24周）
通用大模型最大的问题是：它不懂你的业务。
比如你问它"签约状态为2的账户怎么处理"，它不知道在你的系统里"2"代表"已签约待激活"。
2.1 微调方案选型
| 方案 | 成本 | 效果 | 适用场景 |
|---|---|---|---|
| Prompt Engineering | 零成本 | 一般 | 简单场景 |
| RAG（检索增强） | 低 | 较好 | 知识密集型 |
| LoRA微调 | 中（一张4090） | 好 | 领域适配 |
| QLoRA微调 | 低（消费级显卡） | 好 | 个人/小团队 |
| 全量微调 | 极高（多张A100） | 最好 | 大厂/特殊领域 |
建议选择：QLoRA——在一张RTX 4090上就能跑，成本可控，效果接近全量微调。
2.2 数据准备：用你的业务文档造数据（仅供参考）
# prepare_sft_data.py
import json
import re
def create_sft_dataset(business_docs: list, output_file: str):
"""
从业务文档中构造SFT（Supervised Fine-Tuning）数据
方法：用GPT生成问答对，人工审核后用于微调
"""
sft_data = []
for doc in business_docs:
# 方法1：用大模型自动生成QA对
prompt = f"""基于以下业务文档，生成10个问答对（JSON格式）：
要求：
1. 问题要覆盖文档中的核心业务概念和流程
2. 答案要准确、完整
3. 包含一些银行业务专业术语
文档内容：
{doc['content'][:3000]}
输出格式：{{"qa_pairs": [{{"question": "...", "answer": "..."}}]}}"""
# 调用GPT生成（这里省略API调用代码）
qa_pairs = call_gpt4o(prompt)
for qa in qa_pairs:
sft_data.append({
"instruction": qa["question"],
"input": "",
"output": qa["answer"]
})
# 保存为JSONL格式（LLaMA-Factory标准格式）
with open(output_file, 'w', encoding='utf-8') as f:
for item in sft_data:
f.write(json.dumps(item, ensure_ascii=False) + '\n')
print(f"生成 {len(sft_data)} 条SFT数据 → {output_file}")
# 使用（用你自己项目的脱敏业务文档）
# business_docs = load_business_docs("/path/to/docs")
# create_sft_dataset(business_docs, "finance_sft_data.jsonl")
2.3 用LLaMA-Factory微调Qwen（这里以旧版本Qwen2.5-7B-Instruct为例）
# 安装LLaMA-Factory
git clone https://github.com/hiyouga/LLaMA-Factory.git
cd LLaMA-Factory
pip install -e .
# 准备数据（放在 data/ 目录下）
# 编辑 data/finance_sft_data.jsonl
# 单卡QLoRA微调（4090即可）
CUDA_VISIBLE_DEVICES=0 llamafactory-cli train \
--model_name_or_path Qwen/Qwen2.5-7B-Instruct \
--stage sft \
--do_train \
--finetuning_type lora \
--lora_target q_proj,v_proj \
--dataset_dir ./data \
--dataset finance_sft_data \
--template qwen \
--output_dir ./output/qwen2.5-finance-lora \
--cutoff_len 2048 \
--per_device_train_batch_size 4 \
--gradient_accumulation_steps 4 \
--lr_scheduler_type cosine \
--logging_steps 10 \
--save_steps 100 \
--eval_steps 100 \
--warmup_ratio 0.1 \
--max_steps 500 \
--fp16 True \
--quantization_bit 4 \
--quantization_method bnb
# 合并LoRA权重
llamafactory-cli export \
--model_name_or_path Qwen/Qwen2.5-7B-Instruct \
--adapter_name_or_path ./output/qwen2.5-finance-lora \
--template qwen \
--export_dir ./output/qwen2.5-finance-merged \
--export_quantization_bit 16
2.4 微调效果对比
| 测试集（50题金融QA） | 通用Qwen2.5-7B | 微调后Qwen2.5-7B | 提升 |
|---|---|---|---|
| 回答准确率 | 62% | 89% | +27% |
| 专业术语正确使用率 | 55% | 92% | +37% |
| 幻觉率（编造信息） | 18% | 5% | -13% |
| 平均Token消耗 | 320 | 280 | -12% |
微调后的模型在金融领域问答上，效果接近GPT-4o，但推理成本只有它的1/50。
三、企业AI平台完整架构设计（第25-27周）
到这里，你已经具备了设计企业级AI平台的所有组件。下面是我最终输出的架构方案：
3.1 全景架构图
┌────────────────────────────────────────────────────────────┐
│ 企业AI平台全景架构 │
├────────────────────────────────────────────────────────────┤
│ 应用层 │
│ ├── 智能客服 ├── 文档助手 ├── 代码助手 ├── 数据分析 │
│ └── 自定义应用（低代码搭建） │
├────────────────────────────────────────────────────────────┤
│ Agent编排层（LangGraph/Dify/自研） │
│ ├── 多Agent协作 ├── 工作流引擎 ├── 人工审核节点 │
│ └── Agent市场（可复用Agent模板） │
├────────────────────────────────────────────────────────────┤
│ 模型服务层 │
│ ├── 模型路由网关（按任务/成本/延迟智能选模型） │
│ ├── 模型推理集群（vLLM/TGI，支持多模型并发） │
│ ├── 模型微调流水线（数据→训练→评估→部署） │
│ └── 模型注册中心（模型版本/灰度/AB测试） │
├────────────────────────────────────────────────────────────┤
│ RAG/知识层 │
│ ├── 文档解析（PDF/Word/Excel/图片OCR） │
│ ├── 向量化服务（Embedding模型管理） │
│ ├── 向量数据库（Milvus集群） │
│ ├── Rerank服务 │
│ └── 知识图谱（Neo4j - 核心业务实体关系） │
├────────────────────────────────────────────────────────────┤
│ Java服务治理层（Spring Cloud） │
│ ├── API Gateway（鉴权/限流/审计/计费） │
│ ├── 用户与租户管理 │
│ ├── 降级与熔断（Sentinel/Resilience4j） │
│ └── 配置中心（Nacos/Apollo） │
├────────────────────────────────────────────────────────────┤
│ 基础设施层 │
│ ├── K8s + Docker（你已有经验） │
│ ├── GPU资源调度（KubeFlow/Volcano） │
│ ├── 模型存储（MinIO/S3） │
│ ├── 监控（Prometheus + Grafana + LLM专用监控） │
│ └── CI/CD（你已有DevOps经验） │
├────────────────────────────────────────────────────────────┤
│ 安全与治理层 │
│ ├── 租户隔离 ├── 数据脱敏 ├── Prompt注入防御 │
│ ├── 审计日志 ├── 内容审核 └── 模型输出合规检查 │
└────────────────────────────────────────────────────────────┘
3.2 各层职责与你的经验映射
| 架构层 | 核心职责 | 你的已有经验 | 需要新学 |
|---|---|---|---|
| 应用层 | 面向业务的功能交付 | 多年积累业务理解力 | AI交互设计 |
| Agent编排层 | 多Agent协作、工作流 | 工作流引擎经验 | LangGraph |
| 模型服务层 | 模型路由、推理、微调 | — | vLLM/微调流水线 |
| RAG/知识层 | 知识检索增强 | 搜索引擎经验 | 向量数据库/Embedding |
| Java服务治理层 | 鉴权/限流/降级/审计 | ← 核心壁垒 | Spring AI |
| 基础设施层 | K8s/GPU/CI-CD | DevOps经验 | GPU调度 |
| 安全治理层 | 数据脱敏/合规/审计 | 金融安全经验 | AI特有安全 |
注意看"Java服务治理层"——这一整层是作为Java研发经验的直接变现。 很多原生的AI工程师并未具备这些积累，而这恰恰是企业在生产环境中最看重的部分。
四、落地与影响力：从学习到产出（Phase 4）
4.1 选一个真实场景端到端落地
我一开始选的是**"智能运维助手"**——这也是结合我自己项目经验和当时可操作层面，解决一个真实痛点：
运维人员每天要查大量的日志、监控指标、告警信息，当前的方式是登录多个系统、写SQL查数据库、翻Grafana看板。平均定位一个问题要20-30分钟甚至更长。
AI助手的目标：用自然语言提问，30秒内给出根因分析和处置建议。
4.2 系统架构
运维人员（自然语言提问）
↓
┌──────────────────────────────────┐
│ Java API Gateway │
│ 鉴权 → 限流 → 审计 → 路由 │
└────────────┬─────────────────────┘
↓
┌──────────────────────────────────┐
│ Agent编排引擎（LangGraph） │
│ │
│ ┌────────┐ ┌────────┐ ┌────┐ │
│ │ 意图 │ →│ 规划 │→ │执行 │ │
│ │ 识别 │ │ 步骤 │ │Agent│ │
│ └────────┘ └────────┘ └──┬─┘ │
│ ↓ │
│ ┌────────┐ ┌────────┐ ┌────┐ │
│ │ 日志 │ │ 指标 │ │SQL │ │
│ │ 检索 │ │ 查询 │ │执行 │ │
│ └────────┘ └────────┘ └────┘ │
│ ↓ │
│ ┌────────────────────────────┐ │
│ │ LLM 根因分析 + 建议生成 │ │
│ └────────────────────────────┘ │
└──────────────────────────────────┘
↓
返回分析结果
4.3 效果验证
内部测试2周后，数据如下：
| 指标 | 改造前 | 改造后 | 提升 |
|---|---|---|---|
| 平均问题定位时间 | 25分钟 | 3分钟 | 88%↓ |
| 跨系统查询次数 | 5-8次 | 1次 | 80%↓ |
| 运维人员满意度 | 3.2/5 | 4.6/5 | 44%↑ |
| 误判率 | 基线 | <5% | — |
五、12个月转型终极复盘
5.1 投入产出比
| 维度 | 投入 | 产出 |
|---|---|---|
| 时间 | 每天1-2小时，持续12个月 ≈ 600小时 | 完整的AI平台架构能力 |
| 金钱 | GPU云资源约5000元 + 模型API约3000元 | 一个生产级AI项目 + 技术品牌 |
| 机会成本 | 牺牲了部分休息和娱乐时间 | 职业方向质的升级 |
5.2 值不值得？
因人而异。 但客观现状有三：
-
市场稀缺性：能做Java架构的人很多，能做AI工程的人也很多，但既能设计企业级AI平台架构、又懂领域级业务和Java生态的人，凤毛麟角。
-
薪资天花板：AI架构师的薪资中位数比纯Java架构师高30%-50%甚至更多，且岗位增速远快于传统开发岗位。
-
不可替代性：AI不会替代架构师，但会用AI的架构师会替代不会用的。这个趋势在未来3-5年只会加速。
5.3 后不后悔？
唯一后悔的是：没有更早开始。
2023年大模型刚出来时，我还觉得"这不就是个聊天机器人吗"。如果当时就开始深入研究，现在可能就不会这么被动了（因为没有可拿出手的实际AI项目经验）。
但换个角度想：现在开始，也不晚。因为大多数企业还在"怎么把AI用起来"的阶段，真正缺的是能把它工程化、平台化、规模化的人——而这，恰恰是一个14年马畜经验的用武之地吧。
六、给同行Java的最后一句话
未来的技术架构，一定是"传统架构能力 × AI工程能力"的复合体。
纯Java架构师不会消失，但会被"会用AI的架构师"拉开巨大差距；纯AI工程师也会遇到天花板，因为企业级的复杂系统永远需要架构思维来驾驭。
而拥抱变化的我们，可以做一个"两条腿走路"的人。
转型不难，难的是开始。从今天起，给自己定一个90天的小目标：跑通一个RAG系统，封装一个Agent工具，写一篇技术总结博客。
12个月后，你也会感谢今天做出这个决定的自己。
附：完整学习资源清单（平台上很多，自己找哈）
课程推荐
| 课程 | 平台 | 适合阶段 |
|---|---|---|
| 《LLM Engineering: Master AI》 | DeepLearning.AI | Phase 1 |
| 《LangChain for LLM Apps》 | DeepLearning.AI | Phase 1-2 |
| 《LangGraph》官方教程 | LangChain官网 | Phase 2 |
| 《Finetuning Large Language Models》 | DeepLearning.AI | Phase 3 |
必读开源项目
| 项目 | 学习点 |
|---|---|
| LangChain/LangGraph | Agent编排设计模式 |
| Dify | 低代码AI应用平台架构 |
| FastGPT | RAG系统完整实现 |
| LLaMA-Factory | 模型微调最佳实践 |
| Spring AI | Java侧AI集成参考 |
建议阅读书籍
| 书名 | 作者 | 说明 |
|---|---|---|
| 《AI Engineering》 | Chip Huyen | 2025新出版，系统全面 |
| 《Designing Data-Intensive Applications》 | Martin Kleppmann | 架构经典，AI平台必读 |
全文完。
如果这三篇文章对你有所启发和帮助，是我荣幸。也许我们现在都在遭遇着属于我们不同的窘境，但请相信这也只是暂时的！还是借用星爷的一句话画个句号：这一路走来全是老师，他们斩我天真，杀我幼稚，磨我心性，练我筋骨。能点醒我的，从来不是道理，而是经历，是南墙。
让我们在AI时代，做那个"多条腿走路"的超级码畜。
作者注：本文基于作者在以往履历中项目的真实实践撰写。文中涉及的技术方案已做脱敏处理。转载请注明出处。
系列文章导航：
- 上篇：为什么转，以及从哪开始（Phase 1 实战）
- 中篇：Agent与编排体系实战（Phase 2 实战）
- 下篇：模型层与平台化架构（Phase 3-4 实战）← 本篇
