AI knowledge base: NotebookLM, Claude Projects or custom RAG?

The short answer: most businesses do not need a RAG project; they need tidy folders. If you want to make company knowledge accessible to AI, start with NotebookLM or Claude Projects — both are included in plans you probably already pay for, and both are set up in an hour. A custom RAG solution only pays off once you have very many documents that change constantly, or when the data may not leave your building.

Last checked: October 2026.

Disclosure: I build RAG systems professionally and earn money doing so. Which makes the central claim of this article — that most businesses do not need one — an argument against my own short-term interest. It stands anyway, because I have seen too many expensive projects that could have been a folder structure.

The short version

• The most common misdiagnosis: “we need RAG” usually means “our document store is a mess”.
• NotebookLM and Claude Projects solve 80 per cent of cases — no project, no development.
• Custom RAG pays off with very large, constantly changing collections, or when data may not leave the building.
• The expensive part is never the technology but the upkeep of the content.
• Test with 20 documents before planning for 20,000.

What separates the three approaches

The most telling row is the first. The difference between “minutes” and “weeks to months” is large enough to overwhelm any discussion of feature detail. Start at the top and only move down when you have a concrete reason.

The misdiagnosis that gets expensive

The conversation runs almost identically every time. Someone says: “We have so much knowledge in the building and nobody can find it. We need one of those AIs that knows our documents.” And then comes the question of what a RAG system costs.

My counter-question: when a new employee looks for the price list on day one — do they find it? And which of the four versions in circulation?

In most cases the actual problem is not that search is too poor. It is that nobody can say which document applies. A RAG system does not solve that — it will simply answer questions quickly and confidently from an outdated version. That is worse than no answer, because it looks more credible.

The uncomfortable order is: first establish which documents apply and who maintains them. Then put a tool on top. Reverse the order and you buy a system that reproduces disorder at high speed.

NotebookLM

What it is for: a bounded topic with a manageable number of sources. You create a notebook, load documents into it and ask questions — with citations showing which source supports the answer.

Where it shines: getting into a topic, evaluating a tender, preparing for a project. Anything with a clear beginning and a clear end.

Where it hits limits: as a permanent company memory. Updating is manual — somebody has to add new documents and remove old ones. With a collection that changes weekly, that quickly becomes a chore nobody wants to own.

Claude Projects

What it is for: ongoing work in one area. You store the material that always applies once — policies, text modules, product information, tone and style guidance — and every conversation in that project already knows it.

Where it shines: recurring work with consistent requirements. Proposal writing, customer communication, technical text within a fixed frame. The value lies less in looking things up than in not having to explain the context every time.

Where it hits limits: very large collections, and updating again. It is a working context, not an archive.

A note from practice: the biggest gain comes not from uploading existing documents but from writing down knowledge that previously sat only in people’s heads. How to extract that systematically I have described in Knowledge out of your head and into the system.

Custom RAG

When it genuinely pays off — in my experience at least two of these must apply:

• A very large collection clearly exceeding the limits of the off-the-shelf tools.
• Constant change, so manual upkeep is out and updating has to run automatically.
• Data may not leave the building — the most common hard reason, and the only one that suffices on its own.
• Integration with line-of-business systems whose content lives in a database rather than in files.
• Many users with different permissions, each allowed to see only their part.

What you must budget for: development, operations, and above all the ongoing upkeep of content. That last point is where these projects fail — not on the technology. A RAG system whose content is a year old is a liability question, not a convenience.

Why simple RAG often falls short and which approach holds up better in practice I have set out in Agentic RAG in n8n. For a concrete build without programming, see RAG agent without code.

The route I recommend

1. Name the ten questions asked most often in the business. Concretely, not as categories.
2. Find the documents that answer them. If you discover the documents do not exist, you have found your actual problem — and it is not a technology problem.
3. Establish which version applies, and who maintains it. By name.
4. Load those 20 to 50 documents into NotebookLM or Claude Projects and ask your ten questions.
5. Assess the result. If it is good, you are done — and you saved a few thousand euros.
6. Only if it fails, and you understand why, talk about a custom solution.

Frequently asked questions

What if we have tens of thousands of documents?

Then you very probably do not have ten thousand relevant documents. The first step is not a bigger system but the question of which two hundred of them actually answer questions. In almost every project I have accompanied, the answering set was an order of magnitude smaller than the total.

Is Copilot not already a RAG system over our document store?

Functionally in a similar direction, yes — and so the same applies there: it is only as good as the order in your store. More on this in the Copilot versus Claude comparison.

How do we keep the content current?

With a named person and a fixed appointment — say one hour per quarter. It sounds banal and it is the point at which most knowledge systems die. Without that appointment, after a year any system is a collection of outdated statements with a very convincing manner.

Are we even allowed to upload all our documents?

That depends on plan and data category. On business plans there is no training on your content — details in the GDPR comparison. For personnel data and special categories the route runs through your data protection officer, not a blog article.

What does a custom RAG system realistically cost?

The range is too wide for a serious flat figure — it depends on data volume, integrations and permission structure. What I can say: development is rarely the largest item. Operations and content upkeep over three years regularly exceed the build. Budgeting only the build means budgeting half.