Related ToolsChatgptClaudeConsensusBloomfire

Karpathy's Case for Treating LLMs as Knowledge Bases

AI news: Karpathy's Case for Treating LLMs as Knowledge Bases

What if your LLM isn't a chatbot that happens to know things, but a knowledge base that happens to generate text? Andrej Karpathy, former OpenAI researcher and Tesla AI director, has been pressing this reframing - and it changes how you should think about building AI into your work.

The distinction sounds semantic but has real practical weight. Traditional knowledge bases are explicit: you store documents, you retrieve them, you search them. LLMs learn by absorbing billions of text samples during training, then compress that information into billions of numeric parameters. The knowledge isn't stored as retrievable files - it's encoded into the model's weights, smeared across the whole network.

Karpathy has described this as "lossy compression" of the internet. The model doesn't remember sources. It can't cite the exact page it learned something from. But it can answer questions, make connections, and synthesize across domains in ways a keyword search never could.

Where RAG Fits In

This framing matters most when you're deciding between RAG (Retrieval Augmented Generation - where the AI pulls in relevant documents at query time before answering) versus relying on the model's built-in knowledge. Both approaches have real tradeoffs.

RAG is better when you need current information, proprietary data, or source citations. You feed the model your internal docs, your recent reports, your product specs - it retrieves and answers against those specifically. This is how tools like Notion AI, Glean, and most enterprise search products work.

Parametric knowledge (what the model already "knows" from training) is faster, cheaper, and surprisingly deep for established domains - medicine, law, engineering, history. No retrieval step. No chunking and embedding your documents. Just ask.

The mistake most people make is assuming one approach replaces the other. Karpathy's point seems to be that the LLM itself is a first-class knowledge store - not a fallback for when your retrieval pipeline fails, but a deliberately useful artifact of training. That changes how you design workflows: sometimes the right answer is fewer external documents, not more.

For daily AI users, this is a useful mental model. Before wiring up a complex RAG pipeline, ask whether the model's existing training already covers your use case well enough. Often it does.