Я работаю в корпоративной среде, и мы используем Discourse как форум для поддержки облачной платформы.
Мы хотим использовать плагин Discourse AI для нескольких сценариев использования и даже имеем внутренние конечные точки ИИ, совместимые с OpenAI.
Дело в том, что исходящие запросы к этим конечным точкам должны включать заголовок аутентификации с токеном OAuth2, полученным от внутренней конечной точки m2m-аутентификации, который необходимо запросить заранее.
Я рассматривал несколько подходов, например, локальный прокси на экземпляре EC2, где размещён Discourse, который мог бы дополнять запрос этой аутентификационной информацией.
Другой вариант — шлюз API с функцией-авторизатором Lambda, получающей токен.
Что я пока не до конца понял, так это инструменты, которые можно добавить непосредственно в плагин Discourse AI.
Можно ли с их помощью реализовать то, что я задумал?
Мы обычно не любим добавлять слишком много настроек, так как это путает пользователей, но я понимаю, что сейчас это трудно решить, возможно, нам понадобится ещё одна настройка.
Один из вариантов — разрешить совместимым с Open AI решениям иметь раздел «Пользовательские заголовки».
Инструменты не могут легко решить эту проблему, так как это создало бы невероятно сложный рабочий процесс, и у нас нет возможности легко передавать всю информацию, необходимую инструменту.
спасибо за твой ответ и твои мысли по этому поводу.
Поля для пользовательских заголовков было бы недостаточно, поскольку токен нужно получать динамически перед каждым вызовом API.
Может быть, лучше реализовать что-то вроде пайплайна или middleware, где кто-то может преобразовать весь исходящий запрос своим кодом перед его отправкой?
Думаю, если бы пользовательские инструменты были достаточно функциональными, они могли бы это реализовать… Это, конечно, напоминает машину Руба Голдберга, но представьте:
ЕСЛИ конфигурация с персонажем:
Принудительно вызывает инструменты,
И принудительно использует пользовательский инструмент без параметров,
ТО мы не вызываем LLM, а просто передаем управление инструменту.
ТО предоставляем инструменту необходимую инфраструктуру для потоковой передачи результатов обратно в приложение через инверсию управления каким-либо образом.
Это колоссальное количество изменений, и в итоге поддержка такого решения станет настоящей головной болью.
Другой вариант — создать новый пользовательский плагин, который зависит от Discourse-AI и определяет собственный диалект и конечную точку. Это, безусловно, самый простой способ решить задачу.
Решить эту конкретную задачу гораздо проще с помощью легковесного прокси, такого как Nginx со скриптингом на LUA, поэтому я считаю, что @Wurzelseppi будет лучше выбрать именно этот путь.
вы потрясающие, что так искренне обсуждаете потребности такого маленького пользователя, как я. Я всегда поражаюсь вашей преданности делу, и я говорю это серьёзно (без шуток :-))
Да, так как всё это работает на экземпляре EC2, я уже решил идти путём AWS API Gateway → Lambda → конечная точка LLM…
Конечно, было бы круче, если бы это было встроено в Discourse, но я понимаю, какую сложность это добавило бы…
Большое спасибо за ваше время и за то, что помогаете всем пользователям здесь!
Не мог представить лучшего программного обеспечения для форума, и не только из-за зрелости самого ПО, но и из-за людей, которые оказывают поддержку.
Отличной вам недели, ребята… и оставайтесь такими же!