Case Study · AI Side Project · 2026

Building an AI recomendation chatbot that doesn't just make things up.

Book Buddy is a retrieval-grounded reading recommendation app that uses RAG over real book data to generate personalized, explainable book lists based on genre, mood, pace, length, and tropes.

RAG LLM products Recommendation UX Vector search Streamlit
📖 ~5 min read Type · AI side project Role · Builder / Product thinker Date · 2026
5structured recommendations per query
RAGarchitecture to ground outputs in real book data

The problem

AI recommendations are easy to generate. Harder to trust.

Most LLM recommendation experiences feel impressive at first. You describe what you want, the model gives you a polished list, and everything looks useful on the surface.

But when I started testing simple prompt-based book recommendations, the issues showed up quickly: recommendations became generic, repetitive, disconnected from the user’s actual preferences, or in some cases, completely made up.

The core product question became: how do you make AI recommendations feel personal without letting the model rely entirely on its own memory?

The idea

Ground the model first. Generate second.

I built Book Buddy to explore how retrieval-augmented generation could make recommendations more reliable. Instead of asking an LLM to freely recommend books, the app first retrieves relevant book summaries and descriptions from a local vectorstore, then uses that retrieved context to generate the final reading list.

The goal was not just to build a book recommender. It was to understand how grounding, structure, and explainability can make AI-generated recommendations feel more useful and trustworthy.

01

Collect

Scrape real book titles and descriptions from Goodreads pages.

02

Embed

Convert book content into vector embeddings for semantic search.

03

Retrieve

Use FAISS to find book content that matches the user’s preferences.

04

Generate

Use the LLM to create a structured, grounded reading list.

The interesting part was not “Can an LLM recommend books?” It was “Can the system explain why those recommendations are worth trusting?”

What I built

A simple RAG pipeline with a product layer on top.

The system separates the data pipeline, retrieval logic, LLM generation, and frontend into distinct parts. This made the app easier to reason about, test, and improve.

01 · Data prep

Scraping real book data

I scraped selected Goodreads pages to collect real book titles and descriptions. This gave the system a grounded dataset to retrieve from instead of depending on the model to invent recommendations from memory.

02 · Vectorstore

Embedding and storing book content

The book content is chunked, embedded using OpenAI embeddings, and stored locally in a FAISS vectorstore. This lets the app search by meaning, not just exact keywords.

03 · Retrieval + generation

Generating recommendations from retrieved context

When a user enters preferences, the backend retrieves relevant book chunks and passes them into the LLM prompt. The model then generates a structured 5-book list grounded in the retrieved data.

04 · Frontend

Turning outputs into a usable experience

The Streamlit interface lets users control preferences like genre, mood, pace, length, and tropes. Results are returned as clean recommendation cards with explanations and estimated reading time.

Key product decisions

The decisions that made the app feel less like a chatbot.

Use RAG to reduce hallucinations.

Instead of letting the model freely suggest books, I constrained recommendations to retrieved Goodreads content. This made outputs more grounded and reduced the risk of fabricated or irrelevant suggestions.

Return structured outputs.

I designed the app to return a consistent 5-book list with explanations and estimated reading times. This made the experience easier to scan and reduced messy, inconsistent LLM formatting.

Make explainability part of the UX.

Each recommendation includes a short reason why it fits the user’s preferences. This turns the system from “here are some books” into “here is why these books match what you asked for.”

Keep the architecture modular.

I separated scraping, vectorstore creation, backend retrieval logic, and frontend rendering. This made it easier to debug and gives the project a cleaner path for future improvements like re-ranking or feedback loops.

Tech stack

The system underneath.

Backend

Python

Used for the retrieval pipeline, LLM calls, post-processing, and app logic.

RAG

FAISS + embeddings

Stored embedded book content locally and retrieved relevant chunks using similarity search.

LLM

OpenAI API

Generated structured recommendations using retrieved book context and user preferences.

UI

Streamlit

Created an interactive interface with preference controls and chat-style history.

Challenge

Relevance alone did not create a good recommendation list.

One of the biggest things I noticed was that the most semantically similar results were not always the best user experience. Early outputs often recommended books that were technically relevant, but too similar to each other.

That made the app feel repetitive. It exposed a real recommendation-system tradeoff: maximizing similarity does not always maximize user satisfaction.

What I would improve next

I would add diversity constraints, re-ranking, and a lightweight feedback loop where users can mark recommendations as “more like this,” “too slow,” or “not my vibe.” That would let the system learn from user reactions instead of treating every query as a fresh start.

Impact

What this project shows.

Book Buddy helped me explore how LLM apps need more than a good prompt. The most important work was designing the system around the model: retrieval, constraints, structured output, and a user experience that makes the results easier to trust.

Learnings

What I took away.

This project shifted how I think about AI products. The goal is not just to make a model respond. The goal is to design the right system around the model so the output is useful, grounded, and understandable.

  • LLM fluency can hide weak product quality. A polished answer is not automatically a good recommendation.
  • Grounding improves trust. RAG helped tie outputs to real source material instead of relying only on model memory.
  • Explainability is part of the product experience. Users need to understand why something was recommended, not just what was recommended.
  • Recommendation systems need balance. Relevance matters, but diversity, preference refinement, and feedback loops matter too.

Try it out

Want to explore the project yourself?

You can check out the full codebase, retrieval pipeline, and Streamlit app on GitHub .