与 Blue 工程团队一起深入了解他们如何构建基于 AI 的自动分类和标记功能。
我们最近向所有 Blue 用户发布了 AI 自动分类功能。这是一项集成在 Blue 核心订阅中的 AI 功能，无需额外费用。在本文中，我们将深入探讨实现这一功能背后的工程技术。
在 Blue，我们的功能开发方法根植于对用户需求和市场趋势的深入理解，以及对保持平台简洁易用特性的承诺。这正是推动我们路线图的动力，也是让我们多年来每月持续发布新功能的原因。
将 AI 驱动的自动标记功能引入 Blue 完美体现了这一理念的实践。在我们深入探讨构建这一功能的技术细节之前，理解我们要解决的问题以及开发过程中的深思熟虑至关重要。
项目管理领域正在快速发展，AI 能力越来越成为用户期望的核心。我们的客户，特别是那些管理着包含数百万条记录的大型项目的客户，一直在积极表达他们对更智能、更高效的数据组织和分类方式的需求。
然而，在 Blue，我们不会仅仅因为功能流行或被要求就添加它们。我们的理念是，每个新增功能都必须证明其价值，在功能展现出强大需求和明确效用之前，默认答案是坚定的*"否"*。
为了真正理解问题的深度和 AI 自动标记的潜力，我们进行了广泛的客户访谈，重点关注那些跨多个领域管理复杂、数据密集型项目的长期用户。
这些对话揭示了一个共同主题：虽然标记对于组织和搜索能力非常有价值，但手动操作的本质正在成为瓶颈，特别是对于处理大量记录的团队。
但我们看到的不仅仅是解决手动标记的直接痛点。
我们设想了一个未来，AI 驱动的标记可以成为更智能、自动化工作流程的基础。
我们意识到，这一功能的真正力量在于它与我们的项目管理自动化系统的潜在集成。想象一个项目管理工具，它不仅能智能地分类信息，还能使用这些分类来路由任务、触发操作并实时调整工作流程。
这一愿景与我们保持 Blue 简单而强大的目标完美契合。
此外，我们认识到将这一能力扩展到平台之外的潜力。通过开发强大的 AI 标记系统，我们正在为可以开箱即用的"分类 API"奠定基础，这可能为用户在更广泛的技术生态系统中与 Blue 交互和利用开辟新途径。
因此，这个功能不仅仅是为了在我们的功能列表中添加一个 AI 复选框。
这是朝着更智能、自适应的项目管理平台迈出的重要一步，同时忠于我们简洁和以用户为中心的核心理念。
在接下来的部分中，我们将深入探讨在实现这一愿景过程中面临的技术挑战、我们设计的支持架构以及实施的解决方案。我们还将探索这一功能开启的未来可能性，展示一个经过深思熟虑的添加如何为项目管理的变革性变化铺平道路。
问题
如上所述，手动标记项目记录既耗时又不一致。
我们着手通过利用 AI 根据记录内容自动建议标签来解决这个问题。
主要挑战包括：
- 选择合适的 AI 模型
- 高效处理大量记录
- 确保数据隐私和安全
- 将功能无缝集成到我们现有的架构中
选择 AI 模型
我们评估了几个 AI 平台，包括 OpenAI、HuggingFace 上的开源模型和 Replicate。
我们的标准包括：
- 成本效益
- 理解上下文的准确性
- 遵守特定输出格式的能力
- 数据隐私保证
经过全面测试，我们选择了 OpenAI 的 GPT-3.5 Turbo。虽然 GPT-4 可能在准确性上有边际改进，但我们的测试表明 GPT-3.5 的性能对于我们的自动标记需求来说已经绰绰有余。成本效益和强大分类能力的平衡使 GPT-3.5 成为这一功能的理想选择。
GPT-4 的更高成本会迫使我们将该功能作为付费附加组件提供，这与我们将 AI 捆绑在主产品中而不向最终用户收取额外费用的目标相冲突。
截至我们实施时，GPT-3.5 Turbo 的定价为：
- 每 1K 输入 token $0.0005（或每 1M 输入 token $0.50）
- 每 1K 输出 token $0.0015（或每 1M 输出 token $1.50）
让我们对 Blue 中的平均记录做一些假设：
- 标题：约 10 个 token
- 描述：约 50 个 token
- 2 条评论：每条约 30 个 token
- 5 个自定义字段：每个约 10 个 token
- 列表名称、截止日期和其他元数据：约 20 个 token
- 系统提示和可用标签：约 50 个 token
每条记录的总输入 token：10 + 50 + (30 * 2) + (10 * 5) + 20 + 50 ≈ 240 个 token
对于输出，假设每条记录平均建议 3 个标签，包括 JSON 格式在内可能总共约 20 个输出 token。
对于 100 万条记录：
- 输入成本：(240 * 1,000,000 / 1,000,000) * $0.50 = $120
- 输出成本：(20 * 1,000,000 / 1,000,000) * $1.50 = $30
自动标记 100 万条记录的总成本：$120 + $30 = $150
GPT3.5 Turbo 性能
分类是大型语言模型（LLM）如 GPT-3.5 Turbo 擅长的任务，使它们特别适合我们的自动标记功能。LLM 在大量文本数据上进行训练，使它们能够理解上下文、语义和概念之间的关系。这个广泛的知识库使它们能够在各种领域中以高准确度执行分类任务。
对于我们项目管理标记的特定用例，GPT-3.5 Turbo 展示了几个关键优势：
- 上下文理解： 能够掌握项目记录的整体上下文，不仅考虑单个词汇，还考虑整个描述、评论和其他字段传达的含义。
- 灵活性： 可以适应各种项目类型和行业，无需大量重新编程。
- 处理歧义： 可以权衡多个因素做出细致的决策。
- 从示例中学习： 可以快速理解和应用新的分类方案，无需额外训练。
- 多标签分类： 可以为单个记录建议多个相关标签，这对我们的需求至关重要。
GPT-3.5 Turbo 在遵守我们要求的 JSON 输出格式方面的可靠性也很突出，这对于与我们现有系统的无缝集成至关重要。开源模型虽然有潜力，但经常添加额外的注释或偏离预期格式，这需要额外的后处理。输出格式的一致性是我们决策的关键因素，因为它大大简化了我们的实施并减少了潜在的故障点。
选择具有一致 JSON 输出的 GPT-3.5 Turbo 使我们能够实现更直接、可靠和可维护的解决方案。
如果我们选择了格式可靠性较低的模型，我们将面临一系列复杂问题：需要强大的解析逻辑来处理各种输出格式、对不一致输出的广泛错误处理、额外处理可能带来的性能影响、覆盖所有输出变化的测试复杂性增加，以及更大的长期维护负担。
解析错误可能导致不正确的标记，对用户体验产生负面影响。通过避免这些陷阱，我们能够将工程工作集中在性能优化和用户界面设计等关键方面，而不是与不可预测的 AI 输出作斗争。
系统架构
我们的 AI 自动标记功能建立在强大、可扩展的架构之上，旨在高效处理大量请求，同时提供无缝的用户体验。与我们所有的系统一样，我们设计这个功能以支持比当前流量高一个数量级的流量。这种方法虽然看似对当前需求过度工程化，但这是一种最佳实践，使我们能够无缝处理使用量的突然激增，并为增长提供充足的空间，而无需进行重大架构改造。否则，我们将不得不每 18 个月重新设计所有系统——这是我们过去痛苦学到的教训！
让我们分解系统的组件和流程：
- 用户交互： 当用户在 Blue 界面中按下"自动标记"按钮时，流程开始。这个操作触发自动标记工作流。
- Blue API 调用： 用户的操作被转换为对我们 Blue 后端的 API 调用。这个 API 端点被设计用来处理自动标记请求。
- 队列管理： 我们不是立即处理请求（这可能在高负载下导致性能问题），而是将标记请求添加到队列中。我们使用 Redis 进行队列机制，这使我们能够有效管理负载并确保系统可扩展性。
- 后台服务： 我们实现了一个后台服务，持续监控队列中的新请求。该服务负责处理排队的请求。
- OpenAI API 集成： 后台服务准备必要的数据并向 OpenAI 的 GPT-3.5 模型发出 API 调用。这是实际的 AI 驱动标记发生的地方。我们发送相关的项目数据并接收建议的标签。
- 结果处理： 后台服务处理从 OpenAI 接收的结果。这包括解析 AI 的响应并准备将数据应用到项目中。
- 标签应用： 处理后的结果用于将新标签应用到项目中的相关项目。此步骤使用 AI 建议的标签更新我们的数据库。
- 用户界面反映： 最后，新标签出现在用户的项目视图中，从用户的角度完成自动标记过程。
这种架构提供了几个关键优势，增强了系统性能和用户体验。通过利用队列和后台处理，我们实现了令人印象深刻的可扩展性，使我们能够同时处理大量请求，而不会使我们的系统不堪重负或达到 OpenAI API 的速率限制。实施这种架构需要仔细考虑各种因素以确保最佳性能和可靠性。对于队列管理，我们选择了 Redis，利用其在处理分布式队列方面的速度和可靠性。
这种方法还有助于提高功能的整体响应速度。用户会立即收到他们的请求正在处理的反馈，即使实际的标记需要一些时间，也会产生实时交互的感觉。架构的容错能力是另一个关键优势。如果流程的任何部分遇到问题，例如临时的 OpenAI API 中断，我们可以优雅地重试或处理故障，而不会影响整个系统。
这种稳健性与标签的实时出现相结合，增强了用户体验，给人一种 AI "魔法"在起作用的印象。
数据与提示
我们自动标记过程中的关键步骤是准备要发送到 GPT-3.5 模型的数据。这一步需要仔细考虑，以平衡为准确标记提供足够的上下文，同时保持效率并保护用户隐私。以下是我们数据准备过程的详细介绍。
对于每条记录，我们编译以下信息：
- 列表名称： 提供有关项目更广泛类别或阶段的上下文。
- 记录标题： 通常包含有关记录目的或内容的关键信息。
- 自定义字段： 我们包括基于文本和数字的自定义字段，这些字段通常包含关键的项目特定信息。
- 描述： 通常包含有关记录的最详细信息。
- 评论： 可以提供可能与标记相关的额外上下文或更新。
- 截止日期： 可能影响标签选择的时间信息。
有趣的是，我们不向 GPT-3.5 发送现有的标签数据，这样做是为了避免使模型产生偏见。
我们自动标记功能的核心在于我们如何与 GPT-3.5 模型交互并处理其响应。我们管道的这一部分需要仔细设计，以确保准确、一致和高效的标记。
我们使用精心制作的系统提示来指导 AI 执行任务。以下是我们提示的分解以及每个组件背后的原理：
You will be provided with record data, and your task is to choose the tags that are relevant to the record.
You can respond with an empty array if you are unsure.
Available tags: ${tags}.
Today: ${currentDate}.
Please respond in JSON using the following format:
{ "tags": ["tag-1", "tag-2"] }
- 任务定义： 我们清楚地说明 AI 的任务以确保聚焦的响应。
- 不确定性处理： 我们明确允许空响应，防止在 AI 不确定时强制标记。
- 可用标签： 我们提供有效标签列表（${tags}）以将 AI 的选择限制在现有项目标签中。
- 当前日期： 包括 ${currentDate} 帮助 AI 理解时间上下文，这对某些类型的项目至关重要。
- 响应格式： 我们指定 JSON 格式以便于解析和错误检查。
这个提示是大量测试和迭代的结果。我们发现，明确说明任务、可用选项和所需输出格式显著提高了 AI 响应的准确性和一致性——简单是关键！
可用标签列表在服务器端生成并在包含到提示中之前进行验证。我们对标签名称实施严格的字符限制以防止提示过大。
如上所述，我们在让 GPT-3.5 Turbo 100% 正确返回纯 JSON 响应格式方面没有遇到任何问题。
总结一下，
- 我们将系统提示与准备好的记录数据结合起来。
- 这个组合提示通过 OpenAI 的 API 发送到 GPT-3.5 模型。
- 我们使用 0.3 的温度设置来平衡 AI 响应中的创造性和一致性。
- 我们的 API 调用包括 max_tokens 参数以限制响应大小并控制成本。
一旦我们收到 AI 的响应，我们会经历几个步骤来处理和应用建议的标签：
- JSON 解析：我们尝试将响应解析为 JSON。如果解析失败，我们记录错误并跳过该记录的标记。
- 模式验证：我们根据预期模式（具有"tags"数组的对象）验证解析的 JSON。这可以捕获 AI 响应中的任何结构偏差。
- 标签验证：我们将建议的标签与有效项目标签列表进行交叉引用。此步骤过滤掉项目中不存在的任何标签，如果 AI 误解或项目标签在提示创建和响应处理之间发生更改，可能会发生这种情况。
- 去重：我们从 AI 的建议中删除任何重复的标签以避免冗余标记。
- 应用：然后将验证和去重的标签应用到我们数据库中的记录。
- 日志记录和分析：我们记录最终应用的标签。这些数据对于监控系统性能和随时间改进它很有价值。
挑战
在 Blue 中实施 AI 驱动的自动标记带来了几个独特的挑战，每个挑战都需要创新的解决方案来确保功能的强大、高效和用户友好。
撤销批量操作
AI 标记功能既可以对单个记录执行，也可以批量执行。批量操作的问题是，如果用户不喜欢结果，他们将不得不手动浏览数千条记录并撤销 AI 的工作。显然，这是不可接受的。
为了解决这个问题，我们实施了一个创新的标记会话系统。每个批量标记操作都被分配一个唯一的会话 ID，该 ID 与该会话期间应用的所有标签相关联。这使我们能够通过简单地删除与特定会话 ID 相关联的所有标签来有效管理撤销操作。我们还删除相关的审计跟踪，确保撤销的操作在系统中不留痕迹。这种方法让用户有信心尝试 AI 标记，知道如果需要，他们可以轻松恢复更改。
数据隐私
数据隐私是我们面临的另一个关键挑战。
我们的用户信任我们处理他们的项目数据，确保这些信息不被 OpenAI 保留或用于模型训练至关重要。我们从多个方面解决了这个问题。
首先，我们与 OpenAI 达成协议，明确禁止使用我们的数据进行模型训练。此外，OpenAI 在处理后删除数据，提供额外的隐私保护层。
在我们这边，我们采取了预防措施，从发送给 AI 的数据中排除敏感信息，例如分配人详细信息，这确保特定个人姓名不会与其他数据一起发送给第三方。
这种综合方法使我们能够利用 AI 能力，同时保持最高标准的数据隐私和安全。
速率限制和捕获错误
我们的主要关注点之一是可扩展性和速率限制。对每条记录直接进行 API 调用到 OpenAI 将是低效的，并且可能会快速达到速率限制，特别是对于大型项目或在高峰使用时段。为了解决这个问题，我们开发了一个后台服务架构，允许我们批量请求并实施我们自己的队列系统。这种方法帮助我们管理 API 调用频率，并能够更有效地处理大量记录，确保即使在高负载下也能平稳运行。
AI 交互的性质意味着我们还必须为偶尔的错误或意外输出做好准备。有些情况下，AI 可能会产生无效的 JSON 或不符合我们预期格式的输出。为了处理这个问题，我们在整个系统中实施了强大的错误处理和解析逻辑。如果 AI 响应不是有效的 JSON 或不包含预期的"tags"键，我们的系统被设计为将其视为没有建议标签，而不是尝试处理可能损坏的数据。这确保即使面对 AI 的不可预测性，我们的系统仍然保持稳定和可靠。
未来发展
我们相信功能以及 Blue 产品整体永远不会"完成"——总有改进的空间。
在初始构建中，我们考虑了一些功能，但没有通过范围确定阶段，但值得注意的是，我们将来可能会实施其中的某些版本。
第一个是添加标签描述。这将允许最终用户不仅给标签命名和颜色，还可以提供可选描述。这也将传递给 AI 以帮助提供进一步的上下文并可能提高准确性。
虽然额外的上下文可能很有价值，但我们注意到它可能引入的潜在复杂性。在提供有用信息和用过多细节压倒用户之间需要取得微妙的平衡。在开发此功能时，我们将专注于找到那个甜蜜点，即添加的上下文增强而不是使用户体验复杂化。
也许我们视野中最令人兴奋的增强功能是将 AI 自动标记与我们的项目管理自动化系统集成。
这意味着 AI 标记功能可以是自动化的触发器或操作。这可能是巨大的，因为它可以将这个相当简单的 AI 分类功能转变为基于 AI 的工作路由系统。
想象一个自动化声明：
当 AI 将记录标记为"关键"时 -> 分配给"经理"并发送自定义电子邮件
这意味着当你对记录进行 AI 标记时，如果 AI 决定这是一个关键问题，那么它可以自动分配项目经理并向他们发送自定义电子邮件。这将我们项目管理自动化系统的优势从纯粹基于规则的系统扩展到真正灵活的 AI 系统。
通过不断探索项目管理中 AI 的前沿，我们的目标是为用户提供不仅满足他们当前需求，而且预测和塑造工作未来的工具。一如既往，我们将与用户社区密切合作开发这些功能，确保每项增强都为项目管理流程增加真正的实用价值。
结论
就是这样！
这是一个有趣的功能实施，也是我们进入 AI 的第一步之一，与我们之前推出的 AI 内容摘要一起。我们知道 AI 将在未来的项目管理中扮演越来越重要的角色，我们迫不及待地想要推出更多利用先进 LLM（大型语言模型）的创新功能。
在实施过程中有很多需要考虑的事情，我们特别兴奋的是我们如何能够在未来利用这个功能与 Blue 现有的项目管理自动化引擎。
我们也希望这是一次有趣的阅读，让您了解我们如何思考工程化您每天使用的功能。