ich arbeite in einer Unternehmenskultur und wir verwenden Discourse als Diskussionsforum zur Unterstützung einer Cloud-Plattform.
Wir möchten das Discourse AI-Plugin für mehrere Anwendungsfälle nutzen und haben sogar interne AI-Endpunkte, die OpenAI-kompatibel sind.
Das Problem ist, dass ausgehende Anfragen an diese Endpunkte einen Authentifizierungs-Header mit einem OAuth2-Token enthalten müssen, das von einem internen M2M-Authentifizierungsendpunkt stammt und im Voraus abgerufen werden muss.
Ich habe an verschiedene Ansätze gedacht, wie z.B. einen lokalen Proxy auf der EC2-Instanz, die Discourse hostet, der die Anfrage mit diesen Auth-Informationen anreichern könnte.
Ein anderer Ansatz ist eine API-Gateway mit einer Autorisierer-Lambda, das das Token erhält.
Was ich bisher nicht ganz verstanden habe, sind die Tools, die innerhalb des Discourse AI-Plugins selbst hinzugefügt werden können.
Könnte das dazu verwendet werden, um das zu erreichen, was ich im Sinn habe?
Vielen Dank für eure Unterstützung und einen schönen Tag!
Wir mögen es im Allgemeinen nicht, zu viele Regler hinzuzufügen, da dies die Leute verwirrt, aber ich verstehe, dass dies jetzt schwer zu lösen ist, wir brauchen vielleicht einen weiteren Regler.
Eine Möglichkeit wäre, der OpenAI-kompatiblen Option einen Abschnitt „Benutzerdefinierte Header“ zu geben.
Tools konnten dies nicht einfach lösen, da dies einen unglaublich komplexen Workflow schaffen würde und wir nicht die Möglichkeit haben, alle Informationen, die das Tool benötigt, einfach weiterzugeben.
Autsch, das ist wirklich ziemlich fortgeschritten.
Ich schätze, wenn benutzerdefinierte Tools über genügend Funktionalität verfügen würden, könnten sie dies erreichen… es fühlt sich ein wenig wie eine Rube-Goldberg-Maschine an, aber stellen Sie sich vor.
WENN eine Konfiguration mit einer Persona:
Tool-Aufrufe erzwingt
Ein benutzerdefiniertes Tool erzwingt und es hat KEINE Parameter
DANN rufen wir keine LLM auf und übergeben einfach die Kontrolle an das Tool
DANN geben wir dem Tool genügend Infrastruktur, um Ergebnisse über Inversion of Control in irgendeiner Weise an die App zu streamen
Das ist eine ziemlich erstaunliche Menge an Änderungen und wäre am Ende ein absoluter Albtraum zu warten.
Ich schätze, eine Alternative ist, dass Sie ein neues benutzerdefiniertes Plugin definieren, das von Discourse-AI abhängt und Ihre eigene Dialekt und Endpunkt definiert - es ist sicherlich der einfachste Weg, dies zu tun.
Es ist sooooo viel einfacher, diesen speziellen Bedarf über einen leichtgewichtigen Proxy zu lösen, wie Nginx mit LUA-Skripting, dass ich denke, @Wurzelseppi wird besser bedient sein, wenn er diesen Weg geht.
ihr seid spitze, dass ihr euch ernsthaft mit den Bedürfnissen eines kleinen Nutzers wie mir auseinandersetzt. Ich bin immer wieder von eurem Engagement beeindruckt, und das meine ich ernst (kein Scherz :-))
Ja, da das Ganze auf einer EC2-Instanz läuft und ich mich bereits für den Weg AWS API Gateway → Lambda → LLM-Endpunkt entschieden habe …
Direkt in Discourse integriert wäre cooler, aber ich verstehe natürlich die Komplexität, die das mit sich bringen würde …
Vielen Dank für eure Zeit und die Zeit, die ihr hier allen Nutzern helft!
Ich könnte mir keine bessere Board-Software vorstellen, nicht nur wegen der Reife der Software, sondern auch wegen der Leute, die Unterstützung leisten.