Converting your RAG data to KAG knowledge graphs
Converting RAG data into a KAG knowledge graph means taking the passages you already extracted and linking them - people, decisions, dates, causes - into a sequenced train of thought, so an AI can reason across years of your material the way a colleague who lived it would.
RAG retrieves; KAG connects
RAG - retrieval-augmented generation - finds the passages that match a question. That is necessary and not enough when the answer is a story across files: why a policy changed, how a product decision cascaded, what you learned in year twelve that reframes year three. KAG - knowledge-augmented generation over a graph - starts from those same passages and adds structure: entities, relations and an order you can walk. Conversion is still the foundation. Without honest chunks there is nothing true to link. The graph is what turns a pile of good passages into something closer to memory.
Forty years of experience, as data
Imagine sitting with a model and narrating four decades of your career - every project, every failure, every hard-won rule of thumb. That conversation is slow and incomplete. The practical substitute is the corpus you already keep: notes, decks, contracts, emails, recordings, post-mortems. Converted into overlapping passages with vectors, that pile becomes searchable. Sequenced into a knowledge graph - who decided what, after which incident, under which constraint - it becomes a train of thought: not forty years spoken aloud in one sitting, but forty years walkable, so the model can follow the chain instead of guessing a plausible ending.
What conversion has to give the graph
A knowledge graph built on empty scans or flattened tables inherits their silence. RAG Converter's job is the seam before KAG: files in, JSONL passages out, with a manifest that names skips. Each line carries text, an embedding and source metadata - the raw material for entities and edges. Citeable chunks matter twice: retrieval needs them to answer, and the graph needs them so a path through nodes still opens a real page. If conversion invents placeholder text for a blank PDF, the graph will invent relationships between nothings. Honest conversion is the quality gate KAG cannot skip.
From passages to a train of thought
Once passages exist, sequencing is a separate step. Extract entities from the chunk text - people, products, account names, statutes. Link them when the same passage or neighbouring chunks assert a relation: A depends on B, A superseded C after date D. Order matters: a train of thought is not a bag of facts, it is a walk - cause before effect, draft before final, incident before policy. At question time the system retrieves relevant nodes, expands along edges, and feeds the model an ordered context rather than five unrelated snippets. That ordered context is what feels like "someone who was there".
Where RAG Converter stops and KAG begins
RAG Converter turns documents into a RAG-ready corpus. It does not replace your graph store or your entity linker. Use the free tab or the API to produce chunks.jsonl from the folder that holds your history; load that into the retrieval and graph layer you own; build edges on top of text you can audit. The same artifact works for plain RAG today and for KAG tomorrow, which is the point of converting once. When you are ready to go further, start with a corpus that already retrieves well - if the passages are wrong, no amount of graph machinery will sound like forty years of intelligence.