You’ve been told you need a vector database, embeddings, and a full RAG pipeline before you can build anything useful. It’s a lie.
After analyzing 1014 viral articles and studying how real teams actually build knowledge bases, I found a pattern: the most effective systems start with the simplest possible search. Claude Code famously uses pure grep — no RAG, no embeddings, no vector store. And it works.
The best way to make your knowledge base spread is to make it simple enough that people actually use it.
Let me show you why your instinct to start with complex AI is wrong — and what you should do instead.
The Single Most Important Decision: Search Method
There are three ways to search a knowledge base: exact match, keyword match, and semantic match. Most teams jump straight to semantic (RAG) because it’s sexy. But the real decider is the scene — what the user is actually doing.
Scene 1: Human searching manually. The user types a filter. Give them exact matches. No natural language parsing needed.
Scene 2: Agent answering a question. If the question has clear keywords (e.g., “show me orders from last week”), grep is faster and cheaper. Only use vector search when the intent is fuzzy (e.g., “find something similar to this document”).
Scene 3: Mixed queries. The agent splits the request into exact filters and fuzzy searches, then combines results. This is the hardest — and rarest — case.
Here’s the kicker: over 80% of real-world queries fall into Scene 1 or 2. That means you don’t need RAG for most of your workload.
The Proof: Claude Code vs. Cursor
Two of the most popular AI coding tools illustrate this perfectly. Cursor uses semantic search (embeddings). Claude Code uses pure grep. Cursor’s own blog admits that semantic search only improved accuracy by 12.5% on queries that needed search — but in the overall A/B test, the benefit was tiny: code retention rate went up 0.3%, and follow-up questions dropped by 2.2%.
In other words, for 97% of queries, grep was already good enough.
Claude Code’s team knew this. They chose grep not because it’s less capable, but because it’s more reliable, cheaper, and faster. The trade-off is real: you trade a tiny accuracy gain for massive simplicity and cost savings.
This is the principle that should guide every knowledge base decision: start simple, validate value, then iterate.
The Three Paths to Build a Knowledge Base
Based on your team size and data volume, here are three concrete paths. The key is to pick the one that matches your current reality — not your future ambitions.
Path 1: Code Agent + Feishu (for solo devs or small teams)
If you’re a solo developer or a team of 1-5 with fewer than 1000 records, you don’t need any infrastructure. Use a spreadsheet tool like Feishu (or any Airtable clone) and have your AI agent (like Claude Code) query it via structured filters. Your operations team uses the same spreadsheet with the same filter controls. No sync, no extra permissions.
This is the “zero infrastructure” path. It works because the data is small and the queries are simple. You’ll be shocked at how far this takes you.
Path 2: Cloud RDBMS + NL2SQL (for mid-sized teams with budget)
If you have 1,000 to 100,000 records and a modest budget, use a cloud database that has built-in natural language to SQL translation (e.g., AWS RDS + Bedrock, Azure SQL + Copilot, Google Cloud SQL + Gemini). You don’t need to build an agent layer — the platform handles it. Your job is data curation: define semantic models, create verified queries, and iterate on the top 10-20 questions.
The bottleneck is not technology — it’s curation. The quality of your NL2SQL depends on how well you’ve defined your business terms and validated queries. Start with 10-20 frequent questions, run a benchmark, and expand.
Path 3: Full Custom Build (for large teams with high security)
For 100k+ records, high security needs, and a dedicated engineering team, build your own stack: intent parser, routing logic, search engine (MySQL + ES + vector DB), and curation pipeline. This gives you full control but also full responsibility. You need to maintain your own benchmark and regression tests.
Most teams don’t need this. And if you think you do, start with Path 2 first.
The Curation Trap
Every path relies on curation — the work of organizing, cleaning, and defining your data. No AI can fix a messy knowledge base. The team at Snowflake, Databricks, and Google all converge on the same pattern: trust comes from curated assets, not from LLM confidence.
Your users will never trust a system that returns wrong answers with high confidence. Build a system that shows its sources, flags uncertainty, and lets the user override.
Here’s the golden rule: A simple search with curated data beats a complex search with messy data every time.
What to Do Now
Stop building a vector database this week. Start with a spreadsheet. If you need more, move to a cloud database. Only when you’ve proven the value — and have the data volume to justify it — should you consider a custom stack.
The most viral knowledge bases are not the most advanced — they are the most usable. Give your users something that works, and they’ll tell everyone.
Now go build. Start with grep.
FAQ
Q: Is RAG useless then?
A: No, RAG is powerful for fuzzy queries where you need to find conceptually similar content. But it's overkill for 80% of queries that are exact match or keyword-based. The mistake is defaulting to RAG before checking if grep works.
Q: What if my data grows and I need semantic search later?
A: That's fine. The framework is designed to be incremental. Start with Path 1 (spreadsheet), then Path 2 (cloud RDBMS with NL2SQL), then Path 3 (custom stack). You can add embeddings later. The key is to validate value first.
Q: Isn't this just 'premature optimization' backwards?
A: Yes, exactly. The industry is obsessed with building complex AI infrastructure before proving the product works. This article is a counter-argument: start with the simplest thing that could possibly work, validate, then iterate. It's the opposite of premature optimization.