Constructing a Knowledge Graph from Text

DLAI Study Notes / Knowledge Graphs for RAG / Constructing a Knowledge Graph from Text

SEC Form 10-K: the source data

Pre-processing extracts the useful fields from the raw XML into JSON. Two identifiers and four text sections do most of the work:

| Field | Type | What it holds | | --- | --- | --- | | CIK | identifier | Central Index Key — the SEC’s company id | | CUSIP | identifier | security id (first 6 digits link a company across datasets) | | Item 1 | text | business description | | Item 1A | text | risk factors | | Item 7 | text | management discussion & analysis | | Item 7A | text | market-risk disclosures |

Chunking the text

Each section is far too long to embed whole, so it is split into overlapping chunks with LangChain’s CharacterTextSplitter:

from langchain.text_splitter import CharacterTextSplitter

text_splitter = CharacterTextSplitter(chunk_size=2000, chunk_overlap=200)
chunks = text_splitter.split_text(item1_text)   # Item 1 alone -> 254 chunks

| Parameter | Value | Why | | --- | --- | --- | | chunk_size | 2000 chars | balances context richness against embedding specificity | | chunk_overlap | 200 chars | ~10% overlap so no context is lost at a boundary |

The number of chunks follows from the effective advance — each new chunk moves forward by chunk_size − overlap, not the full size:

$\text{chunks} \approx \left\lceil \frac{L - O}{S - O} \right\rceil$

where $L$ is text length, $S$ is chunk size, and $O$ is overlap.

Chunk metadata

A chunk is stored as a dictionary — text plus metadata that preserves where it came from and where it sits in the document:

chunk_record = {
    "text": "...",          # the chunk content
    "item": "item1",        # which section of the form
    "chunkSeqId": 0,        # position within the section
    "formId": "...",        # the filing this chunk belongs to
    "chunkId": "...",       # unique id for this chunk
    "source": "...",        # link back to the SEC filing
    "cik": "...",           # company CIK
    "cusip6": "..."         # company CUSIP (first 6 digits)
}

Creating graph nodes idempotently

Before bulk loading, declare a uniqueness constraint. It prevents duplicate chunks and creates an implicit index that makes the next step’s existence checks fast:

CREATE CONSTRAINT unique_chunk IF NOT EXISTS
FOR (c:Chunk) REQUIRE c.chunkId IS UNIQUE

Then load each chunk with MERGE on its stable chunkId, writing properties only on first creation:

MERGE (c:Chunk {chunkId: $chunkParam.chunkId})
ON CREATE SET
  c.text       = $chunkParam.text,
  c.item       = $chunkParam.item,
  c.chunkSeqId = $chunkParam.chunkSeqId,
  c.formId     = $chunkParam.formId

Adding vector search to the chunks

The embedding step is exactly the Module 3 pattern, now over chunk text instead of movie taglines: create a vector index on Chunk.textEmbedding, then populate it with genai.vector.encode and db.create.setNodeVectorProperty. The index declares 1536 dimensions (OpenAI’s text-embedding-3-small) and cosine similarity, and must reach ONLINE before you query it.

CREATE VECTOR INDEX form10kChunks IF NOT EXISTS
FOR (c:Chunk) ON (c.textEmbedding)
OPTIONS { indexConfig: {
  `vector.dimensions`: 1536,
  `vector.similarity_function`: 'cosine'
}}

Building the RAG chain

With chunks embedded, LangChain wraps the graph as a vector store and chains retrieval to an LLM:

Neo4jVector.from_existing_graph connects to the index you already built — you tell it the label, the text property, and the embedding property:

from langchain_neo4j import Neo4jVector          # see currency note below
from langchain_openai import OpenAIEmbeddings

neo4j_vector = Neo4jVector.from_existing_graph(
    OpenAIEmbeddings(),
    url=NEO4J_URI, username=NEO4J_USERNAME, password=NEO4J_PASSWORD,
    index_name="form10kChunks",
    node_label="Chunk",
    text_node_properties=["text"],
    embedding_node_property="textEmbedding",
)
retriever = neo4j_vector.as_retriever()

The retriever feeds a retrieval-QA chain that stuffs the retrieved chunks into the prompt and asks an LLM (temperature 0) to answer. Ask “What is NetApp’s primary business?” and it returns “enterprise storage and data management” — grounded in the filing.

When RAG hallucinates

Ask the same system “Tell me about Apple” — a company not in the data — and it answers confidently about Apple anyway, describing it with NetApp’s business. That is hallucination: the retriever returned the nearest available chunks (NetApp’s), and the prompt never told the model it could decline, so it filled the gap with plausible-but-wrong text.

The fix is layered — prompt engineering plus a retrieval check:

1. Instruct refusal — “If the context doesn’t contain the answer, say you don’t know.” 2. Scope the context — state that it comes from specific filings only. 3. Gate on retrieval score — low similarity scores signal an out-of-scope question; drop the chunks before they reach the LLM.

template = """Use ONLY the following context to answer.
The context comes from SEC filings for specific companies.
If the context does not contain information about the company
or topic in the question, respond: "I don't have information
about that company in my data." Do NOT use general knowledge.

Context: {context}
Question: {question}
Answer:"""

The limitation: a pure vector store

Summary

SEC Form 10-K filings are rich, standardised documents — ideal source text. The construction pipeline is: extract sections (Item 1/1A/7/7A) → chunk with overlap so no context is lost → store each chunk with provenance metadata → MERGE into the graph behind a uniqueness constraint for idempotent, exactly-once loading → embed and index for vector search → wrap with Neo4jVector and a retrieval-QA chain. Prompt engineering (“use only this context; say you don’t know”) plus retrieval-score gating is what keeps the system from hallucinating on out-of-scope questions. But at this stage Neo4j is only a vector store: the chunks are disconnected.

• Chapter 5 — adding relationships: NEXT, PART_OF, and SECTION turn the chunk collection into a real knowledge graph.
• Chapter 6 — expanding the SEC graph with companies and investors (Form 13 data).
• Chapter 7 — answering questions by having an LLM generate Cypher against the connected graph.