A portfolio assistant should answer questions about projects, technologies and outcomes without inventing experience. Plain vector search can retrieve a relevant paragraph, but it may not reliably connect a project to its components, role, dates and public evidence. A small knowledge graph can make those relationships explicit, provided every claim remains traceable to its source.
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.
| Graph item | Example | Evidence to retain |
|---|---|---|
| Entity | ESP32 telemetry project | Stable ID, canonical URL and last verified date |
| Relationship | Project USES MQTT | Source passage or repository file that supports the edge |
| Claim | Reduced manual reporting effort | Whether measured, self-reported or an intended result |
| Technology | FastAPI | Project association and evidence; not an inferred proficiency score |
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.
Related: RAG pipelines, agent memory boundaries and local LLM architecture.
A personal knowledge graph is valuable when it links portfolio claims to explicit relationships and verifiable sources. Start with a small model, preserve provenance, combine graph traversal with text retrieval only when it helps, and let the assistant abstain. The goal is not to make a bot sound more confident; it is to make each answer easier to verify.