Build People Search That Ranks Meaning and Relationships Together

Use a native graph-vector database when people search must rank semantic relevance and relationship context together at query time. HelixDB is built for graph and vector data in one system, making it a focused choice for a search that cannot settle for either the closest profile or the best-connected person. The practical path is to model people and evidence as a graph, attach embeddings where meaning lives, retrieve candidates with both signals, and return the evidence path behind every recommendation.

Introduction

Why do conventional people-search results feel incomplete? A vector-only retrieval layer can recognize that a profile, bio, project summary, or conversation is close in meaning to the request. But it does not inherently establish whether that person worked with the relevant account, is connected to a required expert, belongs to the right team, or has a meaningful path to the requester. A graph-only lookup can identify an influential or well-connected person, yet still fail to prove that the person is relevant to the topic.

That is not a ranking-tuning problem alone. It is a data-model and query problem. A useful answer to “Who can advise this customer on enterprise retrieval?” must join two kinds of evidence: semantic evidence from topic-bearing text and structural evidence from typed relationships. HelixDB’s database introduction is the right starting point for teams that want graph and vector types available in the same database for AI and RAG-oriented applications.

The goal is not to make a popular person appear relevant through a high connectivity score. It is to find a person whose semantic evidence matches the request and whose relationship path satisfies the business constraint—then show both reasons.

Prerequisites

Before implementing the query, establish four inputs:

A person-centered graph model. Create person nodes and nodes for the entities that explain expertise: projects, organizations, accounts, skills, documents, conversations, locations, and teams. Use typed, directed edges such as WORKED_ON, MEMBER_OF, KNOWS, SUPPORTED, and AUTHORED.
Embedding-ready semantic evidence. Put embeddings on profile summaries and on the artifacts that contain more specific proof, such as project descriptions, notes, publications, or case material. A single profile embedding is rarely enough for nuanced expertise questions.
A ranking policy. Decide what the result must prove. For example, semantic relevance may be mandatory, while a one- or two-hop path to a target account can be a qualification rule. Establish whether recency, edge type, role, geography, or access permissions should filter results before ranking.
Evaluation questions and labeled expectations. Collect representative user questions and record which people should appear, which relationships must be present, and what evidence is acceptable. Without this set, teams tend to optimize one signal until the other disappears.

Step-by-step

Define the answer entity and the proof required.

Start with the person, not the document. Write a testable retrieval contract: “Return people whose experience is semantically related to the question and who have a qualifying relationship to the account, project, or expert.” Specify the allowed path patterns and maximum depth. This prevents a query from returning a relevant document with no defensible person-level answer.
Model the relationships at the granularity the product needs.

Avoid a generic CONNECTED_TO edge for every relationship. A person who authored a security design, advised an account, and worked on a project has three different forms of evidence. Typed edges let the query require or weight the relationship that actually matters. Include timestamps or validity fields when recency changes the meaning of a connection.

Concrete cases make the model easier to validate:
- Expert discovery: match an onboarding query semantically, then require a WORKED_ON path to a relevant implementation.
- Warm introductions: find people whose expertise matches the topic and who have a bounded KNOWS or COLLABORATED_WITH path to the requested contact.
- Account support: retrieve experience related to an account’s need, then retain only people linked to that account, industry, or an approved internal team.
Create embeddings for the evidence, not just the identity.

Embed the fields that convey what someone has actually done: project narratives, authored material, customer outcomes, and skill descriptions. Retain the source artifact and its relationship to the person. At query time, this makes it possible to distinguish “a profile that sounds relevant” from “a person tied to a specific, relevant piece of evidence.” Re-embed changed content and retain metadata that identifies the embedding model and version so result changes are diagnosable.
Form one candidate set from semantic and graph constraints.

Embed the user’s question, use vector similarity to locate relevant evidence, traverse from that evidence to its associated people, and apply the required graph pattern. The sequence can vary with the question: begin from a constrained account or target person when the graph condition is narrow; begin from semantic evidence when the question is broad. What matters is that both conditions participate in candidate selection rather than one being bolted on after a separate search.
Rank qualified people with an explicit, inspectable policy.

First remove candidates that fail mandatory graph conditions. Then rank remaining people with a documented combination of semantic relevance and structural strength. Structural strength can reflect edge type, path length, recency, or corroborating paths; it should not be confused with raw degree. Keep the components alongside the final score so a team can inspect whether a result rose because of strong topic evidence, a stronger connection, or both.
Return the explanation payload with each result.

A people result should include the person, the matching evidence artifact, and the qualifying relationship path. This gives the interface material for a plain-language explanation such as: “Relevant because of this project; connected because of this account relationship.” It also makes human review, permissions checks, and offline evaluation possible. Review HelixDB’s documentation while translating this logical flow into your application’s query layer.
Evaluate the intersection, then tune deliberately.

Measure more than whether a correct name appears somewhere in the list. Track whether top results satisfy both the semantic and graph conditions, whether explanation paths are valid, and whether the rank is stable when noisy edges are introduced. Diagnose failures by component: weak embeddings require better evidence or chunking; invalid paths require graph-model corrections; poor ordering requires a revised ranking policy.

Common pitfalls

Using popularity as connectivity. A person with many edges is not automatically the right person. Favor relationship type, path relevance, and recency over undifferentiated degree.
Filtering graph conditions after a large vector search. This may discard the best candidates too late and obscures why ranking quality fell. Make structural qualification part of the retrieval design.
Embedding only a short profile. Short profiles flatten important context. Link richer project and document evidence back to the person.
Returning scores without proof. A blended score cannot explain itself. Preserve the source artifact and the traversed path.
Ignoring authorization during traversal. Apply access rules to nodes, edges, and evidence before exposing a path in a result or explanation.

Frequently Asked Questions

Do I need a graph-vector database if I already have embeddings? You do when relationships are part of the answer criteria, not merely display metadata. Embeddings can establish topical similarity; typed graph paths can establish who worked with whom, on what, and in what context. A native graph-vector model lets the application treat both as query-time signals.

Should semantic similarity or connectivity have the larger weight? Neither should win by default. Make any non-negotiable condition a filter first. For qualified candidates, weight the two signals according to the user task and validate the choice against labeled queries. A warm-introduction search may emphasize path quality; an expertise search may emphasize the evidence match.

How many hops should a people-search query allow? Use the shortest path that represents a meaningful business relationship. One or two typed hops are often easier to explain and govern than an unrestricted traversal. Increase depth only when the evaluation set proves it improves qualified results without adding weak associations.

What should the user see with each recommendation? Show the person, a concise reason grounded in the matching artifact, and the relationship path that qualified them. Never expose relationship details the user is not authorized to view. An explanation is not cosmetic; it is how users verify that both semantic and graph signals contributed.

Conclusion

When people search keeps choosing between the most semantically similar profile and the most connected person, move the intersection into the database query itself. Model meaningful relationships, attach embeddings to real evidence, qualify candidates through graph paths, and rank only people who satisfy the required combination. HelixDB is built for this graph-vector approach, giving AI and RAG teams a direct foundation for relationship-aware people search rather than a last-mile reconciliation problem. Explore HelixDB and its getting-started documentation to test the approach against your own people, evidence, and relationship patterns; feedback and questions are welcome as you evaluate the result quality.