search

microsoft / teams-ai

SDK focused on building AI based applications and extensions for Microsoft Teams and other Bot Framework channels
MIT License
415 stars 182 forks source link

[Feature Request]: <Use Recognizer vs Activity Handler superclassinf> #170

Closed guru98 closed 1 year ago

guru98 commented 1 year ago

Why you didn't implement the library as a recognizer instead a replacement of the activity handler? This approach could be more generic compatible with composer and potentiallty usable with other connectors than Teams.

corinagum commented 1 year ago

Our team is not affiliated with the Composer. My understanding of Composer is that it is a solution for a code-less bot building experience, which is not the goal of this repo.

The focus of this repo (aside from the AI aspect) is for Teams-specific features (e.g. Message Extensions), so the code will build on top of Teams bot development. The part of the repo that is for Teams features won't be applicable to other channels without extra work from the bot developer. I'm taking a stab at the features of the recognizer that you are looking for:

  1. Text recognition / Regex handling to route to the correct response / handler. This is already available via app.message(..., which can use regular expressions or strings to identify the action for the app, without needing to take on Composer verbiage or even use AI to help with detection. That would be the equivalent of Composer's Recognizer (without LUIS)

  2. Having the ability to implement LUIS in the app app.ai.action(.... is the OpenAI equivalent to LUIS detection, but the models available for OpenAI are more robust than LUIS with less configuration needed. (Intents, entities, or their equivalents are all handled in prompt.txt, and OpenAI models don't require different apps to be created per human spoken/written language).

As far as I recall, Composer is the only connector/channel that abstracts out the Activity Handler concept, and therefore is not a prerequisite for other channels to take advantage of the AI section of this codebase.

The Activity Handler isn't unique to Teams, and therefore still builds on top of 'universal' Bot Builder concepts. As you might guess, with a focus on OpenAI, there is no immediate need for this repo to make use of LUIS language understanding, since our prompts for the assistant / AI can naturally detect 'intents' using its language model and prompt. I can't speak for the future as to whether or not LUIS will be supported by us in the future, but at the moment it is not on our roadmap.

guru98 commented 1 year ago

I suggest to use recognizer as are more generic and can be used in a more generic way as, in my mind , activity handler should be full feature from bot point if view , eg support all type of activity as events. The scenario is the one you highliged: an alternative to Luis easier to use and more robust. I have an other question scenario like intents with parameters and subsequent request if all parameters are not provide how are handle with your framework? With a new message with a context? No use of activedialogs etc ?

From: Corina @.> Sent: Monday, June 5, 2023 8:47:27 PM To: microsoft/teams-ai @.> Cc: Ugo Castellani @.>; Author @.> Subject: Re: [microsoft/teams-ai] [Feature Request]: (Issue #170)

Our team is not affiliated with the Composer. My understanding of Composer is that it is a solution for a code-less bot building experience, which is not the goal of this repo.

The focus of this repo (aside from the AI aspect) is for Teams-specific features (e.g. Message Extensions), so the code will build on top of Teams bot development. The part of the repo that is for Teams features won't be applicable to other channels without extra work from the bot developer. I'm taking a stab at the features of the recognizer that you are looking for:

  1. Text recognition / Regex handling to route to the correct response / handler. This is already available via app.message(..., which can use regular expressions or strings to identify the action for the app, without needing to take on Composer verbiage or even use AI to help with detection. That would be the equivalent of Composer's Recognizer (without LUIS)

  2. Having the ability to implement LUIS in the app app.ai.action(.... is the OpenAI equivalent to LUIS detection, but the models available for OpenAI are more robust than LUIS with less configuration needed. (Intents, entities, or their equivalents are all handled in prompt.txt, and OpenAI models don't require different apps to be created per human spoken/written language).

As far as I recall, Composer is the only connector/channel that abstracts out the Activity Handler concept, and therefore is not a prerequisite for other channels to take advantage of the AI section of this codebase.

The Activity Handler isn't unique to Teams, and therefore still builds on top of 'universal' Bot Builder concepts. As you might guess, with a focus on OpenAI, there is no immediate need for this repo to make use of LUIS language understanding, since our prompts for the assistant / AI can naturally detect 'intents' using its language model and prompt. I can't speak for the future as to whether or not LUIS will be supported by us in the future, but at the moment it is not on our roadmap.

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/teams-ai/issues/170#issuecomment-1577292070, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA77TTXJ27SREDY4327DPTDXJYST7ANCNFSM6AAAAAAYZGTNQ4. You are receiving this because you authored the thread.Message ID: @.***>

corinagum commented 1 year ago

@guru98 I'd recommend taking a look at the documentation and samples to get a better idea of what capabilities the repo has. In particular I think the samples may help with understanding concepts of learning to 'speak' with an AI agent/assistant. Those samples are categorized under 04.____ in the samples. :)

guru98 commented 1 year ago

@corinagum many thanks, anyway. It was just a suggestion. I wrote bots for the last 5 years and I have a sort of confidence with assistants and agents. As you can immagine i used other tecnology to recognize intents and handle in the bot. As you mentioned in a previous post use of openai instead of language understanding could have better results as use framework like semantic kernel and planners allow very interesting and powerful scenarious. My only concern is that replace of activity handler in the bot framework isn't a great idea as suppose that a specific bot have to be used for one channel only. Also an activity handler replacement shoud manage all possible type of activity as the original activity handler does (like events). I think that teams-ai is a great idea but you shoud be more accurate in the architectural choices ..., probably use a custom recognizer could be not the best solution but be invasive in a "standard" architecture is not better. Thanks for your time to answer to my question.