Building a Personal Knowledge Graph for a Portfolio AI Assistant

A developer outlined an approach to building a personal knowledge graph that powers a portfolio AI assistant, using a minimal ontology of entities like Person, Project, Technology, Role, Outcome and Source connected by typed relationships such as BUILT, USES and CONTRIBUTED_TO. The writeup recommends a hybrid retrieval pipeline that combines vector search for semantic similarity with limited graph traversal for relationship questions, while storing source URI, extraction version, timestamp and review status to separate verified facts from model-extracted candidates. It also details a response contract requiring answers to cite project URLs, distinguish individual roles from team outcomes, abstain when evidence is insufficient, and exclude private client records and credentials from public indexes.

Originally published on PkLavc https://pklavc.com/blog/en/tech/personal-knowledge-graph-portfolio-ai-assistant/ . Start with a small ontology: Person, Project, Technology, Role, Outcome and Source. Relationships might include BUILT, USES, CONTRIBUTED TO, DEMONSTRATES and DOCUMENTED BY. Avoid importing every phrase into a node. The useful graph is the smallest structure that answers questions the portfolio actually receives. Store source URI, extraction version, timestamp and review status. Separate directly verified facts from model-extracted candidates. A confidence score is not proof. For subjective or quantified claims, preserve the exact supporting context and require human review before making it public. Vector retrieval is useful for semantic similarity and finding relevant project descriptions. Graph traversal helps with relationship questions: which projects use a technology, what evidence connects a skill to an outcome, or which components belong to one system. A hybrid pipeline can retrieve candidate text, follow a small number of typed edges and return both the source snippets and relationship path. Do not assume a graph is always better. For a handful of pages, structured JSON or relational tables plus search may be simpler to maintain. Add a graph store when multi-hop questions, entity disambiguation or relationship updates justify the operational cost. GraphRAG systems can also involve costly extraction and indexing; measure answer quality against a simpler baseline. Build a response contract: answer only from retrieved evidence, cite project URLs near claims, distinguish role from team outcome and say when the portfolio does not contain enough information. If the graph has conflicting versions, prefer the latest reviewed source and expose the conflict rather than silently combining them. Do not let the language model create new edges during a public answer. Index only content intended for public disclosure. Exclude private client records, credentials, personal contact data and confidential repository content. Treat user-provided queries as untrusted, authorize source access before retrieval and avoid exposing hidden graph metadata through prompts or citations. Provide deletion and correction paths so outdated facts can be removed from indexes and cached summaries. Create questions with known supporting pages and expected citations. Measure entity resolution, evidence recall, citation correctness, unsupported-claim rate, abstention quality and latency. Include adversarial prompts that ask it to exaggerate ownership or disclose private work. Re-run this set whenever extraction prompts, graph schema or retrieval rules change. Continue reading: Full technical article on PkLavc https://pklavc.com/blog/en/tech/personal-knowledge-graph-portfolio-ai-assistant/ Explore more technology articles: PkLavc Tech Blog https://pklavc.com/blog/