理解 AI 产品生命周期 · AI 工程课程

AI 产品的定义

AI 产品是结合大语言模型（LLM）、检索增强生成（RAG）与智能体系统等技术解决复杂现实问题的应用或服务。由于生成式模型的输出天然具有不确定性，这类产品通常依赖精细的数据检索策略与提示词工程，并需要通过持续评估来保障输出结果的稳定性与实用价值。

AI 产品生命周期概览

AI 产品生命周期涵盖了从设计、构建、部署到维护的结构化迭代过程，重点应对生成式 AI 在行为不确定性、复杂评估标准以及生产可观测性等方面的工程挑战。

AI 产品生命周期的主要阶段

1．定义问题

构建智能体系统的第一步是界定待解决的具体问题。智能体通常利用大语言模型或生成式模型处理复杂的自动化与业务场景，问题本身必须边界清晰且对齐业务目标。立项时需重点评估：

该问题更适合用 AI 解决，还是用传统确定性软件解决？
最终用户是谁？
存在哪些边界情况（Edge Cases）？
系统可接受的行为边界在哪里？

参与角色：AI 产品经理、领域专家、AI 工程师。

重要提示：许多 AI 项目折戟的根源在于选错了问题。问题本身的合理性与模型质量一样，都需要在起步阶段严格评估。

2．构建原型

需要考虑：

借助 Notebook 或无代码工具，配合小规模数据集与现成模型快速验证。
这一阶段以学习和验证为重点，性能优化可以在后续阶段开展。
完整记录实验过程与结论，避免后续迭代重复踩坑。
密集测试不同提示词，并调研可复用的现成工具（如成熟的语音转文字平台）。

参与角色：AI 产品经理、AI 工程师。

重要提示：原型阶段的核心目标是降低技术风险。纸面上合理的方案，仍需通过实际运行来验证长期的技术可行性。

3．定义性能指标

关键问题包括：

明确优化目标（输出指标）：确定最终希望改善的业务结果（如减少人工投入、提升用户满意度或加快交付速度），将其作为北极星输出指标。
拆解驱动指标（输入指标）：找到能够直接推动输出指标改善的输入指标（例如缩短客服工单的平均解决时长）。
对齐衡量口径：AI 应用直接优化输入指标，业务侧则通过输出指标衡量最终价值。

参与角色：AI 产品经理、AI 工程师、业务相关人员。

重要提示：若指标定义不清，项目很容易因无法证明业务价值而被下调优先级。进入开发前，必须与业务团队对齐指标口径并留存书面记录。

4．定义评估规则

需要考虑：

智能体系统通常由多个相互衔接的 LLM 调用组成拓扑结构。
需为拓扑结构中的每个节点分别准备评估数据集，覆盖典型输入与预期输出。
明确划定不可接受的输出红线，包括有害内容、事实幻觉与不安全建议。

参与角色：AI 产品经理、AI 工程师。

5．构建概念验证（PoC）

构建概念验证并提供给用户 — 概念验证包含与模型交互的Agent系统，并将结果提供给用户。

这一阶段的目标容易被误解。团队可能急于把提示词转换为命令行界面、聊天界面或 API 等可运行接口；此时最重要的目标，是尽快让用户使用系统。需要考虑：

按百炼官方接口配置模型，明确服务地域、模型能力边界及独立的 embedding 服务。
交付形态完全可以是一份包含输入与输出示例的 Excel 表格——只要能验证指标改善，就可以直接交付给用户试用。
用户反馈能够暴露原型阶段未覆盖的问题。根据实际反馈调整改进顺序，并记录对应的输入、输出和评估结果。

参与角色：AI 工程师。

重要提示：一份 Excel 表格就足以构成成功的 LLM PoC。如果当前流程无法快速把结果交到用户手中，应优先检视并简化交付流程。

6．为应用采集运行信息

关键事项包括：

记录追踪与人工反馈 — Agent运行产生追踪记录和人工反馈，为后续检查提供证据。

核心运行数据：记录提示词、模型生成内容、向量嵌入（Embedding）、调用延迟、Token 消耗量以及用户反馈。
上下文元数据：附带提示词版本号、原始用户输入与模型版本等元数据。
确保调用链正确连接，并明确各个操作的执行顺序。
多模态数据记录：涉及多模态场景时，同步记录 PDF、图像、音频和视频等输入输出资产。
一次 LLM 调用的输出，经常会成为下一次调用的输入。
反馈与 Trace 绑定：将用户反馈与触发该反馈的具体运行 Trace 关联，以便复盘当时的真实执行上下文。

参与角色：AI 工程师。

重要提示：完善的运行信息采集是开展“评估驱动开发”（Evaluation-Driven Development）的前提。

7．集成可观测性平台

关键事项包括：

将评估规则保存在平台中，后续用于评估追踪记录。
将平台作为提示词注册与管理中心。由于一次应用请求往往包含多次提示词调用，需支持按提示词组聚合分析评估结果。
当业务规模扩大、全量存储 Trace 成本过高时，利用平台的智能采样策略按比例保留关键记录。
优先使用主流可观测性平台自带的追踪 SDK 接入埋点，减少自研维护成本。

参与角色：AI 工程师。

重要提示：尽早接入可观测性平台，有助于透明化系统内部状态并快速定位链路瓶颈。

8．评估追踪数据

关键事项包括：

在评估规则已落库、Trace 持续上报且人工反馈已关联的前提下，对线上运行数据开展持续评估：
对进入可观测性平台的 Trace 自动运行评估规则。
筛选出评估未通过或收到负面人工反馈的 Trace（具体判定阈值由项目团队结合业务定义）。
后续改进重点关注这些失败数据。

参与角色：AI 工程师。

重要提示：在线评估（尤其是采用 LLM-as-a-Judge 方案时）会带来额外的推理开销，可通过对 Trace 采样来控制评估成本。

9．改进应用

关键事项包括：

根据评估改进系统 — 依据未通过的评估，调整提示、模型或系统结构，并检查相关系统组件。

根据评估失败结果和人工反馈，定位需要改进的环节。
仅当现有架构确实无法满足任务要求时，才按需演进系统拓扑：从简单提示词逐步过渡到基础 RAG、智能体 RAG、单智能体乃至多智能体系统，避免过度设计。
只有明确需求要求增加复杂性时，才调整系统结构。同时重点改善提示词工程、数据预处理和工具集成。
持续维护一份动态演进的“失败案例数据集”（Failure Dataset）：每次迭代以攻克现有失败样本为目标，同时不断纳入线上新暴露的失败案例，驱动系统持续改进。

参与角色：AI 工程师、领域专家。

重要提示：改进阶段应让领域专家深度参与——他们最熟悉目标业务场景，往往能直接提供更贴合实际业务的提示词调整建议。