第 2 章：行业大模型技术架构

2025年底，一家中型保险公司的CTO面临一个选择：是直接调用云端GPT-4 API，还是花三个月用开源模型搭建私有化系统？他的安全团队说"数据不能出域"，业务团队说"API太贵且不够准"，而技术团队说"我们没人会微调模型"。这不是个案——几乎每一家企业落地行业大模型时，都要面对同一个核心问题：技术架构怎么选？ 本章将系统解答这个问题。

2.1 核心技术栈全景

行业大模型不是单一模型，而是一个由多个技术组件协同工作的系统。理解这个全景，是做出正确架构决策的前提。

基座模型选型

基座模型是整个系统的"大脑"。2026年的开源模型已经能够与闭源模型在企业场景中一较高下。

开源 vs 闭源：决策框架

2026年企业级开源模型推荐¹

选型的核心原则：先确定部署模式，再选模型。如果数据不能出域（金融、政务），直接排除闭源API路线；如果只是内部辅助工具，闭源API可能是最快的选择。

提示词工程的工程化实践

提示词工程（Prompt Engineering）看似简单——写一段文字让模型做事——但要在生产环境中稳定运行，需要系统化的工程实践。

结构化提示词模板

一个面向行业的提示词通常包含以下结构：

[角色定义]
你是一名{行业}领域的{角色}，具备{专业能力}。

[任务描述]
请根据以下{输入类型}，完成{任务目标}。

[知识上下文]
{通过RAG注入的行业知识}

[输出格式]
请按以下JSON格式输出：
{{
  "字段1": "说明",
  "字段2": "说明"
}}

[约束条件]
- 必须基于提供的知识上下文回答
- 如果信息不足，明确标注"信息不足"
- 不要编造不存在的数据或案例

工程化的三个层次：

1. 版本管理：提示词和代码一样需要版本控制。每次修改提示词模板时记录变更原因和效果对比。
2. A/B测试：对同一任务维护多个提示词版本，通过在线A/B测试选择最优方案。
3. 自动化评估：建立基于LLM的评估流水线，每次提示词变更自动跑评估集，防止回归。

RAG：行业落地的第一选择

在所有行业大模型技术中，RAG（检索增强生成）是落地率最高的方案。它的核心逻辑简单而优雅：先从知识库中检索相关信息，再将检索结果作为上下文喂给模型，让模型基于真实数据生成回答。

为什么RAG是行业落地首选？

• 不需要训练模型：无需昂贵的GPU和标注数据，部署成本低
• 知识可更新：只需更新知识库，无需重新训练
• 结果可追溯：每个回答都可以追溯到源文档，满足合规要求
• 幻觉大幅降低：模型基于检索到的事实回答，而非凭空编造

RAG的演进路线

RAG技术本身也在快速演进。2023年的Naive RAG已经无法满足行业需求：

2023: Naive RAG     → "检索-生成"简单两步，精度有限
2024: Advanced RAG  → 查询改写、重排序、混合检索
2024: GraphRAG      → 知识图谱驱动，支持推理和汇总
2025: Agentic RAG   → Agent自主决定何时检索、检索什么
2026: Multimodal RAG → 支持图文、表格、视频的统一检索

RAG架构的关键组件

一个生产级RAG系统通常包含以下环节：

1. 文档解析：PDF/Word/HTML → 结构化文本，OCR处理扫描件
2. 文本分块：按语义边界切分（而非固定字数），保留上下文完整性
3. 向量化：使用Embedding模型将文本块转为向量表示
4. 向量存储：存入向量数据库（Milvus/Weaviate等）
5. 混合检索：向量检索 + 关键词检索（BM25）的融合排序
6. 重排序：使用Cross-encoder对检索结果精排
7. 上下文注入：将Top-K结果注入提示词
8. 生成与引用：模型生成回答并标注信息来源

GraphRAG：从检索到推理

传统RAG擅长回答"事实性问题"（"某法规的第3条是什么？"），但在需要汇总、推理的场景中表现不佳。GraphRAG通过构建知识图谱解决这个问题：

• 从文档中抽取实体（公司、人物、法规）和关系（收购、合规、适用）
• 构建图结构存储，支持多跳推理
• 适合回答"这个行业的头部公司之间有什么关联？"这类总结性问题

Agentic RAG：让检索变智能

Agentic RAG将Agent的自主决策能力引入RAG流程。模型不再是被动接收检索结果，而是可以：

• 判断是否需要检索（已有足够信息就不检索）
• 决定检索什么（将用户问题拆解为多个子查询）
• 评估检索结果质量（不够就换个策略重新检索）
• 跨多个知识库联合检索

Agent：从对话到自主执行

如果说RAG解决的是"知识"问题，Agent解决的就是"行动"问题。AI Agent不只是回答问题的聊天机器人，而是能够自主规划任务、调用工具、执行操作、反馈结果的"数字员工"。

Agent的核心架构

用户请求
   ↓
┌──────────────┐
│   规划器      │ → 将复杂任务拆解为子任务
│  (Planner)   │
└──────┬───────┘
       ↓
┌──────────────┐
│   执行器      │ → 依次执行子任务
│  (Executor)  │    调用工具/API
└──────┬───────┘
       ↓
┌──────────────┐
│   反思器      │ → 评估执行结果
│  (Reflector) │    判断是否需要重试
└──────────────┘
       ↓
   返回结果

Agent框架选型（2026年）

生产环境推荐 LangGraph：它的状态机设计让Agent的行为可预测、可调试、可中断——这对企业级系统至关重要。

工具调用（Tool Use）

Agent的"手"是工具。一个行业Agent通常需要以下工具集：

• 数据库查询：SQL查询工具，检索业务数据
• API调用：对接内部系统（ERP、CRM、OA）
• 文档处理：读取/生成文档
• 计算工具：财务计算、统计分析
• 外部搜索：联网查询最新信息
• 代码执行：运行Python脚本处理数据

Multi-Agent系统

复杂业务场景下，单一Agent往往不够用。Multi-Agent系统通过角色分工协作解决问题：

• 金融场景：风控Agent + 合规Agent + 审批Agent 协同完成贷款审批
• 法律场景：检索Agent + 审查Agent + 撰写Agent 协同完成合同审查
• 客服场景：意图识别Agent + 知识库Agent + 工单Agent 协同处理客户问题

微调：让模型学会行业语言

当提示词工程和RAG无法满足精度要求时，微调（Fine-tuning）是下一个选项。微调不是从零训练模型，而是在已有模型基础上注入行业知识。

微调方法对比

什么时候需要微调？

不是所有场景都需要微调。遵循以下决策路径：

1. 先试提示词工程 → 如果满足需求，停止
2. 再试RAG → 如果满足需求，停止
3. 再试RAG + 提示词优化 → 如果满足需求，停止
4. 最后才考虑微调

微调的典型适用场景：

• 模型需要学习行业特有的输出格式（如法律文书、医疗报告）
• 模型需要在特定任务上达到专家级精度（如合同风险识别）
• 模型需要理解行业术语和缩写（如金融领域的"承兑汇票""质押回购"）

微调技术细节

2026年主流微调方案是 LoRA（Low-Rank Adaptation）：只训练模型参数的极小部分（低秩矩阵），在保持效果的同时大幅降低计算成本。QLoRA在LoRA基础上引入量化，进一步将显存需求降低4倍，使7B模型微调成本降至$5以下²。

训练数据准备的关键原则：

• 质量 > 数量：1000条高质量样本胜过10000条噪声数据
• 格式一致：所有样本遵循统一的输入-输出格式
• 覆盖全面：覆盖目标场景的各种边界情况

多模态融合

行业场景不只是文本。制造业的质检图片、医疗的CT影像、法律的证据视频——这些都需要多模态能力。

行业多模态的典型组合：

多模态融合的技术路线：

• 统一Embedding：将不同模态映射到同一向量空间
• 跨模态检索：用文本查询图片，或用图片查询文本
• 多模态推理：结合图文信息进行综合判断（如"这张CT影像中是否有异常？"）

2.2 部署架构模式

技术选型之后，下一个关键决策是部署架构。不同的行业、不同的安全要求，对应不同的部署模式。

公有云 API 调用

最简单的部署方式：直接调用模型供应商的API。

适用场景：内部工具、低敏感度数据、快速验证

架构示意：

用户请求 → 应用服务器 → 模型供应商API → 返回结果
              ↑
         知识库(RAG)

注意事项：

• 数据经过第三方，需确保不包含敏感信息
• API延迟受网络影响，不适合实时性要求极高的场景
• 成本随使用量线性增长，高频场景可能很贵
• 供应商可能更新模型版本，导致输出不稳定

私有化部署

将模型部署在企业自己的服务器或私有云上。金融、政务、医疗等行业通常强制要求私有化。

适用场景：高敏感数据、合规要求、高频使用（成本优势）

架构示意：

用户请求 → 负载均衡 → 推理集群(GPU服务器)
              ↑              ↑
           前端应用      模型文件(本地)
              ↑
         知识库(本地向量数据库)

私有化部署的关键考量：

混合云架构

将敏感数据的处理留在本地，非敏感处理交给云端——兼顾安全和弹性。

                    ┌─── 云端(弹性扩展) ───┐
                    │                      │
用户请求 → 智能路由 │  通用对话/文本生成    │
                    │                      │
                    └─── 本地(安全合规) ───┘
                           │
                    敏感数据处理
                    行业知识库查询
                    微调模型推理

适用场景：大部分企业级场景，特别是既需要数据安全又需要弹性算力的场景。

信创环境适配

在中国市场，特别是央国企和政务场景，信创（信息技术应用创新）环境适配是硬性要求。

信创适配的核心工作：

• 国产GPU：华为昇腾910B/310、寒武纪、摩尔线程等
• 国产操作系统：统信UOS、银河麒麟
• 国产数据库：达梦、人大金仓、OceanBase
• 国产中间件：东方通、宝兰德

2025-2026年，国产GPU的推理性能已有显著提升，华为昇腾910B在主流7B模型推理场景下已达到可用水平。

2.3 工程化基础设施

模型和部署模式确定之后，还需要一套工程化基础设施来支撑生产级运行。

向量数据库选型

向量数据库是RAG系统的核心基础设施。2026年主流产品对比：

选型建议：

• 数据敏感（金融/政务）：选Milvus或Weaviate，支持私有化部署
• 快速起步：Pinecone或Chroma
• 已有PG基础设施：pgvector，零额外运维

数据管线

行业数据从原始形态到可用知识库，需要经过完整的数据管线：

原始数据               处理步骤               输出
───────               ────────              ──────
PDF/Word/HTML  ──→  文档解析/OCR     ──→  结构化文本
数据库/Excel   ──→  数据清洗/格式化   ──→  标准化文本
API/网页       ──→  爬取/去重        ──→  干净文本
                              ↓
                    文本分块(Chunking)
                              ↓
                    向量化(Embedding)
                              ↓
                    存入向量数据库

文本分块策略

分块是数据管线中最影响RAG质量的环节：

一个实用技巧：保留元数据。每个文本块应附带来源文档名、页码、章节标题等元数据，用于后续的精准检索和引用标注。

Embedding模型选择

可观测性

生产级系统必须具备可观测性——你知道系统在做什么、做得好不好、哪里出了问题。

三层可观测性架构：

┌─────────────────────────────────┐
│  业务层：回答质量、用户满意度       │
│  (准确率、幻觉率、引用命中率)       │
├─────────────────────────────────┤
│  应用层：链路追踪、性能指标         │
│  (延迟、吞吐量、检索召回率)         │
├─────────────────────────────────┤
│  基础设施层：硬件监控              │
│  (GPU利用率、显存、网络)           │
└─────────────────────────────────┘

关键指标：

工具推荐：

• LangSmith：LangChain生态的追踪和评估平台
• Langfuse：开源替代，支持自部署
• Phoenix (Arize)：LLM可观测性专项工具
• Prometheus + Grafana：基础设施监控标配

2.4 本章小结

本章系统梳理了行业大模型的技术架构全景：

1. 核心技术栈：基座模型选型是起点，提示词工程是基础，RAG是行业落地首选，Agent实现从对话到行动的跃迁，微调在精度不够时出场，多模态融合应对非文本场景。
2. 部署架构：公有云API适合快速验证，私有化部署满足数据安全要求，混合云兼顾安全与弹性，信创适配是中国市场的特殊需求。
3. 工程化基础设施：向量数据库是RAG的核心，数据管线决定知识库质量，可观测性保障生产级运行。

技术架构没有"最佳方案"，只有"最适合的方案"。选择的关键在于：先明确业务需求和安全约束，再匹配技术方案。

下一章将进入落地方法论——有了技术工具箱，如何科学地推进一个行业大模型项目从0到1。

延伸阅读

• 从RAG到Context：2025年RAG技术年终总结 — RAG技术演进全景，从Advanced RAG到Agentic RAG。
• LangGraph vs CrewAI vs AutoGen: Agent框架选型 — 2026年主流Agent框架对比。
• LLM Fine-tuning Complete Guide — LoRA/QLoRA/RLHF/DPO全覆盖的微调指南。
• Best Vector Databases in 2026 — 向量数据库完整对比。
• Best Open Source LLM for Enterprise Deployment — DeepSeek-V3/Qwen3/GLM-4.5企业级对比。