Recommended
Recommended
More Related Content
What's hot
What's hot (15)
Similar to IndexConf 2018: AI Strategy Pattern
Similar to IndexConf 2018: AI Strategy Pattern (20)
Recently uploaded
Recently uploaded (20)
IndexConf 2018: AI Strategy Pattern
- 1. 1 The Globant Approach to Cognitive Our machines should be nothing more than tools for extending the powers of the human beings who use them. –Thomas Watson Jr.
- 2. ● Augment and elevate humans in the system to their own higher value ● Be trusted and valuable in itself 2 We Apply A “Systems Lens” By recognizing that there are many parts to a system, and that each should rise to its highest performance, we can use Cognitive to maximize the value of the people, processes, and technologies. ● Mind the rules of all other investments (gain efficiencies, show ROI, improve experience) ● Support a full digital transformation
- 3. Cognitive Applications That We Experience Today… 3 …are the feature requests, product ideas, and business requirements we wish we’d already implemented... “Why don’t we add some AI to our product too?” “Ya know … we could really help our users do this better if we applied a little AI.” “Hey, I’ve got this great idea for a new product that uses AI for …”
- 4. Allowing for Augmented Intelligence Sean Kennedy, Principal Digital Architect Twitter: seanpk8 ॰ GitHub: seanpk
- 6. How We Might Set Out to Use AI ● Create a new experience ● Enhance an existing experience ● Improve some quality of a service 6
- 7. Concerns That Can Complicate Our Approach ● Providing the “better” (as designed) experience that uses AI ● Learning from how it’s used, both as designers and as AI ● Being prepared for everything to change 7
- 8. The Strategy Design Pattern is a Natural Fit 8 The Context CONTAINS Data State Profile History etc. CONTAINS The algorithm and associated complex data structures The Strategy References the Strategy Other Strategies Executes in the Context
- 9. The Strategy Design Pattern is a Natural Fit 9 The Context CONTAINS Data State Profile History etc. CONTAINS The algorithm and associated complex data structures The Strategy References the Strategy Other Strategies Executes in the Context Rules Add rules to the execution environment to determine when a new Strategy should be tried x
- 10. The Strategy Design Pattern is a Natural Fit 10 The Context CONTAINS Data State Profile History etc. CONTAINS The algorithm and associated complex data structures The Strategy References the Strategy Other Strategies Executes in the Context Rules Even when an API is used to access the AI, still encapsulate that as a Strategy on the client API Integration
- 11. The Strategy Design Pattern is a Natural Fit 11 The Context CONTAINS Data State Profile History etc. CONTAINS The algorithm and associated complex data structures The data collection Strategy References the Strategy Other Strategies Executes in the Context Rules Hey, why not use the same approach for collecting data for future AI training and learning as designers? API Integration References the data collection Strategy, too
- 12. Into The Great Wide Open 12 Allow for all kinds of “intelligence” - both now and in the future Use the Strategy Pattern to separate the concerns of 1. interfacing with the “AI” and 2. collecting data to improve it, from those of providing the user experience.
- 13. Thank You Hello@PointSource.com Twitter: seanpk8 ॰ GitHub: seanpk
Editor's Notes
- How PS thinks of cognitive
- Examples include using machine learning for conserving energy and increasing efficiencies.
- Now, many companies that we talk, clients and prospects, want to do *something* with “AI”. Really, no matter how it might seem to us in the industry, most companies are still figuring out what Cognitive is, and are a long way from understanding how they can really apply it. We think it’s important to pick an application of AI where isn’t in the leading role but where it can win for best supporting “actbot”.
- Thanks Justin, “live and learn” … although, I seem to have a penchant for learning “the hard way” Now, isn’t this stage amazing!? When they contacted me two weeks ago about coming to speak at this conference, I had no idea it would be such an incredible opportunity! Can someone take a picture and tweet it at me so I can show it to my mom? :-) (yeah, all of you is fine too) And keep your phones out to tweet anything that resonates with you, or to tell me where I’m really missing the boat… You see, I have two goals for this talk, Secondly: to find out if others with similar experiences agree with my conclusions, and especially if they don’t so that I can do things differently in the future without having to learning things the “hard way”, again And Primarily: to share our experience integrating Cognitive/”AI”/”intelligence”/whatever into user experiences so that YOU have another option, besides “the hard way”, to choose from
- So … looking at this slide ... we’re consultants. But at our best we’re partners with our clients and we help them uncover and realize business results that they couldn’t even imagine on their own. 3 years ago I worked on my first product, conceived in collaboration with a client, that we designed to leverage AI to drive a differentiating user experience. By the mid-way point of that project it was clear that we didn’t have the data to make that AI do anything useful. Fortunately, we were able to convert the “artificial stupidity engine”, as we called it, which we had created to make progress on other parts of the product, to power the MVP. That experience, and several more since, make up the “hard way” learning that were necessary to get me here to speak with you today. But before I give you The Secret, let’s set the stage for the problem.
- Whatever you’re going to do, basically everything you’ve ever experienced working with a co-evolving client and server is compounded and exacerbated with the introduction of AI.
- 1 Certainly it’s important to know whether it really is “better”, so we have to figure out how to measure that and how to collect that data Also, it’s necessary to figure out graceful fallbacks for when the AI doesn’t work as expected … whether it’s the user indicating this or, ideally, when we can detect this ourselves 2 Need to capture, as much as possible, the whole context of the interaction and usage 3 AI and application need to evolve independently, but also symbiotically For the big reveal, the secret is on the next slide (it was also in the abstract if you read it) and maybe with the situation set you’ve already pulled the right tool out of your toolbox (because you’re wise and think before you do).
- The 2 key parts we need of the strategy pattern are: 1. That the strategies, representing our gateways to the “intelligence” we’re going to leverage, exist at all 2. That we have the flexibility to change the strategy in use, even at runtime This provides the perfect mechanism for falling back to a non-AI solution when the AI is not working the way we want. We can even release a version of the product that only uses that non-AI Strategy before the AI is ready; especially collecting data from the app for training that future AI
- Makes is easier to move between versions Some future version may depend on using parts of the Context that previous solutions didn’t
- Here, we get to a key point, one that I’m not sure I would’ve figured out without “the hard way”: Even when the AI is accessed through an API, it is still helpful to have the Strategy pattern in place close to the user’s experience. Making an API call is not a replacement for applying the Strategy pattern! The alternative, which we’ve experienced and suffered through, is that whenever a new iteration of the AI is available, we have to coordinate changes in the application to gather the additional data necessary for the new AI to work, and who even knows what we have to do to make sense of the “enhanced” answer it’s now giving. This is especially troublesome when you’re relying on SaaS AI APIs, like those from IBM Watson. And not that this is unique to IBM, but it is where we experienced it very badly: there’s one product we’ve been working on for the past 15 months where we’ve had the API we were depending on deprecated and replaced 3 times!
- Ultimately, to me, that we can use the same approach to handling our data collection Strategy is a thing of beauty and a sign that we might be on to something. You see, we have to balance performance and experience for the user with our desire to get all the data we can … different Strategies for collection, coupled with some rules, driven off resource usage and user preference, for choosing between them can help us achieve that balance
- Conclusion, based on the Abstract: Applying “AI” techniques and tools is in reach for more organizations than ever before, and the best user experiences in the market depend on the ability to leverage their results. They depend on them, but they are not them. That is, the best-in-class user experiences are designed experiences through which intelligence is made manifest. Whether your intelligence is based on machine learning, deep learning, analytics, business rules, API integrations like those from Watson, or traditional developer sweat and algorithms, and also because you ought to plan for each of those to play some part, we’ve come to recommend using the Strategy design pattern to augment the (perceived) intelligence and improve the user experience of apps, chatbots, and APIs. Like I said at the beginning, I had two goals for this talk. I hope I’ve achieved my primary goal of sharing something valuable that you can make use of instead of having to (re)learn “the hard way”. And my secondary goal of getting validation and criticism from other practitioners, let’s work that out in the AMA at 4 PM, on twitter, or over drinks at the Index Bash!