PokéDex AI.
My first LLM project.
A custom assistant trained on Pokémon data. Built two backends side-by-side — one with LangChain, one with ChromaDB — to learn how retrieval-augmented generation actually works.
The story
This was my first real LLM project. I wanted to understand retrieval-augmented generation — RAG — by building it instead of reading about it.
So I picked a fun domain (Pokémon), built two versions of the same backend, and compared them.
What I built
- A LangChain RAG backend — NestJS, HuggingFace embeddings, an in-memory vector store. The "framework" approach.
- A ChromaDB backend — NestJS again, but with a persistent vector database. The "do it from scratch" approach.
- Three frontend experiments to learn cross-platform desktop apps: React + Tauri, Svelte + Tauri, and Svelte + Electron.
- Google Gemini 2.0 Flash as the LLM behind both backends.
How it works
The PokéDex assistant answers natural-language questions about Pokémon. "Who has higher Sp. Attack — Mewtwo or Mew?" "What types is Charizard weak to?"
The flow is the same in both backends:
- User question → embed into a vector.
- Search the vector DB for the most relevant Pokémon data chunks.
- Stuff those chunks into the prompt as context.
- Send to Gemini, return the answer.
What I learned by building both: LangChain is great for getting started fast, but it hides a lot. Building the ChromaDB version forced me to understand chunking, retrieval ranking, and embedding choice properly.
The frontend experiments taught me the difference between Tauri (lighter, native) and Electron (heavier, more familiar). I prefer Tauri now.
Stack
Backend — NestJS, LangChain, ChromaDB, HuggingFace embeddings
(all-MiniLM-L6-v2), Google Gemini 2.0 Flash.
Frontend — React, Svelte, Tauri, Electron, Tailwind, Vite.
Why it matters
This is where the LLM trajectory started. RAG fundamentals here → vLLM pipelines on RunPod for the Yahuah project. The path from "I built a chatbot" to "I built a production GPU pipeline" was a year of intentional depth.