Я создаю автоматизации на базе ИИ, используя независимые скрипты первичной обработки (например, проверка на спам, определение тегов). В настоящее время они выполняются параллельно, что неэффективно. Мне нужно «объединить» их в цепочку, чтобы, например, скрипт определения тегов запускался только в том случае, если скрипт проверки на спам не пометил контент как спам.
Как я могу управлять и оркестрировать эти скрипты для создания более логичного рабочего процесса? В частности, как можно условно объединить эти скрипты в цепочку?
Можете описать полный желаемый процесс? Будет ли это решение, которое вы запускаете на отдельном сервере, или вы хотите, чтобы оно работало внутри Discourse?
Рабочие процессы с ИИ — это то, над чем мы много думаем. Возможность определять цепочки действий является ключевой для рабочих процессов. Я полностью согласен с этим.
Насколько я вижу, большинство моих сценариев использования можно реализовать в Discourse с помощью AI Triage и автоматизации, если удаётся настроить цепочку триггеров.
Вот гипотетический поток, где на каждом этапе содержимое поста и промпт отправляются LLM:
Проверка на спам
Если это спам, скрыть пост и пометить как спам
Если это не спам, определить обсуждаемые продукты
Добавить метку(и) продукта
Далее определить намерение:
** Жалоба
** Вопрос
** Предложение
** Обмен информацией
** Положительный отзыв
Добавить метку намерения
Если намерение — «жалоба», оценить наличие острых тем: например, содержатся ли фразы-триггеры (отмена, ужасно, медленно)
Если тема острая, добавить метку «острое» и назначить Сэму
Если намерение — «положительный отзыв», а продукт — «беспроводной тарифный план», составить персональное приглашение в программу рефералов и отправить в личные сообщения.
Это отлично и очень интересный вариант использования.
У пользовательских инструментов уже есть поддержка скриптов, так что у нас есть отличная платформа для таких изменений.
Я думаю о комбинации Persona и принудительного использования инструментов — тогда из инструмента мы сможем запустить поток, учитывая, что у нас уже есть вся необходимая инфраструктура. Нужно лишь дать пользовательским инструментам возможность запускать другие вызовы LLM, что довольно просто реализовать.
Интересно, что поскольку пользовательские инструменты поддерживают REST-вызовы, они могут выполнить весь поток (просто используя REST API Discourse для настройки этой связи).
Давайте я подумаю об этом в выходные, и на следующей неделе отвечу снова с тем, как, по моему мнению, мы можем это реализовать.
Цепочка автоматизации также очень интересный подход здесь, @j.jaffeux, вы думали об этой проблеме?
Это напоминает мне цепочку действий IFTT/Zapier. Думаю, если мы создадим что-то подобное, мы сможем позаимствовать у них множество элементов интерфейса и пользовательского опыта.
Привет, @Cloud_spanner! Я пытаюсь разобраться в этом вопросе и хотел бы немного детализировать реальный процесс. Не могли бы вы помочь, ответив на следующие вопросы?
Какие сообщения должны сканироваться?
Каждое новое сообщение на форуме?
Каждую новую тему (например, первое сообщение) на форуме?
А как насчет правок? Должны ли сканироваться все правки? С какой частотой? (задержка 10 минут)
А пользователи с высоким уровнем доверия? Люди, которые уже публиковали на форуме дважды?
Намерение
Должно ли это применяться ко ВСЕМ темам? Ко ВСЕМ сообщениям?
Что делать, если тег намерения уже присутствует?
Может ли у темы быть более одного намерения (является ли это группой тегов?)?
Если намерение может быть задано вручную, должны ли также сканироваться помеченные вручную сообщения на предмет «острых вопросов»?
Является ли тег hot невидимым или видимым?
В частности, меня в данном случае беспокоит следующее:
Содержит ли «рабочий процесс» сокращения, при которых определенные сообщения пропускают шаги и сразу переходят к следующему?
Как нам избежать циклов обратной связи и пограничных случаев?
Каждое новое обсуждение должно запускать рабочий процесс AI-триажи. Правки можно игнорировать.
Для ясности: я использую понятие «намерение» (intent) только для иллюстрации рабочего процесса, поэтому его не следует рассматривать как жёстко заданную последовательность. Суть в том, что нет смысла запускать рабочий процесс «намерения», если первый этап триажи признаёт его ненужным. Поддерживаю концепцию рабочего процесса IFTTT.
В этом примере теги «намерение» (intent) и «горячее» (hot) будут невидимыми и доступны только модераторам и администраторам.
На каждый пост должен приходиться ровно один тег «намерение».
Я считаю, что в рамках рабочего процесса можно игнорировать посты с ручной разметкой.
Да.
А что если использовать специальный приватный тег, чтобы показать, что процесс уже был выполнен для этой темы? Тогда его можно будет игнорировать при всех последующих запусках.
Ещё одна мысль: учитывая возросшие возможности LLM в области «рассуждений» и большие окна контекста, не лучше ли разрешить использование структурированных выводов в окне автоматизации Discourse? Тогда логику IFTTT можно было бы применять к одному единственному процессу автоматизации вместо цепочки из нескольких. Представьте, что была бы возможность создать одну автоматизацию, но с множеством действий «Поиск текста».
Мы можем добавить для неё несколько дополнительных функций, таких как llm.generate, topic.close, topic.tag и другие, которые инструмент сможет использовать для выполнения подобных рабочих процессов.
Ещё одним преимуществом этого подхода является возможность тестирования, что упростит настройку инструмента.
Звучит как отличная идея. Я всё ещё довольно новичок в экосистеме Discourse, поэтому изучу Custom Tools, а также то, как запросы на новые функции доходят до реализации.
У меня есть хорошие новости: ваш рабочий процесс теперь полностью реализуем с помощью пользовательских инструментов!
Суть в том, что вы определяете один пользовательский инструмент со всеми параметрами:
is_spam, intent, hot, requires_invite
Затем вы настраиваете triage using persona для вызова этого инструмента, который выполнит все необходимые действия (в данный момент через API Discourse, но по мере развития мы сможем предоставлять больше встроенных функций).
Отличное введение в то, как всё это можно связать вместе, доступно здесь:
Я также столкнулся с проблемой невозможности оркестрации выполнения скриптов автоматизации вместе с детектором спама.
Отличная новость заключается в том, что Discourse теперь создал базовый плагин «Workflows» (Рабочие процессы), который облегчает реализацию тех же типов приложений, что и плагин «Automation» (Автоматизация), но гораздо более мощным и гибким способом:
Запрошенная здесь оркестрация может быть достигнута, если вы используете плагин Workflows для реализации систем, которые ранее реализовывались через плагин Automation.
Целью моей автоматизации было постановка флагов на сообщениях с определенными характеристиками, которые могут указывать на спам, но не однозначно. Проблема, с которой я столкнулся, заключается в том, что эти же характеристики часто присутствуют в спам-сообщениях, помеченных системой обнаружения спама Discourse AI. Это приводило к тому, что автоматизация часто ставила избыточные флаги, создавая бессмысленную дополнительную работу для модераторов.
«Обходной путь», предложенный выше, заключающийся в объединении всего в единую автоматизацию, не подходил для моей системы, поскольку я намеренно разделял эти две системы:
Задача системы обнаружения спама — выявлять сообщения с высокой вероятностью спама.
Задача моей вспомогательной системы — привлекать внимание модераторов к сообщениям, которые имеют некоторую вероятность быть спамом.
Поскольку детектор спама Discourse AI имеет специальную реализацию в фреймворке Discourse (в отличие от чистой работы на фреймворке Discourse AI, предоставляемом администратору форума), у меня не было никакого желания пытаться заменить его автоматизацией.
Кроме того, не было целесообразно объединять мою вспомогательную систему с детектором спама (добавляя инструкции в промпт). Поведение спам-системы, немедленно скрывающее сообщение и заглушающее автора, уместно, пока оно настроено на работу с высокой точностью. Напротив, моя вспомогательная система по своей природе подвержена ложным срабатываниям, и поэтому ее флаги не должны влиять на пользователя до проверки человеком.
Решение, которое мне удалось достичь после замены автоматизации на рабочий процесс:
Триггер «Создание сообщения».
Шаг «Ожидание», чтобы дать время системе обнаружения спама на выполнение.
Шаг «Data Explorer» (Исследователь данных) для получения данных о сообщении:
