---

Недавно мы выпустили Автоматическую категоризацию с помощью ИИ для всех пользователей Blue. Это функция ИИ, которая включена в основную подписку Blue без дополнительных затрат. В этой статье мы подробно рассмотрим инженерную составляющую реализации этой функции.

---

В Blue наш подход к разработке функций основан на глубоком понимании потребностей пользователей и рыночных тенденций, в сочетании с приверженностью к сохранению простоты и удобства использования, которые определяют нашу платформу. Это то, что движет нашей дорожной картой, и что позволило нам последовательно выпускать функции каждый месяц на протяжении многих лет.

Внедрение автоматического тегирования на основе ИИ в Blue является прекрасным примером этой философии в действии. Прежде чем мы углубимся в технические детали того, как мы создали эту функцию, важно понять проблему, которую мы решали, и тщательные размышления, которые легли в основу её разработки.

Ландшафт управления проектами быстро развивается, и возможности ИИ становятся всё более важными для ожиданий пользователей. Наши клиенты, особенно те, кто управляет крупномасштабными проектами с миллионами записей, активно выражали желание иметь более интеллектуальные и эффективные способы организации и категоризации своих данных.

Однако в Blue мы не просто добавляем функции, потому что они модные или запрашиваются. Наша философия заключается в том, что каждое новое дополнение должно доказать свою ценность, причём ответом по умолчанию является твёрдое "нет", пока функция не продемонстрирует сильный спрос и явную полезность.

Чтобы по-настоящему понять глубину проблемы и потенциал автоматического тегирования с помощью ИИ, мы провели обширные интервью с клиентами, сосредоточившись на давних пользователях, которые управляют сложными, насыщенными данными проектами в различных областях.

Эти беседы выявили общую нить: хотя тегирование было бесценным для организации и возможности поиска, ручной характер процесса становился узким местом, особенно для команд, работающих с большими объёмами записей.

Но мы видели не только решение непосредственной проблемы ручного тегирования.

Мы представляли будущее, где тегирование на основе ИИ может стать фундаментом для более интеллектуальных, автоматизированных рабочих процессов.

Настоящая сила этой функции, как мы поняли, заключалась в её потенциальной интеграции с нашей системой автоматизации управления проектами. Представьте инструмент управления проектами, который не только интеллектуально категоризирует информацию, но и использует эти категории для маршрутизации задач, запуска действий и адаптации рабочих процессов в реальном времени.

Это видение идеально соответствовало нашей цели сохранить Blue простым, но мощным.

Кроме того, мы признали потенциал расширения этой возможности за пределы нашей платформы. Разрабатывая надёжную систему тегирования на основе ИИ, мы закладывали основу для "API категоризации", который мог бы работать из коробки, потенциально открывая новые возможности для взаимодействия наших пользователей с Blue в их более широких технологических экосистемах.

Таким образом, эта функция была не просто добавлением галочки ИИ в наш список функций.

Это был значительный шаг к более интеллектуальной, адаптивной платформе управления проектами при сохранении верности нашей основной философии простоты и ориентированности на пользователя.

В следующих разделах мы углубимся в технические проблемы, с которыми мы столкнулись при воплощении этого видения в жизнь, архитектуру, которую мы разработали для её поддержки, и решения, которые мы реализовали. Мы также исследуем будущие возможности, которые открывает эта функция, демонстрируя, как тщательно продуманное дополнение может проложить путь к трансформационным изменениям в управлении проектами.

---

Проблема

Как обсуждалось выше, ручное тегирование записей проектов может быть трудоёмким и непоследовательным.

Мы решили решить эту проблему, используя ИИ для автоматического предложения тегов на основе содержимого записей.

Основными задачами были:

1. Выбор подходящей модели ИИ
2. Эффективная обработка больших объёмов записей
3. Обеспечение конфиденциальности и безопасности данных
4. Беспрепятственная интеграция функции в нашу существующую архитектуру

Выбор модели ИИ

Мы оценили несколько платформ ИИ, включая OpenAI, модели с открытым исходным кодом на HuggingFace и Replicate.

Наши критерии включали:

• Экономическую эффективность
• Точность понимания контекста
• Способность придерживаться определённых форматов вывода
• Гарантии конфиденциальности данных

После тщательного тестирования мы выбрали GPT-3.5 Turbo от OpenAI. Хотя GPT-4 может предложить незначительные улучшения в точности, наши тесты показали, что производительность GPT-3.5 была более чем достаточной для наших потребностей в автоматическом тегировании. Баланс экономической эффективности и сильных возможностей категоризации сделал GPT-3.5 идеальным выбором для этой функции.

Более высокая стоимость GPT-4 заставила бы нас предлагать функцию как платную надстройку, что противоречило бы нашей цели включить ИИ в наш основной продукт без дополнительных затрат для конечных пользователей.

На момент нашей реализации ценообразование для GPT-3.5 Turbo составляет:

• $0.0005 за 1K входных токенов (или $0.50 за 1M входных токенов)
• $0.0015 за 1K выходных токенов (или $1.50 за 1M выходных токенов)

Давайте сделаем некоторые предположения о средней записи в Blue:

• Заголовок: ~10 токенов
• Описание: ~50 токенов
• 2 комментария: ~30 токенов каждый
• 5 пользовательских полей: ~10 токенов каждое
• Название списка, срок выполнения и другие метаданные: ~20 токенов
• Системный промпт и доступные теги: ~50 токенов

Всего входных токенов на запись: 10 + 50 + (30 * 2) + (10 * 5) + 20 + 50 ≈ 240 токенов

Для вывода давайте предположим в среднем 3 предложенных тега на запись, что может составить около 20 выходных токенов, включая форматирование JSON.

Для 1 миллиона записей:

• Стоимость входных данных: (240 * 1,000,000 / 1,000,000) * $0.50 = $120
• Стоимость выходных данных: (20 * 1,000,000 / 1,000,000) * $1.50 = $30

Общая стоимость автоматического тегирования 1 миллиона записей: $120 + $30 = $150

Производительность GPT3.5 Turbo

Категоризация — это задача, в которой большие языковые модели (LLM), такие как GPT-3.5 Turbo, преуспевают, что делает их особенно подходящими для нашей функции автоматического тегирования. LLM обучаются на огромных объёмах текстовых данных, что позволяет им понимать контекст, семантику и отношения между концепциями. Эта широкая база знаний позволяет им выполнять задачи категоризации с высокой точностью в широком спектре областей.

Для нашего конкретного случая использования тегирования в управлении проектами GPT-3.5 Turbo демонстрирует несколько ключевых преимуществ:

• Понимание контекста: Может уловить общий контекст записи проекта, учитывая не только отдельные слова, но и смысл, передаваемый всем описанием, комментариями и другими полями.
• Гибкость: Может адаптироваться к различным типам проектов и отраслям без необходимости обширного перепрограммирования.
• Обработка неоднозначности: Может взвешивать множество факторов для принятия нюансированных решений.
• Обучение на примерах: Может быстро понимать и применять новые схемы категоризации без дополнительного обучения.
• Многометочная классификация: Может предлагать несколько релевантных тегов для одной записи, что было критически важно для наших требований.

GPT-3.5 Turbo также выделился своей надёжностью в соблюдении требуемого нами формата вывода JSON, что было критически важно для беспрепятственной интеграции с нашими существующими системами. Модели с открытым исходным кодом, хотя и многообещающие, часто добавляли дополнительные комментарии или отклонялись от ожидаемого формата, что потребовало бы дополнительной постобработки. Эта последовательность в формате вывода была ключевым фактором в нашем решении, так как она значительно упростила нашу реализацию и уменьшила потенциальные точки отказа.

Выбор GPT-3.5 Turbo с его последовательным выводом JSON позволил нам реализовать более простое, надёжное и удобное для поддержки решение.

Если бы мы выбрали модель с менее надёжным форматированием, мы столкнулись бы с каскадом осложнений: необходимостью надёжной логики разбора для обработки различных форматов вывода, обширной обработкой ошибок для непоследовательных выводов, потенциальным влиянием на производительность от дополнительной обработки, повышенной сложностью тестирования для покрытия всех вариаций вывода и большей долгосрочной нагрузкой на обслуживание.

Ошибки разбора могут привести к неправильному тегированию, негативно влияя на пользовательский опыт. Избегая этих ловушек, мы смогли сосредоточить наши инженерные усилия на критических аспектах, таких как оптимизация производительности и дизайн пользовательского интерфейса, а не бороться с непредсказуемыми выводами ИИ.

Системная архитектура

Наша функция автоматического тегирования с помощью ИИ построена на надёжной, масштабируемой архитектуре, разработанной для эффективной обработки больших объёмов запросов при обеспечении беспрепятственного пользовательского опыта. Как и во всех наших системах, мы спроектировали эту функцию для поддержки на порядок большего трафика, чем мы испытываем в настоящее время. Этот подход, хотя и кажется чрезмерно спроектированным для текущих потребностей, является лучшей практикой, которая позволяет нам беспрепятственно обрабатывать внезапные всплески использования и даёт нам достаточный запас для роста без крупных архитектурных перестроек. В противном случае нам пришлось бы перепроектировать все наши системы каждые 18 месяцев — то, что мы усвоили на горьком опыте в прошлом!

Давайте разберём компоненты и поток нашей системы:

• Взаимодействие с пользователем: Процесс начинается, когда пользователь нажимает кнопку "Autotag" в интерфейсе Blue. Это действие запускает рабочий процесс автоматического тегирования.
• Вызов API Blue: Действие пользователя преобразуется в вызов API к нашему бэкенду Blue. Эта конечная точка API предназначена для обработки запросов автоматического тегирования.
• Управление очередью: Вместо немедленной обработки запроса, что может привести к проблемам с производительностью при высокой нагрузке, мы добавляем запрос на тегирование в очередь. Мы используем Redis для этого механизма очередей, что позволяет нам эффективно управлять нагрузкой и обеспечивать масштабируемость системы.
• Фоновая служба: Мы реализовали фоновую службу, которая постоянно отслеживает очередь на наличие новых запросов. Эта служба отвечает за обработку запросов в очереди.
• Интеграция API OpenAI: Фоновая служба подготавливает необходимые данные и делает вызовы API к модели GPT-3.5 от OpenAI. Здесь происходит фактическое тегирование на основе ИИ. Мы отправляем соответствующие данные проекта и получаем предложенные теги в ответ.
• Обработка результатов: Фоновая служба обрабатывает результаты, полученные от OpenAI. Это включает в себя разбор ответа ИИ и подготовку данных для применения к проекту.
• Применение тегов: Обработанные результаты используются для применения новых тегов к соответствующим элементам в проекте. Этот шаг обновляет нашу базу данных с тегами, предложенными ИИ.
• Отражение в пользовательском интерфейсе: Наконец, новые теги появляются в представлении проекта пользователя, завершая процесс автоматического тегирования с точки зрения пользователя.

Эта архитектура предлагает несколько ключевых преимуществ, которые улучшают как производительность системы, так и пользовательский опыт. Используя очередь и фоновую обработку, мы достигли впечатляющей масштабируемости, позволяя нам обрабатывать многочисленные запросы одновременно без перегрузки нашей системы или достижения лимитов скорости API OpenAI. Реализация этой архитектуры требовала тщательного рассмотрения различных факторов для обеспечения оптимальной производительности и надёжности. Для управления очередью мы выбрали Redis, используя его скорость и надёжность в обработке распределённых очередей.

Этот подход также способствует общей отзывчивости функции. Пользователи получают немедленную обратную связь о том, что их запрос обрабатывается, даже если фактическое тегирование занимает некоторое время, создавая ощущение взаимодействия в реальном времени. Отказоустойчивость архитектуры — ещё одно критическое преимущество. Если какая-либо часть процесса сталкивается с проблемами, такими как временные сбои API OpenAI, мы можем изящно повторить попытку или обработать сбой без влияния на всю систему.

Эта надёжность в сочетании с появлением тегов в реальном времени улучшает пользовательский опыт, создавая впечатление "магии" ИИ в действии.

Данные и промпты

Критическим шагом в нашем процессе автоматического тегирования является подготовка данных для отправки в модель GPT-3.5. Этот шаг требовал тщательного рассмотрения, чтобы сбалансировать предоставление достаточного контекста для точного тегирования при сохранении эффективности и защите конфиденциальности пользователей. Вот подробный обзор нашего процесса подготовки данных.

Для каждой записи мы собираем следующую информацию:

• Название списка: Предоставляет контекст о более широкой категории или фазе проекта.
• Заголовок записи: Часто содержит ключевую информацию о цели или содержании записи.
• Пользовательские поля: Мы включаем текстовые и числовые пользовательские поля, которые часто содержат критически важную информацию, специфичную для проекта.
• Описание: Обычно содержит наиболее подробную информацию о записи.
• Комментарии: Могут предоставить дополнительный контекст или обновления, которые могут быть релевантны для тегирования.
• Срок выполнения: Временная информация, которая может влиять на выбор тегов.

Интересно, что мы не отправляем существующие данные тегов в GPT-3.5, и делаем это, чтобы избежать предвзятости модели.

Ядро нашей функции автоматического тегирования заключается в том, как мы взаимодействуем с моделью GPT-3.5 и обрабатываем её ответы. Этот раздел нашего конвейера требовал тщательного проектирования для обеспечения точного, последовательного и эффективного тегирования.

Мы используем тщательно созданный системный промпт для инструктирования ИИ о его задаче. Вот разбор нашего промпта и обоснование каждого компонента:

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"] }

• Определение задачи: Мы чётко формулируем задачу ИИ для обеспечения сфокусированных ответов.
• Обработка неопределённости: Мы явно разрешаем пустые ответы, предотвращая принудительное тегирование, когда ИИ не уверен.
• Доступные теги: Мы предоставляем список действительных тегов (${tags}), чтобы ограничить выбор ИИ существующими тегами проекта.
• Текущая дата: Включение ${currentDate} помогает ИИ понять временной контекст, который может быть критически важным для определённых типов проектов.
• Формат ответа: Мы указываем формат JSON для лёгкого разбора и проверки ошибок.

Этот промпт является результатом обширного тестирования и итераций. Мы обнаружили, что явное указание задачи, доступных опций и желаемого формата вывода значительно улучшило точность и последовательность ответов ИИ — простота является ключом!

Список доступных тегов генерируется на стороне сервера и проверяется перед включением в промпт. Мы реализуем строгие ограничения на количество символов в названиях тегов, чтобы предотвратить слишком большие промпты.

Как упоминалось выше, у нас не было проблем с GPT-3.5 Turbo в получении чистого ответа JSON в правильном формате в 100% случаев.

Итак, подводя итог:

• Мы объединяем системный промпт с подготовленными данными записи.
• Этот объединённый промпт отправляется в модель GPT-3.5 через API OpenAI.
• Мы используем настройку температуры 0.3 для баланса креативности и последовательности в ответах ИИ.
• Наш вызов API включает параметр max_tokens для ограничения размера ответа и контроля затрат.

После получения ответа ИИ мы проходим несколько этапов для обработки и применения предложенных тегов:

• Разбор JSON: Мы пытаемся разобрать ответ как JSON. Если разбор не удаётся, мы регистрируем ошибку и пропускаем тегирование для этой записи.
• Валидация схемы: Мы проверяем разобранный JSON на соответствие нашей ожидаемой схеме (объект с массивом "tags"). Это позволяет выявить любые структурные отклонения в ответе ИИ.
• Валидация тегов: Мы сверяем предложенные теги с нашим списком действительных тегов проекта. Этот шаг отфильтровывает любые теги, которые не существуют в проекте, что может произойти, если ИИ неправильно понял или если теги проекта изменились между созданием промпта и обработкой ответа.
• Дедупликация: Мы удаляем любые дубликаты тегов из предложения ИИ, чтобы избежать избыточного тегирования.
• Применение: Проверенные и дедуплицированные теги затем применяются к записи в нашей базе данных.
• Логирование и аналитика: Мы регистрируем окончательные применённые теги. Эти данные ценны для мониторинга производительности системы и её улучшения со временем.

Проблемы

Реализация автоматического тегирования на основе ИИ в Blue представила несколько уникальных проблем, каждая из которых требовала инновационных решений для обеспечения надёжной, эффективной и удобной для пользователя функции.

Отмена массовой операции

Функция тегирования с помощью ИИ может выполняться как для отдельных записей, так и массово. Проблема с массовой операцией заключается в том, что если пользователю не нравится результат, ему придётся вручную просматривать тысячи записей и отменять работу ИИ. Очевидно, это неприемлемо.

Для решения этой проблемы мы реализовали инновационную систему сессий тегирования. Каждой массовой операции тегирования присваивается уникальный идентификатор сессии, который связан со всеми тегами, применёнными во время этой сессии. Это позволяет нам эффективно управлять операциями отмены, просто удаляя все теги, связанные с конкретным идентификатором сессии. Мы также удаляем связанные следы аудита, гарантируя, что отменённые операции не оставляют следов в системе. Этот подход даёт пользователям уверенность экспериментировать с тегированием ИИ, зная, что они могут легко отменить изменения при необходимости.

Конфиденциальность данных

Конфиденциальность данных была ещё одной критической проблемой, с которой мы столкнулись.

Наши пользователи доверяют нам свои данные проектов, и было крайне важно обеспечить, чтобы эта информация не сохранялась и не использовалась для обучения модели OpenAI. Мы решили эту проблему с нескольких сторон.

Во-первых, мы заключили соглашение с OpenAI, которое явно запрещает использование наших данных для обучения модели. Кроме того, OpenAI удаляет данные после обработки, обеспечивая дополнительный уровень защиты конфиденциальности.

С нашей стороны мы приняли меры предосторожности, исключив конфиденциальную информацию, такую как данные об исполнителях, из данных, отправляемых в ИИ, чтобы гарантировать, что имена конкретных людей не отправляются третьим лицам вместе с другими данными.

Этот комплексный подход позволяет нам использовать возможности ИИ, сохраняя при этом самые высокие стандарты конфиденциальности и безопасности данных.

Лимиты скорости и обработка ошибок

Одной из наших основных проблем была масштабируемость и ограничение скорости. Прямые вызовы API к OpenAI для каждой записи были бы неэффективными и могли бы быстро достичь лимитов скорости, особенно для крупных проектов или во время пиковой нагрузки. Для решения этой проблемы мы разработали архитектуру фоновых служб, которая позволяет нам группировать запросы и реализовать нашу собственную систему очередей. Этот подход помогает нам управлять частотой вызовов API и обеспечивает более эффективную обработку больших объёмов записей, обеспечивая плавную производительность даже при высокой нагрузке.

Природа взаимодействий с ИИ означала, что мы также должны были подготовиться к случайным ошибкам или неожиданным выводам. Были случаи, когда ИИ мог выдавать недействительный JSON или выводы, которые не соответствовали нашему ожидаемому формату. Для решения этой проблемы мы реализовали надёжную обработку ошибок и логику разбора во всей нашей системе. Если ответ ИИ не является действительным JSON или не содержит ожидаемого ключа "tags", наша система предназначена для обработки этого как будто никаких тегов не было предложено, а не пытаться обработать потенциально повреждённые данные. Это гарантирует, что даже перед лицом непредсказуемости ИИ наша система остаётся стабильной и надёжной.

Будущие разработки

Мы считаем, что функции и продукт Blue в целом никогда не "завершены" — всегда есть место для улучшения.

Были некоторые функции, которые мы рассматривали при первоначальной разработке, но которые не прошли этап определения объёма работ, но интересно отметить, так как мы, вероятно, реализуем некоторую версию их в будущем.

Первое — это добавление описания тегов. Это позволило бы конечным пользователям не только давать тегам название и цвет, но и необязательное описание. Это также было бы передано ИИ, чтобы помочь обеспечить дополнительный контекст и потенциально улучшить точность.

Хотя дополнительный контекст может быть ценным, мы помним о потенциальной сложности, которую он может внести. Существует деликатный баланс между предоставлением полезной информации и перегрузкой пользователей слишком большим количеством деталей. По мере разработки этой функции мы будем сосредоточены на поиске той золотой середины, где добавленный контекст улучшает, а не усложняет пользовательский опыт.

Возможно, самое захватывающее улучшение на нашем горизонте — это интеграция автоматического тегирования с помощью ИИ с нашей системой автоматизации управления проектами.

Это означает, что функция тегирования ИИ может быть либо триггером, либо действием из автоматизации. Это может быть огромным, так как это может превратить эту довольно простую функцию категоризации ИИ в систему маршрутизации работы на основе ИИ.

Представьте автоматизацию, которая гласит:

Когда ИИ помечает запись как "Critical" -> Назначить "Manager" и отправить пользовательское письмо

Это означает, что когда вы тегируете запись с помощью ИИ, если ИИ решает, что это критическая проблема, то он может автоматически назначить менеджера проекта и отправить ему пользовательское письмо. Это расширяет преимущества нашей системы автоматизации управления проектами от чисто основанной на правилах системы до истинно гибкой системы ИИ.

Постоянно исследуя границы ИИ в управлении проектами, мы стремимся предоставить нашим пользователям инструменты, которые не только удовлетворяют их текущие потребности, но и предвосхищают и формируют будущее работы. Как всегда, мы будем разрабатывать эти функции в тесном сотрудничестве с нашим сообществом пользователей, гарантируя, что каждое улучшение добавляет реальную, практическую ценность процессу управления проектами.

Заключение

Вот и всё!

Это была интересная функция для реализации, и один из наших первых шагов в ИИ, наряду с Суммированием контента с помощью ИИ, которое мы ранее запустили. Мы знаем, что ИИ будет играть всё большую и большую роль в управлении проектами в будущем, и мы с нетерпением ждём выпуска большего количества инновационных функций, использующих передовые LLM (большие языковые модели).

Было довольно много чего продумать при реализации этого, и мы особенно взволнованы тем, как мы можем использовать эту функцию в будущем с существующим механизмом автоматизации управления проектами Blue.

Мы также надеемся, что это было интересным чтением, и что оно даёт вам представление о том, как мы думаем о разработке функций, которые вы используете каждый день.