Beyond RAG: AI Search Using Graph DBs

Graph DBs is the criminally underexplored sibling of Relational Databases in AI search. They have 2 properties that sets them up to be incredible options for better AI search that no one is attempting to see.

1. Natural Language & Simplicity:

Graph DBs are nothing more than dots and Lines. They create a web of interconnected relationships between pieces of information. Google has a massive knowledge graph that stores billions of facts about people, places, events, and things. So the next time you ask google, "How tall is the Eiffel Tower?", the answer you get is extracted from a massive Graph DB.

With simplicity, comes an easy way for any human to read Graph DBs in natural language and understand what is going on.

Can you tell me what this relational DB is saying?

Not really? How about its Graph DB counterpart?

Its definitely a lot easier to understand the Graph DB, and so should be the same case for Large Language Models. This means better AI reasoning even with complex data.

Backed by Graph Theory:

Mathematically, Graph DBs just make sense. Their backed by 50+ years of Machine learning knowledge like dijkstra's algorithm and A*. These transversal algorithms can map out our answers to AI search queries like following a trail of clues, right to the culprit.

Imagine if your codebase history was converted into a knowledge graph, with all dependencies, variables, classes/modules, and functions/methods interconnected by function calls, parameter passing, inheritance, and shared relationships.

SIMPLE EXAMPLE:

FROM

class Person:
    def __init__(self, name: str, age: int):
        self.name = name
        self.age = age

    def greet(self):
        return f"Hello, my name is {self.name} and I am {self.age} years old."

class Employee(Person):
    def __init__(self, name: str, age: int, employee_id: str):
        super().__init__(name, age)
        self.employee_id = employee_id

    def get_employee_id(self):
        return self.employee_id        

TO

Now Imagine if a software intern messed around with your code behind your back and you get an error the next time you run it!

ERROR:

AttributeError: 'Employee' object has no attribute 'employee_id'        

How your Graph DB + LLM Assistant will work:

• "I am a function named get_employee_id in the Employee class. My job is to return the employee_id of an employee."

• "When the Employee class is created, my buddy, the __init__ method, should set up the employee_id so that I can return it when asked."

• "Wait a minute, So 'employee_id' is supposed to be initialized by 'Employee.___init__, BUT i can't find 'employee_id anywhere in the method!
• "Huh, there is an attribute named 'employe_id' though, could this just be a spelling mistake?

Suggested Fix: "Could you please check the spelling in the __init__ method of Employee? It looks like there is a typo there! The correct name should be employee_id, but you wrote employe_id."

The LLM is able to use transversal algorithms to create a small Relevant Sub-graph where it could backtrack with its reasoning, and find the crux of the problem.

Conclusion

Graph DB is the toy long forgotten in this new Gen AI world. Replaced by shiny new things like word embeddings and re-ranking. But, Graph DBs are actually the perfect choice for grounding AI models. This is exactly why I am working on AffinityAI, an open-source Python package that simplifies graph database storage and querying. Stay tuned.