So NOI was founded, well, many years ago now, back in 2014. The common thread of problems was that, hey, there was lots of data all over the place. The first thing was, how do I get a unified view into multiple different data sources?
I used to run product engineering at a company called DemandForce back then, and we had data in 19 different silos, right? So, we needed to bring embedded analytics products for our customers. The question was, do we build in-house, or do we buy an existing product? But when you looked at what the market was, okay, the first thing they tell you to do is take all the data, move it into a centralized repository, then do the transformation and your analysis on top of that before you even plug in either an existing analytics tool or roll your own for more fine-grained control and so on, right?
So that meant millions of dollars, 18-month lead time, and all of that. That was many years ago—still the same. Oh yeah, sounds so familiar, right? So, NOI was basically founded on the fundamental premise: this is silly. Is there a better way to do this from the ground up, all the way from where the data is to the business user? And what are all the points in between that we can solve or just have other best-of-breed technologies that can help solve it but can be integrated in a way that feels unified? So that's the genesis of NOI.
So just a back—if you say, if you say "unify your data," what is the difference where you say before we were trying to move it all into a central place, and now you're looking into unifying? Is that more into the virtualization or moving it in a different way or pushing your queries to the data? What approach are you taking with NOI on this?
You know, it's a little bit all of the above, is the best way to say it. So, the first thing we focused on was on the data side of things. You have data in multiple different places. Sometimes it helps to have it where you want to shield your underlying data sources from push-down queries and things like that, and you need it somewhere. That somewhere could be your Snowflakes and Redshift, or it could be within NOI.
So, we have an option to basically, what we call at the dataset level, where you can define it: hey, this is a push-down direct query, or this is a query against Snowflake, or we're going to run these queries and put it into NOI or put it into Snowflake, Redshift, etc. And you can control that where you need that.
So, the foundational piece for NOI is this concept of this dataset as a service. In some ways, it's like virtualization, but in some ways, it's not. But virtualization for us is basically, how do you get a unified view into the data, whatever that data might be, right? So, that's our definition, at least.
In some cases, it could be real-time against an inline source. In some cases, it won't make sense to do real-time. So, you know, how do you support those cases? And then the approach we've taken is—this also goes against the traditional ETL processes, which is like, hey, lift and shift the data, move it into your data warehouse, right? And then you have the dbt's of the world or transformation tools in between to do additional transforms, put it back into your database, and so on.
And our approach is, if you do this from where...
The data is and give you the control of in the virtualized layer. Then you don't need to do all of those, you know, heavy-duty lift and shifts and transforms, or do it in a different way. Basically, is this something what the architects define, design the end user, or is there some intelligent mechanism in between as well?
I see the evolution of virtualization layers and where they had troubles in the past where it was not working. But it's like you're building a query, and you need to optimize it, and you need to have the knowledge of memory, of storage, of latency, and optimize that query in a certain way depending on your backend. Is there some intelligence in the NOI platform that helps you in guiding you on how to best set that up for your specific dataset, what you want to have in a performant way, secured, or whatever would be the reason to not move all the data in a central place or other places to query it?
Yeah. Um, short answer is we don't. So the—we leave that. So on the Phil design philosophy side of things, we had, you know, the data engineering piece, and then you have the non-technical business user thing on top of those datasets. You great that we've tried to make it as simple as possible.
The issue on the data engineering side is that you need the—you know, data is complex. You know, as you mentioned, right? You might have terabytes or petabytes of data, and it could be in—elas could be in—and the intricacies of each other's databases can be quite different. So the—so we kind of leave that up to someone who knows what they're doing on that layer to basically put those datasets together.
But once you have that, once you have these business-user-friendly datasets, then those are reusable, right? So the business user doesn't have to go in and f about with the datasets and so on. So that's the approach we've taken. So to answer your question, you know, we don't out of the box give you any, you know, recommendations or anything like that to say, "Hey, you should do direct query on these versus," you know—so but you have all the possibilities to move your data where you want and how to query it. I mean, you can push down, you can move the data, whatever you feel.
Otherwise, you have to choose for a certain architecture where you say, "We take all the data, we standardize it in the data lake, and from the lake it goes on and the data warehouse, data mods," so you have the five or six next levels what you have. But in no way, you can define, depending on the use case of your dataset, on how you will make that and where will you make that data available.
If I understand exactly—and part of, you know, how we—when we architected this, one of the things we wanted to do was like, you know, don't listen to, um, the pundits and like the all the latest because that's stuff is going to change, right? So how do you—you know, so just what's our pain point as a customer? We're on the other side—how do we do this if we were on the other side and that we don't have to end up putting together a bunch of different tools, make it all work, and all of that? You know, so that's basically the, you know, the—yeah, philosophy-wise, how we went about doing it.
Yeah, I'm still curious where—I do understand where you have the possibilities of moving that data, make it in a certain way easily, um, bring it together, or how can we put it in in such a way it will be a combination of—one will be a query, another one will be moving the data and—
Here’s the formatted transcript with punctuation, capitalization, and paragraph breaks:
---
Then bringing that together, if I can imagine—I haven't seen the platform yet—but I'm trying to understand how everything works. Everything, yeah. Let me, you know, let me do this iPad stuff, and then I'll, uh, hopefully this makes a little bit more sense because there's like multiple different pieces to it. And I think, uh, once I go through it, it would make hopefully a little bit more sense.
So let's just put it in a box and go through. So, you know, we've talked about this dataset as a service layer. So let's say you got data in, you know, Elastic, Snowflake, any cloud services or APIs, files, and so on, right? So first thing we do is like, okay, we want to get some data from maybe or join that with some Snowflake data.
So, uh, you can push down these queries real-time, and that's option one. And we call it direct—sorry, my handwriting is terrible; iPad doesn't help. And so that can—that's basically saying, "Hey, I'm going to get these things real-time." Option number two is, "Hey, I've got data from and Snowflake, uh, I'm going to merge them together," um, and have the data stored within NOI.
And NOI comes with what we call an elastic storage mechanism, which is basically like an intermediate storage layer that you can dump the data in. And so that's option number two. And option number three is we call it DB, right? So it's talk to talk to S, like combine the stuff together. It's nice and tidied up and chuck that into, um, your Snowflake or some of the other data sources we support. So that's option number three.
So instead of—so the shift here is sort of moving all the raw data in a raw form into the data warehouse. You basically have an option to choose: "Hey, some of this makes sense to have that in the data on the Snowflake side; some of it doesn't. Some of it you can do push-down queries," and so on. And indirectly, what also—if you have large amounts of data you're putting into Snowflake, for example—right, with this approach, you can basically choose to put what you want in Snowflake and then drastically, you know, pare down the costs as well if you want.
So, uh, sometimes we see savings go up to 50% with this approach on Snowflake cost if you're spending, you know, $100 grand plus, like, so. So that's the dataset concept, and this is automatically API-enabled. There's also a push API—you can push data into NOI too—but I'll skip for now.
But anything you create—the idea is that it's a reusable component that you can take any existing datasets and use that, you know, basically like an object-oriented way in some ways, and use that as an input into the next set of joins or something you want to do if you want. So, you know, it's like create once, reuse multiple times. And once you create it, you're basically validating that this is good to go for all the upstream things you can do with it.
And within this dataset, you know, I mentioned this—you can do multi-source joins, transforms, any step along the way. So, for example, query, do some transformations, query Snowflake, do some transformations, do those in parallel, put the two things together, transform the end result into something, you know, that's meaningful to the business, add new columns, calculations, etc. That can be part of the dataset itself.
Security and governance—so basically, who's allowed to access this? If I have access to this dataset in its entirety, and SR has access just to, like, row-level security for marketing.
Here’s the formatted transcript with punctuation, capitalization, and paragraph breaks:
---
Stuff you can set those up there, um, if you like. Um, and then there's also, like, a, um, you know, because we know the metadata of the results, we basically build a world around it to say, "What are the fields? What are the, um, the field types?" And then that feeds into our NRP engine to create that, uh, um, gen-type world for that data as well. So that's basically—yeah, yeah.
I understand. You get the metadata from all your datasets, you feed it into the large language model or the embeddings, and that allows you to interrogate, um, your data in NLP language—so the natural language speak. Um, get the results if you want.
That's right, yeah. And then on top of this, you know, with best-class BI with dashboards, visualizations, roll-downs, filters, and all of that stuff that, you know, people would expect. Um, and the, you know, the stuff we were just talking about—being able to ask questions on the data and get answers back. Um, and both of these things and basically anything here is embeddable.
So you can take the dashboards and embed it. You can take, um, the NLP bar—the search bar—and embed that, um, and then basically have that user context done by an API, um, as well. There is also, you know, what we call "instance," which is, you know, an NLG layer essentially—so generating insights from the data and also AI-enabling it so it can basically summarize it for you based on what you give the prompts on it.
Um, and, uh, alerts. So alerts can be simple, you know, threshold-based alerts to custom, more complicated things that you can create. Um, we have a syntax called Cloud9 Cure, which is like an SQL-like transformation of the data if you don't want to use the AI for any other transformations. Um, and so you can use that Cloud NQR on those alerts as well as some many other transformations if you want. You can do some more advanced stuff there, too.
Um, and then reports and scheduled stuff—we can push the data out to an endpoint or email, Slack, etc., um, as, uh, driving actions. And then there's also, like, a, you know, somewhat limited machine learning capabilities, I would say. Um, so you can do, like, a, um, classification, regression, and anomaly detection type of problems and build models within NOI or if you have those models defined elsewhere—like SageMaker and so on—as long as it's fronted by an API, we can also call into that as well.
So, oh yeah, you can send your dataset to the API, get the results back, and then integrate it again in the NOI platform. Is that top layer as well? An API available?
And well, mainly, I'm looking then at the NLP and NLG—alerts, yeah. All of these things, we have a management API to basically—just so we have on-premise customers, for example. They basically create these templates and things, um, for each of their customer instances, which may be separate for instance, and then all of those things happen by an API that they run behind the scenes on.
So, um, yeah, AB, certainly, you can go in any direction that you want because you have the interconnectivity through the APIs to configure the platform, to configure the layers, but as well to, um, interact with the datasets as well.
Exactly. So, like, um, you know, a customer, um, that we, you know, they've been a customer for some time, but they sell to small businesses. But then some of their customers are big, and so they embed NOI as part of their platform. But then some of their larger customers, they also want these datasets that are specifically for their data to be sent to them by an API. And one of the other customers, they want it to be put into—
Here's the formatted transcript with proper punctuation, capitalization, and paragraph breaks:
Their Snowflake, right? So then they can basically tweet, you know, that same dataset that the original dataset they've created. They can basically send that over in multiple different directions to modify anything, yeah. And I see a lot of things available like the metadata and LPD alerts that allows you to get a lot of observability and traceability on what is happening within the platform and what is happening with it with your datasets with the data exactly.
Yeah, so you know our whole objective was like back in the early days, a lot of people try to dissuade us from doing the full thing, said, "Oh, this is too much," right? But then it's like we just came back to that underlying problem. So it's like two sides of the same coin. You got the BI side of the equation on the top hand, and then you got the dataset, and they're kind of intricately linked together.
You know, it's a lot of big companies are trying to do this right. Salesforce trying to buy Informatica plus they got the Tableau and then putting that stack together. Look, Google with Looker and BigQuery and stuff. But then our approach was, you know, if you have this holistically integrated that seems like a seamless experience, then there's a lot—the value goes up exponentially because it's all tied together, you know?
But yeah, exactly. And I've been into various architecture designs as well, and where you see we are building this one, and every company is building this type of architecture with the dataset as a service. They're not yet there in that understanding or in that concept, but they trying to get all the data unified but not having the availability or the possibility to push it back to any other of the sources. And that's still a big, big challenge for, yeah, when you're designing these architectures or being involved in a team that is building the next data platform again.
Yeah, yeah. So, um, yeah, and so that's our whole spiel. And then there's things that we're working on at the moment, you know. There still, I think it's still some months away, but I'll just mention it on where we all the pieces are tying together. So, um, so we have a mechanism which—not in this diagram—but that can ingest documents and, you know, PDF files and Word documents and Excel files and so on, and that can be passed through a Gen model that's on-premise that we run or the customers can run within their environment too.
And then the idea is that you have all of this, you know, structure, semi-structure data. We can use all of this for and combine that with your data in documents and stuff that you have access to and then match them together, right? So for example, if I want to know, "What's the contract and date for Converge One? What was the contract amount?" Being able to just type that in Slack and get answers back, right? And then say other information that's captured within Airtable or Salesforce or whatever, you know, the underlying source might be.
And to combine those two things with, you know, the Gen RAG approach plus your data approach and merge them together, that's basically a grail that we've been working on the last few months as well.
Yeah, that's great to hear because this is, well, to my feeling as well, the way to go—to combine the unstructured and the structured data as well. I've been playing around with the large language models and the reification of various unstructured sources as well. But if you see how you want to interact with a structured dataset or database, it's the LLM or the adapter that creates SQL.
Here’s the formatted transcript with proper punctuation, capitalization, and paragraph breaks:
---
Builds that query and then pushes it back, but it needs to understand the schema as well to be able to build the query, run the query, return results, and then interpret results as well. But you have it all in the NOI platform, so it should be easier for you guys to build this and bring it out. Yeah, that's the objective, you know.
So I think, on the NLP side of things, the easiest way to do the NLP stuff would be, "Hey, you have a text-based question," but then convert that to, as you mentioned, SQL, and then push it down to the underlying database and grab data back. When we originally did the NLP, that was where our initial thinking was, but then it's like, "Oh, this is not going to work in a price-level setting because you don't want arbitrary queries running against the underlying data source right, unless it's a data engineer who knows what they're doing and stuff."
You know, so if you're working with some large data sets within Snowflake and you run some queries, and all of a sudden your compute goes up, right? There's some real-world ramifications to that as well. And then, so the approach we took was, you know, you got this data set as a service. That data set as a service is curated with all the underlying stuff, and then any NLP would go against that data set as a service, so it's safe.
We can do whatever transformations and manipulations on top of this data set that it's validated essentially, so that's the approach we've taken. And we built our own NLP engine on top of that essentially—that's how we've done it. We are looking at feeding synonyms and things like that to the Gen to enhance that and improve the experience, excuse me, at the moment as well. But yeah.
Yeah, so the data set as a service is either a stored data set or sometimes just a definition on how to query underlying sources. And that's where you say the data set as a service layer is an extra safeguard layer—not to have everybody free-wheeling on the sources but just generating some NLP queries and firing that off through the complete stack.
Exactly. You know, in a traditional world, it would be kind of like, "Hey, if you have all the data that you want into Snowflake, Redshift, and then you have your transforms done on top of that, and then you have these curated set of tables, and then they give to the users, say, 'Hey, you can query these.'" So it's somewhat similar to that concept, but except the data set is, you know, it could be multiple different data sources, transforms, real-time versus batch—all of that stuff encapsulated.
Oh yeah, and you have the governance as well available, where you could define who has access to which data set and safeguard a bit on how the data is used and who is using that and when it was used.
That's right, yeah, exactly. Okay, yeah, fully understand what you put together and how it is now. Next step for me is just diving into the engine and seeing how performant that is, how flexible it is, and having an understanding as well on how you put that to work in just an enterprise-level environment.
Excellent. Um, so should I go back to my laptop and then just give you like a demo run-through? I can connect you to some data sources and do some of these things I've mentioned—data sets—and then go into the BI insight. Yeah, that would be.
Here’s the formatted transcript with punctuation, capitalization, and paragraph breaks:
---
Nice. That shows a bit how easy it is to connect. Uh, I have an understanding because I understand the concepts as well, but uh, how to configure it in, in, in NOI as well, that would be very helpful. And then you get an idea of, okay, this is how you put, uh, put it to use, and this is the type of problem what you're trying to solve.
I see that you have the complete platform, and where I said earlier, uh, that I've seen in a lot of companies that were building exactly this type of data platform, uh, but just getting, getting at the beginning. We have the drawings already, but the, the building is, is, is not yet done. Yeah, yeah. Cool.
So let me, uh, let me do that one second. Right, so just moving things around a bit. Good. So let me, uh, into one of our accounts. We, we'll come to the, uh, dashboard side of things in a minute, but uh, let's start with the data engineering side of, uh, side of the house first.
So, data sources, you know, a bunch of NOQ data that, uh, we have native support for. So we go in deep into each of these data sources and then basically figure out how to work with that in the form that the database was designed for. So, for example, we just put together Tigra, which is a graph database. So being able to query Tiger Graph in its native way, and then how can we then combine that with other sources, for example, so I use and maybe ML as a, as some data sources.
Um, so I'm connecting you to database. So at this point, I've connected to, and then you can start, uh, writing queries natively. So this is what I meant, you know, someone who knows what they're doing, so they can go in and create those queries directly, or they can drag and drop it in and say, hey, I'm interested in this collection, um, and I want to know the, the ES by customer, for example, and use a visual Builder, and we'll create the underline queries for you, or you can use the code generation.
Um, this is AI-enabled, so you can get some syntax help for explain queries and find issues and so, um, so this is that step of building that data set, right? So Step One is like, what is it that you're trying to get out of the original data source, right? So in this case, I got, I got a simple query that just says bounds by customer. Say this customer information is somewhere else, so if I want to join this with, uh, say my SQL database with some customer information, and this time it's basically a simple SLE query, right?
And we'll leave the FS empty here, but say this is what that data looks like, but I want to enrich the data from the query from here with that and combine the two things together or do a join across them. And then if you do a preview, what happens is we'll execute these both of these varies in parallel, then do the merge up together. This obviously a smaller data set, so it's quick. So then you end up with, hey, these are the total bounces by customer, you know, all time.
Um, so now this becomes a data set in itself. So let me just grab, just want to grab more data, so, uh, so we can work with it. So I just grab everything from the S activity. Yeah, it's better. So this is what the data set looks like at the moment, right?
And then the data strategy, this is the stuff we talked about, so either direct, and these direct can also support runtime queries. So depending on who's logged in and some parameters associated to that, you want to push that down all of those parameters into the underlying queries and can do that. And then there's some, you know, fingerprint caching and stuff like that you can do within that.
---
The transcript retains every spoken word while improving readability with punctuation, capitalization, and paragraph breaks. No words were added, removed, or paraphrased.
Direct query, or say, "Hey, I want to run this periodically"—whatever that is, minutes, hours, months—and then the results of that, how do you want to capture it? So you can do incremental updates. So once you've created an overall query first, then any subsequent queries, you just say, "Hey, just get me everything for this data since yesterday," and how do I keep upserting that into this dataset? So those are some options there as well.
And by default, we'll just chuck it into the last six mechanism if you do this, but you can also say, "Hey, I want to write this to a custom store, put it into a Redshift with the schema table," and we'll do those things seamlessly.
Yeah, yeah. I'm laughing because these are all the questions that are coming up, and then the next step is you're explaining all these possibilities in there. I mean, being in the data space and having built the data warehouses for the last 15 years, this is so powerful where you have all the possibilities to write it. I did a lot of stuff in SSIS, and if you can store it to a data store, then all to a SQL database, but yeah, all the tricks you have to do. But it's all in the platform, so that's really powerful to have all these possibilities built in.
Yeah, this is what we call DBR functionality. We launched that last year. It's been actually really useful for our customers. Right now, we have Redshift, Postgres—I think we have a handful of data sources we can write into—but the plan is to also enhance that with a few other databases as well. So yeah, that's the... I use this—sorry, go ahead.
No, no, I was just thinking out loud where you say, "Okay, I can see the use cases where this would be beneficial to save the intermediate dataset as well, to provision it either to the data science department or just a more secure environment where you want to have only those people have access to it in a more performant way." And that's why you want to put it in a different database.
Yeah, exactly, exactly. And sometimes you need both. So you could have a customer write to a custom store like a Redshift or something as a table, or you could say, "Hey, this is the core dataset. I want to extend this, maybe do some additional manipulation on this data, but then also leave it as is, and whenever this original one is run, just write it to somewhere else." Or you can push it into an API and stuff like that.
So an easy overview where you say, "These are the transformations, this is how the data flows, this is the update strategy," in one overview. Yeah, so the one we created—this is the dataset page—so it basically says, "Hey, this is where we got the data from, this is the underlying dataset representation," and then by default, some visualization. But then if I derive something from this, that will show up in the diagram or as part of this dataset, and then multiple different visualizations.
So if I create another visualization off it, which is basically another transform on top of this data, there's a couple of different ways to do it: one is drag and drop, or just ask the questions, like, "Total clicks by customer weekly," or something like that, and then this will do the transforms.
On top of the data set, you know, from the NLP, and this just shows you how we're getting the hits. If you do the visualization, put some visualizations together, you can always change it. Um, I'll come to this visualization in a bit more detail, but then basically say, "Hey, new view or something." Um, want to add it to a new dashboard yet, but uh, it's fine. And so now, you know, you got two visualizations on that same data set.
Um, and so this, this spot on is the domain of non-technical users to be able to do whatever they want with that now that this is, you know, validated and stamped and all of that. And all these other things for data types, what we've detected—you change it. You know, you need to specify a specific date format that you want to be standard for this data set. Set those up.
The search-based analytics is where the NLP world gets put together. Right now, we haven't set any configuration, but then you can set up synonyms and things like that or uh, some more advanced options. I'll just leave this as is. Maybe add, you know, one thing to say "campaign" is the same as "campaign" in this scenario. We're trying to improve using LLMs as well.
Um, and then, um, any visualization template that's for like pre-built visualizations. And then indices are handy if you're having large amounts of data that you are, um, using noi as an intermediary store. Being able to, like, how you're going to query that if you're, you know, tens of millions of records into that data set, for example.
So, so then this is that data set view, right? So, so the indexes are pushed back to the backend, or how do I understand the indexes? Uh, so the, in, in, the indexes are actually—this would go away if because this, the, because of the data strategy I use for this was it puts it into noi, right? I didn't use a—so what would happen is, um, either for noi or for anything we write into like Snowflake and Redshift, um, it would create an index for it like behind the scenes automatically.
It doesn't create for any direct—it doesn't create any index within the database. That gets too security-wise tricky, you know. Um, we don't want to be changing customer databases, right? So, so there, we—no, that's a bit up to the DBA if they still exist to optimize the system for that.
Okay, but I understand what you're offering as functionality through the noi platform, and you leave bits and pieces up to who should be responsible for either, uh, sources, uh, and so on. Exactly.
And then, then after, then it's just like from there on all the other boxes I drew, right? So this is the one we just created. Um, then this is the original like data. So then being able to like create the dashboards from it and then doing, you know, interesting things from that.
So for example, one-click insights, right? So, uh, I click on that, it will go in and build some insights for us. But then if I want to tweak that, say, "Hey, for this, let me just do a—let's let me, uh, configure my AI to figure out which ones are important," right? So based on the data set names and so on, then it will go in and highlight the ones that it thinks are important.
Right, so in this data set's anomalies, um, maybe some bottom group, so I don't care about that, so I check that growth and so on. And then it will create these summaries and anomaly patterns from that data set, which you can then use an insights widget to summarize it with some AI context. So you can take all of these bits of information and then just say, "Put a—"
Basically, a summary together to say, "Hey, if this is the dataset, these are the anomalies we saw, these are so many records," and then just get a basically a report out.
The way to do that, you know, would be in visualization types. There's like lots of options that 40-odd now, so that's an interesting given. So you make other summary subsets as well, you pull them all together, and then summarize those summaries. Exactly.
So, you know, the AI stuff can be handy if you feed it the right set of context. It's not a magic silver bullet as well. You still have to tweak it in a certain way, know what you're talking about. It's like my daughter said, "Hey, but this ChatGPT, it's not always right." I say, "Yes, that's what I'm trying to warn people for." It's just predictive stuff. It's smart, and it can do a lot of stuff, but you still have to get your gut feeling and know that what you see you can trust as well. So don't trust it blindly in such a way.
And exactly, I think that's a big danger from AI for the time being. But yeah, yeah, ultimately all it's doing is, you know, the LLMs is predicting the next word, right? Or token. So and then it probability that it thinks that it's important. But then, you know, for us, it's like that's not going to work with lots of data first of all because you can't train it with lots of data on the fly. So then you kind of have to have your data engine, and then this can be used as an enhancer to summarize it or to put things in, you know, to identify what's important from what you're going to get fed into and things like that. So that's what we see its power.
Yeah, but then also there's some drawbacks too, right? Even the example I mentioned, one of the things we're grappling with is, say we create a new widget on, you know, Instant Size that we just created, and say we change this to and then turn on the AI. So this is all the individual pieces of information, like just a fair bit to read through, right? But then if you do an AI-generated summary, it, you know, takes 10, 20, 30 seconds for it to basically come up with, basically, you know, a text-based summary of that because we have to take all of that, put it into LLM, and the more tokens we use up—and especially it's running on our environment, our GPUs—it takes a, you know, takes a few seconds. So those are some of the drawbacks with it.
Summary of the data—this is what I want to see. I mean, I don't want to click around in so many datasets to understand what is happening. I want to see it in one overview, and then I can get a better feeling of, "Hey, where are things going wrong?" or "Why do I have a high bounce rate or getting into the spam folders?" Should put that on top of my, uh, on top of my analytics of the newsletter. But I always have a problem of getting to the real raw data. That's a problem to get that out of the system.
So yeah, impressive. Yeah, so that's, uh, so I'll leave that. And there's a couple other new things we just came up with, which is, like, spreadsheet widget, for example. So you can basically, you know, for people who want to, uh, as the financial folks, as on, they can go in and create their own sales and stuff like that and put it on there if you like. So kind of write-back mechanism because sometimes for budgeting purposes or forecasting, that's sometimes interesting to be able to put the data in there and then work with that to do the—
Simulations, you know, the way we've approached it—so you can say these are locked columns from the data, right? You can hide and so on. So, let's say I want to add a new column, and the new column is that one divided by that one or something like that, right? Just like you would do in a spreadsheet. And then this gets stored at that widget level. What it doesn't do is change the underlying data that it gets from. But it's originally from spreadsheets and so on or within Notic Store, to write that back—that's been a topic that we've talked about. It gets a little bit hairy, so we would want to do that second part at some point. We need to, you know, battle-test this a bit more with real customer use cases since it's fairly new and then have that as an option later. Yeah, but it's good, I think, at this stage to just log the columns as well.
You have the Airtables of this world that allow you to do a lot of these things, but you can overwrite your data, which you don't want to have overwritten. So that's good—to keep it and see on a use-case basis where that should lead to and what availability you'd like to have. But I'm talking about 15 years ago, where this was a bit more hot—having the ability to do scenarios and forecasting, and they didn't have any way to write back that data into any system. So you had to create something separate from it, store it in an Excel file somewhere, then load it from there. These were the approaches we did at that time.
Oh, interesting, interesting. Yeah, yeah. By the way, on the instance size thing I mentioned, there's some, you know, predictions and things that we do too. If you're in it, if it's some like—and the predictions can be by group or date, and then you specify what the frequency, prediction date, and algorithm you want to use if you want to override our defaults. And it will just go do its thing—pick the right algorithm for you if you leave it empty—and do some predictions that way too.
Yeah, interesting, interesting. Just—it's kind of, hey, I want to get my hands dirty, start playing around, and see how fast we can get insights without doing all the data engineering stuff per se all over the place. I mean, getting it into one system, standardizing on the formats and structures, that's already 80% of the work you're doing. So if you don't have to do that, you can focus more on the outcome and the value and the insights.
Yeah, yeah, exactly. We agree. Um, yeah, so that's basically just a, you know, dip in the toe of what Noi does. Alerts and reports mentioned—so you can send alerts either on any of these widgets, use anomaly detection, for example. So if you look at, you know, the clicks and you want to get some anomalous patterns off that—we should—it's taking a little longer than I was suspecting.
You can even use it for just keeping an eye on your data quality—if something goes wrong or something in the loading processes. Exactly right. So if I make this threshold a little bit, maybe a little bit more noisier—so like this point, you know, you can set it up so that when we get stuff like this at a customer level, each of those can be appropriately called out. So we use that, for example, within our customers if the usage drops. Right? It's a good precursor indicator something isn't right—did they have a layoff or, you know, stuff like that.
Here’s the formatted transcript with punctuation, capitalization, and paragraph breaks:
---
So it's like a good thing for a customer success team to go figure out what's going on with the customer. Yeah, pretty really data-driven, data-driven insights. Yeah. Yeah. And then, the other bit to that, since you mentioned that, is the Slack and Teams integration. I think, you know, we run the company on that. Um, so it would be... so for example, let me... within Slack, well, pretty nifty. I think Slack integration, so all our alerts, reports, and stuff get into Slack. But then you can also get any of the things that we created, like this one, right? For example, you can grab it, you know, on demand right from Slack on your phone if you like, or ask questions to say, "You know, what was the average price for Tesla weekly since last year?" or something like that. I don't know if it's going to get... I don't know if this account has the right stock dataset, but... yeah, it doesn't. But yeah, it's hitting with something else. So, but you can ask those questions, and if you get a match, we can get that data back. Basically.
Got it. Got it. Simplification of how you interact with your data. Exactly. Yeah. Yeah. So, bringing that for us, the Slack integration and the Teams integration was important just because it brings data to where you work. You know, at least most folks in the US use one or the other. But yeah, I know Slack is not fully allowed in the European Zone all the time, security-wise. It's not allowed for a lot of companies. That's what I see. So, but Teams is... yeah, that's all over the place. So I think that's a nice place where you just communicate with everybody but as well with your data. So instead of having to jump into running the dashboard, seeing what is happening, doing the filtering... it's, "I want to know it now. I don't have to make a call or whatever." And that's how you... well, how you want to have your data served.
Yep. Yep. Exactly. So, yeah, that's no way scratching... no, a bit scratching. So you still have a lot in the box to explain or things you could show. Or just scratching the surface of it. I see the power and the flexibility, and the advantage is that you set up a certain strategy or architecture, but you can easily swap it around just starting from there as well. But still, you need to know what you're looking for and how you want to get the insights as well. And once you have that view, you can use NoWay in a very easy way.
Yeah. I think I would say, on the setting of the datasets, that's... you know, we haven't figured out a way to where you just need someone who knows that data piece, someone knowledgeable who can set those up. But then, what we recommend is setting those up as like a business entity—things like could be within sales, it could be accounts, opportunities, combination of two, right? And then, you know, that's where everything related to what the business cares about around that topic or entity lives. So then it just makes it easier to... yeah, that's dataset as a service. Relates a bit to the concept of the data products, the data mesh principles as well. And NoWay seems to be the platform that could facilitate that in a very easy way because you have the data governance next to that and observability as well that helps in taking the approach.
In the beginning, those were Excel files that were just lying all over the place in an organization, but nobody knew which dataset did exist. Just saying to refresh it or just knowing how fresh the data is... can you...
Trust it, whatever. All these things, but with a platform like noi, I see that that is one of the issues you're tackling as well.
Yeah, yeah, exactly. Yeah. Um, yeah. And then, uh, um, I don't have a demo for the doc stuff, but uh, I need to, um, I did one a couple of weeks ago, um, so I need to rejig that. And I'm happy to show you how that works, uh, as well, um, and then, uh, put some use cases together around that, uh, if you like, uh, so that's that concept of merging the unstructured data, the documents and stuff, you know.
And then the example I use for the talk was, uh, being able to ask questions in contracts and get it back from Slack, you know. So yeah. And I would be interested as well because currently I'm working with a customer just into their first steps of digital transformation as well. Just gave them a course on ChatGPT, what you can do with it, and then was, yeah, but you have to be careful because of privacy reasons and don't upload all your, uh, product manuals.
Yes, they're public, so we can do it just for the workshop and show people how you can talk to your PDF. But now I'm looking into deploying the large language models on a, just on a local system and then playing with that. But it feels like, hey, let's have a look at noi as well at the same time to go faster, to build these insights, uh, that would be a very nice use case as well to just show the power, how easy it is to get all this information together.
Their idea is, let's take a picture of our industrial gear or motor, take the serial number out of that, do a query online, take the product, and then you can say, "Which cable do I need to just connect the gear to another device?" or something like that, uh, and that's one of the use cases we want to try to build and see how that would be possible.
Well, I'm quite convinced that we can get something out of the large language models, but the challenge is they're so different in their predictions and what is the outcome. So you have to test on, I think, at least five or six levels to see what do you get by prompting and all the different layers in between as well. So that's, to my feeling, the challenge where we're up to.
Yeah, I'll definitely, uh, fire the demo and show you. The approach we've taken is, you know, when you ask a question, it's any documents that it gives you the answer, but you also want the user to trust that answer. So we give them the sources where it got the information from, you know, so then they can be confident that this is legit, right? So the consumption of LLMs is just like, is it just making stuff up?
So yeah, that's what I did with this big manual of 300 pages, and I told the people, I say, well, I just took a bold move and I just loaded it up and then asked, "What is this PDF about?" I didn't take the time to read it, uh, then I got some answers back and then I verified to the PDF, does this make sense? But I'm by no way an expert on your gears, on your gearboxes and machines, so I have to trust that the LLMs are coming back with some interesting information.
But the point was more to show how easy it is to summarize these big chunks of text and get at least some simple insights. I was trying to look at a mermaid diagram for a flow, and it—
Just asked, "Hey, give me some principles or steps for problem-solving or whatever. What do you find in the PDF?" And then you get something back, and I say, "This does make sense. Let's have a look. Is it really in the PDF, and does it make sense?" And yes, it is. So it's okay for 80-90% of the time. That's an interesting way to go.
But if I see people saying, "Hey, we have this amazing solution," and now playing with the LLMs, I'm thinking, "Guys, can you put it in production? Can you update your LLM behind the scenes if something changes? What testing do you do?" I have too many architecture questions to trust the system where a lot of consultancy companies are trying to sell to smaller companies that don't have big teams to challenge those. But yeah, having fun for the time being on that level.
Yeah, it's definitely interesting. The funny thing is, as we were... So I got my car manual because I was trying to figure out some things, and it's funny you mention that car manual. That was a thing I used to test the stuff because I was like, "How do I do launch mode on this?" And then it gives you the steps, and then you verify it on the PDF. So, "Oh, okay, that's actually pretty legit."
The way we architected that LLM piece is like... The M stuff is going to change week over week, pretty much, right? So it has to be model-agnostic. But then, how can we put this framework or architecture in place where that can be swapped out? The underlying vector store—like A or Elastic or whatever that might be—can be swapped out. But then you just interact with certain API endpoints that we, from the core application, can call. That core API, if it's doc search, then we can prompt it in a certain way and have security and stuff around it. And then also swap out the LLMs or give the customers the option to, you know, instead of Misra, use something else and do it that way. Then we are not tied to anything.
But yeah, that was the same approach. Just being a few weeks into the LLM space, started playing around with LM Studio where they have a wrapper around the OpenAI API, so then you can load your large language models and have an abstraction layer in there. But then today, I was playing around with LangChain and just trying to get the ChatGPT Python code for the LangChain, and things didn't work. But then I found out, "Hey, they changed LangChain. They have a core version, they have a public version, a community version as well." So things are swapping around. There you see, they don't have the recent information to help you build that, so you have to go out and do online research again to find the right instructions and the right APIs and libraries to use.
So there you see, if you're on the edge of developing that, the large language models can't build that good code for the time being yet. Exactly. It's interesting—you can get 60-80% pretty quickly, and then shiny object, right? And then that last 20%... Ah, it's... Yeah, exactly. Learning a lot of the things, but you still see, okay, on the architectural level, we still have to be very careful and make it production-wise. It's going to take another few years. That's the feeling—maybe a year, maybe two. Things are developing very fast, like you say.
Yeah, exactly. Excellent. Okay, good.
