第 9 章驻场工程化技术栈:LLM 选型 / RAG / Agent / 推理 / 量化 / 可观测

本章一句话:FDE 在客户现场要搭一个能跑的 AI 系统,靠的是一套从模型到可观测的七层技术栈;本章给出 2026 年生产级选型与可照抄的命令/配置。

9.1 技术栈全景图:七层

一个完整的企业 AI 系统,FDE 需要打通七层技术栈:

7. 可观测与评估层   日志/追踪/监控/告警/eval
6. Agent 编排层     LangGraph/CrewAI/MCP/护栏
5. RAG 与检索层     向量库/嵌入/知识图谱/重排
4. 推理服务层       vLLM/TGI/TensorRT-LLM/量化
3. 模型层           闭源 API/开源权重/国产模型
2. 数据管道层       ETL/特征/增量同步/质量
1. 基础设施层       GPU/CPU/存储/网络/信创

FDE 不需要在每层都是专家,但必须能"端到端打通"——知道每一层选什么、怎么连、出了问题怎么查。这是 FDE 区别于纯算法工程师(专注 3、4 层)和纯应用工程师(专注 6 层)的地方。

9.2 模型层:LLM 选型

模型选型是 FDE 在 Design 阶段的第一个关键决策。2026 年的选型空间分三类:

闭源 API(海外)

GPT 系列(OpenAI)、Claude 系列(Anthropic)、Gemini(Google);
优势:能力最强、开箱即用;
劣势:数据出境(中国政企不可用)、成本高、依赖外部。

开源权重(可私有化)

Llama 系列(Meta)、Qwen 系列(阿里)、DeepSeek、Mistral、GLM(智谱);
优势:可私有化、可微调、成本低;
劣势:需自建推理、能力略逊顶尖闭源。

国产模型(中国政企首选)

通义千问(Qwen)、文心一言(百度)、豆包(字节)、智谱 GLM、DeepSeek、Kimi(月之暗面)、盘古(华为);
优势:信创合规、中文强、生态完善;
选型考量:能力、中文、推理成本、生态、合规。

选型决策框架

客户是否允许数据出境?→ 否则开源/国产私有化;
算力预算多少?→ 决定模型参数量(7B/14B/32B/72B);
中文为主?→ 优先国产模型(中文优化好);
是否需要微调?→ 选有完整微调工具链的(Qwen、Llama)。

量化(降低部署成本的关键) 大模型部署成本高,FDE 常用量化压缩:FP16 → INT8 → INT4。主流量化方案:

AWQ(Activation-aware Weight Quantization):精度损失小,广泛使用;
GPTQ:另一种权重量化;
bitsandbytes:易用的 INT8/INT4。

可照抄命令(Qwen2.5-7B AWQ 量化,常见于国产私有化部署):

bash

# 用 vLLM 直接加载已量化模型(推荐,生产用)
vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \
  --quantization awq \
  --dtype half \
  --max-model-len 8192

9.3 推理服务层:vLLM 为王

模型选好后,要把它变成"可调用的服务",这就是推理服务层。2026 年的生产级推理,基本绕不开几个选择:

vLLM:2026 事实标准

高吞吐(PagedAttention)、连续批处理、广泛模型支持;
几乎是开源推理的默认选择;
支持 AWQ/GPTQ 量化、张量并行。

TGI(Text Generation Inference,HuggingFace)

易用、生态好;
适合 HuggingFace 生态。

TensorRT-LLM(NVIDIA)

极致性能(NVIDIA 官方优化);
部署复杂、绑定 NVIDIA;
适合追求极致吞吐的场景。

推理选型建议

通用首选 vLLM;
已有 HuggingFace 栈 → TGI;
追求极致 + 全 NVIDIA → TensorRT-LLM。

可照抄命令(vLLM 起服务,生产级常用):
bash
# 启动 vLLM OpenAI 兼容 API 服务
vllm serve Qwen/Qwen2.5-14B-Instruct \
  --host 0.0.0.0 --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.9 \
  --enable-auto-tool-choice \
  --tool-call-parser hermes
起来后,用 OpenAI SDK 即可调用(base_url=http://localhost:8000/v1),业务代码零改动。

9.4 RAG 与检索层:让模型"懂"客户

RAG(检索增强生成)是企业 AI 系统的标配——它让通用模型拥有客户的私有知识。 这也是 FDCE(上下文工程)的核心实现。

RAG 的基本链路

文档 → 切分(chunking)→ 嵌入(embedding)→ 存入向量库
查询 → 嵌入 → 向量检索 → 取回相关片段 → 拼进 prompt → 模型生成

向量库选型(2026)

Milvus / Zilliz:国产开源,大规模、生产级,中国政企常用;
Qdrant:Rust 写的高性能,易部署;
Weaviate:功能全;
pgvector:基于 PostgreSQL,适合已有 PG 栈、数据量不大;
Elasticsearch / OpenSearch:传统搜索 + 向量,适合混合检索。

嵌入模型

bge 系列(智源,中文强,开源);
OpenAI text-embedding、Cohere embed;
国产:通义、智谱的嵌入模型。

进阶 RAG 技巧(FDE 进阶)

混合检索:向量 + 关键词(BM25),召回更全;
重排(rerank):用 reranker 对召回结果精排,精度提升明显;
查询改写/扩展:用 LLM 改写查询,提升召回;
知识图谱 RAG(GraphRAG):结构化知识,适合复杂关联;
分块策略:按语义/结构切分,而非固定长度。

可照抄命令(用 bge 嵌入 + Milvus,常见国产栈):

python

from FlagEmbedding import FlagModel
from pymilvus import MilvusClient

embedder = FlagModel('BAAI/bge-large-zh-v1.5', use_fp16=True)
client = MilvusClient(uri="http://localhost:19530")

docs = ["客户文档1", "客户文档2"]
vectors = embedder.encode(docs)
# 入库后,查询时 top-k 检索,拼进 prompt

9.5 Agent 编排层

第 8 章已详述 Agent 编排,这里补充技术栈要点:

编排框架:LangGraph(生产)/CrewAI(原型);
工具接口:MCP server(把企业系统暴露给 Agent);
护栏:Guardrails AI、NVIDIA NeMo Guardrails(输入输出过滤);
状态管理:LangGraph 的 checkpointing(持久化、可恢复);
HITL:LangGraph 原生支持 interrupt/resume。

MCP server 最小示例(把一个内部 API 暴露给 Agent):

python

# 用 Anthropic <abbr class="term" title="Anthropic 提出的 Agent 工具接口标准">MCP</abbr> SDK 暴露工具
from mcp.server.fastmcp import Fast<abbr class="term" title="Anthropic 提出的 Agent 工具接口标准">MCP</abbr>
mcp = FastMCP("customer-erp")

@mcp.tool()
def query_order(order_id: str) -> dict:
    """查询订单状态"""
    return call_internal_erp(order_id)  # 对接客户真实系统

if __name__ == "__main__":
    mcp.run()

9.6 数据管道层:70% 工作量在这

企业 AI 项目 70% 的工作量,在数据管道——这是 FDE 最容易低估、也最该重视的一层。

数据管道的典型环节

接入:从客户的 ERP/CRM/HIS/MES 等系统抽数据(批/流);
清洗:处理脏数据、缺失、不一致;
转换:格式统一、特征工程;
质量:数据质量监控(完整性、准确性、时效性);
增量:增量同步,保证实时性。

工具选型

批处理:Spark、Dask、Pandas(小数据);
流处理:Flink、Kafka Streams;
编排:Temporal、Prefect、Airflow(Stord 等 FDE JD 明确要求);
ELT:dbt(SQL 转换);
数据质量:Great Expectations、Soda。

FDE 的现实:客户的真实数据,远比想象的脏、乱、散。一个优秀的 FDE,数据工程能力往往比模型能力更重要——因为模型现成,数据要自己理。

9.7 可观测与评估层:上线后不抓瞎

可观测(observability)和评估(eval),是系统上线后 FDE 能否"睡好觉"的关键。

可观测三件套

日志(logging):记录关键事件、错误;
追踪(tracing):记录每个请求的完整链路(LLM 调用、工具调用、检索);
指标(metrics):QPS、延迟、错误率、token 消耗、成本。

LLM 专用可观测

LangSmith(LangChain):追踪 LLM/Agent 链路;
Langfuse:开源 LLM 可观测;
Phoenix(Arize):LLM 评估与可观测;
OpenTelemetry:通用标准,可对接。

评估(eval)

离线 eval:构建评估集,量化模型/系统效果(准确率、召回、事实一致性);
在线 eval:线上 A/B、用户反馈、bad case 分析;
LLM-as-judge:用强模型评判输出质量(注意成本和偏差)。

关键原则:评估前移(eval-driven)。在 Design 阶段就定义评估集,Engineer 阶段持续评估,而不是上线才知道效果。这是 2026 年 LLM 工程的共识。

9.8 部署形态:云 / 私有 / 边缘 / 信创

FDE 要根据客户约束选择部署形态:

云部署

公有云(阿里云/腾讯云/AWS/Azure);
优势:快、弹性;
劣势:数据出境/合规风险(部分客户不可用)。

私有化部署

客户自建机房/私有云;
优势:数据不出域、合规;
劣势:运维成本高、扩容难。

边缘部署

工厂、门店、设备端(如视觉质检相机旁);
优势:低延迟、断网可用;
劣势:算力受限。

信创部署(中国)

国产芯片(鲲鹏/昇腾/飞腾/海光)+ 国产 OS(麒麟/统信)+ 国产数据库 + 国产模型;
政务、金融、能源、央企硬要求;
FDE 要做全栈适配验证。

可照抄命令(docker-compose 一键起 RAG 栈,私有化常用):

yaml

# docker-compose.yml: vLLM + Milvus + 应用
services:
  vllm:
    image: vllm/vllm-openai:latest
    command: --model Qwen/Qwen2.5-7B-Instruct --port 8000
    deploy:
      resources:
        reservations:
          devices: [{driver: nvidia, count: all}]
  milvus:
    image: milvusdb/milvus:latest
  app:
    image: my-rag-app:latest
    depends_on: [vllm, milvus]

9.9 技术选型决策框架

面对这么多技术,FDE 需要一个决策框架,避免"选择困难":

决策五问

合规约束:数据能否出境?→ 决定云/私有/信创;
算力预算:有多少 GPU?→ 决定模型大小和量化;
延迟要求:实时还是准实时?→ 决定部署形态和批处理;
团队能力:客户/自己团队能维护什么?→ 决定技术复杂度;
演进空间:未来要扩展吗?→ 决定架构灵活性。

选型原则

够用就好:不追求最新最强,选"足够好且能落地";
生态优先:选有社区、有文档、有人会的;
可观测优先:宁可功能少,不可不 observability;
安全前置:涉及资金/数据/对外,HITL + 护栏不可省。

本章小结

企业 AI 系统是七层栈:基础设施→数据管道→模型→推理→RAG→Agent→可观测;
模型层:闭源 API/开源权重/国产,按合规+算力+中文选型,量化降本(AWQ);
推理层:vLLM 是 2026 事实标准,TGI/TensorRT-LLM 备选;
RAG 层:向量库(Milvus/Qdrant/pgvector)+ 嵌入(bge)+ 重排 + 混合检索 + GraphRAG;
Agent 层:LangGraph/CrewAI + MCP + 护栏 + HITL;
数据管道占 70% 工作量,Temporal/Prefect/Airflow 编排;
可观测:日志/追踪/指标 + LLM 专用(LangSmith/Langfuse)+ eval 前移;
部署:云/私有/边缘/信创按约束选;docker-compose 一键起栈;
选型决策五问:合规/算力/延迟/团队能力/演进空间。

本章来源😮'Reilly《AI Agents Stack 2026》、vLLM/Milvus/LangGraph 官方文档、Stord FDE JD(Temporal/Prefect/Airflow)、OWASP MCP Top 10、本书第 8 章及第三篇各行业技术落地章节、用户库《FDE工程化工具链》《fde-delivery 技能包 80-120 深度手册》。

9.1 技术栈全景图:七层 ​

9.2 模型层:LLM 选型 ​

9.3 推理服务层:vLLM 为王 ​

9.4 RAG 与检索层:让模型"懂"客户 ​

9.5 Agent 编排层 ​

9.6 数据管道层:70% 工作量在这 ​

9.7 可观测与评估层:上线后不抓瞎 ​

9.8 部署形态:云 / 私有 / 边缘 / 信创 ​

9.9 技术选型决策框架 ​

本章小结 ​