Knowledge Graph
Knowledge Graph
What is a knowledge graph?
- A knowledge network linking entities and relationships
- Improves search, recommendations, and AI understanding
- Also used to reduce hallucinations
Once a knowledge graph is in place, the unit you work with changes from 'documents' to 'entities.' Type 'instructors who taught last year's leadership course' into the company search bar, and a conventional system finds files containing that sentence and hands you ten or so. With a knowledge graph, it finds the entity 'instructor' directly and answers in one line, with affiliation, history, and course ratings attached. What you search for shifts from files to the facts themselves. That is the first thing teams notice in practice, and it is what produces the same answer no matter who asks.
There are two main ways to build one. RDF triples record a fact in three slots, 'subject-predicate-object,' which suits standardization and linking to external data. Property graphs (LPG) let you attach properties to nodes and relationships, which makes them easier to connect to internal systems. Either way, without a schema that defines the relationship types in advance, you get scribbles, not a graph. You also need to tell it apart from vector search. Vectors find 'similar things' while a graph follows 'connected things,' so questions with overlapping conditions, such as 'courses that every executive in our division has completed,' cannot be answered accurately by vectors alone.
You can start smaller than you might think. With 5 to 10 node types and around 15 relationship types, a good share of internal Q&A already works. The real burden is not the cost of building but the cost of maintaining, because a single reorganization can throw hundreds of 'belongs to' relationships out of date at once. Unless you first put in place a pipeline that syncs automatically from source systems such as HR and the LMS, six months later you will be left with a graph nobody opens.
The most common failure points in practice are duplicate names and near-identical names. If three people are named 'Minsu Kim, Team Lead' and 'AI Basics' and 'AI Intro' are effectively the same course but enter as separate nodes, the graph quietly gives wrong answers with no error message. Once connected to an LLM, those wrong facts get wrapped in fluent prose and end up in an executive report as is. The belief that more nodes make a better graph is the most dangerous one. In reality, cleanup work to merge duplicate entities takes half of the build effort.
John KimInstructor John Kim, author of B2B Marketing Design and CEO of Nanum Consulting
Seolyeong ParkGenerative AI and AX training specialist with 17 years of hands-on experience and 200+ lectures, helping non-technical staff put AI to work right awayRooted in Semantic Web research, it became widely known when Google introduced its 'Knowledge Graph' into search in 2012.
Let's look at a hypothetical case. Company A, an auto parts manufacturer with 1,400 employees, had its training records scattered across an LMS, department spreadsheets, and email approval folders. Pulling a roster of 'production engineers who completed last year's smart factory course' alone took two and a half days, and every promotion-review season, HR and the business units showed up with different numbers. This is a record of how they built an internal knowledge graph over four months.
- It started when Ms. Lee, a senior manager on the HR team, said, 'Everyone has a different spreadsheet, so I don't know whose numbers are right.' The first two weeks went to hunting down the seven source systems that held the training data.
- We cut the node types down to five (person, department, course, job role, certification) and kept only 12 relationship types, such as 'completes,' 'requires,' and 'belongs to.' The first draft had 30, and we rolled it back.
- Consolidating 1,830 course-name variants into 420 took six weeks. Park, an assistant manager in training operations, checked them one by one to confirm that 'AI Basics,' 'AI Intro,' and 'Ai Basics (Repeat)' were all the same course.
- We linked the LMS and the HR system through a nightly batch that syncs every day at 3 a.m., and once a reorganization is confirmed, 'belongs to' relationships update automatically.
- Pulling a roster that used to take two and a half days now takes 30 seconds, and for the first time, all 312 employees who had not completed their role-required courses appeared on a single screen. Objections to promotion-review data dropped from 27 a year to 3.