Transcript
0:00 The intel, most intelligent robot in the world, doesn't know what you didn't tell it. >> Somewhere it can feel like it's become a buzzword. >> You know, the best way to work with AI is to assume it can do impossible things and reduce your expectations until you get to something it can do. >> We already know that the models are great. And now more of the attention comes in from >> Because the models are far better at public information than what they are in an enterprise. Without closing that data gap, it's hard to benefit from any increase in intelligence.
0:30 >> So, you've seen all of these waves over like the last two decades. >> And like you imagine like all of the capex we'd ever put into Google, what is this going to be? And it it turned out that Larry was right. and I do think there's a a bit of a moment like that that's also going on in AI. >> How do we even verify that the graph that we have built is right or not?
1:12 I'm here with Chris, who is VP and a Google Fellow, who's been at Google for over two decades. And we have a lot of really interesting conversation. You've been at Google for like over two decades and over a decade and a half ago you co-authored a paper for Google Spanner. >> No. >> Yeah. And that was sort of the starting version of graph databases being used in production. So, tell us more about graph databases and obviously like we have a lot of follow-up questions to that and how it's being used in agents, but would love to learn about how that even started.
1:47 >> Right. So, Spanner got started. We published the paper in 2012. I started working on it 5 years before that. and really I think one of the things Spanner became known for was bringing SQL and relational to the world of scale out databases, which had really not been done a whole lot prior to that. and that actually took us a while to sort of recognize. we had built Bigtable many years before. And, you know, the big Bigtable sort of big thing for us, so to speak, was storing a copy of the internet so we could index it.
2:24 but we were also finding that as as we developed, you know, more of the the modern applications, Docs, Gmail, these kinds of things, what we really were needing was something with better developer productivity affordances, like make it easier to program, and that really meant SQL and the relational model. So, they we worked very hard on that. We published another paper some years later about how we adapted Spanner to make it a good relational system. it was maybe five years ago that we started really seriously thinking about graph.
2:55 >> Mhm. >> and you know, it was it was interesting because we realized just sort of based on inbound customer questions from from Google Cloud and some internal signals that we needed to build something in the graph space. and it was interesting cuz we went out looking for, well, you know, what do people who want a graph database use today? And that was actually very hard to figure out. we talked to a lot of people who wanted to use a graph database but didn't have one yet.
3:25 and and what that what we also ended up learning is that actually a lot of that data was already in a relational database. and that was that was many customers' starting points. Many of them had concerns about, you know, if I move to a graph database, I'll have to teach my entire company to use graph to work with that data. and so we ended up in the in the place that we are with with Spanner, where one, we bring scale to graphs that is hard to get from from many of other other vendors that are out there and really lets you bring graph to whatever data size you have. Also lets you bring in data sets that are adjacent to the graph that maybe you want to use with the graph.
4:02 This is this is something we see very commonly with customers. And then I think the the other sort of pieces we've made it possible to have a single set of tables that you can work with as a graph or work with as a table. Which is super valuable because sometimes like you just need to spell your question as a graph question or you need graph specific sort of execution to get it go to get it to go the right speed but at the same time if you just want to like poke around in the customers table you don't have to write a graph query for that.
4:31 And so we we we ended up like in a place that that's really nice. Now interesting like if you go back in in that chronology we started our graph work before chat GPT and before the the current AI moment took off and so I think that caught us a little bit by surprise like some of the new ways that graphs are turning out to be relevant but we you know sometimes luck is better than skill and we sort of stumbled into a moment where a scalable graph can make a really big difference.
5:03 >> Yeah. I love that. So Trace I'm sure you've seen this entire change in the wave right? Like whether it was Kubernetes which also came out of Google was open source Transformers was something that came out of Google TPUs was something which came way before the advent of like the the the wave of when GenAI became so popular in in the industry. So you've seen all of these waves over like the last two decades. From your vantage point how do you see the GenAI wave right now? Because it somewhere can feel bloated somewhere it can feel like it's it's become a buzzword but from your vantage point on how you're seeing this actually being used in the industry, do you feel that this is like a incremental change where it's like a layer new layer which is being introduced, or do you think people have to fundamentally rethink all of their entire stack ground up?
6:03 >> Right. I do think it's a big change. you know, I I think when I first sort of got into the industry, the internet was a text and images place, and images were sort of new. and you sort of wondered what all these computers were going to be for, and it turned out that the answer was streaming video over the internet, which we now take for total granted. and you know, I I I think that GenAI is in some ways the answer to the question of what could you do with an even bigger computer.
6:38 and it it does I think do some really new and interesting things for you. you know, I found that AM and AI overviews in search are a big transformation in the way I at least interact with Google. It does a lot of things for me that I I have never been able to do, or could only have done by investing a lot more time into digging through sources and sort of scraping them together. It's ability to do synthesis is remarkable, and this has kind of come come out of nowhere over a couple of years.
7:07 I think, you know, you can look at coding agents and some of the things that they're able to do to you know, just enable stuff that wasn't going to happen that without the extra speed. and you know, I I think we see some of these things that are real. and you know, where it will go is hard to predict. The the fact that there are some things that will probably never go away that we will always value, I think is also true.
7:35 >> Chris, do you agree like we are living in a era of code abundance? Like everybody is producing code, everybody loves writing code and building apps. That's That's definitely what's happening. But, you're working very close with customers and you see what's really being implemented in the roots of it, in the weeds of it. What do you feel about the AI adoption curve right now with large language models and agents from an industry adoption standpoint? >> I think that it has outpaced where I actually thought it would be.
8:11 you know, I I remember a couple of years ago at Next I was meeting with customers and talking about what they were doing and many of them intended to use Gen AI but had never done any. and you know, you you move on a year and many people had done some work on organizing their data and built some chatbots and things. And this last year, you know, you it's not not everyone. maybe not even most, but you certainly run into more customers who have put something in production that is making them money. or that is making a difference for their business and how it executes.
8:45 and I I fully expect that at Next '27 I'll be talking to a far more customers who have accomplished something meaningful with these new tools. and partly that's a reflection of you know, the models get better. There are things you can do with today's models that you could not have in a million years done with the models 2 years ago. And just the pace of improvement is such that, you know, one of my colleagues, Sam who you met this morning, sometimes says, you know, the best way to work with AI is to assume it can do impossible things and reduce your expectations until you get to something it can do.
9:18 and very often that point that you reach by assuming it can do a lot and backing off is much higher than than you would guess. Especially, you know, again the models that we have out now like Flash 3.8 like it's has shoulders better than 3.5 at the things that I used to do. and so I think there's a There's a long way to go with it. >> You were talking about models, right? And you mentioned like how how the newer models are leaps ahead of the previous generation of the models.
9:51 but we've also seen like the mere excitement of every single model update has somewhere reduced than what it used to be before because we've seen that plateau reaching from like a model benchmarking perspective. We already know that the models are great and now more of the attention comes in from context engineering and loop engineering and harness engineering and how do we really plumb the data well like I was speaking with Andy earlier about agentic data cloud.
10:19 >> Yeah. >> And that conversation now it feels like the limelight which models had for so long is sort of reducing. >> Yeah, and I think there's a few interesting dimensions to that. one of the things we've been thinking a lot about in Google Cloud with our sort of focus on enterprises and enterprise AI adoption is that the models are far better at public information than what they are in an enterprise at enterprise information.
10:50 like if you ask a model to you know tell you about the code in Postgres, it's awesome. All that stuff's in its training data. It implicitly knows a great deal about what's going on there. whereas the private information that you work with it as an enterprise is all hidden. And the model has to discover it. You have to somehow engineer that stuff into into these solutions. And so I think some of what you see in like the limited amount of excitement is just that without closing that data gap it's hard to benefit from any increase in intelligence cuz like an the intel most intelligent robot in the world doesn't know what you didn't tell it.
11:30 >> Yeah. >> and so you know, I I think there's there's a a bridge to be crossed there. I think the other thing that's that's a little bit going on is that 3.5 was pretty impressive. It could do some things I didn't expect a computer to ever be able to do. And like 3.8 can also do those things and some new things, but they're not quite as like they're not what you do every day. This is the other thing that's been an interesting trend to watch, especially with cloud customers, is that you know, there's a the level of intelligence you need to do useful enterprise jobs isn't necessarily the frontier level of intelligence the way it was a year ago.
12:13 Now, a a relatively inexpensive model can often just do stuff for you. and does it as well as the top model cuz that problem is sort of saturated. We can already do that problem as well as it needs to be done. and you know, a a good example of this that I I saw probably on X was if you have an enormous pile of PDFs and you just need to like have a model dig through those and find some information, >> Mhm.
12:48 >> you used to pay a couple of dollars per document to do that with the models that were available and now you can do that for pennies per document. And so what's economically available has changed quite a bit. and so even when you're not looking for the next crack of intelligence, very often things that used to be uneconomical are now economical and you can use them at greater scale. I think if you'll permit the a story, like one of the early Google things that I thought was this just mind-blowing for me, like I came to Google, Google was search, you type a query, you hit enter, you get search results and this This great, right? And Larry Page wanted it to be every time you type a character, the search results change. As we researched on that, and like you imagine like all of the capex we had ever put into Google was to deliver the search when you hit enter.
13:39 >> Yeah. >> And like what is this going to be? And it it turned out that Larry was right and it was an amazing launch and the engineering came through and delivered 10 searches for the price of one, you know, give or take. and I do think there's a a bit of a moment like that that's also going on in AI. >> I love that. You were you were talking about like, you know, the advent of search and obviously that changed to from being keyword search to semantic search and vectors and embeddings and then there was a rise of vector databases. But now there would I would still say this probably like the top 1% of the enterprises out there were understanding how to productionize with graph DBs. So, could we talk about graph DBs a little bit from like maybe a level 100 perspective maybe maybe who don't really understand how graph DBs work or how they are implemented from a enterprise perspective. So, if you could talk a little bit about that.
14:32 >> Well, I I think the core value of a graph database, right, is that it explicitly represents the connections between pieces of data. so, customers and accounts, transfers between accounts, like all of these things in a relational schema you sort of have separate tables. The fact that they're related to each other is not not necessarily declared and not something that's very visible. and the value of the graph, especially in an AI context, is that the edges you show very clearly are edges that an agent can follow and use.
15:11 and so, you know, the the very first step of success for the graph is actually, you know, you just take the data you have, you recognize those relationships that you already understand exist. And you sort of reify them as explicit things that a that a model can follow. And it doesn't have to be a great deal more than that, especially with systems like Spanner graph where you can take the relational data spelled the way you've always spelled it and then sort of additionally view it as a graph.
15:39 I think when we talk about the more advanced forms of graph rag, we're really talking about how do you take less structured data and extract the structure from it and represent that structure as a graph and then query it again. And this is a pattern that I think we'll all see more and more as we go forward. It shows up in knowledge graphs, it shows up in our our knowledge catalog. roughly the the intuition to have for it is that the traditional rag is a little bit just like dumping a binder full of notes on somebody's desk and asking them to tell you something.
16:21 and if you go to the trouble of, you know, having some people organize that binder and divide it into sections and provide cross-links and indexes and so on, then when you drop that binder on somebody's desk, they just work more quickly. >> Yeah. >> and in the in the graph world, the the equivalent of that is essentially using AI to pre-look at all of your information, extract the connections and model them, so that then the next AI that has to come and answer a question under time pressure doesn't have to go find and reconstruct all of that stuff on the fly.
17:00 and you know, I I think that that's a a more complex form of it. It's sort of, you know, there's agents on both sides that you have to figure out how to program. but I also think that Google Cloud is bringing more and more capability to help do that. >> Mhm. >> and you can also find some of these capabilities here in in open source for say looking through a a range of documents and finding a graph schema and graph links that can just go into a graph database. And similarly, there's a lot of good work that's gone into teaching agents. I think our data data agent kit even has some of these for taking text and just generating graph queries. You don't have to know how to spell the graph query to have an AI use it today.
17:43 >> I love that. I definitely want to double tap on that, Chris, because I think one of the major concerns when we're talking to folks who are thinking about building these databases and build graph frag in production, they stop themselves at this point. They're like, "Oh, I don't think we understand the ontology really well. I don't think we have enough metadata to really say what that graph should look like. How do we even verify that the graph that we have built is right or not? Is it providing it the right kind of information or not?" So, are there any like rule of thumb that you would say would be helpful from like a practitioner's lens on how to get started?
18:18 >> So, I I think and we talked about this a little bit this morning. In in any sort of system like this, one of the most important things you can do is decide how to evaluate your end-to-end solution. Like, what does a good answer look like? What does a not good answer look like? What are some of the inputs in terms of the questions you want to ask where you know you sort of know what the answer ought to be and you're therefore able to say "Here's the question. Here's the answer.
18:46 Was it a good answer?" And you sort of build this up as a real library of questions you can ask a new layout of your stuff. >> Yeah. >> and you can sort of hill climb that. You say, you know, your initial setup with you know, maybe your best guess at an ontology achieves this. And then you want to ask the question, "Well, if I let an AI just decide on a few more entities and node and entities and edges and things to add to this database.
19:15 Did the answers to my questions get better or worse? Where are my wins? Where are my losses? And you can start to sort of understand, well, was that a good change or was it a bad change and I should take it out? and you know, I think a lot of the ambiguity in how to do these things is goes away when you realize you're just going to hill climb your evaluation. >> Yeah. Yeah. >> You know, I think a lot of the search quality work that we've done at Google over the years is this kind of work of you know, you have 20 ideas and you actually don't know which one's good and which one's bad.
19:49 Maybe only one of them is any good. And the essence of going quickly and actually improving your product is actually just being able to test all 20 and pick the winner. >> I love that. I absolutely love that. You know, you mentioned about this use cases around GraphRag, right? it makes me wonder if if folks have to think about knowledge graphs in general, GraphRag in the core essence of it will provide them with knowledge retrieval. >> Yep.
20:19 >> But when we sort of flip the switch going from knowledge retrieval or enterprise search to agentic capabilities, how does graph help? >> Yeah, I think there there's a a few useful things. One is just you get better context. It's like if you imagine sort of search over a graph, you maybe use a vector search or a text search to find yourself the entry points to the graph that you want to to give this give this agent, but you know, I'll use a a silly example of like people.
20:55 And if you're searching for people and the agent has said they want to know about this person, well, you might have this couple of paragraphs of text about the person, but a graph might know like who's their spouse, who are their children, what boards are they on, and etc. and etc. And all of these things are just like one hop away in a knowledge graph. >> Yeah. >> and so, very often if all you do with the graph is you find an entry point in any of the classic rag ways, and then you just do a two-hop expansion in the graph, and you feed that graph to the agent. Well, now it just knows a bunch more things that are true cuz they're in your knowledge graph.
21:33 True. More true than it guessing. And those things might be really relevant to answering the question. Right? Like if I ask a question, you know, what boards is so-and-so on? This is actually one that came up with a customer. A graph can get that answer, and a vector database often can't unless there's actually a document in the corpus that spells that stuff out. >> Yeah. >> and so, they they end up being very complimentary techniques where there's just certain information the graph can get to for pretty easy.
22:03 >> Yeah, I love I love that. Chris, you know, you just gave all of us like a mini Thank you so much for taking out time with us.