How NASA is building its 'People Graph': a knowledge graph with LLMs to map talent and projects

NASA has developed an internal system called 'People Graph', a people-analytics initiative that combines graph databases and language models (LLMs) to identify experts, build high-performing teams and detect skills gaps across the agency. The project was presented in a community call by members of NASA's People Analytics team: David Meza (chief of the People Analytics branch and lead for human capital analytics), Madison Ostermann (data scientist and data engineer) and Katherine Knott (data scientist), who explained the system's technical architecture, gave a live demo and answered questions from the audience.

The underlying motivation is that personnel data in traditional relational databases — rows, columns, joins — does not capture well the complex relationships that exist in an organization the size of NASA. A graph, by contrast, connects people directly to their skills, their projects and their career paths, making it possible to answer questions such as who has worked on very similar AI projects at different NASA centers, which employees have interdisciplinary AI/ML experience, or where skills gaps need to be filled. For this, the team chose the graph database Memgraph, which lets them query and traverse multi-hop relationships in real time.

On infrastructure, the entire solution runs on NASA's secure internal AWS cloud. Memgraph runs in Docker containers on EC2 instances, alongside an on-premise LLM server (Ollama), also on EC2, used both to extract skills from résumés and to answer chatbot queries. Structured and unstructured data are stored in Amazon S3 buckets, and ingestion into Memgraph is carried out with Cypher using the GQLAlchemy library. One relevant aspect is that Memgraph's enterprise license allowed NASA to segment the data across multiple databases, keeping personally identifiable information (PII) isolated and protected.

Data ingestion combines three main sources: personnel data from NASA's internal personnel data warehouse, AI/ML project data drawn from the agency's AI use case inventory, and skills extracted from team members' résumés. For the AI/ML projects, the team calculated cosine similarity between project descriptions to create similarity relationships between them as a graph property. Résumés, meanwhile, were processed with Ollama to extract skills automatically, without needing manually labeled datasets; those extracted skills are then incorporated as nodes linked to each employee.

The graph schema is a labeled property graph that includes nodes for employees, job titles, occupational series, pay grades, organizations (such as MISO, the mission support organization), NASA centers, projects (with the unstructured description as a node property), education level, university, degree program, major and extracted skills. All of these nodes were additionally labeled as 'Entity' to enable vector indexing and the use of GraphRAG (graph-based retrieval-augmented generation).

During the live demo, using sample data and anonymized PII, the team showed real Cypher queries capable of addressing three types of need: locating experts in mission-critical domains or capabilities; generating high-level descriptive reports for leadership on workforce composition, capability distribution and organizational dynamics; and detecting near-duplicate projects based on similarity scores. They also presented a RAG-based chatbot that allows the graph to be queried in natural language.

That chatbot's pipeline works as follows: an LLM extracts the key information from the user's question; then a 'modified pivot search' is run on each piece of information separately (not combined), returning multiple relevant nodes; from those nodes, a 'relevance expansion' is performed, hopping the desired number of hops and returning the start node, the end node and the relationship between them, which form what are called 'context triplets'. GraphRAG passes those context triplets along with the original question to Ollama to generate a context-aware answer. The embeddings are stored directly in Memgraph and indexed by cosine similarity. The system is still being refined, with plans to test reranking and to improve the embedding models.

On scale, the current graph has around 27,000 nodes and 230,000 edges, of which some 18,000 nodes correspond to employees. NASA's stated goal is to scale the People Graph to more than 500,000 nodes and millions of edges. Next steps include improving data quality and disambiguation (for example, mapping 'JS' to 'JavaScript'), automating the data pipeline, expanding the graph to include employees' learning goals, preferred project types and skill classifications, and improving Cypher query generation and RAG accuracy through the model context protocol (MCP).

The Q&A session surfaced additional interesting details. On extracting skills from unstructured text, Madison explained that before LLMs the team used custom named entity recognition (NER) models with spaCy, which required manually labeled training sets and involved a great deal of work; LLMs have made this information extraction far more feasible. On the design of the graph schema, both Madison and David agreed that they did not start from a complete predefined schema: they began with an intuitive understanding of how people connect to their attributes and their work, and added latent relationships — such as similarity between projects — as they explored the data, taking advantage of the flexibility inherent to knowledge graphs.

One of the most revealing questions was why they chose Memgraph instead of alternatives such as Neo4j. David replied that he has been working with different graph databases for more than ten years — he used Neo4j starting in 2015, when it was still a command-line interface — and that he prefers labeled property graphs over RDF, which naturally inclined him toward Neo4j. However, Neo4j's cost proved unaffordable for his current environment (something he says he has already communicated directly to the Neo4j team). On discovering Memgraph, he found that it uses Cypher just like Neo4j, but also offers native Python support (versus Neo4j's Java-only approach), which fit a team split between Python and R. That allowed them to migrate without a steep learning curve, retaining the property-graph capabilities they had already mastered, at a considerably lower cost.

On building the cosine similarity relationships, Madison explained that they iterated over the project nodes, compared the embeddings of their descriptions and created relationships between projects that exceeded a given similarity threshold; those embeddings are stored as node properties in Memgraph and used with vector search indexes to find similar nodes and enable fuzzy searches. As for attributes on relationships (for example, proficiency level in a skill or years of experience), they acknowledged that some relationship attributes already exist, but that more experimentation is still needed to quantify aspects such as experience; although RAG does consider relationship properties, it is not the main focus for now, even though they see potential in it.

On data ambiguity and duplication — for example, variations such as 'JavaScript' and 'JS' coming from different sources — David noted that LLMs help make sense of those variations, and that they also use prompt engineering and context awareness within the RAG environment to steer the model toward consistent representations of synonyms. Madison added that, although LLMs help with this, they also factor semantic similarities into their accuracy metrics when evaluating the extracted skills, in order to account for those variations. On expected scale, David noted that the current database is around 27,000 nodes and 230,000 edges (including some 18,000 employee nodes, without being exhaustive), and mentioned that a previous, similar project comfortably handled around 500,000 nodes and between 1.5 and 2 million relationships, a scale he still considers 'small' for a graph.

Taken together, NASA's case illustrates a pattern that is becoming common in advanced enterprise analytics: combining a graph database with local LLMs (on-premise, for security reasons and because of sensitive personnel data) to automate the extraction of knowledge from unstructured sources (résumés, project descriptions) and then expose it through structured queries (Cypher) and natural language (GraphRAG). The emphasis on cost as a decisive factor in the technology choice, the preference for tools that do not force the team to retrain, and the strategy of isolating PII in separate databases within the same enterprise license are practical details that could prove useful for any large organization considering a similar people knowledge graph project.