Unraveling the World of AI-Native Application Development with Mehmet Ozan Kabak Ph.D (CEO at Synnada, fmr ML at Instagram)

Mehmet Ozan Kabak, Ph.D. joins us to introduce the idea of AI-native application development. Ozan applies his real world experience working on machine learning at Instagram Signals and various other roles in AI & ML.  Embark on a transformative journey into the heart of AI infrastructure with Ozan Kabak, a beacon of knowledge in the realms of AI and machine learning. Our enlightening dialogue traverses the landscape of 'AI native' applications, where Ozan's insights bridge the gap between academic theory and industry practice. Through anecdotes from his Stanford days to tales of data infrastructure dilemmas, Ozan demystifies the often-overlooked development hurdles such as model monitoring and the balance between training and inference. This episode promises to illuminate the intricate dance behind the scenes of deploying AI solutions, sparing not a detail on the developer's labor and the pivotal moments that shape the backbone of AI applications.

Gain an edge as we unpack the strategic foresight necessary for wielding AI in business; a cautious approach underscored by the significance of a robust data framework and the lurking risks of customer-facing AI systems. Ozan's expertise shines as we introduce Apache Arrow, the open-source project championing data format interoperability, heralding a new era of standardization and best practices. Be prepared to peer into the crystal ball of AI's future with us, where efficiency reigns supreme, and the compute landscape is primed for an overhaul. We grapple with the immense potential and existential considerations of large language models, examining how today's marvels could become tomorrow's masters. Tune in for a session packed with insights that will redefine your perspective on AI's current and future roles.

What's New In Data is a data thought leadership series hosted by John Kutay who leads data and products at Striim. What's New In Data hosts industry practitioners to discuss latest trends, common patterns for real world data patterns, and analytics success stories.

Transcript

0:17

Hello everyone. Thank you for tuning into today's episode of what's new in data. We have an awesome guest today. Great technical and real world industrial background in AI and machine learning. We have Ozan Kabak. Ozan, how are you doing today? Good, good, John. How are you doing? Great, great. Yeah, happy we're finally able to do this episode. We've been talking about it for a while. I ran into you at Data Council in Austin earlier this year, where we originally had the idea to catch up on a pod episode. So good that we're here now. Yeah. Yeah. Super happy to do this. And, yeah, we have been planning about, you know a discussion on all the cool developments in our space, but never got the chance. So finally we can do this. Exactly. Definitely in that timeframe a lot has changed as well. So in, in the landscape of data and AI. So definitely very timely that we're able to have this conversation now before we get into those topics, tell the listeners a bit about yourself. Sure. I think I can say that I'm a computer nerd from you know, a very young age. I kind of started, , like hacking my way with QBasic when, you know, we had MS DOS stuff. And, you know, anything about computers, systems, programming, all of these things, it's a passion In terms of my career, I did my master's and PhD at Stanford. And during my time at Stanford, I got introduced to the notion of dynamical systems, time series data. How do we observe dynamical systems? How do we apply? Algorithms on these systems like A. I. And other like, you know, data processing algorithms and all of that. So that's how I kind of got into this world of data and AI. And actually, my first job out of graduate school, was at Striim where you and I work together and that's how we know each other. And that was my I guess foray into like the data infra world, right? And I really liked it because I, I was coming from this like academic and like algorithm. Focused world view, right? And then at Striim, I had the chance to really apply all of that in a more like, How do we deploy this kind of perspective? So that really enriched my view of how to create systems. And ever since then, I've been working on, you know, data systems, applying AI on data streams trying to create more and more efficient data infrastructures. Thinking about algorithms in this space. So that's basically who I am. I am a data and AI practitioner who came in from a from the academic side of the world, and I've been in the practical side of the world for the last 10 years. Yeah, and like you mentioned, you you worked at Striim. We were colleagues and, you know, I was always very impressed from the time you arrived at Striim, you were a PhD in electrical engineering from Stanford, but just how quickly we were able to dive into some real world industry problems and. Since then you worked at you know, various companies, including you know, Facebook, where you worked on Instagram signals, and now you're the founder of your own company, which is awesome you know, love seeing, you know people I've been connected with for a long time and go into entrepreneurship, but some really exciting stuff that, that you've been working on and especially exciting with the growth and demand for AI and machine learning as commercialize products that teams can, leverage for their own use cases. So given, you know, all that's going on in the industry, where do you think we are now? Like the current state of developer technology for AI? Yeah. You know I think a good introduction into this whole, you know, where are we kind of analysis is probably through what people are talking about, and one of the buzzwords that you are probably hearing all the time is like AI native, right? AI native X, AI native Y, AI native applications. What, and what does it really mean? Like, okay, it's a buzzword, but like everybody is probably having different things in their mind when they say AI native. Obviously, there is no consensus around this, but I think we are right now getting into a point where at least in certain contexts people have agreed on understanding of this in in our space in data infrastructure, I kind of think I liken the buzzword to cloud native, right? And what I like about this analogy is when we are developing any software service, we obviously think about the business logic of the service, right? But then we also think about a lot of externalities, like where is this thing going to get deployed? How is it going to scale? Do I need to wrap it inside some auto scale mechanism? How do I do load balancing stuff, right? Like, because if it's scaling and there are multiple replicas, how do they share the load? And then, like, how do I cache, like, what role does caching play in this? How do I collect metrics from this? So these are things that we think about and has nothing to do with the business logic of the service, right? The actual code that you write. But I would find like 60, 70 percent of my time would go into these things, right? And now we have cloud native and if you actually conform to a manifest, right? And if you containerize your business logic, all of these things come very cheap. They're abstracted away from you. I think AI is going through, such a period. Right now, we are thinking about a lot of things when you're developing an AI application. We are thinking about training versus inference. Like, where does inference take place? Do I need a separate infrastructure for inference? Where does training take place? How often do I need to, you know, retrain or fine tune this thing? How do I know when I need to retrain or fine tune this thing? How do I observe my models? So all of these things again, like they're, they cut across all kinds of different applications, right? I haven't discussed any business logic at all yet. Probably like more than 50, 60 percent of our time goes into these things and they're still very fragile. Like we spent a lot of time on these things, but they're still very fragile., I think when we arrive at the AI native infrastructure, just like what Kubernetes did in cloud native, we will not need to obsess about these things anymore. Like most of these things will be abstracted away and there will be contracts. And if we actually abide by those contracts, you know, all of these things will come for like free. And that's actually what we happen to be building at Synada. Like, it's obviously like a very large mission and it's not like one startup is going to solve it all kind of mission. But I think I'd like to think that we will contribute to this general trend towards the AI native data infrastructure. So it was a long answer to your short question, but in summary. I think building AI applications today is, is hard. You need to duct tape a lot of things together. You need to maintain a lot of different data infrastructures to support your application. You need, you need to think about dichotomies like batch and streaming. You need to think about observability. You think about retrains or fine tunes, you need to think about triggers. You need to think about internal dashboards to monitor these things. So, today we are super excited and we go through all of these complications, but as the technology matures, people, I think will want more unified infrastructure for these things. Yeah. And one of the things that you mentioned to me was, you know, the bifurcation between AI infrastructure and traditional data infrastructure, whether it's, you know, in the cloud or, or in on premise environments. So where do you see teams adopting AI infrastructure? Do you see mostly fully managed services or? Or deploying on their own cloud, bare model bare metal, but more GPU based systems that could be, you know, obviously higher costs and, and a little more scarce. Yeah, well, I think there's going to be a transition. I think people are going to get started with all these like AI clouds, right. And make API calls for everything. Cause that's what you need to do if you want to get going quickly today, right? But I think over time people will actually want to have more control about these things and So there's going to be a migration from Let these xyz companies let OpenAi let Hugging Face to all of these and I'm going to make an api call so people will do that for a while, but eventually I think people will have their own compute. This bifurcation thing is actually quite interesting. Think about traditional data processing systems, like Spark or Flink, you know, things like that. Or, you know, what we worked on together at Striim. They are all like these CPU based compute technologies, right? Like at the end of the day, okay, they're distributed and, you know, they're, they have fault tolerance. So they have all these like fine features, but the types of computations they are doing is like, let's group by stuff together and, you know, let's order things and window things. So this is what I call like the traditional CPU based compute. So this comes all the way from database systems, right? And then now for AI, we have this GPU based compute, which, which has nothing to do with this. It's just about arrays and tensors and linear algebra operations on these things. And the hardware is also very different. Like what is a GPU? It's like, it's like a huge collection of processors that are very good at doing these kinds of linear algebra stuff and nothing else. So the traditional compute engines that we worked on over the last 40, 50 years as like engineers doesn't really do this stuff well. We have hardware that do tensor manipulation very well, but we don't have engines in the sense that they do both this kind of tensor stuff and traditional stuff, and I don't need to think about which engine I'm going to use for what. So we don't have one compute, like if, if I'm going to do traditional compute, I have spark or fling. If I have tensor stuff, I use some sort of distributed, you know, Ray like thing and then it runs something like torch underneath So these are very disparate worlds and they needed to be like because they were different things before But at the end of today, they are all transformations So I think at some point we are going to have compute abstractions where I will not need to do things at separate places. I think there's going to be a lot of interesting tech in that space too, like in this unified compute space. Absolutely. And when you say transformations, you're really getting at, going from raw, maybe unstructured or just data, that's that's not useful in its current format to making it something that's ready for the business, whether that's an ML generated alert or a report that summarizes data or, you know, something that's interactive, like an AI application where you can do some natural language chat type experiences with the data itself and get some insights. And that's really a problem that, you know, companies have been solving for decades now, but the technology and the art of the possible has just really accelerated in the last obviously over the last 10 years with, cloud infrastructure, but now over the last one year with the AI. It's, it's become a much faster pace of innovation going on. And I think teams are kind of struggling to see, you know, what's the best way to adopt it because it's changing every month. And like you said... Yeah, it's very hard to keep up, man. Like two months ago, if you wanted to generate some kind of like a image from some text or like, you know, some start from like a template image and then make AI fill in the gaps that would take a lot of inference time. Now there are startups who can give you this real time image generation experience. So they actually, one of those startups, the founders are our friends, Fall.Ai, if anybody's interested in the audience, go check them out. They're a very cool company. But the thing is like two months ago, nobody was like, people were imagining it, but it didn't exist right? Now you can actually make you know, open like some sort of channel and then you can stream AI generated images with 30 frames per second. So the, the pace is very fast. Yes. Yeah, absolutely. And the pace of innovation is very fast. And then of course the demands from the business are also accelerating in terms of, you know, knowing that AI is available and being able to actually see AI in their business facing operations, whether that's, customer facing experiences where people want, to give AI chatbots to their end users or internal operations where, AI is making, smart decisions from your data automatically. Of course, there's risks there too. I mean, there's already a lot of examples on Twitter of, you know, companies rolling out chatbots and they're just terrible experiences. Like, you know, if you give it the wrong question, it'll completely give you some bogus answer, which is kind of looks negatively on the brand. I mean, people end up making fun of the actual brain brand as a result of that. So, you know, what's your advice to, you know, data teams and engineering teams that are embarking on the journey of deploying an AI application for the first time? Cause there's so many of them now. Yeah. Well, definitely I would advise don't go too fast when you're trying to go too fast because what you said will happen, right? Especially today I see a lot of AI based customer support kind of deployments with the RAG and all of that, right? So these in theory sound very good and they are good, but if you do not back it with a good data infrastructure, which allows you to fix problems very quickly, you know, fine tune your model as soon as you discover those problems. What I mean is like having a data infrastructure that supports human in the loop, right? If you don't have this kind of a infrastructure that backs these AI applications, you're taking a risk. There are some contexts where like you can take this risk. It's okay. You know, the world will not fall apart if you have a problem. But sometimes, especially like if you're doing customer support and something funny happens that people are going to share it on Twitter and then, you know, the brand will suffer and all of that. So like you need to, you know, you need to be sufficiently careful when you're doing these things. And you need to have a good infrastructure to support these things because you're going to iterate a lot. At the current state of technology, AI driven data applications need a lot of iterations. And you will need to do a lot of those iterations when the thing is live, that's something you have to prepare for. Yeah. Almost sounds like the AI operations will need their own production engineering team to make sure that there's constantly fine tuning going on and monitoring this system. My perspective on rolling out AI. If you're, your company is, is new to rolling out AI based applications is start with your public facing data for an internal audience, right? Understand all the, you know, the caveats of deploying an AI system, but very minimal risk because if the system, let's say it leaks data, it's already public and your end users are all internal. So that's okay. And then really just take more risk over time. And it might be a one to two year cycle where you incrementally add more risk and eventually make it public facing experiences on customers private data. Let's say, I work with a bank and a bank gives me a chat application that's telling me about my account. That's actually a lot of risk to deploy something like that, because now your AI, your vector databases are indexing and generating embeddings from private customer data and building experiences for that. That's something where, you know, hallucinations can be catastrophic, right? So I do think that teams just have to, you know, phase out how much risk they take and start small, start with the least risky project where, the worst case scenario is someone internal raises their hand and said, Hey, this looks wrong and you have a human in the loop that's monitoring everything. There's already lawsuits coming up over, AI driven experiences. So, the technology is amazing and moving very fast, but, like you said, you definitely don't want to move too fast. Yeah, definitely. A lot of, a lot of companies are like deploying these things in, in this kind of support context because all of their support documentation is already public, right? So they actually kind of follow your advice, where I think they get too excited about is like having these support train, support document train LLMs interact with the customer directly. That's probably where they go. Too fast. I agree with you. I would first really like roll it out in, in, into an internal audience and then graduate it to the general public over time. That's what I would do. Absolutely, it seems though like the best way to, to sort of get your groundings in, in AI as a business 'cause the technical parts there and people are gonna arrive at similar conclusions over time, but ultimately you want to phase it where your organization is not burned by AI in the process. Cause it is great technology and you want to make sure that you're always building positive momentum there. So there's another very exciting project that you're very closely tied to in the open source community called Apache Arrow. Can you talk to us about that? Yeah. Arrow is a very interesting project. It has two origins, the first origin is, let's just roll back time five years ago and think about all the different data formats and file formats and, you know conversions between formats and we would have like at the start of this whole modern data stack movement, what did we have and how did it progress, right? If you think about all that journey, there was like this huge interoperability problem. Right. Like a new tool is coming out every day and everybody's storing data in a different way. And unfortunately it's very hard to build an end to end data application with a single tool, which means you will need these things to integrate to each other. And then the question is like, do I need to convert and deconvert between all of these different formats? So we had that interoperability problem, and Arrow kind of came out as a solution for this problem. Let's gather all the best practices from how to store data in memory, how to ultimately convert it to files, which in this case is Parquet, right? And if we can actually gather all these, like, best practices then everybody can just focus on the actual like processing that they're doing on the data and just agree on arrow once and for all. So that's obviously a good idea, like any kind of standardization idea. But then arrow also has origins in this whole column storage, column processing way. So this, has been going on for a long time now. Probably had the most moment in the last two decades, right? And Arrow kind of integrates a lot of good ideas from that space of ideas as well. So the ultimate trend result is, okay, we have this in memory layout which is a columnar layout and it takes all the best practices and it plays very well with storage formats like parquet. And, , now you can take in any kind of like C++ implementation, Rust implementation, whatever implementation that you need for your own data project. And obviously, once you have that as a next step, people started to create projects on top of Arrow, and one of the projects that I'm super excited about is called DataFusion. Arrow DataFusion basically is a query engine at the end of the day. So, you know, the audience of this podcast knows probably very well what query engines are. But what's new about Data Fusion is that it's a deconstructed query engine. So typically what we want from query engines is like high performance, right? And we want them to be able to run as many different types of SQL queries as they can in the fastest way possible. And to achieve that, programmers and engineers who build query engines typically come up with very tightly integrated designs. Right? So the, you know, very efficient code and, , it runs very fast, you know, very high throughput, whatever. If it is a streaming engine, maybe a very low latency, depends on, you know, what you're building for. But to achieve all of that, you end up with something that's very hard to extend. So you typically use it as is, and if it doesn't do the job for your use case, you search for some other engine. So data fusion is kind of like an antithesis against this. So it is trying to do what LLVM has done in the programming language space. And this analogy between Data Fusion and LLVM is due to Andrew Lam, who was Arrow's PMC chair last year, and this year he's still super active. And I collaborate with him daily. Great guy. Anyway, so what Andrew says is, if we can deconstruct the experience of building data systems, And if, as a, you know, , engineer, if I can isolate myself from, oh, if I need to support SQL, how do I parse it? How do I create a logical plan out of it? How do I insert my own logical plan stuff in this engine? How do I optimize this kind of plan? What happens if I need this specific optimization for my use case? How does this thing get translated into a physical plan? Again, how do I do optimizers? Blah, blah, blah. So these, all of these things were very tightly integrated before, but the deconstructed data system idea is that if I actually have different components for each of these steps, And each of these components are modular and changeable, extensible, right? Then I can create families of query engines from a template. You know, I have my DSL, I optimize for this whatever X kind of data, I have special operators, you know to do very efficient whatever operations on this data. Now I don't need to replicate 80 percent of, You know, the stuff that I'm not changing and I can only focus on the 20 percent of the stuff that I'm changing. So this is very similar to how LLVM transformed the programming language space, right? Yeah. And just for the listeners, LLVM is a language compilation framework. You may have a better definition. No, I think that's what it does. It helps you essentially build programming languages and handles a compilation and the Lexar parser, etc. And you're saying that, Arrow essentially gives you a query engine creation framework, correct? Yeah. Yeah. So Arrow is the base layer, like data format and Data Fusion gives you this query engine creation framework. So I, I really like this analogy because if you think about, you know, IDEs and programming languages before LLVM, like we had Eclipse and that's it, right? Like an IntelliJ. Okay. And now, we have like this VS Code and LSPs and all kinds of plugins and everybody's creating their own language. It is so easy, right? Because now, what used to be a gargantuan task of creating like these compilers and all of that, now it's not that hard. You just change what you want to change and that's it. So DataFusion is trying to do the same for the experience of building databases and compute engines and all of that, right? So I'm very excited because I think if this trend really takes on, people will be able to make a lot of like custom made systems with very little effort and optimize for their use case. And roll out, you know, these kinds of technologies very easily, like imagining this VS code, like, you know, proliferation of all different engines kind of thing in our space is very exciting to me. The natural question is why, for example, my company Sonara is betting on this, right? Like, okay, this sounds good. Why? Well, if you go back to the AI native data infrastructure, how do you make that real? We have specific ideas on how to unify batch and streaming. We have ideas of how to integrate AI models into compute pipelines. So either I need to reinvent everything that Spark does today, right? Which I cannot do with, you know, a small amount of money, right? Or I need like an extensible query engine creation tool, like Data Fusion, so that I can do this. So that's why like I'm personally very excited about Data Fusion. I think it's going to create opportunities for a lot of data entrepreneurs to create all kinds of different technologies. Yeah. And It's, it's powerful technology. And I think the, the great thing with Arrow and Data Fusion it is making it more accessible for more innovation to happen in the market because, you know, traditionally , query engines were proprietary, kind of black boxes where it was commercialized and expensive. You had to buy a database. You didn't really know anything about the underlying query engine. Then you had, open source databases come out where, you can build on top of the database. Now you have like a framework to build your own, domain specific query engine OLTP, OLAP, you know, whatever you want to call it using open storage, which is another innovation in its own category. Right. The fact that you can, you have this cheap on cloud native, you can store data either locally on on files. Sorry, I use the buzz word cloud native, but it's actually not cloud native, but works very well with the cloud storing in S3 buckets or, GCS buckets. And things like parquet and you can essentially build your own columnar storage format for super fast OLAP queries. So, you know, there's, there's a lot of room for additional, you know, innovation that's going to happen over the next five to 10 years with like I said, sort of these domain specific, , data processing engines. And you're applying this at, at Sonata essentially and you're also a big contributor to the community. So you're also helping others innovate along the way and build their own domain problem solving specific data processing products that will be, you know, kind of commercialized for very specific use cases. So it's super exciting. I remember when you were at Striim, the big things back then were Apache Storm and, you know, Flink was very much in its infancy. We were aware of Flink, but at the time Flink, didn't quite have, the stream processing features that Striim had. But now Flink is obviously grown over the years and gotten a lot of adoption and Hadoop was very popular. But now it seems like now, instead of, being handed this kind of open source data processing engine, you have the framework to build your own, which is awesome. Yeah, you know, just the other day I saw a project., using data fusion to build a bioinformatics specialized query engine. Like, how cool is that, right? Like, it's not a we're doing this AI native data infrastructure and the same base layer technology. It is so modular and extensible somebody else is using it for bioinformatics. So that's the kind of future that I see, like people will not need to reinvent the wheel in terms of these like compute engines anymore. Yeah. It is very powerful. I think it's also going to be great for, both commercial and academic and research purposes. You made the, comparison to LLVM and LLVM was obviously very popular and in programming languages courses, it came up in mind when I was a student and I think it's great to see this now being offered to people who want to build data processing products. Definitely excited to see how Sonata is able to apply this and roll it out into your own products and we'll all be very excited for those announcements, but I also want to get your take on, you know, your vision for the future of AI. Yeah. Sure. Well, this is, this is a thorny topic, right? Because there's this huge debate between AI is going to kill us all versus, you know, no, AI is not gonna kill us all camps, right? So let's get that out of the way first. I think AI will not kill us all. I agree with basically what Ian LeCun says all the time. All the developments are very cool. It's going to impact economics, you know, it's really going to have a huge impact on the world, but I don't think Skynet is coming soon. I'm not saying it will never happen. Okay. I mean, like, because the pace of progress is very fast, but we do not need to lose sleep over it just yet. That's what I, I'm going to say. So with this out of the way, , let me discuss more practical aspects of what the future holds. I think if you're following the miniaturization efforts in the open source to get smaller and smaller, you know, models that have similar generative capabilities. I'm a huge fan of this who isn't? But I think that's really going to keep going, and I think that will unlock a lot of the use cases. I think in a few years, we'll go through maybe a few algorithmic innovations, you know, innovations on how we train models, innovations on topologies, innovations on distilling the models that we already have. So all of those, I think will synergistically result in much smaller models. And we will be able to deploy these to edge systems, like phones and this and that. And I think that will unlock a lot of, a lot of use cases. And we have, we are seeing this already in computer vision. Like if you look at the recent LCM stuff, right? That's how people can do this real- time image generation now, because you can do inference under like 100 milliseconds now so that's going to keep, you know, keep going. I think we started off with very large models because we somehow figured out how to train very large models. I don't think we need that many parameters. I don't want to say I have a firm belief, but if I have to take a position, make a bet on whether we actually need like this many billions of parameters, I would say no. I think we'll eventually figure out how to do these things with fewer parameters, not like 10, 000 parameters, that's not what I mean, but we don't need that many parameters. So I think those, those efforts will keep, you know, bearing fruit and you're going to unlock a lot of new use cases. We have some work in Sonara towards this as well. I don't want to discuss this out like very publicly, but this is a personal interest area of mine as well. So I would say anybody interested in how the space is going to evolve to follow, you know, what the model sizes are doing. I think that that gives you a lot of cues. And then the second thing is, maybe this is a little counter position to the typical Silicon Valley think right now, but this whole GPU rich GPU poor stuff that may not last for very long. I think as these models get smaller, and if we make a few algorithmic innovations on the way we will not need this many, this big of a compute power. I mean, we will still need the big compute power, but not as much as today, I think. And I kind of liken this to Cisco before and after the dot com bubble, right? Everything was about stronger routers and, you know, like network equipment and this and that. And then it turns turned out the value was not really there after the dot com bubble and Cisco, it's still a fantastic company, obviously, but like it never had the same standing in the market anymore. So now, okay. People think about like all these GPUs and GPU makers and all of that. And I think that's going to keep going for a while because we don't know how to do otherwise today in terms of creating good models, but I think at some point this is going to pass. GPUs are always going to be very important because at the end of the day, this is just linear algebra, all AI is linear algebra, but it is not going to be as much of a bottleneck as it is today. So that's, that's, I know this is a little counter position to what people are talking about these days, but well, we come out to podcast to, you know, say somewhat somewhat controversial things, don't we? Absolutely. And, it's definitely a great perspective that, you know miniature models are growing in their applications, I'm very excited by the work one company is doing called Hyper B. They have some great performance on a Hugging Face and you'll see you know, other examples in the, in the market as, more demand comes up for, for miniature sort of portable models can run on, you know, more commodity compute that's lower costs and sort of purpose built for specific use cases. Just to entertain your, your other point that you kind of glossed over, which is, you know, will AI kill us? Just to humor me, what's the argument there that, you know, AI is actually a threat to us. If anybody is curious about this, maybe a good person to take a look at is Eliezer Yudkowsky , right? Like, he has been talking about these things in the less room community for a very long time., and he has a lot of articles about, why he thinks this is a possibility. And if you, if you actually remember, like, when there was a call for moratorium on, on AI development, right? I think a lot of that kind of came out from the intellectual work of the less wrong people and Eliezer Yudkowsky. So I would advise the, you know, anybody curious about this to take a look at that. I think Elon Musk mostly, my understanding of what he says is like, he also thinks that this is a possibility., I'm not sure if just scaling the models that we have today is gonna give us that. But I think what, what their argument is, this whole notion of emergent capabilities. Right, like you think about an LLM, an LLM is not trained specifically to be great at let's say, translating from language, between languages, right? They don't do it but it turns out if you have a very large data set, and if your model has large enough capacity just by training it on this, you know, predict the next token kind of thing, actually gives rise to this emerging capability of translation. Right. And right now, I think we have some ideas about what kinds of capabilities are emergent versus what kinds of capabilities you need to specifically train for. For example, it seems like arithmetic is not emerging from predicting the next talk. So. We know that certain things are, like, more on the emergent side and certain things are, oh no, you have to actually teach the models these things. Or, like, we haven't found a simpler rule out of which these things emerge. Class, I would say, maybe. Yeah. But I think what scares people is this whole notion of emergent capability, right? Like, if, if now we discovered a certain simple rule by which if we train models other things Maybe in the future, things that we don't expect are going to emerge, right? I think that's the one of not, I wouldn't say that's like the key idea of like AI may kill us all thing, but I would say that's one of the factors why people think it could be dangerous. Things can emerge out of this that we have, we didn't expect. Right, because it has happened before, like this example just I gave, right, like, so this thing called emergent capability exists, and they are, I think, afraid that reasoning may be an emergent capability too. Yeah, it's, it's fun to talk about for, you know, science fiction at, at this point, you know. Agree. I agree, but I, I don't want to, I don't want to be like overly confident about anything. Because in this space, things are moving so fast. Yeah. Yeah. And I think there's the other scary one, which, you know, at the same time fun to talk about is, you know, the idea of like collective intelligence where, multiple agents can start collaborating and they can communicate over networks and plan things together and distribute tasks and all that sort of stuff. But yes, I think that's sort of futuristic, sort of sci fi, there was a fun book on that topic from a Nick Bostrom as well, Superintelligence, which I think Elon Musk was tweet was actually the one where I came across that book. It was entertaining actually, not that I believe in that viewpoint that AI is going to kill us, especially seeing the current state of AI, but like you said, it's moving so fast. You don't want to make any declarations of how the future will, will actually play out. Well, Ozan Kabak CEO and founder at Sonata, you know, and you've done a lot of great work in a machine learning and AI over the years. So great to have you on this episode of What's New in Data. And thank you to all the listeners who tuned in. Ozan, where can people follow along with your work? Yuh, well to two places, definitely go visit the Data Fusion GitHub it's very active and we would appreciate more stars and more people checking it out. Obviously it is a very fast pace, a lot of comments are coming in. And play with it, give us feedback, we want to make it better all the time. Use it, we will be very happy. So that's, that's venue number one. And if you're curious about, like, what we mean by AI native data infrastructure, unification of batch and streaming, and seamless, you know integration of AI into compute. What's going to replace Spark? Like, what's the next generation Spark? If you're curious about these things, check out Sonara.ai and if you have any questions about what we do and what our ideas are on, like, what's going to replace Spark just shoot us an email. Join the data fusion discord. We are super excited about all these technologies. And I will be happy to be in touch with any practitioner who wants to discuss these things. Thanks so much, Ozan. And thank you to everyone who tuned in today. Thank you.