AI for Beginners: Build a Movie Recommendation List You’ll Use

Section 1.1: AI in plain language vs. rules

When people say “AI recommendations,” they often picture a mysterious brain. In practice, beginner-friendly recommenders are usually closer to “patterns from examples” than “human-like thinking.” A rules-based approach is explicit: if the movie is a comedy and under 100 minutes, then recommend it. Rules can work, but they break quickly when your taste is nuanced (“I like some slow dramas, but only if the acting is strong”).

AI-style approaches learn from signals you provide—ratings, likes, watches, skips—and try to generalize. They don’t need you to articulate every rule; they infer what tends to go together. That doesn’t mean they’re always “smart.” They can be confidently wrong when the data is thin, biased, or messy. A key engineering judgment is knowing when a simple rule beats a complicated model. Early in this course, you’ll intentionally keep the “AI” part lightweight so you can control it and understand it.

• Common mistake: believing AI will fix poor inputs. If your ratings are inconsistent, the recommender will reflect that inconsistency.
• Practical mindset: treat your recommender like a personal tool. It should be transparent enough that you can debug it when it suggests something odd.

As you read the rest of this chapter, notice how often “recommendation” is really a workflow: collect signals → create a clean dataset → generate a ranked list → sanity-check it. The AI is only one piece of that pipeline.

Section 1.2: What a recommendation system does

A recommendation system takes a set of options and produces a prioritized shortlist for a specific situation. That situation matters: “What should I watch tonight?” is different from “What movies should I explore this month?” The first is time-sensitive and mood-sensitive; the second rewards variety and discovery. Your goal in this course is a movie list you can act on—something you could open, pick from in a minute, and feel good about.

You already use recommendation systems constantly: Netflix rows, YouTube home feed, TikTok “For You,” Amazon “Customers also bought,” Goodreads suggestions, and even Google Maps restaurant picks. Each one is doing the same basic job: reduce choice overload. The difference is the context and constraints—availability, price, length, and your patience. A practical recommender respects constraints first, then optimizes for preference.

• Input: information about you (or people like you), about movies, and about your interactions.
• Process: rank or filter movies to produce a short list.
• Output: recommendations plus (ideally) a reason you can understand, such as “similar to movies you rated highly.”

Common mistake: building a recommender that outputs hundreds of titles. That’s a catalog, not a recommendation. In this course, you will aim for a list size that matches reality—often 10–30 movies. You should be able to watch through it, update ratings, and regenerate a better list later. That feedback loop is how recommenders improve.

Section 1.3: Movies as “items” and you as a “user”

Most recommenders can be explained with three building blocks, starting with users and items. In this course, you are the user (at least for the first version), and movies are the items. That sounds obvious, but defining “movie” carefully avoids messy data later. For example: do you include documentaries? Concert films? Mini-series? Director’s cuts? If you mix these without labeling them, your recommender may suggest a three-part mini-series when you wanted a single sitting movie.

Scoping is an engineering decision, not a philosophical one. Choose boundaries that make the project doable and useful. A good beginner scope is “feature films available on the services I currently have,” plus optionally “movies I’m willing to rent.” Also decide whose taste you’re modeling. Start with one user: you. Multi-user recommenders introduce complexity (different rating scales, conflicting preferences) that can wait until later.

• Constraint examples: under 120 minutes; not horror; only English-language; only movies released after 1990; only titles available on a specific platform.
• Data consistency tip: pick a canonical movie identifier (title + year is a good start) so you don’t rate “Dune” and “Dune (2021)” as if they were different by accident.

The practical outcome of this section is a clear definition of what you’re recommending and for whom. Write it down in one sentence in your workspace. It will prevent scope creep and make your final list more trustworthy.

Section 1.4: Signals: ratings, likes, watches, and skips

The third building block is signals: evidence of preference. Signals can be explicit (you rate a movie 1–5) or implicit (you watched it to the end, rewatched it, abandoned it after 10 minutes, skipped past it). Recommendation systems often rely heavily on implicit signals because they’re plentiful, but for a beginner project, explicit ratings are easier to reason about and debug.

You will turn your personal preferences into a small dataset. The goal is not perfection; the goal is consistency. Choose a rating scale you can stick with. A practical option is 1–5 stars with clear meanings: 5 = loved it and would rewatch; 4 = liked; 3 = fine/neutral; 2 = disliked; 1 = strongly disliked. If you prefer thumbs up/down, that’s also workable, but it gives less nuance for “similar movies.”

• Common mistake: rating based on “what I think is objectively good” rather than “would I recommend this to myself on a random night?” Your data should represent your future decisions.
• Basic data checks: no missing titles; consistent year formatting; ratings within allowed values; no duplicates with slightly different titles (“Spider-Man” vs “Spiderman”).
• Practical tip: include a short note column for context (e.g., “great soundtrack,” “too slow,” “fun with friends”). Notes help you interpret weird recommendations later.

In this course you will set up your workspace (spreadsheet or provided template) early, because clean data is what makes the later steps feel easy. Think of this as building a small personal dataset you can reuse rather than a one-off homework table.

Section 1.5: The idea of similarity (without math)

One of the simplest useful recommenders is “similar movies.” Similarity means: if you liked Movie A, which other movies are close enough to A that you might also like them? Importantly, “close” can be defined in different ways. Sometimes it’s about content (same genre, director, cast, themes). Other times it’s about behavior (people who liked A also liked B). You will build beginner-friendly versions, so you’ll keep similarity understandable and easy to test.

Without math, you can think of similarity as “shared signals.” Two movies are similar if they tend to receive similar ratings from you (or from many users), or if they share descriptive attributes you care about. Early on, you’ll likely use a mix: a little metadata (genres, year) plus your ratings. This helps when your dataset is small—because your ratings alone may not cover enough movies to find good neighbors.

• Engineering judgment: prefer explanations you can defend. “Recommended because it shares genres and you rated similar titles highly” is easier to trust than an opaque score.
• Common mistake: confusing popularity with similarity. A blockbuster can appear everywhere, but that doesn’t mean it matches your taste.
• Practical outcome: you will be able to generate a “because you liked X” mini-list, which is a powerful way to explore intentionally rather than scrolling endlessly.

Later, when you build “movies for you,” you’ll combine multiple similarity signals to rank candidates. For now, keep the concept simple: similarity is a tool for narrowing choices, not an absolute truth.

Section 1.6: Your project plan and success criteria

A beginner project succeeds when it produces something you will use. Define your deliverable and how you’ll judge it before you build anything. Your deliverable is a clean movie list and two recommenders: (1) “similar movies” and (2) “movies for you.” Your success criteria should be human-friendly and measurable enough to guide improvements.

Start by choosing your workspace: a spreadsheet is perfect. Create columns such as: Title, Year, Watched?, Rating, Genres, Platform/Availability, Notes, and optionally Date Rated. The point is not to track everything; it’s to track what you’ll actually use for decisions. Add basic validation where possible (dropdown for watched yes/no, rating range enforcement) to prevent silent errors.

• Scope statement (write yours): “Recommend feature films I can access this month, for one viewer (me), optimized for enjoyable weeknight watching.”
• Constraints (pick 2–4): maximum runtime, excluded genres, language, platform, age rating, mood tags.
• Success criteria examples: at least 7 of the top 10 recommendations are movies you genuinely want to watch; recommendations include at least 3 “safe picks” and 3 “exploration picks”; no duplicates or unavailable titles in the final list.

Common mistake: skipping the “act on it” test. A recommender that produces interesting titles but none you will actually start tonight has failed its primary job. In later chapters you will evaluate with simple tests (does it surface forgotten favorites? does it avoid obvious dislikes?) and basic metrics, but your first criterion is practical: the list should make choosing a movie easier.

With your scope, dataset columns, and success criteria defined, you’re ready to start collecting ratings and building the simplest possible recommenders—then iterating based on what you learn from your own experience using the list.

A dataset is just a table where each row represents one thing (an “example”) and each column represents a property of that thing (a “feature”). For your project, the “thing” is a movie you’ve watched, and the properties include your rating and a few details about the movie.

Start by deciding what a single row means. A common mistake is mixing concepts in one table—for example, having some rows represent movies and other rows represent “views” (the same movie multiple times). For beginners, keep it simple: one row per movie. If you rewatch a movie and your opinion changes, update the rating in that row and record the change in a notes column (you’ll set that up later).

Your minimum useful dataset can be as small as 20–30 movies, but aim for 40–80 if you can. The key is variety: include movies you loved, movies you disliked, different eras, and different genres. This starter collection is your seed list. You can pull it from your memory, a streaming “watched” list, Letterboxd history, or even a notes app. What matters is that you’ve actually seen them and can rate them confidently.

• Rows: individual movies you have watched.
• Columns: title, year, your rating, and a few context fields.
• Outcome: a consistent table that can be filtered, sorted, cleaned, and later used by recommenders.

Think of this dataset as a “personal sensor.” It captures your preferences in a form a computer can work with. The better your rows and columns reflect consistent decisions, the more trustworthy your recommendations will be.

A rating scale is a contract you make with yourself. If you rate inconsistently—giving a “5” sometimes to mean “amazing” and other times to mean “pretty good”—your dataset becomes noisy, and your recommender will learn the wrong signals.

Choose a scale you can apply quickly. Two beginner-friendly options:

• 1–5 stars (integers): simple, familiar, and easy to keep consistent.
• 1–10 (integers): more expressive, but easier to overthink.

For this course, a 1–5 scale is usually best. Define each value in plain language and write it down so you can refer back to it. Example definitions:

• 5 = Loved it; would rewatch; would recommend strongly.
• 4 = Really liked it; would recommend.
• 3 = Okay; some good parts; neutral overall.
• 2 = Didn’t like it; wouldn’t recommend.
• 1 = Strongly disliked; regret watching.

Now apply your scale consistently. A practical method is to rate in batches of 10–15 movies, then stop and sanity-check: do the ratings “feel” right relative to each other? If everything is a 4 or 5, your scale may be too generous; if everything is a 2 or 3, you may be using the scale as a “quality score” rather than a “personal enjoyment score.” This course works best when ratings represent your preference, not what you think is objectively “good.”

Common mistake: mixing “not seen” with a low rating. If you haven’t watched a movie, leave it out of this dataset for now. Unwatched movies belong in a separate “candidate list” later, not in your rating table.

Use a tool that makes editing easy: Google Sheets, Excel, or Numbers. Create a new sheet called something like movie_ratings. Then build your first table with clear column headers. Here is a practical starter schema (you can copy these headers directly):

• movie_id (optional but recommended): a unique ID you assign, like M0001, M0002…
• title: the movie title as you commonly write it.
• year: release year (four digits).
• rating: your rating (1–5).
• genre: one or more genres (you’ll standardize later).
• runtime_min: runtime in minutes (integer).
• watched_date (optional): when you watched it (YYYY-MM-DD).
• notes: short free text (why you rated it that way).

Now populate your seed list. Start with 20 movies you can rate instantly. Don’t get stuck researching details yet—focus on getting the table shape correct. Once the first 20 are in, add the next 20. This staged approach prevents “setup fatigue.”

Add simple movie details for context: genre, year, runtime. These fields help in two ways: (1) they let you eyeball whether your dataset has variety, and (2) later, they give you a baseline for “similar movies” recommendations (for example, movies in the same genre range and era).

Engineering judgment: keep the table narrow at first. Beginners often add too many columns (director, actors, studio, language, awards) and then abandon the project. You can always expand later. For now, capture what you will actually maintain.

Cleaning is not glamorous, but it’s where your recommender’s reliability begins. Two issues show up immediately in small personal datasets: duplicates and missing values.

Duplicates happen when you enter the same movie twice with slightly different titles, like “Alien” and “Alien (1979).” They also happen with remakes (same title, different year). Your first defense is structure: include year, and if possible a movie_id. Then check duplicates by sorting the sheet by title and year, or using a “Remove duplicates” feature (but be careful—don’t remove remakes accidentally).

Missing entries happen when you leave year blank, forget runtime, or skip a rating. Decide which columns are required. For recommendation training later, the only truly required field is rating plus a stable identifier (title + year, or movie_id). Genres and runtime are helpful but can be filled in gradually.

Practical rules:

• If rating is missing, the row isn’t usable yet—either rate it or remove it until you do.
• If year is missing, try to fill it in; otherwise, your duplicate detection gets harder.
• If runtime_min is missing, leave it blank for now, but be consistent (blank, not “?” or “unknown”).

Common mistake: using mixed formats. For example, runtime as “2h 10m” in some rows and “130” in others. Pick one representation (minutes as an integer is easiest for later math) and convert everything to that.

Computers are literal. If you write “Sci-Fi” in one row and “Science Fiction” in another, a program will treat them as different genres unless you normalize them. The same is true for movie titles (“Spirited Away” vs “Spirited Away (Dub)”) and even punctuation (“Se7en” vs “Seven”). Consistent labels make later grouping and similarity matching dramatically easier.

Start with two normalization decisions:

• Movie naming rule: store title without extra notes. Put versions like “Director’s Cut” or “Dub” in notes. Use year to disambiguate.
• Genre vocabulary: create a small approved list and stick to it.

A practical genre list for beginners might include: Action, Adventure, Animation, Comedy, Crime, Drama, Fantasy, Horror, Romance, Sci-Fi, Thriller, Documentary. If you want multiple genres per movie, choose a separator and use it consistently, such as Comedy|Romance. Avoid commas if you plan to export CSV later, because commas often separate columns.

Engineering judgment: don’t chase perfect genre accuracy. Genres are fuzzy. Your goal is consistency, not film-studies precision. If you can apply the same labels the same way across your seed list, your later “similar movies” recommender will have cleaner signals to work with.

Common mistake: changing labels over time without backfilling. If you decide to rename “Sci-Fi” to “Science Fiction,” update all rows (find/replace) so your dataset stays coherent.

Your dataset is a living artifact. If you plan to reuse it—adding new movies, adjusting ratings, or fixing mistakes—you need minimal documentation so you can trust future changes. This is “versioning,” and you can do it even without any code.

First, include lightweight metadata inside the sheet:

• watched_date: helps you remember context (you might rate differently in different phases of life).
• notes: capture short reasons (“loved the pacing,” “too slow,” “great soundtrack”). These notes help later when you evaluate recommendations in human terms.

Next, version your file. A simple approach:

• Export a copy as movie_ratings_v1.csv when you finish your first clean pass.
• When you make significant changes (add 20 movies, normalize genres, fix duplicates), save movie_ratings_v2.csv.
• Keep a tiny changelog in a separate tab called CHANGELOG with date and what changed.

Why this matters: when you later build recommenders, you’ll want to know whether a change in recommendations came from your algorithm or from your data edits. Versioning gives you that control. It also protects you from accidental edits—if you delete rows or overwrite ratings, you can roll back.

Practical outcome for this chapter: you should now have a seed list in a spreadsheet, rated with a consistent scale, enriched with a few context fields, cleaned for obvious duplicates and missing ratings, labeled with consistent genres and titles, and saved as a versioned dataset you can update. That dataset is the foundation for every recommender you build next.

Section 3.1: Content-based recommendations explained

A content-based recommender answers a simple question: “If I liked this movie, what else is similar to it?” It does that by comparing movie attributes—genres, keywords, cast/crew, plot themes, and even numeric traits like runtime or release year. The core assumption is that your enjoyment is related to these attributes. If two movies share many attributes, they’re likely to feel similar.

This approach has two big benefits for beginners. First, it is transparent: you can explain why a movie was suggested (“both are Sci‑Fi and Action, and both are in the 2010s”). Second, it works even when you have very few ratings, because it does not require many users or a lot of historical behavior data.

It also has limitations you should anticipate. A content-based system can get stuck in a “taste bubble,” repeatedly recommending items that are too similar. It can also miss movies that are different on the surface but loved by similar audiences (that’s where collaborative methods help). For this chapter, that’s okay—your goal is a reliable, inspectable baseline.

• Input: one seed movie (a favorite) plus a catalog of movies with features.
• Process: convert each movie into a feature vector, compute similarity to the seed, rank, and filter.
• Output: a short “more like this” list with reasons you can read.

A common mistake is to treat similarity as “same genre only.” That usually produces generic results and misses nuance. Instead, you’ll combine multiple simple features so that “similar” means “shares several traits,” not just one label.

Section 3.2: Features: genres, keywords, and year buckets

To recommend similar movies, you need to represent each movie using features that are (1) available for most movies in your list, (2) stable over time, and (3) meaningful to viewers. For a beginner-friendly build, three feature groups work well: genres, a small set of keywords, and year buckets.

Genres are your backbone features. They are usually multi-label (a movie can be Action and Sci‑Fi). Treat each genre as a binary flag: 1 if the movie has it, 0 if not. Be careful with inconsistent spelling (“Sci-Fi” vs “Sci Fi”). Normalize early so your feature list doesn’t split into duplicates.

Keywords add specificity. Genres can’t distinguish “space opera” from “time travel,” but keywords can. Keep keywords beginner-simple: choose a small, curated vocabulary (for example 20–50 terms) that appears in your dataset. You can build it manually from your list or by taking the most frequent tags and removing vague ones (“based on novel,” “sequel”). If you overuse keywords, you’ll create sparse data where nothing matches; start small and expand later.

Year buckets capture the “era feel” without overfitting to a single year. Instead of using the exact release year, group into buckets like 1980s, 1990s, 2000s, 2010s, 2020s. This helps because viewers often perceive production style by decade. It also avoids awkward comparisons where 2014 and 2015 are treated as meaningfully different.

• Rule of thumb: Prefer features you can explain in one sentence.
• Data check: Verify every movie has at least one genre; otherwise similarity scores collapse to zero.
• Engineering judgment: Start with fewer, higher-quality features; add more only when you can tell what they improve.

By the end of this section, you should be able to look at any movie row and see a clear set of on/off feature values that describe it.

Section 3.3: Turning features into a simple comparison

Once each movie is represented by the same set of features, you need a way to compare two movies. The beginner-friendly approach is to create a binary feature vector for each movie and then compute a similarity score. A practical and intuitive metric for binary features is Jaccard similarity: it measures how much the two movies overlap relative to how many features they have in total.

In plain language: similarity = shared features / all unique features. If two movies share 3 features and have 6 unique features combined, their Jaccard similarity is 3/6 = 0.5. Scores range from 0 (no overlap) to 1 (identical feature set).

This works well for genres and keywords because they are “present or not present.” For year buckets, treat the bucket as a single binary feature as well (exactly one bucket is 1). That makes year act as a gentle tie-breaker: movies from the same era get a small boost.

Common mistakes to avoid:

• Comparing mismatched vocabularies: If one movie uses “Sci-Fi” and another uses “Science Fiction,” you’ll get artificial mismatches. Normalize your labels first.
• Letting keywords dominate: If you include 200 keywords but only 10 genres, overlap becomes rare. Start with fewer keywords or weight genres higher.
• Ignoring missing data: If keywords are missing for many movies, decide on a consistent behavior (empty set) and expect lower similarity.

If you want a slightly more controllable score without jumping into advanced math, add simple weights: count a genre match as 2 points, a keyword match as 1 point, and a year-bucket match as 0.5 points, then divide by the maximum possible points for the combined feature set. The key is not the exact numbers—it’s that you can reason about them and adjust when results feel off.

After this step, you should be able to compute a similarity score between your favorite movie and every other movie in the catalog.

Section 3.4: Ranking: sorting by similarity score

With a similarity function in hand, generating recommendations becomes a ranking problem: compute the similarity score from the seed movie to every candidate movie, then sort from highest to lowest. The top of that list is your “more like this” set.

In practice, you’ll want to store more than just the score. Keep a few debugging fields: which genres matched, which keywords matched, and whether the year bucket matched. This turns ranking from a black box into a tool you can tune. If a surprising recommendation appears, you can immediately see whether it is a data issue (wrong genre tags) or a scoring issue (keywords overpowering genres).

Decide how many recommendations to show. A good default for a personal list is 10–20. Fewer than 10 can feel repetitive; more than 20 becomes a backlog rather than a decision aid.

Ties are common—many movies will share the same genre set. Add simple tie-breakers that keep the system human-friendly:

• Popularity or rating count: If you have it, prefer movies with more votes (more “proven” picks).
• Recency: For some users, newer movies are easier to access; for others, era matching matters more.
• Deterministic ordering: If you don’t have extra metadata, tie-break alphabetically so results are stable run-to-run.

A workflow that prevents confusion: (1) pick the seed movie, (2) generate the full ranked table, (3) inspect the top 30, (4) adjust features or weights once, then (5) regenerate. Avoid endless tweaking—make small changes, verify, and move on.

By the end of this section you should have a ranked list that looks plausible, plus enough evidence (“matched features”) to trust or debug it.

Section 3.5: Basic guardrails: already-watched and duplicates

A similarity ranker will happily recommend things you’ve already seen, the seed movie itself, and near-duplicates like a director’s cut, remaster, or the same title spelled slightly differently. Guardrails are simple rules that make outputs feel immediately more useful—often more than changing the similarity formula.

Guardrail 1: Remove the seed movie. It sounds obvious, but it’s easy to forget when you compute similarity across the full dataset. Always filter out the seed movie’s unique ID (or normalized title + year) before taking the top N.

Guardrail 2: Filter already-watched items. Use the ratings dataset you built earlier: if a movie has a rating (or a “watched” flag), exclude it from recommendations by default. Keep an option to include watched movies when you want “rewatch” ideas, but make the default action-oriented.

Guardrail 3: Deduplicate titles. Build a normalized key such as lowercase(title) plus release year, and collapse duplicates. When you detect duplicates, choose a preferred record (for example: the one with more complete metadata). Without this, your top 10 might contain three versions of the same movie.

Guardrail 4: Handle series and franchises carefully. Content similarity often over-recommends direct sequels because they share many keywords and genres. That may be good (“watch the sequel”) or boring (“everything is Marvel”). A practical rule of thumb is to limit to one item per franchise keyword, or at least ensure variety in the top N by requiring that each new recommendation adds at least one new genre/keyword not already represented in the list.

These guardrails are not “cheating.” They are part of building a recommendation system that respects user context. In real-world systems, filtering and business rules are a major part of quality.

Section 3.6: Packaging results as a clean recommendation list

Now package your ranked, filtered results into a clean recommendation list you can reuse. Think of this as a small product: it should be readable, repeatable, and easy to update when your movie catalog changes.

Start by defining a standard output table. At minimum include:

• seed_title (the movie you started from)
• rec_title and rec_year
• similarity_score
• matched_genres (comma-separated)
• matched_keywords (comma-separated, optional)
• notes (optional: “same decade,” “same director” if you later add those features)

Including “matched features” is not just nice for users—it is your debugging tool. When a recommendation feels wrong, you can see whether it matched on only a weak signal (for example, year bucket only) and decide whether to add a minimum-match rule (e.g., must share at least one genre, or at least two total features).

Create a reusable template workflow:

• Step A: Choose the seed movie (by ID, not by raw title text).
• Step B: Build/refresh the feature matrix for the entire catalog.
• Step C: Compute similarity from seed to all candidates.
• Step D: Apply guardrails (remove seed, watched, duplicates, franchise rules).
• Step E: Sort, take top N, and export (CSV/Sheet).

A common packaging mistake is to export only titles. Titles alone are fragile (same name, different year) and hard to maintain. Always store IDs and years so you can update metadata later without breaking your list.

Once you have this template, you can run it whenever you add movies, adjust your keyword vocabulary, or want recommendations for a different seed. You’ve built a practical, inspectable “similar movies” recommender—an essential foundation for the personalized “movies for you” system coming next.

Collaborative filtering is the family of methods behind the phrase “people like you liked…”. Instead of analyzing the movie itself (plot keywords, actors, genres), it learns from patterns of ratings. If your ratings line up with someone else’s ratings on movies you both watched, that person becomes a clue for what you might enjoy next.

There are two common perspectives, and beginners often mix them up:

• User-based: find users with similar taste to you, then recommend what they liked.
• Item-based: find movies similar to a movie you liked, based on how many users rate them similarly.

This chapter focuses on user-based logic because it maps directly to “neighbors” and is easy to reason about with small data. Later, you can adapt the same thinking to item-based “similar movies.”

Engineering judgment: collaborative filtering is powerful because it can discover surprising connections (you and another user both love a niche film). But it is also fragile when data is sparse. With a tiny dataset, your similarity scores can swing wildly if two users overlap on only one movie. A practical rule: require a minimum overlap (for example, at least 3 shared rated movies) before you trust a similarity score.

Common mistake: treating collaboration like a mind-reading device. It’s not. It’s a structured guess based on limited evidence, so you want simple sanity checks: do the recommended movies look plausible given what you rated highly, and are you avoiding movies you already disliked?

To collaborate, you need other people’s ratings. In a beginner course, you have two practical options:

• Synthetic users: you generate a handful of fake user profiles to test your system.
• Shared ratings: you ask friends/classmates to rate a short list (even 10–20 movies each).

Either way, structure the data in a consistent “long” format:

• user_id (e.g., u_me, u_01)
• movie_id or a stable movie key (avoid raw titles if possible)
• rating (e.g., 1–5)

From this long table, you can imagine a rating matrix: rows are users, columns are movies, and cells contain ratings. Most cells will be empty because nobody rates everything. That emptiness is normal; it’s what you design around.

Data checks that matter before you compute anything:

• Rating scale consistency: ensure everyone uses the same scale (1–5, not mixed with 1–10).
• Duplicate rows: one user should not have two ratings for the same movie unless you decide how to merge them (latest wins, average, etc.).
• Movie identity: “Alien” (1979) vs “Alien” (other) needs a consistent identifier; otherwise your matrix becomes nonsense.

Practical workflow: start with 5–10 users (including you) and 30–60 movies total. You’ll get enough overlap to see the method work, but not so much data that you lose track of what’s happening.

Common mistake: filling missing ratings with zeros. A missing rating is not a dislike; it is unknown. Treat missing as missing and compute similarity only on the overlap.

Once you have multiple users, you need a way to measure “how similar” two taste profiles are. For a beginner-friendly approach, keep it direct: compare users only on movies both have rated, and compute a simple score.

Two practical similarity choices:

• Mean absolute difference (MAD): for the overlap movies, compute the average of |r_me - r_other|. Smaller is more similar.
• Cosine similarity on centered ratings: subtract each user’s average rating first (so generous raters don’t look similar to everyone), then compute cosine similarity. Larger is more similar.

If you want a very transparent method, MAD is hard to beat: you can show the overlap list and the per-movie differences. To turn it into a “similarity” where bigger is better, you can convert it, for example: similarity = 1 / (1 + MAD).

Add two safeguards that dramatically improve quality:

• Minimum overlap: ignore comparisons with fewer than N shared movies (start with N=3).
• Overlap weighting: prefer users with more shared ratings. A simple tactic is weighted_similarity = similarity * (overlap_count / (overlap_count + 2)). This gently down-weights “similar” users who only overlap on a couple of films.

Engineering judgment: similarity is not “truth”; it’s a knob. If your overlap threshold is too high, you’ll have no neighbors; too low, you’ll trust noisy matches. Pick a threshold that yields 2–5 neighbors most of the time for your dataset size.

Common mistake: forgetting rating bias. Some users rate nearly everything 5/5, others rarely go above 3/5. Centering ratings (subtracting each user’s mean) is a simple, effective fix when you move beyond MAD.

With similarity scores in hand, you can produce personalized recommendations using a “neighbors vote” idea. The workflow looks like this:

• Compute similarity between you and every other user (using only overlaps).
• Select the top K neighbors (start with K=3 to 5).
• Collect movies your neighbors rated that you have not rated yet.
• Score each candidate movie based on neighbor ratings and similarity weights.

A simple scoring rule is a weighted average:

• score(movie) = sum(sim(u) * rating(u, movie)) / sum(sim(u)) across neighbors who rated the movie

Then sort by score and take the top N as “movies for you.” In practice, also add two filters:

• Minimum neighbor support: require at least 2 neighbors to have rated the movie before recommending it (reduces one-person flukes).
• Exclude known dislikes: if you rated a related movie low (or if you have explicit “no-go” genres), you can down-rank similar candidates later in a hybrid step.

Practical outcome: your recommendations become explainable. You can attach a reason string like: “Recommended because u_03 (very similar) rated it 5 and u_07 rated it 4.” This is not just nice UX; it’s a debugging tool. If a recommendation looks wrong, you can see which neighbor caused it.

Common mistakes:

• Recommending already-rated movies: always subtract your watched list.
• Letting one super-similar neighbor dominate: cap similarity weights or use K neighbors to diversify.
• Ignoring uncertainty: a movie rated by only one neighbor should be treated as low-confidence.

At the end of this step you should have a ranked list plus basic metadata: predicted score, neighbor count, and a short explanation of where it came from.

Collaborative methods have a famous weakness called cold start: they struggle when there is not enough rating history. You’ll see it in two forms.

• New user: you have few or no ratings, so you can’t find reliable neighbors.
• New movie: a movie has few ratings, so it rarely appears as a strong recommendation.

Beginner-friendly fallback strategies that work well:

• Popularity baseline: recommend the most-liked movies overall (by average rating with a minimum rating count). This is simple and surprisingly effective.
• Short onboarding ratings: ask the user to rate 5–10 well-known movies spanning different styles. Choose movies likely to be recognized so you get fast signal.
• Genre-first defaults: if the user selects a few preferred genres, start from top-rated movies in those genres until collaborative signal grows.

Engineering judgment: do not pretend collaboration works when it doesn’t. Implement a clear rule such as: “If I have fewer than 5 ratings or fewer than 3 overlap movies with any other user, switch to fallback.” You can still compute collaborative suggestions, but label them as low confidence.

For new movies, the best you can do in a small project is: let content signals (genre, year, keywords) give them exposure, or treat them separately in a “new releases” lane that does not depend on ratings. In real systems, exploration strategies handle this; for your course project, a simple lane-based approach is enough.

Common mistake: using a fallback that never turns off. Make sure you transition from popularity/genre defaults to collaborative suggestions as soon as your overlap becomes meaningful.

Pure collaboration is only one tool. A practical recommender often becomes a hybrid: it mixes what you know about the items (content) with what you know about people (taste patterns). Hybrids are not automatically complex—you can build a simple, reliable one with rules and small weights.

Three beginner-friendly hybrid patterns:

• Two-stage: generate candidates with collaborative filtering, then re-rank using content preferences (e.g., boost genres you love, down-rank genres you avoid).
• Weighted blend: final_score = 0.7 * collaborative_score + 0.3 * content_score (tune these weights by eyeballing results).
• Fallback ladder: if collaborative confidence is low, rely more on content/popularity; as confidence rises, increase collaborative weight.

A simple content score can come from your earlier work: if you built a “similar movies” list using genres or tags, reuse it. For each candidate movie, compute a content similarity to movies you rated highly, and combine it with the neighbor-based predicted rating.

Engineering judgment: hybrids are a safety net against weird neighbor effects. For example, you might match a neighbor because you both loved one sci-fi classic, but that neighbor also loves slapstick comedies you dislike. A content re-rank step can push your preferred genres back to the top and improve perceived quality immediately.

Common mistakes:

• Overfitting to your own favorites: if you only boost one genre, recommendations become repetitive. Use small boosts and keep some diversity.
• Mixing incomparable scales: collaborative scores might be 1–5, content similarity might be 0–1. Normalize before blending.

Practical outcome: you end this chapter with two complementary recommendation lanes—“Because similar users liked it” and “Because it matches movies you liked”—plus a cold-start plan. That combination is enough to produce a reusable recommendation list that stays helpful as your ratings grow.

Section 5.1: Evaluation without heavy math

Before you measure anything, define what “good” means. For movie nights, “good” is rarely one number. It’s a set of outcomes you care about: finding something you’ll actually watch, avoiding repetitive picks, and discovering a few pleasant surprises.

Start by writing down 3–5 success criteria as plain-language metrics. Keep them concrete so you can check them quickly each time you update your list. Examples that work well for beginners:

• Relevance: At least 5 out of the top 20 look genuinely appealing.
• Variety: The top 20 spans multiple genres and at least two decades (or languages, or countries—whatever matters to you).
• Freshness: At least 3 recommendations are movies you did not already know.
• Usefulness: You can pick one movie within 2 minutes of scanning.

Notice that none of these requires advanced math, but they are still measurable. This is engineering judgement: you choose evaluation criteria that match the real use case (choosing a movie), not a theoretical objective.

A second beginner-friendly principle: evaluate the list, not individual titles. Any recommender will produce a few bad items. What matters is whether the list has enough good candidates and whether the bad ones follow a pattern you can fix (for example, always recommending the most popular films).

Finally, separate “quality” from “taste.” If your recommendations include movies you dislike because your ratings dataset is tiny or inconsistent, that’s not the model being “wrong”—it’s the system reflecting the input. Evaluation is your feedback loop for deciding whether to collect more ratings, add filters, or adjust weighting.

Section 5.2: A simple holdout test (train vs. test idea)

If you evaluate on the same movies you used to build the recommender, you’re grading it on material it has already “seen.” That can make a weak system look strong. The simplest fix is a holdout test: temporarily hide a small set of your rated movies, build recommendations from the rest, then check whether the hidden favorites show up.

Here is a practical workflow that works even with a small personal dataset:

• Step 1: Pick holdouts. Choose 5–10 movies you rated highly (for example, 4–5 stars) and hide them. If you want a tougher test, include a couple of “disliked” movies too.
• Step 2: Train. Build your recommenders using only the remaining ratings.
• Step 3: Predict. Generate a top-N list (top 10, 20, or 50).
• Step 4: Check recovery. Do any of the hidden favorites appear? Are they near the top?

This is the train-vs-test idea in plain form. The “train” set is what the system is allowed to learn from. The “test” set is what you use to evaluate. You are not proving scientific truth—you are making sure your system can generalize beyond the exact inputs it was fed.

Common mistakes here are subtle. First, don’t hold out only the most famous movies; those are easy to “recover” because they are popular and well-connected. Mix in a couple of niche favorites. Second, do not change multiple things at once (new filters, new weights, new data) and then holdout-test—otherwise you won’t know what caused an improvement.

When your holdout results are weak, treat it as a diagnostic, not a failure. It often means you need more ratings, better genre/tag coverage, or a simple tweak like filtering out titles you already watched.

Section 5.3: Human checks: variety, freshness, and relevance

Metrics are helpful, but movie nights are human. After you generate a top-N list, do a “quick scan” review using three lenses: variety, freshness, and relevance. This takes five minutes and catches issues that numbers miss.

Variety answers: “Does the list feel like a buffet or like one aisle of a grocery store?” If your top 20 contains 18 action movies, your system may be stuck in a same-genre loop. A simple check is to count genres (or your own tags) in the list and confirm you have at least 3–5 distinct buckets. If you don’t have genre data, you can approximate variety by release year bands or by MPAA rating.

Freshness answers: “Is this list teaching me anything new?” A recommender that only returns movies you already know is not useless, but it is not adding value. Mark each recommendation as “already knew” vs. “new to me.” If fewer than ~20–30% are new, add exploration: allow less-similar items, widen year ranges, or include under-seen movies from adjacent genres.

Relevance answers: “Do these match the mood I tend to enjoy?” Relevance is where your personal ratings matter. If you love slow mysteries but the list is full of loud blockbusters, something is off: either your ratings don’t reflect your true preferences (inconsistent ratings), or your recommender is over-weighting popularity or a single feature like genre.

• Practical tip: Keep a small “do not recommend” filter list (movies you’ve watched, franchises you’re tired of, or titles you strongly disliked). Removing obvious no’s makes the list feel smarter immediately.

These checks also help you define what “good” means for your movie nights. A couple might matter more than others. For example, if you mostly watch with friends, variety might be more important than precision. If you watch alone and know your taste well, relevance may dominate.

Section 5.4: Basic metrics: hit rate and top-N accuracy (plain)

Now add two simple metrics that work well with holdout tests and small datasets: hit rate and top-N accuracy. They sound technical, but you can compute them with basic counting.

Hit rate asks: “Did the recommender find any of my held-out favorites?” If you hold out 10 favorite movies and your top-20 list includes 3 of them, you got 3 hits. You can report hit rate as a fraction: 3/10 = 0.30. This metric is forgiving and useful early on, because it rewards systems that surface at least some true favorites.

Top-N accuracy (in this beginner course) is a plain version of the same idea: “What share of the top-N recommendations are actually good, according to my test set?” One practical approach is to treat your held-out favorites as “relevant,” then count how many of the recommended titles are in that set. If your top 20 includes 3 held-out favorites, top-20 accuracy is 3/20 = 0.15. This is stricter because it penalizes filler items.

• How to use them: Pick a consistent N (like 20) and compute both numbers for each recommender and each change you make.
• How to interpret: On tiny datasets, absolute values will be low. You’re looking for direction: did metric values improve after your tweak?

Common mistakes: First, changing N between experiments makes comparisons meaningless (top-10 and top-50 are different tasks). Second, using only “favorites” as relevant can bias you toward narrow tastes; if you also want “pleasantly fine” movies, consider holding out a few 3–4 star items as additional relevant targets.

These metrics are not the full story; they ignore diversity and freshness. That’s why you pair them with the human checks from the previous section.

Section 5.5: Debugging: why bad recommendations happen

When recommendations are bad, they are usually bad in predictable ways. Debugging is easier when you name the failure mode, then apply a targeted fix instead of rebuilding everything.

Failure mode 1: Same-genre loop. Your list is 90% one genre or one franchise. Causes include: your ratings are dominated by that genre; your similarity features heavily weight genre tags; or your personalized model over-trusts a single “signal.” Fixes: cap the number of items per genre in top-N; add a diversity re-ranker (simple rule-based); reduce the weight of genre and increase the weight of other signals (year, keywords, cast, or your own tags).

Failure mode 2: Popularity bias. The system recommends the same famous movies everyone recommends. This happens when you use average rating or number of ratings directly, or when similarity is based on co-occurrence in widely watched sets. Fixes: down-weight popularity; filter out movies above a certain “seen by everyone” threshold; or add a small boost for less-watched items (an “exploration” bonus).

Failure mode 3: Cold start (not enough personal data). With only a handful of ratings, the system cannot infer your taste. Symptoms: generic results or unstable lists that change dramatically. Fixes: add 20–30 more ratings; rate across genres you might watch; include a few “strong dislikes” so the model learns boundaries.

Failure mode 4: Data quality issues. Duplicate titles, inconsistent naming, or mixed versions (director’s cut vs. original) can poison similarity. Fixes: deduplicate; standardize titles and years; merge alternate versions when appropriate; and ensure your watched list filter is accurate.

Failure mode 5: Leaky evaluation. Your metrics look great, but only because you accidentally evaluated on training data or held out only extremely popular favorites. Fixes: re-run holdouts with a mix of mainstream and niche picks; keep your evaluation procedure consistent and written down.

Debugging is part of building trust. When you can explain why a bad recommendation happened, you can also decide whether it is acceptable (one-off oddity) or a sign the system needs adjustment.

Section 5.6: Iteration: adjust inputs, rerun, compare results

Improving a beginner recommender is mostly about small, disciplined iterations. You will change one thing, rerun the pipeline, then compare results using the same holdout test, the same N, and the same human checklist.

Here are simple changes that often produce immediate gains:

• Adjust weights: If your “movies for you” scorer combines signals (similarity, genre match, year proximity, popularity), try increasing the weight on similarity to your top-rated movies and decreasing raw popularity.
• Add filters: Remove already-watched titles, exclude sequels if you’re burned out, or filter by runtime if you want weeknight picks.
• Introduce a diversity rule: After ranking, enforce a maximum of, say, 5 movies per genre in the top 20, or require at least 3 genres represented.
• Time-based tuning: If you want newer movies, add a gentle preference for recent years rather than a hard cutoff (hard cutoffs can remove great matches).
• Update your input ratings: Add a few targeted ratings in underrepresented genres. This is often the most effective “model improvement” available to beginners.

After each iteration, record three things in a small log (a note file is enough): the change you made, your hit rate/top-N accuracy on the holdout, and your human scan notes (variety/freshness/relevance). Over time, this becomes your personal “trust checklist.” Before you use the list for a real movie night, confirm:

• You can explain what data the model used and what it ignored.
• Your top-N list excludes watched titles and obvious no’s.
• Variety is acceptable for the setting (solo vs. group).
• Freshness exists: some items are new to you.
• Holdout test shows at least a few recovered favorites.

This is the practical outcome of evaluation: you turn recommendation quality from a feeling into a repeatable routine. Once you have that routine, updating your list over time—new ratings, new releases, shifting tastes—becomes simple: change, rerun, compare, and keep what demonstrably improves your movie nights.

Your recommendations become useful when they are easy to scan, sort, and act on. A “real-world” list is not just titles—it includes metadata that helps you decide what to watch next and helps you debug the system later. Start by deciding what you are publishing: a top-20 “watch soon” list and optionally a top-50 “consider later” list. The top-20 is your operational list; the top-50 is a backlog that you can reshuffle after you watch something.

Use a consistent table schema. A practical minimum is: rank, title, year, your_score (predicted rating or relevance), source_model (similar-movies vs movies-for-you), because (short explanation), and status (unwatched/watched/skipped). If you have it, add genres, runtime, where_to_watch (optional), and date_added. These fields make your list actionable and make maintenance easier.

• Engineering judgment: pick one scoring scale (e.g., 0–5 stars or 0–100). Mixing scales is a classic mistake that makes ranks meaningless.
• Data checks: remove duplicates (same movie, different spellings), verify year is numeric, and ensure each row has a stable identifier (e.g., IMDb ID) if you have one.
• Watchability filter: apply simple constraints that match your life: “under 140 minutes on weekdays,” “family-safe on Fridays,” or “no horror after 10pm.” These filters are not cheating; they are product requirements.

Once you have a long candidate list from both recommenders, merge them into one table and deduplicate by ID or normalized title+year. Then sort by score and keep the top-20 (or top-50). If two movies are nearly tied, break ties with practical rules: prefer items available on your services, shorter runtimes, or genres you want to explore. This is where human judgment is supposed to enter—recommendation systems are decision support, not decision replacement.

Explanations make recommendations trustworthy. Without them, a list feels arbitrary and you can’t tell whether the system is capturing your taste or just popular titles. Your explanations do not need to be “AI-generated essays.” A single sentence or phrase is enough if it is specific and consistent.

For a similar-movies recommender, explanations are often easiest: “Because you liked Movie A and Movie B.” Choose the top 1–3 most similar movies from your history that contributed to the recommendation. If your similarity model is based on genres or embeddings, you can also mention shared attributes: “Similar tone: slow-burn thriller; shares director; same subgenre (neo-noir).” Keep it honest—only claim features your data actually supports.

For a movies-for-you model (often based on your ratings patterns), your explanation can be anchored in your high ratings: “You tend to rate ensemble comedies highly,” or “You rate character-driven dramas 4+.” If you don’t have enough metadata to justify that statement, fall back to the simplest reliable form: “Recommended because it matches movies you rated 4–5 stars.”

• Common mistake: writing explanations that sound confident but are unverifiable (“You’ll love this because it is objectively the best”). Prefer evidence: similarity links, shared genres, or your own rating behavior.
• Practical tip: store the explanation inputs, not just the final text—e.g., because_movie_ids or because_titles. That makes refreshes repeatable.

When you review the top-20, use explanations as a debugging tool. If you see “Because you liked Movie X” but you actually rated Movie X poorly, your pipeline may be using the wrong subset of ratings (e.g., including 2-star movies as “liked”). Fixing the explanation logic often reveals scoring bugs you would otherwise miss.

A recommendation list decays quickly because your taste evolves and your available catalog changes. The good news is you don’t need complex MLOps to maintain a personal system—you need a routine. Choose an update cadence you can sustain: weekly if you watch several movies, monthly if you watch occasionally. The rule is consistency over intensity.

Your refresh routine can be a checklist:

• Add new ratings: after you watch a movie, record a rating plus a short note (“too slow,” “great ending,” “loved the dialogue”). Notes help later when you question your own data.
• Re-run basic data checks: missing titles, duplicate IDs, invalid years, out-of-range ratings (e.g., 6 on a 1–5 scale).
• Update candidate pool: add newly discovered movies (trailers, friends, awards lists) and remove movies you can’t access or no longer want.
• Recompute recommendations: regenerate both models, merge, dedupe, and rebuild top-20/top-50.
• Archive old lists: keep a snapshot with a date so you can compare changes and learn what the system is doing.

Engineering judgment matters when you decide what changes trigger a refresh. If you only rate one new movie, you might not need to rerun everything; you can append it and wait until month-end. But if you rate a movie that strongly reveals a new preference (for example, you discover you love classic musicals), it’s worth refreshing sooner.

A common maintenance mistake is “ratings drift”: you start using 4 stars differently over time. If you notice your average rating creeping upward, consider normalizing (e.g., subtract your mean rating) or adopting a stable rubric (“5 = favorites I would rewatch; 4 = strong recommend; 3 = okay; 2 = not for me; 1 = disliked”). Consistent ratings make your recommenders more stable.

Even a personal recommendation system has ethical dimensions because it shapes what you consume. Two practical risks are filter bubbles (you keep getting the same kind of movie) and unnoticed bias (systematically excluding certain eras, countries, languages, or creators). You can address both with lightweight, beginner-friendly rules.

Start by measuring your list’s diversity in simple terms: count genres, decades, and original languages in your top-20. If 16 of 20 are the same genre or decade, that might be fine for a week—but if it stays that way month after month, you are likely trapped in a narrow loop driven by your own past ratings.

• Diversity constraint: reserve 3–5 slots in the top-20 for “exploration picks.” These can be high-quality out-of-genre movies or items with high critic scores but low similarity to your history.
• Fair exposure: when merging recommenders, do not let one model dominate. For example, cap “similar movies” to 12 slots and “movies for you” to 8, or alternate ranks.
• Avoid proxy bias: popularity-based signals can erase niche films. If your candidate pool is sourced from “most popular” lists, you may never see smaller releases. Add at least one curated list that reflects different regions or communities.

Also watch for “taste overfitting”: if you only rate movies you already expect to like, your system becomes self-confirming. The fix is to intentionally rate a few wildcards. Not all exploration needs to become part of your identity; it just keeps your system honest and helps you discover new favorites.

Ethics here is not about being perfect—it’s about designing your workflow so it doesn’t quietly narrow your world. A small diversity rule plus an exploration budget is often enough to keep your personal recommender both satisfying and growth-oriented.

Your ratings and watch history are personal preference data. They can reveal sensitive information: mood, relationships (shared viewing), religion or politics (documentaries), or health interests. Treat your dataset as something you would not casually publish. You can still share your recommendations—just separate the output list from the underlying data.

Basic privacy practices for this course project:

• Minimize: store only what you need. If “date watched” is not important, omit it. If you keep notes, avoid highly personal details.
• Separate files: keep ratings.csv private, and share only recommendations.csv with explanations that do not expose exact ratings.
• Remove identifiers: if you ever include other people (family ratings), do not store names—use anonymous IDs, or don’t store their data at all.
• Access control: if using Google Sheets/Notion, check sharing settings. “Anyone with link can view” is easy to forget and hard to detect later.

If you want to publish your project (portfolio, blog), consider creating a synthetic or redacted version of your dataset: keep the structure but replace titles with categories, or include only aggregate statistics (counts by genre, sample rows with fictional movies). Your learning outcome remains valid without exposing your private taste profile.

The common mistake is assuming “it’s just movies.” In reality, preference data is a fingerprint. Build the habit now: share outputs, protect inputs.

At this point, you should be able to hand your future self (or a friend) a clean, usable recommendation artifact. Your final deliverables are simple but complete:

• Top-20 (or top-50) list: ranked, deduplicated, and filtered for watchability.
• Explanations column: “because you liked…” evidence tied to your own history or model signals.
• Status tracking: unwatched/watched/skipped plus optional “next up” marker.
• Exported format: CSV for portability, plus a shareable version (Google Sheet, Notion, or Markdown table) for convenience.
• Update routine: a weekly/monthly checklist and a place to store dated snapshots.

When exporting, prefer CSV with UTF-8 encoding and stable column names. This makes it easy to import later into Python, spreadsheets, or another tool. If you share a public version, create two exports: (1) recommendations_public.csv with titles, year, genres, and explanations; (2) ratings_private.csv stored locally or in a private drive.

For next steps, you have several good learning directions that build naturally from this project: add richer metadata (cast, director, keywords), try a simple train/test split to evaluate “did I watch it and like it?”, or experiment with a hybrid ranker that blends similarity, predicted rating, and diversity. Most importantly, keep using the system. Each time you watch and rate, you are collecting better training data—and you are practicing the real skill behind machine learning: turning messy human preferences into a dependable workflow.

Chapter 6 is your “ship it” moment. A beginner recommendation system becomes real when it is readable, explainable, refreshable, and safe to share.