graphs, vectors and generative AI
all relationships are built in advance in the graph, so operations requiring real-time calculations are minimized;
graphs require only a small amount of data, which simplifies the cold start of recommendations for a new user;
visualization and a clear explanation of why a particular product item was chosen for recommendation is available;
The data is easily divided by product category, user gender and other parameters. Only those data that are really necessary can be included in the calculation;
graphs can take into account history and be dynamic;
relationships between products are able to find what people actually buy together, so the recommendation system will not recommend a second sunscreen to the user based on his purchases, but sunglasses and beach items;
For particularly tricky algorithms, you can use graph neural networks, feeding them a subgraph associated with a specific product or user.
As a calculation engine and data storage, the choice fell on Neo4j, as the most popular graph database, rich in functionality for recommendations, having a wide community and a free version.
Graph RAG
In an ideal world, all recommendations could be built using collaborative filtering, but in the real world there are cases that collaborative filtering cannot completely cover. A striking example is the sale of auto parts. The user comes with a specific breakdown of a car of a specific brand of a specific year of manufacture. He also wants to be able to choose the cheapest spare part, and is ready to take a non-original one. And in order to make a recommendation, it is necessary not only to find a similar profile, but also to understand how suitable the profile’s recommendations are for a specific car brand, and which non-original spare parts are applicable in this case and which are not.
Here the addition of other columns comes to the rescue – what spare parts or brands are bought for certain cars and types of repairs, in what cases returns occur. Using the graph as a RAG – an external knowledge base for generative AI – made it possible not only to find similar profiles, but also to take into account similar relationships.
Not just a count
The graph, with the help of relationships, covers most of the recommendation algorithms, but one still required the use of additional tools – this is the algorithm for similar products. Not just goods that are bought as interchangeable, but those with a large set of similar characteristics. They could be placed in the properties of the graph nodes, but to speed up the calculations we preferred to use vector search. For each product, significant properties were selected, and then, based on vector similarity, each product received the top K similar ones, and this similarity was transferred to the graph in the form of connections.
Difficulties on the path to success. Dynamic Queries
When we started work, we initially saw our work as follows: prepare a specific query for each recommendation algorithm and use it in the recommendation process. But when it turned out that the business wanted to have a flexible interface for creating complex recommendations, for example, the first 3 products are the most similar, then the 3 most popular and so on, and everything should happen without our intervention in the code, we had to seriously think about the solution. As a result, we decided that queries to the database should be built dynamically and implemented a smart internal query designer for the Neo4j database, which understands the rule parameters and collects the necessary elements into the query.
The product has the ability to assemble a recommendation panel from several basic blocks at once, and also apply additional filtering and sorting to their totality. In this case, we will have separate queries for the selected algorithms and one additional algorithm that will collect the result into a single panel, taking into account filters and sorting.
And now the assembled recommendation algorithm is ready to go to the database to extract data, but until the time comes to use it, it will be stored in Redis.
Difficulties on the path to success. Performance
Recommendations must work at such a speed that they can respond to every user action before the user leaves the page or scrolls the panel with the recommendation out of visibility. Therefore, we had to work hard on how to ensure quick delivery. Neo4j claims to have much higher performance compared to SQL databases in tasks where multiple joins are required. But better performance doesn't mean everything will fly out of the box. It was very important to build queries and connections correctly, and we were able to find useful guides on this topic here And here.
The speed is affected by where to place the property – in a node or in a connection between nodes. Connections between nodes are initially found faster. But, if you need to access data through several connections, for example, for a specific user, find his receipts, the goods that he bought in these receipts, and filter these products by a certain category or property, then it may be more convenient to build a connection from the user directly to endpoint or give the user node an additional “preferred category” characteristic. When building connections, you should not get carried away with creating supernodes; these are nodes with a particularly large number of connections. These could be user gender nodes – male and female, sharing connections from all users of the store. This is an antipattern that greatly slows down the database.
PS If you are interested in news about generative AI, LLM, multi-agents, I talk about it in my Telegram channel https://t.me/generative_ai_ru
