Originally published on PkLavc.
Model the portfolio as claims with evidence
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.
Keep provenance on every assertion
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.
Use graph and vector retrieval for different questions
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.
Answer with citations and abstention
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.
Protect personal and private information
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.
Evaluate the assistant as a retrieval system
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
Explore more technology articles: PkLavc Tech Blog
Top comments (0)