Skip to content

The Problem With How Knowledge Is Stored Today

treedinteractive edited this page Jun 28, 2026 · 3 revisions

Every knowledge system on the market forces the same compromise: vectors or structure, pick one.

Vector databases (Pinecone, Weaviate, Chroma, Qdrant) give you fast similarity search over a flat index of points. That's it. There are no relationships between results, no provenance, no structure. You get a ranked list and everything else — why these results relate, whether they contradict each other, whether they've been tampered with — is your problem to solve in application code.

Knowledge graphs (Neo4j, Amazon Neptune) give you explicit structure and traversal. But someone has to author every edge. Someone has to design the schema. Someone has to run an extraction pipeline. The graph is only as complete as the human or NLP model that built it, and it can't answer "what's semantically similar?" without bolting on a vector store as a sidecar.

Hybrid systems bolt the two together and inherit both bug surfaces. The vector store and the graph disagree, and the application layer mediates. There is no single source of truth.

RAG pipelines chunk documents, embed chunks, retrieve top-k, and stuff them into an LLM context window. Chunk boundaries destroy context. Results have no relationship to each other. There's no deduplication, no contradiction detection, no provenance. Two chunks can say opposite things and RAG surfaces both without noticing.

GraphRAG (Microsoft) improves on naive RAG by building a knowledge graph via LLM extraction. But the graph quality depends on which LLM did the extraction. It's non-deterministic, expensive to build (every document requires LLM API calls), and static once constructed. It's still two separate systems coordinated by a query layer.

SERAPH was built because none of these are substrates. They're all assemblages of parts that don't share a source of truth.

Clone this wiki locally