Sign in to continue learning
Knowledge Graphs for AI Agent: API Discovery
Intermediate
1 hour 14 mins
Topics
Agents
Embeddings
Search and Retrieval
Vector Databases
In this lesson, you will learn what knowledge graphs are, various methods to construct them, and how they enable AI agents with better API discovery and execution in the context of enterprise applications. Let's dive in. In order to see how knowledge graphs are used in practice, let's do a quick web search. Let's search for SAP. What do you see as part of the result? Besides the list of matching websites, You'll see a comprehensive overview of this entity SAP drawn from a knowledge graph. Here you will see properties such as the description, link to a website, also relations to other entities such as the headquarters being Walldorf. Clicking on Walldorf leads you to the corresponding knowledge graph entry for Walldorf, where again you will see a list of properties such as description and relations to other entities, for example, the region that it's related to, Karlsruhe. Now that you've seen how knowledge graphs are used in practice, let's dive a bit deeper to understand their technical foundations. A knowledge graph represents structured information in the form of a graph where nodes represent entities and edges represent relationships between these entities. There are two main components of knowledge graphs. First, the schema or ontology, which defines the types of entities, their attributes, and relationships between the entities which occur in the knowledge graph. Second, the instance data, which are the instances that form the graph and follow the definitions of the schema. In general, there are two main approaches to represent knowledge graphs. labeled property graphs and the Resource Description Framework or RDF. While both of them model entities and relationships, they differ in their structure, expressiveness, and intended use cases. In this course, we will use RDF as a graph-based data model to represent knowledge graphs. The Resource Description Framework is a graph-based data model standardized by the Worldwide Web Consortium, in short, the W3C. RDF does not enforce a schema, which makes it flexible and easy to integrate data from heterogeneous data sources. SPARQL is the standard query language for RDF with well-defined semantics, similar to SQL for the relational data model. The atomic building block of RDF are triples. A triple consists of a subject, a predicate, and an object. Each triple can be represented as labeled directed edges in an RDF graph. For instance, the shown edges represent the fact that SAP is located in Walldorf. Now that you understand the fundamental elements of RDF graphs, let's take a look at an example knowledge graph similar to the one which was shown in our web search experiment previously. We first start with a node that represents SAP. In RDF, unique resource identifiers or URIs are used to uniquely identify resources in the graph. We can add attributes to the SAP instance, such as the year when it was founded, its name, and state that it's a company. Attribute values in RDF are so-called literal values. We can further expand the graph and link SAP to other nodes in the graph, such as Christian Klein as the CEO and Walldorf as a city of its headquarters location. One advantage of knowledge graphs is the ability to infer facts which are not explicitly stated in the data that can be derived from the definitions in the ontology. For instance, by defining located in as a transitive relationship, we can then infer that SAP is located in Germany. RDF graphs are usually serialized in a machine-readable format such as N-Triples or Turtle files as shown here. An example triple in this file indicates that SAP CEO is Christian Klein. There are various methods to construct knowledge graphs. You can use structured sources. Here you have a fixed schema where entities of the same type or class are described with the same attributes as in the case of relational databases. Here you will use mapping rules such as R2RML. You can also use semi-structured sources. Here you will have a flexible schema where entities of the same type or class may be described differently like XML documents. Here again, we use mapping rules to construct knowledge graphs. Of course, you could use Unstructured Sources in the knowledge graph. Here you do not have a fixed schema at all. For example, natural language text or images. NLP Techniques may be used to construct knowledge graphs from such data sources. In this course, you will work with Structured Sources to construct a sample knowledge graph. Here's a high level overview on the knowledge graph construction process. In step zero, you define the use case, the scope and the business questions that are needed to be answered by the graph, which triggers what metadata to extract, what to model, and so on. In step one, you begin by gathering data from across your enterprise ecosystem, which forms the foundation of the knowledge graph. The foundation stage is where you connect various systems and extract their valuable business data. Each source system speaks its own language and organizes data differently. For example, CSV, XML, JSON, and others. In step two, you analyze and standardize your data to ensure its knowledge graph ready. Think of it as translating different dialects into a common language, identifying duplicate information, resolving inconsistencies and validating data quality, all to ensure that knowledge graph is built on a solid foundation of trustworthy information. In step three, data modeling is where the magic happens. Here you convert the clean data into standardized RDF triples. Each piece of business information is represented as subject, predicate, object statements that directly mirror the relationships in the relevant underlying systems. And finally, in step four is where you leverage the connected nature of knowledge graphs to deliver value. These aren't just representations of the source systems. They're new connections, analysis, and insights derived from source metadata as an interconnected whole. Now that you know what a knowledge graph is and various methods to construct it, let's look at an example on how you can use knowledge graphs with AI agents in an enterprise context. Suppose you have a user request to create a purchase order for five pencils in purchasing group 002 and purchasing organization 3000 and want an AI agent to fulfill this request. Without any context, this is not a trivial task for the agent since the enterprise system landscape can be very complex with several thousand different APIs that might be relevant. Hence, we construct a knowledge graph of the APIs in the system landscape and enrich it with business process information to provide the right context to the agent to fulfill the user request. In large enterprise environments with complex evolving APIs, AI Agents face several challenges. Number one. LLMs often spend a lot of time and tokens just trying to discover the right API. It's a trial and error process that can slow things down significantly. Knowledge graphs help by organizing APIs around business processes and objects. This narrows down the search space, makes planning more efficient, reduces unnecessary replanning, and speeds up execution overall. Number two. While LLMs and retrieval-based systems like RAG are great at pulling relevant content, they often miss the deeper structure and context, especially when it comes to domain-specific logic or API metadata. Knowledge graphs bring that missing context. Because they are structured and semantically rich, they reflect the relationships between APIs, business processes and data models. This makes them especially helpful for grounding responses and avoiding hallucinations. particularly in dynamic or customized business environments. Number three, for simple read operations, LLMs usually cope well. But when tasks get more complex, like executing a series of API calls in the right order or understanding allowed fixed values, they start to struggle. Knowledge graphs offer a built-in structure that maps these dependencies and sequences, guiding the agents step-by-step and reducing the chances of error. And number four, AI agents typically generate answers based on learned patterns or retrieved snippets, but they rarely provide visibility into how they got there. That makes it hard to explain results or trace them back to source logic, especially when the same query returns different results. Knowledge graphs change that by making reasoning transparent. You can trace exactly which APIs were used with what filters, what the system returned, what was the source system, and so on. These are capabilities in enterprise settings where trust, auditability, and reproducibility are non-negotiable.
