1. 先搞清楚“AI工程”到底在解决什么问题

如果你在技术社区里看到“AI工程”这个词，第一反应可能是“这又是一个新概念吗？”。实际上，它指向的是一个非常具体且正在发生的转变： 如何把那些在Jupyter Notebook里跑通的、充满不确定性的AI模型和实验，变成稳定、可靠、可维护、能持续交付的软件系统。

这不是一个空泛的标题。过去几年，大家卷模型、卷论文、卷Prompt，但真要把一个AI能力集成到产品里，会发现从原型到生产之间隔着巨大的鸿沟。模型服务化怎么做？版本如何管理？Prompt怎么迭代和测试？数据漂移了怎么监控？这些才是让AI项目真正产生价值，而不是停留在演示PPT上的关键。所谓的“AI工程核心技能图谱”，就是一张帮你系统化填补这道鸿沟的地图。它不是为了罗列所有AI算法，而是聚焦于 工程化落地 所需的技能栈。

所以，这篇文章适合两类人看：一是已经会用一些AI工具（比如调用API、跑开源模型）但不知道如何将其产品化的开发者；二是负责技术架构、需要引入AI能力的工程师或技术负责人。最值得关注的不是图谱里有多少个技能点，而是它帮你建立的一套从实验到生产的 系统性工程思维 。

2. 技能图谱的四个核心层次：从基础设施到业务价值

一个完整的AI工程技能体系，可以自上而下分为四个层次。理解这个结构，比死记硬背具体工具更重要。

2.1 第一层：AI基础设施与计算工程

这是地基。没有稳定、高效、成本可控的计算资源，一切上层应用都是空中楼阁。这一层关注的是“让AI模型能跑起来，并且跑得好”。

• 硬件与算力管理 ：不仅仅是知道需要GPU。你需要理解不同任务（训练、微调、推理）对显存、内存、CPU的核心需求差异。例如，大模型推理可能更关注显存带宽和低延迟，而批量数据处理则可能更依赖CPU和高速IO。你需要能评估是使用云上按需实例、抢占式实例，还是维护自己的物理机集群，并做好成本核算。
• 容器化与编排 ：Docker是标配，但关键在于如何为AI负载优化镜像。比如，如何构建包含CUDA、cuDNN以及特定深度学习框架的基础镜像，如何通过分层构建减少镜像体积，加速拉取和启动。Kubernetes则是生产级部署的核心，你需要掌握如何编写适合AI工作负载的Deployment、StatefulSet（用于有状态的服务如向量数据库），以及如何利用Resource Quotas、PriorityClasses来管理集群资源，避免推理任务被训练任务“饿死”。
• 模型服务化框架 ：这是将模型封装成API的关键。除了广为人知的TensorFlow Serving、TorchServe，还有更现代的 Triton Inference Server （NVIDIA出品，支持多框架后端和动态批处理，性能优化极佳）和 Ray Serve （适合构建复杂的多模型推理管道）。选择时，要评估其对模型格式的支持、并发性能、动态批处理能力以及监控集成度。

2.2 第二层：MLOps与模型生命周期管理

这一层是AI工程的“流水线”，确保模型从诞生到退役的整个过程可控、可追溯、可重复。MLOps不是简单的CI/CD加上模型，而是一套专门的方法论。

• 实验追踪与版本控制 ：模型训练不只是代码，还包括超参数、数据集版本、环境配置和评估指标。工具如 MLflow 、 Weights & Biases (W&B) 、 DVC 就是为此而生。你需要建立规范：每次实验必须记录完整的上下文，确保任何结果都能被精确复现。这比“我的模型准确率95%”这句话有价值得多。
• 自动化训练流水线 ：当数据更新或需要定期重新训练模型时，手动操作是不可靠的。你需要用 Kubeflow Pipelines 、 Airflow 或 MLflow Projects 来构建自动化流水线。流水线应包含数据验证、特征工程、模型训练、评估、以及将达标模型自动推送到模型仓库的环节。
• 模型注册与部署 ：模型仓库（如MLflow Model Registry、Hugging Face Hub）是模型的“单一可信源”。在这里，模型经历从Staging到Production的状态流转，并与特定的代码、数据版本绑定。部署时，要实现蓝绿部署或金丝雀发布，以便平滑升级和快速回滚。
• 监控与可观测性 ：模型上线不是终点。你需要监控：
  • 技术指标 ：API延迟、吞吐量、错误率、GPU利用率。
  • 业务/模型指标 ：预测结果的分布变化（数据漂移）、模型准确率/性能下降（概念漂移）。工具如 Evidently AI 、 Aporia 或自建监控看板至关重要。

2.3 第三层：应用开发与集成模式

模型作为服务提供能力后，如何被业务系统消费？这一层关注集成模式和用户体验。

• API设计与治理 ：设计稳定、易用的推理API。考虑输入输出格式（JSON、Protobuf）、认证鉴权（API Keys, OAuth）、限流熔断、以及详细的错误码定义。使用API网关（如Kong, APISIX）进行统一管理。
• 提示工程与上下文管理 ：对于大语言模型应用，Prompt就是新的“代码”。需要像管理代码一样管理Prompt：版本化、A/B测试、评估其效果。同时，设计高效的 上下文工程 方案，如何从知识库中检索、组装最相关的信息放入Prompt，是决定应用效果的核心。
• AI Agent与工作流编排 ：当单一模型调用无法完成任务时，需要AI Agent。Agent能理解目标、调用工具（搜索、计算、执行代码）、进行规划。框架如 LangChain 、 LlamaIndex 、 Semantic Kernel 提供了构建Agent的基础。关键在于设计清晰的任务分解逻辑和工具调用规范，并处理好可能出现的“幻觉”问题。
• 前端与交互 ：根据场景，可能需要开发聊天界面、文生图界面、语音交互界面等。考虑流式输出（SSE/WebSocket）以提升用户体验。

2.4 第四层：质量、安全与合规

这是保障系统长期健康运行的“免疫系统”，往往被早期项目忽略，但却是企业级应用的门槛。

• AI测试 ：不同于传统软件测试。包括：
  • 模型评估 ：在保留的测试集和代表边缘案例的数据集上进行评估。
  • 对抗性测试 ：故意构造输入，测试模型的鲁棒性。
  • Prompt注入测试 ：对于LLM应用，测试其是否容易被用户输入带偏或泄露系统Prompt。
  • 集成测试 ：测试整个AI服务管道，包括上下文检索、Prompt组装、模型调用、后处理。
• 安全与隐私 ：确保训练数据不包含敏感信息，推理数据不被泄露。了解差分隐私、联邦学习等隐私保护技术。对模型文件本身进行安全扫描，防止恶意代码。
• 合规与审计 ：特别是在金融、医疗等领域，需要模型决策可解释。可能用到LIME、SHAP等可解释性工具。同时，记录所有模型决策的数据和版本，以满足审计要求。

3. 从零搭建一个可实践的AI工程化原型

光有图谱不够，我们需要一个具体的“最小可行工程化”原型来串联理解。下面以部署一个开源大语言模型（LLM）并提供问答服务为例，展示如何应用上述技能。

3.1 环境与工具选型

我们选择在单台具备GPU的Linux服务器上实践，这更贴近中小团队的真实起点。

• 基础环境 ：Ubuntu 20.04/22.04 LTS， Docker， Docker Compose。
• 模型服务 ：选用 vLLM 或 TGI 。它们专为LLM推理优化，支持连续批处理、PagedAttention等，吞吐量和延迟远优于原生PyTorch部署。这里选vLLM。
• API与业务逻辑 ：使用 FastAPI ，轻量且异步支持好。
• 实验追踪 ： MLflow （轻量，够用）。
• 向量数据库 ： Qdrant （Docker部署，性能不错）。
• 编排 ：初期用Docker Compose管理所有服务。

3.2 第一步：模型服务化与基础API

目标是先让模型跑起来，并提供最基础的生成接口。

# 1. 准备模型（以Qwen1.5-7B-Chat为例）
# 从ModelScope或Hugging Face下载模型至本地目录，如 /data/models/Qwen1.5-7B-Chat

# 2. 使用Docker启动vLLM服务
# docker-compose.yml 部分内容
version: '3.8'
services:
  vllm-server:
    image: vllm/vllm-openai:latest
    container_name: vllm-qwen
    runtime: nvidia # 需要NVIDIA Container Toolkit
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    volumes:
      - /data/models:/data/models # 挂载模型目录
    command: [
      "--model", "/data/models/Qwen1.5-7B-Chat",
      "--served-model-name", "qwen-7b-chat",
      "--api-key", "your-api-key-here", # 建议设置API密钥
      "--port", "8000",
      "--max-model-len", "4096"
    ]
    ports:
      - "8000:8000"

启动后，vLLM会提供一个兼容OpenAI API的端点 http://localhost:8000/v1 。你可以立即用curl测试：

curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-api-key-here" \
  -d '{
    "model": "qwen-7b-chat",
    "prompt": "中国的首都是",
    "max_tokens": 10
  }'

但这只是第一步。生产环境不能直接暴露这个端口给业务方，我们需要一个业务层。

3.3 第二步：构建业务应用层与上下文工程

现在用FastAPI构建一个业务应用，它接收用户问题，从知识库检索上下文，组装Prompt，再调用vLLM。

# main.py
from fastapi import FastAPI, HTTPException, Depends
from pydantic import BaseModel
import httpx
import os
from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue

app = FastAPI(title="AI知识库问答服务")

# 依赖项：获取vLLM客户端和向量数据库客户端
class ServiceClients:
    def __init__(self):
        self.vllm_client = httpx.AsyncClient(base_url="http://vllm-server:8000/v1", timeout=30.0)
        self.qdrant_client = QdrantClient(host="qdrant", port=6333)

def get_clients():
    return ServiceClients()

# 数据模型
class QueryRequest(BaseModel):
    question: str
    user_id: str = None

class QueryResponse(BaseModel):
    answer: str
    sources: list[str] # 引用来源

@app.post("/query", response_model=QueryResponse)
async def query_knowledge_base(
    request: QueryRequest,
    clients: ServiceClients = Depends(get_clients)
):
    # 1. 检索上下文
    search_result = clients.qdrant_client.search(
        collection_name="company_docs",
        query_vector=embed_text(request.question), # 假设有embedding函数
        limit=3
    )
    
    contexts = [hit.payload["text"] for hit in search_result]
    source_ids = [hit.payload["doc_id"] for hit in search_result]
    
    # 2. 组装Prompt（上下文工程的核心）
    prompt_template = """基于以下已知信息，简洁和专业地回答问题。如果无法从中得到答案，请说“根据已知信息无法回答该问题”。
    
已知信息：
{context}
    
问题：
{question}
    
请用中文回答："""
    
    filled_prompt = prompt_template.format(
        context="\n\n".join(contexts),
        question=request.question
    )
    
    # 3. 调用vLLM
    try:
        resp = await clients.vllm_client.post(
            "/chat/completions",
            json={
                "model": "qwen-7b-chat",
                "messages": [{"role": "user", "content": filled_prompt}],
                "temperature": 0.1, # 低温度，减少随机性
                "max_tokens": 500
            },
            headers={"Authorization": "Bearer your-api-key-here"}
        )
        resp.raise_for_status()
        result = resp.json()
        answer = result["choices"][0]["message"]["content"]
    except httpx.RequestError as e:
        raise HTTPException(status_code=503, detail=f"模型服务调用失败: {e}")
    
    # 4. 返回结果
    return QueryResponse(answer=answer, sources=source_ids)

# 将此FastAPI服务也加入docker-compose

这个步骤的关键在于 上下文工程 ：如何根据问题检索最相关的文档片段，并巧妙地将其嵌入Prompt。检索的质量直接决定了最终答案的准确性。

3.4 第三步：引入实验追踪与初步监控

现在，我们需要追踪每次问答的效果，特别是Prompt的变更和模型输出的评估。

# 在query函数中集成MLflow追踪
import mlflow

@app.post("/query")
async def query_knowledge_base(request: QueryRequest, ...):
    with mlflow.start_run(run_name="query_inference") as run:
        # 记录输入、使用的上下文、Prompt模板版本、模型参数
        mlflow.log_param("question", request.question)
        mlflow.log_param("retrieved_docs_count", len(contexts))
        mlflow.log_param("prompt_template_version", "v1.2")
        mlflow.log_param("temperature", 0.1)
        
        # ... 调用模型 ...
        
        # 记录输出和来源
        mlflow.log_param("answer", answer)
        mlflow.log_param("source_docs", source_ids)
        
        # 这里可以加入人工或自动评估分数（后续扩展）
        # mlflow.log_metric("relevance_score", score)
        
    return QueryResponse(...)

同时，在应用层添加基础的健康检查和指标端点（例如使用 prometheus_client ），并配置Grafana看板，监控QPS、延迟和错误率。

4. 技能图谱落地的关键：从原型到生产的挑战

把原型跑通只是第一步。真正考验“工程”能力的，是如何应对下面这些生产环境中的实际问题。

4.1 性能、成本与规模化

• 推理优化 ：
  • 量化 ：将FP16/BF16模型量化为INT8/INT4，能显著减少显存占用和提升推理速度，但会带来轻微精度损失。使用 GPTQ 、 AWQ 或vLLM内置的量化支持进行测试。
  • 批处理 ：利用vLLM/TGI的动态批处理，将多个请求合并计算，极大提升GPU利用率。你需要根据业务延迟要求调整最大批处理大小。
  • 模型蒸馏与剪枝 ：用更小的模型逼近大模型的效果，适合对延迟极度敏感的场景。
• 缓存策略 ：对于相同或相似的查询，结果是否可以缓存？可以使用Redis缓存最终的 answer ，或者更进一步，缓存中间层的 embedding 向量或检索结果。
• 多模型与路由 ：不同的问题可能由不同的专用小模型处理更高效（例如，分类问题用分类模型，摘要用摘要模型）。需要设计一个路由层，根据输入内容选择最合适的模型，实现成本与效果的平衡。

4.2 稳定性与可观测性

• 健康检查与熔断 ：业务应用（FastAPI服务）对vLLM服务的调用必须设置超时和重试机制。当vLLM服务连续失败时，应触发熔断，避免积压请求拖垮整个系统。可以使用 backoff 库实现指数退避重试。
• 全面的日志 ：日志不仅要记录错误，还要记录每次请求的完整轨迹：请求ID、用户ID、检索到的文档ID、使用的Prompt哈希、模型响应时间、Token用量等。这便于事后问题排查和效果分析。
• 监控与告警 ：
  • 基础设施 ：GPU显存使用率、GPU利用率、系统内存、磁盘IO。
  • 服务层 ：HTTP请求速率、延迟（P50, P95, P99）、错误率（4xx, 5xx）。
  • 模型层 ：输入Token分布、输出Token分布、首次Token延迟（Time to First Token）。
  • 业务层 ：用户反馈的“不满意”率、人工抽检的准确率。
• 混沌工程 ：主动注入故障（如模拟向量数据库超时、模型服务延迟飙升），测试系统的弹性和恢复能力。

4.3 数据与迭代循环

• 数据飞轮 ：生产系统产生的用户交互数据（问题、模型回答、用户反馈）是黄金。需要建立管道，安全地收集、脱敏、标注这些数据，用于持续评估模型效果和准备下一轮训练/微调数据。
• Prompt版本管理与A/B测试 ：将Prompt模板存储在数据库或配置中心，并赋予版本号。可以通过在请求头中传递 X-Prompt-Version 或根据用户分组，进行不同Prompt版本的A/B测试，用实际数据驱动Prompt优化。
• 模型版本回滚 ：当新模型版本上线后效果不佳时，必须能快速回滚到旧版本。这要求模型注册表和服务编排（如K8s）紧密集成，实现一键切换。

4.4 安全、合规与伦理

• 输入输出过滤与审查 ：在应用层设置内容安全过滤器，对用户输入和模型输出进行扫描，防止生成有害、偏见或不合规内容。这可能需要结合关键词过滤和基于小分类模型的二次判断。
• 权限控制 ：确保只有授权用户/服务可以访问模型API。API密钥需要轮换，不同密钥可对应不同的速率限制和访问权限。
• 可解释性与审计日志 ：对于关键决策（如信贷审批、内容推荐），需要记录模型做出此决策所依据的主要检索上下文和Prompt，提供一定的事后解释能力。

5. 个人学习路径与团队建设建议

面对如此庞大的技能图谱，个人和团队应该如何入手？

5.1 个人学习：从点到面，实战驱动

不要试图一次性学完所有东西。建议采用“T型”路径：

1. 纵向深入一个点 ：根据你当前的工作，选一个最相关的领域深入。如果你是后端开发，就先深入研究 模型服务化（vLLM/TGI）和API设计 ；如果你是算法研究员，就主攻 MLOps流水线（MLflow/Kubeflow）和实验管理 ；如果你是运维，就专注 容器化、K8s编排和监控 。
2. 通过项目横向拓展 ：找一个具体的项目（比如用LLM搭建一个内部知识库问答系统），强迫自己走完全流程：环境搭建 -> 模型部署 -> 应用开发 -> 简单监控。在项目中，你会自然遇到其他层次的问题，从而驱动你去学习。
3. 建立知识连接 ：每学一个新工具或概念，问自己三个问题：它属于技能图谱的哪一层？它解决的核心痛点是什么？它和我知道的另一个工具（如Docker和K8s的关系）是如何协作的？
4. 关注核心原理 ：比起追逐最新框架，理解底层原理更重要。例如，理解 动态批处理 为什么能提升吞吐，理解 向量检索 的近似最近邻算法，理解 量化 是如何工作的。这能让你在工具迭代中保持判断力。

5.2 团队建设：明确角色，建立流程

对于团队而言，关键是定义清晰的角色和协作流程，而不是要求每个人都是全才。

• AI/ML工程师 ：聚焦于模型本身。负责模型选型、训练、微调、评估，并产出符合服务化要求的模型文件。他们需要熟练掌握MLflow等实验追踪工具。
• 机器学习平台工程师 ：聚焦于基础设施和MLOps。负责搭建和维护模型训练集群、推理服务平台、特征仓库、流水线编排系统。他们是K8s、Docker、各种服务化框架的专家。
• 后端/应用开发工程师 ：聚焦于业务集成。负责开发调用AI服务的业务API，设计上下文检索逻辑，实现提示工程，并保障应用的高可用和安全性。
• 质量与安全工程师 ：聚焦于保障。负责设计AI测试用例，进行安全扫描和对抗测试，建立监控告警体系。

团队需要建立的核心流程包括： 模型上线评审会 （评估性能、安全、合规）、 事故响应机制 （特别是模型效果下降时）、以及定期的 技术债梳理 （如升级基础镜像、优化Prompt模板）。

AI工程的成熟度，最终体现在团队能否像发布普通软件一样，自信、平稳、可追溯地发布和迭代AI能力。这张技能图谱不是一份考试大纲，而是一张导航图，帮助你在从AI实验到AI产品的漫长航道上，避开暗礁，找到方向。