Navigating the Data Labyrinth with Seth Earley

Ryan: today’s guest is an expert with 20 plus years of experience in knowledge strategy, information architecture, and information findability solutions. He’s the author of the award winning book, The AI Powered Enterprise, and is a sought after speaker. and Influencer.

Ryan: Additionally, he co hosts the Early AI Podcast. Please welcome founder and CEO of Early Information Science, Seth Early. Welcome to the show.

Seth: Thank you so much for having me. It’s a

Seth: pleasure to be here. Right.

Ryan: Yeah, the [00:01:00] pleasure is mine. Thank you for coming on. So I want to jump right in because you kind of have a brainful of information that I want to hear about. So what is the one thing you wish more people knew about using data to make better decisions?

Seth: So that’s a pretty broad question. And I think the way to the best way to answer that is to. Begin with the outcome in mind. So understanding what the business is trying to do, what it’s, what its objectives are, and, uh, deconstructing that to finer and finer degrees of granularity, uh, because if you just say, well, we want to increase sales, we want to reduce costs, that’s kind of ambiguous.

Seth: That’s kind of meaningless. So we have to say exactly how. Do we want to do that? What are all the supporting, uh, business outcomes that will support that? That’s a big picture, you know, outcome, but there’s other things such as increasing the, uh, uh, the customer base, the amount of customers, the customer base, uh, increasing [00:02:00] the share of wallet, right?

Seth: There could be a lot of other things. It could be, you know, expanding the sales force, whatever it might be building new marketing campaigns. So there’s lots of elements that go into that big picture objective. And then we, when we look at those elements, we have to say, well, what processes are now going to be needed to support those bigger objectives.

Seth: And then within those processes, we need to deconstruct those processes to understand who are the users. What information do they need at each step of

the process? So I think a lot of times, you know, people are attacking, uh, uh, problems, big picture problems with tools, right? Rather than getting to, or starting with what is the most important thing to the business, uh, uh, itself.

Seth: And then who are the players involved? And. What do they specifically need? I talk about, uh, information leverage points, meaning where can you get the biggest bang for the buck when you have a new piece of information or a more accurate piece of information, or, uh, you have information [00:03:00] faster, right?

Seth: What’s going to help you with your processes and your downstream, uh, systems. And so having that, that place where you say, Oh, here’s a really, here’s a pinch point. Here’s a critical point where, um, we have some kind of a blocker or we’re not able to make the decision quickly, or we have to go through too many manual processes.

Seth: Understanding those points are what’s going to give you the biggest bang for the buck. I think the other thing is making sure that you’re measuring your outcomes. So starting with baselines and making sure that you’re, Tracking against those baselines. So, so I think that it’s, it’s kind of a, what I guess I would also say, so that’s kind of motherhood and apple pie, right?

Seth: I think the other thing is starting with a good semantic architecture and, uh, data architecture. That’s a critical piece because a lot of folks think that the technology will take care of that. And as you know, having the right foundation is really critical to any tool technology or business

Seth: process. [00:04:00] Wow. Yeah. Uh, couldn’t agree more. I mean, I think like, first off, I love that term information leverage points. That’s a good one. Um, but you know, what I, what I really heard, there were two big categories of things. Number one, data is just a tool. Right. So if you don’t know why you’re breaking out a socket wrench in a given situation, it’s just kind of like, you know, you’re not going to be driving nails with it.

Ryan: So I think there’s this idea that a lot of people have like, Oh, we’re going to do data. Cool. Love that. Why?

Seth: We’re going to be data driven. What does that mean?

Ryan: What are, what are we doing with that? Yeah. So it’s really about what is the business strategy and then how can we use this set of tools to get there?

Seth: Very precise, very

Seth: precise points. Sorry, Yeah, yeah, no, great. Um, I mean, I think the other thing that I would love to dig in a little bit more, I mean, in an, in a non technical way is this kind of marketing [00:05:00] promise from, you know, every vendor out there of like, just use our stuff. You won’t have to think like there’s no code, there’s no effort.

Ryan: You’re just going to like, like plug it into all your places and it’ll be magic. And it’s like, you know, um, In like the least technical way possible, help our listeners know like, what is a semantic model and why should they care?

Seth: So I think, you know, the other misconception that I didn’t mention is that people will think that the tool is all they need, right? And start off with, okay, we have this problem. Even if I understand my, my, uh, process and my business objectives, now we’re going to apply a tool to it. And the problem, of course, is that.

Seth: You know, it’s, it’s the data that is critical to leveraging the tool. If you don’t have the right data, if it’s not in the right structure, what happens sometimes when we say semantic architecture, that means that there could be [00:06:00] a term that’s used in different systems that has a different meaning. Like sales is always a great example.

Seth: What, how are you defining sales? at what level of granularity, uh, et cetera. And is it net sales? Is it gross sales? What is it? And then the other is that you can have different terms that mean the same thing in different systems. So you can have the same thing, same term that means different things. You can have different terms that mean the same thing.

Seth: Mapping those together so that you can Disambiguate, right? The two terms that have different meanings where it’s sales, uh, net sales versus gross sales, right? They’re not sales. Sales is too ambiguous and then being able to map together those, you know, disambiguate those but also when you have Uh, uh, retail sales and, you know, gross sales.

Seth: And those are really the same thing, mapping those together. So in one case, we’re splitting them apart. The other case we’re mapping them together, but that overall is the semantic [00:07:00] architecture when you have all of these, Entities representing in different environments and different tools and technologies.

Seth: And that’s always the case. You know, I read something the other day that said, um, that it had related to AI, uh, and it said that, uh, 46 percent of

executives Admit that they have a data problem. And my response to that is the other 54 percent are in denial.

Ryan: Yeah. Yeah.

Seth: admit you

Seth: have a data problem.

Ryan: Yeah. You know, I think it’s like, uh, you know, in these big manufacturing places, it’s like, what’s the acceptable amount of, uh, metal, like metal shavings in your frosted wheat? And everyone’s like, surely zero. And it’s like, unfortunately that’s a non zero number, you know? So like, no matter, no matter, even if you spend every waking moment, you know, there’s something that could be improved with the data.

Ryan: So it’s really about focusing on, you know, kind of Pareto principles or [00:08:00] whatever you like to do to prioritize and just focus on like, what are the problems we’re trying to solve? And then how can we use what we have to get there? And I think you did a really good job. I’ve never actually heard anybody explain the concept of a semantic layer as cleanly as that.

Ryan: Um, You know,

Seth: I can confuse people just as well. So

Seth: anyway, Yeah, me too, me too, you know, but it’s, uh, that’s where all of your business logic lives and the idea that some vendor off the street, I don’t know what your sales cycle with them was, but like the idea that they understand every single morsel of your business as well as you do, and on a technical level that allows them to translate it with 100 percent accuracy is like, you know, so that actually leads into.

Ryan: you know, a really interesting area that I would say you are, if you know, if not the specialist, at least a specialist in, and that’s, how do we [00:09:00] go from talking about something like a semantic model, which is just, Hey, this is, we put all of your business logic into a layer so that the tool works. How do we go from that to talking about something like information architecture on a larger scale?

Seth: sure. So information architecture is just what it sounds like. It is a structure for the content, the data, the knowledge. in your organization, in your

Seth: enterprise. And just as, uh, uh, just like if you were building a house, you wouldn’t just start, you know, digging foundations and pouring concrete. You would start with an architecture.

Seth: You’d start with a plan, right? A foundation plan, plumbing, and then, and then you have all these other representations. So you’re going to bring in an architect, or we’re going to at least have architectural drawings, and maybe we’ll modify them to suit your needs. But the idea is that you have multiple representations.

Seth: There’s a framing plan, there’s a, an HVAC plan, there’s a plumbing plan, there’s an electrical plan, there’s [00:10:00] all of these different levels of granularity around, How you represent that house and how you design that house. Same thing happens with a data or information environment. You need to have things like wireframes, you have to have use cases, you have to have metadata structures, you have to have content models, you have to have renderings, you have to have all sorts of different things that are very analogous.

Seth: So information architecture is looking at all the different ways of structuring that content, data, and knowledge so that it can be used by. Different systems and different processes and ultimately consumed by humans, right? At the end of the day, a human needs to do something. A person needs to do something.

Seth: So we need to have interoperability between the different systems on their own, right? Because we don’t want to do a manual, um, uh, ETLs. We want to do transformations and spreadsheets and so on. So we need to have those things mapped together so the systems can talk to one another, and then we need to have a way that.

Seth: that [00:11:00] people can interact with it, whether it’s, you know, increasingly, it’s a chat or conversational interface, but that’s not everything. Obviously, you still need to be able to navigate. You still need to be able to search. You still need to be able to retrieve. You still need to be able to run different scenarios and different queries.

Seth: So. All of this requires that we have that comprehensive view

Seth: of the information sources in the organization. We understand the quality of those information sources, and we understand the structure and architecture of those sources so that we can build those interfaces. So that’s kind of a broad view of what information architecture is.

Seth: It can be on a very focused level, or it can be at an

Seth: enterprise level. So I have a couple things that I want to dig into on that, but there’s, there’s one thing that you said that I just can’t let pass without us addressing. And it’s something like I couldn’t agree more with, but if somebody else hears it, they might write it off. You said, ’cause we don’t [00:12:00] want to be using spreadsheets.

Ryan: Why don’t we want to be using spreadsheets?

Seth: Well, you know, they get lost, uh, they, they pile up, we have, uh, we don’t use the right naming conventions. We don’t know what the right version is. Uh, I’m not a spreadsheet, uh, uh, jockey. So I don’t know the details of how it can, but they can be very complex. You know, I’ve used spreadsheets in terms of financials.

Seth: You need their snapshots in time, essentially right there. This is a continuum. This is a movie. Right. And you’re taking a picture with a spreadsheet and that movie has to continue. So one of the reasons is that, again, it’s not giving you a real time, uh, of course you can build in connectors and you can build in real time, you know, mechanisms, but it’s not, it’s not as, um, as friendly.

Seth: It’s not as. Uh, as, uh, flexible as other types of, of tools are, and this is not my space. But my point is that when you have tons [00:13:00] and tons of spreadsheets, they get lost. They’re not named correctly. It’s hard to find information. It’s hard to get what you really want. They’re not a user friendly interface.

Seth: So I think that spreadsheets are, uh, uh, you know, a necessary evil in a lot of organizations, but you really need to say, well, why are we, Why are we not quartering the system of record, right? Why are we going through this intermediate process with this spreadsheet? It’s not the real deal. It’s not, it’s, it’s, it’s an abstraction from something

Seth: else.

Ryan: Yeah. Yeah. I let all, all of the awesome hit points there. I mean, to put it simply as someone who cut their teeth as a spreadsheet jockey, it’s painful and it’s manual, you know? And then if I get hit by a bus, I guess we’ll just rebuild that business process. Cause I was the only one that understood the inside of it, you know?

Ryan: And I, I love connecting what you just talked about there with this idea of, um, you know, the, the semantic model, [00:14:00] which, you know, might be, um, It’s definitely a fancy term. Um, like when I want to sound smart, I talk about a semantic model,

Seth: Oh no, if you want to start, it sounds smart to talk about n dimensional free space vectors.

Ryan: there we go with that, you know, but, um, I think that. When we talk about, hey, we are going to invest some time in information architecture. We’re going to make sure that our business logic is clear. The thing that to me is the most valuable about that is that we’re doing it in one place, no matter what that’s happening throughout an organization, right?

Ryan: Unless this organization is just like blindly flying by the seat of their pants and doing everything on gut, which some people do, and some people do really well,

Seth: You’d be surprised how

Ryan: I know, you know, but if the organization is doing even the very basics of like generating a financial report, right? Like how much money did we make, [00:15:00] right?

Ryan: You are absolutely already doing this. You’re just doing it in individual cells in an Excel spreadsheet that somebody else can’t follow, that you’re going to forget, that it might break. 10th time this week, right? You know, then you can get into a tough situation, where Something that you’re relying on to make a decision about your company is unclear.

Ryan: To me, it makes sense. Like, Hey, if you’re just willing to take the time and the effort that you’re doing over here, manually wrangling this information, just do it once over here and then it works for everything and everybody gets to use

Ryan: it. That’s, that’s the paradigm shift. That’s it. It’s stuff we’re already doing.

Seth: Yeah. And that’s a really great point that whether you’re doing it or not, it is a difference between, you know, an accidental information architecture and an intentional information architecture. You’re doing it because you’re just by the nature of, of analysis. You’re, you’re, you’re naming things, right?

Seth: You’re organizing things. You’re, [00:16:00] you’re, uh, labeling data, right? Labeling data is metadata. We need a reference point for that so that everybody labels it in the same way. If we don’t do that, then we have chaos. We have confusion. And as you say, you know, somebody named this thing in this weird way in this spreadsheet here, and they named it in this other weird way in the spreadsheet here, and you only know, you know, the people who know where the bodies are buried are the ones who can figure it out, right?

Seth: And,

Ryan: Yeah. Yeah.

Seth: is not a good way to run the business, obviously, because people leave and et cetera, the proverbial bus hit. But, but I think that it’s, it’s recognizing that you have to do this in a very big picture way to begin with. And that’s called the domain model. And the domain model or the big organizing principles like customers, what type of customers do you have?

Seth: Products, what kinds of products do you have? Processes, right? Solutions, um, document types, uh, you know, [00:17:00] all of the entities, account charts of accounts, right? All of the entities that are needed to run the business. And then those are the big picture pieces. And then what you do is drill down to define like all of your product categories and your product subcategories and your, your attribute models, and all of those things get defined.

Seth: To meet certain use cases, and that’s the critical piece here is that everything has to be driven by use case.

Seth: People will start to build models, data models, and I, I give this assignment in a class that I teach. I used to teach. I should probably teach it again, but it’s it’s saying, hey, um, come up with a data model for, um, for this, uh, um, for this, uh, patient, right, or, or for this, I know what it was.

Seth: It was, it was come up with a data model for an invoice, right. And they would start adding more and more pieces to this. But it was really a document. And the point here is you [00:18:00] only needed so much information in that document. What they ended up doing is rebuilding the accounting system in the document management system.

Seth: Whereas all you might need are, you know, name, address, you know, the list of the, the documents. The services or products, and then a link to the accounting system, right? Because you don’t, because the boundaries of those

systems are so important. So the point here is whenever people want to ask for more, uh, uh, metadata, more data points, more, you know, more details, you have to say, is there a use case?

Seth: Do you have a use case for that? Because if you don’t have a use case, you can’t have it. Period.

Seth: You don’t

Seth: have it, you can’t have It

Seth: You

Ryan: can get out of control.

Seth: get out of control, but people will say, well, I want to plan for the future. That’s fine. But what are your prospective use cases? You would leave it, you can’t do everything just in case,

Seth: right?

Ryan: Yeah. Well, you know, especially as, uh, like I said, as I, you know, former, uh, recovering spreadsheet jockey, shall we say, [00:19:00] um, I totally get it. Like I was one of the few people. You know, my first company that really had access to the source systems. Like I could get in there, I could get anything that we needed.

Ryan: And that access was restricted to just a handful of people. And then people would have to come to us with like a use case. And I think kind of the, the old school. Model of it was, uh, of data was that it was like an it function. And then it’s like a ticket, like, it’s not a value add. This is like a cost center type thing.

Ryan: And people will come with requests and we’re a modern data driven business. We should be able to answer them. And it’s like, okay, well. Putting that mess to the side. Um, people kind of had this situation where it’s like, okay, well, this is my one bite at the apple. So I’m going to ask for everything for all time and all the columns.

Ryan: Cause if I have to come back to you again, I’m going to have to wait in line with another ticket. And I think that mentality just like continued. People are so used to this, like [00:20:00] very. I, I personally view this like kind of old

school, like manufacturing, waterfall, IT cost center mindset, you know, of like, I only get one bite at the Apple.

Ryan: So I’m going to try to get everything that I can so I can do my job in the future without needing to interface with other people,

Ryan: um, which kind of speaks to like a deeper breakdown of how some organizations view, view data and probably, you know, even it and and

Seth: Yeah,

Ryan: those things, but,

Seth: yeah. They probably didn’t go through that exercise of

Seth: truly understanding the needs of the business. And then the business doesn’t always know what questions to ask, right? They’re there, they’ll ask for broad, uh, uh, sets of data where they’ll ask for things that are ambiguous, but then you have to work with them to really deconstruct, but what are you really trying to do?

Seth: Right. Maybe you don’t need all that. Let’s, let’s

Seth: talk about that. I found was when somebody wanted something like that, it’s because they were hiding like a manual process under the hood somewhere. And I was like, hold on, why don’t we just make your life easier? Why don’t I just like automate you something that [00:21:00] shows up on your desktop every morning? Like you can do that.

Ryan: And it’s like, all right, now, now you got to convert, you know?

Seth: don’t know what’s possible.

Ryan: Uh, Yeah. Yeah. So when we were talking at the tail end of the spreadsheets, you, you mentioned it in a way that once again, kind of gave me clarity. You, You were basically saying, Okay, well, we know that we’re doing this. We’re just doing it in the enterprise way that we’re trying to do.

Ryan: Everything else. And that, that hit home for me, right? I obviously had to have my little therapy session there about the Excel spreadsheets, but, um, that really hit home for me, right? Like this information architecture stuff, data strategy, this is stuff that is happening withi

it to or not, we’re just going to try to take an enterprise approach to it, and we’re going to try and tie it to our business strategy so that we can realize ROI.

Seth: Yeah. And, and the downside of that, you know, when you have a large [00:22:00] organization is you start to think it’s scope creep, you start to think you’re trying to boil the ocean, but there’s a way that can be, that can, uh, uh, that this can be done where you’re, you’re not getting too granular. And it doesn’t mean that everybody needs to do the same thing.

Seth: Right. It doesn’t mean

Seth: that. You, everybody uses the same taxonomy, for example, right? There are different, there may be a product hierarchy for retailers and for the, for the retail market, for, for consumers and another hierarchy for, uh, for brand managers, for example, right? It doesn’t mean everybody has the same thing,

Seth: uh, but you have to be intentional about the differences.

Seth: The point here is you’re trying to have a reference point for the most critical things, the most common elements across the organization. So, you know, you don’t necessarily want to do a big. top down master data project, but you want to be able to harmonize those use cases and, uh, those, the data architecture decisions that are made at the departmental or business process level.

Seth: And you want to be able to at least have a [00:23:00] coherent framework for integrating that. So a lot of times we did this at a large insurance company and whenever people had a new project, the gating factor was what are you going to use for your Your data architecture and your information architecture. What are you going to use for taxonomies?

Seth: And then if they were saying, well, we’re going to start with a clean sheet. It’s like, no, step back in it. Let’s look at what you really need to do. Don’t need to start with a clean sheet. Or if you do need to start with a clean sheet, there still has to be connections to the larger picture.

Seth: So there’s a way of balancing that so that it doesn’t

Seth: become

Ryan: yeah. I love that because that’s, I mean, I think particularly in my space, so my company, we focus a lot on, uh, the faucet that all of this stuff comes out to the end user end, right? With, with business intelligence and reporting and,

uh, There is this kind of like narrative of the, you know, quarter, half, three quarter million dollar infrastructure [00:24:00] project that like, you know, doesn’t get finished, you know, at, you know, whatever, right. You get like a quarter or two and some new executive comes in and it’s like, we’re paying how much for what?

Ryan: Like, you know, um, it’s, I, I, Focus really, really heavily on exactly what you talked about. Like, what is the use case? How does that tie to the business strategy? How are we going to use this to realize ROI? And then what’s the 20 percent that’ll get us 80 percent of the way? Like, let’s start realizing that return on investment as quickly as possible.

Ryan: Doesn’t mean infrastructure is bad, but it also doesn’t mean infrastructure is good. And we should just like dump all of our money into it. Right. It’s a balancing act. It’s a tool. Um, You know, I don’t need to start buying up Home Depot locations cause I want to be a contractor. Um,

Seth: the punishment

Seth: fit the crime.

Ryan: yeah, I like that.

Ryan: Yeah. So one of the things that anybody who reads your stuff hears about a lot [00:25:00] is a knowledge graph. And I think it’s a really cool concept to get shared with the audience. So can you tell us a little bit about like, what is a knowledge graph and what’s the use case? Um,

Seth: Sure. So. The idea of a knowledge graph is a mechanism to connect together lots of different data sources and many times unstructured content with structured data. And the way it does that is by sharing attributes. So when you, you begin, everything in my mind begins with a, a descriptor, uh, of, of something.

Seth: And, and again, what are your products? It’s the isness. This is a product, uh, sheet or a specification sheet. What is it about? What’s about this particular product? And then when you have a thousand of those things in a pile, How do you tell them apart? That’s the aboutness. If I have a thousand contracts, what kinds of contracts are there?

Seth: What piles would I put them in? Well, this is a work [00:26:00] order type of a contract. This is the real estate contract. This is an employment contract. And then what are the other details that will identify those? So when we start

thinking about. All the different buckets, that domain model I mentioned, the big picture organizing principles.

Seth: What we can do is start defining the relationships between them. So we start off with the vocabularies that define that entity. And then when you start saying, well, what are the services, if we have a services hierarchy or, or list and a product, What are the services that go along with this product, right, in order to install, in order to, what are the support materials that also can be used for this product installation?

Seth: For example, if I have an individual role, what are the interests of that role? If I have, uh, any type of, uh, say an industrial product, uh, what are the environments in which that industrial product will work? And, and what happens is you’re creating the, this relationship between. All the different taxonomies [00:27:00] that describe the different big picture, right, buckets and the relationships between them.

Seth: So an insurance company might have regions and they may have risks and then they’ll have risks in a region. So that’s called an associative relationship. It’s part of a thesaurus. It’s a C also in the back of the book index, right? Why do you want to see it? You want to see this particular aspect, right?

Seth: It’s a, it’s a, it’s a very finely defined C also. Okay. So again, why do you want to see it? You want to see it because these are products and these are the services I might need, or here are our solutions. for this particular problem. And what you’re doing is you’re building this knowledge scaffolding.

Seth: You’re building these, these big buckets of information, the details behind them. And then you’re building the relationships amongst those elements. And what this means is that you have the ability to come into. A data source, and you can do things like faceted search, right? Which is a typical [00:28:00] kind of example where you’re saying, well, again, if you walked into a, uh, Home Depot and said tools to the guy behind the counter, you’d say, well, what kind of tools do you want?

Seth: One

Seth: hand tool, power tools, right? And so that’s giving you those dimensions. of what that information is. And, and, and what you can also do is use it for product recommendations, right? You can start to say, well, what are the types of, of, of products that are appropriate for this individual with these characteristics?

Seth: If somebody’s wearing a painter’s hat and they are, or they have a hat and it says Joe’s painting and they have splatter all over them. You can infer that they want painting supplies, right? And so what you’re doing is you’re saying, based on the characteristics of this individual, I think they’re going to be interested in these things.

Seth: When we map those things

Seth: together, we can use it for stuff like product recommendations. We can use it to put context into When we’re asking questions [00:29:00] of a chatbot. And what happens is when we, we, what we’re building, when we build those relationships between those big buckets, those big organizing principles, that’s essentially an ontology, right?

Seth: A taxonomy. is a hierarchy, a list of parent and child type of relationships, whole part, you know, Massachusetts, Boston is a city in Massachusetts, which is a state in the United States. So there’s that parent child, whole part relationship. And then we have equivalence terms, which are, you know, uh, uh, uh, Boston is called bean town, right?

Seth: And then you have associations, right? You know, the freedom trail and other types of things are related to that city of Boston. When you have all those taxonomies and all those relationships between them, you have an ontology and ontology describes the domain of your world. So if you’re a pharmaceutical company, it’s drugs and generic drugs and chemical compounds and mechanisms of action and, uh, [00:30:00] and cellular targets or biochemical targets, processes, all of those things.

Seth: That describes your world of pharmaceuticals. That’s the ontology. Then when you add the data to that, when you let that ontology be the, the infrastructure, the scaffolding for the organization, and then you have the data, now you have a knowledge graph.

Seth: Now you can use those relationships that you define to get to specific information.

Seth: IMDB, right? The movie database is an on, is a knowledge graph because you say, who are the actors that were in this movie? Okay, what other movies were they in? All right. Who are the directors? Okay. What other movies did they direct? What other actors? That’s how you play Six Degrees

Seth: and Kevin Bacon. Yeah. So, I had a secret motivation for asking you about knowledge graphs. Um, Anybody who is listening to that would know,

you know, that you definitely have some experience with product information, right? So I know that that was a big part [00:31:00] of, um, your business for a while, but now that, um, you know, AI is, you know, big in pop culture, um, and a lot of people are talking about it.

Ryan: It just so happens that the things that you described right there are kind of a prerequisite for. AI doing anything meaningful within an organization, like going from any type of kind of very generalist, generative AI into something that can really effectively and accurately answer questions about a specific domain or specific company, it requires what you’re talking about.

Ryan: So tell me a little bit about that.

Seth: I don’t want to explain how LLMs work, uh, but I want to explain how. LLMs interpret the query and then they interpret the results to make them more conversational.

Seth: In between, we can retrieve from a knowledge source or a data source in the organization. That’s what’s [00:32:00] called Retrieval Augmented Generation. And what’s really important about that is it Reduces the likelihood of hallucinations when you are going from a, and the beauty of LLMs is not necessarily asking them for the answer.

Seth: Uh, even though the LLM contains a representation of knowledge and an understanding of concepts and relationships, what you really want the LLM to do is make the question and the answer conversational. But use the organization’s knowledge. Use the organization’s data source. So the things I talked about in terms of knowledge graphs, knowledge graphs provide additional signals for the LLM.

Seth: They provide the reference point, the context. When you add metadata to your content and ingest it into an LLM, those become additional signals. for that mathematical representation of the knowledge and it increases the accuracy. We did this with a pharmaceutical customer and we found that with that [00:33:00] metadata representation, that isness and aboutness, that data architecture, that content architecture, we went from 53% Accuracy to 83 percent accuracy by

Seth: including the metadata.

Seth: So the metadata provides context. It provides context for who the user is,

Seth: right? Because just like, you know, uh, uh, who, what, you know, what role are you playing? Oh, I’m a painter. Therefore you need painting supplies,

right? And being able to represent. Those different roles in the organization with those associated attributes.

Seth: That’s a, that’s an employee data model or a customer data model. And then what you’re doing is you’re using that to provide context for the retrieval of information. And that is the knowledge architecture knowledge model.

Seth: And so again, what an L, what a, what a knowledge graph does is it has Uh, the, the, uh, the representation of all of those entities, of the products, of the content, of the users, of the processes, [00:34:00] and that allows you to more precisely leverage the LLM, the chat GPT type of AI application for getting at your corporate

Seth: content. that’s, that is super cool. Now, all this and more Seth puts the knowledge that he’s acquired over a long time and a lot of places and makes it pretty freely accessible to a lot of people. So Thank you. before we get into telling everybody where they can connect with you, I want to give everybody the opportunity to know who they’re connecting with a little bit.

Ryan: Tell me a little bit about. You know, who is Seth outside of work?

Seth: Sure. So I, um, Uh, I have been a big, uh, um, fan of, of physical activity. I, I, uh, work out and do, uh, bootcamps. I also like, um, Martial arts. I, I, I do, [00:35:00] uh, that’s my, uh, black belt certificate on the back of the, on the wall there. Um, and I’ve been doing a Shotokan, uh, for about 40 years. In fact, I have a video of myself 40 years ago, and I wanted to put up a current version of that at some point.

Seth: Uh, but I’ve also recently started to do Aikido, which is a lot of fun. Uh, so a lot of, um, You know, bootcamp, uh, martial arts, those types of things. At my age, it’s, it’s a little bit tougher because you can’t go as hard as you used to. And,

Ryan: Yeah

Seth: and I, and I forget my physical limitations, but,

Seth: uh, but it is what it I don’t know, dude. I bet you can still beat me up.

Seth: Let’s not, let’s not, let’s not, let’s try to avoid, uh, Getting into that space

Seth: where we need to prove that we’re Yeah. Here’s, here’s open. Um, I love it.

Seth: I also have some animals. I have three dogs,

Seth: which are [00:36:00] Havanese, and they’re wonderful and lots of energy. And I have two cats, which are Bengals. And it’s very cute to see the Havanese and the Bengals play together.

Seth: And Sabrina loves Simon and he’s, that’s his, that’s her buddy. And you know, it’s just really great to watch them

Seth: all together. So that’s a lot of fun. And then my wife likes, and I like to travel. Uh, and we also have a, what’s called a Thundercat, um, boat, which is a small, uh, Racing catamaran. Um, uh, it’s about a 14 foot boat, but if you look at ThunderCat racing, uh, online, you’ll see these things in the water.

Seth: I did a little bit of racing, but that’s not my space. I, uh, I was competing with two guys who were the, uh, National Motorcycle Racing Champions.

Seth: Let’s just say they’re a little too aggressive for me, right? Invincible, I’m

Seth: not that’s that’s pretty wild. I love it. So tell everybody where they can learn more. I mean, you dropped the seeds of entire fields of knowledge here. So where [00:37:00] can people learn more about your connect with you?

Seth: Sure. Well, uh, go to www dot early, and that’s E-A-R-L-E-Y. Don’t forget the e Before the YI should have bought the early.com domain, E-A-R-L-Y and I probably would’ve gotten more traffic, but E-A-R-L-E-Y uh, dot com. You can also connect with me on LinkedIn. I’m just Seth early. Uh, uh, just one word, E-A-R-L-E-Y.

Seth: Um, I’m also, uh, I, I have more personal stuff on Instagram, but that’s Seth Doley. Uh, I a little bit on Facebook, but not too much. But, uh, really LinkedIn and the website. Uh, and you can always send me a note, Seth, that early.com if you wanna talk shop or, or catch up. We’re, we’re happy to answer any more questions

Seth: and, uh, for folks. I also will recommend, I mean, the website is a great place to get linked out to both of these things, but if any of the knowledge architecture stuff was interesting to anybody, I would recommend, uh, Seth’s book. And he also puts [00:38:00] on a lot of cool seminars, um, where he’ll bring in. That’s right. Yeah.

Ryan: He also does podcasts of course. Um, but I would recommend going to Seth’s seminars. I try to attend every single one that I’m available for. Yes. Here’s the book.

Seth: There’s the book

Ryan: powered enterprise.

Seth: then, um, yeah, the webinars, uh, you’ll find about out of those, uh, on the website, the podcasts.

Seth: Uh, and then I do some speaking, uh, you know, some, uh, public speaking, some conferences, some keynotes.

Seth: I do, uh, paid

Ryan: You’re all over,

Seth: organizations. So yeah, I’m, I’m starting to slow down a little bit. So

Seth: there’s a lot on the table.

Ryan: you’ve, earned it, man. You’ve put a lot out into the world for other people to eat.

Seth: I write for MS wire for, uh, customer Think magazine. Uh, anyway, so lots of stuff.

Ryan: Awesome, man. Awesome. Thank you, Seth, so much.

Seth: Oh, you’re welcome. It’s been a pleasure. Thanks for

Seth: having me. it really was. This flowed. It was so easy. It was so much fun getting to pick [00:39:00] your brain. And it’s knowledge that I think is more interesting and useful than ever. Even though I, you know, to you, old bottle in an, uh, old wine in a new bottle. Um, thank you to the audience.

Ryan: If you guys learned something today, please tell someone about the podcast. Thank you, Seth. Again, thanks. And this has been another exciting episode of Making Better Decisions. [00:40:00]