From 7 Days to 2 Minutes: Automating Workflows with Knowledge Graphs

0:10All right, Hello everyone. My name is Anaya Rai Singani from Mongo DB Ventures, and I'm here today with a very special guest, Audi, the founder and CEO of Morphic. We have actually been lucky enough to already work together on a joint blog post, and I'm going to be linking that in the description box below so you can read it for yourself on the Mongo DB blog, but I will be mentioning some parts of it during this interview today. So thank you so much for joining me today, Audi. Can you please go ahead and introduce yourself to our audience?

0:40I'm Audi Co founder and of Morphic. I live in San Francisco, bail out of the docbatch area and super excited to chat with you. OK. So just to start us off, Audie, could you introduce Morphic for folks who maybe have never heard about your company before? Absolutely. Morphic helps businesses understand complex data and their processes, and then we help automate high leverage tasks within the business. What would you consider Morphic to be more of?

1:08Kind of like a dev tool? Or would you say it's mostly for enterprise companies? That's a good question. So our North star is that we want to bring the most value to our customers. A lot of developers use us and whatever we build with enterprises, anything that can improve our product, we would like flow that down. In terms of developers, they can like meet us where they want. So if they want, they can use our MCP, our API. We have a Python SDK and a TypeScript SDK.

1:39Or they could just use us on the UI, which is technically what a lot of our enterprise customers do. They just skip the API and MCP part and then they just use the UI. So yeah, it it meets you where you want. Love that, and if I was a developer and I wanted to start using Morphic later today, where should I go first? Absolutely go to morphic dot AI. Actually depends on your preference. If you prefer to self host it, you could go to a GitHub, download the docker image, get up and running with it.

2:08You can use local alarms if you want so there's no network ingress or egress. You could also the easiest way is to go to morphic dot AI sign up for her account. It's free, no credit card required, and you can start building in like a second or two and. It's open source too, right? It is open core. Yeah, OK, perfect. And then what was that pain point that push you to build Morphic? So we were trying, my Co founder and I were trying a bunch of different AI apps just tinkering around and we realized that to really make it work, you need to marry it with data and AI can understand unstructured data super well.

2:50However, the frameworks that existed or the models that existed were not performing as we expected on on those data points and the information, it inherently was super lossy with those providers. They needed to be a better alternative just to get an AI application or an assistant to do some meaningful work. We had to do a lot on top of it to make it understand that data. And that was like a light bulb moment where we were like, hey, this is probably a great product to work on. I love that.

3:26And when did you kind of realize, like, what was that pivot point where you realize that just like chat with documents or basic rag tools just weren't enough? We were working with this customer that had really complex architectural drawings or floor plans, and the way that current systems would work is they would have an OCR step where they would try to extract textual information out of a document. If there were images in the document, the really sophisticated ones, what they did was pass it to a captioning model. So you could caption images.

4:00However, let's say you have a graph or let's say you have a drawing of like a living room with like sofas in the middle. There are so many questions that could be asked over a single data point that you cannot capture those in words. So we needed to capture everything. And current solutions were just not cutting it because the whole process that they used was inherently incorrect in in in our view. Yeah. Super interesting. What do you think? Because kind of from that, what do you think?

4:32Like the biggest misconception people have about Rag is because, you know, especially in AI, everyone's talking about hallucinations, but I feel like there's not a lot that's going on to help kind of bridge that gap and that barrier. And it seems like Morphic is. So can you explain a little bit how you went from seeing that and then creating Morphic to, you know, fix that problem? I would say the biggest misconception around RAG is that RAG is equal to vector search.

5:01A lot of people when they talk about RAG start talking about, hey, what vector database do I use or what embedding model do I use. But it's much more than that. It's about getting high quality context back to the LLM. And that is not plainly just semantic search. That could be searching over some metadata that you have. It could be searching over very specific details that semantic search would not capture otherwise. Those things are not the same as as just plain vector search.

5:35That's a misconception many people have. Are they equated to to just being vector search? But doing things like discovering what documents you have, or discovering the metadata, or like any tags that you have on top helps you narrow down that context and pass in only the most relevant context to your LLM so it can answer or perform more effectively. No, I love that. Why do you think it is that most AI assistants really breakdown when documents include these complex diagrams, visuals or tables? Because I know Morphic is really, really good at processing in like diagrams, videos, all this complex stuff that is not just text, right?

6:16Exactly. So the way we're different is we would not use something like OCR or we would not use textual embeddings. What we would do is, let's say you upload a PDF, we would treat every page in that PDF as an image and then pass it through a visual language model and generate our embeddings through that. So we trained a small vision language model to instead of outputting tokens, output embeddings instead. And that works super well because that is technically how the LLM is understanding that data in itself and all sort of information that it would possibly be able to generate out of a certain page would be captured within that.

7:01So when you're retrieving, you're not getting back chunks of text, but you're getting back the correct page. So let's say you have a lease where you have the DocuSign ID on top that might be missed by an OCR assistant, you still get that information back. Or if you have signature pages that might some signatures might be missed, you still get that information back versus just losing that information with with other providers. Very cool. And how did you find out about VLMS?

7:30Because I know right now like that, at least from where where my viewpoint is, that's not very common. A lot of people are dealing with a lot of hallucinations, a lot of loss. So how did you figure out that VLMS are the way to go? Because I know from seeing on your website on Morphic, like some of your VLMS are outperforming some of the biggest embedding models out there today, right? Yeah, exactly. So a bunch of reading research papers I think was a big part of it. There was this research, specific research called Coldpally, I think it was out of French institute. I might, I might be wrong that, but Google also worked on polyjama and techniques like late interaction. I think just learning more about those unlocked a possibility to marry that to embedding generation and not just token generation.

8:22And that was sort of the moment where we're like, hey, you know what, We can make LLM see the data instead of giving LLM some convoluted form of that data, which is lossy. Yeah, I know that you combine embeddings with a knowledge graph, right? Is that kind of what you mean when you say this or for listeners who aren't really that deep into AI? And for like, how is that different from relying on just embeddings by itself? Outside of embeddings, we rely on a lot of other information.

8:53What we do with every customer is truly understand what documents they're giving us and what information would they want out of those documents. So while ingesting, we would create an evaluation set so we know the really complex questions you could ask of one page in a document for the 900 page manual in like thousands of manuals. And we would use that to improve our embeddings back again. So yeah. And and then using different tools, we would extract a lot of structured information as well.

9:31So let's say it's a lease document, we would extract rent information. Or if it's an architectural diagram, we would extract things like how many doors there are or how many toilet diagrams there are or the symbol table of it. And that information helps us while our agent is doing that retrieval, to minimize the entropy of the system. So by reducing randomness, we can increase the chances of finding the right context and passing that back to the other one. So I want to move on a little bit to your architecture. In the Mongo DB blog, you shared that as Morphic move from pilot deployments to real enterprise rollouts, your Postgres and Jason B setup started to show its limits. So can you talk a little bit about like what specifically began to breakdown as you scaled on a relational database so? The structured information that I mentioned that we want to extract out of those documents.

10:25If I'm using Postgres without Jason B, I'll have to keep on creating new columns as I discover more fields. Which means that the model is not or like the table rows and column model is not well suited to an ever changing or dynamic data set underneath. And you don't face these problems when it's just plain structured data. But when you start dealing with unstructured data, I might have documents where I want some data points, some documents I don't want those data points. So yeah, the table column structure, sorry, row and column structure does not work well there. If I start using Jason BS, those inherently do not have typing information.

11:07So if I'm ingesting date, date information, how do I filter on those? To do all of those things, we had to build our own translation layer. And then as we built more and more, it seemed like, hey, we're technically writing, it's a MongoDB style translation layer, just to get LLM to be able to query that metadata, which wasted a lot of time in engineering. And also yeah, we had to have like thousands of tasks cuz you want accurate information. Very cool.

11:44And then So what made you've kind of touched it, but can we dive a little bit deeper into like what made longer to be Atlas feel like the right foundation once you realize you needed more flexibility? That was the point where we were like, OK, we are building the translation layer by ourselves and that's not what we are experts in and that's not what we should spend most of our time on for startups. I mean, time is the most important currency and if you're wasting time on something that already exists, you're either reinventing the wheel or you're not working to your strengths.

12:16So it was pretty obvious that something needed to change that and we needed to use something that's much more flexible. Mongo DB came in and then it was, hey, we're not bounded by rows and columns anymore. We can be as dynamic as we want to. I don't have to have specific translation logic in where I'm by myself converting like a dollar equal to an equal in in Postgres or things like that. So it was just much simpler to work with Mongo DB there and then a bunch of other features like being able to spin up private instances of databases using like just a single URL rather than one paying extra for it like like SQL providers make you do or writing again another script to just be able to generate those have a routing table made yeah, it was just a lot of engineering on top that was unnecessary when when you use some something as flexible as Mongo.

13:18I know too that you've said that Mongo DB reduced query complexity and simplified multi tenancy. What exactly did that unlock for your team kind of in your day-to-day? We were initially running a multi tenant system where we were using one instance of a database but storing documents for all our customers, which was. As you start selling to enterprises that breaks down because everyone wants their own database instance, everyone wants their own file storage instance and and like data should naturally be segregated for everyone. When using Postgres that is possible but that is again a lot of lot lot more work than then it would be with MongoDB. So with Mongo, we when you spin up something on MongoDB Atlas, you get a Uri and with that Uri you can spin up thousands of databases within that same cluster. And those are inherently like separate, those don't share any data or anything like that.

14:22That just made it easy to form multiple customers without having a routing table, without having like a secret manager just to save different Postgres URS for them securely. Just reduced a bunch of engineering overhead and made it so much easier to to pass on the value prop to our customers when compared to using something something different. Very. Nice. I know too that the article really heavily emphasizes the accuracy and reliability are huge non negotiables of course for your customers, right? Especially because you're dealing with highly regulated or very high precision precision industries. So how do you actually maintain that kind of level of trust in practice?

15:09A lot of it has to do with I think #1 for customers is security and their data not being lost or not being messed with or like leaking out. The things I mentioned about having a separate database with just one URL, that certainly helps that other things like. So at that scale, you need to have, You simply cannot just rely on semantic search or like the store to find the relevant data points. You need to rely on other structured information that you can extract while ingesting documents.

15:47And those again, very easily expressible in MongoDB. So if I'm storing dates or if I'm storing integers, I can like do range queries on them. Now I can do equality queries, I can do regular expression queries on those. And that's just very complex to do with something that's not Mongo. And I think, yeah, for us, getting that high reliability means reducing entropy as much as we can, for which we rely on a lot of structured information and working closely with the customer to build ontologies for them, etcetera. And it just fits in so well that compared to something else, yeah.

16:29So I know too that you're part of the mongod for startups program, which is very exciting. Can you talk a little bit about how that has supported Morphic as you've scaled? And what does the future of Morphic look like from here? When it comes to the MongoDB startups team, I think the best part for a startup is definitely free credits. You get so many free credits that you can experiment a lot, you can build a lot. I think outside of that, there's a ton of support. So things like helping with Co marketing. We I know we did a blog that that helps us as well get into developers eyes and like hope potentially reach more customers.

17:11And then I would say that that the team is generally so helpful. They they try to touch base often and, and I can ask them questions. There are various roles on the team as well. So like I know Mongo DB startups team, I've spoken to someone who emphasis, who's, whose emphasis is go to market. So I can ask them those go to market questions or someone who does marketing really well and I can ask them those those style questions. So I think it's just more than like the credits or anything, it's getting like a second opinion on, on some of the strategies or like just being a good, good thinking partner. Love that.

17:55As a founder, what is your favorite use case that you've seen from one of your customers where they've used Morphic? That's a good question. We have this manufacturing customer that does like thousands of projects in a year. They make industrial ovens. And what we did for them was initially they wanted to understand all the CAD files, etcetera, and let their engineers when they're designing new things, be able to query all the old data for design inspirations or like help the field text when they're in the field. Just ask questions about how do I set this up or how do I modify this?

18:32But one super interesting use case for them was they get calls from their customers for orders and then they have to generate quotes for them. This process usually takes like a week or 10 days to do. However, just being able to understand all the past data, building like a relevant good ontology on how how that flows. We were able to automate that process. And now instead of seven days, it takes them less than two minutes to generate that. And the impact is not that they don't have to do that work, but it unlocks a lot of potential revenue for them because they're able to respond more to quotes. And then the blocker is no longer technology or intelligence that it's just the size of the facility or how many things they can make.

19:22So that's super interesting where we just removed such a big impediment and it wasn't difficult once the data was inside morphic, yeah. Wow, I love that. It must feel so good as a founder to be able to see results like that, right? And just hearing about it and just from them, them telling us, you know what, this has been a complete game changer for us. Yeah. And can you do more of this? And I think it also just naturally builds more trust with them so that they would tell their friends about it. And we grow as a company as well. And kind of our last question, if we Fast forward five years, what does understanding enterprise knowledge at scale look like and what role do you hope Morphic plays in that future?

20:09Data looks like I think in the future is the data layer is self healing, it's self updating, it's queriable by by an AI assistant. I think one of the features that I forgot to mention about why we like Mongo DB so much is instead of us having to, instead of us having to give, give our agent our own language to query the data, we could just give it the MQL language to query the data. And, and it does it really well because one, it's, it's been trained on a lot of data that includes Mongo DB queries. So those aspects just like help improve the data layer. And I think in the future, the data layer needs to be #1 secure, robust, self updating, self healing, also be able to figure out the gaps.

21:00I think that's a huge point where a lot of our customers, they have T BS of data. And with that data, a lot of they do not get expected responses a lot of the times because some data might be missing. And you don't realize that when a human has to deal with millions of files. But with a good system which can figure out what the gaps are in my knowledge, what what do I need to update in my knowledge or like find mistakes automatically within data. That's that's super useful in terms of like when Morphic goes from there.

21:35It's what can we build more on top of these workflows. So it would be really understanding the processes around that data, what's the input, what's the output? Who does it today? And like how can we do it in the same way or much better? To close us out, if any of the listeners want to learn more about Morphic, where can they find more resources? You can check us out on morphic dot AI. We have a GitHub morphic org slash Morphic core and feel free to connect with me on LinkedIn.

22:06Thank you so much for being here today Audie. This has been fantastic. I look forward to connecting with you soon. It was great speaking to you. Looking forward to talking soon again. Thanks.