Je travaille dans un environnement d’entreprise et nous utilisons Discourse comme forum de discussion pour supporter une plateforme cloud.
Nous voulons utiliser le plugin Discourse AI pour plusieurs cas d’utilisation et même avoir des points de terminaison IA internes compatibles avec OpenAI.
Le problème est que les requêtes sortantes vers ces points de terminaison doivent inclure un en-tête d’authentification avec un jeton oauth2 provenant d’un point de terminaison d’authentification m2m interne qui doit être récupéré au préalable.
J’ai pensé à plusieurs approches, comme un proxy local sur l’instance ec2 hébergeant Discourse, qui pourrait enrichir la requête avec ces informations d’authentification.
Une autre approche est une passerelle API avec une fonction lambda d’autorisation récupérant le jeton.
Ce que je n’ai pas encore compris, ce sont les outils que l’on peut ajouter dans le plugin Discourse AI lui-même.
Pourrait-on les utiliser pour réaliser ce que j’ai en tête ?
Merci beaucoup pour votre aide et passez une excellente journée !
Nous n’aimons généralement pas ajouter trop d’options car cela confond les gens, mais je comprends que c’est difficile à résoudre maintenant, nous pourrions avoir besoin d’une autre option.
Une option serait de permettre à la compatibilité avec OpenAI d’avoir une section “en-têtes personnalisés”.
Les outils ne pourraient pas résoudre cela facilement car cela créerait un flux de travail incroyablement complexe et nous n’avons pas la capacité de transmettre facilement toutes les informations dont l’outil a besoin.
Merci pour ta réponse et tes réflexions à ce sujet.
Un champ pour les en-têtes personnalisés ne suffirait pas, car le jeton doit être récupéré dynamiquement avant chaque appel API.
Peut-être plutôt une sorte de pipeline/middleware, où l’on peut transmuter l’ensemble de l’appel sortant avec son propre code avant qu’il ne soit envoyé ?
Merci beaucoup les gars et passez une excellente journée !
Je suppose que si les outils personnalisés offraient suffisamment de richesse, ils pourraient y parvenir… cela ressemble un peu à une machine de Rube Goldberg, mais imaginez.
SI une configuration avec une persona :
Force les appels d’outils
A un outil personnalisé forcé et il n’a AUCUN paramètre
ALORS nous n’invoquons aucun LLM et nous passons simplement le contrôle à l’outil
ALORS nous donnons à l’outil suffisamment d’infrastructure pour diffuser les résultats à l’application via une inversion de contrôle d’une manière ou d’une autre
C’est une quantité de changement assez stupéfiante et ce serait un véritable enfer à maintenir.
Je suppose qu’une alternative consiste à définir un nouveau plugin personnalisé qui dépend de Discourse-AI et définit votre propre Dialect et Endpoint - c’est certainement la façon la plus simple de procéder.
Il est tellement plus facile de répondre à ce besoin spécifique via un proxy léger, comme Nginx avec le scripting LUA, que je pense que @Wurzelseppi sera mieux servi en suivant cette voie.
vous êtes géniaux de discuter sérieusement du besoin d’un petit utilisateur comme moi. Je suis toujours frappé par votre dévouement, et je le pense sincèrement (pas de blague )
Oui, comme tout cela fonctionne sur une instance ec2 et que j’ai déjà décidé d’opter pour la voie API Gateway AWS → Lambda → point de terminaison LLM …
Intégré dans Discourse serait plus cool, mais je comprends la complexité que cela apporterait, bien sûr …
Merci beaucoup pour votre temps, et le temps que vous consacrez à aider tous les utilisateurs ici !
Je ne pourrais pas imaginer un meilleur logiciel de forum, non seulement en raison de la maturité du logiciel, mais aussi en raison des personnes qui apportent leur soutien.
Excellente semaine, les gars … et restez comme vous êtes !
)