RAG (Retrieval-Augmented Generation) is a technique that combines a language model (such as Claude, OpenAI or Ollama) with a database of your own documents, so that the model can answer using real, up-to-date information instead of relying only on what it "knows" from its training.
It works like this:
- Your documents (PDFs, manuals, product sheets...) are split into fragments and converted into embeddings (numeric vectors that represent the meaning of the text).
- When someone asks a question, that question is also converted into an embedding, and the database is searched for the fragments that are most semantically similar (not by exact words, but by meaning).
- The most relevant fragments are passed to the AI model as context, together with the question.
- The model answers based on that real context, instead of making things up or relying only on its memory.
The advantage is that the model can "consult" specific and private information (your own documents) without having to be retrained.
Classic RAG vs. Graph RAG
The RAG used in InvoiceFlash is classic RAG (also called vector RAG). There is an evolution, Graph RAG (GraphRAG, or knowledge-graph RAG), which does not just look for similar fragments but also understands how things are related.
Classic RAG: splits documents into independent fragments, turns them into embeddings and, for each question, retrieves the fragments closest in meaning. It is fast, cheap and very good when the answer lives in one or a few fragments.
Graph RAG: a language model extracts the entities (customers, products, suppliers, contracts, people) and the relationships between them from the documents, and builds a knowledge graph. When asked, it walks the graph (neighbours, paths, communities), usually combined with vector search. That is why it can answer questions that need information from several documents, or summarise a whole topic.
Example: “Which customers are affected if supplier X fails?” Classic RAG finds fragments that mention supplier X, but it does not link supplier → material → product → customer. Graph RAG does, because it follows the relationships.
Comparison table
| Aspect | Classic RAG | Graph RAG |
|---|---|---|
| Unit of information | Text fragments (chunks) | Entities and relationships (nodes and edges) |
| How it retrieves | Semantic similarity between vectors | Graph traversal, often together with vector search |
| Questions it handles well | Specific: “what does the manual say about X?” | Relational and global: “how are A and B connected?”, “what are the main themes?” |
| Multi-document reasoning | Limited: each fragment is handled separately | Strong: joins data across documents |
| Explainability | Medium: shows the fragments used | High: the path of relationships can be seen |
| Indexing cost and time | Low: embeddings only | High: many model calls to extract entities |
| Complexity and maintenance | Low | High: the graph must be maintained and updated |
| Updating a document | Easy: its fragments are re-indexed | Costlier: entities and relationships may change |
| When to choose it | Documentation search, FAQs, manuals, product sheets | Highly connected data: supply chain, contracts, customers, regulatory compliance |
In practice they are not mutually exclusive: many companies start with classic RAG and add a graph only for the cases where relationships matter.