Java架构师的AI转型之路（下）：模型层与平台化架构

过江龙847 2026-08-21 0 阅读12分钟

系列文章：总篇 · 上篇 · 中篇 · 下篇

---

接中篇

在中篇中，我详细拆解了 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) + ' ')
    
    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 值不值得？

因人而异。 但客观现状有三：

1. 市场稀缺性：能做Java架构的人很多，能做AI工程的人也很多，但既能设计企业级AI平台架构、又懂领域级业务和Java生态的人，凤毛麟角。

2. 薪资天花板：AI架构师的薪资中位数比纯Java架构师高30%-50%甚至更多，且岗位增速远快于传统开发岗位。

3. 不可替代性：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 实战）← 本篇