A chatbot can produce a plausible answer without checking whether it is true. A knowledge graph gives it structured facts to consult instead. It stores knowledge as relationships between concepts: entities are nodes, and relationships are edges. A collection of those connections can support questions that require more than a single fact. section 10.2.3 section 11.0
Start with a sentence stating that Stanislav Petrov was a lieutenant colonel. Its compact representation is the triple `(Stanislav Petrov, is-a, lieutenant colonel)`: a subject, a relationship, and an object. Triples in this form can be stored in files or databases; they do not require a particular graph database. When represented according to the RDF standard, they are called RDF triples. section 11.7
Why connect the facts?
Suppose someone asks, “What was Stanislav Petrov’s military rank?” The first triple alone does not establish that lieutenant colonel is a military rank. Connect that title to the concept *military rank*, and a query can follow both relationships to answer. Deriving an answer across such connections is knowledge graph inference. It depends on the necessary background facts already being present. section 11.8
Figure 11.4 Stanislav’s knowledge graph
The diagram makes the extra connection needed for the military-rank answer visible. section 11.8
A practical path from text to a usable graph is:
- Identify entities and extract their relationships from sentences. Rule-based patterns and neural methods are both options; part-of-speech tagging and dependency parsing help expose relationships. section 11.11
- Store each extracted fact as a triple, adding entities and connections as needed. Keep names consistent so the same entity or relationship can be queried reliably. section 11.0 section 11.8.1
- Query connected facts to answer questions. SPARQL, Cypher, GraphQL, and SQL are named options; questions spanning several relationships require the relevant facts to be available. section 11.0 section 11.8
Inspecting a larger graph
NELL provides a less tidy example than a hand-written triple. Its data has one row per triple, with columns such as `entity`, `relation`, and `value`. The Python utilities `read_nell_tsv` and `simplify_names` turn a sample into rows such as `limited_brands | ceo | leslie_wexner`. Simplifying names makes the graph easier to inspect, while consistent identifiers make its facts easier to query. NELL also shows why extracted knowledge needs care: wording and spelling can vary, and some displayed facts carry probability values rather than certainty. section 11.8.1
For a generative chatbot, graph facts can help check an answer before it is delivered. A claim absent from the graph may be off topic or incorrect, but absence alone does not establish which: the graph may lack needed knowledge. Building and validating one takes work. When extracting a graph is impractical, retrieving relevant text for the prompt is another grounding approach. section 12.4 section 10.2.3
