אני עובד בסביבת ארגון ואנחנו משתמשים ב-Discourse כלוח דיונים לתמיכת פלטפורמת ענן.
אנחנו רוצים להשתמש בתוסף ה-AI של Discourse למספר מקרים ושיש לנו גם נקודות קצה פנימיות של AI התואמות ל-OpenAI.
הדבר הוא שכאשר נשלחים בקשות חיצוניות לנקודות קצה אלה, יש לכלול בכותרת האותנטיקציה אסימון OAuth2 שמגיע מנקודת גישה פנימית של מ- M2M שיש לקבל מראש.
חשבתי על כמה גישות, כמו פרוקסי מקומי על מופע EC2 שמארח את Discourse, שיכול להעשיר את הבקשה עם המידע הזה.
גישה נוספת היא שער API עם ל middleware שמקבל את האסימון.
מה שלא הבנתי עד עכשיו הם הכלים שאפשר להוסיף בתוך תוסף ה-AI של Discourse.
האם זה יכול לשמש כדי להשיג את מה שיש לי בראש?
We generally do not like to add too many knobs cause it confuses people but I hear you that this is hard to solve now, we may need another knob.
One option would be to allow the open ai compatible to have a “custom headers” section.
Tools could not easily solve this cause this would create an incredibly complex workflow and we don’t have the ability of easily passing all the information the tool needs.
I guess if custom tools came with enough richness they could accomplish this… it does feel like a bit of a rube goldberg machine but imagine.
IF a configuration with a persona:
Forces tool calls
Has a custom tool forced and it has NO params
THEN we invoke no LLM and simply pass control to the tool
THEN we give the tool enough infra to stream results back to the app via inversion of control in some fashion
Its a pretty staggering amount of change and would end up being an absolute bear to maintain.
I guess an alternative is for you to define a new custom plugin that depends on Discourse-AI and defines your own Dialect and Endpoint - it is certainly the simplest way to go about this.
It is sooooo much easier to solve this specific need via a lightweight proxy, like Nginx with LUA scripting, that I think @Wurzelseppi will be better served going that route.
)