DEV Community: Amit Verma

I Built a RAG Chatbot for My Portfolio Without a Vector Database (BM25 + Next.js + Vercel AI SDK)

Amit Verma — Thu, 05 Nov 2026 13:43:50 +0000

No embeddings. No vector database. About 40 lines of retrieval code. This is how the AI assistant on this site works, including the bugs I found when I tested it properly.

In my post on vectorless RAG I argued that vector embeddings are often the wrong default. This post puts that argument into production. The chat assistant on my portfolio answers questions about my experience, skills and projects, and it retrieves context with BM25 — the same keyword-ranking algorithm behind classic search engines — instead of a vector database.

Here's the full build: how the data is chunked, how BM25 ranks it, how the answer is streamed, how the endpoint is protected, and the retrieval mistakes I only caught by running real questions against it.

Why no vector database?

For this use case, embeddings would add cost and moving parts without improving answers:

The corpus is tiny. My resume becomes 25 chunks averaging about 50 words each. You can score all of them on every request in well under a millisecond.
Questions use the same words as the data. People ask about "React", "Next.js", "Startbit" or "blockchain" — exact terms that keyword search handles well and embeddings sometimes blur.
No extra infrastructure. No embedding API call per query, no index to rebuild when the resume changes, no vector store to pay for or keep in sync.
It's debuggable. When an answer is wrong, I can print the scores and see exactly why a chunk ranked where it did.

If you have thousands of documents, or users who describe things in very different words from your content, vectors (or a hybrid) start to earn their place. For a portfolio, a docs site of a few hundred pages, or a product FAQ, BM25 is a strong default.

The architecture

The whole thing is one Next.js route handler:

Chunk the resume data into small labelled passages (once, at module load).
Retrieve the top 5 chunks for the user's latest message with BM25.
Generate an answer with the Vercel AI SDK's streamText, putting the chunks in the system prompt.
Stream the text back to a small React hook that renders it as it arrives.

Step 1: Chunk by meaning, not by character count

Generic RAG tutorials split documents every N characters. My data is already structured — a TypeScript object with profile, skills, experience, projects and education — so each chunk is one meaningful unit: one job, one project, one skill category.

interface Chunk {
  text: string
  section: string
}

function buildChunks(): Chunk[] {
  const chunks: Chunk[] = []

  chunks.push({
    text: `Name: ${resumeData.profile.name}. Title: ${resumeData.profile.title}. Summary: ${resumeData.profile.summary}`,
    section: 'profile',
  })

  for (const [category, items] of Object.entries(resumeData.skills)) {
    chunks.push({ text: `Skills — ${category}: ${(items as string[]).join(', ')}`, section: 'skills' })
  }

  for (const exp of resumeData.experiences) {
    chunks.push({
      text: `Experience: ${exp.role} at ${exp.company} (${exp.dateRange}), ${exp.location}. ${exp.achievements.join(' ')}`,
      section: 'experience',
    })
  }

  for (const proj of resumeData.projects) {
    chunks.push({
      text: `Project "${proj.name}": ${proj.description.join(' ')} Stack: ${proj.skills.join(', ')}.`,
      section: 'project',
    })
  }

  return chunks
}

const CHUNKS = buildChunks() // built once per cold start

Prefixing each chunk with its type ("Experience:", "Project …:") does two jobs. It gives the model context about what it's reading, and it gives BM25 a keyword to match when someone asks about "experience" or "projects".

Step 2: BM25 in about 40 lines

BM25 scores a chunk higher when it contains the query's words, especially rare words, and it stops rewarding a word after a few repetitions. It also adjusts for chunk length so long chunks don't win just by being long.

const K1 = 1.5 // how quickly repeated terms stop adding score
const B = 0.75 // how strongly to normalise by chunk length

const tokenisedChunks = CHUNKS.map((c) => tokenise(c.text))
const avgDocLen = tokenisedChunks.reduce((s, t) => s + t.length, 0) / tokenisedChunks.length

// Document frequency: in how many chunks does each term appear?
const df = new Map<string, number>()
for (const tokens of tokenisedChunks) {
  for (const term of new Set(tokens)) df.set(term, (df.get(term) ?? 0) + 1)
}

function idf(term: string): number {
  const n = CHUNKS.length
  const d = df.get(term) ?? 0
  return Math.log((n - d + 0.5) / (d + 0.5) + 1)
}

function bm25Score(queryTokens: string[], docTokens: string[]): number {
  const tf = new Map<string, number>()
  for (const t of docTokens) tf.set(t, (tf.get(t) ?? 0) + 1)

  let score = 0
  for (const term of queryTokens) {
    const f = tf.get(term) ?? 0
    if (f === 0) continue
    const lengthNorm = 1 - B + B * (docTokens.length / avgDocLen)
    score += idf(term) * ((f * (K1 + 1)) / (f + K1 * lengthNorm))
  }
  return score
}

function retrieveTopK(query: string, k = 5): string {
  const q = tokenise(query)
  return tokenisedChunks
    .map((tokens, i) => ({ chunk: CHUNKS[i], score: bm25Score(q, tokens) }))
    .sort((a, b) => b.score - a.score)
    .slice(0, k)
    .filter((r) => r.score > 0)
    .map((r) => r.chunk.text)
    .join('\n\n')
}

The IDF term is what makes this work. "Startbit" appears in one chunk, so matching it is worth a lot. "Built" appears in many chunks, so it's worth little. Everything is computed at module load, so a request only does the scoring loop.

Step 3: Stream the answer with the Vercel AI SDK

The route handler retrieves context and hands it to streamText. The model provider is chosen by an environment variable, so I can switch between Claude, Groq and Gemini without code changes.

import { streamText } from 'ai'

export async function POST(req: Request) {
  if (!(await rateLimit(req, 'portfolio-chat', 20, 60 * 10))) {
    return new Response('Too many messages. Please try again in a few minutes.', { status: 429 })
  }

  const { messages } = (await req.json()) as { messages: ChatMessage[] }
  const userMessage = String(messages.at(-1)?.content ?? '').slice(0, 2000)
  if (!userMessage) return new Response('No message provided', { status: 400 })

  const { model } = getProviderConfig()
  const context = retrieveTopK(userMessage)

  const result = streamText({
    model,
    system: `You are a helpful assistant on Amit Verma's portfolio website.
Answer questions about Amit's background, skills, projects and experience.
Stick strictly to the provided context. If something is not covered,
say you don't have that detail and invite the visitor to get in touch.

Retrieved context:
${context}`,
    messages: buildModelMessages(messages), // last 12 turns, each capped at 2,000 chars
    maxOutputTokens: 512,
  })

  return result.toTextStreamResponse()
}

A few decisions in there are worth explaining:

Retrieval uses only the latest message. It's simple and it works for most questions. The trade-off is follow-ups: "what stack did it use?" doesn't name the project, so retrieval misses. Rewriting the follow-up into a standalone question first would fix it, at the cost of one extra model call.
"Stick strictly to the provided context" plus a polite fallback is most of the hallucination protection. A small model with good context and a clear "say you don't know" instruction does better than a big model guessing.
History and output are capped. Twelve turns, 2,000 characters each, 512 output tokens. Each request stays small and its cost is predictable.
OpenAI-compatible doesn't mean identical. Groq and Gemini expose OpenAI-compatible endpoints, but only for Chat Completions. Recent versions of the AI SDK’s OpenAI provider call the newer Responses API by default, which those endpoints don’t support, so every request failed. Creating the model with .chat() (for example gemini.chat('gemini-2.5-flash')) fixed it, and every provider now gets the full conversation history.

Step 4: Rate limiting with Upstash Redis

A public endpoint that calls a paid model needs a limit. I use a fixed window keyed by IP: 20 messages per 10 minutes.

export async function rateLimit(req: Request, name: string, limit: number, windowSeconds: number) {
  const client = getRedis()
  if (!client) return true // no Redis configured: allow

  const ip = req.headers.get('x-forwarded-for')?.split(',')[0]?.trim() || 'unknown'
  const key = `ratelimit:${name}:${ip}`

  try {
    const count = await client.incr(key)
    if (count === 1) await client.expire(key, windowSeconds)
    return count <= limit
  } catch {
    return true // fail open
  }
}

It fails open : if Redis is down, chats still work. For a portfolio, a short Redis outage shouldn't take the assistant offline. For an expensive or abusable endpoint I'd fail closed instead. A fixed window also allows a burst at the window boundary; a sliding window (@upstash/ratelimit has one) smooths that out if you need it.

What broke when I tested it properly

Unit tests passed. Then I ran real questions against the real data and printed the top results. Three problems showed up immediately.

1. Short words were silently dropped. The tokeniser discarded words of two characters or fewer. That removed "AI", "JS" and "TS" — some of the most important words a visitor types. For "Does Amit know AI and JS?" the only tokens left were does, amit, know, and, so the ranking was driven by filler words.

2. No stopwords. Words like "what", "has", "with" and "does" were scored like real terms. In a 25-chunk corpus they add noise to every query.

3. No normalisation of word forms. "Which companies has he worked at?" matched only one chunk. "Worked" didn't match "work", and "companies" appears in only one place. The model received one job out of four — so it would confidently answer with an incomplete list.

None of these were visible from reading the code. They only appeared by running representative questions and looking at what came back.

The fix: a better tokeniser

All three problems live in one function. The improved version keeps two-letter words, removes stopwords, maps common synonyms and abbreviations, and applies a very light stemmer:

const STOPWORDS = new Set([
  'the', 'and', 'for', 'with', 'what', 'which', 'does', 'did', 'has', 'have', 'can',
  'his', 'him', 'about', 'tell', 'know', 'how', 'who', 'was', 'were', 'are', 'you',
  'is', 'he', 'do', 'at', 'in', 'of', 'to', 'an', 'on',
])

const SYNONYMS: Record<string, string> = {
  js: 'javascript', ts: 'typescript', ai: 'genai', llm: 'genai',
  frontend: 'front', backend: 'back',
  companies: 'experience', company: 'experience', worked: 'experience', job: 'experience',
}

const stem = (w: string) => w.replace(/(ing|ed|es|s)$/, '')

function tokenise(text: string): string[] {
  return text
    .toLowerCase()
    .replace(/front[\s-]end/g, 'front')
    .replace(/back[\s-]end/g, 'back')
    .replace(/[^a-z0-9\s]/g, ' ')
    .split(/\s+/)
    .filter((w) => w.length > 1 && !STOPWORDS.has(w))
    .map((w) => SYNONYMS[w] ?? w)
    .map(stem)
}

Because the same function tokenises both the chunks and the query, "front-end", "front end" and "frontend" all become front, and "JS" in a question matches "JavaScript" in the skills list.

Same questions, same data, before and after:

"Does Amit know AI and JS?" — before: tokens does, amit, know, and; top result was the generic profile chunk. After: tokens amit, genai, javascript; the top three are the profile ("GenAI Specialist"), the Generative AI skills chunk and the RAG project, followed by the JavaScript skills.
"Which companies has he worked at?" — before: 1 of 4 jobs retrieved. After: all 4 jobs in the top 5.
"Can he do frontend work?" — before: the top result was an awards chunk and only one project matched, because "frontend" never matched "front end". After: three front-end projects and an experience chunk make the top five, with the Everledger front-end project first.
Context size for "What has he built with Next.js?" dropped from about 2,900 to 2,200 characters, because filler-word matches no longer pull in weak chunks.

The synonym map is the part you'll customise most. Build it from real questions: log anonymised queries that return weak results, and add the words people actually use.

Is this "real" RAG?

Yes. RAG means retrieving relevant context and generating an answer grounded in it; nothing in the definition requires embeddings. BM25 is a retriever. What matters is whether the right chunks reach the model — and with a small, structured corpus, a tuned keyword retriever gets them there reliably, with nothing extra to host.

When would I switch? If the content grows into thousands of passages, if users ask conceptual questions in words that never appear in the text ("is he good with distributed systems?"), or if I add multiple languages. At that point I'd run BM25 and embeddings side by side and merge the results with reciprocal rank fusion — the hybrid approach I described in the vectorless RAG post.

Takeaways

For small, structured content, BM25 is a strong, cheap, debuggable retriever.
Chunk by meaning , and label each chunk with its type.
The tokeniser is where retrieval quality lives. Stopwords, short tokens and synonyms matter more than the scoring formula.
Test retrieval separately from generation. Print the top chunks for 20 real questions before you judge the model's answers.
Protect the endpoint with a rate limit and capped history before you share the link.

Try the assistant on my homepage — and if it gets something wrong, now you know exactly where I'll look first.

Originally published at www.tayloramitverma.com.

JavaScript Module Boundaries That Scale: Feature Folders, Public APIs and Lint-Enforced Imports

Amit Verma — Tue, 01 Oct 2024 00:00:00 +0000

A couple of summers ago I spent a weekend untangling an analytics bundle because one small helper imported the entire dashboard layer. The homepage was shipping chart libraries it never rendered. That refactor taught me something I still repeat to every team: modules are only useful when their boundaries make sense to the humans on call.

The language gives you import and export. It doesn't give you architecture. This post is the set of conventions — and the tooling that enforces them — that I use to keep a growing JavaScript or TypeScript codebase from turning into one big ball of imports.

Three questions that define a boundary

Before creating a folder, I answer three questions. If the team can't answer them in a minute, the boundary is muddy.

What does this module produce? One sentence. "Formats and sends invoices" is a boundary. "Utils" is not.
What does it depend on? List the other modules it's allowed to import.
How would we replace it? If swapping the email provider means touching 40 files, the provider isn't behind a boundary.

Organise by feature, not by file type

The classic layout groups by kind — components/, hooks/, services/, utils/. It looks tidy and scales badly: every feature is smeared across every folder, and nothing stops components/Chart from importing services/billing.

Group by feature instead, with a small shared layer underneath:

src/
  features/
    billing/
      api.ts # server calls
      components/
      hooks/
      index.ts # the public API of this feature
    analytics/
      ...
      index.ts
  shared/ # no feature imports allowed in here
    ui/
    lib/
  app/ # routes/pages — composes features

The dependency direction is one-way: app → features → shared. Features don't import each other's internals, and shared never imports a feature.

Give every feature a public API

Each feature exposes an index.ts with named exports for what other code may use. Everything else is private by convention:

// features/billing/index.ts
export { InvoiceTable } from './components/InvoiceTable'
export { useInvoices } from './hooks/useInvoices'
export type { Invoice, InvoiceStatus } from './types'
// formatLineItem, the API client, internal hooks: not exported

Other features import from @/features/billing, never from @/features/billing/components/InvoiceTable. When you refactor billing's internals, only billing changes.

I use named exports for these public APIs. They rename safely across the codebase, autocomplete well, and make "what does this module offer?" a one-file read.

Enforce it with lint, not code review

Conventions that rely on reviewers catching them don't survive deadlines. ESLint's built-in no-restricted-imports can block deep imports into another feature:

// eslint.config.mjs
export default [
  {
    files: ['src/**/*.{ts,tsx}'],
    rules: {
      'no-restricted-imports': [
        'error',
        {
          patterns: [
            {
              group: ['@/features/*/*'],
              message: 'Import from the feature’s public API (e.g. @/features/billing), not its internals.',
            },
          ],
        },
      ],
    },
  },
  {
    files: ['src/shared/**/*.{ts,tsx}'],
    rules: {
      'no-restricted-imports': [
        'error',
        { patterns: [{ group: ['@/features/*', '@/app/*'], message: 'shared/ must not depend on features or app.' }] },
      ],
    },
  },
]

The first rule stops deep imports between features. The second keeps the shared layer truly shared. For more complex rules — "billing may import from auth, but not the other way around" — dependency-cruiser lets you describe allowed edges between folders and fails CI when a new import breaks them.

Catch circular dependencies early

Cycles are the most common way boundaries rot. They also cause real bugs: with ES modules, a cycle can mean one module sees another's exports as undefined at load time.

madge finds them in seconds:

npx madge --circular --extensions ts,tsx src/

Run it in CI. A new cycle should block the merge just like a failing test.

Libraries: let package.json enforce the boundary

If the module is a package — in a monorepo or on npm — the exports field makes the public API a hard boundary. Anything not listed simply can't be imported:

{
  "name": "@acme/billing",
  "type": "module",
  "exports": {
    ".": "./dist/index.js",
    "./react": "./dist/react/index.js"
  }
}

import { x } from '@acme/billing/dist/internal/x' now fails with ERR_PACKAGE_PATH_NOT_EXPORTED. No lint rule needed.

Pass dependencies in, don't import them

Hidden imports make modules hard to test and hard to replace. Compare:

// Hidden dependencies: hard to test, tied to real time and the real store
import { fetchReport } from './analytics'
import { store } from './store'

export const buildSummary = () => store.persist(fetchReport(new Date()))

// Explicit dependencies: the boundary is visible in the signature
type Deps = {
  clock: () => Date
  fetchReport: (at: Date) => Promise<Report>
  store: { persist: (r: Report) => Promise<void> }
}

export const buildSummary = async ({ clock, fetchReport, store }: Deps) => {
  const report = await fetchReport(clock())
  await store.persist(report)
  return report
}

Tests pass a fake clock and an in-memory store. Production wiring happens once, at the edge of the app. You don't need a dependency-injection framework for this — a function argument is enough.

The barrel file trap

Public index.ts files are good. Barrel files that re-export everything are not. A shared/index.ts that does export * from './ui'; export * from './lib'; … causes two problems:

Bundle size. Depending on your bundler and how "side-effect free" the code is, importing one icon through a giant barrel can pull in far more than you asked for.
Slow dev servers and tests. Every import of the barrel loads every module behind it.

Keep public APIs small and intentional. For third-party barrels you can't change, Next.js has experimental.optimizePackageImports to rewrite them into direct imports.

Check the result, not just the rules

Before shipping a structural change I open the bundle analyser (@next/bundle-analyzer, or vite-bundle-visualizer) and confirm that lazy-loaded chunks stayed small. Then I write the boundary decision in the pull request description, so future me remembers why billing can't import from analytics.

Checklist

Each module answers: what it produces, what it depends on, how to replace it.
Code is grouped by feature, with a one-way dependency direction.
Every feature has a small index.ts public API with named exports.
no-restricted-imports (or dependency-cruiser) blocks deep and upward imports.
madge --circular runs in CI.
Packages use package.json exports.
Dependencies are passed in, not imported, at important boundaries.
No catch-all barrel files.

The analytics bundle that started all this stopped shipping chart code to the homepage after the refactor. More importantly, the problem hasn't come back, because the rules now live in CI instead of in my memory.

Originally published at www.tayloramitverma.com.

How to Install NVM, Install Node.js, and Manage Multiple Node Versions (Windows, macOS & Linux)

Amit Verma — Wed, 07 Feb 2024 18:30:00 +0000

Managing different versions of Node.js is essential for modern development. Some projects need an older version (like Node 14 or 16), while others need the latest LTS version.

NVM (Node Version Manager) makes this easy by allowing you to install, switch, and manage multiple Node.js versions on the same machine.

This guide explains how to:

✅ Install NVM

✅ Install Node.js using NVM

✅ Use multiple Node versions

✅ Switch between versions

✅ Uninstall or set default versions

✅ Works for Windows, macOS, and Linux

⸻

🚀 What is NVM?

NVM stands for Node Version Manager.

It is a command-line tool that lets you:

• Install any Node version

• Switch versions quickly

• Set a default version

• Use different versions per project

• Test your app in various Node environments

⸻

🟦 1. Install NVM on Windows

Windows does not support the original nvm-sh.

Instead, we use a dedicated tool called nvm-windows.

✅ Step 1 — Download Installer

Go to: 🔗 https://github.com/coreybutler/nvm-windows/releases

Download the file: nvm-setup.exe

✅ Step 2 — Run Installer

During installation:

• Choose location for NVM

• Choose Node.js symlink path

• Click Next → Install

✅ Step 3 — Verify Installation

Open cmd or PowerShell: nvm version

If you see a version number, NVM is ready.

⸻

✅ Install Node.js using Windows NVM

Install latest LTS: nvm install lts

Install a specific version: nvm install 18.17.0

Use a Node version: nvm use 18.17.0

Check current version: node -v

⸻

✅ 2. Install NVM on macOS (Official NVM)

On macOS, we use the original NVM from nvm-sh.

✅ Step 1 — Install via cURL

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

✅ Step 2 — Add NVM to your shell config

If you’re using zsh (default on macOS):

echo 'export NVM_DIR="$HOME/.nvm"' >> ~/.zshrc
echo '[-s "$NVM_DIR/nvm.sh"] && \. "$NVM_DIR/nvm.sh"' >> ~/.zshrc

Reload config: source ~/.zshrc

✅ Step 3 — Verify NVM

nvm -v

⸻

✅ Install Node.js on macOS

Install latest Node LTS: nvm install --lts

Install specific Node version: nvm install 20.10.0

Use a version: nvm use 20.10.0

⸻

✅ 3. Install NVM on Linux

Works on Ubuntu, Debian, Fedora, Arch, etc.

✅ Step 1 — Install NVM

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

or using wget:

wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

✅ Step 2 — Add to shell config (.bashrc or .zshrc)

export NVM_DIR="$HOME/.nvm"

[-s "$NVM_DIR/nvm.sh"] && . "$NVM_DIR/nvm.sh"

Reload: source ~/.bashrc

✅ Step 3 — Verify

nvm -v

⸻

🎯 Common NVM Commands (macOS & Linux)

✅ List installed Node versions

nvm ls

✅ List all available versions

nvm ls-remote

✅ Set default Node version

nvm alias default 18

✅ Uninstall a Node version

nvm uninstall 16

⸻

🎯 Common NVM Commands (Windows)

List installed versions: nvm list

Set default version: nvm use 20

Uninstall version: nvm uninstall 16.0.0

⸻

🧠 Tip: Use .nvmrc File Per Project

Inside any project, create a file named: .nvmrc

Add the Node version: 18

Then run: nvm use

NVM will automatically switch to the required Node version.

Originally published at www.tayloramitverma.com.

DEV Community: Amit Verma

I Built a RAG Chatbot for My Portfolio Without a Vector Database (BM25 + Next.js + Vercel AI SDK)

Why no vector database?

The architecture

Step 1: Chunk by meaning, not by character count

Step 2: BM25 in about 40 lines

Step 3: Stream the answer with the Vercel AI SDK

Step 4: Rate limiting with Upstash Redis

What broke when I tested it properly

The fix: a better tokeniser

Is this "real" RAG?

Takeaways

Related posts

JavaScript Module Boundaries That Scale: Feature Folders, Public APIs and Lint-Enforced Imports

Three questions that define a boundary

Organise by feature, not by file type

Give every feature a public API

Enforce it with lint, not code review

Catch circular dependencies early

Libraries: let package.json enforce the boundary

Pass dependencies in, don't import them

The barrel file trap

Check the result, not just the rules

Checklist

How to Install NVM, Install Node.js, and Manage Multiple Node Versions (Windows, macOS & Linux)