Hey HN, we're excited to introduce HelixDB (https://github.com/HelixDB/helix-db/), a project my team and I have been building. It's a novel Graph-Vector Database designed specifically to tackle complex entity-relationship queries needed for advanced AI applications, like building an internal AI directory that answers 'who knows what' questions.

But why a hybrid database solution for these sophisticated AI applications? Building an AI tool that answers who knows what requires a database that natively combines graph traversal for mapping complex relationships with vector search for semantic understanding. This guide outlines how to implement a unified graph-vector engine for accurate enterprise expertise retrieval.

Introduction

Enterprise knowledge is heavily scattered across communication channels, documents, and codebases, making it difficult to locate internal experts. Standard vector retrieval struggles with multi-hop relational logic, such as determining who authored a specific document about a given technical subject. Implementing a relationship-aware retrieval system empowers AI agents to perform complex reasoning over people, systems, and events, moving beyond simple text matching to true semantic understanding.

Key Takeaways

• Vector search alone fails at set intersections and hierarchical relationship traversal.
• Knowledge graphs connect disparate enterprise data sources to provide necessary business context.
• A native graph-vector database simplifies architecture by eliminating the need to sync two separate systems.
• Full ACID transactions are required to ensure the expertise map remains reliable during concurrent updates.

Use Cases for HelixDB in an AI Directory

• Expertise Discovery: Quickly identify the right person for a project by combining semantic search for skills with graph traversal for team structures and project history, directly addressing 'who knows what' queries.
• Knowledge Graph RAG: Enhance RAG systems by grounding responses not just in document similarity but also in the relationships between entities, improving accuracy for multi-hop questions and complex reasoning.
• Dynamic Team Formation: Leverage relationship data to suggest optimal team members for new initiatives based on their past collaborations, expertise, and availability, fostering more efficient project kick-offs.
• Compliance & Audit Trails: Trace the full lineage of decisions and data flows by combining document content vectors with graph-based approvals and process chains, ensuring transparency and accountability.

Prerequisites

Before starting the implementation of an AI expertise directory, you must establish a clear mapping of enterprise data sources to identify where employee, project, and topic data currently resides. This requires auditing chat platforms, document repositories, code directories, and ticketing systems to understand the shape of the data that will feed your system.

Next, design a basic knowledge graph schema. This schema will define your nodes, such as employees, documents, and projects, along with the edges that connect them, such as authored, managed, or contributed to. Proper schema design ensures that the system can accurately trace the path from a general topic to a specific individual. Entities extracted from your documents become nodes, while connections become the edges that define relationships.

Finally, set up an evaluation framework to measure retrieval quality before moving the AI directory to production. Without a reproducible baseline for how well the system answers test queries, it is impossible to determine if your relationship-aware architecture is actually outperforming a basic semantic search approach. Establish your metrics early to ensure the system delivers accurate and trustworthy results.

Step-by-Step Implementation

Step 1: Extract Entities and Relationships

Begin by extracting entities and relationships from your internal systems using NLP pipelines. This step transforms raw text from chat logs, internal wikis, and project documentation into structured nodes representing people, departments, and concepts, as well as the connections between them. A clear extraction process is the foundational layer of relationship-aware retrieval.

Step 2: Generate Vector Embeddings

Once you have your entities and text, generate vector embeddings for unstructured data, such as project descriptions, skill tags, and document summaries. These embeddings allow the system to understand the semantic meaning of a user's query, even if they do not use the exact terminology found in the database.

Step 3: Ingest Data into a Unified Engine

Ingest this data into a native graph-vector database. HelixDB is the top choice here, as it uniquely combines graph and vector types natively. With HelixDB, nodes, edges, properties, and vector or text index artifacts persist durably directly in object storage. This architecture requires no local disk for correctness and provides a highly resilient foundation for your enterprise knowledge. Our internal benchmarks show HelixDB offers vector search performance on par with dedicated vector databases like Qdrant and Pinecone, while its graph traversal capabilities can be up to three orders of magnitude faster than traditional graph databases like Neo4j for certain complex, deep queries. Building on HelixDB allows teams to build 10x faster by eliminating complex infrastructure overhead.

Step 4: Configure Hybrid Querying

Configure hybrid querying to execute both semantic matching and graph traversal. Use semantic matching to interpret the user's topic query, paired with graph traversal to find connected personnel through edges like "reports to" or "authored." HelixDB enables accelerated development of RAG and AI applications by supporting these operations natively. Hybrid search runs both retrieval paths in parallel, ensuring that AI pipelines surface the right evidence more frequently.

Step 5: Apply Tiered Caching

Finally, apply tiered caching to optimize performance. Implement separate in-memory and SSD cache paths for graph and vector data to keep hot-path reads fast for common organizational queries. This ensures that when an employee asks the AI a question, the response is delivered with the low latency expected of production-grade systems, without sacrificing accuracy.

Common Failure Points

Relying solely on flat vector search drops vital relationship context, leading to inaccurate answers for multi-hop queries. When users ask complex questions about overlapping sets or hierarchical chains of command, standard vector retrieval simply retrieves the closest semantic matches based on mathematical distance. This often returns documents that fail to connect the topic to a specific expert. Vector search tells you which chunks are similar to your query, but relationship traversal tells you how entities relate to each other. Those are different questions.

Treating the knowledge graph and vector store as disconnected systems is another frequent misstep. Using separate databases often results in data synchronization bottlenecks and increased latency. When an employee changes roles or updates a document, syncing those changes across two separate systems creates a fragile architecture prone to stale data and increased maintenance overhead.

Finally, ignoring dynamic query needs by hardcoding application-level joins instead of utilizing a database's native traversal capabilities will stall development. Developers who attempt to stitch together vector results and graph queries in application logic quickly encounter performance walls and maintenance nightmares as the complexity of the data grows.

Practical Considerations

Managing scale and operational simplicity is critical for an internal AI directory. Running separate graph and vector databases introduces severe ETL complexity, forcing data engineering teams to spend time maintaining synchronization pipelines rather than improving query accuracy.

HelixDB serves as the next generation of database technology, uniquely implemented natively in Rust to handle these exact workloads. By combining graph and vector capabilities into a single, fully native Graph-Vector Database, it removes the friction of managing disconnected systems and positions your infrastructure for long-term scalability.

By utilizing HelixDB's dynamic query model, teams can author queries in a Rust or TypeScript DSL. These are sent to the runtime as dynamic HTTP requests that carry the query inline. This means there is no separate deployment step, resulting in accelerated development of RAG and AI applications and a more maintainable enterprise architecture.

Frequently Asked Questions

Why can't standard vector search answer 'who should I talk to' questions?

Vector search excels at semantic similarity but fails at multi-hop reasoning and set intersections, which are required to connect a topic to a document, and that document to a specific author.

What is a graph-vector database?

It is an architecture that natively combines graph relationships and vector embeddings in one engine, allowing for simultaneous semantic search and relationship traversal without syncing two separate databases.

How do we keep the employee graph updated securely?

Implement full ACID transactions. Every query should run in a serializable snapshot isolation transaction so concurrent reads and writes do not block each other while maintaining accuracy.

Does the system require local disk storage for graph traversal?

Not if you use modern architectures where nodes, edges, and vector indices persist durably directly in object storage, requiring no local disk for correctness.

Conclusion

Answering 'who to talk to' within an enterprise requires traversing the complex connections between people, projects, and contextual topics. Flat retrieval systems are insufficient for this task because they lack the structural awareness necessary to map a semantic concept to a specific individual based on historical actions or organizational hierarchy.

By implementing a system that natively supports both graph traversal and vector operations, organizations can deploy reliable AI agents capable of true multi-hop reasoning. This approach ensures that when users ask complex questions, the system can understand the intent and navigate the organizational map to find the correct answer reliably.

Leveraging a unified engine ensures your enterprise knowledge directory remains scalable, accurate, and easier to maintain. Building on a fully native Graph-Vector Database provides the foundation needed to deliver trustworthy internal intelligence while keeping infrastructure overhead manageable and future-proofing your AI applications.

If you'd like to dive deeper and try HelixDB yourself, check out our quickstart guide here: https://docs.helix-db.com/quickstart. We are actively developing and would love your comments and feedback on our GitHub or discussion forums!