 Thank you! So let's get that out. Okay, cool. So I'm Jayden from ematic.ai. I see a couple of familiar faces, so possibly something you guys have seen this before. So Word of Warning is kind of a bit of a high-level kind of overview kind of talk, so more focused on problems. But we've built this all in Ruby, so after that, happy to take some questions. How much time do I have? So what's the company do? We build assistance that increase productivity. That's our passion because we want to give everyone time to do things that they love. Basically, we're lazy, machines should do stuff for us. There's a bit about me, engineer, Yahoo, whatever. Let's skip to the interesting bit. What is AI? And I always start with this because whenever we talk about AI, it conjures up a lot of images in people's mind, and most of the time, what people think about, I mean, it's nothing new, right? And the whole point of the slide is it's been around, this was coined in 1956, obviously, work on making intelligent machines have started way before that. But whenever we talk about AI, this is what people think about, right? They think about Terminator or they think about Her, they think about Scarlett Johansson and someone you can fall in love with and talk to. But the reality is a bit more like this today, right? I mean, chatbots are a huge, huge space right now, everyone wants to do them. But the reality is that they're kind of really a little limited today, right? So if you go off the rails, they aren't really able to respond. And that's simply just a fact of the state of the art, right? I mean, no one really knows how to build a truly flexible thinking machine that incorporates all the kind of world knowledge that we have. And that can kind of really respond to you intelligently outside kind of certain volume. So another quick thing about what's an agent versus a chatbot. So here's a chatbot, it says schedule meeting for us next week. And you notice this is a pretty broad statement, right? You didn't say when. But it turns out chatbots today tend to function a little more like IVR agents, right? So they want to know like something specific that you want them to do. So they need to know like what they, right? So maybe suggest two days and that's still not good enough. And then they want to know what time. So literally if you try this with Siri, this is exactly what you would get, right? I mean, Siri will actually ask you for specifically when you would like to have this meeting. And then it will proceed to send a calendar invite out, right? At which point you're like, done, I'm done with this, right? And I forgot to set the context. This is basically kind of a busy executive. You're really on the run. You're just shooting emails off. And what you really want to do is to hand this off to an agent. Now the difference is an agent takes ownership and it's autonomous, right? So it makes decisions on your behalf. So you throw a task. It's ambiguous. It's ill-defined, relatively speaking. But the agent says, okay, fine. Let me go figure this out, okay? And it goes off. It emails the people on your behalf that you want to meet, figures out time based on your calendar and their responses and says, okay, I've confirmed the meeting Monday, 3pm, send the invite out. And, you know, if you work in the corporate world, you know a lot of people live and die by their calendars, right? So that's the difference between an agent and a chatbot. And obviously what we're building is closer to the agent side of things. So I'll have a quick video that will introduce EV to you guys that will set the stage and then we dive a bit deeper, which doesn't play, which never plays. Let's figure this out. Okay, all right. Okay, great. So it's built with Ruby, of course, but there's a slide missing, which is, so let's around a second. Right, so just a quick recap. As you saw, EV's really this AI system, it reads and writes emails, right? So you notice there wasn't anything special that the users need to do. They email the person they're talking to, or they want to meet, and then you just copy EV into the email like they would a real assistant, right? So if you had a real assistant, that's exactly how they would interact, right? And, you know, EV takes over from there and interacts like a real person, looks at your calendar, sends you, sends them some times, they can respond using natural language, and they can literally say anything they want, right? There's no keywords, there's no kind of boundaries, and EV would just handle it like a real assistant would, yeah? And of course, it's built with Ruby, mostly. It's a little bit of Python in there. And so, and, you know, a lot of people say, well, that's a strange choice, right? Because Ruby isn't usually the language that people use to do natural language or to do any sort of machine learning or anything like that, right? So why did we pick Ruby? Very simply, speed, right? And speed is not something you associate with Ruby, but in terms of raw performance, but what we are doing is we're building a ton of these algorithms from scratch, right? A lot of the natural language algorithms, a lot of the scheduling algorithms, we built and rebuilt multiple times, and the choice of Ruby was really to allow us to iterate really, really quickly, right? And to build something like a tiny mini Hadoop style thing that's totally integrated into your code base, and you can do that in less than a week. In fact, you could probably do it in a day or two in Ruby, which implements some sort of parallel execution or some sort of kind of map-reduced type implementation at a small scale, right? So it lets us iterate very, very quickly because literally, this is new stuff, right? I mean, I think no one's really built a kind of fully automated AI. And a lot of things that we need to try and throw out, or, you know, we've rebuilt algorithms at least three times, I think, for scheduling. And I think our natural language algorithm is on to its fifth iteration. And that doesn't count all the incremental kind of stuff that gets built on top of it, right? So that's Ruby. So now I thought I'd spend a little bit of time just talking a little bit about the challenges of natural language processing, right? Which we call speaking human. So let's take a very simple example. Someone says, let's meet for lunch. And implicitly, between you and that person, you know that lunch is typically a meal and it's somewhere between 12 to 2. And you actually have to usually meet in person for lunch. Now, machine knows nothing about this, right? So the first thing you need to do is to encode all this information into Ruby, sorry, into code, right? So you have to have some sort of ontology that you or a dictionary, if you will. And Ruby makes it really easy to do this because hashes are really easy to manipulate, right? And it's got great syntax, very elegant, and you really get to just say what you mean. So it really makes it easy for us to encode this sort of information and manipulate it, right? Then you have to think about syntax versus semantics, right? So consider I'm free at five, but I have to run at six. This means really you want to meet at five, but it's got to end. It means you've got to run end at six. And you connect with I'm busy at five and I'm available at six. So a lot of traditional syntactic analysis tools that exist in natural language today are able to tell you a syntax, right? This is a noun, this is a verb, this is a dependency graph. But what they can't tell you is that, in fact, although these two looks tactically similar, they're actually, from a meeting perspective, almost entirely opposite, right? So if you run a traditional word-to-vec program, which is a fairly common first step in a machine learning kind of pipeline for NLP, you'll find that these phrases are going to come out looking very similar in a vector space, right? So we need to basically write our own custom algorithms on top of this, combine that with the ontology to be able to just make these distinct ones, right? And you know, so here's another example. Let's meet Thursday or Friday afternoon works. Really simple sentence. Again, effortless for a human to process, you know, exactly what this means. But let's consider, right, that the machine really just sees this as a sequence of symbols. So first of all, Friday and afternoon need to be joined together. You're really talking about Friday afternoon. Very straightforward. But then you need to look a little further and realize that, hey, that the word afternoon, although it's a little ambiguous, probably belongs to Thursday as well, right? So you need to kind of look at how you can group stuff. And then on top of that, you then have to take this entire Thursday or Friday afternoon chunk and treat that as a single unit, right? And use that and say, hey, this person is saying that both Thursday and Friday afternoon work, right? And again, you can imagine how, you know, using the Ruby hash format, it's really easy to combine these things and kind of construct a structured representation of what Thursday or Friday afternoon really means, right? And so I think that has really kind of paid a lot of dividends for us. Here's another example of another different sort of problem that we need to deal with. Let's do coffee at Holland Village, say Starbucks or Yapen, okay? So a few things we need to pass out here. Besides the natural language syntax and structure, there's an implicit relationship here. First of all, Holland Village, HV in the Singapore context means Holland Village, right? That isn't necessarily the case for someone in San Francisco or in Seattle or New York, right? So we need to have very, very region and city specific dereferencing or core reference resolution to be able to decode something like HV and put it in the right context. In fact, this might even vary from person to person, right? So that's the first problem. Then you need to recognize that there's an implicit relationship that Starbucks is a very specific venue within Holland Village, the area, and the same thing with Yapen. And so you know that there are actually two kind of proposals here, right? Holland Village at Starbucks or Holland Village at Yapen. And again, I love hashes. They allow us to just throw stuff in and add more and more resolution to a particular location as you build it up, right? And as you read the sentence, you just add more attributes to it. As long as you've got your schema done properly, you can actually do this fairly simply. Here's the last problem. And now we go a little bit beyond just the surface level reading of language. I'm in Hong Kong next week. So subject, this is a fact, right? This is simply a statement of fact. So you need to first be able to take that sentence and turn it into a structured representation, which is the fact, right? That, hey, I'm in Hong Kong. So the person who's speaking, the first person form is saying that this person's in Hong Kong, right? And you can have some details about Hong Kong. And again, there's a validity now attached to this fact. So you first need to capture this, store it, and then you need to reason from this because it depends very much on what you're trying to do, right? So in the context of an AI meeting assistant trying to start with scheduling a meeting, we need to now bring in the context of conversation and figure out where's this meeting, right? Is this meeting going to be in Singapore? Am I organizing meeting in Hong Kong? Is it a call, right? Does this person have any personalization parameters, right? It's like, oh, well, no calls, be honest at the time, or I only do calls on Monday, Wednesdays or Fridays. And only after you're taking the context plus the fact, are you able to make some decisions? So there's another kind of big brain there that makes these decisions. It says, takes the fact, takes the context, reasons from it and says, well, you know, maybe I need to propose a time next week because it is in Hong Kong. So it's a great time. Or maybe I need to find another time range because it's not a good time, right? Or I need to change the meeting to a call. So there are various actions that you can take. And it all starts from just one single sentence. You can trigger this kind of, not cascade, but literally a sequence of events that could result in a decision where you can say, well, I want to reschedule the meeting, or I'm going to turn it into a call if it's urgent, or I'm going to move it to another time, right? So at a higher level, this is kind of what the natural language pipeline looks like. And it's, as I said, all built-in Ruby with the exception of the shelf components. So the tokenizer and POS tagger are off-the-shelf. And this is one of the components that are actually, is actually running in Python right now. But the reality is it could run in Java, it could run in C, it could run in whatever natural language library we haven't had it connected to. And the reason for that is because these are fairly well-solved problems in academia, right? I mean, you can get really good off-the-shelf tokenizers and puzzle speech taggers that will basically break a sentence up into its constituent words and tell you, you know, within some level of approximation or accuracy what part of speech each word is, right? And these in and off themselves are the product of kind of 30 years of research and, you know, they all incorporate kind of latest machine learning techniques. And some of them, I think, if you guys follow the space, Google's pasty mac past space or model has uses neural nets as well to help with some of the decision-making. Then the rest of it is entirely a customized NLP stack that we've built. It's got an ontology that looks up things like lunch and kind of enriches it. And then we've got a semantic chunker which really uses meaning to kind of group to group words together. Then we do entity detection. So this is the Holland Village example. And then we build kind of a graph of the sentence and not only of the sentence but across multiple sentences, right? So if you think about it, we're reading entire email. We're looking at sentence one, sentence two, sentence three, and we're kind of constructing information and actions and data from these series of sentences, right? And so that's the graph building and then the information synthesis piece of it. I have to compete with that. Then we route. So I'm going to try. We route which means looking up the context that I talked about. So putting the message that came into the right context, right? What task is it talking about, what was proposed, where's the meeting, et cetera. We bring that context in and then we enrich it. That's the last box. Then we end up with the structured language representation that's really the machine readable understanding of what this message means, right? And that's really the natural language pipeline that we built to handle this. And that's just understanding language, right? Then there's a whole bunch of other stuff. I talked a little bit about the scheduling algorithms and how it needs to take into account a whole bunch of different things. For example, in a very naive scenario, machines don't understand human notions of time, right? So you say, hey, let's meet next week. Well, what's next week? Well, is that midnight on Monday, the first day of the week? Not really, right? And there's whole kinds of various factors you consider, time zones. How do you do that in a scalable way? And I think route was really great in helping us kind of experiment with different architectures for doing this. Location modeling. We talked about that when we talked about language as well. Aside from the language, you also need to have a way to represent this in terms of database structures and looking up stuff in a tiered and hierarchical manner. Dynamic workflows, so lunch, coffee, meeting, all that, then natural language generation, right? So each of these are like boxes and that are handled by one of these, right? So the natural language piece is really this box over there, right? So that's condensed in here. So this is kind of a broader view of the entire system. We start with the IO layer on the left. So you notice that in the current iteration, current version of the product, we take email input, but really the application has been designed to take any kind of textual input, right? So you could take text from instant messages, Slack, etc. So there's a generalized, virtualized kind of IO layer that we've abstracted away, goes into the natural language engine, the routing engine, and then it goes into the task manager that obviously kind of just looks at which tasks it's in, what state it's in, what workflows we are, location, location classification understanding. So that would involve, again, taking HB and translating it into something meaningful. You have a meeting room in your office named Hong Kong. Well, that's something that we're responsible of. The locust component is responsible for transforming into, you know, your kind of establishing probabilities, right? Is this Hong Kong meeting room or is this Hong Kong the country, right? That's your self-scheduler. P39 is our personalization engine. So no meetings on Mondays or I'm okay to travel on Tuesdays, but on Fridays, I want meetings in my office. So there are lots of rich personalization that it turns out users want for AR scheduling assistance to the useful. And we couple that with world models, right? And world models is really what we're saying is something like, if I'm scheduling a meeting and I say, hey, I'm talking to someone else or two events, I mean, Hong Kong next week, right? The next meeting I schedule, EV should really know that I'm in Hong Kong next week because I've told her in a different task, right? In a different email. So you always have to establish this memory and this kind of model of the world where people are and when they are in different places. And it's really a very dynamic environment that we keep track of, right? The sync engine is maintaining synchronization with the user's calendars, right? And this again was where Rugo is really useful because it turns out that synchronization is actually a fairly common operation in a lot of things that at least we do. So we were able to kind of extract the whole synchronization logic out as a module and literally just throw that into any class that needed the standard kind of like what's been added, what's been deleted, what's been changed and kind of like the automated pride infrastructure, right? So all this is kind of the brain that makes decisions and then at the end of making decisions, if you need to send an email out that goes into the national language generation engine, we haven't talked much about it, but it's also kind of that's worthy of another kind of deep dive at some point. And then flex message is really our abstraction layer because again we need to be able to say that I didn't want to rewrite, we didn't want to rewrite the code or rewrite the logic if we're talking to someone on SMS or short message just like chatbots or Slack versus a full email, right? So you want to be able to say the same things, but the way you would say it will be increasing will be pretty different depending on the channel you're talking to, right? So basically we've abstracted the way that in the messaging layer and then that just goes to the generalized IOL layer. And so that's really kind of the end-to-end architecture. We're obviously hiring as well, we just raised the seat round a few months ago and we're looking for software engineers, NLP researchers and of course anyone interested in machine learning. So that's it, so questions. Thank you. Yeah, so a lot of the feedback, so there's actually a supervisory loop, right? So it turns out that people don't like it when assistants get things wrong, so you can't actually afford to have it go out and do something wrong, you have to catch it beforehand. So until she's good enough, there's still people in the loop who kind of verify that things look good. There's also one of the things we're looking at is actually in the process of building. It's kind of a separate God, kind of like the way the Apollo computers, right? You'd have like two computers compute the same thing and if the numbers agree then it's good. But if you have, in our case, we're using two different methods and if they come with the same thing then it's all good. If they're different then it's like, hey, okay, maybe someone should look at this, right? Okay, I'll stop. Can you do it that precisely? Sure. So the IO there, that generates the hash from the app? Not really. I mean, the IO there is just responsible for taking input from email versus slag purchase, yeah. So you're saying that it generates the hash that you can then work with? That's more the conceptual language understanding. So it's from the what part is it, does that part of it all always need to build emails? For example, you said lunch, right? Yeah. What distinguishes between at lunch and for? Because at lunch could be a skyfall during the region and for lunch could be a street. Is there a rule set or is there like a training nurse? How do you classify those different ways of doing things? And if you file an edge case, how do you add them there? So a lot of it is, so that's actually the slide you really want is here. Which is really the expansion of the clues, right? And that typically happens during this process, like in middle of the oncology and the semantic jumping. And really you have what we're using is, you're using the attributes of these words, right? To kind of figure out what the right thing is to do. So typically what happens is lunch is the subject, right? It's got two properties, right? It's actually, you model both the fact that it's an event, but you also model the fact that it has time properties, right? And then the preposition tells you what to do with it, right? But a lot of times you don't actually need to be that fine grade because generally intent is clear, right? So we're trying to avoid being too picky about grammar because the moment you start doing things on the mobile, grammar goes to hell anyway, right? So what we try to do is kind of pick out the sense of the message and figure out from there. If I had e-mail and you had e-mail, would they just get a good thing? So technically it's possible. It turns out that sometimes people don't like that, especially if we haven't met before. So typically within a team or within a domain, then it's usually acceptable to do that. But usually it's like, say I want to meet you and I copy you, but you will usually wait for you to come back and say something to say, okay, yeah, let's do this, right? Or if you don't reply, then you will ask you, hey, do you want me to go ahead and confirm this meeting with you? So a lot of this is human factor engineering, in that sense. Really? No, right now we're using mailback. To receive, you know? Yeah, they've got an API, they give you a, you get, actually it's not even that, it's just a web call. And they handle parsing, so they do some level of parsing for you. So would they tell you what is their client or what is the injection? Yeah, so, you know, and we skip over this. I mean, an email really has a whole bunch of things, right? It's got the quarter part and it's got the main part. They do, I think when we started out, we used the off-the-shelf algorithm, and then we built a customized version on top of that, and then after that it detects signatures as well. So, and that's, you know, then you do the interesting stuff with who's in two fields, in a CC field, and solve data and context that you use to decide how to respond, right? Okay, sorry, well, which one? This one? Sorry, I'm having trouble hearing you. Okay, so my question is, how do you still communicate with the NLM-based systems? Yeah, when one system learns to love big enemies of math and information, you don't have a language. Yeah, I mean, ideally, ideally, right, you can think of it as a translation task, right? You take national language, translate input, human language, translated into machine language, and then when you're ready, you output machine language, and you translate that into human language. We're not quite there yet. But yeah, that's definitely kind of a long-term area we'd like to kind of work on, and figure out how to really kind of unify those two, because you're right. I mean, they are two sides at the same point, yeah, yep. One question I guess I have, how do you deal with the noise-signal-to-noise ratio? Because you know, obviously, people spend a lot of their life, wow, and there's gonna be a high rate of noise signal when you only care about a very small portion. That seems relevant. Yeah, so that actually is kind of part of the challenge, right? Because a lot of times, we're not the only recipient in the email. I think what you're talking about is like, you know, someone's talking to the other person, and then at the end, there's a sentence that says, E.B., do this, right? But it turns out you have to pay attention to all the other stuff, because it has a bunch of contextual clues that tell you what you need to do at the end, because people aren't, they aren't gonna repeat what they said earlier in the message, right? So they'll be having a conversation about, hey, we should meet here, and we can do this, and talk about that, and then E.B. set this up, right? So you really have to read the entire message, and you know, some of it's just, okay, maybe you've discussed stuff that's in the past tense, right? For now, at some point, we'll do something interesting with the data, of course. But in the short term, maybe that's not meaningful. You're looking for future-looking events, for example. There's one way you can do it. You could look at who it's addressed to. So part of that is the information synthesis and the graph building, right? So figure out, like, there's a bit of diode modeling happening as well, right, in a very primitive sense, yeah. So those are some ways we can deal with it. Does E.B. have a custom email address per person, or does 3 to it is based on the 2? Does E.B. have a custom email address? So it generally is a shared, like, everyone can just email E.B. at Mimetic, and we know who we're talking to based on who sent the email. So if I mask my email address, I can fuck it up? If you mask your email address, it doesn't recognize who you are, so it's not going to take instructions from you. But if I mask my email address to someone else that was a customer? Oh, yeah, sure, yeah. That would potentially be a risk factor, right? I'm sorry, I didn't say that. No, but it's a great point, right? And it hasn't been much of an issue yet. I'm sure at some point we'll start checking DKM and SPF and making sure that the people who sent the email are verified, right? Why is she a female? You know, I didn't want E.B. to be a female name, but it's about as gender neutral as you come up with, and yet still be too syllable and could search on the App Store for it, because at one point we had an app. But yeah, at some point it's going to be just something you can, if you pay enough, you can name your own assistant. I'm open to suggestions, guys and girls. All right, if anyone has any more questions, can I look for Jin after the meetup? Cool. Again, I guess they could email you if they want to. Yeah, absolutely. All right, thanks guys. Okay.