AI Crime Investigations: The Epstein Files

Imagine that you are a crime investigator asking a question like this:\

"Find me a few people with no obvious connection to Epstein who may still warrant\ scrutiny, based purely on who they know."

This is the kind of question that exposes the limit of ordinary AI search. AI tools can only read a limited amount of context at a time, and the longer the text provided is, the more likely they will struggle to give accurate answers over the available information. There is also a hard limit, typically in the range of ten thousand to one hundred thousand words (depending on the model).

In this article, we will investigate the broad concept of what GraphRAG is, how it is better than regular AI search (RAG) for certain use cases such as crime investigation and motivate it with an example that we built as an app plugin for an existing LLM chat interface.

Below you can see the investigative power of our solution, as well as the ability to directly ask questions about and visualise the relationships between the mentioned entities:

Asking a broad investigative question:

Exploring the connections to individuals:

Exploring further connections to companies:

The Challenge

The most common type of AI retrieval searches documents for passages that are similar to the question (something like a Google search over your documents), and feeds those passages to the AI as context for its answer.

It might surface portions of documents containing well-known names or entities, and be able to fetch sufficient information to produce a partially complete answer. The real value in investigative work often lies elsewhere such as the structure of the corpus, in recurring patterns, indirect links, intermediary roles or relationships that only become visible when evidence is assembled across many documents. There is often no singular document that can tell the whole story.

Some questions are relatively simple and can be answered by a standard RAG retrieval method. This includes questions where the answer exists in one passage:
"What does a filing say about a named person?"

Other questions are often harder to answer and perhaps more valuable:
"Which names, organizations, and locations keep recurring around the same cluster of activity?"

It is usually the second class of questions that reveals where ordinary retrieval fails.

If analysts still have to cross-reference names, filings, and recurring contexts by hand, then the AI is only helping at the edges. The real time cost is still there along with the risk of missing the weakest but most important connections.

Standard RAG Is Useful, but It Solves a Narrower Problem

RAG stands for "Retrieval Augmented Generation". This means that in order for the AI to generate an answer, some additional context documents need to be retrieved and provided as context to the AI to help augment its answer. In practice, the concept is simple:
Make a search-engine for your documents and allow the AI to find information there.

In practice there are two stages:

Indexing: Performed only once, before any questions are asked. Documents are split into chunks and made searchable.
Searching: Performed every time a question is asked. A search query is generated, and the top results are passed to the AI as context.

This works excellently when the answer to a question exists in one place, in one document. The following questions will most likely work, but there is no guarantee that you will be able to retrieve all instances of the relevant documents on the first try:

"What does this filing say about a named person?"
"Where is this organization mentioned?"

The problem is that investigative questions are often not "passage-shaped". They may require aggregation across dozens of filings. They may depend on:

The frequency of co-occurrence between names.
People, organizations, or locations act as bridges between clusters of evidence.
Individuals whose importance does not come from a direct mention, but from the position they occupy in the surrounding network of names and entities.

Why Ordinary Passage Retrieval Breaks Down

There are at least three common failure modes when standard RAG is applied to
an investigative corpus:

The first is phrasing mismatch. Relevant evidence may exist, but not in the same language as the question. A query about "travel logistics" may not surface pages that describe "property management" or "arrangements" unless the wording lines up closely enough.
The second is distribution. No single passage may contain the answer. One document names a person, another names an organization, another provides a location, and a fourth reveals the recurrence pattern that makes the link interesting. Standard RAG can retrieve fragments of this, but it does not organize those fragments into a usable structure.
The third is relational meaning. Some answers do not exist primarily in any one document at all. They emerge from how entities relate to one another across the corpus: who appears with whom, which names bridge communities, which organizations recur in specific thematic clusters, and which actors keep showing up at structurally important points in the network.

For an investigative team, those turn into very practical costs. Analysts spend time stitching evidence together by hand. Important relationships can be missed. Review work becomes harder to validate. And a system that sounds impressive in a demo can still leave the hardest reasoning work to the human operator.

What GraphRAG Solves

GraphRAG changes the problem by reorganising the corpus into a structured 'graph' before the question is asked. Then, when a question is asked, it is a matter of searching this structured representation rather than looking for document chunks.

In practical terms, this involves using an LLM to break down the corpus of text into distinct entities, relationships and community-level groupings before a question is ever asked. When a question is asked, it becomes a matter of retrieving information from that structure, rather than searching only over individual text chunks.

The system is no longer limited to finding the best-matching passages. It can retrieve details about specific people and organisations, broader context about how groups of entities relate, and structural information from the graph itself.

One way to think about the difference is this:

Standard RAG searches a pile of excerpts.
GraphRAG first turns the corpus into a map

That map does not entirely replace the original documents, but it makes them both easier to navigate, as well as gives you tools to analyse the data statistically. It gives you a compressed, queryable representation of the corpus that is better aligned with the kinds of questions investigators actually ask.

Why This Matters in Practice

The value of GraphRAG is not just "more complicated AI is always better" It is about being a better fit between the kind of work being done and the data that is available.

If the system can retrieve entities, cross-document relationships, community structure, and grounded summaries, several practical benefits follow. Some of the benefits are as follows:

Reduces manual cross-referencing: Analysts no longer have to rebuild every pattern by hand from scattered filings.
Improves the chances of surfacing indirect links: Some names matter not because they are mentioned in an obvious headline passage, but because they sit at a bridge point in the surrounding network.
Supports better validation: A graph-based system can combine semantic answers with exact structural queries, which matters when a user wants to move from "this looks interesting" to "show me the evidence."
Gives organizations more control over how the system is deployed: For investigative, compliance, due-diligence, or public-interest use cases, control over data, models, and infrastructure is often part of the value proposition, not a secondary deployment detail.

What This Looks Like in Practice

"Who handled the logistics?"

We asked the system an open-ended question:
"Who organised travel and accommodation arrangements for Epstein? What roles did different people play, and how are they connected to each other?"

Ordinary RAG handles this situation poorly as the answer is not in any one document. It is spread across dozens of filings, involving different people in different roles.

Alternately, our GraphRAG solution begins by identifying which thematic clusters in the corpus were relevant. This includes groups of entities that had been found to co-occur around key areas such as logistics and and personal staff. From there, it automatically generated follow-up questions on its own and pursued them across the graph. This commonly would include questions such as:

Who managed specific properties?
Which names keep recurring in these contexts?
Are there intermediaries?

It follows the high-scoring leads in order to retrieve the most relevant information. This includes specific individuals, their roles, the organisations they connect to, and the documents where these patterns appear, pulled together from evidence scattered across filings that no single search would have surfaced on its own.

The investigator did not search six times and cross-reference by hand. They asked one question, and the system explored the corpus on their behalf using the graph network, while also providing a high degree of traceability.

Then: "Show me the evidence"

Suppose one of those names caught the investigator's attention, someone who kept appearing in travel and logistics contexts but is not a household name.

We asked a follow-up:
"Who are Saphire Travel frequently co-mentioned with?"

This time the system did something completely different. Instead of exploring broadly, it translated the question into a structured query. The result was a table, the precise number of pages mentioning that person, and a ranked list of who they appear alongside, with exact co-occurrence counts.

That is the difference. The first query explored. The second was verified. Both used the same underlying graph, but the system chose a different retrieval approach for each one, matching the method to what the question actually needed.

You can also ask the system to visualise a person's network directly, who they are connected to, how strongly, and through which types of entities. Sometimes a picture of the local graph makes a pattern click in a way that a paragraph does not.

Conclusion

The main lesson is that investigative search is rarely just a matter of finding the right passage faster. Sometimes it is. Standard RAG is genuinely useful for that class of problem.

But once the work depends on cross-document patterns, indirect links, recurring communities, and exact validation, the representation of the corpus starts to matter as much as the model answering the question. That is where GraphRAG becomes genuinely useful.

For a team doing investigative or high-sensitivity work, it means less manual stitching, stronger structural retrieval, clearer validation paths, and more control over how the system is run.