Knowledge Graphs for RAG: why would you need a graph for the "window" technique?

In “Adding Relationships to The SEC Knowledge Graph”, they talk about how you can organize chunks in a document using a graph. You can link the chunks to each other sequentially, and you can link the chunks to the parent document. That way when you pull one chunk for context using a vector search, you can also pull the chunk before and the chunk after that search result.

However, it seems to me this could be much more easily accomplished without using a graph. For example, if we use a vector database with these fields:

text: “Hello this is a test”
embedding: [1,2,3,4,5,6…]
document: “Document.docx”
chunk_number_in_document: 4

Then we can simply query the database records where the document field is “Document.docx” and the chunk_number_in_document field is 3 or 5. It seems to me this would be way easier, without all the overhead of setting up a graph database. Am I missing something here?

Hi Tyler,

You’re completely right! There are lots of ways to maintain the original sequence of chunks. There’s nothing particularly graph-y about it. The intent is to slowly introduce the ideas of how to assemble a helpful graph, a “minimum viable graph.”

Graph modeling aims to be explicit about implicit relationships, with one goal being to reveal patterns of information. The emergent information structures become more useful the more you connect. What’s common, what’s unusual, what’s important, and what’s missing are all easier to answer with graph structures in place.

The important, subtle shift here is that the chunk doesn’t “know” its place in the sequence. Relieved of that responsibility, other “placements” become possible that the chunk has no idea about. It can be cross-referenced, indexed, and mapped across unstructured and structured data.

Best,
ABK