AI 自動分類（工程深度解析）

與 Blue 工程團隊一起深入了解他們如何建構 AI 驅動的自動分類和標籤功能。

我們最近向所有 Blue 用戶發布了 AI 自動分類。這是一項整合在 Blue 核心訂閱中的 AI 功能，無需額外費用。在這篇文章中，我們將深入探討實現這項功能背後的工程細節。

在 Blue，我們的功能開發方法植根於對用戶需求和市場趨勢的深入理解，並致力於維持定義我們平台的簡潔性和易用性。這是推動我們路線圖的動力，也是讓我們能夠多年來每月持續發布功能的原因。

將 AI 驅動的自動標籤引入 Blue 是這種理念的完美體現。在深入探討我們如何建構這項功能的技術細節之前，了解我們要解決的問題以及開發過程中的審慎考量至關重要。

專案管理領域正在快速發展，AI 能力正日益成為用戶期望的核心。我們的客戶，特別是那些管理包含數百萬條記錄的大型專案的客戶，強烈表達了他們對更智能、更高效的數據組織和分類方式的需求。

然而，在 Blue，我們不會僅僅因為功能流行或被要求就簡單地添加功能。我們的理念是，每個新增功能都必須證明其價值，預設答案是堅定的*「不」*，直到功能展現出強勁的需求和明確的實用性。

為了真正理解問題的深度和 AI 自動標籤的潛力，我們進行了廣泛的客戶訪談，重點關注在多個領域管理複雜、數據豐富專案的長期用戶。

這些對話揭示了一個共同主題：雖然標籤對於組織和搜索能力非常寶貴，但手動標籤的本質正在成為瓶頸，特別是對於處理大量記錄的團隊。

但我們看到的不僅僅是解決手動標籤的即時痛點。

我們設想了一個未來，AI 驅動的標籤可以成為更智能、自動化工作流程的基礎。

我們意識到，這項功能的真正力量在於其與我們的專案管理自動化系統整合的潛力。想像一個專案管理工具，不僅能智能地分類資訊，還能使用這些類別來路由任務、觸發動作並即時調整工作流程。

這個願景與我們保持 Blue 簡單而強大的目標完美契合。

此外，我們認識到將這種能力擴展到平台之外的潛力。通過開發強大的 AI 標籤系統，我們正在為一個可以開箱即用的「分類 API」奠定基礎，這可能為用戶在更廣泛的技術生態系統中與 Blue 互動和利用 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 性能

分類是大型語言模型（LLMs）如 GPT-3.5 Turbo 擅長的任務，使它們特別適合我們的自動標籤功能。LLMs 在大量文本數據上進行訓練，使它們能夠理解上下文、語義和概念之間的關係。這個廣泛的知識庫使它們能夠在廣泛的領域中以高準確度執行分類任務。

對於我們專案管理標籤的特定用例，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 回應的準確性和一致性——簡單是關鍵！

可用標籤列表在服務器端生成，並在包含在提示中之前進行驗證。我們對標籤名稱實施嚴格的字符限制，以防止過大的提示。

如上所述，我們在 100% 的時間內從 GPT-3.5 Turbo 獲得正確格式的純 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 能力，同時保持最高標準的數據隱私和安全性。

速率限制和捕獲錯誤

我們主要關注的問題之一是可擴展性和速率限制。為每條記錄直接調用 OpenAI API 將是低效的，並且可能很快達到速率限制，特別是對於大型專案或在高峰使用時間。為了解決這個問題，我們開發了一個後台服務架構，允許我們批處理請求並實施我們自己的隊列系統。這種方法幫助我們管理 API 調用頻率，並使我們能夠更高效地處理大量記錄，確保即使在高負載下也能順暢運行。

AI 互動的本質意味著我們還必須為偶爾的錯誤或意外輸出做好準備。有時 AI 可能會產生無效的 JSON 或不符合我們預期格式的輸出。為了處理這個問題，我們在整個系統中實施了強大的錯誤處理和解析邏輯。如果 AI 回應不是有效的 JSON 或不包含預期的「tags」鍵，我們的系統被設計為將其視為沒有建議標籤，而不是嘗試處理可能損壞的數據。這確保即使面對 AI 的不可預測性，我們的系統也保持穩定和可靠。

未來發展

我們相信功能和整個 Blue 產品永遠不會「完成」——總有改進的空間。

在初始構建中，我們考慮了一些功能，但沒有通過範圍階段，但值得注意的是，我們可能會在未來實施其中的某些版本。

第一個是添加標籤描述。這將允許最終用戶不僅給標籤一個名稱和顏色，還可以選擇性地添加描述。這也將傳遞給 AI 以幫助提供進一步的上下文並可能提高準確性。

雖然額外的上下文可能很有價值，但我們注意到它可能引入的潛在複雜性。在提供有用資訊和用過多細節壓倒用戶之間需要找到微妙的平衡。在開發這個功能時，我們將專注於找到那個甜蜜點，使添加的上下文增強而不是複雜化用戶體驗。

我們視野中最令人興奮的增強功能可能是將 AI 自動標籤與我們的專案管理自動化系統整合。

這意味著 AI 標籤功能可以是自動化的觸發器或動作。這可能具有重大意義，因為它可以將這個相對簡單的 AI 分類功能轉變為基於 AI 的工作路由系統。

想像一個自動化規則：

當 AI 將記錄標記為「關鍵」時 -> 分配給「經理」並發送自定義電子郵件

這意味著當您對記錄進行 AI 標記時，如果 AI 決定這是一個關鍵問題，那麼它可以自動分配專案經理並向他們發送自定義電子郵件。這將我們專案管理自動化系統的優勢從純粹基於規則的系統擴展到真正靈活的 AI 系統。

通過不斷探索 AI 在專案管理中的前沿，我們的目標是為用戶提供不僅滿足他們當前需求，而且預測和塑造工作未來的工具。一如既往，我們將與用戶社群密切合作開發這些功能，確保每項增強都為專案管理過程增加真實、實用的價值。

結論

就是這樣！

這是一個有趣的功能實施，也是我們在 AI 方面的第一步之一，與我們之前推出的 AI 內容摘要一起。我們知道 AI 在未來的專案管理中將扮演越來越重要的角色，我們迫不及待地要推出更多利用先進 LLMs（大型語言模型）的創新功能。

在實施過程中有很多需要考慮的事情，我們特別興奮的是我們如何能夠在未來利用這個功能與 Blue 現有的專案管理自動化引擎結合。

我們也希望這是一篇有趣的閱讀，讓您了解我們如何思考工程化您每天使用的功能。

問題