Swinburne University of Technology

Nakul Nambiar

Amir Aryani

<figure>
<img
src="https://cdn-images-1.medium.com/max/1024/1*Gzmbpq5qJUz2W1zpHd1XGA.png" />
<figcaption>Created using DALL-E on 28 Jan 2024</figcaption>
</figure>

### Authors

* Nakul Nambiar (ORCID: [0009-0009-9720-9233](https://orcid.org/0009-0009-9720-9233))
* Amir Aryani (ORCID: [0000-0002-4259-9774](https://orcid.org/0000-0002-4259-9774))

Knowledge graphs, which offer a structured representation of data and
its relationships, are revolutionising how we organise and access
information. With large amounts of data, it sometimes becomes difficult
to draw insights from it. This blog article examines how to combine
Neo4j, a graph database, with OpenAI's Retrieval-Augmented Generation
(RAG) model to build a robust knowledge management system.

LLMs are pre-trained models and generate outputs based on the prompts we
pass them. Sometimes, the LLM results are precisely what you need, but
other times, they just return random facts from their training data.
Retrieval-augmented generation (RAG) is an AI framework that tries to
improve the response of the LLM models by providing context knowledge
from external sources. Additional benefits of RAG include:

- Enables getting insights into private data without sharing or using it
  for training.
- Reduces the chances of 'Hallucination' and incorrect responses.
- Reduces the need to train the model on new data continuously.

### Sample Data

For our exercise, we will use OpenAI, combined with the Australian
National Graph Database, to create an RAG pipeline.

The [Australian National Graph
Database](https://researchgraph.org/national-graph/) is a vast knowledge
graph with around 11 million nodes. We can't possibly fit all the data
into the OpenAI context. So, in the first phase, we will retrieve a
subset of the graph and then use this graph as a context for the OpenAI
and to answer prompts.

We use a Virtual Machine (VM) with a Neo4j server running the graph
database as a Neo4j server. The [graph
schema](https://researchgraph.org/schema/) includes five primary node
types that describe the research ecosystem: Researchers, Publications,
Datasets, Grants and Organisations.

<figure>
<img
src="https://cdn-images-1.medium.com/max/1024/1*UocexTQHeuX3_VAwSJ03CQ.png"
alt="Research Graph Schema: https://researchgraph.org/schema/" />
<figcaption>Research Graph Schema. <a
href="https://researchgraph.org/schema/">https://researchgraph.org/schema/</a></figcaption>
</figure>

### Step 1

Firstly, we must establish the connection to the Neo4j database. Also,
you might notice that we use an OpenAI API key. This key can be
generated at the OpenAI portal. A tutorial is available
[here](https://elephas.app/blog/how-to-create-openai-api-keys-cl5c4f21d281431po7k8fgyol0).

    import os
    import json
    import pandas as pd
    import configparser
    from neo4j import GraphDatabase

    config = configparser.ConfigParser()
    config.read('config.ini')

    # Set the OpenAI API key env variable manually
    os.environ["OPENAI_API_KEY"] = config['DEFAULT']['openai-key']

    # DB credentials
    url = config['DEFAULT']['url']
    username = config['DEFAULT']['username']
    password = config['DEFAULT']['password']

### Step 2

We get a subset of the graph from the larger dataset by querying Neo4j.
The output of the graph is retrieved in JSON format.

    def run_query(cypher_query):
        with GraphDatabase.driver(url, auth=(username, password)) as driver:
            with driver.session() as session:
                result = session.run(cypher_query)
                return result.data()

    cypher_query = """
    MATCH (n:organisation)-[r]-(g:grant)
    where g.source='arc.gov.au' RETURN * LIMIT 100
    """

    result = run_query(cypher_query)

Note: We have used a limit of 100 nodes in the response to limit the
size of the returning JSON file. This would impact the LLM functionality
if it exceeds the context window size.

We create a system prompt by providing background knowledge about the
graph database and the task. Along with it, we pass the JSON subgraph
as context.

    system_prompt = f'''
    You are a helpful agent designed to fetch information from a graph database.
    Data
    {json.dumps(result)}

    This is the output of the Neo4j cypher which returns nodes and relationships. n is the organisations, g is the grants
    and r is the relationships between the grants and organisations.

    Based on this data answer the user prompts and return the output as json.

    '''

Users can then enter the prompt to get insights from the subgraph. For
example, in the prompt below, we are trying to find the grant with the
most relationship to organisations.

    prompt = "Help me find the grants which is related to the most organisations"

### Step 3

We pass the system and user prompts to the OpenAI model. In this case,
we use "gpt-4--1106-preview". More information is available on the
[OpenAI page on Models](https://platform.openai.com/docs/models).

    from openai import OpenAI
    client = OpenAI()

    def define_query(prompt, model="gpt-4-1106-preview"):
        completion = client.chat.completions.create(
        model=model,
        temperature=0,
        response_format= {
            "type": "json_object"
        },
        messages=[
            {
                "role": "system",
                "content": system_prompt
            },
            {
                "role": "user",
                "content": prompt
            }
            ]
        )
        return completion.choices[0].message.content

OpenAI provides the grant details with the most connections to
organisations as a JSON output.

    print(define_query(prompt))

### Output

This is the output provided by OpenAI RAG.

    {
      "grants": [
        {
          "arc_for_primary": "1117",
          "local_id": "LP200301123",
          "start_year": "2023",
          "purl": "http://purl.org/au-research/grants/arc/LP200301123",
          "source": "arc.gov.au",
          "type": "grant",
          "arc_scheme_name": "Linkage Projects",
          "title": "Making Australia resilient to airborne infection transmission.",
          "arc_announcement_administering_organisation": "Queensland University of Technology",
          "url": "http://dataportal.arc.gov.au/NCGP/API/grants/LP200301123",
          "arc_funding_at_announcement": "898013",
          "arc_grant_status": "Active",
          "arc_for": "040101,1117,111705,120404",
          "r_number": "158880661",
          "end_year": "2026",
          "participant_list": "Lidia Morawska,Duzgun Agdas,Laurie Buys,Keith Grimwood,Graham Johnson,Guy Marks,Alexander Paz,Thomas Rainey,Zoran Ristovski,Kirsten Spann,Bo Xia,Patrick Chambers,Shaun Clough,Stephen Corbett,Charles dePuthod,Neal Durant,Travis Kline,Peter McGarry,Ross Mensforth,Clive Paige,John Penny,Brad Prezant,Uma Rajappa,David Ward,Scott Bell,Giorgio Buonanno,Mark Jermy,Jose Jimenez,Claire Wainwright,Sandra Glaister,greg Bell,Louisa O'Toole",
          "key": "arc/LP200301123",
          "related_organisations_count": 24
        }
      ]
    }

We can compare it visually with the graph from Neo4j and see that RAG
provided the correct output.

<figure>
<img
src="https://cdn-images-1.medium.com/max/1024/1*PkIQl8fupR-TdiwppqdJkg.png" />
</figure>

We have tested this mini pipeline with other examples, and the
simplicity of the pipeline makes it functional as long as the size of
the subgraph produced in Step 2 does not exceed the context window of
the OpenAI model.

### Conclusion

The integration of OpenAI RAG and Neo4j paves the way for innovative
solutions in knowledge graph applications, and recommendation systems.
RAG is efficient in grounding the LLM on the most recent data, and
verified information and reduces the expense of retraining the model
when new data is available.

![](https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=3a183df816ce){width="1"
height="1"}


Authors  Nakul Nambiar (ORCID: 0009-0009-9720-9233) Amir Aryani (ORCID: 0000-0002-4259-9774)  Knowledge graphs, which offer a structured representation of data and its relationships, are revolutionising how we organise and access information.

Mini RAG using Neo4j

University of Glasgow

Roderic Page

![Neo4j](https://lh3.googleusercontent.com/-f30vIZ2GNN0/VcTIPJq94zI/AAAAAAAAD_g/Wz7AU7qFzTs/neo4j.png?imgmax=800 "neo4j.png"){border="0"
width="128" height="139" style="float:right;"}

I\'ve been playing with the graph database [Neo4J](http://neo4j.com) to
investigate aspects of the classification of taxa in GBIF\'s backbone
classification. Neo4J is a graph database, and a number of people in
biodiversity informatics have been playing with it. Nicky Nicolson at
Kew has a nice presentation using graph databases to handle names
[Building a names
backbone](http://www.slideshare.net/nickyn/building-a-names-backbone),
and the Open Tree of Life project use it in their [tree
machine](http://opentreedevblog.com/tag/neo4j/).

One of the striking things about Neo4J is how much effort has gone in to
making it easy to play with. In particular, you can create
[GraphGists](http://gist.neo4j.org), which are simple text documents
that are transformed into interactive graphs that you can query. This is
fun, and I think it\'s also a great lesson in how to publicise a
technology (compare this with RDF and SPARQL, which is in no way fun to
work with).

I created some GraphGists that explore various problems with the current
GBIF taxonomy. The goal is to find ways to quickly test the
classifications for logical errors, and wherever possible I want to use
just the information in the GBIF classification itself.

The first example is a version of the \"papaya plots\" that I played
with in an [earlier
post](http://iphylo.blogspot.com/2013/08/cluster-maps-papaya-plots-and-trouble.html)
(see also an unfinished manuscript [Taxonomy as impediment: synonymy and
its impact on the Global Biodiversity Information Facility\'s
database](https://github.com/rdmpage/taxonomy-GBIF-manuscript)). For
various reasons, GBIF has ended up with the same species occuring more
that once in its backbone classification, usually because none of its
source databases has enough information on synonymy to prevent this
happening.

As an example, I\'ve grabbed the classification for the bat family
Molossidae, converted it to a Neo4J graph, and then tested for the
existence of species in different genera that have the same specific
epithet. This is a useful (but not foolproof test) of whether there are
undetected synonyms, especially if the generic placement of a set of
species has been in flux (this is certainly true for these bats). If you
[visit the gist](http://gist.neo4j.org/?a91e351279438d2ec1e6) you will
see a list of species that are potential synonyms.

A related test catches cases where one classification treats a taxon as
a subspecies whereas another treats it as a full species, and GBIF has
ended up with both interpretations in the same classification (e.g.,
[the butterfly species *Heliopyrgus margarita* and the subspecies
*Heliopyrgus domicella
margarita*](http://gist.neo4j.org/?e1552e40451ac0474548)).

Another [GraphGist](http://gist.neo4j.org/?4a53f02c1b7fff9710c9) tests
that the genus name for a species matches the genus it is assigned too.
This seems obvious (the species *Homo sapiens* belongs in the genus
*Homo*) but there are cases where GBIF\'s classification fails this
test, such as the genus *Forsterinaria*. Typically this test fails due
to problematic generic names (e.g., homonyms), incorrect spellings, etc.

The last test is slightly more pedantic, but revealing nevertheless. It
relies on the convention in zoology that when you write the authorship
of a species name, if the name is not in the original genus then you
enclose the authorship in parentheses. For example, it\'s *Homo sapiens*
Linnaeus, but *Homo erectus* (Dubois, 1894) because Dubois originally
called this species *Pithecanthropus erectus*.

Because you can only move a species to a genus that has been named, it
follows that if a species is described before the genus name was
published, then if the species is in that newer genus the authorship
must be in parentheses. For example, the lepidopteran genus
*Heliopyrgus* was published in 1957, and includes the species *willi*
Plötz, 1884. Since this species was described before 1957, it must have
been originally placed in a different genus, and so the species name
should be *Heliopyrgus willi* (Plötz, 1884). However, GBIF has this as
[*Heliopyrgus willi* Plötz, 1884](http://gbif.org/species/1950651) (no
parentheses). The
[GraphGist](http://gist.neo4j.org/?dae6d15551eda2d7ca12) tests for this,
and finds several species of *Heliopyrgus* that are incorrectly formed.
This may seem pendantic, but it has practical consequences. Anyone
searching for the original description of *Heliopyrgus willi* Plötz,
1884 might think that they should be looking for the text string
\"Heliopyrgus willi\" in literature from 1884, but the name didn\'t
exist then and so the search will be fruitless.

I think there\'s a lot of scope for deveoping tests like these,
inclusing some that m make use of external data as well. In an earlier
post ([A use case for RDF in
taxonomy](http://iphylo.blogspot.com/2013/08/a-use-case-for-rdf-in-taxonomy.html)
) I mused about using RDF to perform tests like this. However Neo4J is
so much easier to work with I suspect that it makes better sense to
develop standard queries in it\'s query language (CYPHER) and use those.


I've been playing with the graph database Neo4J to investigate aspects of the classification of taxa in GBIF's backbone classification. Neo4J is a graph database, and a number of people in biodiversity informatics have been playing with it. Nicky Nicolson at Kew has a nice presentation using graph databases to handle names Building a names backbone, and the Open Tree of Life project use it in their tree machine.

Rogue Scholar Beiträge

Mini RAG using Neo4j

Testing the GBIF taxonomy with the graph database Neo4J