AI Radar：我们的分类方法

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

自我们推出 AI Radar 以来，收到了很多关于其背后分类体系的问题：什么是 AI 任务，它与用例有什么区别？为什么要区分模型家族、架构、模态和工程方法？这些分类如何转化为实际的 AI 产品设计？

这些问题听起来像是术语讨论，但在实践中，它们帮助你讨论、对齐并结构化 AI 项目中的决策。

本文以 AI Radar 背后的分类体系为视角来进行这一分解。从一个简单的例子出发，我们将从业务问题到 AI 任务，从任务到数据和知识表示，再到模型和架构，最后到产品和交互层。你将看到这个分类体系如何帮助在可行性、成本、风险和实施策略方面做出更好的决策。

1. 用例：以业务问题为起点

想象一个客户服务团队的周一早晨。周末期间，数百个新的支持工单涌入。有些是简单的密码重置，有些是账单投诉，还有几个非常紧急。团队已经有了一套处理流程。人工坐席阅读每个工单，分配类别，评估紧急程度，并将其路由到合适的团队。有时，他们还会搜索内部知识库来辅助操作和回答。

这种方式在一段时间内运作良好，但随着数量的增长，不一致性和延迟开始出现。运营瓶颈逐渐变成了人员问题。坐席感到沮丧并离职。客户等待时间更长，团队负责人失去了可见性。组织对重大客户问题的反应变得越来越慢。

其中一位团队负责人发现了一个 AI 机会：我们能否利用 AI 帮助支持团队更快地理解、优先排序和路由传入的工单？

在 AI Radar 中，这被表示为一个用例——AI 在业务流程中的具体应用。在我们的例子中，这可以是工单分类与路由。这种表述方式很有用，因为它将讨论锚定在业务价值上。目标不是"使用 LLM"或"构建 Agent"，而是改善一个特定的（且令人痛苦的）流程。

然而，用例还不是技术规格。它不能告诉工程团队输入是什么样的，系统应该输出什么，有哪些数据可用，或者当 AI 不确定或出错时应该怎么处理。

这就是为什么下一步是翻译。业务问题需要被分解为系统必须提供的技术能力。

2. 将用例翻译为 AI 任务

一旦我们更仔细地映射客户服务工作流，用例就开始分解为几个熟悉的 AI 任务，如下表所示。

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

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

• 按主题对工单进行分类可能需要带标签的历史工单和一个监督分类器。
• 检索帮助文章可能需要文档嵌入和搜索索引。
• 起草回复可能需要语言模型、上下文支撑和人工审核。

3. 为你的 AI 系统提供数据

数据在 AI 系统中可以扮演多个角色。它可以离线用于训练、微调、测试和评估模型。它也可以在线用于在交互过程中提供上下文，例如，当检索系统在生成回复之前获取相关的帮助文章时。在成熟的 AI 产品中，用户反馈和交互数据也可能成为学习循环的一部分。

在 AI Radar 中，有三个类别在此尤为相关：

• 模态描述系统处理或产生的数据类型。在我们的例子中，主要模态是文本：支持工单、评论、帮助文章和坐席回复。稍后，系统可能还需要处理截图、通话录音或结构化的客户元数据。
• 数据集提供训练、测试和评估的材料。支持团队可能拥有数年的历史工单，包含客户消息、分配的类别、优先级、路由决策和最终解决方案。公开数据集可以帮助进行原型设计，但企业工作流通常需要反映公司自身语言、产品和规则的自定义数据集。
• 知识表示决定数据如何为 AI 使用而结构化。有时清理和预处理就足够了。在其他情况下，有意的数据表示可以显著提升性能。例如，嵌入可以支持语义检索，知识图谱可以连接产品和已知问题，结构化元数据可以捕获客户细分、合同类型或产品版本。

一旦我们理解了数据格局，模型选择就变得不那么凭猜测了：我们可以基于任务、模态、可用示例和表示策略来选择模型，而不是基于流行度和通用基准。

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

下一步是弄清楚哪个模型可以足够可靠、足够快速、以合理成本执行特定任务。

在我们的支持工单示例中，不同的任务需要不同的模型能力。工单路由可能需要分类器，语义检索需要嵌入模型，起草回复可能需要完整的 LLM。如果截图或通话录音成为工作流的一部分，视觉或语音模型也可能进入系统。

如今，大多数团队依赖于由 AI 实验室、云提供商或开源社区预训练的模型。但别忘了，你也可以为自己的上下文训练或微调模型。例如，如果一家公司使用高度特定的工单分类体系，一个基于历史工单训练的更小的自定义模型可能比大型通用模型更有效、更便宜、更容易控制。

在 AI Radar 中，几个类别有助于使这些选择更加透明：

• 模型家族将共享共同架构、训练方法或谱系的相关预训练模型分组。示例包括 Llama、Gemini 和 Mistral。
• 算法描述用于训练、优化或运行模型的数学过程。示例包括逻辑回归、随机森林和支持向量机。当团队训练自己的模型或将经典机器学习基线与较新方法进行比较时，这个类别变得尤为相关。
• 模型架构描述模型内部的构建方式：它包含哪些组件，它们如何连接，以及信息如何流经它们。示例包括 Transformer、LSTM 和混合专家架构。

模型选择应该从任务、数据和约束出发。大型语言模型可能对起草回复有用，但对于有良好标签数据的稳定分类问题来说，它可能造成巨大的开销。相反，如果系统需要从多个文档综合信息并产生自然语言答案，简单的分类器是不合适的。

5. 系统设计：将模型转化为产品

到目前为止，用例已经被翻译为任务、数据需求和模型选择。一个生产就绪的 AI 产品需要将这些部分整合到一个可靠的工作流中。它可能还需要其他组件，如数据管道、检索层、评估基础设施、监控、备用路径和反馈循环。

许多 AI 项目难以跨越从演示到生产的鸿沟。原型可能展示了模型可以做有用的事情，但用户需要一个可靠、可衡量、安全和可维护的系统。

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

在 AI Radar 中，三个类别有助于将模型连接到生产系统：

• 架构模式捕获常见 AI 用例的反复出现的系统设计。例如，当应用需要基于内部文档回答问题时，使用检索增强生成，而 Agent 框架帮助在执行多步工作流时约束和协调 Agent。
• 工程方法解决 AI 特定的开发挑战。因此，上下文工程专注于为模型推理构建正确的上下文。评估驱动开发将评估视为一个持续的过程，帮助团队随时间使系统行为与用户需求保持一致。
• 工具和框架提供可复用的抽象和实现支持。例如，LangChain 或 LlamaIndex 等智能体框架可以帮助处理复合 AI 系统中常见的检索、工具调用、记忆、编排和其他组件。

一个常见的陷阱是让工具驱动架构。团队看到一个强大的框架、一个新的 Agent 平台或一个精美的演示，就开始围绕它塑造应用。在最坏的情况下，他们从工具反向工程出 AI 机会。

工具应该是实现辅助手段，而不是起点。在选择它们之前，你需要理解系统的架构需求：什么需要被检索、生成、验证、监控，以及移交给人或另一个服务。一个好的架构也应该保持足够的抽象性，以便在更好的选项出现时可以替换工具和模型。

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

到目前为止，我们专注于幕后发生的事情：任务、数据、模型、架构和工程方法。这些层面在技术上要求很高，团队常常花数周或数月来选择模型、测试框架和设计管道。

在这种技术狂热中，用户体验可能被忽视。结果通常通过聊天机器人、通用助手或一个"神奇的" AI 按钮来暴露。但如果用户无法理解、验证、纠正或根据系统的输出采取行动，那么大部分价值仍然被困在后端。

在 AI Radar 中，交互模式帮助探索这些需求。它们描述用户与 AI 能力交互的反复出现的方式。例如，提示为用户提供了一种结构化的方式来指导 AI 模型，而人在回路中的交互让他们参与审核和调整 AI 输出。

对于工单系统来说，一个好的设计可能会结合多种模式：建议类别和紧急程度、检索相关的历史案例、起草回复，并且只自动路由高置信度的工单。低置信度或高影响的工单应该保持人工审核。

从分类体系到更好的决策

这个分类体系的目的不是创造更多的术语，而是对齐和改进决策制定：

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

这些类别共同帮助从"AI 可以在这里提供帮助"转向一个具体的设计空间：什么需要被构建、评估、集成和治理。这个过程很少是线性的。数据约束可能迫使不同的任务表述；评估结果可能改变模型选择，新的用户体验需求可能重塑架构。这个框架的价值不在于规定一个序列，而在于尽早使这些依赖关系变得可见，以便及时采取行动。

原文链接：A Practical Taxonomy for Designing AI Systems

汇智网翻译整理，转载请标明出处