Spaces:
Runtime error
Runtime error
Sébastien De Greef
commited on
Commit
·
58a7650
1
Parent(s):
e7d446c
Initial Commit
Browse files- src/GraphLevis.PNG +0 -0
- src/GraphMichelin.PNG +0 -0
- src/GraphScania.PNG +0 -0
- src/_quarto.yml +27 -23
- src/about.qmd +0 -5
- src/content_extraction.webp +0 -0
- src/document_extraction.webp +0 -0
- src/example_outputs.qmd +6 -0
- src/index.qmd +190 -78
- src/knowledge_supply_chain.webp +0 -0
- src/llm_formats.qmd +148 -0
- src/llm_generate_dataset.qmd +146 -0
- src/llm_knowledge.qmd +92 -0
- src/llm_query.qmd +160 -0
- src/llm_supply_chains.qmd +188 -0
src/GraphLevis.PNG
ADDED
src/GraphMichelin.PNG
ADDED
src/GraphScania.PNG
ADDED
src/_quarto.yml
CHANGED
@@ -1,37 +1,41 @@
|
|
1 |
project:
|
2 |
type: website
|
3 |
website:
|
4 |
-
title: "
|
|
|
|
|
|
|
|
|
|
|
|
|
5 |
sidebar:
|
6 |
-
style: "
|
7 |
search: true
|
|
|
|
|
|
|
8 |
collapse-level: 3
|
9 |
contents:
|
10 |
-
- section: "
|
11 |
contents:
|
12 |
- href: index.qmd
|
13 |
-
text:
|
14 |
-
|
15 |
-
|
16 |
-
|
17 |
-
|
18 |
-
|
19 |
-
|
20 |
-
|
21 |
-
|
22 |
-
|
23 |
-
|
24 |
-
|
25 |
-
|
26 |
-
|
27 |
-
text: "Automatic Embedding"
|
28 |
-
- href: notebooks/faiss.ipynb
|
29 |
-
text: "FAISS for Efficient Search"
|
30 |
-
- href: notebooks/single_gpu.ipynb
|
31 |
-
text: "Single GPU Optimization"
|
32 |
|
33 |
format:
|
34 |
html:
|
35 |
-
theme:
|
36 |
css: styles.css
|
37 |
toc: true
|
|
|
1 |
project:
|
2 |
type: website
|
3 |
website:
|
4 |
+
title: "Graphs, RAGs and Knowledge Extraction"
|
5 |
+
page-footer:
|
6 |
+
center:
|
7 |
+
- text: "Index"
|
8 |
+
href: index.qmd
|
9 |
+
- icon: linkedin
|
10 |
+
href: https://www.linkedin.com/in/sebdg/
|
11 |
sidebar:
|
12 |
+
style: "floating"
|
13 |
search: true
|
14 |
+
tools:
|
15 |
+
- icon: linkedin
|
16 |
+
href: https://www.linkedin.com/in/sebdg/
|
17 |
collapse-level: 3
|
18 |
contents:
|
19 |
+
- section: "Index"
|
20 |
contents:
|
21 |
- href: index.qmd
|
22 |
+
text: Who is What ?
|
23 |
+
- href: llm_knowledge.qmd
|
24 |
+
text: LLM Knowledge Extraction
|
25 |
+
- href: llm_query.qmd
|
26 |
+
text: LLM to Answer Queries
|
27 |
+
- href: llm_supply_chains.qmd
|
28 |
+
text: Use in Supply Chains
|
29 |
+
- href: llm_generate_dataset.qmd
|
30 |
+
text: Generate Fine-Tuned Dataset
|
31 |
+
- href: llm_formats.qmd
|
32 |
+
text: Formatting Fine-Tuned Dataset
|
33 |
+
- href: example_outputs.qmd
|
34 |
+
text: Example Outputs
|
35 |
+
|
|
|
|
|
|
|
|
|
|
|
36 |
|
37 |
format:
|
38 |
html:
|
39 |
+
theme: sketchy
|
40 |
css: styles.css
|
41 |
toc: true
|
src/about.qmd
DELETED
@@ -1,5 +0,0 @@
|
|
1 |
-
---
|
2 |
-
title: "About"
|
3 |
-
---
|
4 |
-
|
5 |
-
About this site
|
|
|
|
|
|
|
|
|
|
|
|
src/content_extraction.webp
ADDED
src/document_extraction.webp
ADDED
src/example_outputs.qmd
ADDED
@@ -0,0 +1,6 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
|
2 |
+
![Levis Strauss](GraphLevis.PNG)
|
3 |
+
|
4 |
+
![Michelin](GraphMichelin.PNG)
|
5 |
+
|
6 |
+
![Scania](GraphScania.PNG)
|
src/index.qmd
CHANGED
@@ -1,78 +1,190 @@
|
|
1 |
-
|
2 |
-
|
3 |
-
|
4 |
-
|
5 |
-
|
6 |
-
|
7 |
-
|
8 |
-
|
9 |
-
|
10 |
-
|
11 |
-
|
12 |
-
|
13 |
-
-
|
14 |
-
|
15 |
-
-
|
16 |
-
|
17 |
-
-
|
18 |
-
|
19 |
-
|
20 |
-
|
21 |
-
|
22 |
-
|
23 |
-
|
24 |
-
|
25 |
-
|
26 |
-
|
27 |
-
|
28 |
-
|
29 |
-
|
30 |
-
|
31 |
-
|
32 |
-
|
33 |
-
|
34 |
-
|
35 |
-
|
36 |
-
|
37 |
-
|
38 |
-
|
39 |
-
|
40 |
-
|
41 |
-
|
42 |
-
|
43 |
-
|
44 |
-
|
45 |
-
|
46 |
-
|
47 |
-
For example
|
48 |
-
|
49 |
-
|
50 |
-
|
51 |
-
|
52 |
-
|
53 |
-
|
54 |
-
|
55 |
-
|
56 |
-
|
57 |
-
|
58 |
-
|
59 |
-
|
60 |
-
|
61 |
-
|
62 |
-
|
63 |
-
|
64 |
-
|
65 |
-
|
66 |
-
|
67 |
-
|
68 |
-
|
69 |
-
|
70 |
-
|
71 |
-
|
72 |
-
|
73 |
-
|
74 |
-
|
75 |
-
|
76 |
-
|
77 |
-
|
78 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
|
2 |
+
## The Project
|
3 |
+
|
4 |
+
|
5 |
+
- **Collaboration Partners**: The project is developed in partnership with Windesheim University of Applied Sciences and the Supply Chain Finance research group.
|
6 |
+
|
7 |
+
- **Research Focus**: Investigating the efficient use of financial flows within supply chains and understanding the impact of these efficiencies.
|
8 |
+
|
9 |
+
- **Value Chain Hackers**: A dynamic living lab that serves as a platform for both schools and companies.
|
10 |
+
|
11 |
+
- **Innovation & Experimentation**: The lab facilitates experimentation with innovative supply chain solutions and realistic sustainability strategies.
|
12 |
+
|
13 |
+
- **Open Source**: The project, including all models and datasets, is open source and freely available.
|
14 |
+
|
15 |
+
- **More Information**: Additional details can be found on the website [https://valuechainhackers.xyz/](https://valuechainhackers.xyz/).
|
16 |
+
|
17 |
+
- **Open Invitation**: Encourages participation from individuals with ideas for improving the world and those interested in contributing to sustainable change.
|
18 |
+
|
19 |
+
### Key Takeaways:
|
20 |
+
|
21 |
+
- The project is a collaborative effort aimed at optimizing financial flows within supply chains.
|
22 |
+
- It emphasizes the importance of innovation and sustainability in supply chain management.
|
23 |
+
- Value Chain Hackers provides a practical environment for experimentation and collaboration.
|
24 |
+
- The project's models and datasets are open-sourced, encouraging transparency and wider participation.
|
25 |
+
- There is an open call for participation, inviting individuals and organizations to contribute to the development of sustainable supply chains.
|
26 |
+
- For more information, interested parties can visit [https://valuechainhackers.xyz/](https://valuechainhackers.xyz/).
|
27 |
+
### About the project
|
28 |
+
|
29 |
+
(https://valuechainhackers.xyz/)[https://valuechainhackers.xyz/]
|
30 |
+
|
31 |
+
GitHub repo : (https://github.com/Value-Chain-Hackers/KnopenKoning)[https://github.com/Value-Chain-Hackers/KnopenKoning]
|
32 |
+
|
33 |
+
Models: (https://huggingface.co/sebdg?search_models=scm)[https://huggingface.co/sebdg?search_models=scm]
|
34 |
+
Dataset: (https://huggingface.co/datasets/sebdg/ontologies_train_dataset)[https://huggingface.co/datasets/sebdg/ontologies_train_dataset]
|
35 |
+
Prompts: (https://github.com/Value-Chain-Hackers/KnopenKoning/tree/main/prompts)[https://github.com/Value-Chain-Hackers/KnopenKoning/tree/main/prompts]
|
36 |
+
|
37 |
+
### Who is What ?
|
38 |
+
|
39 |
+
**Knowledge Graphs** are structured representations of information that connect data points through relationships, enabling machines to understand and reason about the relationships between different concepts. They are used to integrate, organize, and retrieve information in a way that reflects the real-world interconnections of entities.
|
40 |
+
|
41 |
+
**Ontologies**, on the other hand, are formal frameworks that define the relationships and categories within a particular domain. They provide a shared vocabulary and a set of rules for how concepts are related, which is essential for ensuring that knowledge graphs accurately represent the domain they cover. Together, knowledge graphs and ontologies enable more effective data integration, retrieval, and reasoning.
|
42 |
+
|
43 |
+
**First-Order Logic**, also known as Predicate Logic, is a formal system used in mathematics, philosophy, computer science, and artificial intelligence to express statements and reason about them. It extends propositional logic by allowing the use of **quantifiers** and **predicates** to make more complex and expressive statements about objects and their relationships.
|
44 |
+
|
45 |
+
#### Key Components of First-Order Logic:
|
46 |
+
|
47 |
+
1. **Constants**: These represent specific objects in the domain of discourse. For example, in a domain of people, `John` and `Mary` could be constants.
|
48 |
+
|
49 |
+
2. **Variables**: These are symbols that can represent any object in the domain. For example, `x`, `y`, and `z` are variables that could represent any person in a domain.
|
50 |
+
|
51 |
+
3. **Predicates**: Predicates are functions that return true or false, depending on the values of the arguments they are applied to. They describe properties of objects or relationships between objects. For example, `Loves(John, Mary)` might mean "John loves Mary."
|
52 |
+
|
53 |
+
4. **Quantifiers**:
|
54 |
+
- **Universal Quantifier (`∀`)**: This denotes that a statement is true for all elements in the domain. For example, `∀x Loves(x, Mary)` means "Everyone loves Mary."
|
55 |
+
- **Existential Quantifier (`∃`)**: This denotes that there is at least one element in the domain for which the statement is true.
|
56 |
+
|
57 |
+
For example, `∃x Loves(John, x)` means "There is someone whom John loves."
|
58 |
+
|
59 |
+
5. **Functions**: These are mappings from one or more elements of the domain to another element.
|
60 |
+
|
61 |
+
For example, `MotherOf(x)` could be a function that returns the mother of `x`.
|
62 |
+
|
63 |
+
6. **Logical Connectives**:
|
64 |
+
These include `∧` (and), `∨` (or), `¬` (not), `→` (implies), and `↔` (if and only if), which are used to build more complex statements.
|
65 |
+
|
66 |
+
7. **Equality (`=`)**: This is a special predicate that asserts that two terms refer to the same object. For example, `John = Mary` would mean that John and Mary are the same person.
|
67 |
+
|
68 |
+
### Axioms
|
69 |
+
|
70 |
+
Axioms are statements or propositions in a logical system that are assumed to be true without proof.
|
71 |
+
They serve as the foundational building blocks from which other statements, called **theorems**, can be logically derived.
|
72 |
+
|
73 |
+
#### Types of Axioms:
|
74 |
+
|
75 |
+
1. **Logical Axioms**: These are tautologies, statements that are always true regardless of the interpretation of their components. For example, in propositional logic, a statement like `P ∨ ¬P` (the law of excluded middle) is a logical axiom.
|
76 |
+
|
77 |
+
2. **Non-Logical Axioms**: These are specific to the domain of discourse. In mathematics, these might be statements like "For any number x, x + 0 = x," which are not universally true but are true within the context of arithmetic.
|
78 |
+
|
79 |
+
3. **Axiomatic Systems**: A formal system can be built by defining a set of axioms along with inference rules. Theorems are then derived from these axioms using the rules of inference.
|
80 |
+
|
81 |
+
#### Role of Axioms in FOL:
|
82 |
+
In First-Order Logic, axioms are used to define the properties of the objects and relationships in the domain. For example, in a theory of arithmetic, axioms might define the properties of addition and multiplication. From these axioms, other properties can be derived.
|
83 |
+
|
84 |
+
Certainly! Let's create an example using the Harry Potter universe, applying First-Order Logic (FOL) with some axioms and statements about the characters and relationships in that world.
|
85 |
+
|
86 |
+
### Example Ontology in Harry Potter:
|
87 |
+
- **Domain**: The set of all people and magical creatures in the Harry Potter universe.
|
88 |
+
- **Constants**: `Harry`, `Voldemort`, `Dumbledore`, `Hogwarts`, `Hedwig`.
|
89 |
+
- **Variables**: `x`, `y`, `z`.
|
90 |
+
|
91 |
+
### Predicates:
|
92 |
+
- **Wizard(x)**: x is a wizard.
|
93 |
+
- **Witch(x)**: x is a witch.
|
94 |
+
- **Muggle(x)**: x is a muggle.
|
95 |
+
- **LoyalTo(x, y)**: x is loyal to y.
|
96 |
+
- **TeachesAt(x, y)**: x teaches at y (where y is a school).
|
97 |
+
- **EnemyOf(x, y)**: x is an enemy of y.
|
98 |
+
- **HasPet(x, y)**: x has a pet y.
|
99 |
+
- **Kills(x, y)**: x kills y.
|
100 |
+
|
101 |
+
### Functions:
|
102 |
+
- **MasterOf(x)**: Returns the person who is the master of x.
|
103 |
+
|
104 |
+
### Axioms:
|
105 |
+
Let's define some axioms that describe the relationships and rules in the Harry Potter universe.
|
106 |
+
|
107 |
+
**Axiom 1**: Every wizard is not a muggle.
|
108 |
+
$$\forall x (Wizard(x) \rightarrow \neg Muggle(x))$$
|
109 |
+
Example: "If Harry is a wizard, then Harry is not a muggle."
|
110 |
+
|
111 |
+
**Axiom 2**: Dumbledore is a wizard.
|
112 |
+
$$Wizard(Dumbledore)$$
|
113 |
+
This is a simple fact about Dumbledore.
|
114 |
+
|
115 |
+
**Axiom 3**: If someone teaches at Hogwarts, they must be a wizard or a witch.
|
116 |
+
$$\forall x \forall y (TeachesAt(x, Hogwarts) \rightarrow (Wizard(x) \vee Witch(x)))$$
|
117 |
+
Example: "If Dumbledore teaches at Hogwarts, then Dumbledore is either a wizard or a witch."
|
118 |
+
|
119 |
+
**Axiom 4**: Voldemort is an enemy of Harry.
|
120 |
+
$$EnemyOf(Voldemort, Harry)$$
|
121 |
+
|
122 |
+
**Axiom 5**: Harry is loyal to Dumbledore.
|
123 |
+
$$LoyalTo(Harry, Dumbledore)$$
|
124 |
+
|
125 |
+
**Axiom 6**: If someone is loyal to Dumbledore, they are not loyal to Voldemort.
|
126 |
+
$$\forall x (LoyalTo(x, Dumbledore) \rightarrow \neg LoyalTo(x, Voldemort))$$
|
127 |
+
Example: "If Harry is loyal to Dumbledore, then Harry is not loyal to Voldemort."
|
128 |
+
|
129 |
+
**Axiom 7**: If someone kills another, they are enemies.
|
130 |
+
$$\forall x \forall y (Kills(x, y) \rightarrow EnemyOf(x, y))$$
|
131 |
+
Example: "If Voldemort kills Harry's parents, then Voldemort is an enemy of Harry's parents."
|
132 |
+
|
133 |
+
**Axiom 8**: If someone is the master of a creature, that creature is loyal to them.
|
134 |
+
$$\forall x \forall y (y = MasterOf(x) \rightarrow LoyalTo(x, y))$$
|
135 |
+
Example: "If Voldemort is the master of Nagini, then Nagini is loyal to Voldemort."
|
136 |
+
|
137 |
+
**Axiom 9**: Harry has a pet, Hedwig.
|
138 |
+
$$HasPet(Harry, Hedwig)$$
|
139 |
+
|
140 |
+
**Axiom 10**: If a wizard has a pet, that pet is not a muggle.
|
141 |
+
$$\forall x \forall y (Wizard(x) \wedge HasPet(x, y) \rightarrow \neg Muggle(y))$$
|
142 |
+
Example: "If Harry is a wizard and has a pet Hedwig, then Hedwig is not a muggle."
|
143 |
+
|
144 |
+
### Example Statements and Inferences:
|
145 |
+
|
146 |
+
Using these axioms, we can make various statements and derive inferences:
|
147 |
+
|
148 |
+
1. **Statement**: `Wizard(Harry)`
|
149 |
+
- Harry is a wizard.
|
150 |
+
|
151 |
+
**Inference**: From Axiom 1 and the statement `Wizard(Harry)`, we can infer:
|
152 |
+
- `not Muggle(Harry)` (Harry is not a muggle).
|
153 |
+
|
154 |
+
3. **Statement**: `TeachesAt(Dumbledore, Hogwarts)`
|
155 |
+
- Dumbledore teaches at Hogwarts.
|
156 |
+
|
157 |
+
**Inference**: From Axiom 3 and the statement `TeachesAt(Dumbledore, Hogwarts)`, we can infer:
|
158 |
+
- `Wizard(Dumbledore) ∨ Witch(Dumbledore)` (Dumbledore is either a wizard or a witch).
|
159 |
+
|
160 |
+
5. **Statement**: `Kills(Voldemort, LilyPotter)`
|
161 |
+
- Voldemort kills Lily Potter.
|
162 |
+
|
163 |
+
**Inference**: From Axiom 7 and the statement `Kills(Voldemort, LilyPotter)`, we can infer:
|
164 |
+
- `EnemyOf(Voldemort, LilyPotter)` (Voldemort is an enemy of Lily Potter).
|
165 |
+
|
166 |
+
**Inference**: If `MasterOf(Nagini) = Voldemort`, then from Axiom 8:
|
167 |
+
- `LoyalTo(Nagini, Voldemort)` (Nagini is loyal to Voldemort).
|
168 |
+
|
169 |
+
**Inference**: From Axiom 5, `LoyalTo(Harry, Dumbledore)`, and Axiom 6, we infer:
|
170 |
+
- `not LoyalTo(Harry, Voldemort)` (Harry is not loyal to Voldemort).
|
171 |
+
|
172 |
+
### Summary
|
173 |
+
|
174 |
+
In this example, First-Order Logic is used to define relationships between characters, their roles, and events in the Harry Potter universe. Axioms establish basic truths, and logical reasoning allows us to derive new information based on these truths. This system is highly expressive and can be extended to include more characters, relationships, and events in the domain.
|
175 |
+
|
176 |
+
### Bullet Points:
|
177 |
+
|
178 |
+
- **Knowledge Graphs**: Structured representations that connect data points through relationships, helping machines understand and reason about these connections.
|
179 |
+
- **Ontologies**: Formal frameworks defining relationships and categories within a domain, providing a shared vocabulary for knowledge representation.
|
180 |
+
- **First-Order Logic (FOL)**: A formal system using constants, variables, predicates, quantifiers, functions, and logical connectives to express and reason about statements.
|
181 |
+
- **Key Components of FOL**: Includes constants, variables, predicates, quantifiers, functions, logical connectives, and equality.
|
182 |
+
- **Axioms**: Fundamental statements assumed to be true, used as building blocks for deriving theorems in logical systems.
|
183 |
+
- **Types of Axioms**: Logical axioms (always true) and non-logical axioms (domain-specific).
|
184 |
+
|
185 |
+
### Key Takeaways:
|
186 |
+
|
187 |
+
- Knowledge Graphs and Ontologies work together to organize and represent information in a structured way.
|
188 |
+
- First-Order Logic allows for complex reasoning about objects and their relationships.
|
189 |
+
- Axioms are essential for defining properties within a domain, enabling logical derivation of theorems.
|
190 |
+
- The Harry Potter example illustrates how FOL can be applied to create logical statements and make inferences within a fictional domain.
|
src/knowledge_supply_chain.webp
ADDED
src/llm_formats.qmd
ADDED
@@ -0,0 +1,148 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
Creating a fine-tuned dataset for an LLM (Large Language Model) to learn how to generate specific output formats like triplets, Turtle, or RDF involves several key steps. This process enables the model to understand and produce structured data according to the rules and formats required. Here’s a detailed guide on how to achieve this:
|
2 |
+
|
3 |
+
### **Understand the Output Formats**
|
4 |
+
|
5 |
+
Before creating the fine-tune dataset, it’s important to understand the output formats you want the model to learn:
|
6 |
+
|
7 |
+
#### **Triplets**
|
8 |
+
- A **triplet** is a simple data structure that consists of three parts: subject, predicate, and object. It’s commonly used to represent relationships in a Knowledge Graph.
|
9 |
+
- **Example**: (`Harry`, `belongsTo`, `Gryffindor`)
|
10 |
+
|
11 |
+
#### **Turtle**
|
12 |
+
- **Turtle** (Terse RDF Triple Language) is a syntax for writing RDF (Resource Description Framework) data in a compact and human-readable format.
|
13 |
+
- **Example**:
|
14 |
+
```turtle
|
15 |
+
:Harry :belongsTo :Gryffindor .
|
16 |
+
```
|
17 |
+
|
18 |
+
#### **RDF**
|
19 |
+
- **RDF** is a framework for representing information about resources on the web. It uses triplets to make statements about resources in the form of subject-predicate-object expressions.
|
20 |
+
- **Example**:
|
21 |
+
```rdf
|
22 |
+
<rdf:Description rdf:about="http://example.org/Harry">
|
23 |
+
<rdf:belongsTo rdf:resource="http://example.org/Gryffindor"/>
|
24 |
+
</rdf:Description>
|
25 |
+
```
|
26 |
+
|
27 |
+
### **Define the Rules for Output Generation**
|
28 |
+
|
29 |
+
The next step is to define the rules that govern how the data should be represented in these formats. These rules will guide the creation of the fine-tuning dataset.
|
30 |
+
|
31 |
+
#### **Rules for Triplets**
|
32 |
+
- **Format**: The subject, predicate, and object must be clearly defined.
|
33 |
+
- **Consistency**: Ensure that relationships (predicates) are used consistently across different subjects and objects.
|
34 |
+
- **Syntax**: Follow a consistent syntax, such as using parentheses or commas to separate components.
|
35 |
+
|
36 |
+
#### **Rules for Turtle**
|
37 |
+
- **Namespaces**: Define and use prefixes (e.g., `:`) to simplify URIs.
|
38 |
+
- **Syntax**: Ensure correct usage of punctuation (`.` to end statements, `;` to separate predicates for the same subject).
|
39 |
+
- **IRIs**: Use Internationalized Resource Identifiers (IRIs) to identify subjects, predicates, and objects.
|
40 |
+
|
41 |
+
#### **Rules for RDF**
|
42 |
+
- **XML Structure**: Follow RDF/XML syntax, ensuring that elements like `<rdf:Description>` and `<rdf:about>` are used correctly.
|
43 |
+
- **Namespaces**: Use appropriate namespaces for RDF elements.
|
44 |
+
- **Attributes**: Use attributes like `rdf:resource` to link resources.
|
45 |
+
|
46 |
+
### **Collect and Annotate Data**
|
47 |
+
|
48 |
+
Gather raw data that can be used to generate examples in the desired formats. This data could be in the form of natural language sentences, structured data, or existing ontologies.
|
49 |
+
|
50 |
+
#### **Annotation Process**
|
51 |
+
- **Triplets**: Convert raw data into triplets by identifying the subject, predicate, and object in each statement.
|
52 |
+
- **Example**: From "Harry belongs to Gryffindor," extract (`Harry`, `belongsTo`, `Gryffindor`).
|
53 |
+
|
54 |
+
- **Turtle**: Annotate the data in Turtle format, paying attention to the use of prefixes, IRIs, and syntax.
|
55 |
+
- **Example**: Convert the triplet into Turtle syntax:
|
56 |
+
```turtle
|
57 |
+
:Harry :belongsTo :Gryffindor .
|
58 |
+
```
|
59 |
+
|
60 |
+
- **RDF**: Annotate the data in RDF/XML, ensuring that the correct elements and attributes are used.
|
61 |
+
- **Example**: Convert the triplet into RDF/XML:
|
62 |
+
```rdf
|
63 |
+
<rdf:Description rdf:about="http://example.org/Harry">
|
64 |
+
<rdf:belongsTo rdf:resource="http://example.org/Gryffindor"/>
|
65 |
+
</rdf:Description>
|
66 |
+
```
|
67 |
+
|
68 |
+
### **Create Training Examples**
|
69 |
+
|
70 |
+
Develop a diverse set of training examples that cover the different scenarios and rules you’ve defined. Each example should include:
|
71 |
+
- **Input Data**: A natural language statement or structured input.
|
72 |
+
- **Expected Output**: The corresponding triplet, Turtle, or RDF format.
|
73 |
+
|
74 |
+
#### **Example Training Data**
|
75 |
+
|
76 |
+
**Input**: "Hermione is friends with Harry."
|
77 |
+
- **Triplet**: (`Hermione`, `isFriendOf`, `Harry`)
|
78 |
+
- **Turtle**:
|
79 |
+
```turtle
|
80 |
+
:Hermione :isFriendOf :Harry .
|
81 |
+
```
|
82 |
+
- **RDF**:
|
83 |
+
```rdf
|
84 |
+
<rdf:Description rdf:about="http://example.org/Hermione">
|
85 |
+
<rdf:isFriendOf rdf:resource="http://example.org/Harry"/>
|
86 |
+
</rdf:Description>
|
87 |
+
```
|
88 |
+
|
89 |
+
**Input**: "The Hogwarts library contains many books."
|
90 |
+
- **Triplet**: (`Hogwarts_Library`, `contains`, `Books`)
|
91 |
+
- **Turtle**:
|
92 |
+
```turtle
|
93 |
+
:Hogwarts_Library :contains :Books .
|
94 |
+
```
|
95 |
+
- **RDF**:
|
96 |
+
```rdf
|
97 |
+
<rdf:Description rdf:about="http://example.org/Hogwarts_Library">
|
98 |
+
<rdf:contains rdf:resource="http://example.org/Books"/>
|
99 |
+
</rdf:Description>
|
100 |
+
```
|
101 |
+
|
102 |
+
### **Augment the Dataset**
|
103 |
+
|
104 |
+
To improve the model’s ability to generalize, consider augmenting the dataset:
|
105 |
+
- **Diverse Examples**: Include examples with varying complexity, such as nested relationships or multiple predicates.
|
106 |
+
- **Negative Examples**: Provide incorrect examples to help the model learn what not to do, such as malformed RDF/XML or incorrect Turtle syntax.
|
107 |
+
|
108 |
+
### **Fine-Tune the Model**
|
109 |
+
|
110 |
+
Fine-tune the LLM using the dataset you’ve created. During fine-tuning:
|
111 |
+
- **Training**: Present the model with input data and the corresponding output formats, adjusting the model’s parameters to minimize errors.
|
112 |
+
- **Validation**: Use a validation set to ensure the model is learning correctly and not overfitting.
|
113 |
+
- **Testing**: Test the model on unseen examples to evaluate its ability to generalize to new data.
|
114 |
+
|
115 |
+
### **Evaluate and Refine the Model**
|
116 |
+
|
117 |
+
After fine-tuning, evaluate the model’s performance:
|
118 |
+
- **Accuracy**: Check how accurately the model generates the desired formats.
|
119 |
+
- **Compliance**: Ensure that the generated outputs comply with the defined rules for triplets, Turtle, and RDF.
|
120 |
+
- **Explainability**: Analyze whether the model’s outputs are logically consistent and understandable.
|
121 |
+
|
122 |
+
Based on the evaluation:
|
123 |
+
- **Refine the Dataset**: Add more examples or correct existing ones to improve accuracy.
|
124 |
+
- **Further Training**: Fine-tune the model further if necessary to enhance its performance.
|
125 |
+
|
126 |
+
### **Deploy and Monitor**
|
127 |
+
|
128 |
+
Deploy the fine-tuned model in real-world applications where it can generate triplets, Turtle, or RDF data from natural language or structured inputs. Monitor the model’s performance and gather feedback to make further improvements.
|
129 |
+
|
130 |
+
### Summary
|
131 |
+
|
132 |
+
Creating a fine-tune dataset for an LLM to learn how to generate output formats like triplets, Turtle, or RDF involves understanding these formats, defining rules, annotating data, and training the model with diverse examples. The process ensures that the model can accurately and consistently produce structured data according to the required formats, enabling it to be used in applications such as semantic web development, knowledge graph construction, and data integration tasks.
|
133 |
+
|
134 |
+
### Bullet Points:
|
135 |
+
|
136 |
+
- **Understand Output Formats**: Grasp the structure and rules of triplets, Turtle, and RDF to guide the dataset creation.
|
137 |
+
- **Define Rules**: Establish consistent rules for generating data in triplet, Turtle, and RDF formats, including syntax and structure.
|
138 |
+
- **Data Annotation**: Convert raw data into annotated examples for each format, ensuring accuracy and consistency.
|
139 |
+
- **Create Training Examples**: Develop diverse examples covering different scenarios, including both correct and incorrect formats.
|
140 |
+
- **Fine-Tune the Model**: Train the LLM using the annotated dataset, validate performance, and refine as needed.
|
141 |
+
- **Evaluate and Refine**: Assess the model's accuracy and compliance with rules, refining the dataset and training further if necessary.
|
142 |
+
- **Deploy and Monitor**: Implement the model in real-world applications, monitor its performance, and gather feedback for improvements.
|
143 |
+
|
144 |
+
### Key Takeaways:
|
145 |
+
|
146 |
+
- Understanding and defining the structure of the desired output formats is crucial for creating an effective fine-tuning dataset.
|
147 |
+
- Annotation and diverse training examples ensure the model learns to generate accurate and compliant outputs.
|
148 |
+
- Continuous evaluation and refinement are essential for improving the model’s performance in generating structured data.
|
src/llm_generate_dataset.qmd
ADDED
@@ -0,0 +1,146 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
Building a fine-tune dataset based on an ontology to train a model on how to reason according to that ontology involves several steps. The goal is to create a dataset that captures the relationships, rules, and structures defined by the ontology, allowing the model to learn how to apply these concepts when reasoning about new data. Here’s a step-by-step guide:
|
2 |
+
|
3 |
+
### **Understand the Ontology**
|
4 |
+
|
5 |
+
Before creating a dataset, you must have a deep understanding of the ontology you intend to use. This includes:
|
6 |
+
|
7 |
+
- **Entities**: The different types of objects or concepts (e.g., `Person`, `Product`, `Supplier`).
|
8 |
+
|
9 |
+
- **Relationships**: How these entities are related (e.g., `Supplies`, `Manufactures`, `BelongsTo`).
|
10 |
+
|
11 |
+
- **Attributes**: Properties associated with entities (e.g., `name`, `location`).
|
12 |
+
- **Logical Rules and Constraints**: Rules that dictate how entities and relationships interact (e.g., "A `Supplier` must supply at least one `Product`").
|
13 |
+
|
14 |
+
### **Define the Reasoning Tasks**
|
15 |
+
|
16 |
+
Identify the types of reasoning tasks you want the model to learn. These could include:
|
17 |
+
|
18 |
+
- **Inference**: Deriving new facts from existing data (e.g., inferring that a `Supplier` is connected to a `Retailer` through a series of relationships).
|
19 |
+
|
20 |
+
- **Validation**: Checking consistency with the ontology (e.g., ensuring that every `Manufacturer` has at least one `Product`).
|
21 |
+
|
22 |
+
- **Classification**: Categorizing entities based on their attributes and relationships (e.g., identifying whether an entity is a `Supplier` or `Manufacturer`).
|
23 |
+
|
24 |
+
- **Query Answering**: Generating or validating answers based on the ontology (e.g., answering "Which products are supplied by Supplier X?").
|
25 |
+
|
26 |
+
### **Collect and Annotate Data**
|
27 |
+
|
28 |
+
Collect data that aligns with the entities, relationships, and attributes defined by the ontology. This data will be used to create examples for training the model.
|
29 |
+
|
30 |
+
#### **Data Collection**:
|
31 |
+
|
32 |
+
- **Structured Data**: Gather structured data sources like databases, CSV files, or existing knowledge graphs.
|
33 |
+
|
34 |
+
- **Unstructured Data**: Extract and structure data from text documents, reports, or other unstructured sources.
|
35 |
+
|
36 |
+
#### **Annotation**:
|
37 |
+
|
38 |
+
- **Entity Annotation**: Label entities according to the ontology (e.g., label "Harry" as a `Person`).
|
39 |
+
|
40 |
+
- **Relationship Annotation**: Label relationships between entities (e.g., label "Harry belongs to Gryffindor" as `BelongsTo`).
|
41 |
+
|
42 |
+
- **Logical Annotations**: Annotate data with logical rules and constraints (e.g., mark invalid relationships or missing connections).
|
43 |
+
|
44 |
+
### **Create Training Examples**
|
45 |
+
|
46 |
+
Convert the annotated data into training examples that illustrate reasoning according to the ontology. Each example should include:
|
47 |
+
|
48 |
+
- **Input Data**: The scenario or data point that requires reasoning (e.g., a set of entities and their relationships).
|
49 |
+
|
50 |
+
- **Expected Output**: The correct reasoning outcome (e.g., an inferred relationship, a classification, or a validation result).
|
51 |
+
|
52 |
+
#### **Types of Training Examples**:
|
53 |
+
|
54 |
+
- **Inference Examples**: Provide partial information and expect the model to infer missing data.
|
55 |
+
|
56 |
+
- Example: Given a `Supplier` and a `Product`, the model should infer the connection to a `Retailer` through a known `Distributor`.
|
57 |
+
|
58 |
+
- **Validation Examples**: Provide complete data, and the model must identify inconsistencies or validate that the data fits the ontology.
|
59 |
+
|
60 |
+
- Example: Check whether all `Products` have an associated `Manufacturer`.
|
61 |
+
|
62 |
+
- **Classification Examples**: Present entities and relationships, and the model should classify them according to the ontology.
|
63 |
+
|
64 |
+
- Example: Classify an entity as a `Supplier` or `Manufacturer` based on its relationships.
|
65 |
+
|
66 |
+
- **Query Answering Examples**: Provide questions about the ontology, and the model should generate the correct answer.
|
67 |
+
|
68 |
+
- Example: "Which suppliers provide raw materials to Manufacturer Y?"
|
69 |
+
|
70 |
+
### **Ensure Diversity in the Dataset**
|
71 |
+
|
72 |
+
To help the model generalize, the dataset should include a diverse set of examples:
|
73 |
+
|
74 |
+
- **Varying Entity Types**: Include all entity types from the ontology in different contexts.
|
75 |
+
|
76 |
+
- **Complex Relationships**: Include simple and complex relationships, such as chains of relationships or multiple interconnected entities.
|
77 |
+
|
78 |
+
- **Logical Variations**: Include different types of logical rules and scenarios, such as both valid and invalid cases.
|
79 |
+
|
80 |
+
### **Augment the Dataset**
|
81 |
+
|
82 |
+
To further enhance the model’s ability to reason, consider augmenting the dataset:
|
83 |
+
|
84 |
+
- **Synthetic Data Generation**: Automatically generate additional examples by applying known transformations or logical rules.
|
85 |
+
|
86 |
+
- Example: If a `Supplier` supplies multiple `Products`, generate variations where each `Product` is connected to different `Retailers`.
|
87 |
+
|
88 |
+
- **Counterexamples**: Include incorrect or misleading examples to help the model learn to distinguish valid from invalid reasoning.
|
89 |
+
|
90 |
+
- Example: Provide scenarios where a `Product` is mistakenly linked to the wrong `Supplier` and label it as incorrect.
|
91 |
+
|
92 |
+
### **Fine-Tune the Model**
|
93 |
+
|
94 |
+
Once the dataset is prepared, fine-tune the LLM or another machine learning model using this data:
|
95 |
+
|
96 |
+
- **Training**: Use the dataset to train the model, adjusting the model’s parameters to minimize the error between its predictions and the expected outputs.
|
97 |
+
|
98 |
+
- **Validation**: Use a separate validation set to monitor the model’s performance and avoid overfitting.
|
99 |
+
|
100 |
+
- **Testing**: Evaluate the model on a test set to ensure it can generalize to new, unseen examples.
|
101 |
+
|
102 |
+
### **Evaluate and Refine**
|
103 |
+
|
104 |
+
After training, evaluate the model’s reasoning abilities:
|
105 |
+
|
106 |
+
- **Accuracy**: Measure how accurately the model can perform reasoning tasks.
|
107 |
+
|
108 |
+
- **Consistency**: Ensure the model’s outputs are consistent with the ontology’s rules and constraints.
|
109 |
+
|
110 |
+
- **Explainability**: Check whether the model’s reasoning process aligns with human understanding of the ontology.
|
111 |
+
|
112 |
+
Based on the evaluation, refine the dataset and model:
|
113 |
+
|
114 |
+
- **Dataset Refinement**: Add more examples, correct errors, or increase diversity.
|
115 |
+
|
116 |
+
- **Model Tuning**: Adjust hyperparameters or model architecture to improve performance.
|
117 |
+
|
118 |
+
### **Deploy and Monitor**
|
119 |
+
|
120 |
+
Once the model is sufficiently trained, deploy it to perform reasoning tasks in real-world applications:
|
121 |
+
|
122 |
+
- **Real-Time Reasoning**: Use the model to infer new knowledge, validate data, or answer queries based on the ontology.
|
123 |
+
|
124 |
+
- **Continuous Learning**: Monitor the model’s performance in production and update the training dataset with new examples as needed.
|
125 |
+
|
126 |
+
### Summary
|
127 |
+
|
128 |
+
Creating a fine-tune dataset based on an ontology involves understanding the ontology, collecting and annotating data, creating diverse training examples, and training a model to reason according to the ontology. This process ensures that the model can accurately and consistently apply the rules and relationships defined by the ontology, enabling it to perform complex reasoning tasks in domains such as supply chain management, healthcare, finance, or any other field where structured knowledge is crucial.
|
129 |
+
|
130 |
+
### Bullet Points:
|
131 |
+
|
132 |
+
- **Understand the Ontology**: Familiarize yourself with entities, relationships, attributes, and logical rules within the ontology.
|
133 |
+
- **Define Reasoning Tasks**: Identify reasoning tasks like inference, validation, classification, and query answering that the model should learn.
|
134 |
+
- **Collect and Annotate Data**: Gather and label data according to the ontology, focusing on entities, relationships, and logical rules.
|
135 |
+
- **Create Training Examples**: Develop examples illustrating how to reason with the ontology, including inference, validation, classification, and query answering tasks.
|
136 |
+
- **Ensure Dataset Diversity**: Include diverse entity types, complex relationships, and logical variations to improve model generalization.
|
137 |
+
- **Augment the Dataset**: Enhance the dataset with synthetic data, transformations, and counterexamples to strengthen reasoning abilities.
|
138 |
+
- **Fine-Tune the Model**: Train the model using the dataset, validate performance, and test on unseen examples.
|
139 |
+
- **Evaluate and Refine**: Measure the model’s accuracy, consistency, and explainability, refining the dataset and model as needed.
|
140 |
+
- **Deploy and Monitor**: Deploy the model for real-time reasoning tasks, and monitor performance for continuous improvement.
|
141 |
+
|
142 |
+
### Key Takeaways:
|
143 |
+
|
144 |
+
- Understanding and accurately representing the ontology is crucial for creating a fine-tune dataset.
|
145 |
+
- Diverse and well-annotated training examples help the model learn to reason according to the ontology.
|
146 |
+
- Continuous evaluation and refinement are essential to ensuring the model’s reasoning aligns with the ontology’s rules and can generalize to new scenarios.
|
src/llm_knowledge.qmd
ADDED
@@ -0,0 +1,92 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
Large Language Models (LLMs), can utilize ontologies to enhance their ability to check, infer, and generate knowledge, especially when working with extracted nodes from a Knowledge Graph. Here’s how this process works:
|
2 |
+
|
3 |
+
## **Using Ontologies for Knowledge Checking**
|
4 |
+
|
5 |
+
![](document_extraction.webp)
|
6 |
+
|
7 |
+
LLMs can use ontologies to verify the correctness and consistency of the knowledge inferred from extracted nodes. Here’s how:
|
8 |
+
|
9 |
+
### **Consistency Checking**
|
10 |
+
- **Schema Validation**: The LLM can ensure that the extracted nodes and their relationships conform to the ontology’s schema. For example, if an ontology specifies that "Professor" must be a subclass of "Person," the LLM can check that any node classified as "Professor" also inherits the attributes and relationships associated with "Person."
|
11 |
+
|
12 |
+
- **Domain and Range Constraints**: Ontologies often define domain (the type of entities that can be the subject of a relationship) and range (the type of entities that can be the object of a relationship). The LLM can verify that these constraints are respected. For instance, if the ontology states that "TeachesAt" should connect a "Person" to an "Institution," the LLM can check that nodes connected by this relationship fit these categories.
|
13 |
+
|
14 |
+
### **Logical Consistency**
|
15 |
+
|
16 |
+
- **Conflict Detection**: The LLM can identify logical contradictions within the knowledge graph by applying the ontology's rules. For instance, if one node states that "Voldemort is a wizard" and another infers that "Voldemort is a muggle" (based on conflicting extracted information), the LLM can detect this inconsistency and flag it for resolution.
|
17 |
+
|
18 |
+
## **Using Ontologies for Knowledge Inference**
|
19 |
+
|
20 |
+
Ontologies allow LLMs to infer new knowledge from existing data by leveraging the relationships and rules defined within the ontology.
|
21 |
+
|
22 |
+
### **Deductive Reasoning**
|
23 |
+
|
24 |
+
- **Transitive Inference**: If the ontology defines a relationship as transitive (e.g., "isA"), the LLM can infer new relationships based on existing ones. For example, if "Dumbledore is a Wizard" and "Wizard is a Person," the LLM can infer "Dumbledore is a Person."
|
25 |
+
|
26 |
+
- **Subclass and Superclass Reasoning**: Ontologies often define hierarchies (e.g., "Professor is a subclass of Person"). The LLM can use these hierarchies to infer broader or more specific relationships. For instance, if "Dumbledore teaches at Hogwarts" and "Professor is a subclass of Person," it can be inferred that "A person teaches at Hogwarts."
|
27 |
+
|
28 |
+
### **Rule-Based Inference**
|
29 |
+
|
30 |
+
- **Applying Logical Rules**: The ontology might include rules like "If x is loyal to y, and y is loyal to z, then x is loyal to z." The LLM can apply these rules to infer new relationships or attributes within the knowledge graph.
|
31 |
+
|
32 |
+
- **Missing Data Inference**: The LLM can infer missing data based on the ontology. For example, if the ontology states that every "Wizard" has a "Wand," and the LLM encounters a node labeled "Harry" as a "Wizard" without a linked "Wand," it can infer and suggest adding the missing relationship "Harry has a Wand."
|
33 |
+
|
34 |
+
### **Contextual Inference**
|
35 |
+
|
36 |
+
- **Disambiguation**: The LLM can use the ontology to disambiguate nodes with multiple potential meanings. For instance, if the node "Sirius" appears, the ontology could help the LLM determine whether it refers to "Sirius Black" (a person) or "Sirius" (a star) based on the context provided by related nodes and relationships.
|
37 |
+
|
38 |
+
## **Practical Example: Harry Potter Knowledge Graph**
|
39 |
+
|
40 |
+
|
41 |
+
![](content_extraction.webp)
|
42 |
+
|
43 |
+
|
44 |
+
Let’s say we have a Knowledge Graph about the Harry Potter universe, and we extract the following nodes:
|
45 |
+
|
46 |
+
- **Node 1**: Harry (Type: Person)
|
47 |
+
- **Node 2**: Hogwarts (Type: Institution)
|
48 |
+
- **Node 3**: TeachesAt (Relationship: Person to Institution)
|
49 |
+
|
50 |
+
### **Ontology Application**
|
51 |
+
|
52 |
+
- **Checking**: The LLM uses the ontology to check that "TeachesAt" correctly links "Person" to "Institution." If "Harry" is connected to "Hogwarts" via "TeachesAt," but Harry is a student, the LLM identifies a potential error because, according to the ontology, "TeachesAt" should connect "Professors" to "Institutions."
|
53 |
+
|
54 |
+
- **Inference**: If the ontology states that all "Wizards" must belong to a "House" at "Hogwarts," and the graph only shows "Harry" as a "Wizard" without a "House," the LLM can infer and suggest the addition of a missing relationship, such as "Harry belongs to Gryffindor."
|
55 |
+
|
56 |
+
## **Advantages of Using Ontologies with LLMs**
|
57 |
+
|
58 |
+
- **Accuracy**: Ensures that knowledge graphs are populated with consistent and accurate information.
|
59 |
+
|
60 |
+
- **Scalability**: Allows LLMs to handle large-scale, complex domains by applying rules and relationships across many nodes.
|
61 |
+
|
62 |
+
- **Automation**: Reduces manual intervention by enabling automated reasoning and data validation.
|
63 |
+
|
64 |
+
- **Enhanced Reasoning**: Improves the ability of LLMs to generate meaningful and contextually accurate responses based on inferred knowledge.
|
65 |
+
|
66 |
+
By integrating ontologies with LLMs, we can achieve a more robust and intelligent system for managing and inferring knowledge, ensuring that the data within a knowledge graph is both accurate and semantically rich.
|
67 |
+
|
68 |
+
### Bullet Points:
|
69 |
+
|
70 |
+
- **Ontology-Enhanced Knowledge Checking**:
|
71 |
+
- **Consistency Checking**: LLMs validate extracted nodes and relationships against the ontology’s schema, ensuring they conform to defined rules like domain and range constraints.
|
72 |
+
- **Logical Consistency**: LLMs detect and flag logical contradictions within the knowledge graph by applying ontology rules, such as identifying conflicting information.
|
73 |
+
|
74 |
+
- **Ontology-Driven Knowledge Inference**:
|
75 |
+
- **Deductive Reasoning**: LLMs infer new relationships and facts by leveraging transitive properties and subclass hierarchies defined in the ontology.
|
76 |
+
- **Rule-Based Inference**: LLMs apply logical rules from the ontology to infer new relationships and identify missing data, enhancing the completeness of the knowledge graph.
|
77 |
+
- **Contextual Inference**: Ontologies help LLMs disambiguate nodes with multiple meanings based on context provided by related entities and relationships.
|
78 |
+
|
79 |
+
- **Practical Example: Harry Potter Knowledge Graph**:
|
80 |
+
- **Checking**: The LLM verifies that relationships like "TeachesAt" are correctly linking appropriate entities according to the ontology (e.g., only professors should be linked to institutions via this relationship).
|
81 |
+
- **Inference**: The LLM infers missing relationships, such as linking "Harry" to "Gryffindor" based on the ontology’s rule that all wizards belong to a house.
|
82 |
+
|
83 |
+
- **Advantages of Integrating Ontologies with LLMs**:
|
84 |
+
- **Accuracy**: Ensures consistent and accurate data in knowledge graphs.
|
85 |
+
- **Scalability**: Enables LLMs to handle complex domains with extensive nodes and relationships.
|
86 |
+
- **Automation**: Reduces the need for manual data validation and reasoning by automating these processes.
|
87 |
+
- **Enhanced Reasoning**: Improves the LLM’s ability to generate meaningful, contextually accurate knowledge and responses.
|
88 |
+
|
89 |
+
### Key Takeaways:
|
90 |
+
|
91 |
+
- Integrating ontologies with LLMs enhances their ability to check, infer, and generate knowledge, ensuring that knowledge graphs are accurate, consistent, and semantically rich.
|
92 |
+
- LLMs can perform advanced reasoning tasks by applying ontology-defined rules and relationships, leading to better automation and scalability in knowledge management.
|
src/llm_query.qmd
ADDED
@@ -0,0 +1,160 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
To use a Large Language Model (LLM) to create queries and Cypher (a query language for graph databases) queries to collect data from a Knowledge Graph and answer a user's question, follow these steps:
|
2 |
+
|
3 |
+
### **Understanding the User's Query**
|
4 |
+
|
5 |
+
The first step is to understand and interpret the user's natural language question. This involves:
|
6 |
+
|
7 |
+
- **Entity Recognition**: Identifying the key entities (e.g., characters, locations) mentioned in the user's query.
|
8 |
+
|
9 |
+
- **Intent Identification**: Determining what the user is asking for (e.g., relationships between entities, attributes of a specific entity).
|
10 |
+
|
11 |
+
For example, if the user asks, "Which house does Harry belong to?", the LLM needs to identify:
|
12 |
+
|
13 |
+
- **Entity**: "Harry"
|
14 |
+
|
15 |
+
- **Intent**: Finding the relationship between "Harry" and the "House" he belongs to.
|
16 |
+
|
17 |
+
### **Mapping the Query to the Knowledge Graph Schema**
|
18 |
+
|
19 |
+
Once the entities and intent are identified, the LLM needs to map these to the structure of the Knowledge Graph, which is defined by the ontology. This includes:
|
20 |
+
|
21 |
+
- **Identifying Nodes and Relationships**: Understanding which nodes (e.g., `Person`, `House`) and relationships (e.g., `BelongsTo`) in the graph are relevant to the query.
|
22 |
+
|
23 |
+
- **Mapping Entities to Nodes**: Associating the identified entities with the corresponding nodes in the graph.
|
24 |
+
|
25 |
+
For example:
|
26 |
+
- The entity "Harry" maps to the node `Person`.
|
27 |
+
- The intent of finding a "House" can be mapped to the relationship `BelongsTo`.
|
28 |
+
|
29 |
+
### **Generating the Cypher Query**
|
30 |
+
|
31 |
+
Cypher is the query language used to interact with Neo4j databases. The LLM can be used to generate a Cypher query based on the user's input and the knowledge graph schema.
|
32 |
+
|
33 |
+
#### **Basic Cypher Query Structure**
|
34 |
+
|
35 |
+
A typical Cypher query has the following structure:
|
36 |
+
|
37 |
+
```cypher
|
38 |
+
MATCH (n:Label)-[r:RELATIONSHIP]->(m:Label)
|
39 |
+
WHERE n.property = 'value'
|
40 |
+
RETURN m.property
|
41 |
+
```
|
42 |
+
|
43 |
+
Here’s how the LLM would translate the user's query into a Cypher query:
|
44 |
+
|
45 |
+
**User Query**: "Which house does Harry belong to?"
|
46 |
+
|
47 |
+
1. **MATCH Clause**: The LLM recognizes that "Harry" is a `Person` and that the relationship we're interested in is `BelongsTo` (connecting a `Person` to a `House`).
|
48 |
+
|
49 |
+
```cypher
|
50 |
+
MATCH (harry:Person)-[:BelongsTo]->(house:House)
|
51 |
+
```
|
52 |
+
|
53 |
+
2. **WHERE Clause**: To filter the nodes to only include the one representing Harry.
|
54 |
+
|
55 |
+
```cypher
|
56 |
+
WHERE harry.name = 'Harry'
|
57 |
+
```
|
58 |
+
|
59 |
+
3. **RETURN Clause**: Finally, return the name of the house.
|
60 |
+
|
61 |
+
```cypher
|
62 |
+
RETURN house.name
|
63 |
+
```
|
64 |
+
|
65 |
+
**Final Cypher Query**:
|
66 |
+
|
67 |
+
```cypher
|
68 |
+
MATCH (harry:Person)-[:BelongsTo]->(house:House)
|
69 |
+
WHERE harry.name = 'Harry'
|
70 |
+
RETURN house.name
|
71 |
+
```
|
72 |
+
|
73 |
+
### **Executing the Query and Retrieving Results**
|
74 |
+
|
75 |
+
The generated Cypher query is then executed against the Knowledge Graph database (e.g., Neo4j).
|
76 |
+
|
77 |
+
The database returns the result, which is typically in the form of a node or a set of nodes (in this case, the `House` node associated with `Harry`).
|
78 |
+
|
79 |
+
### **Interpreting and Formatting the Result**
|
80 |
+
|
81 |
+
After executing the query, the LLM needs to format the result in a user-friendly way. For example:
|
82 |
+
- If the result is "Gryffindor," the LLM might generate a response like, "Harry belongs to the Gryffindor house."
|
83 |
+
|
84 |
+
### **Handling Complex Queries**
|
85 |
+
|
86 |
+
For more complex queries, the LLM can generate more sophisticated Cypher queries by leveraging advanced Cypher features such as:
|
87 |
+
|
88 |
+
- **Multiple Relationships**: Handling queries that involve multiple relationships, such as "Who are Harry's friends that belong to Gryffindor?"
|
89 |
+
|
90 |
+
- **Aggregation**: Using functions like `COUNT`, `SUM`, etc., for queries that require aggregating data, like "How many students belong to Gryffindor?"
|
91 |
+
|
92 |
+
- **Pattern Matching**: Matching complex graph patterns to answer questions like "Which professors at Hogwarts teach Gryffindor students?"
|
93 |
+
|
94 |
+
#### **Example Complex Query**
|
95 |
+
|
96 |
+
**User Query**: "Who are Harry's friends that belong to Gryffindor?"
|
97 |
+
|
98 |
+
**Cypher Query**:
|
99 |
+
```cypher
|
100 |
+
MATCH (harry:Person)-[:FriendOf]->(friend:Person)-[:BelongsTo]->(house:House)
|
101 |
+
WHERE harry.name = 'Harry' AND house.name = 'Gryffindor'
|
102 |
+
RETURN friend.name
|
103 |
+
```
|
104 |
+
|
105 |
+
### **Continuous Learning and Adaptation**
|
106 |
+
|
107 |
+
The LLM can be fine-tuned over time to improve its ability to generate accurate Cypher queries. By analyzing the success or failure of past queries, the LLM can learn to better interpret user questions, understand the ontology, and generate more precise Cypher queries.
|
108 |
+
|
109 |
+
### **Feedback Loop and Iteration**
|
110 |
+
|
111 |
+
Users might provide feedback on the answers they receive, which can be used to further refine the LLM’s understanding of the domain and improve future query generation. This iterative process ensures that the LLM becomes more effective at interacting with the Knowledge Graph over time.
|
112 |
+
|
113 |
+
### Summary
|
114 |
+
|
115 |
+
By following these steps, an LLM can effectively generate Cypher queries to extract data from a Knowledge Graph and answer user questions. The process involves understanding the user’s intent, mapping that intent to the graph’s structure, generating the appropriate Cypher query, and then formatting the retrieved results in a user-friendly manner. This approach allows for a powerful and dynamic interaction between natural language queries and structured graph data.
|
116 |
+
|
117 |
+
|
118 |
+
### Bullet Points:
|
119 |
+
|
120 |
+
- **Understanding the User's Query**:
|
121 |
+
- **Entity Recognition**: Identify key entities in the user's question (e.g., "Harry").
|
122 |
+
- **Intent Identification**: Determine what the user is asking for (e.g., relationships, attributes).
|
123 |
+
|
124 |
+
- **Mapping the Query to the Knowledge Graph Schema**:
|
125 |
+
- **Identifying Nodes and Relationships**: Determine relevant nodes (e.g., `Person`, `House`) and relationships (e.g., `BelongsTo`) in the graph.
|
126 |
+
- **Mapping Entities to Nodes**: Associate identified entities with corresponding graph nodes.
|
127 |
+
|
128 |
+
- **Generating the Cypher Query**:
|
129 |
+
- **Basic Cypher Structure**: Use a structured approach to create Cypher queries.
|
130 |
+
- **Example**: Translate "Which house does Harry belong to?" into a Cypher query:
|
131 |
+
```cypher
|
132 |
+
MATCH (harry:Person)-[:BelongsTo]->(house:House)
|
133 |
+
WHERE harry.name = 'Harry'
|
134 |
+
RETURN house.name
|
135 |
+
```
|
136 |
+
|
137 |
+
- **Executing the Query and Retrieving Results**:
|
138 |
+
- **Query Execution**: Run the Cypher query against the Knowledge Graph database (e.g., Neo4j).
|
139 |
+
- **Result Formatting**: Present the result in a user-friendly format (e.g., "Harry belongs to Gryffindor").
|
140 |
+
|
141 |
+
- **Handling Complex Queries**:
|
142 |
+
- **Advanced Cypher Features**: Handle complex queries involving multiple relationships, aggregation, and pattern matching.
|
143 |
+
- **Example**: "Who are Harry's friends that belong to Gryffindor?"
|
144 |
+
```cypher
|
145 |
+
MATCH (harry:Person)-[:FriendOf]->(friend:Person)-[:BelongsTo]->(house:House)
|
146 |
+
WHERE harry.name = 'Harry' AND house.name = 'Gryffindor'
|
147 |
+
RETURN friend.name
|
148 |
+
```
|
149 |
+
|
150 |
+
- **Continuous Learning and Adaptation**:
|
151 |
+
- **Fine-Tuning**: Improve query generation accuracy over time by learning from past successes and failures.
|
152 |
+
|
153 |
+
- **Feedback Loop and Iteration**:
|
154 |
+
- **User Feedback**: Use feedback to refine the LLM's understanding and improve future query generation.
|
155 |
+
|
156 |
+
### Key Takeaways:
|
157 |
+
|
158 |
+
- LLMs can effectively translate natural language queries into Cypher queries by recognizing entities, understanding intent, and mapping these to a Knowledge Graph schema.
|
159 |
+
- By generating and executing precise Cypher queries, LLMs can retrieve and present data in response to user questions, enabling dynamic interaction with structured graph data.
|
160 |
+
- Continuous learning and user feedback are essential for refining the LLM's capabilities in query generation and knowledge graph interaction.
|
src/llm_supply_chains.qmd
ADDED
@@ -0,0 +1,188 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
+
Applying the concepts of using a Large Language Model (LLM) with ontologies, Cypher queries, and Knowledge Graphs to Supply Chain Mapping can significantly enhance the ability to analyze, query, and manage complex supply chain networks. Here’s how this process can be adapted for supply chain management:
|
2 |
+
|
3 |
+
### **Supply Chain Knowledge Graph**
|
4 |
+
|
5 |
+
|
6 |
+
![](knowledge_supply_chain.webp)
|
7 |
+
|
8 |
+
A **Supply Chain Knowledge Graph** represents the entities, relationships, and attributes involved in a supply chain. This includes suppliers, manufacturers, distributors, retailers, products, logistics, and more.
|
9 |
+
|
10 |
+
#### **Entities (Nodes)**:
|
11 |
+
|
12 |
+
- **Suppliers**: Companies or entities that provide raw materials or components.
|
13 |
+
|
14 |
+
- **Manufacturers**: Entities that produce goods from raw materials.
|
15 |
+
|
16 |
+
- **Distributors**: Entities responsible for distributing products to retailers or end customers.
|
17 |
+
|
18 |
+
- **Retailers**: Stores or businesses that sell products to consumers.
|
19 |
+
|
20 |
+
- **Products**: The goods being produced and distributed.
|
21 |
+
|
22 |
+
- **Locations**: Physical locations such as factories, warehouses, distribution centers, and retail outlets.
|
23 |
+
|
24 |
+
- **Transport Routes**: Paths taken by goods as they move through the supply chain.
|
25 |
+
|
26 |
+
#### **Relationships (Edges)**:
|
27 |
+
|
28 |
+
- **Supplies**: Connects suppliers to manufacturers, representing the supply of materials.
|
29 |
+
|
30 |
+
- **Manufactures**: Connects manufacturers to products, representing production.
|
31 |
+
|
32 |
+
- **Distributes**: Connects manufacturers or distributors to retailers.
|
33 |
+
|
34 |
+
- **LocatedAt**: Connects entities like factories or warehouses to specific locations.
|
35 |
+
|
36 |
+
- **Transports**: Connects transport routes to products and locations, showing the movement of goods.
|
37 |
+
|
38 |
+
### **Using Ontologies for Supply Chain**
|
39 |
+
|
40 |
+
An ontology in the context of supply chain management defines the categories (e.g., Supplier, Manufacturer, Product) and relationships (e.g., Supplies, Manufactures) within the supply chain domain.
|
41 |
+
|
42 |
+
#### **Ontology Use Cases**:
|
43 |
+
|
44 |
+
- **Consistency**: Ensures that data about entities like suppliers and products is consistently categorized and connected in the Knowledge Graph.
|
45 |
+
|
46 |
+
- **Validation**: Validates that relationships such as "Supplier supplies raw material to Manufacturer" adhere to the logical rules of the ontology.
|
47 |
+
|
48 |
+
### **LLM for Query Understanding and Mapping**
|
49 |
+
|
50 |
+
When a user asks a question about the supply chain, an LLM can interpret this natural language query, map it to the Knowledge Graph schema, and generate the corresponding Cypher query.
|
51 |
+
|
52 |
+
#### **Example Queries**:
|
53 |
+
|
54 |
+
- **"Who are the suppliers for Product X?"**
|
55 |
+
- The LLM identifies that the user wants to find nodes labeled `Supplier` connected to `Product X` via the `Supplies` relationship.
|
56 |
+
|
57 |
+
- **"What are the transport routes for delivering Product Y to Retailer Z?"**
|
58 |
+
- The LLM identifies the need to trace `TransportRoutes` linked to `Product Y` and connected to `Retailer Z`.
|
59 |
+
|
60 |
+
### **Generating Cypher Queries**
|
61 |
+
|
62 |
+
Based on the user query, the LLM generates Cypher queries to extract relevant data from the Knowledge Graph.
|
63 |
+
|
64 |
+
#### **Example Cypher Query 1**:
|
65 |
+
|
66 |
+
**User Query**: "Who are the suppliers for Product X?"
|
67 |
+
|
68 |
+
**Cypher Query**:
|
69 |
+
```cypher
|
70 |
+
MATCH (supplier:Supplier)-[:Supplies]->(product:Product)
|
71 |
+
WHERE product.name = 'Product X'
|
72 |
+
RETURN supplier.name
|
73 |
+
```
|
74 |
+
This query matches suppliers linked to "Product X" through the `Supplies` relationship and returns the names of those suppliers.
|
75 |
+
|
76 |
+
#### **Example Cypher Query 2**:
|
77 |
+
|
78 |
+
**User Query**: "What are the transport routes for delivering Product Y to Retailer Z?"
|
79 |
+
|
80 |
+
**Cypher Query**:
|
81 |
+
```cypher
|
82 |
+
MATCH (product:Product)-[:Transports]->(route:TransportRoute)-[:To]->(retailer:Retailer)
|
83 |
+
WHERE product.name = 'Product Y' AND retailer.name = 'Retailer Z'
|
84 |
+
RETURN route.details
|
85 |
+
```
|
86 |
+
This query retrieves transport routes associated with delivering "Product Y" to "Retailer Z."
|
87 |
+
|
88 |
+
### **Inference and Knowledge Checking**
|
89 |
+
|
90 |
+
The LLM can use the supply chain ontology to infer new relationships or validate the consistency of the supply chain data. For example:
|
91 |
+
|
92 |
+
- **Inference**: If a new supplier is added to the graph, the LLM can infer potential supply routes based on existing data about similar products or suppliers.
|
93 |
+
|
94 |
+
- **Validation**: If a query suggests a product is being transported along a route that doesn’t match known transport constraints (e.g., distance or capacity), the LLM can flag this inconsistency.
|
95 |
+
|
96 |
+
### **Handling Complex Supply Chain Queries**
|
97 |
+
|
98 |
+
For more complex queries, the LLM can generate sophisticated Cypher queries that involve multiple nodes and relationships, aggregating data or performing complex pattern matching.
|
99 |
+
|
100 |
+
#### **Example Complex Query**:
|
101 |
+
|
102 |
+
**User Query**: "Which suppliers provide raw materials to manufacturers that produce products sold in Retailer A's stores?"
|
103 |
+
|
104 |
+
**Cypher Query**:
|
105 |
+
```cypher
|
106 |
+
MATCH (supplier:Supplier)-[:Supplies]->(rawMaterial:RawMaterial)<-[:Uses]-(manufacturer:Manufacturer)-[:Manufactures]->(product:Product)-[:SellsAt]->(retailer:Retailer)
|
107 |
+
WHERE retailer.name = 'Retailer A'
|
108 |
+
RETURN supplier.name
|
109 |
+
```
|
110 |
+
This query tracks the entire supply chain from suppliers to manufacturers to products, ending at the retailer.
|
111 |
+
|
112 |
+
### **Updating the Knowledge Graph**
|
113 |
+
|
114 |
+
As new data is collected or inferred from user queries, the Knowledge Graph can be updated. For example:
|
115 |
+
|
116 |
+
- **Adding New Relationships**: If a query identifies a new supplier-product relationship, this can be added to the graph.
|
117 |
+
|
118 |
+
- **Extending the Graph**: The graph can be extended by integrating data from other systems, such as ERP (Enterprise Resource Planning) or logistics software, based on the LLM’s recommendations.
|
119 |
+
|
120 |
+
### **User Interaction and Continuous Learning**
|
121 |
+
|
122 |
+
The LLM can continuously learn from user interactions:
|
123 |
+
|
124 |
+
- **Feedback Loop**: Users can provide feedback on the accuracy of the answers, helping the LLM improve its query generation and understanding.
|
125 |
+
|
126 |
+
- **Iterative Query Refinement**: The LLM can refine queries over time to better align with the supply chain’s ontology and structure.
|
127 |
+
|
128 |
+
### Summary
|
129 |
+
|
130 |
+
In the context of Supply Chain Mapping, using an LLM with a Knowledge Graph and ontology enables powerful and flexible querying of complex supply chain networks. The LLM interprets user questions, generates precise Cypher queries, and interacts with the Knowledge Graph to retrieve relevant information. This approach enhances the ability to analyze, manage, and optimize supply chains by providing detailed, accurate, and contextually rich insights, which are essential for decision-making in complex global supply chains.
|
131 |
+
|
132 |
+
|
133 |
+
### Bullet Points:
|
134 |
+
|
135 |
+
- **Supply Chain Knowledge Graph**:
|
136 |
+
- **Entities**: Includes nodes such as Suppliers, Manufacturers, Distributors, Retailers, Products, Locations, and Transport Routes.
|
137 |
+
- **Relationships**: Represents connections like Supplies, Manufactures, Distributes, LocatedAt, and Transports within the supply chain.
|
138 |
+
|
139 |
+
- **Using Ontologies for Supply Chain**:
|
140 |
+
- **Consistency**: Ensures that data about entities and relationships is consistently categorized and connected in the Knowledge Graph.
|
141 |
+
- **Validation**: Verifies that relationships and connections adhere to logical rules defined by the ontology.
|
142 |
+
|
143 |
+
- **LLM for Query Understanding and Mapping**:
|
144 |
+
- **Interpreting User Queries**: The LLM identifies key entities and the intent behind the user’s question, mapping it to the Knowledge Graph schema.
|
145 |
+
- **Example Queries**:
|
146 |
+
- "Who are the suppliers for Product X?" identifies suppliers connected to the product.
|
147 |
+
- "What are the transport routes for delivering Product Y to Retailer Z?" traces transport routes for the specified product and retailer.
|
148 |
+
|
149 |
+
- **Generating Cypher Queries**:
|
150 |
+
- **Example Cypher Query 1**:
|
151 |
+
```cypher
|
152 |
+
MATCH (supplier:Supplier)-[:Supplies]->(product:Product)
|
153 |
+
WHERE product.name = 'Product X'
|
154 |
+
RETURN supplier.name
|
155 |
+
```
|
156 |
+
- **Example Cypher Query 2**:
|
157 |
+
```cypher
|
158 |
+
MATCH (product:Product)-[:Transports]->(route:TransportRoute)-[:To]->(retailer:Retailer)
|
159 |
+
WHERE product.name = 'Product Y' AND retailer.name = 'Retailer Z'
|
160 |
+
RETURN route.details
|
161 |
+
```
|
162 |
+
|
163 |
+
- **Inference and Knowledge Checking**:
|
164 |
+
- **Inference**: The LLM can infer new relationships, such as potential supply routes, based on existing data.
|
165 |
+
- **Validation**: The LLM can detect inconsistencies in the supply chain data, such as incorrect transport routes.
|
166 |
+
|
167 |
+
- **Handling Complex Supply Chain Queries**:
|
168 |
+
- **Complex Query Example**:
|
169 |
+
- "Which suppliers provide raw materials to manufacturers that produce products sold in Retailer A's stores?" tracks the entire supply chain from suppliers to retailers.
|
170 |
+
```cypher
|
171 |
+
MATCH (supplier:Supplier)-[:Supplies]->(rawMaterial:RawMaterial)<-[:Uses]-(manufacturer:Manufacturer)-[:Manufactures]->(product:Product)-[:SellsAt]->(retailer:Retailer)
|
172 |
+
WHERE retailer.name = 'Retailer A'
|
173 |
+
RETURN supplier.name
|
174 |
+
```
|
175 |
+
|
176 |
+
- **Updating the Knowledge Graph**:
|
177 |
+
- **Adding New Relationships**: New supplier-product relationships can be added based on query results.
|
178 |
+
- **Extending the Graph**: Integrate data from other systems, like ERP or logistics software, to expand the Knowledge Graph.
|
179 |
+
|
180 |
+
- **User Interaction and Continuous Learning**:
|
181 |
+
- **Feedback Loop**: User feedback improves the LLM’s accuracy and understanding.
|
182 |
+
- **Iterative Query Refinement**: The LLM refines queries over time to better align with the supply chain ontology and structure.
|
183 |
+
|
184 |
+
### Key Takeaways:
|
185 |
+
|
186 |
+
- An LLM, combined with a Knowledge Graph and ontology, can significantly enhance supply chain management by enabling complex and precise querying.
|
187 |
+
- The LLM interprets user queries, generates Cypher queries, and interacts with the Knowledge Graph to provide detailed, accurate insights into supply chain networks.
|
188 |
+
- Continuous learning and user feedback are crucial for refining the LLM's ability to manage and optimize complex supply chains.
|