生产环境中跑大模型应用的人，最近几年都有一个共同感受——从 demo 到上线之间有一道巨大的沟。RAG 检索不准、agent 行为不可控、评估体系缺失、上线后延迟和成本飙升……这些问题不是靠换一个模型就能解决的。InfoQ 刚上线了一个为期五周的在线 AI Engineering 认证项目，面向已经在生产系统里做 AI 的资深从业者，覆盖 RAG、agent、AI 平台、评估、可靠性以及工程权衡。这不是入门课，而是给"已经在坑里的人"准备的体系化梳理。
认证覆盖的核心技术域
项目把内容拆成几个硬核方向，每个都直指生产环境的痛点：
RAG（检索增强生成）——不只是"向量搜索 + 拼接 prompt"，而是从 chunk 策略、embedding 选型、检索召回率优化到 rerank 管线的完整工程链路。生产级 RAG 的失败往往不在生成端，而在检索端：召回率不够、chunk 边界切错、索引更新不及时。
Agent 系统——从单工具调用到多步规划、工具编排、错误恢复。认证关注的是 agent 的可控性和可观测性——怎么让 agent 不跑飞、怎么在失败时优雅降级、怎么追踪决策链路。
评估（Evals）——这是目前最被低估的环节。没有评估，所有优化都是盲人摸象。认证覆盖从离线基准测试到在线 A/B 评估的完整框架，包括如何设计评估集、如何定义 metric、如何避免评估集泄漏。
可靠性与运营权衡——延迟、成本、准确率之间的三角博弈；降级策略；多模型 fallback；缓存设计；监控与告警。
评估先行：一个可运行的 RAG 评估框架示例
下面是一个最小但可扩展的 RAG 评估脚本，用 RAGAS 框架对检索和生成质量做量化评估。你可以直接改造接入自己的 RAG 管线。
# rag_eval.py — 最小 RAG 评估脚本
# 依赖：pip install ragas datasets openai
from ragas import evaluate
from ragas.metrics import (
context_relevancy, # 检索上下文与问题的相关性
faithfulness, # 生成内容是否忠实于检索上下文
answer_relevancy, # 回答与问题的相关性
)
from datasets import Dataset
# 1. 构造评估数据集 — 替换成你自己的 QA 对和检索结果
eval_data = {
"question": [
"Kubernetes 中 HPA 的冷却期默认值是多少？",
"Python 的 GIL 在多线程场景下有什么影响？",
],
"answer": [
"Kubernetes HPA 的 cooldown 默认值在 v1 中是 5 分钟，v2 中可通过 --horizontal-pod-autoscaler-downscale-stabilization 调整。",
"GIL 使得同一时刻只有一个线程执行 Python 字节码，CPU 密集型多线程无法真正并行，但 I/O 密集型场景影响较小。",
],
"contexts": [
["HPA cooldown period defaults to 5 minutes in autoscaling/v1..."],
["The Global Interpreter Lock (GIL) is a mutex that protects access to Python objects..."],
],
"ground_truth": [
"HPA v1 默认冷却期 5 分钟，v2 可自定义。",
"GIL 限制多线程 CPU 并行，I/O 场景影响有限。",
],
}
dataset = Dataset.from_dict(eval_data)
# 2. 运行评估 — 需要 OpenAI API key（RAGAS 内部用 LLM 做 judge）
import os
os.environ["OPENAI_API_KEY"] = "sk-your-key-here"
result = evaluate(
dataset,
metrics=[context_relevancy, faithfulness, answer_relevancy],
)
# 3. 输出结果
print(result)
# 预期输出类似：
# {'context_relevancy': 0.82, 'faithfulness': 0.91, 'answer_relevancy': 0.87}
改造要点：
- 把
eval_data替换成从你的 RAG 系统实际采集的 question / retrieved contexts / generated answer，ground_truth 由人工标注或用高质量模型生成。 - 评估集规模建议至少 50-100 条，覆盖典型查询和边界 case。
context_relevancy低说明检索环节有问题——优化 chunk 或 rerank；faithfulness低说明模型在幻觉——加强 prompt 约束或换模型；answer_relevancy低说明生成偏离问题——调整 prompt 模板。- 生产环境建议每周自动跑一次，把指标写入监控面板，和延迟、成本指标并列。
Agent 可控性：不是加工具就完事
认证中 agent 部分强调的核心观点是：agent 的价值不在于能调多少工具，而在于决策链路的可追踪和可干预。生产级 agent 需要解决三个问题：
- 规划约束——用 system prompt 或结构化 planner 限制 agent 的行动空间，避免无限循环或越权操作。
- 失败恢复——工具调用失败时，agent 应该有明确的 fallback 路径（重试、换工具、降级为直接回答），而不是反复重试直到 token 烧完。
- 观测链路——每次 agent 决策都应记录：选择了哪个工具、输入什么、输出什么、为什么做这个选择。这不是日志装饰，是生产系统必须的审计能力。
一个简单的 agent 决策追踪结构可以这样设计：
# agent_trace_schema.yaml — agent 决策追踪的最小结构
trace:
run_id: "a1b2c3"
task: "查询用户订单状态并返回摘要"
steps:
- step: 1
thought: "需要先获取用户 ID，再查订单"
tool: "lookup_user"
input: { email: "user@example.com" }
output: { user_id: "U-789" }
status: success
latency_ms: 120
- step: 2
thought: "有了 user_id，调用订单查询"
tool: "query_orders"
input: { user_id: "U-789" }
output: { orders: [...] }
status: success
latency_ms: 340
- step: 3
thought: "汇总订单信息返回给用户"
tool: null
output: "您有 3 笔订单..."
status: success
total_tokens: 1850
total_latency_ms: 460
fallback_triggered: false
把这个结构写入数据库或日志系统，你就能回答"agent 为什么做了这个决定"以及"哪一步出了问题"。
工程权衡：没有银弹，只有取舍
认证的最后一个模块聚焦运营层面的权衡，这是很多团队从 demo 阶段跃入生产时最缺的视角：
- 延迟 vs 质量——大模型推理慢，但输出质量高；小模型快，但容易出错。生产系统往往需要多模型分级：简单问题走小模型，复杂问题路由到大模型。
- 成本 vs 覆盖——全量用 GPT-4 级模型，成本可能撑不住；用缓存 + 语义相似度匹配历史回答，可以砍掉 30-50% 的调用量，但缓存命中率取决于查询分布。
- 可靠性 vs 灵活性——硬编码流程可靠但死板；agent 灵活但不可控。很多生产系统选择"半结构化"：关键路径硬编码，非关键环节允许 agent 自主决策。
是否值得投入：几条判断标准
这个认证面向的是已经在做生产 AI 系统的人，不是刚入门的初学者。如果你在犹豫是否参加，可以用下面这个清单自测：
- ✅ 你已经在生产环境部署了 RAG 或 agent，但评估体系不完善 → 认证的 eval 模块会直接补上这块。
- ✅ 你团队有多个 AI 服务上线，但缺乏统一的可靠性框架 → 可靠性与权衡模块值得投入。
- ✅ 你对 RAG 和 agent 有实践经验，但知识碎片化，需要体系化梳理 → 五周的结构化课程比零散读文章效率高。
- ❌ 你还没在生产环境跑过 AI 应用，主要在实验阶段 → 先把东西上线，再回来考虑认证。
认证本身不会让你一夜变成 AI 工程专家，但它把生产级 AI 系统最关键的几个技术域拉成了一条线——评估、可靠性、权衡——这些恰恰是 demo 和生产之间最容易被忽略的环节。