AI系统设计实用分类法：从业务到落地的结构化指南

图1：AI Radar 将AI概念归类为结构化分类法

当所有人都在追逐AI热点时，结构化思考是你最好的武器。

这些问题听起来像是术语辨析，但在实践中，它们能帮你更好地讨论、对齐和设计AI项目中的关键决策。

本文以AI Radar背后的分类法为框架，从一个简单案例出发，逐步拆解：从业务问题到AI任务，从任务到数据和知识表示，再到模型与架构，最后落到产品与交互层。你会看到，这种分类法如何帮你在可行性、成本、风险和落地策略上做出更明智的判断。

---

1. 案例：从业务痛点出发

想象一家电商平台的客服团队。周一早上一开工，后台堆积了上百条工单。有些是简单的密码重置，有些是投诉退款，还有几条是紧急问题。团队原有的流程是：人工客服逐一阅读、分类、判断紧急程度，再分配到对应小组。有时候还需要查询内部知识库来支持回答。

随着业务量增长，这套流程开始出问题：响应速度变慢、分类不一致、人员流失。客户等待时间越来越长，团队主管也失去全局视角。

一位团队负责人发现了AI的机会：能否用AI帮助客服更好地理解、排序和分发工单？

在AI Radar中，这个场景被称为“用例”——AI在业务流程中的具体应用。本例中就是“工单分类与分发”。这种框定很有价值：它把讨论锚定在业务价值上。目标不是“用大模型”或“搭一个Agent”，而是改善某个具体（且痛苦）的流程。

但用例还不是技术规格。它没有告诉工程团队：输入是什么？输出是什么？有哪些可用数据？AI不确定或犯错时怎么办？

所以下一步是翻译——把业务问题拆解成系统所需的技术能力。

---

2. 把用例拆解成AI任务

深入分析客服流程后，用例可以被分解成多个熟悉的“AI任务”。下表展示了关键子任务：

表1：工单分类与分发场景的子任务拆解

AI任务是原始的、可复用的能力。它们描述了系统执行的转化：从文本到标签、从文本到结构化字段、从查询到检索文档、从模式到异常分数等。

这个区分很重要，因为任务决定了AI解决方案的形状。它们明确了输入和输出，并缩小了相关数据、模型、评估方法和工程模式的范围。例如：

• 按主题分类工单：需要带标签的历史工单，以及一个监督式分类器。
• 检索帮助文档：需要文档嵌入和搜索索引。
• 草拟回复：需要语言模型、上下文背景以及人工审核。

---

3. 用数据喂养AI系统

数据在AI系统中扮演多种角色。可以离线用于训练、微调、测试和评估模型；也可以在线用于推理时提供上下文（比如检索系统在生成回复前先抓取相关帮助文档）。在成熟的AI产品中，用户反馈和交互数据还会进入学习循环。

在AI Radar中，以下三类特别重要：

• 模态：系统处理或产生的数据类型。本例主要是文本：工单、评论、帮助文档、客服回复。后续可能还要处理截图、通话录音或结构化客户元数据。
• 数据集：训练、测试和评估的材料。客服团队可能有多年历史工单，包含客户消息、分类、优先级、分派决策和最终解决方案。公开数据集可用于原型验证，但企业级工作流通常需要定制数据集，以反映公司自身的语言、产品和规则。
• 知识表示：决定数据如何结构化以供AI使用。有时清洗和预处理就足够，有时需要引入更明确的知识表示来提升性能。例如：嵌入向量支持语义检索，知识图谱关联产品和已知问题，结构化元数据包含客户分层、合同类型或产品版本。

一旦理解了数据全景，模型选择就不再是瞎猜——你可以根据任务、模态、可用样本和表示策略来选择，而不是只看知名度或通用评测。

---

4. 模型与算法：让能力匹配任务和数据

下一步是确定哪种模型能够足够可靠、足够快、成本合理地执行特定任务。

在工单案例中，不同任务需要不同的模型能力。工单分发可能需要分类器，语义检索需要嵌入模型，回复草拟可能需要一个完整的LLM。如果涉及截图或通话录音，还需引入视觉或语音模型。

如今大部分团队依赖AI实验室、云服务商或开源社区预训练好的模型。但别忘了，你也可以针对自己的场景训练或微调模型。例如，如果公司使用高度特定的工单分类体系，一个基于历史数据训练的小型定制模型可能比通用大模型更有效、更便宜、更可控。

AI Radar中的几个分类能帮你更透明地做选择：

• 模型家族：共享相同架构、训练方法或血统的预训练模型组，例如Llama、Gemini、Mistral。
• 算法：训练、优化或运行模型所用的数学程序，例如逻辑回归、随机森林、支持向量机。当团队自己训练模型或对比传统机器学习基线时，这一分类特别有用。
• 模型架构：模型内部结构，包含哪些组件、如何连接、信息如何流动，例如Transformer、LSTM、MoE。

模型选择应从任务、数据和约束出发。大语言模型在回复草拟时可能很有用，但用于一个已有充分标注的分类问题上，可能带来巨大开销。反之，一个简单分类器也不适合需要综合多文档信息并生成自然语言回答的场景。

---

5. 系统设计：把模型变成产品

到现在为止，用例已经被翻译成任务、数据需求和模型选择。一个生产就绪的AI产品需要把这些碎片整合成可靠的工作流，还可能涉及数据管道、检索层、评估基础设施、监控、降级路径和反馈循环等组件。

很多AI项目难以从演示跨越到生产。原型能证明模型可以做有用的事情，但用户需要的是一套可靠、可度量、安全、可维护的系统。

传统软件架构中的许多原则——模块化、清晰接口、可测试性——仍然适用。但AI系统也引入了额外挑战：输出是概率性的，性能高度依赖数据质量，行为可能随着提示词、上下文、模型、用户行为和底层数据的变化而变化。

在AI Radar中，有三类有助于连接模型和产品：

• 架构模式：针对常见AI用例的重复系统设计，例如RAG用于基于内部文档回答的问题，Agent harness用于约束和协调多步骤工作流。
• 工程方法：解决AI特有的开发挑战，例如上下文工程、评估驱动开发等。
• 工具与框架：提供可复用的抽象和实现支持，例如LangChain、LlamaIndex等代理框架可用于检索、工具调用、记忆、编排等。

一个常见陷阱是让工具驱动架构。团队看到强大的框架或炫酷的Demo，就开始围绕它设计应用。最糟糕的情况是从工具反向推导AI机会。

工具应该是实现辅助，而不是起点。在选工具之前，先要理解系统的架构需求：需要检索什么、生成什么、验证什么、监控什么、交给人工或其他服务的边界在哪。一个好的架构还应该保持足够抽象，以便未来替换工具和模型。

---

6. 通过用户体验交付AI价值

前面我们聚焦在后台：任务、数据、模型、架构、工程方法。这些层技术性很强，团队常常花数周选模型、测框架、设计管道。

但在技术冲刺中，用户体验可能变成事后才考虑的事。结果往往是提供一个聊天机器人、一个通用助手或一个“魔法AI按钮”。如果用户无法理解、验证、纠正或对系统输出采取行动，大部分价值就留在了后端。

在AI Radar中，“交互模式”帮助探索这些需求。它们描述了用户与AI能力交互的常见方式，例如提示词让用户以结构化方式指导AI，而人在回路交互则让用户参与审核和调整AI输出。

对于工单系统，好的设计可以组合多种模式：建议类别和紧急程度、检索相似历史案例、草拟回复，仅自动流转高置信度的工单。低置信度或高影响案例应保留人工审核。

---

从分类法到更好的决策

这套分类法的目的不是创造更多术语，而是对齐和改进决策：

• 用例框定商业机会。
• 任务将其转化为技术能力。
• 模态、数据集和知识表示界定可用证据和运行上下文。
• 模型和算法提供计算能力，让系统“智能化”。
• 架构、工程方法和工具决定这些能力如何组合、评估和维护。
• 交互模式塑造系统输出如何进入工作流。

这些类别共同帮助你从“AI可能有用”走向具体的设计空间：需要构建什么、评估什么、集成什么、治理什么。这个过程很少是线性的。数据约束可能迫使你重新定义任务，评估结果可能改变模型选择，新的UX需求可能重塑架构。这个框架的价值不在于规定顺序，而在于尽早让这些依赖关系可见，从而采取行动。