Long context windows and RAG pipelines are the two ways AI handles your documents in 2026. Say you write for a living, and you feed the AI source material. Interview transcripts, research notes, internal documents, articles you are riffing on. You have probably hit the wall. The model forgets what you told it three turns ago, and retrieval gets fuzzy. You paste the same paragraph over and over, hoping it sticks this time. The advice for fixing this has been the same for two years. Use a vector database. Build a RAG pipeline. Live with the upkeep.
In the first ten days of April 2026, three things happened that changed that advice. Anthropic shipped a 1 million token context window for Opus 4.6, and it does not collapse under load. Google shipped Gemini Embedding 2, the first natively multimodal embedding model. And a former OpenAI founding member named Andrej Karpathy made a 'no vector database' approach popular, and it works for most people. This guide breaks down all three, explains when to use each, then walks through the part none of them fix. That last part decides whether you can publish.
Three things just changed about how AI handles your documents
Before April 2026, the choice was one or the other. Stuff everything into the context window and watch quality collapse, or build a RAG pipeline. Now you have four real options. Each one suits a different scale and a different problem.
- Long context windows that actually work. Anthropic's 1M token window for Opus 4.6 holds up, and at full length it still hits 78 percent retrieval accuracy.
- Multimodal embeddings: Google's Gemini Embedding 2 is the first of its kind. It can embed text, images, video, and audio straight into one vector space.
- Graph RAG: open-source projects like Light RAG build a graph of how things link up. It sits next to the vector database, and it makes retrieval richer.
- The no-vector alternative: Karpathy's Obsidian-and-markdown approach skips vector databases. It is for a knowledge base you keep at your own scale.
All four give AI better access to your source material. None of them make the AI more accurate when it answers from that material. That gap is what this guide is about.
The 1M context window that actually works
For years, 'we have a 1 million token context window' was a marketing claim that did not survive contact with real work. Past 200,000 tokens, every model in every benchmark fell off a cliff. Researchers at Chroma published the canonical 'context rot' study in summer 2025. It showed steep drops in retrieval accuracy as input length grew. So the accepted wisdom ran like this: you can stuff a million tokens in. But clear the session at 100,000 to 120,000 if you want answers you can trust.
Then on April 9, 2026, Anthropic released Opus 4.6. It has a 1 million token context window, and a benchmark result that breaks the pattern.
The numbers
- Opus 4.6 scored 78.3 percent on the 8-needle long-context retrieval test at 1 million tokens
- Opus 4.5 scored about 27 percent at the same length, so Opus 4.6 nearly tripled it
- GPT 5.4 scored 36 percent at 1 million tokens
- Gemini 3.1 Pro scored 26 percent at 1 million tokens
- Opus 4.6's accuracy drop from 256 tokens to 1 million tokens was just 14 percent, where earlier models fell 60+ percent
Say those numbers hold up in everyday use. Then you no longer need to clear your Claude session at 100,000 tokens just to keep it working well. You have wiggle room. Some writers feed long documents into Claude: full transcripts, research dumps, multi-source briefs. For them this is the biggest unlock since the original 200,000 token window. The Chroma context rot study still applies to every other model. For now, it does not apply to Opus 4.6.
Two caveats. First, the 1 million token window is only on Anthropic's paid Max plan inside Claude Code, or via the API at full price. Second, 78 percent retrieval accuracy is much better than 27 percent. But it still means roughly 1 in 5 facts you embed in a long context will not be reliably retrieved when you ask about them. Long context solves a lot of the memory problem. It does not solve all of it. And it does not touch the accuracy problem at all.
Multimodal embeddings finally arrived (and most people are using them wrong)
Google released Gemini Embedding 2 in early April 2026, the first natively multimodal embedding model from a major lab. Until now, embedding models could only turn text into vectors. Want a video in your knowledge base? You wrote a description of the video and embedded that. With Embedding 2, you can embed the video itself. It sits next to text, images, audio, and documents, and they all share a single 1500-dimensional vector space.
What this lets writers do
For content teams, the real uses are oddly concrete, and here are three. Build a knowledge base of past interview videos and search across them by topic. Drop a 68-page product manual with diagrams into a vector database. Then ask questions that pull both text answers and the images that go with them. Keep a library of past articles with their hero images. Then ask about a topic and the AI shows you the visual as well. One builder set up a multimodal RAG for a vacuum cleaner manual in 30 minutes via Claude Code. For any question, the system returned both text instructions and the matching diagrams from the PDF.
The setup most tutorials get wrong
Almost every YouTube video about Embedding 2 does the same thing. It hooks the new embedding model up to a naive RAG pipeline and declares victory. The result: ask a question about a video and the system hands you the clip. You want a text answer that points at the video, not the clip itself. The fix is to ingest two things at once. The raw video, and a text description or transcript, paired in the same vector. Then retrieval pulls that vector, and the LLM gets the text it can actually reason about, plus the video as a citation. Skip this step and you get a confused chatbot that hands you two-minute clips.
Limits as of April 2026. Videos cap at 120 seconds per chunk, and images cap at 6 per request. The formats are MP4, MOV, PNG, and JPEG. That works for most content team use cases, and is frustrating at the edges.
Graph RAG: when naive vector search is not enough
Naive RAG is the kind every AI tutorial showed you in 2024: it turns documents into chunks, and chunks into vectors. Then it answers questions by finding the vectors closest to your question. That works until your document collection grows. Past a point, 'closest vector' starts returning chunks that share a few surface words and nothing else. In 2026, serious RAG users have moved to graph RAG.
How graph RAG differs
Graph RAG does everything naive RAG does, then adds a knowledge graph next to the vector database. As documents come in, the system pulls out named entities: people, organizations, products, concepts. It also pulls out the links between them. Ask a question and the system fetches two things. The closest vectors, and the entity-relationship graph around them. So it can answer 'how does X relate to Y' rather than just 'find the chunk most similar to this question.' That is the whole difference. Open-source Light RAG is the most popular build as of April 2026. It competes well with Microsoft's much more expensive GraphRAG.
When you actually need it
The threshold is roughly 500 to 2,000 pages of documents. At that size your collection is big enough that naive RAG starts missing context you need. It is still small enough that you do not need an enterprise-grade pipeline. Below that range, simpler approaches work fine. Above 2,000 pages, you also start saving real money against stuffing context windows. At large scale, RAG is reportedly 1,000+ times cheaper. What it beats is an agentic runner like Claude Code grepping every document on every query.
The no-vector-database alternative for solo operators
On April 8, 2026, Andrej Karpathy posted a short note on X, about a knowledge-base method he had been using himself. It involves no vector database, no embedding model, and no retrieval pipeline at all. You just keep a folder of markdown files. One 'raw' subdirectory holds source documents, and the other is called 'wiki'. That is where Claude Code, or any AI assistant, builds summaries, indexes, and cross-references.
The pattern is simple: drop articles, PDFs, transcripts, and notes into the raw folder. Ask Claude Code to ingest them and build a wiki. Claude reads everything, writes brief summaries, and creates index files. It links related concepts with markdown wiki-link syntax. Later you have a question. Claude reads the index, follows the links, and answers. That is structured retrieval through the file system, not fuzzy matching through vectors.
This works astonishingly well at a personal scale, think 10 to 500 documents. One builder reported a 95 percent cut in token usage against context-stuffing the same material. It scales poorly past about 1,000 documents. At that size the AI starts missing links across the corpus. Then you need a real RAG pipeline. For most solo operators and small content teams, the no-vector approach is simpler than a vector RAG at the same scale, and usually better.
All you need is a folder, an Obsidian install, and Claude Code or any AI tool like it. The Obsidian part is optional, and it is only there to draw the map. Total setup time is about five minutes, and this is one of three viral methods Karpathy made popular. We cover them in What Karpathy's AI methods don't fix, along with autoresearch and brevity constraints.
Decision tree: which approach for your scale
Match the approach to two things: how big your document collection is, and what modality you need.
| If your document collection is... | Modality... | Use... | Because... |
|---|---|---|---|
| Under 100 pages | Text only | Long context window (Opus 4.6 1M) | 78% retrieval accuracy, and nothing to host |
| 100 to 500 pages | Text only | Karpathy's Obsidian wiki method | Free, simple, beats vector RAG at this scale |
| 500 to 2,000 pages | Text only | Graph RAG (Light RAG) | Knowledge graphs catch links that naive search misses |
| 2,000+ pages | Text only | Graph RAG with proper hosting (Light RAG on Postgres) | 1,000x cheaper than agentic search at scale |
| Under 100 items, mixed media | Text + images + video | Long context window for text, Embedding 2 for media | Both work. Pick on whether you need search or reasoning |
| 100+ items, mixed media | Text + images + video | Multimodal RAG with Embedding 2 | Only option that handles non-text retrieval at scale |
Notice what every row in this table has in common: they all solve the memory problem. That is getting the right material in front of the AI when you need it. None of them solve the accuracy problem, which is making sure the AI does not hallucinate when it answers from that material. Better RAG does not mean better truth. That is the gap we built TrueStandard to fill. TrueStandard sits in the layer above all of these architectures. You paste your draft. Four to five models check the claims at once, against their own knowledge. Every disagreement is surfaced in 60 seconds.
The verification gap none of these architectures fix
Here is the part the architecture comparisons do not mention. Take the 1 million token context window, with 78 percent retrieval accuracy. That is a genuine leap, and it is still wrong about 22 percent of the time on what it retrieves. Take the multimodal vector database, with rich entity links. That is a serious upgrade, and it still passes whatever falsehoods sit in your source material straight through to the answer. Take the Obsidian-powered wiki, the most elegant knowledge base most people will ever build. It is also a faithful index of whatever your raw folder held, errors included.
The deep problem is this. Every architecture in this guide makes the AI better at finding and using your source material. None of them check whether the source material is correct, or whether the AI is reasoning correctly from it. Independent benchmarks put hallucination rates for frontier models in the 17 to 34 percent range on factual claims. That is the rate when the model has perfect retrieval. Retrieval and truth are different problems. Solving the first does not solve the second.
This is why fact-checking AI output stays a manual job for most content teams. It stays manual even with the best RAG money can buy. Checking by hand takes the better part of an hour per article, and it still misses subtle errors. The faster, surer route is to run the same content through several AI models from different labs at once. Then focus on the claims where they disagree. That is what TrueStandard does. It checks at the layer above retrieval, in 60 seconds, across four to five models that do not share each other's blind spots.
What writers, journalists, and B2B teams should actually use
Match the architecture to your real workload, then add a check on top. None of them check anything on their own.
Solo writer or small team, under 500 documents
Use Karpathy's Obsidian method: a five-minute setup, nothing to host, and it beats vector RAG at this scale. Skip the rest. Add multi-model verification with TrueStandard before you publish anything fact-heavy.
Long-form drafting from a single big document
Paste the document straight into Opus 4.6 or Sonnet 4.6, and use the long context window. It hits 78 percent retrieval accuracy at 1 million tokens. So you can stop chunking and start drafting. Run the draft through multi-model verification before you publish.
B2B content team with 500 to 2,000 internal documents
Set up Light RAG with a graph layer over your internal docs. Use a hosted Postgres backend so the team can share access, and tend it monthly. Check all generated content with multi-model verification before publishing.
Independent journalist with mixed-media research
Use Embedding 2 for the mixed pile: interview videos, source images, document scans. Use Opus 4.6's long context for one long-form session at a time. Always verify claims before filing. One model, even with perfect RAG, hallucinates often enough to embarrass a serious reporter.
Enterprise content operation with 2,000+ documents
Light RAG with proper hosting, or a similar graph RAG system. Make the check a required step before publish, in your editorial workflow. One published error in a brand voice costs more than multi-model verification at scale.
Frequently Asked Questions
What is context rot and is it solved in 2026?
Context rot is a well-known failure mode: large language models get much less accurate at finding things as their input grows. The Chroma research lab published the canonical study in summer 2025. It showed steep accuracy drops past 100,000 to 200,000 tokens. As of April 2026, Anthropic's Opus 4.6 appears to cut context rot a lot, with its 1 million token context window. It scores 78 percent on the 8-needle retrieval test at 1 million tokens. Opus 4.5 scored 27 percent, and rivals scored 26 to 36 percent. Other models still suffer from severe context rot. The problem is not solved everywhere, only on Opus 4.6 specifically.
Should I use a long context window or RAG in 2026?
Use long context windows for collections under about 100 documents. They have to fit in 1 million tokens. They shine when you need the AI to reason across the whole set at once. Use Karpathy's Obsidian wiki method for personal knowledge bases of 100 to 500 documents. Use graph RAG, Light RAG or one like it, for collections of 500 to 2,000+ documents, where retrieval is the main task. The cost crossover happens around 2,000 pages, past which RAG gets far cheaper than feeding it all into context. None of these approaches check the AI when it answers. So layer a check on top, whichever one you pick.
What is Google Gemini Embedding 2 and what does it enable?
Gemini Embedding 2 is Google's first natively multimodal embedding model, shipped in early April 2026. It can embed text, images, video, audio, and documents into the same 1500-dimensional vector space. Earlier embedding models could only handle text, so you can now build a knowledge base that mixes media types. Embed 13 product photos and a 68-page manual together. Then one search returns both the text and the matching diagrams. The most common setup mistake is hooking it up to a naive RAG pipeline. The right move is to embed a text description next to each media file. Then the LLM can reason about the content, not just hand back clips.
What is graph RAG and how is it different from regular RAG?
Graph RAG adds a knowledge graph to plain vector retrieval. The graph holds named entities, such as people, organizations and concepts, and the links between them. Query a graph RAG system and it pulls two things. The vectors closest in meaning, and the entity links around them. So it can answer 'how does X relate to Y', which naive RAG handles poorly. Open-source Light RAG is the most popular build as of April 2026. Graph RAG is far more useful than naive RAG for collections of 500+ documents where links across documents matter.
What is Karpathy's Obsidian method for AI knowledge bases?
It is a no-vector-database alternative to RAG, made popular by Karpathy in April 2026. You create a folder with two subdirectories: 'raw' for source documents, and 'wiki' for AI-organized output. Ask Claude Code, or another AI, to ingest the raw folder. It builds summaries, creates index files, and cross-references related concepts with markdown wiki-link syntax. Later questions get answered by following the links, not by fuzzy matching. It works well for personal knowledge bases of 10 to 500 documents. It reportedly cuts token usage by 95 percent against context-stuffing the same material. It scales poorly past about 1,000 documents.
Is RAG dead in 2026?
No, but the use case is narrower than it was in 2024. For personal-scale knowledge bases under a few hundred documents, you can drop RAG. Use a long context window, or Karpathy's no-vector method. For collections of 500 to 2,000+ documents, graph RAG is still the best approach. For truly large enterprise collections, RAG is the only option that does not blow up your token budget. The bigger shift is that 'naive RAG' is dead, meaning a vector database with no graph layer. Use either graph RAG or one of the simpler alternatives.
Does better RAG make AI more accurate?
No. RAG setups, long context windows, multimodal embeddings, knowledge wikis: they all improve the AI's access to your source material. None of them make the AI more accurate when it reasons from that material. Independent benchmarks put hallucination rates for frontier models in the 17 to 34 percent range on factual claims. That rate is roughly the same with or without high-quality RAG. The retrieval problem and the truth problem are separate problems. Solving retrieval is necessary. It is not enough to publish AI-assisted content.
How do I verify AI-generated content for accuracy?
Checking by hand means Googling each claim. It takes the better part of an hour per article, and it still misses subtle errors. The faster, surer route is to run the same content through several AI models from different labs at once. Then focus on the claims where they disagree. Models trained on different data have different blind spots. So a claim that all four or five models confirm is much more likely to be correct than a claim from one confident model. TrueStandard does this in 60 seconds across several frontier models. It surfaces every disagreement for human review.
Do these architectures work with ChatGPT and Gemini, or only Claude?
The choices here do not depend on the model. Long context windows are a feature of every frontier model. Opus 4.6 has the best retrieval at 1 million tokens as of April 2026. ChatGPT and Gemini have similar window sizes, with worse retrieval accuracy. Multimodal embeddings work with any model that accepts the embedded content. Graph RAG and the Karpathy wiki method do not care which LLM you use to query them. So mix and match on what each model is good at. Long context with Opus, multimodal with Gemini, and so on.
Keep reading
Multi-Agent vs Multi-Model AI in 2026
Multi-agent AI runs many roles of one model. Multi-model AI runs different models from different labs. Only multi-model can catch an error the first model is blind to.
Every Type of AI, Explained
From large language models to coding agents: what each type of AI does, which tools lead each group, and how to pick the right one for your work.
Karpathy's 3 AI Methods, and What They Don't Fix
Andrej Karpathy's three 2026 methods are autoresearch, the LLM Wiki and brevity constraints. Autoresearch tunes metrics, the wiki organizes memory, and brevity cuts reasoning loops. None of them checks whether a writer's claims are true.
3 AI Stress Tests from Q2 2026
In April 2026, top AI builders ran real experiments instead of demos. The results were more interesting than the demos. Here is what each test reveals, and why none of them fully answers the question writers care about.
What Is AI Slop, and How to Avoid It
AI slop is mass-produced, low-effort content made with little regard for whether it is accurate. What separates AI-assisted work from slop is whether you verified the output, and can prove it.
Better Retrieval Is Not Better Truth.
A 1 million token context window does not make AI more honest. Multimodal RAG does not catch hallucinations. The right architecture gets the AI the right material. The AI still hallucinates from it. TrueStandard handles the layer above. Paste your draft and four to five models check the claims at once. Every disagreement is flagged in 60 seconds.
TrueStandard is for writers who publish AI-assisted drafts. Paid plans check every claim and citation across four AI models before you hit publish.
Free: one check a day, no signup. Pro is $20 a month for 250 drafts.
Start Verifying →