Great work, and interesting to see Knowledge Graphs in a production setting. Why did you choose a Knowledge Graph as the backend? How is the graph modeled. Do you use existing Graph Query languages, or did you have to create your own?
Right now, we've focused on normalizing several key entities (e.g. organizations including parent/subsidiary relations, technologies, people, and job functions), and capturing the relations between these as well as additional useful metadata like location and industry.
From a backend implementation standpoint, this is currently implemented as structured relational tables for query performance and simplicity (e.g. count up all teams mentioning pytorch in job posts including rolling up across parent subsidiaries and sort by the biggest organizations descending).
Future direction here is TBD as we expand the sources that we cover and types of queries that can be computed across these sources.
There's been a lot of attempts at building high-quality public knowledge graphs that haven't hit escape velocity.
We're focusing on a structured, commercially relevant subset of the problem as a starting point to generate a critical mass of usage and funding that will enable us to build the bigger vision: a highly structured, up-to-date, and trusted repository of all the facts about the world that is easy to browse, query, and integrate programatically into all the relevant workflows (including for grounding LLM's)